draft-ietf-mboned-routingarch-02.txt   draft-ietf-mboned-routingarch-03.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: October 12, 2005 Obsoletes: March 3, 2006
3913,2189,2201,1584,1585 (if 3913,2189,2201,1584,1585 (if
approved) approved)
Expires: April 15, 2006 Intended status: Best Current
Practice
Expires: September 4, 2006
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-02.txt draft-ietf-mboned-routingarch-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 36 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2006. This Internet-Draft will expire on September 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The lack of up-to-date documentation on IP multicast routing The lack of up-to-date documentation on IP multicast routing
protocols and procedures has caused a great deal of confusion. To protocols and procedures has caused a great deal of confusion. To
clarify the situation, this memo describes the routing protocols and clarify the situation, this memo describes the routing protocols and
techniques currently (as of this writing) in use. techniques currently (as of this writing) in use.
Table of Contents Table of Contents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 13 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 13
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Multicast Payload Transport Extensions . . . . . . . 18 Appendix A. Multicast Payload Transport Extensions . . . . . . . 18
A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18
A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 18 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
Good, up-to-date documentation of IP multicast is close to non- Good, up-to-date documentation of IP multicast is close to non-
existent. This issue is severely felt with multicast routing existent. This issue is severely felt with multicast routing
protocols and techniques. The consequence is that those who wish to protocols and techniques. The consequence is that those who wish to
learn of IP multicast and how the routing works in the real world do learn of IP multicast and how the routing works in the real world do
not know where to begin. not know where to begin.
The aim of this document is to provide a brief overview of multicast The aim of this document is to provide a brief overview of multicast
skipping to change at page 4, line 16 skipping to change at page 4, line 16
ASM Any Source Multicast ASM Any Source Multicast
BGMP Border Gateway Multicast Protocol BGMP Border Gateway Multicast Protocol
BSR Bootstrap Router BSR Bootstrap Router
CBT Core Based Trees CBT Core Based Trees
CGMP Cisco Group Management Protocol CGMP Cisco Group Management Protocol
DR Designated Router DR Designated Router
DVMRP Distance Vector Multicast Routing Protocol DVMRP Distance Vector Multicast Routing Protocol
GARP Group Address Resolution Protocol GARP Group Address Resolution Protocol
IGMP Internet Group Management Protocol IGMP Internet Group Management Protocol
MBGP Multi-protocol BGP (*not* "Multicast BGP")
MLD Multicast Listener Discovery MLD Multicast Listener Discovery
MSNIP Multicast Source Notification of Interest Protocol
MOSPF Multicast OSPF MOSPF Multicast OSPF
MBGP Multi-protocol BGP (*not* "Multicast BGP")
MSDP Multicast Source Discovery Protocol MSDP Multicast Source Discovery Protocol
PGM Pragmatic General Multicast PGM Pragmatic General Multicast
PIM Protocol Independent Multicast PIM Protocol Independent Multicast
PIM-DM PIM - Dense Mode PIM-DM PIM - Dense Mode
PIM-SM PIM - Sparse Mode PIM-SM PIM - Sparse Mode
PIM-SSM PIM - (Source-specific) Sparse Mode PIM-SSM PIM - (Source-specific) Sparse Mode
RGMP (Cisco's) Router Group Management Protocol RGMP (Cisco's) Router Group Management Protocol
RP Rendezvous Point RP Rendezvous Point
SSM Source-specific Multicast SSM Source-specific Multicast
skipping to change at page 4, line 49 skipping to change at page 4, line 48
By far, the most common multicast routing protocol is PIM-SM By far, the most common multicast routing protocol is PIM-SM
[I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any [I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any
Source Multicast (ASM) and Source-Specific Multicast (SSM) Source Multicast (ASM) and Source-Specific Multicast (SSM)
functionality; PIM-SSM is a subset of PIM-SM. Most current routing functionality; PIM-SSM is a subset of PIM-SM. Most current routing
platforms support PIM-SM. platforms support PIM-SM.
2.1.2. PIM-DM 2.1.2. PIM-DM
Whereas PIM-SM is designed to avoid unnecessary flooding of multicast Whereas PIM-SM is designed to avoid unnecessary flooding of multicast
data, PIM-DM [I-D.ietf-pim-dm-new-v2] operates in a "dense" mode, data, PIM-DM [RFC3973] operates in a "dense" mode, flooding the
flooding the multicast transmissions throughout the network ("flood multicast transmissions throughout the network ("flood and prune")
and prune") unless the leaf parts of the network periodically unless the leaf parts of the network periodically indicate that they
indicate that they are not interested in that particular traffic. are not interested in that particular traffic.
PIM-DM may be some fit in small and/or simple networks, where setting PIM-DM may be some fit in small and/or simple networks, where setting
up an RP would be unnecessary, and possibly in cases where a large up an RP would be unnecessary, and possibly in cases where a large
number of users is expected to be able to wish to receive the number of users is expected to be able to wish to receive the
transmission so that the amount of state the network has to keep is transmission so that the amount of state the network has to keep is
minimal. Therefore PIM-DM has typically only been used in special minimal. Therefore PIM-DM has typically only been used in special
deployments, never currently in, e.g., ISPs' networks. deployments, never currently in, e.g., ISPs' networks.
PIM-DM never really got popular due to its reliance of data plane and PIM-DM never really got popular due to its reliance of data plane and
potential for loops, and the over-reliance of the complex Assert potential for loops, and the over-reliance of the complex Assert
mechanism. Further, it was a non-starter with high-bandwidth mechanism. Further, it was a non-starter with high-bandwidth
streams. streams.
Many implementations also support so-called "sparse-dense" mode, Many implementations also support so-called "sparse-dense" mode,
where Sparse mode is is used by default, but Dense is used for where Sparse mode is used by default, but Dense is used for
configured multicast group ranges (such as Auto-RP in Section 2.4.3) configured multicast group ranges (such as Auto-RP in Section 2.4.3)
only. Lately, many networks have been transitioned away from sparse- only. Lately, many networks have been transitioned away from sparse-
dense to only sparse mode. dense to only sparse mode.
2.1.3. Bi-directional PIM 2.1.3. Bi-directional PIM
Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined
PIM-SM operation, without data-driven events and data-encapsulation, PIM-SM operation, without data-driven events and data-encapsulation,
inside a PIM-SM domain. The usage of bi-dir PIM may be on the inside a PIM-SM domain. The usage of bi-dir PIM may be on the
increase especially inside sites leveraging multicast. increase especially inside sites leveraging multicast.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
2.1.6. BGMP 2.1.6. BGMP
BGMP [RFC3913] did not get sufficient support within the service BGMP [RFC3913] did not get sufficient support within the service
provider community to get adopted and moved forward in the IETF provider community to get adopted and moved forward in the IETF
standards process. There were no reported production implementations standards process. There were no reported production implementations
and no production deployments. and no production deployments.
2.1.7. CBT 2.1.7. CBT
CBT [RFC2201] was was an academic project that provided the basis for CBT [RFC2201] was an academic project that provided the basis for PIM
PIM sparse mode shared trees. Once the shared tree functionality was sparse mode shared trees. Once the shared tree functionality was
incorporated into PIM implementations, there was no longer a need for incorporated into PIM implementations, there was no longer a need for
a production CBT implemention. Therefore, CBT never saw production a production CBT implemention. Therefore, CBT never saw production
deployment. deployment.
2.1.8. Interactions and Summary 2.1.8. Interactions and Summary
It is worth noting that is it is possible to run different protocols It is worth noting that is it is possible to run different protocols
with different groups ranges (e.g., treat some groups as dense mode with different groups ranges (e.g., treat some groups as dense mode
in an other-wise PIM-SM network; this typically requires manual in an other-wise PIM-SM network; this typically requires manual
configuration of the groups) or interact between different protocols configuration of the groups) or interact between different protocols
skipping to change at page 9, line 26 skipping to change at page 9, line 26
these using out of band mechanisms, and when subscribing to an (S,G) these using out of band mechanisms, and when subscribing to an (S,G)
channel indicate toward which source(s) the multicast routing channel indicate toward which source(s) the multicast routing
protocol should send the Join messages. protocol should send the Join messages.
As of this writing, there are attempts to analyze and/or define out- As of this writing, there are attempts to analyze and/or define out-
of-band source discovery functions which would help SSM in particular of-band source discovery functions which would help SSM in particular
[I-D.lehtonen-mboned-dynssm-req]. [I-D.lehtonen-mboned-dynssm-req].
2.3.2. MSDP 2.3.2. MSDP
Multicast Source Discovery Mechanism [RFC3618] was invented as a Multicast Source Discovery Protocol [RFC3618] was invented as a stop-
stop-gap mechanism, when it became apparent that multiple PIM-SM gap mechanism, when it became apparent that multiple PIM-SM domains
domains (and RPs) were needed in the network, and information about (and RPs) were needed in the network, and information about the
the active sources needed to be propagated between the PIM-SM domains active sources needed to be propagated between the PIM-SM domains
using some other protocol. using some other protocol.
MSDP is also used to share the state about sources between multiple MSDP is also used to share the state about sources between multiple
RPs in a single domain for, e.g., redundancy purposes [RFC3446]. RPs in a single domain for, e.g., redundancy purposes [RFC3446].
There is also work in progress to achieve the same using PIM There is also work in progress to achieve the same using PIM
extensions [I-D.ietf-pim-anycast-rp]. See Section 2.5 for more. extensions [I-D.ietf-pim-anycast-rp]. See Section 2.5 for more.
There is no intent to define MSDP for IPv6, but instead use only SSM There is no intent to define MSDP for IPv6, but instead use only SSM
and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues].
skipping to change at page 10, line 17 skipping to change at page 10, line 17
For PIM-SM, configuration mechanisms exist which are used to For PIM-SM, configuration mechanisms exist which are used to
configure the RP addresses and which groups are to use those RPs in configure the RP addresses and which groups are to use those RPs in
the routers. This section outlines the approaches. the routers. This section outlines the approaches.
2.4.1. Manual Configuration with an Anycast Address 2.4.1. Manual Configuration with an Anycast Address
It is often easiest just to manually configure the RP information on It is often easiest just to manually configure the RP information on
the routers when PIM-SM is used. the routers when PIM-SM is used.
Originally, static RP mapping was considered suboptimal since it Originally, static RP mapping was considered suboptimal since it
required explicit configuration chages every time the RP address required explicit configuration changes every time the RP address
changed. However, with the advent of anycast RP addressing, the RP changed. However, with the advent of anycast RP addressing, the RP
address is unlikely to ever change. Therefore, the administrative address is unlikely to ever change. Therefore, the administrative
burden is generally limited to initial configuration. Since there is burden is generally limited to initial configuration. Since there is
usually a fair amount of multicast configuration required on all usually a fair amount of multicast configuration required on all
routers anyway (eg, PIM on all interfaces), adding the RP address routers anyway (eg, PIM on all interfaces), adding the RP address
statically isn't really an issue. Further, static anycast RP mapping statically isn't really an issue. Further, static anycast RP mapping
provides the benefits of RP load balancing and redundancy (see provides the benefits of RP load balancing and redundancy (see
Section 2.5) without the complexity found in dynamic mechanisms like Section 2.5) without the complexity found in dynamic mechanisms like
Auto-RP and Bootstrap Router (BSR). Auto-RP and Bootstrap Router (BSR).
skipping to change at page 13, line 14 skipping to change at page 13, line 14
These options are discussed in this section. These options are discussed in this section.
2.7.1. Router-to-Router Flooding Reduction 2.7.1. Router-to-Router Flooding Reduction
A proprietary solution, Cisco's RGMP [RFC3488] has been developed to A proprietary solution, Cisco's RGMP [RFC3488] has been developed to
reduce the amount of router-to-router flooding on a LAN. This is reduce the amount of router-to-router flooding on a LAN. This is
typically only considered a problem in some Ethernet-based Internet typically only considered a problem in some Ethernet-based Internet
Exchange points. Exchange points.
There have been proposals to snoop PIM messages [I-D.tsenevir-pim-sm- There have been proposals to snoop PIM messages
snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve the same effect. [I-D.tsenevir-pim-sm-snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve
the same effect.
2.7.2. Host/Router Flooding Reduction 2.7.2. Host/Router Flooding Reduction
There are a number of techniques to help reduce flooding both from a There are a number of techniques to help reduce flooding both from a
router to hosts, and from a host to the routers (and other hosts). router to hosts, and from a host to the routers (and other hosts).
Cisco's proprietary CGMP [CGMP] provides a solution where the routers Cisco's proprietary CGMP [CGMP] provides a solution where the routers
notify the switches, but also allows the switches to snoop IGMP notify the switches, but also allows the switches to snoop IGMP
packets to enable faster notification of hosts no longer wishing to packets to enable faster notification of hosts no longer wishing to
receive a group. IPv6 is not supported. receive a group. IPv6 is not supported.
skipping to change at page 13, line 38 skipping to change at page 13, line 39
[GARP] as a link-layer method to perform the same functionality. The [GARP] as a link-layer method to perform the same functionality. The
implementation status is unknown. implementation status is unknown.
IGMP snooping [I-D.ietf-magma-snoop] appears to be the most widely IGMP snooping [I-D.ietf-magma-snoop] appears to be the most widely
implemented technique. IGMP snooping requires that the switches implemented technique. IGMP snooping requires that the switches
implement a significant amount of IP-level packet inspection; this implement a significant amount of IP-level packet inspection; this
appears to be something that is difficult to get right, and often the appears to be something that is difficult to get right, and often the
upgrades are also a challenge. To allow the snooping switches to upgrades are also a challenge. To allow the snooping switches to
identify at which ports the routers reside (and therefore where to identify at which ports the routers reside (and therefore where to
flood the packets) instead of requiring manual configuration, flood the packets) instead of requiring manual configuration,
Multicast Router Discovery protocol is being specified [I-D.ietf- Multicast Router Discovery protocol is being specified [RFC4286].
magma-mrdisc]. IGMP proxying [I-D.ietf-magma-igmp-proxy] is IGMP proxying [I-D.ietf-magma-igmp-proxy] is sometimes used either as
sometimes used either as a replacement of a multicast routing a replacement of a multicast routing protocol on a small router, or
protocol on a small router, or to aggregate IGMP/MLD reports when to aggregate IGMP/MLD reports when used with IGMP snooping.
used with IGMP snooping.
3. Acknowledgements 3. Acknowledgements
Tutoring a couple multicast-related papers, the latest by Kaarle Tutoring a couple multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that the up-to-date Ritvanen [RITVANEN] convinced the author that the up-to-date
multicast routing and address assignment/allocation documentation is multicast routing and address assignment/allocation documentation is
necessary. necessary.
Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer,
Stig Venaas, Tom Pusateri, Marshall Eubanks, and Dino Farinacci Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, and
provided good comments, helping in improving this document. Bharat Joshi provided good comments, helping in improving this
document.
4. IANA Considerations 4. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
5. Security Considerations 5. Security Considerations
This memo only describes different approaches to multicast routing, This memo only describes different approaches to multicast routing,
and this has no security considerations; the security analysis of the and this has no security considerations; the security analysis of the
mentioned protocols is out of scope of this memo. mentioned protocols is out of scope of this memo.
However, there has been analysis of the security of multicast routing However, there has been analysis of the security of multicast routing
infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD [I-D.daley- infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD
magma-smld-prob], and PIM last-hop issues [I-D.savola-pim-lasthop- [I-D.daley-magma-smld-prob], and PIM last-hop issues
threats]. [I-D.savola-pim-lasthop-threats].
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3]
Pusateri, T., "Distance Vector Multicast Routing Pusateri, T., "Distance Vector Multicast Routing
Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress),
December 2003. December 2003.
[I-D.ietf-idmr-dvmrp-v3-as] [I-D.ietf-idmr-dvmrp-v3-as]
Pusateri, T., "Distance Vector Multicast Routing Protocol Pusateri, T., "Distance Vector Multicast Routing Protocol
Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01
(work in progress), May 2004. (work in progress), May 2004.
[I-D.ietf-isis-wg-multi-topology] [I-D.ietf-isis-wg-multi-topology]
Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in
IS-IS", draft-ietf-isis-wg-multi-topology-10 (work in IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in
progress), May 2005. progress), October 2005.
[I-D.ietf-ospf-mt] [I-D.ietf-ospf-mt]
Psenak, P., "Multi-Topology (MT) Routing in OSPF", Psenak, P., "Multi-Topology (MT) Routing in OSPF",
draft-ietf-ospf-mt-04 (work in progress), April 2005. draft-ietf-ospf-mt-06 (work in progress), February 2006.
[I-D.ietf-pim-bidir] [I-D.ietf-pim-bidir]
Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, Handley, M., "Bi-directional Protocol Independent
"Bi-directional Protocol Independent Multicast (BIDIR- Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in
PIM)", draft-ietf-pim-bidir-07 (work in progress), progress), October 2005.
March 2005.
[I-D.ietf-pim-dm-new-v2]
Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", draft-ietf-pim-dm-new-v2-05
(work in progress), June 2004.
[I-D.ietf-pim-sm-v2-new] [I-D.ietf-pim-sm-v2-new]
Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode PIM-SM): "Protocol Independent Multicast - Sparse Mode PIM-SM):
Protocol Specification (Revised)", Protocol Specification (Revised)",
draft-ietf-pim-sm-v2-new-11 (work in progress), draft-ietf-pim-sm-v2-new-11 (work in progress),
October 2004. October 2004.
[I-D.ietf-ssm-arch] [I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for Holbrook, H. and B. Cain, "Source-Specific Multicast for
skipping to change at page 15, line 44 skipping to change at page 15, line 38
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
6.2. Informative References 6.2. Informative References
[CGMP] "Cisco Group Management Protocol", [CGMP] "Cisco Group Management Protocol",
<http://www.javvin.com/protocolCGMP.html>. <http://www.javvin.com/protocolCGMP.html>.
[GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study [GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study
of IEEE 802.1p GARP/GMRP Timer Values", 1997. of IEEE 802.1p GARP/GMRP Timer Values", 1997.
[I-D.daley-magma-smld-prob] [I-D.daley-magma-smld-prob]
Daley, G. and G. Kurup, "Trust Models and Security in Daley, G. and G. Kurup, "Trust Models and Security in
Multicast Listener Discovery", Multicast Listener Discovery",
draft-daley-magma-smld-prob-00 (work in progress), draft-daley-magma-smld-prob-00 (work in progress),
July 2004. July 2004.
[I-D.ietf-idr-rfc2858bis] [I-D.ietf-idr-rfc2858bis]
Bates, T., "Multiprotocol Extensions for BGP-4", Bates, T., "Multiprotocol Extensions for BGP-4",
draft-ietf-idr-rfc2858bis-07 (work in progress), draft-ietf-idr-rfc2858bis-08 (work in progress),
August 2005. January 2006.
[I-D.ietf-magma-igmp-proxy] [I-D.ietf-magma-igmp-proxy]
Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
draft-ietf-magma-igmp-proxy-06 (work in progress), draft-ietf-magma-igmp-proxy-06 (work in progress),
April 2004. April 2004.
[I-D.ietf-magma-mrdisc]
Haberman, B. and J. Martin, "Multicast Router Discovery",
draft-ietf-magma-mrdisc-07 (work in progress), May 2005.
[I-D.ietf-magma-snoop] [I-D.ietf-magma-snoop]
Christensen, M., Kimball, K., and F. Solensky, Christensen, M., Kimball, K., and F. Solensky,
"Considerations for IGMP and MLD Snooping Switches", "Considerations for IGMP and MLD Snooping Switches",
draft-ietf-magma-snoop-12 (work in progress), draft-ietf-magma-snoop-12 (work in progress),
February 2005. February 2005.
[I-D.ietf-mboned-ipv6-multicast-issues] [I-D.ietf-mboned-ipv6-multicast-issues]
Savola, P., "IPv6 Multicast Deployment Issues", Savola, P., "IPv6 Multicast Deployment Issues",
draft-ietf-mboned-ipv6-multicast-issues-02 (work in draft-ietf-mboned-ipv6-multicast-issues-02 (work in
progress), February 2005. progress), February 2005.
[I-D.ietf-mboned-mroutesec] [I-D.ietf-mboned-mroutesec]
Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
Routing Security Issues and Enhancements", Routing Security Issues and Enhancements",
draft-ietf-mboned-mroutesec-04 (work in progress), draft-ietf-mboned-mroutesec-04 (work in progress),
October 2004. October 2004.
[I-D.ietf-pim-anycast-rp] [I-D.ietf-pim-anycast-rp]
Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Farinacci, D. and Y. Cai, "Anycast-RP using PIM",
draft-ietf-pim-anycast-rp-04 (work in progress), draft-ietf-pim-anycast-rp-07 (work in progress),
August 2005. February 2006.
[I-D.ietf-pim-sm-bsr] [I-D.ietf-pim-sm-bsr]
Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM",
draft-ietf-pim-sm-bsr-05 (work in progress), draft-ietf-pim-sm-bsr-06 (work in progress), October 2005.
February 2005.
[I-D.lehtonen-mboned-dynssm-req] [I-D.lehtonen-mboned-dynssm-req]
Lehtonen, R., "Requirements for discovery of dynamic SSM Lehtonen, R., "Requirements for discovery of dynamic SSM
sources", draft-lehtonen-mboned-dynssm-req-00 (work in sources", draft-lehtonen-mboned-dynssm-req-00 (work in
progress), February 2005. progress), February 2005.
[I-D.savola-pim-lasthop-threats] [I-D.savola-pim-lasthop-threats]
Savola, P., "Last-hop Threats to Protocol Independent Savola, P., "Last-hop Threats to Protocol Independent
Multicast (PIM)", draft-savola-pim-lasthop-threats-01 Multicast (PIM)", draft-savola-pim-lasthop-threats-01
(work in progress), January 2005. (work in progress), January 2005.
skipping to change at page 18, line 21 skipping to change at page 18, line 14
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group
Management Protocol (RGMP)", RFC 3488, February 2003. Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP):
Protocol Specification", RFC 3913, September 2004. Protocol Specification", RFC 3913, September 2004.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005.
[RITVANEN] [RITVANEN]
Ritvanen, K., "Multicast Routing and Addressing", HUT Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004, Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>. <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
Appendix A. Multicast Payload Transport Extensions Appendix A. Multicast Payload Transport Extensions
A couple of mechanisms have been, and are being specified, to improve A couple of mechanisms have been, and are being specified, to improve
the characteristics of the data that can be transported over the characteristics of the data that can be transported over
multicast. multicast.
skipping to change at page 19, line 17 skipping to change at page 20, line 7
Pekka Savola Pekka Savola
CSC - Scientific Computing Ltd. CSC - Scientific Computing Ltd.
Espoo Espoo
Finland Finland
Email: psavola@funet.fi Email: psavola@funet.fi
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
skipping to change at page 20, line 13 skipping to change at page 20, line 47
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 29 change blocks. 
57 lines changed or deleted 54 lines changed or added

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