idnits 2.17.1 draft-ietf-mboned-routingarch-05.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 1036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1060. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2006) is 6471 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 Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'I-D.ietf-idmr-dvmrp-v3') == 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 ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Downref: Normative reference to an Experimental RFC: RFC 3973 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-09 Summary: 8 errors (**), 0 flaws (~~), 6 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: July 11, 2006 5 3913,2189,2201,1584,1585 (if 6 approved) 7 Intended status: Best Current 8 Practice 9 Expires: January 12, 2007 11 Overview of the Internet Multicast Routing Architecture 12 draft-ietf-mboned-routingarch-05.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 January 12, 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 Configuration with an Anycast Address . . . . . 12 76 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 77 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13 78 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 19 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 MOSPF Multicast OSPF 162 MSDP Multicast Source Discovery Protocol 163 PGM Pragmatic General Multicast 164 PIM Protocol Independent Multicast 165 PIM-DM PIM - Dense Mode 166 PIM-SM PIM - Sparse Mode 167 PIM-SSM PIM - Source-Specific Multicast 168 RGMP (Cisco's) Router Group Management Protocol 169 RP Rendezvous Point 170 SSM Source-specific Multicast 172 2. Multicast Routing 174 In order to give a simplified summary how each of these class of 175 mechanisms fits together, consider the following multicast receiver 176 scenario. 178 When a host wants to receive a transmission, it first needs to find 179 out the multicast group address (and with SSM, source address) using 180 unspecified means. Then it will signal its interest to its router 181 using IGMP or MLD (Section 2.6). To deliver a multicast 182 transmission, the router will need to know how to build the 183 distribution tree which includes all the sources (Section 2.3) and/or 184 to locate the RP (Section 2.4) or one of RPs (Section 2.5). In 185 scenarios where multicast is routed via different topology than 186 unicast, a means to distribute topology information is required 187 (Section 2.2). Nonetheless, using whatever topology information is 188 available, the first-hop router initiates setting up hop-by-hop 189 multicast forwarding state (Section 2.1). When multicast 190 transmission arrives at the receiver's LAN, it is flooded to every 191 port unless flooding reduction such as IGMP snooping is employed 192 (Section 2.7). 194 2.1. Setting up Multicast Forwarding State 196 The most important part of multicast routing is setting up the 197 multicast forwarding state. This section describes the protocols 198 commonly used for this purpose. 200 2.1.1. PIM-SM 202 By far, the most common multicast routing protocol is PIM-SM 203 [I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any 204 Source Multicast (ASM) and Source-Specific Multicast (SSM) 205 functionality; PIM-SSM is a subset of PIM-SM. Most current routing 206 platforms support PIM-SM. 208 2.1.2. PIM-DM 210 Whereas PIM-SM has been designed to avoid unnecessary flooding of 211 multicast data, PIM-DM [RFC3973] assumed that almost every subnet at 212 a site had at least one receiver for a group. PIM-DM floods 213 multicast transmissions throughout the network ("flood and prune") 214 unless the leaf parts of the network periodically indicate that they 215 are not interested in that particular group. 217 PIM-DM may be an acceptable fit in small and/or simple networks, 218 where setting up an RP would be unnecessary, and possibly in cases 219 where a large percentage of users is expected to want to receive the 220 transmission so that the amount of state the network has to keep is 221 minimal. 223 PIM-DM was used as a first step in transitioning away from DVMRP. It 224 also became apparent that most networks would not have receivers for 225 most groups, and to avoid the bandwidth and state overhead, the 226 flooding paradigm was gradually abandoned. Transitioning from PIM-DM 227 to PIM-SM was easy as PIM-SM was designed to use compatible packet 228 formats and dense-mode operation could also be satisfied by a sparse 229 protocol. PIM-DM is no longer in widespread use. 231 Many implementations also support so-called "sparse-dense" 232 configuration, where Sparse mode is used by default, but Dense is 233 used for configured multicast group ranges (such as Auto-RP in 234 Section 2.4.3) only. Lately, many networks have transitioned away 235 from sparse-dense to only sparse mode. 237 2.1.3. Bi-directional PIM 239 Bi-directional PIM [I-D.ietf-pim-bidir] is a multicast forwarding 240 protocol that establishes a common shared-path for all sources with a 241 single root. It can be used as an alternative to PIM-SM inside a 242 single domain. It doesn't have data-driven events or data- 243 encapsulation. As it doesn't keep source-specific state, it may be a 244 lucrative approach especially in sites with a large number of 245 sources. 247 As of this writing, there is no inter-domain solution to configure a 248 group range to use bi-directional PIM. 250 2.1.4. DVMRP 252 Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] 253 [I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first 254 protocol designed for multicasting, and to get around initial 255 deployment hurdles. It also included tunneling capabilities which 256 were part of its multicast topology functions. 258 Currently, DVMRP is used only very rarely in operator networks, 259 having been replaced with PIM-SM. The most typical deployment of 260 DVMRP is at a leaf network, to run from a legacy firewall only 261 supporting DVMRP to the internal network. However, GRE tunneling 262 [RFC2784] seems to have overtaken DVMRP in this functionality, and 263 there is relatively little use for DVMRP except in legacy 264 deployments. 266 2.1.5. MOSPF 268 MOSPF [RFC1584] was implemented by several vendors and has seen some 269 deployment in intra-domain networks. However, since it is based on 270 intra-domain OSPF it does not scale to the inter-domain case, 271 operators have found it is easier to deploy a single protocol for use 272 in both intra-domain and inter-domain networks and so it is no longer 273 being actively deployed. 275 2.1.6. BGMP 277 BGMP [RFC3913] did not get sufficient support within the service 278 provider community to get adopted and moved forward in the IETF 279 standards process. There were no reported production implementations 280 and no production deployments. 282 2.1.7. CBT 284 CBT [RFC2201] was an academic project that provided the basis for PIM 285 sparse mode shared trees. Once the shared tree functionality was 286 incorporated into PIM implementations, there was no longer a need for 287 a production CBT implemention. Therefore, CBT never saw production 288 deployment. 290 2.1.8. Interactions and Summary 292 It is worth noting that it is possible to run different protocols 293 with different multicast group ranges. For example, treat some 294 groups as dense or bi-dir in an otherwise PIM-SM network; this 295 typically requires manual configuration of the groups or a mechanism 296 like BSR (Section 2.4.3). It is also possible to interact between 297 different protocols, for example use DVMRP in the leaf network, but 298 PIM-SM upstream. The basics for interactions among different 299 protocols have been outlined in [RFC2715]. 301 The following figure gives a concise summary of the deployment status 302 of different protocols as of this writing. 304 +-------------+-------------+----------------+ 305 | Interdomain | Intradomain | Status | 306 +------------+-------------+-------------+----------------+ 307 | PIM-SM | Yes | Yes | Active | 308 | PIM-DM | Not anymore | Not anymore | Little use | 309 | Bi-dir PIM | No | Yes | Some uptake | 310 | DVMRP | Not anymore | Stub only | Going out | 311 | MOSPF | No | Not anymore | Inactive | 312 | CBT | No | No | Never deployed | 313 | BGMP | No | No | Never deployed | 314 +------------+-------------+-------------+----------------+ 316 From this table, it is clear that PIM-Sparse Mode is the only 317 multicast routing protocol that is deployed inter-domain and, 318 therefore, is most frequently used within multicast domains as well. 319 This is partially result of not working on inter-domain RP/group 320 configuration mechanisms since PIM-SM and MSDP (Section 2.3.2). 322 2.2. Distributing Topology Information 324 PIM has become the de-facto multicast forwarding protocol, but as its 325 name implies, it is independent of the underlying unicast routing 326 protocol. When unicast and multicast topologies are the same 327 ("congruent"), i.e., use the same routing tables (routing information 328 base, RIB), it has been considered sufficient just to distribute one 329 set of reachability information to be used in conjunction with a 330 protocol that sets up multicast forwarding state (e.g., PIM-SM). 332 However, when PIM which by default built multicast topology based on 333 the unicast topology gained popularity, it became apparent that it 334 would be necessary to be able to distribute also non-congruent 335 multicast reachability information in the regular unicast protocols. 336 This was previously not an issue, because DVMRP built its own 337 reachability information. 339 The topology information is needed to perform efficient distribution 340 of multicast transmissions and to prevent transmission loops by 341 applying it to the Reverse Path Forwarding (RPF) check. 343 This subsection introduces these protocols. 345 2.2.1. Multi-protocol BGP 347 Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as 348 "MBGP"; however, it is worth noting that "MBGP" does *not* stand for 349 "Multicast BGP") specifies a mechanism by which BGP can be used to 350 distribute different reachability information for unicast and 351 multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP 352 has been widely deployed for years, and is also needed to route IPv6. 353 Note that SAFI=3 was originally specified for "both unicast and 354 multicast" but has been deprecated [I-D.ietf-idr-rfc2858bis]. 356 These extensions are in widespread use wherever BGP is used to 357 distribute unicast topology information. Multicast-enabled networks 358 that use BGP should use Multiprotocol BGP to distribute multicast 359 reachability information explicitly even if the topologies are 360 congruent to make an explicit statement about multicast reachability. 361 A number of significant multicast transit providers even require 362 this, by doing the RPF lookups solely based on explicitly advertised 363 multicast address family. 365 2.2.2. OSPF/IS-IS Multi-topology Extensions 367 Similar to BGP, some IGPs also provide the capability for signalling 368 a differing topologies, for example IS-IS multi-topology extensions 369 [I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast 370 topology that differs from unicast. Similar but not so widely 371 implemented work exists for OSPF [I-D.ietf-ospf-mt]. 373 It is worth noting that interdomain incongruence and intradomain 374 incongruence are orthogonal, so one doesn't require the other. 375 Specifically, interdomain incongruence is quite common, while 376 intradomain incongruence isn't, so you see much more deployment of 377 MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well 378 without protocols handling intradomain incongruence. However, the 379 availability of multi-topology mechanisms may in part replace the 380 typically used workarounds such as tunnels. 382 2.2.3. Issue: Overlapping Unicast/multicast Topology 384 An interesting case occurs when some routers do not distribute 385 multicast topology information explicitly while others do. In 386 particular, this happens when some multicast sites in the Internet 387 are using plain BGP while some use MBGP. 389 Different implementations deal with this in different ways. 390 Sometimes, multicast RPF mechanisms first look up the multicast 391 routing table, or M-RIB ("topology database") with a longest prefix 392 match algorithm, and if they find any entry (including a default 393 route), that is used; if no match is found, the unicast routing table 394 is used instead. 396 An alternative approach is to use longest prefix match on the union 397 of multicast and unicast routing tables; an implementation technique 398 here is to copy the whole unicast routing table over to the multicast 399 routing table. The important point to remember here, though, is to 400 not override the multicast-only routes; if the longest prefix match 401 would find both a (copied) unicast route and a multicast-only route, 402 the latter should be treated as preferable. 404 Another implemented approach is to just look up the information in 405 the unicast routing table, and provide the user capabilities to 406 change that as appropriate, using for example copying functions 407 discussed above. 409 2.2.4. Summary 411 The following table summarizes the topology distribution approaches 412 described in this Section. In particular, it is recommended that if 413 interdomain routing uses BGP, multicast-enabled sites should use MP- 414 BGP SAFI=1+2 even if the topology were congruent. 416 +-------------+---------------+ 417 | Interdomain | Intradomain | 418 +--------------------- +--------------+--------------+ 419 | Congruent topology | Yes | Yes | 420 | BGP without SAFI | Not recomm. | Yes | 421 | MP-BGP SAFI=1+2 | Recommended | Yes | 422 | MP-BGP SAFI=3 | Doesn't work | Doesn't work | 423 | IS-IS multi-topology | No | Yes | 424 | OSPF multi-topology | No | Few implem. | 425 +----------------------+--------------+--------------+ 427 2.3. Learning (Active) Sources 429 Typically, multicast routing protocols must either assume that the 430 receivers know the IP addresses of the (active) sources for a group 431 in advance, possibly using an out-of-band mechanism (SSM), or the 432 transmissions are forwarded to the receivers automatically (ASM). 434 Learning active sources is a relatively straightforward process with 435 a single PIM-SM domain and with a single RP, but having a single 436 PIM-SM domain for the whole Internet is a completely unscalable model 437 for many reasons. Therefore it is required to be able to split up 438 the multicast routing infrastructures to smaller domains, and there 439 must be a way to share information about active sources using some 440 mechanism if the ASM model is to be supported. 442 This section discusses the options. 444 2.3.1. SSM 446 Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also 447 referred to as "single-source Multicast") does not count on learning 448 active sources in the network. Recipients need to know the source IP 449 addresses using an out of band mechanism which are used to subscribe 450 to the (source, group) channel. The multicast routing uses the 451 source address to set up the state and no further source discovery is 452 needed. 454 As of this writing, there are attempts to analyze and/or define out- 455 of-band source discovery functions which would help SSM in particular 456 [I-D.lehtonen-mboned-dynssm-req]. 458 2.3.2. MSDP 460 Multicast Source Discovery Protocol [RFC3618] was invented as a stop- 461 gap mechanism, when it became apparent that multiple PIM-SM domains 462 (and RPs) were needed in the network, and information about the 463 active sources needed to be propagated between the PIM-SM domains 464 using some other protocol. 466 MSDP is also used to share the state about sources between multiple 467 RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The 468 same can be achieved using PIM extensions [I-D.ietf-pim-anycast-rp]. 469 See Section 2.5 for more information. 471 There is no intent to define MSDP for IPv6, but instead use only SSM 472 and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. 474 2.3.3. Embedded-RP 476 Embedded-RP [RFC3956] is an IPv6-only technique to map the address of 477 the RP to the multicast group address. Using this method, it is 478 possible to avoid the use of MSDP while still allowing multiple 479 multicast domains (in the traditional sense). 481 The model works by defining a single RP address for a particular 482 group for all of the Internet, so there is no need to share state 483 about that with any other RPs. If necessary, RP redundancy can still 484 be achieved with Anycast-RP using PIM. 486 2.3.4. Summary 488 The following table summarizes the source discovery approaches and 489 their status. 491 +------+------+------------------------------+ 492 | IPv4 | IPv6 | Status | 493 +----------------------+------+------+------------------------------+ 494 | Bi-dir single domain | Yes | Yes | OK but for intra-domain only | 495 | PIM-SM single domain | Yes | Yes | OK | 496 | PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM | 497 | PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option | 498 | SSM | Yes | Yes | No major uptake yet | 499 +----------------------+------+------+------------------------------+ 501 2.4. Configuring and Distributing PIM RP Information 503 PIM-SM and Bi-dir PIM configuration mechanisms exist which are used 504 to configure the RP addresses and which groups are to use those RPs 505 in the routers. This section outlines the approaches. 507 2.4.1. Manual Configuration with an Anycast Address 509 It is often easiest just to manually configure the RP information on 510 the routers when PIM-SM is used. 512 Originally, static RP mapping was considered suboptimal since it 513 required explicit configuration changes every time the RP address 514 changed. However, with the advent of anycast RP addressing, the RP 515 address is unlikely to ever change. Therefore, the administrative 516 burden is generally limited to initial configuration. Since there is 517 usually a fair amount of multicast configuration required on all 518 routers anyway (eg, PIM on all interfaces), adding the RP address 519 statically isn't really an issue. Further, static anycast RP mapping 520 provides the benefits of RP load sharing and redundancy (see 521 Section 2.5) without the complexity found in dynamic mechanisms like 522 Auto-RP and Bootstrap Router (BSR). 524 With such design, an anycast RP uses an address that is configured on 525 a loopback interfaces of the routers currently acting as RPs, and 526 state is distributed using PIM [I-D.ietf-pim-anycast-rp] or MSDP 527 [RFC3446]. 529 Using this technique, each router might only need to be configured 530 with one, portable RP address. 532 2.4.2. Embedded-RP 534 Embedded-RP provides the information about the RP's address in the 535 group addresses which are delegated to those who use the RP, so 536 unless no other ASM than Embedded-RP is used, the network 537 administrator only needs to configure the RP routers. 539 While Embedded-RP in many cases is sufficient for IPv6, other methods 540 of RP configuration are needed if one needs to provide ASM service 541 for other than Embedded-RP group addresses. In particular, service 542 discovery type of applications may need hard-coded addresses that are 543 not dependent on local RP addresses. 545 As the RP's address is exposed to the users and applications, it is 546 very important to ensure it does not change often, e.g., by using 547 manual configuration of an anycast address. 549 2.4.3. BSR and Auto-RP 551 BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP 552 address for groups. It may no longer be in as wide use with IPv4 as 553 it was ealier, and for IPv6, Embedded-RP will in many cases be 554 sufficient. 556 Cisco's Auto-RP is an older, proprietary method for distributing 557 group to RP mappings, similar to BSR. Auto-RP has little use today. 559 Both Auto-RP and BSR require some form of control at the routers to 560 ensure that only valid routers are able to advertise themselves as 561 RPs. Further, flooding of BSR and Auto-RP messages must be prevented 562 at PIM borders. Additionally, routers require monitoring that they 563 are actually using the RP(s) the administrators think they should be 564 using, for example if a router (maybe in customer's control) is 565 advertising itself inappropriately. All in all, while BSR and 566 Auto-RP provide easy configuration, they also provide very 567 significant configuration and management complexity. 569 It is worth noting that both Auto-RP and BSR were deployed before the 570 use of a manually configured anycast-RP address became relatively 571 commonplace, and there is actually relatively little need for them 572 today unless there is a need to configure different properties (e.g., 573 sparse, dense, bi-dir) in a dynamic fashion. 575 2.4.4. Summary 577 The following table summarizes the RP discovery mechanisms and their 578 status. With the exception of Embedded-RP, each mechanism operates 579 within a PIM domain. 581 +------+------+-----------------------+ 582 | IPv4 | IPv6 | Deployment | 583 +--------------------+------+------+-----------------------+ 584 | Static RP | Yes | Yes | Especially in ISPs | 585 | Auto-RP | Yes | No | Legacy deployment | 586 | BSR | Yes | Yes | Some, anycast simpler | 587 | Embedded-RP | No | Yes | Growing | 588 +--------------------+------+------+-----------------------+ 590 2.5. Mechanisms for Enhanced Redundancy 592 A couple of mechanisms, already described in this document, have been 593 used as a means to enhance redundancy, resilience against failures, 594 and to recover from failures quickly. This section summarizes these 595 techniques explicitly. 597 2.5.1. Anycast RP 599 As mentioned in Section 2.3.2, MSDP is also used to share the state 600 about sources between multiple RPs in a single domain for, e.g., 601 redundancy purposes [RFC3446]. The purpose of MSDP in this context 602 is to share the same state information on multiple RPs for the same 603 groups to enhance the robustness of the service. 605 Recent PIM extensions [I-D.ietf-pim-anycast-rp] also provide this 606 functionality. In contrast to MSDP, this approach works for both 607 IPv4 and IPv6. 609 2.5.2. Stateless RP Failover 611 It is also possible to use some mechanisms for smaller amount of 612 redundancy as Anycast RP, without sharing state between the RPs. A 613 traditional mechanism has been to use Auto-RP or BSR (see 614 Section 2.4.3) to select another RP when the active one failed. 615 However, the same functionality could be achieved using a shared- 616 unicast RP address ("anycast RP without state sharing") without the 617 complexity of a dynamic mechanism. Further, Anycast RP offers a 618 significantly more extensive failure mitigation strategy, so today 619 there is actually very little need to use stateless failover 620 mechanisms, especially dynamic ones, for redundancy purposes. 622 2.5.3. Bi-directional PIM 624 Because bi-directional PIM (see Section 2.1.3) does not switch to 625 shortest path tree (SPT), the final multicast tree is may be 626 established faster. On the other hand, PIM-SM or SSM may converge 627 more quickly especially in scenarios (e.g., unicast routing change) 628 where bi-directional needs to re-do the Designated Forwarder 629 election. 631 2.5.4. Summary 633 The following table summarizes the techniques for enhanced 634 redundancy. 636 +------+------+-----------------------+ 637 | IPv4 | IPv6 | Deployment | 638 +--------------------+------+------+-----------------------+ 639 | Anycast RP w/ MSDP | Yes | No | De-facto approach | 640 | Anycast RP w/ PIM | Yes | Yes | New, simpler than MSDP| 641 | Stateless RP fail. | Yes | Yes | Causes disturbance | 642 | Bi-dir PIM | Yes | Yes | Deployed at some sites| 643 +-------------+------+------+------------------------------+ 645 2.6. Interactions with Hosts 647 Previous sections have dealt with the components required by routers 648 to be able to do multicast routing. Obviously, the real users of 649 multicast are the hosts: either sending or receiving multicast. This 650 section describes the required interactions with hosts. 652 2.6.1. Hosts Sending Multicast 654 After choosing a multicast group through a variety of means, hosts 655 just send the packets to the link-layer multicast address, and the 656 designated router will receive all the multicast packets and start 657 forwarding them as appropriate. 659 In intra-domain or Embedded-RP scenarios, ASM senders may move to a 660 new IP address without significant impact on the delivery of their 661 transmission. SSM senders cannot change the IP address unless 662 receivers join the new channel or the sender uses an IP mobility 663 technique that is transparent to the receivers. 665 2.6.2. Hosts Receiving Multicast 667 Hosts signal their interest in receiving a multicast group or channel 668 by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are 669 still commonplace, but are also often used in new deployments. Some 670 vendors also support SSM mapping techniques for receivers which use 671 an older IGMP/MLD version where the router maps the join request to 672 an SSM channel based on various, usually complex means of 673 configuration. 675 2.6.3. Summary 677 The following table summarizes the techniques host interaction. 679 +-------+------+----------------------+ 680 | IPv4 | IPv6 | Notes | 681 +--------------------+-------+------+----------------------+ 682 | Host sending | Yes | Yes | No support needed | 683 | Host receiving ASM | IGMP | MLD | Any IGMP/MLD version | 684 | Host receiving SSM | IGMPv3| MLDv2| Also SSM-mapping | 685 +--------------------+-------+------+----------------------+ 687 2.7. Restricting Multicast Flooding in the Link Layer 689 Multicast transmission in the link layer, for example Ethernet, 690 typically includes some form of flooding the packets through a LAN. 691 This causes unnecessary bandwidth usage and discarding unwanted 692 frames on those nodes which did not want to receive the multicast 693 transmission. 695 Therefore a number of techniques have been developed, to be used in 696 Ethernet switches between routers, or between routers and hosts, to 697 limit the flooding. 699 These options are discussed in this section. 701 2.7.1. Router-to-Router Flooding Reduction 703 A proprietary solution, Cisco's RGMP [RFC3488] has been developed to 704 reduce the amount of flooding between routers in a switched networks. 705 This is typically only considered a problem in some Ethernet-based 706 Internet Exchange points or VPNs. 708 There have been proposals to observe and possibly react ("snoop") PIM 709 messages [I-D.tsenevir-pim-sm-snoop][I-D.serbest-l2vpn-vpls-mcast] to 710 achieve the same effect. 712 2.7.2. Host/Router Flooding Reduction 714 There are a number of techniques to help reduce flooding both from a 715 router to hosts, and from a host to the routers (and other hosts). 717 Cisco's proprietary CGMP [CGMP] provides a solution where the routers 718 notify the switches, but also allows the switches to snoop IGMP 719 packets to enable faster notification of hosts no longer wishing to 720 receive a group. IPv6 is not supported. 722 IEEE 802.1D-2004 specification describes Generic Attribute 723 Registration Protocol (GARP), and GARP Multicast Registration 724 Protocol (GMRP) [GMRP] is a link-layer multicast group application of 725 GARP that notifies switches about IP multicast group memberships. 726 GMRP requires support at the host stack and implementation status 727 especially on hosts is unknown. Some further information about GARP/ 728 GMRP is also available in Appendix B of [RFC3488]. 730 IGMP snooping [RFC4541] appears to be the most widely implemented 731 technique. IGMP snooping requires that the switches implement a 732 significant amount of IP-level packet inspection; this appears to be 733 something that is difficult to get right, and often the upgrades are 734 also a challenge. 736 Snooping switches also need to identify the ports where routers 737 reside and therefore where to flood the packets. This can be 738 accomplished using Multicast Router Discovery protocol [RFC4286], 739 looking at certain IGMP queries [RFC4541], looking at PIM Hello and 740 possibly other messages, or by manual configuration. An issue with 741 PIM snooping at LANs is that PIM messages can't be turned off or 742 encrypted, leading to security issues 743 [I-D.savola-pim-lasthop-threats]. 745 IGMP proxying [I-D.ietf-magma-igmp-proxy] is sometimes used either as 746 a replacement of a multicast routing protocol on a small router, or 747 to aggregate IGMP/MLD reports when used with IGMP snooping. 749 2.7.3. Summary 751 The following table summarizes the techniques for multicast flooding 752 reduction inside a single link for router-to-router and last-hop 753 LANs. 755 +--------+-----+---------------------------+ 756 | R-to-R | LAN | Notes | 757 +-----------------------+--------+-----+---------------------------+ 758 | Cisco's RGMP | Yes | No | Replaced by PIM snooping | 759 | PIM snooping | Yes | No | Security issues in LANs | 760 | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD bad | 761 | Multicast Router Disc | No | Yes | Few if any implem. yet | 762 | IEEE 802.1D-2004 GMRP | No | Yes | Impl. status unknown | 763 | Cisco's CGMP | No | Yes | Replaced by other snooping| 764 +-----------------------+--------+-----+---------------------------+ 766 3. Acknowledgements 768 Tutoring a couple multicast-related papers, the latest by Kaarle 769 Ritvanen [RITVANEN] convinced the author that up-to-date multicast 770 routing and address assignment/allocation documentation is necessary. 772 Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, 773 Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat 774 Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon 775 Chisholm, and John Zwiebel provided good comments, helping in 776 improving this document. 778 4. IANA Considerations 780 This memo includes no request to IANA. 782 5. Security Considerations 784 This memo only describes different approaches to multicast routing, 785 and this has no security considerations; the security analysis of the 786 mentioned protocols is out of scope of this memo. 788 However, there has been analysis of the security of multicast routing 789 infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD 790 [I-D.daley-magma-smld-prob], and PIM last-hop issues 791 [I-D.savola-pim-lasthop-threats]. 793 6. References 795 6.1. Normative References 797 [I-D.ietf-idmr-dvmrp-v3] 798 Pusateri, T., "Distance Vector Multicast Routing 799 Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), 800 December 2003. 802 [I-D.ietf-isis-wg-multi-topology] 803 Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in 804 IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in 805 progress), October 2005. 807 [I-D.ietf-mboned-addrarch] 808 Savola, P., "Overview of the Internet Multicast Addressing 809 Architecture", draft-ietf-mboned-addrarch-04 (work in 810 progress), March 2006. 812 [I-D.ietf-ospf-mt] 813 Psenak, P., "Multi-Topology (MT) Routing in OSPF", 814 draft-ietf-ospf-mt-06 (work in progress), February 2006. 816 [I-D.ietf-pim-bidir] 817 Handley, M., "Bi-directional Protocol Independent 818 Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in 819 progress), October 2005. 821 [I-D.ietf-pim-sm-v2-new] 822 Fenner, B., "Protocol Independent Multicast - Sparse Mode 823 (PIM-SM): Protocol Specification (Revised)", 824 draft-ietf-pim-sm-v2-new-12 (work in progress), 825 March 2006. 827 [I-D.ietf-ssm-arch] 828 Holbrook, H. and B. Cain, "Source-Specific Multicast for 829 IP", draft-ietf-ssm-arch-07 (work in progress), 830 October 2005. 832 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 833 3", BCP 9, RFC 2026, October 1996. 835 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 836 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 838 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 839 Thyagarajan, "Internet Group Management Protocol, Version 840 3", RFC 3376, October 2002. 842 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 843 Protocol (MSDP)", RFC 3618, October 2003. 845 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 846 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 848 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 849 Point (RP) Address in an IPv6 Multicast Address", 850 RFC 3956, November 2004. 852 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 853 Independent Multicast - Dense Mode (PIM-DM): Protocol 854 Specification (Revised)", RFC 3973, January 2005. 856 6.2. Informative References 858 [CGMP] "Cisco Group Management Protocol", 859 . 861 [GMRP] "GARP Multicast Registration Protocol", 862 . 864 [I-D.daley-magma-smld-prob] 865 Daley, G. and G. Kurup, "Trust Models and Security in 866 Multicast Listener Discovery", 867 draft-daley-magma-smld-prob-00 (work in progress), 868 July 2004. 870 [I-D.ietf-idmr-dvmrp-v3-as] 871 Pusateri, T., "Distance Vector Multicast Routing Protocol 872 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 873 (work in progress), May 2004. 875 [I-D.ietf-idr-rfc2858bis] 876 Bates, T., "Multiprotocol Extensions for BGP-4", 877 draft-ietf-idr-rfc2858bis-10 (work in progress), 878 March 2006. 880 [I-D.ietf-magma-igmp-proxy] 881 Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ 882 MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", 883 draft-ietf-magma-igmp-proxy-06 (work in progress), 884 April 2004. 886 [I-D.ietf-mboned-ipv6-multicast-issues] 887 Savola, P., "IPv6 Multicast Deployment Issues", 888 draft-ietf-mboned-ipv6-multicast-issues-02 (work in 889 progress), February 2005. 891 [I-D.ietf-mboned-mroutesec] 892 Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast 893 Routing Security Issues and Enhancements", 894 draft-ietf-mboned-mroutesec-04 (work in progress), 895 October 2004. 897 [I-D.ietf-pim-anycast-rp] 898 Farinacci, D. and Y. Cai, "Anycast-RP using PIM", 899 draft-ietf-pim-anycast-rp-07 (work in progress), 900 February 2006. 902 [I-D.ietf-pim-sm-bsr] 903 Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", 904 draft-ietf-pim-sm-bsr-09 (work in progress), June 2006. 906 [I-D.lehtonen-mboned-dynssm-req] 907 Lehtonen, R., "Requirements for discovery of dynamic SSM 908 sources", draft-lehtonen-mboned-dynssm-req-00 (work in 909 progress), February 2005. 911 [I-D.savola-pim-lasthop-threats] 912 Lingard, J. and P. Savola, "Last-hop Threats to Protocol 913 Independent Multicast (PIM)", 914 draft-savola-pim-lasthop-threats-02 (work in progress), 915 June 2006. 917 [I-D.serbest-l2vpn-vpls-mcast] 918 Serbest, Y., "Supporting IP Multicast over VPLS", 919 draft-serbest-l2vpn-vpls-mcast-03 (work in progress), 920 July 2005. 922 [I-D.tsenevir-pim-sm-snoop] 923 Senevirathne, T. and S. Vallepali, "Protocol Independent 924 Multicast-Sparse Mode (PIM-SM) Snooping", 925 draft-tsenevir-pim-sm-snoop-00 (work in progress), 926 April 2002. 928 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 929 Vector Multicast Routing Protocol", RFC 1075, 930 November 1988. 932 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 933 March 1994. 935 [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, 936 March 1994. 938 [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 939 Routing -- Protocol Specification --", RFC 2189, 940 September 1997. 942 [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing 943 Architecture", RFC 2201, September 1997. 945 [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing 946 Protocols", RFC 2715, October 1999. 948 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 949 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 950 March 2000. 952 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 953 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 954 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 955 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 956 Protocol Specification", RFC 3208, December 2001. 958 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 959 Rendevous Point (RP) mechanism using Protocol Independent 960 Multicast (PIM) and Multicast Source Discovery Protocol 961 (MSDP)", RFC 3446, January 2003. 963 [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group 964 Management Protocol (RGMP)", RFC 3488, February 2003. 966 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 967 Architecture", RFC 3740, March 2004. 969 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 970 Protocol Specification", RFC 3913, September 2004. 972 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 973 RFC 4286, December 2005. 975 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 976 "Considerations for Internet Group Management Protocol 977 (IGMP) and Multicast Listener Discovery (MLD) Snooping 978 Switches", RFC 4541, May 2006. 980 [RITVANEN] 981 Ritvanen, K., "Multicast Routing and Addressing", HUT 982 Report, Seminar on Internetworking, May 2004, 983 . 985 Appendix A. Multicast Payload Transport Extensions 987 A couple of mechanisms have been, and are being specified, to improve 988 the characteristics of the data that can be transported over 989 multicast. 991 These go beyond the scope of multicast routing, but as reliable 992 multicast has some relevance, these are briefly mentioned. 994 A.1. Reliable Multicast 996 Reliable Multicast Working Group has been working on experimental 997 specifications so that applications requiring reliable delivery 998 characteristics, instead of simple unreliable UDP, could use 999 multicast as a distribution mechanism. 1001 One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. 1002 This does not require support from the routers, bur PGM-aware routers 1003 may act in router assistance role in the initial delivery and 1004 potential retransmission of missing data. 1006 A.2. Multicast Group Security 1008 Multicast Security Working Group has been working on methods how the 1009 integrity, confidentiality, and authentication of data sent to 1010 multicast groups can be ensured using cryptographic techniques 1011 [RFC3740]. 1013 Author's Address 1015 Pekka Savola 1016 CSC - Scientific Computing Ltd. 1017 Espoo 1018 Finland 1020 Email: psavola@funet.fi 1022 Full Copyright Statement 1024 Copyright (C) The Internet Society (2006). 1026 This document is subject to the rights, licenses and restrictions 1027 contained in BCP 78, and except as set forth therein, the authors 1028 retain all their rights. 1030 This document and the information contained herein are provided on an 1031 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1032 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1033 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1034 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1035 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1036 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1038 Intellectual Property 1040 The IETF takes no position regarding the validity or scope of any 1041 Intellectual Property Rights or other rights that might be claimed to 1042 pertain to the implementation or use of the technology described in 1043 this document or the extent to which any license under such rights 1044 might or might not be available; nor does it represent that it has 1045 made any independent effort to identify any such rights. Information 1046 on the procedures with respect to rights in RFC documents can be 1047 found in BCP 78 and BCP 79. 1049 Copies of IPR disclosures made to the IETF Secretariat and any 1050 assurances of licenses to be made available, or the result of an 1051 attempt made to obtain a general license or permission for the use of 1052 such proprietary rights by implementers or users of this 1053 specification can be obtained from the IETF on-line IPR repository at 1054 http://www.ietf.org/ipr. 1056 The IETF invites any interested party to bring to its attention any 1057 copyrights, patents or patent applications, or other proprietary 1058 rights that may cover technology that may be required to implement 1059 this standard. Please address the information to the IETF at 1060 ietf-ipr@ietf.org. 1062 Acknowledgment 1064 Funding for the RFC Editor function is provided by the IETF 1065 Administrative Support Activity (IASA).