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