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

Versions: (draft-chen-mpls-return-path-specified-lsp-ping) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 7110

Network Working Group                                            M. Chen
Internet-Draft                                                    W. Cao
Intended status: Standards Track            Huawei Technologies Co., Ltd
Expires: March 21, 2014                                          S. Ning
                                                     Tata Communications
                                                               F. Jounay
                                                               Orange CH
                                                               S. Delord
                                                          Alcatel-Lucent
                                                      September 17, 2013


                     Return Path Specified LSP Ping
         draft-ietf-mpls-return-path-specified-lsp-ping-13.txt

Abstract

   This document defines extensions to the data-plane failure-detection
   protocol for Multiprotocol Label Switching (MPLS) Label Switched
   Paths (LSPs) known as "LSP Ping".  These extensions allow selection
   of the LSP to use for the echo reply return path.  Enforcing a
   specific return path can be used to verify bidirectional connectivity
   and also increase LSP ping robustness.

Requirements Language

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

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 21, 2014.





Chen, et al.             Expires March 21, 2014                 [Page 1]

Internet-Draft       Return Path Specified LSP Ping       September 2013


Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statements and Solution Overview  . . . . . . . . . .   3
     2.1.  Limitations of Existing Mechanisms for Bidirectional LSPs   3
     2.2.  Limitations of Existing Mechanisms for Handling
           Unreliable Return Paths . . . . . . . . . . . . . . . . .   4
   3.  Extensions  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Reply Via Specified Path mode . . . . . . . . . . . . . .   5
     3.2.  Reply Path (RP) TLV . . . . . . . . . . . . . . . . . . .   6
     3.3.  Tunnel sub-TLVs . . . . . . . . . . . . . . . . . . . . .   8
       3.3.1.  IPv4 RSVP Tunnel sub-TLV  . . . . . . . . . . . . . .   9
       3.3.2.  IPv6 RSVP Tunnel sub-TLV  . . . . . . . . . . . . . .  10
       3.3.3.  Static Tunnel sub-TLV . . . . . . . . . . . . . . . .  10
     3.4.  Reply TC TLV  . . . . . . . . . . . . . . . . . . . . . .  11
   4.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Sending an Echo Request . . . . . . . . . . . . . . . . .  12
     4.2.  Receiving an Echo Request . . . . . . . . . . . . . . . .  13
     4.3.  Sending an Echo Reply . . . . . . . . . . . . . . . . . .  14
     4.4.  Receiving an Echo Reply . . . . . . . . . . . . . . . . .  14
     4.5.  Non-IP Encapsulation for MPLS-TP LSPs . . . . . . . . . .  15
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  TLVs  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.2.  New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . .  16
     6.3.  New Reply Mode  . . . . . . . . . . . . . . . . . . . . .  16
     6.4.  Reply Path Return Code  . . . . . . . . . . . . . . . . .  16
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19



Chen, et al.             Expires March 21, 2014                 [Page 2]

Internet-Draft       Return Path Specified LSP Ping       September 2013


1.  Introduction

   This document defines extensions to the data-plane failure-detection
   protocol for Multiprotocol Label Switching (MPLS) Label Switched
   Paths (LSPs) known as "LSP Ping" [RFC4379] that can be used to
   specify the return paths for the echo reply message, increasing the
   robustness of LSP Ping, reducing the opportunity for error, and
   improving the reliability of the echo reply message.  A new reply
   mode, which is referred to as "Reply via Specified Path", is added
   and a new Type-Length-Value (TLV), which is referred to as Reply Path
   (RP) TLV, is defined in this memo.  The procedures defined in this
   document currently only apply to "ping" mode.  The "traceroute" mode
   is out of scope for this document.

   In this document, the term bidirectional LSP includes the co-routed
   bidirectional LSP defined in [RFC3945] and the associated
   bidirectional LSP that is constructed from a pair of unidirectional
   LSPs (one for each direction), and which are associated with one
   another at the LSP's ingress/egress points [RFC5654].  The mechanisms
   defined in this document can apply to both IP/MPLS and MPLS Transport
   Profile (MPLS-TP) scenarios.

