Network Working Group A. Farrel (Editor) Internet-Draft Old Dog Consulting Intended Status: Standards Track S. Yasukawa Updates: RFC4379 NTT Created:
September 10, 2008 Expires: March 10,August 11, 2009 Expires: February 11, 2010 Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping draft-ietf-mpls-p2mp-lsp-ping-07.txtdraft-ietf-mpls-p2mp-lsp-ping-08.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF in accordancefull conformance with Section 6the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Contents 1. Introduction ...................................................Introduction.................................................... 4 1.1 Design Considerations .........................................Considerations.......................................... 5 2. Notes on Motivation ............................................Motivation............................................. 6 2.1. Basic Motivations for LSP Ping ...............................Ping................................ 6 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 8LSPs........................ 6 2.3 Bootstrapping Other OAM Procedures Using LSP Ping ............. 9Ping.............. 8 3. Operation of LSP Ping for a P2MP LSP ........................... 9LSP............................ 8 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 ...........................Sub-TLV............................ 9 188.8.131.52. RSVP P2MP IPv6 Session Sub-TLV .......................... 10Sub-TLV............................ 9 3.1.2. Identifying a Multicast LDP LSP ...........................LSP............................ 10 184.108.40.206. Multicast LDP FEC Stack Sub-TLV .........................Sub-TLVs......................... 10 220.127.116.11. Applicability to Multipoint-to-Multipoint LSPs........... 11 3.2. Ping Mode Operation .........................................Operation.......................................... 12 3.2.1. Controlling Responses to LSP Pings ........................Pings......................... 12 3.2.2. Ping Mode Egress Procedures ...............................Procedures................................ 12 3.2.3. Jittered Responses ........................................ 13Responses......................................... 12 3.2.4. P2MP Responder Identifier TLV and Sub-TLVs ................Sub-TLVs................. 13 18.104.22.168. Egress Address P2MP Responder Identifier Sub-TLVs........ 14 22.214.171.124. Node Address P2MP Responder Identifier Sub-TLVs.......... 14 3.2.5. Echo Jitter TLV ...........................................TLV............................................ 15 3.2.6. Echo Response Reporting ...................................Reporting.................................... 15 126.96.36.199 Ping Responses at Transit and Branch Nodes................ 16 188.8.131.52 Ping Responses at Egress and Bud Nodes.................... 16 3.3. Traceroute Mode Operation ...................................Operation.................................... 16 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 17 184.108.40.206.Correlating Traceroute Responses ........................Responses........................... 17 3.3.2. Traceroute Responses at Branch Nodes .....................Transit Nodes...................... 18 220.127.116.11. Node Properties TLV .....................................3.3.3. Traceroute Responses at Branch Nodes....................... 18 18.104.22.168. Branching Properties Sub-TLV ............................ 19 22.214.171.124. Egress Address Sub-TLV .................................. 20 126.96.36.199. Correlating3.3.4. Traceroute Responses ........................ 21 3.3.3.at Egress Nodes....................... 19 3.3.5. Traceroute Responses at Bud Nodes ......................... 21 3.3.4.Nodes.......................... 19 3.3.6. Non-Response to Traceroute Echo Requests .................. 22 3.3.5. Additions toRequests................... 20 3.3.7 Use of Downstream Detailed Mapping Multipath Information ..... 22 3.3.6. Echo Response Reporting ................................... 24 188.8.131.52. Reporting Multiple Conditions Using The DDMTLV ......... 24in Echo Request...... 20 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 25 5.Non-compliant Routers ......................................... 26 6.Routers.......................................... 20 5. OAM Considerations ............................................ 26 7.Considerations............................................. 20 6. IANA Considerations ........................................... 27 7.1.Considerations............................................ 21 6.1. New Sub-TLV Types ........................................... 27 7.2. New Multipath Type .......................................... 27 7.3. New TLVs .................................................... 28 7.4. New Return Code ............................................. 28 7.5.Types............................................ 21 6.2. New Sub-TLV Value for the Downstream Detailed Mapping TLV ... 28 8.TLVs..................................................... 21 7. Security Considerations ....................................... 29Considerations........................................ 22 8. Acknowledgements............................................... 22 9. Acknowledgements .............................................. 29 10. Intellectual Property Considerations ......................... 29 11.References..................................................... 23 9.1 Normative References ......................................... 30 12.References.......................................... 23 9.2 Informative References ....................................... 30 13.References........................................ 23 10. Authors' Addresses ........................................... 31 14.Addresses............................................ 24 11. Full Copyright Statement ..................................... 32Statement...................................... 25 0. Change Log This section to be removed before publication as an RFC. 0.1 Changes from 00 to 01 - Update references. - Fix boilerplate. 0.2 Changes from 01 to 02 - Update entire document so that it is not specific to MPLS-TE, but also includes multicast LDP LSPs. - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new egress identifier TLV. - Include Multicast LDP FEC Stack sub-TLV definition from [MCAST-CV]. - Add brief section on use of LSP Ping for bootstrapping. - Add new references to References section. - Add details of two new authors. 0.3 Changes from 02 to 03 - Update references. - Update boilerplate. - Fix typos. - Clarify in 3.2.2 that a recipient of an echo request must reply only once it has applied incoming rate limiting. - Tidy references to bootstrapping for [MCAST-CV] in 1.1. - Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4. - Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs in sections 3.2.1 and 3.2.2. 0.4 Changes from 03 to 04 - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4 with respect to multiple sub-TLVs in the P2MP Egress Identifier TLV. 0.5 Changes from 04 to 05 - Change coordinates for Tom Nadeau. Section 13. - Fix typos. - Update references. - Resolve all acronym expansions. 0.6 Changes from 05 to 06 - New section, 3.2.6, to explain echo response reporting in the Ping case. - New section, 3.3.7, to explain echo response reporting in the Traceroute case. - Sections 3.3.2, 3.3.5, and 5. Retire the E-flag for identification of bud nodes. Use the B-flag in a Downstream Mapping TLV with a zero address to provide the necessary indication. - Section 3.3.4. Note the use of ALLROUTERS address as per RFC 4379 - Section 7. Suggest values for IANA assignment. - Rename "P2MP Responder Identifier TLV" to "P2MP Responder Identifier TLV", "Egress Identifier sub-TLV" to "Responder Identifier sub-TLV", and "P2MP egresses" multipath type to "P2MP responder". This allows any LSR on the P2MP LSP to be the target of, or responder to, an echo request. 0.7 Changes from 06 to 07 - Sections 3.3.2 and 3.3.3. Delete section 3.3.5. New sections 184.108.40.206 through 220.127.116.11: Retire B-flag from Downstream Mapping TLV. Introduce new Node Properties TLV with Branching Properties and Egress Address sub-TLVs. - Section 18.104.22.168: Clarify rules on presence of Multipath Information in Downstream Mapping TLVs. - Section 3.3.5: Clarify padding rules. - Section 3.3.6: Updated to use Downstream Detailed Mapping TLVs for multiple return conditions reported by a single echo response. - Section 7: Update IANA values and add new sub-sections. - Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap. - Section 13: Update Bill Fenner's coordinates. 1. Introduction Simple and efficient mechanisms that can be used0.8 Changes from 07 to detect data plane failures in point-to-point (P2P) Multiprotocol Label Switching08 - Removed the Node Properties TLV (Section 22.214.171.124 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 126.96.36.199 of version 07), as it is already included in draft-ietf-mpls-lsp-ping-enhanced-dsmap-02. - Clarified the behavior of Responder Identifier TLV (Section 3.2.4 of version 07). Two new Sub-TLVs are introduced. - Downstream Detailed Mapping TLV is now mandatory for implementing P2MP OAM functionality. - Split Multicast LDP TLV into two TLVs, one for P2MP and other for MP2MP. Also added description to allow MP2MP ping by using this draft. - Removed Section 4. as it was a duplicate of Section 2.3. 1. Introduction Simple and efficient mechanisms that can be used to detect data plane failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSP) are described in [RFC4379]. The techniques involve information carried in an MPLS "echo request" and "echo reply", and mechanisms for transporting the echo reply. The echo request and reply messages provide sufficient information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. The use of reliable channels for echo reply messages as described in [RFC4379] enables more robust fault isolation. This collection of mechanisms is commonly referred to as "LSP Ping". The requirements for point-to-multipoint (P2MP) MPLS traffic engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a signaling solution for establishing P2MP MPLS TE LSPs. The requirements for point-to-multipoint extensions to the Label Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] specifies extensions to LDP for P2MP MPLS. P2MP MPLS LSPs are at least as vulnerable to data plane faults or to discrepancies between the control and data planes as their P2P counterparts. Mechanisms are, therefore, desirable to detect such data plane faults in P2MP MPLS LSPs as described in [RFC4687]. This document extends the techniques described in [RFC4379] such that they may be applied to P2MP MPLS LSPs and so that they can be used to bootstrap other Operations and Management (OAM) procedures such as [MCAST-CV]. This document stresses the reuse of existing LSP Ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify implementation and network operation. 1.1 Design Considerations An important consideration for designing LSP Ping for P2MP MPLS LSPs is that every attempt is made to use or extend existing mechanisms rather than invent new mechanisms. As for P2P LSPs, a critical requirement is that the echo request messages follow the same data path that normal MPLS packets traverse. However, it can be seen this notion needs to be extended for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so that it arrives at each egress (or leaf) of the P2MP tree. MPLS echo requests are meant primarily to validate the data plane, and they can then be used to validate data plane state against the control plane. They may also be used to bootstrap other OAM procedures such as [MPLS-BFD] and [MCAST-CV]. As pointed out in [RFC4379], mechanisms to check the liveness, function, and consistency of the control plane are valuable, but such mechanisms are not a feature of LSP Ping and are not covered in this document. As is described in [RFC4379], to avoid potential Denial of Service attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to the control plane. A rate limiter should be applied to the well-known UDP port defined for use by LSP Ping traffic. 2. Notes on Motivation 2.1. Basic Motivations for LSP Ping The motivations listed in [RFC4379] are reproduced here for completeness. When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that enables users to detect such traffic "black holes" or misrouting within a reasonable period of time. A mechanism to isolate faults is also required. [RFC4379] describes a mechanism that accomplishes these goals. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [RFC792]) is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode for testing MPLS LSPs. The basic idea as expressed in [RFC4379] is to test that the packets that belong to a particular Forwarding Equivalence Class (FEC) actually end their MPLS path on an LSR that is an egress for that FEC. [RFC4379] achieves this test by sending a packet (called an "MPLS echo request") along the same data path as other packets belonging to this FEC. An MPLS echo request also carries information about the FEC whose MPLS path is being verified. This echo request is forwarded just like any other packet belonging to that FEC. In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then verifies that it is indeed an egress for the FEC. In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit LSR, which performs various checks that it is indeed a transit LSR for this path; this LSR also returns further information that helps to check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path. One way these tools can be used is to periodically ping a FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and should be used with caution. 2.2. Motivations for LSP Ping for P2MP LSPs As stated in [RFC4687], MPLS has been extended to encompass P2MP LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical. For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects is important because such defects may affect the fundamentals of an MPLS network, but also because they may impact service level specification commitments for customers of their network. P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish multicast LSPs. These LSPs distribute data from a single source to one or more destinations across the network according to the next hops indicated by the routing protocols. Each LSP is identified by an MPLS multicast FEC. P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a single ingress and multiple egresses. The tunnels, built on P2MP LSPs, are explicitly routed through the network. There is no concept or applicability of a FEC in the context of a P2MP MPLS TE LSP. MPLS packets inserted at the ingress of a P2MP LSP are delivered equally (barring faults) to all egresses. In consequence, the basic idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an intention to test that packets that enter (at the ingress) a particular P2MP LSP actually end their MPLS path on the LSRs that are the (intended) egresses for that LSP. The idea may be extended to check selectively that such packets reach specific egresses. The technique in this document makes this test by sending an LSP Ping echo request message along the same data path as the MPLS packets. An echo request also carries the identification of the P2MP MPLS LSP (multicast LSP or P2MP TE LSP) that it is testing. The echo request is forwarded just as any other packet using that LSP, and so is replicated at branch points of the LSP and should be delivered to all egresses. In "ping" mode (basic connectivity check), the echo request should reach the end of the path, at which point it is sent to the control plane of the egress LSRs, which verify that they are indeed an egress (leaf) of the P2MP LSP. An echo response message is sent by an egress to the ingress to confirm the successful receipt (or announce the erroneous arrival) of the echo request. In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR also returns information on an echo response that helps verify the control plane against the data plane. That is, the information is used by the ingress to check that the data plane forwarding matches what is signaled by the control plane. P2MP MPLS LSPs may have many egresses, and it is not necessarily the intention of the initiator of the ping or traceroute operation to collect information about the connectivity or path to all egresses. Indeed, in the event of pinging all egresses of a large P2MP MPLS LSP, it might be expected that a large number of echo responses would arrive at the ingress independently but at approximately the same time. Under some circumstances this might cause congestion at or around the ingress LSR. Therefore, the procedures described in this document provide a mechanism that allows the responders to randomly delay (or jitter) their responses so that the chances of swamping the ingress are reduced. Further, the procedures in this document allow the initiator to limit the scope of an LSP Ping echo request (ping or traceroute mode) to one specific intended egress. The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be addressed by other mechanisms such as [MCAST-CV] that utilize the LSP Ping procedures in this document to provide bootstrapping mechanisms as described in Section 2.3. LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure connectivity to any or all of the egresses. If the ping fails, the operator or an automated process can then initiate a traceroute to determine where the fault is located within the network. A traceroute may also be used periodically to verify that data plane forwarding matches the control plane state; however, this places an increased burden on transit LSRs and should be used infrequently and with caution. 2.3 Bootstrapping Other OAM Procedures Using LSP Ping [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to bootstrap the Bidirectional Forwarding Detection (BFD) mechanism [BFD] for use to track the liveliness of an MPLS LSP. In particular BFD can be used to detect a data plane failure in the forwarding path of an MPLS LSP. Requirements for MPLS P2MP LSPs extend to hundreds or even thousands of endpoints. If a protocol required explicit acknowledgments to each probe for connectivity verification, the response load at the root would be overwhelming. A more scalable approach to monitoring P2MP LSP connectivity is described in [MCAST-CV]. It relies on using the MPLS echo request and echo response messages of LSP Ping [RFC4379] to bootstrap the monitoring mechanism in a manner similar to [MPLS-BFD]. The actual monitoring is done using a separate process defined in [MCAST-CV]. Note that while the approach described in [MCAST-CV] was developed in response to the multicast scalability problem, it can be applied to P2P LSPs as well. 3. Operation of LSP Ping for a P2MP LSP This section describes how LSP Ping is applied to P2MP MPLS LSPs. It covers the mechanisms and protocol fields applicable to both ping mode and traceroute mode. It explains the responsibilities of the initiator (ingress), transit nodes, and receivers (egresses). 3.1. Identifying the LSP Under Test 3.1.1. Identifying a P2MP MPLS TE LSP [RFC4379] defines how an MPLS TE LSP under test may be identified in an echo request. A Target FEC Stack TLV is used to carry either an RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. In order to identify the P2MP MPLS TE LSP under test, the echo request message MUST carry a Target FEC Stack TLV, and this MUST carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry fields from the RSVP-TE P2MP Session and Sender-Template objects [RFC4875] and so provide sufficient information to uniquely identify the LSP. The new sub-TLVs are assigned sub-type identifiers as follows, and are described in the following sections. Sub-Type # Length Value Field ---------- ------ ----------- TBD 20 RSVP P2MP IPv4 Session TBD 56 RSVP P2MP IPv6 Session 188.8.131.52. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184.108.40.206. 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 220.127.116.11. Multicast LDP FEC Stack Sub-TLV The format of theSub-TLVs Both Multicast P2MP and MP2MP LDP FEC Stack sub-TLV is shown below.have the same format, as specified in the following figure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Address Length| Root LSR Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Root LSR Address (Cont.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Length | Opaque Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family A twoTwo octet quantity containing a value from ADDRESS FAMILY NUMBERS in [IANA-PORT] that encodes the address family for the Root LSR Address. Address Length The lengthLength of the Root LSR Address in octets. Root LSR Address An addressAddress of the LSR at the root of the P2MP LSP encoded according to the Address Family field. Opaque Length The length of the Opaque Value, in octets. Opaque Value An opaque value elements ofelement 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. 18.104.22.168. Applicability to Multipoint-to-Multipoint LSPs The mechanisms defined in this document can be extended to include Multipoint-to-Multipoint (MP2MP) Multicast LSPs. In an MP2MP LSP tree, any leaf node can be treated like a head node of a P2MP tree. In other words, for MPLS OAM purposes, the MP2MP tree can be treated like a collection of P2MP trees, with each MP2MP leaf node acting like a P2MP head-end node. When a leaf node is acting like a P2MP head-end node, the remaining leaf nodes act like egress nodes. 3.2. Ping Mode Operation 3.2.1. Controlling Responses to LSP Pings As described in Section 2.2, it may be desirable to restrict the operation of LSP Ping to a single egress. Since echo requests are forwarded through the data plane without interception by the control plane (compare with traceroute mode), there is no facility to limit the propagation of echo requests, and they will automatically be forwarded to all (reachable) egresses. However, the intended egress under test can be identified by the inclusion of a P2MP Responder Identifier TLV containing an IPv4 P2MP Responder Identifier sub-TLV or an IPv6 P2MP Responder Identifier sub-TLV.TLV. The P2MP Responder Identifierdetails of this TLV SHOULD contain precisely one sub-TLV. Ifand its Sub-TLVs are in section 3.2.4. The initiator may choose whether only the TLV contains no sub-TLVs it SHOULD be processed as ifnode identified in the wholeTLV were absent (causing all egresses to respond as described below). Ifresponds or any node on the TLV contains more than one sub-TLV,path to the first MUST be processed as describednode identified in this document, and subsequent sub-TLVs SHOULD be ignored.the TLV may respond. An initiator may indicate that it wishes all egresses to respond to an echo request by omitting the P2MP Responder Identifier TLV. Note that the ingress of a multicast LDP LSP will not know the identities of the egresses of the LSP except by some external means such as running P2MP LSP Ping to all egresses. 3.2.2. Ping Mode Egress Procedures An egress node is RECOMMENDED to rate limit its receipt of echo request messages as described in [RFC4379]. After rate limiting, an egress node that receives an echo request carrying an RSVP P2MP IPv4 Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast LDP FEC Stack sub-TLV MUST determine whether it is an intendedegress of the P2MP LSP in question by checking with the control plane. - If itthe node is not supposed to bean egress, it MUST respond according to the setting of the Response Type field in the echo message following the rules defined in [RFC4379]. - If the egressnode that receives an echo request and allows it through its rate limitingis an intendedegress of the P2MP LSP, the node MUSTmust check to seewhether it is an intended Ping recipient. Ifa P2MP Responder Identifier TLV is present and contains an address that indicates any address that is local to the node, the node MUST respond according to the settingreceipient of the Response Type field in theecho message following the rules defined in [RFC4379].request. - If thea P2MP Responder Identifier TLV is present, but does not identifythen the egress node,node must follow the procedures defined in section 3.2.4 to determine whether it MUST NOTshould respond to the echo request.reqeust or not. - If the P2MP Responder Identifier TLV is not present (or, in the error case, is present, but does not contain any sub-TLVs), butand the egress node that received the echo request is an intended egress of the LSP, the node MUST respond according to the setting of the Response Type field in the echo message following the rules defined in [RFC4379]. 3.2.3. Jittered Responses The initiator (ingress) of a ping request MAY request the responding egress to introduce a random delay (or jitter) before sending the response. The randomness of the delay allows the responses from multiple egresses to be spread over a time period. Thus this technique is particularly relevant when the entire LSP tree is being pinged since it helps prevent the ingress (or nearby routers) from being swamped by responses, or from discarding responses due to rate limits that have been applied. It is desirable for the ingress to be able to control the bounds within which the egress delays the response. If the tree size is small, only a small amount of jitter is required, but if the tree is large, greater jitter is needed. The ingress informs the egresses of the jitter bound by supplying a value in a new TLV (the Echo Jitter TLV) carried on the echo request message. If this TLV is present, the responding egress MUST delay sending a response for a random amount of time between zero secondsmilliseconds and the value indicated in the TLV. If the TLV is absent, the responding egress SHOULD NOT introduce any additional delay in responding to the echo request. LSP ping SHOULD NOT be used to attempt to measure the round-trip time for data delivery. This is because the LSPs are unidirectional, and the echo response is often sent back through the control plane. The timestamp fields in the echo request/response MAY be used to deduce some information about delivery times and particularly the variance in delivery times. The use of echo jittering does not change the processes for gaining information, but note that the responding egress MUST set the value in the Timestamp Received fields before applying any delay. It is RECOMMENDED that echo response jittering is not used except in the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo request for any other type of TLV, the responding egress MAY apply the jitter behavior described here. 3.2.4. P2MP Responder Identifier TLV and Sub-TLVs A new TLV is defined for inclusion in the Echo request message. The P2MP Responder Identifier TLV is assigned the TLV type value TBD and is encoded as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=TBD(P2MP Responder ID TLV)| Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-TLVs: Zero, one or more sub-TLVs as defined below. If no sub-TLVs are present, the TLV MUST be processed as if it were absent. If more than one sub-TLV is present the first MUST be processed as described in this document, and subsequent sub-TLVs SHOULD be ignored. The P2MP Responder Identifier TLV only has meaning on an echo request message. If present on an echo response message, it SHOULD be ignored. TwoFour sub-TLVs are defined for inclusion in the P2MP Responder Identifier TLV carried on the echo request message. These are: Sub-Type # Length Value Field ---------- ------ ----------- 1 4 IPv4 Egress Address P2MP Responder Identifier 2 16 IPv6 Egress Address P2MP Responder Identifier The value of an3 4 IPv4 Node Address P2MP Responder Identifier consists of four octets of an IPv4 address. The IPv4 address is in network byte order. The value of an4 16 IPv6 Node Address P2MP Responder Identifier consistsThe content of these Sub-TLVs are defined in the following sections. Also defined is the intended behavior of sixteen octetsthe responding node upon receiving any of an IPv6 address. The IPv6 addressthese Sub-TLVs. Please note that the echo response is always controlled by Response Type field in network byte order. 3.2.5. Echo Jitter TLV A new TLV isthe echo message as defined for inclusionin [RFC4379] and whether or not the Echo request message. The Echo Jitter TLVresponding node is assignedpart for the TLV type value TBD and is encoded as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD (Jitter TLV) | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Jitter time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jitter time: This field specifies the upper bound ofP2MP tree being identified in the jitter period that should be applied by a responding node to determine how longTarget FEC Stack TLV. The Sub-TLVs defined in this section provide additional constraints to wait before sendingthose requirements and are not a replacement for those requirements. 22.214.171.124. Egress Address P2MP Responder Identifier Sub-TLVs The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs MAY be used in an echo response.request carrying RSVP P2MP Session Sub-TLV. They SHOULD NOT be used with an echo request carrying Multicast LDP FEC Stack Sub-TLV. A respondingnode SHOULD wait a random amount of time between zero seconds and the value specified in this field. Jitter time is specified in milliseconds. The Echo Jitter TLV only has meaning onthat receives an echo request message. Ifwith this Sub-TLV present MUST respond only if the node lies on an echo response message, itthe path to the address in the Sub-TLV. The address in this Sub-TLV SHOULD be ignored. 3.2.6. Echo Response Reporting Echo response messages carry return codesof an egress or bud node and subcodesSHOULD NOT be of a transit or branch node. This address MUST be known to indicatethe resultnodes upstream of the LSP Ping (when the ping mode is being used)target node, possibly via control plane signaling, such as describedRSVP. This Sub-TLV may be used to trace a specific egress or bud node in [RFC4379]. Whenthe respondingP2MP tree. 126.96.36.199. Node Address P2MP Responder Identifier Sub-TLVs The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY be used in an echo request carrying either RSVP P2MP Session or Multicast LDP FEC Stack Sub-TLV. A node reportsthat it isreceives an egress, it is clear that theecho response appliesrequest with this Sub-TLV present MUST respond only to the reporting node. Similarly, when a node reports that it does not form part of the LSP described byif the FEC (i.e. their is a misconnection) thenaddress in the echo response appliesSub-TLV corresponds to the reporting node. However, it should be noted that an echo response messageany address that reports an error from a transit node may applyis local to multiple egress nodes (i.e. leaves) downstream ofthe reportingnode. InThis address in the caseSub-TLV may be of any physical interface or may be the Ping moderouter id of operation, it is not possible to correlatethe reportingnode to the affected egresses unless the shapeitself. The address in this Sub-TLV SHOULD be of theany transit, branch, bud or egress node for that P2MP tree is already known, and ittree. This Sub-TLV may be necessary to use the Traceroute mode of operation (see Section 3.3)used to further diagnose the LSP. Note also that a transitping any specific node may discover an error but also determine that while it does lie onin the path ofP2MP tree. 3.2.5. Echo Jitter TLV A new TLV is defined for inclusion in the LSP under test, it does not lie onEcho request message. The Echo Jitter TLV is assigned the path toTLV type value TBD and is encoded as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD (Jitter TLV) | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Jitter time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jitter time: This field specifies the specific egress being tested. In this case,upper bound of the jitter period that should be applied by a responding node SHOULD NOT generateto determine how long to wait before sending an echo response. A reportingresponding node that isSHOULD wait a branch node may need to report multiple different errors (for different downstream branches). This is discussed further in Section 3.3.6. 3.3. Traceroute Mode Operation The traceroute moderandom amount of operationtime between zero milliseconds and the value specified in this field. Jitter time is describedspecified in [RFC4379]. Like other traceroute operations, it reliesmilliseconds. The Echo Jitter TLV only has meaning on the expiration of the TTL of the packet that carries thean echo request.request message. If present on an echo response message, it SHOULD be ignored. 3.2.6. Echo requests may include a Downstream Mapping TLV,Response Reporting Echo response messages carry return codes and when the TTL expires the echo request is passedsubcodes to indicate the control plane onresult of the transit node which responds according toLSP Ping (when the Response Typeping mode is being used) as described in [RFC4379]. When the message. Aresponding node fills in the fields ofreports that it is an egress, it is clear that the Downstream Mapping TLVecho response applies only to indicatethe downstream interfaces and labels used byreporting node. Similarly, when a node reports that it does not form part of the reportedLSP from the responding node. In this way,described by successively sending out echo requests with increasing TTLs,the ingress may gainFEC (i.e. there is a picture ofmisconnection) then the path and resources used by an LSP upecho response applies to the point of failure when noreporting node. However, it should be noted that an echo response is received, ormessage that reports an error response is generated byfrom a transit node where the control plane does not expectmay apply to be handlingmultiple egress nodes (i.e. leaves) downstream of the LSP. Thisreporting node. In the case of the Ping mode of operationoperation, it is equally applicablenot possible to P2MP MPLS TE LSPs as described incorrelate the following sections. The traceroute mode can be appliedreporting node to all destinations of the P2MP tree just as inthe ping mode. Inaffected egresses unless the caseshape of P2MP MPLS TE LSPs,the traceroute mode can alsoP2MP tree is already known, and it may be appliednecessary to individual traceroute targets identified byuse the presenceTraceroute mode of a P2MP Responder Identifier TLV. These targets may be egresses or transit nodes. However, sinceoperation (see Section 3.3) to further diagnose the LSP. Note also that a transit node of a multicast LDP LSP is unable tomay discover an error but also determine whetherthat while it liesdoes lie on the path to any one destination or any other transit node, the traceroute mode limited to specific nodesof such an LSP MUST NOT be used. Note that the addresses specified inthe P2MP Responder Identifier TLV needLSP under test, it does not be egresses: they could be transit nodeslie on the LSP. The processing rules here and in the following sections apply equallypath to the specific egress and transit nodes.being tested. In this case, the absence of a P2MP Responder Identifier TLV, the echo request is asking for traceroute information applicable to all egresses. Thenode SHOULD NOT generate an echo response jitter technique described for the ping mode is equally applicable to the traceroute mode and is not additionally described in the procedures below. 3.3.1. Tracerouteresponse. 188.8.131.52 Ping Responses at Non-BranchTransit and Branch Nodes WhenIf the TTL forof the MPLS packet carrying an echo request expires at a transit or branch node, the packet MUST be passed to the control plane as specified in [RFC4379]. If the LSP under testP2MP Responder Identifier is a multicast LDP LSP and ifnot present or does not contain any Sub-TLV, then the node MUST respond. If the echo request carries aP2MP Responder Identifier TLVSub-TLV is present, then the node MUST treatrespond as per section 3.2.4. If the echo requestresponse being sent is not indicating an error condition, such as malformed and MUST process it according toMalformed request, then the rules specifiedReturn Code in [RFC4379]. Otherwise,the node MUST NOT return anecho response unless the responding node lies on the path of the P2MP LSPheader may be set to the node (egressvalue 8 ('Label switched at stack-depth <RSC>') or transit) identified byany other error value as needed. 184.108.40.206 Ping Responses at Egress and Bud Nodes The echo request packet MUST be sent to the control plane at egress and bud nodes. If the P2MP Responder Identifier TLV carried on the request, or if no such sub-TLVis present. If sent,not present or does not contain any Sub-TLV, then the echo responsenode MUST identify the next hop of the path of the LSP inrespond. If the data plane by including a Downstream Mapping TLV as described in [RFC4379]. 220.127.116.11. Correlating Traceroute Responses When traceroute is being simultaneously applied to multiple responders (e.g., egresses), itP2MP Responder Identifier Sub-TLV is important thatpresent, then the ingress should be able to correlatenode MUST respond as per section 3.2.4. If the echo responses withresponse being sent is not indicating an error condition, such as Malformed request, then the branchesReturn Code in the P2MP tree. Without this information the ingress willecho response header 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 (in the case of multicast LDP LSPs) illegal.any other error value as needed. 3.3. Traceroute Mode Operation The Downstream Mapping TLV that MUST be includedtraceroute mode of operation is described in [RFC4379]. Like other traceroute operations, it relies on the echo response indicatesexpiration of the next hop from each responding node, and this information supplied by a non-branch node can be pieced together byTTL of the ingress to reconstructpacket that carries the P2MP tree although it may be necessary to refer toecho request. When the routing information distributed byTTL expires the IGP to correlate next hop addresses and node reporting addresses in subsequentecho responses. In orderrequest is passed to facilitate more easy correlation of echo responses,the Downstream Mapping TLV can also contain Multipath Information as described in [RFC4379] to identify to which responders (transit nodes or egresses) the echo response applies. This information: - Cannot be present when the information is not known by the responding node. For example, for a multicast LDP LSP, the branch node will not know through normal LDP signaling which leaf nodes liecontrol plane on which downstream branch. - SHOULD be present when the information is known by the responding node. That is for P2MP MPLS TE LSPs whenthe echo request applies to all egresses or to a specific singletransit node or egress. The format of the information in the Downstream Mapping TLV for P2MP MPLS LSPs is described in section 3.3.5. 3.3.2. Traceroute Responses at Branch Nodes A branch node may need to identify more than one downstream interface in a traceroute echo response if some of the nodes identified in the P2MP Responder Identifier TLV that are being traced lie on different branches. This will always be the case for any branch node if all egresses are being traced. [RFC4379] describes how multiple Downstream Mapping TLVs should be included in an echo response, each identifying exactly one downstream interface that is applicable to the LSP. A branch node MUST follow the procedures described in Section 3.3.1 to determine whether it should respond to an echo request. The branch node MUST add a Downstream Mapping TLV (or Downstream Detailed Mapping TLV - see Section 3.3.7) to the echo response for each outgoing branch that it reports, but it MUST NOT report branches that do not lie on the path to one of the destinations being traced. Thus a branch node may sometimes only need to respond with a single Downstream Mapping TLV; for example, consider the case where the traceroute is directed to only a single egress node. Therefore, the presence of only one Downstream Mapping TLV in an echo response does not guarantee that the reporting node is not a branch node. To report on its branching properties on a particular LSP, the responding node MAY include an optional TLV called the Node Properties TLV. This new TLV (see Section 18.104.22.168) can carry sub- TLVs, one ofwhich (the Branching Properties sub-TLV - see Section 22.214.171.124) allows the reporting node to describe the branching characteristics of the LSP at the reporting node. 126.96.36.199. Node Properties TLV A new TLV has been added to the set of optional TLVs that may be carried on an echo response message. Type # Value Field ------ ------------ TBD Node properties The Node Properties TLV MAY be included in an echo response message. If more than one such TLV is present, the first MUST be processed and subsequent instances SHOULD be ignored. The Node Properties TLV is used to report characteristics of the reporting node, and the LSP at that node. This distinguishes it from the Downstream Mapping TLV [RFC4379] and the Downstream Detailed Mapping TLV [DDMT] used to report characteristics of specific out- segments an LSP. The Node Properties TLV is a standard LSP Ping TLV as defined in [RFC4379]. It has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : First Sub-TLV : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ Further Sub-TLVs ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The content of the Node Properties TLV is a series of one or more sub-TLVs. The Nore Properties TLV SHOULD contain one or more sub-TLVs and MUST be ignored if there are no sub-TLVs present. Each sub-TLV consists of the following fields as per [RFC4379]: - Two octet Type field: A value indicating the sub-TLV type. - Two octet Length field: A value indicating the total length of the Value field. - A Value field carrying the data of the sub-TLV. The content of the Value field is padded to a four byte boundary with zero-filled octets so that the Length field is always a multiple of 4. 188.8.131.52. Branching Properties Sub-TLV This document defines the Branching Properties sub-TLV carried in the Node Properties TLV. The Branching Properties sub-TLV is optional. If more than one such sub-TLV is found in a Node Properties TLV, the first MUST be processed and subsequent instances SHOULD be ignored. The sub-TLV may be used for P2MP and P2P LSPs. The Branching Properties sub-TLV is formed as described in Section 184.108.40.206. The Value field has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Branch Count | Egress Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Downstream Branch Count This field reports the number of downstream branches from the reporting node for this LSP. The number may be zero for an egress, one for a non-branch node, and more than one for a branch node. Note that the value reported here may be greater than the number of Downstream Mapping TLVs present in the echo response message since those TLVs only report on the specific egresses queried. This value may be of use in detecting faults caused by delay introduced by the data replication mechanism at branch nodes. Egress Count This field reports the number of egresses local to the reporting node. Thus, for non-zero values the reporting node is either a leaf or a bud. When the value reported is non-zero, the reporting node MAY also include an Egress Address Sub-TLV for each local egress (see Section 220.127.116.11). For example, a branch node that has two downstream next hops on the LSP and that also delivers payload data to one local egress would set the two fields to 2 and 1 respectively. 18.104.22.168. Egress Address Sub-TLV This document defines the IPv4 and IPv6 Egress Address sub-TLVs carried in the Node Properties TLV. These TLVs are optional, and more than one instance of the sub-TLVs may legitimately be present. The Egress Address sub-TLVs are formed as described in Section 22.214.171.124. The Value field has the following formats. IPv4 Egress Address Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Egress Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Egress Address Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Egress Address | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Egress Address sub-TLVs are optional. They MAY be included in a Node Properties TLV when reporting node is an egress (leaf or bud) for the LSP being tested. The sub-TLV may be used for P2MP and P2P LSPs. When one or more Egress Address sub-TLVs are present and the Branch Properties sub-TLV is also present, the value ofresponds according to the Egress Count fieldResponse Type in the Branch Properties sub-TLV SHOULDmessage (and any Responder Identifier TLV that may be present). Echo requests MAY include a Downstream Detailed Mapping TLV, and a responding node fills in the same as the numberfields of Egress Address sub-TLVs. The address contained in an Egress Address sub-TLV isthe egress addressDownstream Detailed Mapping TLV to whichindicate the data is delivered. If there is just one egressdownstream interfaces and iflabels used by the egress address isreported LSP from the same asresponding node. In this way, by successively sending out echo requests with increasing TTLs, the local node address carried iningress may gain a picture of the main echopath and resources used by an LSP. This process continues either to the point of failure when no response message, bothis received, or an error response is generated by a node where the Branching Properties sub-TLV andcontrol plane does not expect to be handling the Egress Address sub-TLV MAYLSP. For P2MP Traceroute, a node MUST support Downstream Detailed Mapping TLV [DDMT]. Downstream Mapping TLV [RFC4379] SHOULD NOT be omitted as in legacy LSP Ping implementations. 126.96.36.199. Correlating Traceroute Responses Just as with non-branches, itused for P2MP traceroute functionality. As per Section 4.3 of [DDMT], Downstream Mapping TLV is important thatbeing deprecated. A node MUST ignore any Downstream Mapping TLV it receives in the echo responses from branchrequest. If there are nodes provide correlation informationin the P2MP tree that do not support Downstream Detailed Mapping TLV, they will allow the ingress to work outsend an echo reply with Return Code set to which branch2. The ingress node upon receiving such a value SHOULD send subsequent echo requests with a larger TTL. The traceroute mode of theoperation is equally applicable to P2MP MPLS TE LSP and P2MP Multicast LDP LSP and is described in the response applies.following sections. The P2MP treetraceroute mode can be determined by the ingress using the identityapplied to all destinations of the reporting node and the next hop information from the previous echo response,P2MP tree just as with echo responses from non-branch nodes. As with non-branch nodes,in order to facilitate more easy correlationthe ping mode. In the case of echo responses,P2MP MPLS TE LSPs, the Downstream Mapping TLVtraceroute mode can also contain Multipath Information as described in [RFC4379] to identify to which nodes the echo response applies. This information: - Cannotbe present when the information is not knownapplied to individual traceroute targets identified by the responding node. For example, forpresence of a multicast LDP LSP,P2MP Responder Identifier TLV. In this case, the branchresponding node will not know through normal LDP signaling which leaf nodes lie on which downstream branch. -must follow the behavior specified in 3.2.4. These targets SHOULD be present when the information is known by the responding node. That is for P2MP MPLS TE LSPs when the echo request applies to allegresses or tobud nodes. However, since a specific singletransit node or egress. The formatof the information in the Downstream Mapping TLV for P2MP MPLS LSPs is described in section 3.3.5. 3.3.3. Traceroute Responses at Bud Nodes Some nodes ona P2MP MPLSmulticast LDP LSP may be egresses, but also have downstream node. Such nodes are known as budis unable to determine whether it lies on the path to any one destination or any other transit node, the traceroute mode limited to specific nodes [RFC4461]. A bud nodeof such an LSP MUST respond toNOT be used. In the absence of a tracerouteP2MP Responder Identifier TLV, the echo request just as a branch node would, but it MUST also indicateis asking for traceroute information applicable to all egresses. The echo response jitter technique described for the ingress that itping mode is an egress in its own right. The issueequally applicable to be resolved herethe traceroute mode and is how to indicate thatnot additionally described in the reporting nodeprocedures below. 3.3.1. Correlating Traceroute Responses When traceroute is an egress whensimultaneously applied to multiple responders (e.g. egresses), it is also providing one or more Downstream Mapping TLVs that indicateimportant that it has downstream neighbors. Thisthe ingress is achieved byable to correlate the inclusion of a Node Properties TLVecho responses with a Branch Properties sub-TLV indicating the number of local egresses andthe number of downstream branches. The bud node MAY also include one or more Egress Address sub-TLVsnodes in the Node Properties TLV to report on the local egresses. 3.3.4. Non-Response to Traceroute Echo Requests The nature ofP2MP MPLS TE LSPs intree. Without this information the data plane means that traceroute echo requests mayingress will be deliveredunable to determine the control planecorrect ordering of nodes that must not reply to the request because, although they lie on the P2MP tree, they do not lie ontransit nodes. One possibility is for the pathingress to poll the node that is being traced. Thus, a node on a P2MP MPLS LSP MUST NOT respondpath to an echo request wheneach responder in turn, but this may be inefficient, undesirable, or (in the TTL has expired if anycase of the following applies: -multicast LDP LSPs) illegal. The Reply Type indicates that no reply is required [RFC4379] - There is a P2MP Responder IdentifierDownstream Detailed Mapping TLV present onMUST be included in the echo request (which means thatresponse from transit, bud, or branch nodes. The information from Downstream Detailed Mapping TLV can be pieced together by the LSP is a P2MP MPLS TE LSP), butingress to reconstruct the address does not identify a node that is reached through this node for this particularP2MP MPLS LSP. Note that when no responsetree although it may be necessary to refer to an echo request is received bythe ingress (perhaps becauserouting information distributed by the transitIGP to correlate next hop addresses and node has failed, or perhaps becausereporting addresses in subsequent echo responses. The following sections describe the transit node does not support LSP Ping), then as per [RFC4379]Return Code used in the subsequentecho request (with a larger TTL) SHOULD be sent with Downstream Mapping TLV "Downstream IP Address" field set toresponse header and in the ALLROUTERs multicast address until a reply is received with aDownstream Detailed Mapping TLV. 3.3.5. Additions to Downstream Mapping Multipath Information A new value for the Multipath TypeIt is definedpossible to indicate thatidentify the reported Multipath Information applies to a P2MP MPLS TE LSP and may contain a listtype of node identifiers that indicate(transit, branch, bud and egress) by using various values in the egress nodesReturn Code and (inpresence of Downstream Detailed Mapping TLV. 3.3.2. Traceroute Responses at Transit Nodes When the case whereTTL of the MPLS packet carrying an echo request expires the packet MUST be passed to the control plane as specified in [RFC4379]. If the echo request packet contains an IPv4 or IPv6 Egress Address P2MP Responder Identifier TLV was usedTLV, and the FEC is IPv4 or IPv6 P2MP TE LSP, then the node MUST respond only if the node lies on the echo requestpath to identify non-egress nodes) transit nodes that can be reached throughthe reported interface. This Multipath Type MUST NOT be used foregress specified in the Sub-TLV. If the LSP under test is a multicast LDP LSP. Type # Address Type Multipath Information --- ---------------- ------------------------------ TBD P2MP responders List of reachable P2MP nodes Note that a list of nodes may include IPv4LSP and echo request has an IPv4 or IPv6 identifiers since these may be mixed in theEgress Address P2MP MPLS TE LSP. The Multipath Length field continues to identifyResponder Identifier TLV, then the length ofnode MUST treat the Multipath Information justecho request as in [RFC4379] (that is, not including the downstream labels),malformed and MUST process it according to the downstream label (or potential stack thereof) is also handled just asrules specified in [RFC4379]. The format ofIf the Multipath Information for a Multipath Type of P2MP respondersecho response being sent is not indicating an error condition, such as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Responder Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (continued) | : +-+-+-+-+-+-+-+-+ : : Further Address Types and Responder Addresses : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Type This field indicates whetherMalformed request, it MUST identify the address that follows is an IPv4 or IPv6 address, and so implicitly encodesnext hop of the lengthpath of the address. Two values are defined and mirror the values usedLSP in the Address Type field ofdata plane by including a Downstream Detailed Mapping TLV as described in [DDMT]. The Return Code in echo response header will be value TBD ('See DDM TLV for Return Code and Return SubCode') as defined in [DDMT]. The Return Code for the Downstream Detailed Mapping TLV itself. Type # Address Type ------ ------------ 1 IPv4 3 IPv6 Responder Address An egress or transit nodewill depend on the state of thisthe output interface. 3.3.3. Traceroute Responses at Branch Nodes A branch node MUST follow the procedures described in Section 3.3.2 to determine whether it should respond to an echo request. If the P2MP MPLS TE LSP thatResponder Identifier is reached through the interface indicated bynot present or does not contain any Sub-TLV (that is, if all egresses are being traced), then the branch node MUST add a Downstream Detailed Mapping TLV and for whichto the tracerouteecho request was enquiring. Note that padding to ensureresponse for each outgoing branch that the whole Multipath information is aligned to a four-octet boundaryit reports. If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is appliedpresent, it MUST report only after the last responder address inthe list. That is, each successive Address Type followsbranch that is on immediately afterthe previous Responder Address. 3.3.6. Echo Response Reporting Echo responses are generated in responsepath to traceroute echo requests at transit, branch, and bud nodes as described in Sections 3.3.1, 3.3.2, and 3.3.3, whilethe specified egress responses are as described in [RFC4379]. Note, however, that a branch or budnode may have multiple downstream branches,and a transit node may have multiple downstream egresses (reached on the same branch). It may beit MUST NOT report the case that different conditions need to be reported for different branches or egresses.other branches. The Return Code in echo response message defined in [RFC4379] has spaceheader will be value TBD ('See DDM TLV for only a single return codeReturn Code and subcode pair, so where more than one return condition is reported by a single node it actsReturn SubCode') as follows. - It SHOULD usedefined in [DDMT]. The Return Code for each of the Downstream Detailed Mapping TLV [DDMT] in place ofwill depend on the Downstream Mapping TLV, and encodestate of the return code as described in Section 188.8.131.52. - It MAY report each condition in a separate echo responseoutput interface being reported in which casethis TLV. 3.3.4. Traceroute Responses at Egress Nodes If P2MP Responder Identifier is not present or does not contain any Sub-TLV (that is, if all egresses are being traced), then the egress node MUST limitrespond to the downstream mapping information on eachecho response to those branches/egresses to whichrequest. If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is present, it MUST respond only if the response applies.specified address belongs the egress node. Egress node MUST NOT return a Downstream Detailed Mapping TLV. The use of multipleReturn Code in the echo response messages to report errors might cause issuesheader will be value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>') as defined in [RFC4379]. 3.3.5. Traceroute Responses at Bud Nodes Some nodes on a P2MP MPLS LSP may be an initiator thategress as well as a branch (i.e. have one or more downstream nodes). Such nodes are known as bud nodes [RFC4461]. A bud node's response is a combination of branch node and egress node behavior. If P2MP Responder Identifier is not present or does not know how many responses it should wait for. For that reason, multiple messages should be used with care. 184.108.40.206. Reporting Multiple Conditions Using The DDM TLV When multiple different return codescontain any Sub-TLV (that is, if all egresses are indicated on a single echo response message theybeing traced), then the bud node MUST be carried in separate instances onrespond to the echo request. It MUST add a Downstream Detailed Mapping (DDM) TLV [DDMT]. That is, each instance of a DDM TLV carries one return code, and all information carried in thatTLV MUST be limited to branches/egressesto which that return code applies. However, more than one DDM TLV onthe sameecho response MAY carry the same return code.for each outgoing branch that it reports. The echo response message still carries aReturn Code and a Return Subcode field. In order to clearly indicate that the relevant return codes are carriedin the DDM TLV, a new return codeecho response header will be value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>') as defined to be carriedin the[RFC4379]. The Return Code fieldfor each of the echo response message as follows: Value Meaning ----- ------- TBD See DDM TLV for more details The Return Subcode for this Return Code MUST be set to zero and MUST be ignored. The DDMDownstream Detailed Mapping TLV is defined as carrying a set of sub-TLVs. A new sub-TLV,will depend on the Return Code sub-TLV, is defined here to carry a return code and return subcode. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Code | Return Subcode| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The lengthstate of the Return Code sub-TLVoutput interface being reported in this TLV. If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is 8.present, and the specified address belongs the bud node, then it MUST respond as if it were an egress node. The Return Code As defined for inclusionin the echo response message in [RFC4379]. Return Subcode As definedheader will be value 3 ('Replying router is an egress for inclusion inthe echo response messageFEC at stack-depth <RSC>') as defined in [RFC4379]. Reserved SHOULD be set to zero on transmission andIt MUST be ignored on receipt.NOT report any Downstream Detailed Mapping TLV. If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is present, and the Return Code ofbud node lies on the echo response message is not setpath to "See DDM TLV for more details"the specified egress address, then any Return Code sub-TLV present init MUST respond as if it was a DDM TLV SHOULD be ignored. If thebranch node. The Return Code ofin the echo response message is set to "Seeheader will be value TBD ('See DDM TLV for more details" then aReturn Code sub-TLV MUST be presentand Return SubCode') as defined in each DDM TLV. Subsequent[DDMT]. The Return Code sub-TLVs presentfor each of the Downstream Detailed Mapping TLV will depend on the state of the output interface being reported in this TLV. 3.3.6. Non-Response to Traceroute Echo Requests There are multiple reasons for which an ingress node may not receive a response to its echo request. For example, perhaps because the same DDMtransit node has failed, or perhaps because the transit node does not support LSP Ping, or the Responder Identifier TLV failed to match a valid node. When no response to an echo request is received by the ingress, then as per [RFC4379] the subsequent echo request with a larger TTL SHOULD be ignored. 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms Bootstrappingsent. 3.3.7 Use of other OAM procedures can be achieved usingDownstream Detailed Mapping TLV in Echo Request If no Responder Identifier TLV is being used, then in the MPLSEcho Request/Response messages. The LSP(s) under test are identified usingRequest packet, the RSVP P2MP IPv4 or IPv6 Session sub-TLVs (see Section 3.1.1) or"Downstream IP Address" field, of the Multicast LDP FEC Stack sub-TLV (see Section 3.1.2). Other sub-TLVs mayDownstream Detailed Mapping TLV, MUST be defined in other specificationsset to indicatethe OAM proceduresALLROUTERs multicast address. If a Responder Identifier TLV is being bootstrapped, and to describe the bootstrap parameters. Further details of the bootstrapping processes andused, then the bootstrapped OAM processes are described in other documents. For example, see [MPLS-BFD] and [MCAST-CV]. 5.Echo Request packet MAY reuse a received Downstream Detailed Mapping TLV. 4. Non-compliant Routers If an egress for a P2MP LSP does not support MPLS LSP ping, then no reply will be sent, resulting in a "false negative" result. There is no protection for this situation, and operators may wish to ensure that end points for P2MP LSPs are all equally capable of supporting this function. Alternatively, the traceroute option can be used to verify the LSP nearly all the way to the egress, leaving the final hop to be verified manually. If, in "traceroute" mode, a transit node does not support LSP ping, then no reply will be forthcoming from that node for some TTL, say n. The node originating the echo request SHOULD continue to send echo request with TTL=n+1, n+2, ..., n+k to probe nodes further down the path. In such a case, the echo request for TTL > n SHOULD be sent with Downstream Detailed Mapping TLV "Downstream IP Address" field set to the ALLROUTERs multicast address as described in Section 3.3.4 until a reply is received with a Downstream Detailed Mapping TLV. 6.5. OAM Considerations The procedures in this document provide OAM functions for P2MP MPLS LSPs and may be used to enable bootstrapping of other OAM procedures. In order to be fully operational several considerations must be made. - Scaling concerns dictate that only cautious use of LSP Ping should be made. In particular, sending an LSP Ping to all egresses of a P2MP MPLS LSP could result in congestion at or near the ingress when the responses arrive. Further, incautious use of timers to generate LSP Ping echo requests either in ping mode or especially in traceroute may lead to significant degradation of network performance. - Management interfaces should allow an operator full control over the operation of LSP Ping. In particular, it SHOULD provide the ability to limit the scope of an LSP Ping echo request for a P2MP MPLS LSP to a single egress. Such an interface SHOULD also provide the ability to disable all active LSP Ping operations to provide a quick escape if the network becomes congested. - A MIB module is required for the control and management of LSP Ping operations, and to enable the reported information to be inspected. There is no reason to believe this should not be a simple extension of the LSP Ping MIB module used for P2P LSPs. 7.6. IANA Considerations 220.127.116.11. New Sub-TLV Types Three new sub-TLV types are defined for inclusion within the LSP Ping [RFC4379] Target FEC Stack TLV (TLV type 1). IANA is requested to assign sub-type values to the following sub-TLVs from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry. RSVP P2MP IPv4 Session (see Section 3.1.1). Suggested value 17. RSVP P2MP IPv6 Session (see Section 3.1.1). Suggested value 18. Multicast LDP FEC Stack (see Section 3.1.2). Suggested value 19. 7.2. New Multipath Type Section 3.3 of [RFC4379] defines a set of values for the LSP Ping Multipath Type. These values are currently not tracked by IANA. A new value for the LSP Ping Multipath Type is defined in Section 3.3.5 of this document to indicate that the reported Multipath Information applies to a P2MP MPLS TE LSP.for inclusion within the LSP Ping [RFC4379] Target FEC Stack TLV (TLV type 1). IANA is requested to create a new registry as follows:assign sub-type values to the following sub-TLVs from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters - Multipath Types" Key Type Multipath Information --- ---------------- --------------------- 0 no multipath Empty (Multipath Length = 0) [RFC4379] 2 IP address IP addresses [RFC4379] 4 IP address range low/high address pairs [RFC4379] 8 Bit-masked IP IP address prefix and bit mask [RFC4379] address set 9 Bit-masked label set Label prefixTLVs" registry, "TLVs and bit mask [RFC4379] xxsub-TLVs" sub-registry. RSVP P2MP responder IP List ofIPv4 Session (see Section 3.1.1). Suggested value 17. RSVP P2MP responders [thisDoc] addresses A suggestedIPv6 Session (see Section 3.1.1). Suggested value of xx is 16. New values from this registry are to be assigned only by Standards Action. 7.3.18. Multicast P2MP LDP FEC Stack (see Section 3.1.2). Suggested value 19. Multicast MP2MP LDP FEC Stack (see Section 3.1.2). Suggested value 20. 6.2. New TLVs ThreeTwo 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. TwoFour sub-TLVs are defineddefined. - Type 1: IPv4 Egress Address P2MP Responder Identifier (see Section 3.2.4)- Type 2: IPv6 Egress Address P2MP Responder Identifier (see Section 3.2.4) Echo Jitter TLV (see Section 3.2.5) is a mandatory TLV. Suggested value 12. Node Properties TLV (see Section 18.104.22.168) is an optional TLV. Suggested value 32768. Three sub-TLVs are defined- Type 1:3: IPv4 EgressNode Address P2MP Responder Identifier - Type 2:4: IPv6 EgressNode Address - Type 3: Branch Properties 7.4. New Return Code A new Return Code is defined in Section 22.214.171.124. IANA is requested to assign a new Return Code value for the "Multi- Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, "Return Codes" sub-registry as follows using a Standards Action value. Value Meaning ----- ------- TBD See DDM TLV for more details Suggested value 14. 7.5. New Sub-TLV Value for the Downstream Detailed Mapping TLV [DDMT] defines a TLV called the Downstream Detailed Mapping TLV and requests IANA to maintain a registry of sub-TLVs that it can carry.P2MP Responder Identifier Echo Jitter TLV (see Section 126.96.36.199 of this document defines a new sub-TLV. IANA3.2.5) is requested to assign a TLV type value as follows usinga Standards Actionmandatory TLV. Suggested value from the range 0-32767. Sub-Type Value Field --------- ------------ TBD Return Code 8.12. 7. Security Considerations This document does not introduce security concerns over and above those described in [RFC4379]. Note that because of the scalability implications of many egresses to P2MP MPLS LSPs, there is a stronger concern to regulate the LSP Ping traffic passed to the control plane by the use of a rate limiter applied to the LSP Ping well-known UDP port. Note that this rate limiting might lead to false positives. 9.8. Acknowledgements The authors would like to acknowledge the authors of [RFC4379] for their work which is substantially re-used in this document. Also thanks to the members of the MBONED working group for their review of this material, to Daniel King and Mustapha Aissaoui for their review, and to Yakov Rekhter for useful discussions. The authors would like to thank Vanson Lim, Danny Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin Bahadur, Tetsuya Murakami andMurakami, Michael Hua, Michael HuaWildt, Dipa Thakkar and IJsbrand Wijnands for their comments and suggestions. 10. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- firstname.lastname@example.org. 11.9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism for Performing LSP-Ping over MPLS Tunnels", draft-ietf- mpls-lsp-ping-enhanced-dsmap, work in progress. 12.9.2 Informative References [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. [RFC4461] Yasukawa, S., "Signaling Requirements for Point to Multipoint Traffic Engineered Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)", RFC 4461, April 2006. [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp, work in progress. [MCAST-CV] Swallow, G., and Nadeau, T., "Connectivity Verification for Multicast Label Switched Paths", draft-swallow-mpls-mcast-cv, work in progress. [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-ietf-bfd-base, work in progress. [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in progress. [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 13.10. Authors' Addresses Seisho Yasukawa NTT Corporation (R&D Strategy Department) 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan Phone: +81 3 5205 5341 Email: email@example.com Adrian Farrel Old Dog Consulting EMail: firstname.lastname@example.org Zafar Ali Cisco Systems Inc. 2000 Innovation Drive Kanata, ON, K2K 3E8, Canada. Phone: 613-889-6158 Email: email@example.com Bill Fenner Arastra, Inc. 275 Middlefield Rd. Suite 50 Menlo Park, CA 94025 Email: firstname.lastname@example.org George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: email@example.com Thomas D. Nadeau British Telecom BT Centre 81 Newgate Street EC1A 7AJ London Email: firstname.lastname@example.org 14.Shaleen Saxena Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: email@example.com 11. Full Copyright Statement Copyright (C) The(c) 2009 IETF Trust (2008).and the persons identified as the document authors. All rights reserved. This document is subject to the rights, licenses and restrictions contained inBCP 78,78 and except as set forth therein,the authors retain all their rights. ThisIETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.restrictions with respect to this document.