<pre>Internet Engineering Task Force (IETF)                    S. Saxena, Ed.
Request for Comments: 6425                                    G. Swallow
Updates: <a href="./rfc4379">4379</a>                                                     Z. Ali
Category: Standards Track                            Cisco Systems, Inc.
ISSN: 2070-1721                                                A. Farrel
                                                        Juniper Networks
                                                             S. Yasukawa
                                                         NTT Corporation
                                                               T. Nadeau
                                                         CA Technologies
                                                           November 2011


                    <span class="h1">Detecting Data-Plane Failures in</span>
           <span class="h1">Point-to-Multipoint MPLS - Extensions to LSP Ping</span>

Abstract

   Recent proposals have extended the scope of Multiprotocol Label
   Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-
   multipoint (P2MP) LSPs.

   The requirement for a simple and efficient mechanism that can be used
   to detect data-plane failures in point-to-point (P2P) MPLS LSPs has
   been recognized and has led to the development of techniques for
   fault detection and isolation commonly referred to as "LSP ping".

   The scope of this document is fault detection and isolation for P2MP
   MPLS LSPs.  This documents does not replace any of the mechanisms of
   LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and
   extends the techniques and mechanisms of LSP ping to the MPLS P2MP
   environment.

   This document updates <a href="./rfc4379">RFC 4379</a>.

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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6425">http://www.rfc-editor.org/info/rfc6425</a>.



<span class="grey">Saxena, et al.               Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.

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

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. Design Considerations ......................................<a href="#page-4">4</a>
      <a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-4">4</a>
   <a href="#section-2">2</a>. Notes on Motivation .............................................<a href="#page-5">5</a>
      <a href="#section-2.1">2.1</a>. Basic Motivations for LSP Ping .............................<a href="#page-5">5</a>
      <a href="#section-2.2">2.2</a>. Motivations for LSP Ping for P2MP LSPs .....................<a href="#page-6">6</a>
   <a href="#section-3">3</a>. Packet Format ...................................................<a href="#page-7">7</a>
      <a href="#section-3.1">3.1</a>. Identifying the LSP Under Test .............................<a href="#page-8">8</a>
           <a href="#section-3.1.1">3.1.1</a>. Identifying a P2MP MPLS TE LSP ......................<a href="#page-8">8</a>
                  <a href="#section-3.1.1.1">3.1.1.1</a>. RSVP P2MP IPv4 Session Sub-TLV .............<a href="#page-8">8</a>
                  <a href="#section-3.1.1.2">3.1.1.2</a>. RSVP P2MP IPv6 Session Sub-TLV .............<a href="#page-9">9</a>
           <a href="#section-3.1.2">3.1.2</a>. Identifying a Multicast LDP LSP .....................<a href="#page-9">9</a>
                  <a href="#section-3.1.2.1">3.1.2.1</a>. Multicast LDP FEC Stack Sub-TLVs ..........<a href="#page-10">10</a>
                  3.1.2.2. Applicability to
                           Multipoint-to-Multipoint LSPs .............<a href="#page-11">11</a>
      <a href="#section-3.2">3.2</a>. Limiting the Scope of Responses ...........................<a href="#page-11">11</a>
           <a href="#section-3.2.1">3.2.1</a>. Egress Address P2MP Responder Sub-TLVs .............<a href="#page-12">12</a>
           <a href="#section-3.2.2">3.2.2</a>. Node Address P2MP Responder Sub-TLVs ...............<a href="#page-13">13</a>
      <a href="#section-3.3">3.3</a>. Preventing Congestion of Echo Replies .....................<a href="#page-14">14</a>



<span class="grey">Saxena, et al.               Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


      <a href="#section-3.4">3.4</a>. Respond Only If TTL Expired Flag ..........................<a href="#page-14">14</a>
      <a href="#section-3.5">3.5</a>. Downstream Detailed Mapping TLV ...........................<a href="#page-15">15</a>
   <a href="#section-4">4</a>. Operation of LSP Ping for a P2MP LSP ...........................<a href="#page-15">15</a>
      <a href="#section-4.1">4.1</a>. Initiating LSR Operations .................................<a href="#page-16">16</a>
           <a href="#section-4.1.1">4.1.1</a>. Limiting Responses to Echo Requests ................<a href="#page-16">16</a>
           <a href="#section-4.1.2">4.1.2</a>. Jittered Responses to Echo Requests ................<a href="#page-16">16</a>
      <a href="#section-4.2">4.2</a>. Responding LSR Operations .................................<a href="#page-17">17</a>
           <a href="#section-4.2.1">4.2.1</a>. Echo Reply Reporting ...............................<a href="#page-18">18</a>
                  <a href="#section-4.2.1.1">4.2.1.1</a>. Responses from Transit and Branch Nodes ...<a href="#page-19">19</a>
                  <a href="#section-4.2.1.2">4.2.1.2</a>. Responses from Egress Nodes ...............<a href="#page-19">19</a>
                  <a href="#section-4.2.1.3">4.2.1.3</a>. Responses from Bud Nodes ..................<a href="#page-19">19</a>
      <a href="#section-4.3">4.3</a>. Special Considerations for Traceroute .....................<a href="#page-21">21</a>
           <a href="#section-4.3.1">4.3.1</a>. End of Processing for Traceroutes ..................<a href="#page-21">21</a>
           <a href="#section-4.3.2">4.3.2</a>. Multiple Responses from Bud and Egress Nodes .......<a href="#page-22">22</a>
           <a href="#section-4.3.3">4.3.3</a>. Non-Response to Traceroute Echo Requests ...........<a href="#page-22">22</a>
           4.3.4. Use of Downstream Detailed Mapping TLV in
                  Echo Requests ......................................<a href="#page-23">23</a>
           <a href="#section-4.3.5">4.3.5</a>. Cross-Over Node Processing .........................<a href="#page-23">23</a>
   <a href="#section-5">5</a>. Non-Compliant Routers ..........................................<a href="#page-24">24</a>
   <a href="#section-6">6</a>. OAM and Management Considerations ..............................<a href="#page-24">24</a>
   <a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-25">25</a>
      <a href="#section-7.1">7.1</a>. New Sub-TLV Types .........................................<a href="#page-25">25</a>
      <a href="#section-7.2">7.2</a>. New TLVs ..................................................<a href="#page-25">25</a>
      <a href="#section-7.3">7.3</a>. New Global Flags Registry .................................<a href="#page-26">26</a>
   <a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-26">26</a>
   <a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-26">26</a>
   <a href="#section-10">10</a>. References ....................................................<a href="#page-27">27</a>
      <a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-27">27</a>
      <a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-27">27</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Simple and efficient mechanisms that can be used to detect data-plane
   failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS)
   Label Switched Paths (LSP) are described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].  The
   techniques involve information carried in MPLS "echo request" and
   "echo reply" messages, and mechanisms for transporting them.  The
   echo request and reply messages provide sufficient information to
   check correct operation of the data plane, as well as a mechanism to
   verify the data plane against the control plane, and thereby localize
   faults.  The use of reliable channels for echo reply messages as
   described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] enables more robust fault isolation.  This
   collection of mechanisms is commonly referred to as "LSP ping".

   The requirements for point-to-multipoint (P2MP) MPLS traffic
   engineered (TE) LSPs are stated in [<a href="./rfc4461" title="&quot;Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)&quot;">RFC4461</a>].  [<a href="./rfc4875" title="&quot;Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)&quot;">RFC4875</a>] specifies a
   signaling solution for establishing P2MP MPLS TE LSPs.




