draft-ietf-ssm-overview-03.txt   draft-ietf-ssm-overview-04.txt 
INTERNET-DRAFT Supratik Bhattacharyya INTERNET-DRAFT Supratik Bhattacharyya
Expires 04 September 2002 Christophe Diot Expires 04 May 2003 Christophe Diot
Sprint ATL Sprint ATL
Leonard Giuliano Leonard Giuliano
Juniper Networks Juniper Networks
Rob Rockell Rob Rockell
Sprint E|Solutions Sprint
John Meylor John Meylor
Cisco Systems Cisco Systems
David Meyer David Meyer
Sprint E|Solutions Sprint
Greg Shepherd Greg Shepherd
Juniper Networks Juniper Networks
Brian Haberman Brian Haberman
No Affiliation Caspian Networks
04 March 2002 04 November 2002
An Overview of Source-Specific Multicast (SSM) An Overview of Source-Specific Multicast (SSM)
<draft-ietf-ssm-overview-03.txt> <draft-ietf-ssm-overview-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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].
Abstract Abstract
The 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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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 (S,G). Channel subscription is supported by version 3 of
the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6. the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6.
The interdomain tree for forwarding IP multicast datagrams is rooted The interdomain tree for forwarding IP multicast datagrams is rooted
at the source S, and is constructed using the PIM Sparse Mode [PIM- at the source S, and is constructed using the PIM Sparse Mode [9]
SM-NEW] protocol. 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 and its benefits for anyone interested in deploying SSM
services. It provides an overview of SSM and and how it solves a services. It provides an overview of SSM and and how it solves a
number of problems faced in the deployment of inter-domain multicast. number of problems faced in the deployment of inter-domain multicast.
It outlines changes to protocols and applications both at end-hosts It outlines changes to protocols and applications both at end-hosts
and routers for supporting SSM, with pointers to more detailed and routers for supporting SSM, with pointers to more detailed
documents where appropriate. Issues of interoperability with the documents where appropriate. Issues of interoperability with the
multicast service model defined by RFC 1112 are also discussed. multicast service model defined by RFC 1112 are also discussed.
1. Terminology 2. Terminology
This section defines some terms that are used in the rest of this This section defines some terms that are used in the rest of this
document : document :
Any-Source Multicast (ASM) : This is the IP multicast service model Any-Source Multicast (ASM) : This is the IP multicast service model
defined in RFC 1112 [RFC1112]. An IP datagram is transmitted to a defined in RFC 1112 [27]. An IP datagram is transmitted to a "host
"host group", a set of zero or more end-hosts identified by a single group", a set of zero or more end-hosts (or routers) identified by a
IP destination address (224.0.0.0 through 239.255.255.255 for IPv4). single IP destination address (224.0.0.0 through 239.255.255.255 for
End-hosts may join and leave the group any time, and there is no IPv4). End-hosts may join and leave the group any time, and there is
restriction on their location or number. Moreover, this model supports no restriction on their location or number. Moreover, this model
multicast groups with arbitrarily many senders - any end-host may supports multicast groups with arbitrarily many senders - any end-host
transmit to a host group, even if it is not a member of that group. (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 Source-Specific Multicast (SSM) : This is the multicast service model
defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to defined in [5]. An IP datagram is transmitted by a source S to an SSM
an SSM destination address G, and receivers can receive this datagram destination address G, and receivers can receive this datagram by
by subscribing to channel (S,G). SSM provides host applications with a subscribing to channel (S,G). SSM provides host applications with a
"channel" abstraction, in which each channel has exactly one source "channel" abstraction, in which each channel has exactly one source
and any number of receivers. SSM is derived from earlier work in and any number of receivers. SSM is derived from earlier work in
EXPRESS [EXPRESS].The address range 232/8 has been assigned by IANA EXPRESS [1].The address range 232/8 has been assigned by IANA for SSM
[IANA-ALLOC] for SSM service in IPv4. For IPv6, the range FF3x::/96 is service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM
defined for SSM services [SSM-IPv6]. services [23].
Source-Filtered Multicast (SFM) : This is a variant of the ASM service Source-Filtered Multicast (SFM) : This is a variant of the ASM service
model, and uses the same address range as ASM model, and uses the same address range as ASM
(224.0.0.0-239.255.255.255). It extends the ASM service model as (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 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 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. 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 Support for source filtering is provided by version 3 of the Internet
Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and version 2 Group Management Protocol (or IGMPv3) [3] for IPv4, and version 2 of
of the Multicast Listener Discovery (or MLDv2) [MLDv2] protocol for the Multicast Listener Discovery (or MLDv2) [22] protocol for IPv6.
IPv6. We shall henceforth refer to these two protocols as "SFM- We shall henceforth refer to these two protocols as "SFM-capable".
capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and Earlier versions of these protocols - IGMPv1/IGMPv2 and MLDv1 - do not
MLDv1 - do not provide support for source-filtering, and are referred provide support for source-filtering, and are referred to as "non-SFM-
to as "non-SFM-capable". Note that while SFM is a different model than capable". Note that while SFM is a different model than ASM from a
ASM from a receiver standpoint, there is no distinction between the receiver standpoint, there is no distinction between the two for a
two for a sender. sender.
For the purpose of this document, we treat the scoped multicast model of For the purpose of this document, we treat the scoped multicast model of
[RFC2365] to be a variant of ASM since it does not explicitly restrict [12] to be a variant of ASM since it does not explicitly restrict the
the number of sources, but only requires that they be located within the number of sources, but only requires that they be located within the
scope zone of the group. scope zone of the group.
2. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM 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 [IGMPv2], PIM-SM [PIM- supporting ASM consists of IGMP version 2 [28], PIM-SM [8,9], MSDP
SM,PIM-SM-NEW], MSDP [MSDP] and MBGP [MBGP] protocols. IGMPv2 [13] and MBGP [29] protocols. IGMPv2 [2] is the most commonly used
[RFC2236] is the most commonly used protocol for hosts to specify protocol for hosts to specify membership in a multicast group, and
membership in a multicast group, and nearly all multicast routers nearly all multicast routers support (at least) IGMPv2. In case of
support (at least) IGMPv2. In case of IPv6, MLDv1 [RFC2710] is the IPv6, MLDv1 [21] is the commonly used protocol.
commonly used protocol.
Although a number of protocols such as PIM-DM [PIM-DM], CBT Although a number of protocols such as PIM-DM [10], CBT [26,11],
[RFC2189,RFC2201], DVMRP [IPMULTICAST], etc. exist for building DVMRP [6], etc. exist for building multicast tree among all receivers
multicast tree among all receivers and sources in the same and sources in the same administrative domain, PIM-SM [8,9] is the
administrative domain, PIM-SM [PIM-SM, PIM-SM-NEW] is the most widely most widely used protocol. PIM-SM builds a spanning multicast tree
used protocol. PIM-SM builds a spanning multicast tree rooted at a rooted at a core rendezvous point or RP for all group members within
core rendezvous point or RP for all group members within a single a single administrative domain. A 'first-hop' router adjacent to a
administrative domain. A 'first-hop' router adjacent to a multicast multicast source sends the source's traffic to the RP for its domain.
source sends the source's traffic to the RP for its domain. The RP The RP forwards the data down the shared spanning tree to all
forwards the data down the shared spanning tree to all interested interested receivers within the domain. PIM-SM also allows receivers
receivers within the domain. PIM-SM also allows receivers to switch to switch to a source-based shortest path tree.
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 at least one source for a Inter-domain multicast service (i.e., where sources and receivers are
multicast group is located in a different domain than the receivers) located in multiple domains) requires additional protocols - MSDP
requires additional protocols - MSDP [MSDP] and MBGP [MBGP] are the [13] and MBGP [29] are the most commonly used ones. An RP uses the
most commonly used ones. An RP uses the MSDP [MSDP] protocol to MSDP [13] protocol to announce multicast sources to RPs in other
announce multicast sources to RPs in other domains. When an RP domains. When an RP discovers a source in a different domain
discovers a source in a different domain transmitting data to a transmitting data to a multicast group for which there are interested
multicast group for which there are interested receivers in its own receivers in its own domain, it joins the shortest-path source based
domain, it joins the shortest-path source based tree rooted at that tree rooted at that source. It then redistributes the data received
source. It then redistributes the data received to all interested to all interested receivers via the intra-domain shared tree rooted
receivers via the intra-domain shared tree rooted at itself. at itself.
The MBGP protocol [MBGP] defines extensions to the BGP protocol [BGP] The MBGP protocol [29] defines extensions to the BGP protocol to
to support the advertisement of reachability information for support the advertisement of reachability information for multicast
multicast routes. This allows an autonomous system (AS) to support routes. This allows an autonomous system (AS) to support incongruent
incongruent unicast and multicast routing topologies, and thus unicast and multicast routing topologies, and thus implement separate
implement separate routing policies for each. routing policies for each.
3. Problems with Current Architecture 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 by
the ASM service model. The current multicast architecture does not the ASM service model. The current multicast architecture does not
provide a deployable solution to prevent address collisions among provide a deployable solution to prevent address collisions among
multiple applications. The problem is much less serious for IPv6 multiple applications. The problem is much less serious for IPv6
than for IPv4 since the size of the multicast address space is than for IPv4 since the size of the multicast address space is
much larger. A static address allocation scheme, GLOP [GLOP00] much larger. A static address allocation scheme, GLOP [18] has
has been proposed as an interim solution for IPv4; however, GLOP been proposed as an interim solution for IPv4; however, GLOP
addresses are allocated per registered AS, which is inadequate in addresses are allocated per registered AS, which is inadequate in
cases where the number of sources exceeds the AS numbers available cases where the number of sources exceeds the AS numbers available
for mapping. Proposed longer-term solutions such as the Multicast for mapping. Proposed longer-term solutions such as the Multicast
Address Allocation Architecture [MAAA] are generally perceived as Address Allocation Architecture [14] are generally perceived as
being too complex (with respect to the dynamic nature of multicast being too complex (with respect to the dynamic nature of multicast
address allocation) for widespread deployment. 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 by
any source. Moreover, even when a source is allocated a multicast any source. Moreover, even when a source is allocated a multicast
group address to transmit on, it has no way of enforcing that no group address to transmit on, it has no way of enforcing that no
skipping to change at page 5, line 23 skipping to change at page 5, line 40
case of IPv6, where address collisions are less likely due to the case of IPv6, where address collisions are less likely due to the
much larger size of the address space. 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 advance
of the receiver joining the group, and when the shortest of the receiver joining the group, and when the shortest
forwarding path is the preferred forwarding mode, then shared tree forwarding path is the preferred forwarding mode, then shared tree
mechanisms and MSDP are not necessary. mechanisms and MSDP are not necessary.
4. 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 :
skipping to change at page 6, line 15 skipping to change at page 6, line 33
C) Handling of well-known sources : SSM requires only source-based C) Handling of well-known sources : SSM requires only source-based
forwarding trees; this eliminates the need for a shared tree forwarding trees; this eliminates the need for a shared tree
infrastructure. In terms of the IGMP/PIM-SM/MSDP/MBGP protocol infrastructure. In terms of the IGMP/PIM-SM/MSDP/MBGP protocol
suite, this implies that neither the RP-based shared tree suite, this implies that neither the RP-based shared tree
infrastructure of PIM-SM nor the MSDP protocol is required. Thus infrastructure of PIM-SM nor the MSDP protocol is required. Thus
the complexity of the multicast routing infrastructure for SSM is the complexity of the multicast routing infrastructure for SSM is
low, making it viable for immediate deployment. Note that MBGP is low, making it viable for immediate deployment. Note that MBGP is
still required for distribution of multicast reachability still required for distribution of multicast reachability
information. information.
D) It is widely held that point-to-multipoint applications such as 6. SSM Framework
Internet TV will be important in the near future. The SSM model is
ideally suited for such applications.
5. SSM Framework
Figure 1 illustrates the elements in an end-to-end implementation Figure 1 illustrates the elements in an end-to-end implementation
framework for SSM : framework for SSM :
-------------------------------------------------------------- --------------------------------------------------------------
IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION
FF3x::/12 for IPv6 FF3x::/96 for IPv6
-------------------------------------------------------------- --------------------------------------------------------------
| |
v v
+--------------+ session directory/web page +--------------+ session directory/web page
| source,group | SESSION DESCRIPTION | source,group | SESSION DESCRIPTION
-------------------------------------------------------------- --------------------------------------------------------------
^ | ^ |
Query | | (S,G) Query | | (S,G)
| v | v
+-----------------+ host +-----------------+ host
skipping to change at page 7, line 17 skipping to change at page 7, line 31
| PIM-SSM | | PIM-SSM |
+-----------+ +-----------+
| |
| (S,G) Join only | (S,G) Join only
V 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 :
5.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 [SSM-BCP] which recommend that routers policies are being proposed [20] which recommend that routers should
should not send SSM traffic to parts of the network that do not have not send SSM traffic to parts of the network that do not have channel
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 [SSM-ARCH], is available range. However, SSM service, as defined in [5], is available only in
only in this address range for IPv4. this address range for IPv4.
In case of IPv6, [HABE1] has defined an extension to the addressing In case of IPv6, [25] 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.
Bytes 0-3 (starting from the least significant byte) of the IP Bytes 0-3 (starting from the least significant byte) of the IP
address are used to specify a multicast group id, bytes 4-11 are used address are used to specify a multicast group id, bytes 4-11 are used
to specify a unicast address prefix (of up to 64 bits) that owns this 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 multicast group id, and byte 12 is used to specify the length of the
prefix. A source-specific multicast address is specified by setting prefix. A source-specific multicast address is specified by setting
both the prefix length field and the prefix field to zero. both the unicast address prefix field and the prefix length field to
zero.
5.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 discovery is the responsibility of applications. channel. Channel discovery is the responsibility of applications.
This information can be made available in a number of ways, This information can be made available in a number of ways,
including via web pages, sessions announcement applications, etc. including via web pages, sessions announcement applications, etc.
This is similar to what is used for ASM applications where a This is similar to what is used for ASM applications where a
multicast session needs to be announced so that potential multicast session needs to be announced so that potential
subscribers can know of the multicast group adddres, encoding subscribers can know of the multicast group adddres, encoding
schemes used, etc. In fact, the only additional piece of schemes used, etc. In fact, the only additional piece of
information that needs to be announced is the source address for information that needs to be announced is the source address for
the channel being advertised. However, the exact mechanisms for the channel being advertised. However, the exact mechanisms for
doing this is outside the scope of this framework document. doing this is outside the scope of this framework document.
5.3. SSM-Aware Applications 6.3. SSM-Aware Applications
There are two main issues in making multicast applications "SSM-
aware":
-- An application that wants to received an SSM session must first -- An application that wants to received an SSM session must first
discover the channel address in use. Any of the mechanisms discover the channel address in use. Any of the mechanisms
described in Section 5.2 can be used for this purpose. described in Section 5.2 can be used for this purpose.
-- 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. In other words, the application must be module on the end-host. In other words, the application must be
"SSM-aware". "SSM-aware".
Specific API requirements are identified in [THAL00]. [THAL00] Specific API requirements are identified in [17]. [17] describes a
describes a recommended application programming interface for a recommended application programming interface for a host operating
host operating system to support the SFM service model. Although system to support the SFM service model. Although it is intended
it is intended for SFM, a subset of this interface is sufficient for SFM, a subset of this interface is sufficient for supporting
for supporting SSM. SSM.
5.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 destination address. IGMP version 2 [IGMPv2] and MLD version 1 SSM destination address. IGMP version 2 [28] and MLD version 1
[MLDv1] allows an end-host to specify only a destination multicast [21] allows an end-host to specify only a destination multicast
address. The ability to specify an SSM channel address c is address. The ability to specify an SSM channel address c is
provided by IGMP version 3 [IGMPv3] and MLD version 2 [MLDv2]. provided by IGMP version 3 [3] and MLD version 2 [22]. These
These protocols support "source filtering", i.e., the ability of protocols support "source filtering", i.e., the ability of an end-
an end-system to express interest in receiving data packets sent system to express interest in receiving data packets sent only by
only by SPECIFIC sources, or from ALL BUT some specific sources. SPECIFIC sources, or from ALL BUT some specific sources. In fact,
In fact, IGMPv3 provides a superset of the capabilities required IGMPv3 provides a superset of the capabilities required to realize
to realize the SSM service model. the SSM service 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 [SSM-IGMPv3]. 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 are of interest to those neighboring nodes. Version 1 of MLD that are of interest to those neighboring nodes. Version 1 of MLD
[DEER99] is derived from IGMPv2 and does not provide the source [21] is derived from IGMPv2 and does not provide the source
filtering capability required for the SSM service model. Version 2 filtering capability required for the SSM service model. Version 2
of MLD [VIDA01] is derived from, and provides the same support for of MLD [22] is derived from, and provides the same support for
source-filtering as, IGMPv3. THus IGMPv3 (or MLDv2 for IPv6) source-filtering as, IGMPv3. Thus IGMPv3 (or MLDv2 for IPv6)
provides a host with the ability to request the network for an SSM provides a host with the ability to request the network for an SSM
channel subscription. channel subscription.
5.5. PIM-SSM Routing 6.5. PIM-SSM Routing
[PIM-SM-NEW] provides guideliness for how a PIM-SM implementation [9] provides guideliness for how a PIM-SM implementation should
should handle source-specific host reports as required by SSM. handle source-specific host reports as required by SSM. Earlier
Earlier versions of the PIM protocol specifications did not describe versions of the PIM protocol specifications did not describe how to
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 [SSM-ARCH]. These rules are primarily concerned with preventing in [5]. These rules are primarily concerned with preventing ASM-style
ASM-style behaviour in the SSM address range. In order to comply with behaviour in the SSM address range. In order to comply with [5]
[SSM-ARCH] several changes to the PIM-SM protocol are required, as several changes to the PIM-SM protocol are required, as described in
described in [PIM-SM-NEW].The most important changes in PIM-SM [9].The most important changes in PIM-SM required for compliance with
required for compliance with [SSM-ARCH] are : [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 SSM address range, it must initiate a (S,G) join and NEVER a the 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 hosts) must not propagate (*,G) joins for group addresses attached hosts) must not propagate (*,G) joins for group addresses
in the SSM address range. in the 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 subset
is explicitly documented in [PIM-SM-NEW]. is explicitly documented in [9].
6. 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 for
the SSM address range - the correct protocol behaviour for this range the SSM address range - the correct protocol behaviour for this range
is specified in [SSM-ARCH]. The ASM service model will be offered for is specified in [5]. The ASM service model will be offered for the
the non-SSM adddress range, where receivers can issue (*,G) join non-SSM adddress range, where receivers can issue (*,G) join requests
requests to receive multicast data. A receiver is also allowed to to receive multicast data. A receiver is also allowed to issue an
issue an (S,G) join request in the non-SSM address range; however, in (S,G) join request in the non-SSM address range; however, in that
that case there is no guarantee that it will receive service case there is no guarantee that it will receive service according to
according to the SSM model. 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. [SSM-BCP] specifies operational needed if ASM is supported. [20] 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,
[SSM-BCP] states that RPs must not accept, originate or forward MSDP [20] states that RPs must not accept, originate or forward MSDP SA
SA messages for the SSM address range [SSM-BCP]. messages for the SSM address range [20].
7. 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.
8. Acknowledgments 9. Acknowledgments
We would like to thank Gene Bowen, Ed Kress, Bryan Lyles and Timothy We would like to thank Gene Bowen, Ed Kress, Bryan Lyles and Timothy
Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, Tony Speakman Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, Tony Speakman
and Nidhi Bhaskar at Cisco Systems for participating in lengthy and Nidhi Bhaskar at Cisco Systems for participating in lengthy
discussions and design work on SSM, and providing feedback on this discussions and design work on SSM, and providing feedback on this
document. Thanks are also due to Mujahid Khan and Ted Seely at document. Thanks are also due to Mujahid Khan and Ted Seely at
SprintLink, Tom Pusateri at Juniper Networks, Bill Fenner at AT&T SprintLink, Tom Pusateri at Juniper Networks, Bill Fenner at AT&T
Research, Kevin Almeroth at the University of California Santa Research, Kevin Almeroth at the University of California Santa
Barbara, Brian Levine at the University of Massachusetts Amherst, Barbara, Brian Levine at the University of Massachusetts Amherst,
Brad Cain at Cereva Networks and Hugh LaMaster at NASA for their Brad Cain at Cereva Networks and Hugh LaMaster at NASA for their
valuable insights and continuing support. valuable insights and continuing support.
9. References: 10. References:
[EXPRESS] H. Holbrook and D.R. Cheriton. IP Multicast Channels : [1] H. Holbrook and D.R. Cheriton, "IP Multicast Channels : EXPRESS
EXPRESS Support for Large-scale Single-Source Applications. In Support for Large-scale Single-Source Applications", In Proceedings
Proceedings of SIGCOMM 1999. of SIGCOMM 1999.
[IANA-ALLOCATION] Internet Assigned Numbers Authority. [2] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. 2236.
[RFC2236] W. Fenner. Internet Group Management Protocol, Version 2. [2] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan, "Internet
Request For Comments 2236. Group Management Protocol, Version 3.", Work in Progress.
[IGMPv3] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan. [4] H. Holbrook and B. Cain, "IGMPv3 for SSM", Work in Progress.
Internet Group Management Protocol, Version 3. Work in Progress.
[SSM-IGMPv3] H. Holbrook and B. Cain. IGMPv3 for SSM. Work in [5] H. Holbrook and B. Cain, "Source-Specific Multicast for
Progress. IP", Work in Progress.
[SSM-ARCH] H. Holbrook and B. Cain. Source-Specific Multicast for [6] S. Deering and D. Cheriton,"Multicast Routing in Datagram
IP. Work in Progress. Networks and Extended LANs", ACM Transactions on Computer Systems,
8(2):85-110, May 1990.
[IPMULTICAST] S. Deering and D. Cheriton. Multicast Routing in [7] S. Deering et al., "PIM Architecture for Wide-Area Multicast
Datagram Networks and Extended LANs. ACM Transactions on Computer Routing", IEEE/ACM Transaction on Networking, pages 153-162, April
Systems, 8(2):85-110, May 1990. 1996.
[PIM-ARCH] S. Deering et al. PIM Architecture for Wide-Area [8] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode
Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162, (PIM-SM) : Protocol Specification", RFC 2362.
April 1996.
[PIM-SM] D. Estrin et al. Protocol Independent Multicast - Sparse [9] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Mode (PIM-SM) : Protocol Specification. Request for Comments 2362. Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", Work In Progress, 2000.
[PIM-SM-NEW] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. [10] S. Deering et al., "Protocol Independent Multicast Version 2
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Dense Mode Specification", Work in Progress.
Specification (Revised)", Work In Progress, 2000. <draft-ietf-pim-
sm-v2-new-01.txt>.
[PIM-DM] S. Deering et al. Protocol Independent Multicast Version 2 [11] A. Ballardie, "Core-Based Trees (CBT) Multicast Routing
Dense Mode Specification. Work in Progress. Architecture", RFC 2201.
[RFC2189] A. Ballardie. Core-Based Trees (CBT Version 2) Multicast [12] D. Meyer, "Adminstratively Scoped IP Multicast", RFC 2365.
Routing -- Protocol Specification. Request for Comments 2189.
[RFC2201] A. Ballardie. Core-Based Trees (CBT) Multicast Routing [13] Farinacci et al., "Multicast Source Discovery Protocol", Work in
Architecture. Request for Comments 2201. Progress.
[RFC2365] D. Meyer. Adminstratively Scoped IP Multicast. Request for [14] M. Handley, D. Thaler and D. Estrin, "The Internet Multicast
Comments 2365. Address Allocation Architecture", Work in Progress.
[MSDP] Farinacci et al. Multicast Source Discovery Protocol. Work in [15] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen,
Progress. "Deployment Issues for the IP Multicast Service and Architecture", In
IEEE Networks Magazine's Special Issue on Multicast, January, 2000.
[MAAA] M. Handley, D. Thaler and D. Estrin. The Internet Multicast [16] H. Sandick and B. Cain, "PIM-SM Rules for Support of Single-
Address Allocation Architecture. Work in Progress (draft-ietf- Source Multicast", Work in Progress.
malloc-arch-**.txt) June 2000.
[MCAST-DEPLOY] C. Diot, B. Levine, B. Lyles, H. Kassem and D. [17] Dave Thaler, Bill Fenner and Bob Quinn, "Socket Interface
Balensiefen. Deployment Issues for the IP Multicast Service and Extensions for Multicast Source Filters", Work in Progress.
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 [18] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", Request
Single-Source Multicast. Work in Progress. For Comments 2770.
[MSF-API] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface [19] B. Levine et al., "Consideration of Receiver Interest for IP
Extensions for Multicast Source Filters. Work in Progress. Multicast Delivery", In Proceedings of IEEE Infocom, March 2000.
[RFC2770] GLOP Addressing in 233/8. Request For Comments 2770. [20] G. Shepherd et al., "Source-Specific Protocol Independent
Multicast in 232/8", Work in Progress.
[RCVR-INTEREST] B. Levine et al. Consideration of Receiver Interest [21] S. Deering, W. Fenner and B. Haberman, "Multicast Listener
for IP Multicast Delivery. In Proceedings of IEEE Infocom, March Discovery for IPv6", RFC 2710.
2000.
[SSM-BCP] G. Shepherd et al. Source-Specific Protocol Independent [22] R. Vida, et. al., "Multicast Listener Discovery Version 2(MLDv2)
Multicast in 232/8. Work in Progress. for IPv6", Work in progress.
[RFC2710] S. Deering, W. Fenner and B. Haberman. Multicast Listener [23] B. Haberman and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast
Discovery for IPv6. Request for Comments 2710. Addresses", Work in Progress.
[MLDv2] R. Vida, et. al. [24] S. Kent, R. Atkinson, "Security Architecture for the Internet
Multicast Listener Discovery Version 2 (MLDv2) for IPv6. Protocol", Request for Comments 2401.
Work in progress.
[SSM-IPv6] B. Haberman and D. Thaler. [25] B. Haberman, "Dynamic Allocation Guidelines for IPv6 Multicast
Unicast-Prefix-Based IPv6 Multicast Addresses. Work in Addresses", Work in Progress.
Progress.
[IPSEC] S. Kent, R. Atkinson. [26] A. Ballardie, "Core-Based Trees (CBT Version 2) Multicast
Security Architecture for the Internet Protocol. Request for Routing -- Protocol Specification", RFC 2189.
Comments 2401.
[IPv6-ALLOC] B. Haberman. [27] S. Deering, "Host Extensions for IP Multicasting", RFC 1112.
Dynamic Allocation Guidelines for IPv6 Multicast Addresses.
Work in Progress. [28] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
2236.
[29] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283.
12. Authors' Address: 12. Authors' Address:
Supratik Bhattacharyya Supratik Bhattacharyya
Christophe Diot Christophe Diot
Sprint Advanced Technology Labs Sprint Advanced Technology Labs
One Adrian Court One Adrian Court
Burlingame CA 94010 USA Burlingame CA 94010 USA
{supratik,cdiot}@sprintlabs.com {supratik,cdiot}@sprintlabs.com
http://www.sprintlabs.com http://www.sprintlabs.com
skipping to change at page 13, line 14 skipping to change at page 13, line 34
Sprint E|Solutions Sprint E|Solutions
Reston Virginia USA Reston Virginia USA
{rrockell,dmm}@sprint.net {rrockell,dmm}@sprint.net
John Meylor John Meylor
Cisco Systems Cisco Systems
San Jose CA USA San Jose CA USA
jmeylor@cisco.com jmeylor@cisco.com
Brian Haberman Brian Haberman
No Affiliation Caspian Networks
haberman@innovationslab.net bkhabs@nc.rr.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/