Network Working Group                                Sami Boutros (Ed.)
Internet Draft                                     Siva Sivabalan (Ed.)
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: December 5, 2011 February 15, 2012
                                                   Rahul Aggarwal (Ed.)
                                                 Juniper Networks, Inc.

                                                 Martin Vigoureux (Ed.)
                                                         Alcatel-Lucent

                                                       Xuehui Dai (Ed.)
                                                        ZTE Corporation

                                                           June 5,

                                                        August 15, 2011

        MPLS Transport Profile Lock lock Instruct and Loopback Functions
                      draft-ietf-mpls-tp-li-lb-02.txt
                      draft-ietf-mpls-tp-li-lb-03.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 December 5, 2011. February 15, 2012.

Abstract
     This document specifies an extension to MPLS Operation,
   administration, one function and Maintenance (OAM) describes a second
     function which are applicable to operate an Label Switched
   Path (LSP), bi-directional RSVP-TE tunnels, Pseudowires (PW), or
   Multi-segment PWs in loopback mode for management purpose in an MPLS
   based Transport. This extension includes mechanism transport networks. The first
     function enables an operator to lock and
   unlock MPLS-TP Tunnels (i.e. data and control traffic) and can be
   used to loop all traffic (i.e, data and control traffic) at a
   specified LSR on the transport path of while the LSP in
     second enables an MPLS based Transport
   Network back operator to set, in loopback, a given node along
     a transport path. This document also defines the source. However, the mechanisms are intended to
   be applicable extension to other aspects of MPLS as well.
     operation, administration, and maintenance (OAM) to perform the
     lock function.

Table of Contents

   1. Introduction...................................................3 Introduction...................................................2
   2. Terminology....................................................5 Terminology....................................................4
   3. Loopback/Lock Mechanism........................................5 Lock Message...................................................4
      3.1. In-band Message Identification............................5 Identification............................4
      3.2. LI-LB LI Message Format......................................6
      3.3. Return codes..............................................7
      3.4. Cause codes...............................................7
      3.5. Authentication TLV........................................8
      3.6. LSP Ping Extensions.......................................9
         3.6.1. LI-LB Request TLV....................................9
         3.6.2. LI-LB Response TLV...................................9 Format.........................................5
   4. Loopback/Lock Operations.......................................9
      4.1. Lock Request.............................................10
      4.2. Unlock Request...........................................10
      4.3. Loopback Request.........................................10
      4.4. Loopback Removal.........................................11 Operation.................................................5
      4.1. UnLock Operation..........................................6
   5. Data packets..................................................11 Loopback and maintenance operations............................6
   6. Operation.....................................................11 Operation......................................................6
      6.1. General Procedures.......................................11 Procedures........................................6
      6.2. Example Topology.........................................11 Topology..........................................6
      6.3. Locking an LSP...........................................12 a transport path..................................7
      6.4. Unlocking an LSP.........................................13
      6.5. Setting an LSP into Loopback mode........................14
      6.6. Removing an LSP from Loopback mode.......................15 UnLocking a transport path................................7
   7. Security Considerations.......................................16 Considerations........................................7
   8. IANA Considerations...........................................16 Considerations............................................8
      8.1. Pseudowire Associated Channel Type.......................16
      8.2. New LSP Ping TLV types...................................16 Type........................8
   9. Acknowledgements..............................................16 Acknowledgements...............................................8
   10. References...................................................16 References....................................................8
      10.1. Normative References....................................16 References.....................................8
      10.2. Informative References..................................17 References...................................9
   Author's Addresses...............................................17 Addresses................................................9
   Full Copyright Statement.........................................19 Statement.........................................11
   Intellectual Property Statement..................................19 Statement..................................11

1. Introduction

   In traditional transport networks, circuits are provisioned across
   multiple nodes

   This document specifies one function and service providers have the ability describes another function
   which are applicable to operate the MPLS transport circuit such as T1 line in loopback mode for management
   purposes, e.g., networks.

   The first function enables an operator to test or verify connectivity of the circuit up lock a transport path.  The
   second function enables an operator to set that transport path in
   loopback at a
   specific specified node on the path of the circuit, to test along the circuit
   performance with respect to delay/jitter, etc. path. This document provides also
   defines the same loopback capability for extensions to the bi-directional LSPs in MPLS
   based Transport Networks emulating traditional transport circuits. operation, administration and
   maintenance (OAM) to perform the lock function.

   The mechanisms in this document apply Lock function is operated from MEP to co-routed MEP on bidirectional
   paths as defined
   (associated and co-routed) Label Switched Paths (LSPs), Pseudowires
   (including multi-segment Pseudowires). As per RFC 5860 [1], lock is
   an administrative state in [7], which include LSPs, bi-directional RSVP-TE
   tunnels, Pseudowires (PW), it is expected that only test
   traffic and Multi-segment PWs in MPLS based
   Transport Networks. However, the mechanisms are intended to be
   applicable to other aspects of MPLS control traffic (such as well.

   This document specifies how OAM messages dedicated to operate the
   transport path) can be mapped on that transport path.

   The Lock and Loopback
   functions over both the Generic Associated Channel (GACh) and over
   LSP-Ping. LSP-Ping itself function can run either over the GACh or be performed using
   native IP addressing; an extension to the manner in which LSP-Ping is transported MPLS OAM
   as described in
   an MPLS-TP network is out of the scope of this document. next sections. This document uses is a sample topology common mechanism to describe the lock instruct
   PWs and loopback functions.  This sample topology comprises four MPLS-TP
   nodes [A---B---C---D].  There LSPs.

   The Lock function can as well be realized using a management plane.

   The Loopback function is an LSP operated from A MEP to D, and thus A and D
   are MEPs and B MEP on bidirectional
   (associated and C are MIPs.  Unless otherwise specified, the
   operator desires to lock the LSP (this co-routed) Label Switched Paths (LSPs), Pseudowires
   (including multi-segment Pseudowires). The Loopback function is done
   additionally operated from MEP to MIP on A and D, by
   definition) co-routed bidirectional
   LSPs, and loop the LSP at C.

   That is, the desired behavior on multi-segment Pseudowires. The Loopback is a function
   that all packets transmitted by A on
   this locked and looped LSP arrive enables a MEP to request a MEP or a MIP to enter a loopback
   state. This state corresponds to the situation where, at C from B a given
   node, a forwarding plane loop is configured and are encapsulated in the D->A incoming
   direction by C such that these packets reach A.

   Locking and looping an LSP is of a two-step process.  The first step transport path is cross-connected to lock the LSP so that it is not made available to carry user
   traffic. The locking of an LSP is managed by outgoing
   reverse direction. Therefore, except in the two MEPs case of an LSP -
   in this example, A and D.  Locking is controlled early TTL expiry,
   traffic sent by one of the MEPs;
   this example uses A.  A sends a Lock request message to D along the
   LSP, either in the GACh or in LSP-Ping.  This message source will be received by D as it is the far-end MEP for that LSP.  D responds to
   the lock request with an ACK or NACK; the ACK indicates source.
   Note that D has
   taken the LSP out of service (i.e. Locked the LSP) and the NACK
   indicates that D cannot comply with the Lock request.  In general, if before setting a message (e.g. Lock request, Loopback request) cannot be complied
   with, the given node which received the request replies with in Loopback for a NACK and specific
   transport path, this transport path MUST be locked.

   The Loopback can be performed using a
   cause code; management plane. Management
   plane MUST insure that the details of error message processing two MEPs are discussed
   later in this document.

   Once A has received locked before performing the ACK to its
   loopback function.

   The Lock request, A function is then allowed to
   put the LSP in Loopback mode.  In order to set the LSP in Loopback
   mode, A sends based on a Loopback request new G-ACH message to using a new channel
   type as well as an existing TLV.

   When an LSP is locked, the MIP management or MEP where A
   desired the loopback to be enabled.  In this example, A desires to
   set the loopback at C, although note that it control function is possible to A expected
   to set
   the loopback at any node downstream of A (e.g. B, C, D). lock both ends. The TTL on purpose of the Loopback request Lock message is set by A such that the TTL expires
   when it reaches the node where A wants the loopback to be set (in
   this case, C).  C responds to the Loopback request with a reply
   message (ACK/NACK) back to A to indicate whether it has successfully
   set the LSP into ensure the Loopback mode.

   If A receives an ACK from its Loopback request,
   tight coordination of locking and unlocking the LSP two ends. Lock
   Instruct messages may be lost during looping or maintenance
   operations, thus locking both ends is now required, before such
   operations occur.

   Conventions used in
   Loopback mode.  A is free to send any test packets down this LSP as
   it sees fit.  These packets MUST NOT document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be forwared towards D.  As the
   LSP is locked, D MUST NOT transmit any traffic on the LSP in the
   reverse direction (that is, D->A).  Any traffic received by C from
   the reverse direction MUST be dropped and MAY be logged, as the
   receipt of traffic by C in the D->A direction indicates an error.

   When A desires to remove the LSP from Loopback state, it begins to
   reverse the Loopback and Lock.  This is a two-step process; first A
   removes the Loopback from C, then A removes the Lock from D. This
   process is similar to the process of establishing Lock and Loopback
   in the first place.  A sends a Loopback Remove message to C using the
   TTL method described above, and C ACKs or NACKs the Loopback Remove.
   Once A receives the Loopback Remove ACK from C, A sends a Lock Remove
   message to D. D must ACK or NACK this message.  Once A receives the
   Lock Remove ACK from D, the LSP is brought back into normal
   operation.

   The proposed mechanism is based on a new set of messages and TLVs
   which can be transported using one of the following methods:

   (1) An in-band MPLS message transported using a new ACH code point,
   the message will have different types to perform the loopback
   request/remove and Lock/unlock functions, and may carry new set of
   TLVs.

   (2) A new set of TLVs which can be transported using LSP-Ping
   extensions defined in [4], and in compliance to specifications [5].

   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 interpreted as described in RFC-2119 [3]. [2].

