Network Working Group                                    Seisho Yasukawa
IETF Internet Draft                                                  NTT
Proposed Status: Informational
Expires: April 2005
                                                           Adrian Farrel
                                                       Olddog Consulting

                                                               Zafar Ali
                                                           Cisco Systems

                                                            October 2004


     Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic
                  Engineering - Extensions to LSP Ping

               draft-yasukawa-mpls-p2mp-lsp-ping-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

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

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


Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.






Yasukawa, Farrel and Ali.                                       [Page 1]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


Abstract

   Recent proposals have extended the scope of Multi-Protocol Label
   Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs)
   to encompass point-to-multipoint (P2MP) TE 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"
   [LSP-PING].

   This documents does not replace any of the mechanism of LSP Ping, but
   clarifies their applicability to P2MP MPLS TE LSPs, and extends the
   techniques and mechanisms of LSP Ping to the P2MP TE
   environment.

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





























Yasukawa, Farrel and Ali.                                       [Page 2]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


Contents

   1. Introduction .................................................. 04
      1.1 Design Considerations ..................................... 04
   2. Notes on Motivation ........................................... 05
      2.1. Basic Motivations for LSP Ping ........................... 05
      2.2. Motivations for LSP Ping for P2MP TE LSPs ................ 05
   3. Operation of LSP Ping for a P2MP TE LSP ....................... 07
      3.1. Identifying the LSP Under Test ........................... 07
      3.1.1. RSVP P2MP IPv4 Session Sub-TLV ......................... 07
      3.1.2. RSVP P2MP IPv6 Session Sub-TLV ......................... 08
      3.2. Ping Mode Operation ...................................... 09
      3.2.1. Controlling Responses to LSP Pings ..................... 09
      3.2.2. P2MP Egress Identifier sub-TLVs ........................ 10
      3.3. Traceroute Mode Operation ................................ 10
      3.3.1. Traceroute Responses at Non-Branch Nodes ............... 11
      3.3.2.  Traceroute Responses at Branch Nodes .................. 11
      3.3.3. Traceroute Responses at Bud Nodes ...................... 12
      3.3.4. Non-Response to Traceroute Echo Requests ............... 12
      3.3.5. Modifications to the Downstream Mapping TLV ............ 13
      3.3.6. Additions to Downstream Mapping Multipath Information .. 14
   4. OAM Considerations ............................................ 15
   5. IANA Considerations ........................................... 16
      5.1. New Sub TLV Types ........................................ 16
   6. Security Considerations ....................................... 16
   7. Acknowledgements .............................................. 16
   8. Intellectual Property Considerations .......................... 16
   9. Normative References .......................................... 17
   10. Informational References ..................................... 17
   11. Authors' Addresses ........................................... 18
   12. Full Copyright Statement ..................................... 18




















Yasukawa, Farrel and Ali.                                       [Page 3]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


1. Introduction

   Simple and efficient mechanisms that can be used to detect data plane
   failures in point-to-point MPLS LSP are described in [LSP-PING]. 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 reply channels for echo request messages
   as described in [LSP-PING] enables more robust fault isolation. This
   collection of mechanisms is commonly referred to as "LSP Ping".

   The requirement for Point-to-multipoint traffic engineered MPLS LSPs
   is introduced in [P2MP-REQ]. [P2MP-RSVP] specifies a signaling
   solution for establishing P2MP MPLS TE LSPs. P2MP MPLS TE LSPs are at
   least as vulnerable to data plane faults or to discrepancies between
   the control and data planes as their P2P counterparts. LSP Ping
   Mechanisms are, therefore, also desirable to detect such data plane
   faults in P2MP MPLS TE LSPs.

   This document extends the techniques described in [LSP-PING] in order
   that they may be applied to P2MP MPLS TE LSPs. This document stresses
   the reuse of existing LSP Ping mechanisms as such reuse simplifies
   operations of the network.

