idnits 2.17.1 draft-ietf-mpls-p2mp-lsp-ping-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1423. 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. 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.) -- The document date (September 10, 2008) is 5700 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Farrel (Editor) 2 Internet-Draft Old Dog Consulting 3 Intended Status: Standards Track S. Yasukawa 4 Updates: RFC4379 NTT 5 Created: September 10, 2008 6 Expires: March 10, 2009 8 Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol 9 Label Switching (MPLS) - Extensions to LSP Ping 11 draft-ietf-mpls-p2mp-lsp-ping-07.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Recent proposals have extended the scope of Multiprotocol Label 39 Switching (MPLS) Label Switched Paths (LSPs) to encompass 40 point-to-multipoint (P2MP) LSPs. 42 The requirement for a simple and efficient mechanism that can be 43 used to detect data plane failures in point-to-point (P2P) MPLS LSPs 44 has been recognized and has led to the development of techniques 45 for fault detection and isolation commonly referred to as "LSP Ping". 47 The scope of this document is fault detection and isolation for P2MP 48 MPLS LSPs. This documents does not replace any of the mechanisms of 49 LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and 50 extends the techniques and mechanisms of LSP Ping to the MPLS P2MP 51 environment. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [RFC2119]. 59 Contents 61 1. Introduction ................................................... 4 62 1.1 Design Considerations ......................................... 5 63 2. Notes on Motivation ............................................ 6 64 2.1. Basic Motivations for LSP Ping ............................... 6 65 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 8 66 2.3 Bootstrapping Other OAM Procedures Using LSP Ping ............. 9 67 3. Operation of LSP Ping for a P2MP LSP ........................... 9 68 3.1. Identifying the LSP Under Test ............................... 9 69 3.1.1. Identifying a P2MP MPLS TE LSP ............................. 9 70 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 9 71 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV .......................... 10 72 3.1.2. Identifying a Multicast LDP LSP ........................... 10 73 3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 11 74 3.2. Ping Mode Operation ......................................... 12 75 3.2.1. Controlling Responses to LSP Pings ........................ 12 76 3.2.2. Ping Mode Egress Procedures ............................... 12 77 3.2.3. Jittered Responses ........................................ 13 78 3.2.4. P2MP Responder Identifier TLV and Sub-TLVs ................ 14 79 3.2.5. Echo Jitter TLV ........................................... 15 80 3.2.6. Echo Response Reporting ................................... 15 81 3.3. Traceroute Mode Operation ................................... 16 82 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 17 83 3.3.1.1. Correlating Traceroute Responses ........................ 17 84 3.3.2. Traceroute Responses at Branch Nodes ..................... 18 85 3.3.2.1. Node Properties TLV ..................................... 18 86 3.3.2.2. Branching Properties Sub-TLV ............................ 19 87 3.3.2.3. Egress Address Sub-TLV .................................. 20 88 3.3.2.4. Correlating Traceroute Responses ........................ 21 89 3.3.3. Traceroute Responses at Bud Nodes ......................... 21 90 3.3.4. Non-Response to Traceroute Echo Requests .................. 22 91 3.3.5. Additions to Downstream Mapping Multipath Information ..... 22 92 3.3.6. Echo Response Reporting ................................... 24 93 3.3.6.1. Reporting Multiple Conditions Using The DDM TLV ......... 24 94 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 25 95 5. Non-compliant Routers ......................................... 26 96 6. OAM Considerations ............................................ 26 97 7. IANA Considerations ........................................... 27 98 7.1. New Sub-TLV Types ........................................... 27 99 7.2. New Multipath Type .......................................... 27 100 7.3. New TLVs .................................................... 28 101 7.4. New Return Code ............................................. 28 102 7.5. New Sub-TLV Value for the Downstream Detailed Mapping TLV ... 28 103 8. Security Considerations ....................................... 29 104 9. Acknowledgements .............................................. 29 105 10. Intellectual Property Considerations ......................... 29 106 11. Normative References ......................................... 30 107 12. Informative References ....................................... 30 108 13. Authors' Addresses ........................................... 31 109 14. Full Copyright Statement ..................................... 32 111 0. Change Log 113 This section to be removed before publication as an RFC. 115 0.1 Changes from 00 to 01 117 - Update references. 118 - Fix boilerplate. 120 0.2 Changes from 01 to 02 122 - Update entire document so that it is not specific to MPLS-TE, but 123 also includes multicast LDP LSPs. 124 - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new 125 egress identifier TLV. 126 - Include Multicast LDP FEC Stack sub-TLV definition from [MCAST-CV]. 127 - Add brief section on use of LSP Ping for bootstrapping. 128 - Add new references to References section. 129 - Add details of two new authors. 131 0.3 Changes from 02 to 03 133 - Update references. 134 - Update boilerplate. 135 - Fix typos. 136 - Clarify in 3.2.2 that a recipient of an echo request must reply 137 only once it has applied incoming rate limiting. 138 - Tidy references to bootstrapping for [MCAST-CV] in 1.1. 139 - Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in 140 sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4. 141 - Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs 142 in sections 3.2.1 and 3.2.2. 144 0.4 Changes from 03 to 04 146 - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 147 3.3.4 with respect to multiple sub-TLVs in the P2MP Egress 148 Identifier TLV. 150 0.5 Changes from 04 to 05 152 - Change coordinates for Tom Nadeau. Section 13. 153 - Fix typos. 154 - Update references. 155 - Resolve all acronym expansions. 157 0.6 Changes from 05 to 06 159 - New section, 3.2.6, to explain echo response reporting in the Ping 160 case. 161 - New section, 3.3.7, to explain echo response reporting in the 162 Traceroute case. 163 - Sections 3.3.2, 3.3.5, and 5. Retire the E-flag for identification 164 of bud nodes. Use the B-flag in a Downstream Mapping TLV with a 165 zero address to provide the necessary indication. 166 - Section 3.3.4. Note the use of ALLROUTERS address as per RFC 4379 167 - Section 7. Suggest values for IANA assignment. 168 - Rename "P2MP Responder Identifier TLV" to "P2MP Responder 169 Identifier TLV", "Egress Identifier sub-TLV" to "Responder 170 Identifier sub-TLV", and "P2MP egresses" multipath type to "P2MP 171 responder". This allows any LSR on the P2MP LSP to be the target 172 of, or responder to, an echo request. 174 0.7 Changes from 06 to 07 176 - Sections 3.3.2 and 3.3.3. Delete section 3.3.5. New sections 177 3.3.2.1 through 3.3.2.3: Retire B-flag from Downstream Mapping TLV. 178 Introduce new Node Properties TLV with Branching Properties and 179 Egress Address sub-TLVs. 180 - Section 3.3.2.4: Clarify rules on presence of Multipath Information 181 in Downstream Mapping TLVs. 182 - Section 3.3.5: Clarify padding rules. 183 - Section 3.3.6: Updated to use Downstream Detailed Mapping TLVs for 184 multiple return conditions reported by a single echo response. 185 - Section 7: Update IANA values and add new sub-sections. 186 - Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap. 187 - Section 13: Update Bill Fenner's coordinates. 189 1. Introduction 191 Simple and efficient mechanisms that can be used to detect data plane 192 failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) 193 Label Switched Paths (LSP) are described in [RFC4379]. The techniques 194 involve information carried in an MPLS "echo request" and "echo 195 reply", and mechanisms for transporting the echo reply. The echo 196 request and reply messages provide sufficient information to check 197 correct operation of the data plane, as well as a mechanism to verify 198 the data plane against the control plane, and thereby localize 199 faults. The use of reliable channels for echo reply messages as 200 described in [RFC4379] enables more robust fault isolation. This 201 collection of mechanisms is commonly referred to as "LSP Ping". 203 The requirements for point-to-multipoint (P2MP) MPLS traffic 204 engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a 205 signaling solution for establishing P2MP MPLS TE LSPs. 207 The requirements for point-to-multipoint extensions to the Label 208 Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] 209 specifies extensions to LDP for P2MP MPLS. 211 P2MP MPLS LSPs are at least as vulnerable to data plane faults or to 212 discrepancies between the control and data planes as their P2P 213 counterparts. Mechanisms are, therefore, desirable to detect such 214 data plane faults in P2MP MPLS LSPs as described in [RFC4687]. 216 This document extends the techniques described in [RFC4379] such 217 that they may be applied to P2MP MPLS LSPs and so that they can be 218 used to bootstrap other Operations and Management (OAM) procedures 219 such as [MCAST-CV]. This document stresses the reuse of existing LSP 220 Ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs 221 in order to simplify implementation and network operation. 223 1.1 Design Considerations 225 An important consideration for designing LSP Ping for P2MP MPLS LSPs 226 is that every attempt is made to use or extend existing mechanisms 227 rather than invent new mechanisms. 229 As for P2P LSPs, a critical requirement is that the echo request 230 messages follow the same data path that normal MPLS packets traverse. 231 However, it can be seen this notion needs to be extended for P2MP 232 MPLS LSPs, as in this case an MPLS packet is replicated so that it 233 arrives at each egress (or leaf) of the P2MP tree. 235 MPLS echo requests are meant primarily to validate the data plane, 236 and they can then be used to validate data plane state against the 237 control plane. They may also be used to bootstrap other OAM 238 procedures such as [MPLS-BFD] and [MCAST-CV]. As pointed out in 239 [RFC4379], mechanisms to check the liveness, function, and 240 consistency of the control plane are valuable, but such mechanisms 241 are not a feature of LSP Ping and are not covered in this document. 243 As is described in [RFC4379], to avoid potential Denial of Service 244 attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to 245 the control plane. A rate limiter should be applied to the well-known 246 UDP port defined for use by LSP Ping traffic. 248 2. Notes on Motivation 250 2.1. Basic Motivations for LSP Ping 252 The motivations listed in [RFC4379] are reproduced here for 253 completeness. 255 When an LSP fails to deliver user traffic, the failure cannot always 256 be detected by the MPLS control plane. There is a need to provide a 257 tool that enables users to detect such traffic "black holes" or 258 misrouting within a reasonable period of time. A mechanism to isolate 259 faults is also required. 261 [RFC4379] describes a mechanism that accomplishes these goals. This 262 mechanism is modeled after the ping/traceroute paradigm: ping (ICMP 263 echo request [RFC792]) is used for connectivity checks, and 264 traceroute is used for hop-by-hop fault localization as well as path 265 tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode 266 for testing MPLS LSPs. 268 The basic idea as expressed in [RFC4379] is to test that the packets 269 that belong to a particular Forwarding Equivalence Class (FEC) 270 actually end their MPLS path on an LSR that is an egress for that 271 FEC. [RFC4379] achieves this test by sending a packet (called an 272 "MPLS echo request") along the same data path as other packets 273 belonging to this FEC. An MPLS echo request also carries information 274 about the FEC whose MPLS path is being verified. This echo request is 275 forwarded just like any other packet belonging to that FEC. In "ping" 276 mode (basic connectivity check), the packet should reach the end of 277 the path, at which point it is sent to the control plane of the 278 egress LSR, which then verifies that it is indeed an egress for the 279 FEC. In "traceroute" mode (fault isolation), the packet is sent to 280 the control plane of each transit LSR, which performs various checks 281 that it is indeed a transit LSR for this path; this LSR also returns 282 further information that helps to check the control plane against the 283 data plane, i.e., that forwarding matches what the routing protocols 284 determined as the path. 286 One way these tools can be used is to periodically ping a FEC to 287 ensure connectivity. If the ping fails, one can then initiate a 288 traceroute to determine where the fault lies. One can also 289 periodically traceroute FECs to verify that forwarding matches the 290 control plane; however, this places a greater burden on transit LSRs 291 and should be used with caution. 293 2.2. Motivations for LSP Ping for P2MP LSPs 295 As stated in [RFC4687], MPLS has been extended to encompass P2MP 296 LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and 297 diagnose control and data plane defects is critical. For operators 298 deploying services based on P2MP MPLS LSPs, the detection and 299 specification of how to handle those defects is important because 300 such defects may affect the fundamentals of an MPLS network, but also 301 because they may impact service level specification commitments for 302 customers of their network. 304 P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish 305 multicast LSPs. These LSPs distribute data from a single source to 306 one or more destinations across the network according to the next 307 hops indicated by the routing protocols. Each LSP is identified by an 308 MPLS multicast FEC. 310 P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a 311 single ingress and multiple egresses. The tunnels, built on P2MP 312 LSPs, are explicitly routed through the network. There is no concept 313 or applicability of a FEC in the context of a P2MP MPLS TE LSP. 315 MPLS packets inserted at the ingress of a P2MP LSP are delivered 316 equally (barring faults) to all egresses. In consequence, the basic 317 idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an 318 intention to test that packets that enter (at the ingress) a 319 particular P2MP LSP actually end their MPLS path on the LSRs that are 320 the (intended) egresses for that LSP. The idea may be extended to 321 check selectively that such packets reach specific egresses. 323 The technique in this document makes this test by sending an LSP Ping 324 echo request message along the same data path as the MPLS packets. An 325 echo request also carries the identification of the P2MP MPLS LSP 326 (multicast LSP or P2MP TE LSP) that it is testing. The echo request 327 is forwarded just as any other packet using that LSP, and so is 328 replicated at branch points of the LSP and should be delivered to all 329 egresses. In "ping" mode (basic connectivity check), the echo request 330 should reach the end of the path, at which point it is sent to the 331 control plane of the egress LSRs, which verify that they are indeed 332 an egress (leaf) of the P2MP LSP. An echo response message is sent by 333 an egress to the ingress to confirm the successful receipt (or 334 announce the erroneous arrival) of the echo request. 336 In "traceroute" mode (fault isolation), the echo request is sent to 337 the control plane at each transit LSR, and the control plane checks 338 that it is indeed a transit LSR for this P2MP MPLS LSP. The transit 339 LSR also returns information on an echo response that helps verify 340 the control plane against the data plane. That is, the information 341 is used by the ingress to check that the data plane forwarding 342 matches what is signaled by the control plane. 344 P2MP MPLS LSPs may have many egresses, and it is not necessarily the 345 intention of the initiator of the ping or traceroute operation to 346 collect information about the connectivity or path to all egresses. 347 Indeed, in the event of pinging all egresses of a large P2MP MPLS 348 LSP, it might be expected that a large number of echo responses would 349 arrive at the ingress independently but at approximately the same 350 time. Under some circumstances this might cause congestion at or 351 around the ingress LSR. Therefore, the procedures described in this 352 document provide a mechanism that allows the responders to randomly 353 delay (or jitter) their responses so that the chances of swamping the 354 ingress are reduced. 356 Further, the procedures in this document allow the initiator to limit 357 the scope of an LSP Ping echo request (ping or traceroute mode) to 358 one specific intended egress. 360 The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be 361 addressed by other mechanisms such as [MCAST-CV] that utilize the LSP 362 Ping procedures in this document to provide bootstrapping mechanisms 363 as described in Section 2.3. 365 LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure 366 connectivity to any or all of the egresses. If the ping fails, 367 the operator or an automated process can then initiate a traceroute 368 to determine where the fault is located within the network. A 369 traceroute may also be used periodically to verify that data plane 370 forwarding matches the control plane state; however, this places an 371 increased burden on transit LSRs and should be used infrequently and 372 with caution. 374 2.3 Bootstrapping Other OAM Procedures Using LSP Ping 376 [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to 377 bootstrap the Bidirectional Forwarding Detection (BFD) mechanism 378 [BFD] for use to track the liveliness of an MPLS LSP. In particular 379 BFD can be used to detect a data plane failure in the forwarding 380 path of an MPLS LSP. 382 Requirements for MPLS P2MP LSPs extend to hundreds or even thousands 383 of endpoints. If a protocol required explicit acknowledgments to 384 each probe for connectivity verification, the response load at the 385 root would be overwhelming. 387 A more scalable approach to monitoring P2MP LSP connectivity is 388 described in [MCAST-CV]. It relies on using the MPLS echo request and 389 echo response messages of LSP Ping [RFC4379] to bootstrap the 390 monitoring mechanism in a manner similar to [MPLS-BFD]. The actual 391 monitoring is done using a separate process defined in [MCAST-CV]. 393 Note that while the approach described in [MCAST-CV] was developed in 394 response to the multicast scalability problem, it can be applied to 395 P2P LSPs as well. 397 3. Operation of LSP Ping for a P2MP LSP 399 This section describes how LSP Ping is applied to P2MP MPLS LSPs. 400 It covers the mechanisms and protocol fields applicable to both ping 401 mode and traceroute mode. It explains the responsibilities of the 402 initiator (ingress), transit nodes, and receivers (egresses). 404 3.1. Identifying the LSP Under Test 406 3.1.1. Identifying a P2MP MPLS TE LSP 408 [RFC4379] defines how an MPLS TE LSP under test may be identified in 409 an echo request. A Target FEC Stack TLV is used to carry either an 410 RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. 412 In order to identify the P2MP MPLS TE LSP under test, the echo 413 request message MUST carry a Target FEC Stack TLV, and this MUST 414 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 415 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs 416 carry fields from the RSVP-TE P2MP Session and Sender-Template 417 objects [RFC4875] and so provide sufficient information to uniquely 418 identify the LSP. 420 The new sub-TLVs are assigned sub-type identifiers as follows, and 421 are described in the following sections. 423 Sub-Type # Length Value Field 424 ---------- ------ ----------- 425 TBD 20 RSVP P2MP IPv4 Session 426 TBD 56 RSVP P2MP IPv6 Session 428 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 430 The format of the RSVP P2MP IPv4 Session sub-TLV value field is 431 specified in the following figure. The value fields are taken from 432 the definitions of the P2MP IPv4 LSP Session Object and the P2MP 433 IPv4 Sender-Template Object in [RFC4875]. Note that the Sub-Group 434 ID of the Sender-Template is not required. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | P2MP ID | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Must Be Zero | Tunnel ID | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Extended Tunnel ID | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | IPv4 tunnel sender address | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Must Be Zero | LSP ID | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV 452 The format of the RSVP P2MP IPv6 Session sub-TLV value field is 453 specified in the following figure. The value fields are taken from 454 the definitions of the P2MP IPv6 LSP Session Object, and the 455 P2MP IPv6 Sender-Template Object in [RFC4875]. Note that the 456 Sub-Group ID of the Sender-Template is not required. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 | P2MP ID | 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Must Be Zero | Tunnel ID | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | | 468 | Extended Tunnel ID | 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 | IPv6 tunnel sender address | 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Must Be Zero | LSP ID | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 3.1.2. Identifying a Multicast LDP LSP 480 [RFC4379] defines how a P2P LDP LSP under test may be identified in 481 an echo request. A Target FEC Stack TLV is used to carry one or more 482 sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the 483 LSP. 485 In order to identify a multicast LDP LSP under test, the echo request 486 message MUST carry a Target FEC Stack TLV, and this MUST carry 487 exactly one new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This 488 sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so 489 provides sufficient information to uniquely identify the LSP. 491 The new sub-TLV is assigned a sub-type identifier as follows, and 492 is described in the following section. 494 Sub-Type # Length Value Field 495 ---------- ------ ----------- 496 TBD Variable Multicast LDP FEC Stack 498 3.1.2.1. Multicast LDP FEC Stack Sub-TLV 500 The format of the Multicast LDP FEC Stack sub-TLV is shown below. 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Address Family | Address Length| Root LSR Addr | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 ~ Root LSR Address (Cont.) ~ 509 | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Opaque Length | Opaque Value ... | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 513 ~ ~ 514 | | 515 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Address Family 521 A two octet quantity containing a value from ADDRESS FAMILY 522 NUMBERS in [IANA-PORT] that encodes the address family for the 523 Root LSR Address. 525 Address Length 527 The length of the Root LSR Address in octets. 529 Root LSR Address 531 An address of the LSR at the root of the P2MP LSP encoded 532 according to the Address Family field. 534 Opaque Length 536 The length of the Opaque Value, in octets. 538 Opaque Value 540 An opaque value elements of which uniquely identifies the P2MP LSP 541 in the context of the Root LSR. 543 If the Address Family is IPv4, the Address Length MUST be 4. If the 544 Address Family is IPv6, the Address Length MUST be 16. No other 545 Address Family values are defined at present. 547 3.2. Ping Mode Operation 549 3.2.1. Controlling Responses to LSP Pings 551 As described in Section 2.2, it may be desirable to restrict the 552 operation of LSP Ping to a single egress. Since echo requests are 553 forwarded through the data plane without interception by the control 554 plane (compare with traceroute mode), there is no facility to limit 555 the propagation of echo requests, and they will automatically be 556 forwarded to all (reachable) egresses. 558 However, the intended egress under test can be identified by the 559 inclusion of a P2MP Responder Identifier TLV containing an IPv4 P2MP 560 Responder Identifier sub-TLV or an IPv6 P2MP Responder Identifier 561 sub-TLV. The P2MP Responder Identifier TLV SHOULD contain precisely 562 one sub-TLV. If the TLV contains no sub-TLVs it SHOULD be processed 563 as if the whole TLV were absent (causing all egresses to respond as 564 described below). If the TLV contains more than one sub-TLV, the 565 first MUST be processed as described in this document, and subsequent 566 sub-TLVs SHOULD be ignored. 568 An initiator may indicate that it wishes all egresses to respond to 569 an echo request by omitting the P2MP Responder Identifier TLV. 571 Note that the ingress of a multicast LDP LSP will not know the 572 identities of the egresses of the LSP except by some external means 573 such as running P2MP LSP Ping to all egresses. 575 3.2.2. Ping Mode Egress Procedures 577 An egress node is RECOMMENDED to rate limit its receipt of echo 578 request messages as described in [RFC4379]. After rate limiting, an 579 egress node that receives an echo request carrying an RSVP P2MP IPv4 580 Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast 581 LDP FEC Stack sub-TLV MUST determine whether it is an intended egress 582 of the P2MP LSP in question by checking with the control plane. If it 583 is not supposed to be an egress, it MUST respond according to the 584 setting of the Response Type field in the echo message following the 585 rules defined in [RFC4379]. 587 If the egress node that receives an echo request and allows it 588 through its rate limiting is an intended egress of the P2MP LSP, the 589 node MUST check to see whether it is an intended Ping recipient. If a 590 P2MP Responder Identifier TLV is present and contains an address that 591 indicates any address that is local to the node, the node MUST 592 respond according to the setting of the Response Type field in the 593 echo message following the rules defined in [RFC4379]. If the P2MP 594 Responder Identifier TLV is present, but does not identify the egress 595 node, it MUST NOT respond to the echo request. If the P2MP Responder 596 Identifier TLV is not present (or, in the error case, is present, but 597 does not contain any sub-TLVs), but the egress node that received the 598 echo request is an intended egress of the LSP, the node MUST respond 599 according to the setting of the Response Type field in the echo 600 message following the rules defined in [RFC4379]. 602 3.2.3. Jittered Responses 604 The initiator (ingress) of a ping request MAY request the responding 605 egress to introduce a random delay (or jitter) before sending the 606 response. The randomness of the delay allows the responses from 607 multiple egresses to be spread over a time period. Thus this 608 technique is particularly relevant when the entire LSP tree is being 609 pinged since it helps prevent the ingress (or nearby routers) from 610 being swamped by responses, or from discarding responses due to rate 611 limits that have been applied. 613 It is desirable for the ingress to be able to control the bounds 614 within which the egress delays the response. If the tree size is 615 small, only a small amount of jitter is required, but if the tree is 616 large, greater jitter is needed. The ingress informs the egresses of 617 the jitter bound by supplying a value in a new TLV (the Echo Jitter 618 TLV) carried on the echo request message. If this TLV is present, 619 the responding egress MUST delay sending a response for a random 620 amount of time between zero seconds and the value indicated in the 621 TLV. If the TLV is absent, the responding egress SHOULD NOT introduce 622 any additional delay in responding to the echo request. 624 LSP ping SHOULD NOT be used to attempt to measure the round-trip 625 time for data delivery. This is because the LSPs are unidirectional, 626 and the echo response is often sent back through the control plane. 627 The timestamp fields in the echo request/response MAY be used to 628 deduce some information about delivery times and particularly the 629 variance in delivery times. 631 The use of echo jittering does not change the processes for gaining 632 information, but note that the responding egress MUST set the value 633 in the Timestamp Received fields before applying any delay. 635 It is RECOMMENDED that echo response jittering is not used except in 636 the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo 637 request for any other type of TLV, the responding egress MAY apply 638 the jitter behavior described here. 640 3.2.4. P2MP Responder Identifier TLV and Sub-TLVs 642 A new TLV is defined for inclusion in the Echo request message. 644 The P2MP Responder Identifier TLV is assigned the TLV type value TBD 645 and is encoded as follows. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |Type=TBD(P2MP Responder ID TLV)| Length = Variable | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 ~ Sub-TLVs ~ 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Sub-TLVs: 657 Zero, one or more sub-TLVs as defined below. 659 If no sub-TLVs are present, the TLV MUST be processed as if it 660 were absent. If more than one sub-TLV is present the first MUST 661 be processed as described in this document, and subsequent 662 sub-TLVs SHOULD be ignored. 664 The P2MP Responder Identifier TLV only has meaning on an echo request 665 message. If present on an echo response message, it SHOULD be 666 ignored. 668 Two sub-TLVs are defined for inclusion in the P2MP Responder 669 Identifier TLV carried on the echo request message. These are: 671 Sub-Type # Length Value Field 672 ---------- ------ ----------- 673 1 4 IPv4 P2MP Responder Identifier 674 2 16 IPv6 P2MP Responder Identifier 676 The value of an IPv4 P2MP Responder Identifier consists of four 677 octets of an IPv4 address. The IPv4 address is in network byte order. 679 The value of an IPv6 P2MP Responder Identifier consists of sixteen 680 octets of an IPv6 address. The IPv6 address is in network byte order. 682 3.2.5. Echo Jitter TLV 684 A new TLV is defined for inclusion in the Echo request message. 686 The Echo Jitter TLV is assigned the TLV type value TBD and is encoded 687 as follows. 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Type = TBD (Jitter TLV) | Length = 4 | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Jitter time | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 Jitter time: 699 This field specifies the upper bound of the jitter period that 700 should be applied by a responding node to determine how long to 701 wait before sending an echo response. A responding node SHOULD 702 wait a random amount of time between zero seconds and the value 703 specified in this field. 705 Jitter time is specified in milliseconds. 707 The Echo Jitter TLV only has meaning on an echo request message. If 708 present on an echo response message, it SHOULD be ignored. 710 3.2.6. Echo Response Reporting 712 Echo response messages carry return codes and subcodes to indicate 713 the result of the LSP Ping (when the ping mode is being used) as 714 described in [RFC4379]. 716 When the responding node reports that it is an egress, it is clear 717 that the echo response applies only to the reporting node. Similarly, 718 when a node reports that it does not form part of the LSP described 719 by the FEC (i.e. their is a misconnection) then the echo response 720 applies to the reporting node. 722 However, it should be noted that an echo response message that 723 reports an error from a transit node may apply to multiple egress 724 nodes (i.e. leaves) downstream of the reporting node. In the case of 725 the Ping mode of operation, it is not possible to correlate the 726 reporting node to the affected egresses unless the shape of the P2MP 727 tree is already known, and it may be necessary to use the Traceroute 728 mode of operation (see Section 3.3) to further diagnose the LSP. 730 Note also that a transit node may discover an error but also 731 determine that while it does lie on the path of the LSP under test, 732 it does not lie on the path to the specific egress being tested. In 733 this case, the node SHOULD NOT generate an echo response. 735 A reporting node that is a branch node may need to report multiple 736 different errors (for different downstream branches). This is 737 discussed further in Section 3.3.6. 739 3.3. Traceroute Mode Operation 741 The traceroute mode of operation is described in [RFC4379]. Like 742 other traceroute operations, it relies on the expiration of the TTL 743 of the packet that carries the echo request. Echo requests may 744 include a Downstream Mapping TLV, and when the TTL expires the echo 745 request is passed to the control plane on the transit node which 746 responds according to the Response Type in the message. A responding 747 node fills in the fields of the Downstream Mapping TLV to indicate 748 the downstream interfaces and labels used by the reported LSP from 749 the responding node. In this way, by successively sending out echo 750 requests with increasing TTLs, the ingress may gain a picture of the 751 path and resources used by an LSP up to the point of failure when no 752 response is received, or an error response is generated by a node 753 where the control plane does not expect to be handling the LSP. 755 This mode of operation is equally applicable to P2MP MPLS TE LSPs 756 as described in the following sections. 758 The traceroute mode can be applied to all destinations of the P2MP 759 tree just as in the ping mode. In the case of P2MP MPLS TE LSPs, the 760 traceroute mode can also be applied to individual traceroute targets 761 identified by the presence of a P2MP Responder Identifier TLV. These 762 targets may be egresses or transit nodes. However, since a transit 763 node of a multicast LDP LSP is unable to determine whether it lies on 764 the path to any one destination or any other transit node, the 765 traceroute mode limited to specific nodes of such an LSP MUST NOT be 766 used. 768 Note that the addresses specified in the P2MP Responder Identifier 769 TLV need not be egresses: they could be transit nodes on the LSP. The 770 processing rules here and in the following sections apply equally to 771 egress and transit nodes. 773 In the absence of a P2MP Responder Identifier TLV, the echo request 774 is asking for traceroute information applicable to all egresses. 776 The echo response jitter technique described for the ping mode is 777 equally applicable to the traceroute mode and is not additionally 778 described in the procedures below. 780 3.3.1. Traceroute Responses at Non-Branch Nodes 782 When the TTL for the MPLS packet carrying an echo request expires the 783 packet MUST be passed to the control plane as specified in [RFC4379]. 784 If the LSP under test is a multicast LDP LSP and if the echo request 785 carries a P2MP Responder Identifier TLV the node MUST treat the echo 786 request as malformed and MUST process it according to the rules 787 specified in [RFC4379]. 789 Otherwise, the node MUST NOT return an echo response unless the 790 responding node lies on the path of the P2MP LSP to the node (egress 791 or transit) identified by the P2MP Responder Identifier TLV carried 792 on the request, or if no such sub-TLV is present. 794 If sent, the echo response MUST identify the next hop of the path of 795 the LSP in the data plane by including a Downstream Mapping TLV as 796 described in [RFC4379]. 798 3.3.1.1. Correlating Traceroute Responses 800 When traceroute is being simultaneously applied to multiple 801 responders (e.g., egresses), it is important that the ingress should 802 be able to correlate the echo responses with the branches in the P2MP 803 tree. Without this information the ingress will be unable to 804 determine the correct ordering of transit nodes. One possibility is 805 for the ingress to poll the path to each responder in turn, but this 806 may be inefficient, undesirable, or (in the case of multicast LDP 807 LSPs) illegal. 809 The Downstream Mapping TLV that MUST be included in the echo response 810 indicates the next hop from each responding node, and this 811 information supplied by a non-branch node can be pieced together by 812 the ingress to reconstruct the P2MP tree although it may be necessary 813 to refer to the routing information distributed by the IGP to 814 correlate next hop addresses and node reporting addresses in 815 subsequent echo responses. 817 In order to facilitate more easy correlation of echo responses, the 818 Downstream Mapping TLV can also contain Multipath Information as 819 described in [RFC4379] to identify to which responders (transit 820 nodes or egresses) the echo response applies. This information: 822 - Cannot be present when the information is not known by the 823 responding node. For example, for a multicast LDP LSP, the branch 824 node will not know through normal LDP signaling which leaf nodes 825 lie on which downstream branch. 827 - SHOULD be present when the information is known by the responding 828 node. That is for P2MP MPLS TE LSPs when the echo request applies 829 to all egresses or to a specific single transit node or egress. 831 The format of the information in the Downstream Mapping TLV for 832 P2MP MPLS LSPs is described in section 3.3.5. 834 3.3.2. Traceroute Responses at Branch Nodes 836 A branch node may need to identify more than one downstream interface 837 in a traceroute echo response if some of the nodes identified in the 838 P2MP Responder Identifier TLV that are being traced lie on different 839 branches. This will always be the case for any branch node if all 840 egresses are being traced. 842 [RFC4379] describes how multiple Downstream Mapping TLVs should be 843 included in an echo response, each identifying exactly one downstream 844 interface that is applicable to the LSP. 846 A branch node MUST follow the procedures described in Section 3.3.1 847 to determine whether it should respond to an echo request. The branch 848 node MUST add a Downstream Mapping TLV (or Downstream Detailed 849 Mapping TLV - see Section 3.3.7) to the echo response for each 850 outgoing branch that it reports, but it MUST NOT report branches that 851 do not lie on the path to one of the destinations being traced. Thus 852 a branch node may sometimes only need to respond with a single 853 Downstream Mapping TLV; for example, consider the case where the 854 traceroute is directed to only a single egress node. Therefore, 855 the presence of only one Downstream Mapping TLV in an echo response 856 does not guarantee that the reporting node is not a branch node. 858 To report on its branching properties on a particular LSP, the 859 responding node MAY include an optional TLV called the Node 860 Properties TLV. This new TLV (see Section 3.3.2.1) can carry sub- 861 TLVs, one of which (the Branching Properties sub-TLV - see Section 862 3.3.2.2) allows the reporting node to describe the branching 863 characteristics of the LSP at the reporting node. 865 3.3.2.1. Node Properties TLV 867 A new TLV has been added to the set of optional TLVs that may be 868 carried on an echo response message. 870 Type # Value Field 871 ------ ------------ 873 TBD Node properties 875 The Node Properties TLV MAY be included in an echo response message. 876 If more than one such TLV is present, the first MUST be processed and 877 subsequent instances SHOULD be ignored. 879 The Node Properties TLV is used to report characteristics of the 880 reporting node, and the LSP at that node. This distinguishes it from 881 the Downstream Mapping TLV [RFC4379] and the Downstream Detailed 882 Mapping TLV [DDMT] used to report characteristics of specific out- 883 segments an LSP. 885 The Node Properties TLV is a standard LSP Ping TLV as defined in 886 [RFC4379]. It has the following format. 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 : : 892 : First Sub-TLV : 893 : : 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 ~ ~ 896 ~ Further Sub-TLVs ~ 897 ~ ~ 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 The content of the Node Properties TLV is a series of one or more 901 sub-TLVs. The Nore Properties TLV SHOULD contain one or more sub-TLVs 902 and MUST be ignored if there are no sub-TLVs present. 904 Each sub-TLV consists of the following fields as per [RFC4379]: 906 - Two octet Type field: A value indicating the sub-TLV type. 908 - Two octet Length field: A value indicating the total length of the 909 Value field. 911 - A Value field carrying the data of the sub-TLV. The content of the 912 Value field is padded to a four byte boundary with zero-filled 913 octets so that the Length field is always a multiple of 4. 915 3.3.2.2. Branching Properties Sub-TLV 917 This document defines the Branching Properties sub-TLV carried in the 918 Node Properties TLV. The Branching Properties sub-TLV is optional. If 919 more than one such sub-TLV is found in a Node Properties TLV, the 920 first MUST be processed and subsequent instances SHOULD be ignored. 921 The sub-TLV may be used for P2MP and P2P LSPs. 923 The Branching Properties sub-TLV is formed as described in Section 924 3.3.2.1. The Value field has the following format. 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Downstream Branch Count | Egress Count | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Downstream Branch Count 934 This field reports the number of downstream branches from the 935 reporting node for this LSP. The number may be zero for an egress, 936 one for a non-branch node, and more than one for a branch node. 937 Note that the value reported here may be greater than the number 938 of Downstream Mapping TLVs present in the echo response message 939 since those TLVs only report on the specific egresses queried. This 940 value may be of use in detecting faults caused by delay introduced 941 by the data replication mechanism at branch nodes. 943 Egress Count 945 This field reports the number of egresses local to the reporting 946 node. Thus, for non-zero values the reporting node is either a leaf 947 or a bud. When the value reported is non-zero, the reporting node 948 MAY also include an Egress Address Sub-TLV for each local egress 949 (see Section 3.3.2.3). 951 For example, a branch node that has two downstream next hops on the 952 LSP and that also delivers payload data to one local egress would set 953 the two fields to 2 and 1 respectively. 955 3.3.2.3. Egress Address Sub-TLV 957 This document defines the IPv4 and IPv6 Egress Address sub-TLVs 958 carried in the Node Properties TLV. These TLVs are optional, and more 959 than one instance of the sub-TLVs may legitimately be present. 961 The Egress Address sub-TLVs are formed as described in Section 962 3.3.2.1. The Value field has the following formats. 964 IPv4 Egress Address Sub-TLV 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | IPv4 Egress Address | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 IPv6 Egress Address Sub-TLV 974 0 1 2 3 975 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 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | IPv6 Egress Address | 978 | (16 octets) | 979 | | 980 | | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 The Egress Address sub-TLVs are optional. They MAY be included in a 984 Node Properties TLV when reporting node is an egress (leaf or bud) 985 for the LSP being tested. The sub-TLV may be used for P2MP and P2P 986 LSPs. 988 When one or more Egress Address sub-TLVs are present and the Branch 989 Properties sub-TLV is also present, the value of the Egress Count 990 field in the Branch Properties sub-TLV SHOULD be the same as the 991 number of Egress Address sub-TLVs. 993 The address contained in an Egress Address sub-TLV is the egress 994 address to which the data is delivered. If there is just one egress 995 and if the egress address is the same as the local node address 996 carried in the main echo response message, both the Branching 997 Properties sub-TLV and the Egress Address sub-TLV MAY be omitted as 998 in legacy LSP Ping implementations. 1000 3.3.2.4. Correlating Traceroute Responses 1002 Just as with non-branches, it is important that the echo responses 1003 from branch nodes provide correlation information that will allow the 1004 ingress to work out to which branch of the LSP the response applies. 1006 The P2MP tree can be determined by the ingress using the identity of 1007 the reporting node and the next hop information from the previous 1008 echo response, just as with echo responses from non-branch nodes. 1010 As with non-branch nodes, in order to facilitate more easy 1011 correlation of echo responses, the Downstream Mapping TLV can also 1012 contain Multipath Information as described in [RFC4379] to identify 1013 to which nodes the echo response applies. This information: 1015 - Cannot be present when the information is not known by the 1016 responding node. For example, for a multicast LDP LSP, the branch 1017 node will not know through normal LDP signaling which leaf nodes 1018 lie on which downstream branch. 1020 - SHOULD be present when the information is known by the responding 1021 node. That is for P2MP MPLS TE LSPs when the echo request applies 1022 to all egresses or to a specific single transit node or egress. 1024 The format of the information in the Downstream Mapping TLV for 1025 P2MP MPLS LSPs is described in section 3.3.5. 1027 3.3.3. Traceroute Responses at Bud Nodes 1029 Some nodes on a P2MP MPLS LSP may be egresses, but also have 1030 downstream node. Such nodes are known as bud nodes [RFC4461]. 1032 A bud node MUST respond to a traceroute echo request just as a branch 1033 node would, but it MUST also indicate to the ingress that it is an 1034 egress in its own right. The issue to be resolved here is how to 1035 indicate that the reporting node is an egress when it is also 1036 providing one or more Downstream Mapping TLVs that indicate that it 1037 has downstream neighbors. 1039 This is achieved by the inclusion of a Node Properties TLV with a 1040 Branch Properties sub-TLV indicating the number of local egresses and 1041 the number of downstream branches. The bud node MAY also include one 1042 or more Egress Address sub-TLVs in the Node Properties TLV to report 1043 on the local egresses. 1045 3.3.4. Non-Response to Traceroute Echo Requests 1047 The nature of P2MP MPLS TE LSPs in the data plane means that 1048 traceroute echo requests may be delivered to the control plane of 1049 nodes that must not reply to the request because, although they lie 1050 on the P2MP tree, they do not lie on the path to the node that is 1051 being traced. 1053 Thus, a node on a P2MP MPLS LSP MUST NOT respond to an echo request 1054 when the TTL has expired if any of the following applies: 1056 - The Reply Type indicates that no reply is required [RFC4379] 1058 - There is a P2MP Responder Identifier TLV present on the echo 1059 request (which means that the LSP is a P2MP MPLS TE LSP), but the 1060 address does not identify a node that is reached through this node 1061 for this particular P2MP MPLS LSP. 1063 Note that when no response to an echo request is received by the 1064 ingress (perhaps because the transit node has failed, or perhaps 1065 because the transit node does not support LSP Ping), then as per 1066 [RFC4379] the subsequent echo request (with a larger TTL) SHOULD be 1067 sent with Downstream Mapping TLV "Downstream IP Address" field set to 1068 the ALLROUTERs multicast address until a reply is received with a 1069 Downstream Mapping TLV. 1071 3.3.5. Additions to Downstream Mapping Multipath Information 1073 A new value for the Multipath Type is defined to indicate that the 1074 reported Multipath Information applies to a P2MP MPLS TE LSP and may 1075 contain a list of node identifiers that indicate the egress nodes and 1076 (in the case where the P2MP Responder Identifier TLV was used on the 1077 echo request to identify non-egress nodes) transit nodes that can be 1078 reached through the reported interface. This Multipath Type MUST NOT 1079 be used for a multicast LDP LSP. 1081 Type # Address Type Multipath Information 1082 --- ---------------- ------------------------------ 1083 TBD P2MP responders List of reachable P2MP nodes 1085 Note that a list of nodes may include IPv4 and IPv6 identifiers since 1086 these may be mixed in the P2MP MPLS TE LSP. 1088 The Multipath Length field continues to identify the length of the 1089 Multipath Information just as in [RFC4379] (that is, not including 1090 the downstream labels), and the downstream label (or potential stack 1091 thereof) is also handled just as in [RFC4379]. The format of the 1092 Multipath Information for a Multipath Type of P2MP responders is as 1093 follows. 1095 0 1 2 3 1096 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 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Address Type | Responder Address (4 or 16 octets) | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | (continued) | : 1101 +-+-+-+-+-+-+-+-+ : 1102 : Further Address Types and Responder Addresses : 1103 : : 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Address Type 1108 This field indicates whether the address that follows is an IPv4 1109 or IPv6 address, and so implicitly encodes the length of the 1110 address. 1112 Two values are defined and mirror the values used in the Address 1113 Type field of the Downstream Mapping TLV itself. 1115 Type # Address Type 1116 ------ ------------ 1117 1 IPv4 1118 3 IPv6 1120 Responder Address 1122 An egress or transit node of this P2MP MPLS TE LSP that is 1123 reached through the interface indicated by the Downstream 1124 Mapping TLV and for which the traceroute echo request was 1125 enquiring. 1127 Note that padding to ensure that the whole Multipath information is 1128 aligned to a four-octet boundary is applied only after the last 1129 responder address in the list. That is, each successive Address Type 1130 follows on immediately after the previous Responder Address. 1132 3.3.6. Echo Response Reporting 1134 Echo responses are generated in response to traceroute echo requests 1135 at transit, branch, and bud nodes as described in Sections 3.3.1, 1137 3.3.2, and 3.3.3, while egress responses are as described in 1138 [RFC4379]. 1140 Note, however, that a branch or bud node may have multiple downstream 1141 branches, and a transit node may have multiple downstream egresses 1142 (reached on the same branch). It may be the case that different 1143 conditions need to be reported for different branches or egresses. 1144 The echo response message defined in [RFC4379] has space for only a 1145 single return code and subcode pair, so where more than one return 1146 condition is reported by a single node it acts as follows. 1148 - It SHOULD use the Downstream Detailed Mapping TLV [DDMT] in place 1149 of the Downstream Mapping TLV, and encode the return code as 1150 described in Section 3.3.6.1. 1152 - It MAY report each condition in a separate echo response in which 1153 case MUST limit the downstream mapping information on each echo 1154 response to those branches/egresses to which the response applies. 1155 The use of multiple echo response messages to report errors might 1156 cause issues for an initiator that does not know how many responses 1157 it should wait for. For that reason, multiple messages should be 1158 used with care. 1160 3.3.6.1. Reporting Multiple Conditions Using The DDM TLV 1162 When multiple different return codes are indicated on a single echo 1163 response message they MUST be carried in separate instances on the 1164 Downstream Detailed Mapping (DDM) TLV [DDMT]. That is, each instance 1165 of a DDM TLV carries one return code, and all information carried in 1166 that TLV MUST be limited to branches/egresses to which that return 1167 code applies. However, more than one DDM TLV on the same echo 1168 response MAY carry the same return code. 1170 The echo response message still carries a Return Code and a Return 1171 Subcode field. In order to clearly indicate that the relevant return 1172 codes are carried in the DDM TLV, a new return code is defined to be 1173 carried in the Return Code field of the echo response message as 1174 follows: 1176 Value Meaning 1177 ----- ------- 1178 TBD See DDM TLV for more details 1180 The Return Subcode for this Return Code MUST be set to zero and 1181 MUST be ignored. 1183 The DDM TLV is defined as carrying a set of sub-TLVs. A new sub-TLV, 1184 the Return Code sub-TLV, is defined here to carry a return code and 1185 return subcode. 1187 0 1 2 3 1188 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 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Return Code | Return Subcode| Reserved | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 The length of the Return Code sub-TLV is 8. 1195 Return Code 1196 As defined for inclusion in the echo response message in [RFC4379]. 1198 Return Subcode 1199 As defined for inclusion in the echo response message in [RFC4379]. 1201 Reserved 1202 SHOULD be set to zero on transmission and MUST be ignored on 1203 receipt. 1205 If the Return Code of the echo response message is not set to "See 1206 DDM TLV for more details" then any Return Code sub-TLV present in a 1207 DDM TLV SHOULD be ignored. 1209 If the Return Code of the echo response message is set to "See DDM 1210 TLV for more details" then a Return Code sub-TLV MUST be present in 1211 each DDM TLV. Subsequent Return Code sub-TLVs present in the same DDM 1212 TLV SHOULD be ignored. 1214 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms 1216 Bootstrapping of other OAM procedures can be achieved using the 1217 MPLS Echo Request/Response messages. The LSP(s) under test are 1218 identified using the RSVP P2MP IPv4 or IPv6 Session sub-TLVs 1219 (see Section 3.1.1) or the Multicast LDP FEC Stack sub-TLV 1220 (see Section 3.1.2). 1222 Other sub-TLVs may be defined in other specifications to indicate 1223 the OAM procedures being bootstrapped, and to describe the bootstrap 1224 parameters. Further details of the bootstrapping processes and the 1225 bootstrapped OAM processes are described in other documents. For 1226 example, see [MPLS-BFD] and [MCAST-CV]. 1228 5. Non-compliant Routers 1230 If an egress for a P2MP LSP does not support MPLS LSP ping, then no 1231 reply will be sent, resulting in a "false negative" result. There is 1232 no protection for this situation, and operators may wish to ensure 1233 that end points for P2MP LSPs are all equally capable of supporting 1234 this function. Alternatively, the traceroute option can be used to 1235 verify the LSP nearly all the way to the egress, leaving the final 1236 hop to be verified manually. 1238 If, in "traceroute" mode, a transit node does not support LSP ping, 1239 then no reply will be forthcoming from that node for some TTL, say n. 1240 The node originating the echo request SHOULD continue to send echo 1241 request with TTL=n+1, n+2, ..., n+k to probe nodes further down the 1242 path. In such a case, the echo request for TTL > n SHOULD be sent 1243 with Downstream Mapping TLV "Downstream IP Address" field set to the 1244 ALLROUTERs multicast address as described in Section 3.3.4 until a 1245 reply is received with a Downstream Mapping TLV. 1247 6. OAM Considerations 1249 The procedures in this document provide OAM functions for P2MP MPLS 1250 LSPs and may be used to enable bootstrapping of other OAM procedures. 1252 In order to be fully operational several considerations must be made. 1254 - Scaling concerns dictate that only cautious use of LSP Ping should 1255 be made. In particular, sending an LSP Ping to all egresses of a 1256 P2MP MPLS LSP could result in congestion at or near the ingress 1257 when the responses arrive. 1259 Further, incautious use of timers to generate LSP Ping echo 1260 requests either in ping mode or especially in traceroute may lead 1261 to significant degradation of network performance. 1263 - Management interfaces should allow an operator full control over 1264 the operation of LSP Ping. In particular, it SHOULD provide the 1265 ability to limit the scope of an LSP Ping echo request for a P2MP 1266 MPLS LSP to a single egress. 1268 Such an interface SHOULD also provide the ability to disable all 1269 active LSP Ping operations to provide a quick escape if the network 1270 becomes congested. 1272 - A MIB module is required for the control and management of LSP Ping 1273 operations, and to enable the reported information to be inspected. 1275 There is no reason to believe this should not be a simple extension 1276 of the LSP Ping MIB module used for P2P LSPs. 1278 7. IANA Considerations 1280 7.1. New Sub-TLV Types 1282 Three new sub-TLV types are defined for inclusion within the LSP Ping 1283 [RFC4379] Target FEC Stack TLV (TLV type 1). 1285 IANA is requested to assign sub-type values to the following 1286 sub-TLVs from the "Multiprotocol Label Switching Architecture (MPLS) 1287 Label Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and 1288 sub-TLVs" sub-registry. 1290 RSVP P2MP IPv4 Session (see Section 3.1.1). Suggested value 17. 1291 RSVP P2MP IPv6 Session (see Section 3.1.1). Suggested value 18. 1292 Multicast LDP FEC Stack (see Section 3.1.2). Suggested value 19. 1294 7.2. New Multipath Type 1296 Section 3.3 of [RFC4379] defines a set of values for the LSP Ping 1297 Multipath Type. These values are currently not tracked by IANA. 1299 A new value for the LSP Ping Multipath Type is defined in Section 1300 3.3.5 of this document to indicate that the reported Multipath 1301 Information applies to a P2MP MPLS TE LSP. 1303 IANA is requested to create a new registry as follows: 1305 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1306 Paths (LSPs) - Multipath Types" 1308 Key Type Multipath Information 1309 --- ---------------- --------------------- 1310 0 no multipath Empty (Multipath Length = 0) [RFC4379] 1311 2 IP address IP addresses [RFC4379] 1312 4 IP address range low/high address pairs [RFC4379] 1313 8 Bit-masked IP IP address prefix and bit mask [RFC4379] 1314 address set 1315 9 Bit-masked label set Label prefix and bit mask [RFC4379] 1316 xx P2MP responder IP List of P2MP responders [thisDoc] 1317 addresses 1319 A suggested value of xx is 16. 1321 New values from this registry are to be assigned only by Standards 1322 Action. 1324 7.3. New TLVs 1326 Three new LSP Ping TLV types are defined for inclusion in LSP Ping 1327 messages. 1329 IANA is requested to assign a new value from the "Multi-Protocol 1330 Label Switching Architecture (MPLS) Label Switched Paths (LSPs) 1331 Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as 1332 follows using a Standards Action value. 1333 P2MP Responder Identifier TLV (see Section 3.2.4) is a mandatory 1334 TLV. Suggested value 11. 1336 Two sub-TLVs are defined 1337 - Type 1: IPv4 P2MP Responder Identifier (see Section 3.2.4) 1338 - Type 2: IPv6 P2MP Responder Identifier (see Section 3.2.4) 1340 Echo Jitter TLV (see Section 3.2.5) is a mandatory TLV. Suggested 1341 value 12. 1343 Node Properties TLV (see Section 3.2.2.1) is an optional TLV. 1344 Suggested value 32768. 1345 Three sub-TLVs are defined 1346 - Type 1: IPv4 Egress Address 1347 - Type 2: IPv6 Egress Address 1348 - Type 3: Branch Properties 1350 7.4. New Return Code 1352 A new Return Code is defined in Section 3.3.6.1. 1354 IANA is requested to assign a new Return Code value for the "Multi- 1355 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 1356 Parameters" registry, "Return Codes" sub-registry as follows using a 1357 Standards Action value. 1359 Value Meaning 1360 ----- ------- 1361 TBD See DDM TLV for more details 1363 Suggested value 14. 1365 7.5. New Sub-TLV Value for the Downstream Detailed Mapping TLV 1367 [DDMT] defines a TLV called the Downstream Detailed Mapping TLV and 1368 requests IANA to maintain a registry of sub-TLVs that it can carry. 1370 Section 3.3.6.1 of this document defines a new sub-TLV. 1372 IANA is requested to assign a TLV type value as follows using a 1373 Standards Action value from the range 0-32767. 1375 Sub-Type Value Field 1376 --------- ------------ 1377 TBD Return Code 1379 8. Security Considerations 1381 This document does not introduce security concerns over and above 1382 those described in [RFC4379]. Note that because of the scalability 1383 implications of many egresses to P2MP MPLS LSPs, there is a 1384 stronger concern to regulate the LSP Ping traffic passed to the 1385 control plane by the use of a rate limiter applied to the LSP Ping 1386 well-known UDP port. Note that this rate limiting might lead to 1387 false positives. 1389 9. Acknowledgements 1391 The authors would like to acknowledge the authors of [RFC4379] for 1392 their work which is substantially re-used in this document. Also 1393 thanks to the members of the MBONED working group for their review 1394 of this material, to Daniel King and Mustapha Aissaoui for their 1395 review, and to Yakov Rekhter for useful discussions. 1397 The authors would like to thank Vanson Lim, Danny Prairie, Reshad 1398 Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin Bahadur, Tetsuya 1399 Murakami and Michael Hua for their comments and suggestions. 1401 10. Intellectual Property Considerations 1403 The IETF takes no position regarding the validity or scope of any 1404 Intellectual Property Rights or other rights that might be claimed to 1405 pertain to the implementation or use of the technology described in 1406 this document or the extent to which any license under such rights 1407 might or might not be available; nor does it represent that it has 1408 made any independent effort to identify any such rights. Information 1409 on the procedures with respect to rights in RFC documents can be 1410 found in BCP 78 and BCP 79. 1412 Copies of IPR disclosures made to the IETF Secretariat and any 1413 assurances of licenses to be made available, or the result of an 1414 attempt made to obtain a general license or permission for the use of 1415 such proprietary rights by implementers or users of this 1416 specification can be obtained from the IETF on-line IPR repository at 1417 http://www.ietf.org/ipr. 1419 The IETF invites any interested party to bring to its attention any 1420 copyrights, patents or patent applications, or other proprietary 1421 rights that may cover technology that may be required to implement 1422 this standard. Please address the information to the IETF at ietf- 1423 ipr@ietf.org. 1425 11. Normative References 1427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1428 Requirement Levels", BCP 14, RFC 2119, March 1997. 1430 [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol 1431 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1432 February 2006. 1434 [DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism 1435 for Performing LSP-Ping over MPLS Tunnels", draft-ietf- 1436 mpls-lsp-ping-enhanced-dsmap, work in progress. 1438 12. Informative References 1440 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 1442 [RFC4461] Yasukawa, S., "Signaling Requirements for Point to 1443 Multipoint Traffic Engineered Multiprotocol Label 1444 Switching (MPLS) Label Switched Paths (LSPs)", 1445 RFC 4461, April 2006. 1447 [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1448 "Operations and Management (OAM) Requirements for 1449 Point-to-Multipoint MPLS Networks", RFC 4687, September 1450 2006. 1452 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 1453 "Extensions to Resource Reservation Protocol - Traffic 1454 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1455 Switched Paths (LSPs)", RFC 4875, May 2007. 1457 [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for 1458 point-to-multipoint extensions to the Label Distribution 1459 Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. 1461 [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol 1462 Extensions for Point-to-Multipoint and 1463 Multipoint-to-Multipoint Label Switched Paths", 1464 draft-ietf-mpls-ldp-p2mp, work in progress. 1466 [MCAST-CV] Swallow, G., and Nadeau, T., "Connectivity Verification 1467 for Multicast Label Switched Paths", 1468 draft-swallow-mpls-mcast-cv, work in progress. 1470 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 1471 Detection", draft-ietf-bfd-base, work in progress. 1473 [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., 1474 "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in 1475 progress. 1477 [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 1479 13. Authors' Addresses 1481 Seisho Yasukawa 1482 NTT Corporation 1483 (R&D Strategy Department) 1484 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 1485 Phone: +81 3 5205 5341 1486 Email: s.yasukawa@hco.ntt.co.jp 1488 Adrian Farrel 1489 Old Dog Consulting 1490 EMail: adrian@olddog.co.uk 1492 Zafar Ali 1493 Cisco Systems Inc. 1494 2000 Innovation Drive 1495 Kanata, ON, K2K 3E8, Canada. 1496 Phone: 613-889-6158 1497 Email: zali@cisco.com 1499 Bill Fenner 1500 Arastra, Inc. 1501 275 Middlefield Rd. 1502 Suite 50 1503 Menlo Park, CA 94025 1504 Email: fenner@fenron.com 1506 George Swallow 1507 Cisco Systems, Inc. 1508 1414 Massachusetts Ave 1509 Boxborough, MA 01719 1510 Email: swallow@cisco.com 1512 Thomas D. Nadeau 1513 British Telecom 1514 BT Centre 1515 81 Newgate Street 1516 EC1A 7AJ 1517 London 1518 Email: tom.nadeau@bt.com 1520 14. Full Copyright Statement 1522 Copyright (C) The IETF Trust (2008). 1524 This document is subject to the rights, licenses and restrictions 1525 contained in BCP 78, and except as set forth therein, the authors 1526 retain all their rights. 1528 This document and the information contained herein are provided on an 1529 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1530 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1531 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1532 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1533 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1534 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.