Network Working Group Sami Boutros (Ed.) Internet Draft Siva Sivabalan(Ed.) Intended status: Standards Track George Swallow Expires: September 2009 David Ward Stewart Bryant Cisco Systems, Inc. March 9, 2009 Performance Monitoring of MPLS Transport Profile LSP draft-boutros-mpls-tp-performance-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 9, 2009. Abstract This document specifies an extension to MPLS Operation, Administration, and Maintenance (OAM) for monitoring the performance of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) with respect to packet loss and unidirectional delay/jitter. Table of Contents Boutros Expires September 9, 2009 [Page 1] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 1. Introduction...................................................2 2. Terminology....................................................4 3. MPLS-TP Performance Monitor Mechanism..........................5 4. MPLS-OAM Performance Message...................................5 4.1. In-band Message Identification............................5 4.2. Out-of-band Message Identification........................6 4.3. MPLS-OAM Performance control Message Format...............6 4.4. Performance Request TLV...................................8 4.5. Packet Loss Reporting TLV.................................9 4.6. Performance Removal.......................................9 4.7. MPLS-OAM PF Packet........................................9 4.8. Monitoring regular PW packets............................10 4.9. Network Management System................................10 5. Operation.....................................................11 6. Security Considerations.......................................12 7. IANA Considerations...........................................12 8. References....................................................12 8.1. Normative References.....................................12 8.2. Informative References...................................13 Author's Addresses...............................................14 Full Copyright Statement.........................................14 Intellectual Property Statement..................................15 1. Introduction In traditional transport networks, circuits such as T1 lines are provisioned on multiple switches, and service providers should be able to monitor the performance of such circuits for management purpose. For example, when performance of a primary circuit degrades backup circuit may be activated. An MPLS-TP bidirectional LSPs emulate the traditional transport circuits and hence should provide the same performance measurement capability. In this document, an MPLS-TP LSP means either an MPLS transport LSP or an MPLS Pseudowire (PW). This document specifies an MPLS-TP LSP performance monitoring scheme that is based on two new types of MPLS-OAM packets called "MPLS-OAM Performance Control(PC)" and "MPLS-OAM Performance Flow(PF)". These packets are sent at a rate that is acceptable to both sender and receiver. The MPLS-OAM PC packets are used to setup an MPLS-TP LSP for performance monitoring, and the MPLS-OAM PF packets are used as the probes for collecting performance data. Performance can be monitored using one of the two following modes: Boutros Expires September 9, 2009 [Page 2] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 On-Demand: An MPLS-TP LSP's performance is monitored only based on operator request, i.e., performance is not monitored automatically as soon as the LSP becomes operational. Continuous: In this mode, it is assumed that an MPLS-TP LSP is configured for continuous performance monitoring. Also, the relevant configuration can be applied to and removed from an MPLS- TP LSP at any time during the life of the LSP. When configured for continuous performance monitoring, an MPLS-TP LSP's performance is continuously monitored as soon as it becomes operational. The following features are common to both the on-demand and the continuous modes: 1. The LSP can be optionally locked for data traffic. 2. MPLS-OAM PC and PF packets can be consumed by either a Maintenance Intermediate Point (MIP) or a Maintenance End Point (MEP). 3. MPLS-OAM PC and PF packets are intercepted at any MIP based on MPLS TTL expiry, and are intercepted at MEP simply because it is the egress LSR of the LSP (i.e., regardless of the TTL value). 4. More than one MPLS-OAM performance flows can be maintained simultaneously from a MEP to any MIP or the other MEP. 5. The transmission rate of MPLS-OAM PF packets MUST be acceptable to both the sender and the receiver, otherwise transmission of such packets MUST NOT begin. The rate is negotiated via MPLS-OAM PC packets. 6. An MPLS OAM PF packets contains sequence number and time-stamp to measure packet loss and unidirectional delay/jitter. In the continuous mode, the MEP at which performance is monitored is configured to send MPLS-OAM PF packets continuously to different MIPs and/or the other MEP. The configuration specifies: . Rate at which the MPLS-OAM PF packets are sent. . Addresses of MIPs/MEP to which the MPLS-OAM PF packets are destined. . Whether or not performance is monitored in both directions of the MPLS-TP LSP. Boutros Expires September 9, 2009 [Page 3] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 . Rate at which the number of lost MPLS-OAM PF packets should be reported to the sender MEP. The proposed mechanism is based on a set of new TLVs which can be transported using one of the following methods: 1. Using in-band MPLS OAM messages which are forwarded as MPLS packets (non-IP based). 2. Using in-band LSP-Ping extensions defined in [3] where IP/UDP packets are used (IP-based). The LSP-Ping messages are sent using the codepoint defined in [2]. Method (1) and (2) are referred to as "Non-IP option" and "LSP-Ping option" respectively in the rest of the document. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 2. Terminology ACH: Associated Channel Header LSR: Label Switching Router MEP: Maintenance End Point MIP: Maintenance Intermediate Point MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-TP: MPLS Transport Profile MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit NMS: Network Management System PC: Performance Control PF: Performance Flow Boutros Expires September 9, 2009 [Page 4] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 PM: Performance Monitoring TLV: Type Length Value TTL: Time To Live 3. MPLS-TP Performance Monitor Mechanism For the Non-IP option, the proposed mechanism uses two new code points in the Associated Channel Header (ACH) described in [6]. The LSP-Ping option is in compliance to the specifications [2],[3], and [7]. The proposed mechanism requires a set of new TLVs called Performance Request TLV, Performance Loss Report TLV. In addition, the proposed mechanism uses the Address and LSPI TLVs defined in [5]. Moreover, it can also be used in conjunction with the data-locking mechanism defined in [4]. The new TLVs are described below. 4. MPLS-OAM Performance Message 4.1. In-band Message Identification In the in-band option, under MPLS label stack of the MPLS-TP LSP, the ACH with "MPLS-TP Performance Control" code point indicates that the message is an MPLS OAM Performance Control (PC) message. The ACH with code point "MPLS-TP Performance Flow" indicates that the message is an MPLS OAM Performance Flow (PF) message. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version|Flags | 0xHH MPLS-TP Performance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of MPLS-TP Performance Control The first nibble (0001b) indicates the ACH. The version and the reserved values are both set to 0 as specified in [1]. MPLS-TP Performance control and performance flow code points = 0xHH and 0xhh. [HH and hh to be assigned by IANA from the PW Associated Channel Type registry.] Boutros Expires September 9, 2009 [Page 5] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 4.2. Out-of-band Message Identification [To be added] 4.3. MPLS-OAM Performance control Message Format The format of an MPLS-OAM Performance control Message is shown below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Operation | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Code | Cause Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV's | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS-TP OAM Message Format Version The Version Number is currently 1. Message Type Four message types are defined as shown below. Message Type Description ------------ ------------- 0x1 Performance Request 0x2 Performance Report 0x3 Performance Removal 0x4 Performance Response Operation Boutros Expires September 9, 2009 [Page 6] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 Two operations are defined as shown below. In the unidirectional mode, the receiver MIP or MEP does not have to maintain a PM flow towards the sender MEP. But, in the bidirectional mode, the receiver MIP or MEP MUST maintain a PM flow towards the sender MEP. Operation Description --------- ------------- 0x0 Unidirectional 0x1 Bidirectional Sender's Handle The Sender's Handle is filled in by the sender. There are no semantics associated with this handle. Message Length The total length of any included TLVs. Message ID The Message ID is set by the sender and is incremented everytime the sender sends a new message. The receiver MUST include the Message ID in the response. This way, the sender can correlate a reply with the corresponding request. Return code Value Meaning ----- ------- 0 Informational 1 Success 2 Failure Cause code Value Meaning ----- ------- 1 Fail to match MPLS-TP LSP ID. 2 Malformed performance message received 3 One or more of the TLVs is/are unknown 4 Authentication failed 5 Specified PF Packet Rate cannot be supported 6 Specified Packet Loss Report Rate cannot be supported Boutros Expires September 9, 2009 [Page 7] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 Note that the MPLS-TP LSP whose performance is to be monitored is identified by the LSP ID TLV as defined in [5] in the MPLS-OAM performance message. MPLS-TP performance control message may include authentication TLV defined in [4]. 4.4. Performance Request TLV 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Performance Flow Packet Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Loss Report Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Performance Request TLV When a MEP wants to monitor performance on an MPLS-TP, it sends an MPLS-OAM PC packet with Performance Request TLV. The Performance Request message can be intercepted by either a MIP (due to TTL expiry) or a MEP (simply because it is the egress LSR). Performance Flow Packet Rate (in packets per second) specifies the maximum rate at which MPLS-OAM PF packets can be sent. Packet loss Report Rate specifies the maximum rate at which the loss of MPLS-OAM PF packets can be reported to the sender MEP. The receiver MIP or MEP MUST send either an ACK or NAK response to the sender MEP using an MPLS OAM performance response message. An ACK response is sent if the receiver can support the specified rates. Otherwise, a NAK response is sent. Until an ACK response is received, the sender MEP MUST NOT assume that the MPLS-TP LSP is ready for performance monitoring. If multiple Performance Request TLVs are present, only the first TLV is taken into consideration. Boutros Expires September 9, 2009 [Page 8] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 4.5. Packet Loss Reporting TLV 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lost packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Number of Packets Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Packet Loss Report TLV Performance monitor report MPLS-OAM Messages will be sent at the rate that does not exceed the maximum packet loss reporting rate specified in the MPLS-OAM Performance Request TLV. This TLV includes the number of lost MPLS-OAM PF packets as well as the total number of MPLS-OAM PF flow packets that it must have received from the sender. The receiver figures out the latter using the sequence number in the MPLS-OAM PF packets (described below). 4.6. Performance Removal When performance monitor mode operation of an MPLS-TP LSP is no longer required, the MEP that previously sent the MPLS OAM Performance request message sends another MPLS OAM performance removal message. The receiver MEP or MIP MUST send either an ACK or NAK response to the sender MEP using an MPLS OAM performance response message. An ACK response is sent if the MPLS-TP LSP is already monitoring performance. Otherwise, a NAK response is sent. 4.7. MPLS-OAM PF Packet When the performance of MPLS-TP LSP is monitored, MPLS-OAM PF packets are sent from the sender MEP to the MEP/MIP end of the flow. A PF packet contains a sequence number and a time-stamp using which the receiver can calculate packet loss and one-way delay/jitter. Boutros Expires September 9, 2009 [Page 9] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label stack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label with EOS bit set | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version|Reserved |0xHH (MPLS-TP Performance Flow)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: MPLS-OAM PF Packet 4.8. Monitoring regular PW packets When the performance of PW is monitored, in continuous mode, regular PW data packets can be used to monitor performance. PW packets in the presence of CW contain a sequence number that can be used to measure packets loss. Data traffic is sent over an MPLS-TP PW using the format shown below:- 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN LSP label stack (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label with EOS set | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.9. Network Management System An operator should be able to provision any given LSR to: 1. Lock/Unlock any MPLS-TP LSP. 2. Send MPLS OAM packets from a MEP and notify NMS when MPLS OAM response arrives. Boutros Expires September 9, 2009 [Page 10] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 When NMS is used to provision any of the above the functionality, the corresponding MPLS OAM message is not used. 5. Operation Consider an MPLS-TP LSP LSR-1 <--> LSR-2 <--> LSR-3 <--> LSR-4 <--> LSR-5. LSR-1 and LSR-5 are ingress and egress LSR for the respective direction, and LSR-1 and LSR-5 act as MEPs and LSR-2, LSR-3 and LSR-5 acts as a MIPs. Assume that the objective is to evaluate the performance of the segment between LSR-1 and LSR-2 at LSR-1. Thus, LSR-2 is the destination for the MPLS-OAM PM packets. 1- LSR-1 sends an optional Lock Request MPLS-OAM message to LSR-5 (egress LSR) to take the MPLS-TP LSP out of service 2- LSR-5 takes the MPLS-TP LSP out of service from data-plane and sends an ACK MPLS-OAM message back to LSR-1 3- LSR-1 sends a PM Request MPLS-OAM message to LSR-2 containing its source address the MPLS-TP LSP ID, and destination address of LSR-2, maximum rate at which PF packets are to be sent, maximum packet loss report rate (back to LSR-1), and an indication as to whether or not LSR-2 also needs to send MPLS-OAM PM packets. 4- LSR-2 verifies the LSP ID, and the destination address and sends a performance response MPLS-OAM message with return code 1(success) back to LSR-1 if it can handle the specified PM packet transmission and loss reporting rate, otherwise LSR-2 sends the performance response MPLS-OAM message with return code 2(failure) back to LSR-1 with the following cause codes: 1. if destination address or LSP-ID cannot be matched, it sends a response with cause code 1. 2. if the message is malformed, it sends a response with the cause code 2. 3. if any of the TLV is not known, it sends a response with cause code 3. It may also include the unknown TLVs. 4. if message authentication fails, it sends a response with the cause code 4. 5. if the specified PF packet rate cannot be handled, it sends a response with cause code 5. Boutros Expires September 9, 2009 [Page 11] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 6. if the specified packet loss report rate cannot be supported, it sends a response with cause code 6. Note that MPLS TTL value is set to 255 in the response message. After receiving the ACK from LSR-2 for the MPLS-OAM PM request, MPLS-OAM PF packets are transmitted on the MPLS-TP LSP. Both LSR-1 and LSR-2 keep a count of the lost MPLS-OAM PF packets. The receiver LSR computes the number of lost MPLS-OAM PF flow packets using the sequence number. Note that the sequence number equals the total number of packets that must have received in the absence of any packet loss. The receiver periodically send the number of lost MPLS-OAM PF packets as well as the total number of MPLS-OAM PF packets that it must have received to the sender. Removal of PM mode (only for on-demand mode) 1- LSR-1 sends an MPLS-OAM message to LSR-2 in order to stop operating the MPLS-TP LSP in Performance Management mode. 2- LSR-2 sends its latest Packet Loss Report to LSR-1 via an MPLS-OAM message. 3- LSR-1 sends an Unlock Request MPLS-OAM message to LSR-5 4- LSR-5 puts the MPLS-TP LSP back in service and sends an ACK MPLS- OAM message back to LSR-1. 6. Security Considerations The security considerations for the authentication TLV need further study. 7. IANA Considerations To be added. 8. References 8.1. Normative References [1] Bradner. S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. Boutros Expires September 9, 2009 [Page 12] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 [2] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires ", RFC 5085, December 2007. [3] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [4] S. Boutros, et. al., "Operating MPLS Transport Profile LSP in Loopback Mode", draft-boutros-mpls-tp-loopback-01.txt, Work in Progress, December 2008. 8.2. Informative References [5] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009. [6] M. Bocci, et. al., "MPLS Generic Associated Channel", draft- ietf-mpls-tp-gach-gal-02.txt, work in progress, January 6, 2009. [7] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008. Boutros Expires September 9, 2009 [Page 13] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 Author's Addresses Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: msiva@cisco.com George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MASSACHUSETTS 01719 United States Email: swallow@cisco.com David Ward Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: wardd@cisco.com Stewart Bryant Cisco Systems, Inc. 250, Longwater, Green Park, Reading RG2 6GB, UK UK Email: stbryant@cisco.com Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of Boutros Expires September 9, 2009 [Page 14] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. Boutros Expires September 9, 2009 [Page 15] Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009 For the avoidance of doubt, each Contributor to the UETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Boutros Expires September 9, 2009 [Page 16]