Internet DRAFT - draft-bhattach-pim-ssm
draft-bhattach-pim-ssm
INTERNET-DRAFT Supratik Bhattacharyya
Expires 13 January 2001 Christophe Diot
Sprint ATL
Leonard Giuliano
Rob Rockell
SprintLink
John Meylor
Dave Meyer
Greg Shepherd
Cisco Systems
13 July 2000
A Framework for Source-Specific IP Multicast Deployment
<draft-bhattach-pim-ssm-00.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. FORMFEED[Page 1]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
Abstract
This document provides an overview of the Source-Specific Multicast
(SSM) service model which supports source-based multicast trees
across multiple domains in the Internet. SSM realizes components of
the EXPRESS [HOLB99] multicast service model in which there is a
single source for every multicast channel, and channel membership is
based on the unique combination of multicast group address (G) as
well as the source's unicast address (S). End-hosts use version 3 of
the IGMP protocol (IGMPv3) to register their interest in a particular
source-group (S,G) pair. The PIM-SM protocol is then used to
construct the multicast forwarding tree rooted at the source S.
This document is intended as a starting point for implementing and
deploying SSM services. It provides a brief architectural overview of
SSM described in more detail in [HOLBOO] and describes associated
deployment challenges. It summarizes changes to protocols and
applications both at end-hosts and routers, with pointers to more
detailed documents, wherever appropriate. Issues of interoperability
with the current multicast architecture are also discussed.
1. Classic Multicast Service Model using IGMPv2/PIM-SM
The current IP multicast service model is an open model where a set
of hosts can be aggregated into a group with a single class-D IP
address in the range of 224.0.0.0 to 239.255.255.255. Any end-host
can send data to a multicast group (even without joining the group),
and any end-host can receive data sent to a group by becoming a
member of it. To become a member of a particular group, an end-host
registers multicast group membership with a querier routers that
handles the multicast group membership function using the IGMP
[FENN97,CAIN99] protocol. Initial IGMPv1 or IGMPv2 protocols only
provide for the ability to specify the group to which a host will
join, there is no mechanism available to allow hosts to describe
their desire to include (or exclude) particular sources sending to a
given group.
Multicast-capable routers then exchange messages with each other
according to some routing protocol to construct a distribution tree
connecting all the end-hosts. A number of different protocols exist
for multicast routing. They differ mainly in the type of delivery
tree constructed [DEER90,DEER96,PIMSM,PIMDM]. Of these, the Protocol
Independent Multicast Sparse-Mode (PIM-SM) protocol is the most
widely deployed in today's public networks. PIM-SM constructs a
single spanning multicast tree rooted at a core rendezvous point or
RP for all group members within a domain.
Bhattacharyya et. al. FORMFEED[Page 2]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
In the following paragraph, the term 'local' when applied to a source
and relative to some router, refers to a source that is in the same
PIM-SM domain. Local sources then send their data to this RP which
forwards the data down the shared tree to interested local receivers.
Again, a receiver joining via IGMPv1 or IGMPv2 can only specify
interest in the entire group and therefore will receive data sent by
any source to this group forwarded via the shared tree. Distribution
via a shared tree can be effective for certain types of traffic,
e.g., where the number of sources is large since forwarding on the
shared tree is performed via a single multicast forwarding entry.
However, there are many cases (eg, Internet broadcast type 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 behavior provides for distribution
of data from local sources to local receivers both sharing a common
RP inside a given PIM domain.
Interdomain PIM-SM Multicast Using MSDP
It is also possible for RP's to learn about sources in other PIM
domains by using the Multicast Source Discovery Protocol (MSDP). Once
an active remote source is identified, an RP can join the shortest
path tree to that source and obtain data to forward down the local
shared tree on behalf of interested local receivers. Designated
routers for particular subnets can again switch to a source-based
shortest path tree for a given remote source once the source's
address is learned from data arriving on the shared tree.
Current implementations of the classic IP multicast service that use
IGMPv2 and PIM-SM, and MSDP for interdomain multicast are widely
deployed and can be particularly effective for groups where sources
are not known in advance by hosts joining a group, or when sources
come and go dynamically, or when forwarding on a common shared tree
is found operationally beneficial.
2. Limitations of IGMPv2/PIM-SM Service Model
There exist several service model limitations associated with use of
IGMPv2, PIM-SM, and MSDP:
A) Handling Well Known Sources via Shortest Path Forwarding
In cases where the address of the source is well known before the
receiver joining the group, and when the shortest forwarding path
is the preferred forwarding mode, then PIM-SM's shared tree
mechanisms and MSDP only represent unnecessary interim mechanisms,
contributing to join latency and operational overhead until the
Bhattacharyya et. al. FORMFEED[Page 3]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
final shortest path tree is constructed.
B) Access Control
In the Classic IP Multicast 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 all sources to
that group.
C) Address Allocation : This is one of the biggest challenges in
deploying inter-domain multicast. Currently there is nothing to
prevent an application from sending data to any multicast address.
More importantly, there is a serious risk of address collisions
among multiple applications. A static address allocation scheme,
GLOP [GLOP00] has been proposed as an interim solution, 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) provide
for additional address allocation but do not guarantee address
availability of any particular address range.
The previously proposed Explicitly-Requested Single-Source(EXPRESS)
Multicast service model decribed, among other things, methods for
addressing the above limitations [HOLB99]. In the EXPRESS model, a
multicast "channel" is determined by specifying a source address S as
well a group address G. Data distribution from source to receiver is
restricted to this shortest path forwarding tree, data is precluded
from being forwared on shared trees. Therefore two channels (S1,G)
and (S2,G) are routed independently, even though they have the same
multicast group address.
The IGMPv3 protocol allows a host to specify a list of sources (S)
which it would like to include (or exclude) if the host can identify
these sources in advance of joining a group. A designated router
serving such hosts is no longer dependent on data coming down the
shared tree to identify local sources nor is it dependent on MSDP for
remote sources, it can initiate a PIM join to specific source
directly and immediately. However, at the same time, IGMPv3 alone
does not preclude the DR from joining the shared tree for a given
group. Thus, while immediate PIM (S,G) joins made possible by IGMPv3
source specific host reports do reduce the amount of mechanism
invoked when sources are well-known in advance, IGMPv3 alone does not
address the issues of access control or address allocation. To
resolve these issues, there must also be an agreed upon range of
globally routable class D address over which PIM (S,G) joins MUST be
used, and over which (*,G) joins MUST NOT be used. For this purpose
IANA has allocated 232/8.
Bhattacharyya et. al. FORMFEED[Page 4]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
3. Source Specific Multicast (SSM)
Source Specific Multicast defines a method of multicast forwarding
restricted to shortest path trees to specific sources described by
hosts using IGMPv3. The allocation of 232/8 for SSM ensures a range
in which SSM is the sole forwarding model. Source-Specific
Multicast, as implemented by PIM-SM and IGMPv3requires the following:
A) source specific host membership reports. As previously described,
IGMPv3 allows a host to describe specific sources from which it would
like to receive data.
B) PIM shortest path forwarding. DR's must be capable of recognizing
receiver-initiated, source specific host reports and initiating PIM
(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 (ie prevent shared tree forwarding) for
some recognized group range. The address range 232/8 has been
allocated by IANA for use by source-specific multicast (SSM)
services. Henceforth, we refer to 232/8 as the SSM address range.
4. Benefits of using SSM
4.1 SSM provides a basis for access control mechanisms. Only a
single source S can transmit to a channel (S,G) where G is an SSM
address. Each receiver is capable of specifying the specific sources
from which it would like to receive content. In addition, the
elimination of shared tree forwarding prevents unrequested sources
from consuming network resources based on (*,G) forwarding.
4.2 SSM defines multicast channels on a per-source basis such that
SSM addresses are "local" to each source. This averts the problem of
global allocation of SSM addresses for multicast groups. Each source
is now 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 rooted
at the source S. Thus there is no need for an RP-based shared tree
infrastructure or for MSDP for source discovery. Thus the complexity
of the multicast routing infrastructure for SSM is low, making it
viable for immediate deployment and more efficient for well-known
sources.
4.4 It is widely held that point-to-multipoint applications such as
Internet TV comprise a large portion of the Internet multicast
application space. The SSM model is designed to efficiently handle
such cases where sources are known in well known.
Bhattacharyya et. al. FORMFEED[Page 5]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
5. SSM Framework
This section describes changes to hosts, applications, and routers that
must be realized in order to deploy and use the SSM service model.
These changes assume that IGMPv3 will be used to provide application-
level interfaces to the SSM service model and that a slightly modified
version of PIM-SM (which we call PIM-SSM) can be deployed on routers
5.1 Address Allocation
SSM addresses should be selected from IANA assigned block 232/8 in
order to ensure source specific functionality.
5.2 Source Discovery
Applications must learn about SSM sources directly before they attempt
to join to the sources content, since they must pass the source address
and group address to the IGMPv3 stack.
5.3 Source-aware Applications
Applications must be capable of parsing source specific information
from sessions descriptions or announcements and be capable of providing
this information to the IGMPv3 stack.
5.4 IGMPv3 Host Stack
Hosts must run IGMPv3 stacks which can receive source specific join
information from applications and convert this into IGMPv3 include mode
source_list information sent to the querier router.
5.5 IGMPv3 Querier
Querier routers must run IGMPv3 and be capable of receiving IGMPv3 host
reports from hosts. 5.6 PIM-SSM Designated Router
The Designated Router must be capable of recognizing source specific
join requests as provided by the IGMPv3 host reports. The DR must be
capable of initiating a direct and immediate PIM (S,G) Join toward the
source. In addition, in the SSM range specified which must include
232/8, the DR must not send an (*,G) join toward the RP in order to
create a shared tree.
5.7 PIM-SSM Core Router Core routers for purposes of this document can
be described as routers which do not have directly connected IGMPv3
speaking hosts.
Core routers must be capable of receiving and propogating PIM (S,G)
joins based on correct RPF information. In addition, they must not
propogate joins for addresses in the SSM range.
Bhattacharyya et. al. FORMFEED[Page 6]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
Figure 1 describes the SSM Framework.
--------------------------------------------------------------
IANA assigned 232/8 ADDRESS ALLOCATION
--------------------------------------------------------------
|
v
+--------------+ session directory/web page
| source,group | SESSION DISCRIPTION
--------------------------------------------------------------
^ |
Query | | s,g
| v
+-----------+ host
| IGMPv3 app| SOURCE DISCOVERY
--------------------------------------------------------------
| IGMPv3 app| IGMPv3 APPLICATION
--------------------------------------------------------------
| IGMPv3 | IGMPv3 HOST REPORTING
+-----------+
|(source specific host report)
|
--------------------------------------------------------------
v
+-----------+ Querier Router
| IGMPv3 | IGMPv3 QUERIER
--------------------------------------------------------------
| PIM-SSM | PIM-SSM ROUTING
+-----------+ Designated Router
|
| (PIM S,G Join only)
v
+-----------+ Core Router
| PIM-SSM |
+-----------+
|
| (PIM S,G Join only)
V
Figure 1 : SSM Framework: elements in end-to-end model
Bhattacharyya et. al. FORMFEED[Page 7]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
6. Framework Elements
In the following sections, we provide a more detailed description of
the SSM framework elements, outline changes to existing protocols,
discuss interoperability issues and tradeoffs of having a SSM based
single source multicast service.
6.1 Address Allocation
The address range of 232/8 has been assigned by IANA for explicit
source join multicast applications. Sessions expecting SSM
functionality must allocate addresses from the 232/8 range. To
ensure global SSM functionality in 232/8, including in networks where
routers run traditional IGMPv2/PIM-SM/MSDP protocols, operational
policies [SHEP] should prevent data sent to 232/8 from being
delivered via shared trees.
NOTE: IGMPv3 and PIM-SM allow for direct creation of the shortest-
path tree for multicast addresses not in the SSM address range,
however, non-232/8 ranges allow for concurrent use of traditional
PIM-SM and shared trees for forwarding data. Therefore, while you can
achieve the PIM join efficiency in non-232/8 with IGMPv3, you can't
prevent 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 232/8.
6.2 Source Discovery
With SSM the application must know the the source address before it
can join to an (S,G) pair, so the function of source discovery
becomes the responsibility of the application. Source information
can be provided in a number of ways, including via a web page, a
session announcement application. The exact mechanisms for doing
this is outside the scope of this framework document, but we provide
two examples of how this might be done.
An advertising tool such as SDR or a content provider URL can be
used to announce multicast services using an abstract naming scheme
(a discussion of an appropriate naming scheme is beyond the scope of
this document). Then it uses the (S,G) address to join the source-
based multicast tree for that service. A session advertisement tool
like SDR can also be used to advertise the source and destination
address of an SSM session.
Bhattacharyya et. al. FORMFEED[Page 8]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
6.3. Requirements for Multicast SSM Applications
-- For applications sourcing content on an SSM address the session
must be advertised including a source address as well as a group
address.
-- An application expecting to join an SSM channel, must be capable
of specifing a source address in addition to a group address. In
other words, the application must be "IGMPv3-aware".
Specific API requirements are identified in [THAL00]. More detailed
discussion of application requirements for SSM are in [QUINN].
6.4. IGMPv3
IGMPv2 allows end-hosts to register their interest in a multicast
group by specifying a class-D IP address. However in order to
implement the single-source multicast model, an end-host must specify
a source's unicast address as well as a group 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
model. Hence an upgrade from IGMPv2 to IGMPv3 is an essential change
for implementing single-source multicast. We believe that this is the
MOST EXTENSIVE CHANGE FOR SSM DEPLOYMENT as it involves changes to
the Application Programming Interface (API) on ALL END-HOSTS that
want to participate in SSM sessions.
IGMPv3 requires the API to provide the following operation (or its
logical equivalent) [CAIN99]:
IPMulticastListen (Socket, IF, G, filter-mode, source-list)
"Socket" is an implementation-specific parameter used to distinguish
among different requesting entities. IF is a local identifier of the
network interface on which the specified multicast address is to be
enabled or disabled and G is the multicast group address to which the
request pertains. filter-mode may be INCLUDE or EXCLUDE. In INCLUDE
mode, reception of packets sent to the specified multicast address is
requested only from the IP addresses listed in the source-list
parameter.
Bhattacharyya et. al. FORMFEED[Page 9]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
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})
If a system (end-host or edge-router) supports both IGMPv2 and
IGMPv3, it must ignore any IGMPv2 message for a SSM address.
A more detailed review of changes to the Internet Group Management
Protocol Version 3 (IGMPv3) [IGMPv3] to support source-specific
multicast detailed can be found in [HOLB00-1].
6.5. PIM-SM Modifications
PIM-SM 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; however, PIM-SM is not designed to allow
a router to immediately select a source-based tree. In fact, with
PIM-SM a DR will always joins a PIM shared tree to start with, and
then may later be switched to a per-source tree.
A key to implementing SSM is eliminate the need for starting with a
shared tree and then switching to a source-specific tree. This
involves several changes to PIM-SM as described in [BHAS00]. The
resulting PIM functionality is described as PIM-SSM. The most
fundemental functional change wrt SSM is as follows:
-- When a DR identifies request to join a specific source in a group
with a SSM group address (232/8), it ALWAYS initiate a (S,G) join and
NEVER a (*,G) join. Moreover, unlike PIM-SM, it need not send a (S,G)
prune towards the RP.
The specific architectural issues associated with PIM-SSM and IGMPv3
are detailed in [HOLB00].
Bhattacharyya et. al. FORMFEED[Page 10]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
7. Interoperability with Existing Multicast Service Models
Moving to SSM will create several deployment issues:
7.1 Addressing: There are two kinds of problems in term of
addressing. PIM-SSM and PIM-SM need to co-exist. There will
consequently be two types of multicast applications on the Internet:
shared groups applications and SSM applications. From an addressing
standpoint, it is important that SSM applications use the 232/8
address range and that PIM-SM groups DO NOT use 232/8 addresses.
Depending on whether a host is PIM-SSM and/or PIM-SM enabled, it will
need to have the following capabilities:
- a PIM-SM sender must use a class D address outside the 232/8 range.
- a PIM-SM receiver can issue a (*, G) join to PIM-SM group.
- a PIM-SSM sender must use a class D address within the 232/8 range.
- a PIM-SSM receiver can issue a (S, G) join to any multicast group,
irrespective of whether it is a PIM-SSM address or not.
These requirements are very important for addressing backward
compatibility issues between PIM-SSM and PIM-SM/MSDP.
7. Acknowledments
We would like to thank a number of people at Sprint Labs -- Gene
Bowen, Ed Kress, Bryan Lyles, Sue Moon, Timothy Roscoe and JayCee
Straley -- and Hugh Holbrook, Isidor Kouvelas, Tony Speakman, 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 Nortel
Networks and Hugh LaMaster at NASA for their valuable insight and
continuing support.
11. References:
[HOLB99] H. Holbrook and D.R. Cheriton.
IP Multicast Channels : EXPRESS Support for Large-scale
Single-Source Applications. In Proceedings of SIGCOMM 1999.
Bhattacharyya et. al. FORMFEED[Page 11]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
[FENN97] W. Fenner.
2236, November 1997.
[CAIN99] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan.
Internet Group Management Protocol, Version 3. Internet
Draft draft-ietf-idmr-igmp-v3-03.txt, March 2000.
[HOLB00] H. Holbrook and B. Cain.
Source-Specific Multicast for IP. Internet Draft draft-
holbrook-ssm-arch-00.txt.
[HOLB00-1] H. Holbrook and B. Cain.
Using IGMPv3 For Source-Specific Multicast. Internet Draft
draft-holbrook-idmr-ssmigmpv3-00.txt
[DEER90] S. Deering and D. Cheriton.
Multicast Routing in Datagram Networks and Extended LANs.
ACM Transactions on Computer Systems, 8(2):85-110, May 1990.
[DEER96] S. Deering et al.
PIM Architecture for Wide-Area Multicast Routing. IEEE/ACM
Transaction on Networking, pages 153-162, April 1996.
[ESTR98] D. Estrin et al.
Protocol Independent Multicast - Sparse Mode (PIM-SM) :
Protocol Specification. Request for Comments, 2362, 1998.
[DEER99] S. Deering et al.
Protocol Independent Multicast Version 2 Dense Mode
Specification. Internet Draft draft-ietf-pim-v2-dm-03.txt,
June 1999.
[FARI00] Farinacci et al.
Multicast Source Discovery Protocol. Internet Draft draft-
ietf-msdp-spec-02.txt, January 2000.
[DIOT00] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen.
Deployment Issues for the IP Multicast Service and
Architecture. In IEEE Networks Magazine's Special Issue on
Multicast, January, 2000.
[SAND00] Hal Sandick and Brad Cain.
PIM-SM Rules for Support of Single-Source Multicast.
Internet Draft draft-sandick-pimsm-ssmrules-00.txt.
[THAL00] Dave Thaler, Bill Fenner and Bob Quinn.
Socket Interface Extensions for Multicast Source Filters.
Internet Draft draft-ietf-idmr-msf-api-00.txt
Bhattacharyya et. al. FORMFEED[Page 12]
INTERNET-DRAFT A Framework for PIM-SSM Deployment 10 March 2000
[BHAS00] N. Bhaskar and I. Kouvelas.
Source-Specific Protocol Independent Multicast. Internet
Draft draft-bhaskar-pim-ss-00.txt
[GLOP97] GLOP Addressing in 233/8. Request For Comments 2770, 1997.
[SDR] Session directory (sdr).
http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr.
[LEVI00] B. Levine et al.
Consideration of Receiver Interest for IP Multicast
Delivery. In Proceedings of IEEE Infocom, March 2000.
[SHEP] G. Shepherd et al.
Source-Specific Protocol Independent Multicast in 232/8.
Internet Draft draft-shepherd-ssm232/8-00.txt
[QUINN]
IP Multicast Applications: Challenges and Solutions.
Internet Draft draft-ietf-mboned-mcast-apps-02.txt
12. Authors' Address:
Supratik Bhattacharyya
Christophe Diot
Sprint Advanced Technology Labs
One Adrian Court
Burlingame CA 94010
{supratik,cdiot}@sprintlabs.com
http://www.sprintlabs.com
Leonard Giuliano
Robert Rockell
Sprint Internet Service Center
Reston, Virginia
{giuliano,rrockell}@sprintlink.net
John Meylor
Dave Meyer
Greg Shepherd
Cisco Systems
{jmeylor,dmm,shep@cisco.com}
Bhattacharyya et. al. FORMFEED[Page 13]
