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

Versions: (draft-nitinb-lsp-ping-over-mpls-tunnel) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6424

Network Working Group                                         N. Bahadur
Internet-Draft                                               K. Kompella
Updates: 4379 (if approved)                       Juniper Networks, Inc.
Intended status: Standards Track                              G. Swallow
Expires: March 13, 2012                                    Cisco Systems
                                                      September 10, 2011


          Mechanism for performing LSP-Ping over MPLS tunnels
               draft-ietf-mpls-lsp-ping-enhanced-dsmap-11

Abstract

   This document describes methods for performing LSP-Ping (specified in
   RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched
   MPLS label-switched-paths (LSPs).  The techniques outlined in RFC
   4379 are insufficient to perform traceroute Forwarding Equivalency
   Class (FEC) validation and path discovery for an LSP that goes over
   other MPLS tunnels or for a stitched LSP.  This document describes
   enhancements to the downstream-mapping TLV (defined in RFC 4379).
   These enhancements along with other procedures outlined in this
   document can be used to trace such LSPs.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 13, 2012.

Copyright Notice

   Copyright (c) 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



Bahadur, et al.          Expires March 13, 2012                 [Page 1]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

































Bahadur, et al.          Expires March 13, 2012                 [Page 2]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions used in this document  . . . . . . . . . . . .  4
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Packet format  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  New Return Codes . . . . . . . . . . . . . . . . . . . . .  6
       3.2.1.  Return code per downstream . . . . . . . . . . . . . .  6
       3.2.2.  Return code for stitched LSPs  . . . . . . . . . . . .  6
     3.3.  Downstream Detailed Mapping TLV  . . . . . . . . . . . . .  7
       3.3.1.  Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . .  9
         3.3.1.1.  Multipath data sub-TLV . . . . . . . . . . . . . .  9
     3.4.  Deprecation of Downstream Mapping TLV  . . . . . . . . . . 13
   4.  Performing MPLS traceroute on tunnels  . . . . . . . . . . . . 13
     4.1.  Transit node procedure . . . . . . . . . . . . . . . . . . 13
       4.1.1.  Addition of a new tunnel . . . . . . . . . . . . . . . 13
       4.1.2.  Transition between tunnels . . . . . . . . . . . . . . 14
       4.1.3.  Modification to FEC Validation procedure on Transit  . 16
     4.2.  Modification to FEC Validation procedure on Egress . . . . 16
     4.3.  Ingress node procedure . . . . . . . . . . . . . . . . . . 16
       4.3.1.  Processing Downstream Detailed Mapping TLV . . . . . . 17
         4.3.1.1.  Stack Change sub-TLV not present . . . . . . . . . 17
         4.3.1.2.  Stack Change sub-TLV(s) present  . . . . . . . . . 17
       4.3.2.  Modifications to handling to Return Code 3 reply.  . . 19
       4.3.3.  Handling of new return codes . . . . . . . . . . . . . 19
     4.4.  Handling deprecated Downstream Mapping TLV . . . . . . . . 19
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22

















Bahadur, et al.          Expires March 13, 2012                 [Page 3]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


1.  Introduction

   This documents describes methods for performing LSP-Ping (specified
   in [RFC4379]) traceroute over MPLS tunnels.  The techniques in
   [RFC4379] outline a traceroute mechanism that includes Forwarding
   Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP)
   path discovery.  Those mechanisms are insufficient and do not provide
   details when the FEC being traced traverses one or more MPLS tunnels
   and when label-switched-path (LSP) stitching [RFC5150] is in use.
   This document defines enhancements to the downstream-mapping TLV
   [RFC4379] to make it more extensible and to enable retrieval of
   detailed information.  Using the enhanced TLV format along with the
   existing definitions of [RFC4379], this document describes procedures
   by which a traceroute request can correctly traverse MPLS tunnels
   with proper FEC and label validations.

1.1.  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 [RFC2119].


2.  Motivation

   A LSP-Ping traceroute may cross multiple MPLS tunnels en-route the
   destination.  Let us consider a simple case.


   A          B          C           D           E
   o -------- o -------- o --------- o --------- o
     \_____/  | \______/   \______/  | \______/
       LDP    |   RSVP       RSVP    |    LDP
              |                      |
               \____________________/
                        LDP


                      Figure 1: LDP over RSVP tunnel

   When a traceroute is initiated from router A, router B returns
   downstream mapping information for node C in the MPLS echo reply.
   The next MPLS echo request reaches router C with a LDP FEC.  Node C
   is a pure RSVP node and does not run LDP.  Node C will receive the
   MPLS echo request with 2 labels but only 1 FEC in the Target FEC
   stack.  Consequently, node C will be unable to perform FEC complete
   validation.  It will let the trace continue by just providing next-
   hop information based on incoming label, and by looking up the



