idnits 2.17.1 draft-lim-mpls-proxy-lsp-ping-01.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2013) is 4079 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 754 -- Looks like a reference, but probably isn't: '255' on line 754 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: August 26, 2013 S. Aldrin 6 Huawei Technologies 7 February 22, 2013 9 Proxy MPLS Echo Request 10 draft-lim-mpls-proxy-lsp-ping-01 12 Abstract 14 This document defines a means of remotely initiating Multiprotocol 15 Label Switched Protocol Pings on Label Switched Paths. A proxy ping 16 request is sent to any Label Switching Routers along a Label Switched 17 Path. The primary motivations for this facility are first to limit 18 the number of messages and related processing when using LSP Ping in 19 large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ 20 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). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 26, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 2. Proxy Ping Overview . . . . . . . . . . . . . . . . . . . . . 5 71 3. Proxy MPLS Echo Request / Reply Procedures . . . . . . . . . . 7 72 3.1. Procedures for the initiator . . . . . . . . . . . . . . . 7 73 3.2. Procedures for the proxy LSR . . . . . . . . . . . . . . . 8 74 3.2.1. Proxy LSR Handling when it is Egress for FEC . . . . . 10 75 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply . . 11 76 3.2.3. Sending an MPLS proxy ping reply . . . . . . . . . . . 11 77 3.2.4. Sending the MPLS echo requests . . . . . . . . . . . . 11 78 3.2.4.1. Forming the base MPLS echo request . . . . . . . . 11 79 3.2.4.2. Per interface sending procedures . . . . . . . . . 13 80 4. Proxy Ping Request / Reply Messages . . . . . . . . . . . . . 13 81 4.1. Proxy Ping Request / Reply Message formats . . . . . . . . 13 82 4.2. Proxy Ping Request Message contents . . . . . . . . . . . 14 83 4.3. Proxy Ping Reply Message Contents . . . . . . . . . . . . 15 84 5. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.1. Proxy Echo Parameters Object . . . . . . . . . . . . . . . 16 86 5.1.1. Next Hop sub-Object . . . . . . . . . . . . . . . . . 19 87 5.2. Reply-to Address Object . . . . . . . . . . . . . . . . . 20 88 5.3. Upstream Neighbor Address Object . . . . . . . . . . . . . 21 89 5.4. Downstream Neighbor Address Object . . . . . . . . . . . . 22 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 98 1. Introduction 100 This document is motivated by two broad issues in connection with 101 diagnosing P2MP LSPs. The first is scalability due to the automatic 102 replication of MPLS Echo Request Messages as they proceed down the 103 tree. The second, which is primarily motivated by mLDP, is the 104 ability to trace a sub-LSP from leaf node to root node. 106 It is anticipated that very large Point-to-Multipoint (P2MP) and 107 Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) will 108 exist. Further it is anticipated that many of the applications for 109 P2MP/MP2MP tunnels will require OAM that is both rigorous and 110 scalable. 112 Suppose one wishes to trace a P2MP LSP to localize a fault which is 113 affecting one egress or a set of egresses. Suppose one follows the 114 normal procedure for tracing - namely repeatedly pinging from the 115 root, incrementing the TTL by one after each three or so pings. Such 116 a procedure has the potential for producing a large amount of 117 processing at the P2MP-LSP midpoints and egresses. It also could 118 produce an unwieldy number of replies back to the root. 120 One alternative would be to begin sending pings from points at or 121 near the affected egress(es) and working backwards toward the root. 122 The TTL could be held constant as say two, limiting the number of 123 responses to the number of next-next-hops of the point where a ping 124 is initiated. 126 In the case of RSVP-TE, all setup is initiated from the root of the 127 tree. Thus, the root of the tree has knowledge of all the leaf nodes 128 and usually the topology of the entire tree. Thus the above 129 alternative can easily be initiated by the root node. 131 In mLDP the situation is quite different. Leaf nodes initiate 132 connection to the tree which is granted by the first node that is 133 part of the tree. The root node may only be aware of the immediately 134 adjacent (downstream) nodes of the tree. Initially the leaf node 135 only has knowledge of the node it is immediately adjacent to 136 (upstream) in the tree. However this is sufficient to initiate a 137 trace by applying the above alternative to the last link in the tree. 138 That is, by requesting the upstream node to send an MPLS Echo Request 139 for the FEC of the tree in question on said link. By adding an 140 additional capability to inquire the upstream node of its upstream 141 node, the procedure can interatively be applied until the fault is 142 localized or the root node is reached. In all cases the TTL for the 143 request need only be at most 2. Thus the processing load of each 144 request is small as only a limited number of nodes will receive the 145 request. 147 This document defines protocol extensions to MPLS ping [RFC4379] to 148 allow a third party to remotely cause an MPLS echo request message to 149 be sent down a Label Switched Path (LSP) or part of an LSP. The 150 procedure described in the paragraphs above does require that the 151 initiator know the previous-hop node to the one which was pinged on 152 the prior iteration. This information is readily available in 153 [RFC4875]. This document also provides a means for obtaining this 154 information for [RFC6388]. 156 While the motivation for this document came from multicast scaling 157 concerns, it's applicability may be wider. However other uses of 158 this facility are beyond the scope of this document. In particular, 159 the procedures defined in this document only allow testing of a FEC 160 stack consisting of a single FEC. It also does not allow the 161 initiator to specify the label assigned to that FEC, nor does it 162 allow the initiator to cause any additional labels to be added to the 163 label stack of the actual MPLS echo request message. 165 1.1. Requirements Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119. 171 The term "Must Be Zero" (MBZ) is used in object descriptions for 172 reserved fields. These fields MUST be set to zero when sent and 173 ignored on receipt. 175 Based on context the terms leaf and egress are used interchangeably. 176 Egress is used where consistency with[RFC4379] was deemed 177 appropriate. Receiver is used in the context of receiving protocol 178 messages. 180 [Note (to be removed after assignments occur): = to be assigned 181 by IANA] 183 2. Proxy Ping Overview 185 This document defines a protocol interaction between a first node and 186 a node which is part of an LSP to allow the first node to request 187 that second node initiate an LSP ping for the LSP on behalf of the 188 first node. Two new LSP Ping messages are defined for remote 189 pinging: the MPLS proxy ping request and the MPLS proxy ping reply. 191 A remote ping operation on a P2MP LSP generally involves at least 192 three LSRs; in some scenarios none of these are the ingress (root) or 193 an egress (leaf) of the LSP. 195 We refer to these nodes with the following terms: 197 Initiator - the node which initiates the ping operation by sending 198 an MPLS proxy ping request message 200 Proxy LSR - the node which is the destination of the MPLS proxy 201 request message and potential initiator of the MPLS echo request 203 Receiver(s) - the nodes which receive the MPLS echo request 204 message 206 Responder - A receiver that responds to a MPLS Proxy Ping Request 207 or an MPLS Echo Request 209 We note that in some scenarios, the initiator could also be the 210 responder, in which case the response would be internal to the node. 212 The initiator formats an MPLS proxy ping request message and sends it 213 to the proxy LSR, a node it believes to be on the path of the LSP. 214 This message instructs the proxy LSR to either Reply with Proxy 215 information or to send a MPLS echo request inband of the LSP. The 216 initiator requests Proxy information so that it can learn additional 217 information it needs to use to form a subsequent MPLS Proxy Ping 218 request. For example during LSP traceroute an initiator needs the 219 downstream map information to form an Echo request. An initiator may 220 also want to learn a Proxy LSR's FEC neighbor information so that it 221 can form proxy request to various nodes along the LSP. 223 The proxy LSR either replies with the requested Proxy information or 224 it validates that it has a label mapping for the specified FEC and 225 that it is authorized to send the specified MPLS echo request on 226 behalf of the initiator. 228 If the proxy LSR has a label mapping for the FEC and all 229 authorization checks have passed, the proxy LSR formats an MPLS echo 230 request. If the source address of the MPLS echo request is not to be 231 set to the Proxy Request source address, the initiator must include a 232 Reply-to Address object containing the source address to use in the 233 MPLS echo request. It then sends it inband of the LSP. 235 The receivers process the MPLS echo request as normal, sending their 236 MPLS echo replies back to the initiator. 238 If the proxy LSR failed to send a MPLS echo request as normal because 239 it encountered an issue while attempting to send, a MPLS proxy ping 240 reply message is sent back with a return code indicating that the 241 MPLS echo request could not be sent. 243 3. Proxy MPLS Echo Request / Reply Procedures 245 3.1. Procedures for the initiator 247 The initiator creates an MPLS proxy ping request message. 249 The message MUST contain a Target FEC Stack that describes the FEC 250 being tested. The topmost FEC in the target FEC stack is used at the 251 Proxy LSR to lookup the MPLS label stack that will be used to 252 encapsulate the MPLS echo request packet. 254 The MPLS Proxy Ping message MUST contain a Proxy Echo Parameters 255 object. In that object, the address type is set to either IPv4 or 256 IPv6. The Destination IP Address is set to the value to be used in 257 the MPLS echo request packet. If the Address Type is IPv4, an 258 address is from the range 127/8. If the Address Type is IPv6, an 259 address is from the range ::FFFF:7F00:0/104. 261 The Reply mode and Global Flags of the Proxy Echo Parameters object 262 are set to the values to be used in the MPLS echo request message 263 header. The Source UDP Port is set to the value to be used in the 264 MPLS echo request packet. The TTL is set to the value to be used in 265 the outgoing MPLS label stack. See Section 5.1 for further details. 267 If the FEC's Upstream/Downstream Neighbor address information is 268 required, the initiator sets the "Request for FEC neighbor 269 information" Proxy Flags in the Proxy Echo Parameters object. 271 If a Downstream Detailed or Downstream Mapping TLV is required in a 272 MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream 273 Detailed Mapping" or "Request for Downstream Mapping" Proxy Flags in 274 the Proxy Echo Parameters object. Only one of the two flags can be 275 set. 277 The Proxy Request reply mode is set with one of the reply modes 278 defined in [RFC4379] as appropriate. 280 A list of Next Hop IP Addresses MAY be included to limit the next 281 hops towards which the MPLS echo request message will be sent. These 282 are encoded as Next Hop sub-objects and included in the Proxy Echo 283 Parameters object. 285 Proxy Echo Parameter object MPLS payload size field may be set to 286 request that the MPLS echo request (including any IP and UDP header) 287 be zero padded to the specified size. When the payload size is non 288 zero, if sending the MPLS Echo Request involves using an IP header, 289 the DF bit MUST be set to 1. 291 Any of following objects MAY be included; these objects will be 292 copied into the MPLS echo request messages: 294 Pad 296 Vendor Enterprise Number 298 Reply TOS Byte 300 P2MP Responder Identifier [RFC6425] 302 Echo Jitter TLV [RFC6425] 304 Vendor Private TLVs 306 Downstream Detailed Mapping or Downstream Mapping objects MAY be 307 included. These objects will be matched to the next hop address for 308 inclusion in those particular MPLS echo request messages. 310 The message is then encapsulated in a UDP packet. The source UDP 311 port is chosen by the initiator; the destination UDP port is set to 312 3503. The IP header is set as follows: the source IP address is a 313 routable address of the initiator; the destination IP address is a 314 routable address to the Proxy LSR. The packet is then sent with the 315 IP TTL is set to 255. 317 3.2. Procedures for the proxy LSR 319 A proxy LSR that receives an MPLS proxy ping request message, parses 320 the packet to ensure that it is a well-formed packet. It checks that 321 the TLVs that are not marked "Ignore" are understood. If not, it 322 sets the Return Code set to "Malformed echo request received" or "TLV 323 not understood" (as appropriate), and the Subcode set to zero. If 324 the Reply Mode of the message header is not 1(Do not reply), an MPLS 325 proxy ping reply message SHOULD be sent as described below. In the 326 latter case, the misunderstood TLVs (only) are included in an Errored 327 TLVs object. 329 The Proxy LSR checks that the MPLS proxy ping request message did not 330 arrive via one of its exception processing paths. Packets arriving 331 via IP TTL expiry, IP destination address set to a Martian address or 332 label ttl expiry MUST be treated as "Unauthorized" packets. An MPLS 333 proxy ping reply message MAY be sent with a Return Code of , 334 "Proxy Ping not authorized". 336 The header fields Sender's Handle and Sequence Number are not 337 examined, but are saved to be included in the MPLS proxy ping reply 338 or MPLS echo request messages. 340 The proxy LSR validates that it has a label mapping for the specified 341 FEC, it then determines if it is an ingress, egress, transit or bud 342 node and sets the Return Code as appropriate. A new return code 343 (Replying router has FEC mapping for topmost FEC) has been defined 344 for the case where the Proxy LSR is an ingress (for example head of 345 the TE tunnel or a transit router) because the existing RFC4379 346 return codes don't match the situation. For example, when a Proxy 347 LSR is a transit router, it's not appropriate for the return code to 348 describe how the packet would transit because the Proxy Request 349 doesn't contain information about what input interface the an MPLS 350 echo request would be switched from at the Proxy LSR. 352 The proxy LSR then determines if it is authorized to send the 353 specified MPLS echo request on behalf of the initiator. A Proxy LSR 354 MUST be capable of filtering addresses to validate initiators. Other 355 filters on FECs or MPLS echo request contents MAY be applied. If a 356 filter has been invoked (i.e. configured) and an address does not 357 pass the filter, then an MPLS echo request message MUST NOT be sent, 358 and the event SHOULD be logged. An MPLS proxy ping reply message MAY 359 be sent with a Return Code of , "Proxy Ping not authorized". 361 The destination address specified in the Proxy Echo Parameters object 362 is checked to ensure that it conforms to the address allowed IPv4 or 363 IPv6 address range. If not, it sets the Return Code set to 364 "Malformed echo request received" and the Subcode set to zero. If 365 the Reply Mode of the message header is not 1, an MPLS proxy ping 366 reply message SHOULD be sent as described below. 368 If the "Request for FEC Neighbor Address info" flag is set, a 369 Upstream Neighbor Address Object and/or Downstream Neighbor Address 370 Object(s) is/are formatted for inclusion in the MPLS proxy ping 371 reply. If the Upstream or Downstream address is unknown they are not 372 included in the Proxy Reply. 374 If there are Next Hop sub-objects in the Proxy Echo Parameters 375 object, each address is examined to determine if it is a valid next 376 hop for this FEC. If any are not, Proxy Echo Parameters object 377 should be updated removing unrecognized Next Hop sub-objects. The 378 updated Proxy Echo Parameters object MUST be included in the MPLS 379 proxy ping reply. 381 If the "Request for Downstream Detailed Mapping" or "Request for 382 Downstream Mapping" flag is set, the LSR formats (for inclusions in 383 the MPLS proxy ping reply) a Downstream Detailed/Downstream Mapping 384 object for each interface over which the MPLS echo request will be 385 sent. 387 If the Proxy LSR is the egress for the FEC, the behavior of the proxy 388 LSR vary depending on whether the node is an Egress of a P2P LSP, a 389 P2MP LSP or MP2MP LSP. Additional details can be found in the 390 section describing "Handling when Proxy LSR it is egress for FEC". 392 If the Reply Mode of the Proxy Request message header is "1 - do not 393 reply", no MPLS proxy ping reply is sent. Otherwise an MPLS proxy 394 ping reply message or MPLS echo request should be sent as described 395 below. 397 3.2.1. Proxy LSR Handling when it is Egress for FEC 399 This sections describes the different behaviors for the Proxy LSR 400 when it's the Egress for the FEC. In the P2MP budnode and MP2MP 401 budnode and egress cases, different behavior is required. 403 When the Proxy LSR is the egress of a P2P FEC, a Proxy reply should 404 be sent to the initiator with the return code set to 3 (Reply router 405 is Egress for FEC) with return subcode set to 0. 407 When the Proxy LSR is the egress of a P2MP FEC, it can be either a 408 budnode or just an Egress. If the Proxy LSR is a Budnode, a Proxy 409 reply should be sent to the initiator with the return code set to 3 410 (Reply router is Egress for FEC) with return subcode set to 0 and DS/ 411 DDMAPs only if the Proxy initiator requested information to be 412 returned in a Proxy reply. If the Proxy LSR is a Budnode but not 413 requested to return a Proxy reply, the Proxy LSR should send packets 414 to the downstream neighbors (no Echo reply is sent to the Proxy 415 Initiator to indicate that the Proxy LSR is an egress). If the Proxy 416 LSR is just an egress, a Proxy reply should be sent to the initiator 417 with the return code set to 3 (Reply router is Egress for FEC) with 418 return subcode set to 0. 420 When the Proxy LSR is the egress of a MP2MP FEC, it can be either a 421 budnode or just an Egress. LSP pings sent from a leaf of a MP2MP has 422 different behavior in this case. MPLS echo request are sent to all 423 upstream/downstream neighbors. The Proxy LSRs need to be consistent 424 with this variation in behavior. If the Proxy LSR is a Budnode or 425 just an egress, a Proxy reply should be sent to the initiator with 426 the return code set to 3 (Reply router is Egress for FEC) with return 427 subcode set to 0 and DS/DDMAPs included only if the Proxy initiator 428 requested information to be returned in a Proxy reply. If the Proxy 429 LSR is not requested to return information in a proxy reply, the 430 Proxy LSR should send packets to all upstream/downstream neighbors as 431 would be done when sourcing an LSP ping from a M2MP leaf (no echo 432 reply is sent to the Proxy initiator indicating that the Proxy LSR is 433 an egress). 435 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply 437 When the Proxy LSR is a transit or bud node, downstream maps 438 corresponding to how the packet is transited can not be supplied 439 unless an ingress interface for the MPLS echo request is specified, 440 since this information is not available and since all valid output 441 paths are of interest, the Proxy LSR should include DS/DDMAP(s) to 442 describe the entire set of paths that the packet can be replicated, 443 like in the case where an LSP ping is initiated at the Proxy LSR. 444 For mLDP there is a DSMAP/DDMAP per upstream/downstream neighbor for 445 MP2MP LSPs, or per downstream neighbor in the P2MP LSP case. 447 When the Proxy LSR is a bud node or egress in a MP2MP LSP or a 448 budnode in a P2MP LSP, an LSP ping initiated from the Proxy LSR would 449 source packets only to the neighbors but not itself despite the fact 450 that the Proxy LSR is itself an egress for the FEC. In order to 451 match the behavior as seen from LSP Ping initiated at the Proxy LSR, 452 the Proxy Reply should contain DSMAP/DDMAPs for only the paths to the 453 upstream/downstream neighbors, but no DSMAP/DDMAP describing its own 454 egresses paths. The proxy LSR identifies that it's an egress for the 455 FEC using a different Proxy Reply return code. The Proxy reply 456 return code is either set to "Reply router has a mapping for the 457 topmost FEC" or "Reply router is Egress for the FEC". 459 3.2.3. Sending an MPLS proxy ping reply 461 The Reply mode, Sender's Handle and Sequence Number fields are copied 462 from the proxy ping request message. The objects specified above are 463 included. The message is encapsulated in a UDP packet. The source 464 IP address is a routable address of the proxy LSR; the source port is 465 the well-known UDP port for LSP ping. The destination IP address and 466 UDP port are copied from the source IP address and UDP port of the 467 echo request. The IP TTL is set to 255. 469 3.2.4. Sending the MPLS echo requests 471 A base MPLS echo request is formed as described in the next section. 472 The section below that describes how the base MPLS echo request is 473 sent on each interface. 475 3.2.4.1. Forming the base MPLS echo request 477 A Next_Hop_List is created as follows. If Next Hop sub-objects were 478 included in the received Proxy Parameters object, the Next_Hop_List 479 created from the address in those sub-objects as adjusted above. 480 Otherwise, the list is set to all the next hops to which the FEC 481 would be forwarded. 483 The proxy LSR then formats an MPLS echo request message. The Global 484 Flags and Reply Mode are copied from the Proxy Echo Parameters 485 object. The Return Code and Return Subcode are set to zero. 487 The Sender's Handle and Sequence Number are copied from the remote 488 echo request message. 490 The TimeStamp Sent is set to the time-of-day (in seconds and 491 microseconds) that the echo request is sent. The TimeStamp Received 492 is set to zero. 494 If the reply-to address object is present, it is used to set the echo 495 request source address, otherwise the echo request source address is 496 set to the proxy request source address. 498 The following objects are copied from the MPLS proxy ping request 499 message. Note that of these, only the Target FEC Stack is REQUIRED 500 to appear in the MPLS proxy ping request message. 502 Target FEC Stack 504 Pad 506 Vendor Enterprise Number 508 Reply TOS Byte 510 P2MP Responder Identifier [RFC6425] 512 Echo Jitter TLV [RFC6425] 514 Vendor Private TLVs 516 The message is then encapsulated in a UDP packet. The source UDP 517 port is copied from the Proxy Echo Parameters object. The 518 destination port copied from the proxy ping request message. 520 The source IP address is set to a routable address specified in the 521 reply-to-address object or the source address of the received proxy 522 request. Per usual the TTL of the IP packet is set to 1. 524 If the Explicit DSCP flag is set, the Requested DSCP byte is 525 examined. If the setting is permitted then the DSCP byte of the IP 526 header of the MPLS Echo Request message is set to that value. If the 527 Proxy LSR does not permit explicit control for the DSCP byte, the 528 MPLS Proxy Echo Parameters with the Explicit DSCP flag cleared MUST 529 be included in any MPLS proxy ping reply message to indicate why an 530 Echo Request was not sent. The return code MUST be set to , 531 "Proxy ping parameters need to be modified". If the Explicit DSCP 532 flag is not set, the Proxy LSR should set the Echo Request DSCP 533 settings to the value normally used to source LSP ping packets.. 535 3.2.4.2. Per interface sending procedures 537 The proxy LSR now iterates through the Next_Hop_List modifying the 538 base MPLS echo request to form the MPLS echo request packet which is 539 then sent on that particular interface. 541 For each next hop address, the outgoing label stack is determined. 542 The TTL for the label corresponding to the FEC specified in the FEC 543 stack is set such that the TTL on the wire will be othe TTL specified 544 in the Proxy Echo Parameters. If any additional labels are pushed 545 onto the stack, their TTLs are set to 255. 547 If the MPLS proxy ping request message contained Downstream Mapping/ 548 Downstream Detailed Mapping objects, they are examined. If the 549 Downstream IP Address matches the next hop address that Downstream 550 Mapping object is included in the MPLS echo request. 552 The packet is then transmitted on this interface. 554 4. Proxy Ping Request / Reply Messages 556 This document defines two new LSP Ping messages, the MPLS proxy ping 557 request and the MPLS proxy ping reply. 559 4.1. Proxy Ping Request / Reply Message formats 561 Except where noted, the definitions of all fields in the messages are 562 identical to those found in [RFC4379]. The messages have the 563 following format: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Version Number | MUST Be Zero | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Message Type | Reply mode | Return Code | Return Subcode| 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Sender's Handle | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Sequence Number | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | TLVs ... | 577 . . 578 . . 579 . . 580 | | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Version Number 585 The Version Number is currently 1. (Note: the Version Number 586 is to be incremented whenever a change is made that affects the 587 ability of an implementation to correctly parse or process an 588 MPLS echo request/reply. These changes include any syntactic 589 or semantic changes made to any of the fixed fields, or to any 590 TLV or sub-TLV assignment or format that is defined at a 591 certain version number. The Version Number may not need to be 592 changed if an optional TLV or sub-TLV is added.) 594 Message Type 596 Type Message 597 ---- ------- 598 3 MPLS proxy ping request 599 (Pending IANA assignment) 600 4 MPLS proxy ping reply 601 (Pending IANA assignment) 603 4.2. Proxy Ping Request Message contents 604 The MPLS proxy ping request message MAY contain the following 605 objects: 607 Type Object 608 ---- ----------- 609 1 Target FEC Stack 610 2 Downstream Mapping 611 3 Pad 612 5 Vendor Enterprise Number 613 10 Reply TOS Byte 615 11 P2MP Responder Identifier [RFC6425] 616 12 Echo Jitter TLV [RFC6425] 617 20 Downstream Detailed Mapping 618 30 Proxy Echo Parameters (Pending IANA assignment) 619 * Vendor Private TLVs 621 * TLVs types in the Vendor Private TLV Space MUST be 622 ignored if not understood 624 4.3. Proxy Ping Reply Message Contents 626 The MPLS proxy ping reply message MAY contain the following objects: 628 Type Object 629 ---- ----------- 630 1 Target FEC Stack 631 2 Downstream Mapping 632 5 Vendor Enterprise Number 633 9 Errored TLVs 634 20 Downstream Detailed Mapping 635 30 Proxy Echo Parameters 636 (Pending IANA assignment) 637 31 Upstream Neighbor Address 638 32 Downstream Neighbor Address (0 or more) 639 * Vendor Private TLVs 641 * TLVs types in the Vendor Private TLV Space MUST be 642 ignored if not understood 644 5. Object formats 645 5.1. Proxy Echo Parameters Object 647 The Proxy Echo Parameters object is a TLV that MUST be included in an 648 MPLS Proxy Echo Request message. The length of the TLV is 12 + K + 649 S, where K is the length of the Destination IP Address field and S is 650 the total length of the sub-objects. The Proxy Echo Parameters 651 object can be used to either to 1) control attributes used in 652 Composing and Sending an MPLS echo request or 2) query the Proxy LSR 653 for information about the topmost FEC in the target FEC stack but not 654 both. In the case where the Proxy LSR is being queried (ie 655 information needs to be returned in a Proxy Reply), no MPLS echo 656 request will be sent from the Proxy LSR. The MPLS Proxy Echo request 657 echo header's Reply Mode should be set to "Reply with Proxy Info". 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Address Type | Reply mode | Proxy Flags | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | TTL | Rqst'd DSCP | Source UDP Port | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Global Flags | MPLS Payload size | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | 669 : Destination IP Address : 670 | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | | 673 : : 674 : Sub-Objects : 675 : : 676 | | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Address Type 681 The type and length of the address found in the in the 682 Destination IP Address and Next Hop IP Addresses fields. 683 The type codes appear in the table below: 685 Address Family Type Length 687 IPv4 1 4 688 IPv6 3 16 690 Reply mode 692 The reply mode to be sent in the MPLS Echo Request message; the 693 values are as specified in [RFC4379]. 695 Proxy Flags 696 The Proxy Request Initiator sets zero, one or more of these 697 flags to request actions at the Proxy LSR. 699 Request for FEC Neighbor Address info 0x01 701 When set this requests that the proxy LSR supply the 702 Upstream and Downstream neighbor address information in the 703 MPLS proxy ping reply message. This flag is only applicable 704 for the topmost FEC in the FEC stack if the FEC types 705 corresponds with a P2MP or MP2MP LSPs. The Proxy LSR MUST 706 respond as applicable with a Upstream Neighbor Address 707 Object and Downstream Neighbor Address Object(s) in the MPLS 708 Proxy ping reply message. Upstream Neighbor Address Object 709 needs be included only if there is an upstream neighbor. 710 Similarly, one Downstream Neighbor Address Object needs to 711 be included for each Downstream Neighbor for which the LSR 712 learned bindings from. 714 Setting this flag will cause the proxy LSR to cancel sending 715 an Echo request. Information learned with such proxy reply 716 may be used by the proxy initiator to generate subsequent 717 proxy requests. 719 Request for Downstream Mapping 0x02 721 When set this requests that the proxy LSR supply a 722 Downstream Mapping object see [RFC4379] in the MPLS 723 proxy ping reply message. It's not valid 724 to have Request for Downstream Detailed Mapping flag set 725 when this flag is set. 727 Setting this flag will cause the proxy LSR to cancel sending 728 an Echo request. Information learned with such proxy reply 729 may be used by the proxy initiator to generate subsequent 730 proxy requests. 732 Request for Downstream Detailed Mapping 0x04 734 When set this requests that the proxy LSR supply a 735 Downstream Detailed Mapping object see [RFC6424] in the 736 MPLS proxy ping reply message. It's not valid 737 to have Request for Downstream Mapping flag set 738 when this flag is set. 740 Setting this flag will cause the proxy LSR to cancel sending 741 an Echo request. Information learned with such proxy reply 742 may be used by the proxy initiator to generate subsequent 743 proxy requests. 745 Explicit DSCP Request 0x08 747 When set this requests that the proxy LSR use 748 the supplied "Rqst'd DSCP" byte in the echo request message 750 TTL 752 The TTL to be used in the label stack entry corresponding to 753 the topmost FEC in the in the MPLS Echo Request packet. Valid 754 values are in the range [1,255]. A setting of 0 should be 755 ignored by the Proxy LSR. 757 Requested DSCP 759 This field is valid only if the Explicit DSCP flag is set. If 760 not set, the field MUST be zero on transmission and ignored on 761 receipt. When the flag is set this field contains the DSCP 762 value to be used in the MPLS echo request packet IP header. 764 Source UDP Port 766 The source UDP port to be sent in the MPLS Echo Request packet 768 Global Flags 770 The Global Flags to be sent in the MPLS Echo Request message 772 MPLS Payload Size 774 Used to request that the MPLS payload (IP header + UDP header 775 + MPLS echo request) be padded using a zero filled Pad TLV 776 so that the IP header, UDP header nad MPLS echo request total 777 the specified size. Field set to zero means no 778 size request is being made. If the requested size is less 779 than the minimum size required to form the MPLS echo request, 780 the request will be treated as a best effort request with 781 the Proxy LSR building the smallest possible packet (ie 782 not using a Pad TLV). The IP header DF bit should be set 783 when this field is non zero. 785 Destination IP Address 787 If the Address Type is IPv4, an address from the range 127/8; 788 If the Address Type is IPv6, an address from the range 789 ::FFFF:7F00:0/104 791 Sub-Objects 793 A TLV encoded list of sub-objects. Currently one is defined. 795 Sub-Type Length Value Field 796 -------- ------ ----------- 797 1 8+ Next Hop 799 5.1.1. Next Hop sub-Object 801 This sub-object is used to describe a particular next hop towards 802 which the Echo Request packet should be sent. If the topmost FEC in 803 the FEC-stack is a multipoint LSP, this sub-object may appear 804 multiple times. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Addr Type | MUST be Zero | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Next Hop IP Address (4 or 16 octets) | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Next Hop Interface (0, 4 or 16 octets) | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Address Type 818 Type Type of Next Hop Addr Length IF Length 820 1 IPv4 Numbered 4 4 821 2 IPv4 Unnumbered 4 4 822 3 IPv6 Numbered 16 16 823 4 IPv6 Unnumbered 16 4 824 5 IPv4 Protocol Adj 4 0 825 6 IPv6 Protocol Adj 16 0 827 Note: Types 1-4 correspond to the types in the DS Mapping 828 object. They are expected to populated with information 829 obtained through a previously returned DS Mapping object. 830 Types 5 and 6 are intended to be populated from the local 831 address information obtained from a previously returned 832 Previous Hop Address Object. 834 Next Hop IP Address 836 A next hop address that the echo request message is to 837 be sent towards 839 Next Hop Interface 841 Identifier of the interface through which the echo request 842 message is to be sent 844 5.2. Reply-to Address Object 846 Used to specify the MPLS echo request IP source address. This 847 address must be IP reachable via the Proxy LSR otherwise it will be 848 rejected. 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Address Type | MUST be Zero | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | | 856 : Reply-to Address : 857 | | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Address Type 862 A type code as specified in the table below: 864 Type Type of Address 866 1 IPv4 867 3 IPv6 869 5.3. Upstream Neighbor Address Object 870 0 1 2 3 871 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 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 |Upst Addr Type |Local Addr Type| MUST be Zero | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | | 876 : Upstream Address : 877 | | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | | 880 : Local Address : 881 | | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Upst Addr Type; Local Addr Type 886 These two fields determine the type and length of the 887 respective addresses. The codes are specified in the table 888 below: 890 Type Type of Address Length 892 0 No Address Supplied 0 893 1 IPv4 4 894 3 IPv6 16 896 Upstream Address 898 The address of the immediate upstream neighbor for the topmost 899 FEC in the FEC stack. If protocol adjacency exists by which 900 the label for this FEC was exchanged, this address MUST be the 901 address used in that protocol exchange. 903 Local Address 905 The local address used in the protocol adjacency exists by 906 which the label for this FEC was exchanged. 908 5.4. Downstream Neighbor Address Object 909 0 1 2 3 910 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 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 |Dnst Addr Type |Local Addr Type| MUST be Zero | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | | 915 : Downstream Address : 916 | | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | | 919 : Local Address : 920 | | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Dnst Addr Type; Local Addr Type 925 These two fields determine the type and length of the 926 respective addresses. The codes are specified in the table 927 below: 929 Type Type of Address Length 931 0 No Address Supplied 0 932 1 IPv4 4 933 3 IPv6 16 935 Downstream Address 937 The address of a immediate downstream neighbor for the topmost 938 FEC in the FEC stack. If protocol adjacency exists by which 939 the label for this FEC was exchanged, this address MUST be the 940 address used in that protocol exchange. 942 Local Address 944 The local address used in the protocol adjacency exists by 945 which the label for this FEC was exchanged. 947 6. Security Considerations 949 The mechanisms described in this document are intended to be used 950 within a Service Provider network and to be initiated only under the 951 authority of that administration. 953 If such a network also carries internet traffic, or permits IP access 954 from other administrations, MPLS proxy ping message SHOULD be 955 discarded at those points. This can be accomplished by filtering on 956 source address or by filtering all MPLS ping messages on UDP port. 958 Any node which acts as a proxy node SHOULD validate requests against 959 a set of valid source addresses. An implementation MUST provide such 960 filtering capabilities. 962 MPLS proxy ping request messages are IP addressed directly to the 963 Proxy node. If a node which receives an MPLS proxy ping message via 964 IP or Label TTL expiration, it MUST NOT be acted upon. 966 MPLS proxy ping request messages are IP addressed directly to the 967 Proxy node. If a MPLS Proxy ping request IP destination address is a 968 Martian Address, it MUST NOT be acted upon. 970 if a MPLS Proxy ping request IP source address is not IP reachable by 971 the Proxy LSR, the Proxy request MUST NOT be acted upon. 973 MPLS proxy ping requests are limited to making their request via the 974 specification of a FEC. This ensures that only valid MPLS echo 975 request messages can be created. No label spoofing attacks are 976 possible. 978 7. Acknowledgements 980 The authors would like to thank Nobo Akiya for his detailed review 981 and insightful commnets. 983 8. IANA Considerations 985 This document makes the following assignments (pending IANA action) 987 LSP Ping Message Types 989 Type Value Field 990 ---- ----------- 991 03(tba) MPLS proxy ping request 992 04(tba) MPLS proxy ping reply 994 Objects and Sub-Objects 996 Type Sub-Type Value Field 997 ---- -------- ----------- 998 22(tba) Proxy Echo Parameters 999 1 Next Hop 1000 23(tba) Reply-to Address 1001 24(tba) Upstream Neighbor Address 1002 25(tba) Downstream Neighbor Address 1004 Return Code [pending IANA assignment] 1006 Value Meaning 1007 ----- ------- 1008 16(tba) Proxy ping not authorized. 1009 17(tba) Proxy ping parameters need to be modified. 1010 18(tba) MPLS Echo Request Could not be sent. 1011 18(tba) Replying router has FEC mapping for topmost FEC. 1013 9. References 1015 9.1. Normative References 1017 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1018 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1019 February 2006. 1021 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1022 Performing Label Switched Path Ping (LSP Ping) over MPLS 1023 Tunnels", RFC 6424, November 2011. 1025 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 1026 S., and T. Nadeau, "Detecting Data-Plane Failures in 1027 Point-to-Multipoint MPLS - Extensions to LSP Ping", 1028 RFC 6425, November 2011. 1030 9.2. Informative References 1032 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1033 "Extensions to Resource Reservation Protocol - Traffic 1034 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1035 Switched Paths (LSPs)", RFC 4875, May 2007. 1037 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1038 "Label Distribution Protocol Extensions for Point-to- 1039 Multipoint and Multipoint-to-Multipoint Label Switched 1040 Paths", RFC 6388, November 2011. 1042 Authors' Addresses 1044 George Swallow 1045 Cisco Systems 1046 1414 Massachusetts Ave 1047 Boxborough, MA 01719 1048 USA 1050 Email: swallow@cisco.com 1052 Vanson Lim 1053 Cisco Systems 1054 1414 Massachusetts Avenue 1055 Boxborough, MA 01719 1056 USA 1058 Email: vlim@cisco.com 1060 Sam Aldrin 1061 Huawei Technologies 1062 2330 Central Express Way 1063 Santa Clara, CA 95951 1064 USA 1066 Email: aldrin.ietf@gmail.com