idnits 2.17.1 draft-ietf-mpls-p2mp-lsp-ping-16.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 (March 14, 2011) is 4791 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) ** 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 (~~), 1 warning (==), 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: September 14, 2011 A. Farrel 6 Old Dog Consulting 7 S. Yasukawa 8 NTT Corporation 9 T. Nadeau 10 LucidVision 11 March 14, 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-16.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 This document updates RFC 4379. 43 Recent proposals have extended the scope of Multiprotocol Label 44 Switching (MPLS) Label Switched Paths (LSPs) to encompass 45 point-to-multipoint (P2MP) LSPs. 47 The requirement for a simple and efficient mechanism that can be used 48 to detect data plane failures in point-to-point (P2P) MPLS LSPs has 49 been recognized and has led to the development of techniques for 50 fault detection and isolation commonly referred to as "LSP Ping". 52 The scope of this document is fault detection and isolation for P2MP 53 MPLS LSPs. This documents does not replace any of the mechanisms of 54 LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and 55 extends the techniques and mechanisms of LSP Ping to the MPLS P2MP 56 environment. 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............ 12 88 3.3. Preventing Congestion of Echo Responses...................... 12 89 3.4. Respond Only If TTL Expired Flag............................. 13 90 3.5. Downstream Detailed Mapping TLV.............................. 14 91 4. Operation of LSP Ping for a P2MP LSP........................... 14 92 4.1. Initiating LSR Operations.................................... 15 93 4.1.1. Limiting Responses to Echo Requests........................ 15 94 4.1.2. Jittered Responses to Echo Requests........................ 15 95 4.2. Responding LSR Operations.................................... 16 96 4.2.1. Echo Response Reporting.................................... 17 97 4.2.1.1. Responses from Transit and Branch Nodes.................. 18 98 4.2.1.2. Responses from Egress Nodes.............................. 18 99 4.2.1.3. Responses from Bud Nodes................................. 18 100 4.3. Special Considerations for Traceroute........................ 20 101 4.3.1. End of Processing for Traceroutes.......................... 20 102 4.3.2. Multiple responses from Bud and Egress Nodes............... 21 103 4.3.3. Non-Response to Traceroute Echo Requests................... 21 104 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 21 105 4.3.5 Cross-Over Node Processing.................................. 22 106 5. Non-compliant Routers.......................................... 22 107 6. OAM and Management Considerations.............................. 23 108 7. IANA Considerations............................................ 23 109 7.1. New Sub-TLV Types............................................ 24 110 7.2. New TLVs..................................................... 24 111 8. Security Considerations........................................ 24 112 9. Acknowledgements............................................... 25 113 10. References.................................................... 25 114 10.1. Normative References........................................ 25 115 10.2. Informative References...................................... 25 116 11. Authors' Addresses............................................ 26 117 12. Full Copyright Statement...................................... 27 119 1. Introduction 121 Simple and efficient mechanisms that can be used to detect data plane 122 failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) 123 Label Switched Paths (LSP) are described in [RFC4379]. The 124 techniques involve information carried in MPLS "Echo Request" and 125 "Echo Reply" messages, and mechanisms for transporting them. The 126 echo request and reply messages provide sufficient information to 127 check correct operation of the data plane, as well as a mechanism to 128 verify the data plane against the control plane, and thereby localize 129 faults. The use of reliable channels for echo reply messages as 130 described in [RFC4379] enables more robust fault isolation. This 131 collection of mechanisms is commonly referred to as "LSP Ping". 133 The requirements for point-to-multipoint (P2MP) MPLS traffic 134 engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a 135 signaling solution for establishing P2MP MPLS TE LSPs. 137 The requirements for point-to-multipoint extensions to the Label 138 Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] 139 specifies extensions to LDP for P2MP MPLS. 141 P2MP MPLS LSPs are at least as vulnerable to data plane faults or to 142 discrepancies between the control and data planes as their P2P 143 counterparts. Therefore, mechanisms are needed to detect such data 144 plane faults in P2MP MPLS LSPs as described in [RFC4687]. 146 This document extends the techniques described in [RFC4379] such that 147 they may be applied to P2MP MPLS LSPs. This document stresses the 148 reuse of existing LSP Ping mechanisms used for P2P LSPs, and applies 149 them to P2MP MPLS LSPs in order to simplify implementation and 150 network operation. 152 1.1. Design Considerations 154 An important consideration for designing LSP Ping for P2MP MPLS LSPs 155 is that every attempt is made to use or extend existing mechanisms 156 rather than invent new mechanisms. 158 As for P2P LSPs, a critical requirement is that the echo request 159 messages follow the same data path that normal MPLS packets traverse. 160 However, it can be seen this notion needs to be extended for P2MP 161 MPLS LSPs, as in this case an MPLS packet is replicated so that it 162 arrives at each egress (or leaf) of the P2MP tree. 164 MPLS echo requests are meant primarily to validate the data plane, 165 and they can then be used to validate data plane state against the 166 control plane. They may also be used to bootstrap other OAM 167 procedures such as [RFC5884]. As pointed out in [RFC4379], 168 mechanisms to check the liveness, function, and consistency of the 169 control plane are valuable, but such mechanisms are not a feature of 170 LSP Ping and are not covered in this document. 172 As is described in [RFC4379], to avoid potential Denial of Service 173 attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to 174 the control plane. A rate limiter should be applied to the 175 well-known UDP port defined for use by LSP Ping traffic. 177 1.2 Terminology 179 The terminology used in this document for P2MP MPLS can be found in 180 [RFC4461]. The terminology for MPLS OAM can be found in [RFC4379]. 181 In particular, the notation refers to the Return Subcode as 182 defined in section 3.1. of [RFC4379]. 184 2. Notes on Motivation 186 2.1. Basic Motivations for LSP Ping 188 The motivations listed in [RFC4379] are reproduced here for 189 completeness. 191 When an LSP fails to deliver user traffic, the failure cannot always 192 be detected by the MPLS control plane. There is a need to provide a 193 tool that enables users to detect such traffic "black holes" or 194 misrouting within a reasonable period of time. A mechanism to 195 isolate faults is also required. 197 [RFC4379] describes a mechanism that accomplishes these goals. This 198 mechanism is modeled after the ping/traceroute paradigm: ping (ICMP 199 echo request [RFC792]) is used for connectivity checks, and 200 traceroute is used for hop-by-hop fault localization as well as path 201 tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode 202 for testing MPLS LSPs. 204 The basic idea as expressed in [RFC4379] is to test that the packets 205 that belong to a particular Forwarding Equivalence Class (FEC) 206 actually end their MPLS path on an LSR that is an egress for that 207 FEC. [RFC4379] achieves this test by sending a packet (called an 208 "MPLS echo request") along the same data path as other packets 209 belonging to this FEC. An MPLS echo request also carries information 210 about the FEC whose MPLS path is being verified. This echo request 211 is forwarded just like any other packet belonging to that FEC. In 212 "ping" mode (basic connectivity check), the packet should reach the 213 end of the path, at which point it is sent to the control plane of 214 the egress LSR, which then verifies that it is indeed an egress for 215 the FEC. In "traceroute" mode (fault isolation), the packet is sent 216 to the control plane of each transit LSR, which performs various 217 checks that it is indeed a transit LSR for this path; this LSR also 218 returns further information that helps to check the control plane 219 against the data plane, i.e., that forwarding matches what the 220 routing protocols determined as the path. 222 One way these tools can be used is to periodically ping a FEC to 223 ensure connectivity. If the ping fails, one can then initiate a 224 traceroute to determine where the fault lies. One can also 225 periodically traceroute FECs to verify that forwarding matches the 226 control plane; however, this places a greater burden on transit LSRs 227 and should be used with caution. 229 2.2. Motivations for LSP Ping for P2MP LSPs 231 As stated in [RFC4687], MPLS has been extended to encompass P2MP 232 LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and 233 diagnose control and data plane defects is critical. For operators 234 deploying services based on P2MP MPLS LSPs, the detection and 235 specification of how to handle those defects is important because 236 such defects may affect the fundamentals of an MPLS network, but also 237 because they may impact service level specification commitments for 238 customers of their network. 240 P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish 241 multicast LSPs. These LSPs distribute data from a single source to 242 one or more destinations across the network according to the next 243 hops indicated by the routing protocols. Each LSP is identified by 244 an MPLS multicast FEC. 246 P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a 247 single ingress and multiple egresses. The tunnels, built on P2MP 248 LSPs, are explicitly routed through the network. There is no concept 249 or applicability of a FEC in the context of a P2MP MPLS TE LSP. 251 MPLS packets inserted at the ingress of a P2MP LSP are delivered 252 equally (barring faults) to all egresses. In consequence, the basic 253 idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an 254 intention to test that packets that enter (at the ingress) a 255 particular P2MP LSP actually end their MPLS path on the LSRs that are 256 the (intended) egresses for that LSP. The idea may be extended to 257 check selectively that such packets reach specific egresses. 259 The technique in this document makes this test by sending an LSP Ping 260 echo request message along the same data path as the MPLS packets. 261 An echo request also carries the identification of the P2MP MPLS LSP 262 (multicast LSP or P2MP TE LSP) that it is testing. The echo request 263 is forwarded just as any other packet using that LSP, and so is 264 replicated at branch points of the LSP and should be delivered to all 265 egresses. 267 In "ping" mode (basic connectivity check), the echo request should 268 reach the end of the path, at which point it is sent to the control 269 plane of the egress LSRs, which verify that they are indeed an egress 270 (leaf) of the P2MP LSP. An echo response message is sent by an 271 egress to the ingress to confirm the successful receipt (or announce 272 the erroneous arrival) of the echo request. 274 In "traceroute" mode (fault isolation), the echo request is sent to 275 the control plane at each transit LSR, and the control plane checks 276 that it is indeed a transit LSR for this P2MP MPLS LSP. The transit 277 LSR returns information about the outgoing paths. This information 278 can be used by ingress LSR to build topology or by downstream LSRs to 279 do extra label verification. 281 P2MP MPLS LSPs may have many egresses, and it is not necessarily the 282 intention of the initiator of the ping or traceroute operation to 283 collect information about the connectivity or path to all egresses. 284 Indeed, in the event of pinging all egresses of a large P2MP MPLS 285 LSP, it might be expected that a large number of echo responses would 286 arrive at the ingress independently but at approximately the same 287 time. Under some circumstances this might cause congestion at or 288 around the ingress LSR. The procedures described in this document 289 provide two mechanisms to control echo responses. 291 The first procedure allows the responders to randomly delay (or 292 jitter) their responses so that the chances of swamping the ingress 293 are reduced. The second procedures allows the initiator to limit the 294 scope of an LSP Ping echo request (ping or traceroute mode) to one 295 specific intended egress. 297 LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure 298 connectivity to any or all of the egresses. If the ping fails, the 299 operator or an automated process can then initiate a traceroute to 300 determine where the fault is located within the network. A 301 traceroute may also be used periodically to verify that data plane 302 forwarding matches the control plane state; however, this places an 303 increased burden on transit LSRs and should be used infrequently and 304 with caution. 306 3. Packet Format 308 The basic structure of the LSP Ping packet remains the same as 309 described in [RFC4379]. Some new TLVs and sub-TLVs are required to 310 support the new functionality. They are described in the following 311 sections. 313 3.1. Identifying the LSP Under Test 315 3.1.1. Identifying a P2MP MPLS TE LSP 317 [RFC4379] defines how an MPLS TE LSP under test may be identified in 318 an echo request. A Target FEC Stack TLV is used to carry either an 319 RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. 321 In order to identify the P2MP MPLS TE LSP under test, the echo 322 request message MUST carry a Target FEC Stack TLV, and this MUST 323 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 324 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs 325 carry fields from the RSVP-TE P2MP Session and Sender-Template 326 objects [RFC4875] and so provide sufficient information to uniquely 327 identify the LSP. 329 The new sub-TLVs are assigned sub-type identifiers as follows, and 330 are described in the following sections. 332 Sub-Type # Length Value Field 333 ---------- ------ ----------- 334 TBD 20 RSVP P2MP IPv4 Session 335 TBD 56 RSVP P2MP IPv6 Session 337 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 339 The format of the RSVP P2MP IPv4 Session sub-TLV value field is 340 specified in the following figure. The value fields are taken from 341 the definitions of the P2MP IPv4 LSP Session Object and the P2MP IPv4 342 Sender-Template Object in Sections 19.1.1 and 19.2.1 of [RFC4875]. 343 Note that the Sub-Group ID of the Sender-Template is not required. 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | P2MP ID | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Must Be Zero | Tunnel ID | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Extended Tunnel ID | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | IPv4 tunnel sender address | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Must Be Zero | LSP ID | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV 361 The format of the RSVP P2MP IPv6 Session sub-TLV value field is 362 specified in the following figure. The value fields are taken from 363 the definitions of the P2MP IPv6 LSP Session Object, and the P2MP 364 IPv6 Sender-Template Object in Sections 19.1.2 and 19.2.2 of 365 [RFC4875]. Note that the Sub-Group ID of the Sender-Template is not 366 required. 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 | P2MP ID | 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Must Be Zero | Tunnel ID | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 | Extended Tunnel ID | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | 382 | IPv6 tunnel sender address | 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Must Be Zero | LSP ID | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 3.1.2. Identifying a Multicast LDP LSP 390 [RFC4379] defines how a P2P LDP LSP under test may be identified in 391 an echo request. A Target FEC Stack TLV is used to carry one or more 392 sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the 393 LSP. 395 In order to identify a multicast LDP LSP under test, the echo request 396 message MUST carry a Target FEC Stack TLV, and this MUST carry 397 exactly one of two new sub-TLVs: either a Multicast P2MP LDP FEC 398 Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV. These 399 sub-TLVs use fields from the multicast LDP messages [P2MP-LDP] and so 400 provides sufficient information to uniquely identify the LSP. 402 The new sub-TLVs are assigned a sub-type identifiers as follows, and 403 are described in the following section. 405 Sub-Type # Length Value Field 406 ---------- ------ ----------- 407 TBD Variable Multicast P2MP LDP FEC Stack 408 TBD Variable Multicast MP2MP LDP FEC Stack 410 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs 412 Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as 413 specified in the following figure. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Address Family | Address Length| Root LSR Addr | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 ~ Root LSR Address (Cont.) ~ 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Opaque Length | Opaque Value ... | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 426 ~ ~ 427 | | 428 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Address Family 434 Two octet quantity containing a value from ADDRESS FAMILY NUMBERS 435 in [IANA-PORT] that encodes the address family for the Root LSR 436 Address. 438 Address Length 440 Length of the Root LSR Address in octets. 442 Root LSR Address 444 Address of the LSR at the root of the P2MP LSP encoded according 445 to the Address Family field. 447 Opaque Length 449 The length of the Opaque Value, in octets. Depending on length of 450 the Root LSR Address, this field may not be aligned to a word 451 boundary. 453 Opaque Value 455 An opaque value element which uniquely identifies the P2MP LSP in 456 the context of the Root LSR. 458 If the Address Family is IPv4, the Address Length MUST be 4. If the 459 Address Family is IPv6, the Address Length MUST be 16. No other 460 Address Family values are defined at present. 462 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs 464 The mechanisms defined in this document can be extended to include 465 Multipoint-to-Multipoint (MP2MP) Multicast LSPs. In an MP2MP LSP 466 tree, any leaf node can be treated like a head node of a P2MP tree. 467 In other words, for MPLS OAM purposes, the MP2MP tree can be treated 468 like a collection of P2MP trees, with each MP2MP leaf node acting 469 like a P2MP head-end node. When a leaf node is acting like a P2MP 470 head-end node, the remaining leaf nodes act like egress or bud nodes. 472 3.2. Limiting the Scope of Responses 474 A new TLV is defined for inclusion in the Echo request message. 476 The P2MP Responder Identifier TLV is assigned the TLV type value TBD 477 and is encoded as follows. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |Type=TBD(P2MP Responder ID TLV)| Length = Variable | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 ~ Sub-TLVs ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Sub-TLVs: 489 Zero, one or more sub-TLVs as defined below. 491 If no sub-TLVs are present, the TLV MUST be processed as if it 492 were absent. If more than one sub-TLV is present the first MUST 493 be processed as described in this document, and subsequent 494 sub-TLVs SHOULD be ignored. 496 The P2MP Responder Identifier TLV only has meaning on an echo request 497 message. If present on an echo response message, it SHOULD be 498 ignored. 500 Four sub-TLVs are defined for inclusion in the P2MP Responder 501 Identifier TLV carried on the echo request message. These are: 503 Sub-Type # Length Value Field 504 ---------- ------ ----------- 505 1 4 IPv4 Egress Address P2MP Responder Identifier 506 2 16 IPv6 Egress Address P2MP Responder Identifier 507 3 4 IPv4 Node Address P2MP Responder Identifier 508 4 16 IPv6 Node Address P2MP Responder Identifier 510 The content of these Sub-TLVs are defined in the following sections. 511 Also defined is the intended behavior of the responding node upon 512 receiving any of these Sub-TLVs. 514 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs 516 The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs 517 MAY be used in an echo request carrying RSVP P2MP Session Sub-TLV. 518 They SHOULD NOT be used with an echo request carrying Multicast LDP 519 FEC Stack Sub-TLV. If a node receives these TLVs in an echo request 520 carrying Multicast LDP then it SHOULD ignore these sub-TLVs and 521 respond as if they are not present. Hence these TLVs cannot be used 522 to traceroute to a single node when Multicast LDP FEC is used. 524 A node that receives an echo request with this Sub-TLV present MUST 525 respond only if the node lies on the path to the address in the 526 Sub-TLV. 528 The address in this Sub-TLV SHOULD be of an egress or bud node and 529 SHOULD NOT be of a transit or branch node. A transit or branch node, 530 should be able to determine if the address in this Sub-TLV is for an 531 egress or bud node which is reachable through it. Hence, this 532 address SHOULD be known to the nodes upstream of the target node, for 533 instance via control plane signaling. As a case in point, if RSVP-TE 534 is used to signal the P2MP LSP, this address SHOULD be the address 535 used in destination address field of the S2L_SUB_LSP object, when 536 corresponding egress or bud node is signaled. 538 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs 540 The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY 541 be used in an echo request carrying either RSVP P2MP Session or 542 Multicast LDP FEC Stack Sub-TLV. 544 A node that receives an echo request with this Sub-TLV present MUST 545 respond only if the address in the Sub-TLV corresponds to any address 546 that is local to the node. This address in the Sub-TLV may be of any 547 physical interface or may be the router id of the node itself. 549 The address in this Sub-TLV SHOULD be of any transit, branch, bud or 550 egress node for that P2MP LSP. 552 3.3. Preventing Congestion of Echo Responses 554 A new TLV is defined for inclusion in the Echo request message. 556 The Echo Jitter TLV is assigned the TLV type value TBD and is encoded 557 as follows. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type = TBD (Jitter TLV) | Length = 4 | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Jitter time | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Jitter time: 569 This field specifies the upper bound of the jitter period that 570 should be applied by a responding node to determine how long to 571 wait before sending an echo response. A responding node SHOULD 572 wait a random amount of time between zero milliseconds and the 573 value specified in this field. 575 Jitter time is specified in milliseconds. 577 The Echo Jitter TLV only has meaning on an echo request message. If 578 present on an echo response message, it SHOULD be ignored. 580 3.4. Respond Only If TTL Expired Flag 582 A new flag is being introduced in the Global Flags field defined in 583 [RFC4379]. The new format of the Global Flags field is: 585 0 1 586 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | MBZ |T|V| 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 The V flag is described in [RFC4379]. 593 The T (Respond Only If TTL Expired) flag SHOULD be set only in the 594 echo request packet by the sender. This flag SHOULD NOT be set in 595 the echo reply packet. If this flag is set in an echo reply packet, 596 then it MUST be ignored. 598 If the T flag is set to 0, then the receiver SHOULD reply as per 599 regular processing. 601 If the T flag is set to 1, then the receiver SHOULD reply only if the 602 TTL of the incoming MPLS label is equal to 1; if the TTL is more than 603 1, then no response should be sent back. 605 If the T flag is set to 1 and there are no incoming MPLS labels on 606 the echo request packet, then a bud node with PHP configured MAY 607 choose to not respond to this echo request. All other nodes SHOULD 608 ignore this bit and respond as per regular processing. 610 3.5. Downstream Detailed Mapping TLV 612 Downstream Detailed Mapping TLV is described in [DDMT]. A transit, 613 branch or bud node can use the Downstream Detailed Mapping TLV to 614 return multiple Return Codes for different downstream paths. This 615 functionality can not be achieved via the Downstream Mapping TLV. As 616 per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in 617 [RFC4379] is being deprecated. 619 Therefore for P2MP, a node MUST support Downstream Detailed Mapping 620 TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP 621 traceroute functionality and SHOULD NOT be included in an Echo Request 622 message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type 623 or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any 624 Downstream Mapping TLV it receives in the echo request and MUST 625 continue processing as if the Downstream Mapping TLV is not present. 627 The details of the Return Codes to be used in the Downstream Detailed 628 Mapping TLV are provided in section 4. 630 4. Operation of LSP Ping for a P2MP LSP 632 This section describes how LSP Ping is applied to P2MP MPLS LSPs. As 633 mentioned previously, an important design consideration has been to 634 extend existing LSP Ping mechanism in [RFC4379] rather than invent 635 new mechanisms. 637 As specified in [RFC4379], MPLS LSPs can be tested via a "ping" mode 638 or a "traceroute" mode. The ping mode is also known as "connectivity 639 verification" and traceroute mode is also known as "fault isolation". 640 Further details can be obtained from [RFC4379]. 642 This section specifies processing of echo requests for both ping and 643 traceroute mode at various nodes (ingress, transit, etc.) of the P2MP 644 LSP. 646 4.1. Initiating LSR Operations 648 The LSR initiating the echo request will follow the procedures in 649 [RFC4379]. The echo request will contain a Target FEC Stack TLV. To 650 identify the P2MP LSP under test, this TLV will contain one of the 651 new sub-TLVs defined in section 3.1. Additionally there may be other 652 optional TLVs present. 654 4.1.1. Limiting Responses to Echo Requests 656 As described in Section 2.2, it may be desirable to restrict the 657 operation of P2MP ping or traceroute to a single egress. Since echo 658 requests are forwarded through the data plane without interception by 659 the control plane, there is no facility to limit the propagation of 660 echo requests, and they will automatically be forwarded to all 661 reachable egresses. 663 However, a single egress may be identified by the inclusion of a P2MP 664 Responder Identifier TLV. The details of this TLV and its Sub-TLVs 665 are in section 3.2. There are two main types of sub-TLV in the P2MP 666 Responder Identifier TLV: Node Address sub-TLV and Egress Address 667 sub-TLV. 669 These sub-TLVs limit the responses either to the specified LSR only 670 or to any LSR on the path to the specified LSR. The former 671 capability is generally useful for ping mode, while the latter is 672 more suited to traceroute mode. An initiating LSR may indicate that 673 it wishes all egresses to respond to an echo request by omitting the 674 P2MP Responder Identifier TLV. 676 4.1.2. Jittered Responses to Echo Requests 678 The initiating LSR MAY request the responding LSRs to introduce a 679 random delay (or jitter) before sending the response. The randomness 680 of the delay allows the responses from multiple egresses to be spread 681 over a time period. Thus this technique is particularly relevant 682 when the entire P2MP LSP is being pinged or traced since it helps 683 prevent the initiating (or nearby) LSRs from being swamped by 684 responses, or from discarding responses due to rate limits that have 685 been applied. 687 It is desirable for the initiating LSR to be able to control the 688 bounds of the jitter. If the tree size is small, only a small amount 689 of jitter is required, but if the tree is large, greater jitter is 690 needed. 692 The initiating LSR can supply the desired value of the jitter in the 693 Echo Jitter TLV as defined section 3.3. If this TLV is present, the 694 responding LSR MUST delay sending a response for a random amount of 695 time between zero milliseconds and the value indicated in the TLV. 696 If the TLV is absent, the responding egress SHOULD NOT introduce any 697 additional delay in responding to the echo request. 699 LSP ping SHOULD NOT be used to attempt to measure the round-trip time 700 for data delivery. This is because the P2MP LSPs are unidirectional, 701 and the echo response is often sent back through the control plane. 702 The timestamp fields in the echo request and echo response packets 703 MAY be used to deduce some information about delivery times and 704 particularly the variance in delivery times. 706 The use of echo jittering does not change the processes for gaining 707 information, but note that the responding node MUST set the value in 708 the Timestamp Received fields before applying any delay. 710 Echo response jittering SHOULD be used for P2MP LSPs. If the Echo 711 Jitter TLV is present in an echo request for any other type of LSPs, 712 the responding egress MAY apply the jitter behavior as described 713 here. 715 4.2. Responding LSR Operations 717 Usually the echo request packet will reach the egress and bud nodes. 718 In case of TTL Expiry, i.e. traceroute mode, the echo request packet 719 may stop at branch or transit nodes. In both scenarios, the echo 720 request will be passed on to control plane for reply processing. 722 The operations at the receiving node are an extension to the existing 723 processing as specified in [RFC4379]. A responding LSR is 724 RECOMMENDED to rate limit its receipt of echo request messages. 725 After rate limiting, the responding LSR must verify general sanity of 726 the packet. If the packet is malformed, or certain TLVs are not 727 understood, the [RFC4379] procedures must be followed for echo reply. 728 Similarly the Reply Mode field determines if the response is required 729 or not (and the mechanism to send it back). 731 For P2MP LSP ping and traceroute, i.e. if the echo request is 732 carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR 733 MUST determine whether it is part of the P2MP LSP in question by 734 checking with the control plane. 736 - If the node is not part of the P2MP LSP, it MUST respond 737 according to [RFC4379] processing rules. 739 - If the node is part of the P2MP LSP, the node must check whether 740 the echo request is directed to it or not. 742 - If a P2MP Responder Identifier TLV is present, then the node 743 must follow the procedures defined in section 3.2 to 744 determine whether it should respond to the reqeust or not. 745 The presence of a P2MP Responder Identifier TLV or a 746 Downstream Detailed Mapping TLV might affect the Return Code. 747 This is discussed in more detail later. 749 - If the P2MP Responder Identifier TLV is not present (or, in 750 the error case, is present, but does not contain any 751 sub-TLVs), then the node MUST respond according to [RFC4379] 752 processing rules. 754 4.2.1. Echo Response Reporting 756 Echo response messages carry return codes and subcodes to indicate 757 the result of the LSP Ping (when the ping mode is being used) as 758 described in [RFC4379]. 760 When the responding node reports that it is an egress, it is clear 761 that the echo response applies only to the reporting node. 762 Similarly, when a node reports that it does not form part of the LSP 763 described by the FEC (i.e. there is a misconnection) then the echo 764 response applies to the reporting node. 766 However, it should be noted that an echo response message that 767 reports an error from a transit node may apply to multiple egress 768 nodes (i.e. leaves) downstream of the reporting node. In the case of 769 the ping mode of operation, it is not possible to correlate the 770 reporting node to the affected egresses unless the topology of the 771 P2MP tree is already known, and it may be necessary to use the 772 traceroute mode of operation to further diagnose the LSP. 774 Note also that a transit node may discover an error but also 775 determine that while it does lie on the path of the LSP under test, 776 it does not lie on the path to the specific egress being tested. In 777 this case, the node SHOULD NOT generate an echo response. 779 The following sections describe the expected values of Return Codes 780 for various nodes in a P2MP LSP. It is assumed that the sanity and 781 other checks have been performed and an echo response is being sent 782 back. As mentioned previously, the Return Code might change based on 783 the presence of Responder Identifier TLV or Downstream Detailed 784 Mapping TLV. 786 4.2.1.1. Responses from Transit and Branch Nodes 788 The presence of a Responder Identifier TLV does not influence the 789 choice of the Return Code, which MAY be set to value 8 ('Label 790 switched at stack-depth ') or any other error value as needed. 792 The presence of a Downstream Detailed Mapping TLV will influence the 793 choice of Return Code. As per [DDMT], the Return Code in the echo 794 response header MAY be set to value TBD ('See DDM TLV for Return Code 795 and Return SubCode') as defined in [DDMT]. The Return Code for each 796 Downstream Detailed Mapping TLV will depend on the downstream path as 797 described in [DDMT]. 799 There will be a Downstream Detailed Mapping TLV for each downstream 800 path being reported in the echo response. Hence for transit nodes, 801 there will be only one such TLV and for branch nodes, there will be 802 more than one. If there is an Egress Address Responder Identifier 803 Sub-TLV, then the branch node will include only one Downstream 804 Detailed Mapping TLV corresponding to the downstream path required to 805 reach the address specified in the Egress Address Sub-TLV. 807 4.2.1.2. Responses from Egress Nodes 809 The presence of a Responder Identifier TLV does not influence the 810 choice of the Return Code, which MAY be set to value 3 ('Replying 811 router is an egress for the FEC at stack-depth ') or any other 812 error value as needed. 814 The presence of the Downstream Detailed Mapping TLV does not 815 influence the choice of Return Code. Egress nodes do not put in any 816 Downstream Detailed Mapping TLV in the echo response. 818 4.2.1.3. Responses from Bud Nodes 820 The case of bud nodes is more complex than other types of nodes. The 821 node might behave as either an egress node or a transit node or a 822 combination of an egress and branch node. This behavior is 823 determined by the presence of any Responder Identifier TLV and the 824 type of sub-TLV in it. Similarly Downstream Detailed Mapping TLV can 825 influence the Return Code values. 827 To determine the behavior of the bud node, use the following 828 guidelines. The intent of these guidelines is to figure out if the 829 echo request is meant for all nodes, or just this node, or for 830 another node reachable through this node or for a different section 831 of the tree. In the first case, the node will behave like a 832 combination of egress and branch node; in the second case, the node 833 will behave like pure egress node; in the third case, the node will 834 behave like a transit node; and in the last case, no response will be 835 sent back. 837 Node behavior guidelines: 839 - If the Responder Identifier TLV is not present, then the node 840 will behave as a combination egress and branch node. 842 - If the Responder Identifier TLV containing a Node Address 843 sub-TLV is present, and: 845 - If the address specified in the sub-TLV matches to an address 846 in the node, then the node will behave like an combination 847 egress and branch node. 849 - If the address specified in the sub-TLV does not match any 850 address in the node, then no response will be sent. 852 - If the Responder Identifier TLV containing an Egress Address 853 sub-TLV is present, and: 855 - If the address specified in the sub-TLV matches to an address 856 in the node, then the node will behave like an egress node 857 only. 859 - If the node lies on the path to the address specified in the 860 sub-TLV, then the node will behave like a transit node. 862 - If the node does not lie on the path to the address specified 863 in the sub-TLV, then no response will be sent. 865 Once the node behavior has been determined, the possible values for 866 Return Codes are as follows: 868 - If the node is behaving as an egress node only, then the Return 869 Code MAY be set to value 3 ('Replying router is an egress for 870 the FEC at stack-depth ') or any other error value as 871 needed. The echo response MUST NOT contain any Downstream 872 Detailed Mapping TLV, even if one is present in the echo 873 request. 875 - If the node is behaving as a transit node, and: 877 - If a Downstream Detailed Mapping TLV is not present, then 878 the Return Code MAY be set to value 8 ('Label switched at 879 stack-depth ') or any other error value as needed. 881 - If a Downstream Detailed Mapping TLV is present, then the 882 Return Code MAY be set to value TBD ('See DDM TLV for 883 Return Code and Return SubCode') as defined in [DDMT]. The 884 Return Code for the Downstream Detailed Mapping TLV will 885 depend on the downstream path as described in [DDMT]. 886 There will be only one Downstream Detailed Mapping 887 corresponding to the downstream path to the address 888 specified in the Egress Address Sub-TLV. 890 - If the node is behaving as a combination egress and branch node, 891 and: 893 - If a Downstream Detailed Mapping TLV is not present, then 894 the Return Code MAY be set to value 3 ('Replying router is 895 an egress for the FEC at stack-depth ') or any other 896 error value as needed. 898 - If a Downstream Detailed Mapping TLV is present, then the 899 Return Code MAY be set to value 3 ('Replying router is an 900 egress for the FEC at stack-depth ') or any other 901 error value as needed. Return Code for the each Downstream 902 Detailed Mapping TLV will depend on the downstream path as 903 described in [DDMT]. There will be a Downstream Detailed 904 Mapping for each downstream path from the node. 906 4.3. Special Considerations for Traceroute 908 4.3.1. End of Processing for Traceroutes 910 As specified in [RFC4379], the traceroute mode operates by sending a 911 series of echo requests with sequentially increasing TTL values. For 912 regular P2P targets, this processing stops when a valid response is 913 received from the intended egress or when some errored return code is 914 received. 916 For P2MP targets, there may not be an easy way to figure out the end 917 of the traceroute processing, as there are multiple egress nodes. 918 Receiving a valid response from an egress will not signal the end of 919 processing. 921 For P2MP TE LSP, the initiating LSR has a priori knowledge about 922 number of egress nodes and their addresses. Hence it possible to 923 continue processing till a valid response has been received from each 924 end-point, provided the responses can be matched correctly to the 925 egress nodes. 927 However for Multicast LDP LSP, the initiating LSR might not always 928 know about all the egress nodes. Hence there might not be a 929 definitive way to estimate the end of processing for traceroute. 931 Therefore it is RECOMMENDED that traceroute operations provide for a 932 configurable upper limit on TTL values. Hence the user can choose 933 the depth to which the tree will be probed. 935 4.3.2. Multiple responses from Bud and Egress Nodes 937 The P2MP traceroute may continue even after it has received a valid 938 response from a bud or egress node, as there may be more nodes at 939 deeper levels. Hence for subsequent TTL values, a bud or egress node 940 that has previously replied would continue to get new echo requests. 941 Since each echo request is handled independently from previous 942 requests, these bud and egress nodes will keep on responding to the 943 traceroute echo requests. This can cause extra processing burden for 944 the initiating LSR and these bud or egress LSRs. 946 To prevent a bud or egress node from sending multiple responses in 947 the same traceroute operation, a new "Respond Only If TTL Expired" 948 flag is being introduced. This flag is described in Section 3.4. 950 It is RECOMMENDED that this flag be used for P2MP traceroute mode 951 only. By using this flag, extraneous responses from bud and egress 952 nodes can be reduced. If PHP is being used in the P2MP tree, then 953 bud and egress nodes will not get any labels with the echo request 954 packet. Hence this mechanism will not be effective for PHP scenario. 956 4.3.3. Non-Response to Traceroute Echo Requests 958 There are multiple reasons for which an ingress node may not receive 959 a response to its echo request. For example, the transit node has 960 failed, or the transit node does not support LSP Ping. 962 When no response to an echo request is received by the ingress, then 963 as per [RFC4379] the subsequent echo request with a larger TTL SHOULD 964 be sent. 966 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request 968 As described in section 4.6 of [RFC4379], an initiating LSR, during 969 traceroute, SHOULD copy the Downstream Mapping(s) into its next echo 970 request(s). However for P2MP LSPs, the intiating LSR will receive 971 multiple sets of Downstream Detailed Mapping TLV from different 972 nodes. It is not practical to copy all of them into the next echo 973 request. Hence this behavior is being modified for P2MP LSPs. In 974 the echo request packet, the "Downstream IP Address" field, of the 975 Downstream Detailed Mapping TLV, SHOULD be set to the ALLROUTERS 976 multicast address. 978 If an Egress Address Responder Identifier sub-TLV is being used, then 979 the traceroute is limited to only one path to one egress. Therefore 980 this traceroute is effectively behaving like a P2P traceroute. In 981 this scenario, as per section 4.2, the echo responses from 982 intermediate nodes will contain only one Downstream Detailed Mapping 983 TLV corresponding to the downstream path required to reach the 984 address specified in the Egress Address sub-TLV. For this case, the 985 echo request packet MAY reuse a received Downstream Detailed Mapping 986 TLV. 988 4.3.5 Cross-Over Node Processing 990 A cross-over node will require slightly different processing for 991 traceroute mode. The following definition of cross-over is taken from 992 [RFC4875]. 994 The term "cross-over" refers to the case of an ingress or transit 995 node that creates a branch of a P2MP LSP, a cross-over branch, that 996 intersects the P2MP LSP at another node farther down the tree. It 997 is unlike re-merge in that, at the intersecting node, the 998 cross-over branch has a different outgoing interface as well as a 999 different incoming interface. 1001 During traceroute, a cross-over node will receive the echo requests 1002 via each of its input interfaces. Therefore the Downstream Detailed 1003 Mapping TLV in the echo response SHOULD carry information only about 1004 the outgoing interface corresponding to the input interface. 1006 Due to this restriction, the cross-over node will not duplicate the 1007 outgoing interface information in each of the echo request it 1008 receives via the different input interfaces. This will reflect the 1009 actual packet replication in the data plane. 1011 5. Non-compliant Routers 1013 If a node for a P2MP LSP does not support MPLS LSP ping, then no 1014 reply will be sent, causing an incorrect result on the initiating 1015 LSR. There is no protection for this situation, and operators may 1016 wish to ensure that all nodes for P2MP LSPs are all equally capable 1017 of supporting this function. 1019 If the non-compliant node is an egress, then the traceroute mode can 1020 be used to verify the LSP nearly all the way to the egress, leaving 1021 the final hop to be verified manually. 1023 If the non-compliant node is a branch or transit node, then it should 1024 not impact ping mode. However the node will not respond during 1025 traceroute mode. 1027 6. OAM and Management Considerations 1029 The procedures in this document provide OAM functions for P2MP MPLS 1030 LSPs and may be used to enable bootstrapping of other OAM procedures. 1032 In order to be fully operational several considerations must be made. 1034 - Scaling concerns dictate that only cautious use of LSP Ping 1035 should be made. In particular, sending an LSP Ping to all 1036 egresses of a P2MP MPLS LSP could result in congestion at or 1037 near the ingress when the responses arrive. 1039 Further, incautious use of timers to generate LSP Ping echo 1040 requests either in ping mode or especially in traceroute may 1041 lead to significant degradation of network performance. 1043 - Management interfaces should allow an operator full control over 1044 the operation of LSP Ping. In particular, it SHOULD provide the 1045 ability to limit the scope of an LSP Ping echo request for a 1046 P2MP MPLS LSP to a single egress. 1048 Such an interface SHOULD also provide the ability to disable all 1049 active LSP Ping operations to provide a quick escape if the 1050 network becomes congested. 1052 - A MIB module is required for the control and management of LSP 1053 Ping operations, and to enable the reported information to be 1054 inspected. 1056 There is no reason to believe this should not be a simple 1057 extension of the LSP Ping MIB module used for P2P LSPs. 1059 7. IANA Considerations 1061 [Note - this paragraph to be removed before publication.] The values 1062 suggested in this section have already been assigned using the IANA 1063 early allocation process [RFC4020]. 1065 7.1. New Sub-TLV Types 1067 Four new sub-TLV types are defined for inclusion within the LSP Ping 1068 [RFC4379] Target FEC Stack TLV (TLV type 1). 1070 IANA is requested to assign sub-type values to the following sub-TLVs 1071 under TLV type 1 (Target FEC Stack) from the "Multiprotocol Label 1072 Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters 1073 - TLVs" registry, "TLVs and sub-TLVs" sub-registry. 1075 RSVP P2MP IPv4 Session (Section 3.1.1). Suggested value 17. 1076 RSVP P2MP IPv6 Session (Section 3.1.1). Suggested value 18. 1077 Multicast P2MP LDP FEC Stack (Section 3.1.2). Suggested value 19. 1078 Multicast MP2MP LDP FEC Stack (Section 3.1.2). Suggested value 20. 1080 7.2. New TLVs 1082 Two new LSP Ping TLV types are defined for inclusion in LSP Ping 1083 messages. 1085 IANA is requested to assign a new value from the "Multi-Protocol 1086 Label Switching Architecture (MPLS) Label Switched Paths (LSPs) 1087 Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as 1088 follows using a Standards Action value. 1090 P2MP Responder Identifier TLV (see Section 3.2) is a mandatory 1091 TLV. Suggested value 11. 1092 Four sub-TLVs are defined. 1093 - Type 1: IPv4 Egress Address P2MP Responder Identifier 1094 - Type 2: IPv6 Egress Address P2MP Responder Identifier 1095 - Type 3: IPv4 Node Address P2MP Responder Identifier 1096 - Type 4: IPv6 Node Address P2MP Responder Identifier 1098 Echo Jitter TLV (see Section 3.3) is a mandatory TLV. Suggested 1099 value 12. 1101 8. Security Considerations 1103 This document does not introduce security concerns over and above 1104 those described in [RFC4379]. Note that because of the scalability 1105 implications of many egresses to P2MP MPLS LSPs, there is a stronger 1106 concern to regulate the LSP Ping traffic passed to the control plane 1107 by the use of a rate limiter applied to the LSP Ping well-known UDP 1108 port. This rate limiting might lead to false indications of LSP 1109 failure. 1111 9. Acknowledgements 1113 The authors would like to acknowledge the authors of [RFC4379] for 1114 their work which is substantially re-used in this document. Also 1115 thanks to the members of the MBONED working group for their review of 1116 this material, to Daniel King and Mustapha Aissaoui for their review, 1117 and to Yakov Rekhter for useful discussions. 1119 The authors would like to thank Bill Fenner, Vanson Lim, Danny 1120 Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin 1121 Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar, 1122 Sam Aldrin and IJsbrand Wijnands for their comments and suggestions. 1124 10. References 1126 10.1. Normative References 1128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1129 Requirement Levels", BCP 14, RFC 2119, March 1997. 1131 [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol 1132 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1133 February 2006. 1135 [DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism 1136 for Performing LSP-Ping over MPLS Tunnels", draft-ietf- 1137 mpls-lsp-ping-enhanced-dsmap, work in progress. 1139 10.2. Informative References 1141 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 1143 [RFC4461] Yasukawa, S., "Signaling Requirements for Point to 1144 Multipoint Traffic Engineered Multiprotocol Label 1145 Switching (MPLS) Label Switched Paths (LSPs)", 1146 RFC 4461, April 2006. 1148 [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1149 "Operations and Management (OAM) Requirements for 1150 Point-to-Multipoint MPLS Networks", RFC 4687, September 1151 2006. 1153 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 1154 "Extensions to Resource Reservation Protocol - Traffic 1155 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1156 Switched Paths (LSPs)", RFC 4875, May 2007. 1158 [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for 1159 point-to-multipoint extensions to the Label Distribution 1160 Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. 1162 [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol 1163 Extensions for Point-to-Multipoint and 1164 Multipoint-to-Multipoint Label Switched Paths", 1165 draft-ietf-mpls-ldp-p2mp, work in progress. 1167 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., 1168 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1169 Switched Paths (LSPs)", RFC 5884, June 2010 1171 [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 1173 [RFC4461] S. Yasukawa, et al., "Signaling Requirements for 1174 Point-to-Multipoint Traffic-Engineered MPLS Label 1175 Switched Paths (LSPs)", RFC 4461, April 2006 1177 [RFC4020] Kompella, K., Zinin, A., "Early Allocation of Standard 1178 Code Points", RFC 4020, February 2005. 1180 11. Authors' Addresses 1182 Seisho Yasukawa 1183 NTT Corporation 1184 (R&D Strategy Department) 1185 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 1186 Phone: +81 3 5205 5341 1187 Email: yasukawa.seisho@lab.ntt.co.jp 1189 Adrian Farrel 1190 Old Dog Consulting 1191 EMail: adrian@olddog.co.uk 1193 Zafar Ali 1194 Cisco Systems Inc. 1195 2000 Innovation Drive 1196 Kanata, ON, K2K 3E8, Canada. 1197 Phone: 613-889-6158 1198 Email: zali@cisco.com 1200 George Swallow 1201 Cisco Systems, Inc. 1202 1414 Massachusetts Ave 1203 Boxborough, MA 01719 1204 Email: swallow@cisco.com 1205 Thomas D. Nadeau 1206 Email: tnadeau@lucidvision.com 1208 Shaleen Saxena 1209 Cisco Systems, Inc. 1210 1414 Massachusetts Ave 1211 Boxborough, MA 01719 1212 Email: ssaxena@cisco.com 1214 12. Full Copyright Statement 1216 Copyright (c) 2011 IETF Trust and the persons identified as the 1217 document authors. All rights reserved. 1219 This document is subject to BCP 78 and the IETF Trust's Legal 1220 Provisions Relating to IETF Documents 1221 (http://trustee.ietf.org/license-info) in effect on the date of 1222 publication of this document. Please review these documents 1223 carefully, as they describe your rights and restrictions with respect 1224 to this document. Code Components extracted from this document must 1225 include Simplified BSD License text as described in Section 4.e of 1226 the Trust Legal Provisions and are provided without warranty as 1227 described in the Simplified BSD License. 1229 This document may contain material from IETF Documents or IETF 1230 Contributions published or made publicly available before November 1231 10, 2008. The person(s) controlling the copyright in some of this 1232 material may not have granted the IETF Trust the right to allow 1233 modifications of such material outside the IETF Standards Process. 1234 Without obtaining an adequate license from the person(s) controlling 1235 the copyright in such materials, this document may not be modified 1236 outside the IETF Standards Process, and derivative works of it may 1237 not be created outside the IETF Standards Process, except to format 1238 it for publication as an RFC or to translate it into languages other 1239 than English.