idnits 2.17.1 draft-ietf-mpls-p2mp-lsp-ping-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1232. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1113. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1120. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1126. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Seisho Yasukawa (Editor) 2 Internet-Draft NTT 3 Intended Status: Standards Track Adrian Farrel (Editor) 4 Created: June 1, 2008 Old Dog Consulting 5 Expires: December 1, 2008 7 Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol 8 Label Switching (MPLS) - Extensions to LSP Ping 10 draft-ietf-mpls-p2mp-lsp-ping-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of 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 42 used to detect data plane failures in point-to-point (P2P) MPLS LSPs 43 has been recognised and has led to the development of techniques 44 for 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 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Contents 60 1. Introduction ................................................... 4 61 1.1 Design Considerations ......................................... 4 62 2. Notes on Motivation ............................................ 5 63 2.1. Basic Motivations for LSP Ping ............................... 5 64 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 6 65 2.3 Bootstrapping Other OAM Procedures Using LSP Ping ............. 7 66 3. Operation of LSP Ping for a P2MP LSP ........................... 8 67 3.1. Identifying the LSP Under Test ............................... 8 68 3.1.1. Identifying a P2MP MPLS TE LSP ............................. 8 69 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 9 70 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 9 71 3.1.2. Identifying a Multicast LDP LSP ........................... 10 72 3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10 73 3.2. Ping Mode Operation ......................................... 11 74 3.2.1. Controlling Responses to LSP Pings ........................ 11 75 3.2.2. Ping Mode Egress Procedures ............................... 12 76 3.2.3. Jittered Responses ........................................ 12 77 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 13 78 3.2.5. Echo Jitter TLV ........................................... 14 79 3.3. Traceroute Mode Operation ................................... 14 80 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15 81 3.3.1.1. Correlating Traceroute Responses ........................ 15 82 3.3.2. Traceroute Responses at Branch Nodes ..................... 16 83 3.3.2.1. Correlating Traceroute Responses ........................ 17 84 3.3.3. Traceroute Responses at Bud Nodes ......................... 17 85 3.3.4. Non-Response to Traceroute Echo Requests .................. 17 86 3.3.5. Modifications to the Downstream Mapping TLV ............... 18 87 3.3.6. Additions to Downstream Mapping Multipath Information ..... 19 88 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 20 89 5. Non-compliant Routers ......................................... 20 90 6. OAM Considerations ............................................ 20 91 7. IANA Considerations ........................................... 21 92 7.1. New Sub-TLV Types ........................................... 21 93 7.2. New Multipath Type .......................................... 21 94 7.3. New TLVs .................................................... 22 95 8. Security Considerations ....................................... 22 96 9. Acknowledgements .............................................. 22 97 10. Intellectual Property Considerations ......................... 23 98 11. Normative References ......................................... 23 99 12. Informative References ....................................... 23 100 13. Authors' Addresses ........................................... 24 101 14. Full Copyright Statement ..................................... 25 103 0. Change Log 105 This section to be removed before publication as an RFC. 107 0.1 Changes from 00 to 01 109 - Update references. 111 - Fix boilerplate. 113 0.2 Changes from 01 to 02 115 - Update entire document so that it is not specific to MPLS-TE, but 116 also includes multicast LDP LSPs. 118 - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new 119 egress identifier TLV. 121 - Include Multicast LDP FEC Stack sub-TLV definition from [MCAST-CV]. 123 - Add brief section on use of LSP Ping for bootstrapping. 125 - Add new references to References section. 127 - Add details of two new authors. 129 0.3 Changes from 02 to 03 131 - Update references. 133 - Update boilerplate. 135 - Fix typos. 137 - Clarify in 3.2.2 that a recipient of an echo request must reply 138 only once it has applied incoming rate limiting. 140 - Tidy references to bootstrapping for [MCAST-CV] in 1.1. 142 - Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in 143 sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4. 145 - Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs 146 in sections 3.2.1 and 3.2.2. 148 0.4 Changes from 03 to 04 150 - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 151 3.3.4 with respect to multiple sub-TLVs in the P2MP Egress 152 Identifier TLV. 154 0.5 Changes from 04 to 05 156 - Change coordinates for Tom Nadeau. Section 13. 158 - Fix typos. 160 - Update references. 162 - Resolve all acronym expansions. 164 1. Introduction 166 Simple and efficient mechanisms that can be used to detect data plane 167 failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) 168 Label Switched Paths (LSP) are described in [RFC4379]. The techniques 169 involve information carried in an MPLS "echo request" and "echo 170 reply", and mechanisms for transporting the echo reply. The echo 171 request and reply messages provide sufficient information to check 172 correct operation of the data plane, as well as a mechanism to verify 173 the data plane against the control plane, and thereby localize 174 faults. The use of reliable channels for echo reply messages as 175 described in [RFC4379] enables more robust fault isolation. This 176 collection of mechanisms is commonly referred to as "LSP Ping". 178 The requirements for point-to-multipoint (P2MP) MPLS traffic 179 engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a 180 signaling solution for establishing P2MP MPLS TE LSPs. 182 The requirements for point-to-multipoint extensions to the Label 183 Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] 184 specifies extensions to LDP for P2MP MPLS. 186 P2MP MPLS LSPs are at least as vulnerable to data plane faults or to 187 discrepancies between the control and data planes as their P2P 188 counterparts. Mechanisms are, therefore, desirable to detect such 189 data plane faults in P2MP MPLS LSPs as described in [RFC4687]. 191 This document extends the techniques described in [RFC4379] such 192 that they may be applied to P2MP MPLS LSPs and so that they can be 193 used to bootstrap other Operations and Management (OAM) procedures 194 such as [MCAST-CV]. This document stresses the reuse of existing LSP 195 Ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs 196 in order to simplify implementation and network operation. 198 1.1 Design Considerations 200 An important consideration for designing LSP Ping for P2MP MPLS LSPs 201 is that every attempt is made to use or extend existing mechanisms 202 rather than invent new mechanisms. 204 As for P2P LSPs, a critical requirement is that the echo request 205 messages follow the same data path that normal MPLS packets traverse. 206 However, it can be seen this notion needs to be extended for P2MP 207 MPLS LSPs, as in this case an MPLS packet is replicated so that it 208 arrives at each egress (or leaf) of the P2MP tree. 210 MPLS echo requests are meant primarily to validate the data plane, 211 and they can then be used to validate data plane state against the 212 control plane. They may also be used to bootstrap other OAM 213 procedures such as [MPLS-BFD] and [MCAST-CV]. As pointed out in 214 [RFC4379], mechanisms to check the liveness, function, and 215 consistency of the control plane are valuable, but such mechanisms 216 are not a feature of LSP Ping and are not covered in this document. 218 As is described in [RFC4379], to avoid potential Denial of Service 219 attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to 220 the control plane. A rate limiter should be applied to the well-known 221 UDP port defined for use by LSP Ping traffic. 223 2. Notes on Motivation 225 2.1. Basic Motivations for LSP Ping 227 The motivations listed in [RFC4379] are reproduced here for 228 completeness. 230 When an LSP fails to deliver user traffic, the failure cannot always 231 be detected by the MPLS control plane. There is a need to provide a 232 tool that enables users to detect such traffic "black holes" or 233 misrouting within a reasonable period of time. A mechanism to isolate 234 faults is also required. 236 [RFC4379] describes a mechanism that accomplishes these goals. This 237 mechanism is modeled after the ping/traceroute paradigm: ping (ICMP 238 echo request [RFC792]) is used for connectivity checks, and 239 traceroute is used for hop-by-hop fault localization as well as path 240 tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode 241 for testing MPLS LSPs. 243 The basic idea as expressed in [RFC4379] is to test that the packets 244 that belong to a particular Forwarding Equivalence Class (FEC) 245 actually end their MPLS path on an LSR that is an egress for that 246 FEC. [RFC4379] achieves this test by sending a packet (called an 247 "MPLS echo request") along the same data path as other packets 248 belonging to this FEC. An MPLS echo request also carries information 249 about the FEC whose MPLS path is being verified. This echo request is 250 forwarded just like any other packet belonging to that FEC. In "ping" 251 mode (basic connectivity check), the packet should reach the end of 252 the path, at which point it is sent to the control plane of the 253 egress LSR, which then verifies that it is indeed an egress for the 254 FEC. In "traceroute" mode (fault isolation), the packet is sent to 255 the control plane of each transit LSR, which performs various checks 256 that it is indeed a transit LSR for this path; this LSR also returns 257 further information that helps to check the control plane against the 258 data plane, i.e., that forwarding matches what the routing protocols 259 determined as the path. 261 One way these tools can be used is to periodically ping a FEC to 262 ensure connectivity. If the ping fails, one can then initiate a 263 traceroute to determine where the fault lies. One can also 264 periodically traceroute FECs to verify that forwarding matches the 265 control plane; however, this places a greater burden on transit LSRs 266 and should be used with caution. 268 2.2. Motivations for LSP Ping for P2MP LSPs 270 As stated in [RFC4687], MPLS has been extended to encompass P2MP 271 LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and 272 diagnose control and data plane defects is critical. For operators 273 deploying services based on P2MP MPLS LSPs, the detection and 274 specification of how to handle those defects is important because 275 such defects may affect the fundamentals of an MPLS network, but also 276 because they may impact service level specification commitments for 277 customers of their network. 279 P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish 280 multicast LSPs. These LSPs distribute data from a single source to 281 one or more destinations across the network according to the next 282 hops indicated by the routing protocols. Each LSP is identified by an 283 MPLS multicast FEC. 285 P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a 286 single ingress and multiple egresses. The tunnels, built on P2MP 287 LSPs, are explicitly routed through the network. There is no concept 288 or applicability of a FEC in the context of a P2MP MPLS TE LSP. 290 MPLS packets inserted at the ingress of a P2MP LSP are delivered 291 equally (barring faults) to all egresses. In consequence, the basic 292 idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an 293 intention to test that packets that enter (at the ingress) a 294 particular P2MP LSP actually end their MPLS path on the LSRs that are 295 the (intended) egresses for that LSP. The idea may be extended to 296 check selectively that such packets reach specific egresses. 298 The technique in this document makes this test by sending an LSP Ping 299 echo request message along the same data path as the MPLS packets. An 300 echo request also carries the identification of the P2MP MPLS LSP 301 (multicast LSP or P2MP TE LSP) that it is testing. The echo request 302 is forwarded just as any other packet using that LSP, and so is 303 replicated at branch points of the LSP and should be delivered to all 304 egresses. In "ping" mode (basic connectivity check), the echo request 305 should reach the end of the path, at which point it is sent to the 306 control plane of the egress LSRs, which verify that they are indeed 307 an egress (leaf) of the P2MP LSP. An echo response message is sent by 308 an egress to the ingress to confirm the successful receipt (or 309 announce the erroneous arrival) of the echo request. 311 In "traceroute" mode (fault isolation), the echo request is sent to 312 the control plane at each transit LSR, and the control plane checks 313 that it is indeed a transit LSR for this P2MP MPLS LSP. The transit 314 LSR also returns information on an echo response that helps verify 315 the control plane against the data plane. That is, the information 316 is used by the ingress to check that the data plane forwarding 317 matches what is signaled by the control plane. 319 P2MP MPLS LSPs may have many egresses, and it is not necessarily the 320 intention of the initiator of the ping or traceroute operation to 321 collect information about the connectivity or path to all egresses. 322 Indeed, in the event of pinging all egresses of a large P2MP MPLS 323 LSP, it might be expected that a large number of echo responses would 324 arrive at the ingress independently but at approximately the same 325 time. Under some circumstances this might cause congestion at or 326 around the ingress LSR. Therefore, the procedures described in this 327 document provide a mechanism that allows the responders to randomly 328 delay (or jitter) their responses so that the chances of swamping the 329 ingress are reduced. 331 Further, the procedures in this document allow the initiator to limit 332 the scope of an LSP Ping echo request (ping or traceroute mode) to 333 one specific intended egress. 335 The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be 336 addressed by other mechanisms such as [MCAST-CV] that utilise the LSP 337 Ping procedures in this document to provide bootstrapping mechanisms 338 as described in Section 2.3. 340 LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure 341 connectivity to any or all of the egresses. If the ping fails, 342 the operator or an automated process can then initiate a traceroute 343 to determine where the fault is located within the network. A 344 traceroute may also be used periodically to verify that data plane 345 forwarding matches the control plane state; however, this places an 346 increased burden on transit LSRs and should be used infrequently and 347 with caution. 349 2.3 Bootstrapping Other OAM Procedures Using LSP Ping 351 [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to 352 bootstrap the Bidirectional Forwarding Detection (BFD) mechanism 353 [BFD] for use to track the liveliness of an MPLS LSP. In particular 354 BFD can be used to detect a data plane failure in the forwarding 355 path of an MPLS LSP. 357 Requirements for MPLS P2MP LSPs extend to hundreds or even thousands 358 of endpoints. If a protocol required explicit acknowledgments to 359 each probe for connectivity verification, the response load at the 360 root would be overwhelming. 362 A more scalable approach to monitoring P2MP LSP connectivity is 363 desribed in [MCAST-CV]. It relies on using the MPLS echo request and 364 echo response messages of LSP Ping [RFC4379] to bootstrap the 365 monitoring mechanism in a manner similar to [MPLS-BFD]. The actual 366 monitoring is done using a separate process defined in [MCAST-CV]. 368 Note that while the approach described in [MCAST-CV] was developed in 369 response to the multicast scalability problem, it can be applied to 370 P2P LSPs as well. 372 3. Operation of LSP Ping for a P2MP LSP 374 This section describes how LSP Ping is applied to P2MP MPLS LSPs. 375 It covers the mechanisms and protocol fields applicable to both ping 376 mode and traceroute mode. It explains the responsibilities of the 377 initiator (ingress), transit LSRs, and receivers (egresses). 379 3.1. Identifying the LSP Under Test 381 3.1.1. Identifying a P2MP MPLS TE LSP 383 [RFC4379] defines how an MPLS TE LSP under test may be identified in 384 an echo request. A Target FEC Stack TLV is used to carry either an 385 RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. 387 In order to identify the P2MP MPLS TE LSP under test, the echo 388 request message MUST carry a Target FEC Stack TLV, and this MUST 389 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 390 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs 391 carry fields from the RSVP-TE P2MP Session and Sender-Template 392 objects [RFC4875] and so provide sufficient information to uniquely 393 identify the LSP. 395 The new sub-TLVs are assigned sub-type identifiers as follows, and 396 are described in the following sections. 398 Sub-Type # Length Value Field 399 ---------- ------ ----------- 400 TBD 20 RSVP P2MP IPv4 Session 401 TBD 56 RSVP P2MP IPv6 Session 403 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 405 The format of the RSVP P2MP IPv4 Session sub-TLV value field is 406 specified in the following figure. The value fields are taken from 407 the definitions of the P2MP IPv4 LSP Session Object and the P2MP 408 IPv4 Sender-Template Object in [RFC4875]. Note that the Sub-Group 409 ID of the Sender-Template is not required. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | P2MP ID | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Must Be Zero | Tunnel ID | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Extended Tunnel ID | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | IPv4 tunnel sender address | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Must Be Zero | LSP ID | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV 427 The format of the RSVP P2MP IPv6 Session sub-TLV value field is 428 specified in the following figure. The value fields are taken from 429 the definitions of the P2MP IPv6 LSP Session Object, and the 430 P2MP IPv6 Sender-Template Object in [RFC4875]. Note that the 431 Sub-Group ID of the Sender-Template is not required. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 | P2MP ID | 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Must Be Zero | Tunnel ID | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | | 443 | Extended Tunnel ID | 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | 447 | IPv6 tunnel sender address | 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Must Be Zero | LSP ID | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 3.1.2. Identifying a Multicast LDP LSP 455 [RFC4379] defines how a P2P LDP LSP under test may be identified in 456 an echo request. A Target FEC Stack TLV is used to carry one or more 457 sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the 458 LSP. 460 In order to identify a multicast LDP LSP under test, the echo request 461 message MUST carry a Target FEC Stack TLV, and this MUST carry 462 exactly one new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This 463 sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so 464 provides sufficient information to uniquely identify the LSP. 466 The new sub-TLV is assigned a sub-type identifier as follows, and 467 is described in the following section. 469 Sub-Type # Length Value Field 470 ---------- ------ ----------- 471 TBD Variable Multicast LDP FEC Stack 473 3.1.2.1. Multicast LDP FEC Stack Sub-TLV 475 The format of the Multicast LDP FEC Stack sub-TLV is shown below. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Address Family | Address Length| Root LSR Addr | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 ~ Root LSR Address (Cont.) ~ 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Opaque Length | Opaque Value ... | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 488 ~ ~ 489 | | 490 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Address Family 496 A two octet quantity containing a value from ADDRESS FAMILY 497 NUMBERS in [IANA-PORT] that encodes the address family for the 498 Root LSR Address. 500 Address Length 502 The length of the Root LSR Address in octets. 504 Root LSR Address 506 An address of the LSR at the root of the P2MP LSP encoded 507 according to the Address Family field. 509 Opaque Length 511 The length of the Opaque Value, in octets. 513 Opaque Value 515 An opaque value elements of which uniquely identifies the P2MP LSP 516 in the context of the Root LSR. 518 If the Address Family is IPv4, the Address Length MUST be 4. If the 519 Address Family is IPv6, the Address Length MUST be 16. No other 520 Address Family values are defined at present. 522 3.2. Ping Mode Operation 524 3.2.1. Controlling Responses to LSP Pings 526 As described in Section 2.2, it may be desirable to restrict the 527 operation of LSP Ping to a single egress. Since echo requests are 528 forwarded through the data plane without interception by the control 529 plane (compare with traceroute mode), there is no facility to limit 530 the propagation of echo requests, and they will automatically be 531 forwarded to all (reachable) egresses. 533 However, the intended egress under test can be identified by the 534 inclusion of a P2MP Egress Identifier TLV containing an IPv4 P2MP 535 Egress Identifier sub-TLV or an IPv6 P2MP Egress Identifier sub-TLV. 536 The P2MP Egress Identifier TLV SHOULD contain precisely one sub-TLV. 537 If the TLV contains no sub-TLVs it SHOULD be processed as if the 538 whole TLV were absent (causing all egresses to respond as described 539 below). If the TLV contains more than one sub-TLV, the first MUST be 540 precessed as described in this document, and subsequent sub-TLVs 541 SHOULD be ignored. 543 An initiator may indicate that it wishes all egresses to respond to 544 an echo request by omitting the P2MP Egress Identifier TLV. 546 Note that the ingress of a multicast LDP LSP will not know the 547 identities of the egresses of the LSP except by some external means 548 such as running P2MP LSP Ping to all egresses. 550 3.2.2. Ping Mode Egress Procedures 552 An egress LSR is RECOMMENDED to rate limit its receipt of echo 553 request messages as described in [RFC4379]. After rate limiting, an 554 egress LSR that receives an echo request carrying an RSVP P2MP IPv4 555 Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast 556 LDP FEC Stack sub-TLV MUST determine whether it is an intended egress 557 of the P2MP LSP in question by checking with the control plane. If it 558 is not supposed to be an egress, it MUST respond according to the 559 setting of the Response Type field in the echo message following the 560 rules defined in [RFC4379]. 562 If the egress LSR that receives an echo request and allows it through 563 its rate limiting is an intended egress of the P2MP LSP, the LSR MUST 564 check to see whether it is an intended Ping recipient. If a P2MP 565 Egress Identifier TLV is present and contains an address that 566 indicates any address that is local to the LSR, the LSR MUST respond 567 according to the setting of the Response Type field in the echo 568 message following the rules defined in [RFC4379]. If the P2MP Egress 569 Identifier TLV is present, but does not identify the egress LSR, it 570 MUST NOT respond to the echo request. If the P2MP Egress Identifier 571 TLV is not present (or, in the error case, is present but does not 572 contain any sub-TLVs), but the egress LSR that received the echo 573 request is an intended egress of the LSP, the LSR MUST respond 574 according to the setting of the Response Type field in the echo 575 message following the rules defined in [RFC4379]. 577 3.2.3. Jittered Responses 579 The initiator (ingress) of a ping request MAY request the responding 580 egress to introduce a random delay (or jitter) before sending the 581 response. The randomness of the delay allows the responses from 582 multiple egresses to be spread over a time period. Thus this 583 technique is particularly relevant when the entire LSP tree is being 584 pinged since it helps prevent the ingress (or nearby routers) from 585 being swamped by responses, or from discarding responses due to rate 586 limits that have been applied. 588 It is desirable for the ingress to be able to control the bounds 589 within which the egress delays the response. If the tree size is 590 small, only a small amount of jitter is required, but if the tree is 591 large, greater jitter is needed. The ingress informs the egresses of 592 the jitter bound by supplying a value in a new TLV (the Echo Jitter 593 TLV) carried on the echo request message. If this TLV is present, 594 the responding egress MUST delay sending a response for a random 595 amount of time between zero seconds and the value indicated in the 596 TLV. If the TLV is absent, the responding egress SHOULD NOT introduce 597 any additional delay in responding to the echo request. 599 LSP ping SHOULD NOT be used to attempt to measure the round-trip 600 time for data delivery. This is because the LSPs are unidirectional, 601 and the echo response is often sent back through the control plane. 602 The timestamp fields in the echo request/response MAY be used to 603 deduce some information about delivery times and particularly the 604 variance in delivery times. 606 The use of echo jittering does not change the processes for gaining 607 information, but note that the responding egress MUST set the value 608 in the Timestamp Received fields before applying any delay. 610 It is RECOMMENDED that echo response jittering is not used except in 611 the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo 612 request for any other type of TLV, the responding egress MAY apply 613 the jitter behavior described here. 615 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs 617 A new TLV is defined for inclusion in the Echo request message. 619 The P2MP Egress Identifier TLV is assigned the TLV type value TBD and 620 is encoded as follows. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |Type = TBD (P2MP Egress ID TLV)| Length = Variable | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 ~ Sub-TLVs ~ 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Sub-TLVs: 632 Zero, one or more sub-TLVs as defined below. 634 If no sub-TLVs are present, the TLV MUST be processed as if it 635 were absent. If more than one sub-TLV is present the first MUST 636 be processed as described in this document, and subsequent 637 sub-TLVs SHOULD be ignored. 639 The P2MP Egress Identifier TLV only has meaning on an echo request 640 message. If present on an echo response message, it SHOULD be 641 ignored. 643 Two sub-TLVs are defined for inclusion in the P2MP Egress Identifier 644 TLV carried on the echo request message. These are: 646 Sub-Type # Length Value Field 647 ---------- ------ ----------- 648 1 4 IPv4 P2MP Egress Identifier 649 2 16 IPv6 P2MP Egress Identifier 651 The value of an IPv4 P2MP Egress Identifier consists of four octets 652 of an IPv4 address. The IPv4 address is in network byte order. 654 The value of an IPv6 P2MP Egress Identifier consists of sixteen 655 octets of an IPv6 address. The IPv6 address is in network byte order. 657 3.2.5. Echo Jitter TLV 659 A new TLV is defined for inclusion in the Echo request message. 661 The Echo Jitter TLV is assigned the TLV type value TBD and is encoded 662 as follows. 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Type = TBD (Jitter TLV) | Length = 4 | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Jitter time | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Jitter time: 674 This field specifies the upper bound of the jitter period that 675 should be applied by a responding egress to determine how long 676 to wait before sending an echo response. An egress SHOULD wait 677 a random amount of time between zero seconds and the value 678 specified in this field. 680 Jitter time is specified in milliseconds. 682 The Echo Jitter TLV only has meaning on an echo request message. If 683 present on an echo response message, it SHOULD be ignored. 685 3.3. Traceroute Mode Operation 687 The traceroute mode of operation is described in [RFC4379]. Like 688 other traceroute operations, it relies on the expiration of the TTL 689 of the packet that carries the echo request. Echo requests may 690 include a Downstream Mapping TLV, and when the TTL expires the echo 691 request is passed to the control plane on the transit LSR which 692 responds according to the Response Type in the message. A responding 693 LSR fills in the fields of the Downstream Mapping TLV to indicate the 694 downstream interfaces and labels used by the reported LSP from the 695 responding LSR. In this way, by successively sending out echo 696 requests with increasing TTLs, the ingress may gain a picture of the 697 path and resources used by an LSP up to the point of failure when no 698 response is received, or an error response is generated by an LSR 699 where the control plane does not expect to be handling the LSP. 701 This mode of operation is equally applicable to P2MP MPLS TE LSPs 702 as described in the following sections. 704 The traceroute mode can be applied to all destinations of the P2MP 705 tree just as in the ping mode. In the case of P2MP MPLS TE LSPs, the 706 traceroute mode can also be applied to individual destinations 707 identified by the presence of a P2MP Egress Identifier TLV. However, 708 since a transit LSR of a multicast LDP LSP is unable to determine 709 whether it lies on the path to any one destination, the traceroute 710 mode limited to specific egresses of such an LSP MUST NOT be used. 712 In the absence of a P2MP Egress Identifier TLV, the echo request is 713 asking for traceroute information applicable to all egresses. 715 The echo response jitter technique described for the ping mode is 716 equally applicable to the traceroute mode and is not additionally 717 described in the procedures below. 719 3.3.1. Traceroute Responses at Non-Branch Nodes 721 When the TTL for the MPLS packet carrying an echo request expires the 722 packet MUST be passed to the control plane as specified in [RFC4379]. 724 If the LSP under test is a multicast LDP LSP and if the echo request 725 carries a P2MP Egress Identifier TLV the LSR MUST treat the echo 726 request as malformed and MUST process it according to the rules 727 specified in [RFC4379]. 729 Otherwise, the LSR MUST NOT return an echo response unless the 730 responding LSR lies on the path of the P2MP LSP to the egress 731 identified by the P2MP Egress Identifier TLV carried on the request, 732 or if no such sub-TLV is present. 734 If sent, the echo response MUST identifiy the next hop of the path of 735 the LSP in the data plane by including a Downstream Mapping TLV as 736 described in [RFC4379]. 738 3.3.1.1. Correlating Traceroute Responses 740 When traceroute is being simultaneously applied to multiple egresses, 741 it is important that the ingress should be able to correlate the echo 742 responses with the branches in the P2MP tree. Without this 743 information the ingress will be unable to determine the correct 744 ordering of transit nodes. One possibility is for the ingress to poll 745 the path to each egress in turn, but this may be inefficient, 746 undesirable, or (in the case of multicast LDP LSPs) illegal. 748 The Downstream Mapping TLV that MUST be included in the echo response 749 indicates the next hop from each responding LSR, and this information 750 supplied by a non-branch LSR can be pieced together by the ingress to 751 reconstruct the P2MP tree although it may be necessary to refer to 752 the routing information distributed by the IGP to correlate next hop 753 addresses and LSR reporting addresses in subsequent echo responses. 755 In order to facilitate more easy correlation of echo responses, the 756 Downstream Mapping TLV can also contain Multipath Information as 757 described in [RFC4379] to identify to which egress/egresses the echo 758 response applies, and indicates. This information: 760 - MUST NOT be present for multicast LDP LSPs 762 - SHOULD be present for P2MP MPLS TE LSPs when the echo request 763 applies to all egresses 765 - is RECCOMMENDED to be present for P2MP MPLS TE LSPs when the echo 766 request is limited to a single egress. 768 The format of the information in the Downstream Mapping TLV for 769 P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6. 771 3.3.2. Traceroute Responses at Branch Nodes 773 A branch node may need to identify more than one downstream interface 774 in a traceroute echo response if some of the egresses that are being 775 traced lie on different branches. This will always be the case for 776 any branch node if all egresses are being traced. 778 [RFC4379] describes how multiple Downstream Mapping TLVs should be 779 included in an echo response, each identifying exactly one downstream 780 interface that is applicable to the LSP. 782 A branch node MUST follow the procedures described in Section 3.3.1 783 to determine whether it should respond to an echo request. The branch 784 node MUST add a Downstream Mapping TLV to the echo response for each 785 outgoing branch that it reports, but it MUST NOT report branches that 786 do not lie on the path to one of the destinations being traced. Thus 787 a branch node may sometimes only need to respond with a single 788 Downstream Mapping TLV, for example, consider the case where the 789 traceroute is directed to only a single egress node. Therefore, 790 the presence of only one Downstream Mapping TLV in an echo response 791 does not guarantee that the reporting LSR is not a branch node. 793 To report on the fact that an LSR is a branch node for the P2MP MPLS 794 LSP a new B-flag is added to the Downstream Mapping TLV. The flag is 795 set to zero to indicate that the reporting LSR is not a branch for 796 this LSP, and is set to one to indicate that it is a branch. The flag 797 is placed in the fourth byte of the TLV that was previously reserved. 799 The format of the information in the Downstream Mapping TLV for 800 P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6. 802 3.3.2.1. Correlating Traceroute Responses 804 Just as with non-branches, it is important that the echo responses 805 from branch nodes provide correlation information that will allow the 806 ingress to work out to which branch of the LSP the response applies. 808 The P2MP tree can be determined by the ingress using the identity of 809 the reporting node and the next hop information from the previous 810 echo response, just as with echo responses from non-branch nodes. 812 As with non-branch nodes, in order to facilitate more easy 813 correlation of echo responses, the Downstream Mapping TLV can also 814 contain Multipath Information as described in [RFC4379] to identify 815 to which egress/egresses the echo response applies, and indicates. 816 This information: 818 - MUST NOT be present for multicast LDP LSPs 820 - SHOULD be present for P2MP MPLS TE LSPs when the echo request 821 applies to all egresses 823 - is RECCOMMENDED to be present for P2MP MPLS TE LSPs when the echo 824 request is limited to a single egress. 826 The format of the information in the Downstream Mapping TLV for 827 P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6. 829 3.3.3. Traceroute Responses at Bud Nodes 831 Some nodes on a P2MP MPLS LSP may be egresses, but also have 832 downstream LSRs. Such LSRs are known as bud nodes [RFC4461]. 834 A bud node MUST respond to a traceroute echo request just as a branch 835 node would, but it MUST also indicates to the ingress that it is an 836 egress in its own right. This is achieved through the use of a new 837 E-flag in the Downstream Mapping TLV that indicates that the 838 reporting LSR is not a bud for this LSP (cleared to zero) or is a bud 839 (set to one). A normal egress MUST NOT set this flag. 841 The flag is placed in the fourth byte of the TLV that was previously 842 reserved. 844 3.3.4. Non-Response to Traceroute Echo Requests 846 The nature of P2MP MPLS TE LSPs in the data plane means that 847 traceroute echo requests may be delivered to the control plane of 848 LSRs that must not reply to the request because, although they lie 849 on the P2MP tree, they do not lie on the path to the egress that is 850 being traced. 852 Thus, an LSR on a P2MP MPLS LSP MUST NOT respond to an echo request 853 when the TTL has expired if any of the following applies: 855 - The Reply Type indicates that no reply is required 857 - There is a P2MP Egress Identifier TLV present on the echo request 858 (which means that the LSP is a P2MP MPLS TE LSP), but the address 859 does not identify an egress that is reached through this LSR for 860 this particular P2MP MPLS LSP. 862 3.3.5. Modifications to the Downstream Mapping TLV 864 A new B-flag is added to the Downstream Mapping TLV to indicate that 865 the reporting LSR is not a branch for this LSP (cleared to zero) or 866 is a branch (set to one). 868 A new E-flag is added to the Downstream Mapping TLV to indicate that 869 the reporting LSR is not a bud node for this LSP (cleared to zero) or 870 is a bud node (set to one). 872 The flags are placed in the fourth byte of the TLV that was 873 previously reserved as shown below. All other fields are unchanged 874 from their definitions in [RFC4379] except for the additional 875 information that can be carried in the Multipath Information (see 876 Section 3.3.6). 878 0 1 2 3 879 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 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | MTU | Address Type | Reserved |E|B| 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Downstream IP Address (4 or 16 octets) | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Downstream Interface Address (4 or 16 octets) | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Hash Key Type | Depth Limit | Multipath Length | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 . . 890 . (Multipath Information) . 891 . . 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Downstream Label | Protocol | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 . . 896 . . 897 . . 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Downstream Label | Protocol | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 3.3.6. Additions to Downstream Mapping Multipath Information 904 A new value for the Multipath Type is defined to indicate that the 905 reported Multipath Information applies to a P2MP MPLS TE LSP and 906 may contain a list of egress identifiers that indicate the egress 907 nodes that can be reached through the reported interface. This 908 Multipath Type MUST NOT be used for a multicast LDP LSP. 910 Type # Address Type Multipath Information 911 --- ---------------- --------------------- 912 TBD P2MP egresses List of P2MP egresses 914 Note that a list of egresses may include IPv4 and IPv6 identifiers 915 since these may be mixed in the P2MP MPLS TE LSP. 917 The Multipath Length field continues to identify the length of the 918 Multipath Information just as in [RFC4379] (that is, not including 919 the downstream labels), and the downstream label (or potential 920 stack thereof) is also handled just as in [RFC4379]. The format 921 of the Multipath Information for a Multipath Type of P2MP Egresses 922 is as follows. 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Address Type | Egress Address (4 or 16 octets) | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | (continued) | : 930 +-+-+-+-+-+-+-+-+ : 931 : Further Address Types and Egress Addresses : 932 : : 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 Address Type 937 This field indicates whether the egress address that follows is 938 an IPv4 or IPv6 address, and so implicitly encodes the length of 939 the address. 941 Two values are defined and mirror the values used in the Address 942 Type field of the Downstream Mapping TLV itself. 944 Type # Address Type 945 ------ ------------ 946 1 IPv4 947 3 IPv6 949 Egress Address 951 An egress of this P2MP MPLS TE LSP that is reached through the 952 interface indicated by the Downstream Mapping TLV and for which 953 the traceroute echo request was enquiring. 955 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms 957 Bootstrapping of other OAM procedures can be achieved using the 958 MPLS Echo Request/Response messages. The LSP(s) under test are 959 identified using the RSVP P2MP IPv4 or IPv6 Session sub-TLVs 960 (see Section 3.1.1) or the Multicast LDP FEC Stack sub-TLV 961 (see Section 3.1.2). 963 Other sub-TLVs may be defined in other specifications to indicate 964 the OAM procedures being bootstrapped, and to describe the bootstrap 965 parameters. Further details of the bootstrapping processes and the 966 bootstrapped OAM processes are described in other documents. For 967 example, see [MPLS-BFD] and [MCAST-CV]. 969 5. Non-compliant Routers 971 If an egress for a P2MP LSP does not support MPLS LSP ping, then no 972 reply will be sent, resulting in a "false negative" result. There is 973 no protection for this situation, and operators may wish to ensure 974 that end points for P2MP LSPs are all equally capable of supporting 975 this function. Alternatively, the traceroute option can be used to 976 verify the LSP nearly all the way to the egress, leaving the final 977 hop to be verified manually. 979 If, in "traceroute" mode, a transit LSR does not support LSP ping, 980 then no reply will be forthcoming from that LSR for some TTL, say n. 981 The LSR originating the echo request SHOULD continue to send echo 982 requests with TTL=n+1, n+2, ..., n+k in the hope that some transit 983 LSR further downstream may support MPLS echo requests and reply. In 984 such a case, the echo request for TTL > n MUST NOT have Downstream 985 Mapping TLVs, until a reply is received with a Downstream Mapping. 987 Note that the settings of the new bit flags in the Downstream Mapping 988 TLV are such that a legacy LSR would return them with value zero 989 which most closely matches the likely default behavior of a legacy 990 LSR. 992 6. OAM Considerations 994 The procedures in this document provide OAM functions for P2MP MPLS 995 LSPs and may be used to enable bootstrapping of other OAM procedures. 997 In order to be fully operational several considerations must be made. 999 - Scaling concerns dictate that only cautious use of LSP Ping should 1000 be made. In particular, sending an LSP Ping to all egresses of a 1001 P2MP MPLS LSP could result in congestion at or near the ingress 1002 when the responses arrive. 1004 Further, incautious use of timers to generate LSP Ping echo 1005 requests either in ping mode or especially in traceroute may lead 1006 to significant degradation of network performance. 1008 - Management interfaces should allow an operator full control over 1009 the operation of LSP Ping. In particular, it SHOULD provide the 1010 ability to limit the scope of an LSP Ping echo request for a P2MP 1011 MPLS LSP to a single egress. 1013 Such an interface SHOULD also provide the ability to disable all 1014 active LSP Ping operations to provide a quick escape if the network 1015 becomes congested. 1017 - A MIB module is required for the control and management of LSP Ping 1018 operations, and to enable the reported information to be inspected. 1020 There is no reason to believe this should not be a simple extension 1021 of the LSP Ping MIB module used for P2P LSPs. 1023 7. IANA Considerations 1025 7.1. New Sub-TLV Types 1027 Three new sub-TLV types are defined for inclusion within the LSP Ping 1028 [RFC4379] Target FEC Stack TLV (TLV type 1). 1030 IANA is requested to assign sub-type values to the following 1031 sub-TLVs from the Multiprotocol Label Switching Architecture (MPLS) 1032 Label Switched Paths (LSPs) Parameters - TLVs registry. 1034 RSVP P2MP IPv4 Session (see Section 3.1.1) 1035 RSVP P2MP IPv6 Session (see Section 3.1.1) 1036 Multicast LDP FEC Stack (see Section 3.1.2) 1038 7.2. New Multipath Type 1040 Section 3.3 of [RFC4379] defines a set of values for the LSP Ping 1041 Multipath Type. These values are currently not tracked by IANA. 1043 A new value for the LSP Ping Multipath Type is defined in Section 1044 3.3.6 of this document to indicate that the reported Multipath 1045 Information applies to a P2MP MPLS TE LSP. 1047 IANA is requested to create a new registry as follows: 1049 Multiprotocol Label Switching Architecture (MPLS) Label Switched 1050 Paths (LSPs) - Multipath Types 1051 Key Type Multipath Information 1052 --- ---------------- --------------------- 1053 0 no multipath Empty (Multipath Length = 0) [RFC4379] 1054 2 IP address IP addresses [RFC4379] 1055 4 IP address range low/high address pairs [RFC4379] 1056 8 Bit-masked IP IP address prefix and bit mask [RFC4379] 1057 address set 1058 9 Bit-masked label set Label prefix and bit mask [RFC4379] 1059 xx P2MP egress IP List of P2MP egresses [thisDoc] 1060 addresses 1062 A suggested value of xx is TBD by the MPLS Working Group. 1064 New values from this registry are to be assigned only by Standards 1065 Action. 1067 7.3. New TLVs 1069 Two new LSP Ping TLV types are defined for inclusion in LSP Ping 1070 messages. 1072 IANA is reuqested to assign a new value from the Multiprotocol Label 1073 Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters 1074 - TLVs registry as follows using a Standards Action value. 1076 P2MP Egress Identifier TLV (see Section 3.2.4) 1077 Two sub-TLVs are defined 1078 - Type 1: IPv4 P2MP Egress Identifier (see Section 3.2.4) 1079 - Type 2: IPv6 P2MP Egress Identifier (see Section 3.2.4) 1081 Echo Jitter TLV (see Section 3.2.5) 1083 8. Security Considerations 1085 This document does not introduce security concerns over and above 1086 those described in [RFC4379]. Note that because of the scalability 1087 implications of many egresses to P2MP MPLS LSPs, there is a 1088 stronger concern to regulate the LSP Ping traffic passed to the 1089 control plane by the use of a rate limiter applied to the LSP Ping 1090 well-known UDP port. Note that this rate limiting might lead to 1091 false positives. 1093 9. Acknowledgements 1095 The authors would like to acknowledge the authors of [RFC4379] for 1096 their work which is substantially re-used in this document. Also 1097 thanks to the members of the MBONED working group for their review 1098 of this material, to Daniel King for his review, and to Yakov Rekhter 1099 for useful discussions. 1101 The authors would like to thank Vanson Lim, Danny Prairie, Reshad 1102 Rahman, and Ben Niven-Jenkins for their comments and suggestions. 1104 10. Intellectual Property Considerations 1106 The IETF takes no position regarding the validity or scope of any 1107 Intellectual Property Rights or other rights that might be claimed to 1108 pertain to the implementation or use of the technology described in 1109 this document or the extent to which any license under such rights 1110 might or might not be available; nor does it represent that it has 1111 made any independent effort to identify any such rights. Information 1112 on the procedures with respect to rights in RFC documents can be 1113 found in BCP 78 and BCP 79. 1115 Copies of IPR disclosures made to the IETF Secretariat and any 1116 assurances of licenses to be made available, or the result of an 1117 attempt made to obtain a general license or permission for the use of 1118 such proprietary rights by implementers or users of this 1119 specification can be obtained from the IETF on-line IPR repository at 1120 http://www.ietf.org/ipr. 1122 The IETF invites any interested party to bring to its attention any 1123 copyrights, patents or patent applications, or other proprietary 1124 rights that may cover technology that may be required to implement 1125 this standard. Please address the information to the IETF at ietf- 1126 ipr@ietf.org. 1128 11. Normative References 1130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1131 Requirement Levels", BCP 14, RFC 2119, March 1997. 1133 [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol 1134 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1135 February 2006. 1137 12. Informative References 1139 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 1141 [RFC4461] Yasukawa, S., "Signaling Requirements for Point to 1142 Multipoint Traffic Engineered Multiprotocol Label 1143 Switching (MPLS) Label Switched Paths (LSPs)", 1144 RFC 4461, April 2006. 1146 [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1147 "Operations and Management (OAM) Requirements for 1148 Point-to-Multipoint MPLS Networks", RFC 4687, September 1149 2006. 1151 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 1152 "Extensions to Resource Reservation Protocol - Traffic 1153 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1154 Switched Paths (LSPs)", RFC 4875, May 2007. 1156 [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for 1157 point-to-multipoint extensions to the Label Distribution 1158 Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. 1160 [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol 1161 Extensions for Point-to-Multipoint and 1162 Multipoint-to-Multipoint Label Switched Paths", 1163 draft-ietf-mpls-ldp-p2mp, work in progress. 1165 [MCAST-CV] Swallow, G., and Nadeau, T., "Connectivity Verification 1166 for Multicast Label Switched Paths", 1167 draft-swallow-mpls-mcast-cv, work in progress. 1169 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 1170 Detection", draft-ietf-bfd-base, work in progress. 1172 [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., 1173 "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in 1174 progress. 1176 [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 1178 13. Authors' Addresses 1180 Seisho Yasukawa 1181 NTT Corporation 1182 (R&D Strategy Department) 1183 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 1184 Phone: +81 3 5205 5341 1185 Email: s.yasukawa@hco.ntt.co.jp 1187 Adrian Farrel 1188 Old Dog Consulting 1189 EMail: adrian@olddog.co.uk 1191 Zafar Ali 1192 Cisco Systems Inc. 1193 2000 Innovation Drive 1194 Kanata, ON, K2K 3E8, Canada. 1195 Phone: 613-889-6158 1196 Email: zali@cisco.com 1197 Bill Fenner 1198 AT&T Labs -- Research 1199 75 Willow Rd. 1200 Menlo Park, CA 94025 1201 United States 1202 Email: fenner@research.att.com 1204 George Swallow 1205 Cisco Systems, Inc. 1206 1414 Massachusetts Ave 1207 Boxborough, MA 01719 1208 Email: swallow@cisco.com 1210 Thomas D. Nadeau 1211 British Telecom 1212 BT Centre 1213 81 Newgate Street 1214 EC1A 7AJ 1215 London 1216 Email: tom.nadeau@bt.com 1218 14. Full Copyright Statement 1220 Copyright (C) The IETF Trust (2008). 1222 This document is subject to the rights, licenses and restrictions 1223 contained in BCP 78, and except as set forth therein, the authors 1224 retain all their rights. 1226 This document and the information contained herein are provided on an 1227 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1228 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1229 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1230 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1231 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1232 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.