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