INTERNET-DRAFT Supratik Bhattacharyya Expires 13 January 2001 Christophe Diot Sprint ATL Leonard Giuliano Rob Rockell SprintLink John Meylor Dave Meyer Greg Shepherd Cisco Systems 13 July 2000 A Framework for Source-Specific IP Multicast Deployment 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. The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. Bhattacharyya et. al. FORMFEED[Page 1] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 Abstract This document provides an overview of the Source-Specific Multicast (SSM) service model which supports source-based multicast trees across multiple domains in the Internet. SSM realizes components of the EXPRESS [HOLB99] multicast service model in which there is a single source for every multicast channel, and channel membership is based on the unique combination of multicast group address (G) as well as the source's unicast address (S). End-hosts use version 3 of the IGMP protocol (IGMPv3) to register their interest in a particular source-group (S,G) pair. The PIM-SM protocol is then used to construct the multicast forwarding tree rooted at the source S. This document is intended as a starting point for implementing and deploying SSM services. It provides a brief architectural overview of SSM described in more detail in [HOLBOO] and describes associated deployment challenges. It summarizes changes to protocols and applications both at end-hosts and routers, with pointers to more detailed documents, wherever appropriate. Issues of interoperability with the current multicast architecture are also discussed. 1. Classic Multicast Service Model using IGMPv2/PIM-SM The current IP multicast service model is an open model where a set of hosts can be aggregated into a group with a single class-D IP address in the range of 224.0.0.0 to 239.255.255.255. Any end-host can send data to a multicast group (even without joining the group), and any end-host can receive data sent to a group by becoming a member of it. To become a member of a particular group, an end-host registers multicast group membership with a querier routers that handles the multicast group membership function using the IGMP [FENN97,CAIN99] protocol. Initial IGMPv1 or IGMPv2 protocols only provide for the ability to specify the group to which a host will join, there is no mechanism available to allow hosts to describe their desire to include (or exclude) particular sources sending to a given group. Multicast-capable routers then exchange messages with each other according to some routing protocol to construct a distribution tree connecting all the end-hosts. A number of different protocols exist for multicast routing. They differ mainly in the type of delivery tree constructed [DEER90,DEER96,PIMSM,PIMDM]. Of these, the Protocol Independent Multicast Sparse-Mode (PIM-SM) protocol is the most widely deployed in today's public networks. PIM-SM constructs a single spanning multicast tree rooted at a core rendezvous point or RP for all group members within a domain. Bhattacharyya et. al. FORMFEED[Page 2] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 In the following paragraph, the term 'local' when applied to a source and relative to some router, refers to a source that is in the same PIM-SM domain. Local sources then send their data to this RP which forwards the data down the shared tree to interested local receivers. Again, a receiver joining via IGMPv1 or IGMPv2 can only specify interest in the entire group and therefore will receive data sent by any source to this group forwarded via the shared tree. Distribution via a shared tree can be effective for certain types of traffic, e.g., where the number of sources is large since forwarding on the shared tree is performed via a single multicast forwarding entry. However, there are many cases (eg, Internet broadcast type streams) where forwarding from a source to a receiver is most efficient via the shortest path. PIM-SM also allows a designated router serving a particular subnet to switch to a source-based shortest path tree for a given source once the source's address is learned from data arriving on the shared tree. This behavior provides for distribution of data from local sources to local receivers both sharing a common RP inside a given PIM domain. Interdomain PIM-SM Multicast Using MSDP It is also possible for RP's to learn about sources in other PIM domains by using the Multicast Source Discovery Protocol (MSDP). Once an active remote source is identified, an RP can join the shortest path tree to that source and obtain data to forward down the local shared tree on behalf of interested local receivers. Designated routers for particular subnets can again switch to a source-based shortest path tree for a given remote source once the source's address is learned from data arriving on the shared tree. Current implementations of the classic IP multicast service that use IGMPv2 and PIM-SM, and MSDP for interdomain multicast are widely deployed and can be particularly effective for groups where sources are not known in advance by hosts joining a group, or when sources come and go dynamically, or when forwarding on a common shared tree is found operationally beneficial. 2. Limitations of IGMPv2/PIM-SM Service Model There exist several service model limitations associated with use of IGMPv2, PIM-SM, and MSDP: A) Handling Well Known Sources via Shortest Path Forwarding In cases where the address of the source is well known before the receiver joining the group, and when the shortest forwarding path is the preferred forwarding mode, then PIM-SM's shared tree mechanisms and MSDP only represent unnecessary interim mechanisms, contributing to join latency and operational overhead until the Bhattacharyya et. al. FORMFEED[Page 3] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 final shortest path tree is constructed. B) Access Control In the Classic IP Multicast service model, a receiver can not specify which specific sources it would like to receive when it joins a given group. A receiver will be forwarded all sources to that group. C) Address Allocation : This is one of the biggest challenges in deploying inter-domain multicast. Currently there is nothing to prevent an application from sending data to any multicast address. More importantly, there is a serious risk of address collisions among multiple applications. A static address allocation scheme, GLOP [GLOP00] has been proposed as an interim solution, however, GLOP addresses are allocated per registered AS, which is inadequate in cases where the number of sources exceeds the AS numbers available for mapping. Proposed longer-term solutions such as the Multicast Address Allocation Architecture (MAAA) provide for additional address allocation but do not guarantee address availability of any particular address range. The previously proposed Explicitly-Requested Single-Source(EXPRESS) Multicast service model decribed, among other things, methods for addressing the above limitations [HOLB99]. In the EXPRESS model, a multicast "channel" is determined by specifying a source address S as well a group address G. Data distribution from source to receiver is restricted to this shortest path forwarding tree, data is precluded from being forwared on shared trees. Therefore two channels (S1,G) and (S2,G) are routed independently, even though they have the same multicast group address. The IGMPv3 protocol allows a host to specify a list of sources (S) which it would like to include (or exclude) if the host can identify these sources in advance of joining a group. A designated router serving such hosts is no longer dependent on data coming down the shared tree to identify local sources nor is it dependent on MSDP for remote sources, it can initiate a PIM join to specific source directly and immediately. However, at the same time, IGMPv3 alone does not preclude the DR from joining the shared tree for a given group. Thus, while immediate PIM (S,G) joins made possible by IGMPv3 source specific host reports do reduce the amount of mechanism invoked when sources are well-known in advance, IGMPv3 alone does not address the issues of access control or address allocation. To resolve these issues, there must also be an agreed upon range of globally routable class D address over which PIM (S,G) joins MUST be used, and over which (*,G) joins MUST NOT be used. For this purpose IANA has allocated 232/8. Bhattacharyya et. al. FORMFEED[Page 4] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 3. Source Specific Multicast (SSM) Source Specific Multicast defines a method of multicast forwarding restricted to shortest path trees to specific sources described by hosts using IGMPv3. The allocation of 232/8 for SSM ensures a range in which SSM is the sole forwarding model. Source-Specific Multicast, as implemented by PIM-SM and IGMPv3requires the following: A) source specific host membership reports. As previously described, IGMPv3 allows a host to describe specific sources from which it would like to receive data. B) PIM shortest path forwarding. DR's must be capable of recognizing receiver-initiated, source specific host reports and initiating PIM (S,G) joins directly and immediately as result. C) elimination of shared tree forwarding. In order to achieve global effectiveness of SSM, all networks must agree to restrict data forwarding to source trees (ie prevent shared tree forwarding) for some recognized group range. The address range 232/8 has been allocated by IANA for use by source-specific multicast (SSM) services. Henceforth, we refer to 232/8 as the SSM address range. 4. Benefits of using SSM 4.1 SSM provides a basis for access control mechanisms. Only a single source S can transmit to a channel (S,G) where G is an SSM address. Each receiver is capable of specifying the specific sources from which it would like to receive content. In addition, the elimination of shared tree forwarding prevents unrequested sources from consuming network resources based on (*,G) forwarding. 4.2 SSM defines multicast channels on a per-source basis such that SSM addresses are "local" to each source. This averts the problem of global allocation of SSM addresses for multicast groups. Each source is now responsible for resolving address collisions for the various channels that it creates. 4.3 The distribution tree for an SSM channel (S, G) is always rooted at the source S. Thus there is no need for an RP-based shared tree infrastructure or for MSDP for source discovery. Thus the complexity of the multicast routing infrastructure for SSM is low, making it viable for immediate deployment and more efficient for well-known sources. 4.4 It is widely held that point-to-multipoint applications such as Internet TV comprise a large portion of the Internet multicast application space. The SSM model is designed to efficiently handle such cases where sources are known in well known. Bhattacharyya et. al. FORMFEED[Page 5] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 5. SSM Framework This section describes changes to hosts, applications, and routers that must be realized in order to deploy and use the SSM service model. These changes assume that IGMPv3 will be used to provide application- level interfaces to the SSM service model and that a slightly modified version of PIM-SM (which we call PIM-SSM) can be deployed on routers 5.1 Address Allocation SSM addresses should be selected from IANA assigned block 232/8 in order to ensure source specific functionality. 5.2 Source Discovery Applications must learn about SSM sources directly before they attempt to join to the sources content, since they must pass the source address and group address to the IGMPv3 stack. 5.3 Source-aware Applications Applications must be capable of parsing source specific information from sessions descriptions or announcements and be capable of providing this information to the IGMPv3 stack. 5.4 IGMPv3 Host Stack Hosts must run IGMPv3 stacks which can receive source specific join information from applications and convert this into IGMPv3 include mode source_list information sent to the querier router. 5.5 IGMPv3 Querier Querier routers must run IGMPv3 and be capable of receiving IGMPv3 host reports from hosts. 5.6 PIM-SSM Designated Router The Designated Router must be capable of recognizing source specific join requests as provided by the IGMPv3 host reports. The DR must be capable of initiating a direct and immediate PIM (S,G) Join toward the source. In addition, in the SSM range specified which must include 232/8, the DR must not send an (*,G) join toward the RP in order to create a shared tree. 5.7 PIM-SSM Core Router Core routers for purposes of this document can be described as routers which do not have directly connected IGMPv3 speaking hosts. Core routers must be capable of receiving and propogating PIM (S,G) joins based on correct RPF information. In addition, they must not propogate joins for addresses in the SSM range. Bhattacharyya et. al. FORMFEED[Page 6] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 Figure 1 describes the SSM Framework. -------------------------------------------------------------- IANA assigned 232/8 ADDRESS ALLOCATION -------------------------------------------------------------- | v +--------------+ session directory/web page | source,group | SESSION DISCRIPTION -------------------------------------------------------------- ^ | Query | | s,g | v +-----------+ host | IGMPv3 app| SOURCE DISCOVERY -------------------------------------------------------------- | IGMPv3 app| IGMPv3 APPLICATION -------------------------------------------------------------- | IGMPv3 | IGMPv3 HOST REPORTING +-----------+ |(source specific host report) | -------------------------------------------------------------- v +-----------+ Querier Router | IGMPv3 | IGMPv3 QUERIER -------------------------------------------------------------- | PIM-SSM | PIM-SSM ROUTING +-----------+ Designated Router | | (PIM S,G Join only) v +-----------+ Core Router | PIM-SSM | +-----------+ | | (PIM S,G Join only) V Figure 1 : SSM Framework: elements in end-to-end model Bhattacharyya et. al. FORMFEED[Page 7] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 6. Framework Elements In the following sections, we provide a more detailed description of the SSM framework elements, outline changes to existing protocols, discuss interoperability issues and tradeoffs of having a SSM based single source multicast service. 6.1 Address Allocation The address range of 232/8 has been assigned by IANA for explicit source join multicast applications. Sessions expecting SSM functionality must allocate addresses from the 232/8 range. To ensure global SSM functionality in 232/8, including in networks where routers run traditional IGMPv2/PIM-SM/MSDP protocols, operational policies [SHEP] should prevent data sent to 232/8 from being delivered via shared trees. NOTE: IGMPv3 and PIM-SM allow for direct creation of the shortest- path tree for multicast addresses not in the SSM address range, however, non-232/8 ranges allow for concurrent use of traditional PIM-SM and shared trees for forwarding data. Therefore, while you can achieve the PIM join efficiency in non-232/8 with IGMPv3, you can't prevent creation of shared trees or shared tree data delivery, and thus cannot provide for certain types of access control or assume per-source unrestricted address use as with 232/8. 6.2 Source Discovery With SSM the application must know the the source address before it can join to an (S,G) pair, so the function of source discovery becomes the responsibility of the application. Source information can be provided in a number of ways, including via a web page, a session announcement application. The exact mechanisms for doing this is outside the scope of this framework document, but we provide two examples of how this might be done. An advertising tool such as SDR or a content provider URL can be used to announce multicast services using an abstract naming scheme (a discussion of an appropriate naming scheme is beyond the scope of this document). Then it uses the (S,G) address to join the source- based multicast tree for that service. A session advertisement tool like SDR can also be used to advertise the source and destination address of an SSM session. Bhattacharyya et. al. FORMFEED[Page 8] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 6.3. Requirements for Multicast SSM Applications -- For applications sourcing content on an SSM address the session must be advertised including a source address as well as a group address. -- An application expecting to join an SSM channel, must be capable of specifing a source address in addition to a group address. In other words, the application must be "IGMPv3-aware". Specific API requirements are identified in [THAL00]. More detailed discussion of application requirements for SSM are in [QUINN]. 6.4. IGMPv3 IGMPv2 allows end-hosts to register their interest in a multicast group by specifying a class-D IP address. However in order to implement the single-source multicast model, an end-host must specify a source's unicast address as well as a group address. This capability is provided by the recently proposed IGMP version 3 (IGMPv3). IGMPv3 supports "source filtering", i.e., the ability of an end-system to express interest in receiving data packets sent only by SPECIFIC sources, or from ALL BUT some specific sources. Thus, IGMPv3 provides a superset of the capabilities required to realize the SSM model. Hence an upgrade from IGMPv2 to IGMPv3 is an essential change for implementing single-source multicast. We believe that this is the MOST EXTENSIVE CHANGE FOR SSM DEPLOYMENT as it involves changes to the Application Programming Interface (API) on ALL END-HOSTS that want to participate in SSM sessions. IGMPv3 requires the API to provide the following operation (or its logical equivalent) [CAIN99]: IPMulticastListen (Socket, IF, G, filter-mode, source-list) "Socket" is an implementation-specific parameter used to distinguish among different requesting entities. IF is a local identifier of the network interface on which the specified multicast address is to be enabled or disabled and G is the multicast group address to which the request pertains. filter-mode may be INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to the specified multicast address is requested only from the IP addresses listed in the source-list parameter. Bhattacharyya et. al. FORMFEED[Page 9] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 As explained in the IGMPv3 specifications [CAIN99], the above IPMulticastListen() operation subsumes the group-specific join and leave operations of IGMPv2. Performing (S,G)-specific joins and leaves is also trivial. A join operation is equivalent to : IPMulticastListen (Socket,IF,G,INCLUDE,{S}) and a leave operation is equivalent to IPMulticastListen (Socket,IF,G,EXCLUDE,{S}) If a system (end-host or edge-router) supports both IGMPv2 and IGMPv3, it must ignore any IGMPv2 message for a SSM address. A more detailed review of changes to the Internet Group Management Protocol Version 3 (IGMPv3) [IGMPv3] to support source-specific multicast detailed can be found in [HOLB00-1]. 6.5. PIM-SM Modifications PIM-SM itself supports two types of trees, a shared tree rooted at a core (RP), and a source-based shortest path tree. THUS PIM-SM ALREADY SUPPORTS SOURCE-BASED TREES; however, PIM-SM is not designed to allow a router to immediately select a source-based tree. In fact, with PIM-SM a DR will always joins a PIM shared tree to start with, and then may later be switched to a per-source tree. A key to implementing SSM is eliminate the need for starting with a shared tree and then switching to a source-specific tree. This involves several changes to PIM-SM as described in [BHAS00]. The resulting PIM functionality is described as PIM-SSM. The most fundemental functional change wrt SSM is as follows: -- When a DR identifies request to join a specific source in a group with a SSM group address (232/8), it ALWAYS initiate a (S,G) join and NEVER a (*,G) join. Moreover, unlike PIM-SM, it need not send a (S,G) prune towards the RP. The specific architectural issues associated with PIM-SSM and IGMPv3 are detailed in [HOLB00]. Bhattacharyya et. al. FORMFEED[Page 10] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 7. Interoperability with Existing Multicast Service Models Moving to SSM will create several deployment issues: 7.1 Addressing: There are two kinds of problems in term of addressing. PIM-SSM and PIM-SM need to co-exist. There will consequently be two types of multicast applications on the Internet: shared groups applications and SSM applications. From an addressing standpoint, it is important that SSM applications use the 232/8 address range and that PIM-SM groups DO NOT use 232/8 addresses. Depending on whether a host is PIM-SSM and/or PIM-SM enabled, it will need to have the following capabilities: - a PIM-SM sender must use a class D address outside the 232/8 range. - a PIM-SM receiver can issue a (*, G) join to PIM-SM group. - a PIM-SSM sender must use a class D address within the 232/8 range. - a PIM-SSM receiver can issue a (S, G) join to any multicast group, irrespective of whether it is a PIM-SSM address or not. These requirements are very important for addressing backward compatibility issues between PIM-SSM and PIM-SM/MSDP. 7. Acknowledments We would like to thank a number of people at Sprint Labs -- Gene Bowen, Ed Kress, Bryan Lyles, Sue Moon, Timothy Roscoe and JayCee Straley -- and Hugh Holbrook, Isidor Kouvelas, Tony Speakman, Nidhi Bhaskar at Cisco Systems -- for participating in lengthy discussions and design work on SSM, and providing feedback on this document. Thanks are also due to Mujahid Khan and Ted Seely at SprintLink, Tom Pusateri at Juniper Networks, Bill Fenner at AT&T Research, Kevin Almeroth at the University of California Santa Barbara, Brian Levine at the University of Massachusetts Amherst, Brad Cain at Nortel Networks and Hugh LaMaster at NASA for their valuable insight and continuing support. 11. References: [HOLB99] H. Holbrook and D.R. Cheriton. IP Multicast Channels : EXPRESS Support for Large-scale Single-Source Applications. In Proceedings of SIGCOMM 1999. Bhattacharyya et. al. FORMFEED[Page 11] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 [FENN97] W. Fenner. 2236, November 1997. [CAIN99] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan. Internet Group Management Protocol, Version 3. Internet Draft draft-ietf-idmr-igmp-v3-03.txt, March 2000. [HOLB00] H. Holbrook and B. Cain. Source-Specific Multicast for IP. Internet Draft draft- holbrook-ssm-arch-00.txt. [HOLB00-1] H. Holbrook and B. Cain. Using IGMPv3 For Source-Specific Multicast. Internet Draft draft-holbrook-idmr-ssmigmpv3-00.txt [DEER90] S. Deering and D. Cheriton. Multicast Routing in Datagram Networks and Extended LANs. ACM Transactions on Computer Systems, 8(2):85-110, May 1990. [DEER96] S. Deering et al. PIM Architecture for Wide-Area Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162, April 1996. [ESTR98] D. Estrin et al. Protocol Independent Multicast - Sparse Mode (PIM-SM) : Protocol Specification. Request for Comments, 2362, 1998. [DEER99] S. Deering et al. Protocol Independent Multicast Version 2 Dense Mode Specification. Internet Draft draft-ietf-pim-v2-dm-03.txt, June 1999. [FARI00] Farinacci et al. Multicast Source Discovery Protocol. Internet Draft draft- ietf-msdp-spec-02.txt, January 2000. [DIOT00] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen. Deployment Issues for the IP Multicast Service and Architecture. In IEEE Networks Magazine's Special Issue on Multicast, January, 2000. [SAND00] Hal Sandick and Brad Cain. PIM-SM Rules for Support of Single-Source Multicast. Internet Draft draft-sandick-pimsm-ssmrules-00.txt. [THAL00] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface Extensions for Multicast Source Filters. Internet Draft draft-ietf-idmr-msf-api-00.txt Bhattacharyya et. al. FORMFEED[Page 12] INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000 [BHAS00] N. Bhaskar and I. Kouvelas. Source-Specific Protocol Independent Multicast. Internet Draft draft-bhaskar-pim-ss-00.txt [GLOP97] GLOP Addressing in 233/8. Request For Comments 2770, 1997. [SDR] Session directory (sdr). http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr. [LEVI00] B. Levine et al. Consideration of Receiver Interest for IP Multicast Delivery. In Proceedings of IEEE Infocom, March 2000. [SHEP] G. Shepherd et al. Source-Specific Protocol Independent Multicast in 232/8. Internet Draft draft-shepherd-ssm232/8-00.txt [QUINN] IP Multicast Applications: Challenges and Solutions. Internet Draft draft-ietf-mboned-mcast-apps-02.txt 12. Authors' Address: Supratik Bhattacharyya Christophe Diot Sprint Advanced Technology Labs One Adrian Court Burlingame CA 94010 {supratik,cdiot}@sprintlabs.com http://www.sprintlabs.com Leonard Giuliano Robert Rockell Sprint Internet Service Center Reston, Virginia {giuliano,rrockell}@sprintlink.net John Meylor Dave Meyer Greg Shepherd Cisco Systems {jmeylor,dmm,shep@cisco.com} Bhattacharyya et. al. FORMFEED[Page 13]