idnits 2.17.1 draft-ietf-mpls-p2mp-lsp-ping-12.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 (October 18, 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: April 17, 2011 S. Yasukawa 6 NTT Corporation 7 October 18, 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-12.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................................. 14 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.................. 17 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.................................................... 24 107 10.1. Normative References........................................ 25 108 10.2. Informative References...................................... 25 109 11. Authors' Addresses............................................ 26 110 12. Full Copyright Statement...................................... 26 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 1, then the reciever SHOULD reply only if the 584 TTL of the incoming MPLS label is equal to 1; if the TTL is more than 585 1, then no response should be sent back. If there is no incoming 586 MPLS label on the echo request packet, then this bit SHOULD be 587 ignored. 589 If the T flag is set to 0, then the receiver SHOULD reply as per 590 regular processing. 592 3.5. Downstream Detailed Mapping TLV 594 Downstream Detailed Mapping TLV is described in [DDMT]. A transit, 595 branch or bud node can use the Downstream Detailed Mapping TLV to 596 return multiple Return Codes for different downstream paths. This 597 functionality can not be achieved via the Downstream Mapping TLV. As 598 per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in 599 [RFC4379] is being deprecated. 601 Therefore for P2MP, a node MUST support Downstream Detailed Mapping 602 TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP 603 traceroute functionality and SHOULD NOT be included in an Echo Request 604 message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type 605 or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any 606 Downstream Mapping TLV it receives in the echo request and MUST 607 continue processing as if the Downstream Mapping TLV is not present. 609 The details of the Return Codes to be used in the Downstream Detailed 610 Mapping TLV are provided in section 4. 612 4. Operation of LSP Ping for a P2MP LSP 614 This section describes how LSP Ping is applied to P2MP MPLS LSPs. As 615 mentioned previously, an important design consideration has been to 616 extend existing LSP Ping mechanism in [RFC4379] rather than invent 617 new mechanisms. 619 As specified in [RFC4379], MPLS LSPs can be tested via a "ping" mode 620 or a "traceroute" mode. The ping mode is also known as "connectivity 621 verification" and traceroute mode is also known as "fault isolation". 622 Further details can be obtained from [RFC4379]. 624 This section specifies processing of echo requests for both ping and 625 traceroute mode at various nodes (ingress, transit, etc.) of the P2MP 626 LSP. 628 4.1. Initiating Router Operations 630 The router initiating the echo request will follow the procedures in 631 [RFC4379]. The echo request will contain a Target FEC Stack TLV. To 632 identify the P2MP LSP under test, this TLV will contain one of the 633 new sub-TLVs defined in section 3.1. Additionally there may be other 634 optional TLVs present. 636 4.1.1. Limiting Responses to Echo Requests 638 As described in Section 2.2, it may be desirable to restrict the 639 operation of P2MP ping or traceroute to a single egress. Since echo 640 requests are forwarded through the data plane without interception by 641 the control plane, there is no facility to limit the propagation of 642 echo requests, and they will automatically be forwarded to all 643 reachable egresses. 645 However, a single egress may be identified by the inclusion of a P2MP 646 Responder Identifier TLV. The details of this TLV and its Sub-TLVs 647 are in section 3.2. There are two main types of sub-TLV in the P2MP 648 Responder Identifier TLV: Egress Address sub-TLV and Node Address 649 sub-TLV. 651 These sub-TLVs limit the responses either to the specified router 652 only or to any router on the path to the specified router. The 653 former capability is generally useful for ping mode, while the latter 654 is more suited to traceroute mode. An initiating router may indicate 655 that it wishes all egresses to respond to an echo request by omitting 656 the P2MP Responder Identifier TLV. 658 4.1.2. Jittered Responses to Echo Requests 660 The initiating router MAY request the responding routers to introduce 661 a random delay (or jitter) before sending the response. The 662 randomness of the delay allows the responses from multiple egresses 663 to be spread over a time period. Thus this technique is particularly 664 relevant when the entire P2MP LSP is being pinged or traced since it 665 helps prevent the initiating (or nearby) routers from being swamped 666 by responses, or from discarding responses due to rate limits that 667 have been applied. 669 It is desirable for the initiating rotuer to be able to control the 670 bounds of the jitter. If the tree size is small, only a small amount 671 of jitter is required, but if the tree is large, greater jitter is 672 needed. 674 The initiating router can supply the desired value of the jitter in 675 the Echo Jitter TLV as defined section 3.3. If this TLV is present, 676 the responding router MUST delay sending a response for a random 677 amount of time between zero milliseconds and the value indicated in 678 the TLV. If the TLV is absent, the responding egress SHOULD NOT 679 introduce any additional delay in responding to the echo request. 681 LSP ping SHOULD NOT be used to attempt to measure the round-trip time 682 for data delivery. This is because the P2MP LSPs are unidirectional, 683 and the echo response is often sent back through the control plane. 684 The timestamp fields in the echo request and echo response packets 685 MAY be used to deduce some information about delivery times and 686 particularly the variance in delivery times. 688 The use of echo jittering does not change the processes for gaining 689 information, but note that the responding node MUST set the value in 690 the Timestamp Received fields before applying any delay. 692 Echo response jittering SHOULD be used for P2MP LSPs. If the Echo 693 Jitter TLV is present in an echo request for any other type of LSPs, 694 the responding egress MAY apply the jitter behavior as described 695 here. 697 4.2. Responding Router Operations 699 Usually the echo request packet will reach the egress and bud nodes. 700 In case of TTL Expiry, i.e. traceroute mode, the echo request packet 701 may stop at branch or transit nodes. In both scenarios, the echo 702 request will be passed on to control plane for reply processing. 704 The operations at the receiving node are an extenstion to the 705 existing processing as specified in [RFC4379]. A responding router 706 is RECOMMENDED to rate limit its receipt of echo request messages. 707 After rate limiting, the responding router must verify general sanity 708 of the packet. If the packet is malformed, or certain TLVs are not 709 understood, the [RFC4379] procedures must be followed for echo reply. 710 Similarly the Reply Mode field determines if the response is required 711 or not (and the mechanism to send it back). 713 For P2MP LSP ping and traceroute, i.e. if the echo request is 714 carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding 715 router MUST determine whether it is part of the P2MP LSP in question 716 by checking with the control plane. 718 - If the node is not part of the P2MP LSP, it MUST respond 719 according to [RFC4379] processing rules. 721 - If the node is part of the P2MP LSP, the node must check whether 722 the echo request is directed to it or not. 724 - If a P2MP Responder Identifier TLV is present, then the node 725 must follow the procedures defined in section 3.2 to 726 determine whether it should respond to the reqeust or not. 727 The presence of a P2MP Responder Identifier TLV or a 728 Downstream Detailed Mapping TLV might affect the Return Code. 730 This is discussed in more detail later. 732 - If the P2MP Responder Identifier TLV is not present (or, in 733 the error case, is present, but does not contain any 734 sub-TLVs), then the node MUST respond according to [RFC4379] 735 processing rules. 737 4.2.1. Echo Response Reporting 739 Echo response messages carry return codes and subcodes to indicate 740 the result of the LSP Ping (when the ping mode is being used) as 741 described in [RFC4379]. 743 When the responding node reports that it is an egress, it is clear 744 that the echo response applies only to the reporting node. 745 Similarly, when a node reports that it does not form part of the LSP 746 described by the FEC (i.e. there is a misconnection) then the echo 747 response applies to the reporting node. 749 However, it should be noted that an echo response message that 750 reports an error from a transit node may apply to multiple egress 751 nodes (i.e. leaves) downstream of the reporting node. In the case of 752 the ping mode of operation, it is not possible to correlate the 753 reporting node to the affected egresses unless the topology of the 754 P2MP tree is already known, and it may be necessary to use the 755 traceroute mode of operation to further diagnose the LSP. 757 Note also that a transit node may discover an error but also 758 determine that while it does lie on the path of the LSP under test, 759 it does not lie on the path to the specific egress being tested. In 760 this case, the node SHOULD NOT generate an echo response. 762 The following sections describe the expected values of Return Codes 763 for various nodes in a P2MP LSP. It is assumed that the sanity and 764 other checks have been performed and an echo response is being sent 765 back. As mentioned previously, the Return Code might change based on 766 the presence of Responder Identifier TLV or Downstream Detailed 767 Mapping TLV. 769 4.2.1.1. Responses from Transit and Branch nodes 771 The presence of a Responder Identifier TLV does not influence the 772 choice of the Return Code, which MAY be set to value 8 ('Label 773 switched at stack-depth ') or any other error value as needed. 775 The presence of a Downstream Detailed Mapping TLV will influence the 776 choice of Return Code. As per [DDMT], the Return Code in the echo 777 response header MAY be set to value TBD ('See DDM TLV for Return Code 778 and Return SubCode') as defined in [DDMT]. The Return Code for each 779 Downstream Detailed Mapping TLV will depend on the downstream path as 780 described in [DDMT]. 782 There will be a Downstream Detailed Mapping TLV for each downstream 783 path being reported in the echo response. Hence for transit nodes, 784 there will be only one such TLV and for branch nodes, there will be 785 more than one. If there is an Egress Address Responder Identifier 786 Sub-TLV, then the branch node will include only one Downstream 787 Detailed Mapping TLV corresponding to the downstream path required to 788 reach the address specified in the Egress Address Sub-TLV. 790 4.2.1.2. Responses from Egress Nodes 792 The presence of a Responder Identifier TLV does not influence the 793 choice of the Return Code, which MAY be set to value 3 ('Replying 794 router is an egress for the FEC at stack-depth ') or any other 795 error value as needed. 797 The presence of the Downstream Detailed Mapping TLV does not 798 influence the choice of Return Code. Egress nodes do not put in any 799 Downstream Detailed Mapping TLV in the echo response. 801 4.2.1.3. Responses from Bud Nodes 803 The case of bud nodes is more complex than other types of nodes. The 804 node might behave as either an egress node or a transit node or a 805 combination of an egress and branch node. This behavior is 806 determined by the presence of any Responder Identifier TLV and the 807 type of sub-TLV in it. Similarly Downstream Detailed Mapping TLV can 808 influence the Return Code values. 810 To determine the behavior of the bud node, use the following 811 guidelines. The intent of these guidelines is to figure out if the 812 echo request is meant for all nodes, or just this node, or for 813 another node reachable through this node or for a different section 814 of the tree. In the first case, the node will behave like a 815 combination of egress and branch node; in the second case, the node 816 will behave like pure egress node; in the third case, the node will 817 behave like a transit node; and in the last case, no response will be 818 sent back. 820 Node behavior guidelines: 822 - If the Responder Identifier TLV is not present, then the node 823 will behave as a combination egress and branch node. 825 - If the Responder Identifier TLV containing a Node Address 826 sub-TLV is present, and: 828 - If the address specified in the sub-TLV matches to an address 829 in the node, then the node will behave like an combination 830 egress and branch node. 832 - If the address specified in the sub-TLV does not match any 833 address in the node, then no response will be sent. 835 - If the Responder Identifier TLV containing an Egress Address 836 sub-TLV is present, and: 838 - If the address specified in the sub-TLV matches to an address 839 in the node, then the node will behave like an egress node 840 only. 842 - If the node lies on the path to the address specified in the 843 sub-TLV, then the node will behave like a transit node. 845 - If the node does not lie on the path to the address specified 846 in the sub-TLV, then no response will be sent. 848 Once the node behavior has been determined, the possible values for 849 Return Codes are as follows: 851 - If the node is behaving as an egress node only, then the Return 852 Code MAY be set to value 3 ('Replying router is an egress for 853 the FEC at stack-depth ') or any other error value as 854 needed. The echo response MUST NOT contain any Downstream 855 Detailed Mapping TLV, even if one is present in the echo 856 request. 858 - If the node is behaving as a transit node, and: 860 - If a Downstream Detailed Mapping TLV is not present, then 861 the Return Code MAY be set to value 8 ('Label switched at 862 stack-depth ') or any other error value as needed. 864 - If a Downstream Detailed Mapping TLV is present, then the 865 Return Code MAY be set to value TBD ('See DDM TLV for 866 Return Code and Return SubCode') as defined in [DDMT]. The 867 Return Code for the Downstream Detailed Mapping TLV will 868 depend on the downstream path as described in [DDMT]. 869 There will be only one Downstream Detailed Mapping 870 corresponding to the downstream path to the address 871 specified in the Egress Address Sub-TLV. 873 - If the node is behaving as a combination egress and branch node, 874 and: 876 - If a Downstream Detailed Mapping TLV is not present, then 877 the Return Code MAY be set to value 3 ('Replying router is 878 an egress for the FEC at stack-depth ') or any other 879 error value as needed. 881 - If a Downstream Detailed Mapping TLV is present, then the 882 Return Code MAY be set to value 3 ('Replying router is an 883 egress for the FEC at stack-depth ') or any other 884 error value as needed. Return Code for the each Downstream 885 Detailed Mapping TLV will depend on the downstream path as 886 described in [DDMT]. There will be a Downstream Detailed 887 Mapping for each downstream path from the node. 889 4.3. Special Considerations for Traceroute 891 4.3.1. End of Processing for Traceroutes 893 As specified in [RFC4379], the traceroute mode operates by sending a 894 series of echo requests with sequentially increasing TTL values. For 895 regular P2P targets, this processing stops when a valid response is 896 received from the intended egress or when some errored return code is 897 received. 899 For P2MP targets, there may not be an easy way to figure out the end 900 of the traceroute processing, as there are multiple egress nodes. 901 Receiving a valid response from an egress will not signal the end of 902 processing. 904 In P2MP TE LSP, the initiating router has a priori knowledge about 905 number of egress nodes and their addresses. Hence it possible to 906 continue processing till a valid response has been received from each 907 end-point, provided the responses can be matched correctly to the 908 egress nodes. 910 However in Multicast LDP LSPs, the initiating router has no knowledge 911 about the egress nodes. Hence it is not possible to estimate the end 912 of processing for traceroute in such scenarios. 914 Therefore it is RECOMMENDED that traceroute operations provide for a 915 configurable upper limit on TTL values. Hence the user can choose 916 the depth to which the tree will be probed. 918 4.3.2. Multiple responses from Bud and Egress Nodes 920 The P2MP traceroute may continue even after it has received a valid 921 response from a bud or egress node, as there may be more nodes at 922 deeper levels. Hence for subsequent TTL values, a bud or egress node 923 that has previously replied would continue to get new echo requests. 924 Since each echo request is handled independently from previous 925 requests, these bud and egress nodes will keep on responding to the 926 traceroute echo requests. This can cause extra processing burden for 927 the initiating router and these bud or egress routers. 929 To prevent a bud or egress node from sending multiple responses in 930 the same traceroute operation, a new "Respond Only If TTL Expired" 931 flag is being introduced. This flag is described in Section 3.4. 933 It is RECOMMENDED that this flag be used for P2MP traceroute mode 934 only. By using this flag, extraneous responses from bud and egress 935 nodes can be reduced. If PHP is being used in the P2MP tree, then 936 bud and egress nodes will not get any labels with the echo request 937 packet. Hence this mechanism will not be effective for PHP scenario. 939 4.3.3. Non-Response to Traceroute Echo Requests 941 There are multiple reasons for which an ingress node may not receive 942 a response to its echo request. For example, the transit node has 943 failed, or the transit node does not support LSP Ping. 945 When no response to an echo request is received by the ingress, then 946 as per [RFC4379] the subsequent echo request with a larger TTL SHOULD 947 be sent. 949 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request 951 As described in section 4.6 of [RFC4379], an initiating router, 952 during traceroute, SHOULD copy the Downstream Mapping(s) into its 953 next echo request(s). However for P2MP LSPs, the intiating router 954 will receive multiple sets of Downstream Detailed Mapping TLV from 955 different nodes. It is not practical to copy all of them into the 956 next echo request. Hence this behavior is being modified for P2MP 957 LSPs. In the echo request packet, the "Downstream IP Address" field, 958 of the Downstream Detailed Mapping TLV, SHOULD be set to the 959 ALLROUTERS multicast address. 961 If an Egress Address Responder Identifier sub-TLV is being used, then 962 the traceroute is limited to only one path to one egress. Therefore 963 this traceroute is effectively behaving like a P2P traceroute. In 964 this scenario, as per section 4.2, the echo responses from 965 intermediate nodes will contain only one Downstream Detailed Mapping 966 TLV corresponding to the downstream path required to reach the 967 address specified in the Egress Address sub-TLV. For this case, the 968 echo request packet MAY reuse a received Downstream Detailed Mapping 969 TLV. 971 4.3.5 Cross Over Node Processing 973 A cross-over nodes will require slightly different processing for 974 traceroute mode. The following definition of cross-over is taken from 975 [RFC4875]. 977 The term "cross-over" refers to the case of an ingress or transit 978 node that creates a branch of a P2MP LSP, a cross-over branch, that 979 intersects the P2MP LSP at another node farther down the tree. It 980 is unlike re-merge in that, at the intersecting node, the 981 cross-over branch has a different outgoing interface as well as a 982 different incoming interface. 984 During traceroute, a cross-over node will receive the echo requests 985 via each of its input interfaces. Therefore the Downstream Detailed 986 Mapping TLV in the echo response SHOULD carry information only about 987 the outgoing interface corresponding to the input interface. 989 Due to this restriction, the cross-over node will not duplicate the 990 outgoing interface information in each of the echo request it 991 receives via the different input interfaces. This will reflect the 992 actual packet replication in the data plane. 994 5. Non-compliant Routers 996 If a node for a P2MP LSP does not support MPLS LSP ping, then no 997 reply will be sent, resulting in a "false negative" result. There is 998 no protection for this situation, and operators may wish to ensure 999 that all nodes for P2MP LSPs are all equally capable of supporting 1000 this function. 1002 If the non-compliant node is an egress, then the traceroute mode can 1003 be used to verify the LSP nearly all the way to the egress, leaving 1004 the final hop to be verified manually. 1006 If the non-compliant node is a branch or transit node, then it should 1007 not impact ping mode. However the node will not respond during 1008 traceroute mode. 1010 6. OAM Considerations 1012 The procedures in this document provide OAM functions for P2MP MPLS 1013 LSPs and may be used to enable bootstrapping of other OAM procedures. 1015 In order to be fully operational several considerations must be made. 1017 - Scaling concerns dictate that only cautious use of LSP Ping 1018 should be made. In particular, sending an LSP Ping to all 1019 egresses of a P2MP MPLS LSP could result in congestion at or 1020 near the ingress when the responses arrive. 1022 Further, incautious use of timers to generate LSP Ping echo 1023 requests either in ping mode or especially in traceroute may 1024 lead to significant degradation of network performance. 1026 - Management interfaces should allow an operator full control over 1027 the operation of LSP Ping. In particular, it SHOULD provide the 1028 ability to limit the scope of an LSP Ping echo request for a 1029 P2MP MPLS LSP to a single egress. 1031 Such an interface SHOULD also provide the ability to disable all 1032 active LSP Ping operations to provide a quick escape if the 1033 network becomes congested. 1035 - A MIB module is required for the control and management of LSP 1036 Ping operations, and to enable the reported information to be 1037 inspected. 1039 There is no reason to believe this should not be a simple 1040 extension of the LSP Ping MIB module used for P2P LSPs. 1042 7. IANA Considerations 1044 7.1. New Sub-TLV Types 1046 Four new sub-TLV types are defined for inclusion within the LSP Ping 1047 [RFC4379] Target FEC Stack TLV (TLV type 1). 1049 IANA is requested to assign sub-type values to the following sub-TLVs 1050 from the "Multiprotocol Label Switching Architecture (MPLS) Label 1051 Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and 1052 sub-TLVs" sub-registry. 1054 RSVP P2MP IPv4 Session (Section 3.1.1). Suggested value 17. 1055 RSVP P2MP IPv6 Session (Section 3.1.1). Suggested value 18. 1056 Multicast P2MP LDP FEC Stack (Section 3.1.2). Suggested value 19. 1057 Multicast MP2MP LDP FEC Stack (Section 3.1.2). Suggested value 20. 1059 7.2. New TLVs 1061 Two new LSP Ping TLV types are defined for inclusion in LSP Ping 1062 messages. 1064 IANA is requested to assign a new value from the "Multi-Protocol 1065 Label Switching Architecture (MPLS) Label Switched Paths (LSPs) 1066 Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as 1067 follows using a Standards Action value. 1069 P2MP Responder Identifier TLV (see Section 3.2) is a mandatory 1070 TLV. Suggested value 11. Four sub-TLVs are defined. 1071 - Type 1: IPv4 Egress Address P2MP Responder Identifier 1072 - Type 2: IPv6 Egress Address P2MP Responder Identifier 1073 - Type 3: IPv4 Node Address P2MP Responder Identifier 1074 - Type 4: IPv6 Node Address P2MP Responder Identifier 1076 Echo Jitter TLV (see Section 3.3) is a mandatory TLV. Suggested 1077 value 12. 1079 8. Security Considerations 1081 This document does not introduce security concerns over and above 1082 those described in [RFC4379]. Note that because of the scalability 1083 implications of many egresses to P2MP MPLS LSPs, there is a stronger 1084 concern to regulate the LSP Ping traffic passed to the control plane 1085 by the use of a rate limiter applied to the LSP Ping well-known UDP 1086 port. Note that this rate limiting might lead to false positives. 1088 9. Acknowledgements 1090 The authors would like to acknowledge the authors of [RFC4379] for 1091 their work which is substantially re-used in this document. Also 1092 thanks to the members of the MBONED working group for their review of 1093 this material, to Daniel King and Mustapha Aissaoui for their review, 1094 and to Yakov Rekhter for useful discussions. 1096 The authors would like to thank Bill Fenner, Vanson Lim, Danny 1097 Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin 1098 Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar, 1099 Sam Aldrin and IJsbrand Wijnands for their comments and suggestions. 1101 10. References 1102 10.1. Normative References 1104 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1105 Requirement Levels", BCP 14, RFC 2119, March 1997. 1107 [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol 1108 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1109 February 2006. 1111 [DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism 1112 for Performing LSP-Ping over MPLS Tunnels", draft-ietf- 1113 mpls-lsp-ping-enhanced-dsmap, work in progress. 1115 10.2. Informative References 1117 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 1119 [RFC4461] Yasukawa, S., "Signaling Requirements for Point to 1120 Multipoint Traffic Engineered Multiprotocol Label 1121 Switching (MPLS) Label Switched Paths (LSPs)", 1122 RFC 4461, April 2006. 1124 [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1125 "Operations and Management (OAM) Requirements for 1126 Point-to-Multipoint MPLS Networks", RFC 4687, September 1127 2006. 1129 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 1130 "Extensions to Resource Reservation Protocol - Traffic 1131 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1132 Switched Paths (LSPs)", RFC 4875, May 2007. 1134 [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for 1135 point-to-multipoint extensions to the Label Distribution 1136 Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. 1138 [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol 1139 Extensions for Point-to-Multipoint and 1140 Multipoint-to-Multipoint Label Switched Paths", 1141 draft-ietf-mpls-ldp-p2mp, work in progress. 1143 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., 1144 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1145 Switched Paths (LSPs)", RFC 5884, June 2010. 1147 [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 1149 11. Authors' Addresses 1151 Seisho Yasukawa 1152 NTT Corporation 1153 (R&D Strategy Department) 1154 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 1155 Phone: +81 3 5205 5341 1156 Email: yasukawa.seisho@lab.ntt.co.jp 1158 Adrian Farrel 1159 Old Dog Consulting 1160 EMail: adrian@olddog.co.uk 1162 Zafar Ali 1163 Cisco Systems Inc. 1164 2000 Innovation Drive 1165 Kanata, ON, K2K 3E8, Canada. 1166 Phone: 613-889-6158 1167 Email: zali@cisco.com 1169 George Swallow 1170 Cisco Systems, Inc. 1171 1414 Massachusetts Ave 1172 Boxborough, MA 01719 1173 Email: swallow@cisco.com 1175 Thomas D. Nadeau 1176 British Telecom 1177 BT Centre 1178 81 Newgate Street 1179 EC1A 7AJ 1180 London 1181 Email: tom.nadeau@bt.com 1183 Shaleen Saxena 1184 Cisco Systems, Inc. 1185 1414 Massachusetts Ave 1186 Boxborough, MA 01719 1187 Email: ssaxena@cisco.com 1189 12. Full Copyright Statement 1191 Copyright (c) 2010 IETF Trust and the persons identified as the 1192 document authors. All rights reserved. 1194 This document is subject to BCP 78 and the IETF Trust's Legal 1195 Provisions Relating to IETF Documents 1196 (http://trustee.ietf.org/license-info) in effect on the date of 1197 publication of this document. Please review these documents 1198 carefully, as they describe your rights and restrictions with respect 1199 to this document. Code Components extracted from this document must 1200 include Simplified BSD License text as described in Section 4.e of 1201 the Trust Legal Provisions and are provided without warranty as 1202 described in the Simplified BSD License. 1204 This document may contain material from IETF Documents or IETF 1205 Contributions published or made publicly available before November 1206 10, 2008. The person(s) controlling the copyright in some of this 1207 material may not have granted the IETF Trust the right to allow 1208 modifications of such material outside the IETF Standards Process. 1209 Without obtaining an adequate license from the person(s) controlling 1210 the copyright in such materials, this document may not be modified 1211 outside the IETF Standards Process, and derivative works of it may 1212 not be created outside the IETF Standards Process, except to format 1213 it for publication as an RFC or to translate it into languages other 1214 than English.