idnits 2.17.1 draft-ietf-mpls-proxy-lsp-ping-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2015) is 3320 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) -- Looks like a reference, but probably isn't: '1' on line 831 -- Looks like a reference, but probably isn't: '255' on line 831 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Swallow 3 Internet-Draft V. Lim 4 Intended status: Standards Track Cisco Systems 5 Expires: September 26, 2015 S. Aldrin 6 Huawei Technologies 7 March 25, 2015 9 Proxy MPLS Echo Request 10 draft-ietf-mpls-proxy-lsp-ping-05 12 Abstract 14 This document defines a means of remotely initiating Multiprotocol 15 Label Switched Protocol Pings on Label Switched Paths. An MPLS Proxy 16 Ping Request is sent to any Label Switching Router along a Label 17 Switched Path. The primary motivations for this facility are first to 18 limit the number of messages and related processing when using LSP 19 Ping in large Point-to-Multipoint LSPs, and second to enable leaf to 20 leaf/root tracing. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on September 26, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Proxy Ping Overview . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Initiating Proxy Ping . . . . . . . . . . . . . . . . . . 6 67 2.2. Handling at Proxy LSR . . . . . . . . . . . . . . . . . . 6 68 2.2.1. Backward Compatibility . . . . . . . . . . . . . . . . 6 69 3. Proxy MPLS Echo Request / Reply Procedures . . . . . . . . . . 7 70 3.1. Procedures for the initiator . . . . . . . . . . . . . . . 7 71 3.2. Procedures for the Proxy LSR . . . . . . . . . . . . . . . 8 72 3.2.1. Proxy LSR Handling when it is egress for FEC . . . . . 10 73 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply . . 11 74 3.2.3. Sending an MPLS Proxy Ping Reply . . . . . . . . . . . 12 75 3.2.4. Sending the MPLS Echo Requests . . . . . . . . . . . . 12 76 3.2.4.1. Forming the base MPLS Echo Request . . . . . . . . 12 77 3.2.4.2. Per interface sending procedures . . . . . . . . . 14 78 4. Proxy Ping Request / Reply Messages . . . . . . . . . . . . . 14 79 4.1. Proxy Ping Request / Reply Message formats . . . . . . . . 14 80 4.2. Proxy Ping Request Message contents . . . . . . . . . . . 15 81 4.3. Proxy Ping Reply Message Contents . . . . . . . . . . . . 15 82 5. TLV formats . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 5.1. Proxy Echo Parameters TLV . . . . . . . . . . . . . . . . 16 84 5.1.1. Next Hop sub-TLV . . . . . . . . . . . . . . . . . . . 19 85 5.2. Reply-to Address TLV . . . . . . . . . . . . . . . . . . . 20 86 5.3. Upstream Neighbor Address TLV . . . . . . . . . . . . . . 20 87 5.4. Downstream Neighbor Address TLV . . . . . . . . . . . . . 21 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 91 8.1. Proxy Echo Parameters Sub-TLVs . . . . . . . . . . . . . . 23 92 8.2. Downstream Address Mapping Registry [pending IANA 93 assignment] . . . . . . . . . . . . . . . . . . . . . . . 24 94 8.3. Next Hop Sub-TLV Address Type Registry . . . . . . . . . . 24 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 This document is motivated by two broad issues in connection with 103 diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). 104 The first is scalability due to the automatic replication of 105 Multiprotocol Label Switching (MPLS) Echo Request Messages as they 106 proceed down the tree. The second, which is primarily motivated by 107 Label Distribution Protocol based Point-to-Multipoint (P2MP) and 108 Multipoint-to-Multipoint (MP2MP) Label Switched Paths [RFC6388], is 109 the ability to trace a sub-LSP from leaf node to root node. 111 When tracing from a source to a particular leaf in a P2MP or MP2MP 112 tree, nodes not along that path will need to process MPLS Echo 113 Request messages that are received. The number of MPLS Echo Replies 114 sent in response to an MPLS Echo Request quickly multiplies, as the 115 Label Switching Routers (LSRs), which are part of the tree but not 116 along the path of the trace could be responding to the received MPLS 117 Echo Request as well. This could also overwhelm the source to process 118 all the MPLS Echo Reply messages it receives. It is anticipated that 119 many of the applications for P2MP/MP2MP tunnels will require OAM that 120 is both rigorous and scalable. 122 Suppose one wishes to trace a P2MP LSP to localize a fault which is 123 affecting one egress or a set of egresses. Suppose one follows the 124 normal procedure for tracing - namely repeatedly pinging from the 125 root, incrementing the Time to Live (TTL) by one after each three or 126 so pings. Such a procedure has the potential for producing a large 127 amount of processing at the P2MP-LSP midpoints and egresses. It also 128 could produce an unwieldy number of replies back to the root. 130 One alternative would be to begin sending pings from points at or 131 near the affected egress(es) and then working backwards toward the 132 root. The TTL could be held constant, say two, limiting the number of 133 responses to the number of next-next-hops of the point where a ping 134 is initiated. 136 In the case of Resource Reservation Protocol-Traffic Engineering 137 (RSVP-TE), all setup is initiated from the root of the tree. Thus, 138 the root of the tree has knowledge of both all the leaf nodes and 139 usually the topology of the entire tree. Thus the above alternative 140 can easily be initiated by the root node. 142 In [RFC6388] the situation is quite different. Leaf nodes initiate 143 connectivity to the tree, which is granted by the first node toward 144 the root that is part of the tree. The root node may only be aware of 145 the immediately adjacent (downstream) nodes of the tree. Initially 146 the leaf node only has knowledge of the (upstream) node to which it 147 is immediately adjacent. However this is sufficient information to 148 initiate a trace. First the above procedure is applied by asking that 149 node to ping across the final link. That is, a message is sent from 150 the leaf to the upstream node requesting it to send an MPLS Echo 151 Request for the Forward Equivalence Class (FEC) of the tree in 152 question on said link. The leaf node also requests the identity of 153 the upstream neighbor's upstream neighbor for that FEC. With this 154 information, the procedure can iteratively be applied until the fault 155 is localized or the root node is reached. In all cases, the TTL for 156 the request need only be at most 2. Thus the processing load of each 157 request is small, since only a limited number of nodes will receive 158 the request. 160 This document defines protocol extensions to MPLS ping [RFC4379] to 161 allow a third party to remotely cause an MPLS Echo Request message to 162 be sent down an LSP or part of an LSP. The procedure described in the 163 paragraphs above does require that the initiator know the previous- 164 hop node to the one which was pinged on the prior iteration. This 165 information is readily available in [RFC4875]. This document also 166 provides a means for obtaining this information for [RFC6388]. 168 While the motivation for this document came from multicast scaling 169 concerns, it's applicability may be wider. The procedures presented 170 in this document are applicable to all LSP ping FEC types where the 171 MPLS Echo Request/Reply are IP encapsulated and the MPLS Echo Reply 172 can sent out of band of the LSP over IP. Remote pinging of LSPs that 173 involve the use of in-band control channels is beyond the scope of 174 this document. 176 Other uses of this facility are beyond the scope of this document. In 177 particular, the procedures defined in this document only allow 178 testing of a FEC stack consisting of a single FEC. The procedures 179 also do not allow the initiator to specify the label assigned to that 180 FEC, nor does it allow the initiator to cause any additional labels 181 to be added to the label stack of the actual MPLS Echo Request 182 message. 184 1.1. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 The term "Must Be Zero" (MBZ) is used in TLV descriptions for 191 reserved fields. These fields MUST be set to zero when sent and 192 ignored on receipt. 194 Based on context the terms leaf and egress are used interchangeably. 195 Egress is used where consistency with[RFC4379] was deemed 196 appropriate. Receiver is used in the context of receiving protocol 197 messages. 199 1.2. Terminology 201 Term Definition 202 ----- ------------------------------------------- 203 LSP Label Switched Path 204 LSR Label Switching Router 205 mLDP Multipoint LDP 206 MP2MP Multipoint to Multipoint 207 MTU Maximum Transmission Unit 208 P2MP Point to Multipoint 209 TTL Time to Live 211 2. Proxy Ping Overview 213 This document defines a protocol interaction between a first LSR, an 214 LSR which is part of an LSP, to allow the first LSR to request that 215 the second LSR initiate an LSP ping for the LSP on the first LSR's 216 behalf. Since the second LSR sends the LSP Ping on behalf of the 217 first LSR, it does not maintain state to be able to handle the 218 corresponding LSP Ping response. Instead the responder to the LSP 219 ping sends the LSP Ping response to either the first LSR or another 220 LSR configured to handle it. Two new LSP Ping messages are defined 221 for remote pinging: the MPLS Proxy Ping Request and the MPLS Proxy 222 Ping Reply. 224 A remote ping operation on a P2MP LSP generally involves at least 225 three LSRs; in some scenarios none of these are the ingress (root) or 226 an egress (leaf) of the LSP. 228 We refer to these LSRs with the following terms: 230 Initiator - the LSR which initiates the ping operation by sending 231 an MPLS Proxy Ping Request message 233 Proxy LSR - the LSR which is the destination of the MPLS Proxy 234 Ping Request message and potential initiator of the MPLS Echo 235 Request 237 Receiver(s) - the LSR(s) which receive the MPLS Echo Request 238 message 240 Responder - A receiver that responds to an MPLS Proxy Ping Request 241 or an MPLS Echo Request 243 We note that in some scenarios, the initiator could also be the 244 responder, in which case the response would be internal to the LSR. 246 2.1. Initiating Proxy Ping 248 The initiator formats an MPLS Proxy Ping Request message and sends it 249 to the Proxy LSR, an LSR it believes to be on the path of the LSP. 250 This message instructs the Proxy LSR to either Reply with Proxy 251 information or to send an MPLS Echo Request inband of the LSP. The 252 initiator requests Proxy information so that it can learn additional 253 information it needs to use to form a subsequent MPLS Proxy Ping 254 Request. For example, during LSP traceroute an initiator needs the 255 downstream map information to form an MPLS Echo Request. An initiator 256 may also want to learn a Proxy LSR's FEC neighbor information so that 257 it can form Proxy Ping Requests to various LSRs along the LSP. 259 2.2. Handling at Proxy LSR 261 The Proxy LSR either replies with the requested Proxy information or 262 it validates that it has a label mapping for the specified FEC and 263 that it is authorized to send the specified MPLS Echo Request on 264 behalf of the initiator. 266 If the Proxy LSR has a label mapping for the FEC and all 267 authorization checks have passed, the Proxy LSR formats an MPLS Echo 268 Request. If the source address of the MPLS Echo Request is not to be 269 set to the Proxy Request source address, the initiator MUST include a 270 Reply-to Address TLV containing the source address to use in the MPLS 271 Echo Request. It then sends it inband of the LSP. 273 The receivers process the MPLS Echo Request as normal, sending their 274 MPLS Echo Replies back to the initiator. 276 If the Proxy LSR failed to send an MPLS Echo Request as normal 277 because it encountered an issue while attempting to send, an MPLS 278 Proxy Ping Reply message is sent back with a Return Code indicating 279 that the MPLS Echo Request could not be sent. 281 2.2.1. Backward Compatibility 282 As described in sec 4.4 of [RFC4379], if the packet is not well- 283 formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code set 284 to "Malformed echo request received" and the Subcode to zero. If 285 there are any TLVs not marked as "Ignore" that Proxy LSR does not 286 understand, Proxy LSR SHOULD send an MPLS "TLV not understood" (as 287 appropriate), and the Subcode set to zero. 289 In the case where the targeted Proxy LSR does not understand the LSP 290 ping Echo Request at all, like any other LSR which does not 291 understand the messages, it MUST drop them and MUST NOT send any 292 message back to the initiator. 294 3. Proxy MPLS Echo Request / Reply Procedures 296 3.1. Procedures for the initiator 298 The initiator creates an MPLS Proxy Ping request message. 300 The message MUST contain a Target FEC Stack that describes the FEC 301 being tested. The topmost FEC in the target FEC stack is used at the 302 Proxy LSR to lookup the MPLS label stack that will be used to 303 encapsulate the MPLS Echo Request packet. 305 The MPLS Proxy Ping Request message MUST contain a Proxy Echo 306 Parameters TLV. In that TLV, the address type is set to either IPv4 307 or IPv6. The Destination IP Address is set to the value to be used by 308 the Proxy LSR to build the MPLS Echo Request packet. The MPLS Echo 309 Request IP header destination address as specified in [RFC4379], if 310 the Address Type is IPv4, MUST be an address is from the range 127/8; 311 If the Address Type is IPv6, MUST be an address from the range 312 ::FFFF:7F00:0/104. 314 The Reply mode and Global Flags of the Proxy Echo Parameters TLV are 315 set to the values to be used in the MPLS Echo Request message header. 316 The Source UDP Port is set to the value to be used in the MPLS Echo 317 Request (the source port is supplied by the Proxy Ping initiator 318 because it or an LSR known to it handles the LSP ping responses). The 319 TTL is set to the value to be used in the outgoing MPLS label stack. 320 See Section 5.1 for further details. 322 If the FEC's Upstream/Downstream Neighbor address information is 323 required, the initiator sets the "Request for FEC neighbor 324 information" Proxy Flags in the Proxy Echo Parameters TLV. 326 If a Downstream Detailed or Downstream Mapping TLV is required in an 327 MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream 328 Detailed Mapping" or "Request for Downstream Mapping" Proxy Flags in 329 the Proxy Echo Parameters TLV. Only one of the two flags can be set. 331 The Proxy Request reply mode is set with one of the reply modes 332 defined in [RFC4379] as appropriate. 334 A list of Next Hop IP Addresses MAY be included to limit the next 335 hops towards which the MPLS Echo Request message will be sent. These 336 are encoded as Next Hop sub-TLVs and included in the Proxy Echo 337 Parameters TLV. 339 Although not explicitly spelled out in [RFC4379], LSP Ping packets 340 can be formed to a desired size using a Pad TLV and then used to test 341 the Maximum Transmission Unit (MTU) of an LSP. When testing an LSPs 342 MTU, if the message is transported as an IP datagram, the IP header 343 DF bit MUST be set to prevent IP fragmentation by the IP forwarding 344 layer. The Proxy Echo Parameter TLV MPLS payload size field is 345 defined for this purpose and may be set to request that the MPLS Echo 346 Request (including any IP and UDP header) be zero padded to the 347 specified size. When a non zero MPLS payload size is specified, the 348 Proxy LSR introduces a Pad TLV to build the MPLS Echo Request packet, 349 so in this case, the Proxy Ping Request MUST NOT include a Pad TLV. 351 Any of following TLVs MAY be included; these TLVs are used to form 352 the MPLS Echo Request messages by the Proxy LSR: 354 Pad 356 Vendor Enterprise Number 358 Reply TOS Byte 360 P2MP Responder Identifier [RFC6425] 362 Echo Jitter TLV [RFC6425] 364 Vendor Private TLVs 366 Downstream Detailed Mapping (DDMAP) or Downstream Mapping (DSMAP) 367 TLVs MAY be included. These TLVs will be matched to the next hop 368 address for inclusion in those particular MPLS Echo Request messages. 370 The message is then encapsulated in a UDP packet. The source User 371 Datagram Protocol (UDP) port for the MPLS Proxy Ping Request message 372 is chosen by the initiator; the destination UDP port is set to 3503. 373 The IP header is set as follows: the source IP address is a routable 374 address of the initiator; the destination IP address is a routable 375 address to the Proxy LSR. The packet is then sent with the IP TTL set 376 to 255. 378 3.2. Procedures for the Proxy LSR 379 A Proxy LSR that receives an MPLS Proxy Ping Request message, parses 380 the packet to ensure that it is a well-formed packet. It checks that 381 the TLVs that are not marked "Ignore" are understood. If any part of 382 the message is malformed, it sets the Return Code to "Malformed echo 383 request received". If all the TLVs are well formed and any TLVs are 384 not understood, the Return Code is set to "TLV not understood". The 385 Subcode is set to zero for both cases. 387 If the Reply Mode of the message header is not 1(Do not reply), an 388 MPLS Proxy Ping Reply message SHOULD be sent as described below. 390 If the Return Code is "TLV not understood", no more processing of the 391 MPLS Proxy Ping Request message is required. The Proxy LSR sends an 392 MPLS Proxy Ping Reply message with an Errored TLVs TLV containing all 393 the not understood TLVs (only). 395 The MPLS Proxy Ping Request is expected to be transported to the 396 Proxy LSR via IP forwarding mechanisms instead of using the same 397 techniques that are employed to inject an MPLS Echo Request packet 398 into an LSP and use IP TTL, MPLS TTL and or loopback addresses (IPv4 399 127.x.x.x/IPv6::FFF:127/104) in the IP header destination address 400 field to trigger the packet to be handled via an LSR's forwarding 401 exception processing path. To gaurd against this, the Proxy LSR 402 checks that the MPLS Proxy Ping Request message did not arrive via 403 one of its exception processing paths. Packets arriving via IP TTL 404 expiry, IP destination address set to a loopback address or label ttl 405 expiry MUST be treated as "Unauthorized" packets. An MPLS Proxy Ping 406 Reply message MAY be sent with a Return Code of , "Proxy Ping 407 not authorized". 409 The header fields Sender's Handle and Sequence Number are not 410 examined, but they are included in the MPLS Proxy Ping Reply or MPLS 411 Echo Request message, if either is sent as a direct result of the 412 received message. 414 The Proxy LSR validates that it has a label mapping for the specified 415 FEC, it then determines if it is an ingress, egress, transit or bud 416 node and sets the Return Code as appropriate. A new Return Code of 417 , "Replying router has FEC mapping for topmost FEC" has been 418 defined for the case where the Proxy LSR is an ingress (for example 419 head of the TE tunnel or a transit router) because the existing 420 RFC4379 Return Codes don't match the situation. For example, when a 421 Proxy LSR is a transit router, it's not appropriate for the Return 422 Code to describe how the packet would transit because the MPLS Proxy 423 Ping Request doesn't contain information about what input interface 424 the MPLS Echo Request would be switched from at the Proxy LSR. 426 The Proxy LSR then determines if it is authorized to send the 427 specified MPLS Echo Request on behalf of the initiator. A Proxy LSR 428 MUST be capable of filtering addresses to validate initiators. Other 429 filters on FECs or MPLS Echo Request contents MAY be applied. If a 430 configured filter has been invoked and an address does not pass the 431 filter, then an MPLS Echo Request message MUST NOT be sent, and the 432 event SHOULD be logged. An MPLS Proxy Ping Reply message MAY be sent 433 with a Return Code of , "Proxy Ping not authorized". 435 The destination address specified in the Proxy Echo Parameters TLV is 436 checked to ensure that it conforms to the address allowed IPv4 or 437 IPv6 address range. If not, the Return Code set to "Malformed echo 438 request received" and the Subcode set to zero. If the Reply Mode of 439 the message header is not 1, an MPLS Proxy Ping Reply message SHOULD 440 be sent as described below. 442 If the "Request for FEC Neighbor Address info" flag is set, the 443 Upstream Neighbor Address and Downstream Neighbor Address TLVs are 444 formatted for inclusion in the MPLS Proxy Ping reply. If the Upstream 445 or Downstream address is unknown, the corresponding TLV is omitted. 447 If there are Next Hop sub-TLVs in the Proxy Echo Parameters TLV, each 448 address is examined to determine if it is a valid next hop for this 449 FEC. If any are not, Proxy Echo Parameters TLV SHOULD be updated 450 removing unrecognized Next Hop sub-TLVs. The updated Proxy Echo 451 Parameters TLV MUST be included in the MPLS Proxy Ping Reply. 453 If the "Request for Downstream Detailed Mapping" or "Request for 454 Downstream Mapping" flag is set, the Proxy LSR formats (for inclusion 455 in the MPLS Proxy Ping Reply) a Downstream Detailed/Downstream 456 Mapping (DD/DSMAP) TLV for each interface over which the MPLS Echo 457 Request will be sent. 459 If the Proxy LSR is the egress for the FEC, the behavior of the Proxy 460 LSR varies depending on whether the LSR is an egress of a P2P LSP, a 461 P2MP LSP or MP2MP LSP. Additional details can be found in the section 462 describing "Handling when Proxy LSR it is egress for FEC". 464 If the Reply Mode of the MPLS Proxy Ping Request message header is "1 465 - do not reply", no MPLS Proxy Ping Reply is sent. Otherwise an MPLS 466 Proxy Ping Reply message or MPLS Echo Request SHOULD be sent as 467 described below. 469 3.2.1. Proxy LSR Handling when it is egress for FEC 471 This section describes the different behaviors for the Proxy LSR when 472 it's the egress for the FEC. In the P2MP bud node and MP2MP bud node 473 and egress cases, different behavior is required. 475 In the case where an MLSP Echo Request is originated by an LSR which 476 is a bud or egress node of a P2MP/MP2MP, MPLS Echo Replies are 477 returned from downstream/upstream LSRs and will not include an MPLS 478 Echo Reply from the LSR that originated the MPLS Echo Request. This 479 section describes the behavior required at a bud or egress node to 480 return or not return information from MPLS Echo Replies in the Proxy 481 Echo Reply so that no changes are required in [RFC4379] compliant 482 implementations. The Proxy Initiator should receive the same MPLS 483 Echo Replies as in the case where of the originator of the LSP ping, 484 any additional information such as the Proxy LSR being a bud or 485 egress node is returned in the MPLS Proxy Ping Reply. 487 When the Proxy LSR is the egress of a P2P FEC, an MPLS Proxy Ping 488 Reply SHOULD be sent to the initiator with the Return Code set to 3, 489 "Reply router is egress for FEC", with Return Subcode set to 0. 491 When the Proxy LSR is the egress of a P2MP FEC, it can be either a 492 bud node or just an egress. If the Proxy LSR is a bud node, a MPLS 493 Proxy Ping Reply SHOULD be sent to the initiator with the return code 494 set to 3 (Reply router is Egress for FEC) with return Subcode set to 495 0. DS/DDMAPs are included only if the Proxy initiator requested 496 information to be returned in a MPLS Proxy Ping Reply. If the Proxy 497 LSR is a bud node but not requested to return an MPLS Proxy Ping 498 Reply, the Proxy LSR SHOULD send MPLS Echo Request packet(s) to the 499 downstream neighbors (no MPLS Echo Reply is sent to the Proxy 500 Initiator to indicate that the Proxy LSR is an egress). If the Proxy 501 LSR is just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the 502 initiator with the Return Code set to 3, "Reply router is egress for 503 FEC", and Return Subcode set to 0. 505 When the Proxy LSR is the egress of a MP2MP FEC, it can be either a 506 bud node or just an egress. LSP pings sent from a leaf of a MP2MP 507 have different behavior in this case. MPLS Echo Requests are sent to 508 all upstream/downstream neighbors. The Proxy LSRs need to be 509 consistent with this variation in behavior. If the Proxy LSR is a bud 510 node or just an egress, an MPLS Proxy Ping Reply SHOULD be sent to 511 the Proxy Initiator with the return code set to 3, "Reply router is 512 Egress for FEC", with Return Subcode set to 0 and DS/DDMAPs included 513 only if the Proxy initiator requested information to be returned in a 514 MPLS Proxy Ping Reply. If the Proxy LSR is not requested to return 515 information in an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send 516 MPLS Echo Request packets to all upstream/downstream neighbors as 517 would be done when sourcing an LSP ping from a MP2MP leaf (no MPLS 518 Echo Reply is sent to the Proxy initiator indicating that the Proxy 519 LSR is an egress). 521 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply 522 When the Proxy LSR is a transit or bud node, downstream maps 523 corresponding to how the packet is transited cannot be supplied 524 unless an ingress interface for the MPLS Echo Request is specified. 525 Since this information is not available and all valid output paths 526 are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe 527 the entire set of paths that the packet can be replicated. This is 528 similar to the case in which an LSP ping is initiated at the Proxy 529 LSR. For mLDP, there is a DSMAP/DDMAP per upstream/downstream 530 neighbor for MP2MP LSPs, or per downstream neighbor in the P2MP LSP 531 case. 533 When the Proxy LSR is a bud node or egress in an MP2MP LSP or a bud 534 node in a P2MP LSP, an LSP ping initiated from the Proxy LSR would 535 source packets only to the neighbors but not itself, despite the fact 536 that the Proxy LSR is itself an egress for the FEC. In order to match 537 the behavior as seen from LSP Ping initiated at the Proxy LSR, the 538 Proxy Reply SHOULD contain DSMAP/DDMAPs for only the paths to the 539 upstream/downstream neighbors, but no DSMAP/DDMAP describing its own 540 egress paths. The proxy LSR identifies that it's an egress for the 541 FEC using a different Proxy Reply Return Code. The Proxy reply Return 542 Code is either set to "Reply router has a mapping for the topmost 543 FEC" or "Reply router is egress for the FEC". 545 3.2.3. Sending an MPLS Proxy Ping Reply 547 The Reply mode, Sender's Handle and Sequence Number fields are copied 548 from the Proxy Ping Request message. The TLVs specified above are 549 included. The message is encapsulated in a UDP packet. The source IP 550 address is a routable address of the Proxy LSR; the source port is 551 the well-known UDP port for LSP ping. The destination IP address and 552 UDP port are copied from the source IP address and UDP port of the 553 MPLS Proxy Ping Request. The IP TTL is set to 255. 555 3.2.4. Sending the MPLS Echo Requests 557 An MPLS Echo Request is formed as described in the next section. The 558 section below that describes how the MPLS Echo Request is sent on 559 each interface. 561 3.2.4.1. Forming the base MPLS Echo Request 563 If Next Hop sub-TLVs were included in the received Proxy Echo 564 Parameters TLV, the Next_Hop_List is created from the addresses in 565 those sub-TLVs adjusted as described in Section 3.2. Otherwise, the 566 list is set to all the next hops to which the FEC would be forwarded. 568 The Proxy LSR then formats an MPLS Echo Request message. The Global 569 Flags and Reply Mode are copied from the Proxy Echo Parameters TLV. 571 The Return Code and Return Subcode are set to zero. 573 The Sender's Handle and Sequence Number are copied from the remote 574 echo request message. 576 The TimeStamp Sent is set to the time-of-day (in seconds and 577 microseconds) that the MPLS Echo Request is sent. The TimeStamp 578 Received is set to zero. 580 If the reply-to address TLV is present, it is used to set the echo 581 request source address; otherwise the echo request source address is 582 set to the Proxy Request source address. 584 The following TLVs are copied from the MPLS Proxy Ping Request 585 message. Note that of these, only the Target FEC Stack is REQUIRED to 586 appear in the MPLS Proxy Ping Request message. The Pad TLV is not 587 copied if the Proxy Echo Parameter TLV MPLS payload size is set to a 588 non zero value. 590 Target FEC Stack 592 Pad 594 Vendor Enterprise Number 596 Reply TOS Byte 598 P2MP Responder Identifier [RFC6425] 600 Echo Jitter TLV [RFC6425] 602 Vendor Private TLVs 604 If the Proxy Echo Parameter TLV MPLS payload size is non zero, the 605 Proxy LSR introduces a Pad TLV such that size of the MPLS Echo 606 Request (including any IP and UDP header) is zero padded to the 607 specified MPLS payload size. The First Octet in Value part of the 608 Pad TLV is set to 1, "Drop Pad TLV from Reply", the remaining Octets 609 of the Value part of the Pad TLV is filled with zeros. If IP header 610 is use to encapsulate in the MPLS Echo Request the DF bit MUST be set 611 to one. 613 The message is then encapsulated in a UDP packet. The source UDP port 614 is copied from the Proxy Echo Parameters TLV. The destination port is 615 copied from the MPLS Proxy Ping Request message. 617 The source IP address is set to a routable address specified in the 618 reply-to-address TLV or the source address of the received Proxy 619 Request. Per usual the TTL of the IP packet is set to 1. 621 If the Explicit Differentiated Services Code Point (DSCP) flag is 622 set, the Requested DSCP byte is examined. If the setting is permitted 623 then the DSCP byte of the IP header of the MPLS Echo Request message 624 is set to that value. If the Proxy LSR does not permit explicit 625 control for the DSCP byte, the MPLS Proxy Echo Parameters with the 626 Explicit DSCP flag cleared MUST be included in any MPLS Proxy Ping 627 Reply message to indicate why an MPLS Echo Request was not sent. The 628 Return Code MUST be set to , "Proxy Ping parameters need to be 629 modified". If the Explicit DSCP flag is not set, the Proxy LSR SHOULD 630 set the MPLS Echo Request DSCP settings to the value normally used to 631 source LSP ping packets.. 633 3.2.4.2. Per interface sending procedures 635 The Proxy LSR now iterates through the Next_Hop_List modifying the 636 base MPLS Echo Request to form the MPLS Echo Request packet which is 637 then sent on that particular interface. 639 The outgoing label stack is determined for each next hop address. The 640 TTL for the label corresponding to the FEC specified in the FEC stack 641 is set such that the TTL on the wire will be other TTL specified in 642 the Proxy Echo Parameters. If any additional labels are pushed onto 643 the stack, their TTLs are set to 255. This will ensure that the 644 requestor will not have control over tunnels not relevant to the FEC 645 being tested. 647 If the MPLS Proxy Ping Request message contained Downstream Mapping/ 648 Downstream Detailed Mapping TLVs, they are examined. If the 649 Downstream IP Address matches the next hop address, that Downstream 650 Mapping TLV is included in the MPLS Echo Request. 652 The packet is then transmitted on this interface. 654 4. Proxy Ping Request / Reply Messages 656 This document defines two new LSP Ping messages, the MPLS Proxy Ping 657 Request and the MPLS Proxy Ping Reply. 659 4.1. Proxy Ping Request / Reply Message formats 661 The packet format is as defined in [RFC4379]. Two new message types, 662 Proxy Ping Request and Reply, are being added. 664 Message Type 666 Type Message 667 ---- ------- 668 TBA-1 MPLS Proxy Ping Request 669 (Pending IANA assignment) 671 TBA-2 MPLS Proxy Ping Reply 672 (Pending IANA assignment) 674 4.2. Proxy Ping Request Message contents 676 The MPLS Proxy Ping Request message MAY contain the following 677 TLVs: 679 Type TLV 680 ---- ----------- 681 1 Target FEC Stack 682 2 Downstream Mapping 683 3 Pad 684 5 Vendor Enterprise Number 685 10 Reply TOS Byte 687 11 P2MP Responder Identifier [RFC6425] 688 12 Echo Jitter TLV [RFC6425] 689 20 Downstream Detailed Mapping 690 21 Reply Path [RFC7110] 691 22 Reply TC [RFC7110] 692 TBA-3 Proxy Echo Parameters (Pending IANA assignment) 693 TBA-4 Reply-to-Address TLV 694 * Vendor Private TLVs 696 * TLVs types in the Vendor Private TLV Space MUST be 697 ignored if not understood 699 4.3. Proxy Ping Reply Message Contents 701 The MPLS Proxy Ping Reply message MAY contain the following TLVs: 703 Type TLV 704 ---- ----------- 705 1 Target FEC Stack 706 2 Downstream Mapping 707 5 Vendor Enterprise Number 708 9 Errored TLVs 709 20 Downstream Detailed Mapping 710 TBA-3 Proxy Echo Parameters (Pending IANA assignment) 711 TBA-5 Upstream Neighbor Address (Pending IANA assignment) 712 TBA-6 Downstream Neighbor Address (0 or more) 713 (Pending IANA assignment) 714 * Vendor Private TLVs 716 * TLVs types in the Vendor Private TLV Space MUST be 717 ignored if not understood 719 5. TLV formats 721 5.1. Proxy Echo Parameters TLV 723 The Proxy Echo Parameters TLV is a TLV that MUST be included in an 724 MPLS Proxy Ping Request message. The length of the TLV is 12 + K + S, 725 where K is the length of the Destination IP Address field and S is 726 the total length of the sub-TLVs. The Proxy Echo Parameters TLV can 727 be used either to 1) control attributes used in composing and sending 728 an MPLS Echo Request or 2) query the Proxy LSR for information about 729 the topmost FEC in the target FEC stack, but not both. In the case 730 where the Proxy LSR is being queried (i.e., information needs to be 731 returned in an MPLS Proxy Ping Reply), no MPLS Echo Request will be 732 sent from the Proxy LSR. The MPLS Proxy Ping Request echo header's 733 Reply Mode SHOULD be set to "Reply with Proxy Info". 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Address Type | Reply mode | Proxy Flags | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | TTL | Rqst'd DSCP | Source UDP Port | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Global Flags | MPLS Payload size | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | 745 : Destination IP Address : 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 : : 750 : Sub-TLVs : 751 : : 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Address Type 757 The type and length of the address found in the in the Destination 758 IP Address and Next Hop IP Addresses fields. The values are shared 759 with the Downstream Mapping Address Type Registry. 761 The type codes applicable in this case appear in the table below: 763 Address Family Type Length 765 IPv4 1 4 766 IPv6 3 16 768 Reply mode 770 The reply mode to be sent in the MPLS Echo Request message; the 771 values are as specified in [RFC4379]. 773 Proxy Flags 775 The Proxy Request Initiator sets zero, one or more of these flags 776 to request actions at the Proxy LSR. 778 0x01 Request for FEC Neighbor Address info 780 When set, this requests that the Proxy LSR supply the 781 Upstream and Downstream neighbor address information in the 782 MPLS Proxy Ping Reply message. This flag is only applicable 783 for the topmost FEC in the FEC stack if the FEC type 784 corresponds with a P2MP or MP2MP LSP. The Proxy LSR MUST 785 respond as applicable with Upstream Neighbor Address and 786 Downstream Neighbor Address TLV(s) in the MPLS Proxy Ping 787 Reply message. The Upstream Neighbor Address TLV needs be 788 included only if there is an upstream neighbor. Similarly, 789 one Downstream Neighbor Address TLV needs to be included for 790 each Downstream Neighbor from which the LSR learned 791 bindings. 793 Setting this flag will cause the Proxy LSR to cancel sending 794 any MPLS Echo Request. The initiator may use information 795 learned from the MPLS Proxy Ping Reply that is sent instead 796 to generate subsequent proxy requests. 798 0x02 Request for Downstream Mapping 800 When set, this requests that the Proxy LSR supply a 801 Downstream Mapping TLV see [RFC4379] in the MPLS Proxy Ping 802 Reply message. Either this flag may be set or the Request 803 for Downstream Detailed Mapping flag may be set, but not 804 both. 806 Setting this flag will cause the Proxy LSR to cancel sending 807 an Echo request. Information learned with such Proxy Reply 808 may be used by the Proxy initiator to generate subsequent 809 Proxy Requests. 811 0x04 Request for Downstream Detailed Mapping 813 When set, this requests that the Proxy LSR supply a 814 Downstream Detailed Mapping TLV see [RFC6424] in the MPLS 815 Proxy Ping Reply message. It's not valid to have Request for 816 Downstream Mapping flag set when this flag is set. Setting 817 this flag will cause the Proxy LSR to cancel sending an Echo 818 request. The initiator may use information learned from the 819 MPLS Proxy Ping Reply that is sent instead to generate 820 subsequent proxy requests. 822 0x08 Explicit DSCP Request 824 When set, this requests that the Proxy LSR use the supplied 825 "Rqst'd DSCP" byte in the Echo Request message 827 TTL 829 The TTL to be used in the label stack entry corresponding to 830 the topmost FEC in the in the MPLS Echo Request packet. Valid 831 values are in the range [1,255]. A setting of 0 SHOULD be 832 ignored by the Proxy LSR. 834 Requested DSCP 836 This field is valid only if the Explicit DSCP flag is set. If 837 not set, the field MUST be zero on transmission and ignored on 838 receipt. When the flag is set, this field contains the DSCP 839 value to be used in the MPLS Echo Request packet IP header. 841 Source UDP Port 843 The source UDP port to be sent in the MPLS Echo Request packet 845 Global Flags 847 The Global Flags to be sent in the MPLS Echo Request message 849 MPLS Payload Size 851 Used to request that the MPLS payload (IP header + UDP header + 852 MPLS Echo Request) be padded using a zero filled Pad TLV so 853 that the IP header, UDP header and MPLS Echo Request total the 854 specified size. Field set to zero means no size request is 855 being made. If the requested size is less than the minimum size 856 required to form the MPLS Echo Request, the request will be 857 treated as a best effort request with the Proxy LSR building 858 the smallest possible packet (i.e. not using a Pad TLV). The IP 859 header DF bit MUST be set when this field is non zero. 861 Destination IP Address 863 If the Address Type is IPv4, an address from the range 127/8; 864 If the Address Type is IPv6, an address from the range 865 ::FFFF:7F00:0/104 867 Sub-TLVs 869 List of TLV-encoded sub-TLVs. Currently one is defined. 871 Sub-TLV Type Length Value Field 872 ------------ ------ ----------- 873 8+ Next Hop 875 5.1.1. Next Hop sub-TLV 877 This sub-TLV is used to describe a particular next hop towards which 878 the Echo Request packet should be sent. If the topmost FEC in the 879 FEC-stack is a multipoint LSP, this sub-TLV may appear multiple 880 times. 882 0 1 2 3 883 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 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Addr Type | MUST be Zero | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Next Hop IP Address (4 or 16 octets) | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Next Hop Interface (0, 4 or 16 octets) | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 Address Type 894 Type Type of Next Hop Addr Length IF Length 896 1 IPv4 Numbered 4 4 897 2 IPv4 Unnumbered 4 4 898 3 IPv6 Numbered 16 16 899 4 IPv6 Unnumbered 16 4 900 5 Reserved 901 TBA-11 IPv4 Protocol Adj 4 0 902 TBA-12 IPv6 Protocol Adj 16 0 904 Note: Types 1-4 correspond to the types in the DS Mapping TLV. 906 They are expected to populated with information obtained 907 through a previously returned DS Mapping TLV. Types 908 and are intended to be populated 909 from the local address information obtained from a 910 previously returned Downstream Neighbor Address 911 TLV(s)/Upstream Neighbor Address TLV. 913 Next Hop IP Address 915 A next hop address that the echo request message is to 916 be sent towards 918 Next Hop Interface 920 Identifier of the interface through which the echo request 921 message is to be sent. For Addr Type 5, and 6, the Next Hop 922 interface field isn't used and MUST be of an associated byte 923 length of "0" octets. 925 5.2. Reply-to Address TLV 927 Used to specify the MPLS Echo Request IP source address. This address 928 MUST be IP reachable via the Proxy LSR; otherwise it will be 929 rejected. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Address Type | MUST be Zero | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | | 937 : Reply-to Address : 938 | | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Address Type 943 A type code as specified in the table below: 945 Type Type of Address 947 1 IPv4 948 3 IPv6 950 5.3. Upstream Neighbor Address TLV 952 0 1 2 3 953 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 |Upst Addr Type |Local Addr Type| MUST be Zero | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | | 959 : Upstream Address : 960 | | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | | 963 : Local Address : 964 | | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Upst Addr Type; Local Addr Type 969 These two fields determine the type and length of the 970 respective addresses. The codes are specified in the table 971 below: 973 Type Type of Address Length 975 0 No Address Supplied 0 976 1 IPv4 4 977 3 IPv6 16 979 Upstream Address 981 The address of the immediate upstream neighbor for the topmost 982 FEC in the FEC stack. If protocol adjacency exists by which the 983 label for this FEC was exchanged, this address MUST be the 984 address used in that protocol exchange. 986 Local Address 988 The local address used in the protocol adjacency exists by 989 which the label for this FEC was exchanged. 991 5.4. Downstream Neighbor Address TLV 993 0 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 |Dnst Addr Type |Local Addr Type| MUST be Zero | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | | 999 : Downstream Address : 1000 | | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | | 1003 : Local Address : 1004 | | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 Dnst Addr Type; Local Addr Type 1009 These two fields determine the type and length of the 1010 respective addresses. The codes are specified in the table 1011 below: 1013 Type Type of Address Length 1015 0 No Address Supplied 0 1016 1 IPv4 4 1017 3 IPv6 16 1019 Downstream Address 1021 The address of a immediate downstream neighbor for the topmost 1022 FEC in the FEC stack. If protocol adjacency exists by which the 1023 label for this FEC was exchanged, this address MUST be the 1024 address used in that protocol exchange. 1026 Local Address 1028 The local address used in the protocol adjacency exists by 1029 which the label for this FEC was exchanged. 1031 6. Security Considerations 1033 The mechanisms described in this document are intended to be used 1034 within a Service Provider network and to be initiated only under the 1035 authority of that administration. 1037 If such a network also carries Internet traffic, or permits IP access 1038 from other administrations, MPLS Proxy Ping message SHOULD be 1039 discarded at the points that where the IP packet is received from the 1040 other administrations. This can be accomplished by filtering on 1041 source address or by filtering all MPLS ping messages on UDP port. 1043 Any node which acts as a Proxy LSR SHOULD validate requests against a 1044 set of valid source addresses. An implementation MUST provide such 1045 filtering capabilities. 1047 MPLS Proxy Ping Request messages are IP addressed directly to the 1048 Proxy LSR. If a Proxy LSR receives an MPLS Proxy Ping message via 1049 expiration of the IP or Label Stack Entry TTL, it MUST NOT be acted 1050 upon. 1052 If an MPLS Proxy Ping Request IP source address is not IP reachable 1053 by the Proxy LSR, the Proxy Request MUST NOT be acted upon. 1055 MPLS Proxy Ping Requests are limited to making their request via the 1056 specification of a FEC. This ensures that only valid MPLS Echo 1057 Request messages can be created. No label spoofing attacks are 1058 possible. 1060 7. Acknowledgements 1062 The authors would like to thank Nobo Akiya, Adrian Farrel, Tom Yu, 1063 Tom Taylor and Warren Kumari for their detailed review and insightful 1064 comments. 1066 8. IANA Considerations 1068 This document makes the following assignments (pending IANA action) 1070 MPLS LSP Ping Message Types 1072 Type Value Field 1073 ---- ----------- 1074 TBA-1 MPLS Proxy Ping Request 1075 TBA-2 MPLS Proxy Ping Reply 1077 TLVs 1079 Type Value Field 1080 ---- ----------- 1081 TBA-3 Proxy Echo Parameters 1082 TBA-4 Reply-to Address 1083 TBA-5 Upstream Neighbor Address 1084 TBA-6 Downstream Neighbor Address 1086 Return Code [pending IANA assignment] 1088 Value Meaning 1089 ----- ------- 1090 TBA-7 Proxy Ping not authorized. 1091 TBA-8 Proxy Ping parameters need to be modified. 1092 TBA-9 MPLS Echo Request Could not be sent. 1093 TBA-10 Replying router has FEC mapping for topmost FEC. 1095 8.1. Proxy Echo Parameters Sub-TLVs 1097 The IANA will create and maintain this new registry for Proxy Echo 1098 Parameters Sub-TLV's. Assignments will use the same rules spelled out 1099 in sec 7.2 of [RFC4379]. 1101 Sub-TLV Type Meaning 1102 ----------- ------- 1103 0 Reserved 1104 TBA-13 Next Hop 1106 8.2. Downstream Address Mapping Registry [pending IANA assignment] 1108 This document makes the following assignments in the Downstream 1109 Address Mapping Registry(pending IANA assignment). This document 1110 updates the registry defined by [RFC6426], modifying the allocation 1111 procedures. 1113 The allocation procedures of Downstream Mapping Address Type Registry 1114 is changed to read 'Standards action - each time a code point is 1115 assigned from this registry, unless the same registration is made in 1116 both registries, the corresponding Next Hop Address Type Registry 1117 must be Marked "Reserved". 1119 Value Meaning K Octets 1120 ----- ------- -------- 1122 TBA-11 Reserved N/A [this doc] 1123 TBA-12 Reserved N/A [this doc] 1125 8.3. Next Hop Sub-TLV Address Type Registry 1127 IANA is requested to create a new registry called "Next Hop Address 1128 Type Registry". The allocation policy for this registry is 1129 "Standards action". Further, each time a code point is assigned from 1130 this registry, unless the same registration is made in both 1131 registries, the corresponding Downstream Address Mapping Registry 1132 must be Marked "Reserved". The initial allocations are: 1134 Type Type of Next Hop Addr Length IF Length Reference 1136 1 IPv4 Numbered 4 4 [RFC4379] 1137 2 IPv4 Unnumbered 4 4 [RFC4379] 1138 3 IPv6 Numbered 16 16 [RFC4379] 1139 4 IPv6 Unnumbered 16 4 [RFC4379] 1140 5 Reserved [this doc] 1141 TBA-11 IPv4 Protocol Adj 4 0 [this doc] 1142 TBA-12 IPv6 Protocol Adj 16 0 [this doc] 1143 x-255 Unassigned 1145 9. References 1146 9.1. Normative References 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, March 1997. 1151 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1152 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1153 February 2006. 1155 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1156 Performing Label Switched Path Ping (LSP Ping) over MPLS 1157 Tunnels", RFC 6424, November 2011. 1159 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 1160 S., and T. Nadeau, "Detecting Data-Plane Failures in 1161 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 1162 6425, November 2011. 1164 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and Aggarwal, R., 1165 "MPLS On-Demand Connectivity Verification and Route 1166 Tracing", RFC 6426, November 2011. 1168 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and Delord, S., 1169 "Return Path Specified Label Switched Path (LSP) Ping", 1170 RFC 7110, January 2014. 1172 9.2. Informative References 1174 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1175 "Extensions to Resource Reservation Protocol - Traffic 1176 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1177 Switched Paths (LSPs)", RFC 4875, May 2007. 1179 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1180 "Label Distribution Protocol Extensions for Point-to- 1181 Multipoint and Multipoint-to-Multipoint Label Switched 1182 Paths", RFC 6388, November 2011. 1184 Authors' Addresses 1186 George Swallow 1187 Cisco Systems 1188 1414 Massachusetts Ave 1189 Boxborough, MA 01719 1190 USA 1192 Email: swallow@cisco.com 1193 Vanson Lim 1194 Cisco Systems 1195 1414 Massachusetts Avenue 1196 Boxborough, MA 01719 1197 USA 1199 Email: vlim@cisco.com 1201 Sam Aldrin 1202 Huawei Technologies 1203 2330 Central Express Way 1204 Santa Clara, CA 95951 1205 USA 1207 Email: aldrin.ietf@gmail.com