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