idnits 2.17.1 draft-atlas-mpls-te-express-path-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 (September 12, 2013) is 3850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-isis-te-metric-extensions-00 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-te-metric-extensions-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group A. Atlas 3 Internet-Draft J. Drake 4 Intended status: Informational Juniper Networks 5 Expires: March 16, 2014 S. Giacalone 6 Thomson Reuters 7 D. Ward 8 S. Previdi 9 C. Filsfils 10 Cisco Systems 11 September 12, 2013 13 Performance-based Path Selection for Explicitly Routed LSPs using TE 14 Metric Extensions 15 draft-atlas-mpls-te-express-path-04 17 Abstract 19 In certain networks, it is critical to consider network performance 20 criteria when selecting the path for an explicitly routed RSVP-TE 21 LSP. Such performance criteria can include latency, jitter, and loss 22 or other indications such as the conformance to link performance 23 objectives and non-RSVP TE traffic load. This specification uses 24 network performance data, such as is advertised via the OSPF and ISIS 25 TE metric extensions (defined outside the scope of this document) to 26 perform such path selections. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 16, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 4 64 1.2. Oscillation and Stability Considerations . . . . . . . . 4 65 2. Using Performance Data Constraints . . . . . . . . . . . . . 5 66 2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5 67 2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Links out of compliance with Link Performance Objectives 6 69 2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7 70 2.3.2. Links entering the Anomalous State . . . . . . . . . 7 71 2.3.3. Links leaving the Anomalous State . . . . . . . . . . 8 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 6.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 81 In certain networks, such as financial information networks, network 82 performance information is becoming as critical to data path 83 selection as other existing metrics. Network performance information 84 can be obtained via either the TE Metric Extensions in OSPF 85 [I-D.ietf-ospf-te-metric-extensions] or ISIS 86 [I-D.ietf-isis-te-metric-extensions] or via a management system. As 87 with other TE information flooded via OSPF or ISIS, the TE metric 88 extensions have a flooding scope limited to the local area or level. 89 This document describes how to use that information for path 90 selection for explicitly routed LSPs signaled via RSVP-TE [RFC3209]. 91 Methods of optimizing path selection for multiple parameters are 92 generally computationally complex. However, there are good 93 heuristics for the delay-constrained lowest-cost (DCLC) computation 94 problem [k-Paths_DCLC] that can be applied to consider both path cost 95 and a maximum delay bound. Some of the network performance 96 information can also be used to prune links from a topology before 97 computing the path. 99 The path selection mechanisms described in this document apply to 100 paths that are fully computed by the head-end of the LSP and then 101 signaled in an ERO where every sub-object is strict. This allows the 102 head-end to consider IGP-distributed performance data without 103 requiring the ability to signal the performance constraints in an 104 object of the RSVP Path message. 106 When considering performance-based data, it is obvious that there are 107 additional contributors to latency beyond just the links. Clearly 108 end-to-end latency is a combination of router latency (e.g. latency 109 from traversing a router without queueing delay), queuing latency, 110 physical link latency and other factors. While traversing a router 111 can cause delay, that router latency can be included in the 112 advertised link delay. As described in 113 [I-D.ietf-ospf-te-metric-extensions] and 114 [I-D.ietf-isis-te-metric-extensions], queuing delay must not be 115 included in the measurements advertised by OSPF or ISIS. 117 Queuing latency is specifically excluded to insure freedom from 118 oscillations and stability issues that have plagued prior attempts to 119 use delay as a routing metric. If application traffic follows a path 120 based upon latency constraints, the same traffic might be in an 121 Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing 122 delay or another PHB with potentially very substantial per-hop 123 queuing delay. Only traffic which experiences relatively low 124 congestion, such as Expedited Forwarding traffic, will experience 125 delays very close to the sum of the reported link delays. 127 This document does not specify how a router determines what values to 128 advertise by the IGP; it does assume that the constraints specified 129 in [I-D.ietf-ospf-te-metric-extensions] and 130 [I-D.ietf-isis-te-metric-extensions] are followed. Additionally, the 131 end-to-end performance that is computed for an LSP path should be 132 built from the individual link data. Any end-to-end characterization 133 used to determine an LSP's performance compliance should be fully 134 reflected in the Traffic Engineering Database so that a path 135 calculation can also determine whether a path under consideration 136 would be in compliance. 138 1.1. Basic Requirements 140 The following are the requirements that motivate this solution. 142 1. Select a TE tunnel's path based upon a combination of existing 143 constraints as well as on link-latency, packet loss, jitter, link 144 performance objectives conformance, and bandwidth consumed by 145 non-RSVP-TE traffic. 147 2. Ability to define different end-to-end performance requirements 148 for each TE tunnel regardless of common use of resources. 150 3. Ability to periodically verify with the TE LSDB that a TE 151 tunnel's current LSP complies with its configured end-to-end 152 performance requirements. 154 4. Ability to move tunnels, using make-before-break, based upon 155 computed end-to-end performance complying with constraints. 157 5. Ability to move tunnels away from any link that is violating an 158 underlying link performance objective. 160 6. Ability to optionally avoid setting up tunnels using any link 161 that is violating a link performance objective, regardless of 162 whether end-to-end performance would still meet requirements. 164 7. Ability to revert back using make-before-break to the best path 165 after a configurable period. 167 1.2. Oscillation and Stability Considerations 169 Past attempts to use unbounded delay or loss as metric sufferred from 170 severe oscillations. The use of performance based data must be such 171 that undampened oscillations are not possible and stability cannot be 172 impacted. 174 The use of timers is often cited as a cure. Oscillation that is 175 damped by timers is known as "slosh". If advertisement timers are 176 very short relative to the jitter applied to RSVP-TE CSPF timers, 177 then a partial oscillation occurs. If RSVP-TE CSPF timers are short 178 relative to advertisement timers, full oscillation (all traffic 179 moving back and forth) can occur. Even a partial oscillation causes 180 unnecessary reordering which is considered at least minimally 181 disruptive. 183 Delay variation or jitter is affected by even small traffic levels. 184 At even tiny traffic levels, the probability of a queue occupancy of 185 one can produce a measured jitter proportional to or equal to the 186 packet serialization delay. Very low levels of traffic can increase 187 the probability of queue occupancies of two or three packets enough 188 to further increase the measured jitter. Because jitter measurement 189 is extremely sensitive to even very low traffic levels, any use of 190 jitter is likely to oscillate. There may be legitimate use of a 191 jitter measurement in path computation that can be considered free of 192 oscillation. 194 Delay measurements that are not sensitive to traffic loads may be 195 safely used in path computation. Delay measurements made at the link 196 layer or measurements made at a queuing priority higher than any 197 significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not CS2 198 if traffic levels at CS3 and higher or EF and AF can affect the 199 measurement). Making delay measurements at the same priority as the 200 traffic on affected paths is likely to cause oscillations. 202 2. Using Performance Data Constraints 204 2.1. End-to-End Constraints 206 The per-link performance data available in the IGP 207 [I-D.ietf-ospf-te-metric-extensions] 208 [I-D.ietf-isis-te-metric-extensions] includes: unidirectional link 209 delay, unidirectional delay variation, and link loss. Each (or all) 210 of these parameters can be used to create the path-level link-based 211 parameter. 213 It is possible to compute a CSPF where the link latency values are 214 used instead of TE metrics, this results in ignoring the TE metrics 215 and causing LSPs to prefer the lowest-latency paths. In practical 216 scenarios, latency constraints are typically a bound constraint 217 rather than a minimization objective. An end-to-end latency upper 218 bound merely requires that the path computed be no more than that 219 bound and does not require that it be the minimum latency path. The 220 latter is exactly the delay-constrained lowest-cost (DCLC) problem to 221 which good heuristics have been proposed in the literature (e.g. 222 [k-Paths_DCLC]). 224 An end-to-end bound on delay variation can be used similarly as a 225 constraint in the path computation on what links to explore where the 226 path's delay variation is the sum of the used links' delay 227 variations. 229 For link loss, the path loss is not the sum of the used links' 230 losses. Instead, the path loss percentage is 100 - (100 - 231 loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links along 232 the path are L1 to Ln. The end-to-end link loss bound, computed in 233 this fashion, can also be used as a constraint in the path 234 computation. 236 The heuristic algorithms for DCLC only address one constraint bound 237 but having a CSPF that limits the paths explored (i.e. based on hop- 238 count) can be combined [hop-count_DCLC]. 240 2.2. Link Constraints 242 In addition to selecting paths that conform to a bound on performance 243 data, it is also useful to avoid using links that do not meet a 244 necessary constraint. Naturally, if such a parameter were a known 245 fixed value, then resource attribute flags could be used to express 246 this behavior. However, when the parameter associated with a link 247 may vary dynamically, there is not currently a configuration-time 248 mechanism to enforce such behavior. An example of this is described 249 in Section 2.3, where links may move in and out of conformance for 250 link performance objectives with regards to latency, delay variation, 251 and link loss. 253 When doing path selection for TE tunnels, it has not been possible to 254 know how much actual bandwidth is available that includes the 255 bandwidth used by non-RSVP-TE traffic. In 256 [I-D.ietf-ospf-te-metric-extensions] 257 [I-D.ietf-isis-te-metric-extensions], the Unidirectional Available 258 Bandwidth is advertised as is the Residual Bandwidth. When computing 259 the path for a TE tunnel, only links with at least a minimum amount 260 of Unidirectional Available Bandwidth might be permitted. 262 Similarly, only links whose loss is under a configurable value might 263 be acceptable. For these constraints, each link can be tested 264 against the constraint and only explored in the path computation if 265 the link passes. In essence, a link that fails the constraint test 266 is treated as if it contained a resource attribute in the exclude-any 267 filter. 269 2.3. Links out of compliance with Link Performance Objectives 270 Link conformance to a link performance objective can change as a 271 result of rerouting at lower layers. This could be due to optical 272 regrooming or simply rerouting of a FA-LSP. When this occurs, there 273 are two questions to be asked: 275 a. Should the link be trusted and used for the setup of new LSPs? 277 b. Should LSPs using this link automatically be moved to a secondary 278 path? 280 2.3.1. Use of Anomalous Links for New Paths 282 If the answer to (a) is no for link latency performance objectives, 283 then any link which has the Anomalous bit set in the Unidirectional 284 Link Delay sub-TLV[I-D.ietf-ospf-te-metric-extensions] 285 [I-D.ietf-isis-te-metric-extensions] should be removed from the 286 topology before a path calculation is used to compute a new path. In 287 essence, the link should be treated exactly as if it fails the 288 exclude-any resource attributes filter.[RFC3209]. 290 Similarly, if the answer to (a) is no for link loss performance 291 objectives, then any link which has the Anomalous bit set in the Link 292 Los sub-TLV should be treated as if it fails the exclude-any resource 293 attributes filter. If the answer to (a) is no for link jitter 294 performance objectives, then any link that has the Anomalous bit set 295 in the Unidirectional Delay Variation sub- 296 TLV[I-D.ietf-isis-te-metric-extensions] should be treated as if it 297 fails the exclude-any resource attributes filter. 299 2.3.2. Links entering the Anomalous State 301 When a link enters the Anomalous state with respect to a parameter, 302 this is an indication that LSPs using that link might also no longer 303 be in compliance with their performance bounds. It can also be 304 considered an indication that something is changing that link and so 305 it might no longer be trustworthy to carry performance-critical 306 traffic. Naturally, which performance criteria are important for a 307 particular LSP is dependent upon the LSP's configuration and thus the 308 compliance of a link with respect to a particular link performance 309 objective is indicated per performance criterion. 311 At the ingress of a TE tunnel, a TE tunnel may be configured to be 312 sensitive to the Anomalous state of links in reference to latency, 313 delay variation, and/or loss. Additionally, such a TE tunnel may be 314 configured to either verify continued compliance, to switch 315 immediately to a standby LSP, or to move to a different path. 317 When a sub-TLV is received with the Anomalous bit set when previously 318 it was clear, the list of interested TE tunnels must be scanned. 319 Each such TE tunnel should either have its continued compliance 320 verified, be switched to a hot standby, or do a make-before-break to 321 a secondary path. 323 It is not sufficient to just look at the Anomalous bit in order to 324 determine when TE tunnels must have their compliance verified. When 325 changing to set, the Anomalous bit merely provides a hint that 326 interested TE tunnels should have their continued compliance 327 verified. 329 2.3.3. Links leaving the Anomalous State 331 When a link leaves the Anomalous state with respect to a parameter, 332 this can serve as an indication that those TE tunnels, whose LSPs 333 were changed due to administrative policy when the link entered the 334 Anomalous state, may want to reoptimize to a better path. The hint 335 provided by the Anomalous state change may help optimize when to 336 recompute for a better path. 338 3. IANA Considerations 340 This document includes no request to IANA. 342 4. Security Considerations 344 This document is not currently believed to introduce new security 345 concerns. 347 5. Acknowledgements 349 The authors would like to thank Curtis Villamizar for his extensive 350 detailed comments and suggested text in the Section 1 and 351 Section 1.2. The authors would also like to thank Xiaohu Xu and 352 Sriganesh Kini for their review. 354 6. References 356 6.1. Normative References 358 [I-D.ietf-isis-te-metric-extensions] 359 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 360 A., and C. Filsfils, "IS-IS Traffic Engineering (TE) 361 Metric Extensions", draft-ietf-isis-te-metric- 362 extensions-00 (work in progress), June 2013. 364 [I-D.ietf-ospf-te-metric-extensions] 365 Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 366 Previdi, "OSPF Traffic Engineering (TE) Metric 367 Extensions", draft-ietf-ospf-te-metric-extensions-04 (work 368 in progress), June 2013. 370 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 371 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 372 Tunnels", RFC 3209, December 2001. 374 6.2. Informative References 376 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 377 J., Courtney, W., Davari, S., Firoiu, V., and D. 378 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 379 Behavior)", RFC 3246, March 2002. 381 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 382 Guidelines for DiffServ Service Classes", RFC 4594, August 383 2006. 385 [hop-count_DCLC] 386 Agrawal, H., Grah, M., and M. Gregory, "Optimization of 387 QoS Routing", 6th IEEE/AACIS International Conference on 388 Computer and Information Science 2007, 2007, . 392 [k-Paths_DCLC] 393 Jia, Z. and P. Varaiya, "Heuristic methods for delay 394 constrained least cost routing using k-shortest-paths", 395 IEEE Transactions on Automatic Control 51(4), 2006, . 399 Authors' Addresses 401 Alia Atlas 402 Juniper Networks 403 10 Technology Park Drive 404 Westford, MA 01886 405 USA 407 Email: akatlas@juniper.net 408 John Drake 409 Juniper Networks 410 1194 N. Mathilda Ave. 411 Sunnyvale, CA 94089 412 USA 414 Email: jdrake@juniper.net 416 Spencer Giacalone 417 Thomson Reuters 418 195 Broadway 419 New York, NY 10007 420 USA 422 Email: Spencer.giacalone@thomsonreuters.com 424 Dave Ward 425 Cisco Systems 426 170 West Tasman Dr. 427 San Jose, CA 95134 428 USA 430 Email: dward@cisco.com 432 Stefano Previdi 433 Cisco Systems 434 Via Del Serafico 200 435 Rome 00142 436 Italy 438 Email: sprevidi@cisco.com 440 Clarence Filsfils 441 Cisco Systems 442 Brussels 443 Belgium 445 Email: cfilsfil@cisco.com