Bahadur, et al.          Expires March 13, 2012                 [Page 4]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   forwarding state associated with that label.  However, ignoring FEC
   validation defeats the purpose of control plane validatations.  The
   MPLS echo request should contain sufficient information to allow node
   C to perform FEC validations to catch any misrouted echo-requests.

   The above problem can be extended for a generic case of hierarchical
   tunnels or stitched tunnels (e.g.  B-C can be a separate RSVP tunnel
   and C-D can be a separate RSVP tunnel).  The problem of FEC
   validation for tunnels can be solved if the transit routers (router B
   in the above example) provide some information to the ingress
   regarding the start of a new tunnel.

   Stitched LSPs involve 2 or more LSP segments stitched together.  The
   LSP segments can be signaled using the same or different signaling
   protocols.  In order to perform an end-to-end trace of a stitched
   LSP, the ingress needs to know FEC information regarding each of the
   stitched LSP segments.  For example, consider the figure below.


   A          B          C           D          E         F
   o -------- o -------- o --------- o -------- o ------- o
     \_____/    \______/   \______/    \______/  \_______/
       LDP        LDP         BGP         RSVP      RSVP


                          Figure 2: Stitched LSP

   Consider ingress (A) tracing end-to-end stitched LSP A--F.  When an
   MPLS echo request reaches router C, there is a FEC stack change
   happening at router C. With current LSP-Ping [RFC4379] mechanisms,
   there is no way to convey this information to A. Consequently, when
   the next echo request reaches router D, router D will know nothing
   about the LDP FEC that A is trying to trace.

   Thus, the procedures defined in [RFC4379] do not make it possible for
   the ingress node to:

   1.  Know that tunneling has occured
   2.  Trace the path of the tunnel
   3.  Trace the path of stitched LSPs


3.  Packet format








Bahadur, et al.          Expires March 13, 2012                 [Page 5]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


3.1.  Introduction

   In many cases there has been a need to associate additional data in
   the MPLS echo reply.  In most cases, the additional data needs to be
   associated on a per downstream neighbor basis.  Currently, the MPLS
   echo reply contains one downstream map TLV (DSMAP) per downstream
   neighbor.  However the DSMAP format is not extensible and hence it is
   not possible to associate more information with a downstream
   neighbor.  This draft defines a new extensible format for the DSMAP
   and provides mechanisms for solving the tunneled LSP-Ping problem
   using the new format.  In summary, the draft makes the following TLV
   changes:

   o  Addition of new Downstream Detailed Mapping TLV (DDMAP).
   o  Deprecation of existing Downstream Mapping TLV (DSMAP).
   o  Addition of Downstream FEC Stack Change Sub-TLV to DDMAP.

3.2.  New Return Codes

3.2.1.  Return code per downstream

   A new Return Code is being defined "See DDM TLV for Return Code and
   Return SubCode" (Section 6.3) to indicate that the Return Code is per
   Downstream Detailed Mapping TLV (Section 3.3).  This Return Code MUST
   be used only in the message header and MUST be set only in the MPLS
   echo reply message.  If the Return Code is set in the MPLS echo
   request message, then it MUST be ignored.  When this Return Code is
   set, each Downstream Detailed Mapping TLV MUST have an appropriate
   Return Code and Return SubCode.  This Return Code MUST be used when
   there are multiple downstreams for a given node (such as P2MP or
   ECMP), and the node needs to return a Return Code/Return SubCode for
   each downstream.  This Return Code MAY be used even when there is
   only 1 downstream for a given node.

3.2.2.  Return code for stitched LSPs

   When a traceroute is being performed on stitched LSPs (Section 4.1.2)
   the stitching point SHOULD indicate the stitching action to the node
   performing the trace.  This is done by setting the Return Code to
   "Label switched with FEC change" (Section 6.3).  If a node is
   performing FEC hiding, then it MAY choose to set the Return Code to a
   value (specified in [RFC4379]) other than "Label switched with FEC
   change".  The Return Code of "Label switched with FEC change" MUST
   NOT be used if no FEC Stack sub-TLV (Section 3.3.1.3) is present in
   the Downstream Detailed Mapping TLV(s).  This new Return Code MAY be
   used for hierarchical LSPs (for indicating start or end of an outer
   LSP).




Bahadur, et al.          Expires March 13, 2012                 [Page 6]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


