idnits 2.17.1 draft-ietf-mpls-self-ping-00.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 3246 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-00 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. This optimization is desirable, because it allows LSRs to 129 install forwarding state in parallel, thus accelerating the process 130 of LSP signaling and setup. However, this optimization creates a 131 race condition. When the ingress LSR receives a RESV message, some 132 downstream LSRs may not have installed forwarding state yet. If the 133 ingress LSR forwards traffic through the LSP before forwarding state 134 has been installed on all downstream nodes, traffic 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. Each protocol listens on its own UDP port and 147 executes is own unique procedures. 149 2. Applicability 151 LSP Self-ping is applicable in the following scenario: 153 o The ingress LSR receives a RESV message 155 o The RESV message indicates that all downstream nodes have begun 156 the process of forwarding state installation 158 o The RESV message does not guarantee that all downstream nodes have 159 completed the process of forwarding state installation 161 o The ingress LSR needs to confirm that all downstream nodes have 162 completed the process for forwarding state installation 164 o The ingress LSR does not need to confirm the correctness of 165 downstream forwarding state, because there is a very high 166 likelihood that downstream forwarding state is correct 168 o Control plane resources on the egress LSR may be scarce 170 o The need to conserve control plane resources on the egress LSR 171 outweighs the need to determine whether downstream forwarding 172 state is correct 174 Unlike LSP Ping [RFC4379] and S-BFD [I-D.akiya-bfd-seamless-base], 175 LSP Self-ping is not a general purpose MPLS OAM mechanism. It cannot 176 reliably determine whether downstream forwarding state is correct. 177 For example, if a downstream LSR installs a forwarding state that 178 causes an LSP to terminate at the wrong node, LSP Self-ping will not 179 detect an error. Furthermore, LSP Self-ping fails when either of the 180 following conditions are true: 182 o The LSP under test is signaled by the Label Distribution Protocol 183 (LDP) Independent Mode [RFC5036] 185 o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on 186 links that connect the ingress LSR to the egress LSR 188 While LSP Ping and S-BFD are general purpose OAM mechanisms, they are 189 not applicable in the above described scenario because: 191 o LSP Ping consumes control plane resources on the egress LSR 192 o An S-BFD implementation either consumes control plane resources on 193 the egress LSR or requires special support for S-BFD on the 194 forwarding plane. 196 By contrast, LSP Self-ping requires nothing from the egress LSR 197 beyond the ability to forward an IP datagram. 199 LSP Self-ping's purpose is to determine whether forwarding state has 200 been installed on all downstream LSRs. Its primary constraint is to 201 minimize its impact on egress LSR performance. This functionality is 202 required during network convergence events that impact a large number 203 of LSPs. 205 Therefore, LSP Self-ping is applicable in the scenario described 206 above, where the LSP is signaled by RSVP, RPF is not enabled, and the 207 need to conserve control plane resources on the egress LSR outweighs 208 the need to determine whether downstream forwarding state is correct. 210 3. The LSP Self-ping Message 212 The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC0768] 213 packet. If the RSVP messages used to establish the LSP under test 214 were delivered over IPv4 [RFC0791], the UDP datagram MUST be 215 encapsulated in an IPv4 header. If the RSVP messages used to 216 establish the LSP were delivered over IPv6 [RFC2460], the UDP 217 datagram MUST be encapsulated in an IPv6 header. 219 In either case: 221 o The IP Source Address MAY be configurable. By default, it MUST be 222 the address of the egress LSR 224 o The IP Destination Address MUST be the address of the ingress LSR 226 o The IP Time to Live (TTL) / Hop Count MAY be configurable. By 227 default, it MUST be 255 229 o The IP DSCP MAY be configurable. By default, it MUST be CS6 230 (Ox48) [RFC4594] 232 o The UDP Source Port MUST be selected from the dynamic range 233 (49152-65535) [RFC6335] 235 o The UDP Destination Port MUST be LSP Self-ping. (Value to be 236 assigned by IANA. See Section 7) 238 UDP packet contents have the following format: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Session-ID | 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 LSP Self-ping Message 249 The Session-ID is a 64-bit field that associates an LSP Self-ping 250 message with an LSP Self-ping session. 252 4. LSP Self Ping Procedures 254 In order to verify that an LSP is ready to carry traffic, the ingress 255 LSR creates a short-lived LSP Self-ping session. All session state 256 is maintained locally on the ingress LSR. Session state includes the 257 following information: 259 o Session-ID: A 64-bit number that identifies the LSP Self-ping 260 session 262 o Retry Counter: The maximum number of times that the ingress LSR 263 probes the LSP before terminating the LSP Self-ping session. The 264 initial value of this variable is determined by configuration. 266 o Retry Timer: The number of milliseconds that the LSR waits after 267 probing the LSP. The initial value of this variable is determined 268 by configuration. 270 o Status: A boolean variable indicating the completion status of the 271 LSP Self-ping session. The initial value of this variable is 272 FALSE. 274 Implementation MAY represent the above mentioned information in any 275 format that is convenient to them. 277 The ingress LSR executes the following procedure until Status equals 278 TRUE or Retry Counter equals zero: 280 o Format a LSP Self-ping message. 282 o Set the Session-ID in the LSP Self-ping message to the Session-ID 283 mentioned above 285 o Send the LSP Self-ping message through the LSP under test 286 o Set a timer to expire in Retry Timer milliseconds 288 o Wait until either an LSP Self-ping message associated with the 289 session returns or the timer expires. If an LSP Self-ping message 290 associated with the session returns, set Status to TRUE. 291 Otherwise, decrement the Retry Counter. Optionally, increase the 292 value of Retry Timer according to an appropriate back off 293 algorithm. 295 In the process described above, the ingress LSR addresses an LSP 296 Self-ping message to itself and forwards that message through the LSP 297 under test. If forwarding state has been installed on all downstream 298 LSRs, the egress LSR receives the LSP Self-ping message and 299 determines that it is addressed to the ingress LSR. So, the egress 300 LSR forwards LSP Self-ping message back to the ingress LSR, exactly 301 as it would forward any other IP packet. 303 The LSP Self-ping message can arrive at the egress LSR with or 304 without an MPLS header, depending on whether the LSP under test 305 executes penultimate hop-popping procedures. If the LSP Self-ping 306 message arrives at the egress LSR with an MPLS header, the egress LSR 307 removes that header. 309 If the egress LSR's most preferred route to the ingress LSR is 310 through an LSP, the egress LSR forwards the LSP Self-ping message 311 through that LSP. However, if the egress LSR's most preferred route 312 to the ingress LSR is not through an LSP, the egress LSR forwards the 313 LSP Self-ping message without MPLS encapsulation. 315 When an LSP Self-ping session terminates, it returns its completion 316 status to the invoking protocol. For example, if RSVP-TE invokes LSP 317 Self-ping as part of the LSP set-up procedure, LSP Self-ping returns 318 its completion status to RSVP-TE. 320 5. Bidirectional LSP Procedures 322 A bidirectional LSP has an active side and a passive side. The 323 active side calculates the ERO and signals the LSP in the forward 324 direction. The passive side reverses the ERO and signals the LSP in 325 the reverse direction. 327 When LSP Self-ping is applied to a bidirectional LSP: 329 o The active side calculates ERO, signals LSP and runs LSP Self-ping 331 o The Passive side reverses ERO, signals LSP and runs another 332 instance of LSP Self-ping 334 o Neither side forwards traffic through the LSP until local LSP 335 Self-ping returns TRUE 337 The two LSP Self-ping sessions, mentioned above, are independent of 338 one another. They are not required to have the same Session-ID. 339 Each endpoint can forward traffic through the LSP as soon as the its 340 local LSP Self-ping returns TRUE. Endpoints are not required to wait 341 until both LSP Self-ping sessions have returned TRUE. 343 6. Rejected Approaches 345 In a rejected approach, the ingress LSR uses LSP-Ping to verify LSP 346 readiness. This approach was rejected for the following reasons. 348 While an ingress LSR can control its control plane overhead due to 349 LSP Ping, an egress LSR has no such control. This is because each 350 ingress LSR can, on its own, control the rate of the LSP Ping 351 originated by the LSR, while an egress LSR must respond to all the 352 LSP Pings originated by various ingresses. Furthermore, when an MPLS 353 Echo Request reaches an egress LSR it is sent to the control plane of 354 the egress LSR, which makes egress LSR processing overhead of LSP 355 Ping well above the overhead of its data plane (MPLS/IP forwarding). 356 These factors make LSP Ping problematic as a tool for detecting LSP 357 readiness to carry traffic when dealing with a large number of LSPs. 359 By contrast, LSP Self-ping does not consume any control plane 360 resources at the egress LSR, and relies solely on the data plane of 361 the egress LSR, making it more suitable as a tool for checking LSP 362 readiness when dealing with a large number of LSPs. 364 In another rejected approach, the ingress LSR does not verify LSP 365 readiness. Alternatively, it sets a timer when it receives an RSVP 366 RESV message and does not forward traffic through the LSP until the 367 timer expires. This approach was rejected because it is impossible 368 to determine the optimal setting for this timer. If the timer value 369 is set too low, it does not prevent black-holing. If the timer value 370 is set too high, it slows down the process of LSP signalling and 371 setup. 373 Moreover, the above-mentioned timer is configured on a per-router 374 basis. However, its optimum value is determined by a network-wide 375 behavior. Therefore, changes in the network could require changes to 376 the value of the timer, making the optimal setting of this timer a 377 moving target. 379 7. IANA Considerations 381 This memo request that IANA assign a UDP port from the user range 382 (1024-49151) for LSP Self-ping. 384 8. Security Considerations 386 LSP Self-ping messages are easily forged. Therefore, an attacker can 387 send the ingress LSR a forged LSP Self-ping message, causing the 388 ingress LSR to terminate the LSP Self-ping session prematurely. In 389 order to mitigate these threats, implementations SHOULD NOT assign 390 Session-ID's in a predictable manner. Furthermore, operators SHOULD 391 filter LSP Self-ping packets at network ingress points. 393 9. Acknowledgements 395 Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg 396 Mirsky and Nobo Akiya for their contributions to this document. 398 10. References 400 10.1. Normative References 402 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 403 August 1980. 405 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 406 1981. 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, March 1997. 411 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 412 (IPv6) Specification", RFC 2460, December 1998. 414 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 415 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 416 Tunnels", RFC 3209, December 2001. 418 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 419 Networks", BCP 84, RFC 3704, March 2004. 421 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 422 Label Switched (MPLS) Data Plane Failures", RFC 4379, 423 February 2006. 425 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 426 Specification", RFC 5036, October 2007. 428 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 429 Cheshire, "Internet Assigned Numbers Authority (IANA) 430 Procedures for the Management of the Service Name and 431 Transport Protocol Port Number Registry", BCP 165, RFC 432 6335, August 2011. 434 10.2. Informative References 436 [I-D.akiya-bfd-seamless-base] 437 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 438 Networks, "Seamless Bidirectional Forwarding Detection 439 (S-BFD)", draft-akiya-bfd-seamless-base-03 (work in 440 progress), April 2014. 442 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 443 Guidelines for DiffServ Service Classes", RFC 4594, August 444 2006. 446 Authors' Addresses 448 Ravi Torvi 449 Juniper Networks 451 Email: rtorvi@juniper.net 453 Ron Bonica 454 Juniper Networks 456 Email: rbonica@juniper.net 458 Ina Minei 459 Google, Inc. 460 1600 Amphitheatre Parkway 461 Mountain View, CA 94043 462 U.S.A. 464 Email: inaminei@google.com 466 Michael Conn 467 Verizon 469 Email: michael.e.conn@verizon.com 470 Dante Pacella 471 Verizon 473 Email: dante.j.pacella@verizon.com 475 Luis Tomotaki 476 Verizon 478 Email: luis.tomotaki@verizon.com 480 Mark Wygant 481 Verizon 483 Email: mark.wygant@verizon.com