1.1 Design Considerations

   As mentioned earlier, an important consideration for designing LSP
   Ping for P2MP MPLS TE 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 would
   traverse. However, it can be seen this notion needs to be extended
   for P2MP MPLS TE 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 secondarily to verify the data plane against the control plane.
   As pointed out in [LSP-PING], mechanisms to check the liveness,
   function and consistency of the control plane are valuable, but such
   mechanisms are not covered in this document.

   As is described in [LSP-PING], 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.



Yasukawa, Farrel and Ali.                                       [Page 4]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


2. Notes on Motivation

2.1. Basic Motivations for LSP Ping

   The motivations listed in [LSP-PING] 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 would enable users to detect such traffic "black holes" or
   misrouting within a reasonable period of time; and a mechanism to
   isolate faults.

   [LSP-PING] 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. [LSP-PING] specifies a "ping mode" and a "traceroute" mode
   for testing MPLS LSPs.

   The basic idea as expressed in [LSP-PING] 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. [LSP-PING] 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 thus should be used with caution.







Yasukawa, Farrel and Ali.                                       [Page 5]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


2.2. Motivations for LSP Ping for P2MP TE LSPs

   P2MP MPLS TE LSPs may be viewed as MPLS tunnels with a single ingress
   and multiple egresses. MPLS packets inserted at the ingress are
   delivered equally (barring faults) to all egresses. There is no
   concept or applicability of an FEC in the context of a P2MP MPLS TE
   LSP, just as there is no similar concept for point-to-point TE LSPs.

   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 MPLS TE LSP actually end their MPLS path
   on LSRs that are (intended) egresses for that LSP. The idea may be
   extended to check selectively that such packets reach a specific
   egress, or a particular group of egresses of the LSP.

   This document proposes that this test is carried out 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 TE LSP that it is testing. The echo request is forwarded just as
   any other packet using that LSP. 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 LSR, which then
   verifies that it is indeed an egress (leaf) of the P2MP MPLS TE LSP.
   An echo response message is sent by the 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 TE 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 TE 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 TE
   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 the ability for the initiator to limit the scope of
   an LSP Ping (ping or traceroute mode) to one or a limited list of the
   intended egresses of the P2MP MPLS TE LSP.





Yasukawa, Farrel and Ali.                                       [Page 6]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


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

3. Operation of LSP Ping for a P2MP TE LSP

   This section describes how LSP Ping is applied to P2MP MPLS TE 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 LSRs and receivers (egresses).

3.1. Identifying the LSP Under Test

   [LSP-PING] 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 or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry
   the various fields from the RSVP-TE P2MP Session and Sender-Template
   objects [P2MP-RSVP] 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. 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 [P2MP-RSVP]. Note that the Sub-Group
   ID of the Sender-Template is not required.






Yasukawa, Farrel and Ali.                                       [Page 7]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


       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.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 [P2MP-RSVP]. 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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+










Yasukawa, Farrel and Ali.                                       [Page 8]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


3.2. Ping Mode Operation

3.2.1. Controlling Responses to LSP Pings

   As described above, 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 is identified in the FEC
   Stack TLV by the inclusion of an IPv4 P2MP Egress Identifier sub-TLV
   or an IPv6 P2MP Egress Identifier sub-TLV. Such TLVs MUST be placed
   after the RSVP P2MP IPv4/6 Session sub-TLV.

   An egress LSR that receives an echo request carrying an RSVP P2MP
   IPv4/6 Session sub-TLV MUST determine whether it is an intended
   egress of the P2MP LSP in question by checking with the control
   plane. If it 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 [LSP-PING].

   If the egress that receives an echo request is an intended egress,
   the LSR can check to see whether it is an intended Ping recipient.
   If the address included in the P2MP Egress Identifier sub-TLV
   indicates any address that is local to the egress LSR it, MUST
   respond according to the setting of the Response Type field in the
   echo message following the rules defined in [LSP-PING]. If the
   address in the P2MP Egress Identifier sub-TLV does not identify the
   egress LSR, it MUST NOT respond to the echo request.

   Multiple P2MP Egress Identifier sub-TLVs may appear in a list after
   the RSVP P2MP IPv4/6 Session sub-TLV. In this case, each identifies a
   single egress that is intended to reply to the echo request according
   to the setting in the Reply Type field. An egress SHOULD consider
   itself a target of the echo request if any of its local addresses
   matches any of the specified egress identifiers.

   An initiator may indicate that it wishes all egresses to respond to
   an echo request by omitting all P2MP Egress Identifier sub-TLVs.










