idnits 2.17.00 (12 Aug 2021) /tmp/idnits42827/draft-fuxh-mpls-delay-loss-te-problem-statement-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 166 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As defined in section 2.2. , the estimation interval for the performance parameters is assumed to be on the order of minutes. The solution MUST not impact stability nor significantly increase convergence time if performance parameters change over a timeframe on the order of minutes. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If performance sensitive re-routing is implemented, and revertive behavior to a preferred LSP is supported, then the preferred LSP MUST not be released. When the end-to-end performance of the preferred LSP becomes acceptable, the service is restored to this preferred LSP. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If performance sensitive re-routing is implemented, and end-to-end measurements of the LSP performance are made, then the LSP requestor is able to request path placement for a performance sensitive LSP using the previously stated requirements. Since a threshold crossing of the end-to-end performance measurement may or may not correspond to a change in the concatenated performance parameter estimates, making any automatic decision on this basis MUST not create instability. -- The document date (October 15, 2012) is 3498 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T Y.1540' is mentioned on line 218, but not defined == Missing Reference: 'ITU-T Y.1541' is mentioned on line 225, but not defined == Missing Reference: 'RFC 6374' is mentioned on line 322, but not defined == Missing Reference: 'RFC 3209' is mentioned on line 415, but not defined == Unused Reference: 'CL-UC' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'CL-FW' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 678, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-rtgwg-cl-use-cases-01 == Outdated reference: draft-ietf-rtgwg-cl-requirement has been published as RFC 7226 == Outdated reference: draft-ietf-mpls-tp-use-cases-and-design has been published as RFC 6965 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group X. Fu(Ed.), M. Betts, Q. 2 Wang 3 Internet Draft ZTE 4 Intended Status: Informational V. Manral 5 Expires: April 14, 2013 Hewlett-Packard Corp. 6 D. McDysan(Ed.), A. Malis 7 Verizon 8 S. Giacalone 9 Thomson Reuters 10 J. Drake 11 Juniper Networks 13 October 15, 2012 15 Delay and Loss Traffic Engineering Problem Statement for MPLS 17 draft-fuxh-mpls-delay-loss-te-problem-statement-01 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other groups 26 may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on February 27, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the document 44 authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 47 Relating to IETF Documents (http://trustee.ietf.org/license-info) in 48 effect on the date of publication of this document. Please review these 49 documents carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this document 51 must include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Abstract 57 Deployment and usage of cloud based applications and services that use 58 an underlying MPLS network are expanding and an increasing number of 59 applications are extremely sensitive to delay and packet loss. 60 Furthermore, in cloud computing an additional decision problem arises of 61 simultaneously choosing the data center to host applications along with 62 MPLS network connectivity such that the overall performance of the 63 application is met. Mechanisms exist to measure and monitor MPLS path 64 performance parameters for packet loss and delay, but the mechanisms 65 work only after the path has been setup. The cloud-based and performance 66 sensitive applications would benefit from measurement of MPLS network 67 and potential path information that would be provided for use in the 68 computation before LSP setup and then the selection of LSPs. 70 This document provides a statement of problems faced by these cloud 71 based and performance sensitive applications and describes requirements 72 to enable the efficient and accurate measurement of the MPLS network. 73 This also allows new performance parameters to be reported and used in 74 the computation of MPLS services in support of these cloud based and 75 performance sensitive applications. 77 Table of Contents 79 1. Introduction...................................................3 80 1.1. Scope.....................................................3 81 2. Conventions used in this document..............................3 82 2.1. Acronyms..................................................3 83 2.2. Terminology and Assumptions...............................4 84 2.2.1. Delay................................................4 85 2.2.2. Packet Loss..........................................4 86 2.2.3. Packet Delay Variation...............................5 87 3. Motivation and Background......................................5 88 3.1. General Characteristics of Performance Parameters.........5 89 3.2. Use Cases for Performance Parameter Sensitive LSP Placement5 90 4. Problem Statement..............................................6 91 4.1. End-to-end Measurement Insufficient for Performance Sensitive 92 LSP Path Selection.............................................6 93 4.2. Lower Layer MPLS Networks Unable to Communicate Significant 94 Performance Changes............................................7 95 4.3. No Method to Communicate Significant Node/Link Performance 96 Changes........................................................7 97 4.4. Routing Metrics Insufficient for Performance Sensitive Path 98 Selection......................................................7 99 4.5. LSP Signaling Methods Insufficient for Performance Sensitive 100 Path Selection.................................................8 101 5. Functional Requirements........................................8 102 5.1. Augment LSP Requestor Signaling with Performance Parameter 103 Values.........................................................8 104 5.2. Specify Criteria for Node and Link Performance Parameter 105 Estimation, Measurement Methods................................9 106 5.3. Support Node Level Performance Information when Needed....9 107 5.4. Augment Routing Information with Performance Parameter Estimates 108 ..............................................................10 109 5.5. Augment Signaling Information with Concatenated Estimates10 110 5.6. Define Significant Performance Parameter Change Thresholds and 111 Frequency.....................................................10 112 5.7. Define Thresholds and Timers for Links with Unusable Performance 113 ..............................................................11 114 5.8. Communicate Significant Performance Changes between Layers11 115 5.9. The above requirement applies to layering with different 116 technologies (e.g., MPLS over OTN) or to different levels within the 117 same technology (e.g., hierarchical LSPs).....................11 118 5.10. Support for Networks with Composite Link................11 119 5.11. Restoration, Protection and Rerouting...................11 120 5.12. Management and Operational Requirements.................12 121 6. IANA Considerations...........................................12 122 7. Security Considerations.......................................12 123 8. References....................................................12 124 8.1. Normative References.....................................12 125 8.2. Informative References...................................12 126 9. Acknowledgments...............................................13 128 1. Introduction 130 This draft is one of two created from draft-fuxh-mpls-delay-loss-te- 131 framework-05 in response to comments from an MPLS Review Team (RT). This 132 draft focuses on a problem statement and requirements, for delay and 133 loss based Traffic Engineering for MPLS networks. A peer document 134 focuses on the framework. 136 The intent of this document is to focus on stating the technical aspects 137 of the application oriented problems to be solved and specific 138 requirements targeted to solve these problems. 140 It describes requirements and application needs for bounded values of 141 delay, packet loss and delay variation. 143 1.1. Scope 145 A (G)MPLS network may have multiple layers of packet, TDM and/or optical 146 network technology and an important objective is to make a prediction of 147 end-to-end delay, loss and delay variation based upon the current state 148 of this network with acceptable accuracy before an LSP is established. 150 The (G)MPLS network may cover a single IGP area/level, may be a 151 hierarchical IGP under control of a single administrator, or may involve 152 multiple domains under control of multiple administrators. 154 2. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC-2119 [RFC2119]. 160 2.1. Acronyms 162 SLA Service Level Agreement 164 SLS Service Level Specification 165 NPO Network Performance Objective 167 2.2. Terminology and Assumptions 169 A Service Level Agreement (SLA) is a contractual agreement that service 170 providers have with customers for services comprised of numerical values 171 for performance measures; for example, delay, loss and delay variation. 172 Additionally, network operators may have Service Level Specification 173 (SLS) that is for internal use by the operator. See [ITU-T.Y.1540], 174 [ITU-T.Y.1541], RFC 3809, Section 4.9 [RFC3809] for examples of the form 175 of such SLA and SLS specifications. 177 Network Performance Objective (NPO) is defined in section 5 of [ITU- 178 T.Y.1541] in terms of numerical values for performance measures, 179 principally delay, loss, and delay variation. The term NPO is used in 180 this document since the SLA and SLS measures have network operator and 181 service specific implications. Furthermore, the NPO measures are 182 sufficiently well defined to address other use cases and the stated 183 problems. 185 Of particular interest is the composition methods defined in Y.1541 for 186 estimating performance parameters of candidate LSP paths based upon the 187 performance parameter estimates/measurements of individual nodes and 188 links. 190 This document assumes that the evaluation interval for a performance 191 parameter is on the order of minutes as stated in [ITU-T Y.1541, 5.3.2], 192 which is the same of that used in some commercial networks. 194 2.2.1. Delay 196 Section 6.2.1 of [ITU-T Y.1540] defines mean IP Packet Transfer Delay 197 (IPTD) as the arithmetic average of the one-way delay observed between 198 measurement points IPTD is referred to as "delay" in this document. 200 Section 8.2.1 of [ITU-T Y.1541] defines composition of the IPTD UNI-UNI 201 performance parameter as "the mean IP packet transfer delay (IPTD) 202 performance parameter, the UNI-UNI performance is the sum of the means 203 contributed by network sections." 205 2.2.2. Packet Loss 207 Section 6.4 of [ITU-T Y.1540] defines IP Packet Loss Ratio (IPLR) as the 208 "ratio of total lost IP packet outcomes to total transmitted IP packets 209 in a population of interest," which is referred to as "loss" in this 210 document. 212 Section 8.2.2 of [ITU-T Y.1541] defines composition of the IPLR UNI-UNI 213 performance parameter as "may be estimated by inverting the probability 214 of successful packet transfer across n network sections." 216 2.2.3. Packet Delay Variation 218 Section 6.2.4.2 of [ITU-T Y.1540] defines quantile-based limits on IP 219 Packet Delay Variation (IPDV), which is referred to as "delay variation" 220 in this document. 222 Section 8.2.4 of [ITU-T Y.1541] defines composition of the IPDV UNI-UNI 223 performance parameter as "must recognize their sub-additive nature and 224 it is difficult to estimate accurately without considerable information 225 about the individual delay distributions." Appendix IV of [ITU-T Y.1541] 226 gives several examples of IPDV estimate calculations. 228 3. Motivation and Background 230 3.1. General Characteristics of Performance Parameters 232 In general, nodes and links contribute to the performance parameters in 233 the network.Another significant contributor is that of the host stack, 234 but that is outside the scope of this document. 236 For many applications, the delay NPO is very important. In networks with 237 wide geographic separation, propagation delay may dominate delay, while 238 in local or metro networks nodal delay may become important. 240 Some link technologies (e.g., wireless, wifi, satellite) may have packet 241 loss characteristics inherently different from those of other link 242 technologies(e.g., fiber optic, cable) networks. Packet loss can be 243 caused due to signal degradation/ high noise, which causes corrupted 244 packets which in turn are discarded in the network. Furthermore, the 245 loading of queues (congestion) may also result in packet loss. 247 Delay variation (sometimes also referred to as packet jitter) is 248 important to some applications, such as interactive voice, video and/or 249 multimedia communication, gaming, and simulations. If delay varies too 250 much, then a playback buffer for such applications may underflow or 251 overflow, resulting in a disruption to the application. Delay variation 252 is caused primarily by queuing within a node. It can also be caused when 253 packets take different paths, due to lower layer routing. 255 3.2. Use Cases for Performance Parameter Sensitive LSP Placement 257 In High Frequency trading for Electronic Financial markets, computers 258 make decisions based on the Electronic Data received, without human 259 intervention. These trades now account for a majority of the trading 260 volumes and rely exclusively on ultra-low-delay direct market access. 261 In certain networks, such as financial information networks (e.g. stock 262 market data providers), network performance information (e.g. delay) is 263 critical to data path selection. In these networks, extremely large 264 amounts of money rest on the ability to access market data as quickly as 265 possible and to predictably make trades faster than the competition. 266 Using metrics such as hop count or link cost as routing may not always 267 meet this need. In such networks it would be beneficial to be able to 268 make path selection decisions based on performance data (such as delay) 269 in a cost-effective and scalable way. 271 In other networks, for example, network-based VPNs there are in place 272 between a customer and a provider a Service Level Agreement (SLA) which 273 specifies performance objectives, such as delay, loss, and delay 274 variation. In some cases these performance objectives are defined 275 between specific customer locations. Furthermore, packets may be 276 associated with certain classes as identified by packet header fields 277 (e.g., IP DSCP, IEEE P-bits, MPLS TC bits) that are associated with 278 different performance objectives. In these types of networks, the 279 objective is to provide service that is no worse than the performance 280 objective. A single SLA may support many customers of the same type. 281 There is also a need to support specific SLAs, typically for very large 282 customers who demand premium performance for which they are willing to 283 pay a premium price. 285 In emerging cloud-based services, an additional decision problem where 286 the application may be placed in a choice of more than one data center 287 and the (G)MPLS network connectivity may also be chosen [CLO, CSO]. In 288 these types of applications, the objective so to meet the overall 289 performance of the application deployed in one more or more data 290 centers. The performance of the intra- data center performance 291 component is out of scope of this draft, but this overall cloud plus 292 networking decision problem would benefit from a prediction of the MPLS 293 network performance as part of path establishment. 295 4. Problem Statement 297 With the use cases in the previous section as motivation, there are 298 several technical problems that currently standardized IETF protocols do 299 not adequately address: 301 o End-to-end Measurement Insufficient for Performance Sensitive LSP 302 Path 304 o Routing Metrics Insufficient for Performance Sensitive Path Selection 306 o LSP Signaling Methods Insufficient for Performance Sensitive Path 307 Selection 309 o Lower Layer MPLS Networks Unable to Communicate Significant 310 Performance Changes 312 o No Method to Communicate Significant Node/Link Performance Changes 314 The following sections expand on each of these technical problem areas 315 in more detail. Although some of the problem statements are made in 316 terms of existing/proposed protocols, there is no intention to imply 317 that the solution requires a revision to these protocols. 319 4.1. End-to-end Measurement Insufficient for Performance Sensitive LSP Path 320 Selection 322 Methods exist to measure established LSP performance, e.g., [RFC 6374] 323 for MPLS-TP, and are most useful in verifying support for an NPO. RFC 324 6374 specifies a mechanism to measure and monitor performance parameters 325 for packet loss, and one-way and two-way delay, delay variation and 326 throughput. However, if measured performance is not met for an LSP there 327 is not a standardized method to aid in an LSP originator or a proxy 328 (e.g., PCE) to select a modified path that would meet the performance 329 objective. 331 Therefore, there is a need to enable path computation that has access to 332 an up to date recent performance estimate. 334 4.2. Lower Layer MPLS Networks Unable to Communicate Significant 335 Performance Changes 337 Historically, when an IP/MPLS network was operated over a lower layer 338 circuit switched network (e.g., SONET rings), a change in delay caused 339 by the lower layer network (e.g., due to a maintenance action or 340 failure) this was not known to the MPLS network. This resulted in delay 341 affecting end user experience, sometimes violating NPO, SLS and/or SLA 342 values and/or resulting in user complaints. 344 Using lower layer networks to provide restoration and grooming may be 345 more efficient than performing packet only restoration, but the 346 inability to communicate performance parameters, in particular delay, 347 from the lower layer network to the higher layer network is an important 348 problem to be solved in not only the composite link case [CL-REQ, 349 section 4.2], but also in the case of single links connecting nodes. 351 In summary, Multi-layer GMPLS networks do not have a means to 352 communicate a significant change in performance (e.g., delay) from one 353 layer to another. 355 4.3. No Method to Communicate Significant Node/Link Performance Changes 357 Performance characteristics of links and nodes may change dynamically in 358 response to a number of events. There is currently no way to 359 automatically indicate which nodes and/or links have had significant 360 performance changes to LSP originators or proxies so that they can 361 attempt to recompute and signal a path that would meet the LSP 362 performance objective. 364 4.4. Routing Metrics Insufficient for Performance Sensitive Path Selection 366 Optimization on a single metric does not meet the needs for all cases of 367 performance sensitive path selection. In some cases, minimizing delay 368 relates directly to the best customer experience (e.g., in TCP closer is 369 faster or in financial trading the absolute minimum delay possible 370 provides a competitive advantage). In other cases, user experience is 371 relatively insensitive to delay, up to a specific limit at which point 372 user perception of quality degrades significantly (e.g., interactive 373 human voice and multimedia conferencing). A number of NPOs have a bound 374 on point-point delay, and as long as this bound is met, the NPO is met - 375 - decreasing the delay is not necessary. In some NPOs, if the specified 376 delay is not met, the user considers the service as unavailable. An 377 unprotected LSP can be manually provisioned on a set of links to meet 378 this type of NPO, but this lowers availability since an alternate route 379 that meets the delay NPO cannot be determined. 381 One operational approach is to provision IP/MPLS networks over 382 unprotected circuits and set the metric and/or TE-metric proportional to 383 delay. This resulted in traffic being directed over the least delay 384 path, even if this was not needed to meet an NPO or user experience 385 objectives. This results in reduced flexibility and increased cost for 386 network operators. However, the (TE) metric is often used to represent 387 other information, such as link speed, economic cost or in support of 388 ECMP (as described below) and may not be able to be set to be 389 proportional to delay. Furthermore, if performance metrics such as loss 390 and delay variation are to be supported in path selection, then 391 proportional mapping is not possible. 393 Link attributes and LSP affinities [RFC 3209] can be used operationally 394 to encode some information regarding performance, for example, 395 indicating wired versus wireless, satellite versus terrestrial, etc. 396 However, these attributes/affinities are used to encode other attributes 397 and the 32 bit format is limiting in terms of numerical representation 398 of performance objective parameters. 400 Another operational approach is to set (TE) metrics to (nearly) the same 401 value so that LSPs are placed across multiple links using Equal Cost 402 Multi-Path (ECMP) path selection. However, these parallel links may 403 have markedly different performance characteristics (e.g., delay) and 404 choice of a link that meets the performance objective is needed [CL-REQ, 405 section 4.3]. 407 IGP link and TE metrics are not sufficient to support performance 408 sensitive path selection in a single IGP area/level [EXPRESS-PATH]. 410 4.5. LSP Signaling Methods Insufficient for Performance Sensitive Path 411 Selection 413 Current signaling approaches do not support inter area/level or inter- 414 domain performance sensitive path selection. There is no standard for 415 setting link attributes and LSP resource affinities [RFC 3209] between 416 administrative domains, and since these have been used within some 417 domains they are not a viable candidate to solve the aforementioned 418 problems in this context. Augmenting an IGP with performance information 419 does not solve the problem in these cases. 421 What is needed is a means for the originator/proxy of an LSP to confirm 422 whether the estimated performance of a computed LSP path will meet the 423 performance objective. 425 5. Functional Requirements 427 This section groups functional requirements intended to address the 428 problems stated in the previous section into related areas. 430 5.1. Augment LSP Requestor Signaling with Performance Parameter Values 432 The solution needs to provide a means for an LSP requestor to signal 433 performance parameter sensitive paths. The following requirements state 434 the types of requests that are required. 436 The solution MUST provide a means to indicate which performance 437 parameters are supported by the network area/level or domain. 439 The solution MUST provide a means for the LSP requestor to ask for the 440 minimum possible value for each supported performance parameter. 442 For example, an LSP requestor may ask for an LSP that has the minimum 443 possible value of delay. 445 The solution MUST provide a means for the LSP requestor to ask for a 446 range of acceptable values for each supported performance parameter. 448 For example, an LSP requestor may ask for an LSP that has performance 449 between a minimum value of delay and packet loss and a maximum value of 450 delay and packet. 452 5.2. Specify Criteria for Node and Link Performance Parameter Estimation, 453 Measurement Methods 455 The solution MUST provide a means to configure the one-way link and node 456 performance parameters for delay, loss and delay variation. 458 The solution SHOULD provide a means to dynamically measure and/or 459 estimate the one-way link and node performance parameters for delay, 460 loss and delay variation. 462 As defined in section 2.2. , the estimation interval for the performance 463 parameters is assumed to be on the order of minutes. The solution MUST 464 not impact stability nor significantly increase convergence time if 465 performance parameters change over a timeframe on the order of minutes. 467 5.3. Support Node Level Performance Information when Needed 469 There are several scenarios under which node-related performance 470 parameters (delay, loss, delay variation) has a different level of 471 importance: 473 1. The case of few nodes with large geographic separation, (e.g.,trans- 474 oceanic), where link delay alone would be a good approximation. 476 2. The case of many nodes with small geographic separation (e.g., 477 interconnected nearby data centers) where node/device delay is very 478 important but link delay may be negligible. 480 3. The case of some number of nodes with medium geographic separation, 481 where usage of both link and node delay may be desirable. 483 The intent in case 1 is to measure the predominant delay in uncongested 484 service provider networks, where geographic delay dominates and is on 485 the order of milliseconds or more. The argument in cases 2 and 3 for 486 including node-level queuing performance parameters is that it better 487 represents the performance experienced by applications. The argument 488 against including queuing related performance parameters is that it if 489 used in routing decisions it can result in routing instability. This 490 tradeoff is discussed in detail in [CL-FW, Section 4.1.1]. 492 The solution MUST define methods to include node level performance 493 estimate information to routing protocols. 495 The solution MUST define methods to include node level performance 496 estimate information to signaling protocols. 498 A specific deployment of the solution MAY choose to not use the node 499 level performance estimates. 501 5.4. Augment Routing Information with Performance Parameter Estimates 503 The solution MUST provide a means to communicate performance parameters 504 of both links and nodes as an estimate for use in performance sensitive 505 LSP path selection within nodes of a single IGP area/level. 507 The solution SHOULD provide a means to communicate delay, loss and delay 508 variation of links and nodes as a traffic engineering performance 509 parameter for use in performance sensitive LSP path selection across a 510 set of nodes in a hierarchy of IGP areas/levels. 512 5.5. Augment Signaling Information with Concatenated Estimates 514 The solution MUST provide a means to signal concatenated performance 515 parameter estimates for both links and nodes as an estimate for use in 516 performance sensitive LSP path selection traversing two or more separate 517 administrative domains. See the terminology section for references on 518 the concatenation method for specific performance parameters. 520 For example, the solution needs to support the capability to compute a 521 route with X amount of bandwidth with less than Y ms of delay and less 522 than Z% loss across multiple domains. 524 The solution MUST support the means to concatenate performance parameter 525 estimates and report this for each traversed domain on the end-end path 527 The solution MUST interoperate with existing path selection and 528 signaling methods traversing multiple domains. 530 5.6. Define Significant Performance Parameter Change Thresholds and 531 Frequency 533 Delay, loss and delay variation measurements and/or estimates may be 534 time varying. The solution MUST provide a means to control the 535 advertisement rate of performance parameter estimates to avoid 536 instability. 538 Any automatic LSP routing and/or load balancing solutions MUST NOT 539 oscillate such that performance observed by users changes such that an 540 NPO is violated. Since oscillation may cause reordering, there MUST be 541 means to control the frequency of changing the path over which an LSP is 542 placed. 544 5.7. Define Thresholds and Timers for Links with Unusable Performance 546 The solution MUST provide a means to configure a performance parameter 547 threshold which defines placement of a node or link into an unusable 548 state. The solution MUST provide a means to configure a performance 549 parameter threshold which defines transition of a node or a link from an 550 unusable state to a useable state. The solution MUST provide a means to 551 control the minimum transition time between these states. 553 This unusable state is intended to operate on a link/node capability 554 basis and not a global basis. Since state transition conditions are 555 locally configured, all routers within a domain should synchronize this 556 configuration value. 558 With current TE protocols, a refreshed LSP would use the most recent 559 performance parameter estimates and may be rerouted based upon nodes or 560 links being placed in an unusable performance state. Section 5.11. 561 defines requirements for a desirable function where performance 562 sensitive LSP re-routing would occur. 564 5.8. Communicate Significant Performance Changes between Layers 566 In order to support network NPOs and provide acceptable user experience, 567 the solution MUST specify a protocol means to allow a lower layer server 568 network to communicate performance parameters (e.g., delay, loss, delay 569 variation) to the higher layer client network. 571 5.9. The above requirement applies to layering with different technologies 572 (e.g., MPLS over OTN) or to different levels within the same technology 573 (e.g., hierarchical LSPs). 575 5.10. Support for Networks with Composite Link 577 An LSP may traverse a network with Composite Links [CL-REQ]. The 578 solution's selection of performance sensitive paths SHOULD be compatible 579 with the general availability, stability and transient response 580 requirements of [CL-REQ, Section 4.1]. 582 When an LSP traverses a network with composite links that has component 583 links provided by lower layer networks, the solution MUST interoperate 584 with the requirements [CL-REQ, Section 4.2]. 586 When an LSP traverses a network with composite links that has parallel 587 component links with different characteristics, the solution MUST 588 interoperate with the requirements [CL-REQ, Section 4.3]. 590 5.11. Restoration, Protection and Rerouting 592 The ability to re-route an LSP if one or more NPO objectives are not met 593 is highly desirable. The solution SHOULD support the capability to 594 configure an LSP as capable of implementing performance sensitive re- 595 routing, as detailed in the following conditional requirements. 597 If performance sensitive re-routing is implemented, the solution MUST 598 provide a means to configure performance parameter threshold crossing 599 and time values. 601 If performance sensitive re-routing is implemented, the solution MUST 602 support a configuration option to move an end-to-end LSP away from any 603 link or node whose performance violates the configured threshold. 605 If implemented, the solution MUST provide a means to control the 606 frequency of LSP rerouting to avoid instability. 608 If performance sensitive re-routing is implemented, and revertive 609 behavior to a preferred LSP is supported, then the preferred LSP MUST 610 not be released. When the end-to-end performance of the preferred LSP 611 becomes acceptable, the service is restored to this preferred LSP. 613 The delay performance of pre-defined protection or dynamic reroutable 614 LSP MUST be defined by the solution in terms of the maximum acceptable 615 delay difference between the primary and protection/restoration path 616 MUST be specifiable in the solution. For example, [MPLS-TP-USE-CASE] 617 defines a Relative Delay Time which is the difference of the Absolute 618 Delay between the primary and protection path. 620 5.12. Management and Operational Requirements 622 Existing management and diagnostic protocols MUST be able to operate 623 over networks supporting performance sensitive LSP placement. 625 If performance sensitive re-routing is implemented, and end-to-end 626 measurements of the LSP performance are made, then the LSP requestor is 627 able to request path placement for a performance sensitive LSP using the 628 previously stated requirements. Since a threshold crossing of the end- 629 to-end performance measurement may or may not correspond to a change in 630 the concatenated performance parameter estimates, making any automatic 631 decision on this basis MUST not create instability. 633 6. IANA Considerations 635 No new IANA consideration are raised by this document. 637 7. Security Considerations 639 This document raises no new security issues. 641 8. References 643 8.1. Normative References 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 8.2. Informative References 650 [CL-UC] C. Villamizer et al, "Composite Link Use Cases and Design 651 Considerations," draft-ietf-rtgwg-cl-use-cases-01 653 [CL-REQ] C. Villamizar et al, "Requirements for MPLS Over a Composite 654 Link", draft-ietf-rtgwg-cl-requirement-08 . 656 [CL-FW] C. Villamizar et al, "Composite Link Framework in Multi Protocol 657 Label Switching (MPLS)", work in progress 659 [ITU-T.Y.1540] ITU-T, "Internet protocol data communication service - IP 660 packet transfer and availability performance parameters", 661 2011, . 663 [ITU-T.Y.1541] ITU-T, "Network performance objectives for IP-based 664 services", 2011, . 666 [RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned 667 Virtual Private Networks (PPVPN)", RFC 3809, June 2004. 669 [CLO] Young Lee et al, "Problem Statement for Cross-Layer 670 Optimization," work in progress. 672 [CSO] Greg Bernstein, Young Lee, "Cross Stratum Optimization Use- 673 cases," work in progress. 675 [EXPRESS-PATH] A. Atlas, "Performance-based Path Selection for 676 Explicitly Routed LSPs", work in progress. 678 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and 679 G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 680 3209, December 2001. 682 [MPLS-TP-USE-CASE] L. Fang, "MPLS-TP Applicability; Use Cases and 683 Design", draft-ietf-mpls-tp-use-cases-and-design-01 . 685 9. Acknowledgments 687 This document was prepared using 2-Word-v2.0.template.dot. 689 The authors would like to thank the MPLS Review Team of Stewart Bryant, 690 Daniel King and He Jia for their many helpful comments suggestions in 691 July 2012. 693 Copyright (c) 2012 IETF Trust and the persons identified as authors of 694 the code. All rights reserved. 696 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 697 IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 698 TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 699 PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER 700 OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 701 EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 702 PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 703 PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 704 LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 705 NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 706 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 708 This code was derived from IETF RFC [insert RFC number]. Please 709 reproduce this note if possible. 711 Authors' Addresses 713 Xihua Fu 714 ZTE 715 Email: fu.xihua@zte.com.cn 717 Vishwas Manral 718 Hewlett-Packard Corp. 719 191111 Pruneridge Ave. 720 Cupertino, CA 95014 721 US 722 Phone: 408-447-1497 723 Email: vishwas.manral@hp.com 725 Dave McDysan 726 Verizon 727 Email: dave.mcdysan@verizon.com 729 Andrew Malis 730 Verizon 731 Email: andrew.g.malis@verizon.com 733 Spencer Giacalone 734 Thomson Reuters 735 195 Broadway 736 New York, NY 10007 737 US 738 Phone: 646-822-3000 739 Email: spencer.giacalone@thomsonreuters.com 741 Malcolm Betts 742 ZTE 743 Email: malcolm.betts@zte.com.cn 745 Qilei Wang 746 ZTE 747 Email: wang.qilei@zte.com.cn 749 John Drake 750 Juniper Networks 751 Email: jdrake@juniper.net