idnits 2.17.1 draft-atlas-mpls-te-express-path-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 (July 12, 2013) is 3939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-ospf-te-metric-extensions-04 Summary: 0 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 A. Atlas 3 Internet-Draft J. Drake 4 Intended status: Informational Juniper Networks 5 Expires: January 13, 2014 S. Giacalone 6 Thomson Reuters 7 D. Ward 8 S. Previdi 9 C. Filsfils 10 Cisco Systems 11 July 12, 2013 13 Performance-based Path Selection for Explicitly Routed LSPs using TE 14 Metric Extensions 15 draft-atlas-mpls-te-express-path-03 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 January 13, 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 . . . . . . . . . . . . . . . . . . . 3 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 7 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 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 86 [I-D.ietf-ospf-te-metric-extensions] or ISIS 87 [I-D.previdi-isis-te-metric-extensions] or via a management system. 88 As with other TE information flooded via OSPF or ISIS, the TE metric 89 extensions have a flooding scope limited to the local area or level. 90 This document describes how to use that information for path 91 selection for explicitly routed LSPs signaled via RSVP-TE [RFC3209]. 92 Methods of optimizing path selection for multiple parameters are 93 generally computationally complex. The methods proposed here are to 94 either make use of either a single metric in path selection, such as 95 minimal path delay, or to make use of another single metric, such as 96 the existing TE metric with additional constraints, such as target 97 link delay bounds and target path delay bounds. 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 beyond just the links. Clearly end-to-end 108 latency is a combination of router latency, queuing latency, physical 109 link latency and other factors. While traversing a router can cause 110 delay, that can be included in the advertised link delay. As 111 described in [I-D.ietf-ospf-te-metric-extensions] and 112 [I-D.previdi-isis-te-metric-extensions], queuing delay must not be 113 included in the measurements advertised by OSPF or ISIS. 115 Queuing latency is specifically excluded to insure freedom from 116 oscillations and stability issues that have plagued prior attempts to 117 use delay as a routing metric. If application traffic which follows 118 path based upon latency constraints, the same traffic might be in an 119 Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing 120 delay or another PHB with potentially very substantial per-hop 121 queuing delay. Only traffic which experiences relatively low 122 congestion, such as Expedited Forwarding traffic, will experience 123 delays very close to the sum of the reported link delays. 125 This document does not specify how a router determines what values to 126 advertise by the IGP; it does assume that the constraints specified 127 in [I-D.ietf-ospf-te-metric-extensions] and 128 [I-D.previdi-isis-te-metric-extensions] are followed. Additionally, 129 the end-to-end performance that is computed for an LSP path should be 130 built from the individual link data. Any end-to-end characterization 131 used to determine an LSP's performance compliance should be fully 132 reflected in the Traffic Engineering Database so that a CSPF 133 calculation can also determine whether a path under consideration 134 would be in compliance. 136 1.1. Basic Requirements 138 The following are the requirements that motivate this solution. 140 1. Select a TE tunnel's path based upon a combination of existing 141 constraints as well as on link-latency, packet loss, jitter, link 142 performance objectives conformance, and bandwidth consumed by 143 non-RSVP-TE traffic. 145 2. Ability to define different end-to-end performance requirements 146 for each TE tunnel regardless of common use of resources. 148 3. Ability to periodically verify that a TE tunnel's current LSP 149 complies with its configured end-to-end performance requirements. 151 4. Ability to move tunnels, using make-before-break, based upon 152 computed end-to-end performance complying with constraints. 154 5. Ability to move tunnels away from any link that is violating an 155 underlying link performance objective. 157 6. Ability to optionally avoid setting up tunnels using any link 158 that is violating a link performance objective, regardless of 159 whether end-to-end performance would still meet requirements. 161 7. Ability to revert back to the best path after a configurable 162 period. 164 1.2. Oscillation and Stability Considerations 166 Past attempts to use unbounded delay or loss as metric sufferred from 167 severe oscillations. The use of performance based data must be such 168 that undampened oscillations are not possible and stability cannot be 169 impacted. 171 The use of timers is often cited as a cure. Oscillation that is 172 damped by timers is known as "slosh". If advertisement timers are 173 very short relative to the jitter applied to RSVP-TE CSPF timers, 174 then a partial oscillation occurs. If RSVP-TE CSPF timers are short 175 relative to advertisement timers, full oscillation (all traffic 176 moving back and forth) can occur. Even a partial oscillation causes 177 unnecessary reordering which is considered at least minimally 178 disruptive. 180 Delay variation or jitter is affected by even small traffic levels. 181 At even tiny traffic levels, the probability of a queue occupancy of 182 one can produce a measured jitter proportional to or equal to the 183 packet serialization delay. Very low levels of traffic can increase 184 the probability of queue occupancies of two or three packets enough 185 to further increase the measured jitter. Because jitter measurement 186 is extremely sensitive to even very low traffic levels, any use of 187 jitter is likely to oscillate. There may be legitimate use of a 188 jitter measurement in path computation that can be considered free of 189 oscillation. 191 Delay measurements that are not sensitive to traffic loads may be 192 safely used in path computation. Delay measurements made at the link 193 layer or measurements made at a queuing priority higher than any 194 significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not CS2 195 if traffic levels at CS3 and higher or EF and AF can affect the 196 measurement). Making delay measurements at the same priority as the 197 traffic on affected paths is likely to cause oscillations. 199 2. Using Performance Data Constraints 201 2.1. End-to-End Constraints 203 The per-link performance data available in the IGP 204 [I-D.ietf-ospf-te-metric-extensions] 205 [I-D.previdi-isis-te-metric-extensions] includes: unidirectional link 206 delay, unidirectional delay variation, and link loss. Each (or all) 207 of these parameters can be used to create the path-level link-based 208 parameter. 210 It is possible to compute a CSPF where the link latency values are 211 used instead of TE metrics, this results in ignoring the TE metrics 212 and causing LSPs to prefer the lowest-latency paths. An alternative 213 to this approach to minimize path latency is an approach to place an 214 upper bound on path latency. An end-to-end latency upper bound 215 merely requires that the path computed be no more than that bound and 216 does not require that it be the minimum latency path. This upper 217 bound can be used as a constraint in CSPF to prevent exploring links 218 that would create a path over the end-to-end latency bound. Both 219 approaches are valid. 221 Basic pseudo-code to further explain this pruning is given below. 222 The change is to decide whether to explore a link based on whether 223 the resulting path would violate the specified latency-bound and to 224 accumulate the latency used along the path. 226 CSPF_with_bound(root, latency_bound) 227 root.distance = 0 228 root.latency = 0 229 fibheap_insert(root, root.distance) 230 while (fibheap_not_empty()) 231 next_rtr = fibheap_pop 232 for each link next_link attached to next_rtr 233 if (next_rtr.latency + next_link.latency) < latency_bound 234 explore_link(next_rtr, next_link) 236 Explore_Link(next_rtr, next_link) 237 if ((next_rtr.distance + next_link.metric) < 238 next_link->neighbor.distance) 239 next_link->neighbor.distance = next_rtr.distance + 240 next_link.metric 241 next_link->neighbor.latency = next_rtr.latency + 242 next_link.latency 244 if ((next_rtr.distance + next_link.metric) == 245 next_link->neighbor.distance) 246 if ((next_rtr.latency + next_link.latency) < 247 next_link->neighbor.latency) 248 next_link->neighbor.latency = next_rtr.latency + 249 next_link.latency 251 Partial Pseudo-Code for latency-pruned SPF 253 An end-to-end bound on delay variation can be used similarly as a 254 constraint in the CSPF on what links to explore where the path's 255 delay variation is the sum of the used links' delay variations. 257 For link loss, the path loss is not the sum of the used links' 258 losses. Instead, the path loss percentage is 100 - (100 - 259 loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links along 260 the path are L1 to Ln. The end-to-end link loss bound, computed in 261 this fashion, can also be used as a constraint in the CSPF on what 262 links to explore. 264 2.2. Link Constraints 266 In addition to selecting paths that conform to a bound on performance 267 data, it is also useful to avoid using links that do not meet a 268 necessary constraint. Naturally, if such a parameter were a known 269 fixed value, then resource attribute flags could be used to express 270 this behavior. However, when the parameter associated with a link 271 may vary dynamically, there is not currently a configuration-time 272 mechanism to enforce such behavior. An example of this is described 273 in Section 2.3, where links may move in and out of conformance for 274 link performance objectives with regards to latency, delay variation, 275 and link loss. 277 When doing path selection for TE tunnels, it has not been possible to 278 know how much actual bandwidth is available that includes the 279 bandwidth used by non-RSVP-TE traffic. In 280 [I-D.ietf-ospf-te-metric-extensions] 281 [I-D.previdi-isis-te-metric-extensions], the Unidirectional Available 282 Bandwidth is advertised as is the Residual Bandwidth. When computing 283 the path for a TE tunnel, only links with at least a configurable 284 amount of Unidirectional Available Bandwidth might be permitted. 286 Similarly, only links whose loss is under a configurable value might 287 be acceptable. For these constraints, each link can be tested 288 against the constraint and only explored in the CSPF if the link 289 passes. In essence, a link that fails the constraint test is treated 290 as if it contained a resource attribute in the exclude-any filter. 292 2.3. Links out of compliance with Link Performance Objectives 294 Link conformance to a link performance objective can change as a 295 result of rerouting at lower layers. This could be due to optical 296 regrooming or simply rerouting of a FA-LSP. When this occurs, there 297 are two questions to be asked: 299 a. Should the link be trusted and used for the setup of new LSPs? 301 b. Should LSPs using this link automatically be moved to a secondary 302 path? 304 2.3.1. Use of Anomalous Links for New Paths 306 If the answer to (a) is no for link latency performance objectives, 307 then any link which has the Anomalous bit set in the Unidirectional 308 Link Delay sub-TLV[I-D.ietf-ospf-te-metric-extensions] 309 [I-D.previdi-isis-te-metric-extensions] should be removed from the 310 topology before a CSPF calculation is used to compute a new path. In 311 essence, the link should be treated exactly as if it fails the 312 exclude-any resource attributes filter.[RFC3209]. 314 Similarly, if the answer to (a) is no for link loss performance 315 objectives, then any link which has the Anomalous bit set in the Link 316 Los sub-TLV should be treated as if it fails the exclude-any resource 317 attributes filter. If the answer to (a) is no for link jitter 318 performance objectives, then any link that has the Anomalous bit set 319 in the Unidirectional Delay Variation sub- 320 TLV[I-D.previdi-isis-te-metric-extensions] should be treated as if it 321 fails the exclude-any resource attributes filter. 323 2.3.2. Links entering the Anomalous State 325 When a link enters the Anomalous state with respect to a parameter, 326 this is an indication that LSPs using that link might also no longer 327 be in compliance with their performance bounds. It can also be 328 considered an indication that something is changing that link and so 329 it might no longer be trustworthy to carry performance-critical 330 traffic. Naturally, which performance criteria are important for a 331 particular LSP is dependent upon the LSP's configuration and thus the 332 compliance of a link with respect to a particular link performance 333 objective is indicated per performance criterion. 335 At the ingress of a TE tunnel, a TE tunnel may be configured to be 336 sensitive to the Anomalous state of links in reference to latency, 337 delay variation, and/or loss. Additionally, such a TE tunnel may be 338 configured to either verify continued compliance, to switch 339 immediately to a standby LSP, or to move to a different path. 341 When a sub-TLV is received with the Anomalous bit set when previously 342 it was clear, the list of interested TE tunnels must be scanned. 343 Each such TE tunnel should either have its continued compliance 344 verified, be switched to a hot standby, or do a make-before-break to 345 a secondary path. 347 It is not sufficient to just look at the Anomalous bit in order to 348 determine when TE tunnels must have their compliance verified. When 349 changing to set, the Anomalous bit merely provides a hint that 350 interested TE tunnels should have their continued compliance 351 verified. 353 2.3.3. Links leaving the Anomalous State 355 When a link leaves the Anomalous state with respect to a parameter, 356 this can serve as an indication that those TE tunnels, whose LSPs 357 were changed due to administrative policy when the link entered the 358 Anomalous state, may want to reoptimize to a better path. The hint 359 provided by the Anomalous state change may help optimize when to 360 recompute for a better path. 362 3. IANA Considerations 364 This document includes no request to IANA. 366 4. Security Considerations 368 This document is not currently believed to introduce new security 369 concerns. 371 5. Acknowledgements 373 The authors would like to thank Curtis Villamizar for his extensive 374 detailed comments and suggested text in the Section 1 and 375 Section 1.2. The authors would also like to thank Xiaohu Xu and 376 Sriganesh Kini for their review. 378 6. References 380 6.1. Normative References 382 [I-D.ietf-ospf-te-metric-extensions] 383 Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 384 Previdi, "OSPF Traffic Engineering (TE) Metric 385 Extensions", draft-ietf-ospf-te-metric-extensions-04 (work 386 in progress), June 2013. 388 [I-D.previdi-isis-te-metric-extensions] 389 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 390 A., and C. Filsfils, "IS-IS Traffic Engineering (TE) 391 Metric Extensions", draft-previdi-isis-te-metric- 392 extensions-03 (work in progress), February 2013. 394 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 395 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 396 Tunnels", RFC 3209, December 2001. 398 6.2. Informative References 400 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 401 J., Courtney, W., Davari, S., Firoiu, V., and D. 402 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 403 Behavior)", RFC 3246, March 2002. 405 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 406 Guidelines for DiffServ Service Classes", RFC 4594, August 407 2006. 409 Authors' Addresses 411 Alia Atlas 412 Juniper Networks 413 10 Technology Park Drive 414 Westford, MA 01886 415 USA 417 Email: akatlas@juniper.net 419 John Drake 420 Juniper Networks 421 1194 N. Mathilda Ave. 422 Sunnyvale, CA 94089 423 USA 425 Email: jdrake@juniper.net 427 Spencer Giacalone 428 Thomson Reuters 429 195 Broadway 430 New York, NY 10007 431 USA 433 Email: Spencer.giacalone@thomsonreuters.com 434 Dave Ward 435 Cisco Systems 436 170 West Tasman Dr. 437 San Jose, CA 95134 438 USA 440 Email: dward@cisco.com 442 Stefano Previdi 443 Cisco Systems 444 Via Del Serafico 200 445 Rome 00142 446 Italy 448 Email: sprevidi@cisco.com 450 Clarence Filsfils 451 Cisco Systems 452 Brussels 453 Belgium 455 Email: cfilsfil@cisco.com