idnits 2.17.1 draft-ietf-mpls-explicit-resource-control-bundle-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([RFC3473], [RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 30, 2008) is 5864 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3945' is defined on line 512, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Anca Zamfir 3 Internet Draft Zafar Ali 4 Expires: September 29, 2008 Cisco Systems 5 Dimitri Papadimitriou 6 Alcatel-Lucent 7 March 30, 2008 9 Component Link Recording and Resource Control for TE Link Bundles 11 draft-ietf-mpls-explicit-resource-control-bundle-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on September 29, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 Record Route is a useful administrative tool that has been used 45 extensively by the service providers. However, when TE links are 46 bundled, identification of label resource in Record Route Object 47 (RRO) is not enough for the administrative purpose. Network service 49 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 51 providers would like to know the component link within a TE link that 52 is being used by a given LSP. In other words, when link bundling is 53 used, resource recording requires mechanisms to specify the component 54 link identifier, along with the TE link identifier and Label. As it 55 is not possible to record component link in the RRO, this draft 56 defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify 57 component link identifiers for resource recording purposes. 59 This draft also defines the Explicit Route Object (ERO) counterpart 60 of the RRO extension. The ERO extensions are needed to perform 61 explicit label/ resource control over bundled TE link. Hence, this 62 document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to 63 specify component link identifiers for explicit resource control and 64 recording over TE link bundles. 66 Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [RFC2119]. 72 Table of Contents 74 1. Terminology....................................................2 75 2. Resource Control and Recording.................................3 76 3. LSP Resource Recording.........................................4 77 3.1 Component Interface Identifier RRO subobject...............4 78 3.2 Processing of Component Interface identifier RRO Subobject.5 79 4. Signaling Component Interface Identifier in ERO................6 80 4.1 Processing of Component Interface Identifier ERO Subobject.7 81 5. Forward Compatibility Note.....................................9 82 6. Security Considerations........................................9 83 7. IANA Considerations...........................................10 84 8. References....................................................10 85 8.1 Normative Reference.......................................10 86 8.2 Informative Reference.....................................11 87 9. Author's Addresses............................................11 88 10. Intellectual Property Considerations.........................12 89 11. Full Copyright Statement.....................................12 91 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 93 1. Terminology 95 TE Link: Unless specified otherwise, it refers to a bundled Traffic 96 Engineering link as defined in [RFC4201]. Furthermore, the terms TE 97 Link and bundled TE Link are used interchangeably in this draft. 99 Component (interface) link: refers (locally) to a component link as 100 part of a bundled TE link. A component link is numbered/ unnumbered 101 in its own right. For unnumbered component links, the component link 102 ID is assumed to be unique on an advertising node. For numbered 103 component links, the component link ID is assumed to be unique within 104 a domain. 106 Component Interface Identifier: Refers to an ID used to uniquely 107 identify a Component Interface. On a bundled link a combination of 108 is sufficient to unambiguously 109 identify the appropriate resources used by an LSP [RFC4201]. 111 2. Resource Control and Recording 113 In GMPLS networks that deals with unbundled (being either PSC, L2SC, 114 TDM or LSC) TE Links, one of the types of resources that an LSP 115 originator can control and would like to record are the TE Link 116 interfaces used by the LSP. The resource control and recording is 117 done by the use of an explicit route, i.e., Explicit Route (ERO) 118 Object and record Route, i.e., Record Route Object (RRO) object, 119 respectively. 121 Link Bundling, introduced in [RFC4201], is used to improve routing 122 scalability by reducing the amount of TE related information that 123 needs to be flooded and handled by IGP in a TE network. This is 124 accomplished by aggregating and abstracting the TE Link resource. In 125 some cases the complete resource identification is left as a local 126 decision. However, as described above there are cases when it is 127 desirable for a non-local (e.g., LSP head-end) node to identify 128 completely or partially the LSP resources. In either case, and for 129 administrative reasons, it is required to know which component link 130 within a bundled TE link has been used for a given LSP. 132 When link bundling is used to aggregate multiple component links into 133 a TE link, label is not the only resource that needs to be identified 134 and recorded. In other words, the TE Link and the Label specified in 135 the ERO/ RRO objects are not enough to completely identify the 136 resource. For the bundled TE link case, in order to fully specify the 137 resources on a link for a given LSP, the component link needs to be 138 specified along with the label. In the case of bi-directional LSPs 139 both upstream and downstream information may be specified. Therefore, 140 explicit resource control and recording over a bundled TE link also 141 requires ability to specify a component link within the TE link. 143 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 145 This draft defines extensions to and describes the use of RSVP-TE 146 [RFC3209], [RFC3471], [RFC3473] to specify the component link 147 identifier for resource recording and explicit resource control over 148 TE link bundles. Specifically, in this document, component interface 149 identifier RRO and ERO subobjects are defined to complement their 150 Label RRO and ERO counterparts. Furthermore, procedures for 151 processing component interface identifier RRO and ERO subobjects and 152 how they can co-exist with the Label RRO and ERO subobjects are 153 specified. 155 3. LSP Resource Recording 157 LSP Resource Recording refers to the ability to record the resources 158 used by an LSP. 160 The procedure for unbundled numbered TE links is described in 161 [RFC3209] and for unbundled unnumbered TE links in [RFC3477]. For the 162 purpose of recording LSP resources used over bundled TE Links, the 163 Component Interface Identifier RRO sub-object is introduced. 165 3.1 Component Interface Identifier RRO subobject 167 A new subobject of the Record Route Object (RRO) is used to record 168 component interface identifier of a (bundled) TE Link. This subobject 169 has the following format: 171 0 1 2 3 172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |L| Type | Length |U| Reserved (must be zero) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 // IPv4, IPv6 or unnumbered Component Interface Identifier // 178 | . . . | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 L: 1 bit 183 This bit must be set to 0. 185 Type 187 Type 10 (TBD): Component Interface identifier IPv4 188 Type 11 (TBD): Component Interface identifier IPv6 189 Type 12 (TBD): Component Interface identifier Unnumbered 191 Length 193 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 195 The Length contains the total length of the subobject in 196 bytes, including the Type and Length fields. The Length is 197 8 bytes for the Component Interface identifier IPv4 and 198 Component Interface identifier Unnumbered types. For 199 Component Interface identifier IPv6 type of sub-object, the 200 length field is 20 bytes. 202 U: 1 bit 204 This bit indicates the direction of the component 205 interface. It is 0 for the downstream interface. It is 206 set to 1 for the upstream interface and is only used for 207 bi-directional LSPs. 209 3.2 Processing of Component Interface identifier RRO Subobject 211 If a node desires component link recording, the "Component Link 212 Recording desired" flag (value TBD) should be set in the 213 LSP_ATTRIBUTES object, object that is defined in [RFC4420]. 215 Setting of "Component Link Recording desired" flag is independent of 216 the Label Recording flag in SESSION_ATTRIBUTE object as specified in 217 [RFC3209]. Nevertheless, the following combinations are valid: 219 1) If both Label and Component Link flags are clear, then neither 220 Labels nor Component Links are recorded. 222 2) If Label Recording flag is set and Component Link flag is 223 clear, then only Label Recording is performed as defined in 224 [RFC3209]. 226 3) If Label Recording flag is clear and Component Link flag is 227 set, then Component Link Recording is performed as defined in this 228 proposal. 230 4) If both Label Recording and Component Link flags are set, then 231 Label Recording is performed as defined in [RFC3209] and also 232 Component Link recording is performed as defined in this proposal. 234 In most cases, a node initiates recording for a given LSP by adding 235 the RRO to the Path message. If the node desires Component Link 236 recording and if the outgoing TE link is bundled, then the initial 237 RRO contains the Component Link identifier (numbered or unnumbered) 238 as selected by the sender. As well, the Component Link Recording 239 desired flag is set in the LSP_ATTRIBUTE object. If the node also 240 desires label recording, it sets the Label_Recording flag in the 241 SESSION_ATTRIBUTE object. 243 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 245 When a Path message with the "Component Link Recording desired" flag 246 set is received by an intermediate node, if a new Path message is to 247 be sent for a downstream bundled TE link, the node adds a new 248 Component Link subobject to the RECORD_ROUTE object (RRO) and appends 249 the resulting RRO to the Path message before transmission. 251 Note also that, unlike Labels, Component Link identifiers are always 252 known on receipt of the Path message. 254 When the destination node of an RSVP session receives a Path message 255 with an RRO and the "Component Link Recording desired" flag set, this 256 indicates that the sender node needs TE route as well as component 257 link recording. The destination node initiates the RRO process by 258 adding an RRO to Resv messages. The processing mirrors that of the 259 Path messages 261 The Component Interface Record subobject is pushed onto the 262 RECORD_ROUTE object (RRO) prior to pushing on the node's IP address. 263 A node MUST NOT push on a Component Interface Record subobject 264 without also pushing on the IP address or unnumbered Interface Id 265 subobject that identifies the TE Link. 267 When component interfaces are recorded for bi-directional LSPs, 268 component interface RRO subobjects for both downstream and upstream 269 interfaces MUST be included. 271 4. Signaling Component Interface Identifier in ERO 273 A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used 274 to specify component interface identifier of a bundled TE Link. 276 This Component Interface Identifier subobject has the following 277 format: 279 0 1 2 3 280 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |L| Type | Length |U| Reserved (MUST be zero) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 // IPv4, IPv6 or unnumbered Component Interface Identifier // 286 | . . . | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 L: 1 bit 291 This bit must be set to 0. 293 Type 295 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 297 Type 10 (TBD): Component Interface identifier IPv4 298 Type 11 (TBD): Component Interface identifier IPv6 299 Type 12 (TBD): Component Interface identifier Unnumbered 301 Length 303 The Length contains the total length of the subobject in 304 bytes, including the Type and Length fields. The Length is 305 8 bytes for the Component Interface identifier types: IPv4 306 and Component Interface identifier Unnumbered. For Component 307 Interface identifier IPv6 type of sub-object, the length field 308 is 20 bytes. 310 U: 1 bit 312 This bit indicates the direction of the component interface. 313 It is 0 for the downstream interface. It is set to 1 for the 314 upstream interface and is only used for bi-directional LSPs. 316 4.1 Processing of Component Interface Identifier ERO Subobject 318 The Component Interface Identifier ERO subobject follows a subobject 319 containing the IP address, or the link identifier [RFC3477], 320 associated with the TE link on which it is to be used. It is used to 321 identify the component of a bundled TE Link. 323 The following SHOULD result in "Bad EXPLICIT_ROUTE object" error 324 being sent upstream by a node processing an ERO that contains the 325 Component Interface ID sub-object: 327 o) The first component interface identifier subobject is not 328 preceded by a sub-object containing an IPv4 or IPv6 address, or 329 an interface identifier [RFC3477], associated with a TE link. 331 o) The Component Interface Identifier ERO subobject follows a 332 subobject that has the L-bit set. 334 o) On unidirectional LSP setup, there is a Component Interface 335 Identifier ERO subobject with the U-bit set. 337 o) Two Component Interface Identifier ERO subobjects with the same 338 U-bit values exist. 340 If a node implements the component interface identifier subobject, it 341 MUST check if it represents a component interface in the bundled TE 342 Link specified in the preceding subobject that contains the IPv4/IPv6 343 address or interface identifier of the TE Link. If the content of the 344 component interface identifier subobject does not match a component 346 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 348 interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD 349 be reported as "Routing Problem" (error code 24). 351 If U-bit of the subobject being examined is cleared (0) and the 352 upstream interface specified in this subobject is acceptable, then 353 the value of the upstream component interface is translated locally 354 in the TLV of the IF_ID RSVP HOP object [RFC3471]. The local 355 decision normally used to select the upstream component link is 356 bypassed except for local translation into the outgoing interface 357 identifier from the received incoming remote interface identifier. If 358 this interface is not acceptable, a "Bad EXPLICIT_ROUTE object" error 359 SHOULD be reported as "Routing Problem" (error code 24). 361 If the U-bit of the subobject being examined is set (1), then the 362 value represents the component interface to be used for upstream 363 traffic associated with the bidirectional LSP. Again, if this 364 interface is not acceptable or if the request is not one for a 365 bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD be 366 reported as "Routing Problem" (error code 24). Otherwise, the 367 component interface IP address/ identifier is copied into a TLV sub- 368 object as part of the IF_ID RSVP_HOP object. The local decision 369 normally used to select the upstream component link is bypassed 370 except for local translation into the outgoing interface identifier 371 from the received incoming remote interface identifier. 373 The IF_ID RSVP_HOP object constructed as above MUST be included in 374 the corresponding outgoing Path message. 376 Note that, associated with a TE Link sub-object in the ERO, either 377 the (remote) upstream component interface or the (remote) downstream 378 component interface or both may be specified. As specified in 379 [RFC4201] there is no relationship between the TE Link type (numbered 380 or unnumbered) and the Link type of any one of its components. 382 The Component Interface Identifier ERO subobject is optional. 383 Similarly, presence of the Label ERO sub-objects is not mandatory 384 [RFC3471], [RFC3473]. Furthermore, component interface identifier 385 ERO subobject and Label ERO subobject may be included in the ERO 386 independently of each other. One of the following alternatives 387 applies: 389 o) When both sub-objects are absent, a node may select any 390 appropriate component link within the TE link and any label on the 391 selected component link. 393 o) When the Label subobject is only present for a bundled link, then 394 the selection of the component link within the bundle is a local 395 decision and the node may select any appropriate component link, 396 which can assume the label specified in the Label ERO. 398 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 400 o) When only the component interface identifier ERO subobject is 401 present, a node MUST select the component interface specified in 402 the ERO and may select any appropriate label value at the 403 specified component link. 405 o) When both component interface identifier ERO subobject and Label 406 ERO subobject are present, the node MUST select the locally 407 corresponding component link and the specified label value on that 408 component link. When present, both subobjects may appear in any 409 relative order to each other but they MUST appear after the TE 410 Link subobject that they refer to. 412 After processing, the component interface identifier subobjects are 413 removed from the ERO. 415 Inferred from above, the interface subobject should never be the 416 first subobject in a newly received message. If the component 417 interface subobject is the first subobject in a received ERO, then it 418 SHOULD be treated as a "Bad strict node" error. 420 Note: Information to construct the Component Interface ERO subobject 421 may come from the same mean used to populate the label ERO subobject. 422 Procedures by which an LSR at the head-end of an LSP obtains the 423 information needed to construct the Component Interface subobject are 424 outside the scope of this document. 426 5. Forward Compatibility Note 428 The extensions specified in this draft do not affect the processing 429 of the RRO, ERO at nodes that do not support them. A node that does 430 not support the Component Interface RRO subobject but that does 431 support Label subobject SHOULD only insert the Label subobject in the 432 RRO as per [RFC3471] and [RFC3473]. 434 A node that receives an ERO that contains a Component Link ID 435 subobject SHOULD send "Bad EXPLICIT_ROUTE object" if it does not 436 implement this subobject. 438 Per [RFC3209], Section 4.4.5, a non-compliant node that receives an 439 RRO that contains Component Interface Identifier sub-objects should 440 ignore and pass them on. This limits the full applicability of if 441 nodes traversed by the LSP are compliant with the proposed 442 extensions. 444 6. Security Considerations 446 This document does not introduce new security issues. The security 447 considerations pertaining to the original RSVP protocol [RFC2205] 448 remain relevant. 450 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 452 7. IANA Considerations 454 This document introduces the following RSVP protocol elements: 456 o) Component Interface Identifier RRO subobject of the Record Route 457 Object (RRO). The following Types are defined: 459 Type 10 (TBD): Component Interface identifier IPv4 460 Type 11 (TBD): Component Interface identifier IPv6 461 Type 12 (TBD): Component Interface identifier Unnumbered 463 o) Component Interface Identifier subobject of the Explicit Route 464 Object (ERO). The following Types are defined: 466 Type 10 (TBD): Component Interface identifier IPv4 467 Type 11 (TBD): Component Interface identifier IPv6 468 Type 12 (TBD): Component Interface identifier Unnumbered 470 o) A new "Component Link Recording desired" flag (value TBD) 471 of the LSP_ATTRIBUTES object [RFC4420] 473 8. References 475 8.1 Normative Reference 477 [RFC2205] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) 478 - Version 1, Functional Specification", RFC 2205, 479 September 1997. 481 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 482 Requirement Levels", RFC 2119, March 1997. 484 [RFC3209] D. Awduche, et al., "Extensions to RSVP for LSP Tunnels", 485 RFC 3209, December 2001. 487 [RFC3471] L. Berger, et al., "Generalized Multi-Protocol Label 488 Switching (GMPLS) Signaling Functional Description", RFC 489 3471, January 2003. 491 [RFC3473] L. Berger, et al., "Generalized Multi-Protocol Label 492 Switching (GMPLS) Signaling Resource ReserVation 493 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 494 3473, January 2003. 496 [RFC3477] K. Kompella, et al., "Signaling Unnumbered Links in 497 Resource ReSerVation Protocol - Traffic Engineering 498 (RSVP-TE)", RFC 3477, January 2003. 500 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 502 [RFC4201] K. Kompella, et al., "Link Bundling in MPLS Traffic 503 Engineering", RFC 4201, January 2003. 505 [RFC4420] A. Farrel, et al., "Encoding of Attributes for 506 Multiprotocol Label Switching (MPLS) Label Switched Path 507 (LSP) Establishment Using Resource ReserVation Protocol- 508 Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. 510 8.2 Informative Reference 512 [RFC3945] E. Mannie, et al., "Generalized Multi-Protocol Label 513 Switching (GMPLS) Architecture", RFC 3945, October 2004. 515 9. Author's Addresses 517 Anca Zamfir 518 Cisco Systems Inc. 519 2000 Innovation Dr., 520 Kanata, Ontario, K2K 3E8 521 Canada. 522 Phone: (613)-254-3484 523 Email: ancaz@cisco.com 525 Zafar Ali 526 Cisco Systems Inc. 527 2000 Innovation Dr., 528 Kanata, Ontario, K2K 3E8 529 Canada. 530 Phone: (613) 889-6158 531 Email: zali@cisco.com 533 Dimitri Papadimitriou 534 Alcatel-Lucent 535 Copernicuslaan 50 536 B-2018 Antwerpen 537 Belgium 538 Phone: +32 3 240-8491 539 Email: dimitri.papadimitriou@alcatel-lucent.be 541 Component Link Record. & Resource Control for TE Link Bundles Mar.2008 543 10. Full Copyright Statement 545 Copyright (C) The IETF Trust (2008). 547 This document is subject to the rights, licenses and restrictions 548 contained in BCP 78, and except as set forth therein, the authors 549 retain all their rights. 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 554 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 555 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 556 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 11. Intellectual Property 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at ietf- 581 ipr@ietf.org. 583 Acknowledgement 585 Funding for the RFC Editor function is provided by the IETF 586 Administrative Support Activity (IASA).