idnits 2.17.1 draft-vigoureux-mpls-tp-oam-requirements-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 653. 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 ([5]), 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 (October 31, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group M. Vigoureux (Editor) 2 Internet Draft Alcatel-Lucent 3 Intended status: Informational 4 Expires: April 2009 D. Ward (Editor) 5 Cisco Systems, Inc. 7 M. Betts (Editor) 8 Nortel Networks 10 October 31, 2008 12 Requirements for OAM in MPLS Transport Networks 13 draft-vigoureux-mpls-tp-oam-requirements-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on April 31, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document lists the requirements for Operations, Administration 46 and Maintenance functionality in MPLS networks that are used for 47 packet transport services and network operations. 49 These requirements are derived from the set of requirements specified 50 by ITU-T and first published in the ITU-T Supplement Y.Sup4 [5]. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [1]. 58 Table of Contents 60 1. Introduction...................................................3 61 1.1. Terminology...............................................3 62 1.2. Definitions...............................................4 63 1.3. Context and Motivations...................................4 64 2. OAM Requirements...............................................5 65 2.1. Architectural Requirements................................6 66 2.2. Functional Requirements...................................7 67 2.2.1. General requirements.................................8 68 2.2.2. Connectivity and Continuity Verification.............8 69 2.2.3. Client Failure Indication............................8 70 2.2.4. Remote Defect Indication.............................8 71 2.2.5. Alarm Suppression....................................9 72 2.2.6. Packet Loss..........................................9 73 2.2.7. Delay Measurement....................................9 74 2.2.8. Route Determination.................................10 75 2.2.9. Diagnostic..........................................10 76 2.3. Operational Requirements.................................10 77 2.4. Performance Requirements.................................11 78 3. Security Considerations.......................................11 79 4. Congestion Considerations.....................................12 80 5. IANA Considerations...........................................12 81 6. Acknowledgments...............................................12 82 7. References....................................................13 83 7.1. Normative References.....................................13 84 7.2. Informative References...................................13 85 Authors' Addresses...............................................13 86 Contributing Authors' Addresses..................................14 87 Intellectual Property Statement..................................15 88 Disclaimer of Validity...........................................16 90 1. Introduction 92 This document lists the requirements for Operations, Administration 93 and Maintenance functionality in MPLS networks that are used for 94 packet transport services and network operations. 96 1.1. Terminology 98 AC Attachment Circuit 100 CSF Client Signal Fail 102 FCAPS Fault, Configuration, Accounting, Performance, Security 104 LER Label Edge Router 106 LSP Label Switched Path 108 LSR Label Switching Router 110 ME Maintenance Entity 112 MEP Maintenance End Point 114 MIP Maintenance Intermediate Point 116 MP Maintenance Point 118 MS-PW Multi Segment Pseudowire 120 OAM Operations, Administration and Maintenance 122 PE Provider Edge 124 PSN Packet Switched Network 126 PW Pseudowire 128 SLA Service Level Agreement 130 SS-PW Single Segment Pseudowire 132 S-PE PW Switching Provider Edge 134 T-PE PW Terminating Provider Edge 136 TCME Tandem Connection Maintenance Entity 138 1.2. Definitions 140 In this document we refer to a fault as the inability of a function 141 to perform a required action. This does not include an inability due 142 to preventive maintenance, lack of external resources, or planned 143 actions. See also ITU-T G.806 [3]. 145 In this document we refer to a defect as the situation for which 146 density of anomalies has reached a level where the ability to perform 147 a required function has been interrupted. See also ITU-T G.806 [3]. 149 In this document, we refer to MPLS Transport Profile (MPLS-TP) as the 150 set of MPLS functions used to support packet transport services and 151 network operations. 153 In this document we refer to a MPLS Section as a network segment 154 between two LSRs that are immediately adjacent at the MPLS layer. 156 For definitions of OAM functional components such as Maintenance 157 Point, Maintenance End Point and Maintenance Intermediate Point, 158 please refer to [7]. 159 Additional definitions can also be found in [8]. 161 1.3. Context and Motivations 163 Important attributes of MPLS-TP are that 165 o it is able to function regardless of which client signals are 166 using its connectivity service or over which transmission media it 167 is running. The client, transport network and server layers are, 168 from a functional point of view, independent layer networks. That 169 is, demarcation points exist between MPLS-TP and the client layer, 170 and between MPLS-TP and the underlying server layer. 172 o it provides means to commit to Service Level Agreements (SLAs) 173 negotiated with customers, as well as means to monitor compliance 174 with these SLAs. 176 o it is consistent with existing transport network OAM models. 178 In the context of MPLS-TP, the rationale for OAM mechanisms are 179 twofold as they can serve: 181 o as a network-oriented mechanism (used by a transport network 182 operator) to monitor his network infrastructure and to implement 183 internal mechanisms in order to enhance the general behaviour and 184 the level of performance of his network (e.g. protection mechanism 185 in case of node or link failure). For example fault localization 186 is typically associated to this use case. 188 o as a service-oriented mechanism (used by a transport service 189 provider) to monitor his offered services to end customers in 190 order to be able to react rapidly in case of a problem and to be 191 able to verify some of the SLA parameters (i.e. performance 192 monitoring) negotiated with the end customer. Note that a 193 transport service could be provided over several networks or 194 administrative domains that may not be all owned and managed by 195 the same transport service provider. 197 More generally, OAM is an important and fundamental functionality in 198 transport networks as it contributes to: 200 o the reduction of operational complexity and costs, by allowing 201 efficient and automatic detection, localisation, handling, and 202 diagnosis of defects, and by minimizing service interruptions and 203 operational repair times. 205 o the enhancement of network availability, by ensuring that defects, 206 for example resulting in misdirected customer traffic are 207 detected, diagnosed and dealt with before a customer reports the 208 problem. 210 o meet service and performance objectives, by running OAM 211 functionality which allows SLA verification in a multi-maintenance 212 domain environment and allows the determination of service 213 degradation due to, for example, packet delay or packet loss. 215 This is achieved through the support of FCAPS functionality, as 216 described in ITU-T M.3400 [2], itself relying on OAM related 217 information. 219 2. OAM Requirements 221 This section lists the requirements by which the OAM functionality of 222 MPLS-TP should abide. Some requirements for this application are 223 similar to some of those listed in RFC 4377 [6]. 225 The requirements listed below may be met by one or more OAM 226 protocols, the definition or selection of these protocols is outside 227 the scope of this document. However, the specified solution MUST 228 inter-work with the existing MPLS and PW OAM protocols. 230 2.1. Architectural Requirements 232 OAM functions SHOULD be independent of the underlying tunnelling or 233 point-to-point technology or transmission media. 235 OAM functions SHOULD be independent of the service a pseudowire may 236 emulate. 238 The set of OAM functions operated on each Maintenance Entity SHOULD 239 be independent one from another. 240 Note that independence should not be understood here in terms of 241 isolation but in terms of separate running processes. There should be 242 one OAM process running per Maintenance Entity but different OAM 243 running processes could interact (e.g. alarm summarization). 245 OAM functionality MAY be deployed in a variety of environments. In 246 some of these IP routing and forwarding capabilities are inherently 247 present (e.g. IP/MPLS) and the OAM functionality MUST also support 248 their use. Other deployment scenarios exist where IP routing and 249 forwarding capabilities are not necessarily present (e.g. MPLS-TP). 250 In these latter cases, the operation of OAM functions MUST NOT rely 251 on IP routing and forwarding capabilities. Further, it is REQUIRED by 252 this document that OAM interoperability is achieved across these 253 environments. It is also REQUIRED by this document that the two above 254 requirements are still met and still hold when interoperability is 255 achieved. 257 Furthermore, in case OAM packets need to incorporate identification 258 information of source and/or destination nodes, an IP addressing 259 structure MUST be supported. 261 When MPLS-TP is run with IP routing and forwarding capabilities, all 262 existing IP/MPLS OAM functionality (e.g. LSP-Ping, BFD and VCCV) MUST 263 be able to operate seamlessly. 265 OAM functions MUST operate and be configurable even in the absence of 266 a control plane. Conversely, OAM functions SHOULD be configurable as 267 part of connectivity (LSP or PW) management. Note that means for 268 configuring OAM functions and for connectivity management are outside 269 the scope of this document. 271 The service emulated by a single segment or a multi-segment 272 pseudowire may span multiple domains. A LSP may also span multiple 273 domains. It MUST be possible to perform OAM functions on a per domain 274 basis and across multiple domains. More generally it MUST be possible 275 to perform OAM functions between any two switching elements of a PW 276 or of a LSP. This is referred to as segment (or tandem connection) 277 monitoring (see [7]). Furthermore, in case of a fault or defect on 278 the service, means MUST be available for the service provider to be 279 informed of the fault even if the fault is located outside of his 280 domain. 282 OAM functions operate in the data plane. OAM packets MUST run in- 283 band. That is, OAM packets for a specific Maintenance Entity MUST 284 follow the exact same data path as user traffic of that Maintenance 285 Entity. This is known as fate sharing. 287 It MUST be possible to discriminate data traffic from OAM packets. 288 This includes a means to differentiate OAM packets from user traffic 289 as well as the capability to apply specific treatment, to OAM 290 packets, at the MIPs or MEPs targeted by these OAM packets. 292 As part of the design of OAM mechanisms for MPLS-TP, a mechanism that 293 enables the realization of a channel for general purpose signalling, 294 e.g. for control, management and OAM information, associated with the 295 data plane paths, MUST be provided. Such mechanism SHOULD support the 296 operation of existing IP/MPLS OAM. 298 OAM functions MUST be able to be used for PWs, LSPs and Sections. 299 Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to 300 run on each LSP, regardless of the label stack depth. 302 2.2. Functional Requirements 304 Hereafter are listed the required functions composing the MPLS-TP OAM 305 tool-set. The list may not be exhaustive and as such the OAM 306 mechanisms developed in support of the identified requirements SHALL 307 be extensible and thus SHALL NOT preclude the definition of 308 additional OAM functions in the future. Furthermore, the design of 309 OAM mechanisms for MPLS-TP MUST allow the ability to support vendor 310 specific and experimental OAM functions. Vendor specific and 311 experimental OAM functions MUST be disabled by default and explicitly 312 enabled by a service provider or network operator, between nodes that 313 support them. 315 Moreover, the use of OAM functions SHOULD be optional for the service 316 provider or network operator. A network operator or service provider 317 SHOULD be able to choose which OAM functions to use and which 318 Maintenance Entities to apply them to. 320 Note that the functions listed below can serve the purpose of fault 321 and/or performance management. For example, connectivity verification 322 can be used for fault management application by detecting failure 323 conditions, but may also be used for performance management 324 application through its contribution to the evaluation of performance 325 metrics (e.g. unavailability time). Nevertheless, it is outside the 326 scope of this document to specify which function should be used for 327 which application. 329 2.2.1. General requirements 331 If a defect or fault occurs, mechanisms MUST be provided to detect 332 it, diagnose it, localize it, and notify the appropriate entities. 333 Corrective actions SHOULD be taken according to the type of defect or 334 fault. 336 In the case of the PW Maintenance Entity, OAM mechanisms SHOULD be 337 provided to ensure that customers do not have to detect faults. The 338 OAM functions SHOULD allow the service provider to automatically 339 detect and notify the faults associated with a PW Maintenance Entity. 341 2.2.2. Connectivity and Continuity Verification 343 The MPLS-TP OAM tool-set MUST provide a function to enable service 344 providers to detect loss of continuity but also mis-connectivity 345 between two points of a Maintenance Entity. 347 2.2.3. Client Failure Indication 349 The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to 350 propagate a client failure indication to its peer MEP when alarm 351 suppression in the client layer is not supported. 353 In cases where the OAM of the native service of an AC or a PW type 354 does not provide mechanisms to propagate failure condition 355 information, while a downstream indication of such state is needed, 356 MPLS-TP OAM SHOULD provide mechanisms for propagating AC failures and 357 their clearance across a MPLS-TP domain. 359 2.2.4. Remote Defect Indication 361 The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to 362 notify its peer MEP of the detection of a defect on a bi-directional 363 connection between them. 365 2.2.5. Alarm Suppression 367 The MPLS-TP OAM tool-set MUST provide a function to enable a server 368 layer MEP to notify a failure condition or an administrative locking 369 to its client layer MEP(s) in order to suppress alarms that may be 370 generated by maintenance domains of the client layer as a result of 371 the failure condition or of the administrative locking in the server 372 layer. 374 The MPLS-TP OAM tool-set MUST allow the client layer to differentiate 375 between a defect condition and an administrative locking action at 376 the server layer ME. 378 The server layer MEP and the client layer MEPs MAY reside on the same 379 node or on different nodes. A mechanism MUST be provided for both 380 cases. 382 An alarm suppression and summarization mechanism MUST be provided. 383 For example, a fault detected at the LSP level MUST NOT trigger 384 various alarms at the PW level. 386 2.2.6. Packet Loss 388 The MPLS-TP OAM tool-set MUST provide a function to enable service 389 providers to measure packet loss ratio between a pair of MEPs. Packet 390 loss ratio is the ratio of the user-plane packets not delivered to 391 the total number of user-plane packets transmitted during a defined 392 time interval. The number of user-plane packets not delivered is the 393 difference between the number of user-plane packets transmitted by 394 the source node and the number of user-plane packets received at the 395 destination node. 397 2.2.7. Delay Measurement 399 The MPLS-TP OAM tool-set MUST provide a function to enable service 400 providers to measure the one-way or two-way delay of a packet 401 transmission between a pair of MEPs. Where, 403 o One-way packet delay is the time elapsed from the start of 404 transmission of the first bit of the packet by a source node until 405 the reception of the last bit of that packet by the destination 406 node. 408 o Two-way packet delay is the time elapsed from the start of 409 transmission of the first bit of the packet by a source node until 410 the reception of the last bit of the loop-backed packet by the 411 same source node, when the loopback is performed at the packet's 412 destination node. 414 2.2.8. Route Determination 416 The MPLS-TP OAM tool-set MUST provide a function to enable service 417 providers to determine the route of a connection across the MPLS 418 transport network. 420 2.2.9. Diagnostic 422 The MPLS-TP OAM tool-set MUST provide a function to enable service 423 providers to verify bandwidth throughput (and other diagnostic tests) 424 between a pair of MEPs. 426 2.3. Operational Requirements 428 OAM functions such as connectivity and continuity verification MUST 429 NOT rely on user traffic. Dedicated OAM flows SHOULD be used to 430 detect connectivity and continuity defects. See also ITU-T G.806 . 431 [3]. 432 This document does not mandate the use of a particular OAM function, 433 however, it is RECOMMENDED that connectivity and continuity 434 verification is performed on every Maintenance Entity in order to 435 reliably detect connectivity defects. 437 OAM functions MUST be applicable to bidirectional point-to-point 438 connections, and a subset of these OAM functions MUST be applicable 439 to unidirectional point-to-point and point-to-multipoint connections. 440 This subset is based on the nature of both the OAM functions and the 441 connections to which they can apply. 443 The following table describes how, on which Maintenance Entity and 444 between which points of the Maintenance Entity SHOULD the required 445 OAM functions be applied. In these tables, MEP stands for monitoring 446 from MEP to MEP, MIP stands for monitoring from MEP to MIP, U stands 447 for unidirectional, B stands for bidirectional. Crosses (x) indicate 448 the way the considered function should be applied, numbers indicate 449 the way the considered function should be applied while pointing to a 450 footnote providing additional details. 452 +-------------------------------------------+ 453 | on-demand | proactive | 454 |---------------------+----------+----------| 455 | MEP | MIP | MEP | MIP | 456 |----------+----------+----------+----------| 457 | P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP| 458 |-----+----+----------+----------+-----+----| 459 |U |B | U |U |B | U |U |B | U |U |B | U | 460 +----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 461 | cc verification | |x | | |x | |x |x | x | | | | 462 |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 463 | client fail. indic. | | | | | | | |x | | | | | 464 |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 465 | remote defect indic. | | | | | | | |x | | | | | 466 |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 467 | alarm suppression | | | | | | |x |x | x | | | | 468 |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 469 | packet loss measure | |1 | | | | |x |2 | x | | | | 470 |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 471 | delay measurement |x |3 | x | | | | | | | | | | 472 |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 473 | route determination | |x | | |x | | | | | | | | 474 |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 475 | diagnostic |x |x | x | | | | | | | | | | 476 +----------------------+-------------------------------------------+ 477 1: single-ended packet loss measurements 479 2: in both directions of the bi-directional connection 481 3: one-way and two-way packet delay measurements 483 Table 1 : OAM functions and their applicability scope 485 2.4. Performance Requirements 487 OAM functions SHOULD continue to meet their objectives regardless of 488 congestion conditions. See also ITU-T Y.1541 [4]. 490 Additional requirements will be incorporated in a future revision of 491 this document. 493 3. Security Considerations 495 Mechanisms SHOULD be provided to ensure that unauthorized access is 496 prevented from triggering any OAM function. 498 OAM messages MAY be authenticated. 500 An OAM packet for a Maintenance Entity MUST NOT leak out of the ME, 501 i.e. go beyond the terminating MEP. 503 4. Congestion Considerations 505 A mechanism (e.g. rate limiting) MUST be provided to prevent OAM 506 messages from causing congestion in the PSN. 508 5. IANA Considerations 510 There are no IANA actions required by this draft. 512 6. Acknowledgments 514 The authors would like to thank all members of the teams (the Joint 515 Working Team, the MPLS Interoperability Design Team in IETF and the 516 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 517 specification of MPLS Transport Profile. 519 7. References 521 7.1. Normative References 523 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 524 Levels", BCP 14, RFC 2119, March 1997 526 [2] ITU-T Recommendation M.3400 (2000), TMN management functions 528 [3] ITU-T Recommendation G.806 (2006), Characteristics of transport 529 equipment - Description methodology and generic functionality 531 [4] ITU-T Recommendation Y.1541 (2006), Network performance 532 objectives for IP-based services 534 [5] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T- 535 MPLS OAM and considerations for the application of IETF MPLS 536 Technology 538 7.2. Informative References 540 [6] Nadeau, T., et al., "Operations and Management (OAM) 541 Requirements for Multi-Protocol Label Switched (MPLS) 542 Networks", RFC 4377, February 2006 544 [7] Busi, I., Niven-Jenkins, B., "MPLS-TP OAM Framework and 545 Overview", draft-busi-mpls-tp-oam-framework, October 2008 547 [8] Niven-Jenkins, B., Brungard, D., Betts, M., "MPLS-TP 548 Requirements", draft-jenkins-mpls-mpls-tp-requirements, October 549 2008 551 Authors' Addresses 553 Martin Vigoureux 554 Alcatel-Lucent 556 Email: martin.vigoureux@alcatel-lucent.com 558 David Ward 559 Cisco Systems, Inc. 561 Email: dward@cisco.com 562 Malcolm Betts 563 Nortel Networks 565 Email: betts01@nortel.com 567 Contributing Authors' Addresses 569 Matthew Bocci 570 Alcatel-Lucent 572 Email: matthew.bocci@alcatel-lucent.com 574 Italo Busi 575 Alcatel-Lucent 577 Email: italo.busi@alcatel-lucent.it 579 Huub van Helvoort 580 Huawei Technologies Co.Ltd. 582 Email: hhelvoort@huawei.com 584 Marc Lasserre 585 Alcatel-Lucent 587 Email: mlasserre@alcatel-lucent.com 589 Lieven Levrau 590 Alcatel-Lucent 592 Email: llevrau@alcatel-lucent.com 594 Han Li 595 China Mobile Communications Corporation (CMCC) 596 Email: lihan@chinamobile.com 597 Julien Meuric 598 Orange 600 Email: julien.meuric@orange-ftgroup.com 602 Philippe Niger 603 Orange 605 Email: philippe.niger@orange-ftgroup.com 607 Benjamin Niven-Jenkins 608 BT 610 Email: benjamin.niven-jenkins@bt.com 612 Jing Ruiquan 613 China Telecom 614 Email: jingrq@ctbri.com.cn 616 Nurit Sprecher 617 Nokia-Siemens Networks 619 Email: nurit.sprecher@nsn.com 621 Yuji Tochio 622 Fujitsu 624 Email: tochio@jp.fujitsu.com 626 Yaacov Weingarten 627 Nokia-Siemens Networks 629 Email: yaacov.weingarten@nsn.com 631 Intellectual Property Statement 633 The IETF takes no position regarding the validity or scope of any 634 Intellectual Property Rights or other rights that might be claimed to 635 pertain to the implementation or use of the technology described in 636 this document or the extent to which any license under such rights 637 might or might not be available; nor does it represent that it has 638 made any independent effort to identify any such rights. Information 639 on the procedures with respect to rights in RFC documents can be 640 found in BCP 78 and BCP 79. 642 Copies of IPR disclosures made to the IETF Secretariat and any 643 assurances of licenses to be made available, or the result of an 644 attempt made to obtain a general license or permission for the use of 645 such proprietary rights by implementers or users of this 646 specification can be obtained from the IETF on-line IPR repository at 647 http://www.ietf.org/ipr. 649 The IETF invites any interested party to bring to its attention any 650 copyrights, patents or patent applications, or other proprietary 651 rights that may cover technology that may be required to implement 652 this standard. Please address the information to the IETF at ietf- 653 ipr@ietf.org. 655 Disclaimer of Validity 657 This document and the information contained herein are provided on an 658 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 659 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 660 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 661 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 662 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 663 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 665 Copyright Statement 667 Copyright (C) The IETF Trust (2008). 669 This document is subject to the rights, licenses and restrictions 670 contained in BCP 78, and except as set forth therein, the authors 671 retain all their rights. 673 Acknowledgment 675 Funding for the RFC Editor function is currently provided by the 676 Internet Society.