Network Working Group                                 A. Farrel (Editor)
Internet-Draft                                        Old Dog Consulting
Intended Status: Standards Track                             S. Yasukawa
Updates: RFC4379                                                     NTT
Created: September 10, 2008
Expires: March 10, August 11, 2009
Expires: February 11, 2010

     Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol
             Label Switching (MPLS) - Extensions to LSP Ping

                  draft-ietf-mpls-p2mp-lsp-ping-07.txt

                  draft-ietf-mpls-p2mp-lsp-ping-08.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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.

Copyright Notice

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

Conventions used in this document
   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].

Contents

   1. Introduction ................................................... Introduction.................................................... 4
   1.1 Design Considerations ......................................... Considerations.......................................... 5
   2. Notes on Motivation ............................................ Motivation............................................. 6
   2.1. Basic Motivations for LSP Ping ............................... Ping................................ 6
   2.2. Motivations for LSP Ping for P2MP LSPs ....................... 8 LSPs........................ 6
   2.3 Bootstrapping Other OAM Procedures Using LSP Ping ............. 9 Ping.............. 8
   3. Operation of LSP Ping for a P2MP LSP ........................... 9 LSP............................ 8
   3.1. Identifying the LSP Under Test ............................... Test................................ 9
   3.1.1. Identifying a P2MP MPLS TE LSP ............................. LSP.............................. 9
   3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... Sub-TLV............................ 9
   3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV .......................... 10 Sub-TLV............................ 9
   3.1.2. Identifying a Multicast LDP LSP ........................... LSP............................ 10
   3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... Sub-TLVs......................... 10
   3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 11
   3.2. Ping Mode Operation ......................................... Operation.......................................... 12
   3.2.1. Controlling Responses to LSP Pings ........................ Pings......................... 12
   3.2.2. Ping Mode Egress Procedures ............................... Procedures................................ 12
   3.2.3. Jittered Responses ........................................ 13 Responses......................................... 12
   3.2.4. P2MP Responder Identifier TLV and Sub-TLVs ................ Sub-TLVs................. 13
   3.2.4.1. Egress Address P2MP Responder Identifier Sub-TLVs........ 14
   3.2.4.2. Node Address P2MP Responder Identifier Sub-TLVs.......... 14
   3.2.5. Echo Jitter TLV ........................................... TLV............................................ 15
   3.2.6. Echo Response Reporting ................................... Reporting.................................... 15
   3.2.6.1 Ping Responses at Transit and Branch Nodes................ 16
   3.2.6.2 Ping Responses at Egress and Bud Nodes.................... 16
   3.3. Traceroute Mode Operation ................................... Operation.................................... 16
   3.3.1. Traceroute Responses at Non-Branch Nodes .................. 17
   3.3.1.1. Correlating Traceroute Responses ........................ Responses........................... 17
   3.3.2. Traceroute Responses at Branch Nodes ..................... Transit Nodes...................... 18
   3.3.2.1. Node Properties TLV .....................................
   3.3.3. Traceroute Responses at Branch Nodes....................... 18
   3.3.2.2. Branching Properties Sub-TLV ............................ 19
   3.3.2.3. Egress Address Sub-TLV .................................. 20
   3.3.2.4. Correlating
   3.3.4. Traceroute Responses ........................ 21
   3.3.3. at Egress Nodes....................... 19
   3.3.5. Traceroute Responses at Bud Nodes ......................... 21
   3.3.4. Nodes.......................... 19
   3.3.6. Non-Response to Traceroute Echo Requests .................. 22
   3.3.5. Additions to Requests................... 20
   3.3.7 Use of Downstream Detailed Mapping Multipath Information ..... 22
   3.3.6. Echo Response Reporting ................................... 24
   3.3.6.1. Reporting Multiple Conditions Using The DDM TLV ......... 24 in Echo Request...... 20
   4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 25
   5. Non-compliant Routers ......................................... 26
   6. Routers.......................................... 20
   5. OAM Considerations ............................................ 26
   7. Considerations............................................. 20
   6. IANA Considerations ........................................... 27
   7.1. Considerations............................................ 21
   6.1. New Sub-TLV Types ........................................... 27
   7.2. New Multipath Type .......................................... 27
   7.3. New TLVs .................................................... 28
   7.4. New Return Code ............................................. 28
   7.5. Types............................................ 21
   6.2. New Sub-TLV Value for the Downstream Detailed Mapping TLV ... 28
   8. TLVs..................................................... 21
   7. Security Considerations ....................................... 29 Considerations........................................ 22
   8. Acknowledgements............................................... 22
   9. Acknowledgements .............................................. 29
   10. Intellectual Property Considerations ......................... 29
   11. References..................................................... 23
   9.1 Normative References ......................................... 30
   12. References.......................................... 23
   9.2 Informative References ....................................... 30
   13. References........................................ 23
   10. Authors' Addresses ........................................... 31
   14. Addresses............................................ 24
   11. Full Copyright Statement ..................................... 32 Statement...................................... 25

0. Change Log

   This section to be removed before publication as an RFC.

0.1 Changes from 00 to 01

   - Update references.
   - Fix boilerplate.

0.2 Changes from 01 to 02

   - Update entire document so that it is not specific to MPLS-TE, but
     also includes multicast LDP LSPs.
   - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new
     egress identifier TLV.
   - Include Multicast LDP FEC Stack sub-TLV definition from [MCAST-CV].
   - Add brief section on use of LSP Ping for bootstrapping.
   - Add new references to References section.
   - Add details of two new authors.

0.3 Changes from 02 to 03

   - Update references.
   - Update boilerplate.
   - Fix typos.
   - Clarify in 3.2.2 that a recipient of an echo request must reply
     only once it has applied incoming rate limiting.
   - Tidy references to bootstrapping for [MCAST-CV] in 1.1.
   - Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in
     sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4.
   - Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs
     in sections 3.2.1 and 3.2.2.

0.4 Changes from 03 to 04

   - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and
     3.3.4 with respect to multiple sub-TLVs in the P2MP Egress
     Identifier TLV.

0.5 Changes from 04 to 05

   - Change coordinates for Tom Nadeau. Section 13.
   - Fix typos.
   - Update references.
   - Resolve all acronym expansions.

0.6 Changes from 05 to 06

   - New section, 3.2.6, to explain echo response reporting in the Ping
     case.

   - New section, 3.3.7, to explain echo response reporting in the
     Traceroute case.
   - Sections 3.3.2, 3.3.5, and 5. Retire the E-flag for identification
     of bud nodes. Use the B-flag in a Downstream Mapping TLV with a
     zero address to provide the necessary indication.
   - Section 3.3.4. Note the use of ALLROUTERS address as per RFC 4379
   - Section 7. Suggest values for IANA assignment.
   - Rename "P2MP Responder Identifier TLV" to "P2MP Responder
     Identifier TLV", "Egress Identifier sub-TLV" to "Responder
     Identifier sub-TLV", and "P2MP egresses" multipath type to "P2MP
     responder". This allows any LSR on the P2MP LSP to be the target
     of, or responder to, an echo request.

