idnits 2.17.1 draft-ietf-mpls-self-ping-06.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 (November 1, 2015) is 3092 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 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track I. Minei 5 Expires: May 4, 2016 Google, Inc. 6 M. Conn 7 D. Pacella 8 L. Tomotaki 9 Verizon 10 November 1, 2015 12 LSP Self-Ping 13 draft-ietf-mpls-self-ping-06 15 Abstract 17 When certain RSVP-TE optimizations are implemented, ingress LSRs can 18 receive RSVP RESV messages before forwarding state has been installed 19 on all downstream nodes. According to the RSVP-TE specification, the 20 ingress LSR can forward traffic through an LSP as soon as it receives 21 a RESV message. However, if the ingress LSR forwards traffic through 22 the LSP before forwarding state has been installed on all downstream 23 nodes, traffic can be lost. 25 This document describes LSP Self-ping. When an ingress LSR receives 26 an RESV message, it can invoke LSP Self-ping procedures to ensure 27 that forwarding state has been installed on all downstream nodes. 29 LSP Self-ping is a new protocol. It is not an extension of LSP Ping. 30 Although LSP Ping and LSP Self-ping are named similarly, each is 31 designed for a unique purpose. Each protocol listens on its own UDP 32 port and executes its own procedures. 34 LSP Self-ping is an extremely light-weight mechanism. It does not 35 consume control plane resources on transit or egress LSRs. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on May 4, 2016. 60 Copyright Notice 62 Copyright (c) 2015 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 5 80 4. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 6 81 5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 8 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 10.2. Informative References . . . . . . . . . . . . . . . . . 10 89 Appendix A. Rejected Approaches . . . . . . . . . . . . . . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 Ingress Label Switching Routers (LSR) use RSVP-TE [RFC3209] to 95 establish MPLS Label Switched Paths. The following paragraphs 96 describe RSVP-TE procedures. 98 The ingress LSR calculates a path between itself and an egress LSR. 99 The calculated path can be either strictly or loosely routed. Having 100 calculated a path, the ingress LSR constructs an RSVP PATH message. 101 The PATH message includes an Explicit Route Object (ERO) that 102 represents the path between the ingress and egress LSRs. 104 The ingress LSR forwards the PATH message towards the egress LSR, 105 following the path defined by the ERO. Each transit LSR that 106 receives the PATH message executes admission control procedures. If 107 the transit LSR admits the LSP, it sends the PATH message downstream, 108 to the next node in the ERO. 110 When the egress LSR receives the PATH message, it binds a label to 111 the LSP. The label can be implicit null, explicit null, or non-null. 112 The egress LSR then installs forwarding state (if necessary), and 113 constructs an RSVP RESV message. The RESV message contains a Label 114 Object that includes the label that has been bound to the LSP. 116 The egress LSR sends the RESV message upstream towards the ingress 117 LSR. The RESV message visits the same transit LSRs that the PATH 118 message visited, in reverse order. Each transit LSR binds a label to 119 the LSP, updates its forwarding state and updates the RESV message. 120 As a result, the Label Object in the RESV message contains the label 121 that has been bound to the LSP most recently. Finally, the transit 122 LSR sends the RESV message upstream, along the reverse path of the 123 LSP. 125 When the ingress LSR receives the RESV message, it installs 126 forwarding state. Once the ingress LSR installs forwarding state it 127 can forward traffic through the LSP. 129 Referring to any LSR, RFC 3209 says, ""The node SHOULD be prepared to 130 forward packets carrying the assigned label prior to sending the RESV 131 message". However, RFC 3209 does not strictly require this behavior. 133 Some implementations optimize the above-described procedure by 134 allowing LSRs to send RESV messages before installing forwarding 135 state [RFC6383]. This optimization is desirable, because it allows 136 LSRs to install forwarding state in parallel, thus accelerating the 137 process of LSP signaling and setup. However, this optimization 138 creates a race condition. When the ingress LSR receives a RESV 139 message, some downstream LSRs may have not yet installed forwarding 140 state. If the ingress LSR forwards traffic through the LSP before 141 forwarding state has been installed on all downstream nodes, traffic 142 can be lost. 144 This document describes LSP Self-ping. When an ingress LSR receives 145 an RESV message, it can invoke LSP Self-ping procedures to verify 146 that forwarding state has been installed on all downstream nodes. By 147 verifying the installation of downstream forwarding state, the 148 ingress LSR eliminates this particular cause of traffic loss. 150 LSP Self-ping is a new protocol. It is not an extension of LSP Ping 151 [RFC4379]. Although LSP Ping and LSP Self-ping are named similarly, 152 each is designed for a unique purpose. Each protocol listens on its 153 own UDP port and executes its own procedures. 155 LSP Self-ping is an extremely light-weight mechanism. It does not 156 consume control plane resources on transit or egress LSRs. 158 2. Applicability 160 LSP Self-ping is applicable in the following scenario: 162 o The ingress LSR signals a point-to-point LSP 164 o The ingress LSR receives a RESV message 166 o The RESV message indicates that all downstream nodes have begun 167 the process of forwarding state installation 169 o The RESV message does not guarantee that all downstream nodes have 170 completed the process of forwarding state installation 172 o The ingress LSR needs to confirm that all downstream nodes have 173 completed the process for forwarding state installation 175 o The ingress LSR does not need to confirm the correctness of 176 downstream forwarding state, because there is a very high 177 likelihood that downstream forwarding state is correct 179 o Control plane resources on the egress LSR may be scarce 181 o The need to conserve control plane resources on the egress LSR 182 outweighs the need to determine whether downstream forwarding 183 state is correct 185 Unlike LSP Ping and S-BFD [I-D.akiya-bfd-seamless-base], LSP Self- 186 ping is not a general purpose MPLS OAM mechanism. It cannot reliably 187 determine whether downstream forwarding state is correct. For 188 example, if a downstream LSR installs a forwarding state that causes 189 an LSP to terminate at the wrong node, LSP Self-ping will not detect 190 an error. In another example, if a downstream LSR erroneously 191 forwards a packet without an MPLS label, LSP Self-ping will not 192 detect an error. 194 Furthermore, LSP Self-ping fails when either of the following 195 conditions are true: 197 o The LSP under test is signaled by the Label Distribution Protocol 198 (LDP) Independent Mode [RFC5036] 200 o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on 201 links that connect the ingress LSR to the egress LSR 203 While LSP Ping and S-BFD are general purpose OAM mechanisms, they are 204 not applicable in the above described scenario because: 206 o LSP Ping consumes control plane resources on the egress LSR 208 o An S-BFD implementation either consumes control plane resources on 209 the egress LSR or requires special support for S-BFD on the 210 forwarding plane. 212 By contrast, LSP Self-ping requires nothing from the egress LSR 213 beyond the ability to forward an IP datagram. 215 LSP Self-ping's purpose is to determine whether forwarding state has 216 been installed on all downstream LSRs. Its primary constraint is to 217 minimize its impact on egress LSR performance. This functionality is 218 valuable during network convergence events that impact a large number 219 of LSPs. 221 Therefore, LSP Self-ping is applicable in the scenario described 222 above, where the LSP is signaled by RSVP, RPF is not enabled, and the 223 need to conserve control plane resources on the egress LSR outweighs 224 the need to determine whether downstream forwarding state is correct. 226 3. The LSP Self-ping Message 228 The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC0768] 229 packet that encapsulates a session ID. If the RSVP messages used to 230 establish the LSP under test were delivered over IPv4 [RFC0791], the 231 UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP 232 messages used to establish the LSP were delivered over IPv6 233 [RFC2460], the UDP datagram MUST be encapsulated in an IPv6 header. 235 In either case: 237 o The IP Source Address MAY be configurable. By default, it MUST be 238 the address of the egress LSR 240 o The IP Destination Address MUST be the address of the ingress LSR 242 o The IP Time to Live (TTL) / Hop Count MAY be configurable. By 243 default, it MUST be 255 245 o The IP DSCP MAY be configurable. By default, it MUST be CS6 246 (Ox48) [RFC4594] 248 o The UDP Source Port MUST be selected from the dynamic range 249 (49152-65535) [RFC6335] 251 o The UDP Destination Port MUST be lsp-self-ping (8503) [IANA.PORTS] 253 UDP packet contents have the following format: 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 | Session-ID | 259 | (64 bits) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 LSP Self-ping Message 264 The Session-ID is a 64-bit field that associates an LSP Self-ping 265 message with an LSP Self-ping session. 267 4. LSP Self Ping Procedures 269 In order to verify that an LSP is ready to carry traffic, the ingress 270 LSR creates a short-lived LSP Self-ping session. All session state 271 is maintained locally on the ingress LSR. Session state includes the 272 following information: 274 o Session-ID: A 64-bit number that identifies the LSP Self-ping 275 session 277 o Retry Counter: The maximum number of times that the ingress LSR 278 probes the LSP before terminating the LSP Self-ping session. The 279 initial value of this variable is determined by configuration. 281 o Retry Timer: The number of milliseconds that the LSR waits after 282 probing the LSP. The initial value of this variable is determined 283 by configuration. 285 o Status: A boolean variable indicating the completion status of the 286 LSP Self-ping session. The initial value of this variable is 287 FALSE. 289 Implementations MAY represent the above mentioned information in any 290 format that is convenient to them. 292 The ingress LSR executes the following procedure until Status equals 293 TRUE or Retry Counter equals zero: 295 o Format a LSP Self-ping message. 297 o Set the Session-ID in the LSP Self-ping message to the Session-ID 298 mentioned above 300 o Send the LSP Self-ping message through the LSP under test 302 o Set a timer to expire in Retry Timer milliseconds 304 o Wait until either an LSP Self-ping message associated with the 305 session returns or the timer expires. If an LSP Self-ping message 306 associated with the session returns, set Status to TRUE. 307 Otherwise, decrement the Retry Counter. Optionally, increase the 308 value of Retry Timer according to an appropriate back off 309 algorithm. 311 In the process described above, the ingress LSR addresses an LSP 312 Self-ping message to itself and forwards that message through the LSP 313 under test. If forwarding state has been installed on all downstream 314 LSRs, the egress LSR receives the LSP Self-ping message and 315 determines that it is addressed to the ingress LSR. So, the egress 316 LSR forwards LSP Self-ping message back to the ingress LSR, exactly 317 as it would forward any other IP packet. 319 The LSP Self-ping message can arrive at the egress LSR with or 320 without an MPLS header, depending on whether the LSP under test 321 executes penultimate hop-popping procedures. If the LSP Self-ping 322 message arrives at the egress LSR with an MPLS header, the egress LSR 323 removes that header. 325 If the egress LSR's most preferred route to the ingress LSR is 326 through an LSP, the egress LSR forwards the LSP Self-ping message 327 through that LSP. However, if the egress LSR's most preferred route 328 to the ingress LSR is not through an LSP, the egress LSR forwards the 329 LSP Self-ping message without MPLS encapsulation. 331 When an LSP Self-ping session terminates, it returns its completion 332 status to the invoking protocol. For example, if RSVP-TE invokes LSP 333 Self-ping as part of the LSP set-up procedure, LSP Self-ping returns 334 its completion status to RSVP-TE. 336 5. Bidirectional LSP Procedures 338 A bidirectional LSP has an active side and a passive side. The 339 active side calculates the ERO and signals the LSP in the forward 340 direction. The passive side reverses the ERO and signals the LSP in 341 the reverse direction. 343 When LSP Self-ping is applied to a bidirectional LSP: 345 o The active side calculates ERO, signals LSP and runs LSP Self-ping 347 o The Passive side reverses ERO, signals LSP and runs another 348 instance of LSP Self-ping 350 o Neither side forwards traffic through the LSP until local LSP 351 Self-ping returns TRUE 353 The two LSP Self-ping sessions, mentioned above, are independent of 354 one another. They are not required to have the same Session-ID. 355 Each endpoint can forward traffic through the LSP as soon as the its 356 local LSP Self-ping returns TRUE. Endpoints are not required to wait 357 until both LSP Self-ping sessions have returned TRUE. 359 6. IANA Considerations 361 IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by LSP 362 Self-ping. 364 7. Security Considerations 366 LSP Self-ping messages are easily forged. Therefore, an attacker can 367 send the ingress LSR a forged LSP Self-ping message, causing the 368 ingress LSR to terminate the LSP Self-ping session prematurely. In 369 order to mitigate these threats, operators SHOULD filter LSP Self- 370 ping packets at the edges of the MPLS signaling domain. Furthermore, 371 implementations SHOULD NOT assign Session-ID's in a predictable 372 manner. In order to avoid predictablity, imlementations can leverage 373 a Cryptographically Secure Pseudo-randomn Number Generator (CSPRNG) 374 [NIST-CSPRNG] 376 8. Contributors 378 The following individuals contributed significantly to this document: 380 Mark Wygant 381 Verizon 383 mark.wygant@verizon.com 385 Ravi Torvi 387 Juniper Networks 389 rtorvi@juniper.net 391 9. Acknowledgements 393 Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg 394 Mirsky and Nobo Akiya for their contributions to this document. 396 10. References 398 10.1. Normative References 400 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 401 DOI 10.17487/RFC0768, August 1980, 402 . 404 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 405 DOI 10.17487/RFC0791, September 1981, 406 . 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 414 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 415 December 1998, . 417 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 418 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 419 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 420 . 422 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 423 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 424 2004, . 426 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 427 Label Switched (MPLS) Data Plane Failures", RFC 4379, 428 DOI 10.17487/RFC4379, February 2006, 429 . 431 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 432 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 433 October 2007, . 435 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 436 Cheshire, "Internet Assigned Numbers Authority (IANA) 437 Procedures for the Management of the Service Name and 438 Transport Protocol Port Number Registry", BCP 165, 439 RFC 6335, DOI 10.17487/RFC6335, August 2011, 440 . 442 10.2. Informative References 444 [I-D.akiya-bfd-seamless-base] 445 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 446 Networks, "Seamless Bidirectional Forwarding Detection 447 (S-BFD)", draft-akiya-bfd-seamless-base-03 (work in 448 progress), April 2014. 450 [IANA.PORTS] 451 IANA, "Service Name and Transport Protocol Port Number 452 Registry", . 456 [NIST-CSPRNG] 457 "NIST Special Publication 800-90A, Recommendation for 458 Random Number Generation Using Deterministic Random Bit 459 Generators", January 2012. 461 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 462 Guidelines for DiffServ Service Classes", RFC 4594, 463 DOI 10.17487/RFC4594, August 2006, 464 . 466 [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to 467 Start Sending Data on Label Switched Paths Established 468 Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September 469 2011, . 471 Appendix A. Rejected Approaches 473 In a rejected approach, the ingress LSR uses LSP-Ping to verify LSP 474 readiness. This approach was rejected for the following reasons. 476 While an ingress LSR can control its control plane overhead due to 477 LSP Ping, an egress LSR has no such control. This is because each 478 ingress LSR can, on its own, control the rate of the LSP Ping 479 originated by the LSR, while an egress LSR must respond to all the 480 LSP Pings originated by various ingresses. Furthermore, when an MPLS 481 Echo Request reaches an egress LSR it is sent to the control plane of 482 the egress LSR, which makes egress LSR processing overhead of LSP 483 Ping well above the overhead of its data plane (MPLS/IP forwarding). 484 These factors make LSP Ping problematic as a tool for detecting LSP 485 readiness to carry traffic when dealing with a large number of LSPs. 487 By contrast, LSP Self-ping does not consume any control plane 488 resources at the egress LSR, and relies solely on the data plane of 489 the egress LSR, making it more suitable as a tool for checking LSP 490 readiness when dealing with a large number of LSPs. 492 In another rejected approach, the ingress LSR does not verify LSP 493 readiness. Instead, it sets a timer when it receives an RSVP RESV 494 message and does not forward traffic through the LSP until the timer 495 expires. This approach was rejected because it is impossible to 496 determine the optimal setting for this timer. If the timer value is 497 set too low, it does not prevent black-holing. If the timer value is 498 set too high, it slows down the process of LSP signalling and setup. 500 Moreover, the above-mentioned timer is configured on a per-router 501 basis. However, its optimum value is determined by a network-wide 502 behavior. Therefore, changes in the network could require changes to 503 the value of the timer, making the optimal setting of this timer a 504 moving target. 506 Authors' Addresses 508 Ron Bonica 509 Juniper Networks 511 Email: rbonica@juniper.net 512 Ina Minei 513 Google, Inc. 514 1600 Amphitheatre Parkway 515 Mountain View, CA 94043 516 U.S.A. 518 Email: inaminei@google.com 520 Michael Conn 521 Verizon 523 Email: michael.e.conn@verizon.com 525 Dante Pacella 526 Verizon 528 Email: dante.j.pacella@verizon.com 530 Luis Tomotaki 531 Verizon 533 Email: luis.tomotaki@verizon.com