<span class="grey">Saxena, et al.               Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   The requirements for P2MP extensions to the Label Distribution
   Protocol (LDP) are stated in [<a href="./rfc6348" title="&quot;Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol&quot;">RFC6348</a>].  [<a href="./rfc6388" title="&quot;Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths&quot;">RFC6388</a>] specifies
   extensions to LDP for P2MP MPLS.

   P2MP MPLS LSPs are at least as vulnerable to data-plane faults or to
   discrepancies between the control and data planes as their P2P
   counterparts.  Therefore, mechanisms are needed to detect such data
   plane faults in P2MP MPLS LSPs as described in [<a href="./rfc4687" title="&quot;Operations and Management (OAM) Requirements for Point- to-Multipoint MPLS Networks&quot;">RFC4687</a>].

   This document extends the techniques described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] such that
   they may be applied to P2MP MPLS LSPs.  This document stresses the
   reuse of existing LSP ping mechanisms used for P2P LSPs, and applies
   them to P2MP MPLS LSPs in order to simplify implementation and
   network operation.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Design Considerations</span>

   An important consideration for designing LSP ping for P2MP MPLS LSPs
   is that every attempt is made to use or extend existing mechanisms
   rather than invent new mechanisms.

   As for P2P LSPs, a critical requirement is that the echo request
   messages follow the same data path that normal MPLS packets traverse.
   However, as can be seen, this notion needs to be extended for P2MP
   MPLS LSPs, as in this case an MPLS packet is replicated so that it
   arrives at each egress (or leaf) of the P2MP tree.

   MPLS echo requests are meant primarily to validate the data plane,
   and they can then be used to validate data-plane state against the
   control plane.  They may also be used to bootstrap other Operations,
   Administration, and Maintenance (OAM) procedures such as [<a href="./rfc5884" title="&quot;Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)&quot;">RFC5884</a>].
   As pointed out in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>], mechanisms to check the liveness,
   function, and consistency of the control plane are valuable, but such
   mechanisms are not a feature of LSP ping and are not covered in this
   document.

   As is described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>], to avoid potential denial-of-service
   attacks, it is RECOMMENDED to regulate the LSP ping traffic passed to
   the control plane.  A rate limiter should be applied to the incoming
   LSP ping traffic.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Terminology</span>

   The terminology used in this document for P2MP MPLS can be found in
   [<a href="./rfc4461" title="&quot;Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)&quot;">RFC4461</a>].  The terminology for MPLS OAM can be found in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].
   In particular, the notation &lt;RSC&gt; refers to the Return Subcode as
   defined in <a href="./rfc4379#section-3.1">Section&nbsp;3.1. of [RFC4379]</a>.




<span class="grey">Saxena, et al.               Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Notes on Motivation</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Basic Motivations for LSP Ping</span>

   The motivations listed in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] are reproduced here for
   completeness.

      When an LSP fails to deliver user traffic, the failure cannot
      always be detected by the MPLS control plane.  There is a need to
      provide a tool that enables users to detect such traffic "black
      holes" or misrouting within a reasonable period of time.  A
      mechanism to isolate faults is also required.

      [<a id="ref-RFC4379">RFC4379</a>] describes a mechanism that accomplishes these goals.
      This mechanism is modeled after the ping/traceroute paradigm: ping
      (ICMP echo request [<a href="./rfc792" title="&quot;Internet Control Message Protocol&quot;">RFC792</a>]) is used for connectivity checks, and
      traceroute is used for hop-by-hop fault localization as well as
      path tracing.  [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] specifies a "ping mode" and a
      "traceroute" mode for testing MPLS LSPs.

      The basic idea as expressed in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] is to test that the
      packets that belong to a particular Forwarding Equivalence Class
      (FEC) actually end their MPLS path on an LSR that is an egress for
      that FEC.  [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] achieves this test by sending a packet
      (called an "MPLS echo request") along the same data path as other
      packets belonging to this FEC.  An MPLS echo request also carries
      information about the FEC whose MPLS path is being verified.  This
      echo request is forwarded just like any other packet belonging to
      that FEC.  In "ping" mode (basic connectivity check), the packet
      should reach the end of the path, at which point it is sent to the
      control plane of the egress LSR, which then verifies that it is
      indeed an egress for the FEC.  In "traceroute" mode (fault
      isolation), the packet is sent to the control plane of each
      transit LSR, which performs various checks that it is indeed a
      transit LSR for this path; this LSR also returns further
      information that helps to check the control plane against the data
      plane, i.e., that forwarding matches what the routing protocols
      determined as the path.

      One way these tools can be used is to periodically ping a FEC to
      ensure connectivity.  If the ping fails, one can then initiate a
      traceroute to determine where the fault lies.  One can also





<span class="grey">Saxena, et al.               Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


      periodically traceroute FECs to verify that forwarding matches the
      control plane; however, this places a greater burden on transit
      LSRs and should be used with caution.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Motivations for LSP Ping for P2MP LSPs</span>

   As stated in [<a href="./rfc4687" title="&quot;Operations and Management (OAM) Requirements for Point- to-Multipoint MPLS Networks&quot;">RFC4687</a>], MPLS has been extended to encompass P2MP
   LSPs.  As with P2P MPLS LSPs, the requirement to detect, handle, and
   diagnose control- and data-plane defects is critical.  For operators
   deploying services based on P2MP MPLS LSPs, the detection and
   specification of how to handle those defects is important because
   such defects may affect the fundamentals of an MPLS network, but also
   because they may impact service-level-specification commitments for
   customers of their network.

   P2MP LDP [<a href="./rfc6388" title="&quot;Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths&quot;">RFC6388</a>] uses LDP to establish multicast LSPs.  These LSPs
   distribute data from a single source to one or more destinations
   across the network according to the next hops indicated by the
   routing protocols.  Each LSP is identified by an MPLS multicast FEC.

   P2MP MPLS TE LSPs [<a href="./rfc4875" title="&quot;Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)&quot;">RFC4875</a>] may be viewed as MPLS tunnels with a
   single ingress and multiple egresses.  The tunnels, built on P2MP
   LSPs, are explicitly routed through the network.  There is no concept
   or applicability of a FEC in the context of a P2MP MPLS TE LSP.

   MPLS packets inserted at the ingress of a P2MP LSP are delivered
   equally (barring faults) to all egresses.  In consequence, the basic
   idea of LSP ping for P2MP MPLS LSPs may be expressed as an intention
   to test that packets that enter (at the ingress) a particular P2MP
   LSP actually end their MPLS path on the LSRs that are the (intended)
   egresses for that LSP.  The idea may be extended to check selectively
   that such packets reach specific egresses.

   The technique in this document makes this test by sending an LSP ping
   echo request message along the same data path as the MPLS packets.
   An echo request also carries the identification of the P2MP MPLS LSP
   (multicast LSP or P2MP TE LSP) that it is testing.  The echo request
   is forwarded just as any other packet using that LSP, and so is
   replicated at branch points of the LSP and should be delivered to all
   egresses.

   In "ping" mode (basic connectivity check), the echo request should
   reach the end of the path, at which point it is sent to the control
   plane of the egress LSRs, which verify that they are indeed an egress
   (leaf) of the P2MP LSP.  An echo reply message is sent by an egress
   to the ingress to confirm the successful receipt (or announce the
   erroneous arrival) of the echo request.