2. Terminology

   ACH: Associated Channel Header

   LSR: Label Switching Router

   MEP: Maintenance Entity Group End Point

   MIP: Maintenance Entity Group 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

   TLV: Type Length Value

   TTL: Time To Live

   LI-LB:

   LI: Lock instruct-Loopback Instruct

   Transport path: MPLS-TP LSP or MPLS Pseudowire.

3. Loopback/Lock Mechanism

   For the in-band option, the Lock Message

3.1. In-band Message Identification

   The proposed mechanism uses a new code point in the Associated
   Channel Header (ACH) described in [6].

3.1. In-band Message Identification [4].

  In the in-band option, the LI-LB LI channel is identified by the ACH as
  defined in RFC 5586 [6] [4] with the Channel Type set to the LI-LB LI code
  point = 0xHH.  [HH to be assigned by IANA from the PW Associated
  Channel Type registry]  The LI-LB LI Channel does not use ACH TLVs and MUST not
  NOT include the ACH TLV header. The LI-LB LI ACH Channel 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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|Reserved       |    0xHH ( LI-LB) (LI)                  |      +-+-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: ACH Indication of LI-LB LI

   The LI-LB LI Channel is 0xHH (to be assigned by IANA)

3.2. LI-LB LI Message Format

   The format of an LI-LB LI 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 Vers  | Reserved                              | Refresh Timer |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Return Code   | Cause Code    | Message Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sender's Handle                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Message ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             TLV's                        MEP Source ID TLV                      |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: MPLS LI-LB LI 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 the
   request/response
   message. These changes include any syntactic or semantic changes made
   to any of the fixed fields, or to any Type-
   Length-Value Type-Length-Value (TLV) or sub-TLV 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.)

   Message Type

   Two message types are defined as shown below.

                Message Type          Description
                ------------          -------------
                         0x0          LI-LB request
                         0x1          LI-LB response

   Operation

   Four operations are defined as shown below.

   Refresh Timer: The operations can appear maximum time between successive LI messages
   specified in a Request or Response message.

                   Operation          Description
                   ---------          -------------
                         0x1          Lock
                         0x2          Unlock
                         0x3          Set_Loopback
                         0x4          Unset_Loopback

   Message Length seconds.  The total length of any included TLVs.

   Sender's Handle default value is 1.  The Sender's Handle value 0 is filled in by the sender, and not
   permitted. When a lock is applied, a refresh timer is chosen.  This
   value MUST NOT be copied
   unchanged by the receiver in the MPLS response message (if any).
   There are no semantics associated with this handle, although a sender
   may find this useful changed for matching up requests with replies.

   Message ID

   The Message the duration of that lock.

   MEP Source ID TLV: This is set by the sender of an MPLS "CC/CV MEP ID TLV" defined in [3].

