idnits 2.17.1 draft-atlas-mpls-te-express-path-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 91: '... for an LSP path SHOULD be built from ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2013) is 4095 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5420' is defined on line 291, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ospf-te-metric-extensions-02 == Outdated reference: A later version (-03) exists of draft-previdi-isis-te-metric-extensions-02 Summary: 1 error (**), 0 flaws (~~), 4 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: August 10, 2013 S. Giacalone 6 Thomson Reuters 7 D. Ward 8 S. Previdi 9 C. Filsfils 10 Cisco Systems 11 February 6, 2013 13 Performance-based Path Selection for Explicitly Routed LSPs 14 draft-atlas-mpls-te-express-path-02 16 Abstract 18 In certain networks, it is critical to consider network performance 19 criteria when selecting the path for an explicitly routed RSVP-TE 20 LSP. Such performance criteria can include latency, jitter, and loss 21 or other indications such as the conformance to link SLAs and non- 22 RSVP TE traffic load. This specification uses IGP extension data 23 (which is defined outside the scope of this document) to perform such 24 path selections. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 10, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 1. Introduction 60 In certain networks, such as financial information networks, network 61 performance information is becoming as critical to data path 62 selection as other existing metrics. The ability to distribute 63 network performance information in OSPF 64 [I-D.ietf-ospf-te-metric-extensions] and in ISIS 65 [I-D.previdi-isis-te-metric-extensions] is being defined (outside the 66 scope of this document). This document describes how to use that 67 information for path selection for explicitly routed LSPs signaled 68 via RSVP-TE [RFC3209]. The method suggested is not optimal for both 69 minimizing path cost and additional constraints, such as latency; 70 optimal solutions are computationally complex. 72 The path selection mechanisms described in this document apply to 73 paths that are fully computed by the head-end of the LSP and then 74 signaled in an ERO where every sub-object is strict. This allows the 75 head-end to consider IGP-distributed performance data without 76 requiring the ability to signal the performance constraints in an 77 object of the RSVP Path message. 79 When considering performance-based data, it is obvious that there are 80 additional contributors beyond just the links. Clearly end-to-end 81 latency is a combination of router latency, queuing latency, physical 82 link latency and other factors. However, if application traffic 83 requires paths to be selected based upon latency constraints, the 84 same traffic might be in an Expedited Forwarding Per-Hop- 85 Behavior[RFC3246] with minimal queuing delay or another PHB with 86 known maximal per-hop queuing delay. While traversing a router can 87 cause delay, that can be included in the advertised link delay. 89 This document does not specify how a router determines what values to 90 advertise by the IGP. However, the end-to-end performance that is 91 computed for an LSP path SHOULD be built from the individual link 92 data. Any end-to-end characterization used to determine an LSP's 93 performance compliance should be fully reflected in the Traffic 94 Engineering Database so that a CSPF calculation can also determine 95 whether a path under consideration would be in compliance. 97 1.1. Basic Requirements 99 The following are the requirements that motivate this solution. 101 1. Select a TE tunnel's path based upon a combination of existing 102 constraints as well as on link-latency, packet loss, jitter, link 103 SLA conformance, and bandwidth consumed by non-RSVP-TE traffic. 105 2. Ability to define different end-to-end performance requirements 106 for each TE tunnel regardless of common use of resources. 108 3. Ability to periodically verify that a TE tunnel's current LSP 109 complies with its configured end-to-end perforance requirements. 111 4. Ability to move tunnels, using make-before-break, based upon 112 computed end-to-end performance complying with configuration 114 5. Ability to move tunnels away from any link that is violating an 115 underlying SLA 117 6. Ability to optionally avoid setting up tunnels using any link 118 that is violating an SLA, regardless of whether end-to-end 119 performance would still meet requirements. 121 7. Ability to revert back to the best path after a configurable 122 period. 124 2. Using Performance Data Constraints 126 2.1. End-to-End Constraints 128 The per-link performance data available in the IGP 129 [I-D.ietf-ospf-te-metric-extensions] 130 [I-D.previdi-isis-te-metric-extensions] includes: unidirectional link 131 delay, unidirectional delay variation, and link loss. Each (or all) 132 of these parameters can be used to create the path-level link-based 133 parameter. 135 While it has been possible to compute a CSPF where the link latency 136 values are used instead of TE metrics, this results in ignoring the 137 TE metrics and causing LSPs to prefer the lowest-latency paths. 138 Instead of this approach to minimize path latency, an end-to-end 139 latency bound merely requires that the path computed be no more than 140 that bound without being the minimum. This bound can be used as a 141 constraint in CSPF to prevent exploring links that would create a 142 path over the end-to-end latency bound. 144 This is illustrated as follows. Let the LSP have an end-to-end 145 latency bound of 20ms. Assume that the path to node X has been 146 minimized and its latency is 12ms. When X's links are to be 147 explored, the link X<->Y has a link latency of 5ms and the link X<->Z 148 has a link latency of 9ms. The path via X to Y along link X<->Y 149 would have a path latency of 12ms + 5ms = 17ms < 20ms; therefore, the 150 link X<->Y can be explored. In contrast, reaching Z via link X<->Z 151 would result in a path latency of 12ms + 9ms = 21ms > 20ms; therefore 152 the link X<->Z would not be explored in the CSPF. 154 An end-to-end bound on delay variation can be used similarly as a 155 constraint in the CSPF on what links to explore where the path's 156 delay variation is the sum of the used links' delay variations. 158 For link loss, the path loss is not the sum of the used links' 159 losses. Instead, the path loss percentage is (100 - loss_L1)*(100 - 160 loss_L2)*...*(100 - loss_Ln), where the links along the path are L1 161 to Ln. The end-to-end link loss bound, computed in this fashion, can 162 also be used as a constraint in the CSPF on what links to explore. 164 2.2. Link Constraints 166 In addition to selecting paths that conform to a bound on performance 167 data, it is also useful to avoid using links that do not meet a 168 necessary constraint. Naturally, if such a parameter were a known 169 fixed value, then resource attribute flags could be used to express 170 this behavior. However, when the parameter associated with a link 171 may vary dynamically, there is not currently a configuration-time 172 mechanism to enforce such behavior. An example of this is described 173 in Section 2.3, where links may move in and out of SLA-conformance 174 with regards to latency, delay variation, and link loss. 176 When doing path selection for TE tunnels, it has not been possible to 177 know how much actual bandwidth is available that inludes the 178 bandwidth used by non-RSVP-TE traffic. In 179 [I-D.ietf-ospf-te-metric-extensions] 180 [I-D.previdi-isis-te-metric-extensions], the Unidirectional Available 181 Bandwidth is advertised as is the Residual Bandwidth. When computing 182 the path for a TE tunnel, only links with at least a configurable 183 amount of Unidirectional Available Bandwidth might be permitted. 185 Similarly, only links whose loss is under a configurable value might 186 be acceptable. For these constraints, each link can be tested 187 against the constraint and only explored in the CSPF if the link 188 passes. In essence, a link that fails the constraint test is treated 189 as if it contained a resource attribute in the exclude-any filter. 191 2.3. Links out of SLA 193 Link conformance to an SLA can change as a result of rerouting at 194 lower layers. This could be due to optical regrooming or simply 195 rerouting of a FA-LSP. When this occurs, there are three questions 196 to be asked: 198 a. Should the link be trusted and used for the setup of new LSPs? 200 b. Should LSPs using this link be immediately verified for continued 201 compliance to their end-to-end constraints? 203 c. Should LSPs using this link automatically be moved to a secondary 204 path? 206 2.3.1. Use of Anomalous Links for New Paths 208 If the answer to (a) is no for latency SLAs, then any link which has 209 the Anomalous bit set in the Unidirectional Link Delay sub- 210 TLV[I-D.ietf-ospf-te-metric-extensions] 211 [I-D.previdi-isis-te-metric-extensions] should be removed from the 212 topology before a CSPF calculation is used to compute a new path. In 213 essence, the link should be treated exactly as if it fails the 214 exclude-any resource attributes filter.[RFC3209]. 216 Similarly, if the answer to (a) is no for link loss SLAs, then any 217 link which has the Anomalous bit set in the Link Los sub-TLV should 218 be treated as if it fails the exclude-any resource attributes filter. 219 If the answer to (a) is no for jitter SLAs, then any link that has 220 the Anomalous bit set in the Unidirectional Delay Variation sub- 221 TLV[I-D.previdi-isis-te-metric-extensions] should be treated as if it 222 fails the exclude-any resource attributes filter. 224 2.3.2. Links entering the Anomalous State 226 When a link enters the Anomalous state with respect to a parameter, 227 this is an indication that LSPs using that link might also no longer 228 be in compliance with their performance bounds. It can also be 229 considered an indication that something is changing that link and so 230 it might no longer be trustworthy to carry performance-critical 231 traffic. Naturally, which performance criteria are important for a 232 particular LSP is dependent upon the LSP's configuration and thus the 233 SLA compliance of a link is indicated per performance criterion. 235 At the ingress of a TE tunnel, a TE tunnel may be configured to be 236 sensitive to the Anomalous state of links in reference to latency, 237 delay variation, and/or loss. Additionally, such a TE tunnel may be 238 configured to either verify continued compliance, to switch 239 immediately to a standby LSP, or to move to a different path. 241 When a sub-TLV is received with the Anomalous bit set when previously 242 it was clear, the list of interested TE tunnels must be scanned. 243 Each such TE tunnel should either have its continued compliance 244 verified, be switched to a hot standby, or do a make-before-break to 245 a secondary path. 247 2.3.3. Links leaving the Anomalous State 249 When a link leaves the Anomalous state with respect to a parameter, 250 this can serve as an indication that those TE tunnels, whose LSPs 251 were changed when the link entered the Anomalous state, may want to 252 reoptimize to a better path. 254 3. IANA Considerations 256 This document includes no request to IANA. 258 4. Security Considerations 260 This document is not currently believed to introduce new security 261 concerns. 263 5. References 265 5.1. Normative References 267 [I-D.ietf-ospf-te-metric-extensions] 268 Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 269 Previdi, "OSPF Traffic Engineering (TE) Metric 270 Extensions", draft-ietf-ospf-te-metric-extensions-02 (work 271 in progress), December 2012. 273 [I-D.previdi-isis-te-metric-extensions] 274 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 275 A., and C. Filsfils, "IS-IS Traffic Engineering (TE) 276 Metric Extensions", 277 draft-previdi-isis-te-metric-extensions-02 (work in 278 progress), October 2012. 280 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 281 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 282 Tunnels", RFC 3209, December 2001. 284 5.2. Informative References 286 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 287 J., Courtney, W., Davari, S., Firoiu, V., and D. 288 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 289 Behavior)", RFC 3246, March 2002. 291 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 292 Ayyangarps, "Encoding of Attributes for MPLS LSP 293 Establishment Using Resource Reservation Protocol Traffic 294 Engineering (RSVP-TE)", RFC 5420, February 2009. 296 Authors' Addresses 298 Alia Atlas 299 Juniper Networks 300 10 Technology Park Drive 301 Westford, MA 01886 302 USA 304 Email: akatlas@juniper.net 306 John Drake 307 Juniper Networks 308 1194 N. Mathilda Ave. 309 Sunnyvale, CA 94089 310 USA 312 Email: jdrake@juniper.net 314 Spencer Giacalone 315 Thomson Reuters 316 195 Broadway 317 New York, NY 10007 318 USA 320 Email: Spencer.giacalone@thomsonreuters.com 321 Dave Ward 322 Cisco Systems 323 170 West Tasman Dr. 324 San Jose, CA 95134 325 USA 327 Email: dward@cisco.com 329 Stefano Previdi 330 Cisco Systems 331 Via Del Serafico 200 332 Rome 00142 333 Italy 335 Email: sprevidi@cisco.com 337 Clarence Filsfils 338 Cisco Systems 339 Brussels 340 Belgium 342 Email: cfilsfil@cisco.com