doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc7110.txt b/doc/rfc/rfc7110.txt
new file mode 100644
index 0000000..ff8f685
--- /dev/null
+++ b/doc/rfc/rfc7110.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           M. Chen
+Request for Comments: 7110                                        W. Cao
+Category: Standards Track                   Huawei Technologies Co., Ltd
+ISSN: 2070-1721                                                  S. Ning
+                                                     Tata Communications
+                                                               F. Jounay
+                                                               Orange CH
+                                                               S. Delord
+                                                            January 2014
+
+
+          Return Path Specified Label Switched Path (LSP) Ping
+
+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 a selection
+   of the LSP to be used for the echo reply return path.  Enforcing a
+   specific return path can be used to verify bidirectional connectivity
+   and also increase LSP ping robustness.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7110.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 1]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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. Requirements Language ...........................................3
+   3. Problem Statements and Solution Overview ........................3
+      3.1. Limitations of Existing Mechanisms for Bidirectional LSPs ..4
+      3.2. Limitations of Existing Mechanisms for Handling
+           Unreliable Return Paths ....................................4
+   4. Extensions ......................................................5
+      4.1. Reply via Specified Path Mode ..............................6
+      4.2. Reply Path (RP) TLV ........................................6
+      4.3. Tunnel Sub-TLVs ............................................8
+           4.3.1. IPv4 RSVP Tunnel Sub-TLV ...........................10
+           4.3.2. IPv6 RSVP Tunnel Sub-TLV ...........................11
+           4.3.3. Static Tunnel Sub-TLV ..............................12
+      4.4. Reply TC TLV ..............................................12
+   5. Theory of Operation ............................................13
+      5.1. Sending an Echo Request ...................................14
+      5.2. Receiving an Echo Request .................................14
+      5.3. Sending an Echo Reply .....................................15
+      5.4. Receiving an Echo Reply ...................................16
+      5.5. Non-IP Encapsulation for MPLS-TP LSPs .....................16
+   6. Security Considerations ........................................16
+   7. IANA Considerations ............................................17
+      7.1. TLVs ......................................................17
+      7.2. New Target FEC Stack Sub-TLVs .............................17
+      7.3. New Reply Mode ............................................17
+      7.4. Reply Path Return Code ....................................18
+   8. Contributors ...................................................19
+   9. Acknowledgements ...............................................19
+   10. References ....................................................19
+      10.1. Normative References .....................................19
+      10.2. Informative References ...................................20
+
+
+
+Chen, et al.                 Standards Track                    [Page 2]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+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) that 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.  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 [RFC2119].
+
+3.  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.
+
+   LSPs 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.
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 3]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+3.1.  Limitations of Existing Mechanisms for Bidirectional LSPs
+
+   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.
+
+3.2.  Limitations of Existing Mechanisms for Handling Unreliable Return
+      Paths
+
+   [RFC4379] defines four 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 support the Router Alert option and understand 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.
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 4]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+   In any case, the use of Reply 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.
+
+   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,
+   Reply Mode 2 is used at the beginning but no echo reply is received.
+   When failure of the return path is suspected, 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.
+
+4.  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.  The FEC information 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 (RP) TLV" and "Reply
+   Traffic Class (TC) TLV" [RFC5462], 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 5]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+4.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
+
+   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.
+
+4.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 4.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 Path                           |
+       ~                                                               ~
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                           Figure 1: Reply Path TLV
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 6]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+   Reply Path TLV Type:  It is 2 octets in length, and the type value is
+      21.
+
+   Length:  It is 2 octets in length.  It defines the length in octets
+      of the Reply Path return code, Flags, and Reply Path fields.
+
+   Reply Path return code:  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:
+
+   Value         Meaning
+   ------        ----------------------
+   0x0000        Reserved, MUST NOT be used
+   0x0001        Malformed Reply Path TLV was received
+   0x0002        One or more of the sub-TLVs in the 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 another LSP
+   0x0005        The specified Reply Path was not found, the echo
+                 reply was sent via pure IP forwarding (non-MPLS)
+                 path
+   0x0006-0xfffb Unassigned
+   0xfffc-0xffff Experimental Use
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 7]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+   Flags:  It 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|
+           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                    Figure 2:  Flags
+
+         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 that 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 flag and B flag MUST NOT both be set, otherwise, an echo
+         reply with the RP return code set to "Malformed Reply Path TLV
+         was received" MUST be returned.
+
+   Reply Path:  It is used to describe the return path that an echo
+      reply will be send along.  It is variable in length and can
+      contain zero, one or more Target FEC sub-TLVs [RFC4379].  In an
+      echo request, it carries sub-TLVs that describe the specified path
+      that the echo reply message is required to follow.  In an echo
+      reply, the sub-TLVs describe the FEC Stack information of the
+      return path (when the return path is an MPLS path) that the echo
+      reply will be sent along.
+
+4.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.
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 8]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+   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 a Tunnel other than a particular LSP can avoid the
+   impact of an 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 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 the
+   following options for return paths specifying:
+
+   1.  a particular LSP as return path
+
+          - use those sub-TLVs defined for the Target FEC Stack TLV
+
+   2.  a more generic tunnel FEC as return path
+          - use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in
+            Sections Section 4.3.1, Section 4.3.2, and Section 4.3.3 of
+            this document
+
+   3.  the reverse path of the bidirectional LSP as return path
+
+          - use B bit defined in Section 4.2 of this document.
+
+   4.  Force return path to non-default path
+
+          - use A bit defined in Section 4.2 of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 9]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+4.3.1.  IPv4 RSVP Tunnel Sub-TLV
+
+   The format of the 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                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Flags            |     Tunnel ID                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Extended Tunnel ID                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   IPv4 tunnel sender address                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 3: 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 of [RFC4379].  All fields have the
+   same semantics as defined in [RFC4379] except that the LSP-ID field
+   is omitted and a new Flags field is defined.
+
+   The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
+   the recommended type value is 26.
+
+   The Flags field is 2 octets in length, it is used to notify the
+   egress LSR how to choose the return path.  The Flags field is a bit
+   vector and has following format:
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         MUST be zero      |S|P|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Figure 4: Tunnel Flags
+
+   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.
+   Primary and secondary LSPs are defined in [RFC4872].
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 10]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+   P bit and S bit MUST NOT both be set, otherwise, an echo reply with
+   the RP return code set to "Malformed Reply Path 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.
+
+4.3.2.  IPv6 RSVP Tunnel Sub-TLV
+
+   The format of the 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                 |
+   |                                                               |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Flags            |     Tunnel ID                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Extended Tunnel ID                      |
+   |                                                               |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   IPv6 tunnel sender address                  |
+   |                                                               |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 5: IPv6 RSVP Tunnel Sub-TLV
+
+   The IPv6 RSVP Tunnel sub-TLV is derived from the 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 Flags field is defined.
+
+   The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
+   the type value is 27.
+
+   The Flags field is 2 octets in length and is identical to that
+   described in Section 4.3.1.
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 11]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+4.3.3.  Static Tunnel Sub-TLV
+
+   The format of the 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    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Flags            |     Must Be Zero              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 6: Static Tunnel Sub-TLV
+
+   The Flags field is 2 octets in length and is identical to that
+   described in Section 4.3.1.
+
+   The sub-TLV type value is 28.
+
+4.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.                 Standards Track                   [Page 12]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+    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                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 7: Reply TC TLV
+
+   The Reply TC TLV Type field is 2 octets in length, and the type value
+   is 22.
+
+   The Length field is 2 octets in length, the value of length field is
+   fixed 4 octets.
+
+5.  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; of course, this 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 Time to Live (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.
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 13]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+5.1.  Sending an Echo Request
+
+   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 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.
+
+5.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 received" 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 a Reply Path TLV that identifies 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 Reply Path".  If there is no such path, an echo
+   reply with the Reply Path TLV SHOULD be sent back to the ingress LSR,
+   the Reply Path return code SHOULD be set to the relevant code
+   (defined in Section 4.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 another LSP", and if the egress chooses an IP
+   path to send the echo reply, the Reply Path return code SHOULD be set
+
+
+
+Chen, et al.                 Standards Track                   [Page 14]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+   to "The specified Reply Path was not found, the echo reply was sent
+   via pure IP forwarding (non-MPLS) path".  If there is an 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 the Reply Path TLV were 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 a 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.
+
+5.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, the destination IP address of
+   the echo reply message is copied from the destination IP address of
+   the echo request, and 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.
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 15]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+5.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
+   Specified Path" and the Reply Path return code is "The echo reply was
+   sent successfully using the specified Reply 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.
+
+5.5.  Non-IP Encapsulation for MPLS-TP LSPs
+
+   In some MPLS-TP deployment scenarios, IP addressing might not be
+   available or the use of 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 the echo request
+   and echo reply is set to 5.  The return path of the echo reply is as
+   specified in the Reply Path TLV.
+
+6.  Security Considerations
+
+   Security considerations discussed in [RFC4379] apply to this
+   document.
+
+   In addition, the extensions defined in this document may be used for
+   potential "proxying" attacks.  For example, an echo request initiator
+   may specify a return path that has a destination different from that
+   of the initiator.  But normally, such attacks will not happen in an
+   MPLS domain where the initiators and receivers belong to the same
+   domain.  Even this, in order to prevent using the extension defined
+   in this document for proxying any possible attacks, the return path
+   LSP should have destination to the same node where the forward path
+   is from.  The receiver may drop the echo request when it cannot
+   determine whether the return path LSP has the destination to the
+
+
+
+Chen, et al.                 Standards Track                   [Page 16]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+   initiator.  That means, when sending echo request, the initiator
+   should choose a proper source address according the specified return
+   path LSP to help the receiver to make the decision.
+
+7.  IANA Considerations
+
+7.1.  TLVs
+
+   IANA has assigned the value 21 for the Reply Path TLV and assigned
+   the value 22 for Reply TC TLV from the "Multiprotocol Label Switching
+   Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters"
+   registry, "TLVs" subregistry.
+
+   Value   Meaning                           Reference
+   -----   -------                           ---------
+   21      Reply Path TLV                    this document (Section 4.2)
+   22      Reply TC TLV                      this document (Section 4.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.
+
+7.2.  New Target FEC Stack Sub-TLVs
+
+   IANA has assigned three new sub-TLV types from the "Multiprotocol
+   Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping
+   Parameters - TLVs" registry, "Sub-TLVs for TLV Types 1, 16, and 21"
+   subregistry.
+
+   Sub-Type      Sub-TLV Name             Reference
+   -------       -----------             ---------
+   26          IPv4 RSVP Tunnel        this document (Section 4.3.1)
+   27          IPv6 RSVP Tunnel        this document (Section 4.3.2)
+   28          Static Tunnel           this document (Section 4.3.3)
+
+
+7.3.  New Reply Mode
+
+   IANA has allocated (5 - Reply via Specified Path) from the "Multi-
+   Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
+   Parameters" registry, the "Reply Modes" subregistry.
+
+   Value    Meaning                      Reference
+   -----    -------                      ----------
+   5        Reply via Specified Path     this document (Section 4.1)
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 17]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+7.4.  Reply Path Return Code
+
+   IANA has created a new subregistry for the "Multi-Protocol Label
+   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" for
+   Reply Path return codes.
+
+   This document (Section 4.2) defines the following return codes:
+
+   Value         Meaning
+   ------        ----------------------
+   0x0000        No return code
+   0x0001        Malformed Reply Path TLV was received
+   0x0002        One or more of the sub-TLVs in the 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 another LSP
+   0x0005        The specified Reply Path was not found, the echo
+                 reply was sent via pure IP forwarding (non-MPLS)
+                 path
+   0x0006-0xfffb Unassigned
+   0xfffc-0xffff Reserved for Experimental Use
+
+   The range of 0x0006-0xfffb is not allocated and reserved for future
+   extensions and is allocated via Standard Action; the range of 0xfffc-
+   0xffff is for Experimental Use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 18]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+8.  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
+
+9.  Acknowledgements
+
+   The authors would like to thank Adrian Farrel, Peter Ashwood-Smith,
+   Sriganesh Kini, Gregory Mirsky, Eric Gray, Loa Andersson, Carlos
+   Pignataro, and Tom Petch for their reviews, suggestions, and
+   comments.
+
+10.  References
+
+10.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.
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 19]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+10.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.                 Standards Track                   [Page 20]
+
+RFC 7110             Return Path Specified LSP Ping         January 2014
+
+
+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
+
+   EMail: Simon.delord@team.telstra.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 21]
+