< draft-ietf-ssm-overview-02.txt   draft-ietf-ssm-overview-03.txt >
INTERNET-DRAFT Supratik Bhattacharyya INTERNET-DRAFT Supratik Bhattacharyya
Expires 04 June 2002 Christophe Diot Expires 04 September 2002 Christophe Diot
Sprint ATL Sprint ATL
Leonard Giuliano Leonard Giuliano
Juniper Networks Juniper Networks
Rob Rockell Rob Rockell
Sprint E|Solutions Sprint E|Solutions
John Meylor John Meylor
Cisco Systems Cisco Systems
David Meyer David Meyer
Sprint E|Solutions Sprint E|Solutions
Greg Shepherd Greg Shepherd
Juniper Networks Juniper Networks
Brian Haberman Brian Haberman
No Affiliation No Affiliation
4 December 2001 04 March 2002
An Overview of Source-Specific Multicast(SSM) Deployment An Overview of Source-Specific Multicast (SSM)
<draft-ietf-ssm-overview-02.txt> <draft-ietf-ssm-overview-03.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 2, line 11 skipping to change at page 2, line 11
The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
Abstract Abstract
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. The IPv4 address range 232/8 has been reserved by IANA fo address S. An IPv4 address range has been reserved by IANA for use
use by the SSM service. An SSM destination address range already by the SSM service. An SSM destination address range already exists
exists for IPv6. A source S transmits IP datagrams to an SSM for IPv6. A source S transmits IP datagrams to an SSM destination
destination address G. A receiver can receive these datagrams by address G. A receiver can receive these datagrams by subscribing to
subscribing to the channel (S,G). Channel subscription is supported the channel (S,G). Channel subscription is supported by version 3 of
by version 3 of the IGMP protocol for IPv4 and version2 of the MLD the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6.
protocol for IPv6. The interdomain tree for forwarding IP multicast The interdomain tree for forwarding IP multicast datagrams is rooted
datagrams is rooted at the source S. Although a number of protocols at the source S, and is constructed using the PIM Sparse Mode [PIM-
exists for constructing source-rooted forwarding trees, this document SM-NEW] protocol.
discusses one of the most widely implemented one - PIM Sparse Mode
[PIM-SM-NEW].
This document is intended as a starting point for deploying SSM This document is not intended to be a standard for Source-Specific
services. It provides an architectural overview of SSM and describes Multicast (SSM). Instead, its goal is to serve as an introduction to
how it solves a number of problems faced in the deployment of inter- SSM and and its benefits for anyone interested in deploying SSM
domain multicast. It outlines changes to protocols and applications services. It provides an overview of SSM and and how it solves a
both at end-hosts and routers for supporting SSM, with pointers to number of problems faced in the deployment of inter-domain multicast.
more detailed documents where appropriate. Issues of interoperability It outlines changes to protocols and applications both at end-hosts
with the multicast service model defined by RFC 1112 are also and routers for supporting SSM, with pointers to more detailed
discussed. documents where appropriate. Issues of interoperability with the
multicast service model defined by RFC 1112 are also discussed.
1. Terminology 1. 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 [RFC1112]. An IP datagram is transmitted to a
"host group", a set of zero or more end-hosts identified by a single "host group", a set of zero or more end-hosts identified by a single
IP destination address (224.0.0.0 through 239.255.255.255 for IPv4). IP destination address (224.0.0.0 through 239.255.255.255 for IPv4).
This model supports one-to-many and and many-to-many multicast groups.
End-hosts may join and leave the group any time, and there is no End-hosts may join and leave the group any time, and there is no
restriction on their location or number. Moreover, any end-host may restriction on their location or number. Moreover, this model supports
multicast groups with arbitrarily many senders - any end-host may
transmit to a host group, even if it is not a member of that group. 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 [SSM-ARCH]. An IP datagram is transmitted by a source S to
an SSM destination address G, and receivers can receive this datagram an SSM destination address G, and receivers can receive this datagram
by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] by subscribing to channel (S,G). SSM provides host applications with a
and supports one-to-many multicast.The address range 232/8 has been "channel" abstraction, in which each channel has exactly one source
assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the and any number of receivers. SSM is derived from earlier work in
range FF3x::/96 is defined for SSM services [SSM-IPv6]. EXPRESS [EXPRESS].The address range 232/8 has been assigned by IANA
[IANA-ALLOC] for SSM service in IPv4. For IPv6, the range FF3x::/96 is
defined for SSM services [SSM-IPv6].
Source-Filtered Multicast (SFM) : This is a variant of the multicast Source-Filtered Multicast (SFM) : This is a variant of the ASM service
service model defined in RFC 1112. A source transmits IP datagrams to model, and uses the same address range as ASM
a host group address in the range of 224.0.0.0 to 239.255.255.255. (224.0.0.0-239.255.255.255). It extends the ASM service model as
However, 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.
Such support for source filtering is provided by version 3 of the Support for source filtering is provided by version 3 of the Internet
Internet Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and version 2
version 2 of the Multicast Listener Discovery (or MLD) protocol for of the Multicast Listener Discovery (or MLDv2) [MLDv2] protocol for
IPv6 [MLDv2]. We shall henceforth refer to these two protocols as IPv6. We shall henceforth refer to these two protocols as "SFM-
"SFM-capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and
MLDv1 - do not provide support for source-filtering, and are referred MLDv1 - do not provide support for source-filtering, and are referred
to as "non-SFM-capable". 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.
2. The IGMP/PIM-SM/MSDP/MBGP Architecture for ASM 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
the number of sources, but only requires that they be located within the
scope zone of the group.
All multicast-capable networks of today support the ASM service 2. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM
model. One of the most common multicast protocol architectures for
supporting ASM in wide-area backbones consists of IGMP version 2
[IGMPv2], PIM-SM [PIM-SM,PIM-SM-NEW], MSDP [MSDP] and MBGP [MBGP]
protocols. To become a member of a particular host group end-hosts
report multicast group membership with querier routers handling
multicast group membership function using the IGMP version 2 (IGMPv2)
protocol [RFC2236] for IPv4 or the MLD version 1 (MLDv1) protocol
[RFC2710] for IPv6. Routers then exchange messages with each other
according to a routing protocol to construct a distribution tree
connecting all the end-hosts. A number of different protocols exist
for building multicast forwarding trees, which differ mainly in the
type of delivery tree constructed [IPMULTICAST,PIM-ARCH, PIM-SM, PIM-
SM-NEW, PIM-DM]. For scalability reasons, sparse-mode protocols
(e.g., PIM-SM) are preferred over dense-mode protocols (e.g., DVMRP,
PIM-DM) for deployment in large backbone networks (though many
smaller networks deploy dense-mode protocols). PIM-SM, most widely
deployed sparse-mode protocol, builds a spanning multicast tree
rooted at a core rendezvous point or RP for all group members within
a single administrative domain. Multicast sources within this domain
send their data to this RP which forwards the data down the shared
tree to interested receivers within the domain. 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. PIM-SM also allows
receivers to switch to a source-based shortest path tree.
An RP uses the MSDP [MSDP] protocol to announce multicast sources to As of this writing, all multicast-capable networks support the ASM
RPs in other domains. When an RP discovers a source in a different service model. One of the most common multicast protocol suites for
domain transmitting data to a multicast group for which there are supporting ASM consists of IGMP version 2 [IGMPv2], PIM-SM [PIM-
interested receivers in its own domain, it joins the shortest-path SM,PIM-SM-NEW], MSDP [MSDP] and MBGP [MBGP] protocols. IGMPv2
source based tree rooted at that source. It then redistributes the [RFC2236] is the most commonly used protocol for hosts to specify
data received to all interested receivers via the intra-domain shared membership in a multicast group, and nearly all multicast routers
tree rooted at itself. support (at least) IGMPv2. In case of IPv6, MLDv1 [RFC2710] is the
commonly used protocol.
Although a number of protocols such as PIM-DM [PIM-DM], CBT
[RFC2189,RFC2201], DVMRP [IPMULTICAST], etc. exist for building
multicast tree among all receivers and sources in the same
administrative domain, PIM-SM [PIM-SM, PIM-SM-NEW] 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 at least one source for a
multicast group is located in a different domain than the receivers)
requires additional protocols - MSDP [MSDP] and MBGP [MBGP] are the
most commonly used ones. An RP uses the MSDP [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.
The MBGP protocol [MBGP] defines extensions to the BGP protocol [BGP] The MBGP protocol [MBGP] defines extensions to the BGP protocol [BGP]
to support the advertisement of reachability information for to support the advertisement of reachability information for
multicast routes. This allows an autonomous system (AS) to support multicast routes. This allows an autonomous system (AS) to support
incongruent unicast and multicast routing topologies, and thus incongruent unicast and multicast routing topologies, and thus
implement separate routing policies for each. implement separate routing policies for each.
3. Problems with Current Architecture 3. 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) Inefficient handling of well-known sources : A) Address Allocation :
In cases where the address of the source is well known in advance
of the receiver joining the group, and when the shortest
forwarding path is the preferred forwarding mode, then shared tree
mechanisms and MSDP are not necessary.
B) Lack of access control :
In the ASM service model, a receiver can not specify which
specific sources it would like to receive when it joins a given
group. A receiver will be forwarded data sent to a host group by
any source.
C) Address Allocation :
Address allocation is one of core deployment challenges posed by 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 more serious for IPv4 than multiple applications. The problem is much less serious for IPv6
IPv6 since the total number of multicast addresses is smaller. A than for IPv4 since the size of the multicast address space is
static address allocation scheme, GLOP [GLOP00] has been proposed much larger. A static address allocation scheme, GLOP [GLOP00]
as an interim solution for IPv4; however, GLOP addresses are has been proposed as an interim solution for IPv4; however, GLOP
allocated per registered AS, which is inadequate in cases where addresses are allocated per registered AS, which is inadequate in
the number of sources exceeds the AS numbers available for cases where the number of sources exceeds the AS numbers available
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 [MAAA] 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 :
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 and MSDP are not necessary.
4. Source Specific Multicast (SSM) : Benefits and Requirements 4. 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 :
4.1 SSM lends itself to an elegant solution to the access control A) Address Allocation : SSM defines channels on a per-source
problem. When a receiver subscribes to an (S,G) channel, it basis, i.e., the channel (S1,G) is distinct from the channel
receives data sent by a only the source S. In contrast, any host (S2,G), where S1 and S2 are source addresses, and G is an SSM
can transmit to an ASM host group. Hence, it is more difficult to destination address. This averts the problem of global allocation
spam an SSM channel than an ASM host group. of SSM destination addresses, and makes each source independently
responsible for resolving address collisions for the various
channels that it creates.
4.2 SSM defines channels on a per-source basis, i.e., the channel B) Access Control : SSM lends itself to an elegant solution to the
(S1,G) is distinct from the channel (S2,G), where S1 and S2 are access control problem. When a receiver subscribes to an (S,G)
source addresses, and G is an SSM destination address. This averts channel, it receives data sent by a only the source S. In
the problem of global allocation of SSM destination addresses, and contrast, any host can transmit to an ASM host group. At the same
makes each source independently responsible for resolving address time, when a sender picks a channel (S,G) to transmit on, it is
collisions for the various channels that it creates. automatically ensured that no other sender will be 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.
4.3 SSM requires only source-based forwarding trees; this C) Handling of well-known sources : SSM requires only source-based
eliminates the need for a shared tree infrastructure. In terms of forwarding trees; this eliminates the need for a shared tree
the IGMP/PIM-SM/MSDP/MBGP protocol suite, this implies that infrastructure. In terms of the IGMP/PIM-SM/MSDP/MBGP protocol
neither the RP-based shared tree infrastructure of PIM-SM nor the suite, this implies that neither the RP-based shared tree
MSDP protocol is required. Thus the complexity of the multicast infrastructure of PIM-SM nor the MSDP protocol is required. Thus
routing infrastructure for SSM is low, making it viable for the complexity of the multicast routing infrastructure for SSM is
immediate deployment. low, making it viable for immediate deployment. Note that MBGP is
still required for distribution of multicast reachability
information.
4.4 It is widely held that point-to-multipoint applications such D) It is widely held that point-to-multipoint applications such as
as Internet TV will dominate the Internet multicast application Internet TV will be important in the near future. The SSM model is
space in the near future. The SSM model is ideally suited for such ideally suited for such applications.
applications.
5. SSM Framework 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::/12 for IPv6
-------------------------------------------------------------- --------------------------------------------------------------
skipping to change at page 6, line 46 skipping to change at page 7, line 22
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 5.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 prevent data sent to policies are being proposed [SSM-BCP] which recommend that routers
232/8 from being delivered to parts of the network that do not have should not send SSM traffic to parts of the network that do not have
channel subscribers. channel 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 guaranteed range. However, SSM service, as defined in [SSM-ARCH], is available
only in this address range for IPv4. only in this address range for IPv4.
In case of IPv6, [HABE1] has defined an extension to the addressing In case of IPv6, [HABE1] 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.
In this case, bytes 0-3 (starting from the least significant byte) of Bytes 0-3 (starting from the least significant byte) of the IP
the IP address is used to specify a multicast group id, bytes 4-11 is address are used to specify a multicast group id, bytes 4-11 are used
be used to specify a unicast address prefix (of up to 64 bits) that to specify a unicast address prefix (of up to 64 bits) that owns this
owns this multicast group id, and byte 12 is used to specify the multicast group id, and byte 12 is used to specify the length of the
length of the prefix. A source-specific multicast address can be prefix. A source-specific multicast address is specified by setting
specified by setting both the prefix length field and the prefix both the prefix length field and the prefix field to zero.
field to zero.
5.2 Session Description and Channel Discovery 5.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. Thus the function of channel discovery becomes the channel. Channel discovery is the responsibility of applications.
responsibility of applications. This information can be made This information can be made available in a number of ways,
available in a number of ways, including via web pages, sessions including via web pages, sessions announcement applications, etc.
announcement applications, etc. The exact mechanisms for doing This is similar to what is used for ASM applications where a
this is outside the scope of this framework document. multicast session needs to be announced so that potential
subscribers can know of the multicast group adddres, encoding
schemes used, etc. In fact, the only additional piece of
information that needs to be announced is the source address for
the channel being advertised. However, the exact mechanisms for
doing this is outside the scope of this framework document.
5.3. SSM-Aware Applications 5.3. SSM-Aware Applications
-- For applications sourcing content via SSM channels, the session -- An application that wants to received an SSM session must first
must be advertised including a source address as well as an SSM discover the channel address in use. Any of the mechanisms
address. described in Section 5.2 can be used for this purpose.
-- Applications expecting to subscribe to an SSM channel must be -- A receiving application must be able to specify both a source
capable of specifying a source address in addition to an SSM address and a destination address to the network layer protocol
destination address. In other words, the application must be "SSM- module on the end-host. In other words, the application must be
aware". "SSM-aware".
Specific API requirements are identified in [THAL00]. Specific API requirements are identified in [THAL00]. [THAL00]
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.
5.4. IGMPv3/MLDv2 Host Reporting and Querier 5.4. IGMPv3/MLDv2 Host Reporting and Querier
IGMP version 2 [IGMPv2] allows end-hosts to report their interest In order to use SSM service, an end-host must be able to specify a
in a multicast group by specifying a class-D IP address for IPv4. channel address, consisting of a source's unicast address and an
However in order to implement the SSM service model, an end-host SSM destination address. IGMP version 2 [IGMPv2] and MLD version 1
must specify a source's unicast address as well as an SSM [MLDv1] allows an end-host to specify only a destination multicast
destination address. This capability is provided by IGMP version 3 address. The ability to specify an SSM channel address c is
[IGMPv3]. IGMPv3 supports "source filtering", i.e., the ability of provided by IGMP version 3 [IGMPv3] and MLD version 2 [MLDv2].
These protocols support "source filtering", i.e., the ability of
an end-system to express interest in receiving data packets sent an end-system to express interest in receiving data packets sent
only by SPECIFIC sources, or from ALL BUT some specific sources. only by SPECIFIC sources, or from ALL BUT some specific sources.
Thus, IGMPv3 provides a superset of the capabilities required to In fact, IGMPv3 provides a superset of the capabilities required
realize the SSM service model. to realize the SSM service model.
There are a number of backward compatibility issues between IGMP A detailed discussion of the use of IGMPv3 in the SSM destination
versions 2 and 3 which have to be addressed. A detailed discussion address range is provided in [SSM-IGMPv3].
of the use of IGMPv3 in the SSM destination address range is
provided in [SSM-IGMPv3].
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 allows a multicast listener [DEER99] is derived from IGMPv2 and does not provide the source
to specify the multicast group(s) that it is interested in. filtering capability required for the SSM service model. Version 2
Version 2 of MLD [VIDA01] is derived from, and provides the same of MLD [VIDA01] is derived from, and provides the same support for
support for source-filtering as, IGMPv3. 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.
5.5. PIM-SSM Routing 5.5. PIM-SSM Routing
PIM-SM [PIM-SM-NEW] itself supports two types of trees, a shared tree [PIM-SM-NEW] provides guideliness for how a PIM-SM implementation
rooted at a core (RP), and a source-based shortest path tree. Thus should handle source-specific host reports as required by SSM.
PIM-SM already supports source-based trees. The original Earlier versions of the PIM protocol specifications did not describe
PIM-SM [PIM-SM] did not allow a router to choose between a shared how to do this.
tree and a source-based tree. In fact, a receiver always joined a PIM
shared tree to start with, and may later be switched to a per-source
tree by its adjacent edge router. However, the more recent PIM-SM
specification [PIM-SM-NEW] has support for source-specific join.
Supporting SSM with PIM-SM involves several changes to PIM-SM as The router requirements for operation in the SSM range are detailed
described in [PIM-SM-NEW]. The resulting PIM functionality is in [SSM-ARCH]. These rules are primarily concerned with preventing
described as PIM-SSM. The specific architectural issues associated ASM-style behaviour in the SSM address range. In order to comply with
with PIM-SSM and IGMPv3/MLDv2 are detailed in [SSM-ARCH]. The most [SSM-ARCH] several changes to the PIM-SM protocol are required, as
important changes to PIM-SM with respect to SSM are as follows: described in [PIM-SM-NEW].The most important changes in PIM-SM
required for compliance with [SSM-ARCH] 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
functionality is needed to support the SSM service model. This subset
is explicitly documented in [PIM-SM-NEW].
6. Interoperability with Existing Multicast Service Models 6. 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. ASM and SSM will always coexist; hence moving to SSM deployment, since both models are expected to be used
there will be two service models for Internet multicast. SSM is the at least in the foreseeable future. SSM is the ONLY service model for
ONLY service model for the SSM address range - the correct protocol the SSM address range - the correct protocol behaviour for this range
behaviour for this range is specified in [SSM-ARCH]. The ASM service is specified in [SSM-ARCH]. The ASM service model will be offered for
model will be offered for the non-SSM adddress range, where receivers the non-SSM adddress range, where receivers can issue (*,G) join
can issue (*,G) join requests to receive multicast data. A receiver requests to receive multicast data. A receiver is also allowed to
is also allowed to issue an (S,G) join request in the non-SSM address issue an (S,G) join request in the non-SSM address range; however, in
range; however, in that case there is no guarantee that it will that case there is no guarantee that it will receive service
receive service according to the SSM model. according to the SSM model.
Another backward compatibility issue concerns the MSDP protocol, Another interoperability issue concerns the MSDP protocol, which is
which is used between PIM-SM rendezvous points (RPs) to discover used between PIM-SM rendezvous points (RPs) to discover multicast
multicast sources across multiple domains. SSM obviates the needs for sources across multiple domains. MSDP is not needed for SSM, but is
MSDP, but MSDP is still required to support ASM for non-SSM class-D needed if ASM is supported. [SSM-BCP] specifies operational
IPv4 addresses. In order to ensure that SSM is the sole forwarding recommendations to help ensure that MSDP does not interfere with the
model in 232/8, RPs must not accept, originate or forward MSDP SA ability of a network to support the SSM service model. Specifically,
messages for the SSM address range [SSM-BCP]. [SSM-BCP] states that RPs must not accept, originate or forward MSDP
SA messages for the SSM address range [SSM-BCP].
7. Security Considerations 7. 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 8. Acknowledgments
We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Sue Moon We would like to thank Gene Bowen, Ed Kress, Bryan Lyles and Timothy
and Timothy Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, Tony Speakman
Tony Speakman and Nidhi Bhaskar at Cisco Systems for participating in and Nidhi Bhaskar at Cisco Systems for participating in lengthy
lengthy discussions and design work on SSM, and providing feedback on discussions and design work on SSM, and providing feedback on this
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: 9. References:
[EXPRESS] H. Holbrook and D.R. Cheriton. IP Multicast Channels : [EXPRESS] H. Holbrook and D.R. Cheriton. IP Multicast Channels :
EXPRESS Support for Large-scale Single-Source Applications. In EXPRESS Support for Large-scale Single-Source Applications. In
skipping to change at page 10, line 35 skipping to change at page 11, line 17
[IPMULTICAST] S. Deering and D. Cheriton. Multicast Routing in [IPMULTICAST] S. Deering and D. Cheriton. Multicast Routing in
Datagram Networks and Extended LANs. ACM Transactions on Computer Datagram Networks and Extended LANs. ACM Transactions on Computer
Systems, 8(2):85-110, May 1990. Systems, 8(2):85-110, May 1990.
[PIM-ARCH] S. Deering et al. PIM Architecture for Wide-Area [PIM-ARCH] S. Deering et al. PIM Architecture for Wide-Area
Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162, Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162,
April 1996. April 1996.
[PIM-SM] D. Estrin et al. Protocol Independent Multicast - Sparse [PIM-SM] D. Estrin et al. Protocol Independent Multicast - Sparse
Mode (PIM-SM) : Protocol Specification. Request for Comments, 2362. Mode (PIM-SM) : Protocol Specification. Request for Comments 2362.
[PIM-SM-NEW] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. [PIM-SM-NEW] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas.
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work In Progress, 2000. <draft-ietf-pim- Specification (Revised)", Work In Progress, 2000. <draft-ietf-pim-
sm-v2-new-01.txt>. sm-v2-new-01.txt>.
[PIM-DM] S. Deering et al. Protocol Independent Multicast Version 2 [PIM-DM] S. Deering et al. Protocol Independent Multicast Version 2
Dense Mode Specification. Work in Progress. Dense Mode Specification. Work in Progress.
[RFC2189] A. Ballardie. Core-Based Trees (CBT Version 2) Multicast
Routing -- Protocol Specification. Request for Comments 2189.
[RFC2201] A. Ballardie. Core-Based Trees (CBT) Multicast Routing
Architecture. Request for Comments 2201.
[RFC2365] D. Meyer. Adminstratively Scoped IP Multicast. Request for
Comments 2365.
[MSDP] Farinacci et al. Multicast Source Discovery Protocol. Work in [MSDP] Farinacci et al. Multicast Source Discovery Protocol. Work in
Progress. Progress.
[MAAA] M. Handley, D. Thaler and D. Estrin. The Internet Multicast [MAAA] M. Handley, D. Thaler and D. Estrin. The Internet Multicast
Address Allocation Architecture. Work in Progress (draft-ietf- Address Allocation Architecture. Work in Progress (draft-ietf-
malloc-arch-**.txt) June 2000. malloc-arch-**.txt) June 2000.
[MCAST-DEPLOY] C. Diot, B. Levine, B. Lyles, H. Kassem and D. [MCAST-DEPLOY] C. Diot, B. Levine, B. Lyles, H. Kassem and D.
Balensiefen. Deployment Issues for the IP Multicast Service and Balensiefen. Deployment Issues for the IP Multicast Service and
Architecture. In IEEE Networks Magazine's Special Issue on Architecture. In IEEE Networks Magazine's Special Issue on
Multicast, January, 2000. Multicast, January, 2000.
[SSM-RULES] H. Sandick and B. Cain. PIM-SM Rules for Support of [SSM-RULES] H. Sandick and B. Cain. PIM-SM Rules for Support of
Single-Source Multicast. Work in Progress. Single-Source Multicast. Work in Progress.
[MSF-API] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface [MSF-API] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface
Extensions for Multicast Source Filters. Work in Progress. Extensions for Multicast Source Filters. Work in Progress.
 End of changes. 41 change blocks. 
192 lines changed or deleted 231 lines changed or added

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