Network Working Group Sami Boutros (Ed.) Internet Draft Siva Sivabalan Intended status: Standards Track George Swallow Expires: April 2009 David Ward Cisco Systems, Inc. October 10, 2008 Operating MPLS Transport Profile LSP in Loopback Mode draft-boutros-mpls-tp-loopback-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 10, 2007. Copyright Notice Copyright (C) The IETF Trust (2008). Boutros Expires April 10, 2009 [Page 1] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 Abstract This document specifies an extension to MPLS Operation, Administration, and Maintenance (OAM) using which an MPLS Label Switching Router (LSR) can explicitly request another MPLS LSR to operate an MPLS Transport Profile(MPLS-TP) Label Switched Path between the two LSRs in loopback mode. This extension can be used to loop the data traffic up to certain LSR in the path of the MPLS LSP back to the source for management purpose. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................4 3. MPLS-TP Loopback Mechanism.....................................4 4. MPLS-OAM Loopback Message......................................4 4.1. Lock Request TLV..........................................5 4.2. Unlock Request TLV........................................5 4.3. Loopback Request TLV......................................6 4.4. Loopback Removal TLV......................................6 4.5. Authentication TLV........................................7 4.6. Source Identifier TLV.....................................7 4.7. Response TLV..............................................8 4.8. Data packets..............................................9 5. Operation......................................................9 6. Security Considerations.......................................12 7. IANA Considerations...........................................12 TBD..............................................................12 8. References....................................................12 8.1. Normative References.....................................12 Author's Addresses...............................................13 Intellectual Property Statement..................................13 Disclaimer of Validity...........................................14 1. Introduction In traditional transport networks, circuits are provisioned on multiple switches and service providers operate the transport circuit such as T1 line in loopback mode for management purpose, e.g., to test connectivity of the circuit up to a specific switch on the path of the circuit, to test the circuit performance with respect to delay/jitter, etc. MPLS-TP bidirectional LSP emulating traditional transport circuits need to provide the same loopback capability. In this document, an MPLS-TP LSP means either MPLS transport LSP or MPLS Pseudowires (PW). Boutros Expires June 10, 2009 [Page 2] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 To decribe the loopback functionality, let us assume a bidirectional MPLS-TP LSP A <---> B <---> C where A, B, and C are MPLS capable nodes. Furthermore, let us assume that A wants B to loop the data packet sent from A back to B. In this example, A and C acts as Maintenance End Points (MEPs) and B acts as a Maintenance Intermediate Point (MIP). First, A sends an in-band MPLS OAM packet along the MPLS-TP LSP to lock the circuit. The message will be intercepted by C since it is at the end of the LSP. When C responds with an ACK to the lock request, A sends another in-band message with the correct MPLS TTL value on the OAM packet so that the MPLS OAM packet will be intercepted by B because of the MPLS TTL expiry. The second MPLS OAM packet contains a request to instruct B to operate the corresponding MPLS-TP LSP in loopback mode. B sends an ACK/NAK OAM reply message back to A to indicate whether or not the corresponding MPLS-TP LSP has been programmed into loopback mode. In the case of NAK, the OAM reply message contains an error code. Moreover, upon receiving a NAK reply to the loopback request, A sends another MPLS OAM message to unlock the LSP. The unlock message is intercepted by C as it is at the end of the LSP. When the MPLS-TP LSP operates in a loopback mode, data packets from A to B sent over that LSP are looped back to A. When loopback mode operation is no longer required, A sends another MPLS OAM message to remove the loopback mode operation, and the MPLS TTL is set such that this message is intercepted by B. It is expected that B sends a reply back to A to ACK/NAK the loopback mode removal request. Upon getting an ACK response to loopback mode removal request, A sends another MPLS OAM message to unlock the LSP, and this message is intercepted by C as it is at the end of the LSP. In the following sections, we describe proposed new MPLS OAM messages and the TLVs in detail. 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 Error! Reference source not found. Boutros Expires June 10, 2009 [Page 3] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 2. Terminology ACH: Associated Channel Header LSR: Label Switching Router MEP: Maintenance End Point MIP: Maintenance Intermediate Point MPLS-TP: MPLS Transport Profile MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit TLV: Type Length Value TTL: Time To Live 3. MPLS-TP Loopback Mechanism The proposed mechanism is based on a new code point in the Associated Channel Header (ACH) described in [1] and a few added TLVs for the existing MPLS OAM message. These TLVs are Loopback Request TLV, Loopback Removal TLV, Lock Request TLV, Lock Removal TLV, Source Address TLV, Authentication Request TLV, and Response TLV. 4. MPLS-OAM Loopback Message Under MPLS label stack of the MPLS-TP LSP, the ACH with "MPLS-TP Looback" code point indicates that the message is an MPLS OAM Loopback message. In addition, a 32-bit field is added to carry the message ID and the message length as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| 0xHH (MPLS-TP Loopback) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MPLS-TP OAM Message Header Boutros Expires June 10, 2009 [Page 4] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 First nibble = 0001b. The version and the reserved values are both set to 0 as specified in [1]. MPLS-TP looback code point = 0xHH The Message ID is set by the sender. The receiver MUST include the Message ID in the response. The Message Length is the total length of the message in bytes excluding the length of the MPLS-TP OAM message header. 4.1. Lock 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 = 0x1 | length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lock Request TLV is used to request a MEP to take an MPLS-TP LSP out of service so that some form of maintenance can be done on the MPLS- TP. A MEP includes a Lock Request TLV in the MPLS OAM message to request the MEP on the other side of the MPLS-TP LSP to take the MPLS-TP LSP out of service. The receiver MEP MUST send either an ACK or a NAK response to the sender MEP using an MPLS OAM message with a Response TLV described below. Until the sender MEP receives an ACK, it MUST NOT assume that the receiver MEP has taken the MPLS-TP out of service. A receiver MEP sends an ACK only if it can successfully lock the MPLS-TP. Otherwise, it sends a NAK. 4.2. Unlock 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 = 0x2 | length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Unlock Request TLV is sent from the MEP which has previously sent lock request via MPLS OAM message. Upon receiving the message, the receiver MEP brings the MPLS-TP back in service. Boutros Expires June 10, 2009 [Page 5] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 The receiver MEP MUST send either an ACK or a NAK response to the sender MEP using an MPLS OAM message with a Response TLV described below. Until the sender MEP receives an ACK, it MUST NOT assume that the MPLS-TP LSP has been put back in service. A receiver MEP sends an ACK only if the MPLS-TP LSP has been unlocked, and unlock operation is successful. Otherwise, it sends a NAK. 4.3. Loopback 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 = 0x3 | length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When a MEP wants to put an MPLS-TP in loopback mode, it sends a MPLS OAM message with Loopback Request TLV. The loopback message can be intercepted by either a MIP or a MEP depending on the MPLS TTL value. The receiver puts in correcponding MPLS-TP LSP in loopback mode. The receiver MEP or MIP MUST send either an ACK or NAK response to the sender MEP using an MPLS OAM message with a Response TLV described below. An ACK response is sent if the MPLS-TP LSP is successfully put in loopback mode. Otherwise, a NAK response is sent. Until an ACK response is received, the sender MEP MUST NOT assume that the MPLS-TP LSP can operate in loopback mode. 4.4. Loopback Removal 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 = 0x4 | length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When loopback mode operation of an MPLS-TP LSP is no longer required, the MEP that previously sent the MPLS OAM loopback message sends another MPLS OAM message with a Loopback Removal TLV. The receiver MEP change the MPLS-TP LSP from loopback mode to normal mode of operation. The receiver MEP or MIP MUST send either an ACK or NAK response to the sender MEP using an MPLS OAM message with a Response TLV described below. An ACK response is sent if the MPLS-TP LSP is already in loopback mode, and if the MPLS-TP LSP is successfully put Boutros Expires June 10, 2009 [Page 6] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 back in normal operation mode. Otherwise, a NAK response is sent. Until an ACK response is received, the sender MEP MUST NOT assume that the MPLS-TP LSP is put back in normal operation mode. 4.5. Authentication 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 = 0x5 | Length = 0xx | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mechanisms similar to PPP Chap can be used to authenticate the MPLS OAM Loopback request. A variable length key can be carried in an optional authentication TLV which can be included in the MPLS OAM loopback request message. The use of authentication key is outside the scope of the document. 4.6. Source Identifier 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 = 0x6 (IPv4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Source Identifier ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ While setting up an MPLS-TP LSP in loopback mode, the sender MEP can include its ID in the the Source Identifier TLV. The ID can be in IPv4, IPv6, or PW FEC (128 or 129) formats. The length field represents the length (in bytes) of only the source identifier. Depending on the format, type and length are interpretted as follows: Format Type Length ------ ---- ------ IPv4 address 0x6 4 IPv6 address 0x7 16 FEC 128 Pseudo Wire Identifier 0x8 4 FEC 129 Pseudo Wire Identifier 0x9 Variable Boutros Expires June 10, 2009 [Page 7] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 In the case of FEC 129, the source is identified by AGI, SAII, and TAII as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Value (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAII Value (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII Value (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For more details on AGI, SAII, and TAII, please refer to [2]. The use of the Source Identifier TLV is outside the scope of this document. 4.7. Response 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 = 0x10 | Length = 0x1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ReturnCode | +-+-+-+-+-+-+-+ Return code Value Meaning ----- ------- 0 No error code 1 Success 2 Malformed loopback request received 3 One or more of the TLVs is/are unknown Boutros Expires June 10, 2009 [Page 8] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 4 Authentication failed 5 MPLS-TP LSP is locked 6 MPLS-TP LSP is not locked 7 Fail to lock MPLS-TP LSP 8 Fail to unlock MPLS-TP LSP 9 MPLS-TP LSP is in loopback mode 10 MPLS-TP is not in loopback mode 11 Fail to set MPLS-TP LSP in loopback mode 12 Fail to remove MPLS-TP from loopback mode Note that in the case of error code 2, the unknown TLV can also be optionally included in the response TLV. 4.8. Data packets When an MPLS-TP LSP operates in loopback mode, data packets sent from the sender MEP will be looped back to that sender MEP. In order for the sender MEP to make ensure that no data packets are dropped, each data MPLS packets MUST contain a sequence-id right after the label stack. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequcence-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Operation Assume an MPLS-TP LSP A <--> B <--> C, and A wants to request B to set the MPLS-TP LSP in loopback mode. The following steps are carried out: Boutros Expires June 10, 2009 [Page 9] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 1. A sends an MPLS-OAM loopback request message consisting of an ACH with the MPLS-TP Loopback code, Lock TLV, and optional authentication TLV to C. The MPLS label stack of the LSP is added and the MPLS TTL value is set to 255. 2. Upon intercepting the MPLS-OAM message, C examines the message, and: a. if the message is malformed, it sends a response with the error code 2 back to A. b. if any of the TLV is not known, it sends a response with error code 3 back to A. It may also include the unknown TLVs. c. if message authentication fails, it sends a response with the error code 4 back to A. d. if the MPLS-TP is already locked, it sends a response with error code 5 back to A. e. if the MPLS-TP is not already locked and cannot be locked, it sends a response with error code 7 back to A. f. if the MPLS-TP is successfully locked, it sends a response an error code 1 (success) back to A. Note that MPLS TTL value is set to 255 in the response message. 3. Upon receiving the MPLS-OAM response message with error code 1, A sends an MPLS-OAM loopback request message consisting of an ACH with the MPLS-TP Loopback code to B. The message can optionally have authentication TLV, and source TLV. The MPLS label stack of the LSP is added and the MPLS TTL value is set to the number of hops between A and B. 4. Upon intercepting the MPLS-OAM message, B examines the message, and: a. if the message is malformed, it sends a response with error code 2. b. if any of the TLV is not known, B sends a response with error code 3. It may also include the unknown TLVs. c. if the message authentication fails, it sends a response with error code 4. Boutros Expires June 10, 2009 [Page 10] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 B identifies the MPLS bidirectional LSP: a. if the MPLS-TP is already in loopback mode, it sends a response with error code 9. b. if the MPLS-TP is successfully set in loopback mode, it sends a reply with error code 1 (success). 5. After receiving a positive reply from B, A can send data packets on the MPLS-TP LSP to B, and expect those packets to loopback to itself. The data packets contains sequence numbers to check for packet loss. 6. B simply loops the data packets coming over the MPLS-TP LSP back towards the source. The MPLS label stack of the LSP is added and the MPLS TTL value is set to 255. To unlock the MPLS-TP LSP: 1. A sends an MPLS-OAM loopback request message consisting of an ACH with the MPLS-TP Loopback code, Unlock Request TLV and optionally an authentication TLV. The MPLS label stack of the LSP is added and the MPLS TTL value is set to 255. 2. Upon intercepting the MPLS-OAM message, C examines the message, and: a. if the message is malformed, it sends a response with the error code 2 back to A. b. if any of the TLV is not known, it sends a response with error code 3 back to A. It may also include the unknown TLVs. c. if message authentication fails, it sends a response with the error code 4 back to A. C identifies the MPLS-TP LSP: a. if the MPLS-TP is not locked, it sends a response with error code 6 back to A. b. if the MPLS-TP is locked and cannot be unlocked, it sends a response with error code 8 back to A. c. if the MPLS-TP is successfully unlocked, it sends a response an error code 1 (success) back to A. Boutros Expires June 10, 2009 [Page 11] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 To remove MPLS-TP LSP from loopback mode: 1. A sends an MPLS-OAM loopback request message consisting of an ACH with the MPLS-TP Loopback code, Loopback Removal Request TLV and optionally an authentication TLV. The MPLS label stack of the LSP is added and the MPLS TTL value is set to the number of hops between A and B. 2. Upon intercepting the MPLS-OAM message, B examines the message and: a. if the message is malformed, it sends a response with error code 2. b. if any of the TLV is not known, B sends a response with error code 3. It may also include the unknown TLVs. c. if the message authentication fails, it sends a response with error code 4. B identifies the MPLS bidirectional LSP: c. if the MPLS-TP is not in loopback mode, it sends a response with error code 10. d. if the MPLS-TP is successfully changed from loopback mode to normal mode of operation, it sends a reply with error code 1(success). 6. Security Considerations The security considerations for the authentication TLV need further study. 7. IANA Considerations TBD 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 June 10, 2009 [Page 12] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 [2] M. Bocci, et. al., "MPLS Generic Associated Channel", draft- bocci-pwe3-mpls-tp-ge-ach-00.txt, Work in progress, June 26, 2008. [3] L. Martini, et. al., " Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC4447, April, 2006. 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 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. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Boutros Expires June 10, 2009 [Page 13] Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008 Copies of IPR 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 this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Boutros Expires June 10, 2009 [Page 14]