3.3.  Downstream Detailed Mapping TLV


        Type #   Value Field
        ------   ------------

        TBD      Downstream detailed mapping


   The Downstream Detailed Mapping object is a TLV that MAY be included
   in an MPLS echo request message.  Only one Downstream Detailed
   Mapping object may appear in an echo request.  The presence of a
   Downstream Detailed Mapping object is a request that Downstream
   Detailed Mapping objects be included in the MPLS echo reply.  If the
   replying router is the destination (Label Edge Router) of the FEC,
   then a Downstream Detailed Mapping TLV SHOULD NOT be included in the
   MPLS echo reply.  Otherwise the replying router SHOULD include a
   Downstream Detailed Mapping object for each interface over which this
   FEC could be forwarded.

       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 2
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               MTU             | Address Type  |    DS Flags   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Downstream Address (4 or 16 octets)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Downstream Interface Address (4 or 16 octets)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Return Code  | Return SubCode|        Sub-tlv length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                      List of Sub TLVs                         .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 3: Downstream Detailed Mapping TLV

   The Downstream Detailed Mapping TLV format is derived from the
   Downstream Mapping TLV format.  The key change is that variable
   length and optional fields have been converted into sub-TLVs.  The
   fields have the same use and meaning as in [RFC4379].  A summary of
   the fields taken from Downstream Mapping TLV is as below:

   Maximum Transmission Unit (MTU)





Bahadur, et al.          Expires March 13, 2012                 [Page 7]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


      The MTU is the size in octets of the largest MPLS frame (including
      label stack) that fits on the interface to the Downstream LSR.

   Address Type

      The Address Type indicates if the interface is numbered or
      unnumbered.  It also determines the length of the Downstream IP
      Address and Downstream Interface fields.


   DS Flags

      The DS Flags field is a bit vector of various flags.

   Downstream Address and Downstream Interface Address

      IPv4 addresses and interface indices are encoded in 4 octets; IPv6
      addresses are encoded in 16 octets.  For details regarding setting
      the address value, refer to [RFC4379].

   The newly added sub-TLVs and their fields are as described below.

   Return code
      The Return Code is set to zero by the sender.  The receiver can
      set it to one of the values specified in the "Multi-Protocol Label
      Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry,
      "Return Codes" sub-registry.

      If the receiver sets a non-zero value of the Return Code field in
      the Downstream Detailed Mapping TLV, then the receiver MUST also
      set the Return Code field in the echo reply header to "See DDM TLV
      for Return Code and Return SubCode" (Section 6.3).  An exception
      to this is if the receiver is a bud node [RFC4461] and is replying
      as both an egress and a transit node with a Return Code of 3
      ("Replying router is an egress for the FEC") in the echo reply
      header.

      If the Return Code of the echo reply message is not set to either
      "See DDM TLV for Return Code and Return SubCode" (Section 6.3) or
      "Replying router is an egress for the FEC", then the Return Code
      specified in the Downstream Detailed Mapping TLV MUST be ignored.

   Return SubCode

      The Return SubCode is set to zero by the sender.  The receiver can
      set it to one of the values specified in the "Multi-Protocol Label
      Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry,
      "Return Codes" sub-registry.  This field is filled in with the



Bahadur, et al.          Expires March 13, 2012                 [Page 8]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


      stack-depth for those codes that specify that.  For all other
      codes, the Return SubCode MUST be set to zero.

      If the Return Code of the echo reply message is not set to either
      "See DDM TLV for Return Code and Return SubCode" (Section 6.3) or
      "Replying router is an egress for the FEC", then the Return
      SubCode specified in the Downstream Detailed Mapping TLV MUST be
      ignored.

   Sub-tlv length
      Total length in bytes of the sub-TLVs associated with this TLV.

3.3.1.  Sub-TLVs

   This section defines the Sub-TLVs that MAY be included as part of the
   Downstream Detailed Mapping TLV.


        Sub-Type    Value Field
        ---------   ------------
        TBD         Multipath data
        TBD         Label stack
        TBD         FEC Stack change


3.3.1.1.  Multipath data sub-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 2
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Multipath Type |       Multipath Length        |Reserved (MBZ) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                  (Multipath Information)                      |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Figure 4: Multipath Sub-TLV

   The multipath data sub-TLV includes multipath information.  The sub-
   TLV fields and their usage is as defined in [RFC4379].  A brief
   summary of the fields is as below:

   Multipath Type






Bahadur, et al.          Expires March 13, 2012                 [Page 9]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


      The type of the encoding for the Multipath Information.

   Multipath Length

      The length in octets of the Multipath Information.

   Multipath Information

      Encoded multipath data, according to the Multipath Type.

