draft-ietf-mboned-routingarch-04.txt   draft-ietf-mboned-routingarch-05.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: June 26, 2006 Obsoletes: July 11, 2006
3913,2189,2201,1584,1585 (if 3913,2189,2201,1584,1585 (if
approved) approved)
Intended status: Best Current Intended status: Best Current
Practice Practice
Expires: December 28, 2006 Expires: January 12, 2007
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-04.txt draft-ietf-mboned-routingarch-05.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 December 28, 2006. This Internet-Draft will expire on January 12, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 4 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5
2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 4 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Setting up Multicast Forwarding State . . . . . . . . . . 4 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6
2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 5 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6
2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 6 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8
2.2. Distributing Topology Information . . . . . . . . . . . . 7 2.2. Distributing Topology Information . . . . . . . . . . . . 8
2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 7 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9
2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 8 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 9
2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 8 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 9
2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 8 2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10
2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 9 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Configuring and Distributing PIM-SM RP Information . . . . 10 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11
2.4.1. Manual Configuration with an Anycast Address . . . . . 10 2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 10 2.4. Configuring and Distributing PIM RP Information . . . . . 12
2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 11 2.4.1. Manual Configuration with an Anycast Address . . . . . 12
2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 11 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13
2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 11 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13
2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 12 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 12 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14
2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 12 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14
2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 12 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14
2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 12 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 14
2.7. Restricting Multicast Flooding in the Link Layer . . . . . 13 2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 13 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15
2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 13 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 16 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Multicast Payload Transport Extensions . . . . . . . 18 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Multicast Payload Transport Extensions . . . . . . . 22
A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 22
A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
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
not know where to begin. Multicast addressing is described in a not know where to begin. Multicast addressing is described in a
companion document [I-D.ietf-mboned-addrarch]. companion document [I-D.ietf-mboned-addrarch].
skipping to change at page 3, line 25 skipping to change at page 4, line 25
routing protocols and techniques. routing protocols and techniques.
This memo deals with: This memo deals with:
o setting up multicast forwarding state (Section 2.1), o setting up multicast forwarding state (Section 2.1),
o distributing multicast topology information (Section 2.2), o distributing multicast topology information (Section 2.2),
o learning active sources (Section 2.3), o learning active sources (Section 2.3),
o configuring and distributing the PIM-SM RP information o configuring and distributing the PIM RP information (Section 2.4),
(Section 2.4),
o mechanisms for enhanced redundancy (Section 2.5), o mechanisms for enhanced redundancy (Section 2.5),
o interacting with hosts (Section 2.6), and o interacting with hosts (Section 2.6), and
o restricting the multicast flooding in the link layer o restricting the multicast flooding in the link layer
(Section 2.7). (Section 2.7).
Some multicast data transport issues are also introduced in Section 2 starts by describing a simplistic example how these classes
Appendix A. of mechanisms fit together. Some multicast data transport issues are
also introduced in Appendix A.
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.
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 Group Address Resolution Protocol GARP (IEEE 802.1D-2004) Generic Attribute Reg. 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
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
2. Multicast Routing 2. Multicast Routing
In order to give a simplified summary how each of these class of
mechanisms fits together, consider the following multicast receiver
scenario.
When a host wants to receive a transmission, it first needs to find
out the multicast group address (and with SSM, source address) using
unspecified means. Then it will signal its interest to its router
using IGMP or MLD (Section 2.6). To deliver a multicast
transmission, the router will need to know how to build the
distribution tree which includes all the sources (Section 2.3) and/or
to locate the RP (Section 2.4) or one of RPs (Section 2.5). In
scenarios where multicast is routed via different topology than
unicast, a means to distribute topology information is required
(Section 2.2). Nonetheless, using whatever topology information is
available, the first-hop router initiates setting up hop-by-hop
multicast forwarding state (Section 2.1). When multicast
transmission arrives at the receiver's LAN, it is flooded to every
port unless flooding reduction such as IGMP snooping is employed
(Section 2.7).
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 [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 has been designed to avoid unnecessary flooding of
data, PIM-DM [RFC3973] operates in a "dense" mode, flooding the multicast data, PIM-DM [RFC3973] assumed that almost every subnet at
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 traffic. are not interested in that particular group.
PIM-DM may be an acceptable fit in small and/or simple networks, PIM-DM may be an acceptable fit in small and/or simple networks,
where setting up an RP would be unnecessary, and possibly in cases where setting up an RP would be unnecessary, and possibly in cases
where a large percentage of users is expected to want to receive the where a large percentage of users is expected to want 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. PIM-DM has been used to transition to PIM-SM but it is no minimal.
longer in widespread use.
PIM-DM never became popular due to its reliance on data plane and PIM-DM was used as a first step in transitioning away from DVMRP. It
potential for loops, and the over-reliance of the complex Assert also became apparent that most networks would not have receivers for
mechanism. Further, it was a non-starter with high-bandwidth streams most groups, and to avoid the bandwidth and state overhead, the
due to its flooding paradigm. flooding paradigm was gradually abandoned. Transitioning from PIM-DM
to PIM-SM was easy as PIM-SM was designed to use compatible packet
formats and dense-mode operation could also be satisfied by a sparse
protocol. PIM-DM is no longer in widespread use.
Many implementations also support so-called "sparse-dense" mode, Many implementations also support so-called "sparse-dense"
where Sparse mode is used by default, but Dense is used for configuration, where Sparse mode is used by default, but Dense is
configured multicast group ranges (such as Auto-RP in Section 2.4.3) used for configured multicast group ranges (such as Auto-RP in
only. Lately, many networks have been transitioned away from sparse- Section 2.4.3) only. Lately, many networks have transitioned away
dense to only sparse mode. from sparse-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] is a multicast forwarding
PIM-SM operation, without data-driven events and data-encapsulation, protocol that establishes a common shared-path for all sources with a
inside a PIM-SM domain. As it doesn't keep source-specific state, it single root. It can be used as an alternative to PIM-SM inside a
may be a lucrative approach especially in sites with a large number single domain. It doesn't have data-driven events or data-
of sources. encapsulation. As it doesn't keep source-specific state, it may be a
lucrative approach especially in sites with a large number of
sources.
As of this writing, in IPv6 or inter-domain multicast there is no As of this writing, there is no inter-domain solution to configure a
standards based mechanism for alerting routers that a group range is group range to use bi-directional PIM.
to be used for bi-directional PIM.
2.1.4. DVMRP 2.1.4. DVMRP
Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075]
[I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first [I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first
protocol designed for multicasting, and to get around initial protocol designed for multicasting, and to get around initial
deployment hurdles. It also included tunneling capabilities which deployment hurdles. It also included tunneling capabilities which
were part of its multicast topology functions. were part of its multicast topology functions.
Currently, DVMRP is used only very rarely in operator networks, Currently, DVMRP is used only very rarely in operator networks,
skipping to change at page 6, line 32 skipping to change at page 8, line 8
CBT [RFC2201] was an academic project that provided the basis for PIM CBT [RFC2201] was an academic project that provided the basis for 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 it is possible to run different protocols It is worth noting that it is possible to run different protocols
with different multicast group ranges (e.g., treat some groups as with different multicast group ranges. For example, treat some
dense mode in an otherwise PIM-SM network; this typically requires groups as dense or bi-dir in an otherwise PIM-SM network; this
manual configuration of the groups) or interaction between different typically requires manual configuration of the groups or a mechanism
protocols (e.g., use DVMRP in the leaf network, but PIM-SM upstream). like BSR (Section 2.4.3). It is also possible to interact between
The basics for interactions among different protocols have been different protocols, for example use DVMRP in the leaf network, but
outlined in [RFC2715]. PIM-SM upstream. The basics for interactions among different
protocols have been outlined in [RFC2715].
The following figure gives a concise summary of the deployment status The following figure gives a concise summary of the deployment status
of different protocols as of this writing. of different protocols as of this writing.
+-------------+-------------+----------------+ +-------------+-------------+----------------+
| Interdomain | Intradomain | Status | | Interdomain | Intradomain | Status |
+------------+-------------+-------------+----------------+ +------------+-------------+-------------+----------------+
| PIM-SM | Yes | Yes | Active | | PIM-SM | Yes | Yes | Active |
| PIM-DM | Not feasible| Yes | Little use | | PIM-DM | Not anymore | Not anymore | Little use |
| Bi-dir PIM | No | Yes | Wait & see | | Bi-dir PIM | No | Yes | Some uptake |
| DVMRP | Not anymore | Stub only | Going out | | DVMRP | Not anymore | Stub only | Going out |
| MOSF | No | Not anymore | Inactive | | MOSPF | No | Not anymore | Inactive |
| CBT | No | No | Never deployed | | CBT | No | No | Never deployed |
| BGMP | No | No | Never deployed | | BGMP | No | No | Never deployed |
+------------+-------------+-------------+----------------+ +------------+-------------+-------------+----------------+
From this table, it is clear that PIM-Sparse Mode is the only From this table, it is clear that PIM-Sparse Mode is the only
multicast routing protocol that is deployed inter-domain and, multicast routing protocol that is deployed inter-domain and,
therefore, is most frequently used within multicast domains as well. therefore, is most frequently used within multicast domains as well.
This is partially result of not working on inter-domain RP/group
configuration mechanisms since PIM-SM and MSDP (Section 2.3.2).
2.2. Distributing Topology Information 2.2. Distributing Topology Information
When unicast and multicast topologies are the same ("congruent"), PIM has become the de-facto multicast forwarding protocol, but as its
i.e., use the same routing tables (routing information base, RIB), it name implies, it is independent of the underlying unicast routing
has been considered sufficient just to distribute one set of protocol. When unicast and multicast topologies are the same
reachability information to be used in conjunction with a protocol ("congruent"), i.e., use the same routing tables (routing information
that sets up multicast forwarding state (e.g., PIM-SM). base, RIB), it has been considered sufficient just to distribute one
set of reachability information to be used in conjunction with a
protocol that sets up multicast forwarding state (e.g., PIM-SM).
However, when PIM which by default built multicast topology based on However, when PIM which by default built multicast topology based on
the unicast topology gained popularity, it became apparent that it the unicast topology gained popularity, it became apparent that it
would be necessary to be able to distribute also non-congruent would be necessary to be able to distribute also non-congruent
multicast reachability information in the regular unicast protocols. multicast reachability information in the regular unicast protocols.
This was previously not an issue, because DVMRP built its own This was previously not an issue, because DVMRP built its own
reachability information. reachability information.
The topology information is needed to perform efficient distribution The topology information is needed to perform efficient distribution
of multicast transmissions and to prevent transmission loops by of multicast transmissions and to prevent transmission loops by
skipping to change at page 8, line 8 skipping to change at page 9, line 34
that use BGP should use Multiprotocol BGP to distribute multicast that use BGP should use Multiprotocol BGP to distribute multicast
reachability information explicitly even if the topologies are reachability information explicitly even if the topologies are
congruent to make an explicit statement about multicast reachability. congruent to make an explicit statement about multicast reachability.
A number of significant multicast transit providers even require A number of significant multicast transit providers even require
this, by doing the RPF lookups solely based on explicitly advertised this, by doing the RPF lookups solely based on explicitly advertised
multicast address family. multicast address family.
2.2.2. OSPF/IS-IS Multi-topology Extensions 2.2.2. OSPF/IS-IS Multi-topology Extensions
Similar to BGP, some IGPs also provide the capability for signalling Similar to BGP, some IGPs also provide the capability for signalling
a differing multicast topology, for example IS-IS multi-topology a differing topologies, for example IS-IS multi-topology extensions
extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists [I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast
for OSPF [I-D.ietf-ospf-mt]. topology that differs from unicast. Similar but not so widely
implemented work exists for OSPF [I-D.ietf-ospf-mt].
It is worth noting that interdomain incongruence and intradomain It is worth noting that interdomain incongruence and intradomain
incongruence are orthogonal, so one doesn't require the other. incongruence are orthogonal, so one doesn't require the other.
Specifically, interdomain incongruence is quite common, while Specifically, interdomain incongruence is quite common, while
intradomain incongruence isn't, so you see much more deployment of intradomain incongruence isn't, so you see much more deployment of
MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well
without protocols handling intradomain incongruence. However, the without protocols handling intradomain incongruence. However, the
availability of multi-topology mechanisms may in part replace the availability of multi-topology mechanisms may in part replace the
typically used workarounds such as tunnels. typically used workarounds such as tunnels.
skipping to change at page 8, line 48 skipping to change at page 10, line 26
routing table. The important point to remember here, though, is to routing table. The important point to remember here, though, is to
not override the multicast-only routes; if the longest prefix match not override the multicast-only routes; if the longest prefix match
would find both a (copied) unicast route and a multicast-only route, would find both a (copied) unicast route and a multicast-only route,
the latter should be treated as preferable. the latter should be treated as preferable.
Another implemented approach is to just look up the information in Another implemented approach is to just look up the information in
the unicast routing table, and provide the user capabilities to the unicast routing table, and provide the user capabilities to
change that as appropriate, using for example copying functions change that as appropriate, using for example copying functions
discussed above. discussed above.
2.2.4. Summary
The following table summarizes the topology distribution approaches
described in this Section. In particular, it is recommended that if
interdomain routing uses BGP, multicast-enabled sites should use MP-
BGP SAFI=1+2 even if the topology were congruent.
+-------------+---------------+
| Interdomain | Intradomain |
+--------------------- +--------------+--------------+
| Congruent topology | Yes | Yes |
| BGP without SAFI | Not recomm. | Yes |
| MP-BGP SAFI=1+2 | Recommended | Yes |
| MP-BGP SAFI=3 | Doesn't work | Doesn't work |
| IS-IS multi-topology | No | Yes |
| OSPF multi-topology | No | Few implem. |
+----------------------+--------------+--------------+
2.3. Learning (Active) Sources 2.3. Learning (Active) Sources
Typically, multicast routing protocols must either assume that the Typically, multicast routing protocols must either assume that the
receivers know the IP addresses of the (active) sources for a group receivers know the IP addresses of the (active) sources for a group
in advance, possibly using an out-of-band mechanism (SSM), or the in advance, possibly using an out-of-band mechanism (SSM), or the
sources must be discovered by the network protocols automatically transmissions are forwarded to the receivers automatically (ASM).
(ASM).
Learning active sources is a relatively straightforward process with Learning active sources is a relatively straightforward process with
a single PIM-SM domain and with a single RP, but having a single a single PIM-SM domain and with a single RP, but having a single
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.
skipping to change at page 10, line 11 skipping to change at page 12, line 7
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).
The model works by defining a single RP address for a particular The model works by defining a single RP address for a particular
group for all of the Internet, so there is no need to share state group for all of the Internet, so there is no need to share state
about that with any other RPs. If necessary, RP redundancy can still about that with any other RPs. If necessary, RP redundancy can still
be achieved with Anycast-RP using PIM. be achieved with Anycast-RP using PIM.
2.4. Configuring and Distributing PIM-SM RP Information 2.3.4. Summary
For PIM-SM, configuration mechanisms exist which are used to The following table summarizes the source discovery approaches and
configure the RP addresses and which groups are to use those RPs in their status.
the routers. This section outlines the approaches.
+------+------+------------------------------+
| IPv4 | IPv6 | Status |
+----------------------+------+------+------------------------------+
| Bi-dir single domain | Yes | Yes | OK but for intra-domain only |
| PIM-SM single domain | Yes | Yes | OK |
| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |
| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |
| SSM | Yes | Yes | No major uptake yet |
+----------------------+------+------+------------------------------+
2.4. Configuring and Distributing PIM RP Information
PIM-SM and Bi-dir PIM configuration mechanisms exist which are used
to configure the RP addresses and which groups are to use those RPs
in 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 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 (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 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, as a loopback interfaces of the routers currently acting as RPs, and
described in [RFC3446]. state is distributed using PIM [I-D.ietf-pim-anycast-rp] or MSDP
[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 11, line 33 skipping to change at page 13, line 45
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
using, for example if a router (maybe in customer's control) is using, for example if a router (maybe in customer's control) is
advertising itself inappropriately. All in all, while BSR and advertising itself inappropriately. All in all, while BSR and
Auto-RP provide easy configuration, they also provide very Auto-RP provide easy configuration, they also provide very
significant configuration and management complexity. significant configuration and management complexity.
It is worth noting that both Auto-RP and BSR were deployed before the It is worth noting that both Auto-RP and BSR were deployed before the
use of a manually configured anycast-RP address became relatively use of a manually configured anycast-RP address became relatively
commonplace, and there is actually relatively little need for them commonplace, and there is actually relatively little need for them
today. today unless there is a need to configure different properties (e.g.,
sparse, dense, bi-dir) in a dynamic fashion.
2.4.4. Summary
The following table summarizes the RP discovery mechanisms and their
status. With the exception of Embedded-RP, each mechanism operates
within a PIM domain.
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Static RP | Yes | Yes | Especially in ISPs |
| Auto-RP | Yes | No | Legacy deployment |
| BSR | Yes | Yes | Some, anycast simpler |
| Embedded-RP | No | Yes | Growing |
+--------------------+------+------+-----------------------+
2.5. Mechanisms for Enhanced Redundancy 2.5. Mechanisms for Enhanced Redundancy
A couple of mechanisms, already described in this document, have been A couple of mechanisms, already described in this document, have been
used as a means to enhance redundancy, resilience against failures, used as a means to enhance redundancy, resilience against failures,
and to recover from failures quickly. This section summarizes these and to recover from failures quickly. This section summarizes these
techniques explicitly. techniques explicitly.
2.5.1. Anycast RP 2.5.1. Anycast RP
skipping to change at page 12, line 22 skipping to change at page 14, line 49
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
significantly more extensive failure mitigation strategy, so today significantly more extensive failure mitigation strategy, so today
there is actually very little need to use stateless failover there is actually very little need to use stateless failover
mechanisms, especially dynamic ones, for redundancy purposes. mechanisms, especially dynamic ones, for redundancy purposes.
2.5.3. Bi-directional PIM 2.5.3. Bi-directional PIM
Because bi-directional PIM (see Section 2.1.3) does not switch to Because bi-directional PIM (see Section 2.1.3) does not switch to
shortest path tree (SPT), the final multicast tree is built faster shortest path tree (SPT), the final multicast tree is may be
and converges faster after failures. On the other hand, PIM-SM or established faster. On the other hand, PIM-SM or SSM may converge
SSM may converge more quickly especially in scenarios where bi- more quickly especially in scenarios (e.g., unicast routing change)
directional needs to re-do the Designated Forwarder election. where bi-directional needs to re-do the Designated Forwarder
election.
2.5.4. Summary
The following table summarizes the techniques for enhanced
redundancy.
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Anycast RP w/ MSDP | Yes | No | De-facto approach |
| Anycast RP w/ PIM | Yes | Yes | New, simpler than MSDP|
| Stateless RP fail. | Yes | Yes | Causes disturbance |
| Bi-dir PIM | Yes | Yes | Deployed at some sites|
+-------------+------+------+------------------------------+
2.6. Interactions with Hosts 2.6. Interactions with Hosts
Previous sections have dealt with the components required by routers Previous sections have dealt with the components required by routers
to be able to do multicast routing. Obviously, the real users of to be able to do multicast routing. Obviously, the real users of
multicast are the hosts: either sending or receiving multicast. This multicast are the hosts: either sending or receiving multicast. This
section describes the required interactions with hosts. section describes the required interactions with hosts.
2.6.1. Hosts Sending Multicast 2.6.1. Hosts Sending Multicast
After choosing a multicast group through a variety of means, hosts After choosing a multicast group through a variety of means, hosts
just send the packets to the link-layer multicast address, and the just send the packets to the link-layer multicast address, and the
designated router will receive all the multicast packets and start designated router will receive all the multicast packets and start
forwarding them as appropriate. forwarding them as appropriate.
ASM senders may move to a new IP address without significant impact In intra-domain or Embedded-RP scenarios, ASM senders may move to a
on the delivery of their transmission. SSM senders cannot change the new IP address without significant impact on the delivery of their
IP address unless receivers join the new channel or the sender uses transmission. SSM senders cannot change the IP address unless
an IP mobility technique that is transparent to the receivers. receivers join the new channel or the sender uses an IP mobility
technique that is transparent to the receivers.
2.6.2. Hosts Receiving Multicast 2.6.2. Hosts Receiving Multicast
Hosts signal their interest in receiving a multicast group or channel Hosts signal their interest in receiving a multicast group or channel
by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are
also commonplace, but most new deployments support the latest still commonplace, but are also often used in new deployments. Some
specifications. vendors also support SSM mapping techniques for receivers which use
an older IGMP/MLD version where the router maps the join request to
an SSM channel based on various, usually complex means of
configuration.
2.6.3. Summary
The following table summarizes the techniques host interaction.
+-------+------+----------------------+
| IPv4 | IPv6 | Notes |
+--------------------+-------+------+----------------------+
| Host sending | Yes | Yes | No support needed |
| Host receiving ASM | IGMP | MLD | Any IGMP/MLD version |
| Host receiving SSM | IGMPv3| MLDv2| Also SSM-mapping |
+--------------------+-------+------+----------------------+
2.7. Restricting Multicast Flooding in the Link Layer 2.7. Restricting Multicast Flooding in the Link Layer
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.
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 flooding between routers in a switched networks.
typically only considered a problem in some Ethernet-based Internet This is typically only considered a problem in some Ethernet-based
Exchange points. 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.tsenevir-pim-sm-snoop][I-D.serbest-l2vpn-vpls-mcast] to messages [I-D.tsenevir-pim-sm-snoop][I-D.serbest-l2vpn-vpls-mcast] to
achieve the same effect. 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.
IEEE specifications mention Group Address Resolution Protocol (GARP) IEEE 802.1D-2004 specification describes Generic Attribute
[GARP] as a link-layer method to perform the same functionality. The Registration Protocol (GARP), and GARP Multicast Registration
implementation status is unknown. Protocol (GMRP) [GMRP] is a link-layer multicast group application of
GARP that notifies switches about IP multicast group memberships.
GMRP requires support at the host stack and implementation status
especially on hosts is unknown. 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. Snooping switches also need to identify the ports also a challenge.
where routers reside (and therefore where to flood the packets) using
Multicast Router Discovery protocol [RFC4286], looking at certain Snooping switches also need to identify the ports where routers
IGMP queries [RFC4541], or by manual configuration. IGMP proxying reside and therefore where to flood the packets. This can be
[I-D.ietf-magma-igmp-proxy] is sometimes used either as a replacement accomplished using Multicast Router Discovery protocol [RFC4286],
of a multicast routing protocol on a small router, or to aggregate looking at certain IGMP queries [RFC4541], looking at PIM Hello and
IGMP/MLD reports when used with IGMP snooping. possibly other messages, or by manual configuration. An issue with
PIM snooping at LANs is that PIM messages can't be turned off or
encrypted, leading to security issues
[I-D.savola-pim-lasthop-threats].
IGMP proxying [I-D.ietf-magma-igmp-proxy] is sometimes used either as
a replacement of a multicast routing protocol on a small router, or
to aggregate IGMP/MLD reports when used with IGMP snooping.
2.7.3. Summary
The following table summarizes the techniques for multicast flooding
reduction inside a single link for router-to-router and last-hop
LANs.
+--------+-----+---------------------------+
| R-to-R | LAN | Notes |
+-----------------------+--------+-----+---------------------------+
| Cisco's RGMP | Yes | No | Replaced by PIM snooping |
| PIM snooping | Yes | No | Security issues in LANs |
| IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD bad |
| Multicast Router Disc | No | Yes | Few if any implem. yet |
| IEEE 802.1D-2004 GMRP | No | Yes | Impl. status unknown |
| Cisco's CGMP | No | Yes | Replaced by other 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 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, and Spencer Dawkins Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon
provided good comments, helping in improving this document. Chisholm, and John Zwiebel 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.
skipping to change at page 16, line 10 skipping to change at page 19, line 50
[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.
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 [GMRP] "GARP Multicast Registration Protocol",
of IEEE 802.1p GARP/GMRP Timer Values", 1997. <http://www.javvin.com/protocolGMRP.html>.
[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-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
 End of changes. 37 change blocks. 
129 lines changed or deleted 276 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/