2.  Problem Statements and Solution Overview

   MPLS LSP Ping is defined in [RFC4379].  It can be used to detect data
   path failures in all MPLS LSPs.

   LSP are increasingly being deployed to provide bidirectional
   services.  The co-routed bidirectional LSP is defined in [RFC3945],
   and the associated bidirectional LSP is defined in [RFC5654].  With
   the deployment of such services, operators have a desire to test both
   directions of a bidirectional LSP in a single operation.

   Additionally, when testing a single direction of an LSP (either a
   unidirectional LSP, or a single direction of a bidirectional LSP)
   using LSP Ping, the validity of the result may be affected by the
   success of delivering the echo reply message.  Failure to exchange
   these messages between the egress Label Switching Router (LSR) and
   the ingress LSR can lead to false negatives where the LSP under test
   is reported as "down" even though it is functioning correctly.

2.1.  Limitations of Existing Mechanisms for Bidirectional LSPs









Chen, et al.             Expires March 21, 2014                 [Page 3]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   With the existing LSP Ping mechanisms as defined in [RFC4379],
   operators have to enable LSP detection on each of the two ends of a
   bidirectional LSP independently.  This not only doubles the workload
   for the operators, but may also bring additional difficulties when
   checking the backward direction of the LSP under the following
   condition:

      The LSR that the operator logged on to perform the checking
      operations might not have out-of-band connectivity to the LSR at
      the far end of the LSP.  That can mean it is not possible to check
      the return direction of a bidirectional LSP in a single operation
      - the operator must log on to the LSR at the other end of the LSP
      to test the return direction.

   Associated bidirectional LSPs have the same issues as those listed
   for co-routed bidirectional LSPs.

   This document defines a mechanism to allow the operator to request
   that both directions of a bidirectional LSP be tested by a single LSP
   Ping message exchange.

2.2.  Limitations of Existing Mechanisms for Handling Unreliable Return
      Paths

   [RFC4379] defines 4 reply modes:

   1. Do not reply
   2. Reply via an IPv4/IPv6 UDP packet
   3. Reply via an IPv4/IPv6 UDP packet with Router Alert
   4. Reply via application level control channel.



   Obviously, the issue of the reliability of the return path for an
   echo reply message does not apply in the first of these cases.

   [RFC4379] states that the third mode may be used when the IP return
   path is deemed unreliable.  This mode of operation requires that all
   intermediate nodes must support the Router Alert option and must
   understand and know how to forward MPLS echo replies.  This is a
   rigorous requirement in deployed IP/MPLS networks especially since
   the return path may be through legacy IP-only routers.

   And in any case, the use modes 2 or 3 cannot guarantee the delivery
   of echo responses through an IP network that is fundamentally
   unreliable.  The failure to deliver echo response messages can lead
   to false negatives making it appear that the LSP has failed.




Chen, et al.             Expires March 21, 2014                 [Page 4]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   Allowing the ingress LSR to control the path used for echo reply
   messages enables an operator to apply an extra level of deterministic
   process to the LSP Ping test.  For example, when testing an LSP, the
   Reply Mode 2 is used at the beginning but no echo reply received.
   When the return path is suspected with failure, the operator can
   initiate another LSP Ping with the Reply Mode defined in this
   document and specify a different return path that is deemed workable
   to complete the test.

   This document defines extensions to LSP Ping that can be used to
   specify the return paths of the echo reply message in an echo request
   message.