3.3.1.2.  Label stack sub-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 2
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Downstream Label                |    Protocol   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Downstream Label                |    Protocol   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 5: Label Stack Sub-TLV

   The Label stack sub-TLV contains the set of labels in the label stack
   as it would have appeared if this router were forwarding the packet
   through this interface.  Any Implicit Null labels are explicitly
   included.  The number of label/protocol pairs present in the sub-TLV
   is determined based on the sub-TLV data length.  The label format and
   protocol type are as defined in [RFC4379].  When the Downstream
   Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be
   included.

   Downstream Label

      A Downstream Label is 24 bits, in the same format as an MPLS label
      minus the TTL field, i.e., the MSBit of the label is bit 0, the
      LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S
      bit.  The replying router SHOULD fill in the EXP and S bits; the
      LSR receiving the echo reply MAY choose to ignore these bits.

   Protocol






Bahadur, et al.          Expires March 13, 2012                [Page 10]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


      This specifies the label distribution protocol for the downstream
      label.

3.3.1.3.  FEC Stack change sub-TLV

   A router MUST include the FEC Stack change sub-TLV when the
   downstream node in the echo reply has a different FEC Stack than the
   FEC stack received in the echo request.  One or more FEC Stack change
   sub-TLVs MAY be present in the Downstream Detailed Mapping TLV.  The
   format is as 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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Operation Type | Address type  | FEC-tlv length|  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Remote Peer Address (0, 4 or 16 octets)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                         FEC TLV                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                    Figure 6: FEC Stack Change Sub-TLV

   Operation Type

      The operation type specifies the action associated with the FEC
      stack change.  The following operation types are defined.

        Type #     Operation
        ------     ---------
        1          Push
        2          Pop



   Address Type

      The Address Type indicates the remote peer's address type.  The
      Address Type is set to one of the following values.  The peer
      address length is determined based on the address type.  The
      address type MAY be different from the address type included in
      the Downstream Detailed Mapping TLV.  This can happen when the LSP
      goes over a tunnel of a different address family.  The address



Bahadur, et al.          Expires March 13, 2012                [Page 11]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


      type MAY be set to Unspecified if the peer-address is either
      unavailable or the transit router does not wish it provide it for
      security or administrative reasons.


        Type #   Address Type   Address length
        ------   ------------   --------------

        0        Unspecified    0
        1        IPv4           4
        2        IPv6           16


   FEC tlv Length
      Length in bytes of the FEC TLV.

   Reserved
      This field is reserved for future use and MUST be set to zero.

   Remote peer address

      The remote peer address specifies the remote peer which is the
      next-hop for the FEC being currently traced.  E.g. in the LDP over
      RSVP case Figure 1, router B would respond back with the address
      of router D as the remote peer address for the LDP FEC being
      traced.  This allows the ingress node to provide information
      regarding FEC peers.  If the operation type is PUSH, the remote
      peer address is the address of the peer from which the FEC being
      pushed was learnt.  If the operation type is POP, the remote peer
      address MAY be set to Unspecified.
      For upstream assigned labels [RFC5331], an operation type of POP
      will have a remote peer address (the upstream node that assigned
      the label) and this SHOULD be included in the FEC Stack change
      sub-TLV.  The remote peer address MAY be set to Unspecified, if
      the address needs to be hidden.

   FEC TLV
      The FEC TLV is present only when FEC-tlv length field is non-zero.
      The FEC TLV specifies the FEC associated with the FEC stack change
      operation.  This TLV MAY be included when the operation type is
      POP.  It MUST be included when the operation type is PUSH.  The
      FEC TLV contains exactly 1 FEC from the list of FECs specified in
      [RFC4379].  A NIL FEC MAY be associated with a PUSH operation if
      the responding router wishes to hide the details of the FEC being
      pushed.

   FEC Stack change sub-TLV operation rules:




Bahadur, et al.          Expires March 13, 2012                [Page 12]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   a.  A FEC Stack change sub-TLV containing a PUSH operation MUST NOT
       be followed by a FEC Stack change sub-TLV containing a POP
       operation.
   b.  One or more POP operations MAY be followed by one or more PUSH
       operations.
   c.  One FEC Stack change sub-TLV MUST be included per FEC stack
       change.  For example, if 2 labels are going to be pushed, then 1
       FEC Stack change sub-TLV MUST be included for each FEC.
   d.  A FEC splice operation (an operation where 1 FEC ends and another
       FEC starts, see Figure 7) MUST be performed by including a POP
       type FEC Stack change sub-TLV followed by a PUSH type FEC Stack
       change sub-TLV.
   e.  A Downstream detailed mapping TLV containing only 1 FEC Stack
       Change sub-TLV with Pop operation is equivalent to IS_EGRESS
       (Return code 3, [RFC4379]) for the outermost FEC in the FEC
       stack.  The ingress router performing the MPLS traceroute MUST
       treat such a case as an IS_EGRESS for the outermost FEC.