4. Lock Operation

   lock is used to request message. It
   MUST a MEP to take a transport path out of service
   so that some form of maintenance can be copied unchanged by the receiver in the MPLS response message
   (if any).  A done.

   When performing a lock, a sender SHOULD increment this value on each new message.
   A retransmitted message SHOULD leave the value unchanged.

   The Return code and Cause code only have meaning MEP in response to a Response
   message. In a management
   system request message MUST take the Return code transport path out of service and Cause code must be
   set MUST
   send LI messages periodically to zero and ignored on receipt. Return codes and cause codes are
   described in the following Sections.

3.3. Return codes

         Value   Meaning
         -----   -------
            0    Informational
            1    Success
            2    Failure

3.4.   Cause codes

   Value   Meaning
   -----   -------
       0    Success
       1    Fail to match target MIP/MEP ID
       2    Malformed LI-LB request received
       3    One or more MEP at the end of the TLVs is/are unknown
       4    Authentication failed
       5    LSP/PW already locked
       6    LSP/PW already unlocked
       7    Fail to
   transport path. LI messages will be sent once every refresh time
   interval.

   The receiver MEP, will lock LSP/PW
       8    Fail to unlock LSP/PW
       9    LSP/PW already in loopback mode
      10    LSP/PW the transport path as long as it is not in loopback mode
      11    Fail to set LSP/PW in loopback mode
      12    Fail to remove LSP/PW from loopback mode
      13    No label binding for received message
      14    Authentication required but not received.

Note that in the case of cause code 3, the unknown TLV can also be
optionally included in the response. For failure responses with multiple
causes only the first cause code can be included.

3.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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PPP CHAP described in [9] will be used to authenticate the LI-LB
   request.

   The variable length value carried in the optional authentication TLV,
   will include the Packet Format described in section 3.2 of [9].

   The optional authentication TLV can be included in the MPLS OAM LSP
   Ping echo messages containing a LI-LB request TLV or in the inband
   LI-LB Message. When an authentication TLV is present in the Request
   message the CHAP procedures described in section 3.2 of [9] MUST be
   followed.

   The CHAP packets will be transmitted by the authenticator using LI-LB
   Request or response messages, responses to
   receiving the authentication
   protocol messages will be transmitted using LI-LB request or response periodic LI messages.

   If the CHAP negotiation results in a failure, the authenticator or
   the sender of the request message MUST stop requesting the LI-LB
   function.

   A

   The receiver of an LI-LB request, MAY send an error "Authentication
   required but not received", if the optional authentication TLV is not
   included in the LI-LB request.

3.6. LSP Ping Extensions

3.6.1. LI-LB 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                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Operation  |
   +-+-+-+-+-+-+

                   Operation          Description
                   ---------          -------------
                         0x1          Lock
                         0x2          Unlock
                         0x3          Set_Loopback
                         0x4          Unset_Loopback

   A MEP includes a LI-LB Request TLV in the MPLS LSP Ping echo request
   message to request the MEP on the other side of the LSP toperform
   Lock/Unlock and Set/Unset Loopback operations. Only one LI-LB request
   TLV can be present in an LSP Ping Echo request message.

3.6.2. LI-LB 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 = 0x3            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Operation    | ReturnCode     |  CauseCode   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Only one LI-LB response TLV can be present in an LSP Ping Echo
   request message.

4. Loopback/Lock Operations

   When performing a Lock or Loopback function, the reply to a message
   MUST use the same method as the original message. That is, if a node
   requests lock or loopback using LSP Ping then any replies to that
   request must also use LSP Ping; if a node requests lock or loopback
   using in-band, any replies to that request must use in-band. It is
   permissible to use different methods for the lock and the loopback
   functions on a given LSP. For example, a node can lock an LSP using
   the LSP Ping method and then can loop the LSP using the in-band
   method, or vice versa.

   An ACK response of a request will be a response message with return
   code 1 (success) and cause code 0, while a NACK response will have a
   return code 2 (failure) and the corresponding cause code.