0.7 Changes from 06 to 07

   - Sections 3.3.2 and 3.3.3. Delete section 3.3.5. New sections
     3.3.2.1 through 3.3.2.3: Retire B-flag from Downstream Mapping TLV.
     Introduce new Node Properties TLV with Branching Properties and
     Egress Address sub-TLVs.
   - Section 3.3.2.4: Clarify rules on presence of Multipath Information
     in Downstream Mapping TLVs.
   - Section 3.3.5: Clarify padding rules.
   - Section 3.3.6: Updated to use Downstream Detailed Mapping TLVs for
     multiple return conditions reported by a single echo response.
   - Section 7: Update IANA values and add new sub-sections.
   - Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap.
   - Section 13: Update Bill Fenner's coordinates.

1. Introduction

   Simple and efficient mechanisms that can be used

0.8 Changes from 07 to detect data plane
   failures in point-to-point (P2P) Multiprotocol Label Switching 08
   - Removed the Node Properties TLV (Section 3.3.2.1 of version 07).
   - Removed the New Multipath Type from Multipath Sub-TLV (Section
     3.3.5 of version 07).
   - Removed the Return Code Sub-TLV from Downstream Detailed TLV
     (Section 3.3.6.1 of version 07), as it is already included in
     draft-ietf-mpls-lsp-ping-enhanced-dsmap-02.
   - Clarified the behavior of Responder Identifier TLV (Section
     3.2.4 of version 07). Two new Sub-TLVs are introduced.
   - Downstream Detailed Mapping TLV is now mandatory for implementing
     P2MP OAM functionality.
   - Split Multicast LDP TLV into two TLVs, one for P2MP and other for
     MP2MP. Also added description to allow MP2MP ping by using this
     draft.
   - Removed Section 4. as it was a duplicate of Section 2.3.

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 an MPLS "echo request" and "echo
   reply", and mechanisms for transporting the echo reply. 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.

   The requirements for point-to-multipoint extensions to the Label
   Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP]
   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. Mechanisms are, therefore, desirable 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 and so that they can be
   used to bootstrap other Operations and Management (OAM) procedures
   such as [MCAST-CV]. 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, it 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 OAM
   procedures such as [MPLS-BFD] and [MCAST-CV]. 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 well-known
   UDP port defined for use by LSP Ping traffic.

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
   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 [P2MP-LDP] uses the Label Distribution Protocol 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 TE 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 response message is sent by
   an egress to the ingress to confirm the successful receipt (or
   announce the erroneous arrival) of the echo request.

   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 also returns information on an echo response that helps verify
   the control plane against the data plane. That is, the information
   is used by the ingress to check that the data plane forwarding
   matches what is signaled by the control plane.

   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 responses 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. Therefore, the procedures described in this
   document provide a mechanism that allows the responders to randomly
   delay (or jitter) their responses so that the chances of swamping the
   ingress are reduced.

   Further, the procedures in this document allow the initiator to limit
   the scope of an LSP Ping echo request (ping or traceroute mode) to
   one specific intended egress.

   The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be
   addressed by other mechanisms such as [MCAST-CV] that utilize the LSP
   Ping procedures in this document to provide bootstrapping mechanisms
   as described in Section 2.3.

   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.

