idnits 2.17.1 draft-ietf-mboned-routingarch-00.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 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 867. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 880. ** 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 == Line 373 has weird spacing: '... domain for t...' -- 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 (April 25, 2005) is 6933 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 709, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-magma-mrdisc' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'I-D.savola-pim-lasthop-threats' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'I-D.tsenevir-pim-sm-snoop' is defined on line 767, 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-09 == 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 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-06 ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Downref: Normative reference to an Experimental RFC: RFC 3618 == Outdated reference: A later version (-07) exists of draft-ietf-magma-mrdisc-05 == Outdated reference: A later version (-07) exists of draft-ietf-pim-anycast-rp-03 == 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 == Outdated reference: A later version (-03) exists of draft-serbest-l2vpn-vpls-mcast-02 Summary: 8 errors (**), 0 flaws (~~), 17 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: April 25, 2005 5 3913,2189,2201,1584,1585 (if 6 approved) 7 Expires: October 27, 2005 9 Overview of the Internet Multicast Routing Architecture 10 draft-ietf-mboned-routingarch-00.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 October 27, 2005. 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 91 A. Multicast Payload Transport Extensions . . . . . . . . . . . . 18 92 A.1 Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18 93 A.2 Multicast Group Security . . . . . . . . . . . . . . . . . 18 94 Intellectual Property and Copyright Statements . . . . . . . . 20 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, it cannot be applied in Inter-domain multicast or 212 for Embedded-RP. XXX: explain why not, someone send text? (one 213 paragraph please!). 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. XXX: does 299 the use of RPF need to be expanded? 301 This subsection introduces these protocols. 303 2.2.1 Multi-protocol BGP 305 Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as 306 "MBGP"; however, it is worth noting that "MBGP" does *not* stand for 307 "Multicast BGP") specifies a mechanism by which BGP can be used to 308 distribute different reachability information for unicast and 309 multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP 310 has been widely deployed for years, and is also needed to route IPv6. 312 These extensions are in widespread use wherever BGP is used to 313 distribute unicast topology information. Those having multicast 314 infrastructure and using BGP should use Multiprotocol BGP to 315 distribute multicast reachability information explicitly even if the 316 topologies are congruent (using SAFI=3). A number of significant 317 multicast transit providers even require this, by doing the RPF 318 lookups solely based on explicitly advertised multicast address 319 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 Internetis a completely unscalable model 374 for many reasons (XXX: a reference would be nice). Therefore it is 375 required to be able to split up the multicast routing infrastructures 376 to smaller domains, and there must be a way to share information 377 about active sources using some mechanism if the ASM model is to be 378 supported. 380 This section discusses the options. 382 2.3.1 SSM 384 Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also 385 referred to as "single-source Multicast") does not count on learning 386 active sources in the network; it is assumed that the recipients know 387 these using out of band mechanisms, and when subscribing to an (S,G) 388 channel indicate toward which source(s) the multicast routing 389 protocol should send the Join messages. 391 As of this writing, there are attempts to analyze and/or define out- 392 of-band source discovery functions which would help SSM in particular 393 [I-D.lehtonen-mboned-dynssm-req]. 395 2.3.2 MSDP 397 Multicast Source Discovery Mechanism [RFC3618] was invented as a 398 stop-gap mechanism, when it became apparent that multiple PIM-SM 399 domains (and RPs) were needed in the network, and information about 400 the active sources needed to be propagated between the PIM-SM domains 401 using some other protocol. 403 MSDP is also used to share the state about sources between multiple 404 RPs in a single domain for, e.g., redundancy purposes [RFC3446]. 405 There is also work in progress to achieve the same using PIM 406 extensions [I-D.ietf-pim-anycast-rp]. See Section 2.5 for more. 408 There is no intent to define MSDP for IPv6, but instead use only SSM 409 and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. 411 2.3.3 Embedded-RP 413 Embedded-RP [RFC3956] is an IPv6-only technique to map the address of 414 the RP to the multicast group address. Using this method, it is 415 possible to avoid the use of MSDP while still allowing multiple 416 multicast domains (in the traditional sense). 418 The model works by defining a single RP for a particular group for 419 all of the Internet, so there is no need to share state about that 420 with any other RPs (except, possibly, for redundancy purposes with 421 Anycast-RP using PIM). 423 2.4 Configuring and Distributing PIM-SM RP Information 425 For PIM-SM, configuration mechanisms exist which are used to 426 configure the RP addresses and which groups are to use those RPs in 427 the routers. This section outlines the approaches. 429 2.4.1 Manual Configuration with an Anycast Address 431 It is often easiest just to manually configure the RP information on 432 the routers when PIM-SM is used. 434 Originally, static RP mapping was considered suboptimal since it 435 required explicit configuration chages every time the RP address 436 changed. However, with the advent of anycast RP addressing, the RP 437 address is unlikely to ever change. Therefore, the administrative 438 burden is generally limited to initial configuration. Since there is 439 usually a fair amount of multicast configuration required on all 440 routers anyway (eg, PIM on all interfaces), adding the RP address 441 statically isn't really an issue. Further, static anycast RP mapping 442 provides the benefits of RP load balancing and redundancy (see 443 Section 2.5) without the complexity found in dynamic mechanisms like 444 Auto-RP and Bootstrap Router (BSR). 446 With such design, an anycast RP uses a "portable" address, which is 447 configured on a loopback interfaces of the routers currently acting 448 as RPs, as described in [RFC3446]. 450 Using this technique, each router might only need to be configured 451 with one, portable RP address. 453 2.4.2 Embedded-RP 455 Embedded-RP provides the information about the RP's address in the 456 group addresses which are delegated to those who use the RP, so 457 unless no other ASM than Embedded-RP is used, one only needs to 458 configure the RP routers themselves. 460 While Embedded-RP in many cases is sufficient for IPv6, other methods 461 of RP configuration are needed if one needs to provide ASM service 462 for other than Embedded-RP group addresses. In particular, service 463 discovery type of applications may need hard-coded addresses that are 464 not dependent on local RP addresses. 466 As the RP's address is exposed to the users and applications, it is 467 very important to ensure it does not change often, e.g., by using 468 manual configuration of an anycast address. 470 2.4.3 BSR and Auto-RP 472 BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP 473 address for groups. It may no longer be in as wide use with IPv4 as 474 it was ealier, and for IPv6, Embedded-RP will in many cases be 475 sufficient. 477 Cisco's Auto-RP is an older, proprietary method for distributing 478 group to RP mappings, similar to BSR. Auto-RP has little use today. 480 Both Auto-RP and BSR require some form of control at the routers to 481 ensure that only valid routers are able to advertise themselves as 482 RPs. Further, flooding of BSR and Auto-RP messages must be prevented 483 at PIM borders. Additionally, routers require monitoring that they 484 are actually using the RP(s) the administrators think they should be 485 using, for example if a router (maybe in customer's control) is 486 advertising itself inappropriately. All in all, while BSR and 487 Auto-RP provide easy configuration, they also provide very 488 significant configuration and management complexity. 490 It is worth noting that both Auto-RP and BSR were deployed before the 491 use of a manually configured anycast-RP address became relatively 492 commonplace, and there is actually relatively little use for them 493 today. 495 2.5 Mechanisms for Enhanced Redundancy 497 A couple of mechanisms, already described in this document, have been 498 used as a means to enhance redundancy, resilience against failures, 499 and to recover from failures quickly. This section summarizes these 500 techniques explicitly. 502 2.5.1 Anycast RP 504 As mentioned in Section 2.3.2, MSDP is also used to share the state 505 about sources between multiple RPs in a single domain for, e.g., 506 redundancy purposes [RFC3446]. The purpose of MSDP in this context 507 is to share the same state information on multiple RPs for the same 508 groups to enhance the robustness of the service. 510 There is also work in progress to achieve the same using PIM 511 extensions [I-D.ietf-pim-anycast-rp]. This is a required method to 512 be able to use Anycast RP with IPv6. 514 2.5.2 Stateless RP Failover 516 It is also possible to use some mechanisms for smaller amount of 517 redundancy as Anycast RP, without sharing state between the RPs. A 518 traditional mechanism has been to use Auto-RP or BSR (see 519 Section 2.4.3) to select another RP when the active one failed. 520 However, the same functionality could be achieved using a shared- 521 unicast RP address ("anycast RP without state sharing") without the 522 complexity of a dynamic mechanism. Further, Anycast RP offers a 523 significantly more extensive failure mitigation strategy, so today 524 there is actually very little need to use stateless failover 525 mechanisms, especially dynamic ones, for redundancy purposes. 527 2.5.3 Bi-directional PIM 529 Bi-directional PIM (see Section 2.1.3) was designed with faster 530 multicast convergence in mind, and if fast failover is required, it 531 may seem like an attractive solution. 533 XXX: someone want to send a bit more text about the convergence 534 differences wrt PIM-SM? 536 2.6 Interactions with Hosts 538 Previous sections have dealt with the components required by routers 539 to be able to do multicast routing. Obviously, the real users of 540 multicast are the hosts: either sending or receiving multicast. This 541 section describes the required interactions with hosts. 543 2.6.1 Hosts Sending Multicast 545 Hosts don't need to do any signalling prior to sending multicast to a 546 group; they just send the packets to the link-layer multicast 547 address, and the designated router will receive all the multicast 548 packets and start forwarding them as appropriate. 550 2.6.2 Hosts Receiving Multicast 552 Hosts signal their interest in receiving a multicast group or channel 553 by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are 554 also commonplace, but most new deployments support the latest 555 specifications. 557 2.7 Restricting Multicast Flooding in the Link Layer 559 Multicast transmission in the link layer, for example Ethernet, 560 typically includes some form of flooding the packets through a LAN. 561 This causes unnecessary bandwidth usage and discarding unwanted 562 frames on those nodes which did not want to receive the multicast 563 transmission. 565 Therefore a number of techniques have been developed, to be used in 566 Ethernet switches between routers, or between routers and hosts, to 567 limit the flooding. 569 These options are discussed in this section. 571 2.7.1 Router-to-Router Flooding Reduction 573 A proprietary solution, Cisco's RGMP [RFC3488] has been developed to 574 reduce the amount of router-to-router flooding on a LAN. This is 575 typically only considered a problem in some Ethernet-based Internet 576 Exchange points. 578 There have been proposals to snoop PIM messages [I-D.tsenevir-pim-sm- 579 snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve the same effect. 581 2.7.2 Host/Router Flooding Reduction 583 There are a number of techniques to help reduce flooding both from a 584 router to hosts, and from a host to the routers (and other hosts). 586 Cisco's proprietary CGMP [CGMP] provides a solution where the routers 587 notify the switches, but also allows the switches to snoop IGMP 588 packets to enable faster notification of hosts no longer wishing to 589 receive a group. IPv6 is not supported. 591 IEEE specifications mention Group Address Resolution Protocol (GARP) 592 [GARP] as a link-layer method to perform the same functionality. The 593 implementation status is unknown. 595 IGMP snooping [I-D.ietf-magma-snoop] appears to be the most widely 596 implemented technique. IGMP snooping requires that the switches 597 implement a significant amount of IP-level packet inspection; this 598 appears to be something that is difficult to get right, and often the 599 upgrades are also a challenge. To allow the snooping switches to 600 identify at which ports the routers reside (and therefore where to 601 flood the packets) instead of requiring manual configuration, 602 Multicast Router Discovery protocol is being specified [I-D.ietf- 603 magma-mrdisc]. IGMP proxying [I-D.ietf-magma-igmp-proxy] is 604 sometimes used either as a replacement of a multicast routing 605 protocol on a small router, or to aggregate IGMP/MLD reports when 606 used with IGMP snooping. 608 3. Acknowledgements 610 Tutoring a couple multicast-related papers, the latest by Kaarle 611 Ritvanen [RITVANEN] convinced the author that the up-to-date 612 multicast routing and address assignment/allocation documentation is 613 necessary. 615 Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, 616 Stig Venaas, and Tom Pusateri provided good comments, helping in 617 improving this document. 619 4. IANA Considerations 621 This memo includes no request to IANA. 623 5. Security Considerations 625 This memo only describes different approaches to multicast routing, 626 and this has no security considerations; the security analysis of the 627 mentioned protocols is out of scope of this memo. 629 However, there has been analysis of the security of multicast routing 630 infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD [I-D.daley- 631 magma-smld-prob], and PIM last-hop issues [I-D.savola-pim-lasthop- 632 threats]. 634 6. References 636 6.1 Normative References 638 [I-D.ietf-idmr-dvmrp-v3] 639 Pusateri, T., "Distance Vector Multicast Routing 640 Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), 641 December 2003. 643 [I-D.ietf-idmr-dvmrp-v3-as] 644 Pusateri, T., "Distance Vector Multicast Routing Protocol 645 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 646 (work in progress), May 2004. 648 [I-D.ietf-isis-wg-multi-topology] 649 Przygienda, T., "M-ISIS: Multi Topology (MT)Routing in 650 IS-IS", draft-ietf-isis-wg-multi-topology-09 (work in 651 progress), March 2005. 653 [I-D.ietf-ospf-mt] 654 Psenak, P., "Multi-Topology (MT) Routing in OSPF", 655 draft-ietf-ospf-mt-04 (work in progress), April 2005. 657 [I-D.ietf-pim-bidir] 658 Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 659 "Bi-directional Protocol Independent Multicast (BIDIR- 660 PIM)", draft-ietf-pim-bidir-07 (work in progress), 661 March 2005. 663 [I-D.ietf-pim-dm-new-v2] 664 Adams, A., Nicholas, J., and W. Siadak, "Protocol 665 Independent Multicast - Dense Mode (PIM-DM): Protocol 666 Specification (Revised)", draft-ietf-pim-dm-new-v2-05 667 (work in progress), June 2004. 669 [I-D.ietf-pim-sm-v2-new] 670 Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 671 "Protocol Independent Multicast - Sparse Mode PIM-SM): 672 Protocol Specification (Revised)", 673 draft-ietf-pim-sm-v2-new-11 (work in progress), 674 October 2004. 676 [I-D.ietf-ssm-arch] 677 Holbrook, H. and B. Cain, "Source-Specific Multicast for 678 IP", draft-ietf-ssm-arch-06 (work in progress), 679 September 2004. 681 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 682 3", BCP 9, RFC 2026, October 1996. 684 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 685 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 687 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 688 Thyagarajan, "Internet Group Management Protocol, Version 689 3", RFC 3376, October 2002. 691 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 692 Protocol (MSDP)", RFC 3618, October 2003. 694 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 695 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 697 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 698 Point (RP) Address in an IPv6 Multicast Address", 699 RFC 3956, November 2004. 701 6.2 Informative References 703 [CGMP] "Cisco Group Management Protocol", 704 . 706 [GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study 707 of IEEE 802.1p GARP/GMRP Timer Values", 1997. 709 [I-D.daley-magma-smld-prob] 710 Daley, G. and G. Kurup, "Trust Models and Security in 711 Multicast Listener Discovery", 712 draft-daley-magma-smld-prob-00 (work in progress), 713 July 2004. 715 [I-D.ietf-magma-igmp-proxy] 716 Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ 717 MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", 718 draft-ietf-magma-igmp-proxy-06 (work in progress), 719 April 2004. 721 [I-D.ietf-magma-mrdisc] 722 Haberman, B. and J. Martin, "Multicast Router Discovery", 723 draft-ietf-magma-mrdisc-05 (work in progress), April 2005. 725 [I-D.ietf-magma-snoop] 726 Christensen, M., Kimball, K., and F. Solensky, 727 "Considerations for IGMP and MLD Snooping Switches", 728 draft-ietf-magma-snoop-12 (work in progress), 729 February 2005. 731 [I-D.ietf-mboned-ipv6-multicast-issues] 732 Savola, P., "IPv6 Multicast Deployment Issues", 733 draft-ietf-mboned-ipv6-multicast-issues-02 (work in 734 progress), February 2005. 736 [I-D.ietf-mboned-mroutesec] 737 Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast 738 Routing Security Issues and Enhancements", 739 draft-ietf-mboned-mroutesec-04 (work in progress), 740 October 2004. 742 [I-D.ietf-pim-anycast-rp] 743 Farinacci, D., "Anycast-RP using PIM", 744 draft-ietf-pim-anycast-rp-03 (work in progress), 745 April 2005. 747 [I-D.ietf-pim-sm-bsr] 748 Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", 749 draft-ietf-pim-sm-bsr-05 (work in progress), 750 February 2005. 752 [I-D.lehtonen-mboned-dynssm-req] 753 Lehtonen, R., "Requirements for discovery of dynamic SSM 754 sources", draft-lehtonen-mboned-dynssm-req-00 (work in 755 progress), February 2005. 757 [I-D.savola-pim-lasthop-threats] 758 Savola, P., "Last-hop Threats to Protocol Independent 759 Multicast (PIM)", draft-savola-pim-lasthop-threats-01 760 (work in progress), January 2005. 762 [I-D.serbest-l2vpn-vpls-mcast] 763 Serbest, Y., "Supporting IP Multicast over VPLS", 764 draft-serbest-l2vpn-vpls-mcast-02 (work in progress), 765 February 2005. 767 [I-D.tsenevir-pim-sm-snoop] 768 Senevirathne, T. and S. Vallepali, "Protocol Independent 769 Multicast-Sparse Mode (PIM-SM) Snooping", 770 draft-tsenevir-pim-sm-snoop-00 (work in progress), 771 April 2002. 773 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 774 Vector Multicast Routing Protocol", RFC 1075, 775 November 1988. 777 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 778 March 1994. 780 [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, 781 March 1994. 783 [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 784 Routing -- Protocol Specification --", RFC 2189, 785 September 1997. 787 [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing 788 Architecture", RFC 2201, September 1997. 790 [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing 791 Protocols", RFC 2715, October 1999. 793 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 794 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 795 March 2000. 797 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 798 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 799 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 800 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 801 Protocol Specification", RFC 3208, December 2001. 803 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 804 Rendevous Point (RP) mechanism using Protocol Independent 805 Multicast (PIM) and Multicast Source Discovery Protocol 806 (MSDP)", RFC 3446, January 2003. 808 [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group 809 Management Protocol (RGMP)", RFC 3488, February 2003. 811 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 812 Architecture", RFC 3740, March 2004. 814 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 815 Protocol Specification", RFC 3913, September 2004. 817 [RITVANEN] 818 Ritvanen, K., "Multicast Routing and Addressing", HUT 819 Report, Seminar on Internetworking, May 2004, 820 . 822 Author's Address 824 Pekka Savola 825 CSC - Scientific Computing Ltd. 826 Espoo 827 Finland 829 Email: psavola@funet.fi 831 Appendix A. Multicast Payload Transport Extensions 833 A couple of mechanisms have been, and are being specified, to improve 834 the characteristics of the data that can be transported over 835 multicast. 837 These go beyond the scope of multicast routing, but as reliable 838 multicast has some relevance, these are briefly mentioned. 840 A.1 Reliable Multicast 842 Reliable Multicast Working Group has been working on experimental 843 specifications so that applications requiring reliable delivery 844 characteristics, instead of simple unreliable UDP, could use 845 multicast as a distribution mechanism. 847 One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. 848 This does not require support from the routers, bur PGM-aware routers 849 may act as helpers delivering missing data. 851 A.2 Multicast Group Security 853 Multicast Security Working Group has been working on methods how the 854 integrity, confidentiality, and authentication of data sent to 855 multicast groups can be ensured using cryptographic techniques 856 [RFC3740]. 858 Intellectual Property Statement 860 The IETF takes no position regarding the validity or scope of any 861 Intellectual Property Rights or other rights that might be claimed to 862 pertain to the implementation or use of the technology described in 863 this document or the extent to which any license under such rights 864 might or might not be available; nor does it represent that it has 865 made any independent effort to identify any such rights. Information 866 on the procedures with respect to rights in RFC documents can be 867 found in BCP 78 and BCP 79. 869 Copies of IPR disclosures made to the IETF Secretariat and any 870 assurances of licenses to be made available, or the result of an 871 attempt made to obtain a general license or permission for the use of 872 such proprietary rights by implementers or users of this 873 specification can be obtained from the IETF on-line IPR repository at 874 http://www.ietf.org/ipr. 876 The IETF invites any interested party to bring to its attention any 877 copyrights, patents or patent applications, or other proprietary 878 rights that may cover technology that may be required to implement 879 this standard. Please address the information to the IETF at 880 ietf-ipr@ietf.org. 882 Disclaimer of Validity 884 This document and the information contained herein are provided on an 885 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 886 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 887 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 888 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 889 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 890 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 892 Copyright Statement 894 Copyright (C) The Internet Society (2005). This document is subject 895 to the rights, licenses and restrictions contained in BCP 78, and 896 except as set forth therein, the authors retain all their rights. 898 Acknowledgment 900 Funding for the RFC Editor function is currently provided by the 901 Internet Society.