3.  Extensions

   LSP Ping defined in [RFC4379] is carried out by sending an echo
   request message.  It carries the Forwarding Equivalence Class (FEC)
   information of the LSP being tested which indicates which MPLS path
   is being verified, along the same data path as other normal data
   packets belonging to the FEC.

   LSP Ping [RFC4379] defines four reply modes that are used to direct
   the egress LSR in how to send back an echo reply.  This document
   defines a new reply mode, the Reply via Specified Path mode.  This
   new mode is used to direct the egress LSR of the tested LSP to send
   the echo reply message back along the path specified in the echo
   request message.

   In addition, two new TLVs, the Reply Path TLV and Reply Traffic Class
   (TC) [RFC5462] TLV, are defined in this document.  The Reply Path TLV
   contains one or more nested sub-TLVs that can be used to carry the
   specified return path information to be used by the echo reply
   message.

3.1.  Reply Via Specified Path mode

   A new reply mode is defined to be carried in the Reply Mode field of
   the echo request message.

   The value of the Reply via Specified Path mode is 5 (This has been
   allocated by IANA using early allocation and is to be confirmed by
   IANA).

       Value    Meaning
       -----    -------
           5     Reply via Specified Path





Chen, et al.             Expires March 21, 2014                 [Page 5]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   The Reply via Specified Path mode is used to request that the remote
   LSR receiving the echo request message sends back the echo reply
   message along the specified paths carried in the Reply Path TLV.

3.2.  Reply Path (RP) TLV

   The Reply Path (RP) TLV is an optional TLV within the LSP Ping
   protocol.  However, if the Reply via Specified Path mode requested as
   described in Section 3.1, the Reply Path (RP) TLV MUST be included in
   an echo request message and its absence is treated as a malformed
   echo request as described in [RFC4379].  Furthermore, if a Reply Path
   (RP) TLV is included in an echo request message, a Reply Path (RP)
   TLV MUST be included in the corresponding echo reply message sent by
   an implementation that is conformant to this specification.

   The Reply Path (RP) TLV carries the specified return path that the
   echo reply message is required to follow.  The format of Reply Path
   TLV is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Reply Path TLV Type       |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Reply Path return code     |           Flags               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Reply Paths                             |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1 Reply Path TLV


   Reply Path TLV Type field is 2 octets in length, and the type value
   is 21.  (This has been allocated by IANA using early allocation and
   is to be confirmed by IANA).

   The Length field is 2 octets in length.  It defines the length in
   octets of the Reply Path return code, Flags and Reply Paths fields.

   The Reply Path return code field is 2 octets in length.  It is
   defined for the egress LSR of the forward LSP to report the results
   of Reply Path TLV processing and return path selection.  This field
   MUST be set to zero in a Reply Path TLV carried on an echo request
   message and MUST be ignored on receipt.  This document defines the
   following Reply Path return codes for inclusion in a Reply Path TLV
   carried on an echo reply:



Chen, et al.             Expires March 21, 2014                 [Page 6]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   Value         Meaning
   ------        ----------------------
   0x0000        Reserved, MUST NOT be used
   0x0001        Malformed Reply Path TLV was received
   0x0002        One or more of the sub-TLVs in Reply Path TLV
                 were not understood
   0x0003        The echo reply was sent successfully using the
                 specified Reply Path
   0x0004        The specified Reply Path was not found, the echo
                 reply was sent via other LSP
   0x0005        The specified Reply Path was not found, the echo
                 reply was sent via pure IP forwarding (non-MPLS)
                 path
   0x0006-0xfffb Not allocated, allocated via Standard Action
   0xfffc-0xffff Experimental Use



   Flags field is also 2 octets in length, it is used to notify the
   egress how to process the Reply Paths field when performing return
   path selection.  The Flags field is a bit vector and has following
   format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MUST be zero         |A|B|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   A (Alternative path): the egress LSR MUST select a non-default path
   as the return path.  This is very useful when reverse default path
   problems are suspected which can be confirmed when the echo reply is
   forced to follow a non-default return path.  Here, the default path
   refers to the path that the egress LSR will use to send the echo
   reply when Reply Mode 2 or 3 is used.  If A bit is set, there is no
   need to carry any specific reply path sub-TLVs, and when received,
   the sub-TLVs SHOULD be ignored.

   B (Bidirectional): the return path is required to follow the reverse
   direction of the tested bidirectional LSP.  If B bit is set, there is
   no need to carry any specific reply path sub-TLVs, and when received,
   the sub-TLVs SHOULD be ignored.

   The A bit and B bit set MUST NOT both be set, otherwise, an echo
   reply with the RP return code set to "Malformed RP TLV was received"
   MUST be returned.