3.4.  Deprecation of Downstream Mapping TLV

   This document deprecates the Downstream Mapping TLV.  LSP-ping
   procedures should now use the Downstream Detailed Mapping TLV.
   Detailed procedures regarding interoperability between the deprecated
   TLV and the new TLV are specified in Section 4.4.


4.  Performing MPLS traceroute on tunnels

   This section describes the procedures to be followed by an LSP
   ingress node and LSP transit nodes when performing MPLS traceroute
   over MPLS tunnels.

4.1.  Transit node procedure

4.1.1.  Addition of a new tunnel

   A transit node (Figure 1) knows when the FEC being traced is going to
   enter a tunnel at that node.  Thus, it knows about the new outer FEC.
   All transit nodes that are the origination point of a new tunnel
   SHOULD add the a FEC Stack change sub-TLV (Section 3.3.1.3) to the
   Downstream Detailed Mapping TLV (Figure 3) in the echo reply.  The
   transit node SHOULD add 1 FEC Stack change sub-TLV of operation type
   PUSH, per new tunnel being originated at the transit node.

   A transit node that sends a Downstream FEC Stack change sub-TLV in
   the echo reply SHOULD fill the address of the remote peer; which is
   the peer of the current LSP being traced.  If the transit node does
   not know the address of the remote peer, it MUST set the address type



Bahadur, et al.          Expires March 13, 2012                [Page 13]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   to Unspecified.

   The Label stack sub-TLV MUST contain 1 additional label per FEC being
   PUSHed.  The label MUST be encoded as per Figure 5.  The label value
   MUST be the value used to switch the data traffic.  If the tunnel is
   transparent pipe to the node, i.e. the data-plane trace will not
   expire in the middle of the new tunnel, then a FEC Stack change sub-
   TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD NOT
   contain a label corresponding to the hidden tunnel.

   If the transit node wishes to hide the nature of the tunnel from the
   ingress of the echo request, then it MAY not want to send details
   about the new tunnel FEC to the ingress.  In such a case, the transit
   node SHOULD use the NIL FEC.  The echo reply would then contain a FEC
   Stack change sub-TLV with operation type PUSH and a NIL FEC.  The
   value of the label in the NIL FEC MUST be set to zero.  The remote
   peer address type MUST be set to Unspecified.  The transit node
   SHOULD add 1 FEC Stack change sub-TLV of operation type PUSH, per new
   tunnel being originated at the transit node.  The Label stack sub-TLV
   MUST contain 1 additional label per FEC being PUSHed.  The label
   value MUST be the value used to switch the data traffic.

4.1.2.  Transition between tunnels


   A          B          C           D          E         F
   o -------- o -------- o --------- o -------- o ------- o
     \_____/    \______/   \______/    \______/  \_______/
       LDP        LDP         BGP         RSVP      RSVP



                          Figure 7: Stitched LSPs

   In the above figure, we have 3 seperate LSP segments stitched at C
   and D. Node C SHOULD include 2 FEC Stack change sub-TLVs.  One with a
   POP operation for the LDP FEC and one with the PUSH operation for the
   BGP FEC.  Similarly, node D SHOULD include 2 FEC Stack change sub-
   TLVs, one with a POP operation for the BGP FEC and one with a PUSH
   operation for the RSVP FEC.  Nodes C and D SHOULD set the Return Code
   to "Label switched with FEC change" (Section 6.3) to indicate change
   in FEC being traced.

   If node C wishes to perform FEC hiding, it SHOULD respond back with 2
   FEC Stack change sub-TLVs.  One POP followed by 1 PUSH.  The POP
   operation MAY either exclude the FEC TLV (by setting FEC TLV length
   to 0) or set the FEC TLV to contain the LDP FEC.  The PUSH operation
   SHOULD have the FEC TLV containing the NIL FEC.  The Return Code