<span class="grey">Saxena, et al.               Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   In "traceroute" mode (fault isolation), the echo request is sent to
   the control plane at each transit LSR, and the control plane checks
   that it is indeed a transit LSR for this P2MP MPLS LSP.  The transit
   LSR returns information about the outgoing paths.  This information
   can be used by ingress LSRs to build topology or by downstream LSRs
   to do extra label verification.

   P2MP MPLS LSPs may have many egresses, and it is not necessarily the
   intention of the initiator of the ping or traceroute operation to
   collect information about the connectivity or path to all egresses.
   Indeed, in the event of pinging all egresses of a large P2MP MPLS
   LSP, it might be expected that a large number of echo replies would
   arrive at the ingress independently but at approximately the same
   time.  Under some circumstances this might cause congestion at or
   around the ingress LSR.  The procedures described in this document
   provide two mechanisms to control echo replies.

   The first procedure allows the responders to randomly delay (or
   jitter) their replies so that the chances of swamping the ingress are
   reduced.  The second procedure allows the initiator to limit the
   scope of an LSP ping echo request (ping or traceroute mode) to one
   specific intended egress.

   LSP ping can be used to periodically ping a P2MP MPLS LSP to ensure
   connectivity to any or all of the egresses.  If the ping fails, the
   operator or an automated process can then initiate a traceroute to
   determine where the fault is located within the network.  A
   traceroute may also be used periodically to verify that data-plane
   forwarding matches the control-plane state; however, this places an
   increased burden on transit LSRs and should be used infrequently and
   with caution.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Packet Format</span>

   The basic structure of the LSP ping packet remains the same as
   described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].  Some new TLVs and sub-TLVs are required to
   support the new functionality.  They are described in the following
   sections.













<span class="grey">Saxena, et al.               Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Identifying the LSP Under Test</span>

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Identifying a P2MP MPLS TE LSP</span>

   [<a id="ref-RFC4379">RFC4379</a>] defines how an MPLS TE LSP under test may be identified in
   an echo request.  A Target FEC Stack TLV is used to carry either an
   RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.

   In order to identify the P2MP MPLS TE LSP under test, the echo
   request message MUST carry a Target FEC Stack TLV, and this MUST
   carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4
   Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV.  These sub-TLVs
   carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE
   objects [<a href="./rfc4875" title="&quot;Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)&quot;">RFC4875</a>] and so provide sufficient information to uniquely
   identify the LSP.

   The new sub-TLVs are assigned Sub-Type identifiers as follows, and
   are described in the following sections.

      Sub-Type #       Length              Value Field
      ----------       ------              -----------
              17         20                RSVP P2MP IPv4 Session
              18         56                RSVP P2MP IPv6 Session

<span class="h5"><a class="selflink" id="section-3.1.1.1" href="#section-3.1.1.1">3.1.1.1</a>.  RSVP P2MP IPv4 Session Sub-TLV</span>

   The format of the RSVP P2MP IPv4 Session sub-TLV value field is
   specified in the following figure.  The value fields are taken from
   the definitions of the P2MP IPv4 LSP SESSION Object and the P2MP IPv4
   SENDER_TEMPLATE Object in Sections <a href="#section-19.1.1">19.1.1</a> and <a href="#section-19.2.1">19.2.1</a> of [<a href="./rfc4875" title="&quot;Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)&quot;">RFC4875</a>].
   Note that the Sub-Group ID of the SENDER_TEMPLATE is not required.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           P2MP ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MUST Be Zero         |     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 Tunnel Sender Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MUST Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






<span class="grey">Saxena, et al.               Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


<span class="h5"><a class="selflink" id="section-3.1.1.2" href="#section-3.1.1.2">3.1.1.2</a>.  RSVP P2MP IPv6 Session Sub-TLV</span>

   The format of the RSVP P2MP IPv6 Session sub-TLV value field is
   specified in the following figure.  The value fields are taken from
   the definitions of the P2MP IPv6 LSP SESSION Object and the P2MP IPv6
   SENDER_TEMPLATE Object in Sections <a href="#section-19.1.2">19.1.2</a> and <a href="#section-19.2.2">19.2.2</a> of [<a href="./rfc4875" title="&quot;Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)&quot;">RFC4875</a>].
   Note that the Sub-Group ID of the SENDER_TEMPLATE is not required.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           P2MP ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MUST Be Zero         |     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Extended Tunnel ID                      |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   IPv6 Tunnel Sender Address                  |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MUST Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Identifying a Multicast LDP LSP</span>

   [<a id="ref-RFC4379">RFC4379</a>] defines how a P2P LDP LSP under test may be identified in
   an echo request.  A Target FEC Stack TLV is used to carry one or more
   sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the
   LSP.

   In order to identify a multicast LDP LSP under test, the echo request
   message MUST carry a Target FEC Stack TLV, and this MUST carry
   exactly one of two new sub-TLVs: either a Multicast P2MP LDP FEC
   Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV.  These sub-
   TLVs use fields from the multicast LDP messages [<a href="./rfc6388" title="&quot;Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths&quot;">RFC6388</a>] and so
   provide sufficient information to uniquely identify the LSP.

   The new sub-TLVs are assigned sub-type identifiers as follows and are
   described in the following section.







<span class="grey">Saxena, et al.               Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


      Sub-Type #       Length              Value Field
      ----------       ------              -----------
              19       Variable            Multicast P2MP LDP FEC Stack
              20       Variable            Multicast MP2MP LDP FEC Stack

<span class="h5"><a class="selflink" id="section-3.1.2.1" href="#section-3.1.2.1">3.1.2.1</a>.  Multicast LDP FEC Stack Sub-TLVs</span>

   Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as
   specified in the following figure.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Address Family         | Address Length| Root LSR Addr |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Root LSR Address (Cont.)                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Opaque Length          |         Opaque Value ...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Address Family

      Two-octet quantity containing a value from ADDRESS FAMILY NUMBERS
      in [<a href="#ref-IANA-AF">IANA-AF</a>] that encodes the address family for the Root LSR
      Address.

   Address Length

      Length of the Root LSR Address in octets.

   Root LSR Address

      Address of the LSR at the root of the P2MP LSP encoded according
      to the Address Family field.

   Opaque Length

      The length of the opaque value, in octets.  Depending on the
      length of the Root LSR Address, this field may not be aligned to a
      word boundary.




<span class="grey">Saxena, et al.               Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   Opaque Value

      An opaque value element that uniquely identifies the P2MP LSP in
      the context of the Root LSR.

   If the Address Family is IPv4, the Address Length MUST be 4.  If the
   Address Family is IPv6, the Address Length MUST be 16.  No other
   Address Family values are defined at present.