Chen, et al.             Expires March 21, 2014                 [Page 7]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   The Reply Paths field is variable in length and MUST contain zero or
   one sub-TLV.  The sub-TLV, if present, describes the specified path
   that the echo reply message is required to follow.

3.3.  Tunnel sub-TLVs

   [RFC4379] has already defined several Target FEC sub-TLVs, the Target
   FEC sub-TLVs provide a good way to identify a specific return path.
   The Reply Path TLV can carry any (existing and future defined) sub-
   TLV defined for use in the Target FEC Stack TLV to specify the return
   path.

   This document defines three new Target FEC sub-TLVs: IPv4 RSVP Tunnel
   sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV.  One
   usage of these generic RSVP Tunnel sub-TLVs is when LSP Ping is used
   to periodically verify the control plane against the data plane
   [RFC5884], using Tunnel other than particular LSP can avoid the
   impact of LSP identifier changing when Make-Before-Break (MBB) is
   deployed.  These sub-TLVs also can be used in the Reply Path TLV to
   allow the operator to specify a more generic tunnel FEC other than a
   particular LSP as the return path.

   No assignments of sub-TLVs are made directly for TLV Type 21, the
   sub-TLV space and assignments for this TLV Type 21 will be the same
   as that for TLV Type 1.  Sub-types for TLV Type 1 and TLV Type 21
   MUST be kept the same.  Any new sub-type added to TLV Type 1 MUST
   apply to the TLV Type 21 as well.

   With the Return Path TLV flags and the sub-TLVs defined for the
   Target FEC Stack TLV and in this document, it could provide following
   options for return paths specifying:

   1.  Specify a particular LSP as return path

          - use those sub-TLVs defined for the Target FEC Stack TLV

   2.  Specify a more generic tunnel FEC as return path

          - use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in
          Section 3.3.1, Section 3.3.2 and Section 3.3.3 of this
          document

   3.  Specify the reverse path of the bidirectional LSP as return path

          - use B bit defined in Section 3.2 of this document.

   4.  Force return path to non-default path




Chen, et al.             Expires March 21, 2014                 [Page 8]

Internet-Draft       Return Path Specified LSP Ping       September 2013


          - use A bit defined in Section 3.2 of this document.

3.3.1.  IPv4 RSVP Tunnel sub-TLV

   The format of IPv4 RSVP Tunnel sub-TLV is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 RSVP Tunnel sub-TLV Type |        Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IPv4 tunnel end point address                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Flag             |     Tunnel ID                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Extended Tunnel ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 tunnel sender address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 2 IPv4 RSVP Tunnel sub-TLV


   The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV
   that is defined in Section 3.2.3 [RFC4379].  All fields have the same
   semantics as defined in [RFC4379] except that the LSP-ID field is
   omitted and a new Flag field is defined.

   The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
   the recommended type value is TBD1.

   The Flag field is 2 octets in length, it is used to notify the egress
   LSR how to choose the return path.  The Flag field is a bit vector
   and has following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         MUST be zero      |S|P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   P (Primary): the return path MUST be chosen from the LSPs that belong
   to the specified Tunnel and the LSP MUST be the primary LSP.

   S (Secondary): the return path MUST be chosen from the LSPs that
   belong to the specified Tunnel and the LSP MUST be the secondary LSP.

   The terminologies and definitions of primary and secondary LSP are
   defined [RFC4872].




Chen, et al.             Expires March 21, 2014                 [Page 9]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   P bit and S bit MUST NOT both be set, otherwise, an echo reply with
   the RP return code set to "Malformed RP TLV was received" SHOULD be
   returned.  If P bit and S bit are both not set, the return path could
   be any one of the LSPs from the same Tunnel.

3.3.2.  IPv6 RSVP Tunnel sub-TLV

   The format of IPv6 RSVP Tunnel sub-TLV is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 RSVP Tunnel sub-TLV Type |        Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IPv6 tunnel end point address                 |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Flag             |     Tunnel ID                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Extended Tunnel ID                      |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv6 tunnel sender address                  |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 3 IPv6 RSVP Tunnel sub-TLV


   The IPv6 RSVP Tunnel sub-TLV is derived from RSVP IPv6 FEC TLV that
   is defined in Section 3.2.4 of [RFC4379].All fields have the same
   semantics as defined in [RFC4379] except that the LSP-ID field is
   omitted and a new Flag field is defined.

   The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
   the type value is TBD2.

   The Flag field is 2 octets in length and is identical to that
   described in Section 3.3.1.

3.3.3.  Static Tunnel sub-TLV





Chen, et al.             Expires March 21, 2014                [Page 10]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   The format of Static RSVP Tunnel sub-TLV is as follows.  The value
   fields are taken from the definitions in [RFC6370].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Static Tunnel sub-TLV Type |        Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Global ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Node ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Destination Global ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Destination Node ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Source Tunnel Num       |     Destination Tunnel Num    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Flag             |     Must Be Zero              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 4 Static Tunnel sub-TLV


   The Flag field is 2 octets in length and is identical to that
   described in Section 3.3.1.

   The sub-TLV type value is TBD3.

3.4.  Reply TC TLV

   Reply TOS Byte TLV [RFC4379] is used by the originator of the echo
   request to request that an echo reply be sent with the IP header TOS
   byte set to the value specified in the TLV.  Similarly, in this
   document, a new TLV: Reply TC TLV is defined and MAY be used by the
   originator of the echo request to request that an echo reply be sent
   with the TC bits of the return path LSP set to the value specified in
   this TLV.  The Reply TC TLV is not limited to the reply mode
   specified in this document (Reply via Specified Path) but may be used
   in all the other reply modes as well.  The format of Reply TC TLV is
   as follows:











Chen, et al.             Expires March 21, 2014                [Page 11]

Internet-Draft       Return Path Specified LSP Ping       September 2013


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Reply TC TLV type        |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TC  |                    MUST be zero                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Reply TC TLV Type field is 2 octets in length, and the type value
   is TBD4.

   The Length field is 2 octets in length, the value of length field is
   fixed 4 octets.

4.  Theory of Operation

   The procedures defined in this document currently only apply to
   "ping" mode.  The "traceroute" mode is out of scope for this
   document.

   In [RFC4379], the echo reply is used to report the LSP checking
   result to the LSP Ping initiator.  This document defines a new reply
   mode and a new TLV (Reply Path TLV) that enable the LSP ping
   initiator to specify or constrain the return path of the echo reply.
   Similarly the behavior of echo reply is extended to detect the
   requested return path by looking at a specified path FEC TLV.  This
   enables LSP Ping to detect failures in both directions of a path with
   a single operation, this of course cuts in half the operational steps
   required to verify the end to end bidirectional connectivity and
   integrity of an LSP.

   When the return path is an MPLS path, the echo reply MUST carry the
   FEC stack information in a Reply Path TLV to test the return MPLS LSP
   path.  The destination IP address of the echo reply message MUST
   never be used in a forwarding decision.  To avoid this possibility
   the destination IP address of the echo reply message that is
   transmitted along the specified return path MUST be set to numbers
   from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for
   IPv6, and the IP TTL MUST be set 1, and the TTL in the outermost
   label MUST be set to 255.

   When the return path is a pure IP forwarding path, the procedures
   defined in [RFC4379] (the destination IP address is copied from the
   source IP address) apply unchanged.

4.1.  Sending an Echo Request




