Network Working Group                                     S. Saxena, Ed.
Internet-Draft                                                G. Swallow
Intended Status: Standards Track                                  Z. Ali
Updates: 4379 (if approved)                          Cisco Systems, Inc.
Expires: July 25, 2011                                         A. Farrel
                                                      Old Dog Consulting
                                                             S. Yasukawa
                                                         NTT Corporation
                                                               T. Nadeau
                                                             LucidVision
                                                        January 26, 2011


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

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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with 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".



Saxena, et al.                                                 [Page 1]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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) 2011 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.................................................... 3
   1.1. Design Considerations......................................... 4
   2. Notes on Motivation............................................. 4
   2.1. Basic Motivations for LSP Ping................................ 4
   2.2. Motivations for LSP Ping for P2MP LSPs........................ 5
   3. Packet Format................................................... 7
   3.1. Identifying the LSP Under Test................................ 7
   3.1.1. Identifying a P2MP MPLS TE LSP.............................. 7
   3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 7
   3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV............................ 8
   3.1.2. Identifying a Multicast LDP LSP............................. 8
   3.1.2.1. Multicast LDP FEC Stack Sub-TLVs.......................... 9
   3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 10
   3.2. Limiting the Scope of Responses.............................. 10
   3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 11
   3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 12
   3.3. Preventing Congestion of Echo Responses...................... 12
   3.4. Respond Only If TTL Expired Flag............................. 13
   3.5. Downstream Detailed Mapping TLV.............................. 13
   4. Operation of LSP Ping for a P2MP LSP........................... 14
   4.1. Initiating Router Operations................................. 14
   4.1.1. Limiting Responses to Echo Requests........................ 14
   4.1.2. Jittered Responses to Echo Requests........................ 15
   4.2. Responding Router Operations................................. 15
   4.2.1. Echo Response Reporting.................................... 16
   4.2.1.1. Responses from Transit and Branch nodes.................. 17
   4.2.1.2. Responses from Egress Nodes.............................. 17
   4.2.1.3. Responses from Bud Nodes................................. 18
   4.3. Special Considerations for Traceroute........................ 19
   4.3.1. End of Processing for Traceroutes.......................... 20

Saxena, et al.                                                 [Page 2]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   4.3.2. Multiple responses from Bud and Egress Nodes............... 20
   4.3.3. Non-Response to Traceroute Echo Requests................... 21
   4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 21
   4.3.5 Cross Over Node Processing.................................. 21
   5. Non-compliant Routers.......................................... 22
   6. OAM Considerations............................................. 22
   7. IANA Considerations............................................ 23
   7.1. New Sub-TLV Types............................................ 23
   7.2. New TLVs..................................................... 23
   8. Security Considerations........................................ 24
   9. Acknowledgements............................................... 24
   10. References.................................................... 24
   10.1. Normative References........................................ 24
   10.2. Informative References...................................... 25
   11. Authors' Addresses............................................ 25
   12. Full Copyright Statement...................................... 26


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.

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

Saxena, et al.                                                 [Page 3]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

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


Saxena, et al.                                                 [Page 4]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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.



Saxena, et al.                                                 [Page 5]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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 returns information about the outgoing paths. This
   information can be used by ingress LSR 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 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.  The procedures described in this document
   provide two mechanisms to control echo responses.

   The first procedure allows the responders to randomly delay (or
   jitter) their responses so that the chances of swamping the ingress
   are reduced.  The second procedures 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

Saxena, et al.                                                 [Page 6]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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.


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.



Saxena, et al.                                                 [Page 7]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011


       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

Saxena, et al.                                                 [Page 8]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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 [P2MP-LDP] and so
   provides sufficient information to uniquely identify the LSP.

   The new sub-TLVs are assigned a sub-type identifiers as follows, and
   are 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-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-PORT] that encodes the address family for the Root LSR
      Address.

   Address Length


Saxena, et al.                                                 [Page 9]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

      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 length of
      the Root LSR Address, this field may not be aligned to a word
      boundary.

   Opaque Value

      An opaque value 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 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 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                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Saxena, et al.                                                [Page 10]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

      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.

   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
           3        4    IPv4 Node Address P2MP Responder Identifier
           4       16    IPv6 Node Address P2MP Responder Identifier

   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 Identifier Sub-TLVs

   The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs
   MAY be used in an echo request carrying RSVP P2MP Session Sub-TLV.
   They SHOULD NOT be used with an echo request carrying Multicast LDP
   FEC Stack Sub-TLV. If a node receives these TLVs in an echo request
   carrying Multicast LDP then it SHOULD ignore these sub-TLVs and
   respond as if they are not present. Hence these TLVs cannot be used
   to traceroute to a single node when Multicast LDP FEC is used.

   A node that receives an echo request with this Sub-TLV present MUST
   respond only if the node lies on the path to the address in the
   Sub-TLV.

   The address in this Sub-TLV SHOULD be of an egress or bud node and
   SHOULD NOT be of a transit or branch node.  A transit or branch node,
   should be able to determine if the address in this Sub-TLV is for an
   egress or bud node which is reachable through it.  Hence, this
   address SHOULD be known to the nodes upstream of the target node, for
   instance via control plane signaling.  As a case in point, if RSVP-TE
   is used to signal the P2MP LSP, this address SHOULD be the address

