idnits 2.17.00 (12 Aug 2021) /tmp/idnits54828/draft-fuxh-mpls-delay-loss-rsvp-te-ext-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 3491 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DELAY-LOSS-PS' is mentioned on line 85, but not defined == Missing Reference: 'RFC5441' is mentioned on line 141, but not defined == Missing Reference: 'RFC2210' is mentioned on line 320, but not defined == Missing Reference: 'RFC5420' is mentioned on line 335, but not defined == Missing Reference: 'RFC3471' is mentioned on line 421, but not defined == Unused Reference: 'RFC3630' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'LOSS-DELAY-PS' is defined on line 670, but no explicit reference was found in the text == Outdated reference: draft-ietf-rtgwg-cl-requirement has been published as RFC 7226 == Outdated reference: A later version (-06) exists of draft-fuxh-mpls-delay-loss-te-framework-05 == Outdated reference: A later version (-04) exists of draft-atlas-mpls-te-express-path-01 == Outdated reference: A later version (-03) exists of draft-previdi-isis-te-metric-extensions-01 == Outdated reference: A later version (-01) exists of draft-fuxh-mpls-delay-loss-te-problem-statement-00 == Outdated reference: draft-ietf-ospf-te-metric-extensions has been published as RFC 7471 Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft M. Betts 4 Intended status: Standards Track Q. Wang 5 Expires: April 25, 2013 ZTE 6 D. McDysan 7 A. Malis 8 Verizon 9 V. Manral 10 Hewlett-Packard Corp. 11 October 22, 2012 13 RSVP-TE extensions for Loss and Delay Traffic Engineering 14 draft-fuxh-mpls-delay-loss-rsvp-te-ext-02 16 Abstract 18 With more and more enterprises using cloud based services, the 19 distances between the user and the applications are growing. For 20 multiple applications such as High Performance Computing and 21 Electronic Financial markets, the response times are critical as is 22 packet loss, while other applications require more throughput. For 23 example, financial or trading companies are very focused on end-to- 24 end private pipe line delay optimizations that improve things 2-3 ms. 25 Delay, jitter, loss and SLA (Service Level Agreement) are key 26 parameters that these "high value" customers use to select a private 27 pipe line provider. This document extends RSVP-TE protocol to 28 promote SLA experince of delay and packet loss application. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 25, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 65 2. Performance Accumulation and Verification . . . . . . . . . . 4 66 2.1. New RSVP ADSPEC sub-object . . . . . . . . . . . . . . . . 4 67 2.2. New RSVP SENDER_TSPEC sub-object . . . . . . . . . . . . . 6 68 2.3. New RSVP FLOWSPEC sub-object . . . . . . . . . . . . . . . 7 69 2.4. Signaling Procedures . . . . . . . . . . . . . . . . . . . 8 70 3. Performance SLA Parameters Conveying . . . . . . . . . . . . . 9 71 3.1. Performance SLA Parameters ERO sub-object . . . . . . . . 10 72 3.2. Signaling Procedure . . . . . . . . . . . . . . . . . . . 14 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 End-to-end service optimization based on delay, jitter and loss is a 83 key requirement for service provider. So communicating delay, jitter 84 and packet loss as traffic engineering performance metrics is a very 85 important requirement. [DELAY-LOSS-PS] describes the requirement of 86 delay and loss traffic engineering application. [DELAY-LOSS- 87 FRAMEWORK] describes the framework and architecture to meet 88 requirements. Delay, jitter and loss metrics are sent in IGP 89 protocol as defined in [OSPF-TE-EXPRESS-PATH] and [ISIS-TE-EXPRESS- 90 PATH]. [EXPRESS-PATH] describes how to use these traffic engineering 91 metrics to compute explicit paths at path computation entity. So 92 source node could predict end-to-end delay or loss performance before 93 an end-to-end LSP is established. 95 In the case of multi-domain (e.g., Inter-AS, Inter-Area or Multi- 96 Layer), a full path of TE LSP can't be or is not determined at the 97 ingress node of TE LSP. This is most likely to arise owing to TE 98 visibility limitations. If not all domains support to communicate 99 delay, jitter and loss as traffic engineering metric parameters, one 100 end-to-end optimized path with performance constraint (e.g., less 101 than 10 ms) may not be computed by BRPC [RFC5441] in PCE 102 architecture. 104 This document extend RSVP-TE to accumulate (e.g., sum) delay and loss 105 information of links and nodes along one LSP across multi-domain 106 (e.g., Inter-AS, Inter-Area or Multi-Layer) so that end points can 107 verify whether total amount of delay or loss could meet the agreement 108 between operator and his user. When RSVP-TE signaling is used, 109 source node can determine if delay and loss requirement is met much 110 more rapidly than performing actual end-to-end performance 111 measurement. delay, jitter and loss are part of service/QoS 112 description/characterization and that as such belongs in a flowspec/ 113 tspec/adspec. This document modify IntServ (as represented by 114 RFC210) to provide new parameters. 116 One end-to-end LSP may go across some Composite Links [CL-REQ]. 117 RSVP-TE message needs to carry a indication for selection of 118 component links based on delay, jitter or loss constraint. When one 119 end-to-end LSP traverse a server layer, there will be some delay, 120 jitter of loss constraint requirements for server layer. So RSVP-TE 121 message needs to carry a indication for FA selection or FA-LSP 122 creation. This document defines a new ERO sub-object to indicate 123 that a component links, FA or FA-LSP should meet maximum acceptable 124 delay, jitter or loss value. 126 1.1. Conventions Used in This Document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Performance Accumulation and Verification 134 Delay, jitter and loss accumulation and verification applies where a 135 full path of multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) 136 TE LSP can't be or is not determined at ingress node of the TE LSP. 137 This is most likely to arise owing to TE visibility limitations. If 138 all domains support to communicate delay, jitter and loss as traffic 139 engineering metric parameters, one end-to-end optimized path with 140 performance constraint (e.g., less than 10 ms) could be computed by 141 BRPC [RFC5441] in PCE. Otherwise, it could use the mechanism defined 142 in this section to accumulat delay, jitter and loss along a path 143 which goes across multi-domain. 145 E2E performance requirement (e.g., delay isn't larger than 10ms) 146 could be signaled by RSVP-TE (e.g., Path and Resv message). 147 Intermediate nodes could reject the request (Path or Resv message) if 148 the accumulated delay, jitter or loss is not achievable. This is 149 essential in multiple AS use cases, but may not be needed in a single 150 IGP level/area if the IGP is extended to convey delay, jitter and 151 loss information. 153 Node delay for a WAN could be ignored or even an average, however 154 that was not true for the LAN cases. Whether the node delay should 155 be accumulated or not depends on the implementation. 157 One domain may need to know that other domains support performance 158 accumulation. It could be discovered in some automatic way. PCEs in 159 different domains may play a role here. It is for further study. 161 2.1. New RSVP ADSPEC sub-object 163 This document defines a new RSVP ADSPEC [RFC2210] sub-object to 164 support end-to-end accumulation of delay, jitter or loss. The new 165 RSVP ADSPEC sub-object has the following format. 167 0 1 2 3 168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type(IANA) | Length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Accumulated Estimated Performance Value 1 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ... | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Accumulated Estimated Performance Value n | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 1: New RSVP ADSPEC sub-Object 181 o Type(TBD): It indicates performance accumulation from source to 182 sink. 184 o Length: length of performance accumulation value. 186 Accumulated Estimated Performance Value format is defined in the next 187 picture. 189 0 1 2 3 190 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Value Type | Reserved | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Value | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 2: Format of Accumulated Estimated Performance Value 199 o Value Type: 201 * 0: It indicates Performance Accumulation Value is for end-to- 202 end delay accumulation along the LSP. 204 * 1: It indicates Performance Accumulation Value is for end-to- 205 end jitter accumulation along the LSP. 207 * 2: It indicates Performance Accumulation Value is for end-to- 208 end loss accumulation along the LSP. 210 o Value: 212 * If it is accumulated estimated delay value, it MUST be 213 quantified in units of micro-seconds and encoded as an float 214 point value. 216 * If it is accumulated estimated delay variation value, it MUST 217 be quantified in units of micro-seconds and encoded as an float 218 point value. Since latecny variation is accumulated non- 219 linearly, delay variation accumulatoin should be in a lower 220 priority. 222 * If it is accumulated estimated loss value, it MUST be 223 quantified in units of the number of packets per million 224 packets. For link loss, the path loss is not the sum of the 225 used links' losses. Instead, the path loss percentage is (100 226 - loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links 227 along the path are L1 to Ln. For example, assume packet loss 228 is 10% for two hops of a link. The measurements will come to 229 19% total packet loss. Because of 10% loss on the first link 230 only 90% packet reach the second link where another 10% of 90% 231 are lost, which is 9% of total packets. 233 2.2. New RSVP SENDER_TSPEC sub-object 235 This document defines a new RSVP SENDER_TSPEC [RFC2210] sub-object 236 which indicates end-to-end latecny, jitter or loss performance 237 requirement. Intermediate nodes could reject the request (Path or 238 Resv message) if the accumulated delay, jitter or loss value exceeds 239 required performance value in the SENDER_TSPEC sub-object. 241 If the accumulated delay, jitter or loss is not achievable, there is 242 no necessary to accumulate delay, jitter or loss for remaining domain 243 or nodes. 245 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type (IANA) | Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Performance Requirement Value 1 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | ... | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Performance Requirement Value n | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 3: New RSVP SENDER_TSPEC sub-object 259 The Performance Requirement Value format is defined in the next 260 picture. 262 0 1 2 3 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Value Type | Reserved | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Value | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 4: Format of Performance Requirement Value 272 o Value Type: 274 * 0: It indicates Performance Value is end-to-end delay 275 requirement. The accumulated estimated delay value should not 276 exceed this value. It MUST be quantified in units of micro- 277 seconds and encoded as an float point value. 279 * 1: It indicates Performance Value is end-to-end jitter 280 requirement. The accumulated estimated delay variation value 281 should not exceed this value. It MUST be quantified in units 282 of micro-seconds and encoded as an float point value. 284 * 2: It indicateds Performance Value is end-to-end loss 285 requirement. The accumulated estimated loss value should not 286 exceed this value. It MUST be quantified in units of the 287 number of packets per million packets. 289 o Value: 291 * If it is end-to-end delay requirement, accumulated estimated 292 delay value should not exceed this value. It MUST be 293 quantified in units of micro-seconds and encoded as an float 294 point value. 296 * If it is end-to-end jitter requirement, accumulated estimated 297 delay variation value should not exceed this value. It MUST be 298 quantified in units of micro-seconds and encoded as an float 299 point value. 301 * If it is end-to-end loss requirement, the accumulated estimated 302 loss value should not exceed this value. It MUST be quantified 303 in units of the number of packets per million packets. 305 2.3. New RSVP FLOWSPEC sub-object 307 In order to make source node get performance accumulation result from 308 source to sink in multi-domain (e.g., Inter-AS, Inter-Area or Multi- 309 Layer) application, this document defines a new RSVP FLOWSPEC 311 [RFC2210] sub-object. It has the same format and TLV Type as defined 312 in section "2.1 New RSVP ADSPEC sub-object". When sink node receive 313 Path message, it must copy the accumulation result from ADSPEC to 314 FLOWSPEC. 316 When LSP goes across a Composite Links [CL-REQ], traffic from LSR A 317 to B and B to A may go across different Component Links so that 318 performance from sink to source may not be indentical to the one from 319 source to sink. This document defines another new RSVP FLOWSPEC 320 [RFC2210] sub-object. It has the same format as defined in section 321 "2.1 New RSVP ADSPEC sub-object" except a different TLV Type which 322 indicates performance accumulation from sink to source. So source 323 node can get performance accumulated value from sink to source. 325 This document also defined a new FLOWSPEC sub-object which has the 326 same format, TLV Type and value as defined in section "2.2 New RSVP 327 SENDER_TSPEC sub-object". It indicates end-to-end delay, jitter or 328 loss performance requirement. 330 2.4. Signaling Procedures 332 When source node desires to accumulate delay, jitter or loss of one 333 end-to-end LSP, "Delay Accumulating desired", "Jitter Accumulation 334 desired" or "Loss Accumulation desired" flag (value TBD) should be 335 set in LSP_ATTRIBUTES object of Path/Resv message [RFC5420]. If 336 source node makes intermediate node have the capability to verify 337 accumulated performance, "Delay Verifying desired", "Jitter Verifying 338 desired" or "Loss Verifying desired" flag (value TBD) should be also 339 set in LSP_ATTRIBUTES object of Path/Resv message. 341 A source node initiates performance accumulation for a given LSP by 342 adding a new ADSPEC sub-object as defined in section 2.1 to Path 343 message. If performance verifying is desired, source node also adds 344 a new SENDER_TSPEC sub-object as defined in section 2.2 to Path 345 message. 347 When downstream node receives Path message and if performance (e.g., 348 delay, jitter or loss) accumulating desired is set in the 349 LSP_ATTRIBUTES, it accumulates delay, jitter or loss and updates 350 ADSPEC sub-object before it sends Path message to downsteam. 352 If performance verifying desired is set in LSP_ATTRIBUTES, downstream 353 node will check whether accumulated estimated performance value 354 exceeds the value carried in SENDER_TSPEC sub-object. If the 355 accumulated performance is not achievable, there is no necessary to 356 accumulate performance for remaining domain or nodes. It MUST 357 generate a error message with a indication which means that 358 accumulated performance (i.e., delay, jitter or loss) couldn't meet 359 end-to-end performance requirement (TBD by IANA). 361 If intermediate node (e.g., entry node of one domain) couldn't 362 support performance accumulation function, it MUST generate a error 363 message with a indication which means that performance accumulation 364 is unsupported (TBD by IANA). 366 When sink node of LSP receives Path message and performance 367 accumulating desired is set in LSP_ATTRIBUTES, it copy accumulated 368 estimated performance value from ADSPEC to FLOWSPEC before it send 369 Resv message to upstream. Then source node can get performance 370 accumulated value from source to sink for unidirectional and 371 bidirectional LSP. 373 If LSP is a bidirectional one and performance accumulating desired is 374 set in LSP_ATTRIBUTES, it adds a FLOWSPEC sub-object as defined in 375 section 2.3 to accumulate end-to-end performance value from sink to 376 source. 378 If LSP is a bidirectional one and performance verifying desired is 379 set in LSP_ATTRIBUTES, it copy end-to-end performance requirement 380 value from SENDER_TSPEC sub-oject to FLOWSPEC sub-object. 382 When upstream node receives Resv message and if performance 383 accumulating desired is set in LSP_ATTRIBUTES, it accumulates 384 performance of each hops and updates FLOWSPEC sub-object (i.e., from 385 sink to source) before it sends Resv message to upstream. 387 If performance verifying desired is set in LSP_ATTRIBUTES, it will 388 check whether accumulated estimated performance value from sink to 389 source exceeds end-to-end performance requirement value. If 390 accumulated performance is not achievable, there is no necessary to 391 accumulate performance for remaining domain or nodes. It MUST 392 generate a error message with a indication which means that 393 accumulated performance couldn't meet end-to-end performance 394 requirement (TBD by IANA). 396 After source node receive Resv message, it will get accumulated 397 performance value, it can confirm whether performance value meet SLA 398 or not. 400 3. Performance SLA Parameters Conveying 402 [CL-REQ] introduces Composite Link into MPLS network. In order to 403 assign LSP to one of component links with different performance 404 characteristics (e.g., delay, jitter and loss), RSVP-TE message MUST 405 convey performance SLA parameter to end points of Composite Links. 407 So it can select one of component links or trigger the creation of 408 lower layer connection based on performance SLA parameter. 410 One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse 411 a FA-LSP of server layer (e.g., OTN rings). There will be some 412 performance constraint requirement for server layer. RSVP-TE message 413 also needs to carry a indication for FA selection or FA-LSP creation. 415 So this document extend RSVP-TE to carry a indication of request 416 maximum acceptable delay, jitter of loss value. The end point will 417 take these parameters into account for selection or creation of 418 component link, FA selection or FA-LSP. 420 This document defines extensions to and describes the use of RSVP-TE 421 [RFC3209], [RFC3471], [RFC3473] to explicitly convey the performance 422 SLA parameter for selection or creation of component link or FA/ 423 FA-LSP. Specifically, in this document, Performance SLA Parameters 424 TLV are defined and added into ERO as a sub-object. 426 3.1. Performance SLA Parameters ERO sub-object 428 A new OPTIONAL sub-object of EXPLICIT_ROUTE Object (ERO) is used to 429 specify performance SLA parameters including a indication of request 430 maximum acceptable delay, jitter or loss value. It can be used for 431 following scenarios. 433 o One end-to-end LSP may traverse a server layer FA-LSP. This sub- 434 object of ERO can indicate that FA selection or FA-LSP creation 435 shall be based on delay, jitter or loss constraint. The boundary 436 nodes of multi-layer will take these parameters into account for 437 FA selection or FA-LSP creation. 439 o One end-to-end LSP may be across some Composite Links [CL-REQ]. 440 This subobject of ERO can indicate that a traffic flow shall 441 select a component link with some delay, jitter of loss constraint 442 values as specified in this subobject. 444 Performance SLA Parameters ERO subobject has the following format. 445 It follows a subobject containing the IP address, or the link 446 identifier [RFC3477], associated with the TE link on which it is to 447 be used. 449 0 1 2 3 450 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |L| Type(IANA) | Length | Reserved | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Request Maximum Acceptable Performance Value 1 | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | ... | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Request Maximum Acceptable Performance Value n | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 5: Format of Performance SLA Parameters TLV 463 Request Maximum Acceptable Performance Value format is defined in the 464 next picture. 466 0 1 2 3 467 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Value Type |M| Reserved | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Value | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 6: Format of Request Maximum Acceptable Performance Value 476 o Value Type: 478 * 0: It is maximum acceptable delay value. 480 * 1: It is maximum acceptable delay variation value. 482 * 2: It is maximum acceptable loss value. 484 o M bit: a one bit field indicates whether a traffic flow shall 485 select a component link with minimum performance (i.e., delay, 486 jitter or loss) value or not. It can also indicate whether one 487 end-to-end LSP shall select a FA with minimum performance value or 488 not when it traverse a server layer. 490 o Value: 492 * If it is maximum acceptable delay or jitter value, it MUST be 493 quantified in units of micro-seconds and encoded as an float 494 point value. 496 * If it is maximum acceptable loss value, it MUST be quantified 497 in units of the number of packets per million packets. 499 Following is an example about how to use these parameters. Assume 500 there are following component links within one composite link. 502 o Component link1: delay=50 ms, delay variation=15 ns, loss=8% 504 o Component link2: delay=100 ms, delay variation=6 ns, loss=9% 506 o Component link3: delay=200 ms, delay variation=3 ns, loss=8% 508 o Component link4: delay=300 ms, delay variation=1 ns, loss=7% 510 Assume there are following request information. 512 o Request minimum delay=FALSE 514 o Request minimum delay variation=FALSE 516 o Request minimum loss=FALSE 518 o Maximum Acceptable delay Value=150 ms 520 o Maximum Acceptable delay Variation Value=10 ns 522 o Maximum Acceptable Loss Value=10% 524 Only Component link2 could be qualified. 526 o Request minimum delay=FALSE 528 o Request minimum delay variation=FALSE 530 o Request minimum loss=FALSE 532 o Maximum Acceptable Delay Value=350 ms 534 o Maximum Acceptable Delay Variation Value=10 ns 536 o Maximum Acceptable Loss Value=8% 538 Component link 3 and 4 could be qualified. Which component link is 539 selected depends on local policy. 541 o Request minimum delay=FALSE 543 o Request minimum delay variation=TRUE 545 o Request minimum loss=FALSE 547 o Maximum Acceptable Delay Value=350 ms 549 o Maximum Acceptable Delay Variation Value=10 ns 551 o Maximum Acceptable Loss Value=10% 553 Only Component link4 could be qualified. 555 o Request minimum delay=TRUE 557 o Request minimum delay variation=FALSE 559 o Request minimum loss=FALSE 561 o Maximum Acceptable Delay Value=350 ms 563 o Maximum Acceptable Delay Variation Value=10 ns 565 o Maximum Acceptable Loss Value=10% 567 Only Component link2 could be qualified. 569 o Request minimum delay=FALSE 571 o Request minimum delay variation=FALSE 573 o Request minimum loss=TRUE 575 o Maximum Acceptable Delay Value= 350 ms 577 o Maximum Acceptable Delay Variation Value=10 ns 579 o Maximum Acceptable Loss Value=10% 581 Only Component link4 could be qualified. 583 Request minimum delay=TRUE 585 Request minimum delay variation=TRUE 586 Request minimum loss=TRUE 588 Maximum Acceptable delay Value=350 ms 590 Maximum Acceptable delay Variation Value=10 ns 592 Maximum Acceptable Loss Value=10% 594 In this case, there is no any qualified component links. But 595 priority may be used for delay and variation, so one of component 596 links could be still selected. 598 3.2. Signaling Procedure 600 When a intermediate node receives a PATH message containing ERO and 601 finds that there is a Performance SLA Parameters ERO sub-object 602 immediately behind the IP address or link address sub-object related 603 to itself, if the node determines that it's a region edge node of FA- 604 LSP or an end point of a Composite Link [CL-REQ], then this node 605 extracts Performance SLA parameters (i.e., request maximum acceptable 606 delay, jitter and loss value) from Performance SLA Parameters ERO 607 sub-object. This node used these performance parameters for FA 608 selection, FA-LSP creation or component link selection. 610 If intermediate node couldn't support performance SLA, it MUST 611 generate a PathErr message with a "Performance SLA unsupported" 612 indication (TBD by IANA). If intermediate node couldn't select a FA 613 or component link, or create a FA-LSP which meet performance 614 constraint defined in Performance SLA Parameters ERO sub-object, it 615 must generate a PathErr message with a "Performance SLA parameters 616 couldn't be met" indication (TBD by IANA). 618 4. Security Considerations 620 This document raises no new security issues. 622 5. IANA Considerations 624 TBD 626 6. References 627 6.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 633 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 634 Tunnels", RFC 3209, December 2001. 636 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 637 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 638 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 640 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 641 in Resource ReSerVation Protocol - Traffic Engineering 642 (RSVP-TE)", RFC 3477, January 2003. 644 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 645 (TE) Extensions to OSPF Version 2", RFC 3630, 646 September 2003. 648 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 649 of Generalized Multi-Protocol Label Switching (GMPLS)", 650 RFC 4203, October 2005. 652 6.2. Informative References 654 [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite 655 Link", draft-ietf-rtgwg-cl-requirement-07 . 657 [DELAY-LOSS-FRAMEWORK] 658 X.Fu, D. McDysan et al., "Loss and Delay Traffic 659 Engineering Framework for MPLS", 660 draft-fuxh-mpls-delay-loss-te-framework-05 . 662 [EXPRESS-PATH] 663 A. Atlas, "Performance-based Path Selection for Explicitly 664 Routed LSPs", draft-atlas-mpls-te-express-path-01 . 666 [ISIS-TE-EXPRESS-PATH] 667 S. Previdi, "IS-IS Traffic Engineering (TE) Metric 668 Extensions", draft-previdi-isis-te-metric-extensions-01 . 670 [LOSS-DELAY-PS] 671 X.Fu, D. McDysan et al., "Delay and Loss Traffic 672 Engineering Problem Statement for MPLS", 673 draft-fuxh-mpls-delay-loss-te-problem-statement-00 . 675 [OSPF-TE-EXPRESS-PATH] 676 S. Giacalone, "OSPF Traffic Engineering (TE) Metric 677 Extensions", draft-ietf-ospf-te-metric-extensions-01 . 679 [ietf-mpls-loss-delay] 680 D. Frost, "Packet Loss and Delay Measurement for MPLS 681 Networks", RFC6374 . 683 Authors' Addresses 685 Xihua Fu 686 ZTE 688 Email: fu.xihua@zte.com.cn 690 Malcolm Betts 691 ZTE 693 Email: malcolm.betts@zte.com.cn 695 Qilei Wang 696 ZTE 698 Email: wang.qilei@zte.com.cn 700 Dave McDysan 701 Verizon 703 Email: dave.mcdysan@verizon.com 705 Andrew Malis 706 Verizon 708 Email: andrew.g.malis@verizon.com 710 Vishwas Manral 711 Hewlett-Packard Corp. 713 Email: vishwas.manral@hp.com