Chen, et al.             Expires March 21, 2014                [Page 12]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   When sending an echo request, in addition to the rules and procedures
   defined in Section 4.3 of [RFC4379], the reply mode of the echo
   request MUST be set to "Reply via Specified Path", and a Reply Path
   TLV MUST be carried in the echo request message correspondingly.  The
   Reply Path TLV includes one or several reply path sub-TLV(s) to
   identify the return path(s) the egress LSR should use for its reply.

   For a bidirectional LSP, since the ingress LSR and egress LSR of a
   bidirectional LSP are aware of the relationship between the forward
   and backward direction LSPs, only the B bit SHOULD be set in the
   Reply Path TLV.  If the operator wants the echo reply to be sent
   along a different path other than the reverse direction of the
   bidirectional LSP, the "A" bit SHOULD be set or another FEC sub-TLV
   SHOULD be carried in the Reply Path TLV instead, and the B bit MUST
   be clear.

   In some cases, operators may want to treat two unidirectional LSPs
   (one for each direction) as a pair.  There may not be any binding
   relationship between the two LSPs.  Using the mechanism defined in
   this document, operators can run LSP Ping one time from one end to
   complete the failure detection on both unidirectional LSPs.  To
   accomplish this, the echo request message MUST carry (in the Reply
   Path TLV) a FEC sub-TLV that belongs to the backward LSP.

4.2.  Receiving an Echo Request

   "Ping" mode processing as defined in Section 4.4 of [RFC4379] applies
   in this document.  In addition, when an echo request is received, if
   the egress LSR does not know the reply mode defined in this document,
   an echo reply with the return code set to "Malformed echo request"
   and the Subcode set to zero will be send back to the ingress LSR
   according to the rules of [RFC4379].  If the egress LSR knows the
   reply mode, according to the Reply Path TLV, it SHOULD find and
   select the desired return path.  If there is a matched path, an echo
   reply with Reply Path TLV that identify the return path SHOULD be
   sent back to the ingress LSR, the Reply Path return code SHOULD be
   set to "The echo reply was sent successfully using the specified
   return path".  If there is no such path, an echo reply with Reply
   Path TLV SHOULD be sent back to the ingress LSR, the Reply Path
   return code SHOULD be set to relevant code (defined Section 3.2) for
   the real situation to reflect the result of Reply Path TLV processing
   and return path selection.  For example, if the specified LSP is not
   found, the egress then chooses another LSP as the return path to send
   the echo reply, the Reply Path return code SHOULD be set to "The
   specified reply path was not found, the echo reply was sent via other
   LSP", and if the egress chooses an IP path to send the echo reply,
   the Reply Path return code SHOULD be set to "The specified reply path
   was not found, the echo reply was sent via IP path".  If there is



Chen, et al.             Expires March 21, 2014                [Page 13]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   unknown sub-TLV in the received Reply Path TLV, the Reply Path return
   code SHOULD be set to "One or more of the sub-TLVs in Reply Path TLV
   was not understood".

   If the A bit of the Reply Path TLV in a received echo request message
   is set, the egress LSR SHOULD send the echo reply along an non-
   default return path.

   IF the B bit of the Reply Path TLV in a received echo request message
   is set, the egress LSR SHOULD send the echo reply along the reverse
   direction of the bidirectional LSP.

   In addition, the FEC validate results of the forward path LSP SHOULD
   NOT affect the egress LSR continue to test return path LSP.