Bahadur, et al.          Expires March 13, 2012                [Page 14]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   SHOULD be set to "Label switched with FEC change".

   If node C performs FEC hiding and node D also performs FEC hiding,
   then node D MAY choose to not send any FEC Stack change sub-TLVs in
   the echo reply since the number of labels has not changed (for the
   downstream of node D) and the FEC type also has not changed (NIL
   FEC).  In such a case, node D MUST NOT set the Return Code to "Label
   switched with FEC change".  If node D performs FEC hiding, then node
   F will respond as IS_EGRESS for the NIL FEC.  The ingress (node A)
   will know that IS_EGRESS corresponds to the end-to-end LSP.


   A          B          C           D           E           F
   o -------- o -------- o --------- o --------- o --------- o
     \_____/  |\____________________/            |\_______/
       LDP    |\       RSVP-A                    |    LDP
              | \_______________________________/|
              |       RSVP-B                     |
               \________________________________/
                               LDP




                        Figure 8: Hierarchical LSPs

   In the above figure, we have an end-to-end LDP LSP between nodes A
   and F. The LDP LSP goes over RSVP LSP RSVP-B.  LSP RSVP-B itself goes
   over another RSVP LSP RSVP-A.  When node A initiates a traceroute for
   the end-to-end LDP LSP, then following sequence of FEC Stack change
   sub-TLVs will be performed

   Node B:

   Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.

   Node D:

   Respond with a Return Code of 3 when RSVP-A is top of FEC stack.
   When the echo request contains RSVP-B as top of stack, respond with
   Downstream information for node E and an appropriate Return Code.

   If node B is performing tunnel hiding, then:

   Node B:

   Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC.




Bahadur, et al.          Expires March 13, 2012                [Page 15]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   Node D:

   If D can co-relate that the NIL-FEC corresponds to RSVP-A, which
   terminates at D, then it SHOULD Respond with Return Code of 3.  D can
   also respond with FEC Stack change sub-TLV: POP (since D knows that
   number of labels towards next-hop is decreasing).  Both responses
   would be valid.


   A          B          C        D        E       F       G
   o -------- o -------- o ------ o ------ o ----- o ----- o
        LDP       LDP        BGP   \  RSVP    RSVP /  LDP
                                    \_____________/
                                         LDP



                   Figure 9: Stitched hierarchical LSPs

   In the above case, node D will send 3 FEC Stack change sub-TLVs.  One
   POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for
   RSVP).  Nodes C and D SHOULD set the Return Code to "Label switched
   with FEC change" (Section 6.3) to indicate change in FEC being
   traced.

4.1.3.  Modification to FEC Validation procedure on Transit

   Section 4.4 of [RFC4379] specifies Target FEC stack validation
   procedures.  This document enhances the FEC validation procedures as
   follows.  If the outermost FEC of the target FEC stack is the NIL
   FEC, then the node MUST skip the target FEC validation completely.
   This is to support FEC hiding, in which the outer hidden FEC can be
   the NIL FEC.

4.2.  Modification to FEC Validation procedure on Egress

   Section 4.4 of [RFC4379] specifies Target FEC stack validation
   procedures.  This document enhances the FEC validation procedures as
   follows.  If the outermost FEC of the target FEC stack is the NIL
   FEC, then the node MUST skip the target FEC validation completely.
   This is to support FEC hiding, in which the outer hidden FEC can be
   the NIL FEC.

4.3.  Ingress node procedure

   It is the responsibility of an ingress node to understand tunnel
   within tunnel semantics and LSP stitching semantics when performing a
   MPLS traceroute.  This section describes the ingress node procedure



Bahadur, et al.          Expires March 13, 2012                [Page 16]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   based on the kind of reply an ingress node receives from a transit
   node.

4.3.1.  Processing Downstream Detailed Mapping TLV

   Downstream Detailed Mapping TLV should be processed in the same way
   as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379].
   This section describes the procedures for processing the new elements
   introduced in this document.

4.3.1.1.  Stack Change sub-TLV not present

   This would be the default behavior as described in [RFC4379].  The
   ingress node MUST perform MPLS echo reply processing as per the
   procedures in [RFC4379].

4.3.1.2.  Stack Change sub-TLV(s) present

   If one or more FEC Stack change sub-TLVs (Section 3.3.1.3) are
   received in the MPLS echo reply, the ingress node SHOULD process them
   and perform some validation.

   The FEC stack changes are associated with a downstream neighbor and
   along a particular path of the LSP.  Consequently, the ingress will
   need to maintain a FEC-stack per path being traced (in case of
   multipath).  All changes to the FEC stack resulting from the
   processing of FEC Stack change sub-TLV(s) should be applied only for
   the path along a given downstream neighbor.  The following algorithm
   should be followed for processing FEC Stack change sub-TLVs.






