Yasukawa, Farrel and Ali.                                       [Page 9]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


3.2.2. P2MP Egress Identifier sub-TLVs

   Two new sub-TLVs are defined for inclusion in the Target FEC Stack
   TLV (type 1) carried on the echo request message. These are:

      Sub-Type #       Length              Value Field
      ----------       ------              -----------
          (TBD)             4              IPv4 P2MP Egress Identifier
          (TBD)            16              IPv6 P2MP Egress Identifier

   The value of an IPv4 P2MP Egress Identifier consists of four octets
   of an IPv4 address. The IPv4 address is in network byte order.

   The value of an IPv6 P2MP Egress Identifier consists of sixteen
   octets of an IPv6 address. The IPv6 address is in network byte order.

3.3. Traceroute Mode Operation

   The traceroute mode of operation is described in [LSP-PING]. Like
   other traceroute operations, it relies on the expiration of the TTL
   of the packet that carries the echo request. Echo requests may
   include a Downstream Mapping TLV and when the TTL expires the echo
   request is passed to the control plane on the transit LSR which
   responds according to the Response Type in the message. A responding
   LSR fills in the fields of the Downstream Mapping TLV to indicate the
   downstream interfaces and labels used by the reported LSP from the
   responding LSR. In this way, by successively sending out echo
   requests with increasing TTLs, the ingress may gain a picture of the
   path and resources used by an LSP up to the point of failure when no
   response is received, or an error response is generated by an LSR
   where the control plane does not expect to be handling the LSP.

   This mode of operation is equally applicable to P2MP MPLS TE LSPs
   as described in the following sections.

   The traceroute mode can be applied to a single destination, a set of
   destinations, or to all destinations of the P2MP tree just as in the
   ping mode. That is, the IPv4/6 P2MP Egress Identifier sub-TLVs may
   be used to identify one or more egresses for which traceroute
   information is requested. In the absence of an IPv4/6 P2MP Egress
   Identifier sub-TLV, the echo request is asking for traceroute
   information applicable to all egresses.









Yasukawa, Farrel and Ali.                                      [Page 10]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


3.3.1. Traceroute Responses at Non-Branch Nodes

   When the TTL for the MPLS packet carrying an echo request expires and
   the message is passed to the control plane, an echo response MUST
   only be returned if the responding LSR lies on the path to one or
   more of the egresses identified by the IPv4/6 P2MP Egress Identifiers
   carried on the request, or if not such sub-TLV is present.

   The echo response identifies the next hop of the path in the data
   plane by including a Downstream Mapping TLV as described in
   [LSP-PING].

   When traceroute is being simultaneously applied to multiple egresses,
   it is important that the ingress should be able to correlate the echo
   responses with the branches in the P2MP tree. Without this
   information the ingress will be unable to determine the correct
   ordering of transit nodes. One possibility is for the ingress to poll
   the path to each egress in turn, but this may be inefficient or
   undesirable. Therefore, the echo response contains additional
   information in the Multipath Information field of the Downstream
   Mapping TLV that identifies to which egress/egresses the echo
   response applies. This information MUST be present when the echo
   request applies to more than one egress, and is RECOMMENDED to be
   present even when the echo request is limited to a single egress.

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

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 egresses that are being
   traced lie on different branches. This would always be the case for
   any branch node if all egresses are being traced.

   [LSP-PING] 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.

   Just as with non-branches, it is important that the echo responses
   provide correlation information that will allow the ingress to work
   out to which branch of the LSP the response applies. Further, when
   multiple downstream interfaces are identified, it is necessary to
   indicate which egresses are reached through which branches. This is
   achieved exactly as for non-branch nodes: that is, by including a
   list of egresses as part of the Multipath Information field of the
   appropriate Downstream Mapping TLV.




