[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 draft-boutros-mpls-tp-li-lb

Network Working Group                                 Sami Boutros (Ed.)
Internet Draft                                      Siva Sivabalan (Ed.)
Category: Standards Track
Expiration Date: September 2010
                                                    George Swallow (Ed.)
                                                     Cisco Systems, Inc.

                                                    Rahul Aggarwal (Ed.)
                                                  Juniper Networks, Inc.

                                                  Martin Vigoureux (Ed.)
                                                          Alcatel-Lucent

                                                           March 1, 2010


         Operating MPLS Transport Profile LSP in Loopback Mode


                 draft-boutros-mpls-tp-loopback-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.










Boutros, et al.              Standards Track                    [Page 1]


Internet Draft    draft-boutros-mpls-tp-loopback-03.txt       March 2010


Copyright Notice

   Copyright (c) 2010 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 BSD License.


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 includes mechanism to lock and
   unlock MPLS-TP Tunnels 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-03.txt       March 2010


Table of 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-03.txt       March 2010


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 mechanisms in this document apply to asso-
   ciated bidirectional paths as defined in [7], which include MPLS-TP
   LSPs, bi-directional RSVP-TE tunnels, pseudowires (PW), and Multi-
   segment 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.



Boutros, et al.              Standards Track                    [Page 4]


Internet Draft    draft-boutros-mpls-tp-loopback-03.txt       March 2010


   This message contains a request to instruct C to operate the corre-
   sponding MPLS-TP LSP in either Full Loopback mode or OAM Loopback
   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 mes-
   sage 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-03.txt       March 2010


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-03.txt       March 2010


   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-03.txt       March 2010


      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-03.txt       March 2010


      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-03.txt       March 2010


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-03.txt       March 2010


   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-03.txt       March 2010


   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-03.txt       March 2010


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-03.txt       March 2010


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-03.txt       March 2010


      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-03.txt       March 2010


      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-03.txt       March 2010


         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-03.txt       March 2010


      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-03.txt       March 2010


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
   Juniper Networks
   Email: dward@juniper.net

   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-03.txt       March 2010


   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]


Html markup produced by rfcmarkup 1.120, available from https://tools.ietf.org/tools/rfcmarkup/