Bahadur, et al.          Expires March 13, 2012                [Page 17]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


    push_seen = FALSE
    fec_stack_depth = current-depth-of-fec-stack-being-traced
    saved_fec_stack = current_fec_stack

    while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))

        if (sub-tlv == NULL) break

        if (sub-tlv.type == FEC-Stack-Change) {

            if (sub-tlv.operation == POP) {
                if (push_seen) {
                    Drop the echo reply
                    current_fec_stack = saved_fec_stack
                    return
                }

                if (fec_stack_depth == 0) {
                    Drop the echo reply
                    current_fec_stack = saved_fec_stack
                    return
                }

                Pop FEC from FEC stack being traced
                fec_stack_depth--;
            }

            if (sub-tlv.operation == PUSH) {
                push_seen = 1
                Push FEC on FEC stack being traced
                fec_stack_depth++;
            }
         }
     }


     if (fec_stack_depth == 0) {
         Drop the echo reply
         current_fec_stack = saved_fec_stack
         return
     }


         Figure 10: FEC Stack Change Sub-TLV Processing Guideline

   The next MPLS echo request along the same path should use the
   modified FEC stack obtained after processing the FEC Stack change
   sub-TLVs.  A non-NIL FEC guarantees that the next echo request along



Bahadur, et al.          Expires March 13, 2012                [Page 18]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   the same path will have the Downstream Detailed Mapping TLV validated
   for IP address, Interface address and label stack mismatches.

   If the top of the FEC stack is a NIL FEC and the MPLS echo reply does
   not contain any FEC Stack change sub-TLV, then it does not
   necessarily mean that the LSP has not started traversing a different
   tunnel.  It could be that the LSP associated with the NIL FEC
   terminated at a transit node and at the same time a new LSP started
   at the same transit node.  The NIL FEC would now be associated with
   the new LSP (and the ingress has no way of knowing this).  Thus, it
   is not possible to build an accurate hierarchical LSP topology if a
   traceroute contains NIL FECs.

4.3.2.  Modifications to handling to Return Code 3 reply.

   The procedures above allow the addition of new FECs to the original
   FEC being traced.  Consequently, a reply from a downstream node with
   Return Code of 3 (IS_EGRESS) may not necessarily be for the FEC being
   traced.  It could be for one of the new FECs that was added.  On
   receipt of an IS_EGRESS reply, the LSP ingress should check if the
   depth of Target FEC sent to the node that just responded, was the
   same as the depth of the FEC that was being traced.  If it was not,
   then it should pop an entry from the Target FEC stack and resend the
   request with the same TTL (as previously sent).  The process of
   popping a FEC is to be repeated until either the LSP ingress receives
   a non-IS_EGRESS reply or until all the additional FECs added to the
   FEC stack have already been popped.  Using IS_EGRESS reply, an
   ingress can build a map of the hierarchical LSP structure traversed
   by a given FEC.

4.3.3.  Handling of new return codes

   When the MPLS echo reply Return Code is "Label switched with FEC
   change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC
   stack as per the FEC Stack change sub-TLVs contained in the
   downstream detailed mapping TLV.  A transit node can use this Return
   Code for stitched LSPs and for hierarchical LSPs.  In case of Equal
   Cost Multi-Path (ECMP) or Point to Multi-Point (P2MP), there could be
   multiple paths and downstream detailed mapping TLVs with different
   return codes (Section 3.2.1).  The ingress node should build the
   topology based on the Return Code per ECMP path/P2MP branch.

4.4.  Handling deprecated Downstream Mapping TLV

   The Downstream Mapping TLV has been deprecated.  Applications should
   now use the Downstream Detailed Mapping TLV.  The following
   procedures SHOULD be used for backward compatibility with routers
   that do not support the Downstream Detailed Mapping TLV.



Bahadur, et al.          Expires March 13, 2012                [Page 19]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


   o  The Downstream Mapping TLV and the Downstream Detailed Mapping TLV
      MUST never be sent together in the same MPLS echo request or in
      the same MPLS echo reply.
   o  If the echo request contains a Downstream Detailed Mapping TLV and
      the corresponding echo reply contains a Return Code of 2 (one or
      more of the TLVs was not understood), then the sender of the echo
      request MAY resend the echo request with the Downstream Mapping
      TLV (instead of the Downstream Detailed Mapping TLV).  In cases
      where a detailed reply is needed, the sender can choose to ignore
      the router that does not support the Downstream Detailed Mapping
      TLV.
   o  If the echo request contains a Downstream Mapping TLV, then a
      Downstream Detailed Mapping TLV MUST NOT be sent in the echo
      reply.  This is to handle the case that the sender of the echo
      request does not support the new TLV.  The echo reply MAY contain
      Downstream Mapping TLV(s).
   o  If echo request forwarding is in use; such that the echo request
      is processed at an intermediate label switched router (LSR) and
      then forwarded on; then the intermediate router is responsible for
      making sure that the TLVs being used among the ingress,
      intermediate and destination are consistent.  The intermediate
      router MUST NOT forward an echo request or an echo reply
      containing a Downstream Detailed Mapping TLV if it itself does not
      support that TLV.


