idnits 2.17.1 draft-takacs-ccamp-oam-configuration-fwk-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 530. 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 149: '...of OAM functions SHOULD be optional fo...' RFC 2119 keyword, line 150: '...network operator SHOULD be able to cho...' RFC 2119 keyword, line 153: '...-TP control pane MUST support the conf...' RFC 2119 keyword, line 156: '.... OAM functions SHOULD be configurabl...' 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 (October 27, 2008) is 5660 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: 'RFC3469' is defined on line 455, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GELS-Framework' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-CFM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-PBBTE' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-TP-FWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-TP-OAM-REQ' ** Downref: Normative reference to an Informational RFC: RFC 3469 ** Downref: Normative reference to an Informational RFC: RFC 4377 ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Takacs 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. Fedyk 5 Expires: April 30, 2009 Nortel 6 October 27, 2008 8 OAM Configuration Framework for GMPLS RSVP-TE 9 draft-takacs-ccamp-oam-configuration-fwk-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 30, 2009. 36 Abstract 38 OAM functions are essential to ensure that the desired service level 39 of traffic engineered connections are met. In certain technologies 40 OAM entities are inherently established once the connection is set 41 up. However other technologies, especially OAM for packet switched 42 networks, require an extra configuration step after connection 43 establishment to setup OAM entities. This document specifies 44 extensions to RSVP-TE to support the establishment and configuration 45 of OAM entities along with LSP signalling. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 7 58 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 7 59 3.2. OAM entities desired -- LSP Attributes flag . . . . . . . 8 60 3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 9 61 3.4. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 9 62 3.5. OAM configuration errors . . . . . . . . . . . . . . . . . 10 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 66 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 14 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 69 Intellectual Property and Copyright Statements . . . . . . . . . . 18 71 1. Introduction 73 Operations and Management (OAM) functions are essential to ensure 74 that the desired service level of traffic engineered connections are 75 met. In certain technologies OAM entities are inherently established 76 once the connection is set up. However other technologies, 77 especially OAM for packet switched networks, require an extra 78 configuration step after connection establishment to setup OAM 79 entities. When the GMPLS control plane is used for LSP establishment 80 it is desirable to bind OAM setup to connection establishment 81 signalling to avoid two separate management/configuration steps 82 (connection setup followed by OAM configuration) which increases 83 delay, processing and more importantly may be prune to 84 misconfiguration errors. 86 This document specifies extensions to the RSVP-TE protocol providing 87 a framework to configure and control OAM entities along with 88 capability to carry technology specific information. Extensions can 89 be grouped into generic elements that are applicable to any OAM 90 solution and technology specific elements that provide additional 91 configuration parameters only needed for a specific OAM technology. 92 This document specifies the technology agnostic elements that alone 93 can be used to establish OAM entities in the case no technology 94 specific information is needed, and specifies the way additional 95 technology specific OAM parameters are provided. 97 2. Motivation 99 When periodic messages are used for liveliness check of LSPs the 100 frequency of messages must be set properly fulfilling the 101 requirements of the service and/or meeting the detection time 102 boundaries posed by possible congruent connectivity check operations 103 of higher layer applications. Furthermore, for consistent 104 measurement of Service Level Agreements (SLAs) it may be required 105 that measurement points agree on a common probing rate to avoid 106 measurement problems. 108 For a network operator to be able to balance the trade-off in fast 109 failure detection and overhead it is beneficial to configure the 110 frequency of continuity check messages on a per LSP basis. 111 Additionally, to simplify network management and reduce the risk (and 112 impact) of misconfiguration, it is desirable to use LSP signaling to 113 configure OAM at the ends of the LSP automatically. 115 MPLS OAM requirements are described in [RFC4377]. It provides 116 requirements to create consistent OAM functionality for MPLS 117 networks. GMPLS OAM requirements are described in [GMPLS-OAM]. The 118 GMPLS OAM requirements are based on the MPLS OAM requirements 119 [RFC4377], in addition it also considers the existing OAM techniques 120 in non-packet networks. 122 The following list is an excerpt of MPLS OAM requirements documented 123 in [RFC4377]. Only a few requirements are discussed that bear a 124 direct relevance to the discussion set forth in this document. 126 o It is desired to support the automation of LSP defect detection. 127 It is especially important in cases where large numbers of LSPs 128 might be tested. 130 o In particular some LSPs may require automated ingress-LSR to 131 egress-LSR testing functionality, while others may not. 133 o Mechanisms are required to coordinate network responses to 134 defects. Such mechanisms may include alarm suppression, 135 translating defect signals at technology boundaries, and 136 synchronising defect detection times by setting appropriately 137 bounded detection timeframes. 139 MPLS-TP defines a profile of MPLS targeted at transport applications 140 [MPLS-TP-FWK]. This profile specifies the specific MPLS 141 characteristics and extensions required to meet transport 142 requirements, including providing additional OAM, survivability and 143 other maintenance functions not currently supported by MPLS. 144 Specific OAM requirements for MPLS-TP are specified in 146 [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane 147 to configure and control OAM entities. 149 o The use of OAM functions SHOULD be optional for the operator. A 150 network operator SHOULD be able to choose which OAM functions to 151 use and which Maintenance Entity to apply them to. 153 o The MPLS-TP control pane MUST support the configuration and 154 modification of OAM maintenance points as well as the activation/ 155 deactivation of OAM when the transport path is established or 156 modified. OAM functions SHOULD be configurable as part of 157 connectivity (LSP or PW) management. 159 Ethernet Connectivity Fault Management (CFM) defines an adjunct 160 connectivity monitoring OAM flow to check the liveliness of Ethernet 161 networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will 162 support explicitly-routed Ethernet connections. CFM can be used to 163 track the liveliness of PBB-TE connections and detect data plane 164 failures. In IETF the GMPLS controlled Ethernet Label Switching 165 (GELS) [GELS-Framework] work is extending the GMPLS control plane to 166 support the establishment of point-to-point PBB-TE data plane 167 connections. Without control plane support separate management 168 commands would be needed to configure and start CFM. 170 3. GMPLS RSVP-TE Extensions 172 3.1. Operation overview 174 Two types of Maintenance Poits (MPs) are disinguished: Maintenance 175 End Points (MEPs) and Maintenance Intermediate Points (MIPs). MEPs 176 are located at the ends of an LSP and are capable of initiating and 177 terminating OAM packets for Fault Management (FM) and Performance 178 Monitoring (PM). MIPs on the other hand are located at transit nodes 179 of an LSP and are capable of reacting to some OAM packets but 180 otherwise do not initiate packets. Maintenance Entity (ME) refers to 181 an association of MEPs and MIPs that are provisioned to monitor an 182 LSP. The ME association is achieved by configuring MPs of an ME with 183 the same unique ME ID. Each MEP must have unique identification (MEP 184 ID) within the ME. 186 When an LSP is signalled forwarding association is established 187 between endpoints and transit nodes via label bindings. This 188 association creates a context for the OAM entities monitoring the 189 LSP. On top of this association OAM entities may be configured with 190 an ME ID and MEP IDs. The ME ID may be used to detect 191 misconfiguration errors and leacking OAM traffic. Within the ME the 192 MEP ID can be used to demultiplex and identify the originating MEP of 193 OAM packets. Since MIPs do not originate OAM packets no specific 194 configuration is required for them. 196 In addition to the ME and MEP identification parameters pro-active 197 OAM functions (e.g., Continuity Check (CC), Performance Monitoring) 198 may have specific parameters requiring configuration as well. In 199 particular, the frequency of periodic CC packets and the measurement 200 interval for loss and delay measurements may need to be configured. 202 MEP 203 +-------------+ 204 |OAM Functions| 205 | FM | PM | 206 +------+------+ 207 | MEP ID | 208 +-------------+ 209 | ME ID | 210 +-------------+ 211 +-------------+ 212 | LSP | 213 +-------------+ 215 In some cases all the above parameters may be either derived form 216 some exiting information or pre-configured default values can be 217 used. In the simplest case the control plane needs to provide 218 information whether or not a ME with MPs need to be setup for the 219 signalled LSP. If OAM entities are created signalling must provide 220 means to activate/deactivate OAM message flows and associated alarms. 222 ME and MEP IDs as well as configuration of OAM functions are 223 technology specific, i.e., vary depending on the data plane 224 technology and the chosen OAM solution. In addition for any given 225 data plane technology a set of OAM solutions may be applicable. The 226 OAM configuration framework allows selecting a specific OAM solution 227 to be used for the signalled LSP and provides technology specific 228 TLVs to carry further detailed configuration information. 230 3.2. OAM entities desired -- LSP Attributes flag 232 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 233 indicate options and attributes of the LSP. The Flags field has 8 234 bits and hence is limited to differentiate only 8 options. [RFC4420] 235 defines a new object for RSVP-TE messages to allow the signalling of 236 arbitrary attribute parameters making RSVP-TE easily extensible to 237 support new applications. Furthermore, [RFC4420] allows options and 238 attributes that do not need to be acted on by all Label Switched 239 Routers (LSRs) along the path of the LSP. In particular, these 240 options and attributes may apply only to key LSRs on the path such as 241 the ingress LSR and egress LSR. Options and attributes can be 242 signalled transparently, and only examined at those points that need 243 to act on them. The LSP_ATTRIBUTES object and the 244 LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide 245 means to signal LSP attributes and options in the form of TLVs. 246 Options and attributes signalled in the LSP_ATTRIBUTES object can be 247 passed transparently through LSRs not supporting a particular option 248 or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES 249 object must be examined and processed by each LSR. One TLV is 250 defined in [RFC4420]: the Attributes Flags TLV. 252 A new bit (10 IANA to assign): "OAM entities desired" is allocated in 253 the LSP Attributes Flags TLV. If the "OAM entities desired" bit is 254 set it is indicating that the establishment of OAM entities are 255 required at the endpoints of the signalled LSP. If the establishment 256 of OAM entities is not supported an error must be generated: "OAM 257 Problem/OAM establishment not supported". 259 If the "OAM entities desired" bit is set and additional parameters 260 are needed to configure the OAM entities an OAM Configuration TLV may 261 be included in the LSP_ATTRIBUTES object. 263 3.3. OAM Configuration TLV 265 This TLV specifies which OAM technology/method should be used for the 266 LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES 267 object in Path messages. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type (2) (IANA) | Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | OAM Type | OAM Function | Reserved (set to all 0s) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Type: indicates a new type: the OAM Configuration TLV (2) (IANA to 278 assign). 280 OAM Type: specifies the technology specify OAM method. If the 281 requested OAM method is not supported an error must be generated: 282 "OAM Problem/Unsupported OAM Type". 284 This document defines no types. The receiving node based on the OAM 285 Type will check if a corresponding technology specific OAM 286 configuration TLV is included. 288 OAM Function Flags: specifies proactive OAM functions (e.g., 289 connectivity monitoring, loss and delay measurement) that should be 290 established and configured. If the selected OAM Function(s) is(are) 291 not supported an error must be generated: "OAM Problem/Unsupported 292 OAM Function". 294 This document defines the following flags. 296 OAM Function Flag Description 297 --------------------- --------------------------- 298 0 Connectivity Monitoring 299 1-7 Reserved 301 3.4. Monitoring Disabled - Admin_Status bit 303 Administrative Status Information is carried in the ADMIN_STATUS 304 Object. The Administrative Status Information is described in 305 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 306 [RFC3473]. 308 One bit is allocated for the administrative control of OAM 309 monitoring. In addition to the Reflect (R) bit, 7 bits are currently 310 occupied (assigned by IANA or temporarily blocked by work in progress 311 Internet drafts). As the 24th bit (IANA to assign) this draft 312 introduces the Monitoring Disabled (M) bit. When this bit is set the 313 monitoring and OAM triggered alarms of the LSP are disabled (e.g., no 314 continuity check messages are sent). 316 3.5. OAM configuration errors 318 To handle OAM configuration errors a new Error Code (IANA to assign) 319 "OAM Problem" is introduced. To refer to specific problems a set of 320 Error Values is defined. 322 If a nodes does not support the establishment of OAM entities via 323 RSVP-TE signalling it must use the error value (IANA to assign): "OAM 324 establishment not supported" in the PathErr message. 326 If a nodes does not support a specific OAM technology/solution it 327 must use the error value (IANA to assign): "Unsupported OAM Type" in 328 the PathErr message. 330 If a nodes does not support a specific OAM Function it must use the 331 error value (IANA to assign): "Unsupported OAM Function" in the 332 PathErr message. 334 4. IANA Considerations 336 One bit (Monitoring Disabled (M)) needs to be allocated in the 337 ADMIN_STATUS Object. 339 One bit ("OAM entities desired") needs to be allocated in the LSP 340 Attributes Flag Registry. 342 This document specifies one new TLVs to be carried in the 343 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages: 344 OAM Configuration TLV. 346 One new Error Code: "OAM Problem" and three new values: "OAM 347 establishment not supported", "Unsupported OAM Type" and "Unsupported 348 OAM Function" needs to be assigned. 350 5. Security Considerations 352 The signalling of OAM related parameters and the automatic 353 establishment of OAM entities introduces additional security 354 considerations to those discussed in [RFC3473]. In particular, a 355 network element could be overloaded, if an attacker would request 356 liveliness monitoring, with frequent periodic messages, for a high 357 number of LSPs, targeting a single network element. 359 Security aspects will be covered in more detailed in subsequent 360 versions of this document. 362 6. Acknowledgements 364 The authors would like to thank Francesco Fondelli, Adrian Farrel, 365 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 366 comments. 368 Appendix A. Discussion on alternatives 370 This appendix summarises the discussions after IETF-71 about the way 371 OAM configuration information should be carried in RSVP-TE. 373 The first question is how the requirement for OAM establishment is 374 signalled and how the operation of OAM is controlled. There is a 375 straightforward way to achieve these using existing objects and 376 fields: 378 o Use one or more OAM flags in the LSP Attributes Flag TLV within 379 the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that 380 OAM entities for the LSP need to be established. If for any 381 reason this cannot be done a notification is sent or an error is 382 raised. 384 o Once the LSP with the desired OAM entities is established OAM 385 operation may be controlled using one or more flags in the 386 ADMIN_STATUS object. For instance, the generation of connectivity 387 monitoring messages can be disabled/enabled by setting/clearing a 388 flag in the ADMIN_STATUS object. 390 However, there are two alternatives when it comes to signalling the 391 actual configuration parameters of OAM entities. 393 o Extension of the LSP_ATTRIBUTES object with new TLVs. 395 o Definition of a new RSVP-TE object to carry OAM information. 397 In the first case, a new OAM configuration TLV is defined in the 398 LSP_ATTRIBUTES object. This TLV would provide the detailed 399 information needed for LSPs with a set OAM flag in the LSP Attributes 400 Flag TLV. The rationale for this approach is that in addition to 401 setting flags the LSP_ATTRIBUTES object may carry complementary 402 information for all or some of the flags set. Furthermore, as top 403 level RSVP-TE objects may become scarce resources, it seems to be 404 beneficial not to allocate new RSVP-TE objects for the purpose of 405 providing detailed information for new LSP Attribute Flags. 406 Currently there is only one TLV, the Attributes Flag TLV, defined in 407 the LSP_ATTRIBUTES object. Defining a new TLV associated with one of 408 the flags would make a precedence and possibly be a guideline for 409 similar future extensions. 411 The other alternative would be to allocate a dedicated object for OAM 412 configuration information. The rationale for this is that the 413 complex information that may be required for OAM configuration would 414 unnecessarily add complexity to LSP_ATTRIBUTES/ 415 LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms. 417 Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to 418 carry configuration information of data plane entities, thus a new 419 object like an "OAM_SPEC" may be a better fit to existing protocol 420 elements. 422 The authors of this document favour the first alternative (adding new 423 TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which 424 alternative to select for standardisation is up for the working group 425 to decide. In any case, the information to be carried would be the 426 same or very similar for both alternatives. 428 7. References 430 [GELS-Framework] 431 "GMPLS Ethernet Label Switching Architecture and 432 Framework", Internet Draft, work in progress. 434 [GMPLS-OAM] 435 "OAM Requirements for Generalized Multi-Protocol Label 436 Switching (GMPLS) Networks", Internet Draft, work in 437 progress. 439 [IEEE-CFM] 440 "IEEE 802.1ag, Draft Standard for Connectivity Fault 441 Management", work in progress. 443 [IEEE-PBBTE] 444 "IEEE 802.1Qay Draft Standard for Provider Backbone 445 Bridging Traffic Engineering", work in progress. 447 [MPLS-TP-FWK] 448 "A Framework for MPLS in Transport Networks", Internet 449 Draft, work in progress. 451 [MPLS-TP-OAM-REQ] 452 "Requirements for OAM in MPLS Transport Networks", 453 Internet Draft, work in progress. 455 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 456 Recovery", RFC 3469, February 2003. 458 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 459 Signaling Functional Description", RFC 3471, January 2003. 461 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 462 Signaling Resource ReserVation Protocol-Traffic 463 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 465 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 466 Protocol Label Switched (MPLS) Networks", RFC 4377, 467 February 2006. 469 [RFC4420] "Encoding of Attributes for Multiprotocol Label Switching 470 (MPLS) Label Switched Path (LSP) Establishment Using 471 Resource ReserVation Protocol-Traffic Engineering 472 (RSVP-TE)", RFC 4420, February 2006. 474 Authors' Addresses 476 Attila Takacs 477 Ericsson 478 Laborc u. 1. 479 Budapest, 1037 480 Hungary 482 Email: attila.takacs@ericsson.com 484 Don Fedyk 485 Nortel 486 600 Technology Park Drive 487 Billerica, MA 01821 488 USA 490 Email: dwfedyk@nortel.com 492 Full Copyright Statement 494 Copyright (C) The IETF Trust (2008). 496 This document is subject to the rights, licenses and restrictions 497 contained in BCP 78, and except as set forth therein, the authors 498 retain all their rights. 500 This document and the information contained herein are provided on an 501 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 502 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 503 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 504 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 505 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 506 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 508 Intellectual Property 510 The IETF takes no position regarding the validity or scope of any 511 Intellectual Property Rights or other rights that might be claimed to 512 pertain to the implementation or use of the technology described in 513 this document or the extent to which any license under such rights 514 might or might not be available; nor does it represent that it has 515 made any independent effort to identify any such rights. Information 516 on the procedures with respect to rights in RFC documents can be 517 found in BCP 78 and BCP 79. 519 Copies of IPR disclosures made to the IETF Secretariat and any 520 assurances of licenses to be made available, or the result of an 521 attempt made to obtain a general license or permission for the use of 522 such proprietary rights by implementers or users of this 523 specification can be obtained from the IETF on-line IPR repository at 524 http://www.ietf.org/ipr. 526 The IETF invites any interested party to bring to its attention any 527 copyrights, patents or patent applications, or other proprietary 528 rights that may cover technology that may be required to implement 529 this standard. Please address the information to the IETF at 530 ietf-ipr@ietf.org.