<span class="h5"><a class="selflink" id="section-3.1.2.2" href="#section-3.1.2.2">3.1.2.2</a>.  Applicability to Multipoint-to-Multipoint LSPs</span>

   The mechanisms defined in this document can be extended to include
   Multipoint-to-Multipoint (MP2MP) Multicast LSPs.  In an MP2MP LSP
   tree, any leaf node can be treated like a head node of a P2MP tree.
   In other words, for MPLS OAM purposes, the MP2MP tree can be treated
   like a collection of P2MP trees, with each MP2MP leaf node acting
   like a P2MP head-end node.  When a leaf node is acting like a P2MP
   head-end node, the remaining leaf nodes act like egress or bud nodes.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Limiting the Scope of Responses</span>

   A new TLV is defined for inclusion in the echo request message.

   The P2MP Responder Identifier TLV is assigned the TLV type value 11
   and is encoded 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Type = 11   (P2MP Responder ID)|       Length = Variable       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Sub-TLVs                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sub-TLVs:

         Zero, one, or more sub-TLVs as defined below.

         If no sub-TLVs are present, the TLV MUST be processed as if it
         were absent.  If more than one sub-TLV is present, the first
         TLV MUST be processed as described in this document, and
         subsequent sub-TLVs SHOULD be ignored.  Interpretation of
         additional sub-TLVs may be defined in future documents.

   The P2MP Responder Identifier TLV only has meaning on an echo request
   message.  If present on an echo reply message, it MUST be ignored.





<span class="grey">Saxena, et al.               Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   Four sub-TLVs are defined for inclusion in the P2MP Responder
   Identifier TLV carried on the echo request message.  These are:

   Sub-Type #   Length   Value Field
   ----------   ------   -----------
           1        4    IPv4 Egress Address P2MP Responder
           2       16    IPv6 Egress Address P2MP Responder
           3        4    IPv4 Node Address P2MP Responder
           4       16    IPv6 Node Address P2MP Responder

   The content of these sub-TLVs are defined in the following sections.
   Also defined is the intended behavior of the responding node upon
   receiving any of these sub-TLVs.

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Egress Address P2MP Responder Sub-TLVs</span>

   The encoding of the IPv4 Egress Address P2MP Responder 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Sub-Type = 1          |        Length = 4             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    32-bit IPv4 Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The encoding of the IPv6 Egress Address P2MP Responder 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Sub-Type = 2          |        Length = 16            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    128-bit IPv6 Address                       |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A node that receives an echo request with this sub-TLV present MUST
   respond if the node lies on the path to the address in the sub-TLV
   and MUST NOT respond if it does not lie on the path to the address in
   the sub-TLV.  For this to be possible, the address in the sub-TLV
   must be known to the nodes that lie upstream in the LSP.  This can be
   the case if RSVP-TE is used to signal the P2MP LSP, in which case
   this address will be the address used in the Destination Address



<span class="grey">Saxena, et al.               Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   field of the S2L_SUB_LSP object, when corresponding egress or bud
   node is signaled.  Thus, the IPv4 or IPv6 Egress Address P2MP
   Responder sub-TLV MAY be used in an echo request carrying RSVP P2MP
   Session sub-TLV.

   However, in Multicast LDP, there is no way for upstream LSRs to know
   the identity of the downstream leaf nodes.  Hence, these TLVs cannot
   be used to perform traceroute to a single node when Multicast LDP FEC
   is used, and the IPv4 or IPv6 Egress Address P2MP Responder sub-TLV
   SHOULD NOT be used with an echo request carrying a Multicast LDP FEC
   Stack sub-TLV.  If a node receives these TLVs in an echo request
   carrying Multicast LDP, then it will not respond since it is unaware
   of whether it lies on the path to the address in the sub-TLV.

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Node Address P2MP Responder Sub-TLVs</span>

   The encoding of the IPv4 Node Address P2MP Responder 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Sub-Type = 3          |        Length = 4             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    32-bit IPv4 Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The encoding of the IPv6 Node Address P2MP Responder 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Sub-Type = 4          |        Length = 16            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    128-bit IPv6 Address                       |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The IPv4 or IPv6 Node Address P2MP Responder sub-TLVs MAY be used in
   an echo request carrying either RSVP P2MP Session or Multicast LDP
   FEC Stack sub-TLVs.

   A node that receives an echo request with one of these sub-TLVs
   present MUST respond if the address in the sub-TLV matches any
   address that is local to the node and MUST NOT respond if the address



<span class="grey">Saxena, et al.               Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   in the sub-TLV does not match any address that is local to the node.
   The address in the sub-TLV may be of any physical interface or may be
   the router ID of the node itself.

   The address in this sub-TLV SHOULD be of any transit, branch, bud, or
   egress node for that P2MP LSP.  The address of a node that is not on
   the P2MP LSP MAY be used as a check for that no reply is received.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Preventing Congestion of Echo Replies</span>

   A new TLV is defined for inclusion in the Echo request message.

   The Echo Jitter TLV is assigned the TLV type value 12 and is encoded
   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type = 12 (Jitter TLV)   |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Jitter Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Jitter Time:

         This field specifies the upper bound of the jitter period that
         should be applied by a responding node to determine how long to
         wait before sending an echo reply.  A responding node MUST wait
         a random amount of time between zero milliseconds and the value
         specified in this field.

         Jitter time is specified in milliseconds.

   The Echo Jitter TLV only has meaning on an echo request message.  If
   present on an echo reply message, it MUST be ignored.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Respond Only If TTL Expired Flag</span>

   A new flag is being introduced in the Global Flags field defined in
   [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].  The new format of the Global Flags field is:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             MBZ           |T|V|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The V flag is described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].



<span class="grey">Saxena, et al.               Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   The T (Respond Only If TTL Expired) flag MUST be set only in the echo
   request packet by the sender.  This flag MUST NOT be set in the echo
   reply packet.  If this flag is set in an echo reply packet, then it
   MUST be ignored.

   If the T flag is set to 0, then the receiving node MUST process the
   incoming echo request.

   If the T flag is set to 1 and the TTL of the incoming MPLS label is
   equal to 1, then the receiving node MUST process the incoming echo
   request.

   If the T flag is set to 1 and the TTL of the incoming MPLS label is
   more than 1, then the receiving node MUST drop the incoming echo
   request and MUST NOT send any echo reply to the sender.

   If the T flag is set to 1 and there are no incoming MPLS labels in
   the echo request packet, then a bud node with PHP configured MAY
   choose to not respond to this echo request.  All other nodes MUST
   ignore this bit and respond as per regular processing.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Downstream Detailed Mapping TLV</span>

   The Downstream Detailed Mapping TLV is described in [<a href="./rfc6424" title="&quot;Mechanism for Performing LSP-Ping over MPLS Tunnels&quot;">RFC6424</a>].  A
   transit, branch or bud node can use the Downstream Detailed Mapping
   TLV to return multiple Return Codes for different downstream paths.
   This functionality can not be achieved via the Downstream Mapping
   TLV.  As per <a href="./rfc6424#section-3.4">Section&nbsp;3.4 of [RFC6424]</a>, the Downstream Mapping TLV as
   described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] is being deprecated.

   Therefore, for P2MP, a node MUST support the Downstream Detailed
   Mapping TLV.  The Downstream Mapping TLV [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] is not appropriate
   for P2MP traceroute functionality and MUST NOT be included in an Echo
   Request message.  When responding to an RSVP IPv4/IPv6 P2MP Session
   FEC type or a Multicast P2MP/MP2MP LDP FEC type, a node MUST ignore
   any Downstream Mapping TLV it receives in the echo request and MUST
   continue processing as if the Downstream Mapping TLV is not present.

   The details of the Return Codes to be used in the Downstream Detailed
   Mapping TLV are provided in <a href="#section-4">Section 4</a>.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Operation of LSP Ping for a P2MP LSP</span>

   This section describes how LSP ping is applied to P2MP MPLS LSPs.  As
   mentioned previously, an important design consideration has been to
   extend the existing LSP ping mechanism in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] rather than
   invent new mechanisms.




