draft-ietf-mboned-routingarch-08.txt   draft-ietf-mboned-routingarch-09.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: June 14, 2007 Obsoletes: August 3, 2007
3913,2189,2201,1584,1585 3913,2189,2201,1584,1585
(if approved) (if approved)
Intended status: Best Current Intended status: Best Current
Practice Practice
Expires: December 16, 2007 Expires: February 4, 2008
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-08.txt draft-ietf-mboned-routingarch-09.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 16, 2007. This Internet-Draft will expire on February 4, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The lack of up-to-date documentation on IP multicast routing This document describes multicast routing architectures that are
protocols and procedures has caused a great deal of confusion. To currently deployed on the Internet. This document briefly describes
clarify the situation, this memo describes the routing protocols and those protocols and references their specifications.
techniques currently (as of this writing) in use. This memo also
Obsoletes and reclassifies to Historic a number of older multicast This memo also obsoletes and reclassifies to Historic several older
protocols. RFCs. These RFCs describe multicast routing protocols that were
never widely deployed or have fallen into disuse.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5
2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6
2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 7
2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8
2.2. Distributing Topology Information . . . . . . . . . . . . 8 2.2. Distributing Topology Information . . . . . . . . . . . . 8
2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9
2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 9 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 9
2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 9 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 10
2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 11
2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12
2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Configuring and Distributing PIM RP Information . . . . . 12 2.4. Configuring and Distributing PIM RP Information . . . . . 12
2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12 2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12
2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13
2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13
2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14
2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14
2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14
2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 14 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15
2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15
2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15
2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15
2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16
2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16
2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16
2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17
2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17
2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . . 19 6.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Multicast Payload Transport Extensions . . . . . . . 22 Appendix A. Multicast Payload Transport Extensions . . . . . . . 23
A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23
A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction 1. Introduction
Good, up-to-date documentation of IP multicast is close to non- This document provides a brief overview of multicast routing
existent. This issue is severely felt with multicast routing architectures that are currently deployed on the Internet and how
protocols and techniques. The consequence is that those who wish to those protocols fit together. It also describes those multicast
learn of IP multicast and how the routing works in the real world do routing protocols that were never widely deployed or have fallen into
not know where to begin. Multicast addressing is described in a disuse. A companion document [I-D.ietf-mboned-addrarch] describes
companion document [I-D.ietf-mboned-addrarch]. multicast addressing architectures.
The aim of this document is to provide a brief overview of multicast
routing protocols and techniques.
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 PIM RP information (Section 2.4), o configuring and distributing the PIM RP information (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).
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 obsoletes and re-classifies to Historic [RFC2026] Border This memo obsoletes and re-classifies to Historic [RFC2026] the
Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast following RFCs:
OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and
[RFC1585]. The purpose of the re-classification is to give the o Border Gateway Multicast Protocol (BGMP) [RFC3913],
readers (both implementors and deployers) an idea what the status of
a protocol is; there may be legacy deployments of some of these o Core Based Trees (CBT) [RFC2189] [RFC2201],
protocols, which are not affected by this reclassification. See
Section 2.1 for more on each protocol. o Multicast OSPF (MOSPF) [RFC1584] and [RFC1585].
For the most part, these protocols have fallen into disuse. There
may be legacy deployments of some of these protocols, which are not
affected by this reclassification. See Section 2.1 for more on each
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
skipping to change at page 5, line 38 skipping to change at page 5, line 38
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 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
multicast routing can work. Specifically, when ASM is employed, a
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
MSDP so information about sources connected to other RPs can be
distributed (Section 2.3). Further, routers need to know if or how
multicast topology differs from unicast topology, and routing
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
unspecified means. Then it will signal its interest to its router unspecified means. Then it will signal its interest to its first-hop
using IGMP or MLD (Section 2.6). To deliver a multicast router using IGMP or MLD (Section 2.6). The router initiates setting
transmission, the router will need to know how to build the up hop-by-hop multicast forwarding state (Section 2.1) to the source
distribution tree which includes all the sources (Section 2.3) and/or (in SSM) or first through the RP (in ASM). Routers use an RP to find
to locate the RP (Section 2.4) or one of RPs (Section 2.5). In out all the sources for a group (Section 2.3). When multicast
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 transmission arrives at the receiver's LAN, it is flooded to every
port unless flooding reduction such as IGMP snooping is employed port unless flooding reduction such as IGMP snooping is employed
(Section 2.7). (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
[RFC4601]. The PIM-SM protocol includes both Any Source Multicast [RFC4601]. The PIM-SM protocol includes both Any Source Multicast
(ASM) and Source-Specific Multicast (SSM) functionality; PIM-SSM is a (ASM) and Source-Specific Multicast (SSM) functionality; PIM-SSM is a
subset of PIM-SM. Most current routing platforms support PIM-SM. subset of PIM-SM. Most current routing platforms support PIM-SM. It
builds a unidirectional, group-specific distribution tree consisting
of the interested receivers of a group.
2.1.2. PIM-DM 2.1.2. PIM-DM
Whereas PIM-SM has been designed to avoid unnecessary flooding of Whereas PIM-SM has been designed to avoid unnecessary flooding of
multicast data, PIM-DM [RFC3973] assumed that almost every subnet at multicast data, PIM-DM [RFC3973] assumed that almost every subnet at
a site had at least one receiver for a group. PIM-DM floods a site had at least one receiver for a group. PIM-DM floods
multicast transmissions throughout the network ("flood and prune") multicast transmissions throughout the network ("flood and prune")
unless the leaf parts of the network periodically indicate that they unless the leaf parts of the network periodically indicate that they
are not interested in that particular group. are not interested in that particular group.
skipping to change at page 7, line 6 skipping to change at page 7, line 12
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. Bi-directional PIM
Bi-directional PIM [I-D.ietf-pim-bidir] is a multicast forwarding Bi-directional PIM [I-D.ietf-pim-bidir] is a multicast forwarding
protocol that establishes a common shared-path for all sources with a protocol that 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 root. It can be used as an alternative to PIM-SM inside a
single domain. It doesn't have data-driven events or data- single domain. It doesn't have data-driven events or data-
encapsulation. As it doesn't keep source-specific state, it may be a encapsulation. As it doesn't keep source-specific state, it may be
lucrative approach especially in sites with a large number of an appealing approach especially in sites with a large number of
sources. 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 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
skipping to change at page 8, line 34 skipping to change at page 8, line 42
| Bi-dir PIM | No | Yes | Some uptake | | Bi-dir 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.
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
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
("congruent"), i.e., use the same routing tables (routing information ("congruent"), i.e., use the same routing tables (routing information
base, RIB), it has been considered sufficient just to distribute one base, RIB), it has been considered sufficient just to distribute one
set of reachability information to be used in conjunction with a set of reachability information to be used in conjunction with a
protocol that sets up multicast forwarding state (e.g., PIM-SM). protocol that sets up multicast forwarding state (e.g., PIM-SM).
skipping to change at page 9, line 37 skipping to change at page 9, line 44
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 topologies, for example IS-IS multi-topology extensions a differing topologies, for example IS-IS multi-topology extensions
[I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast [I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast
topology that differs from unicast. Similar but not so widely topology that differs from unicast. Similar but not so widely
implemented work exists for OSPF [I-D.ietf-ospf-mt]. implemented work exists for OSPF [RFC4915].
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 10, line 28 skipping to change at page 10, line 35
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 2.2.4. Summary
The following table summarizes the topology distribution approaches A congruent topology can be deployed using unicast routing protocols
described in this Section. In particular, it is recommended that if that provide no support for a separate multicast topology. In intra-
interdomain routing uses BGP, multicast-enabled sites should use MP- domain that approach is often adequate. However, it is recommended
BGP SAFI=2 for multicast and SAFI=1 for unicast even if the topology that if interdomain routing uses BGP, multicast-enabled sites should
was congruent. 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".
The following table summarizes the approaches that can be used to
distribute multicast topology information.
+-------------+---------------+ +-------------+---------------+
| Interdomain | Intradomain | | Interdomain | Intradomain |
+--------------------- +--------------+--------------+ +--------------------- +--------------+--------------+
| Congruent topology | Yes | Yes |
| BGP without SAFI | Not recomm. | Yes |
| MP-BGP SAFI=1 only | Not recomm. | Not recomm. |
| MP-BGP SAFI=2 | Recommended | Yes | | MP-BGP SAFI=2 | Recommended | 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 | No | Yes | | IS-IS multi-topology | No | Yes |
| OSPF multi-topology | No | Few implem. | | 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 To build a multicast distribution tree, the routing protocol needs to
receivers know the IP addresses of the (active) sources for a group find out where the sources for the group are. In case of SSM, the
in advance, possibly using an out-of-band mechanism (SSM), or the user specifies the source IP address or it is otherwise learned out
transmissions are forwarded to the receivers automatically (ASM). of band. In ASM, RPs are used to find out the sources (which in turn
requires a mechanism to find the RPs as discussed in Section 2.4).
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 11, line 43 skipping to change at page 12, line 4
(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 instead [I-D.ietf-mboned-ipv6-multicast-issues]. and Embedded-RP [I-D.ietf-mboned-ipv6-multicast-issues].
2.3.3. Embedded-RP 2.3.3. Embedded-RP
Embedded-RP [RFC3956] is an IPv6-only technique to map the address of Embedded-RP [RFC3956] is an IPv6-only technique to map the address of
the RP to the multicast group address. Using this method, it is the RP to the multicast group address. Using this method, it is
possible to avoid the use of MSDP while still allowing multiple possible to avoid the use of MSDP while still allowing multiple
multicast domains (in the traditional sense). multicast domains (in the traditional sense).
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 14, line 34 skipping to change at page 14, line 46
about sources between multiple RPs in a single domain for, e.g., about sources between multiple RPs in a single domain for, e.g.,
redundancy purposes [RFC3446]. The purpose of MSDP in this context redundancy purposes [RFC3446]. The purpose of MSDP in this context
is to share the same state information on multiple RPs for the same is to share the same state information on multiple RPs for the same
groups to enhance the robustness of the service. groups to enhance the robustness of the service.
Recent PIM extensions [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
It is also possible to use some mechanisms for smaller amount of While Anycast RP shares state between RPs so that RP failure causes
redundancy as Anycast RP, without sharing state between the RPs. A only small disturbance, stateless approaches are also possible with a
traditional mechanism has been to use Auto-RP or BSR (see more limited resiliency. A traditional mechanism has been to use
Section 2.4.3) to select another RP when the active one failed. Auto-RP or BSR (see Section 2.4.3) to select another RP when the
However, the same functionality could be achieved using a shared- active one failed. However, the same functionality could be achieved
unicast RP address ("anycast RP without state sharing") without the using a shared-unicast RP address ("anycast RP without state
complexity of a dynamic mechanism. Further, Anycast RP offers a sharing") without the complexity of a dynamic mechanism. Further,
significantly more extensive failure mitigation strategy, so today Anycast RP offers a significantly more extensive failure mitigation
there is actually very little need to use stateless failover strategy, so today there is actually very little need to use
mechanisms, especially dynamic ones, for redundancy purposes. stateless failover 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 may be shortest path tree (SPT), the final multicast tree is may be
established faster. On the other hand, PIM-SM or SSM may converge established faster. On the other hand, PIM-SM or SSM may converge
more quickly especially in scenarios (e.g., unicast routing change) more quickly especially in scenarios (e.g., unicast routing change)
where bi-directional needs to re-do the Designated Forwarder where bi-directional needs to re-do the Designated Forwarder
election. 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 | New, simpler than MSDP| | 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| | 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.
skipping to change at page 18, line 25 skipping to change at page 18, line 40
3. Acknowledgements 3. Acknowledgements
Tutoring a couple multicast-related papers, the latest by Kaarle Tutoring a couple multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that up-to-date multicast Ritvanen [RITVANEN] convinced the author that up-to-date multicast
routing and address assignment/allocation documentation is necessary. routing and address assignment/allocation documentation is necessary.
Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer,
Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat
Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon
Chisholm, John Zwiebel, Dan Romascanu, and Thomas Morin provided good Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, and Ron Bonica
comments, helping in improving this document. provided good comments, helping in improving this document.
4. IANA Considerations 4. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
5. Security Considerations 5. Security Considerations
This memo only describes different approaches to multicast routing, This memo only describes different approaches to multicast routing,
and this has no security considerations; the security analysis of the and this has no security considerations; the security analysis of the
mentioned protocols is out of scope of this memo. mentioned protocols is out of scope of this memo.
However, there has been analysis of the security of multicast routing However, there has been analysis of the security of multicast routing
infrastructures [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and infrastructures [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and
PIM last-hop issues [I-D.ietf-pim-lasthop-threats]. PIM last-hop issues [I-D.ietf-pim-lasthop-threats].
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-ospf-mt]
Psenak, P., "Multi-Topology (MT) Routing in OSPF",
draft-ietf-ospf-mt-08 (work in progress), January 2007.
[I-D.ietf-pim-bidir] [I-D.ietf-pim-bidir]
Handley, M., "Bi-directional Protocol Independent Handley, M., "Bi-directional Protocol Independent
Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in
progress), February 2007. progress), February 2007.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
skipping to change at page 19, line 38 skipping to change at page 20, line 5
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. 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 for
IP", RFC 4607, August 2006. 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.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 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>.
[CGMP] "Cisco Group Management Protocol", [CGMP] "Cisco Group Management Protocol",
<http://www.javvin.com/protocolCGMP.html>. <http://www.javvin.com/protocolCGMP.html>.
[GMRP] "GARP Multicast Registration Protocol", [GMRP] "GARP Multicast Registration Protocol",
<http://www.javvin.com/protocolGMRP.html>. <http://www.javvin.com/protocolGMRP.html>.
skipping to change at page 20, line 39 skipping to change at page 21, line 10
progress), October 2006. progress), October 2006.
[I-D.ietf-mboned-ipv6-multicast-issues] [I-D.ietf-mboned-ipv6-multicast-issues]
Savola, P., "IPv6 Multicast Deployment Issues", Savola, P., "IPv6 Multicast Deployment Issues",
draft-ietf-mboned-ipv6-multicast-issues-02 (work in draft-ietf-mboned-ipv6-multicast-issues-02 (work in
progress), February 2005. progress), February 2005.
[I-D.ietf-pim-lasthop-threats] [I-D.ietf-pim-lasthop-threats]
Savola, P. and J. Lingard, "Last-hop Threats to Protocol Savola, P. and J. Lingard, "Last-hop Threats to Protocol
Independent Multicast (PIM)", Independent Multicast (PIM)",
draft-ietf-pim-lasthop-threats-00 (work in progress), draft-ietf-pim-lasthop-threats-01 (work in progress),
October 2006. June 2007.
[I-D.ietf-pim-sm-bsr] [I-D.ietf-pim-sm-bsr]
Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM",
draft-ietf-pim-sm-bsr-10 (work in progress), draft-ietf-pim-sm-bsr-11 (work in progress), July 2007.
February 2007.
[I-D.lehtonen-mboned-dynssm-req] [I-D.lehtonen-mboned-dynssm-req]
Lehtonen, R., "Requirements for discovery of dynamic SSM Lehtonen, R., "Requirements for discovery of dynamic SSM
sources", draft-lehtonen-mboned-dynssm-req-00 (work in sources", draft-lehtonen-mboned-dynssm-req-00 (work in
progress), February 2005. progress), February 2005.
[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap [IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap
Analysis from the MBONED Working Group for the IESG Analysis from the MBONED Working Group for the IESG
[Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work [Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work
in progress), July 2002. in progress), July 2002.
 End of changes. 35 change blocks. 
95 lines changed or deleted 104 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/