idnits 2.17.1 draft-raggarwa-l3vpn-2547-mvpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 469 has weird spacing: '...ch VPNs must ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KEYWORDS' is mentioned on line 46, but not defined == Unused Reference: 'GRE2784' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 499, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-08 == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-01 == Outdated reference: A later version (-15) exists of draft-rosen-vpn-mcast-06 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Rahul Aggarwal 2 Internet Draft Anil Lohiya 3 Expiration Date: December 2004 Tom Pusateri 4 Yakov Rekhter 5 Juniper Networks 7 Base Specification for Multicast in BGP/MPLS VPNs 9 draft-raggarwa-l3vpn-2547-mvpn-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes the minimal set of procedures required to 35 build multi-vendor inter-operable implementations of multicast for 36 BGP/MPLS VPNs. It is based on prior specifications of multicast for 37 BGP/MPLS VPN specifications that have been implemented and deployed. 38 The procedures described herein require PIM-SM as the multicast 39 routing protocol in the SP network. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 47 Table of Contents 49 1. Motivation.......................................... 2 50 2. Terminology......................................... 3 51 3. Introduction........................................ 3 52 3.1. Efficient vs. Scalable Solution...................... 4 53 4. Basic Concepts...................................... 5 54 4.1. Multicast Domains................................... 5 55 4.2. Provider and VPN PIM Instances...................... 5 56 4.3. Multicast Tunnels................................... 6 57 5. Procedures.......................................... 6 58 5.1. Multicast VPN PIM-SM Join/Prune/Assert Propagation.. 6 59 5.1.1. C-Join/Prune/Assert RPF Interface................... 6 60 5.1.2. C-Join/Prune/Assert PIM Neighbor Address............ 7 61 5.1.3. Switching from Shared to Source Specific MD Trees 62 in the SP Network................................... 7 63 5.2. Multicast VPN Data Forwarding....................... 8 64 5.3. Operation........................................... 9 65 5.3.1. PIM Neighbor Discovery in a MD...................... 9 66 5.3.2. Handling a PIM-Join/Prune received from a CE........ 10 67 6. Inter-AS Considerations............................. 10 68 7. Security Considerations............................. 11 69 8. Acknowledgments..................................... 11 70 9. Normative References................................ 11 71 10. Informative References.............................. 12 73 1. Motivation 75 This document describes the minimal set of procedures required to 76 build inter-operable implementations of multicast support for 77 BGP/MPLS VPNs (MVPNs). It is based on prior multicast in BGP/MPLS VPN 78 specifications [MVPN-6] that have been implemented and deployed. 79 Procedures presented herein are not new. However the intent of this 80 document is to clearly define the base set of procedures required to 81 build inter-operable implementations of multicast support for 82 BGP/MPLS VPNs. 84 This document requires PIM-SM as multicast routing protocol in the SP 85 network. 87 This document does not preclude various optional optimizations of 88 multicast support for BGP/MPLS VPNs - it assumes that procedures for 89 such optimizations will be specified in separate documents. 91 2. Terminology 93 In addition to the terminology used in [2547] and [PIM-SM] this 94 document introduces the following terms: 96 Multicast Domain (MD): A set of VRFs on different PEs, belonging to a 97 given VPN, associated with interfaces that can send multicast traffic 98 to each other. 100 Provider PIM Instance: PIM instance in the SP network 102 VPN PIM Instance: PIM instance in the VPN 104 P-Join: PIM Join message in the Provider PIM instance. 106 C-Join: PIM Join message in the VPN PIM instance. 108 Multicast Tunnel (MT): Tunnel created for each MD, in the provider 109 PIM instance. The MT is used to carry multicast customer packets, 110 both data and control, among the PE routers in a common MD. 112 3. Introduction 114 [2547] specifies a set of procedures which must be implemented for a 115 SP to provide a unicast VPN service. [MVPN-6] describes various 116 methods that can be used to extend [2547] to enable a SP to provide 117 multicast service in a VPN. However it does not specify the minimal 118 and the exact set of procedures required for inter-operability. This 119 has lead to non inter-operable implementations. 121 This document specifies the minimal set of procedures required for an 122 inter-operable solution that enable a SP to provide multicast service 123 in a VPN. The procedures specified herein require a SP to use PIM-SM 124 as the multicast routing protocol in the SP network. Use of other 125 multicast routing protocols (PIM-SSM, PIM-BIDIR, PIM-DM) in the SP 126 network for the purpose of providing multicast service in a VPN is 127 optional and is not part of the minimal set of required procedures 128 discussed here. 130 Within a VPN, any of PIM-SM, PIM-DM, PIM-SSM, PIM-BIDIR can be used 131 as the multicast routing protocol. 133 3.1. Efficient vs. Scalable Solution 135 In the context of this document we define "efficient multicast 136 routing" as follows. When a PE router receives a multicast data 137 packet of a particular multicast group from a CE router, the packet 138 must reach every other PE router which is on the path to a receiver 139 of that group. It should not reach any PEs that aren't on the path to 140 a receiver. It should not be unnecessarily replicated. Efficient 141 multicast routing requires a source-tree for the multicast group, 142 which would mean that the P routers would have to maintain state for 143 each transmitter of each multicast group in each VPN. 145 Note that efficient multicast routing, as defined above, requires 146 potentially an unbounded amount of state in the SP routers, since the 147 SP has no control on the number of multicast groups in the VPNs that 148 it supports. Nor does the SP have any control over the number of 149 transmitters in each group, nor of the distribution of the receivers. 151 However, even if the amount of state was possible, the same multicast 152 group address can be used in multiple VPNs to carry different 153 traffic. This traffic cannot be mixed or delivered to the wrong VPN. 154 This dictates the need for a tunneling mechanism to keep the traffic 155 with the same destination IP address seperated for each VPN. 157 One option is to setup unicast tunnels from the ingress PE to each of 158 the egress PEs. The ingress PE replicates the multicast data packet 159 received from a CE and sends it to each of the egress PEs using the 160 unicast tunnels. Hence this solution uses ingress replication but 161 requires minimal state in the SP network. 163 This documents specifies a solution that aims at achieving a 164 compromise between the the amount of multicast state required to be 165 maintained in the SP network and the efficiency of multicast routing. 166 It uses a PIM-SM shared tree multicast tunnel for each VPN. That 167 allows it to bound the total amount of multicast state in the SP 168 network solely by the number of VPNs. PIM-SM provides a way to 169 improve efficiency of multicast routing (albeit at the cost of 170 additional multicast state in the SP network) by switching from the 171 shared tree to source trees, rooted at each PE. The PIM-SM source 172 tree is shared by all the multicast sources within a VPN that are 173 behind that PE. 175 4. Basic Concepts 177 This section describes terminology used in the remainder of this 178 document. 180 4.1. Multicast Domains 182 A "Multicast Domain (MD)" is a set of VRFs on different PEs, 183 belonging to the same VPN, associated with interfaces that can send 184 multicast traffic to each other. Each MD is assigned a MD P-Group 185 address. It is required that each MD be assigned a unique address 186 across all the domains that are part of the MVPN service. Each VRF 187 has its own multicast routing table. When a multicast control packet 188 is received from a particular CE device, PIM RPF lookup and PIM Join 189 propagation is done in the associated VRF. Similarly, when a 190 multicast data packet is received from a particular CE device, 191 multicast data forwarding is done in the associated VRF. The goal of 192 this is to send the multicast control or data packet to all other 193 VRFs in that MD. This is achieved by building one or more multicast 194 distribution tree for a given MD in the SP network. 196 4.2. Provider and VPN PIM Instances 198 Each PE router runs an instance of PIM per VRF. In each VRF instance 199 of PIM, the PE maintains a PIM adjacency with each of the PIM-capable 200 CE routers associated with that VRF. The multicast routing table 201 created by each instance is specific to the corresponding VRF. These 202 PIM instances are referred as "VPN-specific PIM instances". These PIM 203 instances can support any flavor of PIM, for instance PIM-SM or PIM- 204 DM. 206 Each PE router also runs a "provider-wide" instance of PIM-SM, in 207 which it has a PIM adjacency with each of its IGP neighbors (i.e., 208 with P and directly connected PE routers), but NOT with any CE 209 routers. The provider PIM instance MUST support PIM-SM. 211 In order to help refer to provider-wide PIM instance and to VPN- 212 specific PIM instance, the prefixes "P-" and "C-" are used 213 respectively. Thus a P-Join would be a PIM Join which is processed 214 by the provider-wide PIM-SM instance, and a C-Join would be a PIM 215 Join which is processed by a VPN-specific PIM instance. A P-group 216 address would be a group address in the SP's address space. 218 4.3. Multicast Tunnels 220 Each MD is assigned a unique multicast P-group address across the 221 provider network. As part of normal PIM-SM procedures the provider 222 wide PIM-SM instance has to know the RP for each P-group. 224 Each PE sends the traffic for an MD encapsulated to the P-group for 225 that MD. This is called a Multicast Tunnel (MT). The MT is treated 226 like an interface and normal PIM Hellos are sent through the tunnel. 227 This leads to all PEs discovering each other as PIM neighbors over 228 that MT interface in the given MD. The details are described in 229 section 5.3.1. 231 The MT is used to carry multicast C-packets, both data and control 232 packets, among the PE routers in a common MD. Data forwarding is 233 described in section 5.2. 235 When a packet is received by a PE from another router in the SP 236 network, the receiving PE can determine the MT (and hence the MD) 237 from which the packet was received as the destination address of the 238 packet is the MD P-group address. The decapsulated packet is then 239 passed to the corresponding Multicast VRF and VPN-specific PIM 240 instance for further processing. 242 5. Procedures 244 5.1. Multicast VPN PIM-SM Join/Prune/Assert Propagation 246 For a VRF in a particular MD, the corresponding MT is treated by that 247 VRF's VPN-specific PIM instance as an interface. The PEs which are 248 adjacent on the MT must execute the PIM interface procedures, 249 including the generation and processing of Assert packets. The VPN 250 PIM instances can send C-Join messages through the MT. These messages 251 are received by all PEs in the MD. This allows VPN-specific PIM 252 Join/Prune messages to be extended from site to site, without 253 appearing in the P routers. Note that a C-Join message carries the 254 address of the neighbor for which the C-Join message is meant. This 255 message is processed by the corresponding PIM neighbor on the MT 256 interface. 258 5.1.1. C-Join/Prune/Assert RPF Interface 260 Although the MT is treated as a PIM-enabled interface, unicast 261 routing is NOT run over it, and there are no unicast routing 262 adjacencies over it. It is therefore necessary to specify special 263 procedures for determining when the MT is to be regarded as the "RPF 264 Interface" for a particular C-address. 266 When a PE needs to determine the RPF interface of a particular C- 267 address, it looks up the C-address in the VRF. If the route matching 268 it is not a VPN-IP route learned from MP-BGP as described in [2547], 269 or if that route's outgoing interface is one of the interfaces 270 associated with the VRF, then ordinary PIM procedures for determining 271 the RPF interface apply. 273 However, if the route matching the C-address is a VPN-IP route whose 274 outgoing interface is not one of the interfaces associated with the 275 VRF, then PIM will consider the outgoing interface to be the MT 276 associated with the VPN-specific PIM instance. 278 5.1.2. C-Join/Prune/Assert PIM Neighbor Address 280 Determination of the C-Join PIM neighbor address i.e. the RPF 281 neighbor address needs to be further explained. This depends on the 282 procedure used to assign an address to the MT inteface. The address 283 of this interface MUST be the BGP next-hop address of the unicast VPN 284 routes advertised by the MD VRF. This will typically be a PE loopback 285 address in the provider address space. 287 To determine the C-Join neighbor address, the PE does a route lookup 288 on the C-Source address. This address is a VPN unicast route learnt 289 from the PE sitting in front of the multicast source. The route 290 lookup results in the BGP next-hop of the C-source VPN unicast route. 291 This BGP next-hop is the neighbor address to use while sending the 292 PIM-Join. 294 5.1.3. Switching from Shared to Source Specific MD Trees in the SP 295 Network 297 By default the generation of VPN instance PIM control messages on a 298 MT by a PE results in all the other PEs in that MD to switch from the 299 shared MD tree in the SP network to a source specific MD tree rooted 300 at the PE that is generating the control messages. This is the case 301 even though there may not be any multicast sources transmitting in 302 that given VRF on that PE. This results in a different source 303 specific tree for a given MD for each PE that belongs to that MD. 305 To reduce the number of source specific trees in the SP network an 306 implementation SHOULD provide the following knobs to control 307 switching from the shared MD tree in the SP network: 309 a) A knob on the RP so that it sends the source specific MD P-Group 310 Join to the source PE (after receiving Register messages) only after 311 the multicast traffic being received for that MD from the source PE 312 exceeds a certain threshold. 314 b) A knob on a PE so that it sends the source specific MD P-Group 315 Join to the source PE only after the multicast traffic being received 316 for that MD from the source PE exceeds a certain threshold. 318 Note that this is a local implementation choice and does not impact 319 inter-operability. 321 5.2. Multicast VPN Data Forwarding 323 A PE in a particular MD transmits a C-multicast data packet through 324 the SP network by transmitting it through the MT corresponding to the 325 MD. The MT is installed as the outgoing interface for the C-multicast 326 data packets when C-Join messages corresponding to the data packet's 327 source and group are received on the MT interface. 329 An implementation MUST support GRE encapsulation. 331 The following diagram shows the progression of the packet using GRE 332 encapsulation as it enters and leaves the service provider network. 334 Packets received Packets in transit Packets forwarded 335 at ingress PE in the service by egress PEs 336 provider network 338 +---------------+ 339 | P-IP Header | 340 +---------------+ 341 | GRE | 342 ++=============++ ++=============++ ++=============++ 343 || C-IP Header || || C-IP Header || || C-IP Header || 344 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 345 || C-Payload || || C-Payload || || C-Payload || 346 ++=============++ ++=============++ ++=============++ 348 The destination address in the P-IP header is the MD address 349 corresponding to the MT. This enables the P routers to forward this 350 packet along the multicast distribution tree corresponding to the MD. 352 The IPv4 Protocol Number field in the P-IP Header must be set to GRE 353 (47). 355 If a PE in a particular MD transmits a C-multicast data packet to the 356 backbone, by transmitting it through an MD, every other PE in that MD 357 will receive it. Any of those PEs which are not on a C-multicast 358 distribution tree for the packet's C-multicast destination address 359 (as determined by applying ordinary PIM procedures to the 360 corresponding multicast VRF) will have to discard the packet. 362 5.3. Operation 364 5.3.1. PIM Neighbor Discovery in a MD 366 MTs are described in section 4.3. A MT is a pseudo interface unique 367 to a VPN that can be created when PIM-SM initializes. Unicast 368 routing is not run over this interface. This interface is used to 369 carry PIM control and multicast data traffic. PIM sends Hello 370 messages on the MT interfaces using the PE loopback address in the 371 provider address space as the source address. Each PE router needs to 372 join the MD P-Groups associated with all the MDs it belongs to. 373 Discovery of remote PEs in the same VPN is done by sending PIM Hello 374 messages over MT tunnels as follows: 376 o When PIM-SM initializes in a MD, the PE originates a PIM Join 377 message for the MD P-Group address towards the RP in the SP space. 378 This is done for each MD that is configured on the PE. 380 o Since an MT interface belongs to a VPN, sending a Hello message on 381 this interface does the following: 382 o The PIM Hello message has the source address of PE's loopback 383 interface in the SP address space and the destination of ALL-PIM- 384 ROUTERS group. 386 o This PIM Hello gets encapsulated in a GRE header with the 387 source address as the PE's loopback interface and the destination as 388 the MD P-Group address. After the encapsulation, the original PIM-SM 389 Hello travels as the data packet in a PIM-SM Register towards the SP 390 RP. 392 o RP in the SP network knows about all the receivers (the PEs) 393 because of the earlier PIM Join for the MD P-Group address that it 394 received from all the PEs when they initialized. So, when the RP 395 receives the above PIM-SM register, it decapsulates it and forwards 396 it down to all the PEs. So, all the remote PEs (including the one who 397 sent the packet) receives this data packet which has the source 398 address of the originating PE. 400 o This PIM Hello packet originated within the VRF travels as the 401 data packet (due to encapsulation) in the SP network towards the RP. 403 o The above procedure is repeated on all the PEs. Hence, all the 404 PEs receive each other's data packets which contain PIM Hello 405 messages and discover one another. PEs can decide to send the source 406 Join directly to the remote PEs at this point. 408 5.3.2. Handling a PIM-Join/Prune received from a CE 410 When a PE receives a PIM Join/Prune for a group in the VPN space in 411 its VRF, it processes this message exactly as per PIM procedures. 412 Then it forwards this message to the upstream PIM neighbor in the 413 path to the VPN-RP or the VPN source. The neighbor address in the PIM 414 message is set as described in section 5.1.2. The PIM message is 415 encapsulated in a GRE header with the source address as the PE's 416 loopback interface and the destination as the MD P-Group address. 418 The original PIM control message in the VPN instance PIM now becomes 419 a data packet within the SP space and gets sent either as the PIM-SM 420 Register to the SP-RP or natively through the SP network. It is sent 421 to all PEs that had sent a PIM-SM Join for the MD P-Group address 422 earlier. The packet finally reaches all the PEs in the MD. The PE for 423 which the "upstream neighbor address" matches forwards the original 424 PIM control message towards the RP or source behind the CE. 426 6. Inter-AS Considerations 428 [2547] describes three methods for creating inter-AS VPNs: 430 Option A: VRF-to-VRF connections at the AS border routers. 432 Option B: EBGP redistribution of labeled VPN-IP routes from AS to 433 neighboring AS. 435 Option C: Multihop EBGP distribution of labeled VPN-IP routes between 436 source and destination ASes, with EBGP redistribution of labeled IP 437 routes from AS to neighboring AS. 439 The mechanisms described in this draft support multi-AS VPN multicast 440 when either Option A or C is used. However, they are not sufficient 441 when Option B is used. This is because the BGP Next-hop of the VPN 442 routes is re-written in Option B at the ASBRs. As a result of this 443 the PIM neighbor and the BGP next-hop do not match and the procedures 444 described in section 5.1.2 cannot be used for determining the RPF 445 neighbor. Solution to this issue is outside the scope of this 446 document. 448 It is possible that Option C is used with a 'BGP free SP network'. In 449 this case the P routers in one AS do not know how to route to the PE 450 addresses in another AS. As a result of this they will not be able to 451 forward the P-Join messages towards the egress PE. Solution to this 452 issue is outside the scope of this document. 454 For inter-AS VPNs that require multicast service if the involved ASs 455 are all under a single provider, these ASs can share RPs, and MSDP is 456 not required. Even if the ASs are under control of multiple service 457 providers, the level of cooperation required to offer even plain 458 unicast 2547 VPN service is high enough, which means that one more 459 issue (ownership of RP) may not be a significant addition to what is 460 already required. And if that is the case, the providers can share 461 RPs, and MSDP is not required. If each provider insists on having its 462 own local RP, MSDP can be used between the RPs that belong to the 463 different providers. However, in many cases, this will not be 464 necessary. 466 If there are inter-AS VPNs that span multiple SPs and require 467 multicast service, then MDs (and MTs) for these VPNs will cross 468 provider boundaries. The assignment of the multicast group addresses 469 associated with the MDs for such VPNs must then be coordinated upon 470 by the providers 472 7. Security Considerations 474 Security considerations discussed in [2547] and [PIM-SM] apply to 475 this document. 477 8. Acknowledgment 479 As mentioned earlier, this draft is based on [MVPN-6]. The authors of 480 [MVPN-6] are Eric Rosen, Yiqun Cai, Dan Tappan, IJsbrand Wijnands, 481 Yakov Rekhter and Dino Farinacci. We would like to thank them for 482 their tremendous contribution to this technology. 484 We would also like to thank Paras Trivedi for his detailed review of 485 this document. 487 9. Normative References 489 [PIM-SM] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", 490 Fenner, Handley, Holbrook, Kouvelas, October 2003, draft-ietf-pim- 491 sm-v2-new-08.txt 493 [2547] "BGP/MPLS VPNs", Rosen, Rekhter, et. al., September 2003, 494 draft-ietf-l3vpn-rfc2547bis-01.txt 496 [GRE2784] "Generic Routing Encapsulation (GRE)", Farinacci, Li, 497 Hanks, Meyer, Traina, March 2000, RFC 2784 499 [RFC2119] "Key words for use in RFCs to Indicate Requirement 500 Levels.", Bradner, March 1997 502 10. Informative References 504 [MVPN-6] E. Rosen. et. al., "Multicast in MPLS/BGP VPNs", draft- 505 rosen-vpn-mcast-06.txt 507 Author Information 509 Rahul Aggarwal 510 Juniper Networks 511 1194 North Mathilda Ave. 512 Sunnyvale, CA 94089 513 Email: rahul@juniper.net 515 Anil Lohiya 516 Juniper Networks 517 1194 North Mathilda Ave. 518 Sunnyvale, CA 94089 519 Email: alohiya@juniper.net 521 Tom Pusateri 522 Juniper Networks 523 1194 North Mathilda Ave. 524 Sunnyvale, CA 94089 525 Email: pusateri@juniper.net 527 Yakov Rekhter 528 Juniper Networks 529 1194 North Mathilda Ave. 530 Sunnyvale, CA 94089 531 Email: yakov@juniper.net 533 IPR Notice 535 The IETF takes no position regarding the validity or scope of any 536 intellectual property or other rights that might be claimed to 537 pertain to the implementation or use of the technology described in 538 this document or the extent to which any license under such rights 539 might or might not be available; neither does it represent that it 540 has made any effort to identify any such rights. Information on the 541 IETF's procedures with respect to rights in standards-track and 542 standards-related documentation can be found in BCP-11. Copies of 543 claims of rights made available for publication and any assurances of 544 licenses to be made available, or the result of an attempt made to 545 obtain a general license or permission for the use of such 546 proprietary rights by implementors or users of this specification can 547 be obtained from the IETF Secretariat. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights which may cover technology that may be required to practice 552 this standard. Please address the information to the IETF Executive 553 Director. 555 Full Copyright Notice 557 Copyright (C) The Internet Society (2003). All Rights Reserved. 559 This document and translations of it may be copied and furnished to 560 others, and derivative works that comment on or otherwise explain it 561 or assist in its implementation may be prepared, copied, published 562 and distributed, in whole or in part, without restriction of any 563 kind, provided that the above copyright notice and this paragraph are 564 included on all such copies and derivative works. However, this 565 document itself may not be modified in any way, such as by removing 566 the copyright notice or references to the Internet Society or other 567 Internet organizations, except as needed for the purpose of 568 developing Internet standards in which case the procedures for 569 copyrights defined in the Internet Standards process must be 570 followed, or as required to translate it into languages other than 571 English. 573 The limited permissions granted above are perpetual and will not be 574 revoked by the Internet Society or its successors or assigns. 576 This document and the information contained herein is provided on an 577 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 578 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 579 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 580 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 581 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 583 Acknowledgment 585 Funding for the RFC Editor function is currently provided by the 586 Internet Society.