Network Working Group Keyur Patel Internet Draft AYR Networks Expiration Date: January 2003 Radia Perlman Sun Microsystems Host Extensions to Protocol Independent Multicast draft-keyur-pim-host-extensions-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 defines host extensions to Protocol Independent Multicast - PIM protocol. These host extensions allows endnodes to join/leave any multicast (S/*,G) groups. This helps in easing SSM-style multicast deployment that does not have to depend on IGMP (v1/v2/v3), in either endnodes or the routers. Patel, Perlman [Page 1] Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002 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 host extensions to PIM protocol which eliminate 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 host extensions for PIM. 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. 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 these PIM host extensions will notice these messages and will form a tunnel with the end node that generated the message. Patel, Perlman [Page 2] Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002 4 Host extensions for PIM We propose a new PIM Host-Join/Prune message that is similar to the PIM Join/Prune message, except that the destination address in the IP header is the "Source" (root of the tree) address. PIM routers with host extension support will process these messages without requiring an exchange of the PIM hello messages or establishing the PIM neighbor adjacencies. PIM routers should treat the receipt of Host-Join/Prunes messages as intended for them, even though the destination address in the IP header is the unicast address of the tree root. To allow a router to recognize a PIM Host-Joins 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="PIM" with version 2. PIM routers with host extension support receiving such PIM Host-Join/Prune messages will process them in similar way as PIM Join/Prune messages. PIM routers however will create tunnel interfaces (refer section 6) in their (S, G) oif lists when receiving Host-Join/Prune messages from receivers that are not directly connected. For all the directly connected receivers, PIM 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. PIM routers receiving such PIM Host-Join/Prune messages will process them exactly as PIM Join/Prune messages and will have similar state-machine generated by these messages (as described in [PIM-SM]). It is suggested that an implementation must have a seperate mechanism for processing all the PIM Host-Join/Prune messages within a PIM process in order to prevent any kind of interference with PIM router messages. All the non-multicast PIM capable routers will simply forward such packets towards the unicast source 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. All end-hosts willing to subscribe to a particular (S/*, G) group will be periodically sending PIM Host-Join messages. All the PIM Host-Join/Prune messages will be sent with unicast source address as the destination address. All the PIM Host-Join/Prune messages will be sent with IP Router Alert option. Patel, Perlman [Page 3] Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002 5 PIM Host-Join/Prune message format PIM Host-Joins are sent to assist building source trees (SPT). PIM Host-Prunes are sent to prune source trees when members leave groups. Encoded-Unicast address An Encoded-Unicast address takes the following format: 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 PIM 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. Patel, Perlman [Page 4] Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num groups | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address m (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver PIM Version number is 2. Type Types for specific PIM messages. PIM Types are: Message Type Destination ------------------------------------------------------------------------- 0 = Hello Multicast to ALL-PIM-ROUTERS 1 = Register Unicast to RP 2 = RegisterStop Unicast to source of Register packet 3 = Join/Prune Multicast to ALL-PIM-ROUTERS 4 = Bootstrap Multicast to ALL-PIM-ROUTERS 5 = Assert Multicast to ALL-PIM-ROUTERS 6 = Graft (used in PIM-DM only) Multicast to ALL-PIM-ROUTERS 7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft packet 8 = Candidate-RP-Advertisement Unicast to Domain's BSR 9 = Host-Join/Prune Unicast to Source 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 PIM 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 PIM header for the purposes of calculating the checksum. The "Upper-Layer Packet Length" in the pseudo-header is set to the length of the PIM 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. Reserved Transmitted as zero, ignored on receipt. Patel, Perlman [Page 5] Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002 Holdtime The amount of time a receiver must keep the Join/Prune 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/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 periodic Join/Prune messages. Note that the Holdtime must be larger than the J/P_Override_Interval(I) (refer to [PIM-SM]). Number of Groups The number of multicast group sets contained in the message. Multicast group address For format description refer to Encoded-Unicast address. Number of Joined Sources Number of join source addresses listed for a given group. Join Source Address 1 .. n This list contains the sources that the sending router will forward multicast datagrams for if received on the interface this message is sent on. See Encoded-Source-Address format. Number of Pruned Sources Number of prune source addresses listed for a group. Prune Source Address 1 .. n This list contains the sources that the sending router does not want to forward multicast datagrams for when received on the interface this message is sent on. Within one PIM local-Join/Prune message, all the Multicast Group Addresses, Joined Source addresses and Pruned Source addresses MUST be of the same address family. It is NOT PERMITTED to mix IPv4 and IPv6 addresses within the same message. In addition, the address family of the fields in the message SHOULD be the same as the IP source and destination addresses of the packet. This permits maximum implementation flexibility for dual-stack IPv4/IPv6 routers. Patel, Perlman [Page 6] Internet Draft draft-keyur-pim-host-extensions-00.txt December 2002 6. Tunnel Interfaces Because not all intermediate routers support native ip multicast, PIM host extensions requires all the oifs on which it receives 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 This extension to PIM does not change the underlying security issues. 8. Acknowledgements We express our thanks to Alex Zinin, Dino Farinacci, 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 AYR Networks. Inc. 3977 East Bayshore Road, suite 200 Palo Alto, CA 94303 email: keyur@ayrnetworks.com Radia Perlman Sun Microsystems. Inc. 2 Elizabeth Drive Chelmsford, MA 01824 email: Radia.Perlman@sun.com