draft-ietf-mboned-routingarch-06.txt   draft-ietf-mboned-routingarch-07.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: August 15, 2006 Obsoletes: November 21, 2006
3913,2189,2201,1584,1585 3913,2189,2201,1584,1585
(if approved) (if approved)
Intended status: Best Current Intended status: Best Current
Practice Practice
Expires: February 16, 2007 Expires: May 25, 2007
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-06.txt draft-ietf-mboned-routingarch-07.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 38 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 February 16, 2007. This Internet-Draft will expire on May 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (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. This memo also
Obsoletes and reclassifies to Historic a number of older multicast
protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5
2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6
2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6
skipping to change at page 2, line 33 skipping to change at page 2, line 35
2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10
2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11
2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Configuring and Distributing PIM RP Information . . . . . 12 2.4. Configuring and Distributing PIM RP Information . . . . . 12
2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12 2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12
2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13
2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13
2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14
2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14
2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14
2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 14
2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15
2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15
2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15
2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15
2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 15
2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16
2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16
2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16
2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Multicast Payload Transport Extensions . . . . . . . 22 Appendix A. Multicast Payload Transport Extensions . . . . . . . 22
A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 22 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23
A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 24
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
skipping to change at page 5, line 5 skipping to change at page 4, line 47
This memo obsoletes and re-classifies to Historic [RFC2026] Border This memo obsoletes and re-classifies to Historic [RFC2026] Border
Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast
OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and
[RFC1585]. The purpose of the re-classification is to give the [RFC1585]. The purpose of the re-classification is to give the
readers (both implementors and deployers) an idea what the status of readers (both implementors and deployers) an idea what the status of
a protocol is; there may be legacy deployments of some of these a protocol is; there may be legacy deployments of some of these
protocols, which are not affected by this reclassification. See protocols, which are not affected by this reclassification. See
Section 2.1 for more on each protocol. Section 2.1 for more on each protocol.
Further historical perspective may be found in, for example,
[RFC1458], [IMRP-ISSUES], and [IM-GAPS].
1.1. Multicast-related Abbreviations 1.1. Multicast-related Abbreviations
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 (IEEE 802.1D-2004) Generic Attribute Reg. Protocol GARP (IEEE 802.1D-2004) Generic Attribute Reg. Protocol
GMRP GARP Multicast Registration Protocol GMRP GARP Multicast Registration Protocol
IGMP Internet Group Management Protocol IGMP Internet Group Management Protocol
MBGP Multi-protocol BGP (*not* "Multicast BGP") MBGP Multi-protocol BGP (*not* "Multicast BGP")
MLD Multicast Listener Discovery MLD Multicast Listener Discovery
MMRP (IEEE 802.1ak) Multicast Multiple Registration Protocol MRP (IEEE 802.1ak) Multiple Registration Protocol
MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto.
MOSPF Multicast OSPF MOSPF Multicast OSPF
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 Multicast PIM-SSM PIM - Source-Specific Multicast
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 6, line 14 skipping to change at page 6, line 15
2.1. Setting up Multicast Forwarding State 2.1. Setting up Multicast Forwarding State
The most important part of multicast routing is setting up the The most important part of multicast routing is setting up the
multicast forwarding state. This section describes the protocols multicast forwarding state. This section describes the protocols
commonly used for this purpose. commonly used for this purpose.
2.1.1. PIM-SM 2.1.1. PIM-SM
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 [RFC4601]. The PIM-SM protocol includes both Any Source Multicast
Source Multicast (ASM) and Source-Specific Multicast (SSM) (ASM) and Source-Specific Multicast (SSM) functionality; PIM-SSM is a
functionality; PIM-SSM is a subset of PIM-SM. Most current routing 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 has been designed to avoid unnecessary flooding of Whereas PIM-SM has been designed to avoid unnecessary flooding of
multicast data, PIM-DM [RFC3973] assumed that almost every subnet at multicast data, PIM-DM [RFC3973] assumed that almost every subnet at
a site had at least one receiver for a group. PIM-DM floods a site had at least one receiver for a group. PIM-DM floods
multicast transmissions throughout the network ("flood and prune") multicast transmissions throughout the network ("flood and prune")
unless the leaf parts of the network periodically indicate that they unless the leaf parts of the network periodically indicate that they
are not interested in that particular group. are not interested in that particular group.
skipping to change at page 7, line 46 skipping to change at page 7, line 47
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 an academic project that provided the basis for PIM CBT [RFC2201][RFC2189] was an academic project that provided the
sparse mode shared trees. Once the shared tree functionality was basis for PIM sparse mode shared trees. Once the shared tree
incorporated into PIM implementations, there was no longer a need for functionality was incorporated into PIM implementations, there was no
a production CBT implemention. Therefore, CBT never saw production longer a need for a production CBT implementation. Therefore, CBT
deployment. never saw production deployment.
2.1.8. Interactions and Summary 2.1.8. Interactions and Summary
It is worth noting that it is possible to run different protocols It is worth noting that it is possible to run different protocols
with different multicast group ranges. For example, treat some with different multicast group ranges. For example, treat some
groups as dense or bi-dir in an otherwise PIM-SM network; this groups as dense or bi-dir in an otherwise PIM-SM network; this
typically requires manual configuration of the groups or a mechanism typically requires manual configuration of the groups or a mechanism
like BSR (Section 2.4.3). It is also possible to interact between like BSR (Section 2.4.3). It is also possible to interact between
different protocols, for example use DVMRP in the leaf network, but different protocols, for example use DVMRP in the leaf network, but
PIM-SM upstream. The basics for interactions among different PIM-SM upstream. The basics for interactions among different
skipping to change at page 11, line 17 skipping to change at page 11, line 17
PIM-SM domain for the whole Internet is a completely unscalable model PIM-SM domain for the whole Internet is a completely unscalable model
for many reasons. Therefore it is required to be able to split up for many reasons. Therefore it is required to be able to split up
the multicast routing infrastructures to smaller domains, and there the multicast routing infrastructures to smaller domains, and there
must be a way to share information about active sources using some must be a way to share information about active sources using some
mechanism if the ASM model is to be supported. mechanism if the ASM model is to be supported.
This section discusses the options. This section discusses the options.
2.3.1. SSM 2.3.1. SSM
Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also Source-specific Multicast [RFC4607] (sometimes also referred to as
referred to as "single-source Multicast") does not count on learning "single-source Multicast") does not count on learning active sources
active sources in the network. Recipients need to know the source IP in the network. Recipients need to know the source IP addresses
addresses using an out of band mechanism which are used to subscribe using an out of band mechanism which are used to subscribe to the
to the (source, group) channel. The multicast routing uses the (source, group) channel. The multicast routing uses the source
source address to set up the state and no further source discovery is address to set up the state and no further source discovery is
needed. needed.
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 Protocol [RFC3618] was invented as a stop- Multicast Source Discovery Protocol [RFC3618] was invented as a stop-
gap mechanism, when it became apparent that multiple PIM-SM domains gap mechanism, when it became apparent that multiple PIM-SM domains
(and RPs) were needed in the network, and information about the (and RPs) were needed in the network, and information about 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]. The RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The
same can be achieved using PIM extensions [I-D.ietf-pim-anycast-rp]. same can be achieved using PIM extensions [RFC4610]. See Section 2.5
See Section 2.5 for more information. for more information.
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].
2.3.3. Embedded-RP 2.3.3. Embedded-RP
Embedded-RP [RFC3956] is an IPv6-only technique to map the address of Embedded-RP [RFC3956] is an IPv6-only technique to map the address of
the RP to the multicast group address. Using this method, it is the RP to the multicast group address. Using this method, it is
possible to avoid the use of MSDP while still allowing multiple possible to avoid the use of MSDP while still allowing multiple
multicast domains (in the traditional sense). multicast domains (in the traditional sense).
skipping to change at page 12, line 40 skipping to change at page 12, line 40
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 changes 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 (e.g., 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 sharing and redundancy (see provides the benefits of RP load sharing 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).
With such design, an anycast RP uses an address that is configured on With such design, an anycast RP uses an address that is configured on
a loopback interfaces of the routers currently acting as RPs, and a loopback interfaces of the routers currently acting as RPs, and
state is distributed using PIM [I-D.ietf-pim-anycast-rp] or MSDP state is distributed using PIM [RFC4610] or MSDP [RFC3446].
[RFC3446].
Using this technique, each router might only need to be configured Using this technique, each router might only need to be configured
with one, portable RP address. with one, portable RP address.
2.4.2. Embedded-RP 2.4.2. Embedded-RP
Embedded-RP provides the information about the RP's address in the Embedded-RP provides the information about the RP's address in the
group addresses which are delegated to those who use the RP, so group addresses which are delegated to those who use the RP, so
unless no other ASM than Embedded-RP is used, the network unless no other ASM than Embedded-RP is used, the network
administrator only needs to configure the RP routers. administrator only needs to configure the RP routers.
skipping to change at page 13, line 27 skipping to change at page 13, line 26
not dependent on local RP addresses. not dependent on local RP addresses.
As the RP's address is exposed to the users and applications, it is As the RP's address is exposed to the users and applications, it is
very important to ensure it does not change often, e.g., by using very important to ensure it does not change often, e.g., by using
manual configuration of an anycast address. manual configuration of an anycast address.
2.4.3. BSR and Auto-RP 2.4.3. BSR and Auto-RP
BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP
address for groups. It may no longer be in as wide use with IPv4 as address for groups. It may no longer be in as wide use with IPv4 as
it was ealier, and for IPv6, Embedded-RP will in many cases be it was earlier, and for IPv6, Embedded-RP will in many cases be
sufficient. sufficient.
Cisco's Auto-RP is an older, proprietary method for distributing Cisco's Auto-RP is an older, proprietary method for distributing
group to RP mappings, similar to BSR. Auto-RP has little use today. group to RP mappings, similar to BSR. Auto-RP has little use today.
Both Auto-RP and BSR require some form of control at the routers to Both Auto-RP and BSR require some form of control at the routers to
ensure that only valid routers are able to advertise themselves as ensure that only valid routers are able to advertise themselves as
RPs. Further, flooding of BSR and Auto-RP messages must be prevented RPs. Further, flooding of BSR and Auto-RP messages must be prevented
at PIM borders. Additionally, routers require monitoring that they at PIM borders. Additionally, routers require monitoring that they
are actually using the RP(s) the administrators think they should be are actually using the RP(s) the administrators think they should be
skipping to change at page 14, line 35 skipping to change at page 14, line 29
techniques explicitly. techniques explicitly.
2.5.1. Anycast RP 2.5.1. Anycast RP
As mentioned in Section 2.3.2, MSDP is also used to share the state As mentioned in Section 2.3.2, MSDP is also used to share the state
about sources between multiple RPs in a single domain for, e.g., about sources between multiple RPs in a single domain for, e.g.,
redundancy purposes [RFC3446]. The purpose of MSDP in this context redundancy purposes [RFC3446]. The purpose of MSDP in this context
is to share the same state information on multiple RPs for the same is to share the same state information on multiple RPs for the same
groups to enhance the robustness of the service. groups to enhance the robustness of the service.
Recent PIM extensions [I-D.ietf-pim-anycast-rp] also provide this Recent PIM extensions [RFC4610] also provide this functionality. In
functionality. In contrast to MSDP, this approach works for both contrast to MSDP, this approach works for both IPv4 and IPv6.
IPv4 and IPv6.
2.5.2. Stateless RP Failover 2.5.2. Stateless RP Failover
It is also possible to use some mechanisms for smaller amount of It is also possible to use some mechanisms for smaller amount of
redundancy as Anycast RP, without sharing state between the RPs. A redundancy as Anycast RP, without sharing state between the RPs. A
traditional mechanism has been to use Auto-RP or BSR (see traditional mechanism has been to use Auto-RP or BSR (see
Section 2.4.3) to select another RP when the active one failed. Section 2.4.3) to select another RP when the active one failed.
However, the same functionality could be achieved using a shared- However, the same functionality could be achieved using a shared-
unicast RP address ("anycast RP without state sharing") without the unicast RP address ("anycast RP without state sharing") without the
complexity of a dynamic mechanism. Further, Anycast RP offers a complexity of a dynamic mechanism. Further, Anycast RP offers a
skipping to change at page 16, line 33 skipping to change at page 16, line 25
Multicast transmission in the link layer, for example Ethernet, Multicast transmission in the link layer, for example Ethernet,
typically includes some form of flooding the packets through a LAN. typically includes some form of flooding the packets through a LAN.
This causes unnecessary bandwidth usage and discarding unwanted This causes unnecessary bandwidth usage and discarding unwanted
frames on those nodes which did not want to receive the multicast frames on those nodes which did not want to receive the multicast
transmission. transmission.
Therefore a number of techniques have been developed, to be used in Therefore a number of techniques have been developed, to be used in
Ethernet switches between routers, or between routers and hosts, to Ethernet switches between routers, or between routers and hosts, to
limit the flooding. limit the flooding.
Some mechanisms operate with IP addresses, others with MAC addresses.
If filtering is done based on MAC addresses, hosts may receive
unnecessary multicast traffic (filtered out in the hosts' IP layer)
if more than one IP multicast group addresses maps into the same MAC
address, or if IGMPv3/MLDv2 source filters are used. Filtering based
on IP destination addresses, or destination and sources addresses,
will help avoid these but requires parsing of the Ethernet frame
payload.
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 flooding between routers in a switched networks. reduce the amount of flooding between routers in a switched networks.
This is typically only considered a problem in some Ethernet-based This is typically only considered a problem in some Ethernet-based
Internet Exchange points or VPNs. Internet Exchange points or VPNs.
There have been proposals to observe and possibly react ("snoop") PIM There have been proposals to observe and possibly react ("snoop") PIM
messages [I-D.ietf-l2vpn-vpls-pim-snooping]. messages [I-D.ietf-l2vpn-vpls-pim-snooping].
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. Fast leave behaviour support for IGMPv3 hasn't been
implemented. Due to IGMP report suppression in IGMPv1 and IGMPv2,
multicast is still flooded to ports which were once members of a
group as long as there is at least one receiver on the link.
Flooding restrictions are done based on multicast MAC addresses.
IPv6 is not supported.
IEEE 802.1D-2004 specification describes Generic Attribute IEEE 802.1D-2004 specification describes Generic Attribute
Registration Protocol (GARP), and GARP Multicast Registration Registration Protocol (GARP), and GARP Multicast Registration
Protocol (GMRP) [GMRP] is a link-layer multicast group application of Protocol (GMRP) [GMRP] is a link-layer multicast group application of
GARP that notifies switches about IP multicast group memberships. GARP that notifies switches about MAC multicast group memberships.
If GMRP is used in conjunction with IP multicast, then the GMRP
registration function would become associated with an IGMP "join."
However, this GMRP-IGMP association is beyond the scope of GMRP.
GMRP requires support at the host stack and it has not been widely GMRP requires support at the host stack and it has not been widely
implemented. Further, IEEE considers GMRP obsolete having been implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete
replaced by Multicast Multiple Registration Protocol (MMRP) that's being replaced by Multiple Registration Protocol (MRP) and Multicast
being specified in IEEE 802.1ak [802.1ak]. MMRP is expected to be Multiple Registration Protocol (MMRP) that are being specified in
mainly used between bridges. Some further information about GARP/ IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between
GMRP is also available in Appendix B of [RFC3488]. bridges. Some further information about GARP/GMRP is also available
in Appendix B of [RFC3488].
IGMP snooping [RFC4541] appears to be the most widely implemented IGMP snooping [RFC4541] appears to be the most widely implemented
technique. IGMP snooping requires that the switches implement a technique. IGMP snooping requires that the switches implement a
significant amount of IP-level packet inspection; this appears to be significant amount of IP-level packet inspection; this appears to be
something that is difficult to get right, and often the upgrades are something that is difficult to get right, and often the upgrades are
also a challenge. also a challenge.
Snooping switches also need to identify the ports where routers Snooping switches also need to identify the ports where routers
reside and therefore where to flood the packets. This can be reside and therefore where to flood the packets. This can be
accomplished using Multicast Router Discovery protocol [RFC4286], accomplished using Multicast Router Discovery protocol [RFC4286],
looking at certain IGMP queries [RFC4541], looking at PIM Hello and looking at certain IGMP queries [RFC4541], looking at PIM Hello and
possibly other messages, or by manual configuration. An issue with possibly other messages, or by manual configuration. An issue with
PIM snooping at LANs is that PIM messages can't be turned off or PIM snooping at LANs is that PIM messages can't be turned off or
encrypted, leading to security issues encrypted, leading to security issues [I-D.ietf-pim-lasthop-threats].
[I-D.savola-pim-lasthop-threats].
IGMP proxying [I-D.ietf-magma-igmp-proxy] is sometimes used either as IGMP proxying [RFC4605] is sometimes used either as a replacement of
a replacement of a multicast routing protocol on a small router, or a multicast routing protocol on a small router, or to aggregate IGMP/
to aggregate IGMP/MLD reports when used with IGMP snooping. MLD reports when used with IGMP snooping.
2.7.3. Summary 2.7.3. Summary
The following table summarizes the techniques for multicast flooding The following table summarizes the techniques for multicast flooding
reduction inside a single link for router-to-router and last-hop reduction inside a single link for router-to-router and last-hop
LANs. LANs.
+--------+-----+---------------------------+ +--------+-----+---------------------------+
| R-to-R | LAN | Notes | | R-to-R | LAN | Notes |
+-----------------------+--------+-----+---------------------------+ +-----------------------+--------+-----+---------------------------+
skipping to change at page 18, line 15 skipping to change at page 18, line 25
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 up-to-date multicast Ritvanen [RITVANEN] convinced the author that up-to-date multicast
routing and address assignment/allocation documentation is necessary. routing and address assignment/allocation documentation is 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, Dino Farinacci, Bharat Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat
Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon
Chisholm, and John Zwiebel provided good comments, helping in Chisholm, John Zwiebel, Dan Romascanu, and Thomas Morin provided good
improving this document. 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 infrastructures [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and
[I-D.daley-magma-smld-prob], and PIM last-hop issues PIM last-hop issues [I-D.ietf-pim-lasthop-threats].
[I-D.savola-pim-lasthop-threats].
6. References 6. References
6.1. Normative References 6.1. Normative References
[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-10 (work in progress), draft-ietf-idr-rfc2858bis-10 (work in progress),
March 2006. March 2006.
[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-11 (work in IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in
progress), October 2005. progress), October 2005.
[I-D.ietf-mboned-addrarch] [I-D.ietf-mboned-addrarch]
Savola, P., "Overview of the Internet Multicast Addressing Savola, P., "Overview of the Internet Multicast Addressing
Architecture", draft-ietf-mboned-addrarch-04 (work in Architecture", draft-ietf-mboned-addrarch-05 (work in
progress), March 2006. progress), October 2006.
[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-06 (work in progress), February 2006. draft-ietf-ospf-mt-06 (work in progress), February 2006.
[I-D.ietf-pim-bidir] [I-D.ietf-pim-bidir]
Handley, M., "Bi-directional Protocol Independent Handley, M., "Bi-directional Protocol Independent
Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in
progress), October 2005. progress), October 2005.
[I-D.ietf-pim-sm-v2-new]
Fenner, B., "Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification (Revised)",
draft-ietf-pim-sm-v2-new-12 (work in progress),
March 2006.
[I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-07 (work in progress),
October 2005.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[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.
skipping to change at page 20, line 5 skipping to change at page 19, line 46
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 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005. Specification (Revised)", RFC 3973, January 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
6.2. Informative References 6.2. Informative References
[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol", [802.1ak] "IEEE 802.1ak - Multiple Registration Protocol",
<http://www.ieee802.org/1/pages/802.1ak.html>. <http://www.ieee802.org/1/pages/802.1ak.html>.
[CGMP] "Cisco Group Management Protocol", [CGMP] "Cisco Group Management Protocol",
<http://www.javvin.com/protocolCGMP.html>. <http://www.javvin.com/protocolCGMP.html>.
[GMRP] "GARP Multicast Registration Protocol", [GMRP] "GARP Multicast Registration Protocol",
<http://www.javvin.com/protocolGMRP.html>. <http://www.javvin.com/protocolGMRP.html>.
skipping to change at page 20, line 37 skipping to change at page 20, line 37
[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-l2vpn-vpls-pim-snooping] [I-D.ietf-l2vpn-vpls-pim-snooping]
Hemige, V., "PIM Snooping over VPLS", Hemige, V., "PIM Snooping over VPLS",
draft-ietf-l2vpn-vpls-pim-snooping-00 (work in progress), draft-ietf-l2vpn-vpls-pim-snooping-00 (work in progress),
August 2006. August 2006.
[I-D.ietf-magma-igmp-proxy]
Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
draft-ietf-magma-igmp-proxy-06 (work in progress),
April 2004.
[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-pim-lasthop-threats]
Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast Savola, P. and J. Lingard, "Last-hop Threats to Protocol
Routing Security Issues and Enhancements", Independent Multicast (PIM)",
draft-ietf-mboned-mroutesec-04 (work in progress), draft-ietf-pim-lasthop-threats-00 (work in progress),
October 2004. October 2006.
[I-D.ietf-pim-anycast-rp]
Farinacci, D. and Y. Cai, "Anycast-RP using PIM",
draft-ietf-pim-anycast-rp-07 (work in progress),
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-09 (work in progress), June 2006. draft-ietf-pim-sm-bsr-09 (work in progress), June 2006.
[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] [IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap
Lingard, J. and P. Savola, "Last-hop Threats to Protocol Analysis from the MBONED Working Group for the IESG
Independent Multicast (PIM)", [Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work
draft-savola-pim-lasthop-threats-02 (work in progress), in progress), July 2002.
June 2006.
[IMRP-ISSUES]
Meyer, D., "Some Issues for an Inter-domain Multicast
Routing Protocol [Expired]",
draft-ietf-mboned-imrp-some-issues-01 (work in progress),
September 1997.
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075, Vector Multicast Routing Protocol", RFC 1075,
November 1988. November 1988.
[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast
Protocols", RFC 1458, May 1993.
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994. March 1994.
[RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585,
March 1994. March 1994.
[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast
Routing -- Protocol Specification --", RFC 2189, Routing -- Protocol Specification --", RFC 2189,
September 1997. September 1997.
skipping to change at page 22, line 28 skipping to change at page 22, line 27
Protocol Specification", RFC 3913, September 2004. Protocol Specification", RFC 3913, September 2004.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005. RFC 4286, December 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006. Switches", RFC 4541, May 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609,
October 2006.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610, August 2006.
[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 24, line 7 skipping to change at page 24, 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 (2006). Copyright (C) The IETF Trust (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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 38 change blocks. 
91 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/