idnits 2.17.1 draft-ietf-mpls-return-path-specified-lsp-ping-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3839 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen 3 Internet-Draft W. Cao 4 Intended status: Standards Track Huawei Technologies Co., Ltd 5 Expires: April 24, 2014 S. Ning 6 Tata Communications 7 F. Jounay 8 Orange CH 9 S. Delord 10 Alcatel-Lucent 11 October 21, 2013 13 Return Path Specified LSP Ping 14 draft-ietf-mpls-return-path-specified-lsp-ping-15.txt 16 Abstract 18 This document defines extensions to the data-plane failure-detection 19 protocol for Multiprotocol Label Switching (MPLS) Label Switched 20 Paths (LSPs) known as "LSP Ping". These extensions allow selection 21 of the LSP to use for the echo reply return path. Enforcing a 22 specific return path can be used to verify bidirectional connectivity 23 and also increase LSP ping robustness. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 24, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 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 3 68 2.2. Limitations of Existing Mechanisms for Handling 69 Unreliable Return Paths . . . . . . . . . . . . . . . . . 4 70 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Reply Via Specified Path mode . . . . . . . . . . . . . . 5 72 3.2. Reply Path (RP) TLV . . . . . . . . . . . . . . . . . . . 6 73 3.3. Tunnel sub-TLVs . . . . . . . . . . . . . . . . . . . . . 8 74 3.3.1. IPv4 RSVP Tunnel sub-TLV . . . . . . . . . . . . . . 9 75 3.3.2. IPv6 RSVP Tunnel sub-TLV . . . . . . . . . . . . . . 10 76 3.3.3. Static Tunnel sub-TLV . . . . . . . . . . . . . . . . 11 77 3.4. Reply TC TLV . . . . . . . . . . . . . . . . . . . . . . 11 78 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 12 79 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 12 80 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 13 81 4.3. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 14 82 4.4. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 14 83 4.5. Non-IP Encapsulation for MPLS-TP LSPs . . . . . . . . . . 15 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 6.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 6.2. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 16 88 6.3. New Reply Mode . . . . . . . . . . . . . . . . . . . . . 16 89 6.4. Reply Path Return Code . . . . . . . . . . . . . . . . . 17 90 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 94 9.2. Informative References . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 This document defines extensions to the data-plane failure-detection 100 protocol for Multiprotocol Label Switching (MPLS) Label Switched 101 Paths (LSPs) known as "LSP Ping" [RFC4379] that can be used to 102 specify the return paths for the echo reply message, increasing the 103 robustness of LSP Ping, reducing the opportunity for error, and 104 improving the reliability of the echo reply message. A new reply 105 mode, which is referred to as "Reply via Specified Path", is added 106 and a new Type-Length-Value (TLV), which is referred to as Reply Path 107 (RP) TLV, is defined in this memo. The procedures defined in this 108 document currently only apply to "ping" mode. The "traceroute" mode 109 is out of scope for this document. 111 In this document, the term bidirectional LSP includes the co-routed 112 bidirectional LSP defined in [RFC3945] and the associated 113 bidirectional LSP that is constructed from a pair of unidirectional 114 LSPs (one for each direction), and which are associated with one 115 another at the LSP's ingress/egress points [RFC5654]. The mechanisms 116 defined in this document can apply to both IP/MPLS and MPLS Transport 117 Profile (MPLS-TP) scenarios. 119 2. Problem Statements and Solution Overview 121 MPLS LSP Ping is defined in [RFC4379]. It can be used to detect data 122 path failures in all MPLS LSPs. 124 LSP are increasingly being deployed to provide bidirectional 125 services. The co-routed bidirectional LSP is defined in [RFC3945], 126 and the associated bidirectional LSP is defined in [RFC5654]. With 127 the deployment of such services, operators have a desire to test both 128 directions of a bidirectional LSP in a single operation. 130 Additionally, when testing a single direction of an LSP (either a 131 unidirectional LSP, or a single direction of a bidirectional LSP) 132 using LSP Ping, the validity of the result may be affected by the 133 success of delivering the echo reply message. Failure to exchange 134 these messages between the egress Label Switching Router (LSR) and 135 the ingress LSR can lead to false negatives where the LSP under test 136 is reported as "down" even though it is functioning correctly. 138 2.1. Limitations of Existing Mechanisms for Bidirectional LSPs 139 With the existing LSP Ping mechanisms as defined in [RFC4379], 140 operators have to enable LSP detection on each of the two ends of a 141 bidirectional LSP independently. This not only doubles the workload 142 for the operators, but may also bring additional difficulties when 143 checking the backward direction of the LSP under the following 144 condition: 146 The LSR that the operator logged on to perform the checking 147 operations might not have out-of-band connectivity to the LSR at 148 the far end of the LSP. That can mean it is not possible to check 149 the return direction of a bidirectional LSP in a single operation 150 - the operator must log on to the LSR at the other end of the LSP 151 to test the return direction. 153 Associated bidirectional LSPs have the same issues as those listed 154 for co-routed bidirectional LSPs. 156 This document defines a mechanism to allow the operator to request 157 that both directions of a bidirectional LSP be tested by a single LSP 158 Ping message exchange. 160 2.2. Limitations of Existing Mechanisms for Handling Unreliable Return 161 Paths 163 [RFC4379] defines 4 reply modes: 165 1. Do not reply 166 2. Reply via an IPv4/IPv6 UDP packet 167 3. Reply via an IPv4/IPv6 UDP packet with Router Alert 168 4. Reply via application level control channel. 170 Obviously, the issue of the reliability of the return path for an 171 echo reply message does not apply in the first of these cases. 173 [RFC4379] states that the third mode may be used when the IP return 174 path is deemed unreliable. This mode of operation requires that all 175 intermediate nodes must support the Router Alert option and must 176 understand and know how to forward MPLS echo replies. This is a 177 rigorous requirement in deployed IP/MPLS networks especially since 178 the return path may be through legacy IP-only routers. 180 And in any case, the use modes 2 or 3 cannot guarantee the delivery 181 of echo responses through an IP network that is fundamentally 182 unreliable. The failure to deliver echo response messages can lead 183 to false negatives making it appear that the LSP has failed. 185 Allowing the ingress LSR to control the path used for echo reply 186 messages enables an operator to apply an extra level of deterministic 187 process to the LSP Ping test. For example, when testing an LSP, the 188 Reply Mode 2 is used at the beginning but no echo reply received. 189 When the return path is suspected with failure, the operator can 190 initiate another LSP Ping with the Reply Mode defined in this 191 document and specify a different return path that is deemed workable 192 to complete the test. 194 This document defines extensions to LSP Ping that can be used to 195 specify the return paths of the echo reply message in an echo request 196 message. 198 3. Extensions 200 LSP Ping defined in [RFC4379] is carried out by sending an echo 201 request message. It carries the Forwarding Equivalence Class (FEC) 202 information of the LSP being tested which indicates which MPLS path 203 is being verified, along the same data path as other normal data 204 packets belonging to the FEC. 206 LSP Ping [RFC4379] defines four reply modes that are used to direct 207 the egress LSR in how to send back an echo reply. This document 208 defines a new reply mode, the Reply via Specified Path mode. This 209 new mode is used to direct the egress LSR of the tested LSP to send 210 the echo reply message back along the path specified in the echo 211 request message. 213 In addition, two new TLVs, the Reply Path TLV and Reply Traffic Class 214 (TC) [RFC5462] TLV, are defined in this document. The Reply Path TLV 215 contains one or more nested sub-TLVs that can be used to carry the 216 specified return path information to be used by the echo reply 217 message. 219 3.1. Reply Via Specified Path mode 221 A new reply mode is defined to be carried in the Reply Mode field of 222 the echo request message. 224 The value of the Reply via Specified Path mode is 5 (This has been 225 allocated by IANA using early allocation and is to be confirmed by 226 IANA). 228 Value Meaning 229 ----- ------- 230 5 Reply via Specified Path 232 The Reply via Specified Path mode is used to request that the remote 233 LSR receiving the echo request message sends back the echo reply 234 message along the specified paths carried in the Reply Path TLV. 236 3.2. Reply Path (RP) TLV 238 The Reply Path (RP) TLV is an optional TLV within the LSP Ping 239 protocol. However, if the Reply via Specified Path mode requested as 240 described in Section 3.1, the Reply Path (RP) TLV MUST be included in 241 an echo request message and its absence is treated as a malformed 242 echo request as described in [RFC4379]. Furthermore, if a Reply Path 243 (RP) TLV is included in an echo request message, a Reply Path (RP) 244 TLV MUST be included in the corresponding echo reply message sent by 245 an implementation that is conformant to this specification. 247 The Reply Path (RP) TLV carries the specified return path that the 248 echo reply message is required to follow. The format of Reply Path 249 TLV is as follows: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Reply Path TLV Type | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Reply Path return code | Flags | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Reply Path | 259 ~ ~ 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 1 Reply Path TLV 265 Reply Path TLV Type: It is 2 octets in length, and the type value is 266 21. (This has been allocated by IANA using early allocation and 267 is to be confirmed by IANA). 269 Length: It is 2 octets in length. It defines the length in octets 270 of the Reply Path return code, Flags and Reply Path fields. 272 Reply Path return code: The Reply Path return code field is 2 octets 273 in length. It is defined for the egress LSR of the forward LSP to 274 report the results of Reply Path TLV processing and return path 275 selection. This field MUST be set to zero in a Reply Path TLV 276 carried on an echo request message and MUST be ignored on receipt. 277 This document defines the following Reply Path return codes for 278 inclusion in a Reply Path TLV carried on an echo reply: 280 Value Meaning 281 ------ ---------------------- 282 0x0000 Reserved, MUST NOT be used 283 0x0001 Malformed Reply Path TLV was received 284 0x0002 One or more of the sub-TLVs in Reply Path TLV 285 were not understood 286 0x0003 The echo reply was sent successfully using the 287 specified Reply Path 288 0x0004 The specified Reply Path was not found, the echo 289 reply was sent via other LSP 290 0x0005 The specified Reply Path was not found, the echo 291 reply was sent via pure IP forwarding (non-MPLS) 292 path 293 0x0006-0xfffb Not allocated, allocated via Standard Action 294 0xfffc-0xffff Experimental Use 296 Flags: It is also 2 octets in length, it is used to notify the 297 egress how to process the Reply Paths field when performing return 298 path selection. The Flags field is a bit vector and has following 299 format: 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | MUST be zero |A|B| 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 2 Flags 306 A (Alternative path): the egress LSR MUST select a non-default 307 path as the return path. This is very useful when reverse 308 default path problems are suspected which can be confirmed when 309 the echo reply is forced to follow a non-default return path. 310 Here, the default path refers to the path that the egress LSR 311 will use to send the echo reply when Reply Mode 2 or 3 is used. 312 If A bit is set, there is no need to carry any specific reply 313 path sub-TLVs, and when received, the sub-TLVs SHOULD be 314 ignored. 316 B (Bidirectional): the return path is required to follow the 317 reverse direction of the tested bidirectional LSP. If B bit is 318 set, there is no need to carry any specific reply path sub- 319 TLVs, and when received, the sub-TLVs SHOULD be ignored. 321 The A bit and B bit set MUST NOT both be set, otherwise, an 322 echo reply with the RP return code set to "Malformed RP TLV was 323 received" MUST be returned. 325 Reply Path: It is used to describe the return path that an echo 326 reply will be send along. It is variable in length and can 327 contain zero, one or more Target FEC sub-TLVs [RFC4379] . In echo 328 request, it carries sub-TLVs that describe the specified path that 329 the echo reply message is required to follow. In echo reply, the 330 sub-TLVs describe the FEC Stack information of the return path 331 (when the return path is an MPLS path) that the echo reply will be 332 sent along. 334 3.3. Tunnel sub-TLVs 336 [RFC4379] has already defined several Target FEC sub-TLVs, the Target 337 FEC sub-TLVs provide a good way to identify a specific return path. 338 The Reply Path TLV can carry any (existing and future defined) sub- 339 TLV defined for use in the Target FEC Stack TLV to specify the return 340 path. 342 This document defines three new Target FEC sub-TLVs: IPv4 RSVP Tunnel 343 sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. One 344 usage of these generic RSVP Tunnel sub-TLVs is when LSP Ping is used 345 to periodically verify the control plane against the data plane 346 [RFC5884], using Tunnel other than particular LSP can avoid the 347 impact of LSP identifier changing when Make-Before-Break (MBB) is 348 deployed. These sub-TLVs also can be used in the Reply Path TLV to 349 allow the operator to specify a more generic tunnel FEC other than a 350 particular LSP as the return path. 352 No assignments of sub-TLVs are made directly for TLV Type 21, the 353 sub-TLV space and assignments for this TLV Type 21 will be the same 354 as that for TLV Type 1. Sub-types for TLV Type 1 and TLV Type 21 355 MUST be kept the same. Any new sub-type added to TLV Type 1 MUST 356 apply to the TLV Type 21 as well. 358 With the Return Path TLV flags and the sub-TLVs defined for the 359 Target FEC Stack TLV and in this document, it could provide following 360 options for return paths specifying: 362 1. Specify a particular LSP as return path 364 - use those sub-TLVs defined for the Target FEC Stack TLV 366 2. Specify a more generic tunnel FEC as return path 368 - use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in 369 Section 3.3.1, Section 3.3.2 and Section 3.3.3 of this 370 document 372 3. Specify the reverse path of the bidirectional LSP as return path 373 - use B bit defined in Section 3.2 of this document. 375 4. Force return path to non-default path 377 - use A bit defined in Section 3.2 of this document. 379 3.3.1. IPv4 RSVP Tunnel sub-TLV 381 The format of IPv4 RSVP Tunnel sub-TLV is as follows: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | IPv4 RSVP Tunnel sub-TLV Type | Length | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | IPv4 tunnel end point address | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Flags | Tunnel ID | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Extended Tunnel ID | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | IPv4 tunnel sender address | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Figure 3 IPv4 RSVP Tunnel sub-TLV 398 The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV 399 that is defined in Section 3.2.3 [RFC4379]. All fields have the same 400 semantics as defined in [RFC4379] except that the LSP-ID field is 401 omitted and a new Flags field is defined. 403 The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and 404 the recommended type value is TBD1. 406 The Flags field is 2 octets in length, it is used to notify the 407 egress LSR how to choose the return path. The Flags field is a bit 408 vector and has following format: 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | MUST be zero |S|P| 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 4 Tunnel Flags 415 P (Primary): the return path MUST be chosen from the LSPs that belong 416 to the specified Tunnel and the LSP MUST be the primary LSP. 418 S (Secondary): the return path MUST be chosen from the LSPs that 419 belong to the specified Tunnel and the LSP MUST be the secondary LSP. 421 The terminologies and definitions of primary and secondary LSP are 422 defined [RFC4872]. 424 P bit and S bit MUST NOT both be set, otherwise, an echo reply with 425 the RP return code set to "Malformed RP TLV was received" SHOULD be 426 returned. If P bit and S bit are both not set, the return path could 427 be any one of the LSPs from the same Tunnel. 429 3.3.2. IPv6 RSVP Tunnel sub-TLV 431 The format of IPv6 RSVP Tunnel sub-TLV is as follows: 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | IPv6 RSVP Tunnel sub-TLV Type | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | IPv6 tunnel end point address | 439 | | 440 | | 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Flags | Tunnel ID | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Extended Tunnel ID | 446 | | 447 | | 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | IPv6 tunnel sender address | 451 | | 452 | | 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 5 IPv6 RSVP Tunnel sub-TLV 457 The IPv6 RSVP Tunnel sub-TLV is derived from RSVP IPv6 FEC TLV that 458 is defined in Section 3.2.4 of [RFC4379].All fields have the same 459 semantics as defined in [RFC4379] except that the LSP-ID field is 460 omitted and a new Flags field is defined. 462 The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and 463 the type value is TBD2. 465 The Flags field is 2 octets in length and is identical to that 466 described in Section 3.3.1. 468 3.3.3. Static Tunnel sub-TLV 470 The format of Static RSVP Tunnel sub-TLV is as follows. The value 471 fields are taken from the definitions in [RFC6370]. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Static Tunnel sub-TLV Type | Length | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Source Global ID | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Source Node ID | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Destination Global ID | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Destination Node ID | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Source Tunnel Num | Destination Tunnel Num | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Flags | Must Be Zero | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 6 Static Tunnel sub-TLV 492 The Flags field is 2 octets in length and is identical to that 493 described in Section 3.3.1. 495 The sub-TLV type value is TBD3. 497 3.4. Reply TC TLV 499 Reply TOS Byte TLV [RFC4379] is used by the originator of the echo 500 request to request that an echo reply be sent with the IP header TOS 501 byte set to the value specified in the TLV. Similarly, in this 502 document, a new TLV: Reply TC TLV is defined and MAY be used by the 503 originator of the echo request to request that an echo reply be sent 504 with the TC bits of the return path LSP set to the value specified in 505 this TLV. The Reply TC TLV is not limited to the reply mode 506 specified in this document (Reply via Specified Path) but may be used 507 in all the other reply modes as well. The format of Reply TC TLV is 508 as follows: 510 0 1 2 3 511 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Reply TC TLV type | Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | TC | MUST be zero | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 7 Reply TC TLV 520 The Reply TC TLV Type field is 2 octets in length, and the type value 521 is TBD4. 523 The Length field is 2 octets in length, the value of length field is 524 fixed 4 octets. 526 4. Theory of Operation 528 The procedures defined in this document currently only apply to 529 "ping" mode. The "traceroute" mode is out of scope for this 530 document. 532 In [RFC4379], the echo reply is used to report the LSP checking 533 result to the LSP Ping initiator. This document defines a new reply 534 mode and a new TLV (Reply Path TLV) that enable the LSP ping 535 initiator to specify or constrain the return path of the echo reply. 536 Similarly the behavior of echo reply is extended to detect the 537 requested return path by looking at a specified path FEC TLV. This 538 enables LSP Ping to detect failures in both directions of a path with 539 a single operation, this of course cuts in half the operational steps 540 required to verify the end to end bidirectional connectivity and 541 integrity of an LSP. 543 When the return path is an MPLS path, the echo reply MUST carry the 544 FEC stack information in a Reply Path TLV to test the return MPLS LSP 545 path. The destination IP address of the echo reply message MUST 546 never be used in a forwarding decision. To avoid this possibility 547 the destination IP address of the echo reply message that is 548 transmitted along the specified return path MUST be set to numbers 549 from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for 550 IPv6, and the IP TTL MUST be set 1, and the TTL in the outermost 551 label MUST be set to 255. 553 When the return path is a pure IP forwarding path, the procedures 554 defined in [RFC4379] (the destination IP address is copied from the 555 source IP address) apply unchanged. 557 4.1. Sending an Echo Request 558 When sending an echo request, in addition to the rules and procedures 559 defined in Section 4.3 of [RFC4379], the reply mode of the echo 560 request MUST be set to "Reply via Specified Path", and a Reply Path 561 TLV MUST be carried in the echo request message correspondingly. The 562 Reply Path TLV includes one or several reply path sub-TLV(s) to 563 identify the return path(s) the egress LSR should use for its reply. 565 For a bidirectional LSP, since the ingress LSR and egress LSR of a 566 bidirectional LSP are aware of the relationship between the forward 567 and backward direction LSPs, only the B bit SHOULD be set in the 568 Reply Path TLV. If the operator wants the echo reply to be sent 569 along a different path other than the reverse direction of the 570 bidirectional LSP, the "A" bit SHOULD be set or another FEC sub-TLV 571 SHOULD be carried in the Reply Path TLV instead, and the B bit MUST 572 be clear. 574 In some cases, operators may want to treat two unidirectional LSPs 575 (one for each direction) as a pair. There may not be any binding 576 relationship between the two LSPs. Using the mechanism defined in 577 this document, operators can run LSP Ping one time from one end to 578 complete the failure detection on both unidirectional LSPs. To 579 accomplish this, the echo request message MUST carry (in the Reply 580 Path TLV) a FEC sub-TLV that belongs to the backward LSP. 582 4.2. Receiving an Echo Request 584 "Ping" mode processing as defined in Section 4.4 of [RFC4379] applies 585 in this document. In addition, when an echo request is received, if 586 the egress LSR does not know the reply mode defined in this document, 587 an echo reply with the return code set to "Malformed echo request" 588 and the Subcode set to zero will be send back to the ingress LSR 589 according to the rules of [RFC4379]. If the egress LSR knows the 590 reply mode, according to the Reply Path TLV, it SHOULD find and 591 select the desired return path. If there is a matched path, an echo 592 reply with Reply Path TLV that identify the return path SHOULD be 593 sent back to the ingress LSR, the Reply Path return code SHOULD be 594 set to "The echo reply was sent successfully using the specified 595 return path". If there is no such path, an echo reply with Reply 596 Path TLV SHOULD be sent back to the ingress LSR, the Reply Path 597 return code SHOULD be set to relevant code (defined Section 3.2) for 598 the real situation to reflect the result of Reply Path TLV processing 599 and return path selection. For example, if the specified LSP is not 600 found, the egress then chooses another LSP as the return path to send 601 the echo reply, the Reply Path return code SHOULD be set to "The 602 specified reply path was not found, the echo reply was sent via other 603 LSP", and if the egress chooses an IP path to send the echo reply, 604 the Reply Path return code SHOULD be set to "The specified reply path 605 was not found, the echo reply was sent via IP path". If there is 606 unknown sub-TLV in the received Reply Path TLV, the Reply Path return 607 code SHOULD be set to "One or more of the sub-TLVs in Reply Path TLV 608 was not understood". 610 If the A bit of the Reply Path TLV in a received echo request message 611 is set, the egress LSR SHOULD send the echo reply along an non- 612 default return path. 614 IF the B bit of the Reply Path TLV in a received echo request message 615 is set, the egress LSR SHOULD send the echo reply along the reverse 616 direction of the bidirectional LSP. 618 In addition, the FEC validate results of the forward path LSP SHOULD 619 NOT affect the egress LSR continue to test return path LSP. 621 4.3. Sending an Echo Reply 623 As described in [RFC4379], the echo reply message is a UDP packet, 624 and it MUST be sent only in response to an MPLS echo request. The 625 source IP address is a valid IP address of the replier, the source 626 UDP port is the well-know UDP port for LSP ping. 628 When the return path is an MPLS LSP path, the destination IP address 629 of the echo reply message is copied from the destination IP address 630 of echo request, the destination UDP port is copied from the source 631 UDP port of the echo request. The IP TTL MUST be set to 1, the TTL 632 in the outermost label MUST be set to 255. 634 When the return path is a pure IP forwarding path, the same as 635 defined in [RFC4379], the destination IP address and UDP port are 636 copied from the source IP address and source UDP port of the echo 637 request. 639 When sending the echo reply, a Reply Path TLV that identifies the 640 return path MUST be carried, the Reply Path return code SHOULD be set 641 to relevant code that reflects results about how the egress processes 642 the Reply Path TLV in a previous received echo request message and 643 return path selection. By carrying the Reply Path TLV in an echo 644 reply, it gives the Ingress LSR enough information about the reverse 645 direction of the tested path to verify the consistency of the data 646 plane against control plane. Thus a single LSP Ping could achieve 647 both directions of a path test. If the return path is pure IP path, 648 no sub-TLVs are carried in the Reply Path TLV. 650 4.4. Receiving an Echo Reply 652 The rules and process defined in Section 4.6 of [RFC4379] apply here. 653 When an echo reply is received, if the reply mode is "Reply via 654 Specified Path" and the Reply Path return code is "The echo reply was 655 sent successfully using the specified return path", and if the return 656 path is an MPLS LSP. The ingress LSR MUST perform FEC validation 657 (based on the FEC stack information of the return path carried in the 658 Reply Path TLV) as an egress LSR does when receiving an echo request, 659 the FEC validation process (relevant to "ping" mode) defined in 660 Section 4.4.1 of [RFC4379] applies here. 662 When an echo reply is received with return code set to "Malformed 663 echo request received" and the Subcode set to zero. It is possible 664 that the egress LSR may not know the "Reply via Specified Path" reply 665 mode, the operator may choose to re-perform another LSP Ping by using 666 one of the four reply modes defined [RFC4379]. 668 On receipt of an echo reply with Reply Path return code in the Reply 669 Path TLV set to "The specified reply path was not found, ...", it 670 means that the egress LSR could not find a matched return path as 671 specified. Operators may choose to specify another LSP as the return 672 path or use other methods to detect the path further. 674 4.5. Non-IP Encapsulation for MPLS-TP LSPs 676 In some MPLS-TP deployment scenarios, IP addressing might not be 677 available or use some form of non-IP encapsulation might be 678 preferred. In such scenarios, the Non-IP encapsulation defined in 679 [RFC6426] applies here. The LSP Ping Reply Mode in echo request and 680 echo reply is set to 5. The return path of the echo reply is as 681 specified in the Reply Path TLV. 683 5. Security Considerations 685 Security considerations discussed in [RFC4379] apply to this 686 document. 688 In addition, the extensions defined in this document may be used for 689 potential "proxying" attacks. For example, an echo request initiator 690 may specify a return path that has the destination different from the 691 initiator. But normally, such attacks will not happen in an MPLS 692 domain where the initiators and receivers belong to the same domain. 693 Even this, in order to prevent using the extension defined in this 694 document for "proxying" any possible attacks, the return path LSP 695 should have destination to the same node where the forward path is 696 from. The receiver may drop the echo request when it cannot 697 determine whether the return path LSP has the destination to the 698 initiator. That means, when sending echo request, the initiator 699 should choose a proper source address according the specified return 700 path LSP to help the receiver to make the decision. 702 6. IANA Considerations 704 6.1. TLVs 706 The IANA is requested to assign the temporary assigned value (21) for 707 the Reply Path TLV and assign one new value (TBD4) for Reply TC TLV 708 from the "Multiprotocol Label Switching Architecture (MPLS) Label 709 Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and 710 sub-TLVs" sub-registry. 712 Note: IANA have made an early allocation of the value 21 for Reply 713 Path TLV. 715 Value Meaning Reference 716 ----- ------- --------- 717 21 Reply Path TLV this document (sect 3.2) 718 TBD4 Reply TC TLV this document (sect 3.4) 720 The sub-TLV space and assignments for the Reply Path TLV will be the 721 same as that for the Target FEC Stack TLV. Sub-types for the Target 722 FEC Stack TLV and the Reply Path TLV MUST be kept the same. Any new 723 sub-type added to the Target FEC Stack TLV MUST apply to the Reply 724 Path TLV as well. 726 6.2. New Target FEC Stack Sub-TLVs 728 IANA is also requested to assign three new sub-TLV types from 729 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 730 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV Type 731 1" sub-registry. 733 Sub-type Value Field Reference 734 ------- ----------- --------- 735 TBD1 IPv4 RSVP Tunnel this document (sect 3.3.1) 736 TBD2 IPv6 RSVP Tunnel this document (sect 3.3.2) 737 TBD3 Static Tunnel this document (sect 3.3.3) 739 6.3. New Reply Mode 741 IANA has made an early allocation (5 - Reply via specified path) from 742 the "Multi-Protocol Label Switching (MPLS) Label Switched Paths 743 (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry. 744 IANA is requested to make this allocation permanent. 746 Value Meaning Reference 747 ----- ------- ---------- 748 5 Reply via Specified Path this document (sect 3.1) 750 6.4. Reply Path Return Code 752 IANA is requested to create a new registry (as part of mpls-lsp-ping- 753 parameters ) for Reply Path return code. 755 This document (Section 3.2) defines the following return codes: 757 Value Meaning 758 ------ ---------------------- 759 0x0000 No return code 760 0x0001 Malformed Reply Path TLV was received 761 0x0002 One or more of the sub-TLVs in Reply Path TLV 762 were not understood 763 0x0003 The echo reply was sent successfully using the 764 specified Reply Path 765 0x0004 The specified Reply Path was not found, the echo 766 reply was sent via other LSP 767 0x0005 The specified Reply Path was not found, the echo 768 reply was sent via pure IP forwarding (non-MPLS) 769 path 770 0x0006-0xfffb Not allocated, allocated via Standard Action 771 0xfffc-0xffff Experimental Use 773 The range of 0x0006-0xfffb is not allocated and reserved for future 774 extensions and is allocated via Standard Action, the range of 0xfffc- 775 0xffff is for Experimental Use. 777 7. Contributors 779 The following individuals also contributed to this document: 781 Ehud Doron 782 Orckit-Corrigent 783 EMail: ehudd@orckit.com 785 Ronen Solomon 786 Orckit-Corrigent 787 EMail: RonenS@orckit.com 789 Ville Hallivuori 790 Tellabs 791 Sinimaentie 6 C 792 FI-02630 Espoo, Finland 793 EMail: ville.hallivuori@tellabs.com 795 Xinchun Guo 796 EMail: guoxinchun@huawei.com 798 8. Acknowledgements 800 The authors would like to thank Adrian Farrel, Peter Ashwood-Smith, 801 Sriganesh Kini, Gregory Mirsky, Eric Gray, Loa Andersson, Carlos 802 Pignataro and Tom Petch for their review, suggestion and comments to 803 this document. 805 9. References 807 9.1. Normative References 809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 810 Requirement Levels", BCP 14, RFC 2119, March 1997. 812 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 813 Label Switched (MPLS) Data Plane Failures", RFC 4379, 814 February 2006. 816 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 817 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 819 9.2. Informative References 821 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 822 (GMPLS) Architecture", RFC 3945, October 2004. 824 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 825 Extensions in Support of End-to-End Generalized Multi- 826 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 827 2007. 829 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 830 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 831 Class" Field", RFC 5462, February 2009. 833 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 834 and S. Ueno, "Requirements of an MPLS Transport Profile", 835 RFC 5654, September 2009. 837 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 838 "Bidirectional Forwarding Detection (BFD) for MPLS Label 839 Switched Paths (LSPs)", RFC 5884, June 2010. 841 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 842 On-Demand Connectivity Verification and Route Tracing", 843 RFC 6426, November 2011. 845 Authors' Addresses 847 Mach(Guoyi) Chen 848 Huawei Technologies Co., Ltd 849 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 850 Beijing 100095 851 China 853 Email: mach.chen@huawei.com 855 Wei Cao 856 Huawei Technologies Co., Ltd 857 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 858 Beijing 100095 859 China 861 Email: wayne.caowei@huawei.com 863 So Ning 864 Tata Communications 866 Email: ning.so@tatacommunications.com 868 Frederic Jounay 869 Orange CH 870 4 rue caudray 1020 Renens 871 Switzerland 873 Email: frederic.jounay@orange.ch 874 Simon Delord 875 Alcatel-Lucent 876 Building 3, 388 Ningqiao Road, Jinqiao, Pudong 877 Shanghai 201206 878 China 880 Email: simon.delord@alcatel-lucent.com