5.  Security Considerations

   1.  If a network operator wants to prevent tracing inside a tunnel,
       one can use the pipe mode [RFC3443], i.e. hide the outer MPLS
       tunnel by not propagating the MPLS TTL into the outer tunnel (at
       the start of the outer tunnel).  By doing this, MPLS traceroute
       packets will not expire in the outer tunnel and the outer tunnel
       will not get traced.
   2.  If one doesn't wish to expose the details of the new outer LSP,
       then the NIL FEC can be used to hide those details.  Using the
       NIL FEC ensures that the trace progresses without false negatives
       and all transit nodes (of the new outer tunnel) perform some
       minimal validations on the received MPLS echo requests.

   Other security considerations, as discussed in [RFC4379] are also
   applicable to this document.


6.  IANA Considerations

   The suggested values in all sub-sections below have been allocated
   according to the early allocation process.



Bahadur, et al.          Expires March 13, 2012                [Page 20]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


6.1.  New TLV

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

   Downstream Detailed Mapping TLV (See Section 3.3).  Suggested value:
   20.

6.2.  New Sub-TLV types and associated registry

   IANA is requested to create a new registry for the Sub-Type field of
   Downstream Detailed Mapping TLV.  The valid range for this is
   0-65535.  Assignments in the range 0-16383 and 32768-49161 are made
   via Standards Action as defined in [RFC3692]; assignments in the
   range 16384-31743 and 49162-64511 are made via Specification Required
   ([RFC4379]); values in the range 31744-32767 and 64512-65535 are for
   Vendor Private Use, and MUST NOT be allocated.  If a sub-TLV has a
   Type that falls in the range for Vendor Private Use, the Length MUST
   be at least 4, and the first four octets MUST be that vendor's SMI
   Enterprise Code, in network octet order.  The rest of the Value field
   is private to the vendor.

   It is requested that IANA assign sub-TLV types from this new registry
   to the following sub-TLVs (See Section 3.3.1).

   Multipath data sub-TLV: Suggested value: 1

   Label stack sub-TLV: Suggested value: 2

   FEC Stack change sub-TLV: Suggested value: 3

6.3.  New Return Codes

   IANA is requested to assign new Return Code values from the "Multi-
   Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
   Parameters" registry, "Return Codes" sub-registry as follows using a
   Standards Action value.

       Value    Meaning
       -----    -------
       TBD      See DDM TLV for Return Code and Return SubCode
       TBD      Label switched with FEC change

   Suggested values: 14 and 15 respectively





Bahadur, et al.          Expires March 13, 2012                [Page 21]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


7.  Acknowledgements

   The authors would like to thank Yakov Rekhter and Adrian Farrel for
   their suggestions on the draft.


8.  References

8.1.  Normative References

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

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

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

8.2.  Informative References

   [RFC3443]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
              in Multi-Protocol Label Switching (MPLS) Networks",
              RFC 3443, January 2003.

   [RFC4461]  Yasukawa, S., "Signaling Requirements for Point-to-
              Multipoint Traffic-Engineered MPLS Label Switched Paths
              (LSPs)", RFC 4461, April 2006.

   [RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
              "Label Switched Path Stitching with Generalized
              Multiprotocol Label Switching Traffic Engineering (GMPLS
              TE)", RFC 5150, February 2008.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space",
              RFC 5331, August 2008.













Bahadur, et al.          Expires March 13, 2012                [Page 22]

Internet-Draft          LSP-Ping over MPLS tunnel         September 2011


Authors' Addresses

   Nitin Bahadur
   Juniper Networks, Inc.
   1194 N. Mathilda Avenue
   Sunnyvale, CA  94089
   US

   Phone: +1 408 745 2000
   Email: nitinb@juniper.net
   URI:   www.juniper.net


   Kireeti Kompella
   Juniper Networks, Inc.
   1194 N. Mathilda Avenue
   Sunnyvale, CA  94089
   US

   Phone: +1 408 745 2000
   Email: kireeti@juniper.net
   URI:   www.juniper.net


   George Swallow
   Cisco Systems
   1414 Massachusetts Ave
   Boxborough, MA  01719
   US

   Email: swallow@cisco.com
   URI:   www.cisco.com



















Bahadur, et al.          Expires March 13, 2012                [Page 23]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/