<span class="grey">Saxena, et al.               Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   As specified in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>], MPLS LSPs can be tested via a "ping" mode
   or a "traceroute" mode.  The ping mode is also known as "connectivity
   verification" and traceroute mode is also known as "fault isolation".
   Further details can be obtained from [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].

   This section specifies processing of echo requests for both ping and
   traceroute mode at various nodes (ingress, transit, etc.) of the P2MP
   LSP.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Initiating LSR Operations</span>

   The LSR initiating the echo request will follow the procedures in
   [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].  The echo request will contain a Target FEC Stack TLV.  To
   identify the P2MP LSP under test, this TLV will contain one of the
   new sub-TLVs defined in <a href="#section-3.1">Section 3.1</a>.  Additionally, there may be
   other optional TLVs present.

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  Limiting Responses to Echo Requests</span>

   As described in <a href="#section-2.2">Section 2.2</a>, it may be desirable to restrict the
   operation of P2MP ping or traceroute to a single egress.  Since echo
   requests are forwarded through the data plane without interception by
   the control plane, there is no facility to limit the propagation of
   echo requests, and they will automatically be forwarded to all
   reachable egresses.

   However, a single egress may be identified by the inclusion of a P2MP
   Responder Identifier TLV.  The details of this TLV and its sub-TLVs
   are in <a href="#section-3.2">Section 3.2</a>.  There are two main types of sub-TLVs in the P2MP
   Responder Identifier TLV: Node Address sub-TLV and Egress Address
   sub-TLV.

   These sub-TLVs limit the replies either to the specified LSR only or
   to any LSR on the path to the specified LSR.  The former capability
   is generally useful for ping mode, while the latter is more suited to
   traceroute mode.  An initiating LSR may indicate that it wishes all
   egresses to respond to an echo request by omitting the P2MP Responder
   Identifier TLV.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  Jittered Responses to Echo Requests</span>

   The initiating LSR MAY request that the responding LSRs introduce a
   random delay (or jitter) before sending the reply.  The randomness of
   the delay allows the replies from multiple egresses to be spread over
   a time period.  Thus, this technique is particularly relevant when
   the entire P2MP LSP is being pinged or traced since it helps prevent
   the initiating (or nearby) LSRs from being swamped by replies, or
   from discarding replies due to rate limits that have been applied.



<span class="grey">Saxena, et al.               Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   It is desirable for the initiating LSR to be able to control the
   bounds of the jitter.  If the tree size is small, only a small amount
   of jitter is required, but if the tree is large, greater jitter is
   needed.

   The initiating LSR can supply the desired value of the jitter in the
   Echo Jitter TLV as defined in <a href="#section-3.3">Section 3.3</a>.  If this TLV is present,
   the responding LSR MUST delay sending a reply for a random amount of
   time between zero milliseconds and the value indicated in the TLV.
   If the TLV is absent, the responding egress SHOULD NOT introduce any
   additional delay in responding to the echo request, but MAY delay
   according to local policy.

   LSP ping MUST NOT be used to attempt to measure the round-trip time
   for data delivery.  This is because the P2MP LSPs are unidirectional,
   and the echo reply is often sent back through the control plane.  The
   timestamp fields in the echo request and echo reply packets MAY be
   used to deduce some information about delivery times, for example the
   variance in delivery times.

   The use of echo jittering does not change the processes for gaining
   information, but note that the responding node MUST set the value in
   the Timestamp Received fields before applying any delay.

   Echo reply jittering SHOULD be used for P2MP LSPs, although it MAY be
   omitted for simple P2MP LSPs or when the Node Address P2MP Responder
   sub-TLVs are used.  If the Echo Jitter TLV is present in an echo
   request for any other type of LSPs, the responding egress MAY apply
   the jitter behavior as described here.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Responding LSR Operations</span>

   Usually the echo request packet will reach the egress and bud nodes.
   In case of TTL Expiry, i.e., traceroute mode, the echo request packet
   may stop at branch or transit nodes.  In both scenarios, the echo
   request will be passed on to the control plane for reply processing.

   The operations at the receiving node are an extension to the existing
   processing as specified in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].  As described in that document,
   a responding LSR SHOULD rate-limit the receipt of echo request
   messages.  After rate-limiting, the responding LSR must verify the
   general sanity of the packet.  If the packet is malformed or certain
   TLVs are not understood, the [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] procedures must be followed
   for echo reply.  Similarly, the Reply Mode field determines if the
   reply is required or not (and the mechanism to send it back).






<span class="grey">Saxena, et al.               Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   For P2MP LSP ping and traceroute, i.e., if the echo request is
   carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR
   MUST determine whether it is part of the P2MP LSP in question by
   checking with the control plane.

      -  If the node is not part of the P2MP LSP, it MUST respond
         according to [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] processing rules.

      -  If the node is part of the P2MP LSP, the node must check
         whether or not the echo request is directed to it.

         -  If a P2MP Responder Identifier TLV is present, then the node
            must follow the procedures defined in <a href="#section-3.2">Section 3.2</a> to
            determine whether or not it should respond to the request.
            The presence of a P2MP Responder Identifier TLV or a
            Downstream Detailed Mapping TLV might affect the Return
            Code.  This is discussed in more detail later.

         -  If the P2MP Responder Identifier TLV is not present (or, in
            the error case, is present, but does not contain any sub-
            TLVs), then the node MUST respond according to [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>]
            processing rules.

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  Echo Reply Reporting</span>

   Echo reply messages carry Return Codes and Subcodes to indicate the
   result of the LSP ping (when the ping mode is being used) as
   described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].

   When the responding node reports that it is an egress, it is clear
   that the echo reply applies only to that reporting node.  Similarly,
   when a node reports that it does not form part of the LSP described
   by the FEC, then it is clear that the echo reply applies only to that
   reporting node.  However, an echo reply message that reports an error
   from a transit node may apply to multiple egress nodes (i.e., leaves)
   downstream of the reporting node.  In the case of the ping mode of
   operation, it is not possible to correlate the reporting node to the
   affected egresses unless the topology of the P2MP tree is already
   known, and it may be necessary to use the traceroute mode of
   operation to further diagnose the LSP.

   Note that a transit node may discover an error, but it may also
   determine that while it does lie on the path of the LSP under test,
   it does not lie on the path to the specific egress being tested.  In
   this case, the node SHOULD NOT generate an echo reply unless there is
   a specific error condition that needs to be communicated.





