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