idnits 2.17.1 draft-bonica-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 (February 13, 2015) is 3359 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5036' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: Informational Juniper Networks 5 Expires: August 17, 2015 I. Minei 6 Google, Inc. 7 M. Conn 8 D. Pacella 9 L. Tomotaki 10 M. Wygant 11 Verizon 12 February 13, 2015 14 LSP Self-Ping 15 draft-bonica-mpls-self-ping-04 17 Abstract 19 LSP Self-ping is a new, light-weight protocol that ingress LSRs can 20 use to verify an LSPs readiness to carry traffic. LSP Self-ping does 21 not consume control plane resources on the egress LSR. 23 When an ingress LSR executes LSP Self-ping procedures, it constructs 24 a probe message. The probe message is an IP datagram whose 25 destination address represents an interface on the ingress LSR. 27 The ingress LSR forwards the probe through the LSP under test. If 28 the LSP is ready to forward traffic, the egress LSR receives the 29 probe. Because the probe is addressed to the ingress LSR, the egress 30 LSR forwards the probe back to the ingress. When the ingress LSR 31 receives the probe, it has verified LSP readiness without consuming 32 control plane resources at the egress LSR. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 17, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 4 69 3. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 6 70 4. Rejected Approaches . . . . . . . . . . . . . . . . . . . . . 7 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 Ingress Label Switching Routers (LSR) can use RSVP-TE [RFC3209] to 80 establish a MPLS Label Switched Paths (LSP) [RFC3032]. The following 81 paragraphs outline RSVP-TE procedures. 83 The ingress LSR calculates path between itself and an egress LSR. 84 The calculated path can be either strictly or loosely routed. Having 85 calculated a path, the ingress LSR constructs an RSVP PATH message. 86 The PATH message includes an Explicit Route Object (ERO) and the ERO 87 represents the calculated path between the ingress and egress LSRs. 89 The ingress LSR forwards the PATH message towards the egress LSR, 90 following the path defined by the ERO. Each transit LSR that 91 receives the PATH message executes admission control procedures. If 92 the transit LSR admits the LSP, it sends the PATH message downstream, 93 to the next node in the ERO. 95 When the egress LSR receives the PATH message, it binds a label to 96 the LSP. The label can be implicit null, explicit null, or non-null. 97 The egress LSR then installs forwarding state (if necessary), and 98 constructs an RSVP RESV message. The RESV message contains a Label 99 Object and the Label Object contains the label that has been bound to 100 the LSP. 102 The egress LSR sends the RESV message upstream towards the ingress 103 LSR. The RESV message visits the same transit LSRs that the PATH 104 message visited, in reverse order. Each transit LSR binds a label to 105 the LSP, updates its forwarding state and updates the RESV message. 106 As a result, the RESV message contains a Label Object and the Label 107 Object contains the label that has been bound to the LSP. Finally, 108 the transit LSR sends the RESV message upstream, along the reverse 109 path of the LSP. 111 When the ingress LSR receives the RESV message, it installs 112 forwarding state. Once the ingress LSR installs forwarding state it 113 can forward traffic through the LSP. 115 Some implementations optimize the procedure described above by 116 allowing LSRs to send RESV messages before installing forwarding 117 state. This optimization is desirable, because it allows LSRs to 118 install forwarding state in parallel, thus accelerating the process 119 of LSP signaling and setup. However, this optimization creates a 120 race condition. When the ingress LSR receives a RESV message, some 121 downstream LSRs may not have installed forwarding state yet. In this 122 case, if the ingress LSR forwards traffic through the LSP, traffic 123 will be black-holed until forwarding state is installed on all of the 124 downstream LSRs. 126 The ingress LSR can prevent back-holing by verifying the LSPs 127 readiness to carry traffic before forwarding traffic through it. LSP 128 Ping [RFC4379] and BFD [RFC5884] are mechanisms that the ingress LSR 129 could use to verify LSP readiness. However, LSP Ping and BFD consume 130 control plane resource on the egress LSR. During periods of network 131 restoration or reoptimzation, control plane resources may be scarce. 132 Therefore, a mechanism that does not consume control plane resources 133 on the egress LSR is required. 135 LSP Self-ping is a new, light-weight protocol that ingress LSRs can 136 use to verify an LSPs readiness to carry traffic. Unlike LSP Ping, 137 LSP Self-ping does not consume control plane resources on the egress 138 LSR. 140 When an ingress LSR executes LSP Self-ping procedures, it constructs 141 a probe message. The probe message is an IP datagram whose 142 destination address represents an interface on the ingress LSR. 144 The ingress LSR forwards the probe through the LSP under test. If 145 the LSP is ready to forward traffic, the egress LSR receives the 146 probe. Because the probe is addressed to the ingress LSR, the egress 147 LSR forwards the probe back to the ingress. When the ingress LSR 148 receives the probe, it has verified LSP readiness without consuming 149 control plane resources at the egress LSR. 151 While LSP Self-ping does not consume control plane resources at the 152 egress LSR, it cannot detect some failures that can be detected by 153 protocols that consume control plane resources at the egress. For 154 example, LSP Self-ping cannot detect a misrouted LSP. Furthermore, 155 LSP Self-ping cannot be used to verify LSPs that were signaled using 156 LDP independent mode. 158 2. LSP Self Ping Procedures 160 In order to verify that an LSP is ready to carry traffic, the ingress 161 LSR creates a short-lived LSP Self-ping session. All session state 162 is maintained locally on the ingress LSR. Session state includes the 163 following: 165 o Session-id: A 32-bit number that identifies the session 167 o verification-status: A boolean variable indicating whether LSP 168 readiness has been verified. The initial value of this variable 169 is FALSE. 171 o retries: The number of times that the ingress LSR probes the LSP 172 before giving up. The initial value of this variable is 173 determined by configuration. 175 o retry-timer: The number of milliseconds that the LSR waits after 176 probing the LSP. The initial value of this variable is determined 177 by configuration. 179 The ingress LSR executes the following procedure until verification- 180 status equals TRUE or retries is less than 1: 182 o Format a MPLS Echo Reply [RFC4379] message 184 o Send the MPLS Echo Reply message through the LSP under test 186 o Set a timer to expire in retry-timer milliseconds 188 o Wait until either a) a MPLS Echo Reply message associated with the 189 session returns or b) the timer expires. If an MPLS Echo Reply 190 message associated with the session returns, set verification- 191 status to TRUE. Otherwise, decrement retries. Optionally, 192 increase the value of retry-timer according to an appropriate back 193 off algorithm. 195 As per [RFC4379], the MPLS Echo Reply message is encapsulate in a 196 User Datagram Protocol (UDP) [RFC0768] header. If the protocol 197 messages used to establish the LSP were delivered over IPv4 198 [RFC0791], the UDP datagram is encapsulated in an IPv4 header. If 199 the protocol messages used to establish the LSP were delivered over 200 IPv6 [RFC2460], the UDP datagram is encapsulated in an IPv6 header. 202 In either case, message contents are as follows: 204 o IP Source Address is configurable. By default, it is the address 205 of the egress LSR 207 o IP Destination Address is the address of the ingress LSR 209 o IP Time to Live (TTL) / Hop Count is 255 211 o IP DSCP is configurable. By default, it is equal to CS6 (Ox48) 212 [RFC4594] 214 o UDP Source Port is any port selected from the dynamic range 215 (49152-65535) [RFC6335] 217 o UDP Destination Port is any port selected from the dynamic range 219 o MPLS Echo Global Flags are clear (i.e., set to 0) 221 o MPLS Echo Type is equal to "MPLS Echo Reply" (2) 223 o MPLS Echo Reply Mode is "Reply via an IPv4/IPv6 UDP packet" (2) 225 o MPLS Echo Senders Handle is equal to the Session-ID 227 o MPLS Echo Sequence Number is equal to retries 229 o MPLS Echo Time Stamp Sent is equal to the current time 231 The reader should note that the ingress LSR probes the LSP by sending 232 an MPLS Echo Reply message, addressed to itself, through the LSP. 233 The egress LSR forwards the MPLS Echo Reply message back to the 234 ingress LSR, exactly as it would forward any other IP packet. 236 If the LSP under test is ready to carry traffic, the egress LSR 237 receives the MPLS Echo Reply message. The MPLS Echo Reply message 238 can arrive at the egress LSR with or without an MPLS header, 239 depending on whether the LSP under test executes penultimate hop- 240 popping procedures. If the MPLS Echo Reply message arrives at the 241 egress LSR with an MPLS header, the egress LSR removes that header. 243 The egress LSR forwards the MPLS Echo Reply message to its 244 destination, the ingress LSR. The egress LSR forwards the MPLS Echo 245 Reply message exactly as it would forward any other IP packet. If 246 the egress LSR's most preferred route to the ingress LSR is through 247 an LSP, the egress LSR forwards the MPLS Echo Reply message through 248 that LSP. However, if the egress LSR's most preferred route to the 249 ingress LSR is not through an LSP, the egress LSR forwards the MPLS 250 Echo Reply message without MPLS encapsulation. 252 If the ingress LSR receives an MPLS Echo Reply message with Senders 253 Handle equal to the Session-ID, it sets the verification-status to 254 TRUE. The Sequence Number does not have to match the last Sequence 255 Number sent. 257 When an LSP Self-ping session terminates, it returns the value of 258 verification-status to the invoking protocol. For example, assume 259 that RSVP-TE invokes LSP Self-ping as part of the LSP set-up 260 procedure. If LSP Self-ping returns TRUE, RSVP-TE makes the LSP 261 under test available for forwarding. However, if LSP Self-ping 262 returns FALSE, RSVP-TE takes appropriate remedial actions. 264 LSP Self-ping fails if all of the following conditions are true: 266 o The Source Address of the MPLS Echo Reply message is equal to its 267 default value (that is, the address of the egress LSR) 269 o The penultimate hop pops the MPLS label 271 o The egress LSR executes Unicast Reverse Path Forwarding (uRPF) 272 procedures 274 In this scenario and in similar scenarios, the egress LSR discards 275 the MPLS Echo Reply message rather than forwarding it. In such 276 scenarios, the calling application can set the source address to a 277 more appropriate value. 279 3. Bidirectional LSP Procedures 281 In order to verify a bidirectional LSP's readiness to carry traffic, 282 the procedures described in Section 2 are executed twice, once by 283 each LSP endpoint. Each LSP endpoint tests LSP readiness in one 284 direction. 286 4. Rejected Approaches 288 In a rejected approach, the ingress LSR uses LSP-Ping, exactly as 289 described in [RFC4379] to verify LSP readiness to carry traffic. 290 This approach was rejected for the following reasons. 292 While an ingress LSR can control its control plane overhead due to 293 LSP Ping, an egress LSR has no such control. This is because each 294 ingress LSR can, on its own, control the rate of the LSP Ping 295 originated by the LSR, while an egress LSR must respond to all the 296 LSP Pings originated by various ingresses. Furthermore, when an MPLS 297 Echo Request reaches an egress LSR it is sent to the control plane of 298 the egress LSR, which makes egress LSR processing overhead of LSP 299 Ping well above the overhead of its data plane (MPLS/IP forwarding). 300 These factors make LSP Ping problematic as a tool for detecting LSP 301 readiness to carry traffic when dealing with a large number of LSPs. 303 By contrast, LSP Self-ping does not consume any control plane 304 resources at the egress LSR, and relies solely on the data plane of 305 the egress LSR, making it more suitable as a tool for checking LSP 306 readiness when dealing with a large number of LSPs. 308 In another rejected approach, the ingress LSR does not verify LSP 309 readiness. Alternatively, it sets a timer when it receives an RSVP 310 RESV message and does not forward traffic through the LSP until the 311 timer expires. This approach was rejected because it is impossible 312 to determine the optimal setting for this timer. If the timer value 313 is set too low, it does not prevent black-holing. If the timer value 314 is set too high, it slows down the process of LSP signalling and 315 setup. 317 Moreover, the above-mentioned timer is configured on a per-router 318 basis. However, its optimum value is determined by a network-wide 319 behavior. Therefore, changes in the network could require changes to 320 the value of the timer, making the optimal setting of this timer a 321 moving target. 323 5. IANA Considerations 325 This document makes no request of IANA. 327 Note to RFC Editor: this section may be removed on publication as an 328 RFC. 330 6. Security Considerations 332 MPLS Echo messages are easily forged. Therefore, an attacker can 333 send the ingress LSR a forged MPLS Echo message, causing the ingress 334 LSR to terminate the LSP Self-ping session prematurely. 336 7. Acknowledgements 338 Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne and 339 Nobo Akiya for their contributions to this document. 341 8. Normative References 343 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 344 August 1980. 346 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 347 1981. 349 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 350 (IPv6) Specification", RFC 2460, December 1998. 352 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 353 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 354 Encoding", RFC 3032, January 2001. 356 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 357 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 358 Tunnels", RFC 3209, December 2001. 360 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 361 Label Switched (MPLS) Data Plane Failures", RFC 4379, 362 February 2006. 364 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 365 Guidelines for DiffServ Service Classes", RFC 4594, August 366 2006. 368 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 369 Specification", RFC 5036, October 2007. 371 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 372 "Bidirectional Forwarding Detection (BFD) for MPLS Label 373 Switched Paths (LSPs)", RFC 5884, June 2010. 375 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 376 Cheshire, "Internet Assigned Numbers Authority (IANA) 377 Procedures for the Management of the Service Name and 378 Transport Protocol Port Number Registry", BCP 165, RFC 379 6335, August 2011. 381 Authors' Addresses 383 Ravi Torvi 384 Juniper Networks 386 Email: rtorvi@juniper.net 388 Ron Bonica 389 Juniper Networks 391 Email: rbonica@juniper.net 393 Ina Minei 394 Google, Inc. 395 1600 Amphitheatre Parkway 396 Mountain View, CA 94043 397 U.S.A. 399 Email: inaminei@google.com 401 Michael Conn 402 Verizon 404 Email: michael.e.conn@verizon.com 406 Dante Pacella 407 Verizon 409 Email: dante.j.pacella@verizon.com 411 Luis Tomotaki 412 Verizon 414 Email: luis.tomotaki@verizon.com 415 Mark Wygant 416 Verizon 418 Email: mark.wygant@verizon.com