<span class="grey">Saxena, et al.               Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   The following sections describe the expected values of Return Codes
   for various nodes in a P2MP LSP.  It is assumed that the sanity and
   other checks have been performed and an echo reply is being sent
   back.  As mentioned in <a href="#section-4.2">Section 4.2</a>, the Return Code might change
   based on the presence of a Responder Identifier TLV or Downstream
   Detailed Mapping TLV.

<span class="h5"><a class="selflink" id="section-4.2.1.1" href="#section-4.2.1.1">4.2.1.1</a>.  Responses from Transit and Branch Nodes</span>

   The presence of a Responder Identifier TLV does not influence the
   choice of the Return Code.  For a success response, the Return Code
   MAY be set to value 8 ('Label switched at stack-depth &lt;RSC&gt;').  The
   notation &lt;RSC&gt; refers to the Return Subcode as defined in <a href="./rfc4379#section-3.1">Section</a>
   <a href="./rfc4379#section-3.1">3.1. of [RFC4379]</a>.  For error conditions, use appropriate values
   defined in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].

   The presence of a Downstream Detailed Mapping TLV will influence the
   choice of Return Code.  As per [<a href="./rfc6424" title="&quot;Mechanism for Performing LSP-Ping over MPLS Tunnels&quot;">RFC6424</a>], the Return Code in the echo
   reply header MAY be set to 'See DDM TLV for Return Code and Return
   Subcode' as defined in [<a href="./rfc6424" title="&quot;Mechanism for Performing LSP-Ping over MPLS Tunnels&quot;">RFC6424</a>].  The Return Code for each
   Downstream Detailed Mapping TLV will depend on the downstream path as
   described in [<a href="./rfc6424" title="&quot;Mechanism for Performing LSP-Ping over MPLS Tunnels&quot;">RFC6424</a>].

   There will be a Downstream Detailed Mapping TLV for each downstream
   path being reported in the echo reply.  Hence, for transit nodes,
   there will be only one such TLV, and for branch nodes, there will be
   more than one.  If there is an Egress Address Responder sub-TLV, then
   the branch node will include only one Downstream Detailed Mapping TLV
   corresponding to the downstream path required to reach the address
   specified in the Egress Address sub-TLV.

<span class="h5"><a class="selflink" id="section-4.2.1.2" href="#section-4.2.1.2">4.2.1.2</a>.  Responses from Egress Nodes</span>

   The presence of a Responder Identifier TLV does not influence the
   choice of the Return Code.  For a success response, the Return Code
   MAY be set to value 3 ('Replying router is an egress for the FEC at
   stack-depth &lt;RSC&gt;').  For error conditions, use appropriate values
   defined in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].

   The presence of the Downstream Detailed Mapping TLV does not
   influence the choice of Return Code.  Egress nodes do not put in any
   Downstream Detailed Mapping TLV in the echo reply [<a href="./rfc6424" title="&quot;Mechanism for Performing LSP-Ping over MPLS Tunnels&quot;">RFC6424</a>].

<span class="h5"><a class="selflink" id="section-4.2.1.3" href="#section-4.2.1.3">4.2.1.3</a>.  Responses from Bud Nodes</span>

   The case of bud nodes is more complex than other types of nodes.  The
   node might behave as either an egress node or a transit node, or a
   combination of an egress and branch node.  This behavior is



<span class="grey">Saxena, et al.               Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   determined by the presence of any Responder Identifier TLV and the
   type of sub-TLV in it.  Similarly, the Downstream Detailed Mapping
   TLV can influence the Return Code values.

   To determine the behavior of the bud node, use the following rules.
   The intent of these rules is to figure out if the echo request is
   meant for all nodes, or just this node, or for another node reachable
   through this node or for a different section of the tree.  In the
   first case, the node will behave like a combination of egress and
   branch node; in the second case, the node will behave like pure
   egress node; in the third case, the node will behave like a transit
   node; and in the last case, no reply will be sent back.

   Node behavior rules:

      -  If the Responder Identifier TLV is not present, then the node
         will behave as a combination of egress and branch node.

      -  If the Responder Identifier TLV containing a Node Address sub-
         TLV is present, and:

         -  If the address specified in the sub-TLV matches to an
            address in the node, then the node will behave like a
            combination of egress and branch node.

         -  If the address specified in the sub-TLV does not match any
            address in the node, then no reply will be sent.

      -  If the Responder Identifier TLV containing an Egress Address
        sub-TLV is present, and:

         -  If the address specified in the sub-TLV matches to an
            address in the node, then the node will behave like an
            egress node only.

         -  If the node lies on the path to the address specified in the
            sub-TLV, then the node will behave like a transit node.

         -  If the node does not lie on the path to the address
            specified in the sub-TLV, then no reply will be sent.

   Once the node behavior has been determined, the possible values for
   Return Codes are as follows:

      -  If the node is behaving as an egress node only, then for a
         success response, the Return Code MAY be set to value 3
         ('Replying router is an egress for the FEC at stack-depth
         &lt;RSC&gt;').  For error conditions, use appropriate values defined



<span class="grey">Saxena, et al.               Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


         in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].  The echo reply MUST NOT contain any Downstream
         Detailed Mapping TLV, even if one is present in the echo
         request.

      -  If the node is behaving as a transit node, and:

         -  If a Downstream Detailed Mapping TLV is not present, then
            for a success response, the Return Code MAY be set to value
            8 ('Label switched at stack-depth &lt;RSC&gt;').  For error
            conditions, use appropriate values defined in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].

         -  If a Downstream Detailed Mapping TLV is present, then the
            Return Code MAY be set to 'See DDM TLV for Return Code and
            Return Subcode' as defined in [<a href="./rfc6424" title="&quot;Mechanism for Performing LSP-Ping over MPLS Tunnels&quot;">RFC6424</a>].  The Return Code
            for the Downstream Detailed Mapping TLV will depend on the
            downstream path as described in [<a href="./rfc6424" title="&quot;Mechanism for Performing LSP-Ping over MPLS Tunnels&quot;">RFC6424</a>].  There will be
            only one Downstream Detailed Mapping corresponding to the
            downstream path to the address specified in the Egress
            Address sub-TLV.

      -  If the node is behaving as a combination of egress and branch
         node, and:

         -  If a Downstream Detailed Mapping TLV is not present, then
            for a success response, the Return Code MAY be set to value
            3 ('Replying router is an egress for the FEC at stack-depth
            &lt;RSC&gt;').  For error conditions, use appropriate values
            defined in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].

         -  If a Downstream Detailed Mapping TLV is present, then for a
            success response, the Return Code MAY be set to value 3
            ('Replying router is an egress for the FEC at stack-depth
            &lt;RSC&gt;').  For error conditions, use appropriate values
            defined in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].  The Return Code for the each
            Downstream Detailed Mapping TLV will depend on the
            downstream path as described in [<a href="./rfc6424" title="&quot;Mechanism for Performing LSP-Ping over MPLS Tunnels&quot;">RFC6424</a>].  There will be a
            Downstream Detailed Mapping for each downstream path from
            the node.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Special Considerations for Traceroute</span>