2.3 Bootstrapping Other OAM Procedures Using LSP Ping

   [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to
   bootstrap the Bidirectional Forwarding Detection (BFD) mechanism
   [BFD] for use to track the liveliness of an MPLS LSP. In particular
   BFD can be used to detect a data plane failure in the forwarding
   path of an MPLS LSP.

   Requirements for MPLS P2MP LSPs extend to hundreds or even thousands
   of endpoints. If a protocol required explicit acknowledgments to
   each probe for connectivity verification, the response load at the
   root would be overwhelming.

   A more scalable approach to monitoring P2MP LSP connectivity is
   described in [MCAST-CV]. It relies on using the MPLS echo request and
   echo response messages of LSP Ping [RFC4379] to bootstrap the
   monitoring mechanism in a manner similar to [MPLS-BFD]. The actual
   monitoring is done using a separate process defined in [MCAST-CV].

   Note that while the approach described in [MCAST-CV] was developed in
   response to the multicast scalability problem, it can be applied to
   P2P LSPs as well.

3. Operation of LSP Ping for a P2MP LSP

   This section describes how LSP Ping is applied to P2MP MPLS LSPs.
   It covers the mechanisms and protocol fields applicable to both ping
   mode and traceroute mode. It explains the responsibilities of the
   initiator (ingress), transit nodes, and receivers (egresses).

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
      ----------       ------              -----------
             TBD         20                RSVP P2MP IPv4 Session
             TBD         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 [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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 [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 new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This
   sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so
   provides sufficient information to uniquely identify the LSP.

   The new sub-TLV is assigned a sub-type identifier as follows, and
   is described in the following section.

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

3.1.2.1. Multicast LDP FEC Stack Sub-TLV

   The format of the Sub-TLVs

    Both Multicast P2MP and MP2MP LDP FEC Stack sub-TLV is shown below. 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

      A two

      Two octet quantity containing a value from ADDRESS FAMILY NUMBERS
      in [IANA-PORT] that encodes the address family for the Root LSR
      Address.

   Address Length

      The length

      Length of the Root LSR Address in octets.

   Root LSR Address

      An 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.

   Opaque Value

      An opaque value elements of element which 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 nodes.

3.2. Ping Mode Operation

3.2.1. Controlling Responses to LSP Pings

   As described in Section 2.2, it may be desirable to restrict the
   operation of LSP Ping to a single egress. Since echo requests are
   forwarded through the data plane without interception by the control
   plane (compare with traceroute mode), there is no facility to limit
   the propagation of echo requests, and they will automatically be
   forwarded to all (reachable) egresses.

   However, the intended egress under test can be identified by the
   inclusion of a P2MP Responder Identifier TLV containing an IPv4 P2MP
   Responder Identifier sub-TLV or an IPv6 P2MP Responder Identifier
   sub-TLV. TLV. The P2MP Responder Identifier details of this TLV SHOULD contain precisely
   one sub-TLV. If
   and its Sub-TLVs are in section 3.2.4. The initiator may choose
   whether only the TLV contains no sub-TLVs it SHOULD be processed
   as if node identified in the whole TLV were absent (causing all egresses to respond as
   described below). If responds or any node on
   the TLV contains more than one sub-TLV, path to the
   first MUST be processed as described node identified in this document, and subsequent
   sub-TLVs SHOULD be ignored. the TLV may respond.

   An initiator may indicate that it wishes all egresses to respond to
   an echo request by omitting the P2MP Responder Identifier TLV.

   Note that the ingress of a multicast LDP LSP will not know the
   identities of the egresses of the LSP except by some external means
   such as running P2MP LSP Ping to all egresses.

3.2.2. Ping Mode Egress Procedures

   An egress node is RECOMMENDED to rate limit its receipt of echo
   request messages as described in [RFC4379]. After rate limiting, an
   egress node that receives an echo request carrying an RSVP P2MP IPv4
   Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast
   LDP FEC Stack sub-TLV MUST determine whether it is an intended egress of the
   P2MP LSP in question by checking with the control plane.

     - If it the node is not supposed to be an egress, it MUST respond according to the
       setting of the Response Type field in the echo message following
       the rules defined in [RFC4379].

     - If the egress node that receives an echo request and allows it
   through its rate limiting is an intended egress of the P2MP LSP, the node MUST must
       check to see whether it is an intended Ping recipient. If a
   P2MP Responder Identifier TLV is present and contains an address that
   indicates any address that is local to the node, the node MUST
   respond according to the setting receipient of the Response Type field in the echo message following the rules defined in [RFC4379]. request.
       - If the a P2MP Responder Identifier TLV is present, but does not identify then the egress
   node, node
       must follow the procedures defined in section 3.2.4 to determine
       whether it MUST NOT should respond to the echo request. reqeust or not.
       - If the P2MP Responder Identifier TLV is not present (or, in the
       error case, is present, but does not contain any sub-TLVs), but and
       the egress node that received the echo request is an intended
       egress of the LSP, the node MUST respond according to the setting
       of the Response Type field in the echo message following the
       rules defined in [RFC4379].

3.2.3. Jittered Responses
   The initiator (ingress) of a ping request MAY request the responding
   egress to introduce a random delay (or jitter) before sending the
   response. The randomness of the delay allows the responses from
   multiple egresses to be spread over a time period. Thus this
   technique is particularly relevant when the entire LSP tree is being
   pinged since it helps prevent the ingress (or nearby routers) from
   being swamped by responses, or from discarding responses due to rate
   limits that have been applied.

   It is desirable for the ingress to be able to control the bounds
   within which the egress delays the response. 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 ingress informs the egresses of
   the jitter bound by supplying a value in a new TLV (the Echo Jitter
   TLV) carried on the echo request message. If this TLV is present, the
   responding egress MUST delay sending a response for a random amount
   of time between zero seconds 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.

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

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

   It is RECOMMENDED that echo response jittering is not used except in
   the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo
   request for any other type of TLV, the responding egress MAY apply
   the jitter behavior described here.

3.2.4. P2MP Responder Identifier TLV and Sub-TLVs

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

   The P2MP Responder Identifier TLV is assigned the TLV type value TBD
   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=TBD(P2MP Responder ID TLV)|       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 MUST
        be processed as described in this document, and subsequent
        sub-TLVs SHOULD be ignored.

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

   Two

   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 Identifier
              2        16     IPv6 Egress Address P2MP Responder Identifier

   The value of an
              3         4     IPv4 Node Address P2MP Responder Identifier consists of four
   octets of an IPv4 address. The IPv4 address is in network byte order.

   The value of an
              4        16     IPv6 Node Address P2MP Responder Identifier consists

   The content of these Sub-TLVs are defined in the following
   sections. Also defined is the intended behavior of sixteen
   octets the responding
   node upon receiving any of an IPv6 address. The IPv6 address these Sub-TLVs. Please note that the echo
   response is always controlled by Response Type field in network byte order.

3.2.5. Echo Jitter TLV

   A new TLV is the echo
   message as defined for inclusion in [RFC4379] and whether or not the Echo request message.

   The Echo Jitter TLV responding
   node is assigned part for the TLV type value TBD 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 = TBD (Jitter TLV)  |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Jitter time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Jitter time:

        This field specifies the upper bound of P2MP tree being identified in the jitter period that
        should be applied by a responding node to determine how long Target FEC
   Stack TLV. The Sub-TLVs defined in this section provide additional
   constraints to
        wait before sending those requirements and are not a replacement for those
   requirements.

3.2.4.1. Egress Address P2MP Responder Identifier Sub-TLVs

   The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs
   MAY be used in an echo response. request carrying RSVP P2MP Session
   Sub-TLV. They SHOULD NOT be used with an echo request carrying
   Multicast LDP FEC Stack Sub-TLV.

   A responding node SHOULD
        wait a random amount of time between zero seconds and the value
        specified in this field.

        Jitter time is specified in milliseconds.

   The Echo Jitter TLV only has meaning on that receives an echo request message. If with this Sub-TLV present MUST
   respond only if the node lies on an echo response message, it the path to the address in the
   Sub-TLV.

   The address in this Sub-TLV SHOULD be ignored.

3.2.6. Echo Response Reporting

   Echo response messages carry return codes of an egress or bud node and subcodes
   SHOULD NOT be of a transit or branch node. This address MUST be known
   to indicate the result nodes upstream of the LSP Ping (when the ping mode is being used) target node, possibly via control plane
   signaling, such as
   described RSVP. This Sub-TLV may be used to trace a specific
   egress or bud node in [RFC4379].

   When the responding P2MP tree.

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

   A node reports that it is receives an egress, it is clear
   that the echo response applies request with this Sub-TLV present MUST
   respond only to the reporting node. Similarly,
   when a node reports that it does not form part of the LSP described
   by if the FEC (i.e. their is a misconnection) then address in the echo response
   applies Sub-TLV corresponds to the reporting node.

   However, it should be noted that an echo response message any address
   that
   reports an error from a transit node may apply is local to multiple egress
   nodes (i.e. leaves) downstream of the reporting node. In This address in the case Sub-TLV may be of any
   physical interface or may be the Ping mode router id of operation, it is not possible to correlate the
   reporting node to the affected egresses unless the shape itself.

   The address in this Sub-TLV SHOULD be of the any transit, branch, bud or
   egress node for that P2MP
   tree is already known, and it tree. This Sub-TLV may be necessary to use the Traceroute
   mode of operation (see Section 3.3) used to further diagnose the LSP.

   Note also that a transit ping any
   specific node may discover an error but also
   determine that while it does lie on in the path of P2MP tree.

3.2.5. Echo Jitter TLV

   A new TLV is defined for inclusion in the LSP under test,
   it does not lie on Echo request message.

   The Echo Jitter TLV is assigned the path to TLV type value TBD 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 = TBD (Jitter TLV)  |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Jitter time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Jitter time:

        This field specifies the specific egress being tested. In
   this case, upper bound of the jitter period that
        should be applied by a responding node SHOULD NOT generate to determine how long to
        wait before sending an echo response. A reporting responding node that is SHOULD
        wait a branch node may need to report multiple
   different errors (for different downstream branches). This is
   discussed further in Section 3.3.6.

3.3. Traceroute Mode Operation

   The traceroute mode random amount of operation time between zero milliseconds and the
        value specified in this field.

        Jitter time is described specified in [RFC4379]. Like
   other traceroute operations, it relies milliseconds.

   The Echo Jitter TLV only has meaning on the expiration of the TTL
   of the packet that carries the an echo request. request message. If
   present on an echo response message, it SHOULD be ignored.

3.2.6. Echo requests may
   include a Downstream Mapping TLV, Response Reporting

   Echo response messages carry return codes and when the TTL expires the echo
   request is passed subcodes to indicate
   the control plane on result of the transit node which
   responds according to LSP Ping (when the Response Type ping mode is being used) as
   described in [RFC4379].

   When the message. A responding node fills in the fields of reports that it is an egress, it is clear
   that the Downstream Mapping TLV echo response applies only to indicate the downstream interfaces and labels used by reporting node. Similarly,
   when a node reports that it does not form part of the reported LSP from
   the responding node. In this way, described
   by successively sending out echo
   requests with increasing TTLs, the ingress may gain FEC (i.e. there is a picture of misconnection) then the
   path and resources used by an LSP up echo response
   applies to the point of failure when no reporting node.

   However, it should be noted that an echo response is received, or message that
   reports an error response is generated by from a transit node
   where the control plane does not expect may apply to be handling multiple egress
   nodes (i.e. leaves) downstream of the LSP.

   This reporting node. In the case of
   the Ping mode of operation operation, it is equally applicable not possible to P2MP MPLS TE LSPs
   as described in correlate the following sections.

   The traceroute mode can be applied
   reporting node to all destinations of the P2MP
   tree just as in the ping mode. In affected egresses unless the case shape of P2MP MPLS TE LSPs, the
   traceroute mode can also P2MP
   tree is already known, and it may be applied necessary to individual traceroute targets
   identified by use the presence Traceroute
   mode of a P2MP Responder Identifier TLV. These
   targets may be egresses or transit nodes. However, since operation (see Section 3.3) to further diagnose the LSP.

   Note also that a transit node of a multicast LDP LSP is unable to may discover an error but also
   determine whether that while it lies does lie on the path to any one destination or any other transit node, the
   traceroute mode limited to specific nodes of such an LSP MUST NOT be
   used.

   Note that the addresses specified in the P2MP Responder Identifier
   TLV need LSP under test,
   it does not be egresses: they could be transit nodes lie on the LSP. The
   processing rules here and in the following sections apply equally path to the specific egress and transit nodes. being tested. In
   this case, the absence of a P2MP Responder Identifier TLV, the echo request
   is asking for traceroute information applicable to all egresses.

   The node SHOULD NOT generate an echo response jitter technique described for the ping mode is
   equally applicable to the traceroute mode and is not additionally
   described in the procedures below.

3.3.1. Traceroute response.

3.2.6.1 Ping Responses at Non-Branch Transit and Branch Nodes

   When

   If the TTL for of the MPLS packet carrying an echo request expires at a
   transit or branch node, the packet MUST be passed to the control
   plane as specified in [RFC4379].

   If the LSP under test P2MP Responder Identifier is a multicast LDP LSP and if not present or does not contain
   any Sub-TLV, then the node MUST respond. If the echo request
   carries a P2MP Responder
   Identifier TLV Sub-TLV is present, then the node MUST treat respond as per
   section 3.2.4.

   If the echo
   request response being sent is not indicating an error condition,
   such as malformed and MUST process it according to Malformed request, then the rules
   specified Return Code in [RFC4379].

   Otherwise, the node MUST NOT return an echo response unless the
   responding node lies on the path of the P2MP LSP
   header may be set to the node (egress value 8 ('Label switched at stack-depth <RSC>')
   or transit) identified by any other error value as needed.

3.2.6.2 Ping Responses at Egress and Bud Nodes

   The echo request packet MUST be sent to the control plane at egress
   and bud nodes.

   If the P2MP Responder Identifier TLV carried
   on the request, or if no such sub-TLV is present.

   If sent, not present or does not contain
   any Sub-TLV, then the echo response node MUST identify the next hop of the path of
   the LSP in respond. If the data plane by including a Downstream Mapping TLV as
   described in [RFC4379].

3.3.1.1. Correlating Traceroute Responses

   When traceroute is being simultaneously applied to multiple
   responders (e.g., egresses), it P2MP Responder
   Identifier Sub-TLV is important that present, then the ingress should
   be able to correlate node MUST respond as per
   section 3.2.4.

   If the echo responses with response being sent is not indicating an error condition,
   such as Malformed request, then the branches Return Code in the P2MP
   tree. Without this information the ingress will echo response
   header may be unable set to
   determine the correct ordering of transit nodes. One possibility value 3 ('Replying router is an egress for the ingress to poll the path to each responder in turn, but this
   may be inefficient, undesirable,
   FEC at stack-depth <RSC>')  or (in the case of multicast LDP
   LSPs) illegal. any other error value as needed.

3.3. Traceroute Mode Operation

   The Downstream Mapping TLV that MUST be included traceroute mode of operation is described in [RFC4379]. Like
   other traceroute operations, it relies on the echo response
   indicates expiration of the next hop from each responding node, and this
   information supplied by a non-branch node can be pieced together by TTL
   of the ingress to reconstruct packet that carries the P2MP tree although it may be necessary
   to refer to echo request. When the routing information distributed by TTL expires the IGP to
   correlate next hop addresses and node reporting addresses in
   subsequent
   echo responses.

   In order request is passed to facilitate more easy correlation of echo responses, the
   Downstream Mapping TLV can also contain Multipath Information as
   described in [RFC4379] to identify to which responders (transit
   nodes or egresses) the echo response applies. This information:

   - Cannot be present when the information is not known by the
     responding node. For example, for a multicast LDP LSP, the branch
     node will not know through normal LDP signaling which leaf nodes
     lie control plane on which downstream branch.

   - SHOULD be present when the information is known by the responding
     node. That is for P2MP MPLS TE LSPs when the echo request applies
     to all egresses or to a specific single transit node or egress.

   The format of the information in the Downstream Mapping TLV for
   P2MP MPLS LSPs is described in section 3.3.5.

3.3.2.  Traceroute Responses at Branch Nodes

   A branch node may need to identify more than one downstream interface
   in a traceroute echo response if some of the nodes identified in the
   P2MP Responder Identifier TLV that are being traced lie on different
   branches. This will always be the case for any branch node if all
   egresses are being traced.

   [RFC4379] describes how multiple Downstream Mapping TLVs should be
   included in an echo response, each identifying exactly one downstream
   interface that is applicable to the LSP.

   A branch node MUST follow the procedures described in Section 3.3.1
   to determine whether it should respond to an echo request. The branch
   node MUST add a Downstream Mapping TLV (or Downstream Detailed
   Mapping TLV - see Section 3.3.7) to the echo response for each
   outgoing branch that it reports, but it MUST NOT report branches that
   do not lie on the path to one of the destinations being traced. Thus
   a branch node may sometimes only need to respond with a single
   Downstream Mapping TLV; for example, consider the case where the
   traceroute is directed to only a single egress node. Therefore,
   the presence of only one Downstream Mapping TLV in an echo response
   does not guarantee that the reporting node is not a branch node.

   To report on its branching properties on a particular LSP, the
   responding node MAY include an optional TLV called the Node
   Properties TLV. This new TLV (see Section 3.3.2.1) can carry sub-
   TLVs, one of which (the Branching Properties sub-TLV - see Section
   3.3.2.2) allows the reporting node to describe the branching
   characteristics of the LSP at the reporting node.

3.3.2.1. Node Properties TLV

   A new TLV has been added to the set of optional TLVs that may be
   carried on an echo response message.

        Type #   Value Field
        ------   ------------

        TBD      Node properties

   The Node Properties TLV MAY be included in an echo response message.
   If more than one such TLV is present, the first MUST be processed and
   subsequent instances SHOULD be ignored.

   The Node Properties TLV is used to report characteristics of the
   reporting node, and the LSP at that node. This distinguishes it from
   the Downstream Mapping TLV [RFC4379] and the Downstream Detailed
   Mapping TLV [DDMT] used to report characteristics of specific out-
   segments an LSP.

   The Node Properties TLV is a standard LSP Ping TLV as defined in
   [RFC4379]. It has the following format.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :                        First Sub-TLV                          :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     ~                       Further Sub-TLVs                        ~
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The content of the Node Properties TLV is a series of one or more
   sub-TLVs. The Nore Properties TLV SHOULD contain one or more sub-TLVs
   and MUST be ignored if there are no sub-TLVs present.

   Each sub-TLV consists of the following fields as per [RFC4379]:

   - Two octet Type field: A value indicating the sub-TLV type.

   - Two octet Length field: A value indicating the total length of the
     Value field.

   - A Value field carrying the data of the sub-TLV. The content of the
     Value field is padded to a four byte boundary with zero-filled
     octets so that the Length field is always a multiple of 4.

3.3.2.2. Branching Properties Sub-TLV

   This document defines the Branching Properties sub-TLV carried in the
   Node Properties TLV. The Branching Properties sub-TLV is optional. If
   more than one such sub-TLV is found in a Node Properties TLV, the
   first MUST be processed and subsequent instances SHOULD be ignored.
   The sub-TLV may be used for P2MP and P2P LSPs.

   The Branching Properties sub-TLV is formed as described in Section
   3.3.2.1. The Value field has the following format.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Downstream Branch Count    |         Egress Count          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Downstream Branch Count

     This field reports the number of downstream branches from the
     reporting node for this LSP. The number may be zero for an egress,
     one for a non-branch node, and more than one for a branch node.
     Note that the value reported here may be greater than the number
     of Downstream Mapping TLVs present in the echo response message
     since those TLVs only report on the specific egresses queried. This
     value may be of use in detecting faults caused by delay introduced
     by the data replication mechanism at branch nodes.

   Egress Count

     This field reports the number of egresses local to the reporting
     node. Thus, for non-zero values the reporting node is either a leaf
     or a bud. When the value reported is non-zero, the reporting node
     MAY also include an Egress Address Sub-TLV for each local egress
     (see Section 3.3.2.3).

   For example, a branch node that has two downstream next hops on the
   LSP and that also delivers payload data to one local egress would set
   the two fields to 2 and 1 respectively.

3.3.2.3. Egress Address Sub-TLV

   This document defines the IPv4 and IPv6 Egress Address sub-TLVs
   carried in the Node Properties TLV. These TLVs are optional, and more
   than one instance of the sub-TLVs may legitimately be present.

   The Egress Address sub-TLVs are formed as described in Section
   3.3.2.1. The Value field has the following formats.

   IPv4 Egress Address Sub-TLV

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       IPv4 Egress Address                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Egress Address Sub-TLV

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       IPv6 Egress Address                     |
     |                          (16 octets)                          |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The Egress Address sub-TLVs are optional. They MAY be included in a
   Node Properties TLV when reporting node is an egress (leaf or bud)
   for the LSP being tested. The sub-TLV may be used for P2MP and P2P
   LSPs.

   When one or more Egress Address sub-TLVs are present and the Branch
   Properties sub-TLV is also present, the value of
   responds according to the Egress Count
   field Response Type in the Branch Properties sub-TLV SHOULD message (and any
   Responder Identifier TLV that may be present).

   Echo requests MAY include a Downstream Detailed Mapping TLV, and a
   responding node fills in the same as the
   number fields of Egress Address sub-TLVs.

   The address contained in an Egress Address sub-TLV is the egress
   address Downstream Detailed
   Mapping TLV to which indicate the data is delivered. If there is just one egress downstream interfaces and if labels used by
   the egress address is reported LSP from the same as responding node. In this way, by
   successively sending out echo requests with increasing TTLs, the local node address
   carried in
   ingress may gain a picture of the main echo path and resources used by an
   LSP. This process continues either to the point of failure when no
   response message, both is received, or an error response is generated by a node
   where the Branching
   Properties sub-TLV and control plane does not expect to be handling the Egress Address sub-TLV MAY LSP.

   For P2MP Traceroute, a node MUST support Downstream Detailed Mapping
   TLV [DDMT]. Downstream Mapping TLV [RFC4379] SHOULD NOT be omitted as
   in legacy LSP Ping implementations.

3.3.2.4. Correlating Traceroute Responses

   Just as with non-branches, it used for
   P2MP traceroute functionality. As per Section 4.3 of [DDMT],
   Downstream Mapping TLV is important that being deprecated. A node MUST ignore any
   Downstream Mapping TLV it receives in the echo responses
   from branch request.

   If there are nodes provide correlation information in the P2MP tree that do not support Downstream
   Detailed Mapping TLV, they will allow the
   ingress to work out send an echo reply with Return Code
   set to which branch 2. The ingress node upon receiving such a value SHOULD send
   subsequent echo requests with a larger TTL.

   The traceroute mode of the operation is equally applicable to P2MP MPLS
   TE LSP and P2MP Multicast LDP LSP and is described in the response applies. following
   sections.

   The P2MP tree traceroute mode can be determined by the ingress using the identity applied to all destinations of the reporting node and the next hop information from the previous
   echo response, P2MP
   tree just as with echo responses from non-branch nodes.

   As with non-branch nodes, in order to facilitate more easy
   correlation the ping mode. In the case of echo responses, P2MP MPLS TE LSPs, the Downstream Mapping TLV
   traceroute mode can also
   contain Multipath Information as described in [RFC4379] to identify
   to which nodes the echo response applies. This information:

   - Cannot be present when the information is not known applied to individual traceroute targets
   identified by the
     responding node. For example, for presence of a multicast LDP LSP, P2MP Responder Identifier TLV. In
   this case, the branch responding node will not know through normal LDP signaling which leaf nodes
     lie on which downstream branch.

   - must follow the behavior specified in
   3.2.4. These targets SHOULD be present when the information is known by the responding
     node. That is for P2MP MPLS TE LSPs when the echo request applies
     to all egresses or to bud nodes. However, since
   a specific single transit node or egress.

   The format of the information in the Downstream Mapping TLV for
   P2MP MPLS LSPs is described in section 3.3.5.

3.3.3. Traceroute Responses at Bud Nodes

   Some nodes on a P2MP MPLS multicast LDP LSP may be egresses, but also have
   downstream node. Such nodes are known as bud is unable to determine whether
   it lies on the path to any one destination or any other transit node,
   the traceroute mode limited to specific nodes [RFC4461].

   A bud node of such an LSP MUST respond to NOT
   be used.

   In the absence of a traceroute P2MP Responder Identifier TLV, the echo request just as a branch
   node would, but it MUST also indicate
   is asking for traceroute information applicable to all egresses.

   The echo response jitter technique described for the ingress that it ping mode is an
   egress in its own right. The issue
   equally applicable to be resolved here the traceroute mode and is how to
   indicate that not additionally
   described in the reporting node procedures below.

3.3.1. Correlating Traceroute Responses

   When traceroute is an egress when simultaneously applied to multiple responders
   (e.g. egresses), it is also
   providing one or more Downstream Mapping TLVs that indicate important that it
   has downstream neighbors.

   This the ingress is achieved by able to
   correlate the inclusion of a Node Properties TLV echo responses with a
   Branch Properties sub-TLV indicating the number of local egresses and the number of downstream branches. The bud node MAY also include one
   or more Egress Address sub-TLVs nodes in the Node Properties TLV to report
   on the local egresses.

3.3.4. Non-Response to Traceroute Echo Requests

   The nature of P2MP MPLS TE LSPs in tree. Without
   this information the data plane means that
   traceroute echo requests may ingress will be delivered unable to determine the control plane correct
   ordering of
   nodes that must not reply to the request because, although they lie
   on the P2MP tree, they do not lie on transit nodes. One possibility is for the path ingress to poll
   the node that is
   being traced.

   Thus, a node on a P2MP MPLS LSP MUST NOT respond path to an echo request
   when each responder in turn, but this may be inefficient,
   undesirable, or (in the TTL has expired if any case of the following applies:

   - multicast LDP LSPs) illegal.

   The Reply Type indicates that no reply is required [RFC4379]

   - There is a P2MP Responder Identifier Downstream Detailed Mapping TLV present on MUST be included in the echo
     request (which means that
   response from transit, bud, or branch nodes. The information from
   Downstream Detailed Mapping TLV can be pieced together by the LSP is a P2MP MPLS TE LSP), but ingress
   to reconstruct the
     address does not identify a node that is reached through this node
     for this particular P2MP MPLS LSP.

   Note that when no response tree although it may be necessary to refer to an echo request is received by
   the
   ingress (perhaps because routing information distributed by the transit IGP to correlate next hop
   addresses and node has failed, or perhaps
   because reporting addresses in subsequent echo responses.

   The following sections describe the transit node does not support LSP Ping), then as per
   [RFC4379] Return Code used in the subsequent echo request (with a larger TTL) SHOULD be
   sent with Downstream Mapping TLV "Downstream IP Address" field set to
   response header and in the ALLROUTERs multicast address until a reply is received with a Downstream Detailed Mapping TLV.

3.3.5. Additions to Downstream Mapping Multipath Information

   A new value for the Multipath Type It is defined
   possible to indicate that identify the
   reported Multipath Information applies to a P2MP MPLS TE LSP and may
   contain a list type of node identifiers that indicate (transit, branch, bud and
   egress) by using various values in the egress nodes Return Code and
   (in presence of
   Downstream Detailed Mapping TLV.

3.3.2. Traceroute Responses at Transit Nodes

   When the case where TTL of the MPLS packet carrying an echo request expires the
   packet MUST be passed to the control plane as specified in [RFC4379].

   If the echo request packet contains an IPv4 or IPv6 Egress Address
   P2MP Responder Identifier TLV was used TLV, and the FEC is IPv4 or IPv6 P2MP TE
   LSP, then the node MUST respond only if the node lies on the
   echo request path to identify non-egress nodes) transit nodes that can be
   reached through
   the reported interface. This Multipath Type MUST NOT
   be used for egress specified in the Sub-TLV.

   If the LSP under test is a multicast LDP LSP.

      Type #    Address Type          Multipath Information
      ---       ----------------      ------------------------------
      TBD       P2MP responders       List of reachable P2MP nodes

   Note that a list of nodes may include IPv4 LSP and echo request has an
   IPv4 or IPv6 identifiers since
   these may be mixed in the Egress Address P2MP MPLS TE LSP.

   The Multipath Length field continues to identify Responder Identifier TLV, then the length of
   node MUST treat the
   Multipath Information just echo request as in [RFC4379] (that is, not including
   the downstream labels), malformed and MUST process it
   according to the downstream label (or potential stack
   thereof) is also handled just as rules specified in [RFC4379]. The format of

   If the
   Multipath Information for a Multipath Type of P2MP responders echo response being sent is not indicating an error condition,
   such 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Address Type  |   Responder Address  (4 or 16 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | (continued)   |                                               :
      +-+-+-+-+-+-+-+-+                                               :
      :              Further Address Types and Responder Addresses    :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Address Type

        This field indicates whether Malformed request, it MUST identify the address that follows is an IPv4
        or IPv6 address, and so implicitly encodes next hop of the length path
   of the
        address.

        Two values are defined and mirror the values used LSP in the Address
        Type field of data plane by including a Downstream Detailed
   Mapping TLV as described in [DDMT].

   The Return Code in echo response header will be value TBD ('See DDM
   TLV for Return Code and Return SubCode') as defined in [DDMT]. The
   Return Code for the Downstream Detailed Mapping TLV itself.

          Type #        Address Type
          ------        ------------
               1        IPv4
               3        IPv6

      Responder Address

        An egress or transit node will depend on
   the state of this the output interface.

3.3.3. Traceroute Responses at Branch Nodes

   A branch node MUST follow the procedures described in Section 3.3.2
   to determine whether it should respond to an echo request.

   If the P2MP MPLS TE LSP that Responder Identifier is
        reached through the interface indicated by not present or does not contain
   any Sub-TLV (that is, if all egresses are being traced), then the
   branch node MUST add a Downstream Detailed Mapping TLV and for which to the traceroute echo request was
        enquiring.

   Note that padding to ensure
   response for each outgoing branch that the whole Multipath information is
   aligned to a four-octet boundary it reports.

   If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is applied
   present, it MUST report only after the last
   responder address in the list. That is, each successive Address Type
   follows branch that is on immediately after the previous Responder Address.

3.3.6. Echo Response Reporting

   Echo responses are generated in response path to traceroute echo requests
   at transit, branch, and bud nodes as described in Sections 3.3.1,

   3.3.2, and 3.3.3, while the
   specified egress responses are as described in
   [RFC4379].

   Note, however, that a branch or bud node may have multiple downstream
   branches, and a transit node may have multiple downstream egresses
   (reached on the same branch). It may be it MUST NOT report the case that different
   conditions need to be reported for different branches or egresses. other branches.

   The Return Code in echo response message defined in [RFC4379] has space header will be value TBD ('See DDM
   TLV for only a
   single return code Return Code and subcode pair, so where more than one return
   condition is reported by a single node it acts Return SubCode') as follows.

   - It SHOULD use defined in [DDMT]. The
   Return Code for each of the Downstream Detailed Mapping TLV [DDMT] in place
     of will
   depend on the Downstream Mapping TLV, and encode state of the return code as
     described in Section 3.3.6.1.

   - It MAY report each condition in a separate echo response output interface being reported in which
     case this
   TLV.

3.3.4. Traceroute Responses at Egress Nodes

   If P2MP Responder Identifier is not present or does not contain any
   Sub-TLV (that is, if all egresses are being traced), then the egress
   node MUST limit respond to the downstream mapping information on each echo
     response to those branches/egresses to which request.

   If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is
   present, it MUST respond only if the response applies. specified address belongs the
   egress node.

   Egress node MUST NOT return a Downstream Detailed Mapping TLV.

   The use of multiple Return Code in the echo response messages to report errors might
     cause issues header will be value 3 ('Replying
   router is an egress for the FEC at stack-depth <RSC>') as defined in
   [RFC4379].

3.3.5. Traceroute Responses at Bud Nodes

   Some nodes on a P2MP MPLS LSP may be an initiator that egress as well as a branch
   (i.e. have one or more downstream nodes). Such nodes are known as bud
   nodes [RFC4461]. A bud node's response is a combination of branch
   node and egress node behavior.

   If P2MP Responder Identifier is not present or does not know how many responses
     it should wait for. For that reason, multiple messages should be
     used with care.

3.3.6.1. Reporting Multiple Conditions Using The DDM TLV

   When multiple different return codes contain any
   Sub-TLV (that is, if all egresses are indicated on a single echo
   response message they being traced), then the bud
   node MUST be carried in separate instances on respond to the echo request. It MUST add a Downstream
   Detailed Mapping (DDM) TLV [DDMT]. That is, each instance
   of a DDM TLV carries one return code, and all information carried in
   that TLV MUST be limited to branches/egresses to which that return
   code applies. However, more than one DDM TLV on the same echo response MAY carry the same return code. for each outgoing branch
   that it reports.  The echo response message still carries a Return Code and a Return
   Subcode field. In order to clearly indicate that the relevant return
   codes are carried in the DDM TLV, a new return code echo response header will be
   value 3 ('Replying router is an egress for the FEC at stack-depth
   <RSC>') as defined to be
   carried in the [RFC4379]. The Return Code field for each of the echo response message as
   follows:

          Value    Meaning
          -----    -------
           TBD      See DDM TLV for more details

   The Return Subcode for this Return Code MUST be set to zero and
   MUST be ignored.

   The DDM
   Downstream Detailed Mapping TLV is defined as carrying a set of sub-TLVs. A new sub-TLV, will depend on the Return Code sub-TLV, is defined here to carry a return code and
   return subcode.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Return Code  | Return Subcode|           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length state of the Return Code sub-TLV
   output interface being reported in this TLV.

   If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is 8.
   present, and the specified address belongs the bud node, then it MUST
   respond as if it were an egress node. The Return Code
     As defined for inclusion in the echo
   response message in [RFC4379].

   Return Subcode
     As defined header will be value 3 ('Replying router is an egress for inclusion in
   the echo response message FEC at stack-depth <RSC>') as defined in [RFC4379].

   Reserved
     SHOULD be set to zero on transmission and It MUST be ignored on
     receipt. NOT
   report any Downstream Detailed Mapping TLV.

   If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is
   present, and the Return Code of bud node lies on the echo response message is not set path to "See
   DDM TLV for more details" the specified egress
   address, then any Return Code sub-TLV present in it MUST respond as if it was a
   DDM TLV SHOULD be ignored.

   If the branch node. The Return
   Code of in the echo response message is set to "See header will be value TBD ('See DDM TLV for more details" then a
   Return Code sub-TLV MUST be present and Return SubCode') as defined in
   each DDM TLV. Subsequent [DDMT]. The Return
   Code sub-TLVs present for each of the Downstream Detailed Mapping TLV will depend on
   the state of the output interface being reported in this TLV.

3.3.6. Non-Response to Traceroute Echo Requests

   There are multiple reasons for which an ingress node may not receive
   a response to its echo request. For example, perhaps because the same DDM
   transit node has failed, or perhaps because the transit node does not
   support LSP Ping, or the Responder Identifier TLV failed to match a
   valid node.

   When no response to an echo request is received by the ingress, then
   as per [RFC4379] the subsequent echo request with a larger TTL SHOULD
   be ignored.

4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms

   Bootstrapping sent.

3.3.7 Use of other OAM procedures can be achieved using Downstream Detailed Mapping TLV in Echo Request

   If no Responder Identifier TLV is being used, then in the
   MPLS Echo Request/Response messages. The LSP(s) under test are
   identified using
   Request packet, the RSVP P2MP IPv4 or IPv6 Session sub-TLVs
   (see Section 3.1.1) or "Downstream IP Address" field, of the Multicast LDP FEC Stack sub-TLV
   (see Section 3.1.2).

   Other sub-TLVs may Downstream
   Detailed Mapping TLV, MUST be defined in other specifications set to indicate the OAM procedures ALLROUTERs multicast
   address.

   If a Responder Identifier TLV is being bootstrapped, and to describe the bootstrap
   parameters. Further details of the bootstrapping processes and used, then the
   bootstrapped OAM processes are described in other documents. For
   example, see [MPLS-BFD] and [MCAST-CV].

5. Echo Request
   packet MAY reuse a received Downstream Detailed Mapping TLV.

4. Non-compliant Routers

   If an egress for a P2MP LSP does not support MPLS LSP ping, then no
   reply will be sent, resulting in a "false negative" result. There is
   no protection for this situation, and operators may wish to ensure
   that end points for P2MP LSPs are all equally capable of supporting
   this function. Alternatively, the traceroute option can be used to
   verify the LSP nearly all the way to the egress, leaving the final
   hop to be verified manually.

   If, in "traceroute" mode, a transit node does not support LSP ping,
   then no reply will be forthcoming from that node for some TTL, say n.
   The node originating the echo request SHOULD continue to send echo
   request with TTL=n+1, n+2, ..., n+k to probe nodes further down the
   path. In such a case, the echo request for TTL > n SHOULD be sent
   with Downstream Detailed Mapping TLV "Downstream IP Address" field
   set to the ALLROUTERs multicast address as described in Section 3.3.4
   until a reply is received with a Downstream Detailed Mapping TLV.

6.

5. OAM 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 must be made.

   - 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 responses 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, it SHOULD provide the
     ability to limit the scope of an LSP Ping echo request for a P2MP
     MPLS LSP to a single egress.

     Such an interface SHOULD also provide the ability to disable all
     active LSP Ping operations to provide a quick escape if the network
     becomes congested.

   - 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.

6. IANA Considerations

7.1.

6.1. New Sub-TLV Types

   Three new sub-TLV types are defined for inclusion within the LSP Ping
   [RFC4379] Target FEC Stack TLV (TLV type 1).

   IANA is requested to assign sub-type values to the following
   sub-TLVs from the "Multiprotocol Label Switching Architecture (MPLS)
   Label Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and
   sub-TLVs" sub-registry.

     RSVP P2MP IPv4 Session (see Section 3.1.1). Suggested value 17.
     RSVP P2MP IPv6 Session (see Section 3.1.1). Suggested value 18.
     Multicast LDP FEC Stack (see Section 3.1.2). Suggested value 19.

7.2. New Multipath Type

   Section 3.3 of [RFC4379] defines a set of values for the LSP Ping
   Multipath Type. These values are currently not tracked by IANA.

   A new value for the LSP Ping Multipath Type is defined in Section
   3.3.5 of this document to indicate that the reported Multipath
   Information applies to a P2MP MPLS TE LSP. for inclusion within the LSP Ping
   [RFC4379] Target FEC Stack TLV (TLV type 1).

   IANA is requested to create a new registry as follows: assign sub-type values to the following
   sub-TLVs from the "Multiprotocol Label Switching Architecture (MPLS)
   Label Switched Paths (LSPs) Parameters - Multipath Types"

   Key   Type                  Multipath Information
   ---   ----------------      ---------------------
     0    no multipath          Empty (Multipath Length = 0)   [RFC4379]
     2    IP address            IP addresses                   [RFC4379]
     4    IP address range      low/high address pairs         [RFC4379]
     8    Bit-masked IP         IP address prefix and bit mask [RFC4379]
            address set
     9    Bit-masked label set  Label prefix TLVs" registry, "TLVs and bit mask      [RFC4379]
    xx
   sub-TLVs" sub-registry.

     RSVP P2MP responder IP     List of IPv4 Session (see Section 3.1.1). Suggested value 17.
     RSVP P2MP responders        [thisDoc]
            addresses

    A suggested IPv6 Session (see Section 3.1.1). Suggested value of xx is 16.

    New values from this registry are to be assigned only by Standards
    Action.

7.3. 18.
     Multicast P2MP LDP FEC Stack (see Section 3.1.2). Suggested value 19.
     Multicast MP2MP LDP FEC Stack (see Section 3.1.2). Suggested value 20.

6.2. New TLVs

   Three

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

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

     P2MP Responder Identifier TLV (see Section 3.2.4) is a mandatory
     TLV. Suggested value 11.

       Two Four sub-TLVs are defined defined.
       - Type 1: IPv4 Egress Address P2MP Responder Identifier (see Section 3.2.4)
       - Type 2: IPv6 Egress Address P2MP Responder Identifier (see Section 3.2.4)

     Echo Jitter TLV (see Section 3.2.5) is a mandatory TLV. Suggested
     value 12.

     Node Properties TLV (see Section 3.2.2.1) is an optional TLV.
     Suggested value 32768.
       Three sub-TLVs are defined
       - Type 1: 3: IPv4 Egress Node Address P2MP Responder Identifier
       - Type 2: 4: IPv6 Egress Node Address
       - Type 3: Branch Properties

7.4. New Return Code

   A new Return Code is defined in Section 3.3.6.1.

   IANA is requested to assign a new Return Code value for the "Multi-
   Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
   Parameters" registry, "Return Codes" sub-registry as follows using a
   Standards Action value.

          Value    Meaning
          -----    -------
           TBD      See DDM TLV for more details

   Suggested value 14.

7.5. New Sub-TLV Value for the Downstream Detailed Mapping TLV

   [DDMT] defines a TLV called the Downstream Detailed Mapping TLV and
   requests IANA to maintain a registry of sub-TLVs that it can carry. P2MP Responder Identifier

     Echo Jitter TLV (see Section 3.3.6.1 of this document defines a new sub-TLV.

   IANA 3.2.5) is requested to assign a TLV type value as follows using a
   Standards Action mandatory TLV. Suggested
     value from the range 0-32767.

        Sub-Type    Value Field
        ---------   ------------
        TBD         Return Code

8. 12.

7. 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 to regulate 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. Note that this rate limiting might lead to
   false positives.

9.

8. 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
   review, and to Yakov Rekhter for useful discussions.

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

10. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.

11.

9.  References

9.1 Normative References

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

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

   [DDMT]      Bahadur, N., Kompella, K., and Swallow, G., "Mechanism
               for Performing LSP-Ping over MPLS Tunnels", draft-ietf-
               mpls-lsp-ping-enhanced-dsmap, work in progress.

12.

9.2 Informative References

   [RFC792]    Postel, J., "Internet Control Message Protocol", RFC 792.

   [RFC4461]   Yasukawa, S., "Signaling Requirements for Point to
               Multipoint Traffic Engineered Multiprotocol Label
               Switching (MPLS) Label Switched Paths (LSPs)",
               RFC 4461, April 2006.

   [RFC4687]   Yasukawa, S., Farrel, A., King, D., and Nadeau, T.,
               "Operations and Management (OAM) Requirements for
               Point-to-Multipoint MPLS Networks", RFC 4687, September
               2006.

   [RFC4875]   Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
               "Extensions to Resource Reservation Protocol - Traffic
               Engineering (RSVP-TE) for Point-to-Multipoint TE Label
               Switched Paths (LSPs)", RFC 4875, May 2007.

   [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for
               point-to-multipoint extensions to the Label Distribution
               Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress.

   [P2MP-LDP]  Minei, I., and Wijnands, I., "Label Distribution Protocol
               Extensions for Point-to-Multipoint and
               Multipoint-to-Multipoint Label Switched Paths",
               draft-ietf-mpls-ldp-p2mp, work in progress.

   [MCAST-CV]  Swallow, G., and Nadeau, T., "Connectivity Verification
               for Multicast Label Switched Paths",
               draft-swallow-mpls-mcast-cv, work in progress.

   [BFD]       Katz, D., and Ward, D., "Bidirectional Forwarding
               Detection", draft-ietf-bfd-base, work in progress.

   [MPLS-BFD]  Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G.,
               "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in
               progress.

   [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org

13.

10. Authors' Addresses

   Seisho Yasukawa
   NTT Corporation
   (R&D Strategy Department)
   3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
   Phone: +81 3 5205 5341
   Email: s.yasukawa@hco.ntt.co.jp

   Adrian Farrel
   Old Dog Consulting
   EMail: adrian@olddog.co.uk

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

   Bill Fenner
   Arastra, Inc.
   275 Middlefield Rd.
   Suite 50
   Menlo Park, CA 94025
   Email: fenner@fenron.com

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

   Thomas D. Nadeau
   British Telecom
   BT Centre
   81 Newgate Street
   EC1A 7AJ
   London
   Email: tom.nadeau@bt.com

14.

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

11. Full Copyright Statement

   Copyright (C) The (c) 2009 IETF Trust (2008). and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, 78 and except as set forth therein, the authors
   retain all their rights.

   This IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. restrictions with respect to this document.