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