idnits 2.17.00 (12 Aug 2021) /tmp/idnits51785/draft-fuxh-mpls-delay-loss-rsvp-te-ext-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 : ---------------------------------------------------------------------------- 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 21, 2011) is 3865 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: 'RFC5441' is mentioned on line 134, but not defined == Missing Reference: 'RFC5420' is mentioned on line 274, but not defined == Missing Reference: 'RFC3471' is mentioned on line 372, but not defined == Unused Reference: 'RFC3630' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'EXPRESS-PATH' is defined on line 568, 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 (-02) exists of draft-giacalone-ospf-te-express-path-01 == Outdated reference: A later version (-06) exists of draft-fuxh-mpls-delay-loss-te-framework-02 Summary: 0 errors (**), 0 flaws (~~), 10 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 23, 2012 ZTE 6 D. McDysan 7 A. Malis 8 Verizon 9 V. Manral 10 Hewlett-Packard Corp. 11 October 21, 2011 13 RSVP-TE extensions for services aware MPLS 14 draft-fuxh-mpls-delay-loss-rsvp-te-ext-00 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 latency optimizations that improve things 2-3 25 ms. Latency and latency SLA is one of the key parameters that these 26 "high value" customers use to select a private pipe line provider. 27 This document extends RSVP-TE protocol to promote SLA experince of 28 latency 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 23, 2012. 47 Copyright Notice 48 Copyright (c) 2011 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 . . . . . . . . . . . . 3 65 2. Performance Accumulation and Verification . . . . . . . . . . 3 66 2.1. Signaling Extensions . . . . . . . . . . . . . . . . . . . 4 67 2.1.1. Latency Accumulation Object . . . . . . . . . . . . . 4 68 2.1.1.1. Latency Accumulation sub-TLV . . . . . . . . . . . 5 69 2.1.2. Required Latency Object . . . . . . . . . . . . . . . 6 70 2.1.3. Signaling Procedures . . . . . . . . . . . . . . . . . 7 71 3. Performance SLA Parameters Conveying . . . . . . . . . . . . . 8 72 3.1. Signaling Extensions . . . . . . . . . . . . . . . . . . . 9 73 3.1.1. Latency SLA Parameters subobject . . . . . . . . . . . 9 74 3.1.2. Signaling Procedure . . . . . . . . . . . . . . . . . 12 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 End-to-end service optimization based on latency is a key requirement 85 for service provider. It needs to communicate latency of links and 86 nodes including latency and latency variation as a traffic 87 engineering performance metric is a very important requirement. 88 [LATENCY-REQ] describes the requirement of latency traffic 89 engineering application. 91 This document extend RSVP-TE to accumulate (e.g., sum) latency 92 information of links and nodes along one LSP across multi-domain 93 (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency 94 verification can be made at end points and improve the user's 95 experience. One-way and round-trip latency collection along the LSP 96 by signaling protocol can be supported. So the end points of this 97 LSP can verify whether the total amount of latency could meet the 98 latency agreement between operator and his user. When RSVP-TE 99 signaling is used, the source can determine if the latency 100 requirement is met much more rapidly than performing the actual end- 101 to-end latency measurement. 103 One end-to-end LSP may be across some Composite Links [CL-REQ]. Even 104 if the transport technology (e.g., OTN) implementing the component 105 links is identical, the latency characteristics of the component 106 links may differ. RSVP-TE message needs to carry a indication for 107 the selection of component links based on the latecny constraint. 108 When one end-to-end LSP traverse a server layer, there will be some 109 latency constraint requirement for server layer. RSVP-TE message 110 also needs to carry a indication for the FA selection or FA-LSP 111 creation. This document extends RSVP-TE to indicate that a component 112 links, FA or FA-LSP should meet the minimum and maximum latency value 113 or maximum acceptable latency variation value. 115 Packet Loss constraint will be taken up in a future version of the 116 draft. 118 1.1. Conventions Used in This Document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Performance Accumulation and Verification 126 Latency accumulation and verification applies where the full path of 127 an multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) TE LSP 128 can't be or is not determined at the ingress node of the TE LSP. 130 This is most likely to arise owing to TE visibility limitations. If 131 all domains support to communicate latency as a traffic engineering 132 metric parameter, one end-to-end optimized path with delay constraint 133 (e.g., less than 10 ms) which satisfies latency SLAs parameter could 134 be computed by BRPC [RFC5441] in PCE. Otherwise, it could use the 135 mechanism defined in this section to accumulat the latency of each 136 links and nodes along the path which is across multi-domain. 138 Latency accumulation and verification also applies where not all 139 domains could support the communication latency as a traffic 140 engineering metric parameter. The required latency could be signaled 141 by RSVP-TE (i.e., Path and Resv message). Intermediate nodes could 142 reject the request (Path or Resv message) if the accumulated latency 143 is not achievable. This is essential in multiple AS use cases, but 144 may not be needed in a single IGP level/area if the IGP is extended 145 to convey latency information. 147 Node latency for a WAN could be ignored or even an average, however 148 that was not true for the LAN cases. Whether the node latency should 149 be accumulated or not depends on the implementation. 151 One domain may need to know that other domains support latency 152 accumulation. It could be discovered in some automatic way. PCEs in 153 different domains may play a role here. It is for further study. 155 2.1. Signaling Extensions 157 2.1.1. Latency Accumulation Object 159 An Latency Accumulation Object is defined in this document to support 160 the accumulation and verification of the latency. This object which 161 can be carried in a Path/Resv message may includes two sub-TLVs. 162 Latency Accumulation Object has the following format. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Type(IANA) | Length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Latency Accumulation sub-TLV (from source to sink) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Latency Accumulation sub-TLV (from sink to source) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1: Format of Accumulated Latency Object 176 o Latency Accumulation sub-TLV (from source to sink):It is used to 177 accumulate the latency from source to sink along the 178 unidirectional or bidirectional LSP. A Path message for 179 unidirectional and bidirectional LSP must includes this sub-TLV. 180 When sink node receives the Path message including this sub-TLV, 181 it must copy this sub-TLV into Resv message. So the source node 182 can receive the latency accumulated value (i.e., sum) from itself 183 to sink node which can be used for latency verification. 185 o Latency Accumulation sub-TLV (from sink to source):It is used to 186 accumulate the latency from sink to source along the bidirectional 187 LSP. A Resv message for the bidirectional LSP must includes this 188 sub-TLV. So the source node can get the latency accumulated value 189 (i.e., sum) of round-trip which can be used for latency 190 verification. In the case of unidirectional LSP, this sub-TLV is 191 absent. 193 2.1.1.1. Latency Accumulation sub-TLV 195 The Sub-TLV format is defined in the next picture. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Accumulated Estimated Latency Value | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Accumulated Estimated Latency Variation Value | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2: Format of Latency Accumulation sub-TLV 209 o Type: sub-TLV type 211 * 0: It indicates the sub-TLV is for the latency accumulation 212 from source to sink node along the LSP. 214 * 1: It indicates the sub-TLV is for the latency accumulation 215 from sink to source node along the LSP. 217 o Length: length of the sub-TLV value in bytes. 219 o Accumulated Estimated Latency Value: a value indicates the sum of 220 each links and nodes' latency along one direction of LSP. It MUST 221 be quantified in units of micro-seconds and encoded as an float 222 point value. 224 o Accumulated Estimated Latency Variation Value: a value indicates 225 the sume of each links and nodes' latency variation along one 226 direction of LSP. Since latecny variation is accumulated non- 227 linearly. Latency variation accumulatoin should be in a lower 228 priority. It MUST be quantified in units of nano-seconds and 229 encoded as an float point value. 231 2.1.2. Required Latency Object 233 A required latency could be signaled by RSVP-TE message (i.e., Path 234 and Resv). This object is carried in the LSP_ATTRIBUTES object of 235 Path/Resv message, object that is defined in [RFC5420]. Intermediate 236 nodes could reject the request (Path or Resv message) if the 237 accumulated latency value exceeds required latency value in the 238 Required Latency Object. 240 If the accumulated latency is not achievable, there is no necessary 241 to accumulate the latency for remaining domain or nodes. In order to 242 balance the load across network links more efficiently if the 243 absolute minimum latency is not required, intermediate nodes could 244 choose a cost-effective path if the requested latency could easily be 245 met. Note that this would apply inter-AS if the IGP is extended to 246 advertise latency. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type (IANA) | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Required Latency Value | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Required Latency Variation Value | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 3: Required Latency Object 260 o Required Latency Value: The accumulated estimated latency value 261 should not exceed this value. It MUST be quantified in units of 262 micro-seconds and encoded as an float point value. 264 o Required Latency Variation Value: The accumulated estimated 265 latency variation value should not exceed this value. It MUST be 266 quantified in units of micro-seconds and encoded as an float point 267 value. 269 2.1.3. Signaling Procedures 271 When the source node desires to accumulate (i.e., sum) the total 272 latency of one end-to-end LSP, the "Latency Accumulating desired" 273 flag (value TBD) should be set in the LSP_ATTRIBUTES object of Path/ 274 Resv message, object that is defined in [RFC5420]. If the source 275 node makes the intermediate node have the capability to verify the 276 accumulated latency, the "Latency Verifying desired" flag (value TBD) 277 should be also set in the LSP_ATTRIBUTES object of Path/Resv message. 279 A source node initiates latency accumulation for a given LSP by 280 adding Latency Accumulation object to the Path message. The Latency 281 Accumulation object only includes one sub-TLV (sub-TLV type=0) where 282 it is going to accumulate the latency value of each links and nodes 283 along path from source to sink. If latency verifying is desired, the 284 source node also adds the Required Latency Object to the Path 285 message. 287 When the downstream node receives Path message and if the "Latency 288 Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates 289 the latency of link and node based on the accumulated latency value 290 of the sub-TLV (sub-TLV type=0) in Latency Accumulation object before 291 it sends Path message to downsteam. 293 If the "Latency Verifying desired" is set in the LSP_ATTRIBUTES, 294 downstream node will check whether the Accumulated Estimated Latency 295 and Variation value exceeds the Required Latency and Variation value. 296 If the accumulated latency is not achievable, there is no necessary 297 to accumulate the latency for remaining domain or nodes. It MUST 298 generate a error message with a "Accumulated Latency couldn't meet 299 the required latency" indication (TBD by IANA). 301 If the intermediate node (e.g., entry node of one domain) couldn't 302 support the latency accumulation function, it MUST generate a error 303 message with a "Latency Accumulation unsupported" indication (TBD by 304 IANA). 306 If the intermediate node (e.g., entry node of one domain) couldn't 307 support the latency verify function, it MUST generate a error message 308 with a "Latency Verify unsupported" indication (TBD by IANA). 310 When the sink node of LSP receives the Path message and the "Latency 311 Accumulating desired" is set in the LSP_ATTRIBUTES, it copy the 312 Accumulated Estimated Latency and Variation value in the Latency 313 Accumulation sub-TLV (sub-TLV type=0) of Path message into the one of 314 Resv message which will be forwarded hop by hop in the upstream 315 direction until it arrives the source node. Then source node can get 316 the latency sum value from source to sink for unidirectional and 317 bidirectional LSP. 319 If the LSP is a bidirectional one and the "Latency Accumulating 320 desired" is set in the LSP_ATTRIBUTES, it adds another Latency 321 Accumulation sub-TLV (sub-TLV type=1) into the Latency Accumulation 322 object of Resv message where latency of each links and nodes along 323 path will be accumulated from sink to source into this sub-TLV. 325 If the LSP is a bidirectional one and the "Latency Verifying desired" 326 is set in the LSP_ATTRIBUTES, it copy the Required Latency and 327 Variation value in the Required Latency Object of Path message into 328 the Resv message. 330 When the upstream node receives Resv message and if the "Latency 331 Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates 332 the latency of link and node based on the latency value in sub-TLV 333 (sub-TLV type=1) before it continues to sends Resv message. 335 If the "Latency Verifying desired" is set in the LSP_ATTRIBUTES, it 336 will check whether the latency sum of Accumulated Estimated Latency 337 and Variation value in each Latency Accumulation sub-TLV exceeds the 338 Required Latency and Variation value. If the accumulated latency is 339 not achievable, there is no necessary to accumulate the latency for 340 remaining domain or nodes. It MUST generate a error message with a 341 "Accumulated Latency couldn't meet the required latency" indication 342 (TBD by IANA). 344 After source node receive Resv message, it can get the total latency 345 value of one way or round-trip from Latency Accumulation object. So 346 it can confirm whether the latency value meet the latency SLA or not. 348 3. Performance SLA Parameters Conveying 350 [CL-REQ] introduces Composite Link into MPLS network. In order to 351 assign the LSP to one of component links with different latency 352 characteristics, RSVP-TE message MUST convey latency SLA parameter to 353 the end points of Composite Links where it can select one of 354 component links or trigger the creation of lower layer connection 355 which MUST meet latency SLA parameter. 357 One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse 358 a FA-LSP of server layer (e.g., OTN rings). There will be some 359 latency constraint requirement for server layer. RSVP-TE message 360 also needs to carry a indication for the FA selection or FA-LSP 361 creation. 363 The RSVP-TE message needs to carry a indication of request minimum 364 latency, maximum acceptable latency value and maximum acceptable 365 delay variation value. The end point will take these parameters into 366 account for selection or creation of component link, FA selection or 367 FA-LSP. 369 3.1. Signaling Extensions 371 This document defines extensions to and describes the use of RSVP-TE 372 [RFC3209], [RFC3471], [RFC3473] to explicitly convey the latency SLA 373 parameter for the selection or creation of component link or FA/ 374 FA-LSP. Specifically, in this document, Latency SLA Parameters TLV 375 are defined and added into ERO as a subobject. 377 3.1.1. Latency SLA Parameters subobject 379 A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used 380 to specify the latency SLA parameters including a indication of 381 request minimum latency, request maximum acceptable latency value and 382 request maximum acceptable latency variation value. It can be used 383 for the following scenarios. 385 o One end-to-end LSP may traverse a server layer FA-LSP. This 386 subobject of ERO can indicate that FA selection or FA-LSP creation 387 shall be based on this latency constraint. The boundary nodes of 388 multi-layer will take these parameters into account for FA 389 selection or FA-LSP creation. 391 o One end-to-end LSP may be across some Composite Links [CL-REQ]. 392 This subobject of ERO can indicate that a traffic flow shall 393 select a component link with some latency constraint values as 394 specified in this subobject. 396 This Latency SLA Parameters ERO subobject has the following format. 397 It follows a subobject containing the IP address, or the link 398 identifier [RFC3477], associated with the TE link on which it is to 399 be used. 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type(IANA) | Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |I|V| Reserved | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Request Maximum Acceptable Latency Value | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Request Maximum Acceptable Latency Variation Value | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 4: Format of Latency SLA Parameters TLV 415 o I bit: a one bit field indicates whether a traffic flow shall 416 select a component link with the minimum latency value or not. It 417 can also indicate whether one end-to-end LSP shall select a FA or 418 trigger a FA-LSP creation with the minimum latency value or not 419 when it traverse a server layer. 421 o V bit: a one bit field indicates whether a traffic flow shall 422 select a component link with the minimum latency variation value 423 or not. It can also indicate whether one end-to-end LSP shall 424 select a FA or trigger a FA-LSP creation with the minimum latency 425 variation value or not when it traverse a server layer. 427 o Request Maximum Acceptable Latency Value: a value indicates that a 428 traffic flow shall select a component link with a maximum 429 acceptable latency value. It can also indicate one end-to-end LSP 430 shall select a FA or trigger a FA-LSP creation with a maximum 431 acceptable latency value when it traverse a server layer. It MUST 432 be quantified in units of micro-seconds and encoded as an float 433 point value. 435 o Request Maximum Acceptable Latency Variation Value: a value 436 indicates that a traffic flow shall select a component link with a 437 maximum acceptable latency variation value. It can also indicate 438 one end-to-end LSP shall select a FA or trigger a FA-LSP creation 439 with a maximum acceptable latency variation value when it traverse 440 a server layer. It MUST be quantified in units of nano-seconds 441 and encoded as an float point value. 443 Following is an example about how to use these parameters. Assume 444 there are following component links within one composite link. 446 o Component link1: latency = 50 ms, latency variation = 15 ns 447 o Component link2: latency = 100 ms, latency variation = 6 ns 449 o Component link3: latency = 200 ms, latency variation = 3 ns 451 o Component link4: latency = 300 ms, latency variation = 1 ns 453 Assume there are following request information. 455 o Request minimum latency = FALSE 457 o Request minimum latency variation= FALSE 459 o Maximum Acceptable Latency Value= 150 ms 461 o Maximum Acceptable Latency Variation Value = 10 ns 463 Only Component link2 could be qualified. 465 o Request minimum latency = FALSE 467 o Request minimum latency variation= FALSE 469 o Maximum Acceptable Latency Value= 350 ms 471 o Maximum Acceptable Latency Variation Value = 10 ns 473 Component link2/3/4 could be qualified. Which component link is 474 selected depends on local policy. 476 o Request minimum latency = FALSE 478 o Request minimum latency variation= TRUE 480 o Maximum Acceptable Latency Value= 350 ms 482 o Maximum Acceptable Latency Variation Value = 10 ns 484 Only Component link4 could be qualified. 486 o Request minimum latency = TRUE 488 o Request minimum latency variation= FALSE 489 o Maximum Acceptable Latency Value= 350 ms 491 o Maximum Acceptable Latency Variation Value = 10 ns 493 Only Component link2 could be qualified. 495 Request minimum latency = TRUE 497 Request minimum latency variation= TRUE 499 Maximum Acceptable Latency Value= 350 ms 501 Maximum Acceptable Latency Variation Value = 10 ns 503 In this case, there is no any qualified component links. But 504 priority may be used for latency and variation, so one of component 505 links could be still selected. 507 3.1.2. Signaling Procedure 509 When a intermediate node receives a PATH message containing ERO and 510 finds that there is a Latency SLA Parameters ERO subobject 511 immediately behind the IP address or link address sub-object related 512 to itself, if the node determines that it's a region edge node of FA- 513 LSP or an end point of a composite link [CL-REQ], then, this node 514 extracts latency SLA parameters (i.e.,request minimum, request 515 maximum acceptable and request maximum acceptable latency variation 516 value) from Latency SLA Parameters ERO subobject. This node used 517 these latency parameters for FA selection, FA-LSP creation or 518 component link selection. 520 If the intermediate node couldn't support the latency SLA, it MUST 521 generate a PathErr message with a "Latency SLA unsupported" 522 indication (TBD by IANA). If the intermediate node couldn't select a 523 FA or component link, or create a FA-LSP which meet the latency 524 constraint defined in Latency SLA Parameters ERO subobject, it must 525 generate a PathErr message with a "Latency SLA parameters couldn't be 526 met" indication (TBD by IANA). 528 4. Security Considerations 530 This document raises no new security issues. 532 5. IANA Considerations 534 TBD 536 6. References 538 6.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 544 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 545 Tunnels", RFC 3209, December 2001. 547 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 548 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 549 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 551 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 552 in Resource ReSerVation Protocol - Traffic Engineering 553 (RSVP-TE)", RFC 3477, January 2003. 555 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 556 (TE) Extensions to OSPF Version 2", RFC 3630, 557 September 2003. 559 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 560 of Generalized Multi-Protocol Label Switching (GMPLS)", 561 RFC 4203, October 2005. 563 6.2. Informative References 565 [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite 566 Link", draft-ietf-rtgwg-cl-requirement-02 . 568 [EXPRESS-PATH] 569 S. Giacalone, "OSPF Traffic Engineering (TE) Express 570 Path", draft-giacalone-ospf-te-express-path-01 . 572 [LATENCY-REQ] 573 X. Fu, "Traffic Engineering architecture for services 574 aware MPLS", draft-fuxh-mpls-delay-loss-te-framework-02 . 576 [ietf-mpls-loss-delay] 577 D. Frost, "Packet Loss and Delay Measurement for MPLS 578 Networks", draft-ietf-mpls-loss-delay-03 . 580 Authors' Addresses 582 Xihua Fu 583 ZTE 585 Email: fu.xihua@zte.com.cn 587 Malcolm Betts 588 ZTE 590 Email: malcolm.betts@zte.com.cn 592 Qilei Wang 593 ZTE 595 Email: wang.qilei@zte.com.cn 597 Dave McDysan 598 Verizon 600 Email: dave.mcdysan@verizon.com 602 Andrew Malis 603 Verizon 605 Email: andrew.g.malis@verizon.com 607 Vishwas Manral 608 Hewlett-Packard Corp. 609 191111 Pruneridge Ave. 610 Cupertino, CA 95014 611 US 613 Phone: 408-447-1497 614 Email: vishwas.manral@hp.com 615 URI: