idnits 2.17.1 draft-ietf-mboned-routingarch-11.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1141. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1154. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2201, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC3913, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC1584, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2189, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 13, 2007) is 6038 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-11 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-pim-snooping-01 == Outdated reference: A later version (-07) exists of draft-ietf-mboned-addrarch-05 == Outdated reference: A later version (-04) exists of draft-ietf-pim-lasthop-threats-03 -- Obsolete informational reference (is this intentional?): RFC 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 13 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: 3913,2189,2201,1584 October 13, 2007 5 (if approved) 6 Intended status: Best Current 7 Practice 8 Expires: April 15, 2008 10 Overview of the Internet Multicast Routing Architecture 11 draft-ietf-mboned-routingarch-11.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 15, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes multicast routing architectures that are 45 currently deployed on the Internet. This document briefly describes 46 those protocols and references their specifications. 48 This memo also reclassifies to Historic several older RFCs. These 49 RFCs describe multicast routing protocols that were never widely 50 deployed or have fallen into disuse. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 56 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 58 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 7 61 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8 66 2.2. Distributing Topology Information . . . . . . . . . . . . 9 67 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9 68 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 10 69 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 10 70 2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 11 72 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12 75 2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 76 2.4. Configuring and Distributing PIM RP Information . . . . . 13 77 2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 13 78 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 79 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 14 80 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 81 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 15 82 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 15 83 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 15 84 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15 85 2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 86 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 16 87 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 16 88 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16 89 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 90 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 17 91 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17 92 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17 93 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 19 94 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 95 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 97 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 99 6.2. Informative References . . . . . . . . . . . . . . . . . . 21 100 Appendix A. Multicast Payload Transport Extensions . . . . . . . 24 101 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 24 102 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 25 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 Intellectual Property and Copyright Statements . . . . . . . . . . 26 106 1. Introduction 108 This document provides a brief overview of multicast routing 109 architectures that are currently deployed on the Internet and how 110 those protocols fit together. It also describes those multicast 111 routing protocols that were never widely deployed or have fallen into 112 disuse. A companion document [I-D.ietf-mboned-addrarch] describes 113 multicast addressing architectures. 115 Specifically, this memo deals with: 117 o setting up multicast forwarding state (Section 2.1), 119 o distributing multicast topology information (Section 2.2), 121 o learning active sources (Section 2.3), 123 o configuring and distributing the rendezvous point (RP) information 124 (Section 2.4), 126 o mechanisms for enhanced redundancy (Section 2.5), 128 o interacting with hosts (Section 2.6), and 130 o restricting the multicast flooding in the link layer 131 (Section 2.7). 133 Section 2 starts by describing a simplistic example how these classes 134 of mechanisms fit together. Some multicast data transport issues are 135 also introduced in Appendix A. 137 This memo re-classifies to Historic [RFC2026] the following RFCs: 139 o Border Gateway Multicast Protocol (BGMP) [RFC3913], 141 o Core Based Trees (CBT) [RFC2189] [RFC2201], 143 o Multicast OSPF (MOSPF) [RFC1584]. 145 For the most part, these protocols have fallen into disuse. There 146 may be legacy deployments of some of these protocols, which are not 147 affected by this reclassification. See Section 2.1 for more on each 148 protocol. 150 Further historical perspective may be found in, for example, 151 [RFC1458], [IMRP-ISSUES], and [IM-GAPS]. 153 1.1. Multicast-related Abbreviations 155 ASM Any Source Multicast 156 BGMP Border Gateway Multicast Protocol 157 BSR Bootstrap Router 158 CBT Core Based Trees 159 CGMP Cisco Group Management Protocol 160 DR Designated Router 161 DVMRP Distance Vector Multicast Routing Protocol 162 GARP (IEEE 802.1D-2004) Generic Attribute Reg. Protocol 163 GMRP GARP Multicast Registration Protocol 164 IGMP Internet Group Management Protocol 165 MBGP Multi-protocol BGP (*not* "Multicast BGP") 166 MLD Multicast Listener Discovery 167 MRP (IEEE 802.1ak) Multiple Registration Protocol 168 MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto. 169 MOSPF Multicast OSPF 170 MSDP Multicast Source Discovery Protocol 171 PGM Pragmatic General Multicast 172 PIM Protocol Independent Multicast 173 PIM-DM PIM - Dense Mode 174 PIM-SM PIM - Sparse Mode 175 PIM-SSM PIM - Source-Specific Multicast 176 RGMP (Cisco's) Router Group Management Protocol 177 RP Rendezvous Point 178 RPF Reverse Path Forwarding 179 SAFI Subsequent Address Family Identifier 180 SDP Session Description Protocol 181 SSM Source-specific Multicast 183 2. Multicast Routing 185 In order to give a simplified summary how each of these class of 186 mechanisms fits together, consider the following multicast receiver 187 scenario. 189 Certain protocols and configuration needs to be in place before 190 multicast routing can work. Specifically, when ASM is employed, a 191 router will need to know its RP address(es) (Section 2.4, 192 Section 2.5). With IPv4, RPs need to be connected to other RPs using 193 MSDP so information about sources connected to other RPs can be 194 distributed (Section 2.3). Further, routers need to know if or how 195 multicast topology differs from unicast topology, and routing 196 protocol extensions can provide that information (Section 2.2). 198 When a host wants to receive a transmission, it first needs to find 199 out the multicast group address (and with SSM, source address) using 200 various means (e.g., SDP description file [RFC4566] or manually). 201 Then it will signal its interest to its first-hop router using IGMP 202 (IPv4) or MLD (IPv6) (Section 2.6). The router initiates setting up 203 hop-by-hop multicast forwarding state (Section 2.1) to the source (in 204 SSM) or first through the RP (in ASM). Routers use an RP to find out 205 all the sources for a group (Section 2.3). When multicast 206 transmission arrives at the receiver's LAN, it is flooded to every 207 Ethernet switch port unless flooding reduction such as IGMP snooping 208 is employed (Section 2.7). 210 2.1. Setting up Multicast Forwarding State 212 The most important part of multicast routing is setting up the 213 multicast forwarding state. State maintenance requires periodic 214 messaging because forwarding state has a timeout. This section 215 describes the protocols commonly used for this purpose. 217 2.1.1. PIM-SM 219 By far, the most common multicast routing protocol is PIM-SM 220 [RFC4601]. The PIM-SM protocol includes both Any Source Multicast 221 (ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is 222 a subset of PIM-SM that does not use the RPs but instead requires 223 that receivers know the (source,group) pair and signal that 224 explicitly. Most current routing platforms support PIM-SM. 226 PIM routers elect a designated router on each LAN and the DR is 227 responsible for PIM messaging and source registration on behalf of 228 the hosts. The DR encapsulates multicast packets sourced from the 229 LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional, 230 group-specific distribution tree consisting of the interested 231 receivers of a group. Initially the multicast distribution tree is 232 rooted at the RP but later the DRs have the option of optimizing the 233 delivery by building (source,group)-specific trees. 235 A more lengthy introduction to PIM-SM can be found in Section 3 of 236 [RFC4601]. 238 2.1.2. PIM-DM 240 Whereas PIM-SM has been designed to avoid unnecessary flooding of 241 multicast data, PIM-DM [RFC3973] assumed that almost every subnet at 242 a site had at least one receiver for a group. PIM-DM floods 243 multicast transmissions throughout the network ("flood and prune") 244 unless the leaf parts of the network periodically indicate that they 245 are not interested in that particular group. 247 PIM-DM may be an acceptable fit in small and/or simple networks, 248 where setting up an RP would be unnecessary, and possibly in cases 249 where a large percentage of users are expected to want to receive the 250 transmission so that the amount of state the network has to keep is 251 minimal. 253 PIM-DM was used as a first step in transitioning away from DVMRP. It 254 also became apparent that most networks would not have receivers for 255 most groups, and to avoid the bandwidth and state overhead, the 256 flooding paradigm was gradually abandoned. Transitioning from PIM-DM 257 to PIM-SM was easy as PIM-SM was designed to use compatible packet 258 formats and dense-mode operation could also be satisfied by a sparse 259 protocol. PIM-DM is no longer in widespread use. 261 Many implementations also support so-called "sparse-dense" 262 configuration, where Sparse mode is used by default, but Dense is 263 used for configured multicast group ranges (such as Auto-RP in 264 Section 2.4.3) only. Lately, many networks have transitioned away 265 from sparse-dense to only sparse mode. 267 2.1.3. Bi-directional PIM 269 Bi-directional PIM [I-D.ietf-pim-bidir] is a multicast forwarding 270 protocol that establishes a common shared-path for all sources with a 271 single root. It can be used as an alternative to PIM-SM inside a 272 single domain. It doesn't have data-driven events or data- 273 encapsulation. As it doesn't keep source-specific state, it may be 274 an appealing approach especially in sites with a large number of 275 sources. 277 As of this writing, there is no inter-domain solution to configure a 278 group range to use bi-directional PIM. 280 2.1.4. DVMRP 282 Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] 283 [I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first 284 protocol designed for multicasting. To get around initial deployment 285 hurdles, it also included tunneling capabilities which were part of 286 its multicast topology functions. 288 Currently, DVMRP is used only very rarely in operator networks, 289 having been replaced with PIM-SM. The most typical deployment of 290 DVMRP is at a leaf network, to run from a legacy firewall only 291 supporting DVMRP to the internal network. However, Generic Routing 292 Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP 293 in this functionality, and there is relatively little use for DVMRP 294 except in legacy deployments. 296 2.1.5. MOSPF 298 MOSPF [RFC1584] was implemented by several vendors and has seen some 299 deployment in intra-domain networks. However, since it is based on 300 intra-domain Open Shortest Path First (OSPF) it does not scale to the 301 inter-domain case, operators have found it is easier to deploy a 302 single protocol for use in both intra-domain and inter-domain 303 networks and so it is no longer being actively deployed. 305 2.1.6. BGMP 307 BGMP [RFC3913] did not get sufficient support within the service 308 provider community to get adopted and moved forward in the IETF 309 standards process. There were no reported production implementations 310 and no production deployments. 312 2.1.7. CBT 314 CBT [RFC2201][RFC2189] was an academic project that provided the 315 basis for PIM sparse mode shared trees. Once the shared tree 316 functionality was incorporated into PIM implementations, there was no 317 longer a need for a production CBT implementation. Therefore, CBT 318 never saw production deployment. 320 2.1.8. Interactions and Summary 322 It is worth noting that it is possible to run different protocols 323 with different multicast group ranges. For example, treat some 324 groups as dense or bi-dir in an otherwise PIM-SM network; this 325 typically requires manual configuration of the groups or a mechanism 326 like BSR (Section 2.4.3). It is also possible to interact between 327 different protocols, for example use DVMRP in the leaf network, but 328 PIM-SM upstream. The basics for interactions among different 329 protocols have been outlined in [RFC2715]. 331 The following figure gives a concise summary of the deployment status 332 of different protocols as of this writing. 334 +-------------+-------------+----------------+ 335 | Interdomain | Intradomain | Status | 336 +------------+-------------+-------------+----------------+ 337 | PIM-SM | Yes | Yes | Active | 338 | PIM-DM | Not anymore | Not anymore | Little use | 339 | Bi-dir PIM | No | Yes | Some uptake | 340 | DVMRP | Not anymore | Stub only | Going out | 341 | MOSPF | No | Not anymore | Inactive | 342 | CBT | No | No | Never deployed | 343 | BGMP | No | No | Never deployed | 344 +------------+-------------+-------------+----------------+ 346 From this table, it is clear that PIM-Sparse Mode is the only 347 multicast routing protocol that is deployed inter-domain and, 348 therefore, is most frequently used within multicast domains as well. 350 2.2. Distributing Topology Information 352 PIM has become the de-facto multicast forwarding protocol, but as its 353 name implies, it is independent of the underlying unicast routing 354 protocol. When unicast and multicast topologies are the same 355 ("congruent"), i.e., use the same routing tables (routing information 356 base, RIB), it has been considered sufficient just to distribute one 357 set of reachability information to be used in conjunction with a 358 protocol that sets up multicast forwarding state (e.g., PIM-SM). 360 However, when PIM which by default built multicast topology based on 361 the unicast topology gained popularity, it became apparent that it 362 would be necessary to be able to distribute also non-congruent 363 multicast reachability information in the regular unicast protocols. 364 This was previously not an issue, because DVMRP built its own 365 reachability information. 367 The topology information is needed to perform efficient distribution 368 of multicast transmissions and to prevent transmission loops by 369 applying it to the Reverse Path Forwarding (RPF) check. 371 This subsection introduces these protocols. 373 2.2.1. Multi-protocol BGP 375 Multiprotocol Extensions for BGP-4 [RFC4760] (often referred to as 376 "MBGP"; however, it is worth noting that "MBGP" does *not* stand for 377 "Multicast BGP") specifies a mechanism by which BGP can be used to 378 distribute different reachability information for unicast (SAFI=1) 379 and multicast traffic (SAFI=2). Multiprotocol BGP has been widely 380 deployed for years, and is also needed to route IPv6. Note that 381 SAFI=3 was originally specified for "both unicast and multicast" but 382 has since then been deprecated. 384 These extensions are in widespread use wherever BGP is used to 385 distribute unicast topology information. Multicast-enabled networks 386 that use BGP should use Multiprotocol BGP to distribute multicast 387 reachability information explicitly even if the topologies are 388 congruent to make an explicit statement about multicast reachability. 389 A number of significant multicast transit providers even require 390 this, by doing the RPF lookups solely based on explicitly advertised 391 multicast address family. 393 2.2.2. OSPF/IS-IS Multi-topology Extensions 395 Similar to BGP, some Interior Gateway Protocols (IGPs) also provide 396 the capability for signalling differing topologies, for example IS-IS 397 multi-topology extensions [I-D.ietf-isis-wg-multi-topology]. These 398 can be used for a multicast topology that differs from unicast. 399 Similar but not so widely implemented work exists for OSPF [RFC4915]. 401 It is worth noting that interdomain incongruence and intradomain 402 incongruence are orthogonal, so one doesn't require the other. 403 Specifically, interdomain incongruence is quite common, while 404 intradomain incongruence isn't, so you see much more deployment of 405 MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well 406 without protocols handling intradomain incongruence. However, the 407 availability of multi-topology mechanisms may in part replace the 408 typically used workarounds such as tunnels. 410 2.2.3. Issue: Overlapping Unicast/multicast Topology 412 An interesting case occurs when some routers do not distribute 413 multicast topology information explicitly while others do. In 414 particular, this happens when some multicast sites in the Internet 415 are using plain BGP while some use MBGP. 417 Different implementations deal with this in different ways. 418 Sometimes, multicast RPF mechanisms first look up the multicast 419 routing table, or M-RIB ("topology database") with a longest prefix 420 match algorithm, and if they find any entry (including a default 421 route), that is used; if no match is found, the unicast routing table 422 is used instead. 424 An alternative approach is to use longest prefix match on the union 425 of multicast and unicast routing tables; an implementation technique 426 here is to copy the whole unicast routing table over to the multicast 427 routing table. The important point to remember here, though, is to 428 not override the multicast-only routes; if the longest prefix match 429 would find both a (copied) unicast route and a multicast-only route, 430 the latter should be treated as preferable. 432 Another implemented approach is to just look up the information in 433 the unicast routing table, and provide the user capabilities to 434 change that as appropriate, using for example copying functions 435 discussed above. 437 2.2.4. Summary 439 A congruent topology can be deployed using unicast routing protocols 440 that provide no support for a separate multicast topology. In intra- 441 domain that approach is often adequate. However, it is recommended 442 that if interdomain routing uses BGP, multicast-enabled sites should 443 use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the 444 topology was congruent to explicitly signal "yes, we use multicast". 446 The following table summarizes the approaches that can be used to 447 distribute multicast topology information. 449 +----------------+---------------+ 450 | Interdomain | Intradomain | 451 +--------------------- +----------------+--------------+ 452 | MP-BGP SAFI=2 | Yes | Yes | 453 | MP-BGP SAFI=3 | Doesn't work | Doesn't work | 454 | IS-IS multi-topology | Not applicable | Yes | 455 | OSPF multi-topology | Not applicable | Few implem. | 456 +----------------------+----------------+--------------+ 458 "Not applicable" refers to the fact that IGP protocols can't be used 459 in interdomain routing. "Doesn't work" means that while MP-BGP 460 SAFI=3 was defined and could apply, that part of the specification 461 has not been implemented and can't be used in practice. "Yes" lists 462 the mechanisms which are generally applicable and known to work. 463 "Few implem." means that the approach could work but is not commonly 464 available. 466 2.3. Learning (Active) Sources 468 To build a multicast distribution tree, the routing protocol needs to 469 find out where the sources for the group are. In case of SSM, the 470 user specifies the source IP address or it is otherwise learned out 471 of band. 473 In ASM, the RPs know about all the active sources in a local PIM 474 domain. As a result, when PIM-SM or bi-dir PIM is used in intra- 475 domain the sources are learned as a feature of the protocol itself. 477 Having a single PIM-SM domain for the whole Internet is an 478 insufficient model for many reasons, including scalability, 479 administrative boundaries and different technical tradeoffs. 480 Therefore it is required to be able to split up the multicast routing 481 infrastructures to smaller domains, and there must be a way to share 482 information about active sources using some mechanism if the ASM 483 model is to be supported. 485 This section discusses the options of learning active sources that 486 apply in an inter-domain environment. 488 2.3.1. SSM 490 Source-specific Multicast [RFC4607] (sometimes also referred to as 491 "single-source Multicast") does not count on learning active sources 492 in the network. Recipients need to know the source IP addresses 493 using an out of band mechanism which are used to subscribe to the 494 (source, group) channel. The multicast routing uses the source 495 address to set up the state and no further source discovery is 496 needed. 498 As of this writing, there are attempts to analyze and/or define out- 499 of-band source discovery functions which would help SSM in particular 500 [I-D.lehtonen-mboned-dynssm-req]. 502 2.3.2. MSDP 504 Multicast Source Discovery Protocol [RFC3618] was invented as a stop- 505 gap mechanism, when it became apparent that multiple PIM-SM domains 506 (and RPs) were needed in the network, and information about the 507 active sources needed to be propagated between the PIM-SM domains 508 using some other protocol. 510 MSDP is also used to share the state about sources between multiple 511 RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The 512 same can be achieved using PIM extensions [RFC4610]. See Section 2.5 513 for more information. 515 There is no intent to define MSDP for IPv6, but instead use only SSM 516 and Embedded-RP [I-D.ietf-mboned-ipv6-multicast-issues]. 518 2.3.3. Embedded-RP 520 Embedded-RP [RFC3956] is an IPv6-only technique to map the address of 521 the RP to the multicast group address. Using this method, it is 522 possible to avoid the use of MSDP while still allowing multiple 523 multicast domains (in the traditional sense). 525 The model works by defining a single RP address for a particular 526 group for all of the Internet, so there is no need to share state 527 about that with any other RPs. If necessary, RP redundancy can still 528 be achieved with Anycast-RP using PIM [RFC4610]. 530 2.3.4. Summary 532 The following table summarizes the source discovery approaches and 533 their status. 535 +------+------+------------------------------+ 536 | IPv4 | IPv6 | Status | 537 +----------------------+------+------+------------------------------+ 538 | Bi-dir single domain | Yes | Yes | OK but for intra-domain only | 539 | PIM-SM single domain | Yes | Yes | OK | 540 | PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM | 541 | PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option | 542 | SSM | Yes | Yes | No major uptake yet | 543 +----------------------+------+------+------------------------------+ 545 2.4. Configuring and Distributing PIM RP Information 547 PIM-SM and Bi-dir PIM configuration mechanisms exist which are used 548 to configure the RP addresses and the groups that are to use those 549 RPs in the routers. This section outlines the approaches. 551 2.4.1. Manual RP Configuration 553 It is often easiest just to manually configure the RP information on 554 the routers when PIM-SM is used. 556 Originally, static RP mapping was considered suboptimal since it 557 required explicit configuration changes every time the RP address 558 changed. However, with the advent of anycast RP addressing, the RP 559 address is unlikely to ever change. Therefore, the administrative 560 burden is generally limited to initial configuration. Since there is 561 usually a fair amount of multicast configuration required on all 562 routers anyway (e.g., PIM on all interfaces), adding the RP address 563 statically isn't really an issue. Further, static anycast RP mapping 564 provides the benefits of RP load sharing and redundancy (see 565 Section 2.5) without the complexity found in dynamic mechanisms like 566 Auto-RP and Bootstrap Router (BSR). 568 With such design, an anycast RP uses an address that is configured on 569 a loopback interfaces of the routers currently acting as RPs, and 570 state is distributed using PIM [RFC4610] or MSDP [RFC3446]. 572 Using this technique, each router might only need to be configured 573 with one, portable RP address. 575 2.4.2. Embedded-RP 577 Embedded-RP provides the information about the RP's address in the 578 group addresses which are delegated to those who use the RP, so 579 unless no other ASM than Embedded-RP is used, the network 580 administrator only needs to configure the RP routers. 582 While Embedded-RP in many cases is sufficient for IPv6, other methods 583 of RP configuration are needed if one needs to provide ASM service 584 for other than Embedded-RP group addresses. In particular, service 585 discovery type of applications may need hard-coded addresses that are 586 not dependent on local RP addresses. 588 As the RP's address is exposed to the users and applications, it is 589 very important to ensure it does not change often, e.g., by using 590 manual configuration of an anycast address. 592 2.4.3. BSR and Auto-RP 594 BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP 595 address for groups. It may no longer be in as wide use with IPv4 as 596 it was earlier, and for IPv6, Embedded-RP will in many cases be 597 sufficient. 599 Cisco's Auto-RP is an older, proprietary method for distributing 600 group to RP mappings, similar to BSR. Auto-RP has little use today. 602 Both Auto-RP and BSR require some form of control at the routers to 603 ensure that only valid routers are able to advertise themselves as 604 RPs. Further, flooding of BSR and Auto-RP messages must be prevented 605 at PIM borders. Additionally, routers require monitoring that they 606 are actually using the RP(s) the administrators think they should be 607 using, for example if a router (maybe in customer's control) is 608 advertising itself inappropriately. All in all, while BSR and 609 Auto-RP provide easy configuration, they also provide very 610 significant configuration and management complexity. 612 It is worth noting that both Auto-RP and BSR were deployed before the 613 use of a manually configured anycast-RP address became relatively 614 commonplace, and there is actually relatively little need for them 615 today unless there is a need to configure different properties (e.g., 616 sparse, dense, bi-dir) in a dynamic fashion. 618 2.4.4. Summary 620 The following table summarizes the RP discovery mechanisms and their 621 status. With the exception of Embedded-RP, each mechanism operates 622 within a PIM domain. 624 +------+------+-----------------------+ 625 | IPv4 | IPv6 | Deployment | 626 +--------------------+------+------+-----------------------+ 627 | Static RP | Yes | Yes | Especially in ISPs | 628 | Auto-RP | Yes | No | Legacy deployment | 629 | BSR | Yes | Yes | Some, anycast simpler | 630 | Embedded-RP | No | Yes | Growing | 631 +--------------------+------+------+-----------------------+ 633 2.5. Mechanisms for Enhanced Redundancy 635 Having only one RP in a PIM-SM domain would be a single point of 636 failure for the whole multicast domain. As a result, a number of 637 mechanisms have been developed to either eliminate the RP 638 functionality or to enhance RPs' redundancy, resilience against 639 failures, and to recover from failures quickly. This section 640 summarizes these techniques explicitly. 642 2.5.1. Anycast RP 644 As mentioned in Section 2.3.2, MSDP is also used to share the state 645 about sources between multiple RPs in a single domain for, e.g., 646 redundancy purposes [RFC3446]. The purpose of MSDP in this context 647 is to share the same state information on multiple RPs for the same 648 groups to enhance the robustness of the service. 650 Recent PIM extensions [RFC4610] also provide this functionality. In 651 contrast to MSDP, this approach works for both IPv4 and IPv6. 653 2.5.2. Stateless RP Failover 655 While Anycast RP shares state between RPs so that RP failure causes 656 only small disturbance, stateless approaches are also possible with a 657 more limited resiliency. A traditional mechanism has been to use 658 Auto-RP or BSR (see Section 2.4.3) to select another RP when the 659 active one failed. However, the same functionality could be achieved 660 using a shared-unicast RP address ("anycast RP without state 661 sharing") without the complexity of a dynamic mechanism. Further, 662 Anycast RP offers a significantly more extensive failure mitigation 663 strategy, so today there is actually very little need to use 664 stateless failover mechanisms, especially dynamic ones, for 665 redundancy purposes. 667 2.5.3. Bi-directional PIM 669 Because bi-directional PIM (see Section 2.1.3) does not switch to 670 shortest path tree (SPT), the final multicast tree may be established 671 faster. On the other hand, PIM-SM or SSM may converge more quickly 672 especially in scenarios (e.g., unicast routing change) where bi- 673 directional needs to re-do the Designated Forwarder election. 675 2.5.4. Summary 677 The following table summarizes the techniques for enhanced 678 redundancy. 680 +------+------+-----------------------+ 681 | IPv4 | IPv6 | Deployment | 682 +--------------------+------+------+-----------------------+ 683 | Anycast RP w/ MSDP | Yes | No | De-facto approach | 684 | Anycast RP w/ PIM | Yes | Yes | Newer approach | 685 | Stateless RP fail. | Yes | Yes | Causes disturbance | 686 | Bi-dir PIM | Yes | Yes | Deployed at some sites| 687 +-------------+------+------+------------------------------+ 689 2.6. Interactions with Hosts 691 Previous sections have dealt with the components required by routers 692 to be able to do multicast routing. Obviously, the real users of 693 multicast are the hosts: either sending or receiving multicast. This 694 section describes the required interactions with hosts. 696 2.6.1. Hosts Sending Multicast 698 After choosing a multicast group through a variety of means, hosts 699 just send the packets to the link-layer multicast address, and the 700 designated router will receive all the multicast packets and start 701 forwarding them as appropriate. A host does not need to be a member 702 of the group in order to send to it [RFC1112]. 704 In intra-domain or Embedded-RP scenarios, ASM senders may move to a 705 new IP address without significant impact on the delivery of their 706 transmission. SSM senders cannot change the IP address unless 707 receivers join the new channel or the sender uses an IP mobility 708 technique that is transparent to the receivers. 710 2.6.2. Hosts Receiving Multicast 712 Hosts signal their interest in receiving a multicast group or channel 713 by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are 714 still commonplace, but are also often used in new deployments. Some 715 vendors also support SSM mapping techniques for receivers which use 716 an older IGMP/MLD version where the router maps the join request to 717 an SSM channel based on various, usually complex means of 718 configuration. 720 2.6.3. Summary 722 The following table summarizes the techniques host interaction. 724 +-------+------+----------------------------+ 725 | IPv4 | IPv6 | Notes | 726 +--------------------+-------+------+----------------------------+ 727 | Host sending | Yes | Yes | No support needed | 728 | Host receiving ASM | IGMP | MLD | Any IGMP/MLD version | 729 | Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping | 730 +--------------------+-------+------+----------------------------+ 732 2.7. Restricting Multicast Flooding in the Link Layer 734 Multicast transmission in the link layer, for example Ethernet, 735 typically includes some form of flooding the packets through a LAN. 736 This causes unnecessary bandwidth usage and discarding unwanted 737 frames on those nodes which did not want to receive the multicast 738 transmission. 740 Therefore a number of techniques have been developed, to be used in 741 Ethernet switches between routers, or between routers and hosts, to 742 limit the flooding. 744 Some mechanisms operate with IP addresses, others with MAC addresses. 745 If filtering is done based on MAC addresses, hosts may receive 746 unnecessary multicast traffic (filtered out in the hosts' IP layer) 747 if more than one IP multicast group addresses maps into the same MAC 748 address, or if IGMPv3/MLDv2 source filters are used. Filtering based 749 on IP destination addresses, or destination and sources addresses, 750 will help avoid these but requires parsing of the Ethernet frame 751 payload. 753 These options are discussed in this section. 755 2.7.1. Router-to-Router Flooding Reduction 757 A proprietary solution, Cisco's RGMP [RFC3488] has been developed to 758 reduce the amount of flooding between routers in a switched networks. 759 This is typically only considered a problem in some Ethernet-based 760 Internet Exchange points or VPNs. 762 There have been proposals to observe and possibly react ("snoop") PIM 763 messages [I-D.ietf-l2vpn-vpls-pim-snooping]. 765 2.7.2. Host/Router Flooding Reduction 767 There are a number of techniques to help reduce flooding both from a 768 router to hosts, and from a host to the routers (and other hosts). 770 Cisco's proprietary CGMP [CGMP] provides a solution where the routers 771 notify the switches, but also allows the switches to snoop IGMP 772 packets to enable faster notification of hosts no longer wishing to 773 receive a group. Implementations of CGMP do not support fast leave 774 behaviour with IGMPv3. Due to IGMP report suppression in IGMPv1 and 775 IGMPv2, multicast is still flooded to ports which were once members 776 of a group as long as there is at least one receiver on the link. 777 Flooding restrictions are done based on multicast MAC addresses. 778 Implementations of CGMP do not support IPv6. 780 IEEE 802.1D-2004 specification describes Generic Attribute 781 Registration Protocol (GARP), and GARP Multicast Registration 782 Protocol (GMRP) [GMRP] is a link-layer multicast group application of 783 GARP that notifies switches about MAC multicast group memberships. 784 If GMRP is used in conjunction with IP multicast, then the GMRP 785 registration function would become associated with an IGMP "join." 786 However, this GMRP-IGMP association is beyond the scope of GMRP. 787 GMRP requires support at the host stack and it has not been widely 788 implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete 789 being replaced by Multiple Registration Protocol (MRP) and Multicast 790 Multiple Registration Protocol (MMRP) that are being specified in 791 IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between 792 bridges. Some further information about GARP/GMRP is also available 793 in Appendix B of [RFC3488]. 795 IGMP snooping [RFC4541] appears to be the most widely implemented 796 technique. IGMP snooping requires that the switches implement a 797 significant amount of IP-level packet inspection; this appears to be 798 something that is difficult to get right, and often the upgrades are 799 also a challenge. Snooping support is commonplace for IGMPv1 and 800 IGMPv2, but fewer switches support IGMPv3 or MLD (any version) 801 snooping. In the worst case, enabling IGMP snooping on a switch that 802 does not support IGMPv3 snooping breaks multicast capabilities of 803 nodes using IGMPv3. 805 Snooping switches also need to identify the ports where routers 806 reside and therefore where to flood the packets. This can be 807 accomplished using Multicast Router Discovery protocol [RFC4286], 808 looking at certain IGMP queries [RFC4541], looking at PIM Hello and 809 possibly other messages, or by manual configuration. An issue with 810 PIM snooping at LANs is that PIM messages can't be turned off or 811 encrypted, leading to security issues [I-D.ietf-pim-lasthop-threats]. 813 IGMP proxying [RFC4605] is sometimes used either as a replacement of 814 a multicast routing protocol on a small router, or to aggregate IGMP/ 815 MLD reports when used with IGMP snooping. 817 2.7.3. Summary 819 The following table summarizes the techniques for multicast flooding 820 reduction inside a single link for router-to-router and last-hop 821 LANs. 823 +--------+-----+----------------------------+ 824 | R-to-R | LAN | Notes | 825 +-----------------------+--------+-----+----------------------------+ 826 | Cisco's RGMP | Yes | No | Replaced by PIM snooping | 827 | PIM snooping | Yes | No | Security issues in LANs | 828 | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare | 829 | Multicast Router Disc | No | Yes | Few if any implem. yet | 830 | IEEE GMRP and MMRP | No | No | No host/router deployment | 831 | Cisco's CGMP | No | Yes | Replaced by other snooping | 832 +-----------------------+--------+-----+----------------------------+ 834 3. Acknowledgements 836 Tutoring a couple multicast-related papers, the latest by Kaarle 837 Ritvanen [RITVANEN] convinced the author that up-to-date multicast 838 routing and address assignment/allocation documentation is necessary. 840 Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, 841 Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat 842 Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon 843 Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, and 844 Prashant Jhingran provided good comments, helping in improving this 845 document. 847 4. IANA Considerations 849 IANA is requested to update the following registries by adding a 850 reference to this document: 852 o OSPFv2 Option registry: MC-bit 854 o OSPFv2 Link state type: Group-membership-LSA 856 o OSPFv2 Router properties registry: W-bit (0x08) 858 o OSPFv3 Option registry: MC-bit 860 o OSPFv3 LSA function code registry: Group-membership-LSA 861 o OSPFv3 Prefix Options Registry: MC-bit 863 (To be removed prior to publication as an RFC: IANA is also requested 864 to correct a typo in OSPFv2 Router properties registry: The first 865 W-bit (0x02) entry should be renamed to 'E-bit' as described in RFC 866 2328 section A.4.2.) 868 5. Security Considerations 870 This memo only describes different approaches to multicast routing, 871 and this has no security considerations; the security analysis of the 872 mentioned protocols is out of scope of this memo. 874 However, there has been analysis of the security of multicast routing 875 infrastructures [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and 876 PIM last-hop issues [I-D.ietf-pim-lasthop-threats]. 878 6. References 880 6.1. Normative References 882 [I-D.ietf-pim-bidir] 883 Handley, M., "Bi-directional Protocol Independent 884 Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in 885 progress), February 2007. 887 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 888 3", BCP 9, RFC 2026, October 1996. 890 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 891 Thyagarajan, "Internet Group Management Protocol, Version 892 3", RFC 3376, October 2002. 894 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 895 Protocol (MSDP)", RFC 3618, October 2003. 897 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 898 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 900 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 901 Point (RP) Address in an IPv6 Multicast Address", 902 RFC 3956, November 2004. 904 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 905 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 906 Protocol Specification (Revised)", RFC 4601, August 2006. 908 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 909 IP", RFC 4607, August 2006. 911 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 912 "Multiprotocol Extensions for BGP-4", RFC 4760, 913 January 2007. 915 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 916 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 917 RFC 4915, June 2007. 919 6.2. Informative References 921 [802.1ak] "IEEE 802.1ak - Multiple Registration Protocol", 922 . 924 [CGMP] "Cisco Group Management Protocol", 925 . 927 [GMRP] "GARP Multicast Registration Protocol", 928 . 930 [I-D.daley-magma-smld-prob] 931 Daley, G. and G. Kurup, "Trust Models and Security in 932 Multicast Listener Discovery", 933 draft-daley-magma-smld-prob-00 (work in progress), 934 July 2004. 936 [I-D.ietf-idmr-dvmrp-v3] 937 Pusateri, T., "Distance Vector Multicast Routing 938 Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), 939 December 2003. 941 [I-D.ietf-idmr-dvmrp-v3-as] 942 Pusateri, T., "Distance Vector Multicast Routing Protocol 943 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 944 (work in progress), May 2004. 946 [I-D.ietf-isis-wg-multi-topology] 947 Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in 948 IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in 949 progress), October 2005. 951 [I-D.ietf-l2vpn-vpls-pim-snooping] 952 Hemige, V., "PIM Snooping over VPLS", 953 draft-ietf-l2vpn-vpls-pim-snooping-01 (work in progress), 954 March 2007. 956 [I-D.ietf-mboned-addrarch] 957 Savola, P., "Overview of the Internet Multicast Addressing 958 Architecture", draft-ietf-mboned-addrarch-05 (work in 959 progress), October 2006. 961 [I-D.ietf-mboned-ipv6-multicast-issues] 962 Savola, P., "IPv6 Multicast Deployment Issues", 963 draft-ietf-mboned-ipv6-multicast-issues-02 (work in 964 progress), February 2005. 966 [I-D.ietf-pim-lasthop-threats] 967 Savola, P. and J. Lingard, "Host Threats to Protocol 968 Independent Multicast (PIM)", 969 draft-ietf-pim-lasthop-threats-03 (work in progress), 970 October 2007. 972 [I-D.ietf-pim-sm-bsr] 973 Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", 974 draft-ietf-pim-sm-bsr-12 (work in progress), August 2007. 976 [I-D.lehtonen-mboned-dynssm-req] 977 Lehtonen, R., "Requirements for discovery of dynamic SSM 978 sources", draft-lehtonen-mboned-dynssm-req-00 (work in 979 progress), February 2005. 981 [IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap 982 Analysis from the MBONED Working Group for the IESG 983 [Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work 984 in progress), July 2002. 986 [IMRP-ISSUES] 987 Meyer, D., "Some Issues for an Inter-domain Multicast 988 Routing Protocol [Expired]", 989 draft-ietf-mboned-imrp-some-issues-01 (work in progress), 990 September 1997. 992 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 993 Vector Multicast Routing Protocol", RFC 1075, 994 November 1988. 996 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 997 RFC 1112, August 1989. 999 [RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast 1000 Protocols", RFC 1458, May 1993. 1002 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 1003 March 1994. 1005 [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 1006 Routing -- Protocol Specification --", RFC 2189, 1007 September 1997. 1009 [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing 1010 Architecture", RFC 2201, September 1997. 1012 [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing 1013 Protocols", RFC 2715, October 1999. 1015 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1016 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1017 March 2000. 1019 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 1020 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 1021 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 1022 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 1023 Protocol Specification", RFC 3208, December 2001. 1025 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 1026 Rendevous Point (RP) mechanism using Protocol Independent 1027 Multicast (PIM) and Multicast Source Discovery Protocol 1028 (MSDP)", RFC 3446, January 2003. 1030 [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group 1031 Management Protocol (RGMP)", RFC 3488, February 2003. 1033 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 1034 Architecture", RFC 3740, March 2004. 1036 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 1037 Protocol Specification", RFC 3913, September 2004. 1039 [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1040 "Negative-acknowledgment (NACK)-Oriented Reliable 1041 Multicast (NORM) Protocol", RFC 3940, November 2004. 1043 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1044 Independent Multicast - Dense Mode (PIM-DM): Protocol 1045 Specification (Revised)", RFC 3973, January 2005. 1047 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 1048 RFC 4286, December 2005. 1050 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1051 "Considerations for Internet Group Management Protocol 1052 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1053 Switches", RFC 4541, May 2006. 1055 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1056 Description Protocol", RFC 4566, July 2006. 1058 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1059 "Internet Group Management Protocol (IGMP) / Multicast 1060 Listener Discovery (MLD)-Based Multicast Forwarding 1061 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1063 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 1064 Independent Multicast - Sparse Mode (PIM-SM) Multicast 1065 Routing Security Issues and Enhancements", RFC 4609, 1066 October 2006. 1068 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 1069 Independent Multicast (PIM)", RFC 4610, August 2006. 1071 [RITVANEN] 1072 Ritvanen, K., "Multicast Routing and Addressing", HUT 1073 Report, Seminar on Internetworking, May 2004, 1074 . 1076 Appendix A. Multicast Payload Transport Extensions 1078 A couple of mechanisms have been, and are being specified, to improve 1079 the characteristics of the data that can be transported over 1080 multicast. 1082 These go beyond the scope of multicast routing, but as reliable 1083 multicast has some relevance, these are briefly mentioned. 1085 A.1. Reliable Multicast 1087 Reliable Multicast Working Group has been working on mostly 1088 experimental specifications so that applications requiring reliable 1089 delivery characteristics, instead of simple unreliable UDP, could use 1090 multicast as a distribution mechanism. 1092 One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. 1093 This does not require support from the routers, bur PGM-aware routers 1094 may act in router assistance role in the initial delivery and 1095 potential retransmission of missing data. Another mechanism is 1096 Negative-acknowledgment (NACK)-Oriented Reliable Multicast Protocol 1097 (NORM) [RFC3940] where routers may as an optional feature provide a 1098 more efficient repair functionality. 1100 A.2. Multicast Group Security 1102 Multicast Security Working Group has been working on methods how the 1103 integrity, confidentiality, and authentication of data sent to 1104 multicast groups can be ensured using cryptographic techniques 1105 [RFC3740]. 1107 Author's Address 1109 Pekka Savola 1110 CSC - Scientific Computing Ltd. 1111 Espoo 1112 Finland 1114 Email: psavola@funet.fi 1116 Full Copyright Statement 1118 Copyright (C) The IETF Trust (2007). 1120 This document is subject to the rights, licenses and restrictions 1121 contained in BCP 78, and except as set forth therein, the authors 1122 retain all their rights. 1124 This document and the information contained herein are provided on an 1125 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1126 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1127 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1128 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1129 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1130 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1132 Intellectual Property 1134 The IETF takes no position regarding the validity or scope of any 1135 Intellectual Property Rights or other rights that might be claimed to 1136 pertain to the implementation or use of the technology described in 1137 this document or the extent to which any license under such rights 1138 might or might not be available; nor does it represent that it has 1139 made any independent effort to identify any such rights. Information 1140 on the procedures with respect to rights in RFC documents can be 1141 found in BCP 78 and BCP 79. 1143 Copies of IPR disclosures made to the IETF Secretariat and any 1144 assurances of licenses to be made available, or the result of an 1145 attempt made to obtain a general license or permission for the use of 1146 such proprietary rights by implementers or users of this 1147 specification can be obtained from the IETF on-line IPR repository at 1148 http://www.ietf.org/ipr. 1150 The IETF invites any interested party to bring to its attention any 1151 copyrights, patents or patent applications, or other proprietary 1152 rights that may cover technology that may be required to implement 1153 this standard. Please address the information to the IETF at 1154 ietf-ipr@ietf.org. 1156 Acknowledgment 1158 Funding for the RFC Editor function is provided by the IETF 1159 Administrative Support Activity (IASA).