<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>.  End of Processing for Traceroutes</span>

   As specified in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>], the traceroute mode operates by sending a
   series of echo requests with sequentially increasing TTL values.  For
   regular P2P targets, this processing stops when a valid reply is
   received from the intended egress or when some errored return code is
   received.



<span class="grey">Saxena, et al.               Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   For P2MP targets, there may not be an easy way to figure out the end
   of the traceroute processing, as there are multiple egress nodes.
   Receiving a valid reply from an egress will not signal the end of
   processing.

   For P2MP TE LSP, the initiating LSR has a priori knowledge about the
   number of egress nodes and their addresses.  Hence, it is possible to
   continue processing until a valid reply has been received from each
   end point, provided that the replies can be matched correctly to the
   egress nodes.

   However, for Multicast LDP LSP, the initiating LSR might not always
   know about all of the egress nodes.  Hence, there might not be a
   definitive way to estimate the end of processing for traceroute.

   Therefore, it is RECOMMENDED that traceroute operations provide for a
   configurable upper limit on TTL values.  Hence, the user can choose
   the depth to which the tree will be probed.

<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>.  Multiple Responses from Bud and Egress Nodes</span>

   The P2MP traceroute may continue even after it has received a valid
   reply from a bud or egress node, as there may be more nodes at deeper
   levels.  Hence, for subsequent TTL values, a bud or egress node that
   has previously replied would continue to get new echo requests.
   Since each echo request is handled independently from previous
   requests, these bud and egress nodes will keep on responding to the
   traceroute echo requests.  This can cause an extra processing burden
   for the initiating LSR and these bud or egress LSRs.

   To prevent a bud or egress node from sending multiple replies in the
   same traceroute operation, a new "Respond Only If TTL Expired" flag
   is being introduced.  This flag is described in <a href="#section-3.4">Section 3.4</a>.

   It is RECOMMENDED that this flag be used for P2MP traceroute mode
   only.  By using this flag, extraneous replies from bud and egress
   nodes can be reduced.  If PHP is being used in the P2MP tree, then
   bud and egress nodes will not get any labels with the echo request
   packet.  Hence, this mechanism will not be effective for PHP
   scenarios.

<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>.  Non-Response to Traceroute Echo Requests</span>

   There are multiple reasons for which an ingress node may not receive
   a reply to its echo request.  For example, the transit node has
   failed or the transit node does not support LSP ping.





<span class="grey">Saxena, et al.               Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   When no reply to an echo request is received by the ingress, then (as
   per [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>]) the subsequent echo request with a larger TTL SHOULD
   be sent in order to trace further toward the egress, although the
   ingress MAY halt the procedure at this point.  The time that an
   ingress waits before sending the subsequent echo request is an
   implementation choice.

<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>.  Use of Downstream Detailed Mapping TLV in Echo Requests</span>

   As described in <a href="./rfc4379#section-4.6">Section&nbsp;4.6 of [RFC4379]</a>, an initiating LSR, during
   traceroute, SHOULD copy the Downstream Mapping(s) into its next echo
   request(s).  However, for P2MP LSPs, the initiating LSR will receive
   multiple sets of Downstream Detailed Mapping TLVs from different
   nodes.  It is not practical to copy all of them into the next echo
   request.  Hence, this behavior is being modified for P2MP LSPs.  If
   the echo request is destined for more than one node, then the
   Downstream IP Address field of the Downstream Detailed Mapping TLV
   MUST be set to the ALLROUTERS multicast address, and the Address Type
   field MUST be set to either IPv4 Unnumbered or IPv6 Unnumbered
   depending on the Target FEC Stack TLV.

   If an Egress Address Responder sub-TLV is being used, then the
   traceroute is limited to only one egress.  Therefore this traceroute
   is effectively behaving like a P2P traceroute.  In this scenario, as
   per <a href="#section-4.2">Section 4.2</a>, the echo replies from intermediate nodes will
   contain only one Downstream Detailed Mapping TLV corresponding to the
   downstream path required to reach the address specified in the Egress
   Address sub-TLV.  For this case, the echo request packet MAY reuse a
   received Downstream Detailed Mapping TLV.  This will allow interface
   validation to be performed as per [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].

<span class="h4"><a class="selflink" id="section-4.3.5" href="#section-4.3.5">4.3.5</a>.  Cross-Over Node Processing</span>

   A cross-over node will require slightly different processing for
   traceroute mode.  The following definition of cross-over is taken
   from [<a href="./rfc4875" title="&quot;Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)&quot;">RFC4875</a>].

      The term "cross-over" refers to the case of an ingress or transit
      node that creates a branch of a P2MP LSP, a cross-over branch,
      that intersects the P2MP LSP at another node farther down the
      tree.  It is unlike re-merge in that, at the intersecting node,
      the cross-over branch has a different outgoing interface as well
      as a different incoming interface.

   During traceroute, a cross-over node will receive the echo requests
   via each of its input interfaces.  Therefore, the Downstream Detailed
   Mapping TLV in the echo reply MUST carry information only about the
   outgoing interface corresponding to the input interface.



<span class="grey">Saxena, et al.               Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   If this restriction is applied, the cross-over node will not
   duplicate the outgoing interface information in each of the echo
   request it receives via the different input interfaces.  This will
   reflect the actual packet replication in the data plane.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Non-Compliant Routers</span>

   If a node for a P2MP LSP does not support MPLS LSP ping, then no
   reply will be sent, causing an incorrect result on the initiating
   LSR.  There is no protection for this situation, and operators may
   wish to ensure that all nodes for P2MP LSPs are all equally capable
   of supporting this function.

   If the non-compliant node is an egress, then the traceroute mode can
   be used to verify the LSP nearly all the way to the egress, leaving
   the final hop to be verified manually.

   If the non-compliant node is a branch or transit node, then it should
   not impact ping mode.  However the node will not respond during
   traceroute mode.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  OAM and Management Considerations</span>

   The procedures in this document provide OAM functions for P2MP MPLS
   LSPs and may be used to enable bootstrapping of other OAM procedures.

   In order to be fully operational, several considerations apply.

      -  Scaling concerns dictate that only cautious use of LSP ping
         should be made.  In particular, sending an LSP ping to all
         egresses of a P2MP MPLS LSP could result in congestion at or
         near the ingress when the replies arrive.

         Further, incautious use of timers to generate LSP ping echo
         requests either in ping mode or especially in traceroute may
         lead to significant degradation of network performance.

      -  Management interfaces should allow an operator full control
         over the operation of LSP ping.  In particular, such interfaces
         should provide the ability to limit the scope of an LSP ping
         echo request for a P2MP MPLS LSP to a single egress.

         Such interfaces should also provide the ability to disable all
         active LSP ping operations, to provide a quick escape if the
         network becomes congested.