4.1. Lock Request

   Lock Request is used to request a MEP to take an LSP out of service
   so that some form of maintenance can be done.

   The receiver MEP MUST send either an ACK or a NAK response to the
   sender MEP. Until the sender MEP receives an ACK, it MUST NOT assume
   that the receiver MEP has taken the LSP out of service. A receiver
   MEP sends an ACK only if it can successfully lock the LSP. Otherwise,
   it sends a NAK.

   The receiver MEP once locked, MUST discard all received traffic.

4.2. Unlock Request

   The Unlock Request is sent from the MEP which has previously sent
   lock request. Upon receiving the unlock request message, the receiver
   MEP brings the LSP back in service.

   The receiver MEP MUST send either an ACK or a NAK response to the
   sender MEP. Until the sender MEP receives an ACK, it MUST NOT assume
   that the LSP has been put back in service. A receiver MEP sends an
   ACK only if the LSP has been unlocked, and unlock operation is
   successful. Otherwise, it sends a NAK.

4.3. Loopback Request

   When a MEP wants to put an LSP in loopback mode, it sends a Loopback
   request message. The message can be intercepted by either a MIP or a
   MEP depending on the MPLS TTL value. The receiver puts in
   corresponding LSP in loopback mode.

   The receiver MEP or MIP MUST send either an ACK or NAK response to
   the sender MEP. An ACK response is sent if the 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 LSP can
   operate in loopback mode.

4.4. Loopback Removal

   When loopback mode operation of an LSP is no longer required, the MEP
   that previously sent the Loopback request message sends another
   Loopback Removal message. The receiver MEP changes the 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. An ACK response is sent if the LSP is already in
   loopback mode, and if the 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 LSP is
   put back in normal operation mode.

5. Data packets

   Data packets sent from the sender MEP will be looped back to that
   sender MEP. OAM packets not intercepted by TTL expiry will as well be
   looped back. The use of data packets to measure packet loss, delay
   and delay variation is outside the scope of this document.

6. Operation

6.1. General Procedures

   When placing an LSP into Loopback mode, the operation MUST first be
   preceded by a Lock operation.

   When sending Loopback Request/Removal using LSP Ping or in-Band
   messages the TTL of the topmost label is set as follows:-

   If the target node is a MIP, the TTL MUST be set to the exact number
   of hops required to reach that MIP.

   If the target node is a MEP, the value MUST be set to at least the
   number of hops required to reach that MEP. For most operations where
   the target is a MEP, the TTL MAY be set to 255.

   However, to remove a MEP from Loopback 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 Loopback removal message would be looped
   back toward the sender).

6.2. Example Topology

   The next four sections discuss the procedures for Locking, Unlocking,
   setting an LSP into loopback, and removing the loopback.  The
   description is worded using an example. Assume an LSP traverses nodes
   A <--> B <--> C <--> D.  We will refer to the Maintenance Entities
   involved as MEP-A, MIP-B, MIP-C, and MEP-D respectively.  Suppose a
   maintenance operation invoked at MEP-A requires a loopback be set at
   MIP-C. To invoke Loopack mode at MIP-C, A would first need to lock
   the LSP. Then 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.

