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