idnits 2.17.1 draft-ietf-mpls-p2mp-lsp-ping-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MCAST-CV' is mentioned on line 212, but not defined ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Saxena, Ed. 2 Internet-Draft Cisco Systems, Inc. 3 Intended Status: Standards Track A. Farrel 4 Updates: RFC4379 Old Dog Consulting 5 Created: December 14, 2009 S. Yasukawa 6 Expires: June 14, 2010 NTT Corporation 8 Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol 9 Label Switching (MPLS) - Extensions to LSP Ping 11 draft-ietf-mpls-p2mp-lsp-ping-09.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Recent proposals have extended the scope of Multiprotocol Label 37 Switching (MPLS) Label Switched Paths (LSPs) to encompass 38 point-to-multipoint (P2MP) LSPs. 40 The requirement for a simple and efficient mechanism that can be used 41 to detect data plane failures in point-to-point (P2P) MPLS LSPs has 42 been recognized and has led to the development of techniques for 43 fault detection and isolation commonly referred to as "LSP Ping". 45 The scope of this document is fault detection and isolation for P2MP 46 MPLS LSPs. This documents does not replace any of the mechanisms of 47 LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and 48 extends the techniques and mechanisms of LSP Ping to the MPLS P2MP 49 environment. 51 Copyright Notice 53 Copyright (c) 2009 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Contents 64 1. Introduction.................................................. 5 65 1.1. Design Considerations....................................... 6 66 2. Notes on Motivation........................................... 6 67 2.1. Basic Motivations for LSP Ping.............................. 6 68 2.2. Motivations for LSP Ping for P2MP LSPs...................... 7 69 2.3. Bootstrapping Other OAM Procedures Using LSP Ping........... 9 70 3. Packet Format................................................. 9 71 3.1. Identifying the LSP Under Test.............................. 9 72 3.1.1. Identifying a P2MP MPLS TE LSP............................ 9 73 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV......................... 10 74 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV......................... 10 75 3.1.2. Identifying a Multicast LDP LSP.......................... 11 76 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs....................... 11 77 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs......... 12 78 3.2. Limiting the Scope of Responses............................ 13 79 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs........ 14 80 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs.......... 14 81 3.3. Preventing Congestion of Echo Responses.................... 14 82 3.4. Respond Only If TTL Expired Flag........................... 15 83 3.5. Downstream Detailed Mapping TLV............................ 15 84 4. Operation of LSP Ping for a P2MP LSP......................... 16 85 4.1. Initiating Router Operations............................... 16 86 4.1.1. Limiting Responses to Echo Requests...................... 16 87 4.1.2. Jittered Responses to Echo Requests...................... 17 88 4.2. Responding Router Operations............................... 18 89 4.2.1. Echo Response Reporting.................................. 19 90 4.2.1.1. Responses from Transit and Branch nodes................ 19 91 4.2.1.2. Responses from Egress Nodes............................ 20 92 4.2.1.3. Responses from Bud Nodes............................... 20 93 4.3. Special Considerations for Traceroute...................... 22 94 4.3.1. End of Processing for Traceroutes........................ 22 95 4.3.2. Multiple responses from Bud and Egress Nodes............. 22 96 4.3.3. Non-Response to Traceroute Echo Requests................. 23 97 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request... 23 98 5. Non-compliant Routers........................................ 23 99 6. OAM Considerations........................................... 24 100 7. IANA Considerations.......................................... 24 101 7.1. New Sub-TLV Types.......................................... 25 102 7.2. New TLVs................................................... 25 103 8. Security Considerations...................................... 25 104 9. Acknowledgements............................................. 25 105 10. References.................................................. 26 106 10.1. Normative References...................................... 26 107 10.2. Informative References.................................... 26 108 11. Authors' Addresses.......................................... 27 109 12. Full Copyright Statement.................................... 28 111 0. Change Log 113 This section to be removed before publication as an RFC. 115 0.1 Changes from 00 to 01 117 - Update references. 118 - Fix boilerplate. 120 0.2 Changes from 01 to 02 122 - Update entire document so that it is not specific to MPLS-TE, but 123 also includes multicast LDP LSPs. 124 - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new 125 egress identifier TLV. 126 - Include Multicast LDP FEC Stack sub-TLV definition from [MCAST-CV]. 127 - Add brief section on use of LSP Ping for bootstrapping. 128 - Add new references to References section. 129 - Add details of two new authors. 131 0.3 Changes from 02 to 03 133 - Update references. 134 - Update boilerplate. 135 - Fix typos. 136 - Clarify in 3.2.2 that a recipient of an echo request must reply 137 only once it has applied incoming rate limiting. 138 - Tidy references to bootstrapping for [MCAST-CV] in 1.1. 139 - Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in 140 sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4. 141 - Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs 142 in sections 3.2.1 and 3.2.2. 144 0.4 Changes from 03 to 04 146 - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 147 3.3.4 with respect to multiple sub-TLVs in the P2MP Egress 148 Identifier TLV. 150 0.5 Changes from 04 to 05 152 - Change coordinates for Tom Nadeau. Section 13. 153 - Fix typos. 154 - Update references. 155 - Resolve all acronym expansions. 157 0.6 Changes from 05 to 06 159 - New section, 3.2.6, to explain echo response reporting in the Ping 160 case. 161 - New section, 3.3.7, to explain echo response reporting in the 162 Traceroute case. 163 - Sections 3.3.2, 3.3.5, and 5. Retire the E-flag for identification 164 of bud nodes. Use the B-flag in a Downstream Mapping TLV with a 165 zero address to provide the necessary indication. 166 - Section 3.3.4. Note the use of ALLROUTERS address as per RFC 4379 167 - Section 7. Suggest values for IANA assignment. 168 - Rename "P2MP Responder Identifier TLV" to "P2MP Responder 169 Identifier TLV", "Egress Identifier sub-TLV" to "Responder 170 Identifier sub-TLV", and "P2MP egresses" multipath type to "P2MP 171 responder". This allows any LSR on the P2MP LSP to be the target 172 of, or responder to, an echo request. 174 0.7 Changes from 06 to 07 176 - Sections 3.3.2 and 3.3.3. Delete section 3.3.5. New sections 177 3.3.2.1 through 3.3.2.3: Retire B-flag from Downstream Mapping TLV. 178 Introduce new Node Properties TLV with Branching Properties and 179 Egress Address sub-TLVs. 180 - Section 3.3.2.4: Clarify rules on presence of Multipath Information 181 in Downstream Mapping TLVs. 182 - Section 3.3.5: Clarify padding rules. 183 - Section 3.3.6: Updated to use Downstream Detailed Mapping TLVs for 184 multiple return conditions reported by a single echo response. 185 - Section 7: Update IANA values and add new sub-sections. 186 - Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap. 187 - Section 13: Update Bill Fenner's coordinates. 189 0.8 Changes from 07 to 08 190 - Removed the Node Properties TLV (Section 3.3.2.1 of version 07). 191 - Removed the New Multipath Type from Multipath Sub-TLV (Section 192 3.3.5 of version 07). 193 - Removed the Return Code Sub-TLV from Downstream Detailed TLV 194 (Section 3.3.6.1 of version 07), as it is already included in 195 draft-ietf-mpls-lsp-ping-enhanced-dsmap-02. 197 - Clarified the behavior of Responder Identifier TLV (Section 198 3.2.4 of version 07). Two new Sub-TLVs are introduced. 199 - Downstream Detailed Mapping TLV is now mandatory for implementing 200 P2MP OAM functionality. 201 - Split Multicast LDP TLV into two TLVs, one for P2MP and other for 202 MP2MP. Also added description to allow MP2MP ping by using this 203 draft. 204 - Removed Section 4. as it was a duplicate of Section 2.3. 206 0.9 Changes from 08 to 09 207 - Reformatted the document to follow the RFC4379 style. After the 208 Motivations section is the Packet Format section, followed by the 209 Operations section. The sections on Ping and Traceroute have been 210 merged. 211 - Added a Respond if TTL Expired Flag. 212 - Removed reference to [MCAST-CV]. 214 1. Introduction 216 Simple and efficient mechanisms that can be used to detect data plane 217 failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) 218 Label Switched Paths (LSP) are described in [RFC4379]. The 219 techniques involve information carried in MPLS "Echo Request" and 220 "Echo Reply" messages, and mechanisms for transporting them. The 221 echo request and reply messages provide sufficient information to 222 check correct operation of the data plane, as well as a mechanism to 223 verify the data plane against the control plane, and thereby localize 224 faults. The use of reliable channels for echo reply messages as 225 described in [RFC4379] enables more robust fault isolation. This 226 collection of mechanisms is commonly referred to as "LSP Ping". 228 The requirements for point-to-multipoint (P2MP) MPLS traffic 229 engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a 230 signaling solution for establishing P2MP MPLS TE LSPs. 232 The requirements for point-to-multipoint extensions to the Label 233 Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] 234 specifies extensions to LDP for P2MP MPLS. 236 P2MP MPLS LSPs are at least as vulnerable to data plane faults or to 237 discrepancies between the control and data planes as their P2P 238 counterparts. Therefore, mechanisms are needed to detect such data 239 plane faults in P2MP MPLS LSPs as described in [RFC4687]. 241 This document extends the techniques described in [RFC4379] such that 242 they may be applied to P2MP MPLS LSPs and so that they can be used to 243 bootstrap other Operations and Management (OAM) procedures such as 245 [MPLS-BFD]. This document stresses the reuse of existing LSP Ping 246 mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in 247 order to simplify implementation and network operation. 249 1.1. Design Considerations 251 An important consideration for designing LSP Ping for P2MP MPLS LSPs 252 is that every attempt is made to use or extend existing mechanisms 253 rather than invent new mechanisms. 255 As for P2P LSPs, a critical requirement is that the echo request 256 messages follow the same data path that normal MPLS packets traverse. 257 However, it can be seen this notion needs to be extended for P2MP 258 MPLS LSPs, as in this case an MPLS packet is replicated so that it 259 arrives at each egress (or leaf) of the P2MP tree. 261 MPLS echo requests are meant primarily to validate the data plane, 262 and they can then be used to validate data plane state against the 263 control plane. They may also be used to bootstrap other OAM 264 procedures such as [MPLS-BFD]. As pointed out in [RFC4379], 265 mechanisms to check the liveness, function, and consistency of the 266 control plane are valuable, but such mechanisms are not a feature of 267 LSP Ping and are not covered in this document. 269 As is described in [RFC4379], to avoid potential Denial of Service 270 attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to 271 the control plane. A rate limiter should be applied to the 272 well-known UDP port defined for use by LSP Ping traffic. 274 2. Notes on Motivation 276 2.1. Basic Motivations for LSP Ping 278 The motivations listed in [RFC4379] are reproduced here for 279 completeness. 281 When an LSP fails to deliver user traffic, the failure cannot always 282 be detected by the MPLS control plane. There is a need to provide a 283 tool that enables users to detect such traffic "black holes" or 284 misrouting within a reasonable period of time. A mechanism to 285 isolate faults is also required. 287 [RFC4379] describes a mechanism that accomplishes these goals. This 288 mechanism is modeled after the ping/traceroute paradigm: ping (ICMP 289 echo request [RFC792]) is used for connectivity checks, and 290 traceroute is used for hop-by-hop fault localization as well as path 291 tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode 292 for testing MPLS LSPs. 294 The basic idea as expressed in [RFC4379] is to test that the packets 295 that belong to a particular Forwarding Equivalence Class (FEC) 296 actually end their MPLS path on an LSR that is an egress for that 297 FEC. [RFC4379] achieves this test by sending a packet (called an 298 "MPLS echo request") along the same data path as other packets 299 belonging to this FEC. An MPLS echo request also carries information 300 about the FEC whose MPLS path is being verified. This echo request 301 is forwarded just like any other packet belonging to that FEC. In 302 "ping" mode (basic connectivity check), the packet should reach the 303 end of the path, at which point it is sent to the control plane of 304 the egress LSR, which then verifies that it is indeed an egress for 305 the FEC. In "traceroute" mode (fault isolation), the packet is sent 306 to the control plane of each transit LSR, which performs various 307 checks that it is indeed a transit LSR for this path; this LSR also 308 returns further information that helps to check the control plane 309 against the data plane, i.e., that forwarding matches what the 310 routing protocols determined as the path. 312 One way these tools can be used is to periodically ping a FEC to 313 ensure connectivity. If the ping fails, one can then initiate a 314 traceroute to determine where the fault lies. One can also 315 periodically traceroute FECs to verify that forwarding matches the 316 control plane; however, this places a greater burden on transit LSRs 317 and should be used with caution. 319 2.2. Motivations for LSP Ping for P2MP LSPs 321 As stated in [RFC4687], MPLS has been extended to encompass P2MP 322 LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and 323 diagnose control and data plane defects is critical. For operators 324 deploying services based on P2MP MPLS LSPs, the detection and 325 specification of how to handle those defects is important because 326 such defects may affect the fundamentals of an MPLS network, but also 327 because they may impact service level specification commitments for 328 customers of their network. 330 P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish 331 multicast LSPs. These LSPs distribute data from a single source to 332 one or more destinations across the network according to the next 333 hops indicated by the routing protocols. Each LSP is identified by 334 an MPLS multicast FEC. 336 P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a 337 single ingress and multiple egresses. The tunnels, built on P2MP 338 LSPs, are explicitly routed through the network. There is no concept 339 or applicability of a FEC in the context of a P2MP MPLS TE LSP. 341 MPLS packets inserted at the ingress of a P2MP LSP are delivered 342 equally (barring faults) to all egresses. In consequence, the basic 343 idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an 344 intention to test that packets that enter (at the ingress) a 345 particular P2MP LSP actually end their MPLS path on the LSRs that are 346 the (intended) egresses for that LSP. The idea may be extended to 347 check selectively that such packets reach specific egresses. 349 The technique in this document makes this test by sending an LSP Ping 350 echo request message along the same data path as the MPLS packets. 351 An echo request also carries the identification of the P2MP MPLS LSP 352 (multicast LSP or P2MP TE LSP) that it is testing. The echo request 353 is forwarded just as any other packet using that LSP, and so is 354 replicated at branch points of the LSP and should be delivered to all 355 egresses. 357 In "ping" mode (basic connectivity check), the echo request should 358 reach the end of the path, at which point it is sent to the control 359 plane of the egress LSRs, which verify that they are indeed an egress 360 (leaf) of the P2MP LSP. An echo response message is sent by an 361 egress to the ingress to confirm the successful receipt (or announce 362 the erroneous arrival) of the echo request. 364 In "traceroute" mode (fault isolation), the echo request is sent to 365 the control plane at each transit LSR, and the control plane checks 366 that it is indeed a transit LSR for this P2MP MPLS LSP. The transit 367 LSR also returns information on an echo response that helps verify 368 the control plane against the data plane. That is, the information 369 is used by the ingress to check that the data plane forwarding 370 matches what is signaled by the control plane. 372 P2MP MPLS LSPs may have many egresses, and it is not necessarily the 373 intention of the initiator of the ping or traceroute operation to 374 collect information about the connectivity or path to all egresses. 375 Indeed, in the event of pinging all egresses of a large P2MP MPLS 376 LSP, it might be expected that a large number of echo responses would 377 arrive at the ingress independently but at approximately the same 378 time. Under some circumstances this might cause congestion at or 379 around the ingress LSR. The procedures described in this document 380 provide two mechanisms to control echo responses. 382 The first procedure allows the responders to randomly delay (or 383 jitter) their responses so that the chances of swamping the ingress 384 are reduced. The second procedures allows the initiator to limit the 385 scope of an LSP Ping echo request (ping or traceroute mode) to one 386 specific intended egress. 388 LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure 389 connectivity to any or all of the egresses. If the ping fails, the 390 operator or an automated process can then initiate a traceroute to 391 determine where the fault is located within the network. A 392 traceroute may also be used periodically to verify that data plane 393 forwarding matches the control plane state; however, this places an 394 increased burden on transit LSRs and should be used infrequently and 395 with caution. 397 2.3. Bootstrapping Other OAM Procedures Using LSP Ping 399 [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to 400 bootstrap the Bidirectional Forwarding Detection (BFD) mechanism 401 [BFD] for use to track the liveliness of an MPLS LSP. In particular 402 BFD can be used to detect a data plane failure in the forwarding path 403 of an MPLS LSP. 405 3. Packet Format 407 The basic structure of the LSP Ping packet remains the same as 408 described in [RFC4379]. Some new TLVs and sub-TLVs are required to 409 support the new functionality. They are described in the following 410 sections. 412 3.1. Identifying the LSP Under Test 414 3.1.1. Identifying a P2MP MPLS TE LSP 416 [RFC4379] defines how an MPLS TE LSP under test may be identified in 417 an echo request. A Target FEC Stack TLV is used to carry either an 418 RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. 420 In order to identify the P2MP MPLS TE LSP under test, the echo 421 request message MUST carry a Target FEC Stack TLV, and this MUST 422 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 423 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs 424 carry fields from the RSVP-TE P2MP Session and Sender-Template 425 objects [RFC4875] and so provide sufficient information to uniquely 426 identify the LSP. 428 The new sub-TLVs are assigned sub-type identifiers as follows, and 429 are described in the following sections. 431 Sub-Type # Length Value Field 432 ---------- ------ ----------- 433 TBD 20 RSVP P2MP IPv4 Session 434 TBD 56 RSVP P2MP IPv6 Session 436 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 438 The format of the RSVP P2MP IPv4 Session sub-TLV value field is 439 specified in the following figure. The value fields are taken from 440 the definitions of the P2MP IPv4 LSP Session Object and the P2MP IPv4 441 Sender-Template Object in [RFC4875]. Note that the Sub-Group ID of 442 the Sender-Template is not required. 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | P2MP ID | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Must Be Zero | Tunnel ID | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Extended Tunnel ID | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | IPv4 tunnel sender address | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Must Be Zero | LSP ID | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV 460 The format of the RSVP P2MP IPv6 Session sub-TLV value field is 461 specified in the following figure. The value fields are taken from 462 the definitions of the P2MP IPv6 LSP Session Object, and the P2MP 463 IPv6 Sender-Template Object in [RFC4875]. Note that the Sub-Group ID 464 of the Sender-Template is not required. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 | P2MP ID | 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Must Be Zero | Tunnel ID | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | | 476 | Extended Tunnel ID | 477 | | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | | 480 | IPv6 tunnel sender address | 481 | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Must Be Zero | LSP ID | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 3.1.2. Identifying a Multicast LDP LSP 488 [RFC4379] defines how a P2P LDP LSP under test may be identified in 489 an echo request. A Target FEC Stack TLV is used to carry one or more 490 sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the 491 LSP. 493 In order to identify a multicast LDP LSP under test, the echo request 494 message MUST carry a Target FEC Stack TLV, and this MUST carry 495 exactly one new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This 496 sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so 497 provides sufficient information to uniquely identify the LSP. 499 The new sub-TLV is assigned a sub-type identifier as follows, and is 500 described in the following section. 502 Sub-Type # Length Value Field 503 ---------- ------ ----------- 504 TBD Variable Multicast P2MP LDP FEC Stack 505 TBD Variable Multicast MP2MP LDP FEC Stack 507 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs 509 Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as 510 specified in the following figure. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Address Family | Address Length| Root LSR Addr | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | | 518 ~ Root LSR Address (Cont.) ~ 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Opaque Length | Opaque Value ... | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 523 ~ ~ 524 | | 525 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Address Family 531 Two octet quantity containing a value from ADDRESS FAMILY NUMBERS 532 in [IANA-PORT] that encodes the address family for the Root LSR 533 Address. 535 Address Length 537 Length of the Root LSR Address in octets. 539 Root LSR Address 541 Address of the LSR at the root of the P2MP LSP encoded according 542 to the Address Family field. 544 Opaque Length 546 The length of the Opaque Value, in octets. 548 Opaque Value 550 An opaque value element which uniquely identifies the P2MP LSP in 551 the context of the Root LSR. 553 If the Address Family is IPv4, the Address Length MUST be 4. If the 554 Address Family is IPv6, the Address Length MUST be 16. No other 555 Address Family values are defined at present. 557 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs 559 The mechanisms defined in this document can be extended to include 560 Multipoint-to-Multipoint (MP2MP) Multicast LSPs. In an MP2MP LSP 561 tree, any leaf node can be treated like a head node of a P2MP tree. 562 In other words, for MPLS OAM purposes, the MP2MP tree can be treated 563 like a collection of P2MP trees, with each MP2MP leaf node acting 564 like a P2MP head-end node. When a leaf node is acting like a P2MP 565 head-end node, the remaining leaf nodes act like egress or bud nodes. 567 3.2. Limiting the Scope of Responses 569 A new TLV is defined for inclusion in the Echo request message. 571 The P2MP Responder Identifier TLV is assigned the TLV type value TBD 572 and is encoded as follows. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |Type=TBD(P2MP Responder ID TLV)| Length = Variable | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 ~ Sub-TLVs ~ 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Sub-TLVs: 584 Zero, one or more sub-TLVs as defined below. 586 If no sub-TLVs are present, the TLV MUST be processed as if it 587 were absent. If more than one sub-TLV is present the first MUST 588 be processed as described in this document, and subsequent 589 sub-TLVs SHOULD be ignored. 591 The P2MP Responder Identifier TLV only has meaning on an echo request 592 message. If present on an echo response message, it SHOULD be 593 ignored. 595 Four sub-TLVs are defined for inclusion in the P2MP Responder 596 Identifier TLV carried on the echo request message. These are: 598 Sub-Type # Length Value Field 599 ---------- ------ ----------- 600 1 4 IPv4 Egress Address P2MP Responder Identifier 601 2 16 IPv6 Egress Address P2MP Responder Identifier 602 3 4 IPv4 Node Address P2MP Responder Identifier 603 4 16 IPv6 Node Address P2MP Responder Identifier 605 The content of these Sub-TLVs are defined in the following sections. 606 Also defined is the intended behavior of the responding node upon 607 receiving any of these Sub-TLVs. 609 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs 611 The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs 612 MAY be used in an echo request carrying RSVP P2MP Session Sub-TLV. 613 They SHOULD NOT be used with an echo request carrying Multicast LDP 614 FEC Stack Sub-TLV. 616 A node that receives an echo request with this Sub-TLV present MUST 617 respond only if the node lies on the path to the address in the 618 Sub-TLV. 620 The address in this Sub-TLV SHOULD be of an egress or bud node and 621 SHOULD NOT be of a transit or branch node. A transit or branch node, 622 should be able to determine if the address in this Sub-TLV is for an 623 egress or bud node which is reachable through it. Hence, this 624 address SHOULD be known to the nodes upstream of the target node, for 625 instance via control plane signaling. As a case in point, if RSVP-TE 626 is used to signal the P2MP LSP, this address SHOULD be the address 627 used in destination address field of the S2L_SUB_LSP object, when 628 corresponding egress or bud node is signaled. 630 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs 632 The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY 633 be used in an echo request carrying either RSVP P2MP Session or 634 Multicast LDP FEC Stack Sub-TLV. 636 A node that receives an echo request with this Sub-TLV present MUST 637 respond only if the address in the Sub-TLV corresponds to any address 638 that is local to the node. This address in the Sub-TLV may be of any 639 physical interface or may be the router id of the node itself. 641 The address in this Sub-TLV SHOULD be of any transit, branch, bud or 642 egress node for that P2MP LSP. 644 3.3. Preventing Congestion of Echo Responses 646 A new TLV is defined for inclusion in the Echo request message. 648 The Echo Jitter TLV is assigned the TLV type value TBD and is encoded 649 as follows. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type = TBD (Jitter TLV) | Length = 4 | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Jitter time | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Jitter time: 661 This field specifies the upper bound of the jitter period that 662 should be applied by a responding node to determine how long to 663 wait before sending an echo response. A responding node SHOULD 664 wait a random amount of time between zero milliseconds and the 665 value specified in this field. 667 Jitter time is specified in milliseconds. 669 The Echo Jitter TLV only has meaning on an echo request message. If 670 present on an echo response message, it SHOULD be ignored. 672 3.4. Respond Only If TTL Expired Flag 674 A new flag is being introduced in the Global Flags field. The new 675 format of the Global Flags field is: 677 0 1 678 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | MBZ |T|V| 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 The V flag is described in [RFC4379]. 685 The T (TTL Expired) flag SHOULD be set only in the echo request 686 packet by the sender. This flag SHOULD NOT be set in the echo reply 687 packet. If this flag is set in an echo reply packet, then it MUST be 688 ignored. 690 If the T flag is set to 1, then the reciever SHOULD reply only if the 691 TTL of the incoming MPLS label is equal to 1; if the TTL is more than 692 1, then no response should be sent back. If the T flag is set to 0, 693 then the receiver SHOULD reply as per regular processing. 695 3.5. Downstream Detailed Mapping TLV 696 Downstream Detailed Mapping TLV is described in [DDMT]. A transit, 697 branch or bud node can use the Downstream Detailed Mapping TLV to 698 return multiple Return Codes for different downstream paths. This 699 functionality can not be achieved via the Downstream Mapping TLV. As 700 per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in 701 [RFC4379] is being deprecated. 703 Therefore for P2MP, a node MUST support Downstream Detailed Mapping 704 TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP 705 traceroute functionality and SHOULD NOT be included in an Echo Request 706 message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type 707 or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any 708 Downstream Mapping TLV it receives in the echo request. 710 The details of the Return Codes to be used in the Downstream Detailed 711 Mapping TLV are provided in section 4. 713 4. Operation of LSP Ping for a P2MP LSP 715 This section describes how LSP Ping is applied to P2MP MPLS LSPs. As 716 mentioned previously, an important design consideration has been to 717 extend existing LSP Ping mechanism in [RFC4379] rather than invent 718 new mechanisms. 720 As specified in [RFC4379], MPLS LSPs can be tested via a "ping" mode 721 or a "traceroute" mode. The ping mode is also known as "connectivity 722 verification" and traceroute mode is also known as "fault isolation". 723 Further details can be obtained from [RFC4379]. 725 This section specifies processing of echo requests for both ping and 726 traceroute mode at various nodes (ingress, transit, etc.) of the P2MP 727 LSP. 729 4.1. Initiating Router Operations 731 The router initiating the echo request will follow the procedures in 732 [RFC4379]. The echo request will contain a Target FEC Stack TLV. To 733 identify the P2MP LSP under test, this TLV will contain one of the 734 new sub-TLVs defined in section 3.1. Additionally there may be other 735 optional TLVs present. 737 4.1.1. Limiting Responses to Echo Requests 739 As described in Section 2.2, it may be desirable to restrict the 740 operation of P2MP ping or traceroute to a single egress. Since echo 741 requests are forwarded through the data plane without interception by 742 the control plane, there is no facility to limit the propagation of 743 echo requests, and they will automatically be forwarded to all 744 reachable egresses. 746 However, a single egress may be identified by the inclusion of a P2MP 747 Responder Identifier TLV. The details of this TLV and its Sub-TLVs 748 are in section 3.2. There are two main types of sub-TLV in the P2MP 749 Responder Identifier TLV: Egress Address sub-TLV and Node Address 750 sub-TLV. 752 These sub-TLVs limit the responses either to the specified router 753 only or to any router on the path to the specified router. The 754 former capability is generally useful for ping mode, while the latter 755 is more suited to traceroute mode. An initiating router may indicate 756 that it wishes all egresses to respond to an echo request by omitting 757 the P2MP Responder Identifier TLV. 759 4.1.2. Jittered Responses to Echo Requests 761 The initiating router MAY request the responding routers to introduce 762 a random delay (or jitter) before sending the response. The 763 randomness of the delay allows the responses from multiple egresses 764 to be spread over a time period. Thus this technique is particularly 765 relevant when the entire P2MP LSP is being pinged or traced since it 766 helps prevent the initiating (or nearby) routers from being swamped 767 by responses, or from discarding responses due to rate limits that 768 have been applied. 770 It is desirable for the initiating rotuer to be able to control the 771 bounds of the jitter. If the tree size is small, only a small amount 772 of jitter is required, but if the tree is large, greater jitter is 773 needed. 775 The initiating router can supply the desired value of the jitter in 776 the Echo Jitter TLV as defined section 3.3. If this TLV is present, 777 the responding router MUST delay sending a response for a random 778 amount of time between zero milliseconds and the value indicated in 779 the TLV. If the TLV is absent, the responding egress SHOULD NOT 780 introduce any additional delay in responding to the echo request. 782 LSP ping SHOULD NOT be used to attempt to measure the round-trip time 783 for data delivery. This is because the P2MP LSPs are unidirectional, 784 and the echo response is often sent back through the control plane. 785 The timestamp fields in the echo request and echo response packets 786 MAY be used to deduce some information about delivery times and 787 particularly the variance in delivery times. 789 The use of echo jittering does not change the processes for gaining 790 information, but note that the responding node MUST set the value in 791 the Timestamp Received fields before applying any delay. 793 Echo response jittering SHOULD be used for P2MP LSPs. If the Echo 794 Jitter TLV is present in an echo request for any other type of LSPs, 795 the responding egress MAY apply the jitter behavior as described 796 here. 798 4.2. Responding Router Operations 800 Usually the echo request packet will reach the egress and bud nodes. 801 In case of TTL Expiry, i.e. traceroute mode, the echo request packet 802 may stop at branch or transit nodes. In both scenarios, the echo 803 request will be passed on to control plane for reply processing. 805 The operations at the receiving node are an extenstion to the 806 existing processing as specified in [RFC4379]. A responding router 807 is RECOMMENDED to rate limit its receipt of echo request messages. 808 After rate limiting, the responding router must verify general sanity 809 of the packet. If the packet is malformed, or certain TLVs are not 810 understood, the [RFC4379] procedures must be followed for echo reply. 811 Similarly the Reply Mode field determines if the response is required 812 or not (and the mechanism to send it back). 814 For P2MP LSP ping and traceroute, i.e. if the echo request is 815 carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding 816 router MUST determine whether it is part of the P2MP LSP in question 817 by checking with the control plane. 819 - If the node is not part of the P2MP LSP, it MUST respond 820 according to [RFC4379] processing rules. 822 - If the node is part of the P2MP LSP, the node must check whether 823 the echo request is directed to it or not. 825 - If a P2MP Responder Identifier TLV is present, then the node 826 must follow the procedures defined in section 3.2 to 827 determine whether it should respond to the reqeust or not. 828 The presence of a P2MP Responder Identifier TLV or a 829 Downstream Detailed Mapping TLV might affect the Return Code. 830 This is discussed in more detail later. 832 - If the P2MP Responder Identifier TLV is not present (or, in 833 the error case, is present, but does not contain any 834 sub-TLVs), then the node MUST respond according to [RFC4379] 835 processing rules. 837 4.2.1. Echo Response Reporting 839 Echo response messages carry return codes and subcodes to indicate 840 the result of the LSP Ping (when the ping mode is being used) as 841 described in [RFC4379]. 843 When the responding node reports that it is an egress, it is clear 844 that the echo response applies only to the reporting node. 845 Similarly, when a node reports that it does not form part of the LSP 846 described by the FEC (i.e. there is a misconnection) then the echo 847 response applies to the reporting node. 849 However, it should be noted that an echo response message that 850 reports an error from a transit node may apply to multiple egress 851 nodes (i.e. leaves) downstream of the reporting node. In the case of 852 the ping mode of operation, it is not possible to correlate the 853 reporting node to the affected egresses unless the topology of the 854 P2MP tree is already known, and it may be necessary to use the 855 traceroute mode of operation to further diagnose the LSP. 857 Note also that a transit node may discover an error but also 858 determine that while it does lie on the path of the LSP under test, 859 it does not lie on the path to the specific egress being tested. In 860 this case, the node SHOULD NOT generate an echo response. 862 The following sections describe the expected values of Return Codes 863 for various nodes in a P2MP LSP. It is assumed that the sanity and 864 other checks have been performed and an echo response is being sent 865 back. As mentioned previously, the Return Code might change based on 866 the presence of Responder Identifier TLV or Downstream Detailed 867 Mapping TLV. 869 4.2.1.1. Responses from Transit and Branch nodes 871 The presence of a Responder Identifier TLV does not influence the 872 choice of the Return Code, which MAY be set to value 8 ('Label 873 switched at stack-depth ') or any other error value as needed. 875 The presence of a Downstream Detailed Mapping TLV will influence the 876 choice of Return Code. As per [DDMT], the Return Code in the echo 877 response header MAY be set to value TBD ('See DDM TLV for Return Code 878 and Return SubCode') as defined in [DDMT]. The Return Code for each 879 Downstream Detailed Mapping TLV will depend on the downstream path as 880 described in [DDMT]. 882 There will be a Downstream Detailed Mapping TLV for each downstream 883 path being reported in the echo response. Hence for transit nodes, 884 there will be only one such TLV and for branch nodes, there will be 885 more than one. If there is an Egress Address Responder Identifier 886 Sub-TLV, then the branch node will include only one Downstream 887 Detailed Mapping TLV corresponding to the downstream path required to 888 reach the address specified in the Egress Address Sub-TLV. 890 4.2.1.2. Responses from Egress Nodes 892 The presence of a Responder Identifier TLV does not influence the 893 choice of the Return Code, which MAY be set to value 3 ('Replying 894 router is an egress for the FEC at stack-depth ') or any other 895 error value as needed. 897 The presence of the Downstream Detailed Mapping TLV does not 898 influence the choice of Return Code. Egress nodes do not put in any 899 Downstream Detailed Mapping TLV in the echo response. 901 4.2.1.3. Responses from Bud Nodes 903 The case of bud nodes is more complex than other types of nodes. The 904 node might behave as either an egress node or a transit node or a 905 combination of an egress and branch node. This behavior is 906 determined by the presence of any Responder Identifier TLV and the 907 type of sub-TLV in it. Similarly Downstream Detailed Mapping TLV can 908 influence the Return Code values. 910 To determine the behavior of the bud node, use the following 911 guidelines. The intent of these guidelines is to figure out if the 912 echo request is meant for all nodes, or just this node, or for 913 another node reachable through this node or for a different section 914 of the tree. In the first case, the node will behave like a 915 combination of egress and branch node; in the second case, the node 916 will behave like pure egress node; in the third case, the node will 917 behave like a transit node; and in the last case, no response will be 918 sent back. 920 Node behavior guidelines: 922 - If the Responder Identifier TLV is not present, then the node 923 will behave as a combination egress and branch node. 925 - If the Responder Identifier TLV containing a Node Address 926 sub-TLV is present, and: 928 - If the address specified in the sub-TLV matches to an address 929 in the node, then the node will behave like an egress node 930 only. 932 - If the address specified in the sub-TLV does not match any 933 address in the node, then no response will be sent. 935 - If the Responder Identifier TLV containing an Egress Address 936 sub-TLV is present, and: 938 - If the address specified in the sub-TLV matches to an address 939 in the node, then the node will behave like an egress node 940 only. 942 - If the node lies on the path to the address specified in the 943 sub-TLV, then the node will behave like a transit node. 945 - If the node does not lie on the path to the address specified 946 in the sub-TLV, then no response will be sent. 948 Once the node behavior has been determined, the possible values for 949 Return Codes are as follows: 951 - If the node is behaving as an egress node only, then the Return 952 Code MAY be set to value 3 ('Replying router is an egress for 953 the FEC at stack-depth ') or any other error value as 954 needed. The echo response MUST NOT contain any Downstream 955 Detailed Mapping TLV, even if one is present in the echo 956 request. 958 - If the node is behaving as a transit node, and: 960 - If a Downstream Detailed Mapping TLV is not present, then 961 the Return Code MAY be set to value 8 ('Label switched at 962 stack-depth ') or any other error value as needed. 964 - If a Downstream Detailed Mapping TLV is present, then the 965 Return Code MAY be set to value TBD ('See DDM TLV for 966 Return Code and Return SubCode') as defined in [DDMT]. The 967 Return Code for the Downstream Detailed Mapping TLV will 968 depend on the downstream path as described in [DDMT]. 969 There will be only one Downstream Detailed Mapping 970 corresponding to the downstream path to the address 971 specified in the Egress Address Sub-TLV. 973 - If the node is behaving as a combination egress and branch node, 974 and: 976 - If a Downstream Detailed Mapping TLV is not present, then 977 the Return Code MAY be set to value 3 ('Replying router is 978 an egress for the FEC at stack-depth ') or any other 979 error value as needed. 981 - If a Downstream Detailed Mapping TLV is present, then the 982 Return Code MAY be set to value 3 ('Replying router is an 983 egress for the FEC at stack-depth ') or any other 984 error value as needed. Return Code for the each Downstream 985 Detailed Mapping TLV will depend on the downstream path as 986 described in [DDMT]. There will be a Downstream Detailed 987 Mapping for each downstream path from the node. 989 4.3. Special Considerations for Traceroute 991 4.3.1. End of Processing for Traceroutes 993 As specified in [RFC4379], the traceroute mode operates by sending a 994 series of echo requests with sequentially increasing TTL values. For 995 regular P2P targets, this processing stops when a valid response is 996 received from the intended egress or when some errored return code is 997 received. 999 For P2MP targets, there may not be an easy way to figure out the end 1000 of the traceroute processing, as there are multiple egress nodes. 1001 Receiving a valid response from an egress will not signal the end of 1002 processing. 1004 In P2MP TE LSP, the initiating router has a priori knowledge about 1005 number of egress nodes and their addresses. Hence it possible to 1006 continue processing till a valid response has been received from each 1007 end-point, provided the responses can be matched correctly to the 1008 egress nodes. 1010 However in Multicast LDP LSPs, the initiating router has no knowledge 1011 about the egress nodes. Hence it is not possible to estimate the end 1012 of processing for traceroute in such scenarios. 1014 Therefore it is RECOMMENDED that traceroute operations provide for a 1015 configurable upper limit on TTL values. Hence the user can choose 1016 the depth to which the tree will be probed. 1018 4.3.2. Multiple responses from Bud and Egress Nodes 1020 The P2MP traceroute may continue even after it has received a valid 1021 response from a bud or egress node, as there may be more nodes at 1022 deeper levels. Hence for subsequent TTL values, a bud or egress node 1023 that has previously replied would continue to get new echo requests. 1024 Since each echo request is handled independently from previous 1025 requests, these bud and egress nodes will keep on responding to the 1026 traceroute echo requests. This can cause extra processing burden for 1027 the initiating router and these bud or egress routers. 1029 To prevent a bud or egress node from sending multiple responses in 1030 the same traceroute operation, a new "Respond Only If TTL Expired" 1031 flag is being introduced. This flag is described in Section 3.4. 1033 It is RECOMMENDED that this flag be used for P2MP traceroute mode 1034 only. By using this flag, extraneous responses from bud and egress 1035 nodes can be reduced. 1037 4.3.3. Non-Response to Traceroute Echo Requests 1039 There are multiple reasons for which an ingress node may not receive 1040 a response to its echo request. For example, the transit node has 1041 failed, or the transit node does not support LSP Ping. 1043 When no response to an echo request is received by the ingress, then 1044 as per [RFC4379] the subsequent echo request with a larger TTL SHOULD 1045 be sent. 1047 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request 1049 As described in section 4.6 of [RFC4379], an initiating router, 1050 during traceroute, SHOULD copy the Downstream Mapping(s) into its 1051 next echo request(s). However for P2MP LSPs, the intiating router 1052 will receive multiple sets of Downstream Detailed Mapping TLV from 1053 different nodes. It is not practical to copy all of them into the 1054 next echo request. Hence this behavior is being modified for P2MP 1055 LSPs. In the echo request packet, the "Downstream IP Address" field, 1056 of the Downstream Detailed Mapping TLV, SHOULD be set to the 1057 ALLROUTERS multicast address. 1059 If an Egress Address Responder Identifier sub-TLV is being used, then 1060 the traceroute is limited to only one path to one egress. Therefore 1061 this traceroute is effectively behaving like a P2P traceroute. In 1062 this scenario, as per section 4.2, the echo responses from 1063 intermediate nodes will contain only one Downstream Detailed Mapping 1064 TLV corresponding to the downstream path required to reach the 1065 address specified in the Egress Address sub-TLV. For this case, the 1066 echo request packet MAY reuse a received Downstream Detailed Mapping 1067 TLV. 1069 5. Non-compliant Routers 1071 If a node for a P2MP LSP does not support MPLS LSP ping, then no 1072 reply will be sent, resulting in a "false negative" result. There is 1073 no protection for this situation, and operators may wish to ensure 1074 that all nodes for P2MP LSPs are all equally capable of supporting 1075 this function. 1077 If the non-compliant node is an egress, then the traceroute mode can 1078 be used to verify the LSP nearly all the way to the egress, leaving 1079 the final hop to be verified manually. 1081 If the non-compliant node is a branch or transit node, then it should 1082 not impact ping mode. However the node will not respond during 1083 traceroute mode. 1085 6. OAM Considerations 1087 The procedures in this document provide OAM functions for P2MP MPLS 1088 LSPs and may be used to enable bootstrapping of other OAM procedures. 1090 In order to be fully operational several considerations must be made. 1092 - Scaling concerns dictate that only cautious use of LSP Ping 1093 should be made. In particular, sending an LSP Ping to all 1094 egresses of a P2MP MPLS LSP could result in congestion at or 1095 near the ingress when the responses arrive. 1097 Further, incautious use of timers to generate LSP Ping echo 1098 requests either in ping mode or especially in traceroute may 1099 lead to significant degradation of network performance. 1101 - Management interfaces should allow an operator full control over 1102 the operation of LSP Ping. In particular, it SHOULD provide the 1103 ability to limit the scope of an LSP Ping echo request for a 1104 P2MP MPLS LSP to a single egress. 1106 Such an interface SHOULD also provide the ability to disable all 1107 active LSP Ping operations to provide a quick escape if the 1108 network becomes congested. 1110 - A MIB module is required for the control and management of LSP 1111 Ping operations, and to enable the reported information to be 1112 inspected. 1114 There is no reason to believe this should not be a simple 1115 extension of the LSP Ping MIB module used for P2P LSPs. 1117 7. IANA Considerations 1118 7.1. New Sub-TLV Types 1120 Four new sub-TLV types are defined for inclusion within the LSP Ping 1121 [RFC4379] Target FEC Stack TLV (TLV type 1). 1123 IANA is requested to assign sub-type values to the following sub-TLVs 1124 from the "Multiprotocol Label Switching Architecture (MPLS) Label 1125 Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and 1126 sub-TLVs" sub-registry. 1128 RSVP P2MP IPv4 Session (Section 3.1.1). Suggested value 17. 1129 RSVP P2MP IPv6 Session (Section 3.1.1). Suggested value 18. 1130 Multicast P2MP LDP FEC Stack (Section 3.1.2). Suggested value 19. 1131 Multicast MP2MP LDP FEC Stack (Section 3.1.2). Suggested value 20. 1133 7.2. New TLVs 1135 Two new LSP Ping TLV types are defined for inclusion in LSP Ping 1136 messages. 1138 IANA is requested to assign a new value from the "Multi-Protocol 1139 Label Switching Architecture (MPLS) Label Switched Paths (LSPs) 1140 Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as 1141 follows using a Standards Action value. 1143 P2MP Responder Identifier TLV (see Section 3.2.4) is a mandatory 1144 TLV. Suggested value 11. Four sub-TLVs are defined. 1145 - Type 1: IPv4 Egress Address P2MP Responder Identifier 1146 - Type 2: IPv6 Egress Address P2MP Responder Identifier 1147 - Type 3: IPv4 Node Address P2MP Responder Identifier 1148 - Type 4: IPv6 Node Address P2MP Responder Identifier 1150 Echo Jitter TLV (see Section 3.2.5) is a mandatory TLV. Suggested 1151 value 12. 1153 8. Security Considerations 1155 This document does not introduce security concerns over and above 1156 those described in [RFC4379]. Note that because of the scalability 1157 implications of many egresses to P2MP MPLS LSPs, there is a stronger 1158 concern to regulate the LSP Ping traffic passed to the control plane 1159 by the use of a rate limiter applied to the LSP Ping well-known UDP 1160 port. Note that this rate limiting might lead to false positives. 1162 9. Acknowledgements 1163 The authors would like to acknowledge the authors of [RFC4379] for 1164 their work which is substantially re-used in this document. Also 1165 thanks to the members of the MBONED working group for their review of 1166 this material, to Daniel King and Mustapha Aissaoui for their review, 1167 and to Yakov Rekhter for useful discussions. 1169 The authors would like to thank Bill Fenner, Vanson Lim, Danny 1170 Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin 1171 Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar 1172 and IJsbrand Wijnands for their comments and suggestions. 1174 10. References 1176 10.1. Normative References 1178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1179 Requirement Levels", BCP 14, RFC 2119, March 1997. 1181 [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol 1182 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1183 February 2006. 1185 [DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism 1186 for Performing LSP-Ping over MPLS Tunnels", draft-ietf- 1187 mpls-lsp-ping-enhanced-dsmap, work in progress. 1189 10.2. Informative References 1191 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 1193 [RFC4461] Yasukawa, S., "Signaling Requirements for Point to 1194 Multipoint Traffic Engineered Multiprotocol Label 1195 Switching (MPLS) Label Switched Paths (LSPs)", 1196 RFC 4461, April 2006. 1198 [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1199 "Operations and Management (OAM) Requirements for 1200 Point-to-Multipoint MPLS Networks", RFC 4687, September 1201 2006. 1203 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 1204 "Extensions to Resource Reservation Protocol - Traffic 1205 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1206 Switched Paths (LSPs)", RFC 4875, May 2007. 1208 [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for 1209 point-to-multipoint extensions to the Label Distribution 1210 Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. 1212 [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol 1213 Extensions for Point-to-Multipoint and 1214 Multipoint-to-Multipoint Label Switched Paths", 1215 draft-ietf-mpls-ldp-p2mp, work in progress. 1217 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 1218 Detection", draft-ietf-bfd-base, work in progress. 1220 [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., 1221 "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in 1222 progress. 1224 [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 1226 11. Authors' Addresses 1228 Seisho Yasukawa 1229 NTT Corporation 1230 (R&D Strategy Department) 1231 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 1232 Phone: +81 3 5205 5341 1233 Email: yasukawa.seisho@lab.ntt.co.jp 1235 Adrian Farrel 1236 Old Dog Consulting 1237 EMail: adrian@olddog.co.uk 1239 Zafar Ali 1240 Cisco Systems Inc. 1241 2000 Innovation Drive 1242 Kanata, ON, K2K 3E8, Canada. 1243 Phone: 613-889-6158 1244 Email: zali@cisco.com 1246 George Swallow 1247 Cisco Systems, Inc. 1248 1414 Massachusetts Ave 1249 Boxborough, MA 01719 1250 Email: swallow@cisco.com 1252 Thomas D. Nadeau 1253 British Telecom 1254 BT Centre 1255 81 Newgate Street 1256 EC1A 7AJ 1257 London 1258 Email: tom.nadeau@bt.com 1260 Shaleen Saxena 1261 Cisco Systems, Inc. 1262 1414 Massachusetts Ave 1263 Boxborough, MA 01719 1264 Email: ssaxena@cisco.com 1266 12. Full Copyright Statement 1268 Copyright (c) 2009 IETF Trust and the persons identified as the 1269 document authors. All rights reserved. 1271 This document is subject to BCP 78 and the IETF Trust's Legal 1272 Provisions Relating to IETF Documents in effect on the date of 1273 publication of this document (http://trustee.ietf.org/license-info). 1274 Please review these documents carefully, as they describe your rights 1275 and restrictions with respect to this document. 1277 This document may contain material from IETF Documents or IETF 1278 Contributions published or made publicly available before November 1279 10, 2008. The person(s) controlling the copyright in some of this 1280 material may not have granted the IETF Trust the right to allow 1281 modifications of such material outside the IETF Standards Process. 1282 Without obtaining an adequate license from the person(s) controlling 1283 the copyright in such materials, this document may not be modified 1284 outside the IETF Standards Process, and derivative works of it may 1285 not be created outside the IETF Standards Process, except to format 1286 it for publication as an RFC or to translate it into languages other 1287 than English.