<span class="grey">Saxena, et al.               Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


      -  A MIB module is required for the control and management of LSP
         ping operations, and to enable the reported information to be
         inspected.

         There is no reason to believe this should not be a simple
         extension of the LSP ping MIB module used for P2P LSPs.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IANA Considerations</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  New Sub-TLV Types</span>

   Four new sub-TLV types are defined for inclusion within the LSP ping
   [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] Target FEC Stack TLV (TLV type 1).

   IANA has assigned sub-type values to the following sub-TLVs under TLV
   type 1 (Target FEC Stack) from the "Multi-Protocol Label Switching
   (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs
   and sub-TLVs" sub-registry.

      17 RSVP P2MP IPv4 Session (<a href="#section-3.1.1">Section 3.1.1</a>)
      18 RSVP P2MP IPv6 Session (<a href="#section-3.1.1">Section 3.1.1</a>)
      19 Multicast P2MP LDP FEC Stack (<a href="#section-3.1.2">Section 3.1.2</a>)
      20 Multicast MP2MP LDP FEC Stack (<a href="#section-3.1.2">Section 3.1.2</a>)

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  New TLVs</span>

   Two new LSP ping TLV types are defined for inclusion in LSP ping
   messages.

   IANA has assigned a new value from the "Multi-Protocol Label
   Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping
   Parameters" registry, "TLVs and sub-TLVs" sub-registry as follows
   using a Standards Action value.

      11 P2MP Responder Identifier TLV (see <a href="#section-3.2">Section 3.2</a>) is a mandatory
         TLV.

        Four sub-TLVs are defined.
        - Sub-Type 1: IPv4 Egress Address P2MP Responder
        - Sub-Type 2: IPv6 Egress Address P2MP Responder
        - Sub-Type 3: IPv4 Node Address P2MP Responder
        - Sub-Type 4: IPv6 Node Address P2MP Responder

      12 Echo Jitter TLV (see <a href="#section-3.3">Section 3.3</a>) is a mandatory TLV.







<span class="grey">Saxena, et al.               Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  New Global Flags Registry</span>

   IANA has created a new sub-registry of the "Multi-Protocol Label
   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
   registry.  The sub-registry is called the "Global Flags" registry.

   This registry tracks the assignment of 16 flags in the Global Flags
   field of the MPLS LSP ping echo request message.  The flags are
   numbered from 0 (most significant bit, transmitted first) to 15.

   New entries are assigned by Standards Action.

   Initial entries in the registry are as follows:

   Bit number  |  Name                      | Reference
   ------------+----------------------------+--------------
     15        |  V Flag                    | [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>]
     14        |  T Flag                    | [<a href="./rfc6425">RFC6425</a>]
     13-0      |  Unassigned                |

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Security Considerations</span>

   This document does not introduce security concerns over and above
   those described in [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>].  Note that because of the scalability
   implications of many egresses to P2MP MPLS LSPs, there is a stronger
   concern about regulating the LSP ping traffic passed to the control
   plane by the use of a rate limiter applied to the LSP ping well-known
   UDP port.  This rate limiting might lead to false indications of LSP
   failure.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Acknowledgements</span>

   The authors would like to acknowledge the authors of [<a href="./rfc4379" title="&quot;Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures&quot;">RFC4379</a>] for
   their work, which is substantially re-used in this document.  Also,
   thanks to the members of the MBONED working group for their review of
   this material, to Daniel King and Mustapha Aissaoui for their
   reviews, and to Yakov Rekhter for useful discussions.

   The authors would like to thank Bill Fenner, Vanson Lim, Danny
   Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin
   Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar,
   Sam Aldrin, and IJsbrand Wijnands for their comments and suggestions.









<span class="grey">Saxena, et al.               Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  References</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC4379">RFC4379</a>]   Kompella, K. and G. Swallow, "Detecting Multi-Protocol
               Label Switched (MPLS) Data Plane Failures", <a href="./rfc4379">RFC 4379</a>,
               February 2006.

   [<a id="ref-RFC6424">RFC6424</a>]   Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
               Performing LSP-Ping over MPLS Tunnels", <a href="./rfc6424">RFC 6424</a>,
               November 2011.

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Informative References</span>

   [<a id="ref-IANA-AF">IANA-AF</a>]   IANA Assigned Port Numbers,
               &lt;<a href="http://www.iana.org/assignments/address-family-numbers">http://www.iana.org/assignments/address-family-numbers</a>&gt;.

   [<a id="ref-RFC792">RFC792</a>]    Postel, J., "Internet Control Message Protocol", STD 5,
               <a href="./rfc792">RFC 792</a>, September 1981.

   [<a id="ref-RFC4461">RFC4461</a>]   Yasukawa, S., Ed., "Signaling Requirements for Point-to-
               Multipoint Traffic-Engineered MPLS Label Switched Paths
               (LSPs)", <a href="./rfc4461">RFC 4461</a>, April 2006.

   [<a id="ref-RFC4687">RFC4687</a>]   Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
               "Operations and Management (OAM) Requirements  for Point-
               to-Multipoint MPLS Networks", <a href="./rfc4687">RFC 4687</a>, September 2006.

   [<a id="ref-RFC4875">RFC4875</a>]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
               Yasukawa, Ed., "Extensions to Resource Reservation
               Protocol - Traffic Engineering (RSVP-TE) for Point-to-
               Multipoint TE Label Switched Paths (LSPs)", <a href="./rfc4875">RFC 4875</a>, May
               2007.

   [<a id="ref-RFC5884">RFC5884</a>]   Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
               "Bidirectional Forwarding Detection (BFD) for MPLS Label
               Switched Paths (LSPs)", <a href="./rfc5884">RFC 5884</a>, June 2010.

   [<a id="ref-RFC6348">RFC6348</a>]   Le Roux, JL., Ed., and T. Morin, Ed., "Requirements for
               Point-to-Multipoint Extensions to the Label Distribution
               Protocol", <a href="./rfc6348">RFC 6348</a>, September 2011.







<span class="grey">Saxena, et al.               Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6425">RFC 6425</a>            P2MP MPLS Extensions to LSP PING       November 2011</span>


   [<a id="ref-RFC6388">RFC6388</a>]   Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
               Thomas, "Label Distribution Protocol Extensions for
               Point-to-Multipoint and Multipoint-to-Multipoint Label
               Switched Paths", <a href="./rfc6388">RFC 6388</a>, November 2011.

Authors' Addresses

   Shaleen Saxena
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA 01719
   EMail: ssaxena@cisco.com

   George Swallow
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA 01719
   EMail: swallow@cisco.com

   Zafar Ali
   Cisco Systems Inc.
   2000 Innovation Drive
   Kanata, ON, K2K 3E8, Canada.
   Phone: 613-889-6158
   EMail: zali@cisco.com

   Adrian Farrel
   Juniper Networks
   EMail: adrian@olddog.co.uk

   Seisho Yasukawa
   NTT Corporation
   3-9-11, Midori-Cho Musashino-Shi
   Tokyo 180-8585 Japan
   Phone: +81 422 59 2684
   EMail: yasukawa.seisho@lab.ntt.co.jp

   Thomas D. Nadeau
   CA Technologies, Inc.
   273 Corporate Drive
   Portsmouth, NH 03801

   EMail: thomas.nadeau@ca.com








Saxena, et al.               Standards Track                   [Page 28]
</pre>