idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- ** There are 101 instances of too long lines in the document, the longest one being 9 characters in excess of 72. 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 (July 05, 2013) is 3941 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 766 -- Looks like a reference, but probably isn't: '255' on line 766 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 3 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: January 06, 2014 S. Aldrin 6 Huawei Technologies 7 July 05, 2013 9 Proxy MPLS Echo Request 10 draft-ietf-mpls-proxy-lsp-ping-00 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 January 06, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. Proxy Ping Overview . . . . . . . . . . . . . . . . . . . . . 4 71 3. Proxy MPLS Echo Request / Reply Procedures . . . . . . . . . 6 72 3.1. Procedures for the initiator . . . . . . . . . . . . . . 6 73 3.2. Procedures for the proxy LSR . . . . . . . . . . . . . . 7 74 3.2.1. Proxy LSR Handling when it is Egress for FEC . . . . 9 75 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply . 10 76 3.2.3. Sending an MPLS proxy ping reply . . . . . . . . . . 10 77 3.2.4. Sending the MPLS echo requests . . . . . . . . . . . 10 78 3.2.4.1. Forming the base MPLS echo request . . . . . . . 11 79 3.2.4.2. Per interface sending procedures . . . . . . . . 12 80 4. Proxy Ping Request / Reply Messages . . . . . . . . . . . . . 12 81 4.1. Proxy Ping Request / Reply Message formats . . . . . . . 12 82 4.2. Proxy Ping Request Message contents . . . . . . . . . . . 13 83 4.3. Proxy Ping Reply Message Contents . . . . . . . . . . . . 14 84 5. TLV formats . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 5.1. Proxy Echo Parameters TLV . . . . . . . . . . . . . . . . 14 86 5.1.1. Next Hop sub-TLV . . . . . . . . . . . . . . . . . . 18 87 5.2. Reply-to Address TLV . . . . . . . . . . . . . . . . . . 19 88 5.3. Upstream Neighbor Address TLV . . . . . . . . . . . . . . 19 89 5.4. Downstream Neighbor Address TLV . . . . . . . . . . . . . 20 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 95 9.2. Informative References . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 This document is motivated by two broad issues in connection with 101 diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). 102 The first is scalability due to the automatic replication of 103 Multiprotocol Label Switching (MPLS) Echo Request Messages as they 104 proceed down the tree. The second, which is primarily motivated by 105 Multicast Label Distribution Protocol (mLDP), is the ability to trace 106 a sub-LSP from leaf node to root node. 108 It is anticipated that very large Point-to-Multipoint and Multipoint- 109 to-Multipoint (MP2MP) Label Switched Paths will exist. Further it is 110 anticipated that many of the applications for P2MP/MP2MP tunnels will 111 require OAM that is both rigorous and scalable. 113 Suppose one wishes to trace a P2MP LSP to localize a fault which is 114 affecting one egress or a set of egresses. Suppose one follows the 115 normal procedure for tracing - namely repeatedly pinging from the 116 root, incrementing the Time to Live (TTL) by one after each three or 117 so pings. Such a procedure has the potential for producing a large 118 amount of processing at the P2MP-LSP midpoints and egresses. It also 119 could produce an unwieldy number of replies back to the root. 121 One alternative would be to begin sending pings from points at or 122 near the affected egress(es) and working backwards toward the root. 123 The TTL could be held constant, say two, limiting the number of 124 responses to the number of next-next-hops of the point where a ping 125 is initiated. 127 In the case of Resource Reservation Protocol-Traffic Engineering 128 (RSVP-TE), all setup is initiated from the root of the tree. Thus, 129 the root of the tree has knowledge of both all the leaf nodes and 130 usually the topology of the entire tree. Thus the above alternative 131 can easily be initiated by the root node. 133 In mLDP the situation is quite different. Leaf nodes initiate 134 connectivity to the tree which is granted by the first node toward 135 the root that is part of the tree. The root node may only be aware 136 of the immediately adjacent (downstream) nodes of the tree. 137 Initially the leaf node only has knowledge of the (upstream) node to 138 which it is immediately adjacent. However this is sufficient 139 information to intiate a trace. First the above procedure is applied 140 by asking that node to ping across the final link. That is, a 141 message is sent from the leaf to the upstream node requesting it to 142 send an MPLS Echo Request for the Forward Equivalence Class (FEC) of 143 the tree in question on said link. The leaf node also requests the 144 identity of the the upsteam neighbor's upstream neighbor for that 145 FEC. With this information the procedure can interatively be applied 146 until the fault is localized or the root node is reached. In all 147 cases the TTL for the request need only be at most 2. Thus the 148 processing load of each request is small as only a limited number of 149 nodes will receive the request. 151 This document defines protocol extensions to MPLS ping [RFC4379] to 152 allow a third party to remotely cause an MPLS echo request message to 153 be sent down a LSP or part of an LSP. The procedure described in the 154 paragraphs above does require that the initiator know the previous- 155 hop node to the one which was pinged on the prior iteration. This 156 information is readily available in [RFC4875]. This document also 157 provides a means for obtaining this information for [RFC6388]. 159 While the motivation for this document came from multicast scaling 160 concerns, it's applicability may be wider. The procedures presented 161 in this document are applicable to all LSP ping FEC types where the 162 MPLS echo request/reply are IP encapsulated and the MPLS echo reply 163 can sent out of band of the LSP over ip. Remote pinging of LSPs that 164 involve the use of in-band control channels is beyond the scope of 165 this document. 167 Other uses of this facility are beyond the scope of this document. 168 In particular, the procedures defined in this document only allow 169 testing of a FEC stack consisting of a single FEC. It also does not 170 allow the initiator to specify the label assigned to that FEC, nor 171 does it allow the initiator to cause any additional labels to be 172 added to the label stack of the actual MPLS echo request message. 174 1.1. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119. 180 The term "Must Be Zero" (MBZ) is used in TLV descriptions for 181 reserved fields. These fields MUST be set to zero when sent and 182 ignored on receipt. 184 Based on context the terms leaf and egress are used interchangeably. 185 Egress is used where consistency with[RFC4379] was deemed 186 appropriate. Receiver is used in the context of receiving protocol 187 messages. 189 [Note (to be removed after assignments occur): = to be assigned 190 by IANA] 192 2. Proxy Ping Overview 193 This document defines a protocol interaction between a first node and 194 a node which is part of an LSP to allow the first node to request 195 that second node initiate an LSP ping for the LSP on behalf of the 196 first node. Two new LSP Ping messages are defined for remote 197 pinging: the MPLS proxy ping request and the MPLS proxy ping reply. 199 A remote ping operation on a P2MP LSP generally involves at least 200 three LSRs; in some scenarios none of these are the ingress (root) or 201 an egress (leaf) of the LSP. 203 We refer to these nodes with the following terms: 205 Initiator - the node which initiates the ping operation by sending 206 an MPLS proxy ping request message 208 Proxy LSR - the node which is the destination of the MPLS proxy 209 request message and potential initiator of the MPLS echo request 211 Receiver(s) - the nodes which receive the MPLS echo request 212 message 214 Responder - A receiver that responds to a MPLS Proxy Ping Request 215 or an MPLS Echo Request 217 We note that in some scenarios, the initiator could also be the 218 responder, in which case the response would be internal to the node. 220 The initiator formats an MPLS proxy ping request message and sends it 221 to the proxy LSR, a node it believes to be on the path of the LSP. 222 This message instructs the proxy LSR to either Reply with Proxy 223 information or to send a MPLS echo request inband of the LSP. The 224 initiator requests Proxy information so that it can learn additional 225 information it needs to use to form a subsequent MPLS Proxy Ping 226 request. For example during LSP traceroute an initiator needs the 227 downstream map information to form an Echo request. An initiator may 228 also want to learn a Proxy LSR's FEC neighbor information so that it 229 can form proxy request to various nodes along the LSP. 231 The proxy LSR either replies with the requested Proxy information or 232 it validates that it has a label mapping for the specified FEC and 233 that it is authorized to send the specified MPLS echo request on 234 behalf of the initiator. 236 If the proxy LSR has a label mapping for the FEC and all 237 authorization checks have passed, the proxy LSR formats an MPLS echo 238 request. If the source address of the MPLS echo request is not to be 239 set to the Proxy Request source address, the initiator must include a 240 Reply-to Address TLV containing the source address to use in the MPLS 241 echo request. It then sends it inband of the LSP. 243 The receivers process the MPLS echo request as normal, sending their 244 MPLS echo replies back to the initiator. 246 If the proxy LSR failed to send a MPLS echo request as normal because 247 it encountered an issue while attempting to send, a MPLS proxy ping 248 reply message is sent back with a return code indicating that the 249 MPLS echo request could not be sent. 251 3. Proxy MPLS Echo Request / Reply Procedures 253 3.1. Procedures for the initiator 255 The initiator creates an MPLS proxy ping request message. 257 The message MUST contain a Target FEC Stack that describes the FEC 258 being tested. The topmost FEC in the target FEC stack is used at the 259 Proxy LSR to lookup the MPLS label stack that will be used to 260 encapsulate the MPLS echo request packet. 262 The MPLS Proxy Ping message MUST contain a Proxy Echo Parameters TLV. 263 In that TLV, the address type is set to either IPv4 or IPv6. The 264 Destination IP Address is set to the value to be used in the MPLS 265 echo request packet. If the Address Type is IPv4, an address is from 266 the range 127/8. If the Address Type is IPv6, an address is from the 267 range ::FFFF:7F00:0/104. 269 The Reply mode and Global Flags of the Proxy Echo Parameters TLV are 270 set to the values to be used in the MPLS echo request message header. 271 The Source UDP Port is set to the value to be used in the MPLS echo 272 request packet. The TTL is set to the value to be used in the 273 outgoing MPLS label stack. See Section 5.1 for further details. 275 If the FEC's Upstream/Downstream Neighbor address information is 276 required, the initiator sets the "Request for FEC neighbor 277 information" Proxy Flags in the Proxy Echo Parameters TLV. 279 If a Downstream Detailed or Downstream Mapping TLV is required in a 280 MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream 281 Detailed Mapping" or "Request for Downstream Mapping" Proxy Flags in 282 the Proxy Echo Parameters TLV. Only one of the two flags can be set. 284 The Proxy Request reply mode is set with one of the reply modes 285 defined in [RFC4379] as appropriate. 287 A list of Next Hop IP Addresses MAY be included to limit the next 288 hops towards which the MPLS echo request message will be sent. These 289 are encoded as Next Hop sub-TLVs and included in the Proxy Echo 290 Parameters TLV. 292 Proxy Echo Parameter TLV MPLS payload size field may be set to 293 request that the MPLS echo request (including any IP and UDP header) 294 be zero padded to the specified size. When the payload size is non 295 zero, if sending the MPLS Echo Request involves using an IP header, 296 the Dont Fragment (DF) bit MUST be set to 1. 298 Any of following TLVs MAY be included; these TLVs will be copied into 299 the MPLS echo request messages: 301 Pad 303 Vendor Enterprise Number 305 Reply TOS Byte 307 P2MP Responder Identifier [RFC6425] 309 Echo Jitter TLV [RFC6425] 311 Vendor Private TLVs 313 Downstream Detailed Mapping DDSMAP) or Downstream Mapping (DSMAP) 314 TLVs MAY be included. These TLVs will be matched to the next hop 315 address for inclusion in those particular MPLS echo request messages. 317 The message is then encapsulated in a UDP packet. The source User 318 Datagram Protocol (UDP) port is chosen by the initiator; the 319 destination UDP port is set to 3503. The IP header is set as 320 follows: the source IP address is a routable address of the 321 initiator; the destination IP address is a routable address to the 322 Proxy LSR. The packet is then sent with the IP TTL is set to 255. 324 3.2. Procedures for the proxy LSR 326 A proxy LSR that receives an MPLS proxy ping request message, parses 327 the packet to ensure that it is a well-formed packet. It checks that 328 the TLVs that are not marked "Ignore" are understood. If not, it 329 sets the Return Code set to "Malformed echo request received" or "TLV 330 not understood" (as appropriate), and the Subcode set to zero. If 331 the Reply Mode of the message header is not 1(Do not reply), an MPLS 332 proxy ping reply message SHOULD be sent as described below. In the 333 latter case, the misunderstood TLVs (only) are included in an Errored 334 TLVs TLV. 336 The Proxy LSR checks that the MPLS proxy ping request message did not 337 arrive via one of its exception processing paths. Packets arriving 338 via IP TTL expiry, IP destination address set to a Martian address or 339 label ttl expiry MUST be treated as "Unauthorized" packets. An MPLS 340 proxy ping reply message MAY be sent with a Return Code of , 341 "Proxy Ping not authorized". 343 The header fields Sender's Handle and Sequence Number are not 344 examined, but are saved to be included in the MPLS proxy ping reply 345 or MPLS echo request messages. 347 The proxy LSR validates that it has a label mapping for the specified 348 FEC, it then determines if it is an ingress, egress, transit or bud 349 node and sets the Return Code as appropriate. A new return code 350 (Replying router has FEC mapping for topmost FEC) has been defined 351 for the case where the Proxy LSR is an ingress (for example head of 352 the TE tunnel or a transit router) because the existing RFC4379 353 return codes don't match the situation. For example, when a Proxy 354 LSR is a transit router, it's not appropriate for the return code to 355 describe how the packet would transit because the Proxy Request 356 doesn't contain information about what input interface the an MPLS 357 echo request would be switched from at the Proxy LSR. 359 The proxy LSR then determines if it is authorized to send the 360 specified MPLS echo request on behalf of the initiator. A Proxy LSR 361 MUST be capable of filtering addresses to validate initiators. Other 362 filters on FECs or MPLS echo request contents MAY be applied. If a 363 filter has been invoked (i.e. configured) and an address does not 364 pass the filter, then an MPLS echo request message MUST NOT be sent, 365 and the event SHOULD be logged. An MPLS proxy ping reply message MAY 366 be sent with a Return Code of , "Proxy Ping not authorized". 368 The destination address specified in the Proxy Echo Parameters TLV is 369 checked to ensure that it conforms to the address allowed IPv4 or 370 IPv6 address range. If not, it sets the Return Code set to 371 "Malformed echo request received" and the Subcode set to zero. If 372 the Reply Mode of the message header is not 1, an MPLS proxy ping 373 reply message SHOULD be sent as described below. 375 If the "Request for FEC Neighbor Address info" flag is set, a 376 Upstream Neighbor Address TLV and/or Downstream Neighbor Address 377 TLV(s) is/are formatted for inclusion in the MPLS proxy ping reply. 378 If the Upstream or Downstream address is unknown they are not 379 included in the Proxy Reply. 381 If there are Next Hop sub-TLVs in the Proxy Echo Parameters TLV, each 382 address is examined to determine if it is a valid next hop for this 383 FEC. If any are not, Proxy Echo Parameters TLV should be updated 384 removing unrecognized Next Hop sub-TLVs. The updated Proxy Echo 385 Parameters TLV MUST be included in the MPLS proxy ping reply. 387 If the "Request for Downstream Detailed Mapping" or "Request for 388 Downstream Mapping" flag is set, the LSR formats (for inclusions in 389 the MPLS proxy ping reply) a Downstream Detailed/Downstream Mapping 390 TLV for each interface over which the MPLS echo request will be sent. 392 If the Proxy LSR is the egress for the FEC, the behavior of the proxy 393 LSR vary depending on whether the node is an Egress of a P2P LSP, a 394 P2MP LSP or MP2MP LSP. Additional details can be found in the 395 section describing "Handling when Proxy LSR it is egress for FEC". 397 If the Reply Mode of the Proxy Request message header is "1 - do not 398 reply", no MPLS proxy ping reply is sent. Otherwise an MPLS proxy 399 ping reply message or MPLS echo request should be sent as described 400 below. 402 3.2.1. Proxy LSR Handling when it is Egress for FEC 404 This sections describes the different behaviors for the Proxy LSR 405 when it's the Egress for the FEC. In the P2MP budnode and MP2MP 406 budnode and egress cases, different behavior is required. 408 When the Proxy LSR is the egress of a P2P FEC, a Proxy reply should 409 be sent to the initiator with the return code set to 3 (Reply router 410 is Egress for FEC) with return subcode set to 0. 412 When the Proxy LSR is the egress of a P2MP FEC, it can be either a 413 budnode or just an Egress. If the Proxy LSR is a Budnode, a Proxy 414 reply should be sent to the initiator with the return code set to 3 415 (Reply router is Egress for FEC) with return subcode set to 0 and DS/ 416 DDMAPs only if the Proxy initiator requested information to be 417 returned in a Proxy reply. If the Proxy LSR is a Budnode but not 418 requested to return a Proxy reply, the Proxy LSR should send packets 419 to the downstream neighbors (no Echo reply is sent to the Proxy 420 Initiator to indicate that the Proxy LSR is an egress). If the Proxy 421 LSR is just an egress, a Proxy reply should be sent to the initiator 422 with the return code set to 3 (Reply router is Egress for FEC) with 423 return subcode set to 0. 425 When the Proxy LSR is the egress of a MP2MP FEC, it can be either a 426 budnode or just an Egress. LSP pings sent from a leaf of a MP2MP has 427 different behavior in this case. MPLS echo request are sent to all 428 upstream/downstream neighbors. The Proxy LSRs need to be consistent 429 with this variation in behavior. If the Proxy LSR is a Budnode or 430 just an egress, a Proxy reply should be sent to the initiator with 431 the return code set to 3 (Reply router is Egress for FEC) with return 432 subcode set to 0 and DS/DDMAPs included only if the Proxy initiator 433 requested information to be returned in a Proxy reply. If the Proxy 434 LSR is not requested to return information in a proxy reply, the 435 Proxy LSR should send packets to all upstream/downstream neighbors as 436 would be done when sourcing an LSP ping from a M2MP leaf (no echo 437 reply is sent to the Proxy initiator indicating that the Proxy LSR is 438 an egress). 440 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply 442 When the Proxy LSR is a transit or bud node, downstream maps 443 corresponding to how the packet is transited can not be supplied 444 unless an ingress interface for the MPLS echo request is specified, 445 since this information is not available and since all valid output 446 paths are of interest, the Proxy LSR should include DS/DDMAP(s) to 447 describe the entire set of paths that the packet can be replicated, 448 like in the case where an LSP ping is initiated at the Proxy LSR. 449 For mLDP there is a DSMAP/DDMAP per upstream/downstream neighbor for 450 MP2MP LSPs, or per downstream neighbor in the P2MP LSP case. 452 When the Proxy LSR is a bud node or egress in a MP2MP LSP or a 453 budnode in a P2MP LSP, an LSP ping initiated from the Proxy LSR would 454 source packets only to the neighbors but not itself despite the fact 455 that the Proxy LSR is itself an egress for the FEC. In order to 456 match the behavior as seen from LSP Ping initiated at the Proxy LSR, 457 the Proxy Reply should contain DSMAP/DDMAPs for only the paths to the 458 upstream/downstream neighbors, but no DSMAP/DDMAP describing its own 459 egresses paths. The proxy LSR identifies that it's an egress for the 460 FEC using a different Proxy Reply return code. The Proxy reply 461 return code is either set to "Reply router has a mapping for the 462 topmost FEC" or "Reply router is Egress for the FEC". 464 3.2.3. Sending an MPLS proxy ping reply 466 The Reply mode, Sender's Handle and Sequence Number fields are copied 467 from the proxy ping request message. The TLVs specified above are 468 included. The message is encapsulated in a UDP packet. The source 469 IP address is a routable address of the proxy LSR; the source port is 470 the well-known UDP port for LSP ping. The destination IP address and 471 UDP port are copied from the source IP address and UDP port of the 472 echo request. The IP TTL is set to 255. 474 3.2.4. Sending the MPLS echo requests 475 A base MPLS echo request is formed as described in the next section. 476 The section below that describes how the base MPLS echo request is 477 sent on each interface. 479 3.2.4.1. Forming the base MPLS echo request 481 A Next_Hop_List is created as follows. If Next Hop sub-TLVs were 482 included in the received Proxy Parameters TLV, the Next_Hop_List 483 created from the address in those sub-TLVs as adjusted above. 484 Otherwise, the list is set to all the next hops to which the FEC 485 would be forwarded. 487 The proxy LSR then formats an MPLS echo request message. The Global 488 Flags and Reply Mode are copied from the Proxy Echo Parameters TLV. 489 The Return Code and Return Subcode are set to zero. 491 The Sender's Handle and Sequence Number are copied from the remote 492 echo request message. 494 The TimeStamp Sent is set to the time-of-day (in seconds and 495 microseconds) that the echo request is sent. The TimeStamp Received 496 is set to zero. 498 If the reply-to address TLV is present, it is used to set the echo 499 request source address, otherwise the echo request source address is 500 set to the proxy request source address. 502 The following TLVs are copied from the MPLS proxy ping request 503 message. Note that of these, only the Target FEC Stack is REQUIRED 504 to appear in the MPLS proxy ping request message. 506 Target FEC Stack 508 Pad 510 Vendor Enterprise Number 512 Reply TOS Byte 514 P2MP Responder Identifier [RFC6425] 516 Echo Jitter TLV [RFC6425] 518 Vendor Private TLVs 520 The message is then encapsulated in a UDP packet. The source UDP 521 port is copied from the Proxy Echo Parameters TLV. The destination 522 port copied from the proxy ping request message. 524 The source IP address is set to a routable address specified in the 525 reply-to-address TLV or the source address of the received proxy 526 request. Per usual the TTL of the IP packet is set to 1. 528 If the Explicit Differentiated Services Code Point (DSCP) flag is 529 set, the Requested DSCP byte is examined. If the setting is 530 permitted then the DSCP byte of the IP header of the MPLS Echo 531 Request message is set to that value. If the Proxy LSR does not 532 permit explicit control for the DSCP byte, the MPLS Proxy Echo 533 Parameters with the Explicit DSCP flag cleared MUST be included in 534 any MPLS proxy ping reply message to indicate why an Echo Request was 535 not sent. The return code MUST be set to , "Proxy ping 536 parameters need to be modified". If the Explicit DSCP flag is not 537 set, the Proxy LSR should set the Echo Request DSCP settings to the 538 value normally used to source LSP ping packets.. 540 3.2.4.2. Per interface sending procedures 542 The proxy LSR now iterates through the Next_Hop_List modifying the 543 base MPLS echo request to form the MPLS echo request packet which is 544 then sent on that particular interface. 546 For each next hop address, the outgoing label stack is determined. 547 The TTL for the label corresponding to the FEC specified in the FEC 548 stack is set such that the TTL on the wire will be othe TTL specified 549 in the Proxy Echo Parameters. If any additional labels are pushed 550 onto the stack, their TTLs are set to 255. 552 If the MPLS proxy ping request message contained Downstream Mapping/ 553 Downstream Detailed Mapping TLVs, they are examined. If the 554 Downstream IP Address matches the next hop address that Downstream 555 Mapping TLV is included in the MPLS echo request. 557 The packet is then transmitted on this interface. 559 4. Proxy Ping Request / Reply Messages 561 This document defines two new LSP Ping messages, the MPLS proxy ping 562 request and the MPLS proxy ping reply. 564 4.1. Proxy Ping Request / Reply Message formats 566 Except where noted, the definitions of all fields in the messages are 567 identical to those found in [RFC4379]. The messages have the 568 following format: 570 0 1 2 3 571 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Version Number | MUST Be Zero | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Message Type | Reply mode | Return Code | Return Subcode| 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Sender's Handle | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Sequence Number | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | TLVs ... | 583 . . 584 . . 585 . . 586 | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Version Number 591 The Version Number is currently 1. (Note: the Version Number 592 is to be incremented whenever a change is made that affects the 593 ability of an implementation to correctly parse or process an 594 MPLS echo request/reply. These changes include any syntactic 595 or semantic changes made to any of the fixed fields, or to any 596 TLV or sub-TLV assignment or format that is defined at a 597 certain version number. The Version Number may not need to be 598 changed if an optional TLV or sub-TLV is added.) 600 Message Type 602 Type Message 603 ---- ------- 604 TBA-1 MPLS proxy ping request 605 (Pending IANA assignment) 606 TBA-2 MPLS proxy ping reply 607 (Pending IANA assignment) 609 4.2. Proxy Ping Request Message contents 611 The MPLS proxy ping request message MAY contain the following 612 TLVs: 614 Type TLV 615 ---- ----------- 616 1 Target FEC Stack 617 2 Downstream Mapping 618 3 Pad 619 5 Vendor Enterprise Number 620 10 Reply TOS Byte 622 11 P2MP Responder Identifier [RFC6425] 623 12 Echo Jitter TLV [RFC6425] 624 20 Downstream Detailed Mapping 625 TBA-3 Proxy Echo Parameters (Pending IANA assignment) 626 TBA-4 Reply-to-Address TLV 627 * Vendor Private TLVs 629 * TLVs types in the Vendor Private TLV Space MUST be 630 ignored if not understood 632 4.3. Proxy Ping Reply Message Contents 634 The MPLS proxy ping reply message MAY contain the following TLVs: 636 Type TLV 637 ---- ----------- 638 1 Target FEC Stack 639 2 Downstream Mapping 640 5 Vendor Enterprise Number 641 9 Errored TLVs 642 20 Downstream Detailed Mapping 643 TBA-3 Proxy Echo Parameters (Pending IANA assignment) 644 TBA-5 Upstream Neighbor Address (Pending IANA assignment) 645 TBA-6 Downstream Neighbor Address (0 or more) 646 (Pending IANA assignment) 647 * Vendor Private TLVs 649 * TLVs types in the Vendor Private TLV Space MUST be 650 ignored if not understood 652 5. TLV formats 654 5.1. Proxy Echo Parameters TLV 656 The Proxy Echo Parameters TLV is a TLV that MUST be included in an 657 MPLS Proxy Echo Request message. The length of the TLV is 12 + K + 658 S, where K is the length of the Destination IP Address field and S is 659 the total length of the sub-TLVs. The Proxy Echo Parameters TLV can 660 be used to either to 1) control attributes used in Composing and 661 Sending an MPLS echo request or 2) query the Proxy LSR for 662 information about the topmost FEC in the target FEC stack but not 663 both. In the case where the Proxy LSR is being queried (ie 664 information needs to be returned in a Proxy Reply), no MPLS echo 665 request will be sent from the Proxy LSR. The MPLS Proxy Echo request 666 echo header's Reply Mode should be set to "Reply with Proxy Info". 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Address Type | Reply mode | Proxy Flags | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | TTL | Rqst'd DSCP | Source UDP Port | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Global Flags | MPLS Payload size | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | | 678 : Destination IP Address : 679 | | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 : : 683 : Sub-TLVs : 684 : : 685 | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Address Type 690 The type and length of the address found in the in the 691 Destination IP Address and Next Hop IP Addresses fields. 692 The values are shared with the Downstream Mapping Address 693 Type Registry. 695 The type codes applicable in this case appear in the table below: 697 Address Family Type Length 699 IPv4 1 4 700 IPv6 3 16 702 Reply mode 704 The reply mode to be sent in the MPLS Echo Request message; the 705 values are as specified in [RFC4379]. 707 Proxy Flags 708 The Proxy Request Initiator sets zero, one or more of these 709 flags to request actions at the Proxy LSR. 711 Request for FEC Neighbor Address info 0x01 713 When set this requests that the proxy LSR supply the 714 Upstream and Downstream neighbor address information in the 715 MPLS proxy ping reply message. This flag is only applicable 716 for the topmost FEC in the FEC stack if the FEC types 717 corresponds with a P2MP or MP2MP LSPs. The Proxy LSR MUST 718 respond as applicable with a Upstream Neighbor Address 719 TLV and Downstream Neighbor Address TLV(s) in the MPLS 720 Proxy ping reply message. Upstream Neighbor Address TLV 721 needs be included only if there is an upstream neighbor. 722 Similarly, one Downstream Neighbor Address TLV needs to 723 be included for each Downstream Neighbor for which the LSR 724 learned bindings from. 726 Setting this flag will cause the proxy LSR to cancel sending 727 an Echo request. Information learned with such proxy reply 728 may be used by the proxy initiator to generate subsequent 729 proxy requests. 731 Request for Downstream Mapping 0x02 733 When set this requests that the proxy LSR supply a 734 Downstream Mapping TLV see [RFC4379] in the MPLS 735 proxy ping reply message. It's not valid 736 to have Request for Downstream Detailed Mapping flag set 737 when this flag is set. 739 Setting this flag will cause the proxy LSR to cancel sending 740 an Echo request. Information learned with such proxy reply 741 may be used by the proxy initiator to generate subsequent 742 proxy requests. 744 Request for Downstream Detailed Mapping 0x04 746 When set this requests that the proxy LSR supply a 747 Downstream Detailed Mapping TLV see [RFC6424] in the 748 MPLS proxy ping reply message. It's not valid 749 to have Request for Downstream Mapping flag set 750 when this flag is set. 752 Setting this flag will cause the proxy LSR to cancel sending 753 an Echo request. Information learned with such proxy reply 754 may be used by the proxy initiator to generate subsequent 755 proxy requests. 757 Explicit DSCP Request 0x08 759 When set this requests that the proxy LSR use 760 the supplied "Rqst'd DSCP" byte in the echo request message 762 TTL 764 The TTL to be used in the label stack entry corresponding to 765 the topmost FEC in the in the MPLS Echo Request packet. Valid 766 values are in the range [1,255]. A setting of 0 should be 767 ignored by the Proxy LSR. 769 Requested DSCP 771 This field is valid only if the Explicit DSCP flag is set. If 772 not set, the field MUST be zero on transmission and ignored on 773 receipt. When the flag is set this field contains the DSCP 774 value to be used in the MPLS echo request packet IP header. 776 Source UDP Port 778 The source UDP port to be sent in the MPLS Echo Request packet 780 Global Flags 782 The Global Flags to be sent in the MPLS Echo Request message 784 MPLS Payload Size 786 Used to request that the MPLS payload (IP header + UDP header 787 + MPLS echo request) be padded using a zero filled Pad TLV 788 so that the IP header, UDP header nad MPLS echo request total 789 the specified size. Field set to zero means no 790 size request is being made. If the requested size is less 791 than the minimum size required to form the MPLS echo request, 792 the request will be treated as a best effort request with 793 the Proxy LSR building the smallest possible packet (ie 794 not using a Pad TLV). The IP header DF bit should be set 795 when this field is non zero. 797 Destination IP Address 799 If the Address Type is IPv4, an address from the range 127/8; 800 If the Address Type is IPv6, an address from the range 801 ::FFFF:7F00:0/104 803 Sub-TLVs 805 A TLV encoded list of sub-TLVs. Currently one is defined. 807 Sub-Type Length Value Field 808 -------- ------ ----------- 809 1 8+ Next Hop 811 5.1.1. Next Hop sub-TLV 813 This sub-TLV is used to describe a particular next hop towards which 814 the Echo Request packet should be sent. If the topmost FEC in the 815 FEC-stack is a multipoint LSP, this sub-TLV may appear multiple 816 times. 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 | Addr Type | MUST be Zero | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Next Hop IP Address (4 or 16 octets) | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Next Hop Interface (0, 4 or 16 octets) | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Address Type 830 Type Type of Next Hop Addr Length IF Length 832 1 IPv4 Numbered 4 4 833 2 IPv4 Unnumbered 4 4 834 3 IPv6 Numbered 16 16 835 4 IPv6 Unnumbered 16 4 836 5 IPv4 Protocol Adj 4 0 837 6 IPv6 Protocol Adj 16 0 839 Note: Types 1-4 correspond to the types in the DS Mapping 840 TLV. They are expected to populated with information 841 obtained through a previously returned DS Mapping TLV. 842 Types 5 and 6 are intended to be populated from the local 843 address information obtained from a previously returned 844 Downstream Neighbor Address TLV(s)/Upstream Neighbor Address TLV. 846 Next Hop IP Address 848 A next hop address that the echo request message is to 849 be sent towards 851 Next Hop Interface 853 Identifier of the interface through which the echo request 854 message is to be sent. For Addr Type 5, and 6, the Next Hop 855 interface field isn't used and must of a associated byte 856 length of "0" octets. 858 5.2. Reply-to Address TLV 860 Used to specify the MPLS echo request IP source address. This 861 address must be IP reachable via the Proxy LSR otherwise it will be 862 rejected. 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Address Type | MUST be Zero | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | | 870 : Reply-to Address : 871 | | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Address Type 876 A type code as specified in the table below: 878 Type Type of Address 880 1 IPv4 881 3 IPv6 883 5.3. Upstream Neighbor Address TLV 885 0 1 2 3 886 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 |Upst Addr Type |Local Addr Type| MUST be Zero | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | | 891 : Upstream Address : 892 | | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | | 895 : Local Address : 896 | | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Upst Addr Type; Local Addr Type 901 These two fields determine the type and length of the 902 respective addresses. The codes are specified in the table 903 below: 905 Type Type of Address Length 907 0 No Address Supplied 0 908 1 IPv4 4 909 3 IPv6 16 911 Upstream Address 913 The address of the immediate upstream neighbor for the topmost 914 FEC in the FEC stack. If protocol adjacency exists by which 915 the label for this FEC was exchanged, this address MUST be the 916 address used in that protocol exchange. 918 Local Address 920 The local address used in the protocol adjacency exists by 921 which the label for this FEC was exchanged. 923 5.4. Downstream Neighbor Address TLV 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 |Dnst Addr Type |Local Addr Type| MUST be Zero | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | | 931 : Downstream Address : 932 | | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | | 935 : Local Address : 936 | | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 Dnst Addr Type; Local Addr Type 941 These two fields determine the type and length of the 942 respective addresses. The codes are specified in the table 943 below: 945 Type Type of Address Length 947 0 No Address Supplied 0 948 1 IPv4 4 949 3 IPv6 16 951 Downstream Address 953 The address of a immediate downstream neighbor for the topmost 954 FEC in the FEC stack. If protocol adjacency exists by which 955 the label for this FEC was exchanged, this address MUST be the 956 address used in that protocol exchange. 958 Local Address 960 The local address used in the protocol adjacency exists by 961 which the label for this FEC was exchanged. 963 6. Security Considerations 965 The mechanisms described in this document are intended to be used 966 within a Service Provider network and to be initiated only under the 967 authority of that administration. 969 If such a network also carries internet traffic, or permits IP access 970 from other administrations, MPLS proxy ping message SHOULD be 971 discarded at those points. This can be accomplished by filtering on 972 source address or by filtering all MPLS ping messages on UDP port. 974 Any node which acts as a proxy node SHOULD validate requests against 975 a set of valid source addresses. An implementation MUST provide such 976 filtering capabilities. 978 MPLS proxy ping request messages are IP addressed directly to the 979 Proxy node. If a node which receives an MPLS proxy ping message via 980 IP or Label TTL expiration, it MUST NOT be acted upon. 982 MPLS proxy ping request messages are IP addressed directly to the 983 Proxy node. If a MPLS Proxy ping request IP destination address is a 984 Martian Address, it MUST NOT be acted upon. 986 if a MPLS Proxy ping request IP source address is not IP reachable by 987 the Proxy LSR, the Proxy request MUST NOT be acted upon. 989 MPLS proxy ping requests are limited to making their request via the 990 specification of a FEC. This ensures that only valid MPLS echo 991 request messages can be created. No label spoofing attacks are 992 possible. 994 7. Acknowledgements 996 The authors would like to thank Nobo Akiya for his detailed review 997 and insightful comments. 999 8. IANA Considerations 1001 This document makes the following assignments (pending IANA action) 1003 LSP Ping Message Types 1005 Type Value Field 1006 ---- ----------- 1007 TBA-1 MPLS proxy ping request 1008 TBA-2 MPLS proxy ping reply 1010 TLVs and Sub-TLVs 1012 Type Sub-Type Value Field 1013 ---- -------- ----------- 1014 TBA-3 Proxy Echo Parameters 1015 1 Next Hop 1016 TBA-4 Reply-to Address 1017 TBA-5 Upstream Neighbor Address 1018 TBA-6 Downstream Neighbor Address 1020 Return Code [pending IANA assignment] 1022 Value Meaning 1023 ----- ------- 1024 TBA-7 Proxy ping not authorized. 1025 TBA-8 Proxy ping parameters need to be modified. 1026 TBA-9 MPLS Echo Request Could not be sent. 1027 TBA-10 Replying router has FEC mapping for topmost FEC. 1029 Downstream Address Mapping Registry [pending IANA assignment] 1031 Value Meaning 1032 ----- ------- 1033 TBA-11 IPv4 Protocol Adj 1034 TBA-12 IPv6 Protocol Adj 1036 9. References 1038 9.1. Normative References 1040 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1041 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1042 February 2006. 1044 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1045 Performing Label Switched Path Ping (LSP Ping) over MPLS 1046 Tunnels", RFC 6424, November 2011. 1048 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 1049 S., and T. Nadeau, "Detecting Data-Plane Failures in 1050 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 1051 6425, November 2011. 1053 9.2. Informative References 1055 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1056 "Extensions to Resource Reservation Protocol - Traffic 1057 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1058 Switched Paths (LSPs)", RFC 4875, May 2007. 1060 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1061 "Label Distribution Protocol Extensions for Point-to- 1062 Multipoint and Multipoint-to-Multipoint Label Switched 1063 Paths", RFC 6388, November 2011. 1065 Authors' Addresses 1067 George Swallow 1068 Cisco Systems 1069 1414 Massachusetts Ave 1070 Boxborough, MA 01719 1071 USA 1073 Email: swallow@cisco.com 1074 Vanson Lim 1075 Cisco Systems 1076 1414 Massachusetts Avenue 1077 Boxborough, MA 01719 1078 USA 1080 Email: vlim@cisco.com 1082 Sam Aldrin 1083 Huawei Technologies 1084 2330 Central Express Way 1085 Santa Clara, CA 95951 1086 USA 1088 Email: aldrin.ietf@gmail.com