idnits 2.17.1 draft-lim-mpls-proxy-lsp-ping-00.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 (October 12, 2012) is 4214 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: April 15, 2013 October 12, 2012 7 Proxy LSP Ping 8 draft-lim-mpls-proxy-lsp-ping-00 10 Abstract 12 This document defines a means of remotely initiating Multiprotocol 13 Label Switched Protocol Pings on Label Switched Paths. A proxy ping 14 request is sent to any Label Switching Routers along a Label Switched 15 Path. The primary motivations for this facility are first to limit 16 the number of messages and related processing when using LSP Ping in 17 large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ 18 root tracing. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 15, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2. Proxy Ping Overview . . . . . . . . . . . . . . . . . . . . . 4 69 3. Proxy MPLS Echo Request / Reply Procedures . . . . . . . . . . 5 70 3.1. Procedures for the initiator . . . . . . . . . . . . . . . 5 71 3.2. Procedures for the proxy LSR . . . . . . . . . . . . . . . 7 72 3.2.1. Downstream Detailed/Downstream Maps in Proxy Reply . . 8 73 3.2.2. Sending an MPLS proxy ping reply . . . . . . . . . . . 9 74 3.2.3. Sending the MPLS echo requests . . . . . . . . . . . . 9 75 3.2.3.1. Forming the base MPLS echo request . . . . . . . . 9 76 3.2.3.2. Per interface sending procedures . . . . . . . . . 10 77 4. Proxy Ping Request / Reply Messages . . . . . . . . . . . . . 11 78 4.1. Proxy Ping Request / Reply Message formats . . . . . . . . 11 79 4.2. Proxy Ping Request Message contents . . . . . . . . . . . 12 80 4.3. Proxy Ping Reply Message Contents . . . . . . . . . . . . 12 81 5. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 12 82 5.1. Proxy Echo Parameters Object . . . . . . . . . . . . . . . 12 83 5.1.1. Next Hop sub-Object . . . . . . . . . . . . . . . . . 15 84 5.2. Reply-to Address Object . . . . . . . . . . . . . . . . . 16 85 5.3. Upstream Neighbor Address Object . . . . . . . . . . . . . 17 86 5.4. Downstream Neighbor Address Object . . . . . . . . . . . . 18 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 It is anticipated that very large Point-to-Multipoint (P2MP) and 97 Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) will 98 exist. Further it is anticipated that many of the applications for 99 P2MP/MP2MP tunnels will require OAM that is both rigorous and 100 scalable. 102 Suppose one wishes to trace a P2MP LSP to localize a fault which is 103 affecting one egress or a set of egresses. Suppose one follows the 104 normal procedure for tracing - namely repeatedly pinging from the 105 root, incrementing the TTL by one after each three or so pings. Such 106 a procedure has the potential for producing a large amount of 107 processing at the P2MP-LSP midpoints and egresses. It also could 108 produce an unwieldy number of replies back to the root. 110 One alternative would be to begin sending pings from points at or 111 near the affected egress(es) and working backwards toward the root. 112 The TTL could be held constant as say two, limiting the number of 113 responses to the number of next-next-hops of the point where a ping 114 is initiated. 116 This document defines protocol extensions to MPLS ping [RFC4379] to 117 allow a third party to remotely cause an MPLS echo request message to 118 be sent down a Label Switched Path (LSP) or part of an LSP. The 119 procedure described in the paragraphs above does require that the 120 initiator know the previous-hop node to the one which was pinged on 121 the prior iteration. This information is readily available in 122 [RFC4875]. This also document provides a means for obtaining this 123 information for[RFC6388]. 125 While the motivation for this document came from multicast scaling 126 concerns, its applicability may be wider. However other uses of this 127 facility are beyond the scope of this document. In particular, the 128 procedures defined in this document only allow testing of a FEC stack 129 consisting of a single FEC. It also does not allow the initiator to 130 specify the label assigned to that FEC, nor does it allow the 131 initiator to cause any additional labels to be added to the label 132 stack of the actual MPLS echo request message. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119. 140 The term "Must Be Zero" (MBZ) is used in object descriptions for 141 reserved fields. These fields MUST be set to zero when sent and 142 ignored on receipt. 144 Based on context the terms leaf and egress are used interchangeably. 145 Egress is used where consistency with[RFC4379] was deemed 146 appropriate. Receiver is used in the context of receiving protocol 147 messages. 149 [Note (to be removed after assignments occur): = to be assigned 150 by IANA] 152 2. Proxy Ping Overview 154 This document defines a protocol interaction between a first node and 155 a node which is part of an LSP to allow the first node to request 156 that that second node initiate an LSP ping for the LSP on behalf of 157 the first node. Two new LSP Ping messages are defined for remote 158 pinging, the MPLS proxy ping request and the MPLS proxy ping reply. 160 A remote ping operation on a P2MP LSP generally involves at least 161 three LSRs; in some scenarios none of these are the ingress (root) or 162 an egress (leaf) of the LSP. 164 We refer to these nodes with the following terms: 166 Initiator - the node which initiates the ping operation by sending 167 an MPLS proxy ping request message 169 Proxy LSR - the node which is the destination of the MPLS proxy 170 request message and potential initiator of the MPLS echo request 172 Receiver(s) - the nodes which receive the MPLS echo request 173 message 175 Responder - A receiver that responds to a MPLS Proxy Ping Request 176 or an MPLS Echo Request 178 We note that in some scenarios, the initiator could also be the 179 responder, in which case the response would be internal to the node. 181 The initiator formats an MPLS proxy ping request message and sends it 182 to the proxy LSR, a node it believes to be on the path of the LSP. 183 This message specifies the MPLS echo request to be sent inband of the 184 LSP. It may request the proxy LSR to either Reply with Proxy 185 information or the send a MPLS echo request. The initiator requests 186 Proxy information so that it can learn additional information it 187 needs to use to form a subsequent MPLS Proxy Ping request. For 188 example during LSP traceroute an initiator needs the downstream map 189 information to form an Echo request. An initiator may also want to 190 learn a Proxy LSR's FEC neighbor information so that it can form 191 proxy request to various nodes along the LSP. 193 The proxy LSR either replies with the requested Proxy information or 194 it validates that it has a label mapping for the specified FEC and 195 that it is authorized to send the specified MPLS echo request on 196 behalf of the initiator. 198 If the proxy LSR has a label mapping for the FEC and all 199 authorization checks have passed, the proxy LSR formats an MPLS echo 200 request. If the source address of the IP packet is not the 201 initiator, it includes a Reply-to Address object containing the 202 initiator's address. It then sends it inband of the LSP. 204 The receivers process the MPLS echo request as normal, sending their 205 MPLS echo replies back to the initiator. 207 If the proxy LSR failed to send a MPLS echo request as normal because 208 it encountered and issue while attempting to send, a MPLS proxy ping 209 reply message is sent back with a return code indicating that the 210 MPLS echo request could not be sent. 212 3. Proxy MPLS Echo Request / Reply Procedures 214 3.1. Procedures for the initiator 216 The initiator creates an MPLS proxy ping request message. 218 The message MUST contain a Target FEC Stack that describes the FEC 219 being tested. The topmost FEC in the target FEC stack is used at 220 that the Proxy Router to lookup the MPLS label stack that will be 221 used to encapsulate the MPLS echo request packet. 223 The MPLS Proxy Ping message MUST contain a Proxy Echo Parameters 224 object. In that object, the address type is set to either IPv4 or 225 IPv6. The Destination IP Address is set to the value to be used in 226 the MPLS echo request packet. If the Address Type is IPv4, an 227 address from the range 127/8. If the Address Type is IPv6, an 228 address from the range ::FFFF:7F00:0/104. 230 The Reply mode and Global Flags of the Proxy Echo Parameters object 231 are set to the values to be used in the MPLS echo request message 232 header. The Source UDP Port is set to the value to be used in the 233 MPLS echo request packet. The TTL is set to the value to be used in 234 the outgoing MPLS label stack. See Section 5.1 for further details. 236 If the FEC's Upstream/Downstream Neighbor address information is 237 required, the initiator sets the "Request for FEC neighbor 238 information" Proxy Flags in the Proxy Echo Parameters object. 240 If a Downstream Detailed or Downstream Mapping TLV is required in a 241 MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream 242 Detailed Mapping" or "Request for Downstream Mapping" Proxy Flags in 243 the Proxy Echo Parameters object. Only one of the two flags can be 244 set. 246 The Proxy Request reply mode is set with one of the reply modes 247 defined in [RFC4379] as appropriate. 249 A list of Next Hop IP Addresses MAY be included to limit the next 250 hops towards which the MPLS echo request message will be sent. These 251 are encoded as Next Hop sub-objects and included in the Proxy Echo 252 Parameters object. 254 Proxy Echo Parameter object MPLS payload size field may be set to 255 request that the MPLS echo request (including any IP and UDP header) 256 be zero padded to the specified size. When the payload size is non 257 zero, if sending the MPLS Echo Request involves using an IP header, 258 the DF bit MUST be set to 1. 260 Any of following objects MAY be included; these objects will be 261 copied into the MPLS echo request messages: 263 Pad 265 Vendor Enterprise Number 267 Reply TOS Byte 269 P2MP Egress Identifier [RFC6425] 271 Echo Jitter TLV [RFC6425] 273 Vendor Private TLVs 275 Downstream Detailed Mapping or Downstream Mapping objects MAY be 276 included. These objects will be matched to the next hop address for 277 inclusion in those particular MPLS echo request messages. 279 The message is then encapsulated in a UDP packet. The source UDP 280 port is chosen by the sender; the destination UDP port is set to 281 3503. The IP header is set as follows: the source IP address is a 282 routable address of the sender; the destination IP address is a 283 routable address of the midpoint. The packet is then sent with the 284 IP TTL is set to 255. 286 3.2. Procedures for the proxy LSR 288 A proxy LSR that receives an MPLS proxy ping request message, parses 289 the packet to ensure that it is a well-formed packet. It checks that 290 the TLVs that are not marked "Ignore" are understood. If not, it 291 sets the Return Code set to "Malformed echo request received" or "TLV 292 not understood" (as appropriate), and the Subcode set to zero. If 293 the Reply Mode of the message header is not 1(Do not reply), an MPLS 294 proxy ping reply message SHOULD be sent as described below. In the 295 latter case, the misunderstood TLVs (only) are included in an Errored 296 TLVs object. 298 The Proxy LSR checks that the MPLS proxy ping request message did not 299 arrive via one of its exception processing paths. Packets arriving 300 via IP TTL expiry, IP destination address set to a Martian address or 301 label ttl expiry MUST be treated as "Unauthorized" packets. An MPLS 302 proxy ping reply message MAY be sent with a Return Code of , 303 "Remote Ping not authorized". 305 The header fields Sender's Handle and Sequence Number are not 306 examined, but are saved to be included in the MPLS proxy ping reply 307 and MPLS echo request messages. 309 The proxy LSR validates that it has a label mapping for the specified 310 FEC, it then determines if it is an ingress, egress, transit or bud 311 node and sets the Return Code as appropriate. A new return code (FEC 312 found) has been defined for the case where the Proxy LSR is an 313 ingress (for example head of the TE tunnel or a transit router) 314 because the existing RFC4379 return codes don't match the situation. 315 For example, when a Proxy LSR is a transit router, it's not 316 appropriate for the return code to describe how the packet would 317 transit because the Proxy Request doesn't contain information about 318 what input interface the an MPLS echo request would be switched from 319 at the Proxy LSR. 321 The proxy LSR then determines if it is authorized to send the 322 specified MPLS echo request on behalf of the initiator. A Proxy LSR 323 MUST be capable of filtering addresses to validate initiators. Other 324 filters on FECs or MPLS echo request contents MAY be applied. If a 325 filter has been invoked (i.e. configured) and an address does not 326 pass the filter, then an MPLS echo request message MUST NOT be sent, 327 and the event SHOULD be logged. An MPLS proxy ping reply message MAY 328 be sent with a Return Code of , "Remote Ping not authorized". 330 The destination address specified in the Proxy Echo Parameters object 331 is checked to ensure that it conforms to the address allowed IPv4 or 332 IPv6 address range. If not, it sets the Return Code set to 333 "Malformed echo request received" and the Subcode set to zero. If 334 the Reply Mode of the message header is not 1, an MPLS proxy ping 335 reply message SHOULD be sent as described below. 337 If the "Request for FEC Neighbor Address info" flag is set, a 338 Upstream Neighbor Address Object and/or Downstream Neighbor Address 339 Object(s) is/are formatted for inclusion in the MPLS proxy ping 340 reply. If the Upstream or Downstream address is unknown they are not 341 included in the Proxy Reply. 343 If there are Next Hop sub-objects in the Proxy Echo Parameters 344 object, each address is examined to determine if it is a next hop for 345 this FEC. If any are not, those sub-objects are from the Proxy Echo 346 Parameters object. The updated object is included in the MPLS proxy 347 ping reply. 349 If the "Request for Downstream Detailed Mapping" or "Request for 350 Downstream Mapping" flag is set the LSR formats (for inclusions in 351 the MPLS proxy ping reply) a Downstream Detailed/Downstream Mapping 352 object for each interface over which the MPLS echo request will be 353 sent. 355 If the Proxy LSR is the egress of the FEC, a Proxy reply should be 356 sent to the initiator with the return code set to 3 (Reply router is 357 Egress for FEC) with return subcode set to 0. 359 If the Reply Mode of the message header is 1, 2 or 3 and no errors or 360 modifications have occurred no MPLS proxy ping reply is sent. 361 Otherwise an MPLS proxy ping reply message SHOULD be sent as 362 described below. 364 3.2.1. Downstream Detailed/Downstream Maps in Proxy Reply 366 When the Proxy LSR is a transit or bud node, downstream maps 367 corresponding to how the packet is transited can not be supplied 368 unless an ingress interface for the MPLS echo request is specified, 369 since this information is not available of useful since all valid 370 output paths are of interest, the Proxy LSR should include DS/ 371 DDMAP(s) to describe the entire set of paths that the packet can be 372 replicated to assuming that the packet was sourced from the Proxy 373 LSR. For mLDP there is a DSMAP/DDMAP per upstream/downstream 374 neighbor for MP2MP LSPs, or per donwstream neighbor in the P2MP LSP 375 case. 377 When the Proxy LSR is a bud node or egress in a MP2MP LSP, the Proxy 378 Reply should contain DSMAP/DDMAPs assuming that the packet is being 379 sourced from a leaf. In this case, there will be no DSMAP/DDMAP 380 describing the egresses. The Proxy reply return code is either set 381 to "Reply router found mapping for the FEC" or "Reply router is 382 Egress for the FEC" is returned. 384 3.2.2. Sending an MPLS proxy ping reply 386 The Reply mode, Sender's Handle and Sequence Number fields are copied 387 from the proxy ping request message. The objects specified above are 388 included. The message is encapsulated in a UDP packet. The source 389 IP address is a routable address of the proxy LSR; the source port is 390 the well-known UDP port for LSP ping. The destination IP address and 391 UDP port are copied from the source IP address and UDP port of the 392 echo request. The IP TTL is set to 255. 394 3.2.3. Sending the MPLS echo requests 396 A base MPLS echo request is formed as described in the next section. 397 The section below that describes how the base MPLS echo request is 398 sent on each interface. 400 3.2.3.1. Forming the base MPLS echo request 402 A Next_Hop_List is created as follows. If Next Hop sub-objects were 403 included in the received Proxy Parameters object, the Next_Hop_List 404 created from the address in those sub-objects as adjusted above. 405 Otherwise, the list is set to all the next hops to which the FEC 406 would be forwarded. 408 The proxy LSR then formats an MPLS echo request message. The Global 409 Flags and Reply Mode are copied from the Proxy Echo Parameters 410 object. The Return Code and Return Subcode are set to zero. 412 The Sender's Handle and Sequence Number are copied from the remote 413 echo request message. 415 The TimeStamp Sent is set to the time-of-day (in seconds and 416 microseconds) that the echo request is sent. The TimeStamp Received 417 is set to zero. 419 A Reply-to Address object containing the initiator's address is 420 included. 422 The following objects are copied from the MPLS proxy ping request 423 message. Note that of these, only the Target FEC Stack is REQUIRED 424 to appear in the MPLS proxy ping request message. 426 Target FEC Stack 427 Pad 429 Vendor Enterprise Number 431 Reply TOS Byte 433 P2MP Egress Identifier [RFC6425] 435 Echo Jitter TLV [RFC6425] 437 Vendor Private TLVs 439 The message is then encapsulated in a UDP packet. The source UDP 440 port is copied from the Proxy Echo Parameters object. The 441 destination port copied from the proxy ping request message. 443 The source IP address is set to a routable address of the proxy LSR. 444 Per usual the TTL of the IP packet is set to 1. 446 If the Explicit DSCP flag is set, the Requested DSCP byte is 447 examined. If the setting is permitted then the DSCP byte of the IP 448 header of the MPLS Echo Request message is set to that value. 449 Otherwise the DSCP byte is set to a default value. In this case the 450 MPLS Proxy Echo Parameters with the Explicit DSCP flag cleared MUST 451 be included in any MPLS proxy ping reply message. The return code 452 MUST be set to , "Proxy ping parameters modified". The DSCP 453 field of the MPLS Proxy Echo Parameters SHOULD be set to the actual 454 value used. 456 3.2.3.2. Per interface sending procedures 458 The proxy LSR now iterates through the Next_Hop_List modifying the 459 base MPLS echo request to form the MPLS echo request packet which is 460 then sent on that particular interface. 462 For each next hop address, the outgoing label stack is determined. 463 The TTL for the label corresponding to the FEC specified in the FEC 464 stack is set such that the TTL on the wire will be one less than the 465 TTL specified in the Proxy Echo Parameters. If any additional labels 466 are pushed onto the stack, their TTLs are set to 255. 468 If the MPLS proxy ping request message contained Downstream Mapping/ 469 Enhanced Downstream Mapping objects, they are examined. If the 470 Downstream IP Address matches the next hop address that Downstream 471 Mapping object is included in the MPLS echo request. 473 The packet is then transmitted on this interface. 475 4. Proxy Ping Request / Reply Messages 477 This document defines two new LSP Ping messages, the MPLS proxy ping 478 request and the MPLS proxy ping reply. 480 4.1. Proxy Ping Request / Reply Message formats 482 Except where noted, the definitions of all fields in the messages are 483 identical to those found in [RFC4379]. The messages have the 484 following format: 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Version Number | MUST Be Zero | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Message Type | Reply mode | Return Code | Return Subcode| 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Sender's Handle | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Sequence Number | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | TLVs ... | 497 . . 498 . . 499 . . 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Version Number 505 The Version Number is currently 1. (Note: the Version Number 506 is to be incremented whenever a change is made that affects the 507 ability of an implementation to correctly parse or process an 508 MPLS echo request/reply. These changes include any syntactic 509 or semantic changes made to any of the fixed fields, or to any 510 TLV or sub-TLV assignment or format that is defined at a 511 certain version number. The Version Number may not need to be 512 changed if an optional TLV or sub-TLV is added.) 514 Message Type 516 Type Message 517 ---- ------- 518 5 MPLS proxy ping request 519 (Pending IANA assignment) 520 6 MPLS proxy ping reply 521 (Pending IANA assignment) 523 4.2. Proxy Ping Request Message contents 525 The MPLS proxy ping request message MAY contain the following 526 objects: 528 Type Object 529 ---- ----------- 530 1 Target FEC Stack 531 2 Downstream Mapping 532 3 Pad 533 5 Vendor Enterprise Number 534 10 Reply TOS Byte 536 11 P2MP Egress Identifier [RFC6425] 537 12 Echo Jitter TLV [RFC6425] 538 20 Downstream Detailed Mapping 539 30 Proxy Echo Parameters (Pending IANA assignment) 540 Vendor Private TLVs 542 4.3. Proxy Ping Reply Message Contents 544 The MPLS proxy ping reply message MAY contain the following objects: 546 Type Object 547 ---- ----------- 548 1 Target FEC Stack 549 2 Downstream Mapping 550 5 Vendor Enterprise Number 551 9 Errored TLVs 552 20 Downstream Detailed Mapping 553 30 Proxy Echo Parameters 554 (Pending IANA assignment) 555 31 Upstream Neighbor Address 556 32 Downstream Neighbor Address (0 or more) 557 Vendor Private objects 559 5. Object formats 561 5.1. Proxy Echo Parameters Object 563 The Proxy Echo Parameters object is a TLV that MUST be included in an 564 MPLS Proxy Echo Request message. The length of the TLV is 12 + K + 565 S, where K is the length of the Destination IP Address field and S is 566 the total length of the sub-objects. The Proxy Echo Parameters 567 object can be used to either to 1) control attributes used in 568 Composing and Sending an MPLS echo request or 2) query the Proxy LSR 569 for information about the topmost FEC in the target FEC stack but not 570 both. In the case where the Proxy LSR is being queried (ie 571 information needs to be returned in a Proxy Reply), no MPLS echo 572 request will be sent from the Proxy LSR. The MPLS Proxy Echo request 573 echo header's Reply Mode should be set to "Reply with Proxy Info". 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Address Type | Reply mode | Proxy Flags | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | TTL | Rqst'd DSCP | Source UDP Port | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Global Flags | MPLS Payload size | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | | 585 : Destination IP Address : 586 | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | | 589 : : 590 : Sub-Objects : 591 : : 592 | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Address Type 597 The type and length of the address found in the in the 598 Destination IP Address and Next Hop IP Addresses fields. 599 The type codes appear in the table below: 601 Address Family Type Length 603 IPv4 1 4 604 IPv6 3 16 606 Reply mode 608 The reply mode to be sent in the MPLS Echo Request message; the 609 values are as specified in [RFC4379]. 611 Proxy Flags 613 Request for FEC Neighbor Address info 0x01 615 When set this requests that the proxy LSR supply the 616 Upstream and Downstream neighbor address information in the 617 MPLS proxy ping reply message. This flag is only applicable 618 for the topmost FEC in the FEC stack if the FEC types 619 corresponds with a P2MP or MP2MP LSPs. The Proxy LSR MUST 620 respond as spplicable with a Upstream Neighbor Address 621 Object and Downstream Neighbor Address Object(s) in the MPLS 622 Proxy ping reply message. Upstream Neighbor Address Object 623 needs be included only if there is an upstream neighbor. 624 Similarly, one Downstream Neighbor Address Object needs to 625 be included for each Downstream Neighbor for which the LSR 626 learned bindings from. 628 Setting this flag will cause the proxy LSR to cancel 629 sending an Echo request as the information being requested 630 needs to be returned for use in a subsequent Proxy Request. 632 Request for Downstream Mapping 0x02 634 When set this requests that the proxy LSR supply a 635 Downstream Mapping object see [RFC4379] in the MPLS 636 proxy ping reply message. It's not valid 637 to have Request for Enhanced Downstream Mapping flag set 638 when this flag is set. 640 Setting this flag will cause the proxy LSR to cancel 641 sending an Echo request as the information being requested 642 needs to be returned for use in a subsequent Proxy Request. 644 Request for Enhanced Downstream Mapping 0x04 646 When set this requests that the proxy LSR supply a 647 Enhanced Downstream Mapping object see [RFC6424] in the 648 MPLS proxy ping reply message. It's not valid 649 to have Request for Downstream Mapping flag set 650 when this flag is set. 652 Setting this flag will cause the proxy LSR to cancel 653 sending an Echo request as the information being requested 654 needs to be returned for use in a subsequent Proxy Request. 656 Explicit DSCP Request 0x08 658 When set this requests that the proxy LSR use 659 the supplied "Rqst'd DSCP" byte in the echo request message 661 TTL 663 The TTL to be used in the label stack entry corresponding to 664 the topmost FEC in the in the MPLS Echo Request packet 666 Requested DSCP 668 This field is valid only if the Explicit DSCP flag is set. If 669 not set, the field MUST be zero on transmission and ignored on 670 receipt. When the flag is set this field contains the DSCP 671 value to be used in the MPLS echo request packet IP header. 673 Source UDP Port 675 The source UDP port to be sent in the MPLS Echo Request packet 677 Global Flags 679 The Global Flags to be sent in the MPLS Echo Request message 681 MPLS Payload Size 683 Used to request that the MPLS payload (IP header + UDP header 684 + MPLS echo request) be padded using a zero filled Pad TLV 685 so that the IP header, UDP header nad MPLS echo request total 686 the specified size. Field set to zero means no 687 size request is being made. If the requested size is less 688 than the minimum size required to form the MPLS echo request, 689 the request will be treated as a best effort request with 690 the Proxy LSR building the smallest possible packet (ie 691 not using a Pad TLV). The IP header DF bit should be set 692 when this field is non zero. 694 Destination IP Address 696 If the Address Type is IPv4, an address from the range 127/8; 697 If the Address Type is IPv6, an address from the range 698 ::FFFF:7F00:0/104 700 Sub-Objects 702 A TLV encoded list of sub-objects. Currently one is defined. 704 Sub-Type Length Value Field 705 -------- ------ ----------- 706 1 8+ Next Hop 708 5.1.1. Next Hop sub-Object 710 This sub-object is used to describe a particular next hop towards 711 which the Echo Request packet should be sent. If the topmost FEC in 712 the FEC-stack is a multipoint LSP, this sub-object may appear 713 multiple times. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Addr Type | MUST be Zero | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Next Hop IP Address (4 or 16 octets) | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Next Hop Interface (0, 4 or 16 octets) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 Address Type 727 Type Type of Next Hop Addr Length IF Length 729 1 IPv4 Numbered 4 4 730 2 IPv4 Unnumbered 4 4 731 3 IPv6 Numbered 16 16 732 4 IPv6 Unnumbered 16 4 733 5 IPv4 Protocol Adj 4 0 734 6 IPv6 Protocol Adj 16 0 736 Note: Types 1-4 correspond to the types in the DS Mapping 737 object. They are expected to populated with information 738 obtained through a previously returned DS Mapping object. 739 Types 5 and 6 are intended to be populated from the local 740 address information obtained from a previously returned 741 Previous Hop Address Object. 743 Next Hop IP Address 745 A next hop address that the echo request message is to 746 be sent towards 748 Next Hop Interface 750 Identifier of the interface through which the echo request 751 message is to be sent 753 5.2. Reply-to Address Object 755 Used to specify the MPLS echo request IP source address. This 756 address must be IP reachable via the Proxy LSR otherwise it will be 757 rejected. 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Address Type | MUST be Zero | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | | 765 : Reply-to Address : 766 | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Address Type 771 A type code as specified in the table below: 773 Type Type of Address 775 1 IPv4 776 3 IPv6 778 5.3. Upstream Neighbor Address Object 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 |Upst Addr Type |Local Addr Type| MUST be Zero | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 : Upstream Address : 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | | 789 : Local Address : 790 | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 Upst Addr Type; Local Addr Type 795 These two fields determine the type and length of the 796 respective addresses. The codes are specified in the table 797 below: 799 Type Type of Address Length 801 0 No Address Supplied 0 802 1 IPv4 4 803 3 IPv6 16 805 Upstream Address 807 The address of the immediate upstream neighbor for the topmost 808 FEC in the FEC stack. If protocol adjacency exists by which 809 the label for this FEC was exchanged, this address MUST be the 810 address used in that protocol exchange. 812 Local Address 814 The local address used in the protocol adjacency exists by 815 which the label for this FEC was exchanged. 817 5.4. Downstream Neighbor Address Object 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |Dnst Addr Type |Local Addr Type| MUST be Zero | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | | 824 : Downstream Address : 825 | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | | 828 : Local Address : 829 | | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Upst Addr Type; Local Addr Type 834 These two fields determine the type and length of the 835 respective addresses. The codes are specified in the table 836 below: 838 Type Type of Address Length 840 0 No Address Supplied 0 841 1 IPv4 4 842 3 IPv6 16 844 Upstream Address 846 The address of a immediate downstream neighbor for the topmost 847 FEC in the FEC stack. If protocol adjacency exists by which 848 the label for this FEC was exchanged, this address MUST be the 849 address used in that protocol exchange. 851 Local Address 853 The local address used in the protocol adjacency exists by 854 which the label for this FEC was exchanged. 856 6. Security Considerations 858 The mechanisms described in this document are intended to be used 859 within a Service Provider network and to be initiated only under the 860 authority of that administration. 862 If such a network also carries internet traffic, or permits IP access 863 from other administrations, MPLS proxy ping message SHOULD be 864 discarded at those points. This can be accomplished by filtering on 865 source address or by filtering all MPLS ping messages on UDP port. 867 Any node which acts as a proxy node SHOULD validate requests against 868 a set of valid source addresses. An implementation MUST provide such 869 filtering capabilities. 871 MPLS proxy ping request messages are IP addressed directly to the 872 Proxy node. If a node which receives an MPLS proxy ping message via 873 IP or Label TTL expiration, it MUST NOT be acted upon. 875 MPLS proxy ping request messages are IP addressed directly to the 876 Proxy node. If a MPLS Proxy ping request IP destination address is a 877 Martian Address, it MUST NOT be acted upon. 879 if a MPLS Proxy ping request IP source address is not IP reachable, 880 it MUST NOT be acted upon. 882 MPLS proxy ping requests are limited to making their request via the 883 specification of a FEC. This ensures that only valid MPLS echo 884 request messages can be created. No label spoofing attacks are 885 possible. 887 7. IANA Considerations 889 This document makes the following assignments (pending IANA action) 891 LSP Ping Message Types 893 Type Value Field 894 ---- ----------- 895 03(tba) MPLS proxy ping request message 896 04(tba) MPLS proxy ping reply 898 Objects and Sub-Objects 900 Type Sub-Type Value Field 901 ---- -------- ----------- 902 22(tba) Proxy Echo Parameters 903 1 Next Hop 904 23(tba) Reply-to Address 905 24(tba) Upstream Neighbor Address 906 25(tba) Downstream Neighbor Address 908 Return Code [pending IANA assignment] 910 Value Meaning 911 ----- ------- 912 16(tba) Proxy ping not authorized. 913 17(tba) Proxy ping parameters need to be modified. 914 18(tba) MPLS Echo Request Could not be sent. 915 18(tba) Replying router has FEC mapping for topmost FEC. 917 8. References 919 8.1. Normative References 921 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 922 Label Switched (MPLS) Data Plane Failures", RFC 4379, 923 February 2006. 925 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 926 Performing Label Switched Path Ping (LSP Ping) over MPLS 927 Tunnels", RFC 6424, November 2011. 929 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 930 S., and T. Nadeau, "Detecting Data-Plane Failures in 931 Point-to-Multipoint MPLS - Extensions to LSP Ping", 932 RFC 6425, November 2011. 934 8.2. Informative References 936 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 937 "Extensions to Resource Reservation Protocol - Traffic 938 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 939 Switched Paths (LSPs)", RFC 4875, May 2007. 941 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 942 "Label Distribution Protocol Extensions for Point-to- 943 Multipoint and Multipoint-to-Multipoint Label Switched 944 Paths", RFC 6388, November 2011. 946 Authors' Addresses 948 George Swallow 949 Cisco Systems 950 1414 Massachusetts Ave 951 Boxborough, MA 01719 952 USA 954 Email: swallow@cisco.com 956 Vanson Lim 957 Cisco Systems 958 1414 Massachusetts Avenue 959 Boxborough, MA 01719 960 USA 962 Email: vlim@cisco.com