idnits 2.17.1 draft-ietf-mboned-routingarch-06.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1035. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1053. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1059. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 15, 2006) is 6465 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) == 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-mboned-addrarch-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-addrarch (ref. 'I-D.ietf-mboned-addrarch') == Outdated reference: A later version (-09) exists of draft-ietf-ospf-mt-06 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-08 ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Downref: Normative reference to an Experimental RFC: RFC 3973 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-pim-snooping-00 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-09 Summary: 7 errors (**), 0 flaws (~~), 7 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: August 15, 2006 5 3913,2189,2201,1584,1585 6 (if approved) 7 Intended status: Best Current 8 Practice 9 Expires: February 16, 2007 11 Overview of the Internet Multicast Routing Architecture 12 draft-ietf-mboned-routingarch-06.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 24 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 February 16, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 54 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 56 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6 59 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8 64 2.2. Distributing Topology Information . . . . . . . . . . . . 8 65 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9 66 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 9 67 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 9 68 2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 69 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10 70 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11 73 2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 74 2.4. Configuring and Distributing PIM RP Information . . . . . 12 75 2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12 76 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 77 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13 78 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 79 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14 80 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14 81 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14 82 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15 83 2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 84 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15 85 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15 86 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15 87 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 88 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16 89 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16 90 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16 91 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17 92 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 93 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 97 6.2. Informative References . . . . . . . . . . . . . . . . . . 20 99 Appendix A. Multicast Payload Transport Extensions . . . . . . . 22 100 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 22 101 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 103 Intellectual Property and Copyright Statements . . . . . . . . . . 24 105 1. Introduction 107 Good, up-to-date documentation of IP multicast is close to non- 108 existent. This issue is severely felt with multicast routing 109 protocols and techniques. The consequence is that those who wish to 110 learn of IP multicast and how the routing works in the real world do 111 not know where to begin. Multicast addressing is described in a 112 companion document [I-D.ietf-mboned-addrarch]. 114 The aim of this document is to provide a brief overview of multicast 115 routing protocols and techniques. 117 This memo deals with: 119 o setting up multicast forwarding state (Section 2.1), 121 o distributing multicast topology information (Section 2.2), 123 o learning active sources (Section 2.3), 125 o configuring and distributing the PIM RP information (Section 2.4), 127 o mechanisms for enhanced redundancy (Section 2.5), 129 o interacting with hosts (Section 2.6), and 131 o restricting the multicast flooding in the link layer 132 (Section 2.7). 134 Section 2 starts by describing a simplistic example how these classes 135 of mechanisms fit together. Some multicast data transport issues are 136 also introduced in Appendix A. 138 This memo obsoletes and re-classifies to Historic [RFC2026] Border 139 Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast 140 OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and 141 [RFC1585]. The purpose of the re-classification is to give the 142 readers (both implementors and deployers) an idea what the status of 143 a protocol is; there may be legacy deployments of some of these 144 protocols, which are not affected by this reclassification. See 145 Section 2.1 for more on each protocol. 147 1.1. Multicast-related Abbreviations 149 ASM Any Source Multicast 150 BGMP Border Gateway Multicast Protocol 151 BSR Bootstrap Router 152 CBT Core Based Trees 153 CGMP Cisco Group Management Protocol 154 DR Designated Router 155 DVMRP Distance Vector Multicast Routing Protocol 156 GARP (IEEE 802.1D-2004) Generic Attribute Reg. Protocol 157 GMRP GARP Multicast Registration Protocol 158 IGMP Internet Group Management Protocol 159 MBGP Multi-protocol BGP (*not* "Multicast BGP") 160 MLD Multicast Listener Discovery 161 MMRP (IEEE 802.1ak) Multicast Multiple Registration Protocol 162 MOSPF Multicast OSPF 163 MSDP Multicast Source Discovery Protocol 164 PGM Pragmatic General Multicast 165 PIM Protocol Independent Multicast 166 PIM-DM PIM - Dense Mode 167 PIM-SM PIM - Sparse Mode 168 PIM-SSM PIM - Source-Specific Multicast 169 RGMP (Cisco's) Router Group Management Protocol 170 RP Rendezvous Point 171 SSM Source-specific Multicast 173 2. Multicast Routing 175 In order to give a simplified summary how each of these class of 176 mechanisms fits together, consider the following multicast receiver 177 scenario. 179 When a host wants to receive a transmission, it first needs to find 180 out the multicast group address (and with SSM, source address) using 181 unspecified means. Then it will signal its interest to its router 182 using IGMP or MLD (Section 2.6). To deliver a multicast 183 transmission, the router will need to know how to build the 184 distribution tree which includes all the sources (Section 2.3) and/or 185 to locate the RP (Section 2.4) or one of RPs (Section 2.5). In 186 scenarios where multicast is routed via different topology than 187 unicast, a means to distribute topology information is required 188 (Section 2.2). Nonetheless, using whatever topology information is 189 available, the first-hop router initiates setting up hop-by-hop 190 multicast forwarding state (Section 2.1). When multicast 191 transmission arrives at the receiver's LAN, it is flooded to every 192 port unless flooding reduction such as IGMP snooping is employed 193 (Section 2.7). 195 2.1. Setting up Multicast Forwarding State 197 The most important part of multicast routing is setting up the 198 multicast forwarding state. This section describes the protocols 199 commonly used for this purpose. 201 2.1.1. PIM-SM 203 By far, the most common multicast routing protocol is PIM-SM 204 [I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any 205 Source Multicast (ASM) and Source-Specific Multicast (SSM) 206 functionality; PIM-SSM is a subset of PIM-SM. Most current routing 207 platforms support PIM-SM. 209 2.1.2. PIM-DM 211 Whereas PIM-SM has been designed to avoid unnecessary flooding of 212 multicast data, PIM-DM [RFC3973] assumed that almost every subnet at 213 a site had at least one receiver for a group. PIM-DM floods 214 multicast transmissions throughout the network ("flood and prune") 215 unless the leaf parts of the network periodically indicate that they 216 are not interested in that particular group. 218 PIM-DM may be an acceptable fit in small and/or simple networks, 219 where setting up an RP would be unnecessary, and possibly in cases 220 where a large percentage of users is expected to want to receive the 221 transmission so that the amount of state the network has to keep is 222 minimal. 224 PIM-DM was used as a first step in transitioning away from DVMRP. It 225 also became apparent that most networks would not have receivers for 226 most groups, and to avoid the bandwidth and state overhead, the 227 flooding paradigm was gradually abandoned. Transitioning from PIM-DM 228 to PIM-SM was easy as PIM-SM was designed to use compatible packet 229 formats and dense-mode operation could also be satisfied by a sparse 230 protocol. PIM-DM is no longer in widespread use. 232 Many implementations also support so-called "sparse-dense" 233 configuration, where Sparse mode is used by default, but Dense is 234 used for configured multicast group ranges (such as Auto-RP in 235 Section 2.4.3) only. Lately, many networks have transitioned away 236 from sparse-dense to only sparse mode. 238 2.1.3. Bi-directional PIM 240 Bi-directional PIM [I-D.ietf-pim-bidir] is a multicast forwarding 241 protocol that establishes a common shared-path for all sources with a 242 single root. It can be used as an alternative to PIM-SM inside a 243 single domain. It doesn't have data-driven events or data- 244 encapsulation. As it doesn't keep source-specific state, it may be a 245 lucrative approach especially in sites with a large number of 246 sources. 248 As of this writing, there is no inter-domain solution to configure a 249 group range to use bi-directional PIM. 251 2.1.4. DVMRP 253 Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] 254 [I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first 255 protocol designed for multicasting, and to get around initial 256 deployment hurdles. It also included tunneling capabilities which 257 were part of its multicast topology functions. 259 Currently, DVMRP is used only very rarely in operator networks, 260 having been replaced with PIM-SM. The most typical deployment of 261 DVMRP is at a leaf network, to run from a legacy firewall only 262 supporting DVMRP to the internal network. However, GRE tunneling 263 [RFC2784] seems to have overtaken DVMRP in this functionality, and 264 there is relatively little use for DVMRP except in legacy 265 deployments. 267 2.1.5. MOSPF 269 MOSPF [RFC1584] was implemented by several vendors and has seen some 270 deployment in intra-domain networks. However, since it is based on 271 intra-domain OSPF it does not scale to the inter-domain case, 272 operators have found it is easier to deploy a single protocol for use 273 in both intra-domain and inter-domain networks and so it is no longer 274 being actively deployed. 276 2.1.6. BGMP 278 BGMP [RFC3913] did not get sufficient support within the service 279 provider community to get adopted and moved forward in the IETF 280 standards process. There were no reported production implementations 281 and no production deployments. 283 2.1.7. CBT 285 CBT [RFC2201] was an academic project that provided the basis for PIM 286 sparse mode shared trees. Once the shared tree functionality was 287 incorporated into PIM implementations, there was no longer a need for 288 a production CBT implemention. Therefore, CBT never saw production 289 deployment. 291 2.1.8. Interactions and Summary 293 It is worth noting that it is possible to run different protocols 294 with different multicast group ranges. For example, treat some 295 groups as dense or bi-dir in an otherwise PIM-SM network; this 296 typically requires manual configuration of the groups or a mechanism 297 like BSR (Section 2.4.3). It is also possible to interact between 298 different protocols, for example use DVMRP in the leaf network, but 299 PIM-SM upstream. The basics for interactions among different 300 protocols have been outlined in [RFC2715]. 302 The following figure gives a concise summary of the deployment status 303 of different protocols as of this writing. 305 +-------------+-------------+----------------+ 306 | Interdomain | Intradomain | Status | 307 +------------+-------------+-------------+----------------+ 308 | PIM-SM | Yes | Yes | Active | 309 | PIM-DM | Not anymore | Not anymore | Little use | 310 | Bi-dir PIM | No | Yes | Some uptake | 311 | DVMRP | Not anymore | Stub only | Going out | 312 | MOSPF | No | Not anymore | Inactive | 313 | CBT | No | No | Never deployed | 314 | BGMP | No | No | Never deployed | 315 +------------+-------------+-------------+----------------+ 317 From this table, it is clear that PIM-Sparse Mode is the only 318 multicast routing protocol that is deployed inter-domain and, 319 therefore, is most frequently used within multicast domains as well. 320 This is partially result of not working on inter-domain RP/group 321 configuration mechanisms since PIM-SM and MSDP (Section 2.3.2). 323 2.2. Distributing Topology Information 325 PIM has become the de-facto multicast forwarding protocol, but as its 326 name implies, it is independent of the underlying unicast routing 327 protocol. When unicast and multicast topologies are the same 328 ("congruent"), i.e., use the same routing tables (routing information 329 base, RIB), it has been considered sufficient just to distribute one 330 set of reachability information to be used in conjunction with a 331 protocol that sets up multicast forwarding state (e.g., PIM-SM). 333 However, when PIM which by default built multicast topology based on 334 the unicast topology gained popularity, it became apparent that it 335 would be necessary to be able to distribute also non-congruent 336 multicast reachability information in the regular unicast protocols. 337 This was previously not an issue, because DVMRP built its own 338 reachability information. 340 The topology information is needed to perform efficient distribution 341 of multicast transmissions and to prevent transmission loops by 342 applying it to the Reverse Path Forwarding (RPF) check. 344 This subsection introduces these protocols. 346 2.2.1. Multi-protocol BGP 348 Multiprotocol Extensions for BGP-4 [I-D.ietf-idr-rfc2858bis] (often 349 referred to as "MBGP"; however, it is worth noting that "MBGP" does 350 *not* stand for "Multicast BGP") specifies a mechanism by which BGP 351 can be used to distribute different reachability information for 352 unicast (SAFI=1) and multicast traffic (SAFI=2). Multiprotocol BGP 353 has been widely deployed for years, and is also needed to route IPv6. 354 Note that SAFI=3 was originally specified for "both unicast and 355 multicast" but has since then been deprecated. 357 These extensions are in widespread use wherever BGP is used to 358 distribute unicast topology information. Multicast-enabled networks 359 that use BGP should use Multiprotocol BGP to distribute multicast 360 reachability information explicitly even if the topologies are 361 congruent to make an explicit statement about multicast reachability. 362 A number of significant multicast transit providers even require 363 this, by doing the RPF lookups solely based on explicitly advertised 364 multicast address family. 366 2.2.2. OSPF/IS-IS Multi-topology Extensions 368 Similar to BGP, some IGPs also provide the capability for signalling 369 a differing topologies, for example IS-IS multi-topology extensions 370 [I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast 371 topology that differs from unicast. Similar but not so widely 372 implemented work exists for OSPF [I-D.ietf-ospf-mt]. 374 It is worth noting that interdomain incongruence and intradomain 375 incongruence are orthogonal, so one doesn't require the other. 376 Specifically, interdomain incongruence is quite common, while 377 intradomain incongruence isn't, so you see much more deployment of 378 MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well 379 without protocols handling intradomain incongruence. However, the 380 availability of multi-topology mechanisms may in part replace the 381 typically used workarounds such as tunnels. 383 2.2.3. Issue: Overlapping Unicast/multicast Topology 385 An interesting case occurs when some routers do not distribute 386 multicast topology information explicitly while others do. In 387 particular, this happens when some multicast sites in the Internet 388 are using plain BGP while some use MBGP. 390 Different implementations deal with this in different ways. 391 Sometimes, multicast RPF mechanisms first look up the multicast 392 routing table, or M-RIB ("topology database") with a longest prefix 393 match algorithm, and if they find any entry (including a default 394 route), that is used; if no match is found, the unicast routing table 395 is used instead. 397 An alternative approach is to use longest prefix match on the union 398 of multicast and unicast routing tables; an implementation technique 399 here is to copy the whole unicast routing table over to the multicast 400 routing table. The important point to remember here, though, is to 401 not override the multicast-only routes; if the longest prefix match 402 would find both a (copied) unicast route and a multicast-only route, 403 the latter should be treated as preferable. 405 Another implemented approach is to just look up the information in 406 the unicast routing table, and provide the user capabilities to 407 change that as appropriate, using for example copying functions 408 discussed above. 410 2.2.4. Summary 412 The following table summarizes the topology distribution approaches 413 described in this Section. In particular, it is recommended that if 414 interdomain routing uses BGP, multicast-enabled sites should use MP- 415 BGP SAFI=2 for multicast and SAFI=1 for unicast even if the topology 416 was congruent. 418 +-------------+---------------+ 419 | Interdomain | Intradomain | 420 +--------------------- +--------------+--------------+ 421 | Congruent topology | Yes | Yes | 422 | BGP without SAFI | Not recomm. | Yes | 423 | MP-BGP SAFI=1 only | Not recomm. | Not recomm. | 424 | MP-BGP SAFI=2 | Recommended | Yes | 425 | MP-BGP SAFI=3 | Doesn't work | Doesn't work | 426 | IS-IS multi-topology | No | Yes | 427 | OSPF multi-topology | No | Few implem. | 428 +----------------------+--------------+--------------+ 430 2.3. Learning (Active) Sources 432 Typically, multicast routing protocols must either assume that the 433 receivers know the IP addresses of the (active) sources for a group 434 in advance, possibly using an out-of-band mechanism (SSM), or the 435 transmissions are forwarded to the receivers automatically (ASM). 437 Learning active sources is a relatively straightforward process with 438 a single PIM-SM domain and with a single RP, but having a single 439 PIM-SM domain for the whole Internet is a completely unscalable model 440 for many reasons. Therefore it is required to be able to split up 441 the multicast routing infrastructures to smaller domains, and there 442 must be a way to share information about active sources using some 443 mechanism if the ASM model is to be supported. 445 This section discusses the options. 447 2.3.1. SSM 449 Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also 450 referred to as "single-source Multicast") does not count on learning 451 active sources in the network. Recipients need to know the source IP 452 addresses using an out of band mechanism which are used to subscribe 453 to the (source, group) channel. The multicast routing uses the 454 source address to set up the state and no further source discovery is 455 needed. 457 As of this writing, there are attempts to analyze and/or define out- 458 of-band source discovery functions which would help SSM in particular 459 [I-D.lehtonen-mboned-dynssm-req]. 461 2.3.2. MSDP 463 Multicast Source Discovery Protocol [RFC3618] was invented as a stop- 464 gap mechanism, when it became apparent that multiple PIM-SM domains 465 (and RPs) were needed in the network, and information about the 466 active sources needed to be propagated between the PIM-SM domains 467 using some other protocol. 469 MSDP is also used to share the state about sources between multiple 470 RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The 471 same can be achieved using PIM extensions [I-D.ietf-pim-anycast-rp]. 472 See Section 2.5 for more information. 474 There is no intent to define MSDP for IPv6, but instead use only SSM 475 and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. 477 2.3.3. Embedded-RP 479 Embedded-RP [RFC3956] is an IPv6-only technique to map the address of 480 the RP to the multicast group address. Using this method, it is 481 possible to avoid the use of MSDP while still allowing multiple 482 multicast domains (in the traditional sense). 484 The model works by defining a single RP address for a particular 485 group for all of the Internet, so there is no need to share state 486 about that with any other RPs. If necessary, RP redundancy can still 487 be achieved with Anycast-RP using PIM. 489 2.3.4. Summary 491 The following table summarizes the source discovery approaches and 492 their status. 494 +------+------+------------------------------+ 495 | IPv4 | IPv6 | Status | 496 +----------------------+------+------+------------------------------+ 497 | Bi-dir single domain | Yes | Yes | OK but for intra-domain only | 498 | PIM-SM single domain | Yes | Yes | OK | 499 | PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM | 500 | PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option | 501 | SSM | Yes | Yes | No major uptake yet | 502 +----------------------+------+------+------------------------------+ 504 2.4. Configuring and Distributing PIM RP Information 506 PIM-SM and Bi-dir PIM configuration mechanisms exist which are used 507 to configure the RP addresses and which groups are to use those RPs 508 in the routers. This section outlines the approaches. 510 2.4.1. Manual RP Configuration 512 It is often easiest just to manually configure the RP information on 513 the routers when PIM-SM is used. 515 Originally, static RP mapping was considered suboptimal since it 516 required explicit configuration changes every time the RP address 517 changed. However, with the advent of anycast RP addressing, the RP 518 address is unlikely to ever change. Therefore, the administrative 519 burden is generally limited to initial configuration. Since there is 520 usually a fair amount of multicast configuration required on all 521 routers anyway (eg, PIM on all interfaces), adding the RP address 522 statically isn't really an issue. Further, static anycast RP mapping 523 provides the benefits of RP load sharing and redundancy (see 524 Section 2.5) without the complexity found in dynamic mechanisms like 525 Auto-RP and Bootstrap Router (BSR). 527 With such design, an anycast RP uses an address that is configured on 528 a loopback interfaces of the routers currently acting as RPs, and 529 state is distributed using PIM [I-D.ietf-pim-anycast-rp] or MSDP 530 [RFC3446]. 532 Using this technique, each router might only need to be configured 533 with one, portable RP address. 535 2.4.2. Embedded-RP 537 Embedded-RP provides the information about the RP's address in the 538 group addresses which are delegated to those who use the RP, so 539 unless no other ASM than Embedded-RP is used, the network 540 administrator only needs to configure the RP routers. 542 While Embedded-RP in many cases is sufficient for IPv6, other methods 543 of RP configuration are needed if one needs to provide ASM service 544 for other than Embedded-RP group addresses. In particular, service 545 discovery type of applications may need hard-coded addresses that are 546 not dependent on local RP addresses. 548 As the RP's address is exposed to the users and applications, it is 549 very important to ensure it does not change often, e.g., by using 550 manual configuration of an anycast address. 552 2.4.3. BSR and Auto-RP 554 BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP 555 address for groups. It may no longer be in as wide use with IPv4 as 556 it was ealier, and for IPv6, Embedded-RP will in many cases be 557 sufficient. 559 Cisco's Auto-RP is an older, proprietary method for distributing 560 group to RP mappings, similar to BSR. Auto-RP has little use today. 562 Both Auto-RP and BSR require some form of control at the routers to 563 ensure that only valid routers are able to advertise themselves as 564 RPs. Further, flooding of BSR and Auto-RP messages must be prevented 565 at PIM borders. Additionally, routers require monitoring that they 566 are actually using the RP(s) the administrators think they should be 567 using, for example if a router (maybe in customer's control) is 568 advertising itself inappropriately. All in all, while BSR and 569 Auto-RP provide easy configuration, they also provide very 570 significant configuration and management complexity. 572 It is worth noting that both Auto-RP and BSR were deployed before the 573 use of a manually configured anycast-RP address became relatively 574 commonplace, and there is actually relatively little need for them 575 today unless there is a need to configure different properties (e.g., 576 sparse, dense, bi-dir) in a dynamic fashion. 578 2.4.4. Summary 580 The following table summarizes the RP discovery mechanisms and their 581 status. With the exception of Embedded-RP, each mechanism operates 582 within a PIM domain. 584 +------+------+-----------------------+ 585 | IPv4 | IPv6 | Deployment | 586 +--------------------+------+------+-----------------------+ 587 | Static RP | Yes | Yes | Especially in ISPs | 588 | Auto-RP | Yes | No | Legacy deployment | 589 | BSR | Yes | Yes | Some, anycast simpler | 590 | Embedded-RP | No | Yes | Growing | 591 +--------------------+------+------+-----------------------+ 593 2.5. Mechanisms for Enhanced Redundancy 595 A couple of mechanisms, already described in this document, have been 596 used as a means to enhance redundancy, resilience against failures, 597 and to recover from failures quickly. This section summarizes these 598 techniques explicitly. 600 2.5.1. Anycast RP 602 As mentioned in Section 2.3.2, MSDP is also used to share the state 603 about sources between multiple RPs in a single domain for, e.g., 604 redundancy purposes [RFC3446]. The purpose of MSDP in this context 605 is to share the same state information on multiple RPs for the same 606 groups to enhance the robustness of the service. 608 Recent PIM extensions [I-D.ietf-pim-anycast-rp] also provide this 609 functionality. In contrast to MSDP, this approach works for both 610 IPv4 and IPv6. 612 2.5.2. Stateless RP Failover 614 It is also possible to use some mechanisms for smaller amount of 615 redundancy as Anycast RP, without sharing state between the RPs. A 616 traditional mechanism has been to use Auto-RP or BSR (see 617 Section 2.4.3) to select another RP when the active one failed. 618 However, the same functionality could be achieved using a shared- 619 unicast RP address ("anycast RP without state sharing") without the 620 complexity of a dynamic mechanism. Further, Anycast RP offers a 621 significantly more extensive failure mitigation strategy, so today 622 there is actually very little need to use stateless failover 623 mechanisms, especially dynamic ones, for redundancy purposes. 625 2.5.3. Bi-directional PIM 627 Because bi-directional PIM (see Section 2.1.3) does not switch to 628 shortest path tree (SPT), the final multicast tree is may be 629 established faster. On the other hand, PIM-SM or SSM may converge 630 more quickly especially in scenarios (e.g., unicast routing change) 631 where bi-directional needs to re-do the Designated Forwarder 632 election. 634 2.5.4. Summary 636 The following table summarizes the techniques for enhanced 637 redundancy. 639 +------+------+-----------------------+ 640 | IPv4 | IPv6 | Deployment | 641 +--------------------+------+------+-----------------------+ 642 | Anycast RP w/ MSDP | Yes | No | De-facto approach | 643 | Anycast RP w/ PIM | Yes | Yes | New, simpler than MSDP| 644 | Stateless RP fail. | Yes | Yes | Causes disturbance | 645 | Bi-dir PIM | Yes | Yes | Deployed at some sites| 646 +-------------+------+------+------------------------------+ 648 2.6. Interactions with Hosts 650 Previous sections have dealt with the components required by routers 651 to be able to do multicast routing. Obviously, the real users of 652 multicast are the hosts: either sending or receiving multicast. This 653 section describes the required interactions with hosts. 655 2.6.1. Hosts Sending Multicast 657 After choosing a multicast group through a variety of means, hosts 658 just send the packets to the link-layer multicast address, and the 659 designated router will receive all the multicast packets and start 660 forwarding them as appropriate. 662 In intra-domain or Embedded-RP scenarios, ASM senders may move to a 663 new IP address without significant impact on the delivery of their 664 transmission. SSM senders cannot change the IP address unless 665 receivers join the new channel or the sender uses an IP mobility 666 technique that is transparent to the receivers. 668 2.6.2. Hosts Receiving Multicast 670 Hosts signal their interest in receiving a multicast group or channel 671 by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are 672 still commonplace, but are also often used in new deployments. Some 673 vendors also support SSM mapping techniques for receivers which use 674 an older IGMP/MLD version where the router maps the join request to 675 an SSM channel based on various, usually complex means of 676 configuration. 678 2.6.3. Summary 680 The following table summarizes the techniques host interaction. 682 +-------+------+----------------------+ 683 | IPv4 | IPv6 | Notes | 684 +--------------------+-------+------+----------------------+ 685 | Host sending | Yes | Yes | No support needed | 686 | Host receiving ASM | IGMP | MLD | Any IGMP/MLD version | 687 | Host receiving SSM | IGMPv3| MLDv2| Also SSM-mapping | 688 +--------------------+-------+------+----------------------+ 690 2.7. Restricting Multicast Flooding in the Link Layer 692 Multicast transmission in the link layer, for example Ethernet, 693 typically includes some form of flooding the packets through a LAN. 694 This causes unnecessary bandwidth usage and discarding unwanted 695 frames on those nodes which did not want to receive the multicast 696 transmission. 698 Therefore a number of techniques have been developed, to be used in 699 Ethernet switches between routers, or between routers and hosts, to 700 limit the flooding. 702 These options are discussed in this section. 704 2.7.1. Router-to-Router Flooding Reduction 706 A proprietary solution, Cisco's RGMP [RFC3488] has been developed to 707 reduce the amount of flooding between routers in a switched networks. 708 This is typically only considered a problem in some Ethernet-based 709 Internet Exchange points or VPNs. 711 There have been proposals to observe and possibly react ("snoop") PIM 712 messages [I-D.ietf-l2vpn-vpls-pim-snooping]. 714 2.7.2. Host/Router Flooding Reduction 716 There are a number of techniques to help reduce flooding both from a 717 router to hosts, and from a host to the routers (and other hosts). 719 Cisco's proprietary CGMP [CGMP] provides a solution where the routers 720 notify the switches, but also allows the switches to snoop IGMP 721 packets to enable faster notification of hosts no longer wishing to 722 receive a group. IPv6 is not supported. 724 IEEE 802.1D-2004 specification describes Generic Attribute 725 Registration Protocol (GARP), and GARP Multicast Registration 726 Protocol (GMRP) [GMRP] is a link-layer multicast group application of 727 GARP that notifies switches about IP multicast group memberships. 728 GMRP requires support at the host stack and it has not been widely 729 implemented. Further, IEEE considers GMRP obsolete having been 730 replaced by Multicast Multiple Registration Protocol (MMRP) that's 731 being specified in IEEE 802.1ak [802.1ak]. MMRP is expected to be 732 mainly used between bridges. Some further information about GARP/ 733 GMRP is also available in Appendix B of [RFC3488]. 735 IGMP snooping [RFC4541] appears to be the most widely implemented 736 technique. IGMP snooping requires that the switches implement a 737 significant amount of IP-level packet inspection; this appears to be 738 something that is difficult to get right, and often the upgrades are 739 also a challenge. 741 Snooping switches also need to identify the ports where routers 742 reside and therefore where to flood the packets. This can be 743 accomplished using Multicast Router Discovery protocol [RFC4286], 744 looking at certain IGMP queries [RFC4541], looking at PIM Hello and 745 possibly other messages, or by manual configuration. An issue with 746 PIM snooping at LANs is that PIM messages can't be turned off or 747 encrypted, leading to security issues 748 [I-D.savola-pim-lasthop-threats]. 750 IGMP proxying [I-D.ietf-magma-igmp-proxy] is sometimes used either as 751 a replacement of a multicast routing protocol on a small router, or 752 to aggregate IGMP/MLD reports when used with IGMP snooping. 754 2.7.3. Summary 756 The following table summarizes the techniques for multicast flooding 757 reduction inside a single link for router-to-router and last-hop 758 LANs. 760 +--------+-----+---------------------------+ 761 | R-to-R | LAN | Notes | 762 +-----------------------+--------+-----+---------------------------+ 763 | Cisco's RGMP | Yes | No | Replaced by PIM snooping | 764 | PIM snooping | Yes | No | Security issues in LANs | 765 | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD bad | 766 | Multicast Router Disc | No | Yes | Few if any implem. yet | 767 | IEEE GMRP and MMRP | No | No | No host/router deployment | 768 | Cisco's CGMP | No | Yes | Replaced by other snooping| 769 +-----------------------+--------+-----+---------------------------+ 771 3. Acknowledgements 773 Tutoring a couple multicast-related papers, the latest by Kaarle 774 Ritvanen [RITVANEN] convinced the author that up-to-date multicast 775 routing and address assignment/allocation documentation is necessary. 777 Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, 778 Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat 779 Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon 780 Chisholm, and John Zwiebel provided good comments, helping in 781 improving this document. 783 4. IANA Considerations 785 This memo includes no request to IANA. 787 5. Security Considerations 789 This memo only describes different approaches to multicast routing, 790 and this has no security considerations; the security analysis of the 791 mentioned protocols is out of scope of this memo. 793 However, there has been analysis of the security of multicast routing 794 infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD 795 [I-D.daley-magma-smld-prob], and PIM last-hop issues 796 [I-D.savola-pim-lasthop-threats]. 798 6. References 800 6.1. Normative References 802 [I-D.ietf-idr-rfc2858bis] 803 Bates, T., "Multiprotocol Extensions for BGP-4", 804 draft-ietf-idr-rfc2858bis-10 (work in progress), 805 March 2006. 807 [I-D.ietf-isis-wg-multi-topology] 808 Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in 809 IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in 810 progress), October 2005. 812 [I-D.ietf-mboned-addrarch] 813 Savola, P., "Overview of the Internet Multicast Addressing 814 Architecture", draft-ietf-mboned-addrarch-04 (work in 815 progress), March 2006. 817 [I-D.ietf-ospf-mt] 818 Psenak, P., "Multi-Topology (MT) Routing in OSPF", 819 draft-ietf-ospf-mt-06 (work in progress), February 2006. 821 [I-D.ietf-pim-bidir] 822 Handley, M., "Bi-directional Protocol Independent 823 Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in 824 progress), October 2005. 826 [I-D.ietf-pim-sm-v2-new] 827 Fenner, B., "Protocol Independent Multicast - Sparse Mode 828 (PIM-SM): Protocol Specification (Revised)", 829 draft-ietf-pim-sm-v2-new-12 (work in progress), 830 March 2006. 832 [I-D.ietf-ssm-arch] 833 Holbrook, H. and B. Cain, "Source-Specific Multicast for 834 IP", draft-ietf-ssm-arch-07 (work in progress), 835 October 2005. 837 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 838 3", BCP 9, RFC 2026, October 1996. 840 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 841 Thyagarajan, "Internet Group Management Protocol, Version 842 3", RFC 3376, October 2002. 844 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 845 Protocol (MSDP)", RFC 3618, October 2003. 847 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 848 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 850 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 851 Point (RP) Address in an IPv6 Multicast Address", 852 RFC 3956, November 2004. 854 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 855 Independent Multicast - Dense Mode (PIM-DM): Protocol 856 Specification (Revised)", RFC 3973, January 2005. 858 6.2. Informative References 860 [802.1ak] "IEEE 802.1ak - Multiple Registration Protocol", 861 . 863 [CGMP] "Cisco Group Management Protocol", 864 . 866 [GMRP] "GARP Multicast Registration Protocol", 867 . 869 [I-D.daley-magma-smld-prob] 870 Daley, G. and G. Kurup, "Trust Models and Security in 871 Multicast Listener Discovery", 872 draft-daley-magma-smld-prob-00 (work in progress), 873 July 2004. 875 [I-D.ietf-idmr-dvmrp-v3] 876 Pusateri, T., "Distance Vector Multicast Routing 877 Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), 878 December 2003. 880 [I-D.ietf-idmr-dvmrp-v3-as] 881 Pusateri, T., "Distance Vector Multicast Routing Protocol 882 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 883 (work in progress), May 2004. 885 [I-D.ietf-l2vpn-vpls-pim-snooping] 886 Hemige, V., "PIM Snooping over VPLS", 887 draft-ietf-l2vpn-vpls-pim-snooping-00 (work in progress), 888 August 2006. 890 [I-D.ietf-magma-igmp-proxy] 891 Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ 892 MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", 893 draft-ietf-magma-igmp-proxy-06 (work in progress), 894 April 2004. 896 [I-D.ietf-mboned-ipv6-multicast-issues] 897 Savola, P., "IPv6 Multicast Deployment Issues", 898 draft-ietf-mboned-ipv6-multicast-issues-02 (work in 899 progress), February 2005. 901 [I-D.ietf-mboned-mroutesec] 902 Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast 903 Routing Security Issues and Enhancements", 904 draft-ietf-mboned-mroutesec-04 (work in progress), 905 October 2004. 907 [I-D.ietf-pim-anycast-rp] 908 Farinacci, D. and Y. Cai, "Anycast-RP using PIM", 909 draft-ietf-pim-anycast-rp-07 (work in progress), 910 February 2006. 912 [I-D.ietf-pim-sm-bsr] 913 Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", 914 draft-ietf-pim-sm-bsr-09 (work in progress), June 2006. 916 [I-D.lehtonen-mboned-dynssm-req] 917 Lehtonen, R., "Requirements for discovery of dynamic SSM 918 sources", draft-lehtonen-mboned-dynssm-req-00 (work in 919 progress), February 2005. 921 [I-D.savola-pim-lasthop-threats] 922 Lingard, J. and P. Savola, "Last-hop Threats to Protocol 923 Independent Multicast (PIM)", 924 draft-savola-pim-lasthop-threats-02 (work in progress), 925 June 2006. 927 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 928 Vector Multicast Routing Protocol", RFC 1075, 929 November 1988. 931 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 932 March 1994. 934 [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, 935 March 1994. 937 [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 938 Routing -- Protocol Specification --", RFC 2189, 939 September 1997. 941 [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing 942 Architecture", RFC 2201, September 1997. 944 [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing 945 Protocols", RFC 2715, October 1999. 947 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 948 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 949 March 2000. 951 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 952 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 953 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 954 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 955 Protocol Specification", RFC 3208, December 2001. 957 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 958 Rendevous Point (RP) mechanism using Protocol Independent 959 Multicast (PIM) and Multicast Source Discovery Protocol 960 (MSDP)", RFC 3446, January 2003. 962 [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group 963 Management Protocol (RGMP)", RFC 3488, February 2003. 965 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 966 Architecture", RFC 3740, March 2004. 968 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 969 Protocol Specification", RFC 3913, September 2004. 971 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 972 RFC 4286, December 2005. 974 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 975 "Considerations for Internet Group Management Protocol 976 (IGMP) and Multicast Listener Discovery (MLD) Snooping 977 Switches", RFC 4541, May 2006. 979 [RITVANEN] 980 Ritvanen, K., "Multicast Routing and Addressing", HUT 981 Report, Seminar on Internetworking, May 2004, 982 . 984 Appendix A. Multicast Payload Transport Extensions 986 A couple of mechanisms have been, and are being specified, to improve 987 the characteristics of the data that can be transported over 988 multicast. 990 These go beyond the scope of multicast routing, but as reliable 991 multicast has some relevance, these are briefly mentioned. 993 A.1. Reliable Multicast 995 Reliable Multicast Working Group has been working on experimental 996 specifications so that applications requiring reliable delivery 997 characteristics, instead of simple unreliable UDP, could use 998 multicast as a distribution mechanism. 1000 One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. 1001 This does not require support from the routers, bur PGM-aware routers 1002 may act in router assistance role in the initial delivery and 1003 potential retransmission of missing data. 1005 A.2. Multicast Group Security 1007 Multicast Security Working Group has been working on methods how the 1008 integrity, confidentiality, and authentication of data sent to 1009 multicast groups can be ensured using cryptographic techniques 1010 [RFC3740]. 1012 Author's Address 1014 Pekka Savola 1015 CSC - Scientific Computing Ltd. 1016 Espoo 1017 Finland 1019 Email: psavola@funet.fi 1021 Full Copyright Statement 1023 Copyright (C) The Internet Society (2006). 1025 This document is subject to the rights, licenses and restrictions 1026 contained in BCP 78, and except as set forth therein, the authors 1027 retain all their rights. 1029 This document and the information contained herein are provided on an 1030 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1031 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1032 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1033 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1034 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1035 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1037 Intellectual Property 1039 The IETF takes no position regarding the validity or scope of any 1040 Intellectual Property Rights or other rights that might be claimed to 1041 pertain to the implementation or use of the technology described in 1042 this document or the extent to which any license under such rights 1043 might or might not be available; nor does it represent that it has 1044 made any independent effort to identify any such rights. Information 1045 on the procedures with respect to rights in RFC documents can be 1046 found in BCP 78 and BCP 79. 1048 Copies of IPR disclosures made to the IETF Secretariat and any 1049 assurances of licenses to be made available, or the result of an 1050 attempt made to obtain a general license or permission for the use of 1051 such proprietary rights by implementers or users of this 1052 specification can be obtained from the IETF on-line IPR repository at 1053 http://www.ietf.org/ipr. 1055 The IETF invites any interested party to bring to its attention any 1056 copyrights, patents or patent applications, or other proprietary 1057 rights that may cover technology that may be required to implement 1058 this standard. Please address the information to the IETF at 1059 ietf-ipr@ietf.org. 1061 Acknowledgment 1063 Funding for the RFC Editor function is provided by the IETF 1064 Administrative Support Activity (IASA).