Network Working Group Keyur Patel Internet Draft Cisco Systems Expiration Date: December 2003 Radia Perlman Sun Microsystems Dino Farinacci Greg Shepherd Procket Networks Multicast Signaling Conduit Protocol draft-keyur-mscp-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 an approach for solving the "last-mile" problem for multicast, especially SSM-style multicast, called Multicast Signaling Conduit Protocol (MSCP). It is intended to facilitate an endnode whose OS does not support IGMPv3, or who resides in a portion of the Internet infrastructure without multicast, to join multicast groups. It is especially intended for SSM-style groups, although it could be adapted for use for other multicast groups. Patel, Perlman, Farinacci, Shepherd [Page 1] Internet Draft draft-keyur-mscp-00.txt December 2003 3. Introduction An impediment to getting SSM Multicast deployed is that, as currently specified, it depends on IGMPv3. Since IGMPv3 is in the IP stack, it requires endnodes to upgrade to an OS that supports IGMPv3 and it requires IGMPv3 support on the first hop multicast capable routers as well. This document proposes a new IP protocol known as Multicast Signaling Conduit Protocol (MSCP) which eliminates the requirement of running IGMPv3 both on endnodes as well as first hop multicast capable routers. This draft is solely for the purpose of joining SSM-style groups, i.e., groups in which the IP address of the root is explicitly known by the joining host. This draft allows hosts to join SSM-style groups even if * the host's OS stack does not support IGMPv3 * the local routers do not support IGMPv3, or even multicast, and/or * some routers along the path to the root do not support multicast. This is achieved by defining a new user level process that runs MSCP. All that is really required to join an SSM-style group with this mechanism is for the joining host and the root (the "Source") to support this. As more routers are upgraded to supporting this, bandwidth use is minimized by utilizing multicast rather than tunnels. Although in theory this style of host join could be used instead of IGMP to join a non-SSM group, for non-SSM groups this design offers no advantage over IGMP, since only IGMPv2, which is already widely deployed, is required for joining non-SSM groups. However, if an endnode does reside in a portion of the Internet without any support for multicast, this mechanism could be used for non-SSM groups by using an anycast address in place of an explicit root address. A router that does not support the messages in this draft will simply forward such messages towards the destination specified in the messages. The first multicast capable router that supports MSCP will notice these messages and will form a tunnel with the end node that generated the message. Patel, Perlman, Farinacci, Shepherd [Page 2] Internet Draft draft-keyur-mscp-00.txt December 2003 4 Multicast Signaling Conduit Protocol We propose a new IP multicast signaling protocol known as Multicast Signaling Conduit protocol (MSCP). This protocol has an ability to form multicast tunnels with specified destination address in the IP header. It runs directly over IP protocol. We also propose new MSCP messages with destination address in the IP header as either "Source" (root of the tree) address or anycast address to direct all the MSCP packets to a specific place within an AS. A wellknown anycast address defined by IANA will be used to transmit MSCP packets to a specified destination within an AS. Multicast routers implementing MSCP should treat the receipt of MSCP messages as intended for them, even though the destination address in the IP header is a unicast of the tree root. To allow a router to recognize a MSCP messages addressed to the unicast root address, and place it on the slow path, rather than simply forwarding it towards the specified destination, the packet will have the router alert option, and the IP protocol type="MSCP" with version 1. Usually a multicast router implementing MSCP that notices an MSCP message would trap the message and create a tunnel to the node that sent the MSCP Host-Join. However, in the case where the IP destination address is "MSCP Anycast", the router should forward the packet towards a router that advertises reachability to that address. Multicast routers with MSCP support receiving MSCP Join/Prune [5] messages will process them in similar way as PIM Join/Prune messages. However, MSCP routers receiving MSCP Join/Prune will send MSCP (Join/Prune)-Ack message back to the sender of MSCP Join/Prune messages with a 4 byte cookie value. Receivers upon receipt of MSCP (Join/Prune)-Ack message will respond back with MSCP Auth-Ack message in which it will re-send the cookie value sent by the router. MSCP routers receiving Auth-Ack for Join/Prune will then create/delete interface state accordingly. MSCP routers will create tunnel interfaces (refer section 6) in their (S, G) oif lists when receiving MSCP Join [5] messages from receivers that are not directly connected. For all the directly connected receivers, MSCP routers will create interfaces in their (S, G) oif lists in the same way as if an IGMP (S,G) join or a PIM Join/Prune message were received. An implementation must have a configured upper bound on number of tunnel interfaces that it can put in oif lists of any multicast route. Multicast routers receiving such MSCP Host-Join/Prune messages will process them and create state in similar way as if a PIM Join/Prune (S, G) message was received. All the non-multicast capable routers will simply forward such packets towards the unicast source address/anycast address. Current routers which receive an IP unicast packet with IP options process these packets and forward them towards the unicast destination address specified in the ip packet if the destination is not one of the ip addresses of the routers. Otherwise, these routers forward these packets up the local stack for local delivery. Therefore, current routers will forward the packets destined for the unicast address of the root, to the root, which is the desired behavior. MSCP Routers maintaining tunnel state for (S, G) will periodically query all its interested receivers by sending MSCP Query [5] messages. All end-hosts willing to subscribe to a particular (S, G) group will be periodically sending MSCP Host-Join [5] messages. All the MSCP Host-Join/Prune [5] messages will be sent with unicast source address as the destination address. All the MSCP Host-Join/Prune messages will be sent with IP Router Alert option. Patel, Perlman, Farinacci, Shepherd [Page 3] Internet Draft draft-keyur-mscp-00.txt December 2003 5 MSCP Messages This section defines different message formats for MSCP. MSCP messages are sent either unicast to a particular source or towards anycast address. Each MSCP 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 | Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MSCP Ver MSCP Version number is 1. Type Types for specific MSCP messages. MSCP Types are: Message Type Destination ------------------------------------------------------------------------- 0 = Query Message Unicast to Source/Anycast 1 = Join Message Unicast to Source/Anycast 2 = Join-Ack Message Unicast to Source/Anycast 3 = Auth Ack Unicast to Source/Anycast 4 = Prune Message Unicast to Source/Anycast 5 = Prune-Ack Message Unicast to Source/Anycast 6 = Data Message Unicast to Source/Anycast Reserved Set to zero on transmission. Ignored upon receipt. 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 MSCP 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 MSCP header for the purposes of calculating the checksum. The "Upper-Layer Packet Length" in the pseudo-header is set to the length of the MSCP 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: 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 MSCP 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. Patel, Perlman, Farinacci, Shepherd [Page 4] Internet Draft draft-keyur-mscp-00.txt December 2003 Unicast Address The unicast address as represented by the given Address Family and Encoding Type. 5.1 MSCP Host Query message format MSCP Prune-Ack messages are sent in reply to Prune message by routers forming tunnels. 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 For format description refer to Encoded-Unicast address. 5.2 MSCP Host-Join message format MSCP Host-Joins are sent to assist building source/core trees (SPT/CBT). 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Transmitted as zero, ignored on 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 Join state alive, in seconds. If the Holdtime is set to `0xffff', the receiver of this message should hold the state until canceled by the appropriate canceling Join message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with periodic Join/Prune messages. Note that the Holdtime must be larger than the J/P_Override_Interval(I) (refer to [PIM-SM]). Tunnel Type Specific type of Tunnel that receiver wants Router to create 0 (IP-in-IP), 1 (GRE). Multicast Source address For format description refer to Encoded-Unicast address. Join Group Address 1 .. n This list contains the Groups that the sending router will forward multicast datagrams for if received on the interface this message is sent on. See Encoded-Source-Address format. Patel, Perlman, Farinacci, Shepherd [Page 5] Internet Draft draft-keyur-mscp-00.txt December 2003 5.3 MSCP Host Join-Ack message format MSCP Join-Ack messages are sent in reply to Join message by routers forming tunnels. 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 Pr 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Transmitted as zero, ignored on receipt. Number of Prune Groups The number of multicast group sets contained in the message. Holdtime The amount of time a receiver must keep the Join state alive, in seconds. If the Holdtime is set to `0xffff', the receiver of this message should hold the state until canceled by the appropriate canceling Join message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with periodic Join/Prune messages. Note that the Holdtime must be larger than the J/P_Override_Interval(I) (refer to [PIM-SM]). Tunnel Type Specific type of Tunnel that receiver wants Router to create 0 (IP-in-IP), 1 (GRE). Multicast Source address For format description refer to Encoded-Unicast address. Join Group Address 1 .. n This list contains the Groups that the sending router will forward multicast datagrams for if received on the interface this message is sent on. See Encoded-Source-Address format. Fixed four byte Key Cookie value that is reflected back in Auth-Ack message. 5.4 MSCP Host-Prune message format MSCP Host-Prunes are sent to prune source trees when members leave groups. 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 Pr groups | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tn Format | Multicast Source Address (Encoded format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Group Address n (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Patel, Perlman, Farinacci, Shepherd [Page 6] Internet Draft draft-keyur-mscp-00.txt December 2003 Reserved Transmitted as zero, ignored on receipt. Number of Prune Groups The number of multicast group sets contained in the message. Holdtime The amount of time a receiver must keep the Join state alive, in seconds. If the Holdtime is set to `0xffff', the receiver of this message should hold the state until canceled by the appropriate canceling Join message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with periodic Join/Prune messages. Note that the Holdtime must be larger than the J/P_Override_Interval(I) (refer to [PIM-SM]). Tunnel Type Specific type of Tunnel that receiver is using with the Router 0 (IP-in-IP), 1 (GRE). Multicast Source address For format description refer to Encoded-Unicast address. Join Group Address 1 .. n This list contains the Groups that the sending router will forward multicast datagrams for if received on the interface this message is sent on. See Encoded-Source-Address format. 5.5 MSCP Host Prune-Ack message format MSCP Host-Prunes are sent to prune source trees when members leave groups. 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 Pr 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Transmitted as zero, ignored on receipt. Number of Prune Groups The number of multicast group sets contained in the message. Holdtime The amount of time a receiver must keep the Join state alive, in seconds. If the Holdtime is set to `0xffff', the receiver of this message should hold the state until canceled by the appropriate canceling Join message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with periodic Join/Prune messages. Note that the Holdtime must be larger than the J/P_Override_Interval(I) (refer to [PIM-SM]). Tunnel Type Specific type of Tunnel that receiver is using with the Router 0 (IP-in-IP), 1 (GRE). Multicast Source address For format description refer to Encoded-Unicast address. Join Group Address 1 .. n This list contains the Groups that the sending router will forward multicast datagrams for if received on the interface this message is sent on. See Encoded-Source-Address format. Fixed four byte Key Cookie value that is reflected back in Auth-Ack message. 5.6 MSCP Host Auth-Ack message format MSCP Prune-Ack messages are sent in reply to Prune message by routers forming tunnels. 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/Joine | Cookie Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Transmitted as zero, ignored on receipt. Prune/Join Auth message sent in respone to 0 (Join-Ack) 1 (Prune-Ack). Fixed four byte Key Cookie value that is reflected back in Auth-Ack message. Patel, Perlman, Farinacci, Shepherd [Page 7] Internet Draft draft-keyur-mscp-00.txt December 2003 6. Tunnel Interfaces Because not all intermediate routers support native ip multicast, MSCP requires all the oifs on which it receives MSCP Host-Join/Prunes 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. 7. Security Considerations MSCP 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 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 joins, only nodes on the LAN can initiate a join, 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 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 many tunnels are being created from that customer network, the router can start discriminating against joins 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. 8. Acknowledgements We express our thanks to Alex Zinin, Dino Farinacci, Lorenzo Vicisano, liming Wei, Tom Pusateri, and Nidhi Bhaskar for their review and comments. 9. 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. 10. Author Information Keyur Patel Cisco Systems. Inc. email: keyur@ayrnetworks.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