Saxena, et al.                                                [Page 11]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   used in destination address field of the S2L_SUB_LSP object, when
   corresponding egress or bud node is signaled.


3.2.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 that receives an echo request with this Sub-TLV present MUST
   respond only if the address in the Sub-TLV corresponds to any address
   that is local to the node.  This 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.


3.3. Preventing Congestion of Echo Responses

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

   The Echo Jitter 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 (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 response.  A responding node SHOULD
        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 response message, it SHOULD be ignored.




Saxena, et al.                                                [Page 12]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

3.4. Respond Only If TTL Expired Flag

   A new flag is being introduced in the Global Flags field.  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].

   The T (Respond Only If TTL Expired) flag SHOULD be set only in the
   echo request packet by the sender.  This flag SHOULD 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 receiver SHOULD reply as per
   regular processing.

   If the T flag is set to 1, then the receiver SHOULD reply only if the
   TTL of the incoming MPLS label is equal to 1; if the TTL is more than
   1, then no response should be sent back.

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


3.5. Downstream Detailed Mapping TLV

  Downstream Detailed Mapping TLV is described in [DDMT].  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 4.3 of [DDMT], the Downstream Mapping TLV as described in
  [RFC4379] is being deprecated.

  Therefore for P2MP, a node MUST support Downstream Detailed Mapping
  TLV.  The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP
  traceroute functionality and SHOULD 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.


Saxena, et al.                                                [Page 13]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

  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 existing LSP Ping mechanism in [RFC4379] rather than invent
   new mechanisms.

   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 Router Operations

   The router 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-TLV in the P2MP
   Responder Identifier TLV: Node Address sub-TLV and Egress Address
   sub-TLV.

   These sub-TLVs limit the responses either to the specified router
   only or to any router on the path to the specified router.  The
   former capability is generally useful for ping mode, while the latter
   is more suited to traceroute mode.  An initiating router may indicate

