diff options
Diffstat (limited to 'doc/rfc/rfc5110.txt')
| -rw-r--r-- | doc/rfc/rfc5110.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc5110.txt b/doc/rfc/rfc5110.txt new file mode 100644 index 0000000..cb79a8c --- /dev/null +++ b/doc/rfc/rfc5110.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group P. Savola +Request for Comments: 5110 CSC/FUNET +Category: Informational January 2008 + + + Overview of the Internet Multicast Routing Architecture + +Status of This Memo + + 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 + + This document describes multicast routing architectures that are + currently deployed on the Internet. This document briefly describes + those protocols and references their specifications. + + This memo also reclassifies several older RFCs to Historic. These + RFCs describe multicast routing protocols that were never widely + deployed or have fallen into disuse. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Multicast-Related Abbreviations ............................4 + 2. Multicast Routing ...............................................4 + 2.1. Setting up Multicast Forwarding State ......................5 + 2.1.1. PIM-SM ..............................................5 + 2.1.2. PIM-DM ..............................................5 + 2.1.3. Bidirectional PIM ...................................6 + 2.1.4. DVMRP ...............................................6 + 2.1.5. MOSPF ...............................................7 + 2.1.6. BGMP ................................................7 + 2.1.7. CBT .................................................7 + 2.1.8. Interactions and Summary ............................7 + 2.2. Distributing Topology Information ..........................8 + 2.2.1. Multiprotocol BGP ...................................8 + 2.2.2. OSPF/IS-IS Multi-Topology Extensions ................9 + 2.2.3. Issue: Overlapping Unicast/Multicast Topology .......9 + 2.2.4. Summary ............................................10 + 2.3. Learning (Active) Sources .................................10 + 2.3.1. SSM ................................................11 + 2.3.2. MSDP ...............................................11 + 2.3.3. Embedded-RP ........................................11 + 2.3.4. Summary ............................................12 + + + + +Savola Informational [Page 1] + +RFC 5110 Multicast Routing Overview January 2008 + + + 2.4. Configuring and Distributing PIM RP Information ...........12 + 2.4.1. Manual RP Configuration ............................12 + 2.4.2. Embedded-RP ........................................13 + 2.4.3. BSR and Auto-RP ....................................13 + 2.4.4. Summary ............................................14 + 2.5. Mechanisms for Enhanced Redundancy ........................14 + 2.5.1. Anycast RP .........................................14 + 2.5.2. Stateless RP Failover ..............................14 + 2.5.3. Bidirectional PIM ..................................15 + 2.5.4. Summary ............................................15 + 2.6. Interactions with Hosts ...................................15 + 2.6.1. Hosts Sending Multicast ............................15 + 2.6.2. Hosts Receiving Multicast ..........................15 + 2.6.3. Summary ............................................16 + 2.7. Restricting Multicast Flooding in the Link Layer ..........16 + 2.7.1. Router-to-Router Flooding Reduction ................16 + 2.7.2. Host/Router Flooding Reduction .....................17 + 2.7.3. Summary ............................................18 + 3. Acknowledgements ...............................................18 + 4. IANA Considerations ............................................18 + 5. Security Considerations ........................................19 + 6. References .....................................................19 + 6.1. Normative References ......................................19 + 6.2. Informative References ....................................20 + Appendix A. Multicast Payload Transport Extensions.................24 + A.1. Reliable Multicast.........................................24 + A.2. Multicast Group Security...................................24 + + + + + + + + + + + + + + + + + + + + + + + + +Savola Informational [Page 2] + +RFC 5110 Multicast Routing Overview January 2008 + + +1. Introduction + + This document provides a brief overview of multicast routing + architectures that are currently deployed on the Internet and how + those protocols fit together. It also describes those multicast + routing protocols that were never widely deployed or have fallen into + disuse. A companion document [ADDRARCH] describes multicast + addressing architectures. + + Specifically, this memo deals with: + + o setting up multicast forwarding state (Section 2.1), + + o distributing multicast topology information (Section 2.2), + + o learning active sources (Section 2.3), + + o configuring and distributing the rendezvous point (RP) information + (Section 2.4), + + o mechanisms for enhanced redundancy (Section 2.5), + + o interacting with hosts (Section 2.6), and + + o restricting the multicast flooding in the link layer + (Section 2.7). + + Section 2 starts by describing a simplistic example how these classes + of mechanisms fit together. Some multicast data transport issues are + also introduced in Appendix A. + + This memo reclassifies to Historic [RFC2026] the following RFCs: + + o Border Gateway Multicast Protocol (BGMP) [RFC3913], + + o Core Based Trees (CBT) [RFC2189] [RFC2201], + + o Multicast OSPF (MOSPF) [RFC1584]. + + 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, + [RFC1458], [IMRP-ISSUES], and [IM-GAPS]. + + + + + +Savola Informational [Page 3] + +RFC 5110 Multicast Routing Overview January 2008 + + +1.1. Multicast-Related Abbreviations + + ASM Any Source Multicast + BGMP Border Gateway Multicast Protocol + BSR Bootstrap Router + CBT Core Based Trees + CGMP Cisco Group Management Protocol + DR Designated Router + DVMRP Distance Vector Multicast Routing Protocol + GARP (IEEE 802.1D-2004) Generic Attribute Registration + Protocol + GMRP GARP Multicast Registration Protocol + IGMP Internet Group Management Protocol + MBGP Multiprotocol BGP (*not* "Multicast BGP") + MLD Multicast Listener Discovery + MRP (IEEE 802.1ak) Multiple Registration Protocol + MMRP (IEEE 802.1ak) Multicast Multiple Registration + Protocol + MOSPF Multicast OSPF + MSDP Multicast Source Discovery Protocol + PGM Pragmatic General Multicast + PIM Protocol Independent Multicast + PIM-DM PIM - Dense Mode + PIM-SM PIM - Sparse Mode + PIM-SSM PIM - Source-Specific Multicast + RGMP (Cisco's) Router Group Management Protocol + RP Rendezvous Point + RPF Reverse Path Forwarding + SAFI Subsequent Address Family Identifier + SDP Session Description Protocol + SSM Source-Specific Multicast + +2. Multicast Routing + + In order to give a simplified summary how each of these class of + mechanisms fits together, consider the following multicast receiver + scenario. + + Certain protocols and configurations need 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). + + + + + +Savola Informational [Page 4] + +RFC 5110 Multicast Routing Overview January 2008 + + + When a host wants to receive a transmission, it first needs to find + out the multicast group address (and with SSM, source address) using + various means (e.g., SDP description file [RFC4566] or manually). + Then it will signal its interest to its first-hop router using IGMP + (IPv4) or MLD (IPv6) (Section 2.6). The router initiates setting up + 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 + Ethernet switch port unless flooding reduction such as IGMP snooping + is employed (Section 2.7). + +2.1. Setting up Multicast Forwarding State + + The most important part of multicast routing is setting up the + multicast forwarding state. State maintenance requires periodic + messaging because forwarding state has a timeout. This section + describes the protocols commonly used for this purpose. + +2.1.1. PIM-SM + + By far, the most common multicast routing protocol is PIM-SM + [RFC4601]. The PIM-SM protocol includes both Any Source Multicast + (ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is + a subset of PIM-SM that does not use the RPs but instead requires + that receivers know the (source,group) pair and signal that + explicitly. Most current routing platforms support PIM-SM. + + PIM routers elect a designated router on each LAN and the DR is + responsible for PIM messaging and source registration on behalf of + the hosts. The DR encapsulates multicast packets sourced from the + LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional, + group-specific distribution tree consisting of the interested + receivers of a group. Initially, the multicast distribution tree is + rooted at the RP but later the DRs have the option of optimizing the + delivery by building (source,group)-specific trees. + + A more lengthy introduction to PIM-SM can be found in Section 3 of + [RFC4601]. + +2.1.2. PIM-DM + + Whereas PIM-SM has been designed to avoid unnecessary flooding of + multicast data, PIM-DM [RFC3973] assumed that almost every subnet at + a site had at least one receiver for a group. PIM-DM floods + multicast transmissions throughout the network ("flood and prune") + unless the leaf parts of the network periodically indicate that they + are not interested in that particular group. + + + +Savola Informational [Page 5] + +RFC 5110 Multicast Routing Overview January 2008 + + + 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 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 + minimal. + + 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 + most groups, and to avoid the bandwidth and state overhead, the + flooding paradigm was gradually abandoned. Transitioning from PIM-DM + to PIM-SM was easy as PIM-SM was designed to use compatible packet + formats and dense-mode operation could also be satisfied by a sparse + protocol. PIM-DM is no longer in widespread use. + + Many implementations also support so-called "sparse-dense" + configuration, where Sparse mode is used by default, but Dense is + used for configured multicast group ranges (such as Auto-RP in + Section 2.4.3) only. Lately, many networks have transitioned away + from sparse-dense to only sparse mode. + +2.1.3. Bidirectional PIM + + Bidirectional PIM [RFC5015] is a multicast forwarding 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 domain. + It doesn't have data-driven events or data-encapsulation. As it + doesn't keep source-specific state, it may be an appealing approach + especially in sites with a large number of sources. + + As of this writing, there is no inter-domain solution to configure a + group range to use bidirectional PIM. + +2.1.4. DVMRP + + Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] + [DVMRPv3] [DVMRPv3-AS] was the first protocol designed for + multicasting. To get around initial deployment hurdles, it also + included tunneling capabilities, which were part of its multicast + topology functions. + + Currently, DVMRP is used only very rarely in operator networks, + having been replaced with PIM-SM. The most typical deployment of + DVMRP is at a leaf network, to run from a legacy firewall only + supporting DVMRP to the internal network. However, Generic Routing + Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP + in this functionality, and there is relatively little use for DVMRP + except in legacy deployments. + + + + +Savola Informational [Page 6] + +RFC 5110 Multicast Routing Overview January 2008 + + +2.1.5. MOSPF + + MOSPF [RFC1584] was implemented by several vendors and has seen some + deployment in intra-domain networks. However, since it is based on + intra-domain Open Shortest Path First (OSPF) it does not scale to the + inter-domain case, operators have found it is easier to deploy a + single protocol for use in both intra-domain and inter-domain + networks and so it is no longer being actively deployed. + +2.1.6. BGMP + + BGMP [RFC3913] did not get sufficient support within the service + provider community to get adopted and moved forward in the IETF + standards process. There were no reported production implementations + and no production deployments. + +2.1.7. CBT + + CBT [RFC2201][RFC2189] was an academic project that provided the + basis for PIM sparse mode shared trees. Once the shared tree + functionality was incorporated into PIM implementations, there was no + longer a need for a production CBT implementation. Therefore, CBT + never saw production deployment. + +2.1.8. Interactions and Summary + + It is worth noting that it is possible to run different protocols + with different multicast group ranges. For example, treat some + groups as dense or bidirectional in an otherwise PIM-SM network; this + typically requires manual configuration of the groups or a mechanism + like BSR (Section 2.4.3). It is also possible to interact between + different protocols; for example, use DVMRP in the leaf network, but + PIM-SM upstream. The basics for interactions among different + protocols have been outlined in [RFC2715]. + + The following figure gives a concise summary of the deployment status + of different protocols as of this writing. + + + + + + + + + + + + + + +Savola Informational [Page 7] + +RFC 5110 Multicast Routing Overview January 2008 + + + +--------------+--------------+----------------+ + | Inter-domain | Intra-domain | Status | + +------------+--------------+--------------+----------------+ + | PIM-SM | Yes | Yes | Active | + | PIM-DM | Not anymore | Not anymore | Little use | + | BIDIR-PIM | No | Yes | Some uptake | + | DVMRP | Not anymore | Stub only | Going out | + | MOSPF | No | Not anymore | Inactive | + | CBT | No | No | Never deployed | + | BGMP | No | No | Never deployed | + +------------+--------------+--------------+----------------+ + + From this table, it is clear that PIM-Sparse Mode is the only + multicast routing protocol that is deployed inter-domain and, + therefore, is most frequently used within multicast domains as well. + +2.2. Distributing Topology Information + + PIM has become the de-facto multicast forwarding protocol, but as its + name implies, it is independent of the underlying unicast routing + protocol. When unicast and multicast topologies are the same + ("congruent"), i.e., use the same routing tables (routing information + base, RIB), it has been considered sufficient just to distribute one + set of reachability information to be used in conjunction with a + protocol that sets up multicast forwarding state (e.g., PIM-SM). + + However, when PIM which by default built multicast topology based on + the unicast topology gained popularity, it became apparent that it + would be necessary to be able to distribute also non-congruent + multicast reachability information in the regular unicast protocols. + This was previously not an issue, because DVMRP built its own + reachability information. + + The topology information is needed to perform efficient distribution + of multicast transmissions and to prevent transmission loops by + applying it to the Reverse Path Forwarding (RPF) check. + + This subsection introduces these protocols. + +2.2.1. Multiprotocol BGP + + Multiprotocol Extensions for BGP-4 [RFC4760] (often referred to as + "MBGP"; however, it is worth noting that "MBGP" does *not* stand for + "Multicast BGP") specifies a mechanism by which BGP can be used to + distribute different reachability information for unicast (SAFI=1) + and multicast traffic (SAFI=2). Multiprotocol BGP has been widely + + + + + +Savola Informational [Page 8] + +RFC 5110 Multicast Routing Overview January 2008 + + + deployed for years, and is also needed to route IPv6. Note that + SAFI=3 was originally specified for "both unicast and multicast" but + has since then been deprecated. + + These extensions are in widespread use wherever BGP is used to + distribute unicast topology information. Multicast-enabled networks + that use BGP should use Multiprotocol BGP to distribute multicast + reachability information explicitly even if the topologies are + congruent to make an explicit statement about multicast reachability. + A number of significant multicast transit providers even require + this, by doing the RPF lookups solely based on explicitly advertised + multicast address family. + +2.2.2. OSPF/IS-IS Multi-Topology Extensions + + Similar to BGP, some Interior Gateway Protocols (IGPs) also provide + the capability for signalling differing topologies, for example IS-IS + multi-topology extensions [M-ISIS]. These can be used for a + multicast topology that differs from unicast. Similar but not so + widely implemented work exists for OSPF [RFC4915]. + + It is worth noting that inter-domain incongruence and intra-domain + incongruence are orthogonal, so one doesn't require the other. + Specifically, inter-domain incongruence is quite common, while intra- + domain incongruence isn't, so you see much more deployment of MBGP + than MT-ISIS/OSPF. Commonly deployed networks have managed well + without protocols handling intra-domain incongruence. However, the + availability of multi-topology mechanisms may in part replace the + typically used workarounds such as tunnels. + +2.2.3. Issue: Overlapping Unicast/Multicast Topology + + An interesting case occurs when some routers do not distribute + multicast topology information explicitly while others do. In + particular, this happens when some multicast sites in the Internet + are using plain BGP while some use MBGP. + + Different implementations deal with this in different ways. + Sometimes, multicast RPF mechanisms first look up the multicast + routing table, or M-RIB ("topology database") with a longest prefix + match algorithm, and if they find any entry (including a default + route), that is used; if no match is found, the unicast routing table + is used instead. + + An alternative approach is to use longest prefix match on the union + of multicast and unicast routing tables; an implementation technique + here is to copy the whole unicast routing table over to the multicast + routing table. The important point to remember here, though, is to + + + +Savola Informational [Page 9] + +RFC 5110 Multicast Routing Overview January 2008 + + + not override the multicast-only routes; if the longest prefix match + would find both a (copied) unicast route and a multicast-only route, + the latter should be treated as preferable. + + Another implemented approach is to just look up the information in + the unicast routing table, and provide the user capabilities to + change that as appropriate, using for example copying functions + discussed above. + +2.2.4. Summary + + A congruent topology can be deployed using unicast routing protocols + that provide no support for a separate multicast topology. In intra- + domain that approach is often adequate. However, it is recommended + 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 + 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. + + +----------------+--------------+ + | Inter-domain | Intra-domain | + +--------------------- +----------------+--------------+ + | MP-BGP SAFI=2 | Yes | Yes | + | MP-BGP SAFI=3 | Doesn't work | Doesn't work | + | IS-IS multi-topology | Not applicable | Yes | + | OSPF multi-topology | Not applicable | Few implem. | + +----------------------+----------------+--------------+ + + "Not applicable" refers to the fact that IGP protocols can't be used + in inter-domain routing. "Doesn't work" means that while MP-BGP + 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 + the mechanisms which are generally applicable and known to work. + "Few implem." means that the approach could work but is not commonly + available. + +2.3. Learning (Active) Sources + + 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 + user specifies the source IP address or it is otherwise learned out + of band. + + In ASM, the RPs know about all the active sources in a local PIM + 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. + + + +Savola Informational [Page 10] + +RFC 5110 Multicast Routing Overview January 2008 + + + Having a single PIM-SM domain for the whole Internet is an + insufficient model for many reasons, including scalability, + administrative boundaries, and different technical tradeoffs. + Therefore, it is required to be able to split up the multicast + routing infrastructures to smaller domains, and there must be a way + to share information about active sources using some mechanism if the + ASM model is to be supported. + + This section discusses the options of learning active sources that + apply in an inter-domain environment. + +2.3.1. SSM + + Source-specific Multicast [RFC4607] (sometimes also referred to as + "single-source Multicast") does not count on learning active sources + in the network. Recipients need to know the source IP addresses + using an out of band mechanism which are used to subscribe to the + (source, group) channel. The multicast routing uses the source + address to set up the state and no further source discovery is + needed. + + As of this writing, there are attempts to analyze and/or define out- + of-band source discovery functions which would help SSM in particular + [DYNSSM-REQ]. + +2.3.2. MSDP + + Multicast Source Discovery Protocol [RFC3618] was invented as a stop- + gap mechanism, when it became apparent that multiple PIM-SM domains + (and RPs) were needed in the network, and information about the + active sources needed to be propagated between the PIM-SM domains + using some other protocol. + + MSDP is also used to share the state about sources between multiple + RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The + same can be achieved using PIM extensions [RFC4610]. See Section 2.5 + for more information. + + There is no intent to define MSDP for IPv6, but instead use only SSM + and Embedded-RP [MCAST-ISSUES]. + +2.3.3. Embedded-RP + + 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 + possible to avoid the use of MSDP while still allowing multiple + multicast domains (in the traditional sense). + + + + +Savola Informational [Page 11] + +RFC 5110 Multicast Routing Overview January 2008 + + + 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 + about that with any other RPs. If necessary, RP redundancy can still + be achieved with Anycast-RP using PIM [RFC4610]. + +2.3.4. Summary + + The following table summarizes the source discovery approaches and + their status. + + +------+------+------------------------------+ + | IPv4 | IPv6 | Status | + +----------------------+------+------+------------------------------+ + | Bidir single domain | Yes | Yes | OK but for intra-domain only | + | PIM-SM single domain | Yes | Yes | OK | + | PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM | + | PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option | + | SSM | Yes | Yes | No major uptake yet | + +----------------------+------+------+------------------------------+ + +2.4. Configuring and Distributing PIM RP Information + + PIM-SM and BIDIR-PIM configuration mechanisms exist, which are used + to configure the RP addresses and the groups that are to use those + RPs in the routers. This section outlines the approaches. + +2.4.1. Manual RP Configuration + + It is often easiest just to manually configure the RP information on + the routers when PIM-SM is used. + + Originally, static RP mapping was considered suboptimal since it + required explicit configuration changes every time the RP address + changed. However, with the advent of anycast RP addressing, the RP + address is unlikely to ever change. Therefore, the administrative + burden is generally limited to initial configuration. Since there is + usually a fair amount of multicast configuration required on all + routers anyway (e.g., PIM on all interfaces), adding the RP address + statically isn't really an issue. Further, static anycast RP mapping + provides the benefits of RP load sharing and redundancy (see + Section 2.5) without the complexity found in dynamic mechanisms like + Auto-RP and Bootstrap Router (BSR). + + With such design, an anycast RP uses an address that is configured on + a loopback interface of the routers currently acting as RPs, and + state is distributed using PIM [RFC4610] or MSDP [RFC3446]. + + + + + +Savola Informational [Page 12] + +RFC 5110 Multicast Routing Overview January 2008 + + + Using this technique, each router might only need to be configured + with one, portable RP address. + +2.4.2. Embedded-RP + + Embedded-RP provides the information about the RP's address in the + group addresses that are delegated to those who use the RP, so unless + no other ASM than Embedded-RP is used, the network administrator only + needs to configure the RP routers. + + While Embedded-RP in many cases is sufficient for IPv6, other methods + of RP configuration are needed if one needs to provide ASM service + for other than Embedded-RP group addresses. In particular, service + discovery type of applications may need hard-coded addresses that are + not dependent on local RP addresses. + + 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 + manual configuration of an anycast address. + +2.4.3. BSR and Auto-RP + + BSR [RFC5059] is a mechanism for configuring the RP address for + groups. It may no longer be in as wide use with IPv4 as it was + earlier, and for IPv6, Embedded-RP will in many cases be sufficient. + + Cisco's Auto-RP is an older, proprietary method for distributing + 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 + ensure that only valid routers are able to advertise themselves as + RPs. Further, flooding of BSR and Auto-RP messages must be prevented + at PIM borders. Additionally, routers require monitoring that they + are actually using the RP(s) the administrators think they should be + using, for example, if a router (maybe in customer's control) is + advertising itself inappropriately. All in all, while BSR and + Auto-RP provide easy configuration, they also provide very + significant configuration and management complexity. + + It is worth noting that both Auto-RP and BSR were deployed before the + use of a manually configured anycast-RP address became relatively + commonplace, and there is actually relatively little need for them + today unless there is a need to configure different properties (e.g., + sparse, dense, bidirectional) in a dynamic fashion. + + + + + + + +Savola Informational [Page 13] + +RFC 5110 Multicast Routing Overview January 2008 + + +2.4.4. Summary + + The following table summarizes the RP discovery mechanisms and their + status. With the exception of Embedded-RP, each mechanism operates + within a PIM domain. + + +------+------+-----------------------+ + | IPv4 | IPv6 | Deployment | + +--------------------+------+------+-----------------------+ + | Static RP | Yes | Yes | Especially in ISPs | + | Auto-RP | Yes | No | Legacy deployment | + | BSR | Yes | Yes | Some, anycast simpler | + | Embedded-RP | No | Yes | Growing | + +--------------------+------+------+-----------------------+ + +2.5. Mechanisms for Enhanced Redundancy + + 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 + mechanisms have been developed to either eliminate the RP + 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 + + As mentioned in Section 2.3.2, MSDP is also used to share the state + about sources between multiple RPs in a single domain, e.g., for + redundancy purposes [RFC3446]. The purpose of MSDP in this context + is to share the same state information on multiple RPs for the same + groups to enhance the robustness of the service. + + Recent PIM extensions [RFC4610] also provide this functionality. In + contrast to MSDP, this approach works for both IPv4 and IPv6. + +2.5.2. Stateless RP Failover + + While Anycast RP shares state between RPs so that RP failure causes + only small disturbance, stateless approaches are also possible with a + 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 + active one failed. However, the same functionality could be achieved + using a shared-unicast RP address ("anycast RP without state + sharing") without the complexity of a dynamic mechanism. Further, + Anycast RP offers a significantly more extensive failure mitigation + strategy, so today there is actually very little need to use + stateless failover mechanisms, especially dynamic ones, for + redundancy purposes. + + + +Savola Informational [Page 14] + +RFC 5110 Multicast Routing Overview January 2008 + + +2.5.3. Bidirectional PIM + + Because bidirectional PIM (see Section 2.1.3) does not switch to + shortest path tree (SPT), the final multicast tree may be established + faster. On the other hand, PIM-SM or SSM may converge more quickly + especially in scenarios (e.g., unicast routing change) where + bidirectional needs to re-do the Designated Forwarder election. + +2.5.4. Summary + + The following table summarizes the techniques for enhanced + redundancy. + + +------+------+-----------------------+ + | IPv4 | IPv6 | Deployment | + +--------------------+------+------+-----------------------+ + | Anycast RP w/ MSDP | Yes | No | De-facto approach | + | Anycast RP w/ PIM | Yes | Yes | Newer approach | + | Stateless RP fail. | Yes | Yes | Causes disturbance | + | BIDIR-PIM | Yes | Yes | Deployed at some sites| + +--------------------+------+------------------------------+ + +2.6. Interactions with Hosts + + Previous sections have dealt with the components required by routers + to be able to do multicast routing. Obviously, the real users of + multicast are the hosts: either sending or receiving multicast. This + section describes the required interactions with hosts. + +2.6.1. Hosts Sending Multicast + + After choosing a multicast group through a variety of means, hosts + just send the packets to the link-layer multicast address, and the + designated router will receive all the multicast packets and start + 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 + new IP address without significant impact on the delivery of their + transmission. SSM senders cannot change the IP address unless + receivers join the new channel or the sender uses an IP mobility + technique that is transparent to the receivers. + +2.6.2. Hosts Receiving Multicast + + Hosts signal their interest in receiving a multicast group or channel + by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are + still commonplace, but are also often used in new deployments. Some + + + +Savola Informational [Page 15] + +RFC 5110 Multicast Routing Overview January 2008 + + + vendors also support SSM mapping techniques for receivers which use + an older IGMP/MLD version where the router maps the join request to + an SSM channel based on various, usually complex means of + configuration. + +2.6.3. Summary + + The following table summarizes the techniques host interaction. + + +-------+------+----------------------------+ + | IPv4 | IPv6 | Notes | + +--------------------+-------+------+----------------------------+ + | Host sending | Yes | Yes | No support needed | + | Host receiving ASM | IGMP | MLD | Any IGMP/MLD version | + | Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping | + +--------------------+-------+------+----------------------------+ + +2.7. Restricting Multicast Flooding in the Link Layer + + Multicast transmission in the link layer, for example Ethernet, + typically includes some form of flooding the packets through a LAN. + This causes unnecessary bandwidth usage and discarding unwanted + frames on those nodes which did not want to receive the multicast + transmission. + + Therefore a number of techniques have been developed, to be used in + Ethernet switches between routers, or between routers and hosts, to + limit the flooding. + + Some mechanisms operate with IP addresses, others with MAC addresses. + If filtering is done based on MAC addresses, hosts may receive + unnecessary multicast traffic (filtered out in the hosts' IP layer) + if more than one IP multicast group addresses maps into the same MAC + address, or if IGMPv3/MLDv2 source filters are used. Filtering based + on IP destination addresses, or destination and sources addresses, + will help avoid these but requires parsing of the Ethernet frame + payload. + + These options are discussed in this section. + +2.7.1. Router-to-Router Flooding Reduction + + A proprietary solution, Cisco's RGMP [RFC3488] has been developed to + reduce the amount of flooding between routers in a switched networks. + This is typically only considered a problem in some Ethernet-based + Internet Exchange points or VPNs. + + + + + +Savola Informational [Page 16] + +RFC 5110 Multicast Routing Overview January 2008 + + + There have been proposals to observe and possibly react ("snoop") PIM + messages [PIM-SNOOP]. + +2.7.2. Host/Router Flooding Reduction + + 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). + + Cisco's proprietary CGMP [CGMP] provides a solution where the routers + notify the switches, but also allows the switches to snoop IGMP + packets to enable faster notification of hosts no longer wishing to + receive a group. Implementations of CGMP do not support fast leave + behaviour with IGMPv3. Due to IGMP report suppression in IGMPv1 and + IGMPv2, multicast is still flooded to ports which were once members + of a group as long as there is at least one receiver on the link. + Flooding restrictions are done based on multicast MAC addresses. + Implementations of CGMP do not support IPv6. + + IEEE 802.1D-2004 specification describes Generic Attribute + Registration Protocol (GARP), and GARP Multicast Registration + Protocol (GMRP) [GMRP] is a link-layer multicast group application of + GARP that notifies switches about MAC multicast group memberships. + If GMRP is used in conjunction with IP multicast, then the GMRP + registration function would become associated with an IGMP "join". + However, this GMRP-IGMP association is beyond the scope of GMRP. + GMRP requires support at the host stack and it has not been widely + implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete + being replaced by Multiple Registration Protocol (MRP) and Multicast + Multiple Registration Protocol (MMRP) that are being specified in + IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between + bridges. Some further information about GARP/GMRP is also available + in Appendix B of [RFC3488]. + + IGMP snooping [RFC4541] appears to be the most widely implemented + technique. IGMP snooping requires that the switches implement a + significant amount of IP-level packet inspection; this appears to be + something that is difficult to get right, and often the upgrades are + also a challenge. Snooping support is commonplace for IGMPv1 and + IGMPv2, but fewer switches support IGMPv3 or MLD (any version) + snooping. In the worst case, enabling IGMP snooping on a switch that + does not support IGMPv3 snooping breaks multicast capabilities of + nodes using IGMPv3. + + Snooping switches also need to identify the ports where routers + reside and therefore where to flood the packets. This can be + accomplished using Multicast Router Discovery protocol [RFC4286], + looking at certain IGMP queries [RFC4541], looking at PIM Hello and + possibly other messages, or by manual configuration. An issue with + + + +Savola Informational [Page 17] + +RFC 5110 Multicast Routing Overview January 2008 + + + PIM snooping at LANs is that PIM messages can't be turned off or + encrypted, leading to security issues [PIM-THREATS]. + + IGMP proxying [RFC4605] is sometimes used either as a replacement of + a multicast routing protocol on a small router, or to aggregate IGMP/ + MLD reports when used with IGMP snooping. + +2.7.3. Summary + + The following table summarizes the techniques for multicast flooding + reduction inside a single link for router-to-router and last-hop + LANs. + + +--------+-----+----------------------------+ + | R-to-R | LAN | Notes | + +-----------------------+--------+-----+----------------------------+ + | Cisco's RGMP | Yes | No | Replaced by PIM snooping | + | PIM snooping | Yes | No | Security issues in LANs | + | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare | + | Multicast Router Disc | No | Yes | Few if any implem. yet | + | IEEE GMRP and MMRP | No | No | No host/router deployment | + | Cisco's CGMP | No | Yes | Replaced by other snooping | + +-----------------------+--------+-----+----------------------------+ + +3. Acknowledgements + + Tutoring a couple multicast-related papers, the latest by Kaarle + Ritvanen [RITVANEN] convinced the author that up-to-date multicast + routing and address assignment/allocation documentation is necessary. + + Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, + Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat + Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon + Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, + Prashant Jhingran, and Tim Polk provided good comments, helping in + improving this document. + +4. IANA Considerations + + IANA has updated the following registries by adding a reference to + this document: + + o OSPFv2 Options Registry: MC-bit + + o OSPFv2 Link State (LS) Type: Group-membership-LSA + + o OSPFv2 Router Properties Registry: W-bit + + + + +Savola Informational [Page 18] + +RFC 5110 Multicast Routing Overview January 2008 + + + o OSPFv3 Options Registry: MC-bit + + o OSPFv3 LSA Function Code Registry: Group-membership-LSA + + o OSPFv3 Prefix Options Registry: MC-bit + +5. Security Considerations + + This memo only describes different approaches to multicast routing, + and this has no security considerations; the security analysis of the + mentioned protocols is out of scope of this memo. + + However, there has been analysis of the security of multicast routing + infrastructures [RFC4609], IGMP/MLD [MLD-SEC], and PIM last-hop + issues [PIM-THREATS]. + +6. References + +6.1. Normative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and + A. Thyagarajan, "Internet Group Management Protocol, + Version 3", RFC 3376, October 2002. + + [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery + Protocol (MSDP)", RFC 3618, October 2003. + + [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous + Point (RP) Address in an IPv6 Multicast Address", + RFC 3956, November 2004. + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. + Kouvelas, "Protocol Independent Multicast - Sparse + Mode (PIM-SM): Protocol Specification (Revised)", + RFC 4601, August 2006. + + [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast + for IP", RFC 4607, August 2006. + + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, + January 2007. + + + +Savola Informational [Page 19] + +RFC 5110 Multicast Routing Overview January 2008 + + + [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and + P. Pillay-Esnault, "Multi-Topology (MT) Routing in + OSPF", RFC 4915, June 2007. + + [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. + Vicisano, "Bidirectional Protocol Independent + Multicast (BIDIR-PIM)", RFC 5015, October 2007. + +6.2. Informative References + + [802.1ak] "IEEE 802.1ak - Multiple Registration Protocol", + <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", + <http://www.javvin.com/protocolCGMP.html>. + + [DVMRPv3] Pusateri, T., "Distance Vector Multicast Routing + Protocol", Work in Progress, December 2003. + + [DVMRPv3-AS] Pusateri, T., "Distance Vector Multicast Routing + Protocol Applicability Statement", Work in Progress, + May 2004. + + [DYNSSM-REQ] Lehtonen, R., Venaas, S., and M. Hoerdt, + "Requirements for discovery of dynamic SSM sources", + Work in Progress, February 2005. + + [GMRP] "GARP Multicast Registration Protocol", + <http://www.javvin.com/protocolGMRP.html>. + + [IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap + Analysis from the MBONED Working Group for the IESG + [Expired]", Work in Progress, July 2002. + + [IMRP-ISSUES] Meyer, D., "Some Issues for an Inter-domain Multicast + Routing Protocol", Work in Progress, November 1997. + + [M-ISIS] Przygienda, T., "M-ISIS: Multi Topology (MT) Routing + in IS-IS", Work in Progress, November 2007. + + [MCAST-ISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work + in Progress, February 2005. + + + + + +Savola Informational [Page 20] + +RFC 5110 Multicast Routing Overview January 2008 + + + [MLD-SEC] Daley, G. and G. Kurup, "Trust Models and Security in + Multicast Listener Discovery", Work in Progress, + July 2004. + + [PIM-SNOOP] Hemige, V., "PIM Snooping over VPLS", Work + in Progress, March 2007. + + [PIM-THREATS] Savola, P. and J. Lingard, "Host Threats to Protocol + Independent Multicast (PIM)", Work in Progress, + October 2007. + + [RFC1075] Waitzman, D., Partridge, C., and S. Deering, + "Distance Vector Multicast Routing Protocol", + RFC 1075, 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 Protocols", RFC 1458, May 1993. + + [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, + March 1994. + + [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) + Multicast Routing -- Protocol Specification --", + RFC 2189, September 1997. + + [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast + Routing Architecture", RFC 2201, September 1997. + + [RFC2715] Thaler, D., "Interoperability Rules for Multicast + Routing Protocols", RFC 2715, October 1999. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", + RFC 2784, March 2000. + + [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, + D., Lin, S., Leshchiner, D., Luby, M., Montgomery, + T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, + R., Sumanasekera, R., and L. Vicisano, "PGM Reliable + Transport Protocol Specification", RFC 3208, + December 2001. + + + + + + + +Savola Informational [Page 21] + +RFC 5110 Multicast Routing Overview January 2008 + + + [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, + "Anycast Rendevous Point (RP) mechanism using + Protocol Independent Multicast (PIM) and Multicast + Source Discovery Protocol (MSDP)", RFC 3446, + January 2003. + + [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port + Group Management Protocol (RGMP)", RFC 3488, + February 2003. + + [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group + Security Architecture", RFC 3740, March 2004. + + [RFC3913] Thaler, D., "Border Gateway Multicast Protocol + (BGMP): Protocol Specification", RFC 3913, + September 2004. + + [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol + Independent Multicast - Dense Mode (PIM-DM): Protocol + Specification (Revised)", RFC 3973, January 2005. + + [RFC4286] Haberman, B. and J. Martin, "Multicast Router + Discovery", RFC 4286, December 2005. + + [RFC4541] Christensen, M., Kimball, K., and F. Solensky, + "Considerations for Internet Group Management + Protocol (IGMP) and Multicast Listener Discovery + (MLD) Snooping 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, + "Internet Group Management Protocol (IGMP) / + Multicast Listener Discovery (MLD)-Based Multicast + Forwarding ("IGMP/MLD Proxying")", RFC 4605, + August 2006. + + [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol + Independent Multicast - Sparse Mode (PIM-SM) + Multicast Routing Security Issues and Enhancements", + RFC 4609, October 2006. + + [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol + Independent Multicast (PIM)", RFC 4610, August 2006. + + + + + + +Savola Informational [Page 22] + +RFC 5110 Multicast Routing Overview January 2008 + + + [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, + "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, + <http://www.tml.hut.fi/Studies/T-110.551/2004/ + papers/>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Savola Informational [Page 23] + +RFC 5110 Multicast Routing Overview January 2008 + + +Appendix A. Multicast Payload Transport Extensions + + A couple of mechanisms have been specified to improve the + characteristics of the data that can be transported over multicast. + + We describe those mechanisms that have impact on the multicast + routing infrastructure, e.g., require or specify router assistance or + involvement in some form. Purely end-to-end or host-based protocols + are out of scope. + +A.1. Reliable Multicast + + There has been some work on reliable multicast delivery so that + applications with reliability requirements could use multicast + instead of simple unreliable UDP. + + Most of the mechanisms are host-based and as such out of scope of + this document, but one relevant from multicast routing perspective is + Pragmatic Generic Multicast (PGM) [RFC3208]. It does not require + support from the routers, bur PGM-aware routers may act in router + assistance role in the initial delivery and potential retransmission + of missing data. + +A.2. Multicast Group Security + + Multicast Security Working Group has been working on methods how the + integrity, confidentiality, and authentication of data sent to + multicast groups can be ensured using cryptographic techniques + [RFC3740]. + +Author's Address + + Pekka Savola + CSC - Scientific Computing Ltd. + Espoo + Finland + + EMail: psavola@funet.fi + + + + + + + + + + + + + +Savola Informational [Page 24] + +RFC 5110 Multicast Routing Overview January 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Savola Informational [Page 25] + |