idnits 2.17.1 draft-ietf-mboned-routingarch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 899. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2005) is 6770 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.daley-magma-smld-prob' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-magma-mrdisc' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'I-D.savola-pim-lasthop-threats' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'I-D.tsenevir-pim-sm-snoop' is defined on line 769, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'I-D.ietf-idmr-dvmrp-v3') ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3-as (ref. 'I-D.ietf-idmr-dvmrp-v3-as') == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-10 == Outdated reference: A later version (-09) exists of draft-ietf-ospf-mt-04 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-pim-dm-new-v2 (ref. 'I-D.ietf-pim-dm-new-v2') == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-11 ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Downref: Normative reference to an Experimental RFC: RFC 3618 == Outdated reference: A later version (-10) exists of draft-ietf-idr-rfc2858bis-07 == Outdated reference: A later version (-07) exists of draft-ietf-pim-anycast-rp-04 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-05 == Outdated reference: A later version (-02) exists of draft-savola-pim-lasthop-threats-01 Summary: 8 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet-Draft CSC/FUNET 4 Obsoletes: October 12, 2005 5 3913,2189,2201,1584,1585 (if 6 approved) 7 Expires: April 15, 2006 9 Overview of the Internet Multicast Routing Architecture 10 draft-ietf-mboned-routingarch-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 15, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The lack of up-to-date documentation on IP multicast routing 44 protocols and procedures has caused a great deal of confusion. To 45 clarify the situation, this memo describes the routing protocols and 46 techniques currently (as of this writing) in use. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 4 52 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 4 54 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 5 57 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 6 62 2.2. Distributing Topology Information . . . . . . . . . . . . 7 63 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 7 64 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 7 65 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 8 66 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 8 67 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 9 70 2.4. Configuring and Distributing PIM-SM RP Information . . . . 10 71 2.4.1. Manual Configuration with an Anycast Address . . . . . 10 72 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 10 73 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 11 74 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 11 75 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 11 76 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 11 77 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 12 78 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 12 79 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 12 80 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 12 81 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 12 82 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 13 83 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 13 84 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 89 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 90 Appendix A. Multicast Payload Transport Extensions . . . . . . . 18 91 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18 92 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 18 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 Intellectual Property and Copyright Statements . . . . . . . . . . 19 96 1. Introduction 98 Good, up-to-date documentation of IP multicast is close to non- 99 existent. This issue is severely felt with multicast routing 100 protocols and techniques. The consequence is that those who wish to 101 learn of IP multicast and how the routing works in the real world do 102 not know where to begin. 104 The aim of this document is to provide a brief overview of multicast 105 routing protocols and techniques. 107 This memo deals with: 109 o setting up multicast forwarding state (Section 2.1), 111 o distributing multicast topology information (Section 2.2), 113 o learning active sources (Section 2.3), 115 o configuring and distributing the PIM-SM RP information 116 (Section 2.4), 118 o mechanisms for enhanced redundancy (Section 2.5), 120 o interacting with hosts (Section 2.6), and 122 o restricting the multicast flooding in the link layer 123 (Section 2.7). 125 Some multicast data transport issues are also introduced in 126 Appendix A. 128 This memo obsoletes and re-classifies to Historic [RFC2026] Border 129 Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast 130 OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and 131 [RFC1585]. The purpose of the re-classification is to give the 132 readers (both implementors and deployers) an idea what the status of 133 a protocol is; there may or may not be legacy deployments of these 134 protocols, which are not affected by this reclassification. See 135 Section 2.1 for more on each protocol. 137 1.1. Multicast-related Abbreviations 139 ASM Any Source Multicast 140 BGMP Border Gateway Multicast Protocol 141 BSR Bootstrap Router 142 CBT Core Based Trees 143 CGMP Cisco Group Management Protocol 144 DR Designated Router 145 DVMRP Distance Vector Multicast Routing Protocol 146 GARP Group Address Resolution Protocol 147 IGMP Internet Group Management Protocol 148 MLD Multicast Listener Discovery 149 MSNIP Multicast Source Notification of Interest Protocol 150 MOSPF Multicast OSPF 151 MBGP Multi-protocol BGP (*not* "Multicast BGP") 152 MSDP Multicast Source Discovery Protocol 153 PGM Pragmatic General Multicast 154 PIM Protocol Independent Multicast 155 PIM-DM PIM - Dense Mode 156 PIM-SM PIM - Sparse Mode 157 PIM-SSM PIM - (Source-specific) Sparse Mode 158 RGMP (Cisco's) Router Group Management Protocol 159 RP Rendezvous Point 160 SSM Source-specific Multicast 162 2. Multicast Routing 164 2.1. Setting up Multicast Forwarding State 166 The most important part of multicast routing is setting up the 167 multicast forwarding state. This section describes the protocols 168 commonly used for this purpose. 170 2.1.1. PIM-SM 172 By far, the most common multicast routing protocol is PIM-SM 173 [I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any 174 Source Multicast (ASM) and Source-Specific Multicast (SSM) 175 functionality; PIM-SSM is a subset of PIM-SM. Most current routing 176 platforms support PIM-SM. 178 2.1.2. PIM-DM 180 Whereas PIM-SM is designed to avoid unnecessary flooding of multicast 181 data, PIM-DM [I-D.ietf-pim-dm-new-v2] operates in a "dense" mode, 182 flooding the multicast transmissions throughout the network ("flood 183 and prune") unless the leaf parts of the network periodically 184 indicate that they are not interested in that particular traffic. 186 PIM-DM may be some fit in small and/or simple networks, where setting 187 up an RP would be unnecessary, and possibly in cases where a large 188 number of users is expected to be able to wish to receive the 189 transmission so that the amount of state the network has to keep is 190 minimal. Therefore PIM-DM has typically only been used in special 191 deployments, never currently in, e.g., ISPs' networks. 193 PIM-DM never really got popular due to its reliance of data plane and 194 potential for loops, and the over-reliance of the complex Assert 195 mechanism. Further, it was a non-starter with high-bandwidth 196 streams. 198 Many implementations also support so-called "sparse-dense" mode, 199 where Sparse mode is is used by default, but Dense is used for 200 configured multicast group ranges (such as Auto-RP in Section 2.4.3) 201 only. Lately, many networks have been transitioned away from sparse- 202 dense to only sparse mode. 204 2.1.3. Bi-directional PIM 206 Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined 207 PIM-SM operation, without data-driven events and data-encapsulation, 208 inside a PIM-SM domain. The usage of bi-dir PIM may be on the 209 increase especially inside sites leveraging multicast. 211 As of this writing, in IPv6 or inter-domain multicast there is no 212 standards based mechanism for alerting routers that a group range is 213 to be used for bi-directional PIM. 215 2.1.4. DVMRP 217 Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] 218 [I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first 219 protocol designed for multicasting, and to get around initial 220 deployment hurdles, it also included tunneling capabilities which 221 were part of its multicast topology functions. 223 Currently, DVMRP is used only very rarely in operator networks, 224 having been replaced with PIM-SM. The most typical deployment of 225 DVMRP is at a leaf network, to run from a legacy firewall only 226 supporting DVMRP to the internal network. However, GRE tunneling 227 [RFC2784] seems to have overtaken DVMRP in this functionality, and 228 there is relatively little use for DVMRP except in legacy 229 deployments. 231 2.1.5. MOSPF 233 MOSPF [RFC1584] was implemented by several vendors and has seen some 234 deployment in intra-domain networks. However, since it does not 235 scale to the inter-domain case, operators have found it is easier to 236 deploy a single protocol for use in both intra-domain and inter- 237 domain networks and so it is no longer being actively deployed. 239 2.1.6. BGMP 241 BGMP [RFC3913] did not get sufficient support within the service 242 provider community to get adopted and moved forward in the IETF 243 standards process. There were no reported production implementations 244 and no production deployments. 246 2.1.7. CBT 248 CBT [RFC2201] was was an academic project that provided the basis for 249 PIM sparse mode shared trees. Once the shared tree functionality was 250 incorporated into PIM implementations, there was no longer a need for 251 a production CBT implemention. Therefore, CBT never saw production 252 deployment. 254 2.1.8. Interactions and Summary 256 It is worth noting that is it is possible to run different protocols 257 with different groups ranges (e.g., treat some groups as dense mode 258 in an other-wise PIM-SM network; this typically requires manual 259 configuration of the groups) or interact between different protocols 260 (e.g., use DVMRP in the leaf network, but PIM-SM upstream). The 261 basics for interactions among different protocols have been outlined 262 in [RFC2715]. 264 The following figure gives a concise summary of the deployment status 265 of different protocols as of this writing. 267 +-------------+-------------+----------------+ 268 | Interdomain | Intradomain | Status | 269 +------------+-------------+-------------+----------------+ 270 | PIM-SM | Yes | Yes | Active | 271 | PIM-DM | Not feasible| Yes | Little use | 272 | Bi-dir PIM | No | Yes | Wait & see | 273 | DVMRP | Not anymore | Stub only | Going out | 274 | MOSF | No | Not anymore | Inactive | 275 | CBT | No | No | Never deployed | 276 | BGMP | No | No | Never deployed | 277 +------------+-------------+-------------+----------------+ 278 From this table, it is clear that PIM-Sparse Mode is the only 279 multicast routing protocol that is deployed inter-domain and, 280 therefore, is most frequently used within multicast domains as well. 282 2.2. Distributing Topology Information 284 When unicast and multicast topologies are the same ("congruent"), 285 i.e., use the same routing tables (routing information base, RIB), it 286 has been considered sufficient just to distribute one set of 287 reachability information. 289 However, when PIM -- which by default built multicast topology based 290 on the unicast topology -- gained popularity, it became apparent that 291 it would be necessary to be able to distribute also non-congruent 292 multicast reachability information in the regular unicast protocols. 293 This was previously not an issue, because DVMRP built its own 294 reachability information. 296 The topology information is needed to perform efficient distribution 297 of multicast transmissions and to prevent transmission loops by 298 applying it to the Reverse Path Forwarding (RPF) check. 300 This subsection introduces these protocols. 302 2.2.1. Multi-protocol BGP 304 Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as 305 "MBGP"; however, it is worth noting that "MBGP" does *not* stand for 306 "Multicast BGP") specifies a mechanism by which BGP can be used to 307 distribute different reachability information for unicast and 308 multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP 309 has been widely deployed for years, and is also needed to route IPv6. 310 Note that SAFI=3 was originally specified for "both unicast and 311 multicast" but has been deprecated [I-D.ietf-idr-rfc2858bis]. 313 These extensions are in widespread use wherever BGP is used to 314 distribute unicast topology information. Those having multicast 315 infrastructure and using BGP should use Multiprotocol BGP to 316 distribute multicast reachability information explicitly even if the 317 topologies are congruent. A number of significant multicast transit 318 providers even require this, by doing the RPF lookups solely based on 319 explicitly advertised multicast address family. 321 2.2.2. OSPF/IS-IS Multi-topology Extensions 323 Similar to BGP, some IGPs also provide the capability for signalling 324 a differing multicast topology, for example IS-IS multi-topology 325 extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists 326 for OSPF [I-D.ietf-ospf-mt]. 328 It is worth noting that interdomain incongruence and intradomain 329 incongruence are orthogonal, so one doesn't require the other. 330 Specifically, interdomain incongruence is quite common, while 331 intradomain incongruence isn't, so you see much more deployments of 332 MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well 333 without protocols handling intradomain incongruence. However, the 334 availability of multi-topology mechanisms may in part replace the 335 typically used workarounds such as tunnels. 337 2.2.3. Issue: Overlapping Unicast/multicast Topology 339 An interesting case occurs when some routers do not distribute 340 multicast topology information explicitly while others do. In 341 particular, this happens when some multicast sites in the Internet 342 are using plain BGP while some use MBGP. 344 Different implementations deal with this using different means. 345 Sometimes, multicast RPF mechanisms first look up the multicast 346 routing table, or RIB ("topology database") with a longest prefix 347 match algorithm, and if they find any entry (including a default 348 route), that is used; if no match is found, the unicast routing table 349 is used instead. 351 An alternative approach is to use longest prefix match on the union 352 of multicast and unicast routing tables; an implementation technique 353 here is to copy the whole unicast routing table over to the multicast 354 routing table. The important point to remember here, though, is to 355 not override the multicast-only routes; if the longest prefix match 356 would find both a (copied) unicast route and a multicast-only route, 357 the latter should be treated as preferable. 359 One implemented approach is to just look up the information in the 360 unicast routing table, and provide the user capabilities to change 361 that as appropriate, using for example copying functions discussed 362 above. 364 2.3. Learning (Active) Sources 366 Typically, multicast routing protocols must either assume that the 367 receivers know the IP addresses of the (active) sources for a group a 368 priori, possibly using an out-of-band mechanism (SSM), or the sources 369 must be discovered by the network protocols automatically (ASM). 371 Learning active sources is a relatively straightforward process with 372 a single PIM-SM domain and with a single RP, but having a single 373 PIM-SM domain for the whole Internet is a completely unscalable model 374 for many reasons. Therefore it is required to be able to split up 375 the multicast routing infrastructures to smaller domains, and there 376 must be a way to share information about active sources using some 377 mechanism if the ASM model is to be supported. 379 This section discusses the options. 381 2.3.1. SSM 383 Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also 384 referred to as "single-source Multicast") does not count on learning 385 active sources in the network; it is assumed that the recipients know 386 these using out of band mechanisms, and when subscribing to an (S,G) 387 channel indicate toward which source(s) the multicast routing 388 protocol should send the Join messages. 390 As of this writing, there are attempts to analyze and/or define out- 391 of-band source discovery functions which would help SSM in particular 392 [I-D.lehtonen-mboned-dynssm-req]. 394 2.3.2. MSDP 396 Multicast Source Discovery Mechanism [RFC3618] was invented as a 397 stop-gap mechanism, when it became apparent that multiple PIM-SM 398 domains (and RPs) were needed in the network, and information about 399 the active sources needed to be propagated between the PIM-SM domains 400 using some other protocol. 402 MSDP is also used to share the state about sources between multiple 403 RPs in a single domain for, e.g., redundancy purposes [RFC3446]. 404 There is also work in progress to achieve the same using PIM 405 extensions [I-D.ietf-pim-anycast-rp]. See Section 2.5 for more. 407 There is no intent to define MSDP for IPv6, but instead use only SSM 408 and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. 410 2.3.3. Embedded-RP 412 Embedded-RP [RFC3956] is an IPv6-only technique to map the address of 413 the RP to the multicast group address. Using this method, it is 414 possible to avoid the use of MSDP while still allowing multiple 415 multicast domains (in the traditional sense). 417 The model works by defining a single RP for a particular group for 418 all of the Internet, so there is no need to share state about that 419 with any other RPs (except, possibly, for redundancy purposes with 420 Anycast-RP using PIM). 422 2.4. Configuring and Distributing PIM-SM RP Information 424 For PIM-SM, configuration mechanisms exist which are used to 425 configure the RP addresses and which groups are to use those RPs in 426 the routers. This section outlines the approaches. 428 2.4.1. Manual Configuration with an Anycast Address 430 It is often easiest just to manually configure the RP information on 431 the routers when PIM-SM is used. 433 Originally, static RP mapping was considered suboptimal since it 434 required explicit configuration chages every time the RP address 435 changed. However, with the advent of anycast RP addressing, the RP 436 address is unlikely to ever change. Therefore, the administrative 437 burden is generally limited to initial configuration. Since there is 438 usually a fair amount of multicast configuration required on all 439 routers anyway (eg, PIM on all interfaces), adding the RP address 440 statically isn't really an issue. Further, static anycast RP mapping 441 provides the benefits of RP load balancing and redundancy (see 442 Section 2.5) without the complexity found in dynamic mechanisms like 443 Auto-RP and Bootstrap Router (BSR). 445 With such design, an anycast RP uses a "portable" address, which is 446 configured on a loopback interfaces of the routers currently acting 447 as RPs, as described in [RFC3446]. 449 Using this technique, each router might only need to be configured 450 with one, portable RP address. 452 2.4.2. Embedded-RP 454 Embedded-RP provides the information about the RP's address in the 455 group addresses which are delegated to those who use the RP, so 456 unless no other ASM than Embedded-RP is used, one only needs to 457 configure the RP routers themselves. 459 While Embedded-RP in many cases is sufficient for IPv6, other methods 460 of RP configuration are needed if one needs to provide ASM service 461 for other than Embedded-RP group addresses. In particular, service 462 discovery type of applications may need hard-coded addresses that are 463 not dependent on local RP addresses. 465 As the RP's address is exposed to the users and applications, it is 466 very important to ensure it does not change often, e.g., by using 467 manual configuration of an anycast address. 469 2.4.3. BSR and Auto-RP 471 BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP 472 address for groups. It may no longer be in as wide use with IPv4 as 473 it was ealier, and for IPv6, Embedded-RP will in many cases be 474 sufficient. 476 Cisco's Auto-RP is an older, proprietary method for distributing 477 group to RP mappings, similar to BSR. Auto-RP has little use today. 479 Both Auto-RP and BSR require some form of control at the routers to 480 ensure that only valid routers are able to advertise themselves as 481 RPs. Further, flooding of BSR and Auto-RP messages must be prevented 482 at PIM borders. Additionally, routers require monitoring that they 483 are actually using the RP(s) the administrators think they should be 484 using, for example if a router (maybe in customer's control) is 485 advertising itself inappropriately. All in all, while BSR and 486 Auto-RP provide easy configuration, they also provide very 487 significant configuration and management complexity. 489 It is worth noting that both Auto-RP and BSR were deployed before the 490 use of a manually configured anycast-RP address became relatively 491 commonplace, and there is actually relatively little use for them 492 today. 494 2.5. Mechanisms for Enhanced Redundancy 496 A couple of mechanisms, already described in this document, have been 497 used as a means to enhance redundancy, resilience against failures, 498 and to recover from failures quickly. This section summarizes these 499 techniques explicitly. 501 2.5.1. Anycast RP 503 As mentioned in Section 2.3.2, MSDP is also used to share the state 504 about sources between multiple RPs in a single domain for, e.g., 505 redundancy purposes [RFC3446]. The purpose of MSDP in this context 506 is to share the same state information on multiple RPs for the same 507 groups to enhance the robustness of the service. 509 There is also work in progress to achieve the same using PIM 510 extensions [I-D.ietf-pim-anycast-rp]. This is a required method to 511 be able to use Anycast RP with IPv6. 513 2.5.2. Stateless RP Failover 515 It is also possible to use some mechanisms for smaller amount of 516 redundancy as Anycast RP, without sharing state between the RPs. A 517 traditional mechanism has been to use Auto-RP or BSR (see 518 Section 2.4.3) to select another RP when the active one failed. 519 However, the same functionality could be achieved using a shared- 520 unicast RP address ("anycast RP without state sharing") without the 521 complexity of a dynamic mechanism. Further, Anycast RP offers a 522 significantly more extensive failure mitigation strategy, so today 523 there is actually very little need to use stateless failover 524 mechanisms, especially dynamic ones, for redundancy purposes. 526 2.5.3. Bi-directional PIM 528 Bi-directional PIM (see Section 2.1.3) uses less state than PIM-SM, 529 implying a better total convergence. On the other hand, PIM-SM or 530 SSM may be faster especially in scenarios where bi-directional needs 531 to re-do the Designated Forwarder election. 533 2.6. Interactions with Hosts 535 Previous sections have dealt with the components required by routers 536 to be able to do multicast routing. Obviously, the real users of 537 multicast are the hosts: either sending or receiving multicast. This 538 section describes the required interactions with hosts. 540 2.6.1. Hosts Sending Multicast 542 Hosts don't need to do any signalling prior to sending multicast to a 543 group; they just send the packets to the link-layer multicast 544 address, and the designated router will receive all the multicast 545 packets and start forwarding them as appropriate. 547 2.6.2. Hosts Receiving Multicast 549 Hosts signal their interest in receiving a multicast group or channel 550 by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are 551 also commonplace, but most new deployments support the latest 552 specifications. 554 2.7. Restricting Multicast Flooding in the Link Layer 556 Multicast transmission in the link layer, for example Ethernet, 557 typically includes some form of flooding the packets through a LAN. 558 This causes unnecessary bandwidth usage and discarding unwanted 559 frames on those nodes which did not want to receive the multicast 560 transmission. 562 Therefore a number of techniques have been developed, to be used in 563 Ethernet switches between routers, or between routers and hosts, to 564 limit the flooding. 566 These options are discussed in this section. 568 2.7.1. Router-to-Router Flooding Reduction 570 A proprietary solution, Cisco's RGMP [RFC3488] has been developed to 571 reduce the amount of router-to-router flooding on a LAN. This is 572 typically only considered a problem in some Ethernet-based Internet 573 Exchange points. 575 There have been proposals to snoop PIM messages [I-D.tsenevir-pim-sm- 576 snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve the same effect. 578 2.7.2. Host/Router Flooding Reduction 580 There are a number of techniques to help reduce flooding both from a 581 router to hosts, and from a host to the routers (and other hosts). 583 Cisco's proprietary CGMP [CGMP] provides a solution where the routers 584 notify the switches, but also allows the switches to snoop IGMP 585 packets to enable faster notification of hosts no longer wishing to 586 receive a group. IPv6 is not supported. 588 IEEE specifications mention Group Address Resolution Protocol (GARP) 589 [GARP] as a link-layer method to perform the same functionality. The 590 implementation status is unknown. 592 IGMP snooping [I-D.ietf-magma-snoop] appears to be the most widely 593 implemented technique. IGMP snooping requires that the switches 594 implement a significant amount of IP-level packet inspection; this 595 appears to be something that is difficult to get right, and often the 596 upgrades are also a challenge. To allow the snooping switches to 597 identify at which ports the routers reside (and therefore where to 598 flood the packets) instead of requiring manual configuration, 599 Multicast Router Discovery protocol is being specified [I-D.ietf- 600 magma-mrdisc]. IGMP proxying [I-D.ietf-magma-igmp-proxy] is 601 sometimes used either as a replacement of a multicast routing 602 protocol on a small router, or to aggregate IGMP/MLD reports when 603 used with IGMP snooping. 605 3. Acknowledgements 607 Tutoring a couple multicast-related papers, the latest by Kaarle 608 Ritvanen [RITVANEN] convinced the author that the up-to-date 609 multicast routing and address assignment/allocation documentation is 610 necessary. 612 Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, 613 Stig Venaas, Tom Pusateri, Marshall Eubanks, and Dino Farinacci 614 provided good comments, helping in improving this document. 616 4. IANA Considerations 618 This memo includes no request to IANA. 620 5. Security Considerations 622 This memo only describes different approaches to multicast routing, 623 and this has no security considerations; the security analysis of the 624 mentioned protocols is out of scope of this memo. 626 However, there has been analysis of the security of multicast routing 627 infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD [I-D.daley- 628 magma-smld-prob], and PIM last-hop issues [I-D.savola-pim-lasthop- 629 threats]. 631 6. References 633 6.1. Normative References 635 [I-D.ietf-idmr-dvmrp-v3] 636 Pusateri, T., "Distance Vector Multicast Routing 637 Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), 638 December 2003. 640 [I-D.ietf-idmr-dvmrp-v3-as] 641 Pusateri, T., "Distance Vector Multicast Routing Protocol 642 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 643 (work in progress), May 2004. 645 [I-D.ietf-isis-wg-multi-topology] 646 Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in 647 IS-IS", draft-ietf-isis-wg-multi-topology-10 (work in 648 progress), May 2005. 650 [I-D.ietf-ospf-mt] 651 Psenak, P., "Multi-Topology (MT) Routing in OSPF", 652 draft-ietf-ospf-mt-04 (work in progress), April 2005. 654 [I-D.ietf-pim-bidir] 655 Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 656 "Bi-directional Protocol Independent Multicast (BIDIR- 657 PIM)", draft-ietf-pim-bidir-07 (work in progress), 658 March 2005. 660 [I-D.ietf-pim-dm-new-v2] 661 Adams, A., Nicholas, J., and W. Siadak, "Protocol 662 Independent Multicast - Dense Mode (PIM-DM): Protocol 663 Specification (Revised)", draft-ietf-pim-dm-new-v2-05 664 (work in progress), June 2004. 666 [I-D.ietf-pim-sm-v2-new] 667 Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 668 "Protocol Independent Multicast - Sparse Mode PIM-SM): 669 Protocol Specification (Revised)", 670 draft-ietf-pim-sm-v2-new-11 (work in progress), 671 October 2004. 673 [I-D.ietf-ssm-arch] 674 Holbrook, H. and B. Cain, "Source-Specific Multicast for 675 IP", draft-ietf-ssm-arch-07 (work in progress), 676 October 2005. 678 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 679 3", BCP 9, RFC 2026, October 1996. 681 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 682 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 684 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 685 Thyagarajan, "Internet Group Management Protocol, Version 686 3", RFC 3376, October 2002. 688 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 689 Protocol (MSDP)", RFC 3618, October 2003. 691 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 692 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 694 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 695 Point (RP) Address in an IPv6 Multicast Address", 696 RFC 3956, November 2004. 698 6.2. Informative References 700 [CGMP] "Cisco Group Management Protocol", 701 . 703 [GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study 704 of IEEE 802.1p GARP/GMRP Timer Values", 1997. 706 [I-D.daley-magma-smld-prob] 707 Daley, G. and G. Kurup, "Trust Models and Security in 708 Multicast Listener Discovery", 709 draft-daley-magma-smld-prob-00 (work in progress), 710 July 2004. 712 [I-D.ietf-idr-rfc2858bis] 713 Bates, T., "Multiprotocol Extensions for BGP-4", 714 draft-ietf-idr-rfc2858bis-07 (work in progress), 715 August 2005. 717 [I-D.ietf-magma-igmp-proxy] 718 Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ 719 MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", 720 draft-ietf-magma-igmp-proxy-06 (work in progress), 721 April 2004. 723 [I-D.ietf-magma-mrdisc] 724 Haberman, B. and J. Martin, "Multicast Router Discovery", 725 draft-ietf-magma-mrdisc-07 (work in progress), May 2005. 727 [I-D.ietf-magma-snoop] 728 Christensen, M., Kimball, K., and F. Solensky, 729 "Considerations for IGMP and MLD Snooping Switches", 730 draft-ietf-magma-snoop-12 (work in progress), 731 February 2005. 733 [I-D.ietf-mboned-ipv6-multicast-issues] 734 Savola, P., "IPv6 Multicast Deployment Issues", 735 draft-ietf-mboned-ipv6-multicast-issues-02 (work in 736 progress), February 2005. 738 [I-D.ietf-mboned-mroutesec] 739 Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast 740 Routing Security Issues and Enhancements", 741 draft-ietf-mboned-mroutesec-04 (work in progress), 742 October 2004. 744 [I-D.ietf-pim-anycast-rp] 745 Farinacci, D. and Y. Cai, "Anycast-RP using PIM", 746 draft-ietf-pim-anycast-rp-04 (work in progress), 747 August 2005. 749 [I-D.ietf-pim-sm-bsr] 750 Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", 751 draft-ietf-pim-sm-bsr-05 (work in progress), 752 February 2005. 754 [I-D.lehtonen-mboned-dynssm-req] 755 Lehtonen, R., "Requirements for discovery of dynamic SSM 756 sources", draft-lehtonen-mboned-dynssm-req-00 (work in 757 progress), February 2005. 759 [I-D.savola-pim-lasthop-threats] 760 Savola, P., "Last-hop Threats to Protocol Independent 761 Multicast (PIM)", draft-savola-pim-lasthop-threats-01 762 (work in progress), January 2005. 764 [I-D.serbest-l2vpn-vpls-mcast] 765 Serbest, Y., "Supporting IP Multicast over VPLS", 766 draft-serbest-l2vpn-vpls-mcast-03 (work in progress), 767 July 2005. 769 [I-D.tsenevir-pim-sm-snoop] 770 Senevirathne, T. and S. Vallepali, "Protocol Independent 771 Multicast-Sparse Mode (PIM-SM) Snooping", 772 draft-tsenevir-pim-sm-snoop-00 (work in progress), 773 April 2002. 775 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 776 Vector Multicast Routing Protocol", RFC 1075, 777 November 1988. 779 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 780 March 1994. 782 [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, 783 March 1994. 785 [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 786 Routing -- Protocol Specification --", RFC 2189, 787 September 1997. 789 [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing 790 Architecture", RFC 2201, September 1997. 792 [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing 793 Protocols", RFC 2715, October 1999. 795 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 796 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 797 March 2000. 799 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 800 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 801 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 802 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 803 Protocol Specification", RFC 3208, December 2001. 805 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 806 Rendevous Point (RP) mechanism using Protocol Independent 807 Multicast (PIM) and Multicast Source Discovery Protocol 808 (MSDP)", RFC 3446, January 2003. 810 [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group 811 Management Protocol (RGMP)", RFC 3488, February 2003. 813 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 814 Architecture", RFC 3740, March 2004. 816 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 817 Protocol Specification", RFC 3913, September 2004. 819 [RITVANEN] 820 Ritvanen, K., "Multicast Routing and Addressing", HUT 821 Report, Seminar on Internetworking, May 2004, 822 . 824 Appendix A. Multicast Payload Transport Extensions 826 A couple of mechanisms have been, and are being specified, to improve 827 the characteristics of the data that can be transported over 828 multicast. 830 These go beyond the scope of multicast routing, but as reliable 831 multicast has some relevance, these are briefly mentioned. 833 A.1. Reliable Multicast 835 Reliable Multicast Working Group has been working on experimental 836 specifications so that applications requiring reliable delivery 837 characteristics, instead of simple unreliable UDP, could use 838 multicast as a distribution mechanism. 840 One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. 841 This does not require support from the routers, bur PGM-aware routers 842 may act as helpers delivering missing data. 844 A.2. Multicast Group Security 846 Multicast Security Working Group has been working on methods how the 847 integrity, confidentiality, and authentication of data sent to 848 multicast groups can be ensured using cryptographic techniques 850 [RFC3740]. 852 Author's Address 854 Pekka Savola 855 CSC - Scientific Computing Ltd. 856 Espoo 857 Finland 859 Email: psavola@funet.fi 861 Full Copyright Statement 863 Copyright (C) The Internet Society (2005). 865 This document is subject to the rights, licenses and restrictions 866 contained in BCP 78, and except as set forth therein, the authors 867 retain all their rights. 869 This document and the information contained herein are provided on an 870 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 871 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 872 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 873 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 874 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 875 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 877 Intellectual Property 879 The IETF takes no position regarding the validity or scope of any 880 Intellectual Property Rights or other rights that might be claimed to 881 pertain to the implementation or use of the technology described in 882 this document or the extent to which any license under such rights 883 might or might not be available; nor does it represent that it has 884 made any independent effort to identify any such rights. Information 885 on the procedures with respect to rights in RFC documents can be 886 found in BCP 78 and BCP 79. 888 Copies of IPR disclosures made to the IETF Secretariat and any 889 assurances of licenses to be made available, or the result of an 890 attempt made to obtain a general license or permission for the use of 891 such proprietary rights by implementers or users of this 892 specification can be obtained from the IETF on-line IPR repository at 893 http://www.ietf.org/ipr. 895 The IETF invites any interested party to bring to its attention any 896 copyrights, patents or patent applications, or other proprietary 897 rights that may cover technology that may be required to implement 898 this standard. Please address the information to the IETF at 899 ietf-ipr@ietf.org. 901 Acknowledgment 903 Funding for the RFC Editor function is currently provided by the 904 Internet Society.