draft-ietf-ssm-overview-00.txt   draft-ietf-ssm-overview-01.txt 
INTERNET-DRAFT Supratik Bhattacharyya INTERNET-DRAFT Supratik Bhattacharyya
Expires 18 November 2001 Christophe Diot Expires 18 February 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
Dave Meyer
Cisco Systems Cisco Systems
David Meyer
Sprint E|Solutions
Greg Shepherd Greg Shepherd
Juniper Networks Juniper Networks
Brian Haberman Brian Haberman
Nortel Networks Nortel Networks
18 May 2001 18 August 2001
An Overview of Source-Specific Multicast(SSM) Deployment An Overview of Source-Specific Multicast(SSM) Deployment
<draft-ietf-ssm-overview-00.txt> <draft-ietf-ssm-overview-01.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 IP address range 232/8 has been designated as SSM address S. The IPv4 address range 232/8 has been reserved by IANA fo
addresses by IANA for IPv4. An SSM address range already exists for use by the SSM service. An SSM destination address range already
IPv6. A source S transmits IP datagrams to an SSM address G. A exists for IPv6. A source S transmits IP datagrams to an SSM
receiver can receive these datagrams by subscribing to the channel destination address G. A receiver can receive these datagrams by
(S,G). Channel subscription is supported by version 3 of the IGMP subscribing to the channel (S,G). Channel subscription is supported
protocol for IPv4 and version2 of the MLD protocol for IPv6. The by version 3 of the IGMP protocol for IPv4 and version2 of the MLD
interdomain tree for forwarding UDP datagrams is rooted at the source protocol for IPv6. The interdomain tree for forwarding IP multicast
S. Although a number of protocols exists for constructing source- datagrams is rooted at the source S. Although a number of protocols
rooted forwarding trees, this document discusses the most widely exists for constructing source-rooted forwarding trees, this document
implemented one - PIM Sparse Mode [PIM-SM-NEW]. 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 intended as a starting point for deploying SSM
services. It provides an architectural overview of SSM and describes services. It provides an architectural overview of SSM and describes
how it solves a number of problems faced in the deployment of inter- how it solves a number of problems faced in the deployment of inter-
domain multicast. It outlines changes to protocols and applications domain multicast. It outlines changes to protocols and applications
both at end-hosts and routers for supporting SSM, with pointers to both at end-hosts and routers for supporting SSM, with pointers to
more detailed documents where appropriate. Issues of interoperability more detailed documents where appropriate. Issues of interoperability
with the existing multicast service model (as defined by RFC 1112) with the multicast service model defined by RFC 1112 are also
are also discussed. 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 hosts identified by a single IP "host group", a set of zero or more end-hosts identified by a single
destination address (224.0.0.0 through 239.255.255.255 for IPv4). This IP destination address (224.0.0.0 through 239.255.255.255 for IPv4).
model supports one-to-many and and many-to-many multicast groups. This model supports one-to-many and and many-to-many multicast groups.
Hosts may join and leave the group any time. There is no restriction End-hosts may join and leave the group any time, and there is no
on the location or number of receivers, and a source need not be a restriction on their location or number. Moreover, any end-host may
member of the host group it transmits to. 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 address G, and receivers can receive this datagram by an SSM destination address G, and receivers can receive this datagram
subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS]
and supports one-to-many multicast.The address range 232/8 has been and supports one-to-many multicast.The address range 232/8 has been
assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the
range FF2::/11 through FF3x::/11 is defined for SSM services [SSM- range FF3x::/12 is defined for SSM services [SSM-IPV6].
IPV6].
Source-Filtered Multicast (SFM) : This is a variant of the multicast Source-Filtered Multicast (SFM) : This is a variant of the multicast
service model defined in RFC 1112. A source transmits IP datagrams to service model defined in RFC 1112. A source transmits IP datagrams to
a host group address in the range of 224.0.0.0 to 239.255.255.255. a host group address in the range of 224.0.0.0 to 239.255.255.255.
However, each "upper layer protocol module" can now request data sent However, each "upper layer protocol module" can now request data sent
to a host group G by only a specific set of sources, or can request to a host group G by only a specific set of sources, or can request
data sent to host group G from all BUT a specific set of sources. Such 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 Such support for source filtering is provided by version 3 of the
Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and version 2 Internet Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and
of the Multicast Listener Discovery (or MLD) protocol for IPv6 version 2 of the Multicast Listener Discovery (or MLD) protocol for
[MLDv2]. We shall henceforth refer to these two protocols as "SFM- IPv6 [MLDv2]. We shall henceforth refer to these two protocols as
capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and "SFM-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".
2. Current Interdomain Multicast Architecture 2. The IGMP/PIM-SM/MSDP/MBGP Architecture for ASM
The current interdomain multicast architecture is based on the ASM
service model. To become a member of a particular host group end-
hosts register multicast group membership with querier routers
handling multicast group membership function using the IGMP version 2
(IGMPv2) protocol [RFC2236] for IPv4 or the MLD version 1 (MLDv1)
protocol [RFC2710] for IPv6. These protocols are non-SFM-capable,
hence source-filtering capabilities are unavailable to receivers.
Multicast-capable routers then exchange messages with each other All multicast-capable networks of today support the ASM service
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 according to a routing protocol to construct a distribution tree
connecting all the end-hosts. A number of different protocols exist connecting all the end-hosts. A number of different protocols exist
for building multicast forwarding trees, which differ mainly in the for building multicast forwarding trees, which differ mainly in the
type of delivery tree constructed [IPMULTICAST,PIM-ARCH, RFC2362, type of delivery tree constructed [IPMULTICAST,PIM-ARCH, PIM-SM, PIM-
PIM-SM-NEW, PIM-DM]. Of these, the Protocol Independent Multicast SM-NEW, PIM-DM]. For scalability reasons, sparse-mode protocols
Sparse-Mode (PIM-SM) protocol [PIM-SM-NEW] is the most widely (e.g., PIM-SM) are preferred over dense-mode protocols (e.g., DVMRP,
deployed in today's public networks. PIM-SM, by default, constructs a PIM-DM) for deployment in large backbone networks (though many
single spanning multicast tree rooted at a core rendezvous point or smaller networks deploy dense-mode protocols). PIM-SM, most widely
RP for all group members within a domain. Local sources then send deployed sparse-mode protocol, builds a spanning multicast tree
their data to this RP which forwards the data down the shared tree to rooted at a core rendezvous point or RP for all group members within
interested local receivers. A receiver joining a host group can only a single administrative domain. Multicast sources within this domain
specify interest in the entire group and therefore will receive data send their data to this RP which forwards the data down the shared
for any source to this group forwarded on the shared tree. tree to interested receivers within the domain. As of this writing,
Distribution via a shared tree can be effective for certain types of multicast end-hosts with SFM capabilities are not widely available.
traffic, e.g., where the number of sources is large since forwarding Hence a client can only specify interest in an entire host group and
on the shared tree is performed via a single multicast forwarding receives data sent from any source to this group. PIM-SM also allows
entry. However, there are many cases (e.g., Internet broadcast type receivers to switch to a source-based shortest path tree.
streams) where forwarding from a source to a receiver is most
efficient via the shortest path. PIM-SM also allows a designated
router serving a particular subnet to switch to a source-based
shortest path tree for a given source once the source's address is
learned from data arriving on the shared tree. This capability
provides for distribution of data from local sources to local
receivers both sharing a common RP inside a given PIM domain.
It is also possible for RP's to learn about sources in other PIM An RP uses the MSDP [MSDP] protocol to announce multicast sources to
domains by using the Multicast Source Discovery Protocol (MSDP) RPs in other domains. When an RP discovers a source in a different
[MSDP]. Once an active remote source is identified, an RP can join domain transmitting data to a multicast group for which there are
the shortest path tree to that source and obtain data to forward down interested receivers in its own domain, it joins the shortest-path
the local shared tree on behalf of interested local receivers. source based tree rooted at that source. It then redistributes the
Designated routers for particular subnets can again switch to a data received to all interested receivers via the intra-domain shared
source-based shortest path tree for a given remote source once the tree rooted at itself.
source's address is learned from data arriving on the shared tree.
The IGMPv2/PIM-SM/MSDP-based interdomain multicast architecture is The MBGP protocol [MBGP] defines extensions to the BGP protocol [BGP]
widely deployed in IPv4 networks and can be particularly effective to support the advertisement of reachability information for
for groups where sources are not known in advance by hosts joining a multicast routes. This allows an autonomous system (AS) to support
group, or when sources come and go dynamically, or when forwarding on incongruent unicast and multicast routing topologies, and thus
a common shared tree is found to be operationally beneficial. 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) 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 only are not necessary. mechanisms and MSDP are not necessary.
B) Lack of access control : B) Lack of access control :
In the ASM service model, a receiver can not specify which In the ASM service model, a receiver can not 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. any source.
C) Address Allocation : 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 an adequate 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 more serious for IPv4 than
IPv6 since the total number of multicast addresses is smaller. A IPv6 since the total number of multicast addresses is smaller. A
static address allocation scheme, GLOP [GLOP00] has been proposed static address allocation scheme, GLOP [GLOP00] has been proposed
as an interim solution for IPv4; however, GLOP addresses are as an interim solution for IPv4; however, GLOP addresses are
allocated per registered AS, which is inadequate in cases where allocated per registered AS, which is inadequate in cases where
the number of sources exceeds the AS numbers available for the number of sources exceeds the AS numbers available for
mapping. Proposed longer-term solutions such as the Multicast 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. However, the address allocation) for widespread deployment.
unicast-prefix-based multicast architecture of IPv6 [HABE1]
expands on the GLOP approach, simplifies the multicast address
allocation solution and incorporates support for source-specific
multicast addresses.
4. Source Specific Multicast (SSM) : Benefits and Requirements 4. Source Specific Multicast (SSM) : Benefits and Requirements
As mentioned before, Source Specific Multicast (SSM) defines a As mentioned before, the Source Specific Multicast (SSM) service
service model for a "channel" identified by an (S,G) pair, where S is model defines a "channel" identified by an (S,G) pair, where S is a
a source address and G is an SSM address. This model can be realized source address and G is an SSM destination address. Channel
by a protocol architecture, where packet forwarding is restricted to
shortest path trees rooted at specific sources, and channel
subscriptions are described using an SFM-capable group management subscriptions are described using an SFM-capable group management
protocol such as IGMPv3 or MLDv2. protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees
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 4.1 SSM lends itself to an elegant solution to the access control
problem. Only a single source S can transmit to a channel (S,G) problem. When a receiver subscribes to an (S,G) channel, it
where G is an SSM address. This makes it significantly more receives data sent by a only the source S. In contrast, any host
difficult to spam an SSM channel than an ASM host group. In can transmit to an ASM host group. Hence, it is more difficult to
addition, data from unrequested sources need not be forwarded by spam an SSM channel than an ASM host group.
the network, which prevents unnecessary consumption of network
resources.
4.2 SSM defines channels on a per-source basis; hence SSM 4.2 SSM defines channels on a per-source basis, i.e., the channel
addresses are "local" to each source. This averts the problem of (S1,G) is distinct from the channel (S2,G), where S1 and S2 are
global allocation of SSM addresses, and makes each source source addresses, and G is an SSM destination address. This averts
independently responsible for resolving address collisions for the the problem of global allocation of SSM destination addresses, and
various channels that it creates. makes each source independently responsible for resolving address
collisions for the various channels that it creates.
4.3 The distribution tree for an SSM channel (S,G) is always 4.3 SSM requires only source-based forwarding trees; this
rooted at the source S. Thus there is no need for a shared tree eliminates the need for a shared tree infrastructure. In terms of
infrastructure. In terms of the IGMPv2/PIM-SM/MSDP architecture, the IGMP/PIM-SM/MSDP/MBGP protocol suite, this implies that
this implies that neither the RP-based shared tree infrastructure neither the RP-based shared tree infrastructure of PIM-SM nor the
of PIM-SM nor the MSDP protocol is required. Thus the complexity MSDP protocol is required. Thus the complexity of the multicast
of the multicast routing infrastructure for SSM is low, making it routing infrastructure for SSM is low, making it viable for
viable for immediate deployment and more efficient for well-known immediate deployment.
sources.
4.4 It is widely held that point-to-multipoint applications such 4.4 It is widely held that point-to-multipoint applications such
as Internet TV will dominate the Internet multicast application as Internet TV will dominate the Internet multicast application
space in the near future. The SSM model is ideally suited for such space in the near future. The SSM model is ideally suited for such
applications. applications.
A protocol architecture for SSM requires the following :
A) Source specific host membership reports : A SFM-capable
protocol is needed to allow a host to describe specific sources
from which it would like to receive data.
B) Shortest path forwarding. DR's must be capable of recognizing
receiver-initiated, source specific host reports and initiating
(S,G) joins directly and immediately as result.
C) Elimination of shared tree forwarding. In order to achieve
global effectiveness of SSM, all networks must agree to restrict
data forwarding to source trees (i.e., prevent shared tree
forwarding) for SSM addresses. The address range 232/8 has been
allocated by IANA for deploying source-specific IPv4 multicast
(SSM) services. In this range, SSM is the sole service model. For
IPv6, a source-specific multicast address range has been defined
in [HABE1], as a special case of unicast prefix-based multicast
addresses.
5. SSM Framework 5. SSM Framework
Figure 1 illustrates the elements in an end-to-end SSM framework. Figure 1 illustrates the elements in an end-to-end implementation
framework for SSM :
-------------------------------------------------------------- --------------------------------------------------------------
IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION
SSM range exists for IPv6 FF3x::/12 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
| SSM-aware app | CHANNEL DISCOVERY | SSM-aware app | CHANNEL DISCOVERY
-------------------------------------------------------------- --------------------------------------------------------------
| SSM-aware app | SSM-AWARE APPLICATION | SSM-aware app | SSM-AWARE APPLICATION
-------------------------------------------------------------- --------------------------------------------------------------
| IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING | IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING
+---------------+ +-----------------+
|(source specific host report) |(source specific host report)
|
-------------------------------------------------------------- --------------------------------------------------------------
v v
+-----------------+ Querier Router +-----------------+ Querier Router
| IGMPv3/MLDv2 | QUERIER | IGMPv3/MLDv2 | QUERIER
-------------------------------------------------------------- --------------------------------------------------------------
| PIM-SSM | PIM-SSM ROUTING | PIM-SSM | PIM-SSM ROUTING
+------------+ Designated Router +------------+ Designated Router
| |
| (S,G) Join only | (S,G) Join only
v v
+-----------+ Core Router +-----------+ Backbone Router
| 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 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. Sessions expecting SSM functionality MUST allocate addresses SSM. To ensure global SSM functionality in 232/8, including in
from the 232/8 range. To ensure global SSM functionality in 232/8, networks where routers run non-SFM-capable protocols, operational
including in networks where routers run non-SFM-capable protocols, policies are being proposed [SSM-BCP] which prevent data sent to
operational policies are being proposed [SSM-BCP] which prevent data 232/8 from being delivered to parts of the network that do not have
sent to 232/8 from being delivered via shared trees. channel subscribers.
Note that it is possible to achieve the benefit of direct and Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8
immediate (S,G) joins in response to IGMPv3 reports in other ranges range. However, SSM service, as defined in [SSM-ARCH], is available
than 232/8.However, non-SSM address ranges allow for concurrent use only in this address range for IPv4.
of both the ASM and SSM service models. Therefore, while we can
achieve the PIM join efficiency in the non-SSM address range with
IGMPv3, it is not possible to prevent the creation of shared trees or
shared tree data delivery, and thus cannot provide for certain types
of access control or assume per-source unrestricted address use as
with the SSM address range.
In case of IPv6, [HABE1] has defined an extension to the addressing 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 In this case, bytes 0-3 (starting from the least significant byte) of
the IP address is used to specify a multicast group id, bytes 4-11 is the IP address is used to specify a multicast group id, bytes 4-11 is
be used to specify a unicast address prefix (of up to 64 bits) that be used to specify a unicast address prefix (of up to 64 bits) that
owns this multicast group id, and byte 12 is used to specify the owns this multicast group id, and byte 12 is used to specify the
length of the prefix. A source-specific multicast address can be length of the prefix. A source-specific multicast address can be
specified by setting both the prefix length field and the prefix specified by setting both the prefix length field and the prefix
field to zero. Thus IPv6 allows for 2^32 SSM addresses per scope for field to zero.
every source, while IPv4 allows 2^24 addresses per source.
5.2 Channel Discovery
In case of ASM, receivers need to know only the group address for 5.2 Session Description and Channel Discovery
a specific session. In the IGMPv2/PIM-SM/MSDP architecture,
designated routers discover an active source via PIM-SM and MSDP,
and then graft themselves to the multicast forwarding tree rooted
at that source.
In case of the SSM, an application on an end-host must know both An SSM receiver application must know both the SSM destination
the SSM 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. Thus the function of channel discovery becomes the
responsibility of applications. This information can be made responsibility of applications. This information can be made
available in a number of ways, including via web pages, sessions available in a number of ways, including via web pages, sessions
announcement applications, etc. The exact mechanisms for doing announcement applications, etc. The exact mechanisms for doing
this is outside the scope of this framework document. this is outside the scope of this framework document.
5.3. SSM-Aware Applications 5.3. SSM-Aware Applications
-- For applications sourcing content expected to be available to -- For applications sourcing content via SSM channels, the session
receivers via SSM channels, the session must be advertised must be advertised including a source address as well as an SSM
including a source address as well as an SSM address. address.
-- Applications expecting to subscribe to an SSM channel must be -- Applications expecting to subscribe to an SSM channel must be
capable of specifying a source address in addition to an SSM capable of specifying a source address in addition to an SSM
address. In other words, the application must be "SSM-aware". destination address. In other words, the application must be "SSM-
aware".
Specific API requirements are identified in [THAL00]. Specific API requirements are identified in [THAL00].
5.4. IGMPv3 for SSM 5.4. IGMPv3/MLDv2 Host Reporting and Querier
The currently deployed version of IGMP (IGMPv2) allows end-hosts
to register their interest in a multicast group by specifying a
class-D IP address for IPv4. However in order to implement the SSM
service model, an end-host must specify a source's unicast address
as well as an SSM address. This capability is provided by the
recently proposed IGMP version 3 (IGMPv3). IGMPv3 supports "source
filtering", i.e., the ability of an end-system to express interest
in receiving data packets sent only by SPECIFIC sources, or from
ALL BUT some specific sources. Thus, IGMPv3 provides a superset of
the capabilities required to realize the SSM service model. Hence
an upgrade from IGMPv2 to IGMPv3 is an essential change for
implementing SSM.
IGMPv3 requires the API to provide the following operation (or its
logical equivalent) [CAIN99]:
IPMulticastListen (Socket, IF, G, filter-mode, source-list)
As explained in the IGMPv3 specifications [CAIN99], the above
IPMulticastListen() operation subsumes the group-specific join and
leave operations of IGMPv2. Performing (S,G)-specific joins and
leaves is also trivial. A join operation is equivalent to :
IPMulticastListen (Socket,IF,G,INCLUDE,{S})
and a leave operation is equivalent to
IPMulticastListen (Socket,IF,G,EXCLUDE,{S}) IGMP version 2 [IGMPv2] allows end-hosts to report their interest
in a multicast group by specifying a class-D IP address for IPv4.
However in order to implement the SSM service model, an end-host
must specify a source's unicast address as well as an SSM
destination address. This capability is provided by IGMP version 3
[IGMPv3]. IGMPv3 supports "source filtering", i.e., the ability of
an end-system to express interest in receiving data packets sent
only by SPECIFIC sources, or from ALL BUT some specific sources.
Thus, IGMPv3 provides a superset of the capabilities required to
realize the SSM service model.
There are a number of backward compatibility issues between IGMP There are a number of backward compatibility issues between IGMP
versions 2 and 3 which have to be addressed. There are also some versions 2 and 3 which have to be addressed. A detailed discussion
additional requirements for using IGMPv3 for the SSM address of the use of IGMPv3 in the SSM destination address range is
range. A detailed discussion of these issues is provided in [SSM- provided in [SSM-IGMPv3].
IGMPv3].
5.5 MLDv2 for SSM
The Multicast Listener Discovery (MLD) protocol used by an IPv6 router The Multicast Listener Discovery (MLD) protocol used by an IPv6
to discover the presence of multicast listeners on its directly attached router to discover the presence of multicast listeners on its
links, and to discover the multicast addresses that are of interest to directly attached links, and to discover the multicast addresses
those neighboring nodes. Version 1 of MLD [DEER99] is derived from that are of interest to those neighboring nodes. Version 1 of MLD
IGMPv2 and allows a multicast listener to specify the multicast group(s) [DEER99] is derived from IGMPv2 and allows a multicast listener
that it is interested in. Version 2 of MLD [VIDA01] is derived from, and to specify the multicast group(s) that it is interested in.
provides the same support for source-filtering as, IGMPv3. Version 2 of MLD [VIDA01] is derived from, and provides the same
support for source-filtering as, IGMPv3.
5.6. PIM-SM Modifications for SSM 5.5. PIM-SSM Routing
PIM-SM [PIM-SM-NEW] itself supports two types of trees, a shared tree PIM-SM [PIM-SM-NEW] itself supports two types of trees, a shared tree
rooted at a core (RP), and a source-based shortest path tree. Thus rooted at a core (RP), and a source-based shortest path tree. Thus
PIM-SM already supports source-based trees; however, PIM-SM is not PIM-SM already supports source-based trees. The original
designed to allow a router to choose between a shared tree and a PIM-SM [PIM-SM] did not allow a router to choose between a shared
source-based tree. In fact, a receiver always joins a PIM shared tree tree and a source-based tree. In fact, a receiver always joined a PIM
to start with, and may later be switched to a per-source tree by its shared tree to start with, and may later be switched to a per-source
adjacent edge router. tree by its adjacent edge router. However, the more recent PIM-SM
specification [PIM-SM-NEW] has support for source-specific join.
A key to implementing SSM is eliminate the need for starting with a Supporting SSM with PIM-SM involves several changes to PIM-SM as
shared tree and then switching to a source-specific tree. This described in [PIM-SM-NEW]. The resulting PIM functionality is
involves several changes to PIM-SM as described in [PIM-SM-NEW]. The described as PIM-SSM. The specific architectural issues associated
resulting PIM functionality is described as PIM-SSM. The most with PIM-SSM and IGMPv3/MLDv2 are detailed in [SSM-ARCH]. The most
important changes to PIM-SM with respect to SSM are as follows: important changes to PIM-SM with respect to SSM are as follows:
-- When a DR receives an (S,G) join request with the address G in -- 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.
--Core routers (i.e. routers that do not have directly attached --Backbone routers (i.e. routers that do not have directly
hosts) must not propagate (*,G) joins for group addresses in the attached hosts) must not propagate (*,G) joins for group addresses
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.
The specific architectural issues associated with PIM-SSM and
IGMPv3/MLDv2 are detailed in [SSM-ARCH].
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. ASM and SSM will always coexist; hence
there will be two service models for Internet multicast. SSM is the there will be two service models for Internet multicast. SSM is the
ONLY service model for the SSM address range (232/8 for IPv4 and ONLY service model for the SSM address range - the correct protocol
FF::/8 for IPv6) - the correct protocol behaviour for this range is behaviour for this range is specified in [SSM-ARCH]. The ASM service
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 backward compatibility issue concerns the MSDP protocol,
which is used between PIM-SM rendezvous points (RPs) to discover which is used between PIM-SM rendezvous points (RPs) to discover
multicast sources across multiple domains. SSM obviates the needs for multicast sources across multiple domains. SSM obviates the needs for
MSDP, but MSDP is still required to support ASM for non-SSM class-D MSDP, but MSDP is still required to support ASM for non-SSM class-D
IPv4 addresses. In order to ensure that SSM is the sole forwarding IPv4 addresses. In order to ensure that SSM is the sole forwarding
model in 232/8, RPs must not accept, originate or forward MSDP SA model in 232/8, RPs must not accept, originate or forward MSDP SA
messages for the SSM address range [SSM-BCP]. messages for the SSM address range [SSM-BCP].
7. Security Considerations 7. Security Considerations
skipping to change at page 12, line 7 skipping to change at page 10, line 34
IP. Work in Progress. IP. Work in Progress.
[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.
[RFC2362] 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] Bill Fenner, et al. Protocol Independent Multicast - Sparse [PIM-SM-NEW] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas.
Mode (PIM-SM) : Protocol Specifications (Revised). Work in Progress. Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
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 [PIM-DM] S. Deering et al. Protocol Independent Multicast Version 2
Dense Mode Specification. Work in Progress. Dense Mode Specification. Work in Progress.
[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
Address Allocation Architecture. Work in Progress (draft-ietf-
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.
skipping to change at page 13, line 19 skipping to change at page 12, line 4
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
Leonard Giuliano Leonard Giuliano
Greg Shepherd Greg Shepherd
Juniper Networks, Inc. Juniper Networks, Inc.
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA Sunnyvale, CA 94089 USA
{lenny,shep}@juniper.net {lenny,shep}@juniper.net
Robert Rockell Robert Rockell
David Mayer
Sprint E|Solutions Sprint E|Solutions
Reston Virginia USA Reston Virginia USA
rrockell@sprint.net {rrockell,dmm}@sprint.net
John Meylor John Meylor
Dave Meyer
Cisco Systems Cisco Systems
San Jose CA USA San Jose CA USA
{jmeylor,dmm,shep@cisco.com} {jmeylor@cisco.com}
Brian Haberman Brian Haberman
Nortel Networks Nortel Networks
haberman@nortelnetworks.com haberman@nortelnetworks.com
 End of changes. 

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