6.3. Locking an LSP

   1. MEP-A sends an MPLS LSP Ping Echo request message with the Lock
   TLV or an in-Band Lock request Message. Optionally, an authentication
   TLV MAY be included.

   2. Upon receiving the request message, D uses the received label
   stack and the Target Stack FEC TLV as per [5]/source MEP-ID 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 failure
   response with cause code 1.

   MEP-D then examines the message, and:

   c. if the message is malformed, it sends a failure response with
   cause code 2 back to MEP-A.

   d. if message authentication fails, it MAY send a failure response
   with cause code 4 back to MEP-A.

   e. if any of the TLVs is not known, it sends a failure response with
   cause code 3 back to MEP-A. It may also include the unknown TLVs.

   f. if the LSP is already locked, it sends a response with
   cause code 5 back to MEP-A.

   g. if the LSP is not already locked and cannot be locked, it sends a
   failure response with cause code 7 back to A.

   h. if the LSP is successfully once locked, it sends a success response
   with cause code 0 (Success) back to MEP-A.

   The response is sent using an MPLS LSP Ping echo reply with a
   response TLV or an in-Band Lock response message. An authentication
   TLV MAY be included.

   MEP-D will lock the LSP, resulting in that all traffic from D to A,
   including all OAM traffic, stops.

     a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv
        and cc packets, but since it has been informed that the LSP will
        be locked it will take no action(s).

     b. When MEP-A receives the LI ACK, MEP-A discontinues sending
        other OAM traffic, e.g. cv and cc packets. MEP-D will detect
        this, but since it is in Locked state it will MUST take no action.

6.4. Unlocking an LSP

   1. MEP-A sends an MPLS Echo request message with the unLock TLV or an
   in-Band unLock request Message. Optionally, an authentication TLV MAY
   be included.

   2. Upon receiving the unLock request message, D uses the received
   label stack and target FEC/source MEP-ID as per [5] 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 failure
   response with cause code 1.

   MEP-D then examines the message, and:

   c. if the message is malformed, it sends a failure response with
   cause code 2 back to MEP-A.

   d. if message authentication fails, it MAY send a failure response
   with cause code 4 back to MEP-A.

   e. if any transport path out of the TLVs
   service.

4.1. UnLock Operation

   Unlock is not known, it sends a failure response with
   cause code 3 back used to MEP-A. It may also include the unknown TLVs.

   f. if the LSP is already unlocked, it sends request a response with
   cause code 6 back MEP to MEP-A.

   g. if bring the LSP is previously locked and cannot be unlocked, it sends a response
   with cause code 8
   transport path back to MEP-A.

   h. if the LSP is successfully unlocked, it sends in service.

   When a success response
   with cause code 0 (Success) back to MEP-A.

   The response MEP is sent using an MPLS LSP Ping echo reply with a
   response TLV or an in-Band unlock response message. An authentication
   TLV MAY be included.

6.5. Setting an LSP into Loopback mode

   1. MEP-A sends an MPLS LSP Ping Echo request message with the
   loopback TLV or an in-Band Loopback request message. Optionally, an
   authentication TLV MAY be included.

   2. Upon intercepting the MPLS Loopback message unlocked via TTL expiration, C
   uses management or control it MUST cease
   sending LI messages. Further, it must have stopped receiving LI
   messages for a period of 3.5 times the previously received label stack and target FEC/source MEP-ID as per [5]
   to identify refresh
   timer before it brings the LSP.

   If no label binding exists or there is no associated LSP transport path 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 failure
   response with cause code 1.

   MIP-C then examines the message, and:

   c. if the message is malformed, it sends a failure response with
   cause code 2 service.

   A MEP would unlock transport path and put it back to MEP-A.

   d. service if and
   only if there is no management request to lock the message authentication fails, path and it sends a failure response
   with cause code 4 back is not
   receiving in-band LI messages.

5. Loopback and maintenance operations

   When an LSP is locked, the management or control function is expected
   to MEP-A.

   e. if any lock both ends. The purpose of the TLV LI message is not known, C sends a failure response with
   cause code 3 back to MEP-A. It may also include ensure the unknown TLVs.

   f. if
   tight coordination of locking and unlocking the LSP two ends.  LI
   messages may be lost during looping or maintenance operations, thus
   locking both ends is required, before such operations occur.

   When a transport path is already put in loopback, traffic sent from the requested loopback mode, it sends a
   failure response with cause code 9
   sender MEP will be looped back to MEP-A.

   g. if the LSP is that sender MEP. OAM packets not already in the requested loopback mode
   intercepted by TTL expiry will as well be looped back. The use of
   traffic to measure packet loss, delay and that
   loopback mode cannot delay variation is outside
   the scope of this document.

6. Operation

6.1. General Procedures

   When taking a transport path out of service, the operation MUST first
   be set, it sends preceded by a failure response with cause
   code 11 back to MEP-A.

   h. if lock operation.

