idnits 2.17.1 draft-ietf-mpls-p2mp-lsp-ping-02.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 on line 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1088. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 2006) is 6425 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) ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-p2mp-oam-reqs (ref. 'P2MP-OAM-REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PORT' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Seisho Yasukawa (Editor) 2 IETF Internet Draft NTT 3 Proposed Status: Standards Track Adrian Farrel (Editor) 4 Expires: March 2007 Olddog Consulting 6 September 2006 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-02.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 recognised 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 mechanism 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 ................................................... 3 62 1.1 Design Considerations ......................................... 4 63 2. Notes on Motivation ............................................ 4 64 2.1. Basic Motivations for LSP Ping ............................... 4 65 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 5 66 2.3 Bootstrapping other OAM Procedures using LSP Ping ............. 7 67 3. Operation of LSP Ping for a P2MP LSP ........................... 7 68 3.1. Identifying the LSP Under Test ............................... 7 69 3.1.1. Identifying a P2MP MPLS TE LSP ............................. 7 70 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 8 71 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 8 72 3.1.2. Identifying a Multicast LDP LSP ............................ 9 73 3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10 74 3.2. Ping Mode Operation ......................................... 11 75 3.2.1. Controlling Responses to LSP Pings ........................ 11 76 3.2.2. Ping Mode Egress Procedures ............................... 11 77 3.2.3. Jittered Responses ........................................ 12 78 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 12 79 3.2.5. Echo Jitter TLV ........................................... 13 80 3.3. Traceroute Mode Operation ................................... 14 81 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15 82 3.3.1.1. Correlating Traceroute Responses ........................ 15 83 3.3.2. Traceroute Responses at Branch Nodes ..................... 16 84 3.3.2.1. Correlating Traceroute Responses ........................ 16 85 3.3.3. Traceroute Responses at Bud Nodes ......................... 17 86 3.3.4. Non-Response to Traceroute Echo Requests .................. 17 87 3.3.5. Modifications to the Downstream Mapping TLV ............... 17 88 3.3.6. Additions to Downstream Mapping Multipath Information ..... 18 89 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 19 90 5. Non-compliant Routers ......................................... 20 91 6. OAM Considerations ............................................ 20 92 7. IANA Considerations ........................................... 21 93 7.1. New Sub-TLV Types ........................................... 21 94 7.2. New Multipath Type .......................................... 21 95 7.3. New TLVs .................................................... 22 96 8. Security Considerations ....................................... 22 97 9. Acknowledgements .............................................. 22 98 10. Intellectual Property Considerations ......................... 22 99 11. Normative References ......................................... 23 100 12. Informative References ....................................... 23 101 13. Authors' Addresses ........................................... 24 102 14. Full Copyright Statement ..................................... 25 104 0. Change Log 106 This section to be removed before publication as an RFC. 108 0.1 Changes from 00 to 01 110 - Update references. 112 - Fix boilerplate. 114 0.2 Changes from 01 to 02 116 - Update entire document so that it is not specific to MPLS-TE, but 117 also includes multicast LDP LSPs. 119 - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new 120 egress identifier TLV. 122 - Include Multicast LDP FEC Stack Sub-TLV definition from [MCAST-CV]. 124 - Add brief section on use of LSP Ping for bootstrapping. 126 - Add new references to References section. 128 - Add details of two new authors. 130 1. Introduction 132 Simple and efficient mechanisms that can be used to detect data plane 133 failures in point-to-point (P2P) MPLS LSP are described in 134 [RFC4379]. The techniques involve information carried in an MPLS 135 "echo request" and "echo reply", and mechanisms for transporting the 136 echo reply. The echo request and reply messages provide sufficient 137 information to check correct operation of the data plane, as well as 138 a mechanism to verify the data plane against the control plane, and 139 thereby localize faults. The use of reliable reply channels for echo 140 request messages as described in [RFC4379] enables more robust fault 141 isolation. This collection of mechanisms is commonly referred to as 142 "LSP Ping". 144 The requirements for point-to-multipoint (P2MP) MPLS traffic 145 engineered (TE) LSPs are stated in [RFC4461]. [P2MP-RSVP] specifies a 146 signaling solution for establishing P2MP MPLS TE LSPs. 148 The requirements for point-to-multipoint extensions to the Label 149 Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] 150 specifies extensions to LDP for P2MP MPLS. 152 P2MP MPLS LSPs are at least as vulnerable to data plane faults or to 153 discrepancies between the control and data planes as their P2P 154 counterparts. Mechanisms are, therefore, desirable to detect such 155 data plane faults in P2MP MPLS LSPs as described in [P2MP-OAM-REQ]. 157 This document extends the techniques described in [RFC4379] such 158 that they may be applied to P2MP MPLS LSPs and so that they can be 159 used to bootstrap other OAM procedures such as [MCAST-CV]. This 160 document stresses the reuse of existing LSP Ping mechanisms used for 161 P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify 162 implementation and network operation. 164 1.1 Design Considerations 166 An important consideration for designing LSP Ping for P2MP MPLS LSPs 167 is that every attempt is made to use or extend existing mechanisms 168 rather than invent new mechanisms. 170 As for P2P LSPs, a critical requirement is that the echo request 171 messages follow the same data path that normal MPLS packets would 172 traverse. However, it can be seen this notion needs to be extended 173 for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so 174 that it arrives at each egress (or leaf) of the P2MP tree. 176 MPLS echo requests are meant primarily to validate the data plane, 177 and they can then be used to validate against the control plane. They 178 may also be used to bootsrap other OAM procedures such as [MPLS-BFD]. 179 As pointed out in [RFC4379], mechanisms to check the liveness, 180 function, and consistency of the control plane are valuable, but such 181 mechanisms are not a feature of LSP Ping and are not covered in this 182 document. 184 As is described in [RFC4379], to avoid potential Denial of Service 185 attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to 186 the control plane. A rate limiter should be applied to the well-known 187 UDP port defined for use by LSP Ping traffic. 189 2. Notes on Motivation 191 2.1. Basic Motivations for LSP Ping 193 The motivations listed in [RFC4379] are reproduced here for 194 completeness. 196 When an LSP fails to deliver user traffic, the failure cannot always 197 be detected by the MPLS control plane. There is a need to provide a 198 tool that would enable users to detect such traffic "black holes" or 199 misrouting within a reasonable period of time; and a mechanism to 200 isolate faults. 202 [RFC4379] describes a mechanism that accomplishes these goals. This 203 mechanism is modeled after the ping/traceroute paradigm: ping (ICMP 204 echo request [RFC792]) is used for connectivity checks, and 205 traceroute is used for hop-by-hop fault localization as well as path 206 tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode 207 for testing MPLS LSPs. 209 The basic idea as expressed in [RFC4379] is to test that the packets 210 that belong to a particular Forwarding Equivalence Class (FEC) 211 actually end their MPLS path on an LSR that is an egress for that 212 FEC. [RFC4379] achieves this test by sending a packet (called an 213 "MPLS echo request") along the same data path as other packets 214 belonging to this FEC. An MPLS echo request also carries information 215 about the FEC whose MPLS path is being verified. This echo request is 216 forwarded just like any other packet belonging to that FEC. In "ping" 217 mode (basic connectivity check), the packet should reach the end of 218 the path, at which point it is sent to the control plane of the 219 egress LSR, which then verifies that it is indeed an egress for the 220 FEC. In "traceroute" mode (fault isolation), the packet is sent to 221 the control plane of each transit LSR, which performs various checks 222 that it is indeed a transit LSR for this path; this LSR also returns 223 further information that helps to check the control plane against the 224 data plane, i.e., that forwarding matches what the routing protocols 225 determined as the path. 227 One way these tools can be used is to periodically ping a FEC to 228 ensure connectivity. If the ping fails, one can then initiate a 229 traceroute to determine where the fault lies. One can also 230 periodically traceroute FECs to verify that forwarding matches the 231 control plane; however, this places a greater burden on transit LSRs 232 and thus should be used with caution. 234 2.2. Motivations for LSP Ping for P2MP LSPs 236 As stated in [P2MP-OAM-REQ], MPLS has been extended to encompass 237 P2MP LSPs. As with P2P MPLS LSPs, the requirement to detect, handle 238 and diagnose control and data plane defects is critical. For 239 operators deploying services based on P2MP MPLS LSPs the detection 240 and specification of how to handle those defects is important because 241 such defects may affect the fundamentals of an MPLS network, but also 242 because they may impact service level specification commitments for 243 customers of their network. 245 P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish 246 multicast LSPs. These LSPs distribute data from a single source to 247 one or more destinations across the network according to the next 248 hops indicated by the routing protocols. Each LSP is identified by an 249 MPLS multicast FEC. 251 P2MP MPLS TE LSPs [P2MP-RSVP] may be viewed as MPLS tunnels with a 252 single ingress and multiple egresses. The tunnels, built on P2MP 253 LSPs, are explicitly routed through the network. There is no concept 254 or applicability of a FEC in the context of a P2MP MPLS TE LSP. 256 MPLS packets inserted at the ingress of a P2MP LSP are delivered 257 equally (barring faults) to all egresses. In consequence, the basic 258 idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an 259 intention to test that packets that enter (at the ingress) a 260 particular P2MP LSP actually end their MPLS path on the LSRs that are 261 the (intended) egresses for that LSP. The idea may be extended to 262 check selectively that such packets reach a specific egress. 264 The technique in this document makes this test by sending an LSP Ping 265 echo request message along the same data path as the MPLS packets. An 266 echo request also carries the identification of the P2MP MPLS LSP 267 (multicast LSP or P2MP TE LSP) that it is testing. The echo request 268 is forwarded just as any other packet using that LSP and so is 269 replicated at branch points of the LSP and should be delivered to all 270 egresses. In "ping" mode (basic connectivity check), the echo request 271 should reach the end of the path, at which point it is sent to the 272 control plane of the egress LSRs, which then verify that they are 273 indeed an egress (leaf) of the P2MP LSP. An echo response message is 274 sent by an egress to the ingress to confirm the successful receipt 275 (or announce the erroneous arrival) of the echo request. 277 In "traceroute" mode (fault isolation), the echo request is sent to 278 the control plane at each transit LSR, and the control plane checks 279 that it is indeed a transit LSR for this P2MP MPLS LSP. The transit 280 LSR also returns information on an echo response that helps verify 281 the control plane against the data plane. That is, the information 282 is used by the ingress to check that the data plane forwarding 283 matches what is signaled by the control plane. 285 P2MP MPLS LSPs may have many egresses, and it is not necessarily the 286 intention of the initiator of the ping or traceroute operation to 287 collect information about the connectivity or path to all egresses. 288 Indeed, in the event of pinging all egresses of a large P2MP MPLS 289 LSP, it might be expected that a large number of echo responses would 290 arrive at the ingress independently but at approximately the same 291 time. Under some circumstances this might cause congestion at or 292 around the ingress LSR. Therefore, the procedures described in this 293 document provide a procedure that allows the responders to randomly 294 delay (or jitter) their responses so that the chances of swamping the 295 ingress are reduced. 297 Further, the procedures in this document allow the initiator to limit 298 the scope of an LSP Ping echo request (ping or traceroute mode) to 299 one specific intended egress. 301 The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be 302 addressed by other mechanisms such as [MCAST-CV] that utilise the LSP 303 Ping procedures in this document to provide bootstrapping mechanisms 304 as described in Section 2.3. 306 LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure 307 connectivity to any or all of the egresses. If the ping fails, 308 the operator or an automated process can then initiate a traceroute 309 to determine where the fault is located within the network. A 310 traceroute may also be used periodically to verify that data plane 311 forwarding matches the control plane state; however, this places an 312 increased burden on transit LSRs and should be used infrequently and 313 with caution. 315 2.3 Bootstrapping other OAM Procedures using LSP Ping 317 [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to 318 bootstrap the Bidirectional Forwarding Detection (BFD) mechanism 319 [BFD] for use to track the liveliness of an MPLS LSP. In particular 320 BFD can be used to detect a data plane failure in the forwarding 321 path of an MPLS LSP. 323 Requirements for MPLS P2MP LSPs extend to hundreds or even thousands 324 of endpoints. If a protocol required explicit acknowledgments to 325 each probe for connectivity verification, the response load at the 326 root would be overwhelming. 328 A more scalable approach to monitoring P2MP LSP connectivity is 329 desribed in [MCAST-CV]. It relies on using the MPLS Echo 330 Request/Response messages of LSP Ping [RFC4379] to bootstrap the 331 monitoring mechanism in a manner similar to [MPLS-BFD]. The actual 332 monitoring is done using a separate process defined in [MCAST-CV]. 334 Note that while the approach described in [MCAST-CV] was developed in 335 response to the multicast scalability problem, it can be applied to 336 P2P LSPs as well. 338 3. Operation of LSP Ping for a P2MP LSP 340 This section describes how LSP Ping is applied to P2MP MPLS LSPs. 341 It covers the mechanisms and protocol fields applicable to both ping 342 mode and traceroute mode. It explains the responsibilities of the 343 initiator (ingress), transit LSRs and receivers (egresses). 345 3.1. Identifying the LSP Under Test 347 3.1.1. Identifying a P2MP MPLS TE LSP 349 [RFC4379] defines how an MPLS TE LSP under test may be identified in 350 an echo request. A Target FEC Stack TLV is used to carry either an 351 RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. 353 In order to identify the P2MP MPLS TE LSP under test, the echo 354 request message MUST carry a Target FEC Stack TLV, and this MUST 355 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 356 Session or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry 357 fields from the RSVP-TE P2MP Session and Sender-Template objects 358 [P2MP-RSVP] and so provide sufficient information to uniquely 359 identify the LSP. 361 The new sub-TLVs are assigned sub-type identifiers as follows, and 362 are described in the following sections. 364 Sub-Type # Length Value Field 365 ---------- ------ ----------- 366 TBD 20 RSVP P2MP IPv4 Session 367 TBD 56 RSVP P2MP IPv6 Session 369 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 371 The format of the RSVP P2MP IPv4 Session Sub-TLV value field is 372 specified in the following figure. The value fields are taken from 373 the definitions of the P2MP IPv4 LSP Session Object, and the P2MP 374 IPv4 Sender-Template Object in [P2MP-RSVP]. Note that the Sub-Group 375 ID of the Sender-Template is not required. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | P2MP ID | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Must Be Zero | Tunnel ID | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Extended Tunnel ID | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | IPv4 tunnel sender address | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Must Be Zero | LSP ID | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV 393 The format of the RSVP P2MP IPv6 Session Sub-TLV value field is 394 specified in the following figure. The value fields are taken from 395 the definitions of the P2MP IPv6 LSP Session Object, and the 396 P2MP IPv6 Sender-Template Object in [P2MP-RSVP]. Note that the 397 Sub-Group ID of the Sender-Template is not required. 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 | P2MP ID | 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Must Be Zero | Tunnel ID | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 | Extended Tunnel ID | 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 | IPv6 tunnel sender address | 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Must Be Zero | LSP ID | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 3.1.2. Identifying a Multicast LDP LSP 421 [RFC4379] defines how a P2P LDP LSP under test may be identified in 422 an echo request. A Target FEC Stack TLV is used to carry one or more 423 Sub-TLVs (for example, an IPv4 Prefix FEC Sub-TLV) that identify the 424 LSP. 426 In order to identify a multicast LDP LSP under test, the echo request 427 message MUST carry a Target FEC Stack TLV, and this MUST carry 428 exactly one new sub-TLVs: the Multicast LDP FEC Stack Sub-TLV. This 429 Sub-TLVs fields from the multicast LDP messages [P2MP-LDP] and so 430 provides sufficient information to uniquely identify the LSP. 432 The new sub-TLV is assigned a sub-type identifier as follows, and 433 is described in the following sections. 435 Sub-Type # Length Value Field 436 ---------- ------ ----------- 437 TBD Variable Multicast LDP FEC Stack 439 3.1.2.1. Multicast LDP FEC Stack Sub-TLV 441 The format of the Multicast LDP FEC Stack Sub-TLV is shown below. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Address Family | Address Length| Root LSR Addr | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 ~ Root LSR Address (Cont.) ~ 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Opaque Length | Opaque Value ... | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 454 ~ ~ 455 | | 456 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Address Family 462 A two octet quantity containing a value from ADDRESS FAMILY 463 NUMBERS in [IANA-PORT] that encodes the address family for the 464 Root LSR Address. 466 Address Length 468 The length of the Root LSR Address in octets. 470 Root LSR Address 472 An address of the LSR at the root of the P2MP LSP encoded 473 according to the Address Family field. 475 Opaque Length 477 The length of the Opaque Value, in octets. 479 Opaque Value 481 An opaque value elements of which uniquely identifies the P2MP LSP 482 in the context of the Root LSR. 484 If the Address Family is IPv4, the Address Length MUST be 4. If the 485 Address Family is IPv6, the Address Length MUST be 16. No other 486 Address Family values are defined at present. 488 3.2. Ping Mode Operation 490 3.2.1. Controlling Responses to LSP Pings 492 As described in Section 2.2, it may be desirable to restrict the 493 operation of LSP Ping to a single egress. Since echo requests are 494 forwarded through the data plane without interception by the control 495 plane (compare with traceroute mode), there is no facility to limit 496 the propagation of echo requests, and they will automatically be 497 forwarded to all (reachable) egresses. 499 However, the intended egress under test can be identified by the 500 inclusion of a P2MP Egress Identifier TLV containing an IPv4 P2MP 501 Egress Identifier sub-TLV or an IPv6 P2MP Egress Identifier sub-TLV. 502 In this version of the protocol the P2MP Egress Identifier TLV SHOULD 503 contain precisely one sub-TLV. If the TLV contains no sub-TLVs it 504 MUST be processed as if it were absent. If the TLV contains more than 505 one sub-TLV, the first MUST be precessed as described in this 506 document and subsequent sub-TLVs MUST be ignored. 508 An initiator may indicate that it wishes all egresses to respond to 509 an echo request by omitting the P2MP Egress Identifier TLV. 511 Note that the ingress of a multicast LDP LSP will not know the 512 identities of the egresses of the LSP except by some external means 513 such as running P2MP LSP Ping to all egresses. 515 3.2.2. Ping Mode Egress Procedures 517 An egress LSR is RECOMMENDED to rate limit its receipt of echo 518 request messages as described in [RFC4379]. After rate limiting, an 519 egress LSR that receives an echo request carrying an RSVP P2MP IPv4 520 Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast 521 LDP FEC Stack Sub-TLV MUST determine whether it is an intended egress 522 of the P2MP LSP in question by checking with the control plane. If it 523 is not supposed to be an egress, it MUST respond according to the 524 setting of the Response Type field in the echo message following the 525 rules defined in [RFC4379]. 527 If the egress LSR that receives an echo request is an intended egress 528 of the P2MP LSP, the LSR MUST check to see whether it is an intended 529 Ping recipient. If a P2MP Egress Identifier TLV is present and 530 contains an address that indicates any address that is local to the 531 LSR, the LSR MUST respond according to the setting of the Response 532 Type field in the echo message following the rules defined in 533 [RFC4379]. If the P2MP Egress Identifier TLV is present, but does 534 not identify the egress LSR, it MUST NOT respond to the echo request. 535 If the P2MP Egress Identifier TLV is not present, but the egress LSR 536 that received the echo request is an intended egress of the LSP, the 537 LSR MUST respond according to the setting of the Response Type field 538 in the echo message following the rules defined in [RFC4379]. 540 3.2.3. Jittered Responses 542 The initiator (ingress) of a ping request MAY request the responding 543 egress to introduce a random delay (or jitter) before sending the 544 response. The randomness of the delay allows the responses from 545 multiple egresses to be spread over a time period. Thus this 546 technique is particularly relevant when the entire LSP tree is being 547 pinged since it helps prevent the ingress (or nearby routers) from 548 being swamped by responses, or from discarding responses due to rate 549 limits that have been applied. 551 It is desirable for the ingress to be able to control the bounds 552 within which the egress delays the response. If the tree size is 553 small only a small amount of jitter is required, but if the tree is 554 large greater jitter is needed. The ingress informs the egresses of 555 the jitter bound by supplying a value in a new TLV (the Echo Jitter 556 TLV) carried on the Echo request message. If this TLV is present, 557 the responding egress MUST delay sending a response for a random 558 amount of time between zero seconds and the value indicated in the 559 TLV. If the TLV is absent, the responding egress SHOULD NOT introduce 560 any additional delay in responding to the echo request. 562 LSP ping SHOULD NOT be used to attempt to measure the round-trip 563 time for data delivery. This is because the LSPs are unidirectional, 564 and the echo response is often sent back through the control plane. 565 The timestamp fields in the echo request/response MAY be used to 566 deduce some information about delivery times and particularly the 567 variance in delivery times. 569 The use of echo jittering does not change the processes for gaining 570 information, but note that the responding egress MUST set the value 571 in the Timestamp Received fields before applying any delay. 573 It is RECOMMENDED that echo response jittering is not used except in 574 the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo 575 request for any other type of TLV, the responding egress MAY apply 576 the jitter behavior described here. 578 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs 580 A new TLV is defined for inclusion in the Echo request message. 582 The P2MP Egress Identifier TLV is assigned the TLV type value TBD and 583 is encoded as follows. 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 |Type = TBD (P2MP Egress ID TLV)| Length = Variable | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 ~ Sub-TLVs ~ 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Sub-TLVs: 595 Zero, one or more sub-TLVs as defined below. 596 If no sub-TLVs are present, the TLV MUST be processed as if it 597 were absent. 598 If more than one sub-TLV is present the first MUST be processed 599 as described in this document, and subsequent sub-TLVs MUST be 600 ignored. 602 The P2MP Egress Identifier TLV only has meaning on an echo request 603 message. If present on an echo response message, it SHOULD be 604 ignored. 606 Two Sub-TLVs are defined for inclusion in the P2MP Egress Identifier 607 TLV carried on the echo request message. These are: 609 Sub-Type # Length Value Field 610 ---------- ------ ----------- 611 1 4 IPv4 P2MP Egress Identifier 612 2 16 IPv6 P2MP Egress Identifier 614 The value of an IPv4 P2MP Egress Identifier consists of four octets 615 of an IPv4 address. The IPv4 address is in network byte order. 617 The value of an IPv6 P2MP Egress Identifier consists of sixteen 618 octets of an IPv6 address. The IPv6 address is in network byte order. 620 3.2.5. Echo Jitter TLV 622 A new TLV is defined for inclusion in the Echo request message. 624 The Echo Jitter TLV is assigned the TLV type value TBD and is encoded 625 as follows. 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Type = TBD (Jitter TLV) | Length = 4 | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Jitter time | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Jitter time: 636 This field specifies the upper bound of the jitter period that 637 should be applied by a responding egress to determine how long 638 to wait before sending an echo response. An egress SHOULD wait 639 a random amount of time between zero seconds and the value 640 specified in this field. 642 Jitter time is specified in milliseconds. 644 The Echo Jitter TLV only has meaning on an echo request message. If 645 present on an echo response message, it SHOULD be ignored. 647 3.3. Traceroute Mode Operation 649 The traceroute mode of operation is described in [RFC4379]. Like 650 other traceroute operations, it relies on the expiration of the TTL 651 of the packet that carries the echo request. Echo requests may 652 include a Downstream Mapping TLV and when the TTL expires the echo 653 request is passed to the control plane on the transit LSR which 654 responds according to the Response Type in the message. A responding 655 LSR fills in the fields of the Downstream Mapping TLV to indicate the 656 downstream interfaces and labels used by the reported LSP from the 657 responding LSR. In this way, by successively sending out echo 658 requests with increasing TTLs, the ingress may gain a picture of the 659 path and resources used by an LSP up to the point of failure when no 660 response is received, or an error response is generated by an LSR 661 where the control plane does not expect to be handling the LSP. 663 This mode of operation is equally applicable to P2MP MPLS TE LSPs 664 as described in the following sections. 666 The traceroute mode can be applied to all destinations of the P2MP 667 tree just as in the ping mode. In the case of P2MP MPLS TE LSPs, the 668 traceroute mode can also be applied to individual destinations 669 identified by the presence of a P2MP Egress Identifier TLV. However, 670 since a transit LSR of a multicast LDP LSP is unable to determine 671 whether it lies on the path to any one destination, the traceroute 672 mode limited to a single egress of such an LSP MUST NOT be used. 674 In the absence of a P2MP Egress Identifier TLV, the echo request is 675 asking for traceroute information applicable to all egresses. 677 The echo response jitter technique described for the ping mode is 678 equally applicable to the traceroute mode and is not additionally 679 described in the procedures below. 681 3.3.1. Traceroute Responses at Non-Branch Nodes 683 When the TTL for the MPLS packet carrying an echo request expires the 684 packet MUST be passed to the control plane as specified in [RFC4379]. 686 If the LSP under test is a multicast LDP LSP and if the echo request 687 carries a P2MP Egress Identifier TLV the LSR MUST treat the echo 688 request as malformed and MUST process it according to the rules 689 specified in [RFC4379]. 691 Otherwise, the LSR MUST NOT return an echo response unless the 692 responding LSR lies on the path of the P2MP LSP to the egress 693 identified by the P2MP Egress Identifier TLV carried on the request, 694 or if no such Sub-TLV is present. 696 If sent, the echo response MUST identifiy the next hop of the path of 697 the LSP in the data plane by including a Downstream Mapping TLV as 698 described in [RFC4379]. 700 3.3.1.1. Correlating Traceroute Responses 702 When traceroute is being simultaneously applied to multiple egresses, 703 it is important that the ingress should be able to correlate the echo 704 responses with the branches in the P2MP tree. Without this 705 information the ingress will be unable to determine the correct 706 ordering of transit nodes. One possibility is for the ingress to poll 707 the path to each egress in turn, but this may be inefficient, 708 undesirable, or (in the case of multicast LDP LSPs) illegal. 710 The Downstream Mapping TLV that MUST be included in the echo response 711 indicates the next hop from each responding LSR, and this information 712 supplied by a non-branch LSR can be pieced together by the ingress to 713 reconstruct the P2MP tree although it may be necessary to refer to 714 the routing information distributed by the IGP to correlate next hop 715 addresses and LSR reporting addresses in subsequent echo responses. 717 In order to facilitate more easy correlation of echo responses, the 718 Downstream Mapping TLV can also contain Multipath Information as 719 described in [RFC4379] to identify to which egress/egresses the echo 720 response applies, and indicates. This information: 722 - MUST NOT be present for multicast LDP LSPs 724 - SHOULD be present for P2MP MPLS TE LSPs when the echo request 725 applies to all egresses 727 - is RECCOMMENDED to be present for P2MP MPLS TE LSPs when the echo 728 request is limited to a single egress. 730 The format of the information in the Downstream Mapping TLV for 731 P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6. 733 3.3.2. Traceroute Responses at Branch Nodes 735 A branch node may need to identify more than one downstream interface 736 in a traceroute echo response if some of the egresses that are being 737 traced lie on different branches. This will always be the case for 738 any branch node if all egresses are being traced. 740 [RFC4379] describes how multiple Downstream Mapping TLVs should be 741 included in an echo response, each identifying exactly one downstream 742 interface that is applicable to the LSP. 744 A branch node MUST follow the procedures described in Section 3.3.1 745 to determine whether it should respond to an echo request. The branch 746 node MUST add a Downstream Mapping TLV to the echo response for each 747 outgoing branch that it reports, but it MUST NOT report branches that 748 do not lie on the path to one of the destinations being traced. Thus 749 a branch node may sometimes only need to respond with a single 750 Downstream Mapping TLV, for example, consider the case where the 751 traceroute is directed to only a single egress node. Therefore, 752 the presence of only one Downstream Mapping TLV in an echo response 753 does not guarantee that the reporting LSR is not a branch node. 755 To report on the fact that an LSR is a branch node for the P2MP MPLS 756 LSP a new B-flag is added to the Downstream Mapping TLV. The flag is 757 set to zero to indicate that the reporting LSR is not a branch for 758 this LSP, and is set to one to indicate that it is a branch. The flag 759 is placed in the fourth byte of the TLV that was previously reserved. 761 The format of the information in the Downstream Mapping TLV for 762 P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6. 764 3.3.2.1. Correlating Traceroute Responses 766 Just as with non-branches, it is important that the echo responses 767 from branch nodes provide correlation information that will allow the 768 ingress to work out to which branch of the LSP the response applies. 770 The P2MP tree can be determined by the ingress using the identity of 771 the reporting node and the next hop information from the previous 772 echo response, just as with echo responses from non-branch nodes. 774 As with non-branch nodes, in order to facilitate more easy 775 correlation of echo responses, the Downstream Mapping TLV can also 776 contain Multipath Information as described in [RFC4379] to identify 777 to which egress/egresses the echo response applies, and indicates. 778 This information: 780 - MUST NOT be present for multicast LDP LSPs 781 - SHOULD be present for P2MP MPLS TE LSPs when the echo request 782 applies to all egresses 784 - is RECCOMMENDED to be present for P2MP MPLS TE LSPs when the echo 785 request is limited to a single egress. 787 The format of the information in the Downstream Mapping TLV for 788 P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6. 790 3.3.3. Traceroute Responses at Bud Nodes 792 Some nodes on a P2MP MPLS LSP may be egresses, but also have 793 downstream LSRs. Such LSRs are known as bud nodes [RFC4461]. 795 A bud node MUST respond to a traceroute echo request just as a branch 796 node would, but it MUST also indicates to the ingress that it is an 797 egress in its own right. This is achieved through the use of a new 798 E-flag in the Downstream Mapping TLV that indicates that the 799 reporting LSR is not a bud for this LSP (cleared to zero) or is a bud 800 (set to one). A normal egress MUST NOT set this flag. 802 The flag is placed in the fourth byte of the TLV that was previously 803 reserved. 805 3.3.4. Non-Response to Traceroute Echo Requests 807 The nature of P2MP MPLS TE LSPs in the data plane means that 808 traceroute echo requests may be delivered to the control plane of 809 LSRs that must not reply to the request because, although they lie 810 on the P2MP tree, they do not lie on the path to the egress that is 811 being traced. 813 Thus, an LSR on a P2MP MPLS LSP MUST NOT respond to an echo request 814 when the TTL has expired if any of the following applies: 816 - The Reply Type indicates that no reply is required 818 - There is a P2MP Egress Identifier TLV present on the echo request 819 (which means that the LSP is a P2MP MPLS TE LSP), but the address 820 does not identify an egress that is reached through this LSR for 821 this particular P2MP MPLS LSP. 823 3.3.5. Modifications to the Downstream Mapping TLV 825 A new B-flag is added to the Downstream Mapping TLV to indicate that 826 the reporting LSR is not a branch for this LSP (cleared to zero) or 827 is a branch (set to one). 829 A new E-flag is added to the Downstream Mapping TLV to indicate that 830 the reporting LSR is not a bud node for this LSP (cleared to zero) or 831 is a bud node (set to one). 833 The flags are placed in the fourth byte of the TLV that was 834 previously reserved as shown below. All other fields are unchanged 835 from their definitions in [RFC4379] except for the additional 836 information that can be carried in the Multipath Information (see 837 Section 3.3.6). 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | MTU | Address Type | Reserved |E|B| 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Downstream IP Address (4 or 16 octets) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Downstream Interface Address (4 or 16 octets) | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Hash Key Type | Depth Limit | Multipath Length | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 . . 851 . (Multipath Information) . 852 . . 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Downstream Label | Protocol | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 . . 857 . . 858 . . 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Downstream Label | Protocol | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 3.3.6. Additions to Downstream Mapping Multipath Information 865 A new value for the Multipath Type is defined to indicate that the 866 reported Multipath Information applies to a P2MP MPLS TE LSP and 867 may contain a list of egress identifiers that indicate the egress 868 nodes that can be reached through the reported interface. This 869 Multipath Type MUST NOT be used for a multicast LDP LSP. 871 Type # Address Type Multipath Information 872 --- ---------------- --------------------- 873 TBD P2MP egresses List of P2MP egresses 875 Note that a list of egresses may include IPv4 and IPv6 identifiers 876 since these may be mixed in the P2MP MPLS TE LSP. 878 The Multipath Length field continues to identify the length of the 879 Multipath Information just as in [RFC4379] (that is, not including 880 the downstream labels), and the downstream label (or potential 881 stack thereof) is also handled just as in [RFC4379]. The format 882 of the Multipath Information for a Multipath Type of P2MP Egresses 883 is as follows. 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Address Type | Egress Address (4 or 16 octets) | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | (continued) | : 891 +-+-+-+-+-+-+-+-+ : 892 : Further Address Types and Egress Addresses : 893 : : 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Address Type 898 This field indicates whether the egress address that follows is 899 an IPv4 or IPv6 address, and so implicitly encodes the length of 900 the address. 902 Two values are defined and mirror the values used in the Address 903 Type field of the Downstream Mapping TLV itself. 905 Type # Address Type 906 ------ ------------ 907 1 IPv4 908 3 IPv6 910 Egress Address 912 An egress of this P2MP MPLS TE LSP that is reached through the 913 interface indicated by the Downstream Mapping TLV and for which 914 the traceroute echo request was enquiring. 916 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms 918 Bootstrapping of other OAM procedures can be achieved using the 919 MPLS Echo Request/Response messages. The LSP(s) under test are 920 identified using the RSVP P2MP IPv4 or IPv6 Session Sub-TLVs 921 (see Section 3.1.1) or the Multicast LDP FEC Stack Sub-TLV 922 (see Section 3.1.2). 924 Other Sub-TLVs may be defined in other specifications to indicate 925 the OAM procedures being bootstrapped, and to describe the bootstrap 926 parameters. Further details of the bootstrapping processes and the 927 bootstrapped OAM processes are described in other documents. For 928 example, see [MPLS-BFD] and [MCAST-CV]. 930 5. Non-compliant Routers 932 If an egress for a P2MP LSP does not support MPLS LSP ping, then no 933 reply will be sent, resulting in a "false negative" result. There is 934 no protection for this situation, and operators may wish to ensure 935 that end points for P2MP LSPs are all equally capable of supporting 936 this function. Alternatively, the traceroute option can be used to 937 verify the LSP nearly all the way to the egress, leaving the final 938 hop to be verified manually. 940 If, in "traceroute" mode, a transit LSR does not support LSP ping, 941 then no reply will be forthcoming from that LSR for some TTL, say n. 942 The LSR originating the echo request SHOULD continue to send echo 943 requests with TTL=n+1, n+2, ..., n+k in the hope that some transit 944 LSR further downstream may support MPLS echo requests and reply. In 945 such a case, the echo request for TTL > n MUST NOT have Downstream 946 Mapping TLVs, until a reply is received with a Downstream Mapping. 948 Note that the settings of the new bit flags in the Downstream Mapping 949 TLV are such that a legacy LSR would return them with value zero 950 which most closely matches the likely default behavior of a legacy 951 LSR. 953 6. OAM Considerations 955 The procedures in this document provide OAM functions for P2MP MPLS 956 LSPs and may be used to enable bootstrapping of other OAM procedures. 958 In order to be fully operational several considerations must be made. 960 - Scaling concerns dictate that only cautious use of LSP Ping should 961 be made. In particular, sending an LSP Ping to all egresses of a 962 P2MP MPLS LSP could result in congestion at or near the ingress 963 when the responses arrive. 965 Further, incautious use of timers to generate LSP Ping echo 966 requests either in ping mode or especially in traceroute may lead 967 to significant degradation of network performance. 969 - Management interfaces should allow an operator full control over 970 the operation of LSP Ping. In particular, it SHOULD provide the 971 ability to limit the scope of an LSP Ping echo request for a P2MP 972 MPLS LSP to a single egress. 974 Such an interface SHOULD also provide the ability to disable all 975 active LSP Ping operations to provide a quick escape if the network 976 becomes congested. 978 - A MIB module is required for the control and management of LSP Ping 979 operations, and to enable the reported information to be inspected. 981 There is no reason to believe this should not be a simple extension 982 of the LSP Ping MIB module used for P2P LSPs. 984 7. IANA Considerations 986 7.1. New Sub-TLV Types 988 Three new Sub-TLV types are defined for inclusion within the LSP Ping 989 [RFC4379] Target FEC Stack TLV (TLV type 1). 991 IANA is requested to assign sub-type values to the following 992 Sub-TLVs from the Multiprotocol Label Switching Architecture (MPLS) 993 Label Switched Paths (LSPs) Parameters - TLVs registry. 995 RSVP P2MP IPv4 Session (see Section 3.1.1) 996 RSVP P2MP IPv6 Session (see Section 3.1.1) 997 Multicast LDP FEC Stack (see Section 3.1.2) 999 7.2. New Multipath Type 1001 Section 3.3 of [RFC4379] defines a set of values for the LSP Ping 1002 Multipath Type. These values are currently not tracked by IANA. 1004 A new value for the LSP Ping Multipath Type is defined in Section 1005 3.3.6 of this document to indicate that the reported Multipath 1006 Information applies to a P2MP MPLS TE LSP. 1008 IANA is requested to create a new registry as follows: 1010 Multiprotocol Label Switching Architecture (MPLS) Label Switched 1011 Paths (LSPs) - Multipath Types 1013 Key Type Multipath Information 1014 --- ---------------- --------------------- 1015 0 no multipath Empty (Multipath Length = 0) [RFC4379] 1016 2 IP address IP addresses [RFC4379] 1017 4 IP address range low/high address pairs [RFC4379] 1018 8 Bit-masked IP IP address prefix and bit mask [RFC4379] 1019 address set 1020 9 Bit-masked label set Label prefix and bit mask [RFC4379] 1021 xx P2MP egress IP List of P2MP egresses [thisDoc] 1022 addresses 1024 A suggested value of xx is TBD by the MPLS Working Group. 1026 New values from this registry are to be assigned only by Standards 1027 Action. 1029 7.3. New TLVs 1031 Two new LSP Ping TLV types are defined for inclusion in LSP Ping 1032 messages. 1034 IANA is reuqested to assign a new value from the Multiprotocol Label 1035 Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters 1036 - TLVs registry as follows using a Standards Action value. 1038 P2MP Egress Identifier TLV (see Section 3.2.4) 1039 Two sub-TLVs are defined 1040 - Type 1: IPv4 P2MP Egress Identifier (see Section 3.2.4) 1041 - Type 2: IPv6 P2MP Egress Identifier (see Section 3.2.4) 1043 Echo Jitter TLV (see Section 3.2.5) 1045 8. Security Considerations 1047 This document does not introduce security concerns over and above 1048 those described in [RFC4379]. Note that because of the scalability 1049 implications of many egresses to P2MP MPLS LSPs, there is a 1050 stronger concern to regulate the LSP Ping traffic passed to the 1051 control plane by the use of a rate limiter applied to the LSP Ping 1052 well-known UDP port. Note that this rate limiting might lead to 1053 false positives. 1055 9. Acknowledgements 1057 The authors would like to acknowledge the authors of [RFC4379] for 1058 their work which is substantially re-used in this document. Also 1059 thanks to the members of the MBONED working group for their review 1060 of this material, to Daniel King for his review, and to Yakov Rekhter 1061 for useful discussions. 1063 The authors would like to thank Vanson Lim, Danny Prairie and Reshad 1064 Rahman for their comments and suggestions. 1066 10. Intellectual Property Considerations 1068 The IETF takes no position regarding the validity or scope of any 1069 Intellectual Property Rights or other rights that might be claimed to 1070 pertain to the implementation or use of the technology described in 1071 this document or the extent to which any license under such rights 1072 might or might not be available; nor does it represent that it has 1073 made any independent effort to identify any such rights. Information 1074 on the procedures with respect to rights in RFC documents can be 1075 found in BCP 78 and BCP 79. 1077 Copies of IPR disclosures made to the IETF Secretariat and any 1078 assurances of licenses to be made available, or the result of an 1079 attempt made to obtain a general license or permission for the use of 1080 such proprietary rights by implementers or users of this 1081 specification can be obtained from the IETF on-line IPR repository at 1082 http://www.ietf.org/ipr. 1084 The IETF invites any interested party to bring to its attention any 1085 copyrights, patents or patent applications, or other proprietary 1086 rights that may cover technology that may be required to implement 1087 this standard. Please address the information to the IETF at 1088 ietf-ipr@ietf.org. 1090 11. Normative References 1092 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1093 Requirement Levels", BCP 14, RFC 2119, March 1997. 1095 [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol 1096 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1097 February 2006. 1099 [P2MP-OAM-REQ] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1100 "OAM Requirements for Point-to-Multipoint MPLS Networks", 1101 draft-ietf-mpls-p2mp-oam-reqs, work in progress. 1103 [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org 1105 12. Informative References 1107 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 1109 [RFC4461] Yasukawa, S., "Signaling Requirements for Point to 1110 Multipoint Traffic Engineered Multiprotocol Label 1111 Switching (MPLS) Label Switched Paths (LSPs)", 1112 RFC 4461, April 2006. 1114 [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to 1115 Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, 1116 work in progress. 1118 [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for 1119 point-to-multipoint extensions to the Label Distribution 1120 Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. 1122 [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol 1123 Extensions for Point-to-Multipoint and 1124 Multipoint-to-Multipoint Label Switched Paths", 1125 draft-ietf-mpls-ldp-p2mp, work in progress. 1127 [MCAST-CV] Swallow, G., and Nadeau, T., "Connectivity Verification 1128 for Multicast Label Switched Paths", 1129 draft-swallow-mpls-mcast-cv, work in progress. 1131 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 1132 Detection", draft-ietf-bfd-base, work in progress. 1134 [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., 1135 "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in 1136 progress. 1138 13. Authors' Addresses 1140 Seisho Yasukawa 1141 NTT Corporation 1142 (R&D Strategy Department) 1143 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 1144 Phone: +81 3 5205 5341 1145 Email: s.yasukawa@hco.ntt.co.jp 1147 Adrian Farrel 1148 Old Dog Consulting 1149 EMail: adrian@olddog.co.uk 1151 Zafar Ali 1152 Cisco Systems Inc. 1153 2000 Innovation Drive 1154 Kanata, ON, K2K 3E8, Canada. 1155 Phone: 613-889-6158 1156 Email: zali@cisco.com 1158 Bill Fenner 1159 AT&T Labs -- Research 1160 75 Willow Rd. 1161 Menlo Park, CA 94025 1162 United States 1163 Email: fenner@research.att.com 1165 George Swallow 1166 Cisco Systems, Inc. 1167 1414 Massachusetts Ave 1168 Boxborough, MA 01719 1169 Email: swallow@cisco.com 1171 Thomas D. Nadeau 1172 Cisco Systems, Inc. 1173 1414 Massachusetts Ave 1174 Boxborough, MA 01719 1175 Email: tnadeau@cisco.com 1177 14. Full Copyright Statement 1179 Copyright (C) The Internet Society (2006). This document is subject 1180 to the rights, licenses and restrictions contained in BCP 78, and 1181 except as set forth therein, the authors retain all their rights. 1183 This document and the information contained herein are provided on an 1184 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1185 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1186 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1187 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1188 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1189 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.