Yasukawa, Farrel and Ali.                                      [Page 11]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


   Note also that a branch node may sometimes only need to respond with
   a single Downstream Mapping TLV. Consider the case where the
   traceroute is directed to only a single egress node, or where a
   subset of the egresses are being traced, but where all of them are
   reached through the same branch. Therefore, the presence of only one
   Downstream Mapping TLV in an echo response does not guarantee that
   the reporting LSR is not a branch node.

   To report on the fact that an LSR is a branch node for the MPLS P2MP
   TE LSP, a new B-flag is added to the Downstream Mapping TLV to
   indicate that the reporting LSR is not a branch for this LSP (set to
   zero) or is a branch (set to one). The flag is placed in the fourth
   byte of the TLV that was previous reserved.

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

3.3.3. Traceroute Responses at Bud Nodes

   Some nodes on an MPLS P2MP TE LSP may be egresses, but also have
   downstream LSRs. Such LSRs are known as bud nodes.

   A bud node will respond to a traceroute echo request just as a branch
   node would, but it is also important that it indicates to the ingress
   that it is an egress in its own right. This is achieved through the
   use of a new E-flag in the Downstream Mapping TLV that indicates that
   the reporting LSR is not a bud for this LSP (set to zero) or is a bud
   (set to one). A normal egress is not required to set this flag.
   The flag is placed in the fourth byte of the TLV that was previous
   reserved.

3.3.4. Non-Response to Traceroute Echo Requests

   The nature of MPLS P2MP TE LSPs in the data plane mean that
   traceroute echo requests may be delivered to the control plane of
   LSRs that must not reply to the request because, although they lie
   on the P2MP tree, they do not lie on the paths to the egresses that
   are being traced.

   Thus, an LSR on a P2MP MPLS TE LSP MUST NOT respond to an echo
   request for which the TTL has expired if any of the following
   applies:
   - The Reply Type indicates that no reply is required
   - There is one or more IPv4/6 P2MP Egress Identifiers present on the
     echo request and none of the addresses identifies an egress that is
     reached, for this particular MPLS P2MP TE LSP, through this LSR.





Yasukawa, Farrel and Ali.                                      [Page 12]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


