idnits 2.17.1 draft-yasukawa-mpls-p2mp-lsp-ping-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 780. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 852), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2005) is 6950 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3667' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 807, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Seisho Yasukawa (NTT) 2 IETF Internet Draft Adrian Farrel (Olddog Consulting) 3 Proposed Status: Standards Track Zafar Ali (Cisco Systems) 4 Expires: October 2005 Bill Fenner (AT&T Research) 6 April 2005 8 Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic 9 Engineering - Extensions to LSP Ping 11 draft-yasukawa-mpls-p2mp-lsp-ping-02.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she becomes aware will be disclosed, in accordance with 20 Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 42 Abstract 44 Recent proposals have extended the scope of Multi-Protocol Label 45 Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) 46 to encompass point-to-multipoint (P2MP) TE LSPs. 48 The requirement for a simple and efficient mechanism that can be 49 used to detect data plane failures in point-to-point (P2P) MPLS LSPs 50 has been recognised and has led to the development of techniques 51 for fault detection and isolation commonly referred to as "LSP Ping". 53 The scope of this document is fault detection and isolation for P2MP 54 MPLS TE LSPs. This documents does not replace any of the mechanism of 55 LSP Ping, but clarifies their applicability to P2MP MPLS TE LSPs, and 56 extends the techniques and mechanisms of LSP Ping to the P2MP TE 57 environment. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Contents 67 1. Introduction ................................................... 3 68 1.1 Design Considerations ...................................... 3 69 2. Notes on Motivation ............................................ 4 70 2.1. Basic Motivations for LSP Ping ............................ 4 71 2.2. Motivations for LSP Ping for P2MP TE LSPs ................. 5 72 3. Operation of LSP Ping for a P2MP TE LSP ........................ 6 73 3.1. Identifying the LSP Under Test ............................ 6 74 3.1.1. RSVP P2MP IPv4 Session Sub-TLV .......................... 6 75 3.1.2. RSVP P2MP IPv6 Session Sub-TLV .......................... 7 76 3.2. Ping Mode Operation ....................................... 7 77 3.2.1. Controlling Responses to LSP Pings ...................... 7 78 3.2.2. P2MP Egress Identifier sub-TLVs ......................... 9 79 3.2.3. Echo Jitter TLV ......................................... 9 80 3.3. Traceroute Mode Operation ................................ 10 81 3.3.1. Traceroute Responses at Non-Branch Nodes ............... 10 82 3.3.2. Traceroute Responses at Branch Nodes .................. 11 83 3.3.3. Traceroute Responses at Bud Nodes ...................... 12 84 3.3.4. Non-Response to Traceroute Echo Requests ............... 12 85 3.3.5. Modifications to the Downstream Mapping TLV ............ 12 86 3.3.6. Additions to Downstream Mapping Multipath Information .. 13 87 4. Non-compliant Routers ......................................... 14 88 5. OAM Considerations ............................................ 15 89 6. IANA Considerations ........................................... 15 90 6.1. New Sub TLV Types ........................................ 15 91 6.2. New Multipath Type ....................................... 16 92 7. Security Considerations ....................................... 16 93 8. Acknowledgements .............................................. 16 94 9. Intellectual Property Considerations .......................... 16 95 10. Normative References ......................................... 17 96 11. Informational References ..................................... 17 97 12. Authors' Addresses ........................................... 17 98 13. Full Copyright Statement ..................................... 18 100 1. Introduction 102 Simple and efficient mechanisms that can be used to detect data plane 103 failures in point-to-point (P2P) MPLS LSP are described in 104 [LSP-PING]. The techniques involve information carried in an MPLS 105 "echo request" and "echo reply", and mechanisms for transporting the 106 echo reply. The echo request and reply messages provide sufficient 107 information to check correct operation of the data plane, as well as 108 a mechanism to verify the data plane against the control plane, and 109 thereby localize faults. The use of reliable reply channels for echo 110 request messages as described in [LSP-PING] enables more robust fault 111 isolation. This collection of mechanisms is commonly referred to as 112 "LSP Ping". 114 The requirement for point-to-multipoint (P2MP) MPLS traffic 115 engineered (TE) LSPs is stated in [P2MP-REQ]. [P2MP-RSVP] specifies a 116 signaling solution for establishing P2MP MPLS TE LSPs. P2MP MPLS TE 117 LSPs are at least as vulnerable to data plane faults or to 118 discrepancies between the control and data planes as their P2P 119 counterparts. LSP Ping Mechanisms are, therefore, also desirable to 120 detect such data plane faults in P2MP MPLS TE LSPs. 122 This document extends the techniques described in [LSP-PING] such 123 that they may be applied to P2MP MPLS TE LSPs. This document stresses 124 the reuse of existing LSP Ping mechanisms used for P2P LSPs, and 125 applies them to P2MP MPLS TE LSPs in order to simplify implementation 126 and network operation. 128 1.1 Design Considerations 130 As mentioned earlier, an important consideration for designing LSP 131 Ping for P2MP MPLS TE LSPs is that every attempt is made to use or 132 extend existing mechanisms rather than invent new mechanisms. 134 As for P2P LSPs, a critical requirement is that the echo request 135 messages follow the same data path that normal MPLS packets would 136 traverse. However, it can be seen this notion needs to be extended 137 for P2MP MPLS TE LSPs, as in this case an MPLS packet is replicated 138 so that it arrives at each egress (or leaf) of the P2MP tree. 140 MPLS echo requests are meant primarily to validate the data plane, 141 and they can then be used to validate against the control plane. 142 As pointed out in [LSP-PING], mechanisms to check the liveness, 143 function and consistency of the control plane are valuable, but such 144 mechanisms are not covered in this document. 146 As is described in [LSP-PING], to avoid potential Denial of Service 147 attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to 148 the control plane. A rate limiter should be applied to the well-known 149 UDP port defined for use by LSP Ping traffic. 151 2. Notes on Motivation 153 2.1. Basic Motivations for LSP Ping 155 The motivations listed in [LSP-PING] are reproduced here for 156 completeness. 158 When an LSP fails to deliver user traffic, the failure cannot always 159 be detected by the MPLS control plane. There is a need to provide a 160 tool that would enable users to detect such traffic "black holes" or 161 misrouting within a reasonable period of time; and a mechanism to 162 isolate faults. 164 [LSP-PING] describes a mechanism that accomplishes these goals. This 165 mechanism is modeled after the ping/traceroute paradigm: ping (ICMP 166 echo request [RFC792]) is used for connectivity checks, and 167 traceroute is used for hop-by-hop fault localization as well as path 168 tracing. [LSP-PING] specifies a "ping mode" and a "traceroute" mode 169 for testing MPLS LSPs. 171 The basic idea as expressed in [LSP-PING] is to test that the packets 172 that belong to a particular Forwarding Equivalence Class (FEC) 173 actually end their MPLS path on an LSR that is an egress for that 174 FEC. [LSP-PING] achieves this test by sending a packet (called an 175 "MPLS echo request") along the same data path as other packets 176 belonging to this FEC. An MPLS echo request also carries information 177 about the FEC whose MPLS path is being verified. This echo request is 178 forwarded just like any other packet belonging to that FEC. In "ping" 179 mode (basic connectivity check), the packet should reach the end of 180 the path, at which point it is sent to the control plane of the 181 egress LSR, which then verifies that it is indeed an egress for the 182 FEC. In "traceroute" mode (fault isolation), the packet is sent to 183 the control plane of each transit LSR, which performs various checks 184 that it is indeed a transit LSR for this path; this LSR also returns 185 further information that helps to check the control plane against the 186 data plane, i.e., that forwarding matches what the routing protocols 187 determined as the path. 189 One way these tools can be used is to periodically ping a FEC to 190 ensure connectivity. If the ping fails, one can then initiate a 191 traceroute to determine where the fault lies. One can also 192 periodically traceroute FECs to verify that forwarding matches the 193 control plane; however, this places a greater burden on transit LSRs 194 and thus should be used with caution. 196 2.2. Motivations for LSP Ping for P2MP TE LSPs 198 P2MP MPLS TE LSPs may be viewed as MPLS tunnels with a single ingress 199 and multiple egresses. MPLS packets inserted at the ingress are 200 delivered equally (barring faults) to all egresses. There is no 201 concept or applicability of an FEC in the context of a P2MP MPLS TE 202 LSP. 204 In consequence, the basic idea of LSP Ping for P2MP MPLS TE LSPs may 205 be expressed as an intention to test that packets that enter (at the 206 ingress) a particular P2MP MPLS TE LSP actually end their MPLS path 207 on the LSRs that are the (intended) egresses for that LSP. The idea 208 may be extended to check selectively that such packets reach a 209 specific egress. 211 The technique in this document makes this test by sending an LSP Ping 212 echo request message along the same data path as the MPLS packets. An 213 echo request also carries the identification of the P2MP MPLS TE LSP 214 that it is testing. The echo request is forwarded just as any other 215 packet using that LSP. In "ping" mode (basic connectivity check), the 216 echo request should reach the end of the path, at which point it is 217 sent to the control plane of the egress LSR, which then verifies that 218 it is indeed an egress (leaf) of the P2MP MPLS TE LSP. An echo 219 response message is sent by the egress to the ingress to confirm the 220 successful receipt (or announce the erroneous arrival) of the echo 221 request. 223 In "traceroute" mode (fault isolation), the echo request is sent to 224 the control plane at each transit LSR, and the control plane checks 225 that it is indeed a transit LSR for this P2MP MPLS TE LSP. The 226 transit LSR also returns information on an echo response that helps 227 verify the control plane against the data plane. That is, the 228 information is used by the ingress to check that the data plane 229 forwarding matches what is signaled by the control plane. 231 P2MP MPLS TE LSPs may have many egresses, and it is not necessarily 232 the intention of the initiator of the ping or traceroute operation to 233 collect information about the connectivity or path to all egresses. 234 Indeed, in the event of pinging all egresses of a large P2MP MPLS TE 235 LSP, it might be expected that a large number of echo responses would 236 arrive at the ingress independently but at approximately the same 237 time. Under some circumstances this might cause congestion at or 238 around the ingress LSR. Therefore, the procedures described in this 239 document provide the ability for the initiator to limit the scope of 240 an LSP Ping echo request (ping or traceroute mode) to one specific 241 intended egress of the P2MP MPLS TE LSP, or to target all egresses. 242 Further, in the event that the initiator wishes to use ping or 243 traceroute to a large number of leaves simultaneously, this document 244 provides a procedure that allows the responders to randomly delay or 245 jitter their responses so that the chances of swamping the ingress 246 are reduced. 248 LSP Ping can be used to periodically ping a P2MP MPLS TE LSP to 249 ensure connectivity to any or all of the egresses. If the ping fails, 250 the operator or an automated process can then initiate a traceroute 251 to determine where the fault is located within the network. A 252 traceroute may also be used periodically to verify that data plane 253 forwarding matches the control plane state; however, this places an 254 increased burden on transit LSRs and should be used infrequently and 255 with caution. 257 3. Operation of LSP Ping for a P2MP TE LSP 259 This section describes how LSP Ping is applied to P2MP MPLS TE LSPs. 260 It covers the mechanisms and protocol fields applicable to both ping 261 mode and traceroute mode. It explains the responsibilities of the 262 initiator (ingress), transit LSRs and receivers (egresses). 264 3.1. Identifying the LSP Under Test 266 [LSP-PING] defines how an MPLS TE LSP under test may be identified in 267 an echo request. A Target FEC Stack TLV is used to carry either an 268 RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. 270 In order to identify the P2MP MPLS TE LSP under test, the echo 271 request message MUST carry a Target FEC Stack TLV, and this MUST 272 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 273 Session or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry 274 the various fields from the RSVP-TE P2MP Session and Sender-Template 275 objects [P2MP-RSVP] and so provide sufficient information to uniquely 276 identify the LSP. 278 The new sub-TLVs are assigned sub-type identifiers as follows, and 279 are described in the following sections. 281 Sub-Type # Length Value Field 282 ---------- ------ ----------- 283 TBD 20 RSVP P2MP IPv4 Session 284 TBD 56 RSVP P2MP IPv6 Session 286 3.1.1. RSVP P2MP IPv4 Session Sub-TLV 288 The format of the RSVP P2MP IPv4 Session Sub-TLV value field is 289 specified in the following figure. The value fields are taken from 290 the definitions of the P2MP IPv4 LSP Session Object, and the P2MP 291 IPv4 Sender-Template Object in [P2MP-RSVP]. Note that the Sub-Group 292 ID of the Sender-Template is not required. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | P2MP ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Must Be Zero | Tunnel ID | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Extended Tunnel ID | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | IPv4 tunnel sender address | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Must Be Zero | LSP ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 3.1.2. RSVP P2MP IPv6 Session Sub-TLV 310 The format of the RSVP P2MP IPv6 Session Sub-TLV value field is 311 specified in the following figure. The value fields are taken from 312 the definitions of the P2MP IPv6 LSP Session Object, and the 313 P2MP IPv6 Sender-Template Object in [P2MP-RSVP]. Note that the 314 Sub-Group ID of the Sender-Template is not required. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 | P2MP ID | 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Must Be Zero | Tunnel ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 | Extended Tunnel ID | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 | IPv6 tunnel sender address | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Must Be Zero | LSP ID | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 3.2. Ping Mode Operation 338 3.2.1. Controlling Responses to LSP Pings 340 As described above, it may be desirable to restrict the operation 341 of LSP Ping to a single egress. Since echo requests are forwarded 342 through the data plane without interception by the control plane 343 (compare with traceroute mode), there is no facility to limit the 344 propagation of echo requests, and they will automatically be 345 forwarded to all (reachable) egresses. 347 However, the intended egress under test is identified in the FEC 348 Stack TLV by the inclusion of an IPv4 P2MP Egress Identifier sub-TLV 349 or an IPv6 P2MP Egress Identifier sub-TLV. Such TLVs, if used, MUST 350 be placed after the RSVP P2MP IPv4/6 Session sub-TLV. 352 An initiator may indicate that it wishes all egresses to respond to 353 an echo request by omitting all P2MP Egress Identifier sub-TLVs. 355 An egress LSR that receives an echo request carrying an RSVP P2MP 356 IPv4/6 Session sub-TLV MUST determine whether it is an intended 357 egress of the P2MP LSP in question by checking with the control 358 plane. If it is not supposed to be an egress, it MUST respond 359 according to the setting of the Response Type field in the echo 360 message following the rules defined in [LSP-PING]. 362 If the egress that receives an echo request is an intended egress, 363 the LSR MUST check to see whether it is an intended Ping recipient. 364 If a P2MP Egress Identifier sub-TLV is present and contains an 365 address that indicates any address that is local to the egress LSR, 366 it MUST respond according to the setting of the Response Type field 367 in the echo message following the rules defined in [LSP-PING]. If the 368 P2MP Egress Identifier sub-TLV is present, but does not identify the 369 egress LSR, it MUST NOT respond to the echo request. If the P2MP 370 Egress identifier is not present, but the egress that received the 371 echo request is an intended egress, it MUST respond according to 372 the setting of the Response Type field in the echo message following 373 the rules defined in [LSP-PING]. 375 The initiator (ingress) of a ping request MAY request the responding 376 egress to introduce a random delay (or jitter) before sending the 377 response. The randomness of the delay allows the responses from 378 multiple egresses to be spread over a time period. Thus, this 379 technique is particularly relevant when the entire LSP tree is being 380 pinged since it helps prevent the ingress (or nearby routers) from 381 being swamped by responses, or from discarding responses due to rate 382 limits that have been applied. 384 It is desirable for the ingress to be able to control the bounds 385 within which the egress delays the response. If the tree size is 386 small only a small amount of jitter is required, but if the tree is 387 large greater jitter is needed. The ingress informs the egresses of 388 the jitter bound by supplying a value in a new TLV (the Echo Jitter 389 TLV) carried on the Echo request message. If this TLV is present, 390 the responding egress MUST delay sending a response for a random 391 amount of time between zero seconds and the value indicated in the 392 TLV. If the TLV is absent, the responding egress SHOULD NOT introduce 393 any additional delay in responding to the echo request. 395 LSP ping SHOULD NOT be used to attempt to measure the round-trip 396 time for data delivery. This is because the LSPs are unidirectional, 397 and the echo response is often sent back through the control plane. 398 The timestamp fields in the echo request/response MAY be used to 399 deduce some information about delivery times and particularly the 400 variance in delivery times. 402 The use of echo jittering does not change the processes for gaining 403 information, but note that the responding egress MUST set the value 404 in the Timestamp Received fields before applying any delay. 406 It is RECOMMENDED that echo response jittering is not used except in 407 the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo 408 request for any other type of TLV, the responding egress MAY apply 409 the jitter behavior described here. 411 3.2.2. P2MP Egress Identifier sub-TLVs 413 Two new sub-TLVs are defined for inclusion in the Target FEC Stack 414 TLV (type 1) carried on the echo request message. These are: 416 Sub-Type # Length Value Field 417 ---------- ------ ----------- 418 (TBD) 4 IPv4 P2MP Egress Identifier 419 (TBD) 16 IPv6 P2MP Egress Identifier 421 The value of an IPv4 P2MP Egress Identifier consists of four octets 422 of an IPv4 address. The IPv4 address is in network byte order. 424 The value of an IPv6 P2MP Egress Identifier consists of sixteen 425 octets of an IPv6 address. The IPv6 address is in network byte order. 427 3.2.3. Echo Jitter TLV 429 A new TLV is defined for inclusion in the Echo request message. 431 The Echo Jitter TLV is assigned the TLV type value TBD and is encoded 432 as follows. 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type = TBD (Jitter TLV) | Length = 4 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Jitter time | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Jitter time: 443 This field specifies the upper bound of the jitter period that 444 should be applied by a responding egress to determine how long 445 to wait before sending an echo response. An egress SHOULD wait 446 a random amount of time between zero seconds and the value 447 specified in this field. 449 Jitter time is specified in milliseconds. 451 The Echo Jitter TLV only has meaning on an echo request message. If 452 present on an echo response message, it SHOULD be ignored. 454 3.3. Traceroute Mode Operation 456 The traceroute mode of operation is described in [LSP-PING]. Like 457 other traceroute operations, it relies on the expiration of the TTL 458 of the packet that carries the echo request. Echo requests may 459 include a Downstream Mapping TLV and when the TTL expires the echo 460 request is passed to the control plane on the transit LSR which 461 responds according to the Response Type in the message. A responding 462 LSR fills in the fields of the Downstream Mapping TLV to indicate the 463 downstream interfaces and labels used by the reported LSP from the 464 responding LSR. In this way, by successively sending out echo 465 requests with increasing TTLs, the ingress may gain a picture of the 466 path and resources used by an LSP up to the point of failure when no 467 response is received, or an error response is generated by an LSR 468 where the control plane does not expect to be handling the LSP. 470 This mode of operation is equally applicable to P2MP MPLS TE LSPs 471 as described in the following sections. 473 The traceroute mode can be applied to a single destination, or to all 474 destinations of the P2MP tree just as in the ping mode. That is, the 475 IPv4/6 P2MP Egress Identifier sub-TLVs may be used to identify a 476 specific egress for which traceroute information is requested. In the 477 absence of an IPv4/6 P2MP Egress Identifier sub-TLV, the echo request 478 is asking for traceroute information applicable to all egresses. 480 The echo response jitter technique described for the ping mode is 481 equally applicable to the traceroute mode and is not additionally 482 described in the procedures below. 484 3.3.1. Traceroute Responses at Non-Branch Nodes 486 When the TTL for the MPLS packet carrying an echo request expires and 487 the message is passed to the control plane, an echo response MUST 488 only be returned if the responding LSR lies on the path to the egress 489 identified by the IPv4/6 P2MP Egress Identifier carried on the 490 request, or if no such sub-TLV is present. 492 The echo response identifies the next hop of the path in the data 493 plane by including a Downstream Mapping TLV as described in 494 [LSP-PING]. 496 When traceroute is being simultaneously applied to multiple egresses, 497 it is important that the ingress should be able to correlate the echo 498 responses with the branches in the P2MP tree. Without this 499 information the ingress will be unable to determine the correct 500 ordering of transit nodes. One possibility is for the ingress to poll 501 the path to each egress in turn, but this may be inefficient or 502 undesirable. Therefore, the echo response contains additional 503 information in the Multipath Information field of the Downstream 504 Mapping TLV that identifies to which egress/egresses the echo 505 response applies. This information MUST be present when the echo 506 request applies to all egresses, and is RECCOMMENDED to be present 507 even when the echo request is limited to a single egress. 509 The format of the information in the Downstream Mapping TLV for 510 P2MP MPLS TE LSPs is described in section 3.3.5 and 3.3.6. 512 3.3.2. Traceroute Responses at Branch Nodes 514 A branch node may need to identify more than one downstream interface 515 in a traceroute echo response if some of the egresses that are being 516 traced lie on different branches. This will always be the case for 517 any branch node if all egresses are being traced. 519 [LSP-PING] describes how multiple Downstream Mapping TLVs should be 520 included in an echo response, each identifying exactly one downstream 521 interface that is applicable to the LSP. 523 Just as with non-branches, it is important that the echo responses 524 provide correlation information that will allow the ingress to work 525 out to which branch of the LSP the response applies. Further, when 526 multiple downstream interfaces are identified, it is necessary to 527 indicate which egresses are reached through which branches. This is 528 achieved exactly as for non-branch nodes: that is, by including a 529 list of egresses as part of the Multipath Information field of the 530 appropriate Downstream Mapping TLV. 532 Note also that a branch node may sometimes only need to respond with 533 a single Downstream Mapping TLV. For example, consider the case where 534 the traceroute is directed to only a single egress node. Therefore, 535 the presence of only one Downstream Mapping TLV in an echo response 536 does not guarantee that the reporting LSR is not a branch node. 538 To report on the fact that an LSR is or is not a branch node for the 539 P2MP MPLS TE LSP a new B-flag is added to the Downstream Mapping TLV. 540 The flag is set to zero to indicate that the reporting LSR is not a 541 branch for this LSP, and is set to one to indicate that it is a 542 branch. The flag is placed in the fourth byte of the TLV that was 543 previously reserved. 545 The format of the information in the Downstream Mapping TLV for 546 P2MP MPLS TE LSPs is described in section 3.3.5 and 3.3.6. 548 3.3.3. Traceroute Responses at Bud Nodes 550 Some nodes on an P2MP MPLS TE LSP may be egresses, but also have 551 downstream LSRs. Such LSRs are known as bud nodes. 553 A bud node will respond to a traceroute echo request just as a branch 554 node would, but it is also important that it indicates to the ingress 555 that it is an egress in its own right. This is achieved through the 556 use of a new E-flag in the Downstream Mapping TLV that indicates that 557 the reporting LSR is not a bud for this LSP (set to zero) or is a bud 558 (set to one). A normal egress is not required to set this flag. 560 The flag is placed in the fourth byte of the TLV that was previously 561 reserved. 563 3.3.4. Non-Response to Traceroute Echo Requests 565 The nature of P2MP MPLS TE LSPs in the data plane means that 566 traceroute echo requests may be delivered to the control plane of 567 LSRs that must not reply to the request because, although they lie 568 on the P2MP tree, they do not lie on the path to the egress that is 569 being traced. 571 Thus, an LSR on a P2MP MPLS TE LSP MUST NOT respond to an echo 572 request when the TTL has expired if any of the following applies: 573 - The Reply Type indicates that no reply is required 574 - There is an IPv4/6 P2MP Egress Identifier present on the echo 575 request, but the address does not identify an egress that is 576 reached through this LSR for this particular P2MP MPLS TE LSP. 578 3.3.5. Modifications to the Downstream Mapping TLV 580 A new B-flag is added to the Downstream Mapping TLV to indicate that 581 the reporting LSR is not a branch for this LSP (set to zero) or is a 582 branch (set to one). 584 A new E-flag is added to the Downstream Mapping TLV to indicate that 585 the reporting LSR is not a bud node for this LSP (set to zero) or is 586 a bud node (set to one). 588 The flags are placed in the fourth byte of the TLV that was 589 previously reserved as shown below. All other fields are unchanged 590 from their definitions in [LSP-PING] except for the additional 591 information that can be carried in the Multipath Information. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | MTU | Address Type | Reserved |E|B| 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Downstream IP Address (4 or 16 octets) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Downstream Interface Address (4 or 16 octets) | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Hash Key Type | Depth Limit | Multipath Length | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 . . 605 . (Multipath Information) . 606 . . 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Downstream Label | Protocol | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 . . 611 . . 612 . . 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Downstream Label | Protocol | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 3.3.6. Additions to Downstream Mapping Multipath Information 619 A new value for the Multipath Type is defined to indicate that the 620 reported Multipath Information applies to an P2MP MPLS TE LSP and 621 may contain a list of egress identifiers that indicate the egress 622 nodes that can be reached through the reported interface. 624 Type # Address Type Multipath Information 625 --- ---------------- --------------------- 626 TBD P2MP egresses List of P2MP egresses 628 Note that a list of egresses may include IPv4 and IPv6 identifiers 629 since these may be mixed in the P2MP MPLS TE LSP. 631 The Multipath Length field continues to identify the length of the 632 Multipath Information just as in [LSP-PING] (that is not including 633 the downstream labels), and the downstream label (or potential 634 stack thereof) is also handled just as in [LSP-PING]. The format 635 of the Multipath Information for a Multipath Type of P2MP Egresses 636 is as follows. 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Address Type | Egress Address (4 or 16 octets) | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | (continued) | : 644 +-+-+-+-+-+-+-+-+ : 645 : Further Address Types and Egress Addresses : 646 : : 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Address Type 651 This field indicates whether the egress address that follows is 652 an IPv4 or IPv6 address, and so implicitly encodes the length of 653 the address. 655 Two values are defined and mirror the values used in the Address 656 Type field of the Downstream Mapping TLV itself. 658 Type # Address Type 659 ------ ------------ 660 1 IPv4 661 3 IPv6 663 Egress Address 665 An egress of this P2MP MPLS TE LSP that is reached through the 666 interface indicated by the Downstream Mapping TLV and for which 667 the traceroute echo request was enquiring. 669 4. Non-compliant Routers 671 If an egress for a P2MP LSP does not support MPLS LSP ping, then no 672 reply will be sent, resulting in a "false negative" result. There is 673 no protection for this situation, and operators may wish to ensure 674 that end points for P2MP LSPs are all equally capable of supporting 675 this function. Alternatively, the traceroute option can be used to 676 verify the LSP nearly all the way to the egress, leaving the final 677 hop to be verified manually. 679 If, in "traceroute" mode, a transit LSR does not support LSP ping, 680 then no reply will be forthcoming from that LSR for some TTL, say n. 681 The LSR originating the echo request SHOULD continue to send echo 682 requests with TTL=n+1, n+2, ..., n+k in the hope that some transit 683 LSR further downstream may support MPLS echo requests and reply. In 684 such a case, the echo request for TTL > n MUST NOT have Downstream 685 Mapping TLVs, until a reply is received with a Downstream Mapping. 687 5. OAM Considerations 689 This draft clearly facilitates OAM procedures for P2MP MPLS TE LSPs. 691 In order to be fully operational several considerations must be made. 693 - Scaling concerns dictate that only cautious use of LSP Ping should 694 be made. In particular, sending an LSP Ping to all egresses of a 695 P2MP MPLS TE LSP could result in congestion at or near the ingress 696 when the responses arrive. 698 Further, incautious use of timers to generate LSP Ping echo 699 requests either in ping mode or especially in traceroute may lead 700 to significant degradation of network performance. 702 - Management interfaces should allow an operator full control over 703 the operation of LSP Ping. In particular, it SHOULD provide the 704 ability to limit the scope of an LSP Ping echo request for a P2MP 705 MPLS TE LSP to a single egress. 707 Such an interface SHOULD also provide the ability to disable all 708 active LSP Ping operations to provide a quick escape if the network 709 becomes congested. 711 - A MIB module is required for the control and management of LSP Ping 712 operations, and to enable the reported information to be inspected. 713 There is no reason to believe this should not be a simple extension 714 of the LSP Ping MIB module used for P2P LSPs. 716 6. IANA Considerations 718 6.1. New Sub TLV Types 720 Four new sub-TLV types are defined for inclusion within the Target 721 FEC Stack TLV (TLV type 1). 723 IANA is requested to assign sub-type values to the following 724 sub-TLVs. 726 RSVP P2MP IPv4 Session (see section 3.1) 727 RSVP P2MP IPv6 Session (see section 3.1) 728 IPv4 P2MP Egress Identifier (see section 3.2.2) 729 IPv6 P2MP Egress Identifier (see section 3.2.2) 731 6.2. New Multipath Type 733 A new value for the Multipath Type is defined to indicate that the 734 reported Multipath Information applies to an P2MP MPLS TE LSP. 736 IANA is requested to assign a new value as follows. 738 List of P2MP egresses (see section 3.3.6) 740 7. Security Considerations 742 This document does not introduce security concerns over and above 743 those described in [LSP-PING]. Note that because of the scalability 744 implications of many egresses to P2MP MPLS TE LSPs, there is a 745 stronger concern to regulate the LSP Ping traffic passed to the 746 control plane by the use of a rate limiter applied to the LSP Ping 747 well-known UDP port. Note that this rate limiting might lead to 748 false positives. 750 8. Acknowledgements 752 The authors would like to acknowledge the authors of [LSP-PING] for 753 their work which is substantially re-used in this document. Also 754 thanks to the members of the MBONED working group for their review 755 of this material, to Dan King for his review, and to Yakov Rekhter 756 for useful discussions. 758 9. Intellectual Property Considerations 760 The IETF takes no position regarding the validity or scope of any 761 Intellectual Property Rights or other rights that might be claimed to 762 pertain to the implementation or use of the technology described in 763 this document or the extent to which any license under such rights 764 might or might not be available; nor does it represent that it has 765 made any independent effort to identify any such rights. Information 766 on the procedures with respect to rights in RFC documents can be 767 found in BCP 78 and BCP 79. 769 Copies of IPR disclosures made to the IETF Secretariat and any 770 assurances of licenses to be made available, or the result of an 771 attempt made to obtain a general license or permission for the use of 772 such proprietary rights by implementers or users of this 773 specification can be obtained from the IETF on-line IPR repository at 774 http://www.ietf.org/ipr. 776 The IETF invites any interested party to bring to its attention any 777 copyrights, patents or patent applications, or other proprietary 778 rights that may cover technology that may be required to implement 779 this standard. Please address the information to the IETF at 780 ietf-ipr@ietf.org. 782 10. Normative References 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, March 1997. 787 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 788 RFC 3667, February 2004. 790 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 791 Technology", BCP 79, RFC 3668, February 2004. 793 [LSP-PING] Kompella, K., and Swallow, G., (Editors), "Detecting 794 MPLS Data Plane Failures", draft-ietf-mpls-lsp-ping, 795 work in progress. 797 11. Informational References 799 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 800 IANA Considerations Section in RFCs", BCP: 26, RFC 2434, 801 October 1998. 803 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 804 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 805 Tunnels", RFC 3209, December 2001. 807 [RFC3552] Rescorla E. and B. Korver, "Guidelines for Writing RFC 808 Text on Security Considerations", BCP: 72, RFC 3552, 809 July 2003. 811 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 813 [P2MP-REQ] S. Yasukawa, et. al., "Signaling Requirements for Point 814 to Multipoint Traffic Engineered MPLS LSPs", 815 draft-ietf-mpls-p2mp-sig-requirement, work in progress. 817 [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to 818 Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, 819 work in progress. 821 12. Authors' Addresses 823 Seisho Yasukawa 824 NTT Corporation 825 9-11, Midori-Cho 3-Chome 826 Musashino-Shi, Tokyo 180-8585, 827 Japan 828 Phone: +81 422 59 4769 829 Email: yasukawa.seisho@lab.ntt.co.jp 830 Adrian Farrel 831 Old Dog Consulting 832 EMail: adrian@olddog.co.uk 834 Zafar Ali 835 Cisco Systems Inc. 836 2000 Innovation Drive 837 Kanata, ON, K2K 3E8, Canada. 838 Phone: 613-889-6158 839 Email: zali@cisco.com 841 Bill Fenner 842 AT&T Labs -- Research 843 75 Willow Rd. 844 Menlo Park, CA 94025 845 United States 846 Email: fenner@research.att.com 848 13. Full Copyright Statement 850 Copyright (C) The Internet Society (2005). This document is subject 851 to the rights, licenses and restrictions contained in BCP 78, and 852 except as set forth therein, the authors retain all their rights. 854 This document and the information contained herein are provided on an 855 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 856 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 857 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 858 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 859 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 860 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 862 14. Change History 864 This section to be removed before publication as an RFC 866 14.1. Changes from draft-yasukawa-mpls-p2mp-lsp-ping 01 to 02 868 - Add Bill Fenner as co-author. 869 - Add echo jitter response processing.