idnits 2.17.1 draft-chen-mpls-return-path-specified-lsp-ping-02.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 is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: P bit and S bit MUST not both be set. If P bit and S bit are both not set, the return path could be any one of the LSPs that have the same Tunnel attributes. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If no Any Candidate sub-TLV is present, it means that the echo reply is REQUIRED not only to send along the specified path, but to detect the selected return path as well (by carrying the FEC stack TLV of the return path). In addition, the FEC validate results of forward path LSP SHOULD not affect the egress LSR continue to test return path LSP. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the echo reply is intended to test the return path, the destination IP address of the echo reply message MUST never be used in a forwarding decision. To avoid this problem, the IP destination address of the echo reply message that is transmitted along the specified return path MUST be set to numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be set 1. If the echo reply is required to test the return path, the echo reply MUST have a FEC stack TLV describing the return path, which is used for the ingress LSR to perform FEC validation. The FEC stack TLV of the forward path MUST NOT be copied to the echo reply. And the FEC stack TLV of forward LSP MUST not be copied to the echo reply. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BFD-IP' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 700, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-08 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group M. Chen(Ed.) 2 Internet Draft Huawei Technologies Co.,Ltd 3 Category: Standards Track N. So(Ed.) 4 Created: March 9, 2010 Verizon 5 Expires: September 2010 7 Return Path Specified LSP Ping 9 draft-chen-mpls-return-path-specified-lsp-ping-02.txt 11 Abstract 13 This document defines extensions to the failure-detection protocol 14 for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) 15 known as "LSP Ping" that allow selection of the LSP to use for the 16 echo reply return path. Enforcing a specific return path can be used 17 to verify bidirectional connectivity and also increase LSP ping 18 robustness. It may also be used by Bidirectional Forwarding 19 Detection (BFD) for MPLS bootstrap signaling thereby making BFD for 20 MPLS more robust. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with 25 the provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 15, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 [RFC2119]. 63 Table of Contents 65 1. Introduction...................................................3 66 2. Problem Statements and Solution Overview.......................3 67 2.1. Limitations of Existing Mechanisms for Bidirectional LSPs.4 68 2.2. Limitations of Existing Mechanisms for Handling Unreliable 69 Return Paths...................................................4 70 3. Extensions.....................................................5 71 3.1. Reply Via Specified Path mode.............................6 72 3.2. Reply Path (RP) TLV.......................................6 73 3.3. RP TLV sub-TLVs...........................................7 74 3.3.1. IPv4 RSVP Tunnel sub-TLV.............................8 75 3.3.2. IPv6 RSVP Tunnel sub-TLV.............................9 76 3.3.3. Bidirectional sub-TLV...............................10 77 3.3.4. Any Candidate sub-TLV...............................10 78 4. Theory of Operation...........................................11 79 4.1. Sending an Echo Request..................................11 80 4.2. Receiving an Echo Request................................12 81 4.3. Sending an Echo Reply....................................13 82 4.4. Receiving an Echo Reply..................................13 83 5. Security Considerations.......................................14 84 6. IANA Considerations...........................................14 85 6.1. Reply mode...............................................14 86 6.2. RP TLV...................................................15 87 6.3. Sub-TLVs for RP TLV......................................15 88 7. Contributors..................................................15 89 8. Acknowledgments...............................................16 90 9. References....................................................16 91 9.1. Normative References.....................................16 92 9.2. Informative References...................................17 93 Authors' Addresses...............................................18 95 1. Introduction 97 This document defines extensions to the failure-detection protocol 98 for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) 99 known as "LSP Ping" [RFC4379] that can be used to specify the return 100 paths for the echo reply message, increasing the robustness of LSP 101 Ping, reducing the opportunity for error, and improving the 102 reliability of the echo reply message. A new reply mode, which is 103 referred to as "Reply via specified path", is added and a new Type- 104 Length-Value (TLV), which is referred to as Reply Path (RP) TLV, is 105 defined in this memo. 107 With the extensions described in this document, a bidirectional LSP 108 and a pair of unidirectional LSPs (one for each direction) could 109 both be tested with a single operational action, hence providing 110 better control plane scalability. The defined extensions can also be 111 utilized for creating a single Bidirectional Forwarding Detection 112 (BFD) [BFD], [BFD-MPLS] session for a bidirectional LSP or for a 113 pair of unidirectional LSPs (one for each direction). 115 In this document, term bidirectional LSP includes the co-routed 116 bidirectional LSP defined in [RFC3945]and the associated 117 bidirectional LSP that is constructed from a pair of unidirectional 118 LSPs (one for each direction), and which are associated with one 119 another at the LSP's ingress/egress points [RFC5654]. 121 2. Problem Statements and Solution Overview 123 MPLS LSP Ping is defined in [RFC4379]. It can be used to detect data 124 path failures in all MPLS LSPs, and was originally designed for 125 unidirectional LSPs. 127 LSP are increasingly being deployed to provide bidirectional 128 services. The co-routed bidirectional LSP is defined in [RFC3471] 129 and [RFC3473], and the associated bidirectional LSP is defined in 130 [RFC5654]. With the deployment of such services, operators have a 131 desire to test both directions of a bidirectional LSP in a single 132 operation. 134 Additionally, when testing a single direction of an LSP (either a 135 unidirectional LSP, or a single direction of a bidirectional LSP) 136 using LSP Ping, the validity of the result may be affected by the 137 success of delivering the echo response message. Failure to exchange 138 these messages between the egress Label Switching Router (LSR) and 139 the ingress LSR can lead to false negatives where the LSP under test 140 is reported as "down" even though it is functioning correctly. 142 2.1. Limitations of Existing Mechanisms for Bidirectional LSPs 144 With the existing LSP Ping mechanisms as defined in [RFC4379], 145 operators have to enable LSP detection on each of the two ends of a 146 bidirectional LSP independently. This not only doubles the workload 147 for the operators, but may also bring additional difficulties when 148 checking the backward direction of the LSP under the following 149 conditions: 151 1. The LSR that the operator logged on to perform the checking 152 operations might not have out-of-band connectivity to the LSR at 153 the far end of the LSP. That can mean it is not possible to check 154 the return direction of a bidirectional LSP in a single operation 155 - - the operator must log on to the LSR at the other end of the LSP 156 to test the return direction. 158 2. The LSP being tested might be an inter-domain/inter-AS LSP 159 where the operator of one domain/AS may have no right to log on to 160 the LSR at the other end of the LSP since this LSR resides in 161 another domain/AS. That can make it completely impossible for the 162 operator to check the return direction of a bidirectional LSP. 164 Associated bidirectional LSPs have the same issues as those listed 165 for co-routed bidirectional LSPs. 167 This document defines a mechanism to allow the operator to request 168 that both directions of a bidirectional LSP be tested by a single 169 LSP Ping message exchange. 171 2.2. Limitations of Existing Mechanisms for Handling Unreliable Return 172 Paths 174 [RFC4379] defines 4 reply modes: 176 1. Do not reply 177 2. Reply via an IPv4/IPv6 UDP packet 178 3. Reply via an IPv4/IPv6 UDP packet with Router Alert 179 4. Reply via application level control channel. 181 Obviously, the issue of the reliability of the return path for an 182 echo reply message does not apply in the first of these cases. 184 [RFC4379] states that the third mode may be used when the IP return 185 path is deemed unreliable. This mode of operation requires that all 186 intermediate nodes must support the Router Alert option and must 187 understand and know how to forward MPLS echo replies. 189 This is a rigorous requirement in deployed IP/MPLS networks 190 especially since the return path may be through legacy IP-only 191 routers. Furthermore, for inter-domain LSPs, the use of the Router 192 Alert option may encounter significant issues at domain boundaries 193 where the option is usually stripped from all packets. Thus, the use 194 of this mode may itself introduce issues that lead to the echo reply 195 messages not being delivered. 197 And in any case, the use modes 2 or 3 cannot guarantee the delivery 198 of echo responses through an IP network that is fundamentally 199 unreliable. The failure to deliver echo response messages can lead 200 to false negatives making it appear that the LSP has failed. 202 Allowing the ingress LSR to control the path used for echo reply 203 messages, and in particular forcing those messages to use an LSP 204 rather than being sent through the IP network, enables an operator 205 to apply an extra level of deterministic process to the LSP Ping 206 test. 208 This document defines extensions to LSP Ping that can be used to 209 specify the return paths of the echo reply message in an LSP echo 210 request message. 212 3. Extensions 214 LSP Ping defined in [RFC4379] is carried out by sending an echo 215 request message. It carries the Forwarding Equivalence Class (FEC) 216 information of the tested LSP which indicates which MPLS path is 217 being verified, along the same data path as other normal data 218 packets belonging to the FEC. 220 LSP Ping [RFC4379] defines four reply modes that are used to direct 221 the egress LSR in how to send back an echo reply. This document 222 defines a new reply mode, the Reply Via Specified Path mode. This 223 new mode is used to direct the egress LSR of the tested LSP to send 224 the echo reply message back along the path specified in the echo 225 request message. 227 In addition, a new TLV, the Reply Path (RP) TLV, is defined in this 228 document. The RP TLV consists of one or more sub-TLVs that can be 229 used to carry the specified return path information to be used by 230 the echo reply message. 232 3.1. Reply Via Specified Path mode 234 A new reply mode is defined to be carried in the Reply Mode field of 235 the LSP Ping echo request message. 237 The recommended value of the Reply Via Specified Path mode is 5 238 (This is to be confirmed by the IANA). 240 Value Meaning 241 ----- ------- 242 5 Reply via specified path 244 The Reply Via Specified Path mode is used to notify the remote LSR 245 receiving the LSP Ping echo request message to send back the echo 246 reply message along the specified paths carried in the Reply Path 247 TLV. 249 3.2. Reply Path (RP) TLV 251 The Reply Path (RP) TLV is optionally included in an echo request 252 message. It carries the specified return paths that the echo reply 253 message is required to follow. The format of RP TLV is as follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | RP (reply path) TLV Type | Length | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Reply Paths | 261 ~ ~ 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 RP TLV Type field is 2 octets in length, and the type value is TBD 266 by IANA. 268 The Length field is 2 octets in length. It defines the length in 269 octets of the Reply Paths field. 271 The Reply Paths field is variable in length. It has several nested 272 sub-TLVs that describe the specified paths the echo reply message is 273 required to follow. 275 When the Reply Mode field is set to "Reply via specified path" in an 276 LSP echo request message, the RP TLV MUST be present. 278 3.3. RP TLV sub-TLVs 280 Each of the FEC sub-TLVs defined in [RFC4379] is applicable to be a 281 sub-TLV for inclusion in the RP TLV for expressing a specific return 282 path. 284 In addition, four more new sub-TLVs are defined: IPv4 RSVP Tunnel 285 sub-TLV, IPv6 RSVP Tunnel sub-TLV, Bidirectional sub-TLV and Any 286 Candidate sub-TLV. Detailed definition is in the following sections. 288 With those sub-TLVs defined in [RFC4379] and the sub-TLVs defined in 289 this document, it could provide following options for return paths 290 specifying: 292 1. Specify a particular LSP as return path 293 - use those sub-TLVs defined in [RFC4379], 295 2. Specify a more generic tunnel FEC as return path 296 - use the IPv4/IPv6 RSVP Tunnel sub-TLVs defined in Section 297 3.3.1 and Section 3.3.2 of this document 299 3. Specify the reverse path of the bidirectional LSP as return path 300 - use the Bidirectional sub-TLV defined in Section 3.3.3 of 301 this document. 303 4. Force return path to pure IP path 304 - use the Any Candidate sub-TLV only 306 5. Allow any LSPs except specific or general ones as return path 307 - use the Any Candidate sub-TLV, 308 - and include other sub-TLVs 310 3.3.1. IPv4 RSVP Tunnel sub-TLV 312 The IPv4 RSVP Tunnel sub-TLV is used in the RP TLV to allow the 313 operator to specify a more generic tunnel FEC other than a 314 particular LSP as the return path. The egress LSR chooses any LSP 315 from the LSPs that have the same Tunnel attributes and satisfy the 316 conditions carried in the Flag field. The format of IPv4 RSVP Tunnel 317 sub-TLV is as follows: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | IPv4 RSVP Tunnel sub-TLV Type | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | IPv4 tunnel end point address | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Flag | Tunnel ID | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Extended Tunnel ID | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | IPv4 tunnel sender address | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV 334 that is defined in Section 3.2.3 [RFC4379]. All fields have the same 335 semantics as defined in [RFC4379] except that the LSP-ID field is 336 omitted and a new Flag field is defined. 338 The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and 339 the recommended type value is 19 (to be confirmed by IANA). 341 The Flag field is 2 octets in length, it is used to notify the 342 egress LSR how to choose the return path. The Flag field is a bit 343 vector and has following format: 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | MUST be zero |S|P| 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 P (Primary): the return path MUST be chosen from the LSPs that have 350 the same Tunnel attributes and the LSP MUST be the primary LSP. 352 S (Secondary): the return path MUST be chosen from the LSPs that 353 have the same Tunnel attributes and the LSP MUST be the secondary 354 LSP. 356 P bit and S bit MUST not both be set. If P bit and S bit are both 357 not set, the return path could be any one of the LSPs that have the 358 same Tunnel attributes. 360 3.3.2. IPv6 RSVP Tunnel sub-TLV 362 The IPv6 RSVP Tunnel sub-TLV is used in the RP TLV to allow the 363 operator to specify a more generic tunnel FEC other than a 364 particular LSP as the return path. The egress LSR chooses an LSP 365 from the LSPs that have the same Tunnel attributes and satisfy the 366 conditions carried in the Flag field. The format of IPv6 RSVP Tunnel 367 sub-TLV is as follows: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | IPv6 RSVP Tunnel sub-TLV Type | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | IPv6 tunnel end point address | 375 | | 376 | | 377 | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Flag | Tunnel ID | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Extended Tunnel ID | 382 | | 383 | | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | IPv6 tunnel sender address | 387 | | 388 | | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 The IPv6 RSVP Tunnel sub-TLV is derived from RSVP IPv6 FEC TLV that 393 is defined in Section 3.2.4 of [RFC4379].All fields have the same 394 semantics as defined in [RFC4379] except that the LSP-ID field is 395 omitted and a new Flag field is defined.. 397 The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and 398 the recommended type value is 20 (to be confirmed by IANA). 400 The Flag field is 2 octets in length and is identical to that 401 described in Section 3.3. 403 3.3.3. Bidirectional sub-TLV 405 The Bidirectional sub-TLV is used in the RP TLV when the return path 406 is required to follow the reverse direction of the tested 407 bidirectional LSP. The format of Bidirectional sub-TLV is as follows: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Bidirectional sub-TLV Type | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 The Bidirectional sub-TLV Type field is 2 octets in length, and the 416 recommended type value is 17 (to be confirmed by IANA). 418 The Length field is 2 octets in length, the value of length field 419 MUST be 0, which means that there are no value fields following. 421 3.3.4. Any Candidate sub-TLV 423 The Any Candidate sub-TLV is used in the RP TLV when the return path 424 is required to exclude the paths that are identified by any other 425 reply path sub-TLVs carried in the echo request message. This is 426 very useful when one or more previous LSP Ping attempts failed. By 427 carrying an Any Candidate sub-TLV and the previous failed reply path 428 sub-TLVs, a new LSP Ping echo request could be used to help the 429 egress LSR to select another candidate path when sending echo reply 430 message. If there is only an Any Candidate sub-TLV included in the 431 echo request (i.e., no other sub-TLVs are present in the RP TLV), 432 the egress LSR MUST select a non-LSP path (e.g., an IP path) as the 433 return path. This is very useful when reverse MPLS path problems are 434 suspected which can be confirmed when the echo reply is forced to 435 follow an IP path. The format of the Any Candidate sub-TLV is as 436 follows: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Any Candidate sub-TLV Type | Length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 The Any Candidate sub-TLV Type field is 2 octets in length, and the 445 recommended type value is 18 (to be confirmed by IANA). 447 The Length field is 2 octets in length, the value of length field 448 MUST be 0, it means that there is no any value fields follows. 450 4. Theory of Operation 452 The procedures defined in this document currently only apply to 453 "ping" mode. The "traceroute" mode is out of scope for this document. 455 In [RFC4379], the echo reply is used to report the LSP checking 456 result to the LSP Ping initiator. This document defines a new reply 457 mode and a new TLV (RP TLV) which enable the LSP ping initiator to 458 specify or constrain the return path of the echo reply. Similarly 459 the behavior of echo reply is extended to detect the requested 460 return path by looking at a specified path FEC TLV. This enables LSP 461 Ping to detect failures in both directions of a path with a single 462 operation, this of course cuts in half the operational steps 463 required to verify the end to end bidirectional connectivity and 464 integrity of an LSP. 466 When the echo reply message is intended to test the return MPLS LSP 467 path, the destination IP address of the echo reply message MUST 468 never be used in a forwarding decision. To avoid this possibility 469 the destination IP address of the echo reply message that is 470 transmitted along the specified return path MUST be set to numbers 471 from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, 472 and the IP TTL MUST be set 1. Of course when the echo reply message 473 is not intended for testing the specified return path, the 474 procedures defined in [RFC4379] (the destination IP address is 475 copied from the source IP address) apply unchanged. 477 4.1. Sending an Echo Request 479 When sending an echo request, in addition to the rules and 480 procedures defined in Section 4.3 of [RFC4379], the reply mode of 481 the echo request MUST be set to "Reply via specified path", and a RP 482 TLV MUST be carried in the echo request message correspondingly. The 483 RP TLV includes one or several reply path sub-TLV(s) to identify the 484 return path(s) the egress LSR should use for its reply. 486 For a bidirectional LSP, since the ingress LSR and egress LSR of a 487 bidirectional LSP are aware of the relationship between the forward 488 and backward direction LSPs, only a Bidirectional sub-TLV SHOULD be 489 carried within the RP TLV. If the operator wants the echo reply to 490 be sent along a different path other than the reverse direction of 491 the bidirectional LSP, another FEC sub-TLV SHOULD be carried in the 492 RP TLV instead. 494 In some cases, operators may want to treat two unidirectional LSPs 495 (one for each direction) as a pair. There may not be any binding 496 relationship between the two LSPs. Using the mechanism defined in 497 this document, operators can run LSP Ping one time from one end to 498 complete the failure detection on both unidirectional LSPs. To 499 accomplish this, the echo request message MUST carry (in the RP TLV) 500 a FEC sub-TLV that belongs to the backward LSP. 502 4.2. Receiving an Echo Request 504 "Ping" mode processing as defined in Section 4.4 of [RFC4379] 505 applies in this document. In addition, when an echo request is 506 received, if the egress LSR does not know the reply mode defined in 507 this document, an echo reply with the return code set to "Malformed 508 echo request" and the Subcode set to zero will be send back to the 509 ingress LSR according to the rules of [RFC4379]. If the egress LSR 510 knows the reply mode, according to the RP TLV, it SHOULD find and 511 select the desired return path, if there is no such path, an echo 512 reply with Errored TLVs [RFC4379] that contains the RP TLV SHOULD be 513 sent back to the ingress LSR, which is used to tell the ingress LSR 514 that the requested return path does not exist. 516 As described in Section 3.3.4 of this document, the Any Candidate 517 sub-TLV has two functions: 1) helping the egress LSR to exclude some 518 undesired paths, and 2) indicating whether the return path SHOULD be 519 tested (by carrying the FEC stack TLV of the return path). 521 If an Any Candidate sub-TLV is present, the egress LSR MUST exclude 522 the paths identified by those FEC sub-TLVs carried in the RP TLV and 523 select other path to send the echo reply. 525 If no Any Candidate sub-TLV is present, it means that the echo reply 526 is REQUIRED not only to send along the specified path, but to detect 527 the selected return path as well (by carrying the FEC stack TLV of 528 the return path). In addition, the FEC validate results of forward 529 path LSP SHOULD not affect the egress LSR continue to test return 530 path LSP. 532 4.3. Sending an Echo Reply 534 As described in [RFC4379], the echo reply message is a UDP packet, 535 and it MUST be sent only in response to an MPLS echo request. The 536 source IP address is a routable IP address of the replier, the 537 source UDP port is the well-know UDP port for LSP ping. 539 When the echo reply is intended to test the return path, the 540 destination IP address of the echo reply message MUST never be used 541 in a forwarding decision. To avoid this problem, the IP destination 542 address of the echo reply message that is transmitted along the 543 specified return path MUST be set to numbers from the range 127/8 544 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be 545 set 1. If the echo reply is required to test the return path, the 546 echo reply MUST have a FEC stack TLV describing the return path, 547 which is used for the ingress LSR to perform FEC validation. The FEC 548 stack TLV of the forward path MUST NOT be copied to the echo reply. 549 And the FEC stack TLV of forward LSP MUST not be copied to the echo 550 reply. 552 If the echo reply message is not intended for testing the specified 553 return path, the same as defined in [RFC4379], the destination IP 554 address and UDP port are copied from the source IP address and 555 source UDP port of the echo request. 557 When sending the echo reply, the RP TLV carried in the received echo 558 request MAY be copied to the echo reply to give the Ingress LSR 559 enough information about the reverse direction of the tested path to 560 verify the consistency of the data plane against control plane. 562 4.4. Receiving an Echo Reply 564 The rules and process defined in Section 4.6 of [RFC4379] apply here. 565 When an echo reply is received, if the reply mode is "Reply via 566 specified path" and a FEC stack TLV exists, it means that the echo 567 reply has both Ping result reporting and reverse path checking 568 functions. The ingress LSR MUST do FEC validation as an egress LSR 569 does when receiving an echo request, the FEC validation process 570 (relevant to "ping" mode) defined in Section 4.4.1 of [RFC4379] 571 applies here. 573 When an echo reply is received with return code set to "Malformed 574 echo request received" and the Subcode set to zero. It is possible 575 that the egress LSR may not know the "Reply via specified path" 576 reply mode, the operator may choose to re-perform another LSP Ping 577 by using one of the four reply modes defined [RFC4379]. 579 On receipt of an echo reply with an Errored TLVs and an RP TLV is 580 carried, if the return code is not set to "TLV not understood", it 581 means that the egress LSR could not find a matched return path as 582 specified. Operators may choose to specify another LSP as the return 583 path or use other methods to detect the path. 585 When the LSP Ping initiator fails after some time to receive the 586 echo reply message, the operator MAY initiate another LSP Ping by 587 resending a new echo request carrying a RP TLV that includes an Any 588 Candidate sub-TLV and the previous sent reply path sub-TLV(s) 589 (Bidirectional sub-TLV or FEC sub-TLVs) to notify the egress LSR to 590 send echo reply message along any other workable path (no matter 591 what MPLS LSP or IP path) excluding the path(s) identified by those 592 Bidirectional sub-TLV or/and FEC sub-TLVs. Hence it could improve 593 the reliability of the echo reply message. In such a mode, the echo 594 reply SHOULD NOT be used to detect the return path. 596 5. Security Considerations 598 Security considerations discussed in [RFC4379] apply to this 599 document. In addition to that, in order to prevent using the 600 extension defined in this document for "proxying" any possible 601 attacks, the return path LSP MUST have destination to the same node 602 where the forward path is from. 604 6. IANA Considerations 606 IANA is requested to make the following allocations from registries 607 under its control. 609 6.1. Reply mode 611 IANA is requested to assign a new reply mode as follows: 613 Reply mode: 615 Value Meaning 616 ----- ------- 617 5 Reply via specified path 619 6.2. RP TLV 621 IANA is requested to assign a new TLV type (TBD) from the range of 622 0-16383. We suggest that the value 20 be assigned for the new RP TLV 623 type. 625 Type Value Field 626 ----- ----------- 627 20 Reply Path 629 6.3. Sub-TLVs for RP TLV 631 This document defines four new sub-TLV Types (described in Section 632 3.4, 3.5, 3.6 and 3.7) of RP TLV, and those FEC sub-TLVs defined in 633 [RFC4379] are applicable for inclusion in RP TVL. 635 IANA is requested to assign sub-TLVs as follows. The following 636 numbers are suggested: 638 Sub-type Value Field Reference 639 -------- ----------- --------- 640 17 Bidirectional this document 641 18 Any Candidate this document 642 19 IPv4 RSVP Tunnel this document 643 20 IPv6 RSVP Tunnel this document 645 7. Contributors 647 The following individuals also contributed to this document: 649 Ehud Doron 650 Orckit-Corrigent 652 EMail: ehudd@orckit.com 654 Ronen Solomon 655 Orckit-Corrigent 657 EMail: RonenS@orckit.com 659 Ville Hallivuori 660 Tellabs 661 Sinimaentie 6 C 662 FI-02630 Espoo, Finland 664 EMail: ville.hallivuori@tellabs.com 666 8. Acknowledgments 668 The authors would like to thank Adrian Farrel and Peter Ashwood- 669 Smith for their review, suggestion and comments to this document. 671 9. References 673 9.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, March 1997. 678 [RFC4379] K. Kompella., et al., "Detecting Multi-Protocol Label 679 Switched (MPLS) Data Plane Failures", RFC 4379, February 680 2006. 682 [BFD] D. Katz, D. and Ward, D., "Bidirectional Forwarding 683 Detection", draft-ietf-bfd-base, work in progress. 685 [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., 686 "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in progress. 688 [BFD-IP] D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", 689 draft-ietf-bfd-v4v6-1hop-08.txt. 691 9.2. Informative References 693 [RFC3471] L. Berger, "Generalized Multi-Protocol Label Switching 694 (GMPLS) Signaling Functional Description", RFC 3471, 695 January 2003. 697 [RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching 698 (GMPLS) Signaling", RFC 3473, January 2003. 700 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 701 (GMPLS) Architecture", RFC 3945, October 2004. 703 [RFC5654] Niven-Jenkins, B. (Ed.), Brungard, D. (Ed.), Betts, M. 704 (Ed.) Sprecher, N., and Ueno, S., "Requirements of an MPLS 705 Transport Profile", RFC 5654, September 2009. 707 Authors' Addresses 709 Mach(Guoyi) Chen 710 Huawei Technology Co., Ltd. 711 No. 9 Xinxi Road 712 Shangdi Information Industry Base 713 Hai-Dian District, Beijing 100085 714 China 716 EMail: mach@huawei.com 718 So Ning 719 Verizon 720 2400 N. Glem Ave., 721 Richerson, TX 75082 723 Phone: +1 972-729-7905 724 EMail: ning.so@verizonbusiness.com 726 Frederic Jounay 727 France Telecom 728 2, avenue Pierre-Marzin 729 22307 Lannion Cedex 730 FRANCE 732 EMail: frederic.jounay@orange-ftgroup.com 734 Simon Delord 735 Telstra 736 242 Exhibition St 737 Melbourne VIC 3000 738 Australia 740 EMail: simon.a.delord@team.telstra.com 742 Xinchun Guo 743 Huawei Technology Co., Ltd. 744 No. 9 Xinxi Road 745 Shangdi Information Industry Base 746 Hai-Dian District, Beijing 100085 747 China 748 EMail: guoxinchun@huawei.com 750 Wei Cao 751 Huawei Technology Co., Ltd. 752 No. 9 Xinxi Road 753 Shangdi Information Industry Base 754 Hai-Dian District, Beijing 100085 755 China 757 EMail: caoweigne@huawei.com