idnits 2.17.1 draft-atlas-mpls-te-express-path-00.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 89: '... 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 (October 24, 2011) is 4566 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5420' is defined on line 289, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-previdi-isis-te-metric-extensions-00 Summary: 1 error (**), 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 D. Ward 5 Expires: April 26, 2012 Juniper Networks 6 S. Giacalone 7 Thomson Reuters 8 S. Previdi 9 C. Filsfils 10 Cisco Systems 11 October 24, 2011 13 Performance-based Path Selection for Explicitly Routed LSPs 14 draft-atlas-mpls-te-express-path-00 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 April 26, 2012. 43 Copyright Notice 45 Copyright (c) 2011 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.giacalone-ospf-te-express-path] 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]. 70 The path selection mechanisms described in this document apply to 71 paths that are fully computed by the head-end of the LSP and then 72 signaled in an ERO where every sub-object is strict. This allows the 73 head-end to consider IGP-distributed performance data without 74 requiring the ability to signal the performance constraints in an 75 object of the RSVP Path message. 77 When considering performance-based data, it is obvious that there are 78 additional contributors beyond just the links. Clearly end-to-end 79 latency is a combination of router latency, queuing latency, physical 80 link latency and other factors. However, if application traffic 81 requires paths to be selected based upon latency constraints, the 82 same traffic might be in an Expedited Forwarding Per-Hop- 83 Behavior[RFC3246] with minimal queuing delay or another PHB with 84 known maximal per-hop queuing delay. While traversing a router can 85 cause delay, that can be included in the advertised link delay. 87 This document does not specify how a router determines what values to 88 advertise by the IGP. However, the end-to-end performance that is 89 computed for an LSP path SHOULD be built from the individual link 90 data. Any end-to-end characterization used to determine an LSP's 91 performance compliance should be fully reflected in the Traffic 92 Engineering Database so that a CSPF calculation can also determine 93 whether a path under consideration would be in compliance. 95 1.1. Basic Requirements 97 The following are the requirements that motivate this solution. 99 1. Select a TE tunnel's path based upon a combination of existing 100 constraints as well as on link-latency, packet loss, jitter, link 101 SLA conformance, and bandwidth consumed by non-RSVP-TE traffic. 103 2. Ability to define different end-to-end performance requirements 104 for each TE tunnel regardless of common use of resources. 106 3. Ability to periodically verify that a TE tunnel's current LSP 107 complies with its configured end-to-end perforance requirements. 109 4. Ability to move tunnels, using make-before-break, based upon 110 computed end-to-end performance complying with configuration 112 5. Ability to move tunnels away from any link that is violating an 113 underlying SLA 115 6. Ability to optionally avoid setting up tunnels using any link 116 that is violating an SLA, regardless of whether end-to-end 117 performance would still meet requirements. 119 7. Ability to revert back to the best path after a configurable 120 period. 122 2. Using Performance Data Constraints 124 2.1. End-to-End Constraints 126 The per-link performance data available in the IGP 127 [I-D.giacalone-ospf-te-express-path] 128 [I-D.previdi-isis-te-metric-extensions] includes: unidirectional link 129 delay, unidirectional delay variation, and link loss. Each (or all) 130 of these parameters can be used to create the path-level link-based 131 parameter. 133 While it has been possible to compute a CSPF where the link latency 134 values are used instead of TE metrics, this results in ignoring the 135 TE metrics and causing LSPs to prefer the lowest-latency paths. 136 Instead of this approach to minimize path latency, an end-to-end 137 latency bound merely requires that the path computed be no more than 138 that bound without being the minimum. This bound can be used as a 139 constraint in CSPF to prevent exploring links that would create a 140 path over the end-to-end latency bound. 142 This is illustrated as follows. Let the LSP have an end-to-end 143 latency bound of 20ms. Assume that the path to node X has been 144 minimized and its latency is 12ms. When X's links are to be 145 explored, the link X<->Y has a link latency of 5ms and the link X<->Z 146 has a link latency of 9ms. The path via X to Y along link X<->Y 147 would have a path latency of 12ms + 5ms = 17ms < 20ms; therefore, the 148 link X<->Y can be explored. In contrast, reaching Z via link X<->Z 149 would result in a path latency of 12ms + 9ms = 21ms > 20ms; therefore 150 the link X<->Z would not be explored in the CSPF. 152 An end-to-end bound on delay variation can be used similarly as a 153 constraint in the CSPF on what links to explore where the path's 154 delay variation is the sum of the used links' delay variations. 156 For link loss, the path loss is not the sum of the used links' 157 losses. Instead, the path loss percentage is (100 - loss_L1)*(100 - 158 loss_L2)*...*(100 - loss_Ln), where the links along the path are L1 159 to Ln. The end-to-end link loss bound, computed in this fashion, can 160 also be used as a constraint in the CSPF on what links to explore. 162 2.2. Link Constraints 164 In addition to selecting paths that conform to a bound on performance 165 data, it is also useful to avoid using links that do not meet a 166 necessary constraint. Naturally, if such a parameter were a known 167 fixed value, then resource attribute flags could be used to express 168 this behavior. However, when the parameter associated with a link 169 may vary dynamically, there is not currently a configuration-time 170 mechanism to enforce such behavior. An example of this is described 171 in Section 2.3, where links may move in and out of SLA-conformance 172 with regards to latency, delay variation, and link loss. 174 When doing path selection for TE tunnels, it has not been possible to 175 know how much actual bandwidth is available that inludes the 176 bandwidth used by non-RSVP-TE traffic. In 177 [I-D.giacalone-ospf-te-express-path] 178 [I-D.previdi-isis-te-metric-extensions], the Unidirectional Available 179 Bandwidth is advertised as is the Residual Bandwidth. When computing 180 the path for a TE tunnel, only links with at least a configurable 181 amount of Unidirectional Available Bandwidth might be permitted. 183 Similarly, only links whose loss is under a configurable value might 184 be acceptable. For these constraints, each link can be tested 185 against the constraint and only explored in the CSPF if the link 186 passes. In essence, a link that fails the constraint test is treated 187 as if it contained a resource attribute in the exclude-any filter. 189 2.3. Links out of SLA 191 Link conformance to an SLA can change as a result of rerouting at 192 lower layers. This could be due to optical regrooming or simply 193 rerouting of a FA-LSP. When this occurs, there are three questions 194 to be asked: 196 a. Should the link be trusted and used for the setup of new LSPs? 198 b. Should LSPs using this link be immediately verified for continued 199 compliance to their end-to-end constraints? 201 c. Should LSPs using this link automatically be moved to a secondary 202 path? 204 2.3.1. Use of Anomalous Links for New Paths 206 If the answer to (a) is no for latency SLAs, then any link which has 207 the Anomalous bit set in the Unidirectional Link Delay sub- 208 TLV[I-D.giacalone-ospf-te-express-path] 209 [I-D.previdi-isis-te-metric-extensions] should be removed from the 210 topology before a CSPF calculation is used to compute a new path. In 211 essence, the link should be treated exactly as if it fails the 212 exclude-any resource attributes filter.[RFC3209]. 214 Similarly, if the answer to (a) is no for link loss SLAs, then any 215 link which has the Anomalous bit set in the Link Los sub-TLV should 216 be treated as if it fails the exclude-any resource attributes filter. 217 If the answer to (a) is no for jitter SLAs, then any link that has 218 the Anomalous bit set in the Unidirectional Delay Variation sub- 219 TLV[I-D.previdi-isis-te-metric-extensions] should be treated as if it 220 fails the exclude-any resource attributes filter. 222 2.3.2. Links entering the Anomalous State 224 When a link enters the Anomalous state with respect to a parameter, 225 this is an indication that LSPs using that link might also no longer 226 be in compliance with their performance bounds. It can also be 227 considered an indication that something is changing that link and so 228 it might no longer be trustworthy to carry performance-critical 229 traffic. Naturally, which performance criteria are important for a 230 particular LSP is dependent upon the LSP's configuration and thus the 231 SLA compliance of a link is indicated per performance criterion. 233 At the ingress of a TE tunnel, a TE tunnel may be configured to be 234 sensitive to the Anomalous state of links in reference to latency, 235 delay variation, and/or loss. Additionally, such a TE tunnel may be 236 configured to either verify continued compliance, to switch 237 immediately to a standby LSP, or to move to a different path. 239 When a sub-TLV is received with the Anomalous bit set when previously 240 it was clear, the list of interested TE tunnels must be scanned. 241 Each such TE tunnel should either have its continued compliance 242 verified, be switched to a hot standby, or do a make-before-break to 243 a secondary path. 245 2.3.3. Links leaving the Anomalous State 247 When a link leaves the Anomalous state with respect to a parameter, 248 this can serve as an indication that those TE tunnels, whose LSPs 249 were changed when the link entered the Anomalous state, may want to 250 reoptimize to a better path. 252 3. IANA Considerations 254 This document includes no request to IANA. 256 4. Security Considerations 258 This document is not currently believed to introduce new security 259 concerns. 261 5. References 263 5.1. Normative References 265 [I-D.giacalone-ospf-te-express-path] 266 Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 267 Previdi, "OSPF Traffic Engineering (TE) Express Path", 268 draft-giacalone-ospf-te-express-path-02 (work in 269 progress), September 2011. 271 [I-D.previdi-isis-te-metric-extensions] 272 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 273 A., and C. Filsfils, "IS-IS Traffic Engineering (TE) 274 Metric Extensions", 275 draft-previdi-isis-te-metric-extensions-00 (work in 276 progress), October 2011. 278 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 279 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 280 Tunnels", RFC 3209, December 2001. 282 5.2. Informative References 284 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 285 J., Courtney, W., Davari, S., Firoiu, V., and D. 286 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 287 Behavior)", RFC 3246, March 2002. 289 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 290 Ayyangarps, "Encoding of Attributes for MPLS LSP 291 Establishment Using Resource Reservation Protocol Traffic 292 Engineering (RSVP-TE)", RFC 5420, February 2009. 294 Authors' Addresses 296 Alia Atlas 297 Juniper Networks 298 10 Technology Park Drive 299 Westford, MA 01886 300 USA 302 Email: akatlas@juniper.net 304 John Drake 305 Juniper Networks 306 1194 N. Mathilda Ave. 307 Sunnyvale, CA 94089 308 USA 310 Email: jdrake@juniper.net 312 Dave Ward 313 Juniper Networks 314 1194 N. Mathilda Ave. 315 Sunnyvale, CA 94089 316 USA 318 Email: dward@juniper.net 319 Spencer Giacalone 320 Thomson Reuters 321 195 Broadway 322 New York, NY 10007 323 USA 325 Email: Spencer.giacalone@thomsonreuters.com 327 Stefano Previdi 328 Cisco Systems 329 Via Del Serafico 200 330 Rome 00142 331 Italy 333 Email: sprevidi@cisco.com 335 Clarence Filsfils 336 Cisco Systems 337 Brussels 338 Belgium 340 Email: cfilsfil@cisco.com