6.2. Example Topology

   The next sections discuss the LSP is successfully programmed into procedures for locking, Unlocking a
   transport path.  Assume a transport path traverses nodes A <--> B <--
   > C <--> D.  We will refer to the requested  loopback
   mode, it sends Maintenance Entities involved as
   MEP-A, MIP-B, MIP-C, and MEP-D respectively. Suppose a success response with cause code 0 (Success) back maintenance
   operation invoked at MEP-A requires to
   MEP-A. lock the transport path.

   The response is sent using an MPLS LSP Ping echo reply with following sections describe MEP-A setting and unsetting a
   response TLV or an in-Band Loopback response message. An
   authentication TLV MAY be included.

6.6. Removing an LSP from Loopback mode lock at
   MEP-D.

6.3. Locking a transport path

   1. MEP-A sends an in-band LI Message in response to a MPLS LSP Ping Echo Management
   system request to lock the transport path. The message with will include
   the Loopback
   removal TLV or an in-Band Loopback removal request message.
   Optionally, an authentication TLV MAY be included. source MEP-ID TLV.

   2. Upon intercepting receiving the MPLS Loopback removal message via TTL
   expiration, C LI message, D uses the received label stack and
   the target FEC/source source MEP-ID as per [5] [3] to identify the LSP. transport path. If no
   label binding exists or there is no associated LSP transport path back to
   the originator, or if the source MEP-ID does not match, the event is
   logged.  Processing ceases. Otherwise the message is delivered processed.

6.4. UnLocking a transport path

   1. In response to a Management system request to unlock the target MIP/MEP - in this
   case MIP-C.

   a. if transport
   path MEP-A stops sending LI Messages.

   2. After 3.5 times the source MEP-ID does not match, refresh timer, both sender MEP A and receive
   MEP D unlock the event is logged transport path and
   processing ceases.

   b. if put the target MIP-ID does not match, MIP-C sends a failure
   response with cause code 1 transport path back to MEP-A.

   MIP-C then examines in
   service.

7. Security Considerations

   MPLS-TP is a subset of MPLS and so builds upon many of the message, and:

   c. if aspects of
   the message is malformed, security model of MPLS. MPLS networks make the assumption that it sends
   is very hard to inject traffic into a failure response with network, and equally hard to
   cause code 2 back traffic to MEP-A.

   d. if be directed outside the message authentication fails, it sends network. The control plane
   protocols utilize hop-by-hop security, and assume a failure response
   with cause code 4 back to MEP-A.

   e. if any "chain-of-trust"
   model such that end-to-end control plane security is not used. For
   more information on the generic aspects of MPLS security, see [5].

   This document describes a protocol carried in the TLV G-ACh [4], and so
   is dependent on the security of the G-ACh, itself. The G-ACh is not known, C sends a failure response with
   cause code 3 back to MEP-A. It may also include
   generalization of the unknown TLVs.

   f. if Associated Channel defined in [6]. Thus, this
   document relies heavily on the security mechanisms provided for the
   Associated Channel and described in those two documents.

   A specific concern for the LSP G-ACh is not in loopback mode, it sends a failure response
   with cause code 10 back that is can be used to MEP-A.

   g. if provide a
   covert channel. This problem is wider than the LSP loopback cannot scope of this
   document and does not need to be removed, addressed here, but it sends a failure response
   with cause code 12 back to MEP-A.

   h. if should be
   noted that the LSP channel provides end-to-end connectivity and SHOULD
   NOT be policed by transit nodes. Thus, there is successfully changed from loopback mode to normal
   mode no simple way of
   preventing any traffic being carried between in the G-ACh consenting
   nodes.

   A good discussion of the data plane security of operation, it sends a reply with cause code 0 (Success ) back
   to MEP-A.

   The response is sent using an MPLS LSP Ping echo reply with a
   response TLV or an in-Band Loopback removal response message. An
   authentication TLV MAY associated channel
   may be included.

7. Security Considerations

   Security found in [7]. That document also describes some mitigation
   techniques.

   It should be noted that the G-ACh is addressed through essentially connection-oriented
   so injection or modification of control messages specified in this
   document require the use subversion of authentication TLV a transit node. Such subversion is
   generally considered hard in MPLS networks, and impossible to protect
   against at the
   the Challenge-Handshake Authentication protocol procedures described
   in section [9]. level. Management level techniques are more
   appropriate.

