idnits 2.17.1 draft-ietf-mpls-self-ping-03.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 5, 2015) is 3149 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: March 8, 2016 I. Minei 6 Google, Inc. 7 M. Conn 8 D. Pacella 9 L. Tomotaki 10 M. Wygant 11 Verizon 12 September 5, 2015 14 LSP Self-Ping 15 draft-ietf-mpls-self-ping-03 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 March 8, 2016. 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 a 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 have not yet installed forwarding 133 state. 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, designed for a unique purpose. Each protocol 148 listens on its own UDP port and executes its 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 valuable 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 that encapsulates a session ID. If the RSVP messages used to 222 establish the LSP under test were delivered over IPv4 [RFC0791], the 223 UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP 224 messages used to establish the LSP were delivered over IPv6 225 [RFC2460], the UDP 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 (8503) [IANA.PORTS] 245 UDP packet contents have the following format: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Session-ID | 251 | (64 bits) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 LSP Self-ping Message 256 The Session-ID is a 64-bit field that associates an LSP Self-ping 257 message with an LSP Self-ping session. 259 4. LSP Self Ping Procedures 261 In order to verify that an LSP is ready to carry traffic, the ingress 262 LSR creates a short-lived LSP Self-ping session. All session state 263 is maintained locally on the ingress LSR. Session state includes the 264 following information: 266 o Session-ID: A 64-bit number that identifies the LSP Self-ping 267 session 269 o Retry Counter: The maximum number of times that the ingress LSR 270 probes the LSP before terminating the LSP Self-ping session. The 271 initial value of this variable is determined by configuration. 273 o Retry Timer: The number of milliseconds that the LSR waits after 274 probing the LSP. The initial value of this variable is determined 275 by configuration. 277 o Status: A boolean variable indicating the completion status of the 278 LSP Self-ping session. The initial value of this variable is 279 FALSE. 281 Implementations MAY represent the above mentioned information in any 282 format that is convenient to them. 284 The ingress LSR executes the following procedure until Status equals 285 TRUE or Retry Counter equals zero: 287 o Format a LSP Self-ping message. 289 o Set the Session-ID in the LSP Self-ping message to the Session-ID 290 mentioned above 292 o Send the LSP Self-ping message through the LSP under test 294 o Set a timer to expire in Retry Timer milliseconds 296 o Wait until either an LSP Self-ping message associated with the 297 session returns or the timer expires. If an LSP Self-ping message 298 associated with the session returns, set Status to TRUE. 299 Otherwise, decrement the Retry Counter. Optionally, increase the 300 value of Retry Timer according to an appropriate back off 301 algorithm. 303 In the process described above, the ingress LSR addresses an LSP 304 Self-ping message to itself and forwards that message through the LSP 305 under test. If forwarding state has been installed on all downstream 306 LSRs, the egress LSR receives the LSP Self-ping message and 307 determines that it is addressed to the ingress LSR. So, the egress 308 LSR forwards LSP Self-ping message back to the ingress LSR, exactly 309 as it would forward any other IP packet. 311 The LSP Self-ping message can arrive at the egress LSR with or 312 without an MPLS header, depending on whether the LSP under test 313 executes penultimate hop-popping procedures. If the LSP Self-ping 314 message arrives at the egress LSR with an MPLS header, the egress LSR 315 removes that header. 317 If the egress LSR's most preferred route to the ingress LSR is 318 through an LSP, the egress LSR forwards the LSP Self-ping message 319 through that LSP. However, if the egress LSR's most preferred route 320 to the ingress LSR is not through an LSP, the egress LSR forwards the 321 LSP Self-ping message without MPLS encapsulation. 323 When an LSP Self-ping session terminates, it returns its completion 324 status to the invoking protocol. For example, if RSVP-TE invokes LSP 325 Self-ping as part of the LSP set-up procedure, LSP Self-ping returns 326 its completion status to RSVP-TE. 328 5. Bidirectional LSP Procedures 330 A bidirectional LSP has an active side and a passive side. The 331 active side calculates the ERO and signals the LSP in the forward 332 direction. The passive side reverses the ERO and signals the LSP in 333 the reverse direction. 335 When LSP Self-ping is applied to a bidirectional LSP: 337 o The active side calculates ERO, signals LSP and runs LSP Self-ping 339 o The Passive side reverses ERO, signals LSP and runs another 340 instance of LSP Self-ping 342 o Neither side forwards traffic through the LSP until local LSP 343 Self-ping returns TRUE 345 The two LSP Self-ping sessions, mentioned above, are independent of 346 one another. They are not required to have the same Session-ID. 347 Each endpoint can forward traffic through the LSP as soon as the its 348 local LSP Self-ping returns TRUE. Endpoints are not required to wait 349 until both LSP Self-ping sessions have returned TRUE. 351 6. Rejected Approaches 353 In a rejected approach, the ingress LSR uses LSP-Ping to verify LSP 354 readiness. This approach was rejected for the following reasons. 356 While an ingress LSR can control its control plane overhead due to 357 LSP Ping, an egress LSR has no such control. This is because each 358 ingress LSR can, on its own, control the rate of the LSP Ping 359 originated by the LSR, while an egress LSR must respond to all the 360 LSP Pings originated by various ingresses. Furthermore, when an MPLS 361 Echo Request reaches an egress LSR it is sent to the control plane of 362 the egress LSR, which makes egress LSR processing overhead of LSP 363 Ping well above the overhead of its data plane (MPLS/IP forwarding). 364 These factors make LSP Ping problematic as a tool for detecting LSP 365 readiness to carry traffic when dealing with a large number of LSPs. 367 By contrast, LSP Self-ping does not consume any control plane 368 resources at the egress LSR, and relies solely on the data plane of 369 the egress LSR, making it more suitable as a tool for checking LSP 370 readiness when dealing with a large number of LSPs. 372 In another rejected approach, the ingress LSR does not verify LSP 373 readiness. Instead, it sets a timer when it receives an RSVP RESV 374 message and does not forward traffic through the LSP until the timer 375 expires. This approach was rejected because it is impossible to 376 determine the optimal setting for this timer. If the timer value is 377 set too low, it does not prevent black-holing. If the timer value is 378 set too high, it slows down the process of LSP signalling and setup. 380 Moreover, the above-mentioned timer is configured on a per-router 381 basis. However, its optimum value is determined by a network-wide 382 behavior. Therefore, changes in the network could require changes to 383 the value of the timer, making the optimal setting of this timer a 384 moving target. 386 7. IANA Considerations 388 IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by LSP 389 Self-ping. 391 8. Security Considerations 393 LSP Self-ping messages are easily forged. Therefore, an attacker can 394 send the ingress LSR a forged LSP Self-ping message, causing the 395 ingress LSR to terminate the LSP Self-ping session prematurely. In 396 order to mitigate these threats, implementations SHOULD NOT assign 397 Session-ID's in a predictable manner. Furthermore, operators SHOULD 398 filter LSP Self-ping packets at network ingress points. 400 9. Acknowledgements 402 Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg 403 Mirsky and Nobo Akiya for their contributions to this document. 405 10. References 407 10.1. Normative References 409 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 410 DOI 10.17487/RFC0768, August 1980, 411 . 413 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 414 DOI 10.17487/RFC0791, September 1981, 415 . 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 423 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 424 December 1998, . 426 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 427 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 428 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 429 . 431 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 432 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 433 2004, . 435 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 436 Label Switched (MPLS) Data Plane Failures", RFC 4379, 437 DOI 10.17487/RFC4379, February 2006, 438 . 440 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 441 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 442 October 2007, . 444 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 445 Cheshire, "Internet Assigned Numbers Authority (IANA) 446 Procedures for the Management of the Service Name and 447 Transport Protocol Port Number Registry", BCP 165, 448 RFC 6335, DOI 10.17487/RFC6335, August 2011, 449 . 451 10.2. Informative References 453 [I-D.akiya-bfd-seamless-base] 454 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 455 Networks, "Seamless Bidirectional Forwarding Detection 456 (S-BFD)", draft-akiya-bfd-seamless-base-03 (work in 457 progress), April 2014. 459 [IANA.PORTS] 460 IANA, "Service Name and Transport Protocol Port Number 461 Registry", . 465 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 466 Guidelines for DiffServ Service Classes", RFC 4594, 467 DOI 10.17487/RFC4594, August 2006, 468 . 470 [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to 471 Start Sending Data on Label Switched Paths Established 472 Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September 473 2011, . 475 Authors' Addresses 477 Ravi Torvi 478 Juniper Networks 480 Email: rtorvi@juniper.net 481 Ron Bonica 482 Juniper Networks 484 Email: rbonica@juniper.net 486 Ina Minei 487 Google, Inc. 488 1600 Amphitheatre Parkway 489 Mountain View, CA 94043 490 U.S.A. 492 Email: inaminei@google.com 494 Michael Conn 495 Verizon 497 Email: michael.e.conn@verizon.com 499 Dante Pacella 500 Verizon 502 Email: dante.j.pacella@verizon.com 504 Luis Tomotaki 505 Verizon 507 Email: luis.tomotaki@verizon.com 509 Mark Wygant 510 Verizon 512 Email: mark.wygant@verizon.com