Network Working Group Sami Boutros (Ed.) Internet Draft Siva Sivabalan Intended status: Standards Track George Swallow Expires: May 2009 David Ward Cisco Systems, Inc. Rahul Aggarwal Juniper Networks, Inc. November 04, 2008 Operating MPLS Transport Profile LSP in Loopback Mode draft-boutros-mpls-tp-loopback-01.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 May 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Boutros Expires May 5, 2009 [Page 1] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 This document specifies an extension to MPLS Operation, Administration, and Maintenance (OAM) to operate an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) in loopback mode for management purpose. This extension can be used to loop either all traffic (i.e, data and control traffic) or only OAM traffic up to certain LSR on the path of the MPLS-TP LSP back to the source. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................4 3. MPLS-TP Loopback Mechanism.....................................5 4. MPLS-OAM Loopback Message......................................5 4.1. Lock Request TLV..........................................6 4.2. Unlock Request TLV........................................6 4.3. Loopback Request TLV......................................7 4.4. Loopback Removal TLV......................................7 4.5. Authentication TLV........................................8 4.6. Source Identifier TLV.....................................8 4.7. Target Identifier TLV....................................10 4.8. Response TLV.............................................10 4.9. Data packets.............................................11 4.10. Network Management System...............................11 5. Operation.....................................................12 6. Security Considerations.......................................15 7. IANA Considerations...........................................15 TBD..............................................................15 8. References....................................................15 8.1. Normative References.....................................15 8.2. Informative References...................................16 Author's Addresses...............................................16 Intellectual Property Statement..................................17 Disclaimer of Validity...........................................17 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 Pseudowire (PW). Boutros Expires June 5, 2009 [Page 2] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 To describe the loopback functionality, let us assume a bi- directional MPLS-TP LSP A <---> B <---> C where A, B, and C are MPLS capable nodes. Also, let us assume that the network operator requires B to loop the packets sent from A back to A. In this example, A and C acts as Maintenance End Points (MEPs) and B acts as a Maintenance Intermediate Point (MIP). The operator can setup the MPLS-TP LSP into loopback mode such that: 1. B loops all the packets (regardless of whether they are data or control packets) back to A. We refer to this mode "Full Loopback" (FLB). 2. B loops only the OAM packets back to A, and all other packets from A are sent towards C. We refer to this mode "OAM Loopback" (OLB). The operator can optionally take the MPLS-TP LSP out of service before setting up the MPLS-TP LSP in loopback mode. In that case, A sends an in-band MPLS OAM message along the MPLS-TP LSP to lock the MPLS-TP LSP. The message will be intercepted by C since it is at the end of the LSP. C responds to the lock request with an ACK OAM message. If the operator does not want to take MPLS-TP LSP out of service before setting it up into loopback mode, A does not have to send lock OAM message. In order to setup the MPLS-TP LSP in loopback mode, A sends another in-band OAM message with the correct MPLS TTL value so that the message will be intercepted by B because of the MPLS TTL expiry. The second MPLS OAM message contains a request to instruct B to operate the corresponding MPLS-TP LSP in either Full Loopback mode or OAM Loopback mode. B sends an ACK/NAK OAM message back to A to indicate whether or not it has successfully setup the MPLS-TP LSP in the required loopback mode. In the case of NAK, the OAM reply message contains an error code. Upon receiving a NAK reply to the loopback request, A sends another MPLS OAM message to unlock the MPLS-TP LSP in case it was previously locked. The unlock MPLS OAM message is intercepted by C as it is at the end of the LSP. When the MPLS-TP LSP operates in FLB mode, all the packets (data and control) from are looped back at B. When operating the MPLS-TP LSP in OLB, B loops only the OAM packets back to A. When the loopback operation is no longer required, A sends another MPLS OAM message to remove the loopback operation mode, 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 may send another in-band MPLS OAM message to unlock the MPLS-TP LSP, in case the MPLS- Boutros Expires June 5, 2009 [Page 3] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 TP LSP was previously locked as mentioned above. The unlock MPLS OAM packet is intercepted by C as it is at the end of the MPLS-TP LSP. 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 LSP-Ping extensions defined in [5] where IP/UDP packets are used (IP-based). The LSP-Ping messages are sent using the codepoint defined in [4]. Method (1) and (2) are referred to as "in-band 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 Error! Reference source not found. 2. Terminology ACH: Associated Channel Header FLB: Full Loopback 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 NMS: Network Management System OLB: OAM Loopback Boutros Expires June 5, 2009 [Page 4] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 TLV: Type Length Value TTL: Time To Live 3. MPLS-TP Loopback Mechanism For the in-band option, the proposed mechanism uses a new code point in the Associated Channel Header (ACH) described in [2]. The LSP-Ping option will be in compliance to specifications [4],[5], and [6]. Also, the proposed mechanism requires a set of new TLVs called Loopback Request TLV, Loopback Removal TLV, Lock Request TLV, Lock Removal TLV, Source Address TLV, Target Address TLV, Authentication Request TLV, and Response TLV. These TLVs are described below. 4. MPLS-OAM Loopback Message In the in-band option, 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 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. This way, the sender can correlate a reply with the corresponding request. Boutros Expires June 5, 2009 [Page 5] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 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 = TBD | 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 = TBD | 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. 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. Boutros Expires June 5, 2009 [Page 6] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 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 = TBD | length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | +-+-+-+-+-+-+-+-+ 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 corresponding MPLS-TP LSP in loopback mode. The value of the flag is used to identify the loopback mode as follows: Flag Value Loopback Mode ---------- ------------- 0x0 OLB 0x1 FLB 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 = TBD | 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. Boutros Expires June 5, 2009 [Page 7] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 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 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 = TBD | 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 = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Source Identifier ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ While setting up an MPLS-TP LSP in loopback mode, the sender MEP can include its ID in the Source Identifier TLV. The ID can be in IPv4, IPv6, or PW FEC (128 or 129) formats on can be any of the LSP IDs defined in [5]. The length field represents the length (in bytes) of only the source identifier. Depending on the format, type and length are interpreted as follows: Format Type Length ------ ---- ------ LSP FEC TLVs defined in [5] Variable Boutros Expires June 5, 2009 [Page 8] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 IPv4 address TBD 4 IPv6 address TBD 16 FEC 128 Pseudo Wire Identifier TBD 4 FEC 129 Pseudo Wire Identifier TBD Variable 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 [3]. The use of the Source Identifier TLV is outside the scope of this document. Boutros Expires June 5, 2009 [Page 9] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 4.7. Target 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 = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Target Identifier ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ While setting up an MPLS-TP LSP in loopback mode, the sender MEP can include the target ID in the Target Identifier TLV. The format exactly the same as the Source Identifier TLV described above. The use of the Target Identifier TLV is outside the scope of this document. 4.8. 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 = TBD | 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 4 Authentication failed 5 MPLS-TP LSP is locked 6 MPLS-TP LSP is not locked Boutros Expires June 5, 2009 [Page 10] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 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 13 Fail to match target ID Note that in the case of error code 2, the unknown TLV can also be optionally included in the response TLV. 4.9. Data packets When an MPLS-TP LSP operates in FLB 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 may 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Sequcence-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.10. Network Management System An operator should be able to provision any given LSR to: 1. lock/Unlock any MPLS-TP LSP. 2. setup any MPLS-TP LSP in loopback mode (either FLB or OLB).should have the capability to Network Management System Boutros Expires June 5, 2009 [Page 11] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 (NMS) may also be used to setup an MPLS-TP LSP in loopback mode (either FLB or OLB). 3. send MPLS OAM packets from a MEP and notify NMS when MPLS OAM response arrives. When NMS is used to provision any of the above the functionality, the corresponding MPLS OAM message is not used. 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: 1. A can optionally send an MPLS-OAM loopback request message. The message can be an in-band message in the MPLS-LSP 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. The message can also use the LSP-Ping IP/UDP option, and in this case the message contains all the above TLVs but does not contain the ACH. 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. Boutros Expires June 5, 2009 [Page 12] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 3. Upon receiving the MPLS-OAM response message with error code 1, A sends an MPLS-OAM loopback request message using either the in- band or LSP-Ping option to B. The loopback request can be for either FLB or OLB mode. The message can optionally have an Authentication TLV, and Source Identifier TLV and a Target Identifier 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. d. Target ID cannot be matched, it sends a response with error code 13. B identifies the MPLS-TP LSP, and if the request is for OLB mode, it sends a reply with error code 1 (success). If the request is for FLB mode: a. if the MPLS-TP is already in FLB mode, it sends a response with error code 9. b. if the MPLS-TP is successfully programmed into FLB mode, it sends a reply with error code 1 (success). 5. After receiving a positive reply from B, and if the request is for FLB mode, 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: Boutros Expires June 5, 2009 [Page 13] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 1. A sends an MPLS-OAM loopback request message. The message can be an in-band message in the MPLS-LSP 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. The message can also use the LSP-Ping option in which case the ACH is not used but all others TLVs are included in the message. 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. To remove MPLS-TP LSP from FLB mode: 1. A sends an MPLS-OAM loopback request message, using either in-band or LSP-Ping option to B. consisting 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. Boutros Expires June 5, 2009 [Page 14] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 c. if the message authentication fails, it sends a response with error code 4. d. if the target ID is matched, it sends a response with error code 13. B identifies the MPLS-TP 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. [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. [4] T. Nadeau, et. al, " Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires ", RFC 5085, December 2007. [5] K. Kompella, G. Swallow, " Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Boutros Expires June 5, 2009 [Page 15] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 8.2. Informative References [6] Nabil Bitar, et. al, " Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008. 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 Rahul Aggarwal Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA EMail: rahul@juniper.net Boutros Expires June 5, 2009 [Page 16] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 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. 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. Boutros Expires June 5, 2009 [Page 17] Internet-Draft draft-boutros-mpls-tp-loopback-01.txt November 2008 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Boutros Expires June 5, 2009 [Page 18]