GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7110

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
  1. 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
  1. use B bit defined in Section 4.2 of this document.
 4.  Force return path to non-default path
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7110.txt · Last modified: 2014/01/25 00:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki