Network Working Group Keyur Patel Internet Draft Cisco Systems Expiration Date: April 2004 Radia Perlman Sun Microsystems Dino Farinacci Greg Shepherd Procket Networks Marshall Eubanks Multicast Technologies Automatic Multicast Access Protocol draft-keyur-amap-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes a new multicast signaling protocol for solving the "last-mile connectivity" problem for multicast. This protocol is called Automatic Multicast Access Protocol (AMAP). It is intended to facilitate an endnode that resides in a portion of the Internet infrastructure without multicast support, or whose OS does not support IGMPv3 (SSM stype groups). 3. Introduction An impediment to getting end-to-end multicast connectivity is that, currently, ISPs seldom enable multicast routing within an entire AS. This makes end-to-end multicast content provision difficult, particularly with respect to Last Mile Multicast. This document proposes a new multicast signaling protocol known as Automatic Multicast Access Protocol (AMAP) which allows endnodes residing in portions of the Internet infrastucture without any multicast support to join multicast groups. AMAP allows endnodes which run multicast applications to get the efficiencies of a multicast enabled infrastructure without being directly attached to such an infrastructure. This is achieved using a tunneling mechanism. As the multicast infrastructure deployment moves towards the edge of the network, the tunnel diameter is reduced to a point where it is either minimised or no longer needed. AMAP could be used for both SSM as well as ASM style multicast. For endnodes residing in a portion of the Internet without any support for multicast, this mechanism could be used for ASM groups by using a Replicator address in place of an explicit root address. A Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 1] Internet Draft draft-keyur-amap-00.txt October 2003 Replicator address is an address of a router which serves as a tunnel endpoint for all/set of receivers within an AS. A well known anycast address, which is a valid unicast address assigned to multiple routers to get "closest replicator capability" defined by IANA, can be used as a Replicator address within an AS. Any router that does not support this protocol will simply unicast forward the messages according to the rules for forwarding a packet with the Router Alert set. The first multicast capable router that supports AMAP will notice these messages and may form a tunnel with the endnode that generated the message. 4. AMAP Messages This section defines different message formats for AMAP. AMAP messages are sent unicast to a particular source or an endnode, or towards a Replicator address. AMAP messages are sent as IP protocol type = "UDP" with the port number TBD by IANA. An implementation of AMAP must support all the message types described below. Any unrecognized messages should be logged with a fatal warning. Each AMAP message has a fixed size header. The layout of this header is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Res | Type | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AMAP Ver AMAP Version number is 1. Reserved Set to zero on transmission. Ignored upon receipt. Type Types for specific AMAP messages. AMAP Types are: Message Type Source Destination ------------------------------------------------------------------------- 0 = Query Message Router Unicast to Endnodes 1 = Join Message Endnode Unicast to Source/ Replicator address 2 = Join-Ack Message Router Unicast to Endnodes 3 = Auth Ack Router/Endnode Unicast to Source/Endnodes 4 = Prune Message Router/Endnode Unicast to Source/Endnodes 5 = Prune-Ack Message Router/Endnode Unicast to Source/Endnodes 6 = Data Message Router Unicast to Endnodes 7 = Notification Message Router/Endnode Unicast to Source/Endnodes Checksum The checksum is a standard IP checksum, i.e. the 16-bit one's complement of the one's complement sum of the entire AMAP message. For computing the checksum, the checksum field is zeroed. For IPv6, the checksum also includes the IPv6 "pseudo-header", as specified in RFC 2460, section 8.1 [5]. This "pseudo-header" is prepended to the AMAP header for the purposes of calculating the checksum. The "Upper-Layer Packet Length" in the pseudo-header is set to the length of the AMAP message. The Next Header value used in the pseudo-header is 103. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before performing the checksum. Encoded format for Unicast Source and Group address is shown below: Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 2] Internet Draft draft-keyur-amap-00.txt October 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Addr Family The AMAP address family of the 'Unicast Address' field of this address. Values of 0-127 are as assigned by the IANA for Internet Address Families in [8]. Values 128-250 are reserved to be assigned by the IANA for PIM-specific Address Families. Values 251 though 255 are designated for private use. As there is no assignment authority for this space, collisions should be expected. Encoding Type The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family. Unicast Address The unicast address as represented by the given Address Family and Encoding Type. 4.1 AMAP Router Query message format Query messages are sent by AMAP routers to its tunnel endpoints for periodic refresh of their multicast state. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast Router address (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unicast Router Address Unicast address of an AMAP router generating Query messages. For format description refer to Encoded-Unicast address. 4.2 AMAP Host Join message format Host Join messages are sent to assist building and maintainence of tunnel states for (S/*, G) entries. Host Join messages are sent by endnodes towards a Source address/Replicator address. For all (S, G) Host Join messages, the Multicast Source Address will have a non-zero unicast address field. For all (*, G) Host Join messages, the Multicast Source Address will have a zero unicast address field. AMAP implementations are suggested to send seperate Host Join messages for (S, G) and (*, G) entries. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num Jn groups | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tn Format | Replicator Address (Encoded format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Source Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address n (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable length TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 3] Internet Draft draft-keyur-amap-00.txt October 2003 Reserved Transmitted as zero, ignored upon receipt. Number of Join Groups The number of multicast group sets contained in the message. Holdtime The amount of time a receiver must keep the tunnel state alive in seconds. If the Holdtime is set to `0xffff', the receiver of this message should hold the state until canceled by the Prune message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with the periodic Join or Prune messages. Tunnel Type A specific type of tunnel that an endnode wants to use with an AMAP Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload). Replicator address Address assigned to an AMAP router. When used in anycast-mode, it is an address assigned to multiple AMAP routers to get "closest replicator capability". For format description refer to Encoded-Unicast address. Multicast Source address Sender address that the endnode is interested in receiving data from. For format description refer to Encoded-Unicast address. Join Group Address 1 .. n This list contains the Groups that the endnode is interested in receiving data from. For format description refer to Encoded-Unicast address. Variable length TLVs The Encoded format for TLVs is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type A 16 bit field set to 1. Length A 16 bit field that indicates the length of the value portion in bytes. Capabilities This comprises one or more capability values. 4.3 AMAP Router Join-Ack message format Router Join-Ack messages are sent to acknowledge the receipt of the Host Join message by AMAP routers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num Jn groups | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tn Format | Multicast Source Address (Encoded format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address n (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable length TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 4] Internet Draft draft-keyur-amap-00.txt October 2003 Reserved Transmitted as zero, ignored upon receipt. Number of Join Groups The number of multicast group sets contained in the message. Holdtime The amount of time a receiver must keep the tunnel state alive in seconds. If the Holdtime is set to `0xffff', the receiver of this message should hold the state until canceled by the Prune message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with the periodic Join or Prune messages. Tunnel Type A specific type of tunnel that an endnode wants to use with an AMAP Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload). Multicast Source address Sender address that the endnode is interested in receiving data from. For format description refer to Encoded-Unicast address. Join Group Address 1 .. n This is an accepted list of Groups for which the sending router may establish tunnel connection with an endnode. For format description refer to Encoded-Unicast address. Cookie Value Router cookie value that is reflected back in Auth-Ack message. Variable length TLVs See Encoded-TLV format. 4.4 AMAP Prune message format Prune messages are sent to terminate existing tunnel connections for (S/*, G) entries. Prune messages are sent by endnodes/AMAP routers towards a source/replicator address or an endnode address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Holdtime | Tn Format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replicator Address (Encoded format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Source Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Transmitted as zero, ignored upon receipt. Holdtime The amount of time a receiver must keep the tunnel state alive in seconds. If the Holdtime is set to `0xffff', the receiver of this message should hold the state until canceled by the Prune message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with the periodic Join or Prune messages. Tn Format A specific type of tunnel that an endnode wants to use with an AMAP Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload). Replicator address Address assigned to an AMAP router. When used in anycast-mode, it is an address assigned to multiple AMAP routers to get "closest replicator capability". For format description refer to Encoded-Unicast address. Multicast Source address For format description refer to Encoded-Unicast address. Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 5] Internet Draft draft-keyur-amap-00.txt October 2003 Prune Group Address Group address to be pruned. For format description refer to Encoded-Unicast address. 4.5 AMAP Prune-Ack message format Prunes-Ack messages are sent to acknowlege the receipt of the Prune messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Holdtime | Tn Format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replicator Address (Encoded format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Source Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Transmitted as zero, ignored upon receipt. Holdtime The amount of time a receiver must keep the tunnel state alive in seconds. If the Holdtime is set to `0xffff', the receiver of this message should hold the state until canceled by the Prune message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with the periodic Join or Prune messages. Tn Format A specific type of tunnel that an endnode wants to use with an AMAP Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload). Replicator address Address assigned to an AMAP router. When used in anycast-mode, it is an address assigned to multiple AMAP routers to get "closest replicator capability". For format description refer to Encoded-Unicast address. Multicast Source address Sender address to be pruned. For format description refer to Encoded-Unicast address. Prune Group Address This contains the Group address to be pruned. For format description refer to Encoded-Unicast address. Cookie Value Sender's cookie value that is reflected back in an Auth-Ack message. 4.6 AMAP Host Auth-Ack message format Auth-Ack messages are sent to acknowledge the receipt of a Join-Ack message or a Prune-Ack message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Prune/Join | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prune-Ack/Join-Ack message / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Transmitted as zero, ignored upon receipt. Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 6] Internet Draft draft-keyur-amap-00.txt October 2003 Prune/Join Auth message sent in respone to 0 (Join-Ack) 1 (Prune-Ack). Cookie Value Sender's cookie value that is reflected back in Auth-Ack message. Prune-Ack/Join-Ack message Received AMAP Prune-Ack message/Join-Ack message triggering the Auth-Ack message. 4.7 AMAP Notification message format Notification messages are sent either by an AMAP router or an endnode intiating a tunnel connection. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Source Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Cookie Value (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Cookie Value (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type/Subtype AMAP Notification message are of following types: Type: 1 Error Message Subtype: 1 Incorrect Version Number 2 Incorrect Cookie Value 3 Incorrect Message Type 4 Incorrect Address Encoding format 5 Incorrect Message Length 6 Unrecognised Route Entry Pruned 7 Unrecognised Capability 8 Incorrect Capability length 9 Incorrect Tunnel format 10 Incorrect Destination Multicast Source address Multicast Source address for which the Notification is sent. For format description refer to Encoded-Unicast address. Prune Group Address Multicast Group address for which the Notification is sent. This contains the Group address to be pruned. Destination Cookie Value Destination receiving Notification message's Cookie value. This field is optional Source Cookie Value Source generating Notification message's Cookie value. This field is optional. All Notification messages must be logged. An implementation can choose to terminate tunnel connections for (S/*, G) route entries for which a Notification message received has cookie values successfully verified. 5. Protocol Description for Endnodes AMAP has a seperate protocol behavior for endnodes initiating the tunnel connections to join multicast (S/*, G) channels and AMAP routers terminating tunnel connections. This section describes the protocol behavior for the endnodes initiating the tunnel connections. Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 7] Internet Draft draft-keyur-amap-00.txt October 2003 5.1 Generating Join Messages There are two main events that trigger generation of the Join messages for initiating (S/*, G) tunnel connections: * Applications residing on an endnode wanting to join a particular/set of (S/*, G) groups. * Reception of a Query message. The following subsections describe actions to be taken for each of the above cases. 5.1.1 Applications triggering a Join message Whenever an endnode running multicast applications in a non-multicast network wishes to join a particular (S/*, G) channel, it signals AMAP with relevant parameters: (S/*, G) sets, a Replication address, and a configured cookie value. AMAP schedules a Join-expire timer with a configured/(default holdtime interval)/3. AMAP creates an appropriate Join message and sends it towards a Replication address if specified, or the Source address. 5.1.2 Reception of a Query message Whenever an endnode running AMAP receives a Query message, it processes the message. It verifies the querier's router address with the stored router address in the tunnel interface information. It [re-]schedules the Join-expire timer to the join-expire interval. The suggested default value for the join-expire interval is set to the AMAP router's (Holdtime interval)/3 (received in a Join-Ack message). It also [re-]schedules the query-expire timer to an query-expire interval. The suggested default value for the query-expire interval is set to the AMAP router's (Holdtime interval)/3 (received in a Join-Ack message). It then sends a Join message for all (S/*, G) entries for which the querier acts as a tunnel endpoint. 5.2 Generating Prune message Whenever a particular (S/*, G) channel is no longer required, a Prune message is sent to the tunnel endpoint. An endnode running AMAP schedules the Prune-expire timer to the prune-expire interval. The suggested default value for the prune-expire interval is set to the AMAP router's (Holdtime interval)/3 (received in a Join-Ack message). It then sends a Prune message for a (S/*, G) channel to the AMAP router that acts as a tunnel endpoint. 5.3 Generation of an Auth-Ack message Auth-Ack message is sent in response to the received Join-Ack message or a Prune-Ack message. An Auth-Ack message is sent with the cookie value received in a Join-Ack/Prune-Ack message from the AMAP router. Tunnel connection is either considered functional (if sent in response to the Join-Ack message) or deleted (if sent in response to the Prune-Ack message) once an Auth-Ack message is sent by an endnode to the AMAP router. 5.4 Reception of Data message Data messages are encapsulated in an negotiated tunnel format by AMAP routers. Whenever an endnode receives a data message, its encapsulated format is verified with the stored negotiated format. If the tunnel format differs, then a Notification message is sent and the tunnel connection is terminated. Otherwise, data packets received are decapsulated and sent to appropriate applications. Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 8] Internet Draft draft-keyur-amap-00.txt October 2003 5.5 Reception of Prune message Whenever an endnode receives a Prune message for a given (S/*, G) entry from an AMAP router, it checks to verify if the sending AMAP router is acting as a tunnel endpoint. In case of an error, the Prune message is ignored and a Notification message is sent to an AMAP router. Otherwise, the PruneAck-expire timer is scheduled for the prune-expire interval and a Prune-Ack message is sent to an AMAP router. An endnode cookie is passed in the Prune-Ack message. 5.6 Reception of an Auth-Ack message An Auth-Ack message is received in response to any Prune-Ack message sent by an endnode. Whenever an endnode receives an Auth-Ack message, it processes the message. It verifies cookie values sent within an Auth-Ack message. In the event of an error, a Notification message is sent and an Auth-Ack message is ignored. Otherwise, the PruneAck-expire timer is stopped for all (S/*, G) entries mentioned in the Auth-Ack message. At this point the tunnel is disconnected and the state is removed as described in [6.7]. 5.7 Timer expiry In the event of a join-expire, prune-expire, or a query-expire timeout, a Notification message is sent and the tunnel connection is disconnected. 6. Protocol Description for AMAP Routers This section describes the protocol behavior for AMAP routers. Multicast routers implementing AMAP will process Join messages according to rules defined in this specification even when the IP destination address is not assigned to the router. To allow a router to recognize AMAP messages addressed to the unicast root address, and place it on the slow path, rather than simply forwarding it towards the specified destination, Join messages will have the router alert option, and the IP protocol type="UDP" with port number TBD by IANA. 6.1 Reception of a Join message Whenever an AMAP router intercepts a Join message it verifies them with its locally configured policies. If the locally configured policies disallow the router from intercepting Join messages, then it simply forwards the message towards the destination. All the multicast routers forwarding AMAP packets towards the desired destination must use unicast RIB to resolve destination address. Otherwise, the intercepting router processes the received Join message. In the event of an error, the intercepting router should drop the received Join message and send a Notification message to an endnode. Otherwise, the intercepting router schedules a JoinAck-expire timer for join-expire interval and sends a Join-Ack message to the endnode. The suggested default value for the join-expire interval is set to the endnode's (Holdtime interval)/3 (received in a Join message). A router based cookie value is sent in the Join-Ack message. In an event where an AMAP router processes and resolves a subset of the (S/*, G) entries received in a Join message, the AMAP router should send a Join-Ack message for only those entries which are resolved. For all unresolved (S/*, G) entries, the AMAP router forwards them towards the direction of the Source address/Replication address in the IP destination of the Join message. 6.2 Reception of a Prune message Whenever an AMAP router receives a Prune message for a given (S/*, G) entry, it checks to verify if the sending endnode is a tunnel endpoint. In case of an error the Prune message is ignored and a Notification message is sent to an endpoint. Otherwise, the PruneAck-expire timer is scheduled Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 9] Internet Draft draft-keyur-amap-00.txt October 2003 for the prune-expire interval and the Prune-Ack message is sent to an endnode. The suggested default value for the Prune-expire interval is set to the endnode's (Holdtime interval)/3 (received in a Prune message). A router based cookie value is sent in the Prune-Ack message. 6.3 Reception of an Auth-Ack message Auth-Ack messages are received in response of: * AMAP router's Join-Ack message sent * AMAP router's Prune-Ack message sent The following subsections describe actions to be taken for each of the above cases. 6.3.1 Auth-Ack message in response of a Join-Ack message Whenever an AMAP router receives an Auth-Ack message, it processes the message. It verifies cookie values sent within an Auth-Ack message. In the event of an error, a Notification message is sent and an Auth-Ack message is ignored. Otherwise, the JoinAck-expire timer is stopped for all (S/*, G) entries mentioned in the Auth-Ack message. This signals the successful completion of the tunnel signaling between an endnode intiating the tunnel connection and an AMAP router terminating the tunnel connection. At this point the tunnel is setup and the state is created as described in [6.7]. An AMAP router starts to send multicast packets over the tunnel. 6.3.2 Auth-Ack message in response of a Prune-Ack message Whenever an AMAP router receives an Auth-Ack message, it processes the message. It verifies cookie values sent within an Auth-Ack message. In the event of an error, a Notification message is sent and an Auth-Ack message is ignored. Otherwise, the PruneAck-expire timer is stopped for all (S/*, G) entries mentioned in the Auth-Ack message. At this point the tunnel is disconnected and the state is removed as described in [6.7]. An AMAP router stops sending multicast packets over the tunnel for all (S/*, G) entries metioned in the Auth-Ack message. 6.4 Generation of an Auth-Ack message Auth-Ack message is sent in response to the received Join-Ack message or a Prune-Ack message. An Auth-Ack message is sent with the cookie value received in the Join-Ack/Prune-Ack message from the AMAP router. The tunnel connection is either considered functional (if sent in response to a Join-Ack message) or deleted (if sent in response to a Prune-Ack message) once an Auth-Ack message is sent by an endnode to the AMAP router. 6.5 Generating a Prune message AMAP routers can generate Prune messages whenever they loose upstream connectivity or due to some local policy reasons. An AMAP router schedules the Prune-expire timer to the prune-expire interval. The suggested default value for the prune-expire interval is set to endnodes's (Holdtime interval)/3. It then sends a Prune message for (S/*, G) entry to all/a subset of endnodes listed in the oif-list of (S/*, G) entry. 6.6 Generating a Query message AMAP routers acting as a tunnel endpoint for various (S/*, G) entries will periodically query all its interested tunnel endnodes by sending a Query message. An AMAP router sends Query messages every query-expire interval. The suggested default for the query-expire interval is set to an endnode's (Holdtime interval)/3 (received in a Join message). AMAP routers keeps track of all the tunnel destinations (regardless if the tunnel destination is joined to one or more route entries). Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 10] Internet Draft draft-keyur-amap-00.txt October 2003 Any (S/*, G) entries not refreshed by the endnodes in their Join messages sent in response to Query messages within a join-expire interval will be immediately dropped. This assists AMAP routers sending the Query messages and endpoints replying with the Join messages to detect any unwanted tunnel breakages. The holdtime used in Join messages and Join-Ack messages determines the maximum waiting time that an AMAP router and an endnode should wait before terminating a tunnel at each end. If an endnode fails to receive a Query message for more than the Holdtime interval advertised by an AMAP router in its Join-Ack message, then it terminates and re-initiates tunnel connection. Similarly if the Join messages are not received for more than the Holdtime interval advertised in the previous Join message, then the router removes the tunnel interface from its (S/*, G) entries. Any (S/*, G) entries created with a holdtime value of '0xffff' need not be refreshed periodically using Query messages. Such (S/*, G) entries can only be explicitly removed using Prune messages or timed out using local policies. 6.7 Reception of Data messages Data messages are either received as native multicast, or as encapsulated in a negotiated tunnel format. Whenever an AMAP router receives encapsulated data messages, its encapsulated format is verified with the stored negotiated format. If the tunnel format differs, then the Notification message is sent and tunnel connection is terminated. If an (S/*, G) entry exists for data messages received, then the messages are encapsulated with a negotiated tunnel format and forwarded to all the AMAP tunnel endpoints listed in the oif-lists. Otherwise, data messages are dropped and a Prune message is sent to the upstream router. 6.8 Timer expiry In the event of join-expire, prune-expire, or a query-expire timeout, a Notification message is sent and the tunnel connection is disconnected. 6.9 State Creation and Deletion AMAP routers will add the tunnel interfaces [8] in its (S/*, G) oif-lists when it receives an Auth-Ack message in response to a Join-Ack message from the endnodes. An implementation must have a configured upper bound on the number of the tunnel interfaces that it can put in oif-lists of any (S/*, G) entry. If a tunnel interface added is the first interface in an oif-list, and if Multicast router has PIM enabled, then the PIM Protocol should be signaled for generation of a PIM Join message. AMAP routers will delete the tunnel interfaces from their (S, G) oif-lists when: * It receives an Auth-Ack message in response to a Prune-Ack messages from endnodes. * Any of the Join-expire, or Prune-expire, timers for the tunnel interfaces expire and its state is not refreshed. * If a Join message (in reponse to a Query message) is not received within a Holdtime interval. * If a Query message is not received from a tunnel endpoint within a query-expire interval. * AMAP routers sends an Auth-Ack message in response to a Prune-Ack message received from endnodes. Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 11] Internet Draft draft-keyur-amap-00.txt October 2003 6.10 Signaling and Forwarding Rules: Whenever multicast routers implementing AMAP receive Join messages from any endnodes, the following is done: The received (S/*, G) entry is looked up in the Multicast Routing Table. If the entry does not exist, then the (S/*, G) entry is created. * If a Join message or a Prune message has a non-zero Source address, (i.e (S, G) and not (*, G)) then the next hop for the Source address check is done. If the next hop is a PIM neighbor, or it is directly connected (and PIM enabled) then a JoinAck-expire timer is scheduled for the join-expire interval and a Join-Ack message is sent to an endnode. * If the next hop is neither a PIM neighbor nor directly connected, then the packet is forwarded towards the ip destination address. If the (S/*, G) entry was created as a result of a lookup, then delete the (S/*, G) entry from the Multicast Routing Table. * If there is no source address (i.e (*, G)), then check for the group mapping in the RP cache. If the group mapping is found for a particular entry then schedule a JoinAck-expire timer for the join-expire interval and send a Join-Ack message to an endnode. Otherwise, forward the Join message towards the ip destination address. If the (*, G) entry was created as a result of lookup, then delete the (*, G) entry from the Multicast Routing Table. Whenever Multicast routers implementing AMAP receive an Auth-Ack message for a Join message, the following is done: * Stop the JoinAck-expire timer. * Add the tunnel interface to the Outgoing Interface List (oif-list) of (S/*, G) entry. * For all (S, G) route entries, signal PIM to send a PIM Join message towards the Source address if PIM is enabled. * For all (*, G) route entries, signal PIM to send a PIM Join message towards the RPL address if PIM is enabled. Whenever multicast routers implementing AMAP receive Prune messages from any endnodes, the following is done: The received (S/*, G) entry is looked up in the Multicast Routing Table. If the entry does not exist, then a Notification message is sent for the received (S/*, G) entry. * If the entry is found, then a PruneAck-expire timer is scheduled for the prune-expire interval and a Prue-Ack message is sent to an endnode. Whenever multicast routers implementing AMAP receive an Auth-Ack message for Prune messages, the following is done: The received (S/*, G) entry is looked up in the Multicast Routing Table. If the entry does not exist, then a Notification message is sent for the received (S/*, G) entry. * Stop the PruneAck-expire timer. * Remove the tunnel interface to the Outgoing Interface List (oif-list) of (S/*, G) entry. * For all (S, G) route entries, signal PIM to send a PIM Prune message towards the Source address if PIM is enabled. * For all (*, G) route entries, signal PIM to send a PIM Prune message towards the RPL address if PIM is enabled. Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 12] Internet Draft draft-keyur-amap-00.txt October 2003 6.11 Aggregation TBD 6.12 Tunnel Chaining TBD 7. AMAP Message Processing 7.1 Router receiving AMAP Join message Endnode Router ------- ------ Send AMAP Join ------------------> Receive AMAP Join message message for interested (S, G) groups if (error in message processing) Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Appropriate Message Error Code" For each (S, G) received entry, Lookup (S, G) entry. if (entry found) { schedule Join-expire Timer for a received interface if (cookie value != old cookie value) { store the received cookie value } Receive AMAP Join-Ack <------------- send AMAP Join-Ack message message with router cookie value } else { create (S, G) entry Nexthop Lookup for (S). if ((S == Pim Nbr) || (S == directly connected) { schedule Join-expire Timer for a received interface store the received cookie value Receive AMAP Join-Ack <------------- send AMAP Join-Ack message message with router cookie value } else if (!S && group mapping found in RP Cache) { schedule Join-expire Timer for a received interface store the received cookie value Receive AMAP Join-Ack <------------- send AMAP Join-Ack message message with router cookie value Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 13] Internet Draft draft-keyur-amap-00.txt October 2003 } else if (destination in IP (!local interface)) { stop the Join-expire Timer if (multicast enabled) { lookup in MRIB and forward the Join towards source. } else { lookup in unicast RIB and forward the Join towards the source. } } else { Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Incorrect Destination" } } 7.2 Router receiving AMAP Auth-Ack for the Join-Ack message Endnode Router ------- ------ Send AMAP Auth-Ack ----------------> Receive AMAP Auth-Ack for for the Join-Ack the Join-Ack message message if (error in message processing) Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Appropriate Message Error Code" if (error in cookie received) Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Incorrect Cookie Value" Lookup received (S, G) entry if (found) { Stop the Join-expire Timer Add the tunnel interface to outgoing list. if (PIM enabled && first interface) { Send PIM Join message } } else { Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Unrecognised Route Entry Pruned" } 7.3 Router receiving AMAP Prune message Endnode Router ------- ------ Send AMAP Prune ------------------> Receive AMAP Prune message message Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 14] Internet Draft draft-keyur-amap-00.txt October 2003 if (error in message processing) Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Appropriate Message Error Code" Lookup received (S, G) entry and tunnel interface in oif-list if (found) { Start the Prune-expire Timer for received interface Receive AMAP Prune-Ack <------------- Send Prune-Ack message with message the router cookie value } else { Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Unrecognised Route Entry Pruned" } 7.4 Router receiving AMAP Auth-Ack message for the Prune-Ack message Endnode Router ------- ------ Send AMAP Auth-Ack ----------------> Receive AMAP Auth-Ack for for the Prune-Ack the Prune-Ack message message if (error in message processing) Receive AMAP <------------- Send Notification message with Notification message Type="", Subtype= "Appropriate Message Error Code" if (error in cookie received) Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Incorrect Cookie Value" Lookup received (S, G) entry and tunnel interface in oif-list if (found) { Stop the Prune-expire Timer for a received interface Remove the tunnel interface to outgoing list. if (PIM enabled && last interface) { Send PIM Prune message Remove (S, G) entry } } else { Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Unrecognised Route Entry Pruned" } 7.5 Hosts receiving AMAP Join-Ack or Prune-Ack messages Endnode Router ------- ------ Receive AMAP Join/Prune-Ack <-------- Send Join/Prune-Ack message with message the router cookie value Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 15] Internet Draft draft-keyur-amap-00.txt October 2003 Send Auth-Ack message with Router's cookie value ---------> Receive Auth-Ack messages received in Join/Prune message 7.6 Hosts receiving AMAP Query messages Endnode Router ------- ------ Re-schedule Query time schedule Join-expire Timer for a received interface Receive AMAP Query <------------- Send Query message message Send AMAP Join message for interested (S, G) -------------> Receive AMAP Join messages groups 7.7 Routers sending AMAP Prune messages Endnode Router ------- ------ Start the Prune-expire Timer for a tunnel interface Receive an <------------------ Send an AMAP Prune message with AMAP Prune message the router cookie value if (error in message processing) Send Notification message with -> Receive AMAP Notification message Type="Error", Subtype= if (cookie value matches stored "Appropriate Message Error cookie value) { Code" Lookup received (S, G) entry and tunnel interface in oif-list if (found) { Stop the Prune-expire Timer for a received interface Remove the tunnel interface to outgoing list. } } Send AMAP Prune-Ack -------------> Receive Prune-Ack message with message the host cookie value Lookup received (S, G) entry and tunnel interface in oif-list if (found) { Stop the Prune-expire Timer for a received interface Remove the tunnel interface to outgoing list. } else { Receive AMAP <------------- Send Notification message with Notification message Type="Error", Subtype= "Unrecognised Route Entry Pruned" } Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 16] Internet Draft draft-keyur-amap-00.txt October 2003 8. Tunnel Interfaces Because not all intermediate routers support native ip multicast, AMAP requires all the oifs on which it receives Host Join or Prune messages from receivers which are not directly connected to be created as tunnel interfaces. In practice, tunnels typically use either IP-IP [Perk96] or Generic Routing Encapsulation (GRE) [Han94a,Han94b], although, other encapsulation methods are acceptable. 9. Security Considerations AMAP does not change any multicast security issues. PIM is open to many types of resource overload. For instance, a node which transmits from many bogus source addresses will cause PIM routers to join to many (S, G) pairs, eventually exhausting the state. PIM routers must protect themselves by limiting the amount of state for multicast, so that a denial of service attack on multicast will not destroy unicast. With LAN-based IGMP join message, only nodes on the LAN can initiate a join message, so if the LAN is physically protected, and all routers along the path to the RP (or S in an (S, G) join) are trusted, it might be somewhat harder for a node to create a join state untraceably than it would with this tunnel proposal. With this tunnel proposal, the join message is sent over a multi-hop path. As stated in the document, a router is configured with a maximum number of tunnels it is willing to accept, so an attack to deplete its tunnel resources will only affect attempts to create tunnels, and not cause any other denial of service. Additionally, the router to whom tunnels will be created is likely to be the entry router at an ISP, and it can consider an entire customer network to be a LAN. If suspiciously large number of tunnels are being created from that customer network, then the router can start discriminating against join messages from that customer network, when resources are being depleted. Eventually, cryptographic authentication can be added between the joiner and the router, by having potential joiners obtain a key (or certificate) from the router before they are allowed to join, and having join messages cryptographically authenticated. 10. Acknowledgements We express our thanks to Alex Zinin, Lorenzo Vicisano, liming Wei, Tom Pusateri, and Nidhi Bhaskar for their review and comments on the earlier versions of the draft. 11. References [PIM-SM] Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)". [Han94a] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, October 1994. [Han94b] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd., cisco Systems, October 1994. [Perk96] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. Patel, Perlman, Farinacci, Shepherd, Eubanks [Page 17] Internet Draft draft-keyur-amap-00.txt October 2003 12. Author Information Keyur Patel Cisco Systems. Inc. email: keyupate@cisco.com Radia Perlman Sun Microsystems. Inc. email: Radia.Perlman@sun.com Dino Farinacci Procket Networks Inc. email: dino@procket.com Greg Shepherd Procket Networks Inc. email: shep@procket.com Marshall Eubanks Multicast Technologies Inc. email: tme@multicasttech.com