Saxena, et al.                                                [Page 14]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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 router MAY request the responding routers 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 P2MP LSP is being pinged or traced since it
   helps prevent the initiating (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 initiating rotuer 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 router can supply the desired value of the jitter in
   the Echo Jitter TLV as defined section 3.3.  If this TLV is present,
   the responding router MUST delay sending a response 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.

   LSP ping SHOULD 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 response is often sent back through the control plane.
   The timestamp fields in the echo request and echo response packets
   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 node MUST set the value in
   the Timestamp Received fields before applying any delay.

   Echo response jittering SHOULD be used for P2MP LSPs.  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 Router 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

Saxena, et al.                                                [Page 15]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   request will be passed on to control plane for reply processing.

   The operations at the receiving node are an extenstion to the
   existing processing as specified in [RFC4379].  A responding router
   is RECOMMENDED to rate limit its receipt of echo request messages.
   After rate limiting, the responding router must verify 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 response is required
   or not (and the mechanism to send it back).

   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
   router 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
        the echo request is directed to it or not.

         - If a P2MP Responder Identifier TLV is present, then the node
           must follow the procedures defined in section 3.2 to
           determine whether it should respond to the reqeust or not.
           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 Response Reporting

   Echo response 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 response applies only to the reporting node.
   Similarly, when a node reports that it does not form part of the LSP
   described by the FEC (i.e. there is a misconnection) then the echo
   response applies to the reporting node.

   However, it should be noted that an echo response message that
   reports an error from a transit node may apply to multiple egress

Saxena, et al.                                                [Page 16]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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 also that a transit node may discover an error but 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 response.

   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 response is being sent
   back.  As mentioned previously, the Return Code might change based on
   the presence of 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, which MAY be set to value 8 ('Label
   switched at stack-depth <RSC>') or any other error value as needed.

   The presence of a Downstream Detailed Mapping TLV will influence the
   choice of Return Code.  As per [DDMT], the Return Code in the echo
   response header MAY be set to value TBD ('See DDM TLV for Return Code
   and Return SubCode') as defined in [DDMT].  The Return Code for each
   Downstream Detailed Mapping TLV will depend on the downstream path as
   described in [DDMT].

   There will be a Downstream Detailed Mapping TLV for each downstream
   path being reported in the echo response.  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 Identifier
   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, which MAY be set to value 3 ('Replying
   router is an egress for the FEC at stack-depth <RSC>') or any other
   error value as needed.



Saxena, et al.                                                [Page 17]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

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


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
   determined by the presence of any Responder Identifier TLV and the
   type of sub-TLV in it.  Similarly Downstream Detailed Mapping TLV can
   influence the Return Code values.

   To determine the behavior of the bud node, use the following
   guidelines.  The intent of these guidelines 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 response will be
   sent back.

   Node behavior guidelines:

      - If the Responder Identifier TLV is not present, then the node
        will behave as a combination 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 an combination
           egress and branch node.

         - If the address specified in the sub-TLV does not match any
           address in the node, then no response 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.


Saxena, et al.                                                [Page 18]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

         - If the node does not lie on the path to the address specified
           in the sub-TLV, then no response 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 the Return
        Code MAY be set to value 3 ('Replying router is an egress for
        the FEC at stack-depth <RSC>') or any other error value as
        needed.  The echo response 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
             the Return Code MAY be set to value 8 ('Label switched at
             stack-depth <RSC>') or any other error value as needed.

           - If a Downstream Detailed Mapping TLV is present, then the
             Return Code MAY be set to value TBD ('See DDM TLV for
             Return Code and Return SubCode') as defined in [DDMT].  The
             Return Code for the Downstream Detailed Mapping TLV will
             depend on the downstream path as described in [DDMT].
             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 egress and branch node,
        and:

           - If a Downstream Detailed Mapping TLV is not present, then
             the Return Code MAY be set to value 3 ('Replying router is
             an egress for the FEC at stack-depth <RSC>') or any other
             error value as needed.

           - If a Downstream Detailed Mapping TLV is present, then the
             Return Code MAY be set to value 3 ('Replying router is an
             egress for the FEC at stack-depth <RSC>') or any other
             error value as needed.  Return Code for the each Downstream
             Detailed Mapping TLV will depend on the downstream path as
             described in [DDMT].  There will be a Downstream Detailed
             Mapping for each downstream path from the node.


4.3. Special Considerations for Traceroute


Saxena, et al.                                                [Page 19]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

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 response is
   received from the intended egress or when some errored return code is
   received.

   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 response from an egress will not signal the end of
   processing.

   In P2MP TE LSP, the initiating router has a priori knowledge about
   number of egress nodes and their addresses.  Hence it possible to
   continue processing till a valid response has been received from each
   end-point, provided the responses can be matched correctly to the
   egress nodes.

   However in Multicast LDP LSPs, the initiating router has no knowledge
   about the egress nodes.  Hence it is not possible to estimate the end
   of processing for traceroute in such scenarios.

   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
   response 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 extra processing burden for
   the initiating router and these bud or egress routers.

   To prevent a bud or egress node from sending multiple responses 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 responses 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 scenario.


Saxena, et al.                                                [Page 20]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011


4.3.3. 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, the transit node has
   failed, or the transit node does not support LSP Ping.

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


4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request

   As described in section 4.6 of [RFC4379], an initiating router,
   during traceroute, SHOULD copy the Downstream Mapping(s) into its
   next echo request(s).  However for P2MP LSPs, the intiating router
   will receive multiple sets of Downstream Detailed Mapping TLV 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.  In the echo request packet, the "Downstream IP Address" field,
   of the Downstream Detailed Mapping TLV, SHOULD be set to the
   ALLROUTERS multicast address.

   If an Egress Address Responder Identifier sub-TLV is being used, then
   the traceroute is limited to only one path to one egress.  Therefore
   this traceroute is effectively behaving like a P2P traceroute.  In
   this scenario, as per section 4.2, the echo responses 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.


4.3.5 Cross Over Node Processing

   A cross-over nodes 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.



Saxena, et al.                                                [Page 21]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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 response SHOULD carry information only about
   the outgoing interface corresponding to the input interface.

   Due to this restriction, 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, resulting in a "false negative" result.  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 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.

Saxena, et al.                                                [Page 22]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011


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

   [Note - to be removed before publication.] The values suggested in
   this section have already been assigned using the IANA early
   allocation process [RFC4020].

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 is requested to assign sub-type values to the following sub-TLVs
   under TLV type 1 (Target FEC Stack) from the "Multiprotocol Label
   Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters
   - TLVs" registry, "TLVs and sub-TLVs" sub-registry.

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


7.2. New TLVs

   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) is a mandatory
     TLV.  Suggested value 11.
     Four sub-TLVs are defined.
       - Type 1: IPv4 Egress Address P2MP Responder Identifier

Saxena, et al.                                                [Page 23]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

       - Type 2: IPv6 Egress Address P2MP Responder Identifier
       - Type 3: IPv4 Node Address P2MP Responder Identifier
       - Type 4: IPv6 Node Address P2MP Responder Identifier


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


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


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



Saxena, et al.                                                [Page 24]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

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

   [RFC5884]   Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G.,
               "Bidirectional Forwarding Detection (BFD) for MPLS Label
               Switched Paths (LSPs)", RFC 5884, June 2010

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

   [RFC4020]   Kompella, K., Zinin, A., "Early Allocation of Standard
               Code Points", RFC 4020, February 2005.


11. 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: yasukawa.seisho@lab.ntt.co.jp

   Adrian Farrel
   Old Dog Consulting

Saxena, et al.                                                [Page 25]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   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

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

   Thomas D. Nadeau
   Email: tnadeau@lucidvision.com

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


12. Full Copyright Statement

   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

Saxena, et al.                                                [Page 26]


Internet Draft     draft-ietf-mpls-p2mp-lsp-ping-15.txt     January 2011

   it for publication as an RFC or to translate it into languages other
   than English.
















































Saxena, et al.                                                [Page 27]