Internet Engineering Task Force (IETF) S. Saxena, Ed. Request for Comments: 6425 G. Swallow Updates: 4379 Z. Ali Category: Standards Track Cisco Systems, Inc. ISSN: 2070-1721 A. Farrel Juniper Networks S. Yasukawa NTT Corporation T. Nadeau CA Technologies November 2011 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping
AbstractRecent 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. This document updates RFC 4379. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6425.
Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction ....................................................3 1.1. Design Considerations ......................................4 1.2. Terminology ................................................4 2. Notes on Motivation .............................................5 2.1. Basic Motivations for LSP Ping .............................5 2.2. Motivations for LSP Ping for P2MP LSPs .....................6 3. Packet Format ...................................................7 3.1. Identifying the LSP Under Test .............................8 3.1.1. Identifying a P2MP MPLS TE LSP ......................8 22.214.171.124. RSVP P2MP IPv4 Session Sub-TLV .............8 126.96.36.199. RSVP P2MP IPv6 Session Sub-TLV .............9 3.1.2. Identifying a Multicast LDP LSP .....................9 188.8.131.52. Multicast LDP FEC Stack Sub-TLVs ..........10 184.108.40.206. Applicability to Multipoint-to-Multipoint LSPs .............11 3.2. Limiting the Scope of Responses ...........................11 3.2.1. Egress Address P2MP Responder Sub-TLVs .............12 3.2.2. Node Address P2MP Responder Sub-TLVs ...............13 3.3. Preventing Congestion of Echo Replies .....................14
3.4. Respond Only If TTL Expired Flag ..........................14 3.5. Downstream Detailed Mapping TLV ...........................15 4. Operation of LSP Ping for a P2MP LSP ...........................15 4.1. Initiating LSR Operations .................................16 4.1.1. Limiting Responses to Echo Requests ................16 4.1.2. Jittered Responses to Echo Requests ................16 4.2. Responding LSR Operations .................................17 4.2.1. Echo Reply Reporting ...............................18 220.127.116.11. Responses from Transit and Branch Nodes ...19 18.104.22.168. Responses from Egress Nodes ...............19 22.214.171.124. Responses from Bud Nodes ..................19 4.3. Special Considerations for Traceroute .....................21 4.3.1. End of Processing for Traceroutes ..................21 4.3.2. Multiple Responses from Bud and Egress Nodes .......22 4.3.3. Non-Response to Traceroute Echo Requests ...........22 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Requests ......................................23 4.3.5. Cross-Over Node Processing .........................23 5. Non-Compliant Routers ..........................................24 6. OAM and Management Considerations ..............................24 7. IANA Considerations ............................................25 7.1. New Sub-TLV Types .........................................25 7.2. New TLVs ..................................................25 7.3. New Global Flags Registry .................................26 8. Security Considerations ........................................26 9. Acknowledgements ...............................................26 10. References ....................................................27 10.1. Normative References .....................................27 10.2. Informative References ...................................27 RFC4379]. The techniques involve information carried in MPLS "echo request" and "echo reply" messages, and mechanisms for transporting them. The echo request and reply messages provide sufficient information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. The use of reliable channels for echo reply messages as described in [RFC4379] enables more robust fault isolation. This collection of mechanisms is commonly referred to as "LSP ping". The requirements for point-to-multipoint (P2MP) MPLS traffic engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a signaling solution for establishing P2MP MPLS TE LSPs.
The requirements for P2MP extensions to the Label Distribution Protocol (LDP) are stated in [RFC6348]. [RFC6388] specifies extensions to LDP for P2MP MPLS. P2MP MPLS LSPs are at least as vulnerable to data-plane faults or to discrepancies between the control and data planes as their P2P counterparts. Therefore, mechanisms are needed to detect such data plane faults in P2MP MPLS LSPs as described in [RFC4687]. This document extends the techniques described in [RFC4379] such that they may be applied to P2MP MPLS LSPs. This document stresses the reuse of existing LSP ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify implementation and network operation. RFC5884]. As pointed out in [RFC4379], mechanisms to check the liveness, function, and consistency of the control plane are valuable, but such mechanisms are not a feature of LSP ping and are not covered in this document. As is described in [RFC4379], to avoid potential denial-of-service attacks, it is RECOMMENDED to regulate the LSP ping traffic passed to the control plane. A rate limiter should be applied to the incoming LSP ping traffic. RFC4461]. The terminology for MPLS OAM can be found in [RFC4379]. In particular, the notation <RSC> refers to the Return Subcode as defined in Section 3.1. of [RFC4379].
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]. 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. 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 [RFC6388] uses LDP 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 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 reply message is sent by an egress to the ingress to confirm the successful receipt (or announce the erroneous arrival) of the echo request.
In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR returns information about the outgoing paths. This information can be used by ingress LSRs to build topology or by downstream LSRs to do extra label verification. P2MP MPLS LSPs may have many egresses, and it is not necessarily the intention of the initiator of the ping or traceroute operation to collect information about the connectivity or path to all egresses. Indeed, in the event of pinging all egresses of a large P2MP MPLS LSP, it might be expected that a large number of echo replies would arrive at the ingress independently but at approximately the same time. Under some circumstances this might cause congestion at or around the ingress LSR. The procedures described in this document provide two mechanisms to control echo replies. The first procedure allows the responders to randomly delay (or jitter) their replies so that the chances of swamping the ingress are reduced. The second procedure allows the initiator to limit the scope of an LSP ping echo request (ping or traceroute mode) to one specific intended egress. LSP ping can be used to periodically ping a P2MP MPLS LSP to ensure connectivity to any or all of the egresses. If the ping fails, the operator or an automated process can then initiate a traceroute to 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. RFC4379]. Some new TLVs and sub-TLVs are required to support the new functionality. They are described in the following sections.
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 ---------- ------ ----------- 17 20 RSVP P2MP IPv4 Session 18 56 RSVP P2MP IPv6 Session 19.1.1 and 19.2.1 of [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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19.1.2 and 19.2.2 of [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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 of two new sub-TLVs: either a Multicast P2MP LDP FEC Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV. These sub- TLVs use fields from the multicast LDP messages [RFC6388] 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 section.
Sub-Type # Length Value Field ---------- ------ ----------- 19 Variable Multicast P2MP LDP FEC Stack 20 Variable Multicast MP2MP LDP FEC Stack IANA-AF] 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. Depending on the length of the Root LSR Address, this field may not be aligned to a word boundary.
Opaque Value An opaque value element that 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.
Four sub-TLVs are defined for inclusion in the P2MP Responder Identifier TLV carried on the echo request message. These are: Sub-Type # Length Value Field ---------- ------ ----------- 1 4 IPv4 Egress Address P2MP Responder 2 16 IPv6 Egress Address P2MP Responder 3 4 IPv4 Node Address P2MP Responder 4 16 IPv6 Node Address P2MP Responder The content of these sub-TLVs are defined in the following sections. Also defined is the intended behavior of the responding node upon receiving any of these sub-TLVs.
field of the S2L_SUB_LSP object, when corresponding egress or bud node is signaled. Thus, the IPv4 or IPv6 Egress Address P2MP Responder sub-TLV MAY be used in an echo request carrying RSVP P2MP Session sub-TLV. However, in Multicast LDP, there is no way for upstream LSRs to know the identity of the downstream leaf nodes. Hence, these TLVs cannot be used to perform traceroute to a single node when Multicast LDP FEC is used, and the IPv4 or IPv6 Egress Address P2MP Responder sub-TLV SHOULD NOT be used with an echo request carrying a Multicast LDP FEC Stack sub-TLV. If a node receives these TLVs in an echo request carrying Multicast LDP, then it will not respond since it is unaware of whether it lies on the path to the address in the sub-TLV.
in the sub-TLV does not match any address that is local to the node. The address in the sub-TLV may be of any physical interface or may be the router ID of the node itself. The address in this sub-TLV SHOULD be of any transit, branch, bud, or egress node for that P2MP LSP. The address of a node that is not on the P2MP LSP MAY be used as a check for that no reply is received. RFC4379]. The new format of the Global Flags field is: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |T|V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The V flag is described in [RFC4379].
The T (Respond Only If TTL Expired) flag MUST be set only in the echo request packet by the sender. This flag MUST NOT be set in the echo reply packet. If this flag is set in an echo reply packet, then it MUST be ignored. If the T flag is set to 0, then the receiving node MUST process the incoming echo request. If the T flag is set to 1 and the TTL of the incoming MPLS label is equal to 1, then the receiving node MUST process the incoming echo request. If the T flag is set to 1 and the TTL of the incoming MPLS label is more than 1, then the receiving node MUST drop the incoming echo request and MUST NOT send any echo reply to the sender. If the T flag is set to 1 and there are no incoming MPLS labels in the echo request packet, then a bud node with PHP configured MAY choose to not respond to this echo request. All other nodes MUST ignore this bit and respond as per regular processing. RFC6424]. 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 3.4 of [RFC6424], the Downstream Mapping TLV as described in [RFC4379] is being deprecated. Therefore, for P2MP, a node MUST support the Downstream Detailed Mapping TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP traceroute functionality and MUST NOT be included in an Echo Request message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC type or a Multicast P2MP/MP2MP LDP FEC type, a node MUST ignore any Downstream Mapping TLV it receives in the echo request and MUST continue processing as if the Downstream Mapping TLV is not present. The details of the Return Codes to be used in the Downstream Detailed Mapping TLV are provided in Section 4. 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. 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. Section 2.2, it may be desirable to restrict the operation of P2MP ping or traceroute to a single egress. Since echo requests are forwarded through the data plane without interception by the control plane, there is no facility to limit the propagation of echo requests, and they will automatically be forwarded to all reachable egresses. However, a single egress may be identified by the inclusion of a P2MP Responder Identifier TLV. The details of this TLV and its sub-TLVs are in Section 3.2. There are two main types of sub-TLVs in the P2MP Responder Identifier TLV: Node Address sub-TLV and Egress Address sub-TLV. These sub-TLVs limit the replies either to the specified LSR only or to any LSR on the path to the specified LSR. The former capability is generally useful for ping mode, while the latter is more suited to traceroute mode. An initiating LSR may indicate that it wishes all egresses to respond to an echo request by omitting the P2MP Responder Identifier TLV.
It is desirable for the initiating LSR to be able to control the bounds of the jitter. If the tree size is small, only a small amount of jitter is required, but if the tree is large, greater jitter is needed. The initiating LSR can supply the desired value of the jitter in the Echo Jitter TLV as defined in Section 3.3. If this TLV is present, the responding LSR MUST delay sending a reply for a random amount of time between zero milliseconds and the value indicated in the TLV. If the TLV is absent, the responding egress SHOULD NOT introduce any additional delay in responding to the echo request, but MAY delay according to local policy. LSP ping MUST 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 reply is often sent back through the control plane. The timestamp fields in the echo request and echo reply packets MAY be used to deduce some information about delivery times, for example 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 reply jittering SHOULD be used for P2MP LSPs, although it MAY be omitted for simple P2MP LSPs or when the Node Address P2MP Responder sub-TLVs are used. If the Echo Jitter TLV is present in an echo request for any other type of LSPs, the responding egress MAY apply the jitter behavior as described here. RFC4379]. As described in that document, a responding LSR SHOULD rate-limit the receipt of echo request messages. After rate-limiting, the responding LSR must verify the general sanity of the packet. If the packet is malformed or certain TLVs are not understood, the [RFC4379] procedures must be followed for echo reply. Similarly, the Reply Mode field determines if the reply is required or not (and the mechanism to send it back).
For P2MP LSP ping and traceroute, i.e., if the echo request is carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR MUST determine whether it is part of the P2MP LSP in question by checking with the control plane. - If the node is not part of the P2MP LSP, it MUST respond according to [RFC4379] processing rules. - If the node is part of the P2MP LSP, the node must check whether or not the echo request is directed to it. - If a P2MP Responder Identifier TLV is present, then the node must follow the procedures defined in Section 3.2 to determine whether or not it should respond to the request. The presence of a P2MP Responder Identifier TLV or a Downstream Detailed Mapping TLV might affect the Return Code. This is discussed in more detail later. - If the P2MP Responder Identifier TLV is not present (or, in the error case, is present, but does not contain any sub- TLVs), then the node MUST respond according to [RFC4379] processing rules. RFC4379]. When the responding node reports that it is an egress, it is clear that the echo reply applies only to that reporting node. Similarly, when a node reports that it does not form part of the LSP described by the FEC, then it is clear that the echo reply applies only to that reporting node. However, an echo reply message that reports an error from a transit node may apply to multiple egress nodes (i.e., leaves) downstream of the reporting node. In the case of the ping mode of operation, it is not possible to correlate the reporting node to the affected egresses unless the topology of the P2MP tree is already known, and it may be necessary to use the traceroute mode of operation to further diagnose the LSP. Note that a transit node may discover an error, but it may also determine that while it does lie on the path of the LSP under test, it does not lie on the path to the specific egress being tested. In this case, the node SHOULD NOT generate an echo reply unless there is a specific error condition that needs to be communicated.
The following sections describe the expected values of Return Codes for various nodes in a P2MP LSP. It is assumed that the sanity and other checks have been performed and an echo reply is being sent back. As mentioned in Section 4.2, the Return Code might change based on the presence of a Responder Identifier TLV or Downstream Detailed Mapping TLV. Section 3.1. of [RFC4379]. For error conditions, use appropriate values defined in [RFC4379]. The presence of a Downstream Detailed Mapping TLV will influence the choice of Return Code. As per [RFC6424], the Return Code in the echo reply header MAY be set to 'See DDM TLV for Return Code and Return Subcode' as defined in [RFC6424]. The Return Code for each Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424]. There will be a Downstream Detailed Mapping TLV for each downstream path being reported in the echo reply. Hence, for transit nodes, there will be only one such TLV, and for branch nodes, there will be more than one. If there is an Egress Address Responder sub-TLV, then the branch node will include only one Downstream Detailed Mapping TLV corresponding to the downstream path required to reach the address specified in the Egress Address sub-TLV. RFC4379]. The presence of the Downstream Detailed Mapping TLV does not influence the choice of Return Code. Egress nodes do not put in any Downstream Detailed Mapping TLV in the echo reply [RFC6424].
determined by the presence of any Responder Identifier TLV and the type of sub-TLV in it. Similarly, the Downstream Detailed Mapping TLV can influence the Return Code values. To determine the behavior of the bud node, use the following rules. The intent of these rules is to figure out if the echo request is meant for all nodes, or just this node, or for another node reachable through this node or for a different section of the tree. In the first case, the node will behave like a combination of egress and branch node; in the second case, the node will behave like pure egress node; in the third case, the node will behave like a transit node; and in the last case, no reply will be sent back. Node behavior rules: - If the Responder Identifier TLV is not present, then the node will behave as a combination of egress and branch node. - If the Responder Identifier TLV containing a Node Address sub- TLV is present, and: - If the address specified in the sub-TLV matches to an address in the node, then the node will behave like a combination of egress and branch node. - If the address specified in the sub-TLV does not match any address in the node, then no reply will be sent. - If the Responder Identifier TLV containing an Egress Address sub-TLV is present, and: - If the address specified in the sub-TLV matches to an address in the node, then the node will behave like an egress node only. - If the node lies on the path to the address specified in the sub-TLV, then the node will behave like a transit node. - If the node does not lie on the path to the address specified in the sub-TLV, then no reply will be sent. Once the node behavior has been determined, the possible values for Return Codes are as follows: - If the node is behaving as an egress node only, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined
in [RFC4379]. The echo reply MUST NOT contain any Downstream Detailed Mapping TLV, even if one is present in the echo request. - If the node is behaving as a transit node, and: - If a Downstream Detailed Mapping TLV is not present, then for a success response, the Return Code MAY be set to value 8 ('Label switched at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379]. - If a Downstream Detailed Mapping TLV is present, then the Return Code MAY be set to 'See DDM TLV for Return Code and Return Subcode' as defined in [RFC6424]. The Return Code for the Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424]. There will be only one Downstream Detailed Mapping corresponding to the downstream path to the address specified in the Egress Address sub-TLV. - If the node is behaving as a combination of egress and branch node, and: - If a Downstream Detailed Mapping TLV is not present, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379]. - If a Downstream Detailed Mapping TLV is present, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379]. The Return Code for the each Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424]. There will be a Downstream Detailed Mapping for each downstream path from the node. RFC4379], the traceroute mode operates by sending a series of echo requests with sequentially increasing TTL values. For regular P2P targets, this processing stops when a valid reply is received from the intended egress or when some errored return code is received.
For P2MP targets, there may not be an easy way to figure out the end of the traceroute processing, as there are multiple egress nodes. Receiving a valid reply from an egress will not signal the end of processing. For P2MP TE LSP, the initiating LSR has a priori knowledge about the number of egress nodes and their addresses. Hence, it is possible to continue processing until a valid reply has been received from each end point, provided that the replies can be matched correctly to the egress nodes. However, for Multicast LDP LSP, the initiating LSR might not always know about all of the egress nodes. Hence, there might not be a definitive way to estimate the end of processing for traceroute. Therefore, it is RECOMMENDED that traceroute operations provide for a configurable upper limit on TTL values. Hence, the user can choose the depth to which the tree will be probed. Section 3.4. It is RECOMMENDED that this flag be used for P2MP traceroute mode only. By using this flag, extraneous replies from bud and egress nodes can be reduced. If PHP is being used in the P2MP tree, then bud and egress nodes will not get any labels with the echo request packet. Hence, this mechanism will not be effective for PHP scenarios.
When no reply to an echo request is received by the ingress, then (as per [RFC4379]) the subsequent echo request with a larger TTL SHOULD be sent in order to trace further toward the egress, although the ingress MAY halt the procedure at this point. The time that an ingress waits before sending the subsequent echo request is an implementation choice. Section 4.6 of [RFC4379], an initiating LSR, during traceroute, SHOULD copy the Downstream Mapping(s) into its next echo request(s). However, for P2MP LSPs, the initiating LSR will receive multiple sets of Downstream Detailed Mapping TLVs from different nodes. It is not practical to copy all of them into the next echo request. Hence, this behavior is being modified for P2MP LSPs. If the echo request is destined for more than one node, then the Downstream IP Address field of the Downstream Detailed Mapping TLV MUST be set to the ALLROUTERS multicast address, and the Address Type field MUST be set to either IPv4 Unnumbered or IPv6 Unnumbered depending on the Target FEC Stack TLV. If an Egress Address Responder sub-TLV is being used, then the traceroute is limited to only one egress. Therefore this traceroute is effectively behaving like a P2P traceroute. In this scenario, as per Section 4.2, the echo replies from intermediate nodes will contain only one Downstream Detailed Mapping TLV corresponding to the downstream path required to reach the address specified in the Egress Address sub-TLV. For this case, the echo request packet MAY reuse a received Downstream Detailed Mapping TLV. This will allow interface validation to be performed as per [RFC4379]. RFC4875]. The term "cross-over" refers to the case of an ingress or transit node that creates a branch of a P2MP LSP, a cross-over branch, that intersects the P2MP LSP at another node farther down the tree. It is unlike re-merge in that, at the intersecting node, the cross-over branch has a different outgoing interface as well as a different incoming interface. During traceroute, a cross-over node will receive the echo requests via each of its input interfaces. Therefore, the Downstream Detailed Mapping TLV in the echo reply MUST carry information only about the outgoing interface corresponding to the input interface.
If this restriction is applied, the cross-over node will not duplicate the outgoing interface information in each of the echo request it receives via the different input interfaces. This will reflect the actual packet replication in the data plane.
- 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. RFC4379] Target FEC Stack TLV (TLV type 1). IANA has assigned sub-type values to the following sub-TLVs under TLV type 1 (Target FEC Stack) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry. 17 RSVP P2MP IPv4 Session (Section 3.1.1) 18 RSVP P2MP IPv6 Session (Section 3.1.1) 19 Multicast P2MP LDP FEC Stack (Section 3.1.2) 20 Multicast MP2MP LDP FEC Stack (Section 3.1.2) Section 3.2) is a mandatory TLV. Four sub-TLVs are defined. - Sub-Type 1: IPv4 Egress Address P2MP Responder - Sub-Type 2: IPv6 Egress Address P2MP Responder - Sub-Type 3: IPv4 Node Address P2MP Responder - Sub-Type 4: IPv6 Node Address P2MP Responder 12 Echo Jitter TLV (see Section 3.3) is a mandatory TLV.
RFC4379] 14 | T Flag | [RFC6425] 13-0 | Unassigned | RFC4379]. Note that because of the scalability implications of many egresses to P2MP MPLS LSPs, there is a stronger concern about regulating 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. This rate limiting might lead to false indications of LSP failure. 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 reviews, and to Yakov Rekhter for useful discussions. The authors would like to thank Bill Fenner, Vanson Lim, Danny Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar, Sam Aldrin, and IJsbrand Wijnands for their comments and suggestions.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing LSP-Ping over MPLS Tunnels", RFC 6424, November 2011. [IANA-AF] IANA Assigned Port Numbers, <http://www.iana.org/assignments/address-family-numbers>. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point- to-Multipoint MPLS Networks", RFC 4687, September 2006. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC6348] Le Roux, JL., Ed., and T. Morin, Ed., "Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011.