idnits 2.17.1 draft-bonica-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 (November 10, 2014) is 3454 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: Informational Juniper Networks 5 Expires: May 14, 2015 M. Conn 6 D. Pacella 7 L. Tomotaki 8 M. Wygant 9 Verizon 10 November 10, 2014 12 LSP Self-Ping 13 draft-bonica-mpls-self-ping-03 15 Abstract 17 This memo describes LSP Self-ping. Ingress LSR's can use LSP Self- 18 ping to verify that an LSP is ready to carry traffic. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 14, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 3 56 3. Rejected Approaches . . . . . . . . . . . . . . . . . . . . . 6 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 An ingress Label Switching Router (LSR) can use RSVP-TE [RFC3209] to 66 establish an MPLS Label Switched Path [RFC3032]. The following 67 paragraphs provide an overview of RSVP-TE procedures. 69 The ingress LSR calculates an explicit path between itself and an 70 egress LSR. It then formats an RSVP PATH message, including an 71 Explicit Route Object (ERO). The ERO represents the explicit path 72 between the ingress and egress LSRs. 74 The ingress LSR forwards the PATH message in the direction of the 75 egress LSR, following the path defined by the ERO. Each transit LSR 76 that receives the PATH message executes admission control procedures. 77 If the transit LSR admits the LSP, it reserves bandwidth (if 78 necessary) and sends the PATH message downstream, to the next node in 79 the ERO. 81 When the egress LSR receives the PATH message, it binds a label to 82 the LSP. The label can be implicit null, explicit null, or non-null. 83 The egress LSR then installs forwarding state (if necessary), and 84 constructs an RSVP RESV message. The RESV message includes a Label 85 Object containing the label that has been bound to the LSP. 87 The egress LSR sends the RESV message upstream towards the ingress 88 LSR. The RESV message visits the same transit LSRs that the PATH 89 message visited, but in reverse order. Each transit LSR binds a 90 label to the LSP, updates its forwarding state and updates the RESV 91 message. As a result, the RESV message contains a Label Object and 92 the Label Object contains the label that has been bound to the LSP. 93 Next, the transit LSR sends the RESV message upstream, along the 94 explicit path. 96 The ingress LSR receives the RESV message and installs forwarding 97 state. Once the ingress LSR installs forwarding state it can forward 98 traffic through the LSP. 100 An implementation can optimize the procedure described above by 101 allowing LSRs to send a RESV messages upstream before installing 102 forwarding state. This optimization is desirable, because it allows 103 LSRs to install forwarding state in parallel, thus accelerating the 104 process of LSP signaling and setup. However, this optimization 105 creates a race condition. When the ingress LSR receives a RESV 106 message, some downstream LSRs may have not yet completed the process 107 of forwarding state installation. If the ingress sends traffic over 108 the LSP, the traffic will be black-holed until forwarding state has 109 been installed on all downstream LSRs. 111 The ingress LSP can prevent back-holing by verifying the LSPs 112 readiness to carry traffic before forwarding traffic through it. 113 Ingress LSRs can use LSP Self-Ping to verify that an LSP is ready to 114 carry traffic. 116 LSP Self-ping is an extremely lightweight mechanism, designed to 117 perform well when control plane resources are scarce. Therefore, LSP 118 Self-ping consumes no control plane resources on transit or egress 119 LSRs. 121 This memo describes LSP Self-ping. 123 2. LSP Self Ping Procedures 125 In order to verify that an LSP is ready to carry traffic, the ingress 126 LSR creates a short-lived LSP Self-ping session. All session state 127 is maintained locally on the ingress LSR. Session state includes the 128 following: 130 o Session-id: A 32-bit number that identifies the session 132 o verification-status: A boolean variable indicating whether LSP 133 readiness has been verified. The initial value of this variable 134 is FALSE. 136 o retries: The number of times that the ingress LSR probes the LSP 137 before giving up. The initial value of this variable is 138 determined by configuration. 140 o retry-timer: The number of milliseconds that the LSR waits after 141 probing the LSP. The initial value of this variable is determined 142 by configuration. 144 The ingress LSR executes the following procedure until verification- 145 status equals TRUE or retries is less than 1: 147 o Format a MPLS Echo [RFC4379] message 149 o Send the MPLS Echo message through the LSP under test 151 o Set a timer to expire in retry-timer milliseconds 153 o Wait until either a) a MPLS Echo message associated with the 154 session returns or b) the timer expires. If an MPLS Echo message 155 associated with the session returns, set verification-status to 156 TRUE. Otherwise, decrement retries. Optionally, increase the 157 value of retry-timer according to an appropriate back off 158 algorithm. 160 As per [RFC4379], the MPLS Echo message is encapsulate in a User 161 Datagram Protocol (UDP) [RFC0768] header. If the protocol messages 162 used to establish the LSP were delivered over IPv4 [RFC0791], the UDP 163 datagram is encapsulated in an IPv4 header. If the protocol messages 164 used to establish the LSP were delivered over IPv6 [RFC2460], the UDP 165 datagram is encapsulated in an IPv6 header. 167 In either case, message contents are as follows: 169 o IP Source Address is configurable. By default, it is the address 170 of the egress LSR 172 o IP Destination Address is the address of the ingress LSR 174 o IP Time to Live (TTL) / Hop Count is 255 176 o IP DSCP is configurable. By default, it is equal to CS6 (Ox48) 177 [RFC4594] 179 o UDP Source Port is any port selected from the dynamic range 180 (49152-65535) [RFC6335] 182 o UDP Destination Port is any port selected from the dynamic range 184 o MPLS Echo Global Flags are clear (i.e., set to 0) 186 o MPLS Echo Type is equal to "MPLS Echo Reply" (2) 188 o MPLS Echo Reply Mode is "Reply via an IPv4/IPv6 UDP packet" (2) 190 o MPLS Echo Senders Handle is equal to the Session-ID 191 o MPLS Echo Sequence Number is equal to retries 193 o MPLS Echo Time Stamp Sent is equal to the current time 195 The reader should note that the ingress LSR probes the LSP by sending 196 an MPLS Echo message, addressed to itself, through the LSP. The 197 egress LSR forwards the MPLS Echo message back to the ingress LSR, 198 exactly as it would forward any other packet. 200 If the LSP under test is ready to carry traffic, the egress LSR 201 receives the MPLS Echo message. The MPLS Echo message can arrive at 202 the egress LSR with or without an MPLS header, depending on whether 203 the LSP under test executes penultimate hop-popping procedures. If 204 the MPLS Echo message arrives at the egress LSR with an MPLS header, 205 the egress LSR removes that header. 207 The egress LSR forwards the MPLS Echo message to its destination, the 208 ingress LSR. The egress LSR forwards the MPLS Echo message exactly 209 as it would forward any other packet. If the egress LSR's most 210 preferred route to the ingress LSR is through an LSP, the egress LSR 211 forwards the MPLS Echo message through that LSP. However, if the 212 egress LSR's most preferred route to the ingress LSR is not through 213 an LSP, the egress LSR forwards the MPLS Echo message without MPLS 214 encapsulation. 216 If the ingress LSR receives an MPLS Echo message with Senders Handle 217 equal to the Session-ID, it sets the verification-status to TRUE. 218 The Sequence Number does not have to match the last Sequence Number 219 sent. 221 When an LSP Self-ping session terminates, it returns the value of 222 verification-status to the invoking protocol. For example, assume 223 that RSVP-TE invokes LSP Self-ping as part of the LSP set-up 224 procedure. If LSP Self-ping returns TRUE, RSVP-TE makes the LSP 225 under test available for forwarding. However, if LSP Self-ping 226 returns FALSE, RSVP-TE takes appropriate remedial actions. 228 LSP Self-ping fails if all of the following conditions are true: 230 o The Source Address of the MPLS Echo message is equal to its 231 default value (that is, the address of the egress LSR) 233 o The penultimate hop pops the MPLS label 235 o The egress LSR executes Unicast Reverse Path Forwarding (uRPF) 236 procedures 238 In this scenario and in similar scenarios, the egress LSR discards 239 the MPLS Echo message rather than forwarding it. In such scenarios, 240 the calling application can set the source address to a more 241 appropriate value. 243 3. Rejected Approaches 245 In a rejected approach, the ingress LSR uses LSP-Ping, exactly as 246 described in [RFC4379] to verify LSP readiness to carry traffic. 247 This approach was rejected for the following reasons. 249 While an ingress LSR can control its control plane overhead due to 250 LSP Ping, an egress LSR has no such control. This is because each 251 ingress LSR can, on its own, control the rate of the LSP Ping 252 originated by the LSR, while an egress LSR must respond to all the 253 LSP Pings originated by various ingresses. Furthermore, when an MPLS 254 Echo Request reaches an egress LSR it is sent to the control plane of 255 the egress LSR, which makes egress LSR processing overhead of LSP 256 Ping well above the overhead of its data plane (MPLS/IP forwarding). 257 These factors make LSP Ping problematic as a tool for detecting LSP 258 readiness to carry traffic when dealing with a large number of LSPs. 260 By contrast, LSP Self-ping does not consume any control plane 261 resources at the egress LSR, and relies solely on the data plane of 262 the egress LSR, making it more suitable as a tool for checking LSP 263 readiness when dealing with a large number of LSPs. 265 In another rejected approach, the ingress LSR does not verify LSP 266 readiness. Alternatively, it sets a timer when it receives an RSVP 267 RESV message and does not forward traffic through the LSP until the 268 timer expires. This approach was rejected because it is impossible 269 to determine the optimal setting for this timer. If the timer value 270 is set too low, it does not prevent black-holing. If the timer value 271 is set too high, it slows down the process of LSP signalling and 272 setup. 274 Moreover, the above-mentioned timer is configured on a per-router 275 basis. However, its optimum value is determined by a network-wide 276 behavior. Therefore, changes in the network could require changes to 277 the value of the timer, making the optimal setting of this timer a 278 moving target. 280 4. IANA Considerations 282 This document makes no request of IANA. 284 Note to RFC Editor: this section may be removed on publication as an 285 RFC. 287 5. Security Considerations 289 MPLS Echo messages are easily forged. Therefore, an attacker can 290 send the ingress LSR a forged MPLS Echo message, causing the ingress 291 LSR to terminate the LSP Self-ping session prematurely. 293 6. Acknowledgements 295 Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne and 296 Nobo Akiya for their contributions to this document. 298 7. Normative References 300 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 301 August 1980. 303 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 304 1981. 306 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 307 (IPv6) Specification", RFC 2460, December 1998. 309 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 310 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 311 Encoding", RFC 3032, January 2001. 313 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 314 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 315 Tunnels", RFC 3209, December 2001. 317 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 318 Label Switched (MPLS) Data Plane Failures", RFC 4379, 319 February 2006. 321 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 322 Guidelines for DiffServ Service Classes", RFC 4594, August 323 2006. 325 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 326 Cheshire, "Internet Assigned Numbers Authority (IANA) 327 Procedures for the Management of the Service Name and 328 Transport Protocol Port Number Registry", BCP 165, RFC 329 6335, August 2011. 331 Authors' Addresses 333 Ravi Torvi 334 Juniper Networks 336 Email: rtorvi@juniper.net 338 Ron Bonica 339 Juniper Networks 341 Email: rbonica@juniper.net 343 Michael Conn 344 Verizon 346 Email: michael.e.conn@verizon.com 348 Dante Pacella 349 Verizon 351 Email: dante.j.pacella@verizon.com 353 Luis Tomotaki 354 Verizon 356 Email: luis.tomotaki@verizon.com 358 Mark Wygant 359 Verizon 361 Email: mark.wygant@verizon.com