4.3.  Sending an Echo Reply

   As described in [RFC4379], the echo reply message is a UDP packet,
   and it MUST be sent only in response to an MPLS echo request.  The
   source IP address is a valid IP address of the replier, the source
   UDP port is the well-know UDP port for LSP ping.

   When the return path is an MPLS LSP path, the destination IP address
   of the echo reply message is copied from the destination IP address
   of echo request, the destination UDP port is copied from the source
   UDP port of the echo request.  The IP TTL MUST be set to 1, the TTL
   in the outermost label MUST be set to 255.

   When the return path is a pure IP forwarding path, the same as
   defined in [RFC4379], the destination IP address and UDP port are
   copied from the source IP address and source UDP port of the echo
   request.

   When sending the echo reply, a Reply Path TLV that identifies the
   return path MUST be carried, the Reply Path return code SHOULD be set
   to relevant code that reflects results about how the egress processes
   the Reply Path TLV in a previous received echo request message and
   return path selection.  By carrying the Reply Path TLV in an echo
   reply, it gives the Ingress LSR enough information about the reverse
   direction of the tested path to verify the consistency of the data
   plane against control plane.  Thus a single LSP Ping could achieve
   both directions of a path test.  If the return path is pure IP path,
   no sub-TLVs are carried in the Reply Path TLV.

4.4.  Receiving an Echo Reply

   The rules and process defined in Section 4.6 of [RFC4379] apply here.
   When an echo reply is received, if the reply mode is "Reply via



Chen, et al.             Expires March 21, 2014                [Page 14]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   Specified Path" and the Reply Path return code is "The echo reply was
   sent successfully using the specified return path", and if the return
   path is an MPLS LSP.  The ingress LSR MUST perform FEC validation
   (based on the FEC stack information of the return path carried in the
   Reply Path TLV) as an egress LSR does when receiving an echo request,
   the FEC validation process (relevant to "ping" mode) defined in
   Section 4.4.1 of [RFC4379] applies here.

   When an echo reply is received with return code set to "Malformed
   echo request received" and the Subcode set to zero.  It is possible
   that the egress LSR may not know the "Reply via Specified Path" reply
   mode, the operator may choose to re-perform another LSP Ping by using
   one of the four reply modes defined [RFC4379].

   On receipt of an echo reply with Reply Path return code in the Reply
   Path TLV set to "The specified reply path was not found, ...", it
   means that the egress LSR could not find a matched return path as
   specified.  Operators may choose to specify another LSP as the return
   path or use other methods to detect the path further.

4.5.  Non-IP Encapsulation for MPLS-TP LSPs

   In some MPLS-TP deployment scenarios, IP addressing might not be
   available or use some form of non-IP encapsulation might be
   preferred.  In such scenarios, the Non-IP encapsulation defined in
   [RFC6426] applies here.  The LSP Ping Reply Mode in echo request and
   echo reply is set to 5.  The return path of the echo reply is as
   specified in the Reply Path TLV.

5.  Security Considerations

   Security considerations discussed in [RFC4379] apply to this
   document.  In addition to that, in order to prevent using the
   extension defined in this document for "proxying" any possible
   attacks, the return path LSP MUST have destination to the same node
   where the forward path is from.

6.  IANA Considerations

6.1.  TLVs

   The IANA is requested to assign the temporary assigned value (21) for
   the Reply Path TLV and assign one new value (TBD4) for Reply TC TLV
   from the "Multiprotocol Label Switching Architecture (MPLS) Label
   Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and
   sub-TLVs" sub-registry.





Chen, et al.             Expires March 21, 2014                [Page 15]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   Note: IANA have made an early allocation of the value 21 for Reply
   Path TLV.

   Value   Meaning                           Reference
   -----   -------                           ---------
   21      Reply Path TLV                    this document (sect 3.2)
   TBD4    Reply TC TLV                      this document (sect 3.4)


   The sub-TLV space and assignments for the Reply Path TLV will be the
   same as that for the Target FEC Stack TLV.  Sub-types for the Target
   FEC Stack TLV and the Reply Path TLV MUST be kept the same.  Any new
   sub-type added to the Target FEC Stack TLV MUST apply to the Reply
   Path TLV as well.

