draft-ietf-mboned-routingarch-12.txt   rfc5110.txt 
Internet Engineering Task Force P. Savola Network Working Group P. Savola
Internet-Draft CSC/FUNET Request for Comments: 5110 CSC/FUNET
Intended status: Best Current October 17, 2007 Category: Informational January 2008
Practice
Expires: April 19, 2008
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-12.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2008.
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
This document describes multicast routing architectures that are This document describes multicast routing architectures that are
currently deployed on the Internet. This document briefly describes currently deployed on the Internet. This document briefly describes
those protocols and references their specifications. those protocols and references their specifications.
This memo also reclassifies to Historic several older RFCs. These This memo also reclassifies several older RFCs to Historic. These
RFCs describe multicast routing protocols that were never widely RFCs describe multicast routing protocols that were never widely
deployed or have fallen into disuse. deployed or have fallen into disuse.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 1.1. Multicast-Related Abbreviations ............................4
2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 2. Multicast Routing ...............................................4
2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 2.1. Setting up Multicast Forwarding State ......................5
2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. PIM-SM ..............................................5
2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. PIM-DM ..............................................5
2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 7 2.1.3. Bidirectional PIM ...................................6
2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.4. DVMRP ...............................................6
2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.5. MOSPF ...............................................7
2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.6. BGMP ................................................7
2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.7. CBT .................................................7
2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8 2.1.8. Interactions and Summary ............................7
2.2. Distributing Topology Information . . . . . . . . . . . . 9 2.2. Distributing Topology Information ..........................8
2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9 2.2.1. Multiprotocol BGP ...................................8
2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 10 2.2.2. OSPF/IS-IS Multi-Topology Extensions ................9
2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 10 2.2.3. Issue: Overlapping Unicast/Multicast Topology .......9
2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.4. Summary ............................................10
2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 11 2.3. Learning (Active) Sources .................................10
2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.1. SSM ................................................11
2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2. MSDP ...............................................11
2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12 2.3.3. Embedded-RP ........................................11
2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4. Summary ............................................12
2.4. Configuring and Distributing PIM RP Information . . . . . 13 2.4. Configuring and Distributing PIM RP Information ...........12
2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . 14 2.4.3. BSR and Auto-RP ....................................13
2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.4. Summary ............................................14
2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 15 2.5. Mechanisms for Enhanced Redundancy ........................14
2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 15 2.5.1. Anycast RP .........................................14
2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 15 2.5.2. Stateless RP Failover ..............................14
2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15 2.5.3. Bidirectional PIM ..................................15
2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.4. Summary ............................................15
2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 16 2.6. Interactions with Hosts ...................................15
2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 16 2.6.1. Hosts Sending Multicast ............................15
2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16 2.6.2. Hosts Receiving Multicast ..........................15
2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 2.6.3. Summary ............................................16
2.7. Restricting Multicast Flooding in the Link Layer . . . . . 17 2.7. Restricting Multicast Flooding in the Link Layer ..........16
2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17 2.7.1. Router-to-Router Flooding Reduction ................16
2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17 2.7.2. Host/Router Flooding Reduction .....................17
2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 19 2.7.3. Summary ............................................18
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 3. Acknowledgements ...............................................18
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations ............................................18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations ........................................19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. References .....................................................19
6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 6.1. Normative References ......................................19
6.2. Informative References . . . . . . . . . . . . . . . . . . 21 6.2. Informative References ....................................20
Appendix A. Multicast Payload Transport Extensions . . . . . . . 24 Appendix A. Multicast Payload Transport Extensions.................24
A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 24 A.1. Reliable Multicast.........................................24
A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 24 A.2. Multicast Group Security...................................24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
This document provides a brief overview of multicast routing This document provides a brief overview of multicast routing
architectures that are currently deployed on the Internet and how architectures that are currently deployed on the Internet and how
those protocols fit together. It also describes those multicast those protocols fit together. It also describes those multicast
routing protocols that were never widely deployed or have fallen into routing protocols that were never widely deployed or have fallen into
disuse. A companion document [I-D.ietf-mboned-addrarch] describes disuse. A companion document [ADDRARCH] describes multicast
multicast addressing architectures. addressing architectures.
Specifically, this memo deals with: Specifically, 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 rendezvous point (RP) information o configuring and distributing the rendezvous point (RP) information
skipping to change at page 4, line 36 skipping to change at page 3, line 36
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).
Section 2 starts by describing a simplistic example how these classes Section 2 starts by describing a simplistic example how these classes
of mechanisms fit together. Some multicast data transport issues are of mechanisms fit together. Some multicast data transport issues are
also introduced in Appendix A. also introduced in Appendix A.
This memo re-classifies to Historic [RFC2026] the following RFCs: This memo reclassifies to Historic [RFC2026] the following RFCs:
o Border Gateway Multicast Protocol (BGMP) [RFC3913], o Border Gateway Multicast Protocol (BGMP) [RFC3913],
o Core Based Trees (CBT) [RFC2189] [RFC2201], o Core Based Trees (CBT) [RFC2189] [RFC2201],
o Multicast OSPF (MOSPF) [RFC1584]. o Multicast OSPF (MOSPF) [RFC1584].
For the most part, these protocols have fallen into disuse. There For the most part, these protocols have fallen into disuse. There
may be legacy deployments of some of these protocols, which are not may be legacy deployments of some of these protocols, which are not
affected by this reclassification. See Section 2.1 for more on each affected by this reclassification. See Section 2.1 for more on each
protocol. protocol.
Further historical perspective may be found in, for example, Further historical perspective may be found in, for example,
[RFC1458], [IMRP-ISSUES], and [IM-GAPS]. [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 Registration
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 Multiprotocol BGP (*not* "Multicast BGP")
MLD Multicast Listener Discovery MLD Multicast Listener Discovery
MRP (IEEE 802.1ak) Multiple Registration Protocol MRP (IEEE 802.1ak) Multiple Registration Protocol
MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto. MMRP (IEEE 802.1ak) Multicast Multiple Registration
Protocol
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
RPF Reverse Path Forwarding RPF Reverse Path Forwarding
SAFI Subsequent Address Family Identifier SAFI Subsequent Address Family Identifier
SDP Session Description Protocol SDP Session Description Protocol
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 In order to give a simplified summary how each of these class of
mechanisms fits together, consider the following multicast receiver mechanisms fits together, consider the following multicast receiver
scenario. scenario.
Certain protocols and configuration needs to be in place before Certain protocols and configurations need to be in place before
multicast routing can work. Specifically, when ASM is employed, a multicast routing can work. Specifically, when ASM is employed, a
router will need to know its RP address(es) (Section 2.4, router will need to know its RP address(es) (Section 2.4,
Section 2.5). With IPv4, RPs need to be connected to other RPs using Section 2.5). With IPv4, RPs need to be connected to other RPs using
MSDP so information about sources connected to other RPs can be MSDP so information about sources connected to other RPs can be
distributed (Section 2.3). Further, routers need to know if or how distributed (Section 2.3). Further, routers need to know if or how
multicast topology differs from unicast topology, and routing multicast topology differs from unicast topology, and routing
protocol extensions can provide that information (Section 2.2). protocol extensions can provide that information (Section 2.2).
When a host wants to receive a transmission, it first needs to find When a host wants to receive a transmission, it first needs to find
out the multicast group address (and with SSM, source address) using out the multicast group address (and with SSM, source address) using
skipping to change at page 6, line 35 skipping to change at page 5, line 38
(ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is (ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is
a subset of PIM-SM that does not use the RPs but instead requires a subset of PIM-SM that does not use the RPs but instead requires
that receivers know the (source,group) pair and signal that that receivers know the (source,group) pair and signal that
explicitly. Most current routing platforms support PIM-SM. explicitly. Most current routing platforms support PIM-SM.
PIM routers elect a designated router on each LAN and the DR is PIM routers elect a designated router on each LAN and the DR is
responsible for PIM messaging and source registration on behalf of responsible for PIM messaging and source registration on behalf of
the hosts. The DR encapsulates multicast packets sourced from the the hosts. The DR encapsulates multicast packets sourced from the
LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional, LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional,
group-specific distribution tree consisting of the interested group-specific distribution tree consisting of the interested
receivers of a group. Initially the multicast distribution tree is receivers of a group. Initially, the multicast distribution tree is
rooted at the RP but later the DRs have the option of optimizing the rooted at the RP but later the DRs have the option of optimizing the
delivery by building (source,group)-specific trees. delivery by building (source,group)-specific trees.
A more lengthy introduction to PIM-SM can be found in Section 3 of A more lengthy introduction to PIM-SM can be found in Section 3 of
[RFC4601]. [RFC4601].
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
skipping to change at page 7, line 23 skipping to change at page 6, line 25
to PIM-SM was easy as PIM-SM was designed to use compatible packet 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 formats and dense-mode operation could also be satisfied by a sparse
protocol. PIM-DM is no longer in widespread use. protocol. PIM-DM is no longer in widespread use.
Many implementations also support so-called "sparse-dense" Many implementations also support so-called "sparse-dense"
configuration, where Sparse mode is used by default, but Dense is configuration, where Sparse mode is used by default, but Dense is
used for configured multicast group ranges (such as Auto-RP in used for configured multicast group ranges (such as Auto-RP in
Section 2.4.3) only. Lately, many networks have transitioned away Section 2.4.3) only. Lately, many networks have transitioned away
from sparse-dense to only sparse mode. from sparse-dense to only sparse mode.
2.1.3. Bi-directional PIM 2.1.3. Bidirectional PIM
Bi-directional PIM [RFC5015] is a multicast forwarding protocol that Bidirectional PIM [RFC5015] is a multicast forwarding protocol that
establishes a common shared-path for all sources with a single root. establishes a common shared-path for all sources with a single root.
It can be used as an alternative to PIM-SM inside a single domain. It can be used as an alternative to PIM-SM inside a single domain.
It doesn't have data-driven events or data-encapsulation. As it It doesn't have data-driven events or data-encapsulation. As it
doesn't keep source-specific state, it may be an appealing approach doesn't keep source-specific state, it may be an appealing approach
especially in sites with a large number of sources. especially in sites with a large number of sources.
As of this writing, there is no inter-domain solution to configure a As of this writing, there is no inter-domain solution to configure a
group range to use bi-directional PIM. group range to use bidirectional 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 [DVMRPv3] [DVMRPv3-AS] was the first protocol designed for
protocol designed for multicasting. To get around initial deployment multicasting. To get around initial deployment hurdles, it also
hurdles, it also included tunneling capabilities which were part of included tunneling capabilities, which were part of its multicast
its multicast topology functions. topology functions.
Currently, DVMRP is used only very rarely in operator networks, Currently, DVMRP is used only very rarely in operator networks,
having been replaced with PIM-SM. The most typical deployment of having been replaced with PIM-SM. The most typical deployment of
DVMRP is at a leaf network, to run from a legacy firewall only DVMRP is at a leaf network, to run from a legacy firewall only
supporting DVMRP to the internal network. However, Generic Routing supporting DVMRP to the internal network. However, Generic Routing
Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP
in this functionality, and there is relatively little use for DVMRP in this functionality, and there is relatively little use for DVMRP
except in legacy deployments. except in legacy deployments.
2.1.5. MOSPF 2.1.5. MOSPF
skipping to change at page 8, line 33 skipping to change at page 7, line 33
CBT [RFC2201][RFC2189] was an academic project that provided the CBT [RFC2201][RFC2189] was an academic project that provided the
basis for PIM sparse mode shared trees. Once the shared tree basis for PIM sparse mode shared trees. Once the shared tree
functionality was incorporated into PIM implementations, there was no functionality was incorporated into PIM implementations, there was no
longer a need for a production CBT implementation. Therefore, CBT longer a need for a production CBT implementation. Therefore, CBT
never saw production 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 bidirectional 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
protocols have been outlined in [RFC2715]. 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 | | Inter-domain | Intra-domain | Status |
+------------+-------------+-------------+----------------+ +------------+--------------+--------------+----------------+
| PIM-SM | Yes | Yes | Active | | PIM-SM | Yes | Yes | Active |
| PIM-DM | Not anymore | Not anymore | Little use | | PIM-DM | Not anymore | Not anymore | Little use |
| Bi-dir PIM | No | Yes | Some uptake | | BIDIR-PIM | No | Yes | Some uptake |
| DVMRP | Not anymore | Stub only | Going out | | DVMRP | Not anymore | Stub only | Going out |
| MOSPF | 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.
2.2. Distributing Topology Information 2.2. Distributing Topology Information
PIM has become the de-facto multicast forwarding protocol, but as its PIM has become the de-facto multicast forwarding protocol, but as its
name implies, it is independent of the underlying unicast routing name implies, it is independent of the underlying unicast routing
protocol. When unicast and multicast topologies are the same protocol. When unicast and multicast topologies are the same
skipping to change at page 9, line 33 skipping to change at page 8, line 44
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
applying it to the Reverse Path Forwarding (RPF) check. applying it to the Reverse Path Forwarding (RPF) check.
This subsection introduces these protocols. This subsection introduces these protocols.
2.2.1. Multi-protocol BGP 2.2.1. Multiprotocol BGP
Multiprotocol Extensions for BGP-4 [RFC4760] (often referred to as Multiprotocol Extensions for BGP-4 [RFC4760] (often referred to as
"MBGP"; however, it is worth noting that "MBGP" does *not* stand for "MBGP"; however, it is worth noting that "MBGP" does *not* stand for
"Multicast BGP") specifies a mechanism by which BGP can be used to "Multicast BGP") specifies a mechanism by which BGP can be used to
distribute different reachability information for unicast (SAFI=1) distribute different reachability information for unicast (SAFI=1)
and multicast traffic (SAFI=2). Multiprotocol BGP has been widely and multicast traffic (SAFI=2). Multiprotocol BGP has been widely
deployed for years, and is also needed to route IPv6. Note that deployed for years, and is also needed to route IPv6. Note that
SAFI=3 was originally specified for "both unicast and multicast" but SAFI=3 was originally specified for "both unicast and multicast" but
has since then been deprecated. has since then been deprecated.
These extensions are in widespread use wherever BGP is used to These extensions are in widespread use wherever BGP is used to
distribute unicast topology information. Multicast-enabled networks distribute unicast topology information. Multicast-enabled networks
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 Interior Gateway Protocols (IGPs) also provide Similar to BGP, some Interior Gateway Protocols (IGPs) also provide
the capability for signalling differing topologies, for example IS-IS the capability for signalling differing topologies, for example IS-IS
multi-topology extensions [I-D.ietf-isis-wg-multi-topology]. These multi-topology extensions [M-ISIS]. These can be used for a
can be used for a multicast topology that differs from unicast. multicast topology that differs from unicast. Similar but not so
Similar but not so widely implemented work exists for OSPF [RFC4915]. widely implemented work exists for OSPF [RFC4915].
It is worth noting that interdomain incongruence and intradomain It is worth noting that inter-domain incongruence and intra-domain
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, inter-domain incongruence is quite common, while intra-
intradomain incongruence isn't, so you see much more deployment of domain incongruence isn't, so you see much more deployment of MBGP
MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well than MT-ISIS/OSPF. Commonly deployed networks have managed well
without protocols handling intradomain incongruence. However, the without protocols handling intra-domain 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.
2.2.3. Issue: Overlapping Unicast/multicast Topology 2.2.3. Issue: Overlapping Unicast/Multicast Topology
An interesting case occurs when some routers do not distribute An interesting case occurs when some routers do not distribute
multicast topology information explicitly while others do. In multicast topology information explicitly while others do. In
particular, this happens when some multicast sites in the Internet particular, this happens when some multicast sites in the Internet
are using plain BGP while some use MBGP. are using plain BGP while some use MBGP.
Different implementations deal with this in different ways. Different implementations deal with this in different ways.
Sometimes, multicast RPF mechanisms first look up the multicast Sometimes, multicast RPF mechanisms first look up the multicast
routing table, or M-RIB ("topology database") with a longest prefix routing table, or M-RIB ("topology database") with a longest prefix
match algorithm, and if they find any entry (including a default match algorithm, and if they find any entry (including a default
skipping to change at page 11, line 5 skipping to change at page 10, line 18
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 2.2.4. Summary
A congruent topology can be deployed using unicast routing protocols A congruent topology can be deployed using unicast routing protocols
that provide no support for a separate multicast topology. In intra- that provide no support for a separate multicast topology. In intra-
domain that approach is often adequate. However, it is recommended domain that approach is often adequate. However, it is recommended
that if interdomain routing uses BGP, multicast-enabled sites should that if inter-domain routing uses BGP, multicast-enabled sites should
use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the
topology was congruent to explicitly signal "yes, we use multicast". topology was congruent to explicitly signal "yes, we use multicast".
The following table summarizes the approaches that can be used to The following table summarizes the approaches that can be used to
distribute multicast topology information. distribute multicast topology information.
+----------------+---------------+ +----------------+--------------+
| Interdomain | Intradomain | | Inter-domain | Intra-domain |
+--------------------- +----------------+--------------+ +--------------------- +----------------+--------------+
| MP-BGP SAFI=2 | Yes | Yes | | MP-BGP SAFI=2 | Yes | Yes |
| MP-BGP SAFI=3 | Doesn't work | Doesn't work | | MP-BGP SAFI=3 | Doesn't work | Doesn't work |
| IS-IS multi-topology | Not applicable | Yes | | IS-IS multi-topology | Not applicable | Yes |
| OSPF multi-topology | Not applicable | Few implem. | | OSPF multi-topology | Not applicable | Few implem. |
+----------------------+----------------+--------------+ +----------------------+----------------+--------------+
"Not applicable" refers to the fact that IGP protocols can't be used "Not applicable" refers to the fact that IGP protocols can't be used
in interdomain routing. "Doesn't work" means that while MP-BGP in inter-domain routing. "Doesn't work" means that while MP-BGP
SAFI=3 was defined and could apply, that part of the specification SAFI=3 was defined and could apply, that part of the specification
has not been implemented and can't be used in practice. "Yes" lists has not been implemented and can't be used in practice. "Yes" lists
the mechanisms which are generally applicable and known to work. the mechanisms which are generally applicable and known to work.
"Few implem." means that the approach could work but is not commonly "Few implem." means that the approach could work but is not commonly
available. available.
2.3. Learning (Active) Sources 2.3. Learning (Active) Sources
To build a multicast distribution tree, the routing protocol needs to To build a multicast distribution tree, the routing protocol needs to
find out where the sources for the group are. In case of SSM, the find out where the sources for the group are. In case of SSM, the
user specifies the source IP address or it is otherwise learned out user specifies the source IP address or it is otherwise learned out
of band. of band.
In ASM, the RPs know about all the active sources in a local PIM In ASM, the RPs know about all the active sources in a local PIM
domain. As a result, when PIM-SM or bi-dir PIM is used in intra- domain. As a result, when PIM-SM or BIDIR-PIM is used in intra-
domain the sources are learned as a feature of the protocol itself. domain the sources are learned as a feature of the protocol itself.
Having a single PIM-SM domain for the whole Internet is an Having a single PIM-SM domain for the whole Internet is an
insufficient model for many reasons, including scalability, insufficient model for many reasons, including scalability,
administrative boundaries and different technical tradeoffs. administrative boundaries, and different technical tradeoffs.
Therefore it is required to be able to split up the multicast routing Therefore, it is required to be able to split up the multicast
infrastructures to smaller domains, and there must be a way to share routing infrastructures to smaller domains, and there must be a way
information about active sources using some mechanism if the ASM to share information about active sources using some mechanism if the
model is to be supported. ASM model is to be supported.
This section discusses the options of learning active sources that This section discusses the options of learning active sources that
apply in an inter-domain environment. apply in an inter-domain environment.
2.3.1. SSM 2.3.1. SSM
Source-specific Multicast [RFC4607] (sometimes also referred to as Source-specific Multicast [RFC4607] (sometimes also referred to as
"single-source Multicast") does not count on learning active sources "single-source Multicast") does not count on learning active sources
in the network. Recipients need to know the source IP addresses in the network. Recipients need to know the source IP addresses
using an out of band mechanism which are used to subscribe to the using an out of band mechanism which are used to subscribe to the
(source, group) channel. The multicast routing uses the source (source, group) channel. The multicast routing uses the 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]. [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 [RFC4610]. See Section 2.5 same can be achieved using PIM extensions [RFC4610]. 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 [I-D.ietf-mboned-ipv6-multicast-issues]. and Embedded-RP [MCAST-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).
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
skipping to change at page 13, line 8 skipping to change at page 12, line 18
be achieved with Anycast-RP using PIM [RFC4610]. be achieved with Anycast-RP using PIM [RFC4610].
2.3.4. Summary 2.3.4. Summary
The following table summarizes the source discovery approaches and The following table summarizes the source discovery approaches and
their status. their status.
+------+------+------------------------------+ +------+------+------------------------------+
| IPv4 | IPv6 | Status | | IPv4 | IPv6 | Status |
+----------------------+------+------+------------------------------+ +----------------------+------+------+------------------------------+
| Bi-dir single domain | Yes | Yes | OK but for intra-domain only | | Bidir single domain | Yes | Yes | OK but for intra-domain only |
| PIM-SM single domain | Yes | Yes | OK | | PIM-SM single domain | Yes | Yes | OK |
| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM | | PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |
| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option | | PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |
| SSM | Yes | Yes | No major uptake yet | | SSM | Yes | Yes | No major uptake yet |
+----------------------+------+------+------------------------------+ +----------------------+------+------+------------------------------+
2.4. Configuring and Distributing PIM RP Information 2.4. Configuring and Distributing PIM RP Information
PIM-SM and Bi-dir PIM configuration mechanisms exist which are used PIM-SM and BIDIR-PIM configuration mechanisms exist, which are used
to configure the RP addresses and the groups that are to use those to configure the RP addresses and the groups that are to use those
RPs in the routers. This section outlines the approaches. RPs in the routers. This section outlines the approaches.
2.4.1. Manual RP Configuration 2.4.1. Manual RP Configuration
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
skipping to change at page 13, line 39 skipping to change at page 12, line 49
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 (e.g., 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 interface of the routers currently acting as RPs, and
state is distributed using PIM [RFC4610] or MSDP [RFC3446]. state is distributed using PIM [RFC4610] 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 that are delegated to those who use the RP, so unless
unless no other ASM than Embedded-RP is used, the network no other ASM than Embedded-RP is used, the network administrator only
administrator only needs to configure the RP routers. needs to configure the RP routers.
While Embedded-RP in many cases is sufficient for IPv6, other methods While Embedded-RP in many cases is sufficient for IPv6, other methods
of RP configuration are needed if one needs to provide ASM service of RP configuration are needed if one needs to provide ASM service
for other than Embedded-RP group addresses. In particular, service for other than Embedded-RP group addresses. In particular, service
discovery type of applications may need hard-coded addresses that are discovery type of applications may need hard-coded addresses that are
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 [RFC5059] is a mechanism for configuring the RP address for
address for groups. It may no longer be in as wide use with IPv4 as groups. It may no longer be in as wide use with IPv4 as it was
it was earlier, and for IPv6, Embedded-RP will in many cases be 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
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 unless there is a need to configure different properties (e.g., today unless there is a need to configure different properties (e.g.,
sparse, dense, bi-dir) in a dynamic fashion. sparse, dense, bidirectional) in a dynamic fashion.
2.4.4. Summary 2.4.4. Summary
The following table summarizes the RP discovery mechanisms and their The following table summarizes the RP discovery mechanisms and their
status. With the exception of Embedded-RP, each mechanism operates status. With the exception of Embedded-RP, each mechanism operates
within a PIM domain. within a PIM domain.
+------+------+-----------------------+ +------+------+-----------------------+
| IPv4 | IPv6 | Deployment | | IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+ +--------------------+------+------+-----------------------+
skipping to change at page 15, line 18 skipping to change at page 14, line 32
Having only one RP in a PIM-SM domain would be a single point of Having only one RP in a PIM-SM domain would be a single point of
failure for the whole multicast domain. As a result, a number of failure for the whole multicast domain. As a result, a number of
mechanisms have been developed to either eliminate the RP mechanisms have been developed to either eliminate the RP
functionality or to enhance RPs' redundancy, resilience against functionality or to enhance RPs' redundancy, resilience against
failures, and to recover from failures quickly. This section failures, and to recover from failures quickly. This section
summarizes these techniques explicitly. summarizes these 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, e.g., for
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 [RFC4610] also provide this functionality. In Recent PIM extensions [RFC4610] also provide this functionality. In
contrast to MSDP, this approach works for both IPv4 and IPv6. contrast to MSDP, this approach works for both IPv4 and IPv6.
2.5.2. Stateless RP Failover 2.5.2. Stateless RP Failover
While Anycast RP shares state between RPs so that RP failure causes While Anycast RP shares state between RPs so that RP failure causes
skipping to change at page 15, line 40 skipping to change at page 15, line 5
more limited resiliency. A traditional mechanism has been to use more limited resiliency. A traditional mechanism has been to use
Auto-RP or BSR (see Section 2.4.3) to select another RP when the Auto-RP or BSR (see Section 2.4.3) to select another RP when the
active one failed. However, the same functionality could be achieved active one failed. However, the same functionality could be achieved
using a shared-unicast RP address ("anycast RP without state using a shared-unicast RP address ("anycast RP without state
sharing") without the complexity of a dynamic mechanism. Further, sharing") without the complexity of a dynamic mechanism. Further,
Anycast RP offers a significantly more extensive failure mitigation Anycast RP offers a significantly more extensive failure mitigation
strategy, so today there is actually very little need to use strategy, so today there is actually very little need to use
stateless failover mechanisms, especially dynamic ones, for stateless failover mechanisms, especially dynamic ones, for
redundancy purposes. redundancy purposes.
2.5.3. Bi-directional PIM 2.5.3. Bidirectional PIM
Because bi-directional PIM (see Section 2.1.3) does not switch to Because bidirectional PIM (see Section 2.1.3) does not switch to
shortest path tree (SPT), the final multicast tree may be established shortest path tree (SPT), the final multicast tree may be established
faster. On the other hand, PIM-SM or SSM may converge more quickly faster. On the other hand, PIM-SM or SSM may converge more quickly
especially in scenarios (e.g., unicast routing change) where bi- especially in scenarios (e.g., unicast routing change) where
directional needs to re-do the Designated Forwarder election. bidirectional needs to re-do the Designated Forwarder election.
2.5.4. Summary 2.5.4. Summary
The following table summarizes the techniques for enhanced The following table summarizes the techniques for enhanced
redundancy. redundancy.
+------+------+-----------------------+ +------+------+-----------------------+
| IPv4 | IPv6 | Deployment | | IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+ +--------------------+------+------+-----------------------+
| Anycast RP w/ MSDP | Yes | No | De-facto approach | | Anycast RP w/ MSDP | Yes | No | De-facto approach |
| Anycast RP w/ PIM | Yes | Yes | Newer approach | | Anycast RP w/ PIM | Yes | Yes | Newer approach |
| Stateless RP fail. | Yes | Yes | Causes disturbance | | Stateless RP fail. | Yes | Yes | Causes disturbance |
| Bi-dir PIM | Yes | Yes | Deployed at some sites| | BIDIR-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
skipping to change at page 17, line 44 skipping to change at page 17, line 6
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 [PIM-SNOOP].
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. Implementations of CGMP do not support fast leave receive a group. Implementations of CGMP do not support fast leave
skipping to change at page 18, line 17 skipping to change at page 17, line 28
IGMPv2, multicast is still flooded to ports which were once members 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. of a group as long as there is at least one receiver on the link.
Flooding restrictions are done based on multicast MAC addresses. Flooding restrictions are done based on multicast MAC addresses.
Implementations of CGMP do not support IPv6. Implementations of CGMP do not support IPv6.
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 MAC multicast group memberships. GARP that notifies switches about MAC multicast group memberships.
If GMRP is used in conjunction with IP multicast, then the GMRP If GMRP is used in conjunction with IP multicast, then the GMRP
registration function would become associated with an IGMP "join." registration function would become associated with an IGMP "join".
However, this GMRP-IGMP association is beyond the scope of GMRP. 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 802.1 considers GARP and GMRP obsolete implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete
being replaced by Multiple Registration Protocol (MRP) and Multicast being replaced by Multiple Registration Protocol (MRP) and Multicast
Multiple Registration Protocol (MMRP) that are being specified in Multiple Registration Protocol (MMRP) that are being specified in
IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between
bridges. Some further information about GARP/GMRP is also available bridges. Some further information about GARP/GMRP is also available
in Appendix B of [RFC3488]. 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
skipping to change at page 18, line 43 skipping to change at page 18, line 5
snooping. In the worst case, enabling IGMP snooping on a switch that snooping. In the worst case, enabling IGMP snooping on a switch that
does not support IGMPv3 snooping breaks multicast capabilities of does not support IGMPv3 snooping breaks multicast capabilities of
nodes using IGMPv3. nodes using IGMPv3.
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 [I-D.ietf-pim-lasthop-threats]. encrypted, leading to security issues [PIM-THREATS].
IGMP proxying [RFC4605] is sometimes used either as a replacement of IGMP proxying [RFC4605] is sometimes used either as a replacement of
a multicast routing protocol on a small router, or to aggregate IGMP/ a multicast routing protocol on a small router, or 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.
skipping to change at page 19, line 37 skipping to change at page 18, line 43
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, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica,
Prashant Jhingran, and Tim Polk provided good comments, helping in Prashant Jhingran, and Tim Polk provided good comments, helping in
improving this document. improving this document.
4. IANA Considerations 4. IANA Considerations
IANA is requested to update the following registries by adding a IANA has updated the following registries by adding a reference to
reference to this document: this document:
o OSPFv2 Option registry: MC-bit o OSPFv2 Options Registry: MC-bit
o OSPFv2 Link state type: Group-membership-LSA o OSPFv2 Link State (LS) Type: Group-membership-LSA
o OSPFv2 Router properties registry: W-bit (0x08) o OSPFv2 Router Properties Registry: W-bit
o OSPFv3 Options Registry: MC-bit
o OSPFv3 Option registry: MC-bit o OSPFv3 LSA Function Code Registry: Group-membership-LSA
o OSPFv3 LSA function code registry: Group-membership-LSA
o OSPFv3 Prefix Options Registry: MC-bit o OSPFv3 Prefix Options Registry: MC-bit
(To be removed prior to publication as an RFC: IANA is also requested
to correct a typo in OSPFv2 Router properties registry: The first
W-bit (0x02) entry should be renamed to 'E-bit' as described in RFC
2328 section A.4.2.)
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 [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and infrastructures [RFC4609], IGMP/MLD [MLD-SEC], and PIM last-hop
PIM last-hop issues [I-D.ietf-pim-lasthop-threats]. issues [PIM-THREATS].
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996. Revision 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
Thyagarajan, "Internet Group Management Protocol, Version A. Thyagarajan, "Internet Group Management Protocol,
3", RFC 3376, October 2002. Version 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.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I.
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Kouvelas, "Protocol Independent Multicast - Sparse
Protocol Specification (Revised)", RFC 4601, August 2006. Mode (PIM-SM): Protocol Specification (Revised)",
RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast
IP", RFC 4607, August 2006. for IP", RFC 4607, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", P. Pillay-Esnault, "Multi-Topology (MT) Routing in
RFC 4915, June 2007. OSPF", RFC 4915, June 2007.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L.
"Bidirectional Protocol Independent Multicast (BIDIR- Vicisano, "Bidirectional Protocol Independent
PIM)", RFC 5015, October 2007. Multicast (BIDIR-PIM)", RFC 5015, October 2007.
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>.
[ADDRARCH] Savola, P., "Overview of the Internet Multicast
Addressing Architecture", Work in Progress,
October 2006.
[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", [DVMRPv3] Pusateri, T., "Distance Vector Multicast Routing
<http://www.javvin.com/protocolGMRP.html>. Protocol", Work in Progress, December 2003.
[I-D.daley-magma-smld-prob]
Daley, G. and G. Kurup, "Trust Models and Security in
Multicast Listener Discovery",
draft-daley-magma-smld-prob-00 (work in progress),
July 2004.
[I-D.ietf-idmr-dvmrp-v3]
Pusateri, T., "Distance Vector Multicast Routing
Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress),
December 2003.
[I-D.ietf-idmr-dvmrp-v3-as] [DVMRPv3-AS] Pusateri, T., "Distance Vector Multicast Routing
Pusateri, T., "Distance Vector Multicast Routing Protocol Protocol Applicability Statement", Work in Progress,
Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 May 2004.
(work in progress), May 2004.
[I-D.ietf-isis-wg-multi-topology] [DYNSSM-REQ] Lehtonen, R., Venaas, S., and M. Hoerdt,
Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in "Requirements for discovery of dynamic SSM sources",
IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in Work in Progress, February 2005.
progress), October 2005.
[I-D.ietf-l2vpn-vpls-pim-snooping] [GMRP] "GARP Multicast Registration Protocol",
Hemige, V., "PIM Snooping over VPLS", <http://www.javvin.com/protocolGMRP.html>.
draft-ietf-l2vpn-vpls-pim-snooping-01 (work in progress),
March 2007.
[I-D.ietf-mboned-addrarch] [IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap
Savola, P., "Overview of the Internet Multicast Addressing Analysis from the MBONED Working Group for the IESG
Architecture", draft-ietf-mboned-addrarch-05 (work in [Expired]", Work in Progress, July 2002.
progress), October 2006.
[I-D.ietf-mboned-ipv6-multicast-issues] [IMRP-ISSUES] Meyer, D., "Some Issues for an Inter-domain Multicast
Savola, P., "IPv6 Multicast Deployment Issues", Routing Protocol", Work in Progress, November 1997.
draft-ietf-mboned-ipv6-multicast-issues-02 (work in
progress), February 2005.
[I-D.ietf-pim-lasthop-threats] [M-ISIS] Przygienda, T., "M-ISIS: Multi Topology (MT) Routing
Savola, P. and J. Lingard, "Host Threats to Protocol in IS-IS", Work in Progress, November 2007.
Independent Multicast (PIM)",
draft-ietf-pim-lasthop-threats-03 (work in progress),
October 2007.
[I-D.ietf-pim-sm-bsr] [MCAST-ISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work
Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", in Progress, February 2005.
draft-ietf-pim-sm-bsr-12 (work in progress), August 2007.
[I-D.lehtonen-mboned-dynssm-req] [MLD-SEC] Daley, G. and G. Kurup, "Trust Models and Security in
Lehtonen, R., "Requirements for discovery of dynamic SSM Multicast Listener Discovery", Work in Progress,
sources", draft-lehtonen-mboned-dynssm-req-00 (work in July 2004.
progress), February 2005.
[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap [PIM-SNOOP] Hemige, V., "PIM Snooping over VPLS", Work
Analysis from the MBONED Working Group for the IESG in Progress, March 2007.
[Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work
in progress), July 2002.
[IMRP-ISSUES] [PIM-THREATS] Savola, P. and J. Lingard, "Host Threats to Protocol
Meyer, D., "Some Issues for an Inter-domain Multicast Independent Multicast (PIM)", Work in Progress,
Routing Protocol [Expired]", October 2007.
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,
Vector Multicast Routing Protocol", RFC 1075, "Distance Vector Multicast Routing Protocol",
November 1988. RFC 1075, November 1988.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting",
RFC 1112, August 1989. STD 5, RFC 1112, August 1989.
[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast [RFC1458] Braudes, B. and S. Zabele, "Requirements for
Protocols", RFC 1458, May 1993. 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.
[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2)
Routing -- Protocol Specification --", RFC 2189, Multicast Routing -- Protocol Specification --",
September 1997. RFC 2189, September 1997.
[RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast
Architecture", RFC 2201, September 1997. Routing Architecture", RFC 2201, September 1997.
[RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing [RFC2715] Thaler, D., "Interoperability Rules for Multicast
Protocols", RFC 2715, October 1999. Routing Protocols", RFC 2715, October 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)",
March 2000. RFC 2784, March 2000.
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci,
Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, D., Lin, S., Leshchiner, D., Luby, M., Montgomery,
L., Tweedly, A., Bhaskar, N., Edmonstone, R., T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone,
Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport R., Sumanasekera, R., and L. Vicisano, "PGM Reliable
Protocol Specification", RFC 3208, December 2001. Transport Protocol Specification", RFC 3208,
December 2001.
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
Rendevous Point (RP) mechanism using Protocol Independent "Anycast Rendevous Point (RP) mechanism using
Multicast (PIM) and Multicast Source Discovery Protocol Protocol Independent Multicast (PIM) and Multicast
(MSDP)", RFC 3446, January 2003. Source Discovery Protocol (MSDP)", RFC 3446,
January 2003.
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port
Management Protocol (RGMP)", RFC 3488, February 2003. Group Management Protocol (RGMP)", RFC 3488,
February 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group
Architecture", RFC 3740, March 2004. Security Architecture", RFC 3740, March 2004.
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): [RFC3913] Thaler, D., "Border Gateway Multicast Protocol
Protocol Specification", RFC 3913, September 2004. (BGMP): Protocol Specification", RFC 3913,
September 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.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", [RFC4286] Haberman, B. and J. Martin, "Multicast Router
RFC 4286, December 2005. Discovery", 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
(IGMP) and Multicast Listener Discovery (MLD) Snooping Protocol (IGMP) and Multicast Listener Discovery
Switches", RFC 4541, May 2006. (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Description Protocol", RFC 4566, July 2006. Session Description Protocol", RFC 4566, July 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) /
Listener Discovery (MLD)-Based Multicast Forwarding Multicast Listener Discovery (MLD)-Based Multicast
("IGMP/MLD Proxying")", RFC 4605, August 2006. Forwarding ("IGMP/MLD Proxying")", RFC 4605,
August 2006.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM)
Routing Security Issues and Enhancements", RFC 4609, Multicast Routing Security Issues and Enhancements",
October 2006. RFC 4609, October 2006.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610, August 2006. Independent Multicast (PIM)", RFC 4610, August 2006.
[RITVANEN] [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
Ritvanen, K., "Multicast Routing and Addressing", HUT "Bootstrap Router (BSR) Mechanism for Protocol
Independent Multicast (PIM)", RFC 5059, January 2008.
[RITVANEN] 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 specified to improve the A couple of mechanisms have been specified to improve the
characteristics of the data that can be transported over multicast. characteristics of the data that can be transported over multicast.
We describe those mechanisms that have impact on the multicast We describe those mechanisms that have impact on the multicast
routing infrastructure, e.g., require or specify router assistance or routing infrastructure, e.g., require or specify router assistance or
involvement in some form. Purely end-to-end or host-based protocols involvement in some form. Purely end-to-end or host-based protocols
are out of scope. are out of scope.
skipping to change at page 25, line 12 skipping to change at page 24, line 42
multicast groups can be ensured using cryptographic techniques multicast groups can be ensured using cryptographic techniques
[RFC3740]. [RFC3740].
Author's Address Author's Address
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 IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 26, line 44 skipping to change at line 1101
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 100 change blocks. 
287 lines changed or deleted 242 lines changed or added

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