idnits 2.17.1 draft-ietf-mpls-explicit-resource-control-bundle-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 25, 2010) is 5084 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Anca Zamfir 2 Internet Draft Zafar Ali 3 Expires: November 24, 2010 Cisco Systems 4 Category: Standards Track Dimitri Papadimitriou 5 Alcatel-Lucent 6 May 25, 2010 8 Component Link Recording and Resource Control for TE Link Bundles 10 draft-ietf-mpls-explicit-resource-control-bundle-07.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. This document may contain 16 material from IETF Documents or IETF Contributions published or 17 made publicly available before November 10, 2008. The person(s) 18 controlling the copyright in some of this material may not have 19 granted the IETF Trust the right to allow modifications of such 20 material outside the IETF Standards Process. Without obtaining 21 an adequate license from the person(s) controlling the copyright 22 in such materials, this document may not be modified outside the 23 IETF Standards Process, and derivative works of it may not be 24 created outside the IETF Standards Process, except to format it 25 for publication as an RFC or to translate it into languages other 26 than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet- 36 Drafts as reference material or to cite them other than as "work 37 in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on November 24, 2010. 47 Abstract 49 Record Route is a useful administrative tool that has been used 50 extensively by the service providers. However, when TE links are 51 bundled, identification of label resource in Record Route Object 52 (RRO) is not enough for the administrative purpose. Network service 53 Component Link Record. & Resource Control for TE Link Bundles 55 providers would like to know the component link within a TE link that 56 is being used by a given LSP. In other words, when link bundling is 57 used, resource recording requires mechanisms to specify the component 58 link identifier, along with the TE link identifier and Label. As it 59 is not possible to record component link in the RRO, this draft 60 defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify 61 component link identifiers for resource recording purposes. 63 This draft also defines the Explicit Route Object (ERO) counterpart 64 of the RRO extension. The ERO extensions are needed to perform 65 explicit label/ resource control over bundled TE link. Hence, this 66 document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to 67 specify component link identifiers for explicit resource control and 68 recording over TE link bundles. 70 Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 Table of Contents 78 1. Terminology....................................................2 79 2. Introduction ..................................................3 80 3. LSP Resource Recording.........................................4 81 3.1 Component Interface Identifier RRO subobject...............4 82 3.2 Processing of Component Interface identifier RRO Subobject.5 83 4. Signaling Component Interface Identifier in ERO................6 84 4.1 Processing of Component Interface Identifier ERO Subobject.7 85 5. Forward Compatibility Note.....................................9 86 6. Security Considerations........................................9 87 7. IANA Considerations...........................................10 88 8. References....................................................10 89 8.1 Normative Reference.......................................10 90 8.2 Informative Reference.....................................11 91 9. Author's Addresses............................................11 92 10. Copyright Notice.............................................12 93 11. Legal........................................................12 94 Component Link Record. & Resource Control for TE Link Bundles 96 1. Terminology 98 TE Link: Unless specified otherwise, it refers to a bundled Traffic 99 Engineering link as defined in [RFC4201]. Furthermore, the terms TE 100 Link and bundled TE Link are used interchangeably in this draft. 102 Component (interface) link: refers (locally) to a component link as 103 part of a bundled TE link. A component link is numbered/ unnumbered 104 in its own right. For unnumbered component links, the component link 105 ID is assumed to be unique on an advertising node. For numbered 106 component links, the component link ID is assumed to be unique within 107 a domain. 109 Component Interface Identifier: Refers to an ID used to uniquely 110 identify a Component Interface. On a bundled link a combination of 111 is sufficient to unambiguously 112 identify the appropriate resources used by an LSP [RFC4201]. 114 2. Introduction 116 In GMPLS networks [RFC3945] that deals with unbundled (being either 117 PSC, L2SC, TDM or LSC) TE Links, one of the types of resources that 118 an LSP originator can control and would like to record are the TE 119 Link interfaces used by the LSP. The resource control and recording 120 is done by the use of an explicit route, i.e., Explicit Route (ERO) 121 Object and record Route, i.e., Record Route Object (RRO) object, 122 respectively. 124 Link Bundling, introduced in [RFC4201], is used to improve routing 125 scalability by reducing the amount of TE related information that 126 needs to be flooded and handled by IGP in a TE network. This is 127 accomplished by aggregating and abstracting the TE Link resource. In 128 some cases the complete resource identification is left as a local 129 decision. However, as described above there are cases when it is 130 desirable for a non-local (e.g., LSP head-end) node to identify 131 completely or partially the LSP resources. In either case, and for 132 administrative reasons, it is required to know which component link 133 within a bundled TE link has been used for a given LSP. 135 When link bundling is used to aggregate multiple component links into 136 a TE link, label is not the only resource that needs to be identified 137 and recorded. In other words, the TE Link and the Label specified in 138 the ERO/ RRO objects are not enough to completely identify the 139 resource. For the bundled TE link case, in order to fully specify the 140 resources on a link for a given LSP, the component link needs to be 141 specified along with the label. In the case of bi-directional LSPs 142 both upstream and downstream information may be specified. Therefore, 143 explicit resource control and recording over a bundled TE link also 144 requires ability to specify a component link within the TE link. 146 Component Link Record. & Resource Control for TE Link Bundles 148 This draft defines extensions to and describes the use of RSVP-TE 149 [RFC3209], [RFC3471], [RFC3473] to specify the component link 150 identifier for resource recording and explicit resource control over 151 TE link bundles. Specifically, in this document, component interface 152 identifier RRO and ERO subobjects are defined to complement their 153 Label RRO and ERO counterparts. Furthermore, procedures for 154 processing component interface identifier RRO and ERO subobjects and 155 how they can co-exist with the Label RRO and ERO subobjects are 156 specified. 158 3. LSP Resource Recording 160 LSP Resource Recording refers to the ability to record the resources 161 used by an LSP. 163 The procedure for unbundled numbered TE links is described in 164 [RFC3209] and for unbundled unnumbered TE links in [RFC3477]. For the 165 purpose of recording LSP resources used over bundled TE Links, the 166 Component Interface Identifier RRO sub-object is introduced. 168 3.1 Component Interface Identifier RRO subobject 170 A new subobject of the Record Route Object (RRO) is used to record 171 component interface identifier of a (bundled) TE Link. This subobject 172 has the following format: 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |L| Type | Length |U| Reserved (must be zero) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | | 180 // IPv4, IPv6 or unnumbered Component Interface Identifier // 181 | . . . | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 L: 1 bit 186 This bit must be set to 0. 188 Type 190 Type 10 (TBD): Component Interface identifier IPv4 191 Type 11 (TBD): Component Interface identifier IPv6 192 Type 12 (TBD): Component Interface identifier Unnumbered 194 Length 195 Component Link Record. & Resource Control for TE Link Bundles 197 The Length contains the total length of the subobject in 198 bytes, including the Type and Length fields. The Length is 199 8 bytes for the Component Interface identifier IPv4 and 200 Component Interface identifier Unnumbered types. For 201 Component Interface identifier IPv6 type of sub-object, the 202 length field is 20 bytes. 204 U: 1 bit 206 This bit indicates the direction of the component 207 interface. It is 0 for the downstream interface. It is 208 set to 1 for the upstream interface and is only used for 209 bi-directional LSPs. 211 3.2 Processing of Component Interface identifier RRO Subobject 213 If a node desires component link recording, the "Component Link 214 Recording desired" flag (value TBD) should be set in the 215 LSP_ATTRIBUTES object, object that is defined in [RFC5420]. 217 Setting of "Component Link Recording desired" flag is independent of 218 the Label Recording flag in SESSION_ATTRIBUTE object as specified in 219 [RFC3209]. Nevertheless, the following combinations are valid: 221 1) If both Label and Component Link flags are clear, then neither 222 Labels nor Component Links are recorded. 224 2) If Label Recording flag is set and Component Link flag is 225 clear, then only Label Recording is performed as defined in 226 [RFC3209]. 228 3) If Label Recording flag is clear and Component Link flag is 229 set, then Component Link Recording is performed as defined in this 230 proposal. 232 4) If both Label Recording and Component Link flags are set, then 233 Label Recording is performed as defined in [RFC3209] and also 234 Component Link recording is performed as defined in this proposal. 236 In most cases, a node initiates recording for a given LSP by adding 237 the RRO to the Path message. If the node desires Component Link 238 recording and if the outgoing TE link is bundled, then the initial 239 RRO contains the Component Link identifier (numbered or unnumbered) 240 as selected by the sender. As well, the Component Link Recording 241 desired flag is set in the LSP_ATTRIBUTE object. If the node also 242 desires label recording, it sets the Label_Recording flag in the 243 SESSION_ATTRIBUTE object. 245 Component Link Record. & Resource Control for TE Link Bundles 247 When a Path message with the "Component Link Recording desired" flag 248 set is received by an intermediate node, if a new Path message is to 249 be sent for a downstream bundled TE link, the node adds a new 250 Component Link subobject to the RECORD_ROUTE object (RRO) and appends 251 the resulting RRO to the Path message before transmission. 253 Note also that, unlike Labels, Component Link identifiers are always 254 known on receipt of the Path message. 256 When the destination node of an RSVP session receives a Path message 257 with an RRO and the "Component Link Recording desired" flag set, this 258 indicates that the sender node needs TE route as well as component 259 link recording. The destination node initiates the RRO process by 260 adding an RRO to Resv messages. The processing mirrors that of the 261 Path messages 263 The Component Interface Record subobject is pushed onto the 264 RECORD_ROUTE object (RRO) prior to pushing on the node's IP address. 265 A node MUST NOT push on a Component Interface Record subobject 266 without also pushing on the IP address or unnumbered Interface Id 267 subobject that identifies the TE Link. 269 When component interfaces are recorded for bi-directional LSPs, 270 component interface RRO subobjects for both downstream and upstream 271 interfaces MUST be included. 273 4. Signaling Component Interface Identifier in ERO 275 A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used 276 to specify component interface identifier of a bundled TE Link. 278 This Component Interface Identifier subobject has the following 279 format: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |L| Type | Length |U| Reserved (MUST be zero) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 // IPv4, IPv6 or unnumbered Component Interface Identifier // 288 | . . . | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 L: 1 bit 293 This bit must be set to 0. 295 Type 296 Component Link Record. & Resource Control for TE Link Bundles 298 Type 10 (TBD): Component Interface identifier IPv4 299 Type 11 (TBD): Component Interface identifier IPv6 300 Type 12 (TBD): Component Interface identifier Unnumbered 302 Length 304 The Length contains the total length of the subobject in 305 bytes, including the Type and Length fields. The Length is 306 8 bytes for the Component Interface identifier types: IPv4 307 and Component Interface identifier Unnumbered. For Component 308 Interface identifier IPv6 type of sub-object, the length field 309 is 20 bytes. 311 U: 1 bit 313 This bit indicates the direction of the component interface. 314 It is 0 for the downstream interface. It is set to 1 for the 315 upstream interface and is only used for bi-directional LSPs. 317 4.1 Processing of Component Interface Identifier ERO Subobject 319 The Component Interface Identifier ERO subobject follows a subobject 320 containing the IP address, or the link identifier [RFC3477], 321 associated with the TE link on which it is to be used. It is used to 322 identify the component of a bundled TE Link. 324 The following SHOULD result in "Bad EXPLICIT_ROUTE object" error 325 being sent upstream by a node processing an ERO that contains the 326 Component Interface ID sub-object: 328 o) The first component interface identifier subobject is not 329 preceded by a sub-object containing an IPv4 or IPv6 address, or 330 an interface identifier [RFC3477], associated with a TE link. 332 o) The Component Interface Identifier ERO subobject follows a 333 subobject that has the L-bit set. 335 o) On unidirectional LSP setup, there is a Component Interface 336 Identifier ERO subobject with the U-bit set. 338 o) Two Component Interface Identifier ERO subobjects with the same 339 U-bit values exist. 341 If a node implements the component interface identifier subobject, it 342 MUST check if it represents a component interface in the bundled TE 343 Link specified in the preceding subobject that contains the IPv4/IPv6 344 address or interface identifier of the TE Link. If the content of the 345 component interface identifier subobject does not match a component 346 Component Link Record. & Resource Control for TE Link Bundles 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 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 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 [RFC5420] 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 502 [RFC4201] K. Kompella, et al., "Link Bundling in MPLS Traffic 503 Engineering", RFC 4201, January 2003. 505 [RFC5420] 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 5420. 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 Email: ancaz@cisco.com 521 Zafar Ali 522 Cisco systems, Inc., 523 Email: zali@cisco.com 525 Dimitri Papadimitriou 526 Email: dimitri.papadimitriou@alcatel-lucent.be 527 Component Link Record. & Resource Control for TE Link Bundles 529 10. Copyright Notice 531 Copyright (c) 2010 IETF Trust and the persons identified as the 532 document authors. All rights reserved. 534 This document is subject to BCP 78 and the IETF Trust's Legal 535 Provisions Relating to IETF Documents 536 (http://trustee.ietf.org/license-info) in effect on the 537 date of publication of this document. Please review these documents 538 carefully, as they describe your rights and 539 restrictions with respect to this document. Code Components 540 extracted from this document must include Simplified BSD License 541 text as described in Section 4.e of the Trust Legal Provisions 542 and are provided without warranty as described in the BSD 543 License. 545 11. Legal 547 This documents and the information contained therein are provided 548 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 549 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 550 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 551 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 552 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT 553 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 554 OR FITNESS FOR A PARTICULAR PURPOSE. 556 Acknowledgement 558 Funding for the RFC Editor function is provided by the IETF 559 Administrative Support Activity (IASA).