Network Working Group S. Bhattacharyya, Ed. Request for Comments: 3569 Sprint Category: Informational July 2003 An Overview of Source-Specific Multicast (SSM) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThe purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. 9] protocol. This document is not intended to be a standard for Source-Specific Multicast (SSM). Instead, its goal is to serve as an introduction to SSM and its benefits for anyone interested in deploying SSM services. It provides an overview of SSM and 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 multicast service model defined by RFC 1112 are also discussed. This memo is a product of the Source-Specific Multicast (SSM) Working Group of the Internet Engineering Task Force. The keywords "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as defined in BCP 14, RFC 2119 . RFC 1112 . An IP datagram is transmitted to a "host group", a set of zero or more end-hosts (or routers) identified by a single IP destination address (18.104.22.168 through 22.214.171.124 for IPv4). End-hosts may join and leave the group any time, and there is no restriction on their location or number. Moreover, this model supports multicast groups with arbitrarily many senders - any end-host (or router) may transmit to a host group, even if it is not a member of that group. Source-Specific Multicast (SSM): This is the multicast service model defined in . An IP datagram is transmitted by a source S to an SSM destination address G, and receivers can receive this datagram by subscribing to channel (S,G). SSM provides host applications with a "channel" abstraction, in which each channel has exactly one source and any number of receivers. SSM is derived from earlier work in EXPRESS . The address range 232/8 has been assigned by IANA for SSM service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM services . Source-Filtered Multicast (SFM): This is a variant of the ASM service model, and uses the same address range as ASM (126.96.36.199-188.8.131.52). It extends the ASM service model as follows. 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. Support for source filtering is provided by version 3 of the Internet Group Management Protocol (or IGMPv3)  for IPv4, and version 2 of the Multicast Listener Discovery (or MLDv2)  protocol for IPv6. 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". Note that while SFM is a different model than ASM from a receiver standpoint, there is no distinction between the two for a sender. For the purpose of this document, we treat the scoped multicast model of  to be a variant of ASM since it does not explicitly restrict the number of sources, but only requires that they be located within the scope zone of the group. 2], PIM-SM [8,9], MSDP  and MBGP . IGMPv2 is the most commonly used protocol for hosts to specify membership in a multicast group, and nearly all multicast routers support (at least) IGMPv2. In case of IPv6, MLDv1  is the commonly used protocol. Although a number of protocols such as PIM-DM , CBT [24,11], DVMRP , etc. exist for building multicast tree among all receivers and sources in the same administrative domain, PIM-SM [8,9] is the most widely used protocol. PIM-SM builds a spanning multicast tree rooted at a core rendezvous point or RP for all group members within a single administrative domain. A 'first-hop' router adjacent to a multicast source sends the source's traffic to the RP for its domain. The RP forwards the data down the shared spanning tree to all interested receivers within the domain. PIM-SM also allows receivers to switch to a source-based shortest path tree. As of this writing, multicast end-hosts with SFM capabilities are not widely available. Hence a client can only specify interest in an entire host group and receives data sent from any source to this group. Inter-domain multicast service (i.e., where sources and receivers are located in different domains) requires additional protocols - MSDP  and MBGP  are the most commonly used ones. An RP uses the MSDP protocol to announce multicast sources to RPs in other domains. When an RP discovers a source in a different domain transmitting data to a multicast group for which there are interested receivers in its own domain, it joins the shortest-path source based tree rooted at that source. It then redistributes the data received to all interested receivers via the intra-domain shared tree rooted at itself.
MBGP defines extensions to the BGP protocol to support the advertisement of reachability information for multicast routes. This allows an autonomous system (AS) to support incongruent unicast and multicast routing topologies, and thus implement separate routing policies for each. However, the last-hop routers of interested receivers may eventually switch to a shortest-path tree rooted at the source that is transmitting the data. 17] has been proposed 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. RFC 3138 expands on RFC 2770 to allow routing registries to assign multicast addresses from the GLOP space corresponding to the RFC 1930 private AS space . This space is referred to as the EGLOP (Extended GLOP) address space. Proposed longer-term solutions such as the Multicast Address Allocation Architecture  are generally perceived as being too complex (with respect to the dynamic nature of multicast address allocation) for widespread deployment. B) Lack of Access control: In the ASM service model, a receiver cannot 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. Moreover, even when a source is allocated a multicast group address to transmit on, it has no way of enforcing that no other source will use the same address. This is true even in the case of IPv6, where address collisions are less likely due to the much larger size of the address space.
C) 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 are not necessary.
Figure 1 illustrates the elements in an end-to-end implementation framework for SSM: -------------------------------------------------------------- IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION FF3x::/96 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 -------------------------------------------------------------- | 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 +-----------+ Backbone 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: 9] which recommend that routers should not send SSM traffic to parts of the network that do not have channel subscribers. Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 range. However, SSM service, as defined in , is available only in this address range for IPv4. In case of IPv6,  has defined an extension to the addressing architecture to allow for unicast prefix-based multicast addresses. See RFC 3306 for details.
Specific API requirements are identified in .  describes a recommended application programming interface for a host operating system to support the SFM service model. Although it is intended for SFM, a subset of this interface is sufficient for supporting SSM. 3] and MLD version 1  allows an end-host to specify only a destination multicast address. The ability to specify an SSM channel address c is provided by IGMP version 3  and MLD version 2 . These protocols support "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. In fact, IGMPv3 provides a superset of the capabilities required to realize the SSM service model. A detailed discussion of the use of IGMPv3 in the SSM destination address range is provided in . 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. MLD version 1 is derived from IGMPv2 and does not provide the source filtering capability required for the SSM service model. MLD version 2 is derived from, and provides the same support for source-filtering as, IGMPv3. Thus IGMPv3 (or MLDv2 for IPv6) provides a host with the ability to request the network for an SSM channel subscription. 9] provides guidelines for how a PIM-SM implementation should handle source-specific host reports as required by SSM. Earlier versions of the PIM protocol specifications did not describe how to do this. The router requirements for operation in the SSM range are detailed in . These rules are primarily concerned with preventing ASM-style behaviour in the SSM address range. In order to comply with  several changes to the PIM-SM protocol are required, as described in . The most important changes in PIM-SM required for compliance with  are:
- 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. - Backbone 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. Note that only a small subset of the full PIM-SM protocol functionality is needed to support the SSM service model. This subset is explicitly documented in . 5]. The ASM service model will be offered for the non-SSM address 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 interoperability issue concerns the MSDP protocol, which is used between PIM-SM rendezvous points (RPs) to discover multicast sources across multiple domains. MSDP is not needed for SSM, but is needed if ASM is supported.  specifies operational recommendations to help ensure that MSDP does not interfere with the ability of a network to support the SSM service model. Specifically,  states that RPs must not accept, originate or forward MSDP SA messages for the SSM address range.
 Holbrook, H. and D.R. Cheriton, "IP Multicast Channels: EXPRESS Support for Large-scale Single-Source Applications", In Proceedings of SIGCOMM 1999.  Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.  Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3.", RFC 3376, October 2002.  Holbrook, H. and B. Cain, "Using IGMPv3 and MLDv2 for Source-Specific Multicast", Work In Progress.  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress.  Deering, S. and D. Cheriton,"Multicast Routing in Datagram Networks and Extended LANs", ACM Transactions on Computer Systems, 8(2):85-110, May 1990.  Deering, S. et al., "PIM Architecture for Wide-Area Multicast Routing", IEEE/ACM Transaction on Networking, pages 153-162, April 1996.  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.  Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work In Progress.
 Adams, A., Nicholas, J. and W. Siadek, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Work In Progress.  Ballardie, A., "Core-Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.  Meyer, D., "Adminstratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.  Farinacci, D. et al., "Multicast Source Discovery Protocol", Work In Progress.  Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.  Diot, C., Levine, B., Lyles, B., Kassem, H. and D. Balensiefen, "Deployment Issues for the IP Multicast Service and Architecture", In IEEE Networks Magazine's Special Issue on Multicast, January, 2000.  Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", Work in Progress.  Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.  Levine, B. et al., "Consideration of Receiver Interest for IP Multicast Delivery", In Proceedings of IEEE Infocom, March 2000.  Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999.  Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2) for IPv6", Work In Progress.  Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast Addresses", RFC 3306, August 1992.  Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.  Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
 Ballardie, A., "Core-Based Trees (CBT Version 2) Multicast Routing -- Protocol Specification", RFC 2189, September 2001.  Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.  Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.  Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.