INTERNET-DRAFT Supratik Bhattacharyya Expires 18 November 2001 Christophe Diot Sprint ATL Leonard Giuliano Juniper Networks Rob Rockell Sprint E|Solutions John Meylor Dave Meyer Cisco Systems Greg Shepherd Juniper Networks Brian Haberman Nortel Networks 18 May 2001 An Overview of Source-Specific Multicast(SSM) 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. [Page 1] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 Abstract This document provides an overview of the Source-Specific Multicast (SSM) service and its deployment using the PIM-SM and IGMP/MLD protocols. The network layer service provided by SSM is a "channel", identified by an SSM destination IP address (G) and a source IP address S. The IP address range 232/8 has been designated as SSM addresses by IANA for IPv4. An SSM address range already exists for IPv6. A source S transmits IP datagrams to an SSM address G. A receiver can receive these datagrams by subscribing to the channel (S,G). Channel subscription is supported by version 3 of the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6. The interdomain tree for forwarding UDP datagrams is rooted at the source S. Although a number of protocols exists for constructing source- rooted forwarding trees, this document discusses the most widely implemented one - PIM Sparse Mode [PIM-SM-NEW]. This document is intended as a starting point for deploying SSM services. It provides an architectural overview of SSM and describes how it solves a number of problems faced in the deployment of inter- domain multicast. It outlines changes to protocols and applications both at end-hosts and routers for supporting SSM, with pointers to more detailed documents where appropriate. Issues of interoperability with the existing multicast service model (as defined by RFC 1112) are also discussed. 1. Terminology This section defines some terms that are used in the rest of this document : Any-Source Multicast (ASM) : This is the IP multicast service model defined in RFC 1112 [RFC1112]. An IP datagram is transmitted to a "host group", a set of zero or more hosts identified by a single IP destination address (224.0.0.0 through 239.255.255.255 for IPv4). This model supports one-to-many and and many-to-many multicast groups. Hosts may join and leave the group any time. There is no restriction on the location or number of receivers, and a source need not be a member of the host group it transmits to. Source-Specific Multicast (SSM) : This is the multicast service model defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to an SSM address G, and receivers can receive this datagram by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] and supports one-to-many multicast.The address range 232/8 has been assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the Bhattacharyya et. al. [Page 2] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 range FF2::/11 through FF3x::/11 is defined for SSM services [SSM- IPV6]. Source-Filtered Multicast (SFM) : This is a variant of the multicast service model defined in RFC 1112. A source transmits IP datagrams to a host group address in the range of 224.0.0.0 to 239.255.255.255. However, each "upper layer protocol module" can now request data sent to a host group G by only a specific set of sources, or can request data sent to host group G from all BUT a specific set of sources. Such support for source filtering is provided by version 3 of the Internet Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and version 2 of the Multicast Listener Discovery (or MLD) protocol for IPv6 [MLDv2]. We shall henceforth refer to these two protocols as "SFM- capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and MLDv1 - do not provide support for source-filtering, and are referred to as "non-SFM-capable". 2. Current Interdomain Multicast Architecture The current interdomain multicast architecture is based on the ASM service model. To become a member of a particular host group end- hosts register multicast group membership with querier routers handling multicast group membership function using the IGMP version 2 (IGMPv2) protocol [RFC2236] for IPv4 or the MLD version 1 (MLDv1) protocol [RFC2710] for IPv6. These protocols are non-SFM-capable, hence source-filtering capabilities are unavailable to receivers. Multicast-capable routers then exchange messages with each other according to a routing protocol to construct a distribution tree connecting all the end-hosts. A number of different protocols exist for building multicast forwarding trees, which differ mainly in the type of delivery tree constructed [IPMULTICAST,PIM-ARCH, RFC2362, PIM-SM-NEW, PIM-DM]. Of these, the Protocol Independent Multicast Sparse-Mode (PIM-SM) protocol [PIM-SM-NEW] is the most widely deployed in today's public networks. PIM-SM, by default, constructs a single spanning multicast tree rooted at a core rendezvous point or RP for all group members within a domain. Local sources then send their data to this RP which forwards the data down the shared tree to interested local receivers. A receiver joining a host group can only specify interest in the entire group and therefore will receive data for any source to this group forwarded on 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 (e.g., 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 Bhattacharyya et. al. [Page 3] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 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 capability provides for distribution of data from local sources to local receivers both sharing a common RP inside a given PIM domain. It is also possible for RP's to learn about sources in other PIM domains by using the Multicast Source Discovery Protocol (MSDP) [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. The IGMPv2/PIM-SM/MSDP-based interdomain multicast architecture is widely deployed in IPv4 networks 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 to be operationally beneficial. 3. Problems with Current Architecture There are several deployment problems associated with current multicast architecture: A) Inefficient handling of well-known sources : In cases where the address of the source is well known in advance of the receiver joining the group, and when the shortest forwarding path is the preferred forwarding mode, then shared tree mechanisms and MSDP only are not necessary. B) Lack of access control : In the ASM 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 data sent to a host group by any source. C) Address Allocation : Address allocation is one of core deployment challenges posed by the ASM service model. The current multicast architecture does not provide an adequate solution to prevent address collisions among multiple applications. The problem is more serious for IPv4 than IPv6 since the total number of multicast addresses is smaller. A static address allocation scheme, GLOP [GLOP00] has been proposed Bhattacharyya et. al. [Page 4] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 as an interim solution for IPv4; 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) are generally perceived as being too complex (with respect to the dynamic nature of multicast address allocation) for widespread deployment. However, the unicast-prefix-based multicast architecture of IPv6 [HABE1] expands on the GLOP approach, simplifies the multicast address allocation solution and incorporates support for source-specific multicast addresses. 4. Source Specific Multicast (SSM) : Benefits and Requirements As mentioned before, Source Specific Multicast (SSM) defines a service model for a "channel" identified by an (S,G) pair, where S is a source address and G is an SSM address. This model can be realized by a protocol architecture, where packet forwarding is restricted to shortest path trees rooted at specific sources, and channel subscriptions are described using an SFM-capable group management protocol such as IGMPv3 or MLDv2. The SSM service model alleviates all of the deployment problems described earlier : 4.1 SSM lends itself to an elegant solution to the access control problem. Only a single source S can transmit to a channel (S,G) where G is an SSM address. This makes it significantly more difficult to spam an SSM channel than an ASM host group. In addition, data from unrequested sources need not be forwarded by the network, which prevents unnecessary consumption of network resources. 4.2 SSM defines channels on a per-source basis; hence SSM addresses are "local" to each source. This averts the problem of global allocation of SSM addresses, and makes each source independently 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 a shared tree infrastructure. In terms of the IGMPv2/PIM-SM/MSDP architecture, this implies that neither the RP-based shared tree infrastructure of PIM-SM nor the MSDP protocol is required. Thus the complexity of the multicast routing infrastructure for SSM is low, making it viable for immediate deployment and more efficient for well-known Bhattacharyya et. al. [Page 5] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 sources. 4.4 It is widely held that point-to-multipoint applications such as Internet TV will dominate the Internet multicast application space in the near future. The SSM model is ideally suited for such applications. A protocol architecture for SSM requires the following : A) Source specific host membership reports : A SFM-capable protocol is needed to allow a host to describe specific sources from which it would like to receive data. B) Shortest path forwarding. DR's must be capable of recognizing receiver-initiated, source specific host reports and initiating (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 (i.e., prevent shared tree forwarding) for SSM addresses. The address range 232/8 has been allocated by IANA for deploying source-specific IPv4 multicast (SSM) services. In this range, SSM is the sole service model. For IPv6, a source-specific multicast address range has been defined in [HABE1], as a special case of unicast prefix-based multicast addresses. 5. SSM Framework Figure 1 illustrates the elements in an end-to-end SSM framework. -------------------------------------------------------------- IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION SSM range exists for IPv6 -------------------------------------------------------------- | v +--------------+ session directory/web page | source,group | SESSION DESCRIPTION -------------------------------------------------------------- ^ | Query | | s,g | v +-----------------+ host | SSM-aware app | CHANNEL DISCOVERY -------------------------------------------------------------- | SSM-aware app | SSM-AWARE APPLICATION Bhattacharyya et. al. [Page 6] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 -------------------------------------------------------------- | IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING +---------------+ |(source specific host report) | -------------------------------------------------------------- v +-----------------+ Querier Router | IGMPv3/MLDv2 | QUERIER -------------------------------------------------------------- | PIM-SSM | PIM-SSM ROUTING +------------+ Designated Router | | (S,G) Join only v +-----------+ Core Router | PIM-SSM | +-----------+ | | (S,G) Join only V Figure 1 : SSM Framework: elements in end-to-end model We now discuss the framework elements in detail : 5.1 Address Allocation For IPv4, the address range of 232/8 has been assigned by IANA for SSM. 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 non-SFM-capable protocols, operational policies are being proposed [SSM-BCP] which prevent data sent to 232/8 from being delivered via shared trees. Note that it is possible to achieve the benefit of direct and immediate (S,G) joins in response to IGMPv3 reports in other ranges than 232/8.However, non-SSM address ranges allow for concurrent use of both the ASM and SSM service models. Therefore, while we can achieve the PIM join efficiency in the non-SSM address range with IGMPv3, it is not possible to prevent the 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 the SSM address range. In case of IPv6, [HABE1] has defined an extension to the addressing architecture to allow for unicast prefix-based multicast addresses. Bhattacharyya et. al. [Page 7] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 In this case, bytes 0-3 (starting from the least significant byte) of the IP address is used to specify a multicast group id, bytes 4-11 is be used to specify a unicast address prefix (of up to 64 bits) that owns this multicast group id, and byte 12 is used to specify the length of the prefix. A source-specific multicast address can be specified by setting both the prefix length field and the prefix field to zero. Thus IPv6 allows for 2^32 SSM addresses per scope for every source, while IPv4 allows 2^24 addresses per source. 5.2 Channel Discovery In case of ASM, receivers need to know only the group address for a specific session. In the IGMPv2/PIM-SM/MSDP architecture, designated routers discover an active source via PIM-SM and MSDP, and then graft themselves to the multicast forwarding tree rooted at that source. In case of the SSM, an application on an end-host must know both the SSM address G and the source address S before subscribing to a channel. Thus the function of channel discovery becomes the responsibility of applications. This information can be made available in a number of ways, including via web pages, sessions announcement applications, etc. The exact mechanisms for doing this is outside the scope of this framework document. 5.3. SSM-Aware Applications -- For applications sourcing content expected to be available to receivers via SSM channels, the session must be advertised including a source address as well as an SSM address. -- Applications expecting to subscribe to an SSM channel must be capable of specifying a source address in addition to an SSM address. In other words, the application must be "SSM-aware". Specific API requirements are identified in [THAL00]. 5.4. IGMPv3 for SSM The currently deployed version of IGMP (IGMPv2) allows end-hosts to register their interest in a multicast group by specifying a class-D IP address for IPv4. However in order to implement the SSM service model, an end-host must specify a source's unicast address as well as an SSM 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 Bhattacharyya et. al. [Page 8] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 ALL BUT some specific sources. Thus, IGMPv3 provides a superset of the capabilities required to realize the SSM service model. Hence an upgrade from IGMPv2 to IGMPv3 is an essential change for implementing SSM. IGMPv3 requires the API to provide the following operation (or its logical equivalent) [CAIN99]: IPMulticastListen (Socket, IF, G, filter-mode, source-list) 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}) There are a number of backward compatibility issues between IGMP versions 2 and 3 which have to be addressed. There are also some additional requirements for using IGMPv3 for the SSM address range. A detailed discussion of these issues is provided in [SSM- IGMPv3]. 5.5 MLDv2 for SSM The Multicast Listener Discovery (MLD) protocol used by an IPv6 router to discover the presence of multicast listeners on its directly attached links, and to discover the multicast addresses that are of interest to those neighboring nodes. Version 1 of MLD [DEER99] is derived from IGMPv2 and allows a multicast listener to specify the multicast group(s) that it is interested in. Version 2 of MLD [VIDA01] is derived from, and provides the same support for source-filtering as, IGMPv3. 5.6. PIM-SM Modifications for SSM PIM-SM [PIM-SM-NEW] 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 choose between a shared tree and a source-based tree. In fact, a receiver always joins a PIM shared tree Bhattacharyya et. al. [Page 9] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 to start with, and may later be switched to a per-source tree by its adjacent edge router. 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 [PIM-SM-NEW]. The resulting PIM functionality is described as PIM-SSM. The most important changes to PIM-SM with respect to SSM are as follows: -- When a DR receives an (S,G) join request with the address G in the SSM address range, it must initiate a (S,G) join and NEVER a (*,G) join. --Core routers (i.e. routers that do not have directly attached hosts) must not propagate (*,G) joins for group addresses in the SSM address range. --Rendezvous Points (RPs) must not accept PIM Register messages or (*,G) Join messages in the SSM address range. The specific architectural issues associated with PIM-SSM and IGMPv3/MLDv2 are detailed in [SSM-ARCH]. 6. Interoperability with Existing Multicast Service Models Interoperability with ASM is one of the most important issues in moving to SSM deployment. ASM and SSM will always coexist; hence there will be two service models for Internet multicast. SSM is the ONLY service model for the SSM address range (232/8 for IPv4 and FF::/8 for IPv6) - the correct protocol behaviour for this range is specified in [SSM-ARCH]. The ASM service model will be offered for the non-SSM adddress range, where receivers can issue (*,G) join requests to receive multicast data. A receiver is also allowed to issue an (S,G) join request in the non-SSM address range; however, in that case there is no guarantee that it will receive service according to the SSM model. Another backward compatibility issue concerns the MSDP protocol, which is used between PIM-SM rendezvous points (RPs) to discover multicast sources across multiple domains. SSM obviates the needs for MSDP, but MSDP is still required to support ASM for non-SSM class-D IPv4 addresses. In order to ensure that SSM is the sole forwarding model in 232/8, RPs must not accept, originate or forward MSDP SA messages for the SSM address range [SSM-BCP]. Bhattacharyya et. al. [Page 10] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 7. Security Considerations SSM does not introduce new security considerations for IP multicast. It can help in preventing denial-of-service attacks resulting from unwanted sources transmitting data to a multicast channel (S, G). However no guarantee is provided. 8. Acknowledgments We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Sue Moon and Timothy Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and 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 Cereva Networks and Hugh LaMaster at NASA for their valuable insights and continuing support. 9. References: [EXPRESS] H. Holbrook and D.R. Cheriton. IP Multicast Channels : EXPRESS Support for Large-scale Single-Source Applications. In Proceedings of SIGCOMM 1999. [IANA-ALLOCATION] Internet Assigned Numbers Authority. http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. [RFC2236] W. Fenner. Internet Group Management Protocol, Version 2. Request For Comments 2236. [IGMPv3] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan. Internet Group Management Protocol, Version 3. Work in Progress. [SSM-IGMPv3] H. Holbrook and B. Cain. IGMPv3 for SSM. Work in Progress. [SSM-ARCH] H. Holbrook and B. Cain. Source-Specific Multicast for IP. Work in Progress. [IPMULTICAST] S. Deering and D. Cheriton. Multicast Routing in Datagram Networks and Extended LANs. ACM Transactions on Computer Systems, 8(2):85-110, May 1990. [PIM-ARCH] S. Deering et al. PIM Architecture for Wide-Area Bhattacharyya et. al. [Page 11] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162, April 1996. [RFC2362] D. Estrin et al. Protocol Independent Multicast - Sparse Mode (PIM-SM) : Protocol Specification. Request for Comments, 2362. [PIM-SM] Bill Fenner, et al. Protocol Independent Multicast - Sparse Mode (PIM-SM) : Protocol Specifications (Revised). Work in Progress. [PIM-DM] S. Deering et al. Protocol Independent Multicast Version 2 Dense Mode Specification. Work in Progress. [MSDP] Farinacci et al. Multicast Source Discovery Protocol. Work in Progress. [MCAST-DEPLOY] 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. [SSM-RULES] H. Sandick and B. Cain. PIM-SM Rules for Support of Single-Source Multicast. Work in Progress. [MSF-API] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface Extensions for Multicast Source Filters. Work in Progress. [RFC2770] GLOP Addressing in 233/8. Request For Comments 2770. [RCVR-INTEREST] B. Levine et al. Consideration of Receiver Interest for IP Multicast Delivery. In Proceedings of IEEE Infocom, March 2000. [SSM-BCP] G. Shepherd et al. Source-Specific Protocol Independent Multicast in 232/8. Work in Progress. [RFC2710] S. Deering, W. Fenner and B. Haberman. Multicast Listener Discovery for IPv6. Request for Comments 2710. [MLDv2] R. Vida, et. al. Multicast Listener Discovery Version 2 (MLDv2) for IPv6. Work in progress. [SSM-IPv6] B. Haberman and D. Thaler. Unicast-Prefix-Based IPv6 Multicast Addresses. Work in Progress. [IPSEC] S. Kent, R. Atkinson. Security Architecture for the Internet Protocol. Request for Bhattacharyya et. al. [Page 12] INTERNET-DRAFT An Overview of SSM Deployment 18 May 2000 Comments 2401. [IPv6-ALLOC] B. Haberman. Dynamic Allocation Guidelines for IPv6 Multicast Addresses. Work in Progress. 12. Authors' Address: Supratik Bhattacharyya Christophe Diot Sprint Advanced Technology Labs One Adrian Court Burlingame CA 94010 USA {supratik,cdiot}@sprintlabs.com http://www.sprintlabs.com Leonard Giuliano Greg Shepherd Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA {lenny,shep}@juniper.net Robert Rockell Sprint E|Solutions Reston Virginia USA rrockell@sprint.net John Meylor Dave Meyer Cisco Systems San Jose CA USA {jmeylor,dmm,shep@cisco.com} Brian Haberman Nortel Networks haberman@nortelnetworks.com Bhattacharyya et. al. [Page 13]