--- 1/draft-ietf-mpls-p2mp-lsp-ping-04.txt 2007-10-29 06:12:06.000000000 +0100 +++ 2/draft-ietf-mpls-p2mp-lsp-ping-05.txt 2007-10-29 06:12:06.000000000 +0100 @@ -1,18 +1,20 @@ Network Working Group Seisho Yasukawa (Editor) Internet-Draft NTT Intended Status: Standards Track Adrian Farrel (Editor) -Expires: September 2007 Old Dog Consulting +Created: October 28, 2007 Old Dog Consulting +Expires: April 28, 2008 + Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping - draft-ietf-mpls-p2mp-lsp-ping-04.txt + draft-ietf-mpls-p2mp-lsp-ping-05.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 she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -35,45 +37,45 @@ 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 recognised 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 mechanism of + 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. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Contents 1. Introduction ................................................... 4 1.1 Design Considerations ......................................... 4 2. Notes on Motivation ............................................ 5 2.1. Basic Motivations for LSP Ping ............................... 5 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 6 - 2.3 Bootstrapping other OAM Procedures using LSP Ping ............. 7 + 2.3 Bootstrapping Other OAM Procedures Using LSP Ping ............. 7 3. Operation of LSP Ping for a P2MP LSP ........................... 8 3.1. Identifying the LSP Under Test ............................... 8 3.1.1. Identifying a P2MP MPLS TE LSP ............................. 8 - 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 8 + 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 9 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 9 - 3.1.2. Identifying a Multicast LDP LSP ............................ 9 + 3.1.2. Identifying a Multicast LDP LSP ........................... 10 3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10 3.2. Ping Mode Operation ......................................... 11 3.2.1. Controlling Responses to LSP Pings ........................ 11 3.2.2. Ping Mode Egress Procedures ............................... 12 3.2.3. Jittered Responses ........................................ 12 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 13 3.2.5. Echo Jitter TLV ........................................... 14 3.3. Traceroute Mode Operation ................................... 14 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15 3.3.1.1. Correlating Traceroute Responses ........................ 15 @@ -109,21 +111,21 @@ - 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]. + - 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. @@ -142,92 +144,101 @@ - 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. + 1. Introduction Simple and efficient mechanisms that can be used to detect data plane - failures in point-to-point (P2P) MPLS 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 reply channels for echo - request messages as described in [RFC4379] enables more robust fault - isolation. This collection of mechanisms is commonly referred to as - "LSP Ping". + 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]. [P2MP-RSVP] specifies a + 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 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. + 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 would - 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. + 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 bootsrap 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. + 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 would enable users to detect such traffic "black holes" or - misrouting within a reasonable period of time; and a mechanism to - isolate faults. + 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) @@ -245,57 +256,57 @@ that it is indeed a transit LSR for this path; this LSR also returns further information that helps to check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path. One way these tools can be used is to periodically ping a FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs - and thus should be used with caution. + 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 + 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 + 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 [P2MP-RSVP] may be viewed as MPLS tunnels with a + 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 + 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 @@ -312,118 +323,118 @@ 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 or a set of egresses. + 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 utilise 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 +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 - desribed in [MCAST-CV]. It relies on using the MPLS Echo - Request/Response messages of LSP Ping [RFC4379] to bootstrap the + desribed 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 LSRs and receivers (egresses). + initiator (ingress), transit LSRs, 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 or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry - fields from the RSVP-TE P2MP Session and Sender-Template objects - [P2MP-RSVP] and so provide sufficient information to uniquely + Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs + carry fields from the RSVP-TE P2MP Session and Sender-Template + objects [RFC4875] and so provide sufficient information to uniquely identify the LSP. The new sub-TLVs are assigned sub-type identifiers as follows, and are described in the following sections. Sub-Type # Length Value Field ---------- ------ ----------- TBD 20 RSVP P2MP IPv4 Session TBD 56 RSVP P2MP IPv6 Session 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV - The format of the RSVP P2MP IPv4 Session Sub-TLV value field is + The format of the RSVP P2MP IPv4 Session sub-TLV value field is specified in the following figure. The value fields are taken from - the definitions of the P2MP IPv4 LSP Session Object, and the P2MP - IPv4 Sender-Template Object in [P2MP-RSVP]. Note that the Sub-Group + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV - The format of the RSVP P2MP IPv6 Session Sub-TLV value field is + The format of the RSVP P2MP IPv6 Session sub-TLV value field is specified in the following figure. The value fields are taken from the definitions of the P2MP IPv6 LSP Session Object, and the - P2MP IPv6 Sender-Template Object in [P2MP-RSVP]. Note that the + 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 | @@ -436,39 +447,39 @@ | 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 + 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-TLVs: the Multicast LDP FEC Stack Sub-TLV. This - Sub-TLVs fields from the multicast LDP messages [P2MP-LDP] and so + 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 sections. + is described in the following section. Sub-Type # Length Value Field ---------- ------ ----------- TBD Variable Multicast LDP FEC Stack 3.1.2.1. Multicast LDP FEC Stack Sub-TLV - The format of the Multicast LDP FEC Stack Sub-TLV is shown below. + The format of the Multicast LDP FEC Stack sub-TLV is shown below. 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.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -535,58 +546,58 @@ 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 LSR is RECOMMENDED to rate limit its receipt of echo request messages as described in [RFC4379]. After rate limiting, an egress LSR 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 intended egress + LDP FEC Stack sub-TLV MUST determine whether it is an intended egress of the P2MP LSP in question by checking with the control plane. If it is not supposed to be an egress, it MUST respond according to the setting of the Response Type field in the echo message following the rules defined in [RFC4379]. If the egress LSR that receives an echo request and allows it through its rate limiting is an intended egress of the P2MP LSP, the LSR MUST check to see whether it is an intended Ping recipient. If a P2MP Egress Identifier TLV is present and contains an address that indicates any address that is local to the LSR, the LSR MUST respond according to the setting of the Response Type field in the echo message following the rules defined in [RFC4379]. If the P2MP Egress Identifier TLV is present, but does not identify the egress LSR, it MUST NOT respond to the echo request. If the P2MP Egress Identifier TLV is not present (or, in the error case, is present but does not - a sub-TLVs), but the egress LSR that received the echo request is an - intended egress of the LSP, the LSR MUST respond according to the - setting of the Response Type field in the echo message following the - rules defined in [RFC4379]. + contain any sub-TLVs), but the egress LSR that received the echo + request is an intended egress of the LSP, the LSR 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 + 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, + 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 seconds 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 @@ -622,21 +633,21 @@ 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 Egress Identifier TLV only has meaning on an echo request message. If present on an echo response message, it SHOULD be ignored. - Two Sub-TLVs are defined for inclusion in the P2MP Egress Identifier + Two sub-TLVs are defined for inclusion in the P2MP Egress Identifier TLV carried on the echo request message. These are: Sub-Type # Length Value Field ---------- ------ ----------- 1 4 IPv4 P2MP Egress Identifier 2 16 IPv6 P2MP Egress Identifier The value of an IPv4 P2MP Egress Identifier consists of four octets of an IPv4 address. The IPv4 address is in network byte order. The value of an IPv6 P2MP Egress Identifier consists of sixteen @@ -710,21 +721,21 @@ packet MUST be passed to the control plane as specified in [RFC4379]. If the LSP under test is a multicast LDP LSP and if the echo request carries a P2MP Egress Identifier TLV the LSR MUST treat the echo request as malformed and MUST process it according to the rules specified in [RFC4379]. Otherwise, the LSR MUST NOT return an echo response unless the responding LSR lies on the path of the P2MP LSP to the egress identified by the P2MP Egress Identifier TLV carried on the request, - or if no such Sub-TLV is present. + or if no such sub-TLV is present. If sent, the echo response MUST identifiy the next hop of the path of the LSP in the data plane by including a Downstream Mapping TLV as described in [RFC4379]. 3.3.1.1. Correlating Traceroute Responses When traceroute is being simultaneously applied to multiple egresses, it is important that the ingress should be able to correlate the echo responses with the branches in the P2MP tree. Without this @@ -937,25 +948,25 @@ Egress Address An egress of this P2MP MPLS TE LSP that is reached through the interface indicated by the Downstream Mapping TLV and for which the traceroute echo request was enquiring. 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms Bootstrapping of other OAM procedures can be achieved using the MPLS Echo Request/Response messages. The LSP(s) under test are - identified using the RSVP P2MP IPv4 or IPv6 Session Sub-TLVs - (see Section 3.1.1) or the Multicast LDP FEC Stack Sub-TLV + identified using the RSVP P2MP IPv4 or IPv6 Session sub-TLVs + (see Section 3.1.1) or the Multicast LDP FEC Stack sub-TLV (see Section 3.1.2). - Other Sub-TLVs may be defined in other specifications to indicate + Other sub-TLVs may be defined in other specifications to indicate the OAM procedures being bootstrapped, and to describe the bootstrap parameters. Further details of the bootstrapping processes and the bootstrapped OAM processes are described in other documents. For example, see [MPLS-BFD] and [MCAST-CV]. 5. 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 @@ -1005,25 +1016,25 @@ - A MIB module is required for the control and management of LSP Ping operations, and to enable the reported information to be inspected. There is no reason to believe this should not be a simple extension of the LSP Ping MIB module used for P2P LSPs. 7. IANA Considerations 7.1. New Sub-TLV Types - Three new Sub-TLV types are defined for inclusion within the LSP Ping + 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) + sub-TLVs from the Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters - TLVs registry. RSVP P2MP IPv4 Session (see Section 3.1.1) RSVP P2MP IPv6 Session (see Section 3.1.1) Multicast LDP FEC Stack (see Section 3.1.2) 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. @@ -1129,23 +1140,24 @@ [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. - [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to - Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, - work in progress. + [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. @@ -1189,24 +1200,26 @@ United States Email: fenner@research.att.com George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: swallow@cisco.com Thomas D. Nadeau - Cisco Systems, Inc. - 1414 Massachusetts Ave - Boxborough, MA 01719 - Email: tnadeau@cisco.com + British Telecom + BT Centre + 81 Newgate Street + EC1A 7AJ + London + Email: tom.nadeau@bt.com 14. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an