doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc6425.txt b/doc/rfc/rfc6425.txt
new file mode 100644
index 0000000..f257ad6
--- /dev/null
+++ b/doc/rfc/rfc6425.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    S. Saxena, Ed.
+Request for Comments: 6425                                    G. Swallow
+Updates: 4379                                                     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
+
+
+                    Detecting Data-Plane Failures in
+           Point-to-Multipoint MPLS - Extensions to LSP Ping
+
+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 RFC 4379.
+
+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/rfc6425.
+
+
+
+Saxena, et al.               Standards Track                    [Page 1]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   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
+
+   1. Introduction ....................................................3
+      1.1. Design Considerations ......................................4
+      1.2. Terminology ................................................4
+   2. Notes on Motivation .............................................5
+      2.1. Basic Motivations for LSP Ping .............................5
+      2.2. Motivations for LSP Ping for P2MP LSPs .....................6
+   3. Packet Format ...................................................7
+      3.1. Identifying the LSP Under Test .............................8
+           3.1.1. Identifying a P2MP MPLS TE LSP ......................8
+                  3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV .............8
+                  3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV .............9
+           3.1.2. Identifying a Multicast LDP LSP .....................9
+                  3.1.2.1. Multicast LDP FEC Stack Sub-TLVs ..........10
+                  3.1.2.2. Applicability to
+                           Multipoint-to-Multipoint LSPs .............11
+      3.2. Limiting the Scope of Responses ...........................11
+           3.2.1. Egress Address P2MP Responder Sub-TLVs .............12
+           3.2.2. Node Address P2MP Responder Sub-TLVs ...............13
+      3.3. Preventing Congestion of Echo Replies .....................14
+
+
+
+Saxena, et al.               Standards Track                    [Page 2]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+      3.4. Respond Only If TTL Expired Flag ..........................14
+      3.5. Downstream Detailed Mapping TLV ...........................15
+   4. Operation of LSP Ping for a P2MP LSP ...........................15
+      4.1. Initiating LSR Operations .................................16
+           4.1.1. Limiting Responses to Echo Requests ................16
+           4.1.2. Jittered Responses to Echo Requests ................16
+      4.2. Responding LSR Operations .................................17
+           4.2.1. Echo Reply Reporting ...............................18
+                  4.2.1.1. Responses from Transit and Branch Nodes ...19
+                  4.2.1.2. Responses from Egress Nodes ...............19
+                  4.2.1.3. Responses from Bud Nodes ..................19
+      4.3. Special Considerations for Traceroute .....................21
+           4.3.1. End of Processing for Traceroutes ..................21
+           4.3.2. Multiple Responses from Bud and Egress Nodes .......22
+           4.3.3. Non-Response to Traceroute Echo Requests ...........22
+           4.3.4. Use of Downstream Detailed Mapping TLV in
+                  Echo Requests ......................................23
+           4.3.5. Cross-Over Node Processing .........................23
+   5. Non-Compliant Routers ..........................................24
+   6. OAM and Management Considerations ..............................24
+   7. IANA Considerations ............................................25
+      7.1. New Sub-TLV Types .........................................25
+      7.2. New TLVs ..................................................25
+      7.3. New Global Flags Registry .................................26
+   8. Security Considerations ........................................26
+   9. Acknowledgements ...............................................26
+   10. References ....................................................27
+      10.1. Normative References .....................................27
+      10.2. Informative References ...................................27
+
+1.  Introduction
+
+   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 [RFC4379].  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 [RFC4379] 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 [RFC4461].  [RFC4875] specifies a
+   signaling solution for establishing P2MP MPLS TE LSPs.
+
+
+
+
+Saxena, et al.               Standards Track                    [Page 3]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   The requirements for P2MP extensions to the Label Distribution
+   Protocol (LDP) are stated in [RFC6348].  [RFC6388] 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 [RFC4687].
+
+   This document extends the techniques described in [RFC4379] 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.
+
+1.1.  Design Considerations
+
+   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 [RFC5884].
+   As pointed out in [RFC4379], 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 [RFC4379], 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.
+
+1.2.  Terminology
+
+   The terminology used in this document for P2MP MPLS can be found in
+   [RFC4461].  The terminology for MPLS OAM can be found in [RFC4379].
+   In particular, the notation <RSC> refers to the Return Subcode as
+   defined in Section 3.1. of [RFC4379].
+
+
+
+
+Saxena, et al.               Standards Track                    [Page 4]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Notes on Motivation
+
+2.1.  Basic Motivations for LSP Ping
+
+   The motivations listed in [RFC4379] 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.
+
+      [RFC4379] describes a mechanism that accomplishes these goals.
+      This mechanism is modeled after the ping/traceroute paradigm: ping
+      (ICMP echo request [RFC792]) is used for connectivity checks, and
+      traceroute is used for hop-by-hop fault localization as well as
+      path tracing.  [RFC4379] specifies a "ping mode" and a
+      "traceroute" mode for testing MPLS LSPs.
+
+      The basic idea as expressed in [RFC4379] 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.  [RFC4379] 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
+
+
+
+
+
+Saxena, et al.               Standards Track                    [Page 5]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+      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.
+
+2.2.  Motivations for LSP Ping for P2MP LSPs
+
+   As stated in [RFC4687], 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 [RFC6388] 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 [RFC4875] 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.
+
+
+
+
+Saxena, et al.               Standards Track                    [Page 6]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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.
+
+3.  Packet Format
+
+   The basic structure of the LSP ping packet remains the same as
+   described in [RFC4379].  Some new TLVs and sub-TLVs are required to
+   support the new functionality.  They are described in the following
+   sections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saxena, et al.               Standards Track                    [Page 7]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+3.1.  Identifying the LSP Under Test
+
+3.1.1.  Identifying a P2MP MPLS TE LSP
+
+   [RFC4379] 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 [RFC4875] 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
+
+3.1.1.1.  RSVP P2MP IPv4 Session Sub-TLV
+
+   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 19.1.1 and 19.2.1 of [RFC4875].
+   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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Saxena, et al.               Standards Track                    [Page 8]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+3.1.1.2.  RSVP P2MP IPv6 Session Sub-TLV
+
+   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 19.1.2 and 19.2.2 of [RFC4875].
+   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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.1.2.  Identifying a Multicast LDP LSP
+
+   [RFC4379] 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 [RFC6388] 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.
+
+
+
+
+
+
+
+Saxena, et al.               Standards Track                    [Page 9]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+      Sub-Type #       Length              Value Field
+      ----------       ------              -----------
+              19       Variable            Multicast P2MP LDP FEC Stack
+              20       Variable            Multicast MP2MP LDP FEC Stack
+
+3.1.2.1.  Multicast LDP FEC Stack Sub-TLVs
+
+   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 [IANA-AF] 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.
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 10]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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.
+
+3.1.2.2.  Applicability to Multipoint-to-Multipoint LSPs
+
+   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.
+
+3.2.  Limiting the Scope of Responses
+
+   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.
+
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 11]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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.
+
+3.2.1.  Egress Address P2MP Responder Sub-TLVs
+
+   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
+
+
+
+Saxena, et al.               Standards Track                   [Page 12]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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.
+
+3.2.2.  Node Address P2MP Responder Sub-TLVs
+
+   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
+
+
+
+Saxena, et al.               Standards Track                   [Page 13]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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.
+
+3.3.  Preventing Congestion of Echo Replies
+
+   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.
+
+3.4.  Respond Only If TTL Expired Flag
+
+   A new flag is being introduced in the Global Flags field defined in
+   [RFC4379].  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 [RFC4379].
+
+
+
+Saxena, et al.               Standards Track                   [Page 14]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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.
+
+3.5.  Downstream Detailed Mapping TLV
+
+   The Downstream Detailed Mapping TLV is described in [RFC6424].  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 Section 3.4 of [RFC6424], the Downstream Mapping TLV as
+   described in [RFC4379] is being deprecated.
+
+   Therefore, for P2MP, a node MUST support the Downstream Detailed
+   Mapping TLV.  The Downstream Mapping TLV [RFC4379] 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 Section 4.
+
+4.  Operation of LSP Ping for a P2MP LSP
+
+   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 [RFC4379] rather than
+   invent new mechanisms.
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 15]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   As specified in [RFC4379], 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 [RFC4379].
+
+   This section specifies processing of echo requests for both ping and
+   traceroute mode at various nodes (ingress, transit, etc.) of the P2MP
+   LSP.
+
+4.1.  Initiating LSR Operations
+
+   The LSR initiating the echo request will follow the procedures in
+   [RFC4379].  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 Section 3.1.  Additionally, there may be
+   other optional TLVs present.
+
+4.1.1.  Limiting Responses to Echo Requests
+
+   As described in Section 2.2, 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 Section 3.2.  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.
+
+4.1.2.  Jittered Responses to Echo Requests
+
+   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.
+
+
+
+Saxena, et al.               Standards Track                   [Page 16]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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 Section 3.3.  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.
+
+4.2.  Responding LSR Operations
+
+   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 [RFC4379].  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 [RFC4379] 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).
+
+
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 17]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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 [RFC4379] 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 Section 3.2 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 [RFC4379]
+            processing rules.
+
+4.2.1.  Echo Reply Reporting
+
+   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 [RFC4379].
+
+   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.
+
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 18]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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 Section 4.2, the Return Code might change
+   based on the presence of a Responder Identifier TLV or Downstream
+   Detailed Mapping TLV.
+
+4.2.1.1.  Responses from Transit and Branch Nodes
+
+   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 <RSC>').  The
+   notation <RSC> refers to the Return Subcode as defined in Section
+   3.1. of [RFC4379].  For error conditions, use appropriate values
+   defined in [RFC4379].
+
+   The presence of a Downstream Detailed Mapping TLV will influence the
+   choice of Return Code.  As per [RFC6424], the Return Code in the echo
+   reply header MAY be set to 'See DDM TLV for Return Code and Return
+   Subcode' as defined in [RFC6424].  The Return Code for each
+   Downstream Detailed Mapping TLV will depend on the downstream path as
+   described in [RFC6424].
+
+   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.
+
+4.2.1.2.  Responses from Egress Nodes
+
+   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 <RSC>').  For error conditions, use appropriate values
+   defined in [RFC4379].
+
+   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 [RFC6424].
+
+4.2.1.3.  Responses from Bud Nodes
+
+   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
+
+
+
+Saxena, et al.               Standards Track                   [Page 19]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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
+         <RSC>').  For error conditions, use appropriate values defined
+
+
+
+Saxena, et al.               Standards Track                   [Page 20]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+         in [RFC4379].  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 <RSC>').  For error
+            conditions, use appropriate values defined in [RFC4379].
+
+         -  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 [RFC6424].  The Return Code
+            for the Downstream Detailed Mapping TLV will depend on the
+            downstream path as described in [RFC6424].  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
+            <RSC>').  For error conditions, use appropriate values
+            defined in [RFC4379].
+
+         -  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
+            <RSC>').  For error conditions, use appropriate values
+            defined in [RFC4379].  The Return Code for the each
+            Downstream Detailed Mapping TLV will depend on the
+            downstream path as described in [RFC6424].  There will be a
+            Downstream Detailed Mapping for each downstream path from
+            the node.
+
+4.3.  Special Considerations for Traceroute
+
+4.3.1.  End of Processing for Traceroutes
+
+   As specified in [RFC4379], 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.
+
+
+
+Saxena, et al.               Standards Track                   [Page 21]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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.
+
+4.3.2.  Multiple Responses from Bud and Egress Nodes
+
+   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 Section 3.4.
+
+   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.
+
+4.3.3.  Non-Response to Traceroute Echo Requests
+
+   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.
+
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 22]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   When no reply to an echo request is received by the ingress, then (as
+   per [RFC4379]) 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.
+
+4.3.4.  Use of Downstream Detailed Mapping TLV in Echo Requests
+
+   As described in Section 4.6 of [RFC4379], 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 Section 4.2, 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 [RFC4379].
+
+4.3.5.  Cross-Over Node Processing
+
+   A cross-over node will require slightly different processing for
+   traceroute mode.  The following definition of cross-over is taken
+   from [RFC4875].
+
+      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.
+
+
+
+Saxena, et al.               Standards Track                   [Page 23]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   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.
+
+5.  Non-Compliant Routers
+
+   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.
+
+6.  OAM and Management Considerations
+
+   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.
+
+
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 24]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+      -  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.
+
+7.  IANA Considerations
+
+7.1.  New Sub-TLV Types
+
+   Four new sub-TLV types are defined for inclusion within the LSP ping
+   [RFC4379] 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 (Section 3.1.1)
+      18 RSVP P2MP IPv6 Session (Section 3.1.1)
+      19 Multicast P2MP LDP FEC Stack (Section 3.1.2)
+      20 Multicast MP2MP LDP FEC Stack (Section 3.1.2)
+
+7.2.  New TLVs
+
+   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 Section 3.2) 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 Section 3.3) is a mandatory TLV.
+
+
+
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 25]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+7.3.  New Global Flags Registry
+
+   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                    | [RFC4379]
+     14        |  T Flag                    | [RFC6425]
+     13-0      |  Unassigned                |
+
+8.  Security Considerations
+
+   This document does not introduce security concerns over and above
+   those described in [RFC4379].  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.
+
+9.  Acknowledgements
+
+   The authors would like to acknowledge the authors of [RFC4379] 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.
+
+
+
+
+
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 26]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+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.
+
+   [RFC6424]   Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
+               Performing LSP-Ping over MPLS Tunnels", RFC 6424,
+               November 2011.
+
+10.2.  Informative References
+
+   [IANA-AF]   IANA Assigned Port Numbers,
+               <http://www.iana.org/assignments/address-family-numbers>.
+
+   [RFC792]    Postel, J., "Internet Control Message Protocol", STD 5,
+               RFC 792, September 1981.
+
+   [RFC4461]   Yasukawa, S., Ed., "Signaling Requirements for Point-to-
+               Multipoint Traffic-Engineered MPLS Label Switched Paths
+               (LSPs)", RFC 4461, April 2006.
+
+   [RFC4687]   Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
+               "Operations and Management (OAM) Requirements  for Point-
+               to-Multipoint MPLS Networks", RFC 4687, September 2006.
+
+   [RFC4875]   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)", RFC 4875, May
+               2007.
+
+   [RFC5884]   Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+               "Bidirectional Forwarding Detection (BFD) for MPLS Label
+               Switched Paths (LSPs)", RFC 5884, June 2010.
+
+   [RFC6348]   Le Roux, JL., Ed., and T. Morin, Ed., "Requirements for
+               Point-to-Multipoint Extensions to the Label Distribution
+               Protocol", RFC 6348, September 2011.
+
+
+
+
+
+
+
+Saxena, et al.               Standards Track                   [Page 27]
+
+RFC 6425            P2MP MPLS Extensions to LSP PING       November 2011
+
+
+   [RFC6388]   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", RFC 6388, 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]
+