idnits 2.17.1 draft-ietf-mpls-p2mp-lsp-ping-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- 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.) -- The document date (September 2, 2011) is 4618 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) == Missing Reference: 'This I-D' is mentioned on line 1204, but not defined ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 4020 (Obsoleted by RFC 7120) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 G. Swallow 3 Intended Status: Standards Track Z. Ali 4 Updates: 4379 (if approved) Cisco Systems, Inc. 5 Expires: March 2, 2012 A. Farrel 6 Juniper Networks 7 S. Yasukawa 8 NTT Corporation 9 T. Nadeau 10 LucidVision 11 September 2, 2011 13 Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol 14 Label Switching (MPLS) - Extensions to LSP Ping 16 draft-ietf-mpls-p2mp-lsp-ping-18.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 Recent proposals have extended the scope of Multiprotocol Label 42 Switching (MPLS) Label Switched Paths (LSPs) to encompass 43 point-to-multipoint (P2MP) LSPs. 45 The requirement for a simple and efficient mechanism that can be used 46 to detect data plane failures in point-to-point (P2P) MPLS LSPs has 47 been recognized and has led to the development of techniques for 48 fault detection and isolation commonly referred to as "LSP Ping". 50 The scope of this document is fault detection and isolation for P2MP 51 MPLS LSPs. This documents does not replace any of the mechanisms of 52 LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and 53 extends the techniques and mechanisms of LSP Ping to the MPLS P2MP 54 environment. 56 This document updates RFC 4379. 58 Copyright Notice 60 Copyright (c) 2011 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 Contents 71 1. Introduction.................................................... 3 72 1.1. Design Considerations......................................... 4 73 1.2 Terminology.................................................... 4 74 2. Notes on Motivation............................................. 4 75 2.1. Basic Motivations for LSP Ping................................ 4 76 2.2. Motivations for LSP Ping for P2MP LSPs........................ 5 77 3. Packet Format................................................... 7 78 3.1. Identifying the LSP Under Test................................ 7 79 3.1.1. Identifying a P2MP MPLS TE LSP.............................. 7 80 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 8 81 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV............................ 8 82 3.1.2. Identifying a Multicast LDP LSP............................. 9 83 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs.......................... 9 84 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 11 85 3.2. Limiting the Scope of Responses.............................. 11 86 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 12 87 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 13 88 3.3. Preventing Congestion of Echo Replies........................ 14 89 3.4. Respond Only If TTL Expired Flag............................. 14 90 3.5. Downstream Detailed Mapping TLV.............................. 15 91 4. Operation of LSP Ping for a P2MP LSP........................... 15 92 4.1. Initiating LSR Operations.................................... 16 93 4.1.1. Limiting Responses to Echo Requests........................ 16 94 4.1.2. Jittered Responses to Echo Requests........................ 16 95 4.2. Responding LSR Operations.................................... 17 96 4.2.1. Echo Reply Reporting....................................... 18 97 4.2.1.1. Responses from Transit and Branch Nodes.................. 19 98 4.2.1.2. Responses from Egress Nodes.............................. 19 99 4.2.1.3. Responses from Bud Nodes................................. 20 100 4.3. Special Considerations for Traceroute........................ 21 101 4.3.1. End of Processing for Traceroutes.......................... 21 102 4.3.2. Multiple responses from Bud and Egress Nodes............... 22 103 4.3.3. Non-Response to Traceroute Echo Requests................... 23 104 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 23 105 4.3.5 Cross-Over Node Processing.................................. 23 106 5. Non-compliant Routers.......................................... 24 107 6. OAM and Management Considerations.............................. 24 108 7. IANA Considerations............................................ 25 109 7.1. New Sub-TLV Types............................................ 25 110 7.2. New TLVs..................................................... 26 111 7.3. New Global Flags Registry.................................... 26 112 8. Security Considerations........................................ 26 113 9. Acknowledgements............................................... 27 114 10. References.................................................... 27 115 10.1. Normative References........................................ 27 116 10.2. Informative References...................................... 27 117 11. Authors' Addresses............................................ 28 118 12. Full Copyright Statement...................................... 29 120 1. Introduction 122 Simple and efficient mechanisms that can be used to detect data plane 123 failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) 124 Label Switched Paths (LSP) are described in [RFC4379]. The 125 techniques involve information carried in MPLS "Echo Request" and 126 "Echo Reply" messages, and mechanisms for transporting them. The 127 echo request and reply messages provide sufficient information to 128 check correct operation of the data plane, as well as a mechanism to 129 verify the data plane against the control plane, and thereby localize 130 faults. The use of reliable channels for echo reply messages as 131 described in [RFC4379] enables more robust fault isolation. This 132 collection of mechanisms is commonly referred to as "LSP Ping". 134 The requirements for point-to-multipoint (P2MP) MPLS traffic 135 engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a 136 signaling solution for establishing P2MP MPLS TE LSPs. 138 The requirements for point-to-multipoint extensions to the Label 139 Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] 140 specifies extensions to LDP for P2MP MPLS. 142 P2MP MPLS LSPs are at least as vulnerable to data plane faults or to 143 discrepancies between the control and data planes as their P2P 144 counterparts. Therefore, mechanisms are needed to detect such data 145 plane faults in P2MP MPLS LSPs as described in [RFC4687]. 147 This document extends the techniques described in [RFC4379] such that 148 they may be applied to P2MP MPLS LSPs. This document stresses the 149 reuse of existing LSP Ping mechanisms used for P2P LSPs, and applies 150 them to P2MP MPLS LSPs in order to simplify implementation and 151 network operation. 153 1.1. Design Considerations 155 An important consideration for designing LSP Ping for P2MP MPLS LSPs 156 is that every attempt is made to use or extend existing mechanisms 157 rather than invent new mechanisms. 159 As for P2P LSPs, a critical requirement is that the echo request 160 messages follow the same data path that normal MPLS packets traverse. 161 However, it can be seen this notion needs to be extended for P2MP 162 MPLS LSPs, as in this case an MPLS packet is replicated so that it 163 arrives at each egress (or leaf) of the P2MP tree. 165 MPLS echo requests are meant primarily to validate the data plane, 166 and they can then be used to validate data plane state against the 167 control plane. They may also be used to bootstrap other Operations, 168 Administration, and Maintenance (OAM) procedures such as [RFC5884]. 169 As pointed out in [RFC4379], mechanisms to check the liveness, 170 function, and consistency of the control plane are valuable, but such 171 mechanisms are not a feature of LSP Ping and are not covered in this 172 document. 174 As is described in [RFC4379], to avoid potential Denial of Service 175 attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to 176 the control plane. A rate limiter should be applied to the incoming 177 LSP Ping traffic. 179 1.2 Terminology 181 The terminology used in this document for P2MP MPLS can be found in 182 [RFC4461]. The terminology for MPLS OAM can be found in [RFC4379]. 183 In particular, the notation refers to the Return Subcode as 184 defined in section 3.1. of [RFC4379]. 186 2. Notes on Motivation 188 2.1. Basic Motivations for LSP Ping 190 The motivations listed in [RFC4379] are reproduced here for 191 completeness. 193 When an LSP fails to deliver user traffic, the failure cannot 194 always be detected by the MPLS control plane. There is a need to 195 provide a tool that enables users to detect such traffic "black 196 holes" or misrouting within a reasonable period of time. A 197 mechanism to isolate faults is also required. 199 [RFC4379] describes a mechanism that accomplishes these goals. 200 This mechanism is modeled after the ping/traceroute paradigm: 201 ping (ICMP echo request [RFC792]) is used for connectivity 202 checks, and traceroute is used for hop-by-hop fault localization 203 as well as path tracing. [RFC4379] specifies a "ping mode" and a 204 "traceroute" mode for testing MPLS LSPs. 206 The basic idea as expressed in [RFC4379] is to test that the 207 packets that belong to a particular Forwarding Equivalence Class 208 (FEC) actually end their MPLS path on an LSR that is an egress 209 for that FEC. [RFC4379] achieves this test by sending a packet 210 (called an "MPLS echo request") along the same data path as other 211 packets belonging to this FEC. An MPLS echo request also carries 212 information about the FEC whose MPLS path is being verified. 213 This echo request is forwarded just like any other packet 214 belonging to that FEC. In "ping" mode (basic connectivity 215 check), the packet should reach the end of the path, at which 216 point it is sent to the control plane of the egress LSR, which 217 then verifies that it is indeed an egress for the FEC. In 218 "traceroute" mode (fault isolation), the packet is sent to the 219 control plane of each transit LSR, which performs various checks 220 that it is indeed a transit LSR for this path; this LSR also 221 returns further information that helps to check the control plane 222 against the data plane, i.e., that forwarding matches what the 223 routing protocols determined as the path. 225 One way these tools can be used is to periodically ping a FEC to 226 ensure connectivity. If the ping fails, one can then initiate a 227 traceroute to determine where the fault lies. One can also 228 periodically traceroute FECs to verify that forwarding matches 229 the control plane; however, this places a greater burden on 230 transit LSRs and should be used with caution. 232 2.2. Motivations for LSP Ping for P2MP LSPs 234 As stated in [RFC4687], MPLS has been extended to encompass P2MP 235 LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and 236 diagnose control and data plane defects is critical. For operators 237 deploying services based on P2MP MPLS LSPs, the detection and 238 specification of how to handle those defects is important because 239 such defects may affect the fundamentals of an MPLS network, but also 240 because they may impact service level specification commitments for 241 customers of their network. 243 P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish 244 multicast LSPs. These LSPs distribute data from a single source to 245 one or more destinations across the network according to the next 246 hops indicated by the routing protocols. Each LSP is identified by 247 an MPLS multicast FEC. 249 P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a 250 single ingress and multiple egresses. The tunnels, built on P2MP 251 LSPs, are explicitly routed through the network. There is no concept 252 or applicability of a FEC in the context of a P2MP MPLS TE LSP. 254 MPLS packets inserted at the ingress of a P2MP LSP are delivered 255 equally (barring faults) to all egresses. In consequence, the basic 256 idea of LSP Ping for P2MP MPLS LSPs may be expressed as an 257 intention to test that packets that enter (at the ingress) a 258 particular P2MP LSP actually end their MPLS path on the LSRs that are 259 the (intended) egresses for that LSP. The idea may be extended to 260 check selectively that such packets reach specific egresses. 262 The technique in this document makes this test by sending an LSP Ping 263 echo request message along the same data path as the MPLS packets. 264 An echo request also carries the identification of the P2MP MPLS LSP 265 (multicast LSP or P2MP TE LSP) that it is testing. The echo request 266 is forwarded just as any other packet using that LSP, and so is 267 replicated at branch points of the LSP and should be delivered to all 268 egresses. 270 In "ping" mode (basic connectivity check), the echo request should 271 reach the end of the path, at which point it is sent to the control 272 plane of the egress LSRs, which verify that they are indeed an egress 273 (leaf) of the P2MP LSP. An echo reply message is sent by an 274 egress to the ingress to confirm the successful receipt (or announce 275 the erroneous arrival) of the echo request. 277 In "traceroute" mode (fault isolation), the echo request is sent to 278 the control plane at each transit LSR, and the control plane checks 279 that it is indeed a transit LSR for this P2MP MPLS LSP. The transit 280 LSR returns information about the outgoing paths. This information 281 can be used by ingress LSR to build topology or by downstream LSRs to 282 do extra label verification. 284 P2MP MPLS LSPs may have many egresses, and it is not necessarily the 285 intention of the initiator of the ping or traceroute operation to 286 collect information about the connectivity or path to all egresses. 287 Indeed, in the event of pinging all egresses of a large P2MP MPLS 288 LSP, it might be expected that a large number of echo replies would 289 arrive at the ingress independently but at approximately the same 290 time. Under some circumstances this might cause congestion at or 291 around the ingress LSR. The procedures described in this document 292 provide two mechanisms to control echo replies. 294 The first procedure allows the responders to randomly delay (or 295 jitter) their replies so that the chances of swamping the ingress 296 are reduced. The second procedure allows the initiator to limit the 297 scope of an LSP Ping echo request (ping or traceroute mode) to one 298 specific intended egress. 300 LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure 301 connectivity to any or all of the egresses. If the ping fails, the 302 operator or an automated process can then initiate a traceroute to 303 determine where the fault is located within the network. A 304 traceroute may also be used periodically to verify that data plane 305 forwarding matches the control plane state; however, this places an 306 increased burden on transit LSRs and should be used infrequently and 307 with caution. 309 3. Packet Format 311 The basic structure of the LSP Ping packet remains the same as 312 described in [RFC4379]. Some new TLVs and sub-TLVs are required to 313 support the new functionality. They are described in the following 314 sections. 316 3.1. Identifying the LSP Under Test 318 3.1.1. Identifying a P2MP MPLS TE LSP 320 [RFC4379] defines how an MPLS TE LSP under test may be identified in 321 an echo request. A Target FEC Stack TLV is used to carry either an 322 RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. 324 In order to identify the P2MP MPLS TE LSP under test, the echo 325 request message MUST carry a Target FEC Stack TLV, and this MUST 326 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 327 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs 328 carry fields from the RSVP-TE P2MP Session and Sender-Template 329 objects [RFC4875] and so provide sufficient information to uniquely 330 identify the LSP. 332 The new sub-TLVs are assigned sub-type identifiers as follows, and 333 are described in the following sections. 335 Sub-Type # Length Value Field 336 ---------- ------ ----------- 337 TBD1 20 RSVP P2MP IPv4 Session 338 TBD2 56 RSVP P2MP IPv6 Session 340 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 342 The format of the RSVP P2MP IPv4 Session sub-TLV value field is 343 specified in the following figure. The value fields are taken from 344 the definitions of the P2MP IPv4 LSP Session Object and the P2MP IPv4 345 Sender-Template Object in Sections 19.1.1 and 19.2.1 of [RFC4875]. 346 Note that the Sub-Group ID of the Sender-Template is not required. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | P2MP ID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | MUST Be Zero | Tunnel ID | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Extended Tunnel ID | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | IPv4 tunnel sender address | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | MUST Be Zero | LSP ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV 364 The format of the RSVP P2MP IPv6 Session sub-TLV value field is 365 specified in the following figure. The value fields are taken from 366 the definitions of the P2MP IPv6 LSP Session Object, and the P2MP 367 IPv6 Sender-Template Object in Sections 19.1.2 and 19.2.2 of 368 [RFC4875]. Note that the Sub-Group ID of the Sender-Template is not 369 required. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | P2MP ID | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | MUST Be Zero | Tunnel ID | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 | Extended Tunnel ID | 380 | | 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 | IPv6 tunnel sender address | 385 | | 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | MUST Be Zero | LSP ID | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 3.1.2. Identifying a Multicast LDP LSP 393 [RFC4379] defines how a P2P LDP LSP under test may be identified in 394 an echo request. A Target FEC Stack TLV is used to carry one or more 395 sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the 396 LSP. 398 In order to identify a multicast LDP LSP under test, the echo request 399 message MUST carry a Target FEC Stack TLV, and this MUST carry 400 exactly one of two new sub-TLVs: either a Multicast P2MP LDP FEC 401 Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV. These 402 sub-TLVs use fields from the multicast LDP messages [P2MP-LDP] and so 403 provides sufficient information to uniquely identify the LSP. 405 The new sub-TLVs are assigned sub-type identifiers as follows, and 406 are described in the following section. 408 Sub-Type # Length Value Field 409 ---------- ------ ----------- 410 TBD3 Variable Multicast P2MP LDP FEC Stack 411 TBD4 Variable Multicast MP2MP LDP FEC Stack 413 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs 415 Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as 416 specified in the following figure. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Address Family | Address Length| Root LSR Addr | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | 424 ~ Root LSR Address (Cont.) ~ 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Opaque Length | Opaque Value ... | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 429 ~ ~ 430 | | 431 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Address Family 437 Two octet quantity containing a value from ADDRESS FAMILY NUMBERS 438 in [IANA-PORT] that encodes the address family for the Root LSR 439 Address. 441 Address Length 443 Length of the Root LSR Address in octets. 445 Root LSR Address 447 Address of the LSR at the root of the P2MP LSP encoded according 448 to the Address Family field. 450 Opaque Length 452 The length of the Opaque Value, in octets. Depending on length of 453 the Root LSR Address, this field may not be aligned to a word 454 boundary. 456 Opaque Value 458 An opaque value element which uniquely identifies the P2MP LSP in 459 the context of the Root LSR. 461 If the Address Family is IPv4, the Address Length MUST be 4. If the 462 Address Family is IPv6, the Address Length MUST be 16. No other 463 Address Family values are defined at present. 465 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs 467 The mechanisms defined in this document can be extended to include 468 Multipoint-to-Multipoint (MP2MP) Multicast LSPs. In an MP2MP LSP 469 tree, any leaf node can be treated like a head node of a P2MP tree. 470 In other words, for MPLS OAM purposes, the MP2MP tree can be treated 471 like a collection of P2MP trees, with each MP2MP leaf node acting 472 like a P2MP head-end node. When a leaf node is acting like a P2MP 473 head-end node, the remaining leaf nodes act like egress or bud nodes. 475 3.2. Limiting the Scope of Responses 477 A new TLV is defined for inclusion in the Echo request message. 479 The P2MP Responder Identifier TLV is assigned the TLV type value TBD5 480 and is encoded as follows. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |Type = TBD5 (P2MP Responder ID)| Length = Variable | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 ~ Sub-TLVs ~ 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Sub-TLVs: 492 Zero, one or more sub-TLVs as defined below. 494 If no sub-TLVs are present, the TLV MUST be processed as if it 495 were absent. If more than one sub-TLV is present the first MUST 496 be processed as described in this document, and subsequent 497 sub-TLVs SHOULD be ignored. Interpretation of additional sub- 498 TLVs may be defined in future documents. 500 The P2MP Responder Identifier TLV only has meaning on an echo request 501 message. If present on an echo reply message, it MUST be 502 ignored. 504 Four sub-TLVs are defined for inclusion in the P2MP Responder 505 Identifier TLV carried on the echo request message. These are: 507 Sub-Type # Length Value Field 508 ---------- ------ ----------- 509 1 4 IPv4 Egress Address P2MP Responder Identifier 510 2 16 IPv6 Egress Address P2MP Responder Identifier 511 3 4 IPv4 Node Address P2MP Responder Identifier 512 4 16 IPv6 Node Address P2MP Responder Identifier 514 The content of these Sub-TLVs are defined in the following sections. 515 Also defined is the intended behavior of the responding node upon 516 receiving any of these Sub-TLVs. 518 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs 520 The encoding of the IPv4 Egress Address P2MP Responder Identifier 521 sub-TLV is as follows: 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Sub-Type = 1 | Length = 4 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | 32-bit IPv4 Address | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 The encoding of the IPv6 Egress Address P2MP Responder Identifier 532 sub-TLV is as follows: 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Sub-Type = 2 | Length = 16 | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 | 128-bit IPv6 Address | 541 | | 542 | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 A node that receives an echo request with this Sub-TLV present MUST 546 respond if the node lies on the path to the address in the Sub-TLV 547 and MUST NOT respond if it does not lie on the path to the address in 548 the Sub-TLV. For this to be possible, the address in the Sub-TLV must 549 be known to the nodes that lie upstream in the LSP. This can be the 550 case if RSVP-TE is used to signal the P2MP LSP, in which case this 551 address will be the address used in destination address field of 552 the S2L_SUB_LSP object, when corresponding egress or bud node is 553 signaled. Thus, the IPv4 or IPv6 Egress Address P2MP Responder 554 Identifier Sub-TLV MAY be used in an echo request carrying RSVP P2MP 555 Session Sub-TLV. 557 However, in Multicast LDP there is no way for upstream LSRs to know 558 the idendity of the downstream leaf nodes. Hence these TLVs cannot be 559 used to perform traceroute to a single node when Multicast LDP FEC is 560 used, and the IPv4 or IPv6 Egress Address P2MP Responder Identifier 561 Sub-TLV SHOULD NOT be used with an echo request carrying Multicast 562 LDP FEC Stack Sub-TLV. If a node receives these TLVs in an echo 563 request carrying Multicast LDP then it will not respond since it is 564 unaware of whether it lies on the path to the address in the Sub-TLV. 566 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs 568 The encoding of the IPv4 Node Address P2MP Responder Identifier 569 sub-TLV is as follows: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Sub-Type = 3 | Length = 4 | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | 32-bit IPv4 Address | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 The encoding of the IPv6 Node Address P2MP Responder Identifier 580 sub-TLV is as follows: 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Sub-Type = 4 | Length = 16 | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 | 128-bit IPv6 Address | 589 | | 590 | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY 594 be used in an echo request carrying either RSVP P2MP Session or 595 Multicast LDP FEC Stack Sub-TLV. 597 A node that receives an echo request with this Sub-TLV present MUST 598 respond if the address in the Sub-TLV matches any address that is 599 local to the node and MUST NOT respond if the address in the Sub-TLV 600 does not match any address that is local to the node. The address 601 in the Sub-TLV may be of any physical interface or may be the router 602 id of the node itself. 604 The address in this Sub-TLV SHOULD be of any transit, branch, bud or 605 egress node for that P2MP LSP. The address of a node that is not on 606 the P2MP LSP MAY be used as a check that no reply is received. 608 3.3. Preventing Congestion of Echo Replies 610 A new TLV is defined for inclusion in the Echo request message. 612 The Echo Jitter TLV is assigned the TLV type value TBD6 and is 613 encoded as follows. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type = TBD6 (Jitter TLV) | Length = 4 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Jitter time | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Jitter time: 625 This field specifies the upper bound of the jitter period that 626 should be applied by a responding node to determine how long to 627 wait before sending an echo reply. A responding node MUST 628 wait a random amount of time between zero milliseconds and the 629 value specified in this field. 631 Jitter time is specified in milliseconds. 633 The Echo Jitter TLV only has meaning on an echo request message. If 634 present on an echo reply message, it MUST be ignored. 636 3.4. Respond Only If TTL Expired Flag 638 A new flag is being introduced in the Global Flags field defined in 639 [RFC4379]. The new format of the Global Flags field is: 641 0 1 642 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | MBZ |T|V| 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 The V flag is described in [RFC4379]. 649 The T (Respond Only If TTL Expired) flag MUST be set only in the 650 echo request packet by the sender. This flag MUST NOT be set in 651 the echo reply packet. If this flag is set in an echo reply packet, 652 then it MUST be ignored. 654 If the T flag is set to 0, then the receiving node MUST process the 655 incoming echo request. 657 If the T flag is set to 1, and the TTL of the incoming MPLS label is 658 equal to 1 then the receiving node MUST process the incoming echo 659 request. 661 If the T flag is set to 1, and the TTL of the incoming MPLS label is 662 more than 1 then the receiving node MUST drop the incoming echo 663 request and MUST NOT send any echo reply to the sender. 665 If the T flag is set to 1 and there are no incoming MPLS labels in 666 the echo request packet, then a bud node with PHP configured MAY 667 choose to not respond to this echo request. All other nodes MUST 668 ignore this bit and respond as per regular processing. 670 3.5. Downstream Detailed Mapping TLV 672 Downstream Detailed Mapping TLV is described in [DDMT]. A transit, 673 branch or bud node can use the Downstream Detailed Mapping TLV to 674 return multiple Return Codes for different downstream paths. This 675 functionality can not be achieved via the Downstream Mapping TLV. As 676 per Section 3.4 of [DDMT], the Downstream Mapping TLV as described in 677 [RFC4379] is being deprecated. 679 Therefore for P2MP, a node MUST support Downstream Detailed Mapping 680 TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP 681 traceroute functionality and MUST NOT be included in an Echo Request 682 message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type 683 or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any 684 Downstream Mapping TLV it receives in the echo request and MUST 685 continue processing as if the Downstream Mapping TLV is not present. 687 The details of the Return Codes to be used in the Downstream Detailed 688 Mapping TLV are provided in section 4. 690 4. Operation of LSP Ping for a P2MP LSP 692 This section describes how LSP Ping is applied to P2MP MPLS LSPs. As 693 mentioned previously, an important design consideration has been to 694 extend existing LSP Ping mechanism in [RFC4379] rather than invent 695 new mechanisms. 697 As specified in [RFC4379], MPLS LSPs can be tested via a "ping" mode 698 or a "traceroute" mode. The ping mode is also known as "connectivity 699 verification" and traceroute mode is also known as "fault isolation". 700 Further details can be obtained from [RFC4379]. 702 This section specifies processing of echo requests for both ping and 703 traceroute mode at various nodes (ingress, transit, etc.) of the P2MP 704 LSP. 706 4.1. Initiating LSR Operations 708 The LSR initiating the echo request will follow the procedures in 709 [RFC4379]. The echo request will contain a Target FEC Stack TLV. To 710 identify the P2MP LSP under test, this TLV will contain one of the 711 new sub-TLVs defined in section 3.1. Additionally there may be other 712 optional TLVs present. 714 4.1.1. Limiting Responses to Echo Requests 716 As described in Section 2.2, it may be desirable to restrict the 717 operation of P2MP ping or traceroute to a single egress. Since echo 718 requests are forwarded through the data plane without interception by 719 the control plane, there is no facility to limit the propagation of 720 echo requests, and they will automatically be forwarded to all 721 reachable egresses. 723 However, a single egress may be identified by the inclusion of a P2MP 724 Responder Identifier TLV. The details of this TLV and its Sub-TLVs 725 are in section 3.2. There are two main types of sub-TLV in the P2MP 726 Responder Identifier TLV: Node Address sub-TLV and Egress Address 727 sub-TLV. 729 These sub-TLVs limit the replies either to the specified LSR only 730 or to any LSR on the path to the specified LSR. The former 731 capability is generally useful for ping mode, while the latter is 732 more suited to traceroute mode. An initiating LSR may indicate that 733 it wishes all egresses to respond to an echo request by omitting the 734 P2MP Responder Identifier TLV. 736 4.1.2. Jittered Responses to Echo Requests 738 The initiating LSR MAY request the responding LSRs to introduce a 739 random delay (or jitter) before sending the reply. The randomness 740 of the delay allows the replies from multiple egresses to be spread 741 over a time period. Thus this technique is particularly relevant 742 when the entire P2MP LSP is being pinged or traced since it helps 743 prevent the initiating (or nearby) LSRs from being swamped by 744 replies, or from discarding replies due to rate limits that have 745 been applied. 747 It is desirable for the initiating LSR to be able to control the 748 bounds of the jitter. If the tree size is small, only a small amount 749 of jitter is required, but if the tree is large, greater jitter is 750 needed. 752 The initiating LSR can supply the desired value of the jitter in the 753 Echo Jitter TLV as defined in section 3.3. If this TLV is present, 754 the responding LSR MUST delay sending a reply for a random amount of 755 time between zero milliseconds and the value indicated in the TLV. 756 If the TLV is absent, the responding egress SHOULD NOT introduce any 757 additional delay in responding to the echo request, but MAY delay 758 according to local policy. 760 LSP ping MUST NOT be used to attempt to measure the round-trip time 761 for data delivery. This is because the P2MP LSPs are unidirectional, 762 and the echo reply is often sent back through the control plane. The 763 timestamp fields in the echo request and echo reply packets MAY be 764 used to deduce some information about delivery times, for example 765 the variance in delivery times. 767 The use of echo jittering does not change the processes for gaining 768 information, but note that the responding node MUST set the value in 769 the Timestamp Received fields before applying any delay. 771 Echo reply jittering SHOULD be used for P2MP LSPs although MAY be 772 omitted for simple P2MP LSPs or when the Node Address P2MP Responder 773 Identifier Sub-TLVs are used. If the Echo Jitter TLV is present in 774 an echo request for any other type of LSPs, the responding egress MAY 775 apply the jitter behavior as described here. 777 4.2. Responding LSR Operations 779 Usually the echo request packet will reach the egress and bud nodes. 780 In case of TTL Expiry, i.e. traceroute mode, the echo request packet 781 may stop at branch or transit nodes. In both scenarios, the echo 782 request will be passed on to control plane for reply processing. 784 The operations at the receiving node are an extension to the existing 785 processing as specified in [RFC4379]. As described in that document, 786 a responding LSR SHOULD rate limit the receipt of echo request 787 messages. After rate limiting, the responding LSR must verify 788 general sanity of the packet. If the packet is malformed, or certain 789 TLVs are not understood, the [RFC4379] procedures must be followed 790 for echo reply. Similarly the Reply Mode field determines if the 791 reply is required or not (and the mechanism to send it back). 793 For P2MP LSP ping and traceroute, i.e. if the echo request is 794 carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR 795 MUST determine whether it is part of the P2MP LSP in question by 796 checking with the control plane. 798 - If the node is not part of the P2MP LSP, it MUST respond 799 according to [RFC4379] processing rules. 801 - If the node is part of the P2MP LSP, the node must check whether 802 the echo request is directed to it or not. 804 - If a P2MP Responder Identifier TLV is present, then the node 805 must follow the procedures defined in section 3.2 to 806 determine whether it should respond to the reqeust or not. 807 The presence of a P2MP Responder Identifier TLV or a 808 Downstream Detailed Mapping TLV might affect the Return Code. 809 This is discussed in more detail later. 811 - If the P2MP Responder Identifier TLV is not present (or, in 812 the error case, is present, but does not contain any 813 sub-TLVs), then the node MUST respond according to [RFC4379] 814 processing rules. 816 4.2.1. Echo Reply Reporting 818 Echo reply messages carry return codes and subcodes to indicate 819 the result of the LSP Ping (when the ping mode is being used) as 820 described in [RFC4379]. 822 When the responding node reports that it is an egress, it is clear 823 that the echo reply applies only to that reporting 824 node. Similarly, when a node reports that it does not form part of 825 the LSP described by the FEC then it is clear that the echo reply 826 applies only to that reporting node. However, an echo reply 827 message that reports an error from a transit node may apply to 828 multiple egress nodes (i.e. leaves) downstream of the reporting node. 829 In the case of the ping mode of operation, it is not possible to 830 correlate the reporting node to the affected egresses unless the 831 topology of the P2MP tree is already known, and it may be necessary 832 to use the traceroute mode of operation to further diagnose the LSP. 834 Note that a transit node may discover an error but also 835 determine that while it does lie on the path of the LSP under test, 836 it does not lie on the path to the specific egress being tested. In 837 this case, the node SHOULD NOT generate an echo reply unless there is 838 a specific error condition that needs to be communicated. 840 The following sections describe the expected values of Return Codes 841 for various nodes in a P2MP LSP. It is assumed that the sanity and 842 other checks have been performed and an echo reply is being sent 843 back. As mentioned in Section 4.2, the Return Code might change 844 based on the presence of Responder Identifier TLV or Downstream 845 Detailed Mapping TLV. 847 4.2.1.1. Responses from Transit and Branch Nodes 849 The presence of a Responder Identifier TLV does not influence the 850 choice of the Return Code. For a success response, the Return Code 851 MAY be set to value 8 ('Label switched at stack-depth '). The 852 notation refers to the Return Subcode as defined in section 853 3.1. of [RFC4379]. For error conditions, use appropriate values 854 defined in [RFC4379]. 856 The presence of a Downstream Detailed Mapping TLV will influence the 857 choice of Return Code. As per [DDMT], the Return Code in the echo 858 reply header MAY be set to 'See DDM TLV for Return Code and Return 859 SubCode' as defined in [DDMT]. The Return Code for each Downstream 860 Detailed Mapping TLV will depend on the downstream path as described 861 in [DDMT]. 863 There will be a Downstream Detailed Mapping TLV for each downstream 864 path being reported in the echo reply. Hence for transit nodes, 865 there will be only one such TLV and for branch nodes, there will be 866 more than one. If there is an Egress Address Responder Identifier 867 Sub-TLV, then the branch node will include only one Downstream 868 Detailed Mapping TLV corresponding to the downstream path required to 869 reach the address specified in the Egress Address Sub-TLV. 871 4.2.1.2. Responses from Egress Nodes 873 The presence of a Responder Identifier TLV does not influence the 874 choice of the Return Code. For a success response, the Return Code 875 MAY be set to value 3 ('Replying router is an egress for the FEC at 876 stack-depth '). For error conditions, use appropriate values 877 defined in [RFC4379]. 879 The presence of the Downstream Detailed Mapping TLV does not 880 influence the choice of Return Code. Egress nodes do not put in any 881 Downstream Detailed Mapping TLV in the echo reply [DDMT]. 883 4.2.1.3. Responses from Bud Nodes 885 The case of bud nodes is more complex than other types of nodes. The 886 node might behave as either an egress node or a transit node or a 887 combination of an egress and branch node. This behavior is 888 determined by the presence of any Responder Identifier TLV and the 889 type of sub-TLV in it. Similarly Downstream Detailed Mapping TLV can 890 influence the Return Code values. 892 To determine the behavior of the bud node, use the following rules. 893 The intent of these rules is to figure out if the echo request is 894 meant for all nodes, or just this node, or for another node reachable 895 through this node or for a different section of the tree. In the 896 first case, the node will behave like a combination of egress and 897 branch node; in the second case, the node will behave like pure 898 egress node; in the third case, the node will behave like a transit 899 node; and in the last case, no reply will be sent back. 901 Node behavior rules: 903 - If the Responder Identifier TLV is not present, then the node 904 will behave as a combination of egress and branch node. 906 - If the Responder Identifier TLV containing a Node Address 907 sub-TLV is present, and: 909 - If the address specified in the sub-TLV matches to an address 910 in the node, then the node will behave like a combination of 911 egress and branch node. 913 - If the address specified in the sub-TLV does not match any 914 address in the node, then no reply will be sent. 916 - If the Responder Identifier TLV containing an Egress Address 917 sub-TLV is present, and: 919 - If the address specified in the sub-TLV matches to an address 920 in the node, then the node will behave like an egress node 921 only. 923 - If the node lies on the path to the address specified in the 924 sub-TLV, then the node will behave like a transit node. 926 - If the node does not lie on the path to the address specified 927 in the sub-TLV, then no reply will be sent. 929 Once the node behavior has been determined, the possible values for 930 Return Codes are as follows: 932 - If the node is behaving as an egress node only, then for a 933 success response, the Return Code MAY be set to value 3 934 ('Replying router is an egress for the FEC at stack-depth 935 '). For error conditions, use appropriate values defined 936 in [RFC4379]. The echo reply MUST NOT contain any Downstream 937 Detailed Mapping TLV, even if one is present in the echo 938 request. 940 - If the node is behaving as a transit node, and: 942 - If a Downstream Detailed Mapping TLV is not present, then 943 for a success response, the Return Code MAY be set to value 944 8 ('Label switched at stack-depth '). For error 945 conditions, use appropriate values defined in [RFC4379]. 947 - If a Downstream Detailed Mapping TLV is present, then the 948 Return Code MAY be set to 'See DDM TLV for Return Code and 949 Return SubCode' as defined in [DDMT]. The Return Code for 950 the Downstream Detailed Mapping TLV will depend on the 951 downstream path as described in [DDMT]. There will be only 952 one Downstream Detailed Mapping corresponding to the 953 downstream path to the address specified in the Egress 954 Address Sub-TLV. 956 - If the node is behaving as a combination of egress and branch 957 node, and: 959 - If a Downstream Detailed Mapping TLV is not present, then 960 for a success response, the Return Code MAY be set to value 961 3 ('Replying router is an egress for the FEC at stack-depth 962 '). For error conditions, use appropriate values 963 defined in [RFC4379]. 965 - If a Downstream Detailed Mapping TLV is present, then for a 966 success response, the Return Code MAY be set to value 3 967 ('Replying router is an egress for the FEC at stack-depth 968 '). For error conditions, use appropriate values 969 defined in [RFC4379]. Return Code for the each Downstream 970 Detailed Mapping TLV will depend on the downstream path as 971 described in [DDMT]. There will be a Downstream Detailed 972 Mapping for each downstream path from the node. 974 4.3. Special Considerations for Traceroute 976 4.3.1. End of Processing for Traceroutes 978 As specified in [RFC4379], the traceroute mode operates by sending a 979 series of echo requests with sequentially increasing TTL values. For 980 regular P2P targets, this processing stops when a valid reply is 981 received from the intended egress or when some errored return code is 982 received. 984 For P2MP targets, there may not be an easy way to figure out the end 985 of the traceroute processing, as there are multiple egress nodes. 986 Receiving a valid reply from an egress will not signal the end of 987 processing. 989 For P2MP TE LSP, the initiating LSR has a priori knowledge about 990 number of egress nodes and their addresses. Hence it is possible to 991 continue processing till a valid reply has been received from each 992 end-point, provided the replies can be matched correctly to the 993 egress nodes. 995 However for Multicast LDP LSP, the initiating LSR might not always 996 know about all the egress nodes. Hence there might not be a 997 definitive way to estimate the end of processing for traceroute. 999 Therefore it is RECOMMENDED that traceroute operations provide for a 1000 configurable upper limit on TTL values. Hence the user can choose 1001 the depth to which the tree will be probed. 1003 4.3.2. Multiple responses from Bud and Egress Nodes 1005 The P2MP traceroute may continue even after it has received a valid 1006 reply from a bud or egress node, as there may be more nodes at 1007 deeper levels. Hence for subsequent TTL values, a bud or egress node 1008 that has previously replied would continue to get new echo requests. 1009 Since each echo request is handled independently from previous 1010 requests, these bud and egress nodes will keep on responding to the 1011 traceroute echo requests. This can cause extra processing burden for 1012 the initiating LSR and these bud or egress LSRs. 1014 To prevent a bud or egress node from sending multiple replies in 1015 the same traceroute operation, a new "Respond Only If TTL Expired" 1016 flag is being introduced. This flag is described in Section 3.4. 1018 It is RECOMMENDED that this flag be used for P2MP traceroute mode 1019 only. By using this flag, extraneous replies from bud and egress 1020 nodes can be reduced. If PHP is being used in the P2MP tree, then 1021 bud and egress nodes will not get any labels with the echo request 1022 packet. Hence this mechanism will not be effective for PHP scenario. 1024 4.3.3. Non-Response to Traceroute Echo Requests 1026 There are multiple reasons for which an ingress node may not receive 1027 a reply to its echo request. For example, the transit node has 1028 failed, or the transit node does not support LSP Ping. 1030 When no reply to an echo request is received by the ingress, then 1031 as per [RFC4379] the subsequent echo request with a larger TTL SHOULD 1032 be sent in order to trace further toward the egress, although the 1033 ingress MAY halt the procedure at this point. The time that an 1034 ingress waits before sending the subsequent echo request is an 1035 implementation choice. 1037 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request 1039 As described in section 4.6 of [RFC4379], an initiating LSR, during 1040 traceroute, SHOULD copy the Downstream Mapping(s) into its next echo 1041 request(s). However for P2MP LSPs, the intiating LSR will receive 1042 multiple sets of Downstream Detailed Mapping TLV from different 1043 nodes. It is not practical to copy all of them into the next echo 1044 request. Hence this behavior is being modified for P2MP LSPs. If 1045 the echo request is destined for more than one node, then the 1046 "Downstream IP Address" field of the Downstream Detailed Mapping TLV 1047 MUST be set to the ALLROUTERS multicast address, and the Address Type 1048 field MUST be set to either IPv4 Unnumbered or IPv6 Unnumbered 1049 depending on the Target FEC Stack TLV. 1051 If an Egress Address Responder Identifier sub-TLV is being used, then 1052 the traceroute is limited to only one egress. Therefore this 1053 traceroute is effectively behaving like a P2P traceroute. In this 1054 scenario, as per section 4.2, the echo replies from intermediate 1055 nodes will contain only one Downstream Detailed Mapping TLV 1056 corresponding to the downstream path required to reach the address 1057 specified in the Egress Address sub-TLV. For this case, the echo 1058 request packet MAY reuse a received Downstream Detailed Mapping 1059 TLV. This will allow interface validation to be performed as per 1060 [RFC4379]. 1062 4.3.5 Cross-Over Node Processing 1064 A cross-over node will require slightly different processing for 1065 traceroute mode. The following definition of cross-over is taken from 1066 [RFC4875]. 1068 The term "cross-over" refers to the case of an ingress or transit 1069 node that creates a branch of a P2MP LSP, a cross-over branch, that 1070 intersects the P2MP LSP at another node farther down the tree. It 1071 is unlike re-merge in that, at the intersecting node, the 1072 cross-over branch has a different outgoing interface as well as a 1073 different incoming interface. 1075 During traceroute, a cross-over node will receive the echo requests 1076 via each of its input interfaces. Therefore the Downstream Detailed 1077 Mapping TLV in the echo reply MUST carry information only about the 1078 outgoing interface corresponding to the input interface. 1080 If this restriction is applied, the cross-over node will not 1081 duplicate the outgoing interface information in each of the echo 1082 request it receives via the different input interfaces. This will 1083 reflect the actual packet replication in the data plane. 1085 5. Non-compliant Routers 1087 If a node for a P2MP LSP does not support MPLS LSP ping, then no 1088 reply will be sent, causing an incorrect result on the initiating 1089 LSR. There is no protection for this situation, and operators may 1090 wish to ensure that all nodes for P2MP LSPs are all equally capable 1091 of supporting this function. 1093 If the non-compliant node is an egress, then the traceroute mode can 1094 be used to verify the LSP nearly all the way to the egress, leaving 1095 the final hop to be verified manually. 1097 If the non-compliant node is a branch or transit node, then it should 1098 not impact ping mode. However the node will not respond during 1099 traceroute mode. 1101 6. OAM and Management Considerations 1103 The procedures in this document provide OAM functions for P2MP MPLS 1104 LSPs and may be used to enable bootstrapping of other OAM procedures. 1106 In order to be fully operational several considerations apply. 1108 - Scaling concerns dictate that only cautious use of LSP Ping 1109 should be made. In particular, sending an LSP Ping to all 1110 egresses of a P2MP MPLS LSP could result in congestion at or 1111 near the ingress when the replies arrive. 1113 Further, incautious use of timers to generate LSP Ping echo 1114 requests either in ping mode or especially in traceroute may 1115 lead to significant degradation of network performance. 1117 - Management interfaces should allow an operator full control over 1118 the operation of LSP Ping. In particular, such interfaces 1119 should provide the ability to limit the scope of an LSP Ping 1120 echo request for a P2MP MPLS LSP to a single egress. 1122 Such interfaces should also provide the ability to disable all 1123 active LSP Ping operations to provide a quick escape if the 1124 network becomes congested. 1126 - A MIB module is required for the control and management of LSP 1127 Ping operations, and to enable the reported information to be 1128 inspected. 1130 There is no reason to believe this should not be a simple 1131 extension of the LSP Ping MIB module used for P2P LSPs. 1133 7. IANA Considerations 1135 [Note - this paragraph to be removed before publication.] The values 1136 suggested in sections 7.1 and 7.2 have already been assigned using 1137 the IANA early allocation process [RFC4020]. 1139 7.1. New Sub-TLV Types 1141 Four new sub-TLV types are defined for inclusion within the LSP Ping 1142 [RFC4379] Target FEC Stack TLV (TLV type 1). 1144 IANA is requested to assign sub-type values to the following sub-TLVs 1145 under TLV type 1 (Target FEC Stack) from the "Multiprotocol Label 1146 Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters 1147 - TLVs" registry, "TLVs and sub-TLVs" sub-registry. 1149 TBD1 1150 RSVP P2MP IPv4 Session (Section 3.1.1). 1151 Suggested value 17. 1152 TBD2 1153 RSVP P2MP IPv6 Session (Section 3.1.1). 1154 Suggested value 18. 1155 TBD3 1156 Multicast P2MP LDP FEC Stack (Section 3.1.2). 1157 Suggested value 19. 1158 TBD4 1159 Multicast MP2MP LDP FEC Stack (Section 3.1.2). 1160 Suggested value 20. 1162 7.2. New TLVs 1164 Two new LSP Ping TLV types are defined for inclusion in LSP Ping 1165 messages. 1167 IANA is requested to assign a new value from the "Multi-Protocol 1168 Label Switching Architecture (MPLS) Label Switched Paths (LSPs) 1169 Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as 1170 follows using a Standards Action value. 1172 TBD5 1173 P2MP Responder Identifier TLV (see Section 3.2) is a mandatory 1174 TLV. 1175 Suggested value 11. 1177 Four sub-TLVs are defined. 1178 - Type 1: IPv4 Egress Address P2MP Responder Identifier 1179 - Type 2: IPv6 Egress Address P2MP Responder Identifier 1180 - Type 3: IPv4 Node Address P2MP Responder Identifier 1181 - Type 4: IPv6 Node Address P2MP Responder Identifier 1183 TBD6 1184 Echo Jitter TLV (see Section 3.3) is a mandatory TLV. 1185 Suggested value 12. 1187 7.3. New Global Flags Registry 1189 IANA is requested to create a new sub-registry of the "Multi-Protocol 1190 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 1191 registry. The sub-registry should be called "Global Flags" registry. 1193 This registry tracks the assignment of 16 flags in the Global Flags 1194 field of the MPLS LSP Ping echo request message. The flags are 1195 numbered from 0 (most significant bit, transmitted first) to 15. 1197 New entries are assigned by Standards Action 1199 Initial entries in the registry should read: 1201 Bit number | Name | Reference 1202 ------------+----------------------------+-------------- 1203 15 | V Flag | [RFC4379] 1204 14 | T Flag | [This I-D] 1205 13-0 | Unassigned | 1207 8. Security Considerations 1209 This document does not introduce security concerns over and above 1210 those described in [RFC4379]. Note that because of the scalability 1211 implications of many egresses to P2MP MPLS LSPs, there is a stronger 1212 concern to regulate the LSP Ping traffic passed to the control plane 1213 by the use of a rate limiter applied to the LSP Ping well-known UDP 1214 port. This rate limiting might lead to false indications of LSP 1215 failure. 1217 9. Acknowledgements 1219 The authors would like to acknowledge the authors of [RFC4379] for 1220 their work which is substantially re-used in this document. Also 1221 thanks to the members of the MBONED working group for their review of 1222 this material, to Daniel King and Mustapha Aissaoui for their review, 1223 and to Yakov Rekhter for useful discussions. 1225 The authors would like to thank Bill Fenner, Vanson Lim, Danny 1226 Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin 1227 Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar, 1228 Sam Aldrin, and IJsbrand Wijnands for their comments and suggestions. 1230 10. References 1232 10.1. Normative References 1234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1235 Requirement Levels", BCP 14, RFC 2119, March 1997. 1237 [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol 1238 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1239 February 2006. 1241 [DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism 1242 for Performing LSP-Ping over MPLS Tunnels", draft-ietf- 1243 mpls-lsp-ping-enhanced-dsmap, work in progress. 1245 10.2. Informative References 1247 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 1249 [RFC4461] Yasukawa, S., "Signaling Requirements for Point to 1250 Multipoint Traffic Engineered Multiprotocol Label 1251 Switching (MPLS) Label Switched Paths (LSPs)", 1252 RFC 4461, April 2006. 1254 [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1255 "Operations and Management (OAM) Requirements for 1256 Point-to-Multipoint MPLS Networks", RFC 4687, September 1257 2006. 1259 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 1260 "Extensions to Resource Reservation Protocol - Traffic 1261 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1262 Switched Paths (LSPs)", RFC 4875, May 2007. 1264 [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for 1265 point-to-multipoint extensions to the Label Distribution 1266 Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. 1268 [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol 1269 Extensions for Point-to-Multipoint and 1270 Multipoint-to-Multipoint Label Switched Paths", 1271 draft-ietf-mpls-ldp-p2mp, work in progress. 1273 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., 1274 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1275 Switched Paths (LSPs)", RFC 5884, June 2010 1277 [IANA-PORT] IANA Assigned Port Numbers, 1278 http://www.iana.org/assignments/mpls-lsp-parameters/ 1280 [RFC4461] S. Yasukawa, et al., "Signaling Requirements for 1281 Point-to-Multipoint Traffic-Engineered MPLS Label 1282 Switched Paths (LSPs)", RFC 4461, April 2006 1284 [RFC4020] Kompella, K., Zinin, A., "Early Allocation of Standard 1285 Code Points", RFC 4020, February 2005. 1287 11. Authors' Addresses 1289 Seisho Yasukawa 1290 NTT Corporation 1291 (R&D Strategy Department) 1292 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 1293 Phone: +81 3 5205 5341 1294 Email: yasukawa.seisho@lab.ntt.co.jp 1296 Adrian Farrel 1297 Juniper Networks 1298 Email: adrian@olddog.co.uk 1299 Zafar Ali 1300 Cisco Systems Inc. 1301 2000 Innovation Drive 1302 Kanata, ON, K2K 3E8, Canada. 1303 Phone: 613-889-6158 1304 Email: zali@cisco.com 1306 George Swallow 1307 Cisco Systems, Inc. 1308 1414 Massachusetts Ave 1309 Boxborough, MA 01719 1310 Email: swallow@cisco.com 1312 Thomas D. Nadeau 1313 Email: tnadeau@lucidvision.com 1315 Shaleen Saxena 1316 Cisco Systems, Inc. 1317 1414 Massachusetts Ave 1318 Boxborough, MA 01719 1319 Email: ssaxena@cisco.com 1321 12. Full Copyright Statement 1323 Copyright (c) 2011 IETF Trust and the persons identified as the 1324 document authors. All rights reserved. 1326 This document is subject to BCP 78 and the IETF Trust's Legal 1327 Provisions Relating to IETF Documents 1328 (http://trustee.ietf.org/license-info) in effect on the date of 1329 publication of this document. Please review these documents 1330 carefully, as they describe your rights and restrictions with respect 1331 to this document. Code Components extracted from this document must 1332 include Simplified BSD License text as described in Section 4.e of 1333 the Trust Legal Provisions and are provided without warranty as 1334 described in the Simplified BSD License. 1336 This document may contain material from IETF Documents or IETF 1337 Contributions published or made publicly available before November 1338 10, 2008. The person(s) controlling the copyright in some of this 1339 material may not have granted the IETF Trust the right to allow 1340 modifications of such material outside the IETF Standards Process. 1341 Without obtaining an adequate license from the person(s) controlling 1342 the copyright in such materials, this document may not be modified 1343 outside the IETF Standards Process, and derivative works of it may 1344 not be created outside the IETF Standards Process, except to format 1345 it for publication as an RFC or to translate it into languages other 1346 than English.