idnits 2.17.1 draft-ietf-mpls-self-ping-05.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 (October 2, 2015) is 3128 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: April 4, 2016 Google, Inc. 6 M. Conn 7 D. Pacella 8 L. Tomotaki 9 Verizon 10 October 2, 2015 12 LSP Self-Ping 13 draft-ietf-mpls-self-ping-05 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 April 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 . . . . . . . . . . . . . . . . 10 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, implementations SHOULD NOT assign 370 Session-ID's in a predictable manner. Furthermore, operators SHOULD 371 filter LSP Self-ping packets at network ingress points. 373 8. Contributors 375 The following individuals contributed significantly to this document: 377 Mark Wygant 379 Verizon 380 mark.wygant@verizon.com 382 Ravi Torvi 384 Juniper Networks 386 rtorvi@juniper.net 388 9. Acknowledgements 390 Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg 391 Mirsky and Nobo Akiya for their contributions to this document. 393 10. References 395 10.1. Normative References 397 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 398 DOI 10.17487/RFC0768, August 1980, 399 . 401 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 402 DOI 10.17487/RFC0791, September 1981, 403 . 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, 407 DOI 10.17487/RFC2119, March 1997, 408 . 410 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 411 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 412 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, DOI 10.17487/RFC3209, December 2001, 417 . 419 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 420 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 421 2004, . 423 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 424 Label Switched (MPLS) Data Plane Failures", RFC 4379, 425 DOI 10.17487/RFC4379, February 2006, 426 . 428 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 429 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 430 October 2007, . 432 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 433 Cheshire, "Internet Assigned Numbers Authority (IANA) 434 Procedures for the Management of the Service Name and 435 Transport Protocol Port Number Registry", BCP 165, 436 RFC 6335, DOI 10.17487/RFC6335, August 2011, 437 . 439 10.2. Informative References 441 [I-D.akiya-bfd-seamless-base] 442 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 443 Networks, "Seamless Bidirectional Forwarding Detection 444 (S-BFD)", draft-akiya-bfd-seamless-base-03 (work in 445 progress), April 2014. 447 [IANA.PORTS] 448 IANA, "Service Name and Transport Protocol Port Number 449 Registry", . 453 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 454 Guidelines for DiffServ Service Classes", RFC 4594, 455 DOI 10.17487/RFC4594, August 2006, 456 . 458 [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to 459 Start Sending Data on Label Switched Paths Established 460 Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September 461 2011, . 463 Appendix A. Rejected Approaches 465 In a rejected approach, the ingress LSR uses LSP-Ping to verify LSP 466 readiness. This approach was rejected for the following reasons. 468 While an ingress LSR can control its control plane overhead due to 469 LSP Ping, an egress LSR has no such control. This is because each 470 ingress LSR can, on its own, control the rate of the LSP Ping 471 originated by the LSR, while an egress LSR must respond to all the 472 LSP Pings originated by various ingresses. Furthermore, when an MPLS 473 Echo Request reaches an egress LSR it is sent to the control plane of 474 the egress LSR, which makes egress LSR processing overhead of LSP 475 Ping well above the overhead of its data plane (MPLS/IP forwarding). 476 These factors make LSP Ping problematic as a tool for detecting LSP 477 readiness to carry traffic when dealing with a large number of LSPs. 479 By contrast, LSP Self-ping does not consume any control plane 480 resources at the egress LSR, and relies solely on the data plane of 481 the egress LSR, making it more suitable as a tool for checking LSP 482 readiness when dealing with a large number of LSPs. 484 In another rejected approach, the ingress LSR does not verify LSP 485 readiness. Instead, it sets a timer when it receives an RSVP RESV 486 message and does not forward traffic through the LSP until the timer 487 expires. This approach was rejected because it is impossible to 488 determine the optimal setting for this timer. If the timer value is 489 set too low, it does not prevent black-holing. If the timer value is 490 set too high, it slows down the process of LSP signalling and setup. 492 Moreover, the above-mentioned timer is configured on a per-router 493 basis. However, its optimum value is determined by a network-wide 494 behavior. Therefore, changes in the network could require changes to 495 the value of the timer, making the optimal setting of this timer a 496 moving target. 498 Authors' Addresses 500 Ron Bonica 501 Juniper Networks 503 Email: rbonica@juniper.net 505 Ina Minei 506 Google, Inc. 507 1600 Amphitheatre Parkway 508 Mountain View, CA 94043 509 U.S.A. 511 Email: inaminei@google.com 513 Michael Conn 514 Verizon 516 Email: michael.e.conn@verizon.com 517 Dante Pacella 518 Verizon 520 Email: dante.j.pacella@verizon.com 522 Luis Tomotaki 523 Verizon 525 Email: luis.tomotaki@verizon.com