Network Working Group
A. Farrel (Editor)S. Saxena, Ed. Internet-Draft Old Dog ConsultingCisco Systems, Inc. Intended Status: Standards Track S. YasukawaA. Farrel Updates: RFC4379 NTTOld Dog Consulting Created: August 11,December 14, 2009 S. Yasukawa Expires: February 11,June 14, 2010 NTT Corporation Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping draft-ietf-mpls-p2mp-lsp-ping-08.txtdraft-ietf-mpls-p2mp-lsp-ping-09.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". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Contents 1. Introduction.................................................... 4 1.1 Design Considerations..........................................Introduction.................................................. 5 1.1. Design Considerations....................................... 6 2. Notes on Motivation.............................................Motivation........................................... 6 2.1. Basic Motivations for LSP Ping................................Ping.............................. 6 2.2. Motivations for LSP Ping for P2MP LSPs........................ 6 2.3LSPs...................... 7 2.3. Bootstrapping Other OAM Procedures Using LSP Ping.............. 8Ping........... 9 3. Operation of LSP Ping for a P2MP LSP............................ 8Packet Format................................................. 9 3.1. Identifying the LSP Under Test................................Test.............................. 9 3.1.1. Identifying a P2MP MPLS TE LSP..............................LSP............................ 9 126.96.36.199. RSVP P2MP IPv4 Session Sub-TLV............................ 9Sub-TLV......................... 10 188.8.131.52. RSVP P2MP IPv6 Session Sub-TLV............................ 9Sub-TLV......................... 10 3.1.2. Identifying a Multicast LDP LSP............................ 10LSP.......................... 11 184.108.40.206. Multicast LDP FEC Stack Sub-TLVs......................... 10Sub-TLVs....................... 11 220.127.116.11. Applicability to Multipoint-to-Multipoint LSPs........... 11 3.2. Ping Mode Operation.......................................... 12 3.2.1. Controlling Responses to LSP Pings.........................LSPs......... 12 3.2.2. Ping Mode Egress Procedures................................ 12 3.2.3. Jittered Responses......................................... 12 3.2.4. P2MP Responder Identifier TLV and Sub-TLVs.................3.2. Limiting the Scope of Responses............................ 13 18.104.22.168.3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs........ 14 22.214.171.124.3.2.2. Node Address P2MP Responder Identifier Sub-TLVs.......... 14 126.96.36.199.3. Preventing Congestion of Echo Jitter TLV............................................Responses.................... 14 3.4. Respond Only If TTL Expired Flag........................... 15 3.2.6. Echo Response Reporting....................................3.5. Downstream Detailed Mapping TLV............................ 15 188.8.131.52. Operation of LSP Ping Responses at Transit and Branch Nodes................for a P2MP LSP......................... 16 184.108.40.206 Ping Responses at Egress and Bud Nodes....................4.1. Initiating Router Operations............................... 16 3.3. Traceroute Mode Operation....................................4.1.1. Limiting Responses to Echo Requests...................... 16 3.3.1. Correlating Traceroute Responses........................... 17 3.3.2. Traceroute4.1.2. Jittered Responses at Transit Nodes......................to Echo Requests...................... 17 4.2. Responding Router Operations............................... 18 3.3.3. Traceroute4.2.1. Echo Response Reporting.................................. 19 220.127.116.11. Responses atfrom Transit and Branch Nodes....................... 18 3.3.4. Traceroutenodes................ 19 18.104.22.168. Responses atfrom Egress Nodes....................... 19 3.3.5. TracerouteNodes............................ 20 22.214.171.124. Responses atfrom Bud Nodes.......................... 19 3.3.6.Nodes............................... 20 4.3. Special Considerations for Traceroute...................... 22 4.3.1. End of Processing for Traceroutes........................ 22 4.3.2. Multiple responses from Bud and Egress Nodes............. 22 4.3.3. Non-Response to Traceroute Echo Requests................... 20 3.3.7Requests................. 23 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request...... 20 4. Non-compliant Routers.......................................... 20Request... 23 5. OAM Considerations............................................. 20Non-compliant Routers........................................ 23 6. OAM Considerations........................................... 24 7. IANA Considerations............................................ 21 6.1.Considerations.......................................... 24 7.1. New Sub-TLV Types............................................ 21 6.2.Types.......................................... 25 7.2. New TLVs..................................................... 21 7. Security Considerations........................................ 22TLVs................................................... 25 8. Acknowledgements............................................... 22Security Considerations...................................... 25 9. References..................................................... 23 9.1Acknowledgements............................................. 25 10. References.................................................. 26 10.1. Normative References.......................................... 23 9.2References...................................... 26 10.2. Informative References........................................ 23 10. Authors' Addresses............................................ 24References.................................... 26 11. Authors' Addresses.......................................... 27 12. Full Copyright Statement...................................... 25Statement.................................... 28 0. Change Log This section to be removed before publication as an RFC. 0.1 Changes from 00 to 01 - Update references. - Fix boilerplate. 0.2 Changes from 01 to 02 - Update entire document so that it is not specific to MPLS-TE, but also includes multicast LDP LSPs. - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new egress identifier TLV. - Include Multicast LDP FEC Stack sub-TLV definition from [MCAST-CV]. - Add brief section on use of LSP Ping for bootstrapping. - Add new references to References section. - Add details of two new authors. 0.3 Changes from 02 to 03 - Update references. - Update boilerplate. - Fix typos. - Clarify in 3.2.2 that a recipient of an echo request must reply only once it has applied incoming rate limiting. - Tidy references to bootstrapping for [MCAST-CV] in 1.1. - Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4. - Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs in sections 3.2.1 and 3.2.2. 0.4 Changes from 03 to 04 - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4 with respect to multiple sub-TLVs in the P2MP Egress Identifier TLV. 0.5 Changes from 04 to 05 - Change coordinates for Tom Nadeau. Section 13. - Fix typos. - Update references. - Resolve all acronym expansions. 0.6 Changes from 05 to 06 - New section, 3.2.6, to explain echo response reporting in the Ping case. - New section, 3.3.7, to explain echo response reporting in the Traceroute case. - Sections 3.3.2, 3.3.5, and 5. Retire the E-flag for identification of bud nodes. Use the B-flag in a Downstream Mapping TLV with a zero address to provide the necessary indication. - Section 3.3.4. Note the use of ALLROUTERS address as per RFC 4379 - Section 7. Suggest values for IANA assignment. - Rename "P2MP Responder Identifier TLV" to "P2MP Responder Identifier TLV", "Egress Identifier sub-TLV" to "Responder Identifier sub-TLV", and "P2MP egresses" multipath type to "P2MP responder". This allows any LSR on the P2MP LSP to be the target of, or responder to, an echo request. 0.7 Changes from 06 to 07 - Sections 3.3.2 and 3.3.3. Delete section 3.3.5. New sections 126.96.36.199 through 188.8.131.52: Retire B-flag from Downstream Mapping TLV. Introduce new Node Properties TLV with Branching Properties and Egress Address sub-TLVs. - Section 184.108.40.206: Clarify rules on presence of Multipath Information in Downstream Mapping TLVs. - Section 3.3.5: Clarify padding rules. - Section 3.3.6: Updated to use Downstream Detailed Mapping TLVs for multiple return conditions reported by a single echo response. - Section 7: Update IANA values and add new sub-sections. - Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap. - Section 13: Update Bill Fenner's coordinates. 0.8 Changes from 07 to 08 - Removed the Node Properties TLV (Section 220.127.116.11 of version 07). - Removed the New Multipath Type from Multipath Sub-TLV (Section 3.3.5 of version 07). - Removed the Return Code Sub-TLV from Downstream Detailed TLV (Section 18.104.22.168 of version 07), as it is already included in draft-ietf-mpls-lsp-ping-enhanced-dsmap-02. - Clarified the behavior of Responder Identifier TLV (Section 3.2.4 of version 07). Two new Sub-TLVs are introduced. - Downstream Detailed Mapping TLV is now mandatory for implementing P2MP OAM functionality. - Split Multicast LDP TLV into two TLVs, one for P2MP and other for MP2MP. Also added description to allow MP2MP ping by using this draft. - Removed Section 4. as it was a duplicate of Section 2.3. 0.9 Changes from 08 to 09 - Reformatted the document to follow the RFC4379 style. After the Motivations section is the Packet Format section, followed by the Operations section. The sections on Ping and Traceroute have been merged. - Added a Respond if TTL Expired Flag. - Removed reference to [MCAST-CV]. 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 anMPLS "echo request""Echo Request" and "echo reply","Echo Reply" messages, and mechanisms for transporting the echo reply.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. Mechanisms are, therefore, desirableTherefore, 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 and so that they can be used to bootstrap other Operations and Management (OAM) procedures such as [MCAST-CV].[MPLS-BFD]. This document stresses the reuse of existing LSP Ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify implementation and network operation. 1.11.1. Design Considerations An important consideration for designing LSP Ping for P2MP MPLS LSPs is that every attempt is made to use or extend existing mechanisms rather than invent new mechanisms. As for P2P LSPs, a critical requirement is that the echo request messages follow the same data path that normal MPLS packets traverse. However, it can be seen this notion needs to be extended for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so that it arrives at each egress (or leaf) of the P2MP tree. MPLS echo requests are meant primarily to validate the data plane, and they can then be used to validate data plane state against the control plane. They may also be used to bootstrap other OAM procedures such as [MPLS-BFD] and [MCAST-CV].[MPLS-BFD]. As pointed out in [RFC4379], mechanisms to check the liveness, function, and consistency of the control plane are valuable, but such mechanisms are not a feature of LSP Ping and are not covered in this document. As is described in [RFC4379], to avoid potential Denial of Service attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to the control plane. A rate limiter should be applied to the well-known UDP port defined for use by LSP Ping traffic. 2. Notes on Motivation 2.1. Basic Motivations for LSP Ping The motivations listed in [RFC4379] are reproduced here for completeness. When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that enables users to detect such traffic "black holes" or misrouting within a reasonable period of time. A mechanism to isolate faults is also required. [RFC4379] describes a mechanism that accomplishes these goals. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [RFC792]) is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode for testing MPLS LSPs. The basic idea as expressed in [RFC4379] is to test that the packets that belong to a particular Forwarding Equivalence Class (FEC) actually end their MPLS path on an LSR that is an egress for that FEC. [RFC4379] achieves this test by sending a packet (called an "MPLS echo request") along the same data path as other packets belonging to this FEC. An MPLS echo request also carries information about the FEC whose MPLS path is being verified. This echo request is forwarded just like any other packet belonging to that FEC. In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then verifies that it is indeed an egress for the FEC. In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit LSR, which performs various checks that it is indeed a transit LSR for this path; this LSR also returns further information that helps to check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path. One way these tools can be used is to periodically ping a FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and should be used with caution. 2.2. Motivations for LSP Ping for P2MP LSPs As stated in [RFC4687], MPLS has been extended to encompass P2MP LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical. For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects is important because such defects may affect the fundamentals of an MPLS network, but also because they may impact service level specification commitments for customers of their network. P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish multicast LSPs. These LSPs distribute data from a single source to one or more destinations across the network according to the next hops indicated by the routing protocols. Each LSP is identified by an MPLS multicast FEC. P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a single ingress and multiple egresses. The tunnels, built on P2MP LSPs, are explicitly routed through the network. There is no concept or applicability of a FEC in the context of a P2MP MPLS TE LSP. MPLS packets inserted at the ingress of a P2MP LSP are delivered equally (barring faults) to all egresses. In consequence, the basic idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an intention to test that packets that enter (at the ingress) a particular P2MP LSP actually end their MPLS path on the LSRs that are the (intended) egresses for that LSP. The idea may be extended to check selectively that such packets reach specific egresses. The technique in this document makes this test by sending an LSP Ping echo request message along the same data path as the MPLS packets. An echo request also carries the identification of the P2MP MPLS LSP (multicast LSP or P2MP TE LSP) that it is testing. The echo request is forwarded just as any other packet using that LSP, and so is replicated at branch points of the LSP and should be delivered to all egresses. In "ping" mode (basic connectivity check), the echo request should reach the end of the path, at which point it is sent to the control plane of the egress LSRs, which verify that they are indeed an egress (leaf) of the P2MP LSP. An echo response message is sent by an egress to the ingress to confirm the successful receipt (or announce the erroneous arrival) of the echo request. In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR also returns information on an echo response that helps verify the control plane against the data plane. That is, the information is used by the ingress to check that the data plane forwarding matches what is signaled by the control plane. P2MP MPLS LSPs may have many egresses, and it is not necessarily the intention of the initiator of the ping or traceroute operation to collect information about the connectivity or path to all egresses. Indeed, in the event of pinging all egresses of a large P2MP MPLS LSP, it might be expected that a large number of echo responses would arrive at the ingress independently but at approximately the same time. Under some circumstances this might cause congestion at or around the ingress LSR. Therefore, theThe procedures described in this document provide a mechanism that allowstwo 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. Further, theThe second procedures in this document allowallows the initiator to limit the scope of an LSP Ping echo request (ping or traceroute mode) to one specific intended egress. The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be addressed by other mechanisms such as [MCAST-CV] that utilize the LSP Ping procedures in this document to provide bootstrapping mechanisms as described in Section 2.3.LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure connectivity to any or all of the egresses. If the ping fails, the operator or an automated process can then initiate a traceroute to determine where the fault is located within the network. A traceroute may also be used periodically to verify that data plane forwarding matches the control plane state; however, this places an increased burden on transit LSRs and should be used infrequently and with caution. 2.32.3. Bootstrapping Other OAM Procedures Using LSP Ping [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to bootstrap the Bidirectional Forwarding Detection (BFD) mechanism [BFD] for use to track the liveliness of an MPLS LSP. In particular BFD can be used to detect a data plane failure in the forwarding path of an MPLS LSP. Requirements for MPLS P2MP LSPs extend to hundreds or even thousands3. Packet Format The basic structure of endpoints. If a protocol required explicit acknowledgments to each probe for connectivity verification, the response load at the root would be overwhelming. A more scalable approach to monitoring P2MP LSP connectivity is described in [MCAST-CV]. It relies on usingthe MPLS echo request and echo response messages ofLSP Ping [RFC4379] to bootstrap the monitoring mechanism in a manner similar to [MPLS-BFD]. The actual monitoring is done using a separate process defined in [MCAST-CV]. Note that whilepacket remains the approachsame as described in [MCAST-CV] was developed in response to the multicast scalability problem, it can be applied to P2P LSPs as well. 3. Operation of LSP Ping for a P2MP LSP This section describes how LSP Ping is applied to P2MP MPLS LSPs. It covers the mechanisms[RFC4379]. Some new TLVs and protocol fields applicablesub-TLVs are required to both ping mode and traceroute mode. It explainssupport the responsibilities ofnew functionality. They are described in the initiator (ingress), transit nodes, and receivers (egresses).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 22.214.171.124. RSVP P2MP IPv4 Session Sub-TLV The format of the RSVP P2MP IPv4 Session sub-TLV value field is specified in the following figure. The value fields are taken from the definitions of the P2MP IPv4 LSP Session Object and the P2MP IPv4 Sender-Template Object in [RFC4875]. Note that the Sub-Group ID of the Sender-Template is not required. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126.96.36.199. RSVP P2MP IPv6 Session Sub-TLV The format of the RSVP P2MP IPv6 Session sub-TLV value field is specified in the following figure. The value fields are taken from the definitions of the P2MP IPv6 LSP Session Object, and the P2MP IPv6 Sender-Template Object in [RFC4875]. Note that the Sub-Group ID of the Sender-Template is not required. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | P2MP ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Extended Tunnel ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 tunnel sender address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.2. Identifying a Multicast LDP LSP [RFC4379] defines how a P2P LDP LSP under test may be identified in an echo request. A Target FEC Stack TLV is used to carry one or more sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the LSP. In order to identify a multicast LDP LSP under test, the echo request message MUST carry a Target FEC Stack TLV, and this MUST carry exactly one new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so provides sufficient information to uniquely identify the LSP. The new sub-TLV is assigned a sub-type identifier as follows, and is described in the following section. Sub-Type # Length Value Field ---------- ------ ----------- TBD Variable Multicast P2MP LDP FEC Stack TBD Variable Multicast MP2MP LDP FEC Stack 188.8.131.52. 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 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. 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. 184.108.40.206. 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. Ping Mode Operation 3.2.1. Controlling Responses to LSP Pings As described in Section 2.2, it may be desirable to restrictLimiting the operationScope of LSP Ping to a single egress. Since echo requests are forwarded through the data plane without interception byResponses A new TLV is defined for inclusion in the control plane (compare with traceroute mode), thereEcho request message. The P2MP Responder Identifier TLV is no facility to limitassigned the propagation of echo requests,TLV type value TBD and they will automatically be forwarded to all (reachable) egresses. However,is encoded as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=TBD(P2MP Responder ID TLV)| Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-TLVs: Zero, one or more sub-TLVs as defined below. If no sub-TLVs are present, the intended egress under test canTLV MUST be identified byprocessed as if it were absent. If more than one sub-TLV is present the inclusion of afirst MUST be processed as described in this document, and subsequent sub-TLVs SHOULD be ignored. The P2MP Responder Identifier TLV. The details of thisTLV and its Sub-TLVs are in section 3.2.4. The initiator may choose whetheronly the node identified in the TLV responds or any nodehas meaning on the path to the node identified in the TLV may respond. An initiator may indicate that it wishes all egresses to respond toan echo request by omittingmessage. If present on an echo response message, it SHOULD be ignored. Four sub-TLVs are defined for inclusion in the P2MP Responder Identifier TLV. Note that the ingress of a multicast LDP LSP will not know the identities of the egresses ofTLV carried on the LSP except by some external means such as running P2MP LSP Ping to all egresses. 3.2.2. Ping Mode Egress Procedures An egress node is RECOMMENDED to rate limit its receipt ofecho request messages as described in [RFC4379]. After rate limiting, an egress node that receives an echo request carrying an RSVPmessage. 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 Session sub-TLV, an RSVPNode Address P2MP Responder Identifier 4 16 IPv6 Session sub-TLV, or a Multicast LDP FEC Stack sub-TLV MUST determine whether it is an egress of theNode Address P2MP LSP in question by checking with the control plane. - If the node is not an egress, it MUST respond according to the settingResponder Identifier The content of the Response Type fieldthese Sub-TLVs are defined in the echo messagefollowing the rulessections. Also defined in [RFC4379]. - If the nodeis an egress ofthe P2MP LSP,intended behavior of the responding node must check whether it is a receipientupon receiving any of the echo request. - If athese Sub-TLVs. 3.2.1. Egress Address P2MP Responder Identifier TLV is present, then the node must follow the procedures defined in section 3.2.4 to determine whether it should respond to the reqeustSub-TLVs The IPv4 or not. - If theIPv6 Egress Address P2MP Responder Identifier TLV is not present (or,Sub-TLVs MAY be used in the error case, is present, but does not contain any sub-TLVs), and the egress node that received thean echo request iscarrying RSVP P2MP Session Sub-TLV. They SHOULD NOT be used with an intended egress of the LSP, theecho request carrying Multicast LDP FEC Stack Sub-TLV. A node that receives an echo request with this Sub-TLV present MUST respond according toonly if the setting ofnode lies on the Response Type fieldpath to the address in the echo message following the rules defined in [RFC4379]. 3.2.3. Jittered ResponsesSub-TLV. The initiator (ingress)address in this Sub-TLV SHOULD be of a ping request MAY request the respondingan egress to introduce a random delay (or jitter) before sending the response. The randomness of the delay allows the responses from multiple egresses toor bud node and SHOULD NOT be spread overof a time period. Thus this technique is particularly relevant when the entire LSP tree is being pinged since it helps prevent the ingress (or nearby routers) from being swamped by responses,transit or from discarding responses due to rate limits that have been applied. It is desirable for the ingress tobranch node. A transit or branch node, should be able to control the bounds within which the egress delays the response. If the tree size is small, only a small amount of jitter is required, butdetermine if the treeaddress in this Sub-TLV is large, greater jitterfor an egress or bud node which is needed. The ingress informsreachable through it. Hence, this address SHOULD be known to the egressesnodes upstream of the jitter bound by supplying a value in a new TLV (the Echo Jitter TLV) carried on the echo request message. If this TLV is present, the responding egress MUST delay sending a responsetarget node, for instance via control plane signaling. As a random amount of time between zero milliseconds and the value indicatedcase in the TLV. If the TLVpoint, if RSVP-TE is absent, the responding egress SHOULD NOT introduce any additional delay in respondingused to signal the echo request. LSP pingP2MP LSP, this address SHOULD NOTbe the address used to attempt to measurein destination address field of the round-trip time for data delivery. This is because the LSPs are unidirectional, and the echo responseS2L_SUB_LSP object, when corresponding egress or bud node is often sent back through the control plane.signaled. 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs The timestamp fields in the echo request/responseIPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY be used to deduce some information about delivery times and particularly the variancein delivery times. The use ofan echo jittering does not change the processes for gaining information, but noterequest carrying either RSVP P2MP Session or Multicast LDP FEC Stack Sub-TLV. A node that the responding egressreceives an echo request with this Sub-TLV present MUST setrespond only if the valueaddress in the Timestamp Received fields before applyingSub-TLV corresponds to any delay. It is RECOMMENDEDaddress that echo response jitteringis not used exceptlocal to the node. This address in the caseSub-TLV may be of P2MP LSPs. If the Echo Jitter TLV is present in an echo request forany other typephysical interface or may be the router id of TLV,the respondingnode itself. The address in this Sub-TLV SHOULD be of any transit, branch, bud or egress MAY apply the jitter behavior described here. 3.2.4.node for that P2MP Responder Identifier TLV and Sub-TLVsLSP. 3.3. Preventing Congestion of Echo Responses A new TLV is defined for inclusion in the Echo request message. The P2MP Responder IdentifierEcho 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(P2MP Responder ID TLV)|| Type = TBD (Jitter TLV) | Length = Variable4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~| Jitter time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-TLVs: Zero, one or more sub-TLVs as defined below. If no sub-TLVs are present,Jitter time: This field specifies the TLV MUSTupper bound of the jitter period that should be processed as if it were absent. If more than one sub-TLV is presentapplied 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 first MUST be processed as describedvalue specified in this document, and subsequent sub-TLVs SHOULD be ignored.field. Jitter time is specified in milliseconds. The P2MP Responder IdentifierEcho Jitter 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 inclusion3.4. Respond Only If TTL Expired Flag A new flag is being introduced in the P2MP Responder Identifier TLV carried onGlobal Flags field. The new format of the echo request message. These are: Sub-Type # Length Value Field ---------- ------ -----------Global Flags field is: 0 1 0 1 2 3 4 IPv4 Egress Address P2MP Responder Identifier5 6 7 8 9 0 1 2 16 IPv6 Egress Address P2MP Responder Identifier3 4 IPv4 Node Address5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |T|V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The V flag is described in [RFC4379]. The T (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 1, then the reciever 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 0, then the receiver SHOULD reply 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 Responder Identifier 4 16 IPv6 Node Addresstraceroute functionality and SHOULD NOT be included in an Echo Request message. When responding to an RSVP IPv4/IPv6 P2MP Responder IdentifierSession FEC Type or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any Downstream Mapping TLV it receives in the echo request. The contentdetails of these Sub-TLVsthe 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 following sections. Also defined is the intended behavioroperation of P2MP ping or traceroute to a single egress. Since echo requests are forwarded through the responding node upon receiving any of these Sub-TLVs. Please note thatdata plane without interception by the echo responsecontrol plane, there is always controlled by Response Type field inno facility to limit the propagation of echo message as defined in [RFC4379]requests, and whether or not the responding node is part for the P2MP tree beingthey will automatically be forwarded to all reachable egresses. However, a single egress may be identified inby the Target FEC Stackinclusion of a P2MP Responder Identifier TLV. The details of this TLV and its Sub-TLVs definedare in thissection provide additional constraints to those requirements and3.2. There are not a replacement for those requirements. 220.127.116.11. Egress Addresstwo main types of sub-TLV in the P2MP Responder Identifier Sub-TLVs The IPv4 or IPv6TLV: 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. A node that receives an echo request with this Sub-TLV present MUST respond only ifsub-TLV and Node Address sub-TLV. These sub-TLVs limit the node liesresponses either to the specified router only or to any router on the path to the address in the Sub-TLV.specified router. The address in this Sub-TLV SHOULD be of an egress or bud node and SHOULD NOT be of a transit or branch node. This address MUST be known to the nodes upstream offormer capability is generally useful for ping mode, while the target node, possibly via control plane signaling, such as RSVP. This Sub-TLVlatter is more suited to traceroute mode. An initiating router may be usedindicate that it wishes all egresses to trace a specific egress or bud node inrespond to an echo request by omitting the P2MP tree. 18.104.22.168. Node Address P2MPResponder Identifier Sub-TLVsTLV. 4.1.2. Jittered Responses to Echo Requests The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVsinitiating router MAY be used in an echo request carrying either RSVP P2MP Session or Multicast LDP FEC Stack Sub-TLV. A node that receives an echorequest with this Sub-TLV present MUST respond only ifthe address inresponding routers to introduce a random delay (or jitter) before sending the Sub-TLV correspondsresponse. The randomness of the delay allows the responses from multiple egresses to any address thatbe spread over a time period. Thus this technique is local toparticularly relevant when the node. This address inentire P2MP LSP is being pinged or traced since it helps prevent the Sub-TLV may be of any physical interfaceinitiating (or nearby) routers from being swamped by responses, or mayfrom discarding responses due to rate limits that have been applied. It is desirable for the initiating rotuer to be able to control the router idbounds of the node itself. The address in this Sub-TLV SHOULD bejitter. If the tree size is small, only a small amount of any transit, branch, bud or egress node for that P2MP tree. This Sub-TLV may be used to ping any specific node injitter is required, but if the P2MP tree. 3.2.5. Echo Jitter TLV A new TLVtree is defined for inclusionlarge, greater jitter is needed. The initiating router can supply the desired value of the jitter in the Echo request message. The EchoJitter TLV is assigned theas defined section 3.3. If this TLV type value TBD andis 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 ofpresent, the jitter period that should be applied by aresponding node to determine how long to wait beforerouter MUST delay sending an echo response. A responding node SHOULD waita response for a random amount of time between zero milliseconds and the value specifiedindicated in this field. Jitter timethe TLV. If the TLV is specifiedabsent, the responding egress SHOULD NOT introduce any additional delay in milliseconds.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 Echo Jitter TLV only has meaning on antimestamp fields in the echo request message. If present on anand echo response message, it SHOULDpackets MAY be ignored. 3.2.6. Echo Response Reportingused 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 messages carry return codes and subcodes to indicate the result of the LSP Ping (whenjittering SHOULD be used for P2MP LSPs. If the ping modeEcho Jitter TLV is being used) as describedpresent in [RFC4379]. When the responding node reports that it isan egress, it is clear that theecho response applies only to the reporting node. Similarly, when a node reports that it does not form partrequest for any other type of LSPs, the LSP described byresponding egress MAY apply the FEC (i.e. there is a misconnection) thenjitter behavior as described here. 4.2. Responding Router Operations Usually the echo response applies torequest packet will reach the reporting node. However, it should be noted that an echo response message that reports an error from a transit node may apply to multipleegress nodes (i.e. leaves) downstream of the reporting node.and bud nodes. In thecase of TTL Expiry, i.e. traceroute mode, the Ping mode of operation, it is not possibleecho request packet may stop at branch or transit nodes. In both scenarios, the echo request will be passed on to correlatecontrol plane for reply processing. The operations at the reportingreceiving node are an extenstion to the affected egresses unless the shape of the P2MP treeexisting processing as specified in [RFC4379]. A responding router is already known, and it may be necessaryRECOMMENDED to userate limit its receipt of echo request messages. After rate limiting, the Traceroute moderesponding router must verify general sanity of operation (see Section 3.3) to further diagnosethe LSP. Note also that a transit node may discover an error but also determine that while it does lie onpacket. If the packet is malformed, or certain TLVs are not understood, the [RFC4379] procedures must be followed for echo reply. Similarly the path ofReply Mode field determines if the LSP under test, it doesresponse is required or not lie on(and the pathmechanism to the specific egress being tested. In this case, the node SHOULD NOT generate an echo response. 22.214.171.124 Ping Responses at Transitsend it back). For P2MP LSP ping and Branch Nodes If the TTL oftraceroute, i.e. if the MPLS packet carrying anecho request expires at a transitis carrying an RSVP P2MP FEC or branch node,a Multicast LDP FEC, the packetresponding router MUST be passed todetermine whether it is part of the control plane as specifiedP2MP LSP in [RFC4379].question by checking with the control plane. - If the P2MP Responder Identifiernode is not present or does not contain any Sub-TLV, thenpart of the nodeP2MP LSP, it MUST respond.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 Sub-TLVTLV is present, then the node MUST respond as per section 3.2.4. If the echo response being sent is not indicating an error condition, such as Malformed request, thenmust follow the Return Codeprocedures defined in the echo response header may be setsection 3.2 to value 8 ('Label switched at stack-depth <RSC>')determine whether it should respond to the reqeust or any other error value as needed. 126.96.36.199 Ping Responses at Egress and Bud Nodesnot. The echo request packet MUST be sent topresence of a P2MP Responder Identifier TLV or a Downstream Detailed Mapping TLV might affect the control plane at egress and bud nodes.Return Code. This is discussed in more detail later. - If the P2MP Responder Identifier TLV is not present or(or, in the error case, is present, but does not contain any Sub-TLV, then the node MUST respond. If the P2MP Responder Identifier Sub-TLV is present,sub-TLVs), then the node MUST respond as per section 3.2.4. If the echoaccording to [RFC4379] processing rules. 4.2.1. Echo Response Reporting Echo response being sent is not indicating an error condition, such as Malformed request, thenmessages carry return codes and subcodes to indicate the Return Code inresult of the echo response header may be set to value 3 ('Replying router is an egress forLSP Ping (when the FEC at stack-depth <RSC>') or any other error value as needed. 3.3. Traceroute Mode Operation The tracerouteping mode of operationis being used) as described in [RFC4379]. Like other traceroute operations, it relies on the expiration of the TTL ofWhen the packetresponding node reports that it is an egress, it is clear that carriesthe echo request. Whenresponse applies only to the TTL expiresreporting node. Similarly, when a node reports that it does not form part of the echo request is passed toLSP described by the control plane onFEC (i.e. there is a misconnection) then the transit node which responds accordingecho response applies to the Response Type in thereporting node. However, it should be noted that an echo response message (and any Responder Identifier TLVthat may be present). Echo requests MAY include a Downstream Detailed Mapping TLV, andreports an error from a respondingtransit node fills inmay apply to multiple egress nodes (i.e. leaves) downstream of the fieldsreporting node. In the case of the Downstream Detailed Mapping TLVping mode of operation, it is not possible to indicate the downstream interfaces and labels used bycorrelate the reported LSP fromreporting node to the responding node. In this way, by successively sending out echo requests with increasing TTLs,affected egresses unless the ingress may gain a picturetopology of the pathP2MP tree is already known, and resources used by an LSP. This process continues eitherit may be necessary to use the pointtraceroute mode of failure when no response is received, or an error response is generated by a node where the control plane does not expectoperation to be handlingfurther diagnose the LSP. For P2MP Traceroute,Note also that a transit node MUST support Downstream Detailed Mapping TLV [DDMT]. Downstream Mapping TLV [RFC4379] SHOULD NOT be used for P2MP traceroute functionality. As per Section 4.3 of [DDMT], Downstream Mapping TLV is being deprecated. A node MUST ignore any Downstream Mapping TLVmay discover an error but also determine that while it receives indoes lie on the echo request. If there are nodes inpath of the P2MP tree that doLSP under test, it does not support Downstream Detailed Mapping TLV, they will send an echo reply with Return Code setlie on the path to 2. The ingressthe specific egress being tested. In this case, the node upon receiving such a valueSHOULD send subsequentNOT generate an echo requests with a larger TTL.response. The traceroute modefollowing sections describe the expected values of operation is equally applicable toReturn Codes for various nodes in a P2MP MPLS TE LSPLSP. It is assumed that the sanity and P2MP Multicast LDP LSPother checks have been performed and an echo response is described in the following sections. The traceroute mode can be applied to all destinations of the P2MP tree just as in the ping mode. In the case of P2MP MPLS TE LSPs,being sent back. As mentioned previously, the traceroute mode can also be applied to individual traceroute targets identified byReturn Code might change based on the presence of a P2MPResponder Identifier TLV. In this case, the responding node must follow the behavior specified in 3.2.4. These targets SHOULD be egressesTLV or bud nodes. However, since a transit nodeDownstream Detailed Mapping TLV. 188.8.131.52. Responses from Transit and Branch nodes The presence of a multicast LDP LSP is unable to determine whether it lies onResponder Identifier TLV does not influence the pathchoice of the Return Code, which MAY be set to any one destinationvalue 8 ('Label switched at stack-depth <RSC>') or any other transit node, the traceroute mode limited to specific nodeserror value as needed. The presence of such an LSP MUST NOT be used. Ina Downstream Detailed Mapping TLV will influence the absencechoice of a P2MP Responder Identifier TLV,Return Code. As per [DDMT], the Return Code in the echo request is asking for traceroute information applicableresponse header MAY be set to all egresses.value TBD ('See DDM TLV for Return Code and Return SubCode') as defined in [DDMT]. The echo response jitter technique describedReturn Code for each Downstream Detailed Mapping TLV will depend on the ping mode is equally applicable to the traceroute mode and is not additionallydownstream path as described in [DDMT]. There will be a Downstream Detailed Mapping TLV for each downstream path being reported in the procedures below. 3.3.1. Correlating Traceroute Responses When traceroute is simultaneously applied to multiple responders (e.g. egresses), itecho 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 important thatan Egress Address Responder Identifier Sub-TLV, then the ingress is ablebranch node will include only one Downstream Detailed Mapping TLV corresponding to correlatethe echo responses withdownstream path required to reach the nodesaddress specified in the P2MP tree. Without this informationEgress Address Sub-TLV. 184.108.40.206. Responses from Egress Nodes The presence of a Responder Identifier TLV does not influence the ingress willchoice of the Return Code, which MAY be unableset to determine the correct ordering of transit nodes. One possibilityvalue 3 ('Replying router is an egress for the ingress to poll the path to each responder in turn, but this may be inefficient, undesirable,FEC at stack-depth <RSC>') or (inany other error value as needed. The presence of the caseDownstream Detailed Mapping TLV does not influence the choice of multicast LDP LSPs) illegal. TheReturn Code. Egress nodes do not put in any Downstream Detailed Mapping TLV MUST be includedin the echo responseresponse. 220.127.116.11. Responses from transit, bud, or branchBud Nodes The case of bud nodes is more complex than other types of nodes. The information fromnode 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 be pieced together byinfluence the ingress to reconstructReturn Code values. To determine the P2MP tree although it may be necessary to refer tobehavior of the routing information distributed bybud node, use the IGPfollowing guidelines. The intent of these guidelines is to correlate next hop addresses andfigure out if the echo request is meant for all nodes, or just this node, or for another node reporting addressesreachable 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 subsequent echo responses. The following sections describethe Return Code usedsecond case, the node will behave like pure egress node; in the echo response headerthird case, the node will behave like a transit node; and in the Downstream Detailed Mapping TLV. Itlast case, no response will be sent back. Node behavior guidelines: - If the Responder Identifier TLV is possible to identifynot present, then the type ofnode (transit, branch, budwill behave as a combination egress and egress) by using various values inbranch node. - If the Return Code and presence of Downstream Detailed Mapping TLV. 3.3.2. Traceroute Responses at Transit Nodes WhenResponder Identifier TLV containing a Node Address sub-TLV is present, and: - If the TTL ofaddress specified in the MPLS packet carryingsub-TLV matches to an echo request expiresaddress in the packet MUST be passed tonode, then the control plane asnode will behave like an egress node only. - If the address specified in [RFC4379].the sub-TLV does not match any address in the node, then no response will be sent. - If the echo request packet containsResponder Identifier TLV containing an IPv4 or IPv6Egress Address P2MP Responder Identifier TLV, and the FECsub-TLV is IPv4 or IPv6 P2MP TE LSP,present, and: - If the address specified in the sub-TLV matches to an address in the node, then the node MUST respond only ifwill behave like an egress node only. - If the node lies on the path to the egressaddress specified in the Sub-TLV. If the LSP under test is a multicast LDP LSP and echo request has an IPv4 or IPv6 Egress Address P2MP Responder Identifier TLV,sub-TLV, then the node MUST treat the echo request as malformed and MUST process it according to the rules specified in [RFC4379].will behave like a transit node. - If the echo response being sent isnode does not indicating an error condition, such as Malformed request, it MUST identify the next hop oflie on the path of the LSP into the data plane by including a Downstream Detailed Mapping TLV as described in [DDMT]. The Return Codeaddress specified in echothe sub-TLV, then no response headerwill be value TBD ('See DDM TLVsent. Once the node behavior has been determined, the possible values for Return Code and Return SubCode')Codes are as defined in [DDMT]. Thefollows: - 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 will depend on the state of the output interface. 3.3.3. Traceroute Responses at Branch Nodes A branch node MUST follow the procedures describedTLV, even if one is present in Section 3.3.2 to determine whether it should respond to anthe echo request. - If the P2MP Responder Identifiernode is behaving as a transit node, and: - If a Downstream Detailed Mapping TLV is not present or does not contain any Sub-TLV (that is, if all egresses are being traced),present, then the branch node MUST addReturn 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 to the echo response for each outgoing branch that it reports. If an IPv4 or IPv6 Egress Address P2MP Responder Identifieris present, it MUST report only the branch that is on the path to the specified egress node and it MUST NOT reportthen the other branches. TheReturn Code in echo response header willMAY be set to value TBD ('See DDM TLV for Return Code and Return SubCode') as defined in [DDMT]. The Return Code for each ofthe Downstream Detailed Mapping TLV will depend on the state of the output interface being reported in this TLV. 3.3.4. Traceroute Responses at Egress Nodes If P2MP Responder Identifier is not present or does not contain any Sub-TLV (that is, if all egresses are being traced), thenTLV will depend on the egress node MUST responddownstream path as described in [DDMT]. There will be only one Downstream Detailed Mapping corresponding to the echo request. If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is present, it MUST respond only ifdownstream path to the specifiedaddress belongsspecified in the egress node.Egress Address Sub-TLV. - If the node MUST NOT returnis behaving as a combination egress and branch node, and: - If a Downstream Detailed Mapping TLV. TheTLV is not present, then the Return Code in the echo response header willMAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>') or any other error value as defined in [RFC4379]. 3.3.5. Traceroute Responses at Bud Nodes Some nodes onneeded. - If a P2MP MPLS LSP mayDownstream 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 wellneeded. Return Code for the each Downstream Detailed Mapping TLV will depend on the downstream path as described in [DDMT]. There will be a branch (i.e. have one or moreDownstream Detailed Mapping for each downstream nodes). Such nodes are known as bud nodes [RFC4461]. A bud node's response ispath from the node. 4.3. Special Considerations for Traceroute 4.3.1. End of Processing for Traceroutes As specified in [RFC4379], the traceroute mode operates by sending a combinationseries of branch node and egress node behavior. If P2MP Responder Identifierecho requests with sequentially increasing TTL values. For regular P2P targets, this processing stops when a valid response is not presentreceived from the intended egress or doeswhen some errored return code is received. For P2MP targets, there may not contain any Sub-TLV (that is, if all egressesbe an easy way to figure out the end of the traceroute processing, as there are being traced), thenmultiple egress nodes. Receiving a valid response from an egress will not signal the bud node MUST respond toend of processing. In P2MP TE LSP, the echo request. It MUST addinitiating router has a Downstream Detailed Mapping TLVpriori knowledge about number of egress nodes and their addresses. Hence it possible to the echocontinue processing till a valid response forhas been received from each outgoing branch that it reports. The Return Code inend-point, provided the echo response header willresponses can be value 3 ('Replyingmatched correctly to the egress nodes. However in Multicast LDP LSPs, the initiating router is anhas no knowledge about the egress fornodes. Hence it is not possible to estimate the FEC at stack-depth <RSC>') as definedend of processing for traceroute in [RFC4379]. The Return Codesuch scenarios. Therefore it is RECOMMENDED that traceroute operations provide for each of the Downstream Detailed Mapping TLV will dependa configurable upper limit on TTL values. Hence the state ofuser can choose the output interface being reported in this TLV. If an IPv4 or IPv6depth to which the tree will be probed. 4.3.2. Multiple responses from Bud and Egress AddressNodes The P2MP Responder Identifier is present, and the specified address belongs thetraceroute may continue even after it has received a valid response from a bud or egress node, then it MUST respondas if it were an egress node. The Return Code in the echo response header willthere may be value 3 ('Replying router is an egress for the FECmore nodes at stack-depth <RSC>') as defined in [RFC4379]. It MUST NOT report any Downstream Detailed Mapping TLV. If an IPv4deeper levels. Hence for subsequent TTL values, a bud or IPv6 Egress Address P2MP Responder Identifieregress node that has previously replied would continue to get new echo requests. Since each echo request is present, and thehandled independently from previous requests, these bud node liesand egress nodes will keep on the pathresponding to the specified egress address, then it MUST respond as if it was a branch node. The Return Code in thetraceroute echo response header will be value TBD ('See DDM TLVrequests. This can cause extra processing burden for Return Codethe initiating router and Return SubCode') as definedthese bud or egress routers. To prevent a bud or egress node from sending multiple responses in [DDMT]. The Return Code for each of the Downstream Detailed Mapping TLV will depend on the state ofthe output interfacesame traceroute operation, a new "Respond Only If TTL Expired" flag is being reportedintroduced. This flag is described in Section 3.4. It is RECOMMENDED that this TLV. 3.3.6.flag be used for P2MP traceroute mode only. By using this flag, extraneous responses from bud and egress nodes can be reduced. 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, perhaps becausethe transit node has failed, or perhaps becausethe transit node does not support LSP Ping, or the Responder Identifier TLV failed to match a valid node.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. 18.104.22.168.4. Use of Downstream Detailed Mapping TLV in Echo Request If no Responder IdentifierAs 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 used, then inmodified for P2MP LSPs. In the Echo Requestecho request packet, the "Downstream IP Address" field, of the Downstream Detailed Mapping TLV, MUSTSHOULD be set to the ALLROUTERs multicast address. If a Responder Identifier TLV is being used, thenALLROUTERS 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 Echo RequestEgress Address sub-TLV. For this case, the echo request packet MAY reuse a received Downstream Detailed Mapping TLV. 4.5. Non-compliant Routers If an egressa 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 end pointsall nodes for P2MP LSPs are all equally capable of supporting this function. Alternatively,If the non-compliant node is an egress, then the traceroute optionmode can be used to verify the LSP nearly all the way to the egress, leaving the final hop to be verified manually. If, in "traceroute" mode,If the non-compliant node is a branch or transit node does not support LSP ping,node, then no reply will be forthcoming from that node for some TTL, say n. The node originating the echo request SHOULD continue to send echo request with TTL=n+1, n+2, ..., n+k to probe nodes further down the path. In such a case, the echo request for TTL > n SHOULD be sent with Downstream Detailed Mapping TLV "Downstream IP Address" field set toit should not impact ping mode. However the ALLROUTERs multicast address as described in Section 3.3.4 until a reply is received with a Downstream Detailed Mapping TLV. 5.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. 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. 6.7. IANA Considerations 22.214.171.124. New Sub-TLV Types ThreeFour new sub-TLV types are defined for inclusion within the LSP Ping [RFC4379] Target FEC Stack TLV (TLV type 1). IANA is requested to assign sub-type values to the following sub-TLVs from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry. RSVP P2MP IPv4 Session (see Section(Section 3.1.1). Suggested value 17. RSVP P2MP IPv6 Session (see Section(Section 3.1.1). Suggested value 18. Multicast P2MP LDP FEC Stack (see Section(Section 3.1.2). Suggested value 19. Multicast MP2MP LDP FEC Stack (see Section(Section 3.1.2). Suggested value 20. 126.96.36.199. 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.4) is a mandatory TLV. Suggested value 11. Four sub-TLVs are defined. - Type 1: IPv4 Egress Address P2MP Responder Identifier - 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.2.5) is a mandatory TLV. Suggested value 12. 7.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. 8.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 and IJsbrand Wijnands for their comments and suggestions. 9.10. References 9.110.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. 9.210.2. Informative References [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. [RFC4461] Yasukawa, S., "Signaling Requirements for Point to Multipoint Traffic Engineered Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)", RFC 4461, April 2006. [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp, work in progress. [MCAST-CV] Swallow, G., and Nadeau, T., "Connectivity Verification for Multicast Label Switched Paths", draft-swallow-mpls-mcast-cv, work in progress.[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-ietf-bfd-base, work in progress. [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in progress. [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 10.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: firstname.lastname@example.org@lab.ntt.co.jp Adrian Farrel Old Dog Consulting EMail: email@example.com Zafar Ali Cisco Systems Inc. 2000 Innovation Drive Kanata, ON, K2K 3E8, Canada. Phone: 613-889-6158 Email: firstname.lastname@example.org Bill Fenner Arastra, Inc. 275 Middlefield Rd. Suite 50 Menlo Park, CA 94025 Email: email@example.comGeorge Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: firstname.lastname@example.org Thomas D. Nadeau British Telecom BT Centre 81 Newgate Street EC1A 7AJ London Email: email@example.com Shaleen Saxena Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: firstname.lastname@example.org 11.12. Full Copyright Statement Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.