draft-ietf-ssm-overview-04.txt   draft-ietf-ssm-overview-05.txt 
INTERNET-DRAFT Supratik Bhattacharyya INTERNET-DRAFT Supratik Bhattacharyya
Expires 04 May 2003 Christophe Diot Expires 01 November 2003 Sprint
Sprint ATL Christophe Diot
Intel
Leonard Giuliano Leonard Giuliano
Juniper Networks Juniper Networks
Rob Rockell Rob Rockell
Sprint Sprint
John Meylor John Meylor
Cisco Systems Cisco Systems
David Meyer David Meyer
Sprint Sprint
Greg Shepherd Greg Shepherd
Juniper Networks Procket Networks
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
04 November 2002 01 May 2003
An Overview of Source-Specific Multicast (SSM) An Overview of Source-Specific Multicast (SSM)
<draft-ietf-ssm-overview-04.txt> <draft-ietf-ssm-overview-05.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 3, line 11 skipping to change at page 3, line 11
and routers for supporting SSM, with pointers to more detailed and routers for supporting SSM, with pointers to more detailed
documents where appropriate. Issues of interoperability with the documents where appropriate. Issues of interoperability with the
multicast service model defined by RFC 1112 are also discussed. multicast service model defined by RFC 1112 are also discussed.
2. Terminology 2. Terminology
This section defines some terms that are used in the rest of this This section defines some terms that are used in the rest of this
document : document :
Any-Source Multicast (ASM) : This is the IP multicast service model Any-Source Multicast (ASM) : This is the IP multicast service model
defined in RFC 1112 [27]. An IP datagram is transmitted to a "host defined in RFC 1112 [25]. An IP datagram is transmitted to a "host
group", a set of zero or more end-hosts (or routers) identified by a group", a set of zero or more end-hosts (or routers) identified by a
single IP destination address (224.0.0.0 through 239.255.255.255 for single IP destination address (224.0.0.0 through 239.255.255.255 for
IPv4). End-hosts may join and leave the group any time, and there is IPv4). End-hosts may join and leave the group any time, and there is
no restriction on their location or number. Moreover, this model no restriction on their location or number. Moreover, this model
supports multicast groups with arbitrarily many senders - any end-host supports multicast groups with arbitrarily many senders - any end-host
(or router) may transmit to a host group, even if it is not a member (or router) may transmit to a host group, even if it is not a member
of that group. 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 [5]. An IP datagram is transmitted by a source S to an SSM defined in [5]. An IP datagram is transmitted by a source S to an SSM
destination address G, and receivers can receive this datagram by destination address G, and receivers can receive this datagram by
subscribing to channel (S,G). SSM provides host applications with a subscribing to channel (S,G). SSM provides host applications with a
"channel" abstraction, in which each channel has exactly one source "channel" abstraction, in which each channel has exactly one source
and any number of receivers. SSM is derived from earlier work in and any number of receivers. SSM is derived from earlier work in
EXPRESS [1].The address range 232/8 has been assigned by IANA for SSM EXPRESS [1].The address range 232/8 has been assigned by IANA for SSM
service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM
services [23]. services [21].
Source-Filtered Multicast (SFM) : This is a variant of the ASM service Source-Filtered Multicast (SFM) : This is a variant of the ASM service
model, and uses the same address range as ASM model, and uses the same address range as ASM
(224.0.0.0-239.255.255.255). It extends the ASM service model as (224.0.0.0-239.255.255.255). It extends the ASM service model as
follows. Each "upper layer protocol module" can now request data sent follows. Each "upper layer protocol module" can now request data sent
to a host group G by only a specific set of sources, or can request to a host group G by only a specific set of sources, or can request
data sent to host group G from all BUT a specific set of sources. data sent to host group G from all BUT a specific set of sources.
Support for source filtering is provided by version 3 of the Internet Support for source filtering is provided by version 3 of the Internet
Group Management Protocol (or IGMPv3) [3] for IPv4, and version 2 of Group Management Protocol (or IGMPv3) [3] for IPv4, and version 2 of
the Multicast Listener Discovery (or MLDv2) [22] protocol for IPv6. the Multicast Listener Discovery (or MLDv2) [22] protocol for IPv6.
skipping to change at page 4, line 9 skipping to change at page 4, line 9
For the purpose of this document, we treat the scoped multicast model of For the purpose of this document, we treat the scoped multicast model of
[12] to be a variant of ASM since it does not explicitly restrict the [12] 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 number of sources, but only requires that they be located within the
scope zone of the group. scope zone of the group.
3. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM 3. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM
As of this writing, all multicast-capable networks support the ASM As of this writing, all multicast-capable networks support the ASM
service model. One of the most common multicast protocol suites for service model. One of the most common multicast protocol suites for
supporting ASM consists of IGMP version 2 [28], PIM-SM [8,9], MSDP supporting ASM consists of IGMP version 2 [26], PIM-SM [8,9], MSDP
[13] and MBGP [29] protocols. IGMPv2 [2] is the most commonly used [13] and MBGP [27] protocols. IGMPv2 [2] is the most commonly used
protocol for hosts to specify membership in a multicast group, and protocol for hosts to specify membership in a multicast group, and
nearly all multicast routers support (at least) IGMPv2. In case of nearly all multicast routers support (at least) IGMPv2. In case of
IPv6, MLDv1 [21] is the commonly used protocol. IPv6, MLDv1 [21] is the commonly used protocol.
Although a number of protocols such as PIM-DM [10], CBT [26,11], Although a number of protocols such as PIM-DM [10], CBT [24,11],
DVMRP [6], etc. exist for building multicast tree among all receivers DVMRP [6], etc. exist for building multicast tree among all receivers
and sources in the same administrative domain, PIM-SM [8,9] is the and sources in the same administrative domain, PIM-SM [8,9] is the
most widely used protocol. PIM-SM builds a spanning multicast tree most widely used protocol. PIM-SM builds a spanning multicast tree
rooted at a core rendezvous point or RP for all group members within rooted at a core rendezvous point or RP for all group members within
a single administrative domain. A 'first-hop' router adjacent to a a single administrative domain. A 'first-hop' router adjacent to a
multicast source sends the source's traffic to the RP for its domain. 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 The RP forwards the data down the shared spanning tree to all
interested receivers within the domain. PIM-SM also allows receivers interested receivers within the domain. PIM-SM also allows receivers
to switch to a source-based shortest path tree. to switch to a source-based shortest path tree.
As of this writing, multicast end-hosts with SFM capabilities are not As of this writing, multicast end-hosts with SFM capabilities are not
widely available. Hence a client can only specify interest in an widely available. Hence a client can only specify interest in an
entire host group and receives data sent from any source to this entire host group and receives data sent from any source to this
group. group.
Inter-domain multicast service (i.e., where sources and receivers are Inter-domain multicast service (i.e., where sources and receivers are
located in multiple domains) requires additional protocols - MSDP located in different domains) requires additional protocols - MSDP
[13] and MBGP [29] are the most commonly used ones. An RP uses the [13] and MBGP [27] are the most commonly used ones. An RP uses the
MSDP [13] protocol to announce multicast sources to RPs in other MSDP [13] protocol to announce multicast sources to RPs in other
domains. When an RP discovers a source in a different domain domains. When an RP discovers a source in a different domain
transmitting data to a multicast group for which there are interested transmitting data to a multicast group for which there are interested
receivers in its own domain, it joins the shortest-path source based receivers in its own domain, it joins the shortest-path source based
tree rooted at that source. It then redistributes the data received tree rooted at that source. It then redistributes the data received
to all interested receivers via the intra-domain shared tree rooted to all interested receivers via the intra-domain shared tree rooted
at itself. at itself.
The MBGP protocol [29] defines extensions to the BGP protocol to The MBGP protocol [27] defines extensions to the BGP protocol to
support the advertisement of reachability information for multicast support the advertisement of reachability information for multicast
routes. This allows an autonomous system (AS) to support incongruent routes. This allows an autonomous system (AS) to support incongruent
unicast and multicast routing topologies, and thus implement separate unicast and multicast routing topologies, and thus implement separate
routing policies for each. routing policies for each.
4. Problems with Current Architecture 4. Problems with Current Architecture
There are several deployment problems associated with current There are several deployment problems associated with current
multicast architecture: multicast architecture:
A) Address Allocation : A) Address Allocation :
Address allocation is one of core deployment challenges posed by Address allocation is one of core deployment challenges posed by
the ASM service model. The current multicast architecture does not the ASM service model. The current multicast architecture does not
provide a deployable solution to prevent address collisions among provide a deployable solution to prevent address collisions among
multiple applications. The problem is much less serious for IPv6 multiple applications. The problem is much less serious for IPv6
than for IPv4 since the size of the multicast address space is than for IPv4 since the size of the multicast address space is
much larger. A static address allocation scheme, GLOP [18] has much larger. A static address allocation scheme, GLOP [17] has
been proposed as an interim solution for IPv4; however, GLOP been proposed as an interim solution for IPv4; however, GLOP
addresses are allocated per registered AS, which is inadequate in addresses are allocated per registered AS, which is inadequate in
cases where the number of sources exceeds the AS numbers available cases where the number of sources exceeds the AS numbers available
for mapping. Proposed longer-term solutions such as the Multicast for mapping. Proposed longer-term solutions such as the Multicast
Address Allocation Architecture [14] are generally perceived as Address Allocation Architecture [14] are generally perceived as
being too complex (with respect to the dynamic nature of multicast being too complex (with respect to the dynamic nature of multicast
address allocation) for widespread deployment. address allocation) for widespread deployment.
B) Lack of Access control : B) Lack of Access control :
skipping to change at page 6, line 15 skipping to change at page 6, line 15
A) Address Allocation : SSM defines channels on a per-source A) Address Allocation : SSM defines channels on a per-source
basis, i.e., the channel (S1,G) is distinct from the channel 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 (S2,G), where S1 and S2 are source addresses, and G is an SSM
destination address. This averts the problem of global allocation destination address. This averts the problem of global allocation
of SSM destination addresses, and makes each source independently of SSM destination addresses, and makes each source independently
responsible for resolving address collisions for the various responsible for resolving address collisions for the various
channels that it creates. channels that it creates.
B) Access Control : SSM lends itself to an elegant solution to the B) Access Control : SSM lends itself to an elegant solution to the
access control problem. When a receiver subscribes to an (S,G) access control problem. When a receiver subscribes to an (S,G)
channel, it receives data sent by a only the source S. In channel, it receives data sent only by the source S. In contrast,
contrast, any host can transmit to an ASM host group. At the same any host can transmit to an ASM host group. At the same time, when
time, when a sender picks a channel (S,G) to transmit on, it is a sender picks a channel (S,G) to transmit on, it is automatically
automatically ensured that no other sender will be transmitting on ensured that no other sender will be transmitting on the same
the same channel (except in the case of malicious acts such as channel (except in the case of malicious acts such as address
address spoofing). This makes it much harder to "spam" an SSM spoofing). This makes it much harder to "spam" an SSM channel than
channel than an ASM multicast group. an ASM multicast group.
C) Handling of well-known sources : SSM requires only source-based C) Handling of well-known sources : SSM requires only source-based
forwarding trees; this eliminates the need for a shared tree forwarding trees; this eliminates the need for a shared tree
infrastructure. In terms of the IGMP/PIM-SM/MSDP/MBGP protocol infrastructure. This implies that neither the RP-based shared tree
suite, this implies that neither the RP-based shared tree
infrastructure of PIM-SM nor the MSDP protocol is required. Thus infrastructure of PIM-SM nor the MSDP protocol is required. Thus
the complexity of the multicast routing infrastructure for SSM is the complexity of the multicast routing infrastructure for SSM is
low, making it viable for immediate deployment. Note that MBGP is low, making it viable for immediate deployment. Note that there is
still required for distribution of multicast reachability no difference in how MBGP is used for ASM and SSM.
information.
6. SSM Framework 6. 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::/96 for IPv6 FF3x::/96 for IPv6
-------------------------------------------------------------- --------------------------------------------------------------
skipping to change at page 7, line 44 skipping to change at page 7, line 42
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 [20] which recommend that routers should policies are being proposed [20] which recommend that routers should
not send SSM traffic to parts of the network that do not have channel not send SSM traffic to parts of the network that do not have channel
subscribers. subscribers.
Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8
range. However, SSM service, as defined in [5], is available only in range. However, SSM service, as defined in [5], is available only in
this address range for IPv4. this address range for IPv4.
In case of IPv6, [25] has defined an extension to the addressing In case of IPv6, [23] has defined an extension to the addressing
architecture to allow for unicast prefix-based multicast addresses. architecture to allow for unicast prefix-based multicast addresses.
Bytes 0-3 (starting from the least significant byte) of the IP See RFC 3306 for details.
address are used to specify a multicast group id, bytes 4-11 are used
to specify a unicast address prefix (of up to 64 bits) that owns this
multicast group id, and byte 12 is used to specify the length of the
prefix. A source-specific multicast address is specified by setting
both the unicast address prefix field and the prefix length field to
zero.
6.2 Session Description and Channel Discovery 6.2 Session Description and Channel Discovery
An SSM receiver application must know both the SSM destination An SSM receiver application must know both the SSM destination
address G and the source address S before subscribing to a address G and the source address S before subscribing to a
channel. Channel discovery is the responsibility of applications. channel. Channel discovery is the responsibility of applications.
This information can be made available in a number of ways, This information can be made available in a number of ways,
including via web pages, sessions announcement applications, etc. including via web pages, sessions announcement applications, etc.
This is similar to what is used for ASM applications where a This is similar to what is used for ASM applications where a
multicast session needs to be announced so that potential multicast session needs to be announced so that potential
skipping to change at page 8, line 27 skipping to change at page 8, line 20
schemes used, etc. In fact, the only additional piece of schemes used, etc. In fact, the only additional piece of
information that needs to be announced is the source address for information that needs to be announced is the source address for
the channel being advertised. However, the exact mechanisms for the channel being advertised. However, the exact mechanisms for
doing this is outside the scope of this framework document. doing this is outside the scope of this framework document.
6.3. SSM-Aware Applications 6.3. SSM-Aware Applications
There are two main issues in making multicast applications "SSM- There are two main issues in making multicast applications "SSM-
aware": aware":
-- An application that wants to received an SSM session must first -- An application that wants to receive an SSM session must first
discover the channel address in use. Any of the mechanisms discover the channel address in use.
described in Section 5.2 can be used for this purpose.
-- A receiving application must be able to specify both a source -- A receiving application must be able to specify both a source
address and a destination address to the network layer protocol address and a destination address to the network layer protocol
module on the end-host. In other words, the application must be module on the end-host.
"SSM-aware".
Specific API requirements are identified in [17]. [17] describes a Specific API requirements are identified in [16]. [16] describes a
recommended application programming interface for a host operating recommended application programming interface for a host operating
system to support the SFM service model. Although it is intended system to support the SFM service model. Although it is intended
for SFM, a subset of this interface is sufficient for supporting for SFM, a subset of this interface is sufficient for supporting
SSM. SSM.
6.4. IGMPv3/MLDv2 Host Reporting and Querier 6.4. IGMPv3/MLDv2 Host Reporting and Querier
In order to use SSM service, an end-host must be able to specify a In order to use SSM service, an end-host must be able to specify a
channel address, consisting of a source's unicast address and an channel address, consisting of a source's unicast address and an
SSM destination address. IGMP version 2 [28] and MLD version 1 SSM destination address. IGMP version 2 [26] and MLD version 1
[21] allows an end-host to specify only a destination multicast [19] allows an end-host to specify only a destination multicast
address. The ability to specify an SSM channel address c is address. The ability to specify an SSM channel address c is
provided by IGMP version 3 [3] and MLD version 2 [22]. These provided by IGMP version 3 [3] and MLD version 2 [22]. These
protocols support "source filtering", i.e., the ability of an end- protocols support "source filtering", i.e., the ability of an end-
system to express interest in receiving data packets sent only by system to express interest in receiving data packets sent only by
SPECIFIC sources, or from ALL BUT some specific sources. In fact, SPECIFIC sources, or from ALL BUT some specific sources. In fact,
IGMPv3 provides a superset of the capabilities required to realize IGMPv3 provides a superset of the capabilities required to realize
the SSM service model. the SSM service model.
A detailed discussion of the use of IGMPv3 in the SSM destination A detailed discussion of the use of IGMPv3 in the SSM destination
address range is provided in [4]. address range is provided in [4].
The Multicast Listener Discovery (MLD) protocol used by an IPv6 The Multicast Listener Discovery (MLD) protocol used by an IPv6
router to discover the presence of multicast listeners on its router to discover the presence of multicast listeners on its
directly attached links, and to discover the multicast addresses directly attached links, and to discover the multicast addresses
that are of interest to those neighboring nodes. Version 1 of MLD that are of interest to those neighboring nodes. Version 1 of MLD
[21] is derived from IGMPv2 and does not provide the source [19] is derived from IGMPv2 and does not provide the source
filtering capability required for the SSM service model. Version 2 filtering capability required for the SSM service model. Version 2
of MLD [22] is derived from, and provides the same support for of MLD [20] is derived from, and provides the same support for
source-filtering as, IGMPv3. Thus IGMPv3 (or MLDv2 for IPv6) source-filtering as, IGMPv3. Thus IGMPv3 (or MLDv2 for IPv6)
provides a host with the ability to request the network for an SSM provides a host with the ability to request the network for an SSM
channel subscription. channel subscription.
6.5. PIM-SSM Routing 6.5. PIM-SSM Routing
[9] provides guideliness for how a PIM-SM implementation should [9] provides guideliness for how a PIM-SM implementation should
handle source-specific host reports as required by SSM. Earlier handle source-specific host reports as required by SSM. Earlier
versions of the PIM protocol specifications did not describe how to versions of the PIM protocol specifications did not describe how to
do this. do this.
skipping to change at page 10, line 36 skipping to change at page 10, line 28
8. Security Considerations 8. Security Considerations
SSM does not introduce new security considerations for IP multicast. SSM does not introduce new security considerations for IP multicast.
It can help in preventing denial-of-service attacks resulting from It can help in preventing denial-of-service attacks resulting from
unwanted sources transmitting data to a multicast channel (S, G). unwanted sources transmitting data to a multicast channel (S, G).
However no guarantee is provided. However no guarantee is provided.
9. Acknowledgments 9. Acknowledgments
We would like to thank Gene Bowen, Ed Kress, Bryan Lyles and Timothy We would like to thank Gene Bowen, Ed Kress, Bryan Lyles Timothy
Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, Tony Speakman Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and Nidhi
and Nidhi Bhaskar at Cisco Systems for participating in lengthy Bhaskar for participating in lengthy discussions and design work on
discussions and design work on SSM, and providing feedback on this SSM, and providing feedback on this document. Thanks are also due to
document. Thanks are also due to Mujahid Khan and Ted Seely at Mujahid Khan, Ted Seely , Tom Pusateri, Bill Fenner, Kevin Almeroth,
SprintLink, Tom Pusateri at Juniper Networks, Bill Fenner at AT&T Brian Levine, Brad Cain and Hugh LaMaster at NASA for their valuable
Research, Kevin Almeroth at the University of California Santa insights and continuing support.
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.
10. References: 10. References:
[1] H. Holbrook and D.R. Cheriton, "IP Multicast Channels : EXPRESS [1] H. Holbrook and D.R. Cheriton, "IP Multicast Channels : EXPRESS
Support for Large-scale Single-Source Applications", In Proceedings Support for Large-scale Single-Source Applications", In Proceedings
of SIGCOMM 1999. of SIGCOMM 1999.
[2] W. Fenner, "Internet Group Management Protocol, Version 2", RFC [2] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
2236. 2236.
[2] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan, "Internet [3] B. Cain, S. Deering, I. Kouvelas and A. Thyagarajan, "Internet
Group Management Protocol, Version 3.", Work in Progress. Group Management Protocol, Version 3.", Request for Comments 3376.
[4] H. Holbrook and B. Cain, "IGMPv3 for SSM", Work in Progress. [4] H. Holbrook and B. Cain, "Using IGMPv3 and MLDv2 for Source-
Specific Multicast", Work in Progress.
[5] H. Holbrook and B. Cain, "Source-Specific Multicast for [5] H. Holbrook and B. Cain, "Source-Specific Multicast for
IP", Work in Progress. IP", Work in Progress.
[6] S. Deering and D. Cheriton,"Multicast Routing in Datagram [6] S. Deering and D. Cheriton,"Multicast Routing in Datagram
Networks and Extended LANs", ACM Transactions on Computer Systems, Networks and Extended LANs", ACM Transactions on Computer Systems,
8(2):85-110, May 1990. 8(2):85-110, May 1990.
[7] S. Deering et al., "PIM Architecture for Wide-Area Multicast [7] S. Deering et al., "PIM Architecture for Wide-Area Multicast
Routing", IEEE/ACM Transaction on Networking, pages 153-162, April Routing", IEEE/ACM Transaction on Networking, pages 153-162, April
1996. 1996.
[8] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode [8] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode
(PIM-SM) : Protocol Specification", RFC 2362. (PIM-SM) : Protocol Specification", RFC 2362.
[9] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [9] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", Work In Progress, 2000. (Revised)", Work In Progress, 2000.
[10] S. Deering et al., "Protocol Independent Multicast Version 2 [10] A. Adams, J. Nicholas, W. Siadek, "Protocol Independent
Dense Mode Specification", Work in Progress. Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)",
Work in Progress.
[11] A. Ballardie, "Core-Based Trees (CBT) Multicast Routing [11] A. Ballardie, "Core-Based Trees (CBT) Multicast Routing
Architecture", RFC 2201. Architecture", RFC 2201.
[12] D. Meyer, "Adminstratively Scoped IP Multicast", RFC 2365. [12] D. Meyer, "Adminstratively Scoped IP Multicast", RFC 2365.
[13] Farinacci et al., "Multicast Source Discovery Protocol", Work in [13] Farinacci et al., "Multicast Source Discovery Protocol", Work in
Progress. Progress.
[14] M. Handley, D. Thaler and D. Estrin, "The Internet Multicast [14] D. Thaler, M. Handley and D. Estrin, "The Internet Multicast
Address Allocation Architecture", Work in Progress. Address Allocation Architecture", Request for Comments 2908.
[15] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen, [15] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen,
"Deployment Issues for the IP Multicast Service and Architecture", In "Deployment Issues for the IP Multicast Service and Architecture", In
IEEE Networks Magazine's Special Issue on Multicast, January, 2000. IEEE Networks Magazine's Special Issue on Multicast, January, 2000.
[16] H. Sandick and B. Cain, "PIM-SM Rules for Support of Single- [16] Dave Thaler, Bill Fenner and Bob Quinn, "Socket Interface
Source Multicast", Work in Progress.
[17] 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.
[18] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", Request [17] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", Request
For Comments 2770. For Comments 2770.
[19] B. Levine et al., "Consideration of Receiver Interest for IP [18] B. Levine et al., "Consideration of Receiver Interest for IP
Multicast Delivery", In Proceedings of IEEE Infocom, March 2000. Multicast Delivery", In Proceedings of IEEE Infocom, March 2000.
[20] G. Shepherd et al., "Source-Specific Protocol Independent [19] S. Deering, W. Fenner and B. Haberman, "Multicast Listener
Multicast in 232/8", Work in Progress.
[21] S. Deering, W. Fenner and B. Haberman, "Multicast Listener
Discovery for IPv6", RFC 2710. Discovery for IPv6", RFC 2710.
[22] R. Vida, et. al., "Multicast Listener Discovery Version 2(MLDv2) [20] R. Vida, et. al., "Multicast Listener Discovery Version 2(MLDv2)
for IPv6", Work in progress. for IPv6", Work in progress.
[23] B. Haberman and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast [21] B. Haberman and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast
Addresses", Work in Progress. Addresses", Request for Comments 3306.
[24] S. Kent, R. Atkinson, "Security Architecture for the Internet [22] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", Request for Comments 2401. Protocol", Request for Comments 2401.
[25] B. Haberman, "Dynamic Allocation Guidelines for IPv6 Multicast [23] B. Haberman, "Allocation Guidelines for IPv6 Multicast
Addresses", Work in Progress. Addresses", Request for Comments 3307.
[26] A. Ballardie, "Core-Based Trees (CBT Version 2) Multicast [24] A. Ballardie, "Core-Based Trees (CBT Version 2) Multicast
Routing -- Protocol Specification", RFC 2189. Routing -- Protocol Specification", RFC 2189.
[27] S. Deering, "Host Extensions for IP Multicasting", RFC 1112. [25] S. Deering, "Host Extensions for IP Multicasting", RFC 1112.
[28] W. Fenner, "Internet Group Management Protocol, Version 2", RFC [26] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
2236. 2236.
[29] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol [27] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283. Extensions for BGP-4", RFC 2283.
12. Authors' Address: 12. Author information:
Supratik Bhattacharyya Supratik Bhattacharyya
Sprint
supratik@sprintlabs.com
Christophe Diot Christophe Diot
Sprint Advanced Technology Labs Intel
One Adrian Court christophe.diot@intel.com
Burlingame CA 94010 USA
{supratik,cdiot}@sprintlabs.com
http://www.sprintlabs.com
Leonard Giuliano Leonard Giuliano
Juniper Networks
lenny@juniper.net
Greg Shepherd Greg Shepherd
Juniper Networks, Inc. Procket Networks
1194 North Mathilda Avenue shep@procket.com
Sunnyvale, CA 94089 USA
{lenny,shep}@juniper.net
Robert Rockell Robert Rockell
David Meyer David Meyer
Sprint E|Solutions Sprint
Reston Virginia USA
{rrockell,dmm}@sprint.net {rrockell,dmm}@sprint.net
John Meylor John Meylor
Cisco Systems Cisco Systems
San Jose CA USA
jmeylor@cisco.com jmeylor@cisco.com
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
bkhabs@nc.rr.com bkhabs@nc.rr.com
 End of changes. 

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