--- 1/draft-ietf-mboned-routingarch-04.txt 2006-07-12 22:12:41.000000000 +0200 +++ 2/draft-ietf-mboned-routingarch-05.txt 2006-07-12 22:12:41.000000000 +0200 @@ -1,22 +1,22 @@ Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET -Obsoletes: June 26, 2006 +Obsoletes: July 11, 2006 3913,2189,2201,1584,1585 (if approved) Intended status: Best Current Practice -Expires: December 28, 2006 +Expires: January 12, 2007 Overview of the Internet Multicast Routing Architecture - draft-ietf-mboned-routingarch-04.txt + draft-ietf-mboned-routingarch-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -27,80 +27,86 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 28, 2006. + This Internet-Draft will expire on January 12, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The lack of up-to-date documentation on IP multicast routing protocols and procedures has caused a great deal of confusion. To clarify the situation, this memo describes the routing protocols and techniques currently (as of this writing) in use. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 4 - 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 4 - 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 5 - 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 6 - 2.2. Distributing Topology Information . . . . . . . . . . . . 7 - 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 7 - 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 8 - 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 8 - 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 8 - 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 9 - 2.4. Configuring and Distributing PIM-SM RP Information . . . . 10 - 2.4.1. Manual Configuration with an Anycast Address . . . . . 10 - 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 10 - 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 11 - 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 11 - 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 11 - 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 12 - 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 12 - 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 12 - 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 12 - 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 12 - 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 13 - 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 13 - 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 13 - 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Appendix A. Multicast Payload Transport Extensions . . . . . . . 18 - A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18 - A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 19 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . . . 20 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 + 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 + 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6 + 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8 + 2.2. Distributing Topology Information . . . . . . . . . . . . 8 + 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9 + 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 + 2.4. Configuring and Distributing PIM RP Information . . . . . 12 + 2.4.1. Manual Configuration with an Anycast Address . . . . . 12 + 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 + 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13 + 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14 + 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14 + 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14 + 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 14 + 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 . . . . . . . . . . . . 16 + 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17 + 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 + Appendix A. Multicast Payload Transport Extensions . . . . . . . 22 + A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 22 + A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . . . . 24 1. Introduction Good, up-to-date documentation of IP multicast is close to non- existent. This issue is severely felt with multicast routing protocols and techniques. The consequence is that those who wish to learn of IP multicast and how the routing works in the real world do not know where to begin. Multicast addressing is described in a companion document [I-D.ietf-mboned-addrarch]. @@ -108,119 +114,144 @@ routing protocols and techniques. 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 PIM-SM 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 interacting with hosts (Section 2.6), and o restricting the multicast flooding in the link layer (Section 2.7). - Some multicast data transport issues are also introduced in - Appendix A. + 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 obsoletes and re-classifies to Historic [RFC2026] Border Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and [RFC1585]. The purpose of the re-classification is to give the readers (both implementors and deployers) an idea what the status of a protocol is; 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. 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 Group Address Resolution Protocol + GARP (IEEE 802.1D-2004) Generic Attribute Reg. Protocol + GMRP GARP Multicast Registration Protocol IGMP Internet Group Management Protocol MBGP Multi-protocol BGP (*not* "Multicast BGP") MLD Multicast Listener Discovery 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 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. + + When a host wants to receive a transmission, it first needs to find + out the multicast group address (and with SSM, source address) using + unspecified means. Then it will signal its interest to its router + using IGMP or MLD (Section 2.6). To deliver a multicast + transmission, the router will need to know how to build the + distribution tree which includes all the sources (Section 2.3) and/or + to locate the RP (Section 2.4) or one of RPs (Section 2.5). In + scenarios where multicast is routed via different topology than + unicast, a means to distribute topology information is required + (Section 2.2). Nonetheless, using whatever topology information is + available, the first-hop router initiates setting up hop-by-hop + multicast forwarding state (Section 2.1). When multicast + transmission arrives at the receiver's LAN, it is flooded to every + port unless flooding reduction such as IGMP snooping is employed + (Section 2.7). + 2.1. Setting up Multicast Forwarding State The most important part of multicast routing is setting up the multicast forwarding state. 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 [I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any Source Multicast (ASM) and Source-Specific Multicast (SSM) functionality; PIM-SSM is a subset of PIM-SM. Most current routing platforms support PIM-SM. 2.1.2. PIM-DM - Whereas PIM-SM is designed to avoid unnecessary flooding of multicast - data, PIM-DM [RFC3973] operates in a "dense" mode, flooding the + 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 traffic. + are not interested in that particular group. 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 is expected to want to receive the transmission so that the amount of state the network has to keep is - minimal. PIM-DM has been used to transition to PIM-SM but it is no - longer in widespread use. + minimal. - PIM-DM never became popular due to its reliance on data plane and - potential for loops, and the over-reliance of the complex Assert - mechanism. Further, it was a non-starter with high-bandwidth streams - due to its flooding paradigm. + 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" mode, - 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 been transitioned away from sparse- - dense to only sparse mode. + 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. Bi-directional PIM - Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined - PIM-SM operation, without data-driven events and data-encapsulation, - inside a PIM-SM domain. As it doesn't keep source-specific state, it - may be a lucrative approach especially in sites with a large number - of sources. + Bi-directional PIM [I-D.ietf-pim-bidir] 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 a + lucrative approach especially in sites with a large number of + sources. - As of this writing, in IPv6 or inter-domain multicast there is no - standards based mechanism for alerting routers that a group range is - to be used for bi-directional PIM. + As of this writing, there is no inter-domain solution to configure a + group range to use bi-directional PIM. 2.1.4. DVMRP Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] [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 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, @@ -251,52 +282,58 @@ CBT [RFC2201] 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 implemention. 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 (e.g., treat some groups as - dense mode in an otherwise PIM-SM network; this typically requires - manual configuration of the groups) or interaction between different - protocols (e.g., use DVMRP in the leaf network, but PIM-SM upstream). - The basics for interactions among different protocols have been - outlined in [RFC2715]. + with different multicast group ranges. For example, treat some + groups as dense or bi-dir 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. +-------------+-------------+----------------+ | Interdomain | Intradomain | Status | +------------+-------------+-------------+----------------+ | PIM-SM | Yes | Yes | Active | - | PIM-DM | Not feasible| Yes | Little use | - | Bi-dir PIM | No | Yes | Wait & see | + | PIM-DM | Not anymore | Not anymore | Little use | + | Bi-dir PIM | No | Yes | Some uptake | | DVMRP | Not anymore | Stub only | Going out | - | MOSF | No | Not anymore | Inactive | + | 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. + 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 - 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). + 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 @@ -320,23 +357,24 @@ 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 IGPs also provide the capability for signalling - a differing multicast topology, for example IS-IS multi-topology - extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists - for OSPF [I-D.ietf-ospf-mt]. + a differing topologies, for example IS-IS multi-topology extensions + [I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast + topology that differs from unicast. Similar but not so widely + implemented work exists for OSPF [I-D.ietf-ospf-mt]. It is worth noting that interdomain incongruence and intradomain incongruence are orthogonal, so one doesn't require the other. Specifically, interdomain incongruence is quite common, while intradomain incongruence isn't, so you see much more deployment of MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well without protocols handling intradomain incongruence. However, the availability of multi-topology mechanisms may in part replace the typically used workarounds such as tunnels. @@ -360,27 +398,44 @@ routing table. The important point to remember here, though, is to 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 + + The following table summarizes the topology distribution approaches + described in this Section. In particular, it is recommended that if + interdomain routing uses BGP, multicast-enabled sites should use MP- + BGP SAFI=1+2 even if the topology were congruent. + + +-------------+---------------+ + | Interdomain | Intradomain | + +--------------------- +--------------+--------------+ + | Congruent topology | Yes | Yes | + | BGP without SAFI | Not recomm. | Yes | + | MP-BGP SAFI=1+2 | Recommended | Yes | + | MP-BGP SAFI=3 | Doesn't work | Doesn't work | + | IS-IS multi-topology | No | Yes | + | OSPF multi-topology | No | Few implem. | + +----------------------+--------------+--------------+ + 2.3. Learning (Active) Sources Typically, multicast routing protocols must either assume that the receivers know the IP addresses of the (active) sources for a group in advance, possibly using an out-of-band mechanism (SSM), or the - sources must be discovered by the network protocols automatically - (ASM). + transmissions are forwarded to the receivers automatically (ASM). Learning active sources is a relatively straightforward process with 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 for many reasons. 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. @@ -420,46 +475,62 @@ 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). 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. -2.4. Configuring and Distributing PIM-SM RP Information +2.3.4. Summary - For PIM-SM, configuration mechanisms exist which are used to - configure the RP addresses and which groups are to use those RPs in - the routers. This section outlines the approaches. + The following table summarizes the source discovery approaches and + their status. + + +------+------+------------------------------+ + | IPv4 | IPv6 | Status | + +----------------------+------+------+------------------------------+ + | Bi-dir single domain | Yes | Yes | OK but for intra-domain only | + | PIM-SM single domain | Yes | Yes | OK | + | PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM | + | PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option | + | SSM | Yes | Yes | No major uptake yet | + +----------------------+------+------+------------------------------+ + +2.4. Configuring and Distributing PIM RP Information + + PIM-SM and Bi-dir PIM configuration mechanisms exist which are used + to configure the RP addresses and which groups are to use those RPs + in the routers. This section outlines the approaches. 2.4.1. Manual Configuration with an Anycast Address 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 (eg, 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 interfaces of the routers currently acting as RPs, as - described in [RFC3446]. + a loopback interfaces of the routers currently acting as RPs, and + state is distributed using PIM [I-D.ietf-pim-anycast-rp] or MSDP + [RFC3446]. Using this technique, each router might only need to be configured with one, portable RP address. 2.4.2. Embedded-RP Embedded-RP provides the information about the RP's address in the group addresses which 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. @@ -490,21 +561,37 @@ 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. + today unless there is a need to configure different properties (e.g., + sparse, dense, bi-dir) in a dynamic fashion. + +2.4.4. Summary + + The following table summarizes the RP discovery mechanisms and their + status. With the exception of Embedded-RP, each mechanism operates + within a PIM domain. + + +------+------+-----------------------+ + | IPv4 | IPv6 | Deployment | + +--------------------+------+------+-----------------------+ + | Static RP | Yes | Yes | Especially in ISPs | + | Auto-RP | Yes | No | Legacy deployment | + | BSR | Yes | Yes | Some, anycast simpler | + | Embedded-RP | No | Yes | Growing | + +--------------------+------+------+-----------------------+ 2.5. Mechanisms for Enhanced Redundancy A couple of mechanisms, already described in this document, have been used as a means to enhance redundancy, resilience against failures, and to recover from failures quickly. This section summarizes these techniques explicitly. 2.5.1. Anycast RP @@ -527,112 +614,172 @@ 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. 2.5.3. Bi-directional PIM Because bi-directional PIM (see Section 2.1.3) does not switch to - shortest path tree (SPT), the final multicast tree is built faster - and converges faster after failures. On the other hand, PIM-SM or - SSM may converge more quickly especially in scenarios where bi- - directional needs to re-do the Designated Forwarder election. + shortest path tree (SPT), the final multicast tree is 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 bi-directional needs to re-do the Designated Forwarder + election. + +2.5.4. Summary + + The following table summarizes the techniques for enhanced + redundancy. + + +------+------+-----------------------+ + | IPv4 | IPv6 | Deployment | + +--------------------+------+------+-----------------------+ + | Anycast RP w/ MSDP | Yes | No | De-facto approach | + | Anycast RP w/ PIM | Yes | Yes | New, simpler than MSDP| + | Stateless RP fail. | Yes | Yes | Causes disturbance | + | Bi-dir PIM | Yes | Yes | Deployed at some sites| + +-------------+------+------+------------------------------+ 2.6. Interactions with Hosts 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. - 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. + 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 - also commonplace, but most new deployments support the latest - specifications. + still commonplace, but are also often used in new deployments. Some + vendors also support SSM mapping techniques for receivers which use + an older IGMP/MLD version where the router maps the join request to + an SSM channel based on various, usually complex means of + configuration. + +2.6.3. Summary + + The following table summarizes the techniques host interaction. + + +-------+------+----------------------+ + | IPv4 | IPv6 | Notes | + +--------------------+-------+------+----------------------+ + | Host sending | Yes | Yes | No support needed | + | Host receiving ASM | IGMP | MLD | Any IGMP/MLD version | + | Host receiving SSM | IGMPv3| MLDv2| Also SSM-mapping | + +--------------------+-------+------+----------------------+ 2.7. Restricting Multicast Flooding in the Link Layer 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. 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 router-to-router flooding on a LAN. This is - typically only considered a problem in some Ethernet-based Internet - Exchange points. + 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. There have been proposals to observe and possibly react ("snoop") PIM messages [I-D.tsenevir-pim-sm-snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve the same effect. 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. IPv6 is not supported. - IEEE specifications mention Group Address Resolution Protocol (GARP) - [GARP] as a link-layer method to perform the same functionality. The - implementation status is unknown. + 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 IP multicast group memberships. + GMRP requires support at the host stack and implementation status + especially on hosts is unknown. Some further information about GARP/ + GMRP is also available in Appendix B of [RFC3488]. IGMP snooping [RFC4541] appears to be the most widely implemented 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 switches also need to identify the ports - where routers reside (and therefore where to flood the packets) using - Multicast Router Discovery protocol [RFC4286], looking at certain - IGMP queries [RFC4541], or by manual configuration. IGMP proxying - [I-D.ietf-magma-igmp-proxy] is sometimes used either as a replacement - of a multicast routing protocol on a small router, or to aggregate - IGMP/MLD reports when used with IGMP snooping. + also a challenge. + + 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 + PIM snooping at LANs is that PIM messages can't be turned off or + encrypted, leading to security issues + [I-D.savola-pim-lasthop-threats]. + + IGMP proxying [I-D.ietf-magma-igmp-proxy] is sometimes used either as + a replacement of a multicast routing protocol on a small router, or + to aggregate IGMP/MLD reports when used with IGMP snooping. + +2.7.3. Summary + + The following table summarizes the techniques for multicast flooding + reduction inside a single link for router-to-router and last-hop + LANs. + + +--------+-----+---------------------------+ + | R-to-R | LAN | Notes | + +-----------------------+--------+-----+---------------------------+ + | Cisco's RGMP | Yes | No | Replaced by PIM snooping | + | PIM snooping | Yes | No | Security issues in LANs | + | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD bad | + | Multicast Router Disc | No | Yes | Few if any implem. yet | + | IEEE 802.1D-2004 GMRP | No | Yes | Impl. status unknown | + | Cisco's CGMP | No | Yes | Replaced by other snooping| + +-----------------------+--------+-----+---------------------------+ 3. Acknowledgements 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, and Spencer Dawkins - provided good comments, helping in improving this document. + Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon + Chisholm, and John Zwiebel provided good comments, helping in + improving this document. 4. IANA Considerations This memo includes no request to IANA. 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. @@ -703,22 +850,22 @@ [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. 6.2. Informative References [CGMP] "Cisco Group Management Protocol", . - [GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study - of IEEE 802.1p GARP/GMRP Timer Values", 1997. + [GMRP] "GARP Multicast Registration Protocol", + . [I-D.daley-magma-smld-prob] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", draft-daley-magma-smld-prob-00 (work in progress), July 2004. [I-D.ietf-idmr-dvmrp-v3-as] Pusateri, T., "Distance Vector Multicast Routing Protocol Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01