Network Working Group Sami Boutros (Ed.) Internet Draft Siva Sivabalan (Ed.) Category: Standards Track Expiration Date: September 2009 George Swallow (Ed.) Cisco Systems, Inc. Rahul Aggarwal (Ed.) Juniper Networks, Inc. Martin Vigoureux (Ed.) Alcatel-Lucent March 9, 2009 Operating MPLS Transport Profile LSP in Loopback Mode draft-boutros-mpls-tp-loopback-02.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. Boutros, et al. Standards Track [Page 1] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 Copyright Notice 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 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. Abstract 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 specific OAM traffic at a specified LSR on the path of the MPLS-TP LSP back to the source. Boutros, et al. Standards Track [Page 2] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 Contents 1 Introduction .............................................. 4 2 Terminology ............................................... 6 3 MPLS Loopback Mechanism ................................... 6 4 MPLS Loopback Messages .................................... 6 4.1 In-band Message Identification ............................ 6 4.2 Out-of-band Message Identification ........................ 7 4.3 MPLS Loopback Message Format .............................. 7 4.4 Loopback Operations ....................................... 10 4.4.1 Null_Operation ............................................ 10 4.4.2 Lock ...................................................... 10 4.4.3 Unlock .................................................... 10 4.4.4 Set_Full_Loopback and Set_OAM_Loopback .................... 10 4.4.5 Unset_Full_Loopback and Unset_OAM_Loopback ................ 10 4.5 Loopback TLVs ............................................. 11 4.5.1 Authentication TLV ........................................ 11 4.5.2 Source and Target ME TLV .................................. 11 5 Data packets .............................................. 11 6 Network Management Operations ............................. 12 7 Operation ................................................. 13 7.1 General Procedures ........................................ 13 7.2 Sending in-band Loopback messages ......................... 13 7.3 Sending out-of-band Loopback messages ..................... 14 7.4 Example Topology .......................................... 14 7.5 Locking an LSP ............................................ 14 7.6 Unlocking an LSP .......................................... 15 7.7 Setting an LSP into Loopback mode ......................... 16 7.8 Removing an LSP from Loopback mode ........................ 17 7.9 Sending Loopback echo messages ............................ 18 7.10 Operating in Full Loopback Mode ........................... 18 8 Security Considerations ................................... 18 9 IANA Considerations ....................................... 18 10 References ................................................ 18 10.1 Normative References ...................................... 18 10.2 Informative ............................................... 19 11 Authors' Addresses ........................................ 19 Boutros, et al. Standards Track [Page 3] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 1. Introduction In traditional transport networks, circuits are provisioned across multiple nodes and service providers have the ability to operate the transport circuit such as T1 line in loopback mode for management purposes, e.g., to test or verify connectivity of the circuit up to a specific node on the path of the circuit, to test the circuit perfor- mance with respect to delay/jitter, etc. MPLS-TP bidirectional LSP emulating traditional transport circuits need to provide the same loopback capability. The mechanism in this document apply to assici- cated bidirectional paths as defined in [7], which include MPLS-TP LSPs, pseudowires (PW), and Multisegment PWs. To describe the loopback functionality, let us assume a bi-direc- tional MPLS-TP LSP A <---> B <---> C <---> D where A, B, C, and D are MPLS capable nodes. Also, let us assume that the network operator requires C to loop, back to A, the packets sent from A. In this exam- ple, A and D acts as Maintenance End Points (MEPs) and C acts as a Maintenance Intermediate Point (MIP). The operator can setup the MPLS-TP LSP into loopback mode such that: 1. C loops all the packets (regardless of whether they are data or control packets) generated by node A back to A. The packets are not also forwarded towards D. Similarly, any traffic received by C from the reverse direction will be dropped. We refer to this mode "Full Loopback" (FLB). 2. C loops only the OAM control packets (those OAM control packets will be identified by an ACH code point and will be generated by node A) back to A, and all other packets from A are sent towards C. We refer to this mode "OAM Loopback" (OLB). In FLB mode the operator must take the MPLS-TP LSP out of service before setting up the MPLS-TP LSP in loopback mode. This is accom- plished by the MEP establishing the loopback first sending a Lock command to the remote MEP(s). In the case above, A sends an MPLS Loopback request message along the MPLS-TP LSP and destined to D with a lock TLV to lock the MPLS-TP LSP. The message will be intercepted by D since it is at the end of the LSP. D responds to the lock request with an MPLS Loopback response message. In OLB mode the oper- ator need not take MPLS-TP LSP out of service before setting it up into loopback mode. In order to set the MPLS-TP LSP in loopback mode, A sends an MPLS Loopback request message with either a FLB or OLB TLV to the MIP or MEP where the loopback is to be enabled. In the above example, the MPLS TTL value is set so that the message will be intercepted by C. This message contains a request to instruct C to operate the Boutros, et al. Standards Track [Page 4] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 corresponding MPLS-TP LSP in either Full Loopback mode or OAM Loop- back mode. C sends an MPLS Loopback response message back to A to indicate whether or not it has successfully set the MPLS-TP LSP into the required loopback mode. If the loopback cannot be set, the reply message would contain an error code. Upon receiving such a reply to the loopback request, A logs the event and takes further reporting actions as necessary. If the MPLS-TP LSP was previously locked, A sends another MPLS Loopback request message to D to unlock it. In FLB mode the input LSP from the direction of A is directly cross- connected to the output LSP towards A. All the packets generated by node A (data and control) are looped back at C, excepting the case of TTL expiration. When operating the MPLS-TP LSP in OLB, C loops only OAM packets generated by A with the specific ACH codepoint back to A. When the loopback operation is no longer required, A sends an MPLS Loopback request message to remove the loopback and thus restore the LSP to its original forwarding state. In this example the MPLS TTL is set such that this message is intercepted by C. It is expected that C sends a reply back to A to with a return code either ACKing or NAK the loopback removal request. Upon getting an ACK response to loopback mode removal request, in FLB mode A sends another MPLS Loop- back message to unlock the MPLS-TP LSP. The unlock MPLS Loopback packet is intercepted by D as it is at the end of the MPLS-TP LSP. The proposed mechanism is based on a new set of messages and TLVs which can be transported using one of the following methods: 1. Using in-band MPLS Loopback messages which are forwarded as MPLS packets (non-IP routing and forwarding based). 2. Using LSP-Ping extensions defined in [4] where IP/UDP packets are used (IP-based routing and forwarding). The LSP-Ping messages may be sent in-band using the codepoint defined in [3]. 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 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]. Boutros, et al. Standards Track [Page 5] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 2. Terminology ACH Associated Channel Header FLB Full Loopback LSR Label Switching Router ME Maintenance Entity 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 TLV Type Length Value TTL Time To Live 3. MPLS Loopback Mechanism For the in-band option, the proposed mechanism uses a new code point in the Associated Channel Header (ACH) described in [5]. The LSP- Ping option will be in compliance to specifications [3], [4], and [6]. 4. MPLS Loopback Messages 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 Looback" code point indicates that the message is an MPLS Loopback 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|Reserved | 0xHH (MPLS-TP Loopback) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of MPLS-TP Loopback The first nibble (0001b) indicates the ACH. The version and the reserved values are both set to 0 as specified in [1]. MPLS-TP loop- back code point = 0xHH. [HH to be assigned by IANA from the PW Boutros, et al. Standards Track [Page 6] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 Associated Channel Type registry.] 4.2. Out-of-band Message Identification [To be added] 4.3. MPLS Loopback Message Format The format of an MPLS-TP Loopback 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 Loopback Message Format Version The Version Number is currently 1. (Note: the version number is to be incremented whenever a change is made that affects the ability of an implementation to correctly parse or process an MPLS Loopback request/response. These changes include any syntactic or semantic changes made to any of the fixed fields, or to any Type-Length-Value (TLV) or sub-TLV assignment or format that is defined at a certain version number. The version number may not need to be changed if an optional TLV or sub-TLV is added.) Boutros, et al. Standards Track [Page 7] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 Message Type Three message types are defined as shown below. Message Type Description ------------ ------------- 0x0 Loopback request 0x1 Loopback response 0x2 Loopback Echo Operation Seven operations are defined as shown below. The null operation is used with the Loopback Echo message. The other six operations can appear in a Loopback request or Loopback Response message. Detailed descriptions of the operations appear in the next section. Operation Description --------- ------------- 0x0 Null_Operation 0x1 Lock 0x2 Unlock 0x3 Set_Full_Loopback 0x4 Unset_Full_Loopback 0x5 Set_OAM_Loopback 0x6 Unset_OAM_Loopback Message Length The total length of any included TLVs. Sender's Handle The Sender's Handle is filled in by the sender, and returned unchanged by the receiver in the MPLS Loopback response message (if any). There are no semantics associated with this handle, although a sender may find this useful for matching up requests with replies. Boutros, et al. Standards Track [Page 8] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 Message ID The Message ID is set by the sender of an MPLS Loopback request message. It MUST be copied unchanged by the receiver in the MPLS Loopback response message (if any). A sender SHOULD increment this value on each new message. A retransmitted message SHOULD leave the value unchanged. Return code Value Meaning ----- ------- 0 Informational 1 Success 2 Failure Cause code Value Meaning ----- ------- 0 No cause code 1 Fail to match target MIP/MEP ID 2 Malformed loopback request received 3 One or more of the TLVs is/are unknown 4 Authentication failed 5 MPLS-TP LSP already locked 6 MPLS-TP LSP already unlocked 7 Fail to lock MPLS-TP LSP 8 Fail to unlock MPLS-TP LSP 9 MPLS-TP LSP already 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 No label binding for received message The Return code and Cause code only have meaning in a Loopback Response message. In a Loopback request message the Return code and Cause code must be set to zero and ignored on receipt. Boutros, et al. Standards Track [Page 9] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 4.4. Loopback Operations 4.4.1. Null_Operation The Null_Operation is a place-holder when the Message Type fully specifies the intended operation. 4.4.2. Lock The Lock operation is used to take an LSP out of service for mainte- nance. The Lock operation is carried in an MPLS Loopback request message sent from a MEP to a trail-end MEP of the LSP to request that the LSP be taken out of service. In response, the Lock operation is carried in an Loopback response message sent from the trail-end MEP back to the originating MEP to report the result. 4.4.3. Unlock The Unlock operation is used to restore a previously locked LSP to service. The Unlock operation is carried in an MPLS Loopback request message sent from a MEP to a trail-end MEP of the LSP to request that the LSP be restored to service. In response, the Unlock operation is carried in an Loopback Response message sent from the trail-end MEP back to the originating MEP to report the result. 4.4.4. Set_Full_Loopback and Set_OAM_Loopback The Set_Full_Loopback and Set_OAM_Loopback are used to set an LSP into FLB mode and OLB mode respectively. These operations are car- ried in an MPLS Loopback request message sent from a MEP to either a MIP or a MEP of the LSP to request that the LSP be set into FLB mode and OLB mode respectively. In response, these operations are carried in an Loopback response message sent from the MIP or MEP, where the Loopback operation has been requested, back to the originating MEP to report the result. 4.4.5. Unset_Full_Loopback and Unset_OAM_Loopback The Unset_Full_Loopback and Unset_OAM_Loopback are used to remove a previously set FLB mode and OLB mode respectively. These operations are carried in an MPLS Loopback request message sent from a MEP to a MIP or a MEP to request that a previously set loopback be removed. In response, these operations are carried in an Loopback response message sent from the MIP or MEP, where the Loopback operation has Boutros, et al. Standards Track [Page 10] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 been requested, back to the originating MEP to report the result. 4.5. Loopback TLVs 4.5.1. 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 Loop- back request message. The use of authentication key is outside the scope of the document. 4.5.2. Source and Target ME TLV The Source and Target ME is used when out-of-band messages are used. The TLV is simply a container. The TLVs defined in [8] are used as sub-TLVs of this 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Data packets When an LSP operates in FLB mode, data packets sent from the node on which the sender MEP resides, will be looped back to that same node. Thus any packet format is permitted. [Do we want to standardize a format for mesurement purposes. If so the following format is suggested.] In order for the sender MEP node to make sure that no data packets are dropped, each data MPLS packets may contain a sequence-id right Boutros, et al. Standards Track [Page 11] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 after the label stack. A time-stamp fields in the datapackets can help calculate the Round trip delay of datapackets. The Local Time- Stamp is set by the sender, and can be used to caluculate the round trip delay after the message is looped back. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label with EOS bit set | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-Stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-Stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Arbitrary Padding | : : | Arbitrary Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. Network Management Operations [This section is incomplete - should it even be in this document?] An operator should be able to provision any given LSR to: 1. Lock/Unlock any MPLS-TP LSP. 2. set any MPLS-TP LSP into loopback mode (either FLB or OLB). 3. send MPLS Loopback packets from a MEP and notify NMS when MPLS Loopback response arrives. When an NMS is used to provision any of the above the functionality, the corresponding MPLS Loopback message need not used. Boutros, et al. Standards Track [Page 12] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 7. Operation 7.1. General Procedures When placing an LSP into FLB mode, the operation MUST first be pre- ceded by a Lock operation. A Lock operation is not required for OLB mode. [To be added: text about construction of request and response mes- sages including text about sender's handle, message ID] 7.2. Sending in-band Loopback messages When sending an MPLS Loopback message in-band, the message is prepended with the Source MEP and Target MIP/MEP ID according to the procedures defined in [8]. The ACH is then prepended with the ACH Channel ID set to 0xHH (TBD). The label stack is then applied. In the case of a PW, this consists of just the outgoing label(s) for the PW. (Note - need to deal with entropy label here). For other MPLS-TP LSPs the label stack consists of the label repre- senting the outbound side of the bi-directional path followed by the GAL. The TTL of the topmost label is set as follows. If the target ME is a MIP, the TTL MUST be set to the exact number of hops required to reach that MIP. If the target ME is a MEP, the value MUST be set to at least the number of hops required to reach that MIP. For most operations where the target is a MEP, the TTL MAY be set to 255. However, to remove a MEP from FLB mode, the sending MEP MUST set the TTL to the exact number of hops required to reach the MEP (if the TTL were set higher, the MPLS Loopback request message would be looped back toward the sender). It is RECOMMENDED that when setting a MEP into FLB mode, the TTL be set to the exact number of hops required to reach the MEP. Boutros, et al. Standards Track [Page 13] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 7.3. Sending out-of-band Loopback messages [To be written] 7.4. Example Topology The next four sections discuss the proceedures for Locking, Unlock- ing, setting an LSP into loopback, and removing the loopback. The description is worded using an example. Assume an MPLS-TP LSP tra- verses nodes A <--> B <--> C <--> D. We will refer to the Mainte- nance Entities involved as MEP-A, MIP-B, MIP-C, and MEP-D respec- tively. Suppose a maintenance operation invoked at node A requires a loopback be set at node C. To invoke FLB mode at node C, A would first need to lock the LSP. The it may proceed to set the loopback at C. Following the loopback operation, A would need to remove the loopback at C and finally unlock the LSP. The following sections describe MEP-A setting and unsetting a lock at MEP-D and then setting and removing a loopback at MIP-C. 7.5. Locking an LSP 1. MEP-A sends an MPLS Loopback request message with the Lock Operation indicated. Optionally, an authentication TLV MAY be included. 2. Upon receiving the MPLS Loopback request message, D uses the received label stack to identify the LSP. If no label binding exists or there is no associated LSP back to the originator, the event is logged. Processing ceases. Otherwise the message is delivered to the target MEP. a. if the source MEP-ID does not match, the event is logged and processing ceases. b. if the target MEP-ID does not match, MEP-D sends a response with a return code of 2 and a cause code 1. MEP-D then examines the message, and: c. if the message is malformed, it sends a response with a return code of 2 and a cause code 2 back to MEP-A. d. if message authentication fails, it MAY send a response with a return code of 2 and a cause code 4 back to MEP-A. Boutros, et al. Standards Track [Page 14] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 e. if any of the TLVs is not known, it sends a response with a return code of 2 and a cause code 3 back to MEP-A. It may also include the unknown TLVs. f. if the MPLS-TP is already locked, it sends a response with return code of 1 (success) and a cause code 5 back to MEP-A. g. if the MPLS-TP is not already locked and cannot be locked, it sends a response with a return code of 2 and a cause code 7 back to A. h. if the MPLS-TP is successfully locked, it sends a response with an return code of 1 (success) and a cause code 0 back to MEP-A. The response is sent using an MPLS Loopback reponse message. An authentication TLV MAY be included. 7.6. Unlocking an LSP 1. MEP-A sends an MPLS Loopback request message with the Lock Operation indicated. Optionally, an authentication TLV MAY be included. 2. Upon receiving the MPLS Loopback request message, D uses the received label stack to identify the LSP. If no label binding exists or there is no associated LSP back to the originator, the event is logged. Processing ceases. Otherwise the message is delivered to the target MEP. a. if the source MEP-ID does not match, the event is logged and processing ceases. b. if the target MEP-ID does not match, MEP-D sends a response with a return code of 2 and a cause code 1. MEP-D then examines the message, and: c. if the message is malformed, it sends a response with a return code of 2 and a cause code 2 back to MEP-A. d. if message authentication fails, it MAY send a response with a return code of 2 and a cause code 4 back to MEP-A. e. if any of the TLVs is not known, it sends a response with a return code of 2 and a cause code 3 back to MEP-A. It may also include the unknown TLVs. Boutros, et al. Standards Track [Page 15] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 f. if the LSP is locked and cannot be unlocked, it sends a response with a return code of 2 and a cause code 8 back to MEP-A. g. if the LSP is successfully unlocked, it sends a response an return code of 1 (success) and a cause code 0 back to MEP-A. The response is sent using an MPLS Loopback reponse message. An authentication TLV MAY be included. 7.7. Setting an LSP into Loopback mode 1. MEP-A sends an MPLS Loopback request message with the Set_Full_Loopback or Set_OAM_Loopback Operation indicated. Optionally, an authentication TLV MAY be included. 2. Upon intercepting the MPLS Loopback request message via TTL expiration, C uses the received label stack to identify the LSP. If no label binding exists or there is no associated LSP back to the originator, the event is logged. Processing ceases. Otherwise the message is delivered to the target MIP/MEP - in this case MIP-C. a. if the source MEP-ID does not match, the event is logged and processing ceases. b. if the target MIP-ID does not match, MIP-C sends a response with a return code of 2 and a cause code 1. MIP-C then examines the message, and: c. if the message is malformed, it sends a response with a return code of 2 and a cause code 2. d. if the message authentication fails, it sends a response with a return code of 2 and a cause code 4. e. if any of the TLV is not known, C sends a response with a return code of 2 and a cause code 3. It may also include the unknown TLVs. f. if the MPLS-TP is already in the requested loopback mode (in this case FLB mode), it sends a response with return code of 1 (success) and a cause code 9. g. if the MPLS-TP is not already in the requested loopback mode (in this case FLB mode) and that loopback mode cannot be set, Boutros, et al. Standards Track [Page 16] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 it sends a response with a return code of 2 and a cause code 11 back to A. h. if the MPLS-TP is successfully programmed into the requested loopback mode (in FLB mode), it sends a response with a return code of 1 (success) and a cause code of 0. The response is sent using an MPLS Loopback reponse message. An authentication TLV MAY be included. 7.8. Removing an LSP from Loopback mode 1. MEP-A sends an MPLS Loopback request message with the Unset_Full_Loopback or Unset_OAM_Loopback Operation indicated. Optionally, an authentication TLV MAY be included. 2. Upon intercepting the MPLS Loopback request message via TTL expiration, C uses the received label stack to identify the LSP. If no label binding exists or there is no associated LSP back to the originator, the event is logged. Processing ceases. Otherwise the message is delivered to the target MIP/MEP - in this case MIP-C. a. if the source MEP-ID does not match, the event is logged and processing ceases. b. if the target MIP-ID does not match, MIP-C sends a response with a return code of 2 and a cause code 1. MIP-C then examines the message, and: c. if the message is malformed, it sends a response with a return code of 2 and a cause code 2. d. if the message authentication fails, it sends a response with a return code of 2 and a cause code 4. e. if any of the TLV is not known, C sends a response with a return code of 2 and a cause code 3. It may also include the unknown TLVs. f. if the MPLS-TP is not in loopback mode, it sends a response with a return code of 2 and a cause code 10. g. if the MPLS-TP is successfully changed from loopback mode to normal mode of operation, it sends a reply with a return code of 1 (success) and a cause code of 0. Boutros, et al. Standards Track [Page 17] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 The response is sent using an MPLS Loopback reponse message. An authentication TLV MAY be included. 7.9. Sending Loopback echo messages [To be written] 7.10. Operating in Full Loopback Mode [To be written] 8. Security Considerations The security considerations for the authentication TLV need further study. 9. IANA Considerations TBD 10. References 10.1. Normative References [1] Bradner. S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [2] L. Martini, et. al., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC4447, April, 2006. [3] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires ", RFC 5085, December 2007. [4] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Boutros, et al. Standards Track [Page 18] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 10.2. Informative [5] M. Bocci, et. al., "MPLS Generic Associated Channel", draft-bocci-mpls-tp-gach-gal-00.txt, work in progress, October 24, 2008. [6] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008. [7] M. Bocci, et. al., "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-00, November 2008. [8] S. Boutros, et. al., " Definition of ACH TLV Structure", draft-bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009. 11. Authors' Addresses Sami Boutros Cisco Systems, Inc. Email: sboutros@cisco.com Siva Sivabalan Cisco Systems, Inc. Email: msiva@cisco.com George Swallow Cisco Systems, Inc. Email: swallow@cisco.com David Ward Cisco Systems, Inc. Email: wardd@cisco.com Stewart Bryant Cisco Systems, Inc. Email: stbryant@cisco.com Carlos Pignataro Cisco Systems, Inc. Email:cpignata@cisco.com Rahul Aggarwal Juniper Networks EMail: rahul@juniper.net Boutros, et al. Standards Track [Page 19] Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009 Nabil Bitar Verizon Email: nabil.bitar@verizon.com Martin Vigoureux Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.com Italo Busi Alcatel-Lucent Email:italo.busi@alcatel-lucent.it Lieven Levrau Alcatel-Lucent Email:llevrau@alcatel-lucent.com Laurent Ciavaglia Alcatel-Lucent Email:laurent.ciavaglia@alcatel-lucent.com Boutros, et al. Standards Track [Page 20] Boutros, et al. Standards Track [Page 22]