draft-ietf-mboned-routingarch-09.txt   draft-ietf-mboned-routingarch-10.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: August 3, 2007 Obsoletes: September 25, 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: February 4, 2008 Expires: March 28, 2008
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-09.txt draft-ietf-mboned-routingarch-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 4, 2008. This Internet-Draft will expire on March 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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.
skipping to change at page 2, line 40 skipping to change at page 2, line 40
2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . 15
2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . 16 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16
2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . 17 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17
2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17
2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Multicast Payload Transport Extensions . . . . . . . 23 Appendix A. Multicast Payload Transport Extensions . . . . . . . 23
A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 24
A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25
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 [I-D.ietf-mboned-addrarch] describes
multicast addressing architectures. multicast 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 PIM RP information (Section 2.4), o configuring and distributing the rendezvous point (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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto. MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto.
MOSPF Multicast OSPF MOSPF Multicast OSPF
MSDP Multicast Source Discovery Protocol MSDP Multicast Source Discovery Protocol
PGM Pragmatic General Multicast PGM Pragmatic General Multicast
PIM Protocol Independent Multicast PIM Protocol Independent Multicast
PIM-DM PIM - Dense Mode PIM-DM PIM - Dense Mode
PIM-SM PIM - Sparse Mode PIM-SM PIM - Sparse Mode
PIM-SSM PIM - Source-Specific Multicast PIM-SSM PIM - Source-Specific Multicast
RGMP (Cisco's) Router Group Management Protocol RGMP (Cisco's) Router Group Management Protocol
RP Rendezvous Point RP Rendezvous Point
SAFI Subsequent Address Family Identifier
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 configuration needs 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
unspecified means. Then it will signal its interest to its first-hop various means (e.g., SDP description file [RFC4566] or manually).
router using IGMP or MLD (Section 2.6). The router initiates setting
up hop-by-hop multicast forwarding state (Section 2.1) to the source Then it will signal its interest to its first-hop router using IGMP
(in SSM) or first through the RP (in ASM). Routers use an RP to find (IPv4) or MLD (IPv6) (Section 2.6). The router initiates setting up
out all the sources for a group (Section 2.3). When multicast hop-by-hop multicast forwarding state (Section 2.1) to the source (in
SSM) or first through the RP (in ASM). Routers use an RP to find out
all the sources for a group (Section 2.3). 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 Ethernet switch port unless flooding reduction such as IGMP snooping
(Section 2.7). is employed (Section 2.7).
2.1. Setting up Multicast Forwarding State 2.1. Setting up Multicast Forwarding State
The most important part of multicast routing is setting up the The most important part of multicast routing is setting up the
multicast forwarding state. This section describes the protocols multicast forwarding state. This section describes the protocols
commonly used for this purpose. commonly used for this purpose.
2.1.1. PIM-SM 2.1.1. PIM-SM
By far, the most common multicast routing protocol is PIM-SM By far, the most common multicast routing protocol is PIM-SM
skipping to change at page 6, line 36 skipping to change at page 6, line 40
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.
PIM-DM may be an acceptable fit in small and/or simple networks, PIM-DM may be an acceptable fit in small and/or simple networks,
where setting up an RP would be unnecessary, and possibly in cases where setting up an RP would be unnecessary, and possibly in cases
where a large percentage of users is expected to want to receive the where a large percentage of users are expected to want to receive the
transmission so that the amount of state the network has to keep is transmission so that the amount of state the network has to keep is
minimal. minimal.
PIM-DM was used as a first step in transitioning away from DVMRP. It PIM-DM was used as a first step in transitioning away from DVMRP. It
also became apparent that most networks would not have receivers for also became apparent that most networks would not have receivers for
most groups, and to avoid the bandwidth and state overhead, the most groups, and to avoid the bandwidth and state overhead, the
flooding paradigm was gradually abandoned. Transitioning from PIM-DM flooding paradigm was gradually abandoned. Transitioning from PIM-DM
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.
skipping to change at page 7, line 23 skipping to change at page 7, line 26
an appealing 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. To get around initial deployment
deployment hurdles. It also included tunneling capabilities which hurdles, it also included tunneling capabilities which were part of
were part of its multicast topology functions. its multicast 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, GRE tunneling supporting DVMRP to the internal network. However, Generic Routing
[RFC2784] seems to have overtaken DVMRP in this functionality, and Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP
there is relatively little use for DVMRP except in legacy in this functionality, and there is relatively little use for DVMRP
deployments. except in legacy deployments.
2.1.5. MOSPF 2.1.5. MOSPF
MOSPF [RFC1584] was implemented by several vendors and has seen some MOSPF [RFC1584] was implemented by several vendors and has seen some
deployment in intra-domain networks. However, since it is based on deployment in intra-domain networks. However, since it is based on
intra-domain OSPF it does not scale to the inter-domain case, intra-domain Open Shortest Path First (OSPF) it does not scale to the
operators have found it is easier to deploy a single protocol for use inter-domain case, operators have found it is easier to deploy a
in both intra-domain and inter-domain networks and so it is no longer single protocol for use in both intra-domain and inter-domain
being actively deployed. networks and so it is no longer being actively deployed.
2.1.6. BGMP 2.1.6. BGMP
BGMP [RFC3913] did not get sufficient support within the service BGMP [RFC3913] did not get sufficient support within the service
provider community to get adopted and moved forward in the IETF provider community to get adopted and moved forward in the IETF
standards process. There were no reported production implementations standards process. There were no reported production implementations
and no production deployments. and no production deployments.
2.1.7. CBT 2.1.7. CBT
skipping to change at page 9, line 40 skipping to change at page 9, line 41
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 IGPs also provide the capability for signalling Similar to BGP, some Interior Gateway Protocols (IGPs) also provide
a differing topologies, for example IS-IS multi-topology extensions the capability for signalling differing topologies, for example IS-IS
[I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast multi-topology extensions [I-D.ietf-isis-wg-multi-topology]. These
topology that differs from unicast. Similar but not so widely can be used for a multicast topology that differs from unicast.
implemented work exists for OSPF [RFC4915]. Similar but not so widely 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 12, line 16 skipping to change at page 12, line 23
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
about that with any other RPs. If necessary, RP redundancy can still about that with any other RPs. If necessary, RP redundancy can still
be achieved with Anycast-RP using PIM. be achieved with Anycast-RP using PIM [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 | | Bi-dir 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 Bi-dir PIM configuration mechanisms exist which are used
to configure the RP addresses and which groups are to use those RPs to configure the RP addresses and the groups that are to use those
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
changed. However, with the advent of anycast RP addressing, the RP changed. However, with the advent of anycast RP addressing, the RP
address is unlikely to ever change. Therefore, the administrative address is unlikely to ever change. Therefore, the administrative
skipping to change at page 14, line 28 skipping to change at page 14, line 33
| IPv4 | IPv6 | Deployment | | IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+ +--------------------+------+------+-----------------------+
| Static RP | Yes | Yes | Especially in ISPs | | Static RP | Yes | Yes | Especially in ISPs |
| Auto-RP | Yes | No | Legacy deployment | | Auto-RP | Yes | No | Legacy deployment |
| BSR | Yes | Yes | Some, anycast simpler | | BSR | Yes | Yes | Some, anycast simpler |
| Embedded-RP | No | Yes | Growing | | Embedded-RP | No | Yes | Growing |
+--------------------+------+------+-----------------------+ +--------------------+------+------+-----------------------+
2.5. Mechanisms for Enhanced Redundancy 2.5. Mechanisms for Enhanced Redundancy
A couple of mechanisms, already described in this document, have been Having only one RP in a PIM-SM domain would be a single point of
used as a means to enhance redundancy, resilience against failures, failure for the whole multicast domain. As a result, a number of
and to recover from failures quickly. This section summarizes these mechanisms have been developed to either eliminate the RP
techniques explicitly. functionality or to enhance RPs' redundancy, resilience against
failures, and to recover from failures quickly. This section
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 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
skipping to change at page 15, line 12 skipping to change at page 15, line 22
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. 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 may be established
established faster. On the other hand, PIM-SM or SSM may converge faster. On the other hand, PIM-SM or SSM may converge more quickly
more quickly especially in scenarios (e.g., unicast routing change) especially in scenarios (e.g., unicast routing change) where bi-
where bi-directional needs to re-do the Designated Forwarder 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 |
skipping to change at page 15, line 44 skipping to change at page 16, line 4
Previous sections have dealt with the components required by routers Previous sections have dealt with the components required by routers
to be able to do multicast routing. Obviously, the real users of to be able to do multicast routing. Obviously, the real users of
multicast are the hosts: either sending or receiving multicast. This multicast are the hosts: either sending or receiving multicast. This
section describes the required interactions with hosts. section describes the required interactions with hosts.
2.6.1. Hosts Sending Multicast 2.6.1. Hosts Sending Multicast
After choosing a multicast group through a variety of means, hosts After choosing a multicast group through a variety of means, hosts
just send the packets to the link-layer multicast address, and the just send the packets to the link-layer multicast address, and the
designated router will receive all the multicast packets and start designated router will receive all the multicast packets and start
forwarding them as appropriate. forwarding them as appropriate. A host does not need to be a member
of the group in order to send to it [RFC1112].
In intra-domain or Embedded-RP scenarios, ASM senders may move to a In intra-domain or Embedded-RP scenarios, ASM senders may move to a
new IP address without significant impact on the delivery of their new IP address without significant impact on the delivery of their
transmission. SSM senders cannot change the IP address unless transmission. SSM senders cannot change the IP address unless
receivers join the new channel or the sender uses an IP mobility receivers join the new channel or the sender uses an IP mobility
technique that is transparent to the receivers. technique that is transparent to the receivers.
2.6.2. Hosts Receiving Multicast 2.6.2. Hosts Receiving Multicast
Hosts signal their interest in receiving a multicast group or channel Hosts signal their interest in receiving a multicast group or channel
skipping to change at page 18, line 40 skipping to change at page 18, line 46
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, Thomas Morin, and Ron Bonica Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, and
provided good comments, helping in improving this document. Prashant Jhingran provided good comments, helping in improving this
document.
4. IANA Considerations 4. IANA Considerations
This memo includes no request to IANA. IANA is requested to update the following registries by adding a
reference to this document:
o OSPFv2 Option registry: MC-bit
o OSPFv2 Link state type: Group-membership-LSA
o OSPFv2 Router properties registry: W-bit (0x08)
o OSPFv3 Option registry: MC-bit
o OSPFv3 LSA function code registry: Group-membership-LSA
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 [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].
skipping to change at page 21, line 15 skipping to change at page 21, line 38
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-01 (work in progress), draft-ietf-pim-lasthop-threats-01 (work in progress),
June 2007. 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-11 (work in progress), July 2007. draft-ietf-pim-sm-bsr-12 (work in progress), August 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.
skipping to change at page 21, line 37 skipping to change at page 22, line 11
[IMRP-ISSUES] [IMRP-ISSUES]
Meyer, D., "Some Issues for an Inter-domain Multicast Meyer, D., "Some Issues for an Inter-domain Multicast
Routing Protocol [Expired]", Routing Protocol [Expired]",
draft-ietf-mboned-imrp-some-issues-01 (work in progress), draft-ietf-mboned-imrp-some-issues-01 (work in progress),
September 1997. September 1997.
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075, Vector Multicast Routing Protocol", RFC 1075,
November 1988. November 1988.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast [RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast
Protocols", RFC 1458, May 1993. Protocols", RFC 1458, May 1993.
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994. March 1994.
[RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585,
March 1994. March 1994.
[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast
skipping to change at page 22, line 44 skipping to change at page 23, line 21
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 Discovery",
RFC 4286, December 2005. RFC 4286, December 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006. Switches", RFC 4541, May 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: 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) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("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) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
October 2006. October 2006.
 End of changes. 26 change blocks. 
52 lines changed or deleted 84 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/