draft-ietf-ssm-overview-05.txt   rfc3569.txt 
INTERNET-DRAFT Supratik Bhattacharyya Network Working Group S. Bhattacharyya, Ed.
Expires 01 November 2003 Sprint Request for Comments: 3569 Sprint
Christophe Diot Category: Informational July 2003
Intel
Leonard Giuliano
Juniper Networks
Rob Rockell
Sprint
John Meylor
Cisco Systems
David Meyer
Sprint
Greg Shepherd
Procket Networks
Brian Haberman
Caspian Networks
01 May 2003
An Overview of Source-Specific Multicast (SSM) An Overview of Source-Specific Multicast (SSM)
<draft-ietf-ssm-overview-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
The purpose of this document is to provide an overview of Source- The purpose of this document is to provide an overview of
Specific Multicast (SSM) and issues related to its deployment. It Source-Specific Multicast (SSM) and issues related to its deployment.
discusses how the SSM service model addresses the challenges faced in It discusses how the SSM service model addresses the challenges faced
inter-domain multicast deployment, changes needed to routing protocols in inter-domain multicast deployment, changes needed to routing
and applications to deploy SSM and interoperability issues with current protocols and applications to deploy SSM and interoperability issues
multicast service models. with current multicast service models.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
1.Introduction 1. Introduction
This document provides an overview of the Source-Specific Multicast This document provides an overview of the Source-Specific Multicast
(SSM) service and its deployment using the PIM-SM and IGMP/MLD (SSM) service and its deployment using the PIM-SM and IGMP/MLD
protocols. The network layer service provided by SSM is a "channel", protocols. The network layer service provided by SSM is a "channel",
identified by an SSM destination IP address (G) and a source IP identified by an SSM destination IP address (G) and a source IP
address S. An IPv4 address range has been reserved by IANA for use address S. An IPv4 address range has been reserved by IANA for use
by the SSM service. An SSM destination address range already exists by the SSM service. An SSM destination address range already exists
for IPv6. A source S transmits IP datagrams to an SSM destination for IPv6. A source S transmits IP datagrams to an SSM destination
address G. A receiver can receive these datagrams by subscribing to address G. A receiver can receive these datagrams by subscribing to
the channel (S,G). Channel subscription is supported by version 3 of the channel (Source, Group) or (S,G). Channel subscription is
the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6. supported by version 3 of the IGMP protocol for IPv4 and version2 of
The interdomain tree for forwarding IP multicast datagrams is rooted the MLD protocol for IPv6. The interdomain tree for forwarding IP
at the source S, and is constructed using the PIM Sparse Mode [9] multicast datagrams is rooted at the source S, and is constructed
protocol. using the PIM Sparse Mode [9] protocol.
This document is not intended to be a standard for Source-Specific This document is not intended to be a standard for Source-Specific
Multicast (SSM). Instead, its goal is to serve as an introduction to Multicast (SSM). Instead, its goal is to serve as an introduction to
SSM and and its benefits for anyone interested in deploying SSM SSM and its benefits for anyone interested in deploying SSM services.
services. It provides an overview of SSM and and how it solves a It provides an overview of SSM and how it solves a number of problems
number of problems faced in the deployment of inter-domain multicast. faced in the deployment of inter-domain multicast. It outlines
It outlines changes to protocols and applications both at end-hosts changes to protocols and applications both at end-hosts and routers
and routers for supporting SSM, with pointers to more detailed for supporting SSM, with pointers to more detailed documents where
documents where appropriate. Issues of interoperability with the appropriate. Issues of interoperability with the multicast service
multicast service model defined by RFC 1112 are also discussed. model defined by RFC 1112 are also discussed.
2. Terminology This memo is a product of the Source-Specific Multicast (SSM) Working
Group of the Internet Engineering Task Force.
This section defines some terms that are used in the rest of this The keywords "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document : "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as defined in BCP 14, RFC 2119 [28].
Any-Source Multicast (ASM) : This is the IP multicast service model 2. Terminology
defined in RFC 1112 [25]. 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 (224.0.0.0 through 239.255.255.255 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 This section defines some terms that are used in the rest of this
defined in [5]. An IP datagram is transmitted by a source S to an SSM document:
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 [1].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 [21].
Source-Filtered Multicast (SFM) : This is a variant of the ASM service Any-Source Multicast (ASM): This is the IP multicast service model
model, and uses the same address range as ASM defined in RFC 1112 [25]. An IP datagram is transmitted to a
(224.0.0.0-239.255.255.255). It extends the ASM service model as "host group", a set of zero or more end-hosts (or routers)
follows. Each "upper layer protocol module" can now request data sent identified by a single IP destination address (224.0.0.0 through
to a host group G by only a specific set of sources, or can request 239.255.255.255 for IPv4). End-hosts may join and leave the group
data sent to host group G from all BUT a specific set of sources. any time, and there is no restriction on their location or number.
Support for source filtering is provided by version 3 of the Internet Moreover, this model supports multicast groups with arbitrarily
Group Management Protocol (or IGMPv3) [3] for IPv4, and version 2 of many senders - any end-host (or router) may transmit to a host
the Multicast Listener Discovery (or MLDv2) [22] protocol for IPv6. group, even if it is not a member of that group.
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 Source-Specific Multicast (SSM): This is the multicast service
[12] to be a variant of ASM since it does not explicitly restrict the model defined in [5]. An IP datagram is transmitted by a source S
number of sources, but only requires that they be located within the to an SSM destination address G, and receivers can receive this
scope zone of the group. 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 [1]. 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 [21].
3. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM Source-Filtered Multicast (SFM): This is a variant of the ASM
service model, and uses the same address range as ASM
(224.0.0.0-239.255.255.255). 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) [3] for IPv4,
and version 2 of the Multicast Listener Discovery (or MLDv2) [22]
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 [12] 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.
3. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM
As of this writing, all multicast-capable networks support the ASM As of this writing, all multicast-capable networks support the ASM
service model. One of the most common multicast protocol suites for service model. One of the most common multicast protocol suites for
supporting ASM consists of IGMP version 2 [26], PIM-SM [8,9], MSDP supporting ASM consists of IGMP version 2 [2], PIM-SM [8,9], MSDP
[13] and MBGP [27] protocols. IGMPv2 [2] is the most commonly used [13] and MBGP [26]. IGMPv2 is the most commonly used protocol for
protocol for hosts to specify membership in a multicast group, and hosts to specify membership in a multicast group, and nearly all
nearly all multicast routers support (at least) IGMPv2. In case of multicast routers support (at least) IGMPv2. In case of IPv6, MLDv1
IPv6, MLDv1 [21] is the commonly used protocol. [21] is the commonly used protocol.
Although a number of protocols such as PIM-DM [10], CBT [24,11], Although a number of protocols such as PIM-DM [10], CBT [24,11],
DVMRP [6], etc. exist for building multicast tree among all receivers DVMRP [6], etc. exist for building multicast tree among all receivers
and sources in the same administrative domain, PIM-SM [8,9] is the and sources in the same administrative domain, PIM-SM [8,9] is the
most widely used protocol. PIM-SM builds a spanning multicast tree most widely used protocol. PIM-SM builds a spanning multicast tree
rooted at a core rendezvous point or RP for all group members within rooted at a core rendezvous point or RP for all group members within
a single administrative domain. A 'first-hop' router adjacent to a a single administrative domain. A 'first-hop' router adjacent to a
multicast source sends the source's traffic to the RP for its domain. 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 The RP forwards the data down the shared spanning tree to all
interested receivers within the domain. PIM-SM also allows receivers interested receivers within the domain. PIM-SM also allows receivers
to switch to a source-based shortest path tree. to switch to a source-based shortest path tree.
As of this writing, multicast end-hosts with SFM capabilities are not As of this writing, multicast end-hosts with SFM capabilities are not
widely available. Hence a client can only specify interest in an widely available. Hence a client can only specify interest in an
entire host group and receives data sent from any source to this entire host group and receives data sent from any source to this
group. group.
Inter-domain multicast service (i.e., where sources and receivers are Inter-domain multicast service (i.e., where sources and receivers are
located in different domains) requires additional protocols - MSDP located in different domains) requires additional protocols - MSDP
[13] and MBGP [27] are the most commonly used ones. An RP uses the [13] and MBGP [26] are the most commonly used ones. An RP uses the
MSDP [13] protocol to announce multicast sources to RPs in other MSDP protocol to announce multicast sources to RPs in other domains.
domains. When an RP discovers a source in a different domain When an RP discovers a source in a different domain transmitting data
transmitting data to a multicast group for which there are interested to a multicast group for which there are interested receivers in its
receivers in its own domain, it joins the shortest-path source based own domain, it joins the shortest-path source based tree rooted at
tree rooted at that source. It then redistributes the data received that source. It then redistributes the data received to all
to all interested receivers via the intra-domain shared tree rooted interested receivers via the intra-domain shared tree rooted at
at itself. itself.
The MBGP protocol [27] defines extensions to the BGP protocol to MBGP defines extensions to the BGP protocol to support the
support the advertisement of reachability information for multicast advertisement of reachability information for multicast routes. This
routes. This allows an autonomous system (AS) to support incongruent allows an autonomous system (AS) to support incongruent unicast and
unicast and multicast routing topologies, and thus implement separate multicast routing topologies, and thus implement separate routing
routing policies for each. policies for each.
4. Problems with Current Architecture 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.
4. Problems with Current Architecture
There are several deployment problems associated with current There are several deployment problems associated with current
multicast architecture: multicast architecture:
A) Address Allocation : A) Address Allocation:
Address allocation is one of core deployment challenges posed by Address allocation is one of core deployment challenges posed
the ASM service model. The current multicast architecture does not by the ASM service model. The current multicast architecture
provide a deployable solution to prevent address collisions among does not provide a deployable solution to prevent address
multiple applications. The problem is much less serious for IPv6 collisions among multiple applications. The problem is much
than for IPv4 since the size of the multicast address space is less serious for IPv6 than for IPv4 since the size of the
much larger. A static address allocation scheme, GLOP [17] has multicast address space is much larger. A static address
been proposed as an interim solution for IPv4; however, GLOP allocation scheme, GLOP [17] has been proposed as an interim
addresses are allocated per registered AS, which is inadequate in solution for IPv4; however, GLOP addresses are allocated per
cases where the number of sources exceeds the AS numbers available registered AS, which is inadequate in cases where the number of
for mapping. Proposed longer-term solutions such as the Multicast sources exceeds the AS numbers available for mapping. RFC 3138
Address Allocation Architecture [14] are generally perceived as expands on RFC 2770 to allow routing registries to assign
being too complex (with respect to the dynamic nature of multicast multicast addresses from the GLOP space corresponding to the
address allocation) for widespread deployment. RFC 1930 private AS space [27]. This space is referred to as
the EGLOP (Extended GLOP) address space. Proposed longer-term
solutions such as the Multicast Address Allocation Architecture
[14] 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 : B) Lack of Access control:
In the ASM service model, a receiver cannot specify which In the ASM service model, a receiver cannot specify which
specific sources it would like to receive when it joins a given 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 group. A receiver will be forwarded data sent to a host group
any source. Moreover, even when a source is allocated a multicast by any source. Moreover, even when a source is allocated a
group address to transmit on, it has no way of enforcing that no multicast group address to transmit on, it has no way of
other source will use the same address. This is true even in the enforcing that no other source will use the same address. This
case of IPv6, where address collisions are less likely due to the is true even in the case of IPv6, where address collisions are
much larger size of the address space. less likely due to the much larger size of the address space.
C) Inefficient handling of well-known sources : C) Inefficient handling of well-known sources:
In cases where the address of the source is well known in advance In cases where the address of the source is well known in
of the receiver joining the group, and when the shortest advance of the receiver joining the group, and when the
forwarding path is the preferred forwarding mode, then shared tree shortest forwarding path is the preferred forwarding mode, then
mechanisms and MSDP are not necessary. shared tree mechanisms are not necessary.
5. Source Specific Multicast (SSM) : Benefits and Requirements 5. Source Specific Multicast (SSM): Benefits and Requirements
As mentioned before, the Source Specific Multicast (SSM) service As mentioned before, the Source Specific Multicast (SSM) service
model defines a "channel" identified by an (S,G) pair, where S is a model defines a "channel" identified by an (S,G) pair, where S is a
source address and G is an SSM destination address. Channel source address and G is an SSM destination address. Channel
subscriptions are described using an SFM-capable group management subscriptions are described using an SFM-capable group management
protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees
are needed to implement this model. are needed to implement this model.
The SSM service model alleviates all of the deployment problems The SSM service model alleviates all of the deployment problems
described earlier : described earlier:
A) Address Allocation : SSM defines channels on a per-source
basis, i.e., the channel (S1,G) is distinct from the channel
(S2,G), where S1 and S2 are source addresses, and G is an SSM
destination address. This averts the problem of global allocation
of SSM destination addresses, and makes each source independently
responsible for resolving address collisions for the various
channels that it creates.
B) Access Control : SSM lends itself to an elegant solution to the A) Address Allocation: SSM defines channels on a per-source basis,
access control problem. When a receiver subscribes to an (S,G) i.e., the channel (S1,G) is distinct from the channel (S2,G),
channel, it receives data sent only by the source S. In contrast, where S1 and S2 are source addresses, and G is an SSM
any host can transmit to an ASM host group. At the same time, when destination address. This averts the problem of global
a sender picks a channel (S,G) to transmit on, it is automatically allocation of SSM destination addresses, and makes each source
ensured that no other sender will be transmitting on the same independently responsible for resolving address collisions for
channel (except in the case of malicious acts such as address the various channels that it creates.
spoofing). This makes it much harder to "spam" an SSM channel than
an ASM multicast group.
C) Handling of well-known sources : SSM requires only source-based B) Access Control: SSM lends itself to an elegant solution to the
forwarding trees; this eliminates the need for a shared tree access control problem. When a receiver subscribes to an (S,G)
infrastructure. This implies that neither the RP-based shared tree channel, it receives data sent only by the source S. In
infrastructure of PIM-SM nor the MSDP protocol is required. Thus contrast, any host can transmit to an ASM host group. At the
the complexity of the multicast routing infrastructure for SSM is same time, when a sender picks a channel (S,G) to transmit on,
low, making it viable for immediate deployment. Note that there is it is automatically ensured that no other sender will be
no difference in how MBGP is used for ASM and SSM. transmitting on the same channel (except in the case of
malicious acts such as address spoofing). This makes it much
harder to "spam" an SSM channel than an ASM multicast group.
6. SSM Framework C) Handling of well-known sources: SSM requires only
source-based forwarding trees; this eliminates the need for a
shared tree infrastructure. 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. Note that there is no difference in how
MBGP is used for ASM and SSM.
Figure 1 illustrates the elements in an end-to-end implementation 6. SSM Framework
framework for SSM :
-------------------------------------------------------------- Figure 1 illustrates the elements in an end-to-end implementation
IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION framework for SSM:
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 IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION
+-----------------+ FF3x::/96 for IPv6
|(source specific host report) --------------------------------------------------------------
-------------------------------------------------------------- |
v v
+-----------------+ Querier Router +--------------+ session directory/web page
| IGMPv3/MLDv2 | QUERIER | source,group | SESSION DESCRIPTION
-------------------------------------------------------------- --------------------------------------------------------------
| PIM-SSM | PIM-SSM ROUTING ^ |
+------------+ Designated Router Query | | (S,G)
| | v
| (S,G) Join only +-----------------+ host
v | SSM-aware app | CHANNEL DISCOVERY
+-----------+ Backbone Router --------------------------------------------------------------
| PIM-SSM | | SSM-aware app | SSM-AWARE APPLICATION
+-----------+ --------------------------------------------------------------
| | IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING
| (S,G) Join only +-----------------+
V |(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 Figure 1: SSM Framework: elements in end-to-end model
We now discuss the framework elements in detail : We now discuss the framework elements in detail:
6.1 Address Allocation 6.1. Address Allocation
For IPv4, the address range of 232/8 has been assigned by IANA for For IPv4, the address range of 232/8 has been assigned by IANA for
SSM. To ensure global SSM functionality in 232/8, including in SSM. To ensure global SSM functionality in 232/8, including in
networks where routers run non-SFM-capable protocols, operational networks where routers run non-SFM-capable protocols, operational
policies are being proposed [20] which recommend that routers should policies are being proposed [9] which recommend that routers should
not send SSM traffic to parts of the network that do not have channel not send SSM traffic to parts of the network that do not have channel
subscribers. subscribers.
Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8
range. However, SSM service, as defined in [5], is available only in range. However, SSM service, as defined in [5], is available only in
this address range for IPv4. this address range for IPv4.
In case of IPv6, [23] has defined an extension to the addressing In case of IPv6, [23] has defined an extension to the addressing
architecture to allow for unicast prefix-based multicast addresses. architecture to allow for unicast prefix-based multicast addresses.
See RFC 3306 for details. See RFC 3306 for details.
6.2 Session Description and Channel Discovery 6.2. Session Description and Channel Discovery
An SSM receiver application must know both the SSM destination An SSM receiver application must know both the SSM destination
address G and the source address S before subscribing to a address G and the source address S before subscribing to a channel.
channel. Channel discovery is the responsibility of applications. Channel discovery is the responsibility of applications. This
This information can be made available in a number of ways, information can be made available in a number of ways, including via
including via web pages, sessions announcement applications, etc. web pages, sessions announcement applications, etc. This is similar
This is similar to what is used for ASM applications where a to what is used for ASM applications where a multicast session needs
multicast session needs to be announced so that potential to be announced so that potential subscribers can know of the
subscribers can know of the multicast group adddres, encoding multicast group address, encoding schemes used, etc. In fact, the
schemes used, etc. In fact, the only additional piece of only additional piece of information that needs to be announced is
information that needs to be announced is the source address for the source address for the channel being advertised. However, the
the channel being advertised. However, the exact mechanisms for exact mechanisms for doing this is outside the scope of this
doing this is outside the scope of this framework document. framework document.
6.3. SSM-Aware Applications 6.3. SSM-Aware Applications
There are two main issues in making multicast applications "SSM- There are two main issues in making multicast applications
aware": "SSM-aware":
-- An application that wants to receive an SSM session must first - An application that wants to receive an SSM session must first
discover the channel address in use. discover the channel address in use.
-- A receiving application must be able to specify both a source - A receiving application must be able to specify both a source
address and a destination address to the network layer protocol address and a destination address to the network layer protocol
module on the end-host. module on the end-host.
Specific API requirements are identified in [16]. [16] describes a Specific API requirements are identified in [16]. [16] describes
recommended application programming interface for a host operating a recommended application programming interface for a host
system to support the SFM service model. Although it is intended operating system to support the SFM service model. Although it is
for SFM, a subset of this interface is sufficient for supporting intended for SFM, a subset of this interface is sufficient for
SSM. supporting SSM.
6.4. IGMPv3/MLDv2 Host Reporting and Querier 6.4. IGMPv3/MLDv2 Host Reporting and Querier
In order to use SSM service, an end-host must be able to specify a In order to use SSM service, an end-host must be able to specify a
channel address, consisting of a source's unicast address and an channel address, consisting of a source's unicast address and an SSM
SSM destination address. IGMP version 2 [26] and MLD version 1 destination address. IGMP version 2 [3] and MLD version 1 [19]
[19] allows an end-host to specify only a destination multicast allows an end-host to specify only a destination multicast address.
address. The ability to specify an SSM channel address c is The ability to specify an SSM channel address c is provided by IGMP
provided by IGMP version 3 [3] and MLD version 2 [22]. These version 3 [3] and MLD version 2 [20]. These protocols support
protocols support "source filtering", i.e., the ability of an end- "source filtering", i.e., the ability of an end-system to express
system to express interest in receiving data packets sent only by interest in receiving data packets sent only by SPECIFIC sources, or
SPECIFIC sources, or from ALL BUT some specific sources. In fact, from ALL BUT some specific sources. In fact, IGMPv3 provides a
IGMPv3 provides a superset of the capabilities required to realize superset of the capabilities required to realize the SSM service
the SSM service model. model.
A detailed discussion of the use of IGMPv3 in the SSM destination A detailed discussion of the use of IGMPv3 in the SSM destination
address range is provided in [4]. address range is provided in [4].
The Multicast Listener Discovery (MLD) protocol used by an IPv6 The Multicast Listener Discovery (MLD) protocol used by an IPv6
router to discover the presence of multicast listeners on its router to discover the presence of multicast listeners on its
directly attached links, and to discover the multicast addresses directly attached links, and to discover the multicast addresses that
that are of interest to those neighboring nodes. Version 1 of MLD are of interest to those neighboring nodes. MLD version 1 is derived
[19] is derived from IGMPv2 and does not provide the source from IGMPv2 and does not provide the source filtering capability
filtering capability required for the SSM service model. Version 2 required for the SSM service model. MLD version 2 is derived from,
of MLD [20] is derived from, and provides the same support for and provides the same support for source-filtering as, IGMPv3. Thus
source-filtering as, IGMPv3. Thus IGMPv3 (or MLDv2 for IPv6) IGMPv3 (or MLDv2 for IPv6) provides a host with the ability to
provides a host with the ability to request the network for an SSM request the network for an SSM channel subscription.
channel subscription.
6.5. PIM-SSM Routing 6.5. PIM-SSM Routing
[9] provides guideliness for how a PIM-SM implementation should [9] provides guidelines for how a PIM-SM implementation should handle
handle source-specific host reports as required by SSM. Earlier source-specific host reports as required by SSM. Earlier versions of
versions of the PIM protocol specifications did not describe how to the PIM protocol specifications did not describe how to do this.
do this.
The router requirements for operation in the SSM range are detailed The router requirements for operation in the SSM range are detailed
in [5]. These rules are primarily concerned with preventing ASM-style in [5]. These rules are primarily concerned with preventing
behaviour in the SSM address range. In order to comply with [5] ASM-style behaviour in the SSM address range. In order to comply
several changes to the PIM-SM protocol are required, as described in with [5] several changes to the PIM-SM protocol are required, as
[9].The most important changes in PIM-SM required for compliance with described in [9]. The most important changes in PIM-SM required for
[5] are : compliance with [5] are:
-- When a DR receives an (S,G) join request with the address G in - When a DR receives an (S,G) join request with the address G in the
the SSM address range, it must initiate a (S,G) join and NEVER a SSM address range, it MUST initiate a (S,G) join, and NEVER a
(*,G) join. (*,G) join.
--Backbone routers (i.e. routers that do not have directly - Backbone routers (i.e., routers that do not have directly attached
attached hosts) must not propagate (*,G) joins for group addresses hosts) MUST NOT propagate (*,G) joins for group addresses in the
in the SSM address range. SSM address range.
--Rendezvous Points (RPs) must not accept PIM Register messages or - Rendezvous Points (RPs) MUST NOT accept PIM Register messages or
(*,G) Join messages in the SSM address range. (*,G) Join messages in the SSM address range.
Note that only a small subset of the full PIM-SM protocol Note that only a small subset of the full PIM-SM protocol
functionality is needed to support the SSM service model. This subset functionality is needed to support the SSM service model. This
is explicitly documented in [9]. subset is explicitly documented in [9].
7. Interoperability with Existing Multicast Service Models 7. Interoperability with Existing Multicast Service Models
Interoperability with ASM is one of the most important issues in Interoperability with ASM is one of the most important issues in
moving to SSM deployment, since both models are expected to be used moving to SSM deployment, since both models are expected to be used
at least in the foreseeable future. SSM is the ONLY service model for at least in the foreseeable future. SSM is the ONLY service model
the SSM address range - the correct protocol behaviour for this range for the SSM address range - the correct protocol behaviour for this
is specified in [5]. The ASM service model will be offered for the range is specified in [5]. The ASM service model will be offered for
non-SSM adddress range, where receivers can issue (*,G) join requests the non-SSM address range, where receivers can issue (*,G) join
to receive multicast data. A receiver is also allowed to issue an requests to receive multicast data. A receiver is also allowed to
(S,G) join request in the non-SSM address range; however, in that issue an (S,G) join request in the non-SSM address range; however, in
case there is no guarantee that it will receive service according to that case there is no guarantee that it will receive service
the SSM model. according to the SSM model.
Another interoperability issue concerns the MSDP protocol, which is Another interoperability issue concerns the MSDP protocol, which is
used between PIM-SM rendezvous points (RPs) to discover multicast used between PIM-SM rendezvous points (RPs) to discover multicast
sources across multiple domains. MSDP is not needed for SSM, but is sources across multiple domains. MSDP is not needed for SSM, but is
needed if ASM is supported. [20] specifies operational needed if ASM is supported. [9] specifies operational
recommendations to help ensure that MSDP does not interfere with the recommendations to help ensure that MSDP does not interfere with the
ability of a network to support the SSM service model. Specifically, ability of a network to support the SSM service model. Specifically,
[20] states that RPs must not accept, originate or forward MSDP SA [9] states that RPs must not accept, originate or forward MSDP SA
messages for the SSM address range [20]. messages for the SSM address range.
8. Security Considerations 8. Security Considerations
SSM does not introduce new security considerations for IP multicast. SSM does not introduce new security considerations for IP multicast.
It can help in preventing denial-of-service attacks resulting from It can help in preventing denial-of-service attacks resulting from
unwanted sources transmitting data to a multicast channel (S, G). unwanted sources transmitting data to a multicast channel (S, G).
However no guarantee is provided. However no guarantee is provided.
9. Acknowledgments 9. Acknowledgments
We would like to thank Gene Bowen, Ed Kress, Bryan Lyles Timothy We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Timothy
Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and Nidhi Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and Nidhi
Bhaskar for participating in lengthy discussions and design work on Bhaskar for participating in lengthy discussions and design work on
SSM, and providing feedback on this document. Thanks are also due to SSM, and providing feedback on this document. Thanks are also due to
Mujahid Khan, Ted Seely , Tom Pusateri, Bill Fenner, Kevin Almeroth, Mujahid Khan, Ted Seely, Tom Pusateri, Bill Fenner, Kevin Almeroth,
Brian Levine, Brad Cain and Hugh LaMaster at NASA for their valuable Brian Levine, Brad Cain, Hugh LaMaster and Pekka Savola for their
insights and continuing support. valuable insights and continuing support.
10. References: 10. References
[1] H. Holbrook and D.R. Cheriton, "IP Multicast Channels : EXPRESS 10.1. Informative References
Support for Large-scale Single-Source Applications", In Proceedings
of SIGCOMM 1999.
[2] W. Fenner, "Internet Group Management Protocol, Version 2", RFC [1] Holbrook, H. and D.R. Cheriton, "IP Multicast Channels: EXPRESS
2236. Support for Large-scale Single-Source Applications", In
Proceedings of SIGCOMM 1999.
[3] B. Cain, S. Deering, I. Kouvelas and A. Thyagarajan, "Internet [2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC
Group Management Protocol, Version 3.", Request for Comments 3376. 2236, November 1997.
[4] H. Holbrook and B. Cain, "Using IGMPv3 and MLDv2 for Source- [3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
Specific Multicast", Work in Progress. "Internet Group Management Protocol, Version 3.", RFC 3376,
October 2002.
[5] H. Holbrook and B. Cain, "Source-Specific Multicast for [4] Holbrook, H. and B. Cain, "Using IGMPv3 and MLDv2 for
IP", Work in Progress. Source-Specific Multicast", Work In Progress.
[6] S. Deering and D. Cheriton,"Multicast Routing in Datagram [5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
Networks and Extended LANs", ACM Transactions on Computer Systems, Work in Progress.
8(2):85-110, May 1990.
[7] S. Deering et al., "PIM Architecture for Wide-Area Multicast [6] Deering, S. and D. Cheriton,"Multicast Routing in Datagram
Routing", IEEE/ACM Transaction on Networking, pages 153-162, April Networks and Extended LANs", ACM Transactions on Computer
1996. Systems, 8(2):85-110, May 1990.
[8] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode [7] Deering, S. et al., "PIM Architecture for Wide-Area Multicast
(PIM-SM) : Protocol Specification", RFC 2362. Routing", IEEE/ACM Transaction on Networking, pages 153-162,
April 1996.
[9] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [8] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei,
(Revised)", Work In Progress, 2000. "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
[10] A. Adams, J. Nicholas, W. Siadek, "Protocol Independent [9] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol
Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Independent Multicast - Sparse Mode (PIM-SM): Protocol
Work in Progress. Specification (Revised)", Work In Progress.
[11] A. Ballardie, "Core-Based Trees (CBT) Multicast Routing [10] Adams, A., Nicholas, J. and W. Siadek, "Protocol Independent
Architecture", RFC 2201. Multicast - Dense Mode (PIM-DM): Protocol Specification
(Revised)", Work In Progress.
[12] D. Meyer, "Adminstratively Scoped IP Multicast", RFC 2365. [11] Ballardie, A., "Core-Based Trees (CBT) Multicast Routing
Architecture", RFC 2201, September 1997.
[13] Farinacci et al., "Multicast Source Discovery Protocol", Work in [12] Meyer, D., "Adminstratively Scoped IP Multicast", BCP 23, RFC
Progress. 2365, July 1998.
[14] D. Thaler, M. Handley and D. Estrin, "The Internet Multicast [13] Farinacci, D. et al., "Multicast Source Discovery Protocol",
Address Allocation Architecture", Request for Comments 2908. Work In Progress.
[15] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen, [14] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast
"Deployment Issues for the IP Multicast Service and Architecture", In Address Allocation Architecture", RFC 2908, September 2000.
IEEE Networks Magazine's Special Issue on Multicast, January, 2000.
[16] Dave Thaler, Bill Fenner and Bob Quinn, "Socket Interface [15] Diot, C., Levine, B., Lyles, B., Kassem, H. and D. Balensiefen,
Extensions for Multicast Source Filters", Work in Progress. "Deployment Issues for the IP Multicast Service and
Architecture", In IEEE Networks Magazine's Special Issue on
Multicast, January, 2000.
[17] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", Request [16] Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions
For Comments 2770. for Multicast Source Filters", Work in Progress.
[18] B. Levine et al., "Consideration of Receiver Interest for IP [17] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53,
Multicast Delivery", In Proceedings of IEEE Infocom, March 2000. RFC 3180, September 2001.
[19] S. Deering, W. Fenner and B. Haberman, "Multicast Listener [18] Levine, B. et al., "Consideration of Receiver Interest for IP
Discovery for IPv6", RFC 2710. Multicast Delivery", In Proceedings of IEEE Infocom, March 2000.
[20] R. Vida, et. al., "Multicast Listener Discovery Version 2(MLDv2) [19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
for IPv6", Work in progress. Discovery for IPv6", RFC 2710, October 1999.
[21] B. Haberman and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast [20] Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2)
Addresses", Request for Comments 3306. for IPv6", Work In Progress.
[22] S. Kent, R. Atkinson, "Security Architecture for the Internet [21] Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast
Protocol", Request for Comments 2401. Addresses", RFC 3306, August 1992.
[23] B. Haberman, "Allocation Guidelines for IPv6 Multicast [22] Kent, S. and R. Atkinson, "Security Architecture for the
Addresses", Request for Comments 3307. Internet Protocol", RFC 2401, November 1998.
[24] A. Ballardie, "Core-Based Trees (CBT Version 2) Multicast [23] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Routing -- Protocol Specification", RFC 2189. Addresses", RFC 3307, August 2002.
[25] S. Deering, "Host Extensions for IP Multicasting", RFC 1112. [24] Ballardie, A., "Core-Based Trees (CBT Version 2) Multicast
Routing -- Protocol Specification", RFC 2189, September 2001.
[26] W. Fenner, "Internet Group Management Protocol, Version 2", RFC [25] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
2236. 1112, August 1989.
[27] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol [26] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 2283. Extensions for BGP-4", RFC 2858, June 2000.
12. Author information: [27] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
Supratik Bhattacharyya 10.2. Normative References
Sprint
supratik@sprintlabs.com [28] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
11. Contributors
Christophe Diot Christophe Diot
Intel Intel
christophe.diot@intel.com EMail: christophe.diot@intel.com
Leonard Giuliano Leonard Giuliano
Juniper Networks Juniper Networks
lenny@juniper.net EMail: lenny@juniper.net
Greg Shepherd Greg Shepherd
Procket Networks Procket Networks
shep@procket.com EMail: shep@procket.com
Robert Rockell Robert Rockell
Sprint
EMail: rrockell@sprint.net
David Meyer David Meyer
Sprint Sprint
{rrockell,dmm}@sprint.net EMail: dmm@1-4-5.net
John Meylor John Meylor
Cisco Systems Cisco Systems
jmeylor@cisco.com EMail: jmeylor@cisco.com
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
bkhabs@nc.rr.com EMail: bkhabs@nc.rr.com
12. Editor's Address
Supratik Bhattacharyya
Sprint
EMail: supratik@sprintlabs.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 107 change blocks. 
377 lines changed or deleted 372 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/