6.2.  New Target FEC Stack Sub-TLVs

   IANA is also requested to assign three new sub-TLV types from
   "Multiprotocol Label Switching Architecture (MPLS) Label Switched
   Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV Type
   1" sub-registry.

   Sub-type      Value Field             Reference
   -------       -----------             ---------
   TBD1          IPv4 RSVP Tunnel        this document (sect 3.3.1)
   TBD2          IPv6 RSVP Tunnel        this document (sect 3.3.2)
   TBD3          Static Tunnel           this document (sect 3.3.3)



6.3.  New Reply Mode

   IANA has made an early allocation (5 - Reply via specified path) from
   the "Multi-Protocol Label Switching (MPLS) Label Switched Paths
   (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry.
   IANA is requested to make this allocation permanent.

   Value    Meaning                      Reference
   -----    -------                      ----------
   5        Reply via Specified Path     this document (sect 3.1)


6.4.  Reply Path Return Code

   IANA is requested to create a new registry (as part of mpls-lsp-ping-
   parameters ) for Reply Path return code.

   This document (Section 3.2) defines the following return codes:



Chen, et al.             Expires March 21, 2014                [Page 16]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   Value         Meaning
   ------        ----------------------
   0x0000        No return code
   0x0001        Malformed Reply Path TLV was received
   0x0002        One or more of the sub-TLVs in Reply Path TLV
                 were not understood
   0x0003        The echo reply was sent successfully using the
                 specified Reply Path
   0x0004        The specified Reply Path was not found, the echo
                 reply was sent via other LSP
   0x0005        The specified Reply Path was not found, the echo
                 reply was sent via pure IP forwarding (non-MPLS)
                 path
   0x0006-0xfffb Not allocated, allocated via Standard Action
   0xfffc-0xffff Experimental Use



   The range of 0x0008-0xfffb is not allocated and reserved for future
   extensions and is allocated via Standard Action, the range of 0xfffc-
   0xffff is for Experimental Use.

7.  Contributors

   The following individuals also contributed to this document:

   Ehud Doron
   Orckit-Corrigent
   EMail: ehudd@orckit.com

   Ronen Solomon
   Orckit-Corrigent
   EMail: RonenS@orckit.com

   Ville Hallivuori
   Tellabs
   Sinimaentie 6 C
   FI-02630 Espoo, Finland
   EMail: ville.hallivuori@tellabs.com

   Xinchun Guo
   EMail: guoxinchun@huawei.com


8.  Acknowledgements

   The authors would like to thank Adrian Farrel, Peter Ashwood-Smith,
   Sriganesh Kini, Gregory Mirsky, Eric Gray, Loa Andersson, Carlos



Chen, et al.             Expires March 21, 2014                [Page 17]

Internet-Draft       Return Path Specified LSP Ping       September 2013


   Pignataro and Tom Petch for their review, suggestion and comments to
   this document.

9.  References

9.1.  Normative References

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

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

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.

9.2.  Informative References

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4872]  Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
              Extensions in Support of End-to-End Generalized Multi-
              Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
              2007.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, February 2009.

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

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, June 2010.

   [RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
              On-Demand Connectivity Verification and Route Tracing",
              RFC 6426, November 2011.









Chen, et al.             Expires March 21, 2014                [Page 18]

Internet-Draft       Return Path Specified LSP Ping       September 2013


Authors' Addresses

   Mach(Guoyi) Chen
   Huawei Technologies Co., Ltd
   Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
   Beijing  100095
   China

   Email: mach.chen@huawei.com


   Wei Cao
   Huawei Technologies Co., Ltd
   Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
   Beijing  100095
   China

   Email: wayne.caowei@huawei.com


   So Ning
   Tata Communications

   Email: ning.so@tatacommunications.com


   Frederic Jounay
   Orange CH
   4 rue caudray 1020 Renens
   Switzerland

   Email: frederic.jounay@orange.ch


   Simon Delord
   Alcatel-Lucent
   Building 3, 388 Ningqiao Road, Jinqiao, Pudong
   Shanghai  201206
   China

   Email: simon.delord@alcatel-lucent.com










Chen, et al.             Expires March 21, 2014                [Page 19]


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