INTERNET-DRAFT Supratik Bhattacharyya
Expires 04 June 2002 Christophe Diot
Sprint ATL
Leonard Giuliano
Juniper Networks
Rob Rockell
Sprint E|Solutions
John Meylor
Cisco Systems
David Meyer
Sprint E|Solutions
Greg Shepherd
Juniper Networks
Brian Haberman
No Affiliation
4 December 2001
An Overview of Source-Specific Multicast(SSM) Deployment
<draft-ietf-ssm-overview-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
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].
Bhattacharyya et. al. [Page 1]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
Abstract
This document provides an overview of the Source-Specific Multicast
(SSM) service and its deployment using the PIM-SM and IGMP/MLD
protocols. The network layer service provided by SSM is a "channel",
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
use by the SSM service. An SSM destination address range already
exists for IPv6. A source S transmits IP datagrams to an SSM
destination address G. A receiver can receive these datagrams by
subscribing to 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 interdomain tree for forwarding IP multicast
datagrams is rooted at the source S. Although a number of protocols
exists for constructing source-rooted forwarding trees, this document
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
services. It provides an architectural overview of SSM and describes
how it solves a number of problems faced in the deployment of inter-
domain multicast. It outlines changes to protocols and applications
both at end-hosts and routers for supporting SSM, with pointers to
more detailed documents where appropriate. Issues of interoperability
with the multicast service model defined by RFC 1112 are also
discussed.
1. Terminology
This section defines some terms that are used in the rest of this
document :
Any-Source Multicast (ASM) : This is the IP multicast service model
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
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
restriction on their location or number. Moreover, any end-host may
transmit to a host group, even if it is not a member of that group.
Source-Specific Multicast (SSM) : This is the multicast service model
defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to
an SSM destination address G, and receivers can receive this datagram
by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS]
and supports one-to-many multicast.The address range 232/8 has been
Bhattacharyya et. al. [Page 2]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
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
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.
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
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
Internet Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and
version 2 of the Multicast Listener Discovery (or MLD) protocol for
IPv6 [MLDv2]. We shall henceforth refer to these two protocols as
"SFM-capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and
MLDv1 - do not provide support for source-filtering, and are referred
to as "non-SFM-capable".
2. The IGMP/PIM-SM/MSDP/MBGP Architecture for ASM
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
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
Bhattacharyya et. al. [Page 3]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
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]
to support the advertisement of reachability information for
multicast routes. This allows an autonomous system (AS) to support
incongruent unicast and multicast routing topologies, and thus
implement separate routing policies for each.
3. Problems with Current Architecture
There are several deployment problems associated with current
multicast architecture:
A) 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.
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
the ASM service model. The current multicast architecture does not
provide a deployable solution to prevent address collisions among
multiple applications. The problem is more serious for IPv4 than
IPv6 since the total number of multicast addresses is smaller. A
static address allocation scheme, GLOP [GLOP00] has been proposed
as an interim solution for IPv4; however, GLOP addresses are
allocated per registered AS, which is inadequate in cases where
the number of sources exceeds the AS numbers available for
mapping. Proposed longer-term solutions such as the Multicast
Address Allocation Architecture [MAAA] are generally perceived as
being too complex (with respect to the dynamic nature of multicast
address allocation) for widespread deployment.
Bhattacharyya et. al. [Page 4]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
4. Source Specific Multicast (SSM) : Benefits and Requirements
As mentioned before, the Source Specific Multicast (SSM) service
model defines a "channel" identified by an (S,G) pair, where S is a
source address and G is an SSM destination address. Channel
subscriptions are described using an SFM-capable group management
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
described earlier :
4.1 SSM lends itself to an elegant solution to the access control
problem. When a receiver subscribes to an (S,G) channel, it
receives data sent by a only the source S. In contrast, any host
can transmit to an ASM host group. Hence, it is more difficult to
spam an SSM channel than an ASM host group.
4.2 SSM defines channels on a per-source basis, i.e., the channel
(S1,G) is distinct from the channel (S2,G), where S1 and S2 are
source addresses, and G is an SSM destination address. This averts
the problem of global allocation of SSM destination addresses, and
makes each source independently responsible for resolving address
collisions for the various channels that it creates.
4.3 SSM requires only source-based forwarding trees; this
eliminates the need for a shared tree infrastructure. In terms of
the IGMP/PIM-SM/MSDP/MBGP protocol suite, this implies that
neither the RP-based shared tree infrastructure of PIM-SM nor the
MSDP protocol is required. Thus the complexity of the multicast
routing infrastructure for SSM is low, making it viable for
immediate deployment.
4.4 It is widely held that point-to-multipoint applications such
as Internet TV will dominate the Internet multicast application
space 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
framework for SSM :
--------------------------------------------------------------
IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION
FF3x::/12 for IPv6
--------------------------------------------------------------
Bhattacharyya et. al. [Page 5]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
|
v
+--------------+ session directory/web page
| source,group | SESSION DESCRIPTION
--------------------------------------------------------------
^ |
Query | | (S,G)
| v
+-----------------+ host
| SSM-aware app | CHANNEL DISCOVERY
--------------------------------------------------------------
| SSM-aware app | SSM-AWARE APPLICATION
--------------------------------------------------------------
| IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING
+-----------------+
|(source specific host report)
--------------------------------------------------------------
v
+-----------------+ Querier Router
| IGMPv3/MLDv2 | QUERIER
--------------------------------------------------------------
| PIM-SSM | PIM-SSM ROUTING
+------------+ Designated Router
|
| (S,G) Join only
v
+-----------+ Backbone Router
| PIM-SSM |
+-----------+
|
| (S,G) Join only
V
Figure 1 : SSM Framework: elements in end-to-end model
We now discuss the framework elements in detail :
5.1 Address Allocation
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
networks where routers run non-SFM-capable protocols, operational
policies are being proposed [SSM-BCP] which prevent data sent to
232/8 from being delivered to parts of the network that do not have
channel subscribers.
Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8
Bhattacharyya et. al. [Page 6]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
range. However, SSM service, as defined in [SSM-ARCH], is guaranteed
only in this address range for IPv4.
In case of IPv6, [HABE1] has defined an extension to the addressing
architecture to allow for unicast prefix-based multicast addresses.
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
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
length of the prefix. A source-specific multicast address can be
specified by setting both the prefix length field and the prefix
field to zero.
5.2 Session Description and Channel Discovery
An SSM receiver application must know both the SSM destination
address G and the source address S before subscribing to a
channel. Thus the function of channel discovery becomes the
responsibility of applications. This information can be made
available in a number of ways, including via web pages, sessions
announcement applications, etc. The exact mechanisms for doing
this is outside the scope of this framework document.
5.3. SSM-Aware Applications
-- For applications sourcing content via SSM channels, the session
must be advertised including a source address as well as an SSM
address.
-- Applications expecting to subscribe to an SSM channel must be
capable of specifying a source address in addition to an SSM
destination address. In other words, the application must be "SSM-
aware".
Specific API requirements are identified in [THAL00].
5.4. IGMPv3/MLDv2 Host Reporting and Querier
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
Bhattacharyya et. al. [Page 7]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
realize the SSM service model.
There are a number of backward compatibility issues between IGMP
versions 2 and 3 which have to be addressed. A detailed discussion
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
router to discover the presence of multicast listeners on its
directly attached links, and to discover the multicast addresses
that are of interest to those neighboring nodes. Version 1 of MLD
[DEER99] is derived from IGMPv2 and allows a multicast listener
to specify the multicast group(s) that it is interested in.
Version 2 of MLD [VIDA01] is derived from, and provides the same
support for source-filtering as, IGMPv3.
5.5. PIM-SSM Routing
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
PIM-SM already supports source-based trees. The original
PIM-SM [PIM-SM] did not allow a router to choose between a shared
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
described in [PIM-SM-NEW]. The resulting PIM functionality is
described as PIM-SSM. The specific architectural issues associated
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:
-- When a DR receives an (S,G) join request with the address G in
the SSM address range, it must initiate a (S,G) join and NEVER a
(*,G) join.
--Backbone routers (i.e. routers that do not have directly
attached hosts) must not propagate (*,G) joins for group addresses
in the SSM address range.
--Rendezvous Points (RPs) must not accept PIM Register messages or
(*,G) Join messages in the SSM address range.
Bhattacharyya et. al. [Page 8]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
6. Interoperability with Existing Multicast Service Models
Interoperability with ASM is one of the most important issues in
moving to SSM deployment. ASM and SSM will always coexist; hence
there will be two service models for Internet multicast. SSM is the
ONLY service model for the SSM address range - the correct protocol
behaviour for this range is specified in [SSM-ARCH]. The ASM service
model will be offered for the non-SSM adddress range, where receivers
can issue (*,G) join requests to receive multicast data. A receiver
is also allowed to issue an (S,G) join request in the non-SSM address
range; however, in that case there is no guarantee that it will
receive service according to the SSM model.
Another backward compatibility issue concerns the MSDP protocol,
which is used between PIM-SM rendezvous points (RPs) to discover
multicast sources across multiple domains. SSM obviates the needs for
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
model in 232/8, RPs must not accept, originate or forward MSDP SA
messages for the SSM address range [SSM-BCP].
7. Security Considerations
SSM does not introduce new security considerations for IP multicast.
It can help in preventing denial-of-service attacks resulting from
unwanted sources transmitting data to a multicast channel (S, G).
However no guarantee is provided.
8. Acknowledgments
We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Sue Moon
and Timothy Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas,
Tony Speakman and Nidhi Bhaskar at Cisco Systems for participating in
lengthy discussions and design work on SSM, and providing feedback on
this document. Thanks are also due to Mujahid Khan and Ted Seely at
SprintLink, Tom Pusateri at Juniper Networks, Bill Fenner at AT&T
Research, Kevin Almeroth at the University of California Santa
Barbara, Brian Levine at the University of Massachusetts Amherst,
Brad Cain at Cereva Networks and Hugh LaMaster at NASA for their
valuable insights and continuing support.
Bhattacharyya et. al. [Page 9]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
9. References:
[EXPRESS] H. Holbrook and D.R. Cheriton. IP Multicast Channels :
EXPRESS Support for Large-scale Single-Source Applications. In
Proceedings of SIGCOMM 1999.
[IANA-ALLOCATION] Internet Assigned Numbers Authority.
http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.
[RFC2236] W. Fenner. Internet Group Management Protocol, Version 2.
Request For Comments 2236.
[IGMPv3] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan.
Internet Group Management Protocol, Version 3. Work in Progress.
[SSM-IGMPv3] H. Holbrook and B. Cain. IGMPv3 for SSM. Work in
Progress.
[SSM-ARCH] H. Holbrook and B. Cain. Source-Specific Multicast for
IP. Work in Progress.
[IPMULTICAST] S. Deering and D. Cheriton. Multicast Routing in
Datagram Networks and Extended LANs. ACM Transactions on Computer
Systems, 8(2):85-110, May 1990.
[PIM-ARCH] S. Deering et al. PIM Architecture for Wide-Area
Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162,
April 1996.
[PIM-SM] D. Estrin et al. Protocol Independent Multicast - Sparse
Mode (PIM-SM) : Protocol Specification. Request for Comments, 2362.
[PIM-SM-NEW] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas.
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
Dense Mode Specification. Work in Progress.
[MSDP] Farinacci et al. Multicast Source Discovery Protocol. Work in
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.
Bhattacharyya et. al. [Page 10]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
Balensiefen. Deployment Issues for the IP Multicast Service and
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
Single-Source Multicast. Work in Progress.
[MSF-API] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface
Extensions for Multicast Source Filters. Work in Progress.
[RFC2770] GLOP Addressing in 233/8. Request For Comments 2770.
[RCVR-INTEREST] B. Levine et al. Consideration of Receiver Interest
for IP Multicast Delivery. In Proceedings of IEEE Infocom, March
2000.
[SSM-BCP] G. Shepherd et al. Source-Specific Protocol Independent
Multicast in 232/8. Work in Progress.
[RFC2710] S. Deering, W. Fenner and B. Haberman. Multicast Listener
Discovery for IPv6. Request for Comments 2710.
[MLDv2] R. Vida, et. al.
Multicast Listener Discovery Version 2 (MLDv2) for IPv6.
Work in progress.
[SSM-IPv6] B. Haberman and D. Thaler.
Unicast-Prefix-Based IPv6 Multicast Addresses. Work in
Progress.
[IPSEC] S. Kent, R. Atkinson.
Security Architecture for the Internet Protocol. Request for
Comments 2401.
[IPv6-ALLOC] B. Haberman.
Dynamic Allocation Guidelines for IPv6 Multicast Addresses.
Work in Progress.
12. Authors' Address:
Supratik Bhattacharyya
Christophe Diot
Sprint Advanced Technology Labs
One Adrian Court
Burlingame CA 94010 USA
{supratik,cdiot}@sprintlabs.com
http://www.sprintlabs.com
Bhattacharyya et. al. [Page 11]
INTERNET-DRAFT An Overview of SSM Deployment 4 December 2001
Leonard Giuliano
Greg Shepherd
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
{lenny,shep}@juniper.net
Robert Rockell
David Meyer
Sprint E|Solutions
Reston Virginia USA
{rrockell,dmm}@sprint.net
John Meylor
Cisco Systems
San Jose CA USA
jmeylor@cisco.com
Brian Haberman
No Affiliation
haberman@innovationslab.net
Bhattacharyya et. al. [Page 12]