8. IANA Considerations

8.1. Pseudowire Associated Channel Type

   LI-LB

   LI OAM requires a unique Associated Channel Type which is assigned by
   IANA from the Pseudowire Associated Channel Types Registry.

   Registry:
      Value        Description              TLV Follows  Reference
      -----------  -----------------------  -----------  ---------
      0xHHHH       LI-LB       LI                    No           (Section 3.1)

8.2. New LSP Ping TLV types

   IANA is requested to assign TLV type values to the following TLVs
   from the "Multiprotocol Label Switching Architecture (MPLS) Label
   Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-
   TLVs" sub-registry.

     1. LI-LB Request TLV (See section 3.3.1)
     2. LI-LB Response TLV (See section 3.3.2)
     3. Authentication TLV (See section 3.3.3)

9. Acknowledgements

   The authors would like to thank Loa Andersson for his valuable
   comments.

10. References

10.1. Normative References

   [1]   Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
         S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
         September 2009.

   [2]   Vigoureux, M., Ward, D., and M. Betts, "Requirements for
         Operations, Administration, and Maintenance (OAM) in MPLS
         Transport Networks", RFC 5860, May 2010.

   [3]

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [4]   K. Kompella, G. Swallow, "Detecting Multi-Protocol Label
         Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.

   [5]   N. Bahadur,

   [3]   D. Allan, et. al., "MPLS on-demand Proactive Connectivity Verification,
         Route Tracing
         Continuity Check and Adjacency Verification", draft-ietf-mpls-tp-
         on-demand-cv-00, Remote Defect indication for MPLS
         Transport Profile draft-ietf-mpls-tp-cc-cv-rdi-06, work in
         progress, June 2010

   [6]

   [4]   Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
         Associated Channel", RFC 5586, June 2009.

   [5]   L. Fang, "Security Framework for MPLS and GMPLS Networks", RFC
         5920, July 2010.

   [6]   S. Bryant, G. Swallow, L. Martini "Pseudowire Emulation Edge-
         to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC
         4385, Feb 2006.

   [7]   T. Nadeau, C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, Dec 2007.

10.2. Informative References

   [1]   Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-ietf-
         mpls-tp-identifiers-01
         mpls-tp-identifiers-07 (work in progress), June 2010.

   [8]

   [2]   Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
         S.Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
         September 2009.

   [9]   B. Lloyd, L&A, and W. Simpson, "PPP Authentication Protocols",
         October 1992.

10.2. Informative References

   [10]

   [3]   Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire
         Emulation Edge-to-Edge (PWE3) ", RFC5254, RFC 5254, October 2008.

Author's Addresses

    Sami Boutros
   Cisco Systems, Inc.
   Email: sboutros@cisco.com

   Siva Sivabalan
   Cisco Systems, Inc.
   Email: msiva@cisco.com

   Rahul Aggarwal
   Juniper Networks.
   EMail: rahul@juniper.net

   Martin Vigoureux
   Alcatel-Lucent.
   Email: martin.vigoureux@alcatel-lucent.com

   Xuehui Dai
   ZTE Corporation.

   Email: dai.xuehui@zte.com.cn

   George Swallow
   Cisco Systems, Inc.
   Email: swallow@cisco.com

   David Ward
   Juniper Networks.
   Email: dward@juniper.net

   Stewart Bryant
   Cisco Systems, Inc.
   Email: stbryant@cisco.com

   Carlos Pignataro
   Cisco Systems, Inc.
   Email: cpignata@cisco.com

   Eric Osborne
   Cisco Systems, Inc.
   Email: eosborne@cisco.com

   Nabil Bitar
   Verizon.
   Email: nabil.bitar@verizon.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

   Bo Wu
   ZTE Corporation.
   Email: wu.bo@zte.com.cn
   Jian Yang
   ZTE Corporation.
   Email: yang_jian@zte.com.cn

Full Copyright Statement

   Copyright (c) 2008 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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 Provions.

   For the avoindance od 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.