3.3.5. Modifications to the Downstream Mapping TLV

   A new B-flag is added to the Downstream Mapping TLV to indicate that
   the reporting LSR is not a branch for this LSP (set to zero) or is a
   branch (set to one).

   A new E-flag is added to the Downstream Mapping TLV to indicate that
   the reporting LSR is not a bud node for this LSP (set to zero) or is
   a bud node (set to one).

   The flags are placed in the fourth byte of the TLV that was
   previously reserved as shown below. All other fields are unchanged
   from their definitions in [LSP-PING] except for the additional
   information that can be carried in the Multipath Information.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               MTU             | Address Type  | Resvd     |E|B|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Downstream IP Address (4 or 16 octets)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Downstream Interface Address (4 or 16 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Hash Key Type | Depth Limit   |        Multipath Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                     (Multipath Information)                   .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Downstream Label                |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Downstream Label                |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+













Yasukawa, Farrel and Ali.                                      [Page 13]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


3.3.6. Additions to Downstream Mapping Multipath Information

      A new value for the Hash Key Type is defined to indicate that the
      reported Multipath Information applies to an MPLS P2MP TE LSP and
      may contain a list of egress identifiers that indicate the egress
      nodes that can be reached through the reported interface.

      Key   Type                  Multipath Information
      ---   ----------------      ---------------------
      TBD   P2MP egresses         List of P2MP egresses

      Note that a list of egresses may include IPv4 and IPv6 identifiers
      since these may be mixed in the MPLS P2MP TE LSP.

      The Multipath Length field continues to identify the length of the
      Multipath Information just as in [LSP-PING] (that is not including
      the downstream labels), and the downstream label (or potential
      stack thereof) is also handled just as in [LSP-PING]. The format
      of the Multipath Information for a Hash Key Type of P2MP Egresses
      is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Address Type  |   Egress Address  (4 or 16 octets)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | (continued)   |                                               :
      +-+-+-+-+-+-+-+-+                                               :
      :                 Further Address Types and Egress Addresses    :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Address Type

        This field indicates whether the egress address that follows is
        an IPv4 or IPv6 address, and so implicitly encodes the length of
        the address.

        Two values are defined and mirror the values used in the Address
        Type field of the Downstream Mapping TLV itself.

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






Yasukawa, Farrel and Ali.                                      [Page 14]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


      Egress Address

        An egress of this MPLS P2MP TE LSP that is reached through the
        interface indicated by the Downstream Mapping TLV and for which
        the traceroute echo request was enquiring.


4. OAM Considerations

   This draft clearly facilitates OAM procedures for P2MP MPLS TE LSPs.

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
















Yasukawa, Farrel and Ali.                                      [Page 15]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


5. IANA Considerations

5.1. New Sub TLV Types

   Four new sub-TLV types are defined for inclusion within the Target
   FEC Stack TLV (TLV type 1).

   IANA is requested to assign sub-type values to the following
   sub-TLVs.

     RSVP P2MP IPv4 Session (see section 3.1)
     RSVP P2MP IPv6 Session (see section 3.1)
     IPv4 P2MP Egress Identifier (see section 3.2.2)
     IPv6 P2MP Egress Identifier (see section 3.2.2)


6. Security Considerations

   This document does not introduce security concerns over and above
   those described in [LSP-PING]. Note that because of the scalability
   implications of many egresses to P2MP MPLS TE 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.

7. Acknowledgements

   The authors would like to acknowledge the authors of [LSP-PING] for
   their work which is substantially re-used in this document.

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




Yasukawa, Farrel and Ali.                                      [Page 16]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


   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.


9. Normative References

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

   [RFC3667]   Bradner, S., "IETF Rights in Contributions", BCP 78,
               RFC 3667, February 2004.

   [RFC3668]   Bradner, S., Ed., "Intellectual Property Rights in IETF
               Technology", BCP 79, RFC 3668, February 2004.

   [LSP-PING]  Kompella, K., and Swallow, G., (Editors), "Detecting
               MPLS Data Plane Failures", draft-ietf-mpls-lsp-ping,
               work in progress.

10. Informational References

   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
               October 1998.

   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
               Tunnels", RFC 3209, December 2001.

   [RFC3552]   Rescorla E. and B. Korver, "Guidelines for Writing RFC
               Text on Security Considerations", BCP: 72, RFC 3552,
               July 2003.

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

   [P2MP-REQ]  S. Yasukawa, et. al., "Requirements for Point to
               Multipoint Traffic Engineered MPLS LSPs",
               draft-ietf-mpls-p2mp-requirement, work in progress.

   [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to
               Multipoint TE LSPs", draft-raggarwa-mpls-rsvp-te-p2mp,
               work in progress.






Yasukawa, Farrel and Ali.                                      [Page 17]


Internet Draft  draft-yasukawa-mpls-p2mp-lsp-ping-00.txt    October 2004


11. Authors' Addresses

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

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

   Zafar Ali
   Cisco Systems Inc.
   100 South Main St. #200
   Ann Arbor, MI 48104, USA.
   Phone: (734) 276-2459
   Email: zali@cisco.com

12. Full Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

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

















Yasukawa, Farrel and Ali.                                      [Page 18]