idnits 2.17.1 draft-savola-mboned-routingarch-01.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 838. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 315 has weird spacing: '...opology expli...' == Line 348 has weird spacing: '...reasons for...' -- 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 (December 20, 2004) is 7064 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) ** 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-07 == Outdated reference: A later version (-09) exists of draft-ietf-ospf-mt-00 == 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-03 == Outdated reference: A later version (-06) exists of draft-ietf-magma-msnip-05 == Outdated reference: A later version (-12) exists of draft-ietf-magma-snoop-11 == Outdated reference: A later version (-02) exists of draft-ietf-mboned-ipv6-multicast-issues-01 == Outdated reference: A later version (-07) exists of draft-ietf-pim-anycast-rp-02 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-04 == Outdated reference: A later version (-03) exists of draft-serbest-l2vpn-vpls-mcast-01 Summary: 11 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: December 20, 2004 5 3913,2189,2201,1584,1585 (if 6 approved) 7 Expires: June 20, 2005 9 Overview of the Internet Multicast Routing Architecture 10 draft-savola-mboned-routingarch-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 20, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 The lack of up-to-date documentation on IP multicast routing 46 protocols and procedures has caused a great deal of confusion. To 47 clarify the situation, this memo describes the routing protocols and 48 techniques currently (as of this writing) in use. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Multicast-related Abbreviations . . . . . . . . . . . . . 4 54 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 Setting up Multicast Forwarding State . . . . . . . . . . 4 56 2.1.1 PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1.2 PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.3 Bidirectional PIM . . . . . . . . . . . . . . . . . . 5 59 2.1.4 DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1.5 Obsolete Protocols . . . . . . . . . . . . . . . . . . 6 61 2.1.6 Interactions and Summary . . . . . . . . . . . . . . . 6 62 2.2 Distributing Topology Information . . . . . . . . . . . . 6 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 . . . . 7 66 2.3 Learning (Active) Sources . . . . . . . . . . . . . . . . 8 67 2.3.1 SSM . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 2.3.2 MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.3.3 Embedded-RP . . . . . . . . . . . . . . . . . . . . . 9 70 2.4 Configuring and Distributing PIM-SM RP Information . . . . 9 71 2.4.1 Manual Configuration with an Anycast Address . . . . . 9 72 2.4.2 Embedded-RP . . . . . . . . . . . . . . . . . . . . . 10 73 2.4.3 BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 10 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 Bidirectional PIM . . . . . . . . . . . . . . . . . . 11 78 2.6 Interactions with Hosts . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . 12 83 2.7.2 Host/Router Flooding Reduction . . . . . . . . . . . . 13 84 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 89 6.2 Informative References . . . . . . . . . . . . . . . . . . . 15 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 91 A. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 A.1 Multicast Payload Transport Extensions . . . . . . . . . . 17 93 A.1.1 Reliable Multicast . . . . . . . . . . . . . . . . . . 17 94 A.1.2 Multicast Group Security . . . . . . . . . . . . . . . 18 95 Intellectual Property and Copyright Statements . . . . . . . . 19 97 1. Introduction 99 Good, up-to-date documentation of IP multicast is close to 100 non-existent. This issue severely felt with multicast routing 101 protocols and techniques. The consequence is that those who wish to 102 learn of IP multicast and how the routing works in the real world do 103 not know where to begin. 105 The aim of this document is to provide a brief overview of multicast 106 routing protocols and techniques. 108 This memo deals with: 110 o setting up multicast forwarding state (Section 2.1), 112 o distributing multicast topology information (Section 2.2), 114 o learning active sources (Section 2.3), 116 o configuring and distributing the PIM-SM RP information (Section 117 2.4), 119 o mechanisms for enhanced redundancy (Section 2.5), 121 o interacting with hosts (Section 2.6), and 123 o restricting the multicast flooding in the link layer (Section 124 2.7). 126 Multicast data delivery issues are also introduced in Appendix A.1. 128 This memo obsoletes and re-classifies to Historic Border Gateway 129 Multicast Protocol (BGMP), Core-based Trees (CBT), Multicast OSPF 130 (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and 131 [RFC1585]. 133 1.1 Multicast-related Abbreviations 135 ASM Any Source Multicast 136 BGMP Border Gateway Multicast Protocol (obsolete) 137 BSR Bootstrap Router 138 CBT Core-based Trees (obsolete) 139 CGMP Cisco Group Management Protocol 140 DR Designated Router 141 DVMRP Distance Vector Multicast Routing Protocol 142 GARP Group Address Resolution Protocol 143 IGMP Internet Group Management Protocol 144 MLD Multicast Listener Discovery 145 MSNIP Multicast Source Notification of Interest Protocol 146 MOSPF Multicast OSPF (obsolete) 147 MBGP Multi-protocol BGP (*not* "Multicast BGP") 148 MSDP Multicast Source Discovery Protocol 149 PGM Pragmatic General Multicast 150 PIM Protocol Independent Multicast 151 PIM-DM Protocol Independent Multicast - Dense Mode 152 PIM-SM Protocol Independent Multicast - Sparse Mode 153 PIM-SSM Protocol Independent Multicast - (Source-specific) Sparse Mode 154 RGMP (Cisco's) Router Group Management Protocol 155 RP Rendezvous Point 156 SSM Source-specific Multicast 158 2. Multicast Routing 160 2.1 Setting up Multicast Forwarding State 162 The most important part of multicast routing is setting up the 163 multicast forwarding state. This section describes the protocols 164 commonly used for this purpose. 166 2.1.1 PIM-SM 168 By far, the most common multicast routing protocol is PIM-SM 169 [I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any 170 Source Multicast (ASM) and Source-Specific Multicast (SSM) 171 functionality; PIM-SSM is a subset of PIM-SM. Most current routing 172 platforms support PIM-SM. 174 2.1.2 PIM-DM 176 Whereas PIM-SM is designed to avoid unnecessary flooding of multicast 177 data, PIM-DM [I-D.ietf-pim-dm-new-v2] operates in a "dense" mode, 178 flooding the multicast transmissions throughout the network ("flood 179 and prune") unless the leaf parts of the network periodically 180 indicate that they are not interested in that particular traffic. 182 PIM-DM may be some fit in small and/or simple networks, where setting 183 up an RP would be unnecessary, and possibly in cases where a large 184 number of users is expected to be able to wish to receive the 185 transmission so that the amount of state the network has to keep is 186 minimal. Therefore PIM-DM has typically only been used in special 187 deployments, never currently in, e.g., ISPs' networks. 189 PIM-DM never really got popular due to its reliance of data plane and 190 potential for loops, and the over-reliance of the complex Assert 191 mechanism. Further, it was a non-starter with high-bandwidth 192 streams. 194 Many implementations also support so-called "sparse-dense" mode, 195 where Sparse mode is is used by default, but Dense is used for 196 configured multicast group ranges (such as Auto-RP in Section 2.4.3) 197 only. Lately, many networks have been transitioned away from 198 sparse-dense to only sparse mode. 200 2.1.3 Bidirectional PIM 202 Bidirectional-PIM [I-D.ietf-pim-bidir] aims to offer streamlined 203 PIM-SM operation, without data-driven events and data-encapsulation, 204 inside a PIM-SM domain. The usage of bidir-PIM may be on the 205 increase especially inside sites leveraging multicast. 207 As of this writing, it cannot be applied in Inter-domain multicast or 208 for Embedded-RP. XXX: explain why not, someone send text? (one 209 paragraph please!). 211 2.1.4 DVMRP 213 Distance Vector Multicast Routing Protocol (DVMRP) 214 [RFC1075][I-D.ietf-idmr-dvmrp-v3][I-D.ietf-idmr-dvmrp-v3-as] is the 215 first protocol designed for multicasting, and to get around initial 216 deployment hurdles, it also included the tunneling capabilities which 217 were part of its multicast topology functions. 219 Nowadays, DVMRP is used only very rarely in operator networks, having 220 been replaced with PIM-SM. The most typical deployment of DVMRP is 221 at a leaf network, to run from a legacy firewall only supporting 222 DVMRP to the internal network. However, GRE tunneling [RFC2784] 223 seems to have overtaken DVMRP in this functionality, and there is 224 relatively little use for DVMRP except in legacy deployments. 226 2.1.5 Obsolete Protocols 228 Three protocols which are considered completely obsolete are MOSPF 229 [RFC1584] (which was implemented and deployed at a time, but PIM 230 later replaced it), BGMP [RFC3913] (which did not get sufficient 231 support to get adopted and moved forward), and CBT [RFC2201] (which 232 was never significantly deployed, losing to PIM in the standards 233 process). 235 2.1.6 Interactions and Summary 237 It is worth noting that is it is possible to run different protocols 238 with different groups ranges (e.g., treat some groups as dense mode 239 in an other-wise PIM-SM network; this typically requires manual 240 configuration of the groups) or interact between different protocols 241 (e.g., use DVMRP in the leaf network, but PIM-SM upstream). The 242 basics for interactions among different protocols have been outlined 243 in [RFC2715]. 245 The following figure gives a concise summary of the different 246 protocols as of this writing. 248 +-------------+-------------+------------+ 249 | Interdomain | Intradomain | Status | 250 +------------------+-------------+-------------+------------+ 251 | PIM-SM | Yes | Yes | De facto | 252 | PIM-DM | Not feasible| Yes | Little use | 253 | Bidir-PIM | No | Yes | Wait & see | 254 | DVMRP | Not anymore | Yes (stub) | Going out | 255 | CBT, MOSPF, BGMP | No | No | Obsolete | 256 +------------------+-------------+-------------+------------+ 258 2.2 Distributing Topology Information 260 When unicast and multicast topologies are the same ("congruent"), 261 i.e., use the same routing tables (routing information base, RIB), it 262 has been considered sufficient to just distribute one set of 263 reachability information. 265 However, when PIM -- which by default built multicast topology based 266 on the unicast topology -- gained popularity, it became apparent that 267 it would be necessary to be able to distribute also non-congruent 268 multicast reachability information in the regular unicast protocols. 270 The topology information is needed to perform efficient distribution 271 of multicast transmissions and to prevent transmission loops by 272 applying it to Reverse Path Forwarding (RPF) check. XXX: does the 273 use of RPF need to be expanded? 275 This subsection introduces these protocols. 277 2.2.1 Multi-protocol BGP 279 Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as 280 "MBGP"; however, it is worth noting that "MBGP" does *not* stand for 281 "Multicast BGP") specifies a mechanism how BGP can be used to 282 distribute different reachability information for unicast and 283 multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP 284 has been widely deployed for years, and is also neded for routing for 285 example IPv6. 287 These extensions are in widespread use wherever BGP is used to 288 distribute unicast topology information. Those having multicast 289 infrastructure and using BGP should use Multiprotocol BGP to also 290 distribute multicast reachability information explicitly even if the 291 topologies are congruent (using SAFI=3). A number of significant 292 multicast transit providers even require this, by doing the RPF 293 lookups solely based on explicitly advertised multicast address 294 family. 296 2.2.2 OSPF/IS-IS Multi-topology Extensions 298 Similar to BGP, some IGPs also provide the capability for signalling 299 a differing multicast topology, for example IS-IS multi-topology 300 extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists 301 for OSPF [I-D.ietf-ospf-mt]. 303 It is worth noting that interdomain incongruence and intradomain 304 incongruence are orthogonal, so one doesn't require the other. 305 Specifically, interdomain incongruence is quite common, while 306 intradomain incongruence isn't, so you see much more deployments of 307 MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well 308 without protocols handling intradomain incongruence. However, the 309 availability of multi-topology mechanisms may in part replace the 310 typically used workarounds such as tunnels. 312 2.2.3 Issue: Overlapping Unicast/multicast Topology 314 An interesting case occurs when some do not distribute multicast 315 topology explicitly while some do. In particular, this happens when 316 some multicast sites in the Internet are using plain BGP while some 317 use MBGP. 319 Different implementations deal with this using different means. 320 Sometimes, multicast RPF mechanisms first look up the multicast 321 routing table, or RIB ("topology database") with longest prefix match 322 algorithm, and if they find any entry (including a default route), 323 that is used; if no match is found, unicast routing table is looked 324 instead. 326 An alternative approach is to use longest prefix match on the union 327 of multicast and unicast routing tables; an implementation technique 328 here is to copy the whole unicast routing table over to the multicast 329 routing table. The important point to remember here, though, is to 330 not override the multicast-only routes; if the longest prefix match 331 would find both a (copied) unicast route and a multicast-only route, 332 the latter should be treated as preferable. 334 One implemented approach is to just look up the information in the 335 unicast routing table, and provide the user capabilities to change 336 that as appropriate, using for example copying functions discussed 337 above. 339 2.3 Learning (Active) Sources 341 Typically, multicast routing protocols must either assume that the 342 receivers know the IP addresses of the (active) sources for a group a 343 priori, possibly using a rendezvous mechanism (SSM), or the sources 344 must be discovered by the network protocols automatically (ASM). 346 Learning active sources is a relatively straightforward process with 347 a single PIM-SM domain and with a single RP, but having a single 348 PIM-SM domain is a completely unscalable model for many reasons for 349 the whole Internet. Therefore it is required to be able to split up 350 the multicast routing infrastructures to smaller domains, and there 351 must be a way to share information about active sources using some 352 mechanism, if ASM model is to be supported. 354 This section discusses the options. 356 2.3.1 SSM 358 Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also 359 referred to as "single-source Multicast") does not count on learning 360 active sources in the network; it is assumed that the recipients know 361 these using out of band mechanisms, and when subscribing to a (S,G) 362 channel, indicate toward which source(s) the multicast routing 363 protocol should send the Join messages. 365 As of this writing, there are attempts to analyze and/or define 366 out-of-band source discovery functions which would help SSM in 367 particular. 369 2.3.2 MSDP 371 Multicast Source Discovery Mechanism [RFC3618] was invented as a 372 stop-gap mechanism, when it became apparent that multiple PIM-SM 373 domains (and RPs) were needed in the network, and information about 374 the active sources needed to be propagated between the PIM-SM domains 375 using some other protocol. 377 MSDP is also used to share the state about sources between multiple 378 RPs in a single domain for, e.g., redundancy purposes [RFC3446]. 379 There is also work in progress to achieve the same using PIM 380 extensions [I-D.ietf-pim-anycast-rp]. See Section 2.5 for more. 382 There is no intent to define MSDP for IPv6, but instead use only SSM 383 and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. 385 2.3.3 Embedded-RP 387 Embedded-RP [RFC3956] is an IPv6-only technique to map the address of 388 the RP to the multicast group address. Using this method, it is 389 possible to avoid the use of MSDP while still allowing multiple 390 multicast domains (in the traditional sense). The model works by 391 defining a single RP for a particular group for all of the Internet, 392 so there is no need to share state about that with any other RPs 393 (except, possibly, for redundancy purposes with Anycast-RP using 394 PIM). 396 2.4 Configuring and Distributing PIM-SM RP Information 398 For PIM-SM, there exist configuration mechanisms which are used to 399 configure the RP addresses and which groups are to use those RPs in 400 the routers. This section outlines the approaches. 402 2.4.1 Manual Configuration with an Anycast Address 404 It is often the easiest to just manually configure the RP information 405 on the routers when PIM-SM is used. 407 Originally, static RP mapping was considered suboptimal since it 408 required explicit configuration chages every time the RP address 409 changed. However, with the advent of anycast RP addressing, the RP 410 address is unlikely to ever change. Therefore, the administrative 411 burden is generally limited to initial configuration. Since there is 412 usually a fair amount of multicast configuration required on all 413 routers anyway (eg, PIM on all interfaces), adding the RP address 414 statically isn't really an issue. Further, static anycast RP mapping 415 provides the benefits of RP load balancing and redundancy (see 416 Section 2.5) without the complexity found in dynamic mechanisms like 417 Auto-RP and Bootstrap Router (BSR). 419 With such design, an anycast RP uses a "portable" address, which is 420 configured on a loopback interfaces of the routers currently acting 421 as RPs, as described in [RFC3446]. 423 Using this technique, each router might only need to be configured 424 with one, portable RP address. 426 2.4.2 Embedded-RP 428 Embedded-RP provides the information about the RP's address in the 429 group addresses which are delegated to those who use the RP, so 430 unless no other ASM than Embedded-RP is used, one only needs to 431 configure the RP routers themselves. 433 While Embedded-RP in many cases is sufficient for IPv6, other methods 434 of RP configuration are needed if one needs to provide ASM service 435 for other than Embedded-RP group addresses. In particular, service 436 discovery type of applications may need hard-coded addresses that are 437 not dependent on local RP addresses. 439 As the RP's address is exposed to the users and applications, it is 440 very important to ensure it does not change often, e.g., by using 441 manual configuration of an anycast address. 443 2.4.3 BSR and Auto-RP 445 BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP 446 address for groups. It may no longer be in as wide use with IPv4 it 447 was ealier, and for IPv6, Embedded-RP will in many cases be 448 sufficient. 450 Cisco's Auto-RP is an older, proprietary method for distributing 451 group to RP mappings, similar to BSR. Auto-RP has little use today. 453 Both Auto-RP and BSR require some form of control at the routers to 454 ensure that only valid routers are able to advertise themselves as 455 RPs. Further, flooding of BSR and Auto-RP messages must be prevented 456 at PIM borders. Additionally, routers require monitoring that they 457 are actually using the RP(s) the administrators think they should be 458 using, for example if a router (maybe in customer's control) is 459 advertising itself inappropriately. All in all, while BSR and 460 Auto-RP provide easy configuration, they also provide very 461 significant configuration and management complexity. 463 It is worth noting that both Auto-RP and BSR were deployed before the 464 use of a manually configured anycast-RP address became relatively 465 commonplace, and there is actually relatively little use for them 466 today. 468 2.5 Mechanisms for Enhanced Redundancy 470 A couple of mechanisms, already described in this document, have been 471 used as a means to enhance redundancy, resilience against failures, 472 and to recover from failures quickly. This section summarizes these 473 techniques explicitly. 475 2.5.1 Anycast RP 477 As mentioned in Section 2.3.2, MSDP is also used to share the state 478 about sources between multiple RPs in a single domain for, e.g., 479 redundancy purposes [RFC3446]. The purpose of MSDP in this context 480 is to share the same state information on multiple RPs for the same 481 groups to enhance the robustness of the service. 483 There is also work in progress to achieve the same using PIM 484 extensions [I-D.ietf-pim-anycast-rp]. This is a required method to 485 be able to use Anycast RP with IPv6. 487 2.5.2 Stateless RP Failover 489 It is also possible to use some mechanisms for smaller amount of 490 redundancy as Anycast RP, without sharing state between the RPs. A 491 traditional mechanism has been to use Auto-RP or BSR (see Section 492 2.4.3) to select another RP when the active one failed. However, the 493 same functionality could be achieved using a shared-unicast RP 494 address ("anycast RP without state sharing") without the complexity 495 of a dynamic mechanism. Further, Anycast RP offers a significantly 496 more extensive failure mitigation strategy, so today there is 497 actually very little need to use stateless failover mechanisms, 498 especially dynamic ones, for redundancy purposes. 500 2.5.3 Bidirectional PIM 502 Bidirectional PIM (see Section 2.1.3) was designed with faster 503 multicast convergence in mind, and if fast failover is required, it 504 may seem like an attractive solution. 506 XXX: someone want to send a bit more text about the convergence 507 differences wrt PIM-SM? 509 2.6 Interactions with Hosts 511 Previous sections have dealt with the components required by routers 512 to be able to do multicast routing. Obviously, the the real users of 513 multicast are the hosts: either sending or receiving multicast. 515 This section describes the required interactions with hosts. 517 2.6.1 Hosts Sending Multicast 519 Hosts don't need to do any signalling prior to sending multicast to a 520 group; they just send to the link-layer multicast address, and the 521 designated router will listen to the multicast packets and start 522 forwarding them as appropriate. 524 There is a proposal, Multicast Source Notification of Interest 525 Protocol (MSNIP) [I-D.ietf-magma-msnip] which could be used for both 526 the sending hosts to register as having interest in sending if there 527 would be receivers, and for the receivers (or routers) to signal 528 their interest in receiving the multicast transmission. XXX: to be 529 removed if MSNIP is not finalized before this goes forward. 531 2.6.2 Hosts Receiving Multicast 533 Hosts signal their interest in receiving a multicast group or channel 534 by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are 535 also commonplace, but most new deployments support the latest 536 specifications. 538 2.7 Restricting Multicast Flooding in the Link Layer 540 Multicast transmission in the link layer, for example Ethernet, 541 typically includes some form of flooding the packets through a LAN. 542 This causes unnecessary bandwidth usage and discarding unwanted 543 frames on those nodes which did not want to receive the multicast 544 transmission. 546 Therefore a number of techniques have been developed, to be used in 547 Ethernet switches between routers, or between routers and hosts, to 548 limit the flooding. 550 These options are discussed in this section. 552 2.7.1 Router-to-Router Flooding Reduction 554 Only a proprietary solution, Cisco's RGMP [RFC3488] is known to have 555 been developed to reduce the amount of router-to-router flooding on a 556 LAN. This is typically only considered a problem in some 557 Ethernet-based Internet Exchange points. 559 There have been similar proposals to snoop PIM messages 560 [I-D.tsenevir-pim-sm-snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve 561 the same effect. 563 2.7.2 Host/Router Flooding Reduction 565 There are a number of techniques to help reduce flooding both from a 566 router to hosts, and from a host to the routers (and other hosts). 568 Cisco's proprietary CGMP [CGMP] provides a solution where the routers 569 notify the switches, but also allows the switches to snoop IGMP 570 packets to enable faster notification of hosts no longer wishing to 571 receive a group. IPv6 is not supported. 573 IEEE specifications mention Group Address Resolution Protocol (GARP) 574 [GARP] as a link-layer method to perform the same functionality. Its 575 implementation status is unknown. 577 IGMP snooping [I-D.ietf-magma-snoop] appears to be the most widely 578 implemented technique, often used alongside with IGMP proxying 579 [I-D.ietf-magma-igmp-proxy]. IGMP snooping requires that the 580 switches implement a significant amount of IP-level packet 581 inspection; this appears to be something that is difficult to get 582 right, and often the upgrades are also a challenge. To allow the 583 snooping switches to identify at which ports the routers reside (and 584 therefore where to flood the packets) instead of requiring manual 585 configuration, Multicast Router Discovery protocol is being specified 586 [I-D.ietf-magma-mrdisc]. 588 3. Acknowledgements 590 Tutoring a couple multicast-related papers, the latest by Kaarle 591 Ritvanen [RITVANEN] convinced the author that the up-to-date 592 multicast routing and address assignment/allocation documentation is 593 necessary. 595 Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, 596 and Stig Venaas provided good comments, helping in improving this 597 document. 599 4. IANA Considerations 601 This memo includes no request to IANA. 603 5. Security Considerations 605 This memo only describes different approaches to multicast routing, 606 and this has no security considerations; the security analysis of the 607 mentioned protocols is out of scope of this memo. 609 6. References 611 6.1 Normative References 613 [I-D.ietf-idmr-dvmrp-v3] 614 Pusateri, T., "Distance Vector Multicast Routing 615 Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), 616 December 2003. 618 [I-D.ietf-idmr-dvmrp-v3-as] 619 Pusateri, T., "Distance Vector Multicast Routing Protocol 620 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 621 (work in progress), May 2004. 623 [I-D.ietf-isis-wg-multi-topology] 624 Przygienda, T., Shen, N. and N. Sheth, "M-ISIS: Multi 625 Topology (MT)Routing in IS-IS", 626 draft-ietf-isis-wg-multi-topology-07 (work in progress), 627 June 2004. 629 [I-D.ietf-ospf-mt] 630 Psenak, P., "MT-OSPF: Multi Topology (MT) Routing in 631 OSPF", draft-ietf-ospf-mt-00 (work in progress), October 632 2004. 634 [I-D.ietf-pim-bidir] 635 Handley, M., Kouvelas, I., Speakman, T. and L. Vicisano, 636 "Bi-directional Protocol Independent Multicast 637 (BIDIR-PIM)", draft-ietf-pim-bidir-07 (work in progress), 638 July 2004. 640 [I-D.ietf-pim-dm-new-v2] 641 Adams, A., Nicholas, J. and W. Siadak, "Protocol 642 Independent Multicast - Dense Mode (PIM-DM): Protocol 643 Specification (Revised)", draft-ietf-pim-dm-new-v2-05 644 (work in progress), June 2004. 646 [I-D.ietf-pim-sm-v2-new] 647 Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, 648 "Protocol Independent Multicast - Sparse Mode PIM-SM): 649 Protocol Specification (Revised)", 650 draft-ietf-pim-sm-v2-new-11 (work in progress), October 651 2004. 653 [I-D.ietf-ssm-arch] 654 Holbrook, H. and B. Cain, "Source-Specific Multicast for 655 IP", draft-ietf-ssm-arch-06 (work in progress), September 656 2004. 658 [RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 659 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 661 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 662 Thyagarajan, "Internet Group Management Protocol, Version 663 3", RFC 3376, October 2002. 665 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 666 Protocol (MSDP)", RFC 3618, October 2003. 668 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 669 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 671 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 672 Point (RP) Address in an IPv6 Multicast Address", RFC 673 3956, November 2004. 675 6.2 Informative References 677 [CGMP] "Cisco Group Management Protocol", 678 . 680 [GARP] Tobagi, F., Molinero-Fernandez, P. and M. Karam, "Study of 681 IEEE 802.1p GARP/GMRP Timer Values", 1997. 683 [I-D.ietf-magma-igmp-proxy] 684 Fenner, B., He, H., Haberman, B. and H. Sandick, 685 "IGMP/MLD-based Multicast Forwarding ('IGMP/MLD 686 Proxying')", draft-ietf-magma-igmp-proxy-06 (work in 687 progress), April 2004. 689 [I-D.ietf-magma-mrdisc] 690 Haberman, B. and J. Martin, "Multicast Router Discovery", 691 draft-ietf-magma-mrdisc-03 (work in progress), October 692 2004. 694 [I-D.ietf-magma-msnip] 695 Fenner, B., "Multicast Source Notification of Interest 696 Protocol (MSNIP)", draft-ietf-magma-msnip-05 (work in 697 progress), March 2004. 699 [I-D.ietf-magma-snoop] 700 Christensen, M., Kimball, K. and F. Solensky, 701 "Considerations for IGMP and MLD Snooping Switches", 702 draft-ietf-magma-snoop-11 (work in progress), May 2004. 704 [I-D.ietf-mboned-ipv6-multicast-issues] 705 Savola, P., "IPv6 Multicast Deployment Issues", 706 draft-ietf-mboned-ipv6-multicast-issues-01 (work in 707 progress), September 2004. 709 [I-D.ietf-pim-anycast-rp] 710 Farinacci, D., "Anycast-RP using PIM", 711 draft-ietf-pim-anycast-rp-02 (work in progress), June 712 2004. 714 [I-D.ietf-pim-sm-bsr] 715 Fenner, B., "Bootstrap Router (BSR) Mechanism for PIM", 716 draft-ietf-pim-sm-bsr-04 (work in progress), July 2004. 718 [I-D.serbest-l2vpn-vpls-mcast] 719 Serbest, Y., "Supporting IP Multicast over VPLS", 720 draft-serbest-l2vpn-vpls-mcast-01 (work in progress), 721 November 2004. 723 [I-D.tsenevir-pim-sm-snoop] 724 Senevirathne, T. and S. Vallepali, "Protocol Independent 725 Multicast-Sparse Mode (PIM-SM) Snooping", 726 draft-tsenevir-pim-sm-snoop-00 (work in progress), April 727 2002. 729 [RFC1075] Waitzman, D., Partridge, C. and S. Deering, "Distance 730 Vector Multicast Routing Protocol", RFC 1075, November 731 1988. 733 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 734 1994. 736 [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, March 737 1994. 739 [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 740 Routing -- Protocol Specification --", RFC 2189, September 741 1997. 743 [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing 744 Architecture", RFC 2201, September 1997. 746 [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing 747 Protocols", RFC 2715, October 1999. 749 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, 750 "Generic Routing Encapsulation (GRE)", RFC 2784, March 751 2000. 753 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 754 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 755 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 756 Sumanasekera, R. and L. Vicisano, "PGM Reliable Transport 757 Protocol Specification", RFC 3208, December 2001. 759 [RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci, "Anycast 760 Rendevous Point (RP) mechanism using Protocol Independent 761 Multicast (PIM) and Multicast Source Discovery Protocol 762 (MSDP)", RFC 3446, January 2003. 764 [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group 765 Management Protocol (RGMP)", RFC 3488, February 2003. 767 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 768 Architecture", RFC 3740, March 2004. 770 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 771 Protocol Specification", RFC 3913, September 2004. 773 [RITVANEN] 774 Ritvanen, K., "Multicast Routing and Addressing", HUT 775 Report, Seminar on Internetworking, May 2004, 776 . 778 Author's Address 780 Pekka Savola 781 CSC - Scientific Computing Ltd. 782 Espoo 783 Finland 785 EMail: psavola@funet.fi 787 Appendix A. Other Issues 789 A.1 Multicast Payload Transport Extensions 791 A couple of mechanisms have been, and are being specified, to improve 792 the characteristics of the data that can be transported over 793 multicast. 795 These go beyond the scope of multicast routing, but as reliable 796 multicast has some relevance, these are briefly mentioned. 798 A.1.1 Reliable Multicast 800 Reliable Multicast Working Group has been working on experimental 801 specifications so that applications requiring reliable delivery 802 characteristics, instead of simple unreliable UDP, could use 803 multicast as a distribution mechanism. 805 One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. 806 This does not require support from the routers, bur PGM-aware routers 807 may act as helpers delivering missing data. 809 A.1.2 Multicast Group Security 811 Multicast Security Working Group has been working on methods how the 812 integrity, confidentiality, and authentication of data sent to 813 multicast groups can be ensured using cryptographic techniques 814 [RFC3740]. 816 Intellectual Property Statement 818 The IETF takes no position regarding the validity or scope of any 819 Intellectual Property Rights or other rights that might be claimed to 820 pertain to the implementation or use of the technology described in 821 this document or the extent to which any license under such rights 822 might or might not be available; nor does it represent that it has 823 made any independent effort to identify any such rights. Information 824 on the procedures with respect to rights in RFC documents can be 825 found in BCP 78 and BCP 79. 827 Copies of IPR disclosures made to the IETF Secretariat and any 828 assurances of licenses to be made available, or the result of an 829 attempt made to obtain a general license or permission for the use of 830 such proprietary rights by implementers or users of this 831 specification can be obtained from the IETF on-line IPR repository at 832 http://www.ietf.org/ipr. 834 The IETF invites any interested party to bring to its attention any 835 copyrights, patents or patent applications, or other proprietary 836 rights that may cover technology that may be required to implement 837 this standard. Please address the information to the IETF at 838 ietf-ipr@ietf.org. 840 Disclaimer of Validity 842 This document and the information contained herein are provided on an 843 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 844 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 845 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 846 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 847 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 848 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 850 Copyright Statement 852 Copyright (C) The Internet Society (2004). This document is subject 853 to the rights, licenses and restrictions contained in BCP 78, and 854 except as set forth therein, the authors retain all their rights. 856 Acknowledgment 858 Funding for the RFC Editor function is currently provided by the 859 Internet Society.