idnits 2.17.00 (12 Aug 2021) /tmp/idnits46408/draft-fuxh-ccamp-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 (July 4, 2011) is 3967 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: 'RFC3471' is mentioned on line 163, but not defined == Missing Reference: 'RFC5441' is mentioned on line 327, but not defined == Missing Reference: 'RFC5420' is mentioned on line 462, but not defined == Unused Reference: 'RFC3630' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'G.709' is defined on line 576, but no explicit reference was found in the text == Outdated reference: draft-ietf-rtgwg-cl-requirement has been published as RFC 7226 Summary: 0 errors (**), 0 flaws (~~), 8 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: January 5, 2012 ZTE 6 D. McDysan 7 A. Malis 8 Verizon 9 July 4, 2011 11 RSVP-TE extensions for latency and loss traffic engineering application 12 draft-fuxh-ccamp-delay-loss-rsvp-te-ext-00 14 Abstract 16 The key driver for latency is stock/commodity trading applications. 17 Financial or trading companies are very focused on end-to-end private 18 pipe line latency optimizations that improve things 2-3 ms. Latency 19 and latency SLA is one of the key parameters that these "high value" 20 customers use to select a private pipe line provider. This document 21 extends RSVP-TE protocol to promote SLA experince of latency 22 application. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 60 2. SLA Parameters Conveying . . . . . . . . . . . . . . . . . . . 3 61 2.1. Signaling Extensions . . . . . . . . . . . . . . . . . . . 4 62 2.1.1. Latency SLA Parameters subobject . . . . . . . . . . . 5 63 2.1.2. Signaling Procedure . . . . . . . . . . . . . . . . . 7 64 3. Performance Accumulation and Verification . . . . . . . . . . 8 65 3.1. Signaling Extensions . . . . . . . . . . . . . . . . . . . 8 66 3.1.1. Latency Accumulation Object . . . . . . . . . . . . . 8 67 3.1.1.1. Latency Accumulation sub-TLV . . . . . . . . . . . 9 68 3.1.2. Required Latency Object . . . . . . . . . . . . . . . 10 69 3.1.3. Signaling Procedures . . . . . . . . . . . . . . . . . 11 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 End-to-end service optimization based on latency is a key requirement 80 for service provider. It needs to communicate latency of links and 81 nodes including latency and latency variation as a traffic 82 engineering performance metric is a very important requirement. 83 [LATENCY-REQ] describes the requirement of latency traffic 84 engineering application. 86 This document extend RSVP-TE to accumulate (e.g., sum) latency 87 information of links and nodes along one LSP across multi-domain 88 (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency 89 verification can be made at end points. One-way and round-trip 90 latency collection along the LSP by signaling protocol can be 91 supported. So the end points of this LSP can verify whether the 92 total amount of latency could meet the latency agreement between 93 operator and his user. When RSVP-TE signaling is used, the source 94 can determine if the latency requirement is met much more rapidly 95 than performing the actual end-to-end latency measurement. 97 One end-to-end LSP may be across some Composite Links [CL-REQ]. Even 98 if the transport technology (e.g., OTN) implementing the component 99 links is identical, the latency characteristics of the component 100 links may differ. RSVP-TE message needs to carry a indication for 101 the selection of component links based on the latecny constraint. 102 When one end-to-end LSP traverse a server layer, there will be some 103 latency constraint requirement for the segment route in server layer. 104 RSVP-TE message also needs to carry a indication for the FA selection 105 or FA-LSP creation. This document extends RSVP-TE to indicate that a 106 component links, FA or FA-LSP should meet the minimum and maximum 107 latency value or maximum acceptable latency variation value. 109 1.1. Conventions Used in This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. SLA Parameters Conveying 117 In order to assign the LSP to one of component links with different 118 latency characteristics, RSVP-TE message MUST convey latency SLA 119 parameter to the end points of Composite Links where it can select 120 one of component links or trigger the creation of lower layer 121 connection which MUST meet latency SLA parameter. 123 o The RSVP-TE message needs to carry a indication of request minimum 124 latency, maximum acceptable latency value and maximum acceptable 125 delay variation value for the component link selection or 126 creation. The composite link will take these parameters into 127 account when assigning traffic of LSP to a component link. 129 One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse 130 a FA-LSP of server layer (e.g., OTN rings). The boundary nodes of 131 the FA-LSP SHOULD be aware of the latency information of this FA-LSP 132 (e.g., latency and latency variation). 134 o If the FA-LSP is able to form a routing adjacency and/or as a TE 135 link in the client network, the latency value of the FA-LSP can be 136 as an input to a transformation that results in a FA traffic 137 engineering metric and advertised into the client layer routing 138 instances. Note that this metric will include the latency of the 139 links and nodes that the trail traverses. 141 o If the latency information of the FA-LSP changes (e.g., due to a 142 maintenance action or failure in OTN rings), the boundary node of 143 the FA-LSP will receive the TE link information advertisement 144 including the latency value which is already changed and if it is 145 over than the threshold and a limit on rate of change, then it 146 will compute the total latency value of the FA-LSP again. If the 147 total latency value of FA-LSP changes, the client layer MUST also 148 be notified about the latest value of FA. The client layer can 149 then decide if it will accept the increased latency or request a 150 new path that meets the latency requirement. 152 o When one end-to-end LSP traverse a server layer, there will be 153 some latency constraint requirement for the segment route in 154 server layer. So RSVP-TE message needs to carry a indication of 155 request minimum latency, maximum acceptable latency value and 156 maximum acceptable delay variation value for the FA selection or 157 FA-LSP creation. The boundary nodes of FA-LSP will take these 158 parameters into account for FA selection or FA-LSP creation. 160 2.1. Signaling Extensions 162 This document defines extensions to and describes the use of RSVP-TE 163 [RFC3209], [RFC3471], [RFC3473] to explicitly convey the latency SLA 164 parameter for the selection or creation of component link or FA/ 165 FA-LSP. Specifically, in this document, Latency SLA Parameters TLV 166 are defined and added into ERO as a subobject. 168 2.1.1. Latency SLA Parameters subobject 170 A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used 171 to specify the latency SLA parameters including a indication of 172 request minimum latency, request maximum acceptable latency value and 173 request maximum acceptable latency variation value. It can be used 174 for the following scenarios. 176 o One end-to-end LSP may traverse a server layer FA-LSP. This 177 subobject of ERO can indicate that FA selection or FA-LSP creation 178 shall be based on this latency constraint. The boundary nodes of 179 multi-layer will take these parameters into account for FA 180 selection or FA-LSP creation. 182 o One end-to-end LSP may be across some Composite Links [CL-REQ]. 183 This subobject of ERO can indicate that a traffic flow shall 184 select a component link with some latency constraint values as 185 specified in this subobject. 187 This Latency SLA Parameters ERO subobject has the following format. 188 It follows a subobject containing the IP address, or the link 189 identifier [RFC3477], associated with the TE link on which it is to 190 be used. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type(IANA) | Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 |I|V| Reserved | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Request Maximum Acceptable Latency Value | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Request Maximum Acceptable Latency Variation Value | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 1: Format of Latency SLA Parameters TLV 206 o I bit: a one bit field indicates whether a traffic flow shall 207 select a component link with the minimum latency value or not. It 208 can also indicate whether one end-to-end LSP shall select a FA or 209 trigger a FA-LSP creation with the minimum latency value or not 210 when it traverse a server layer. 212 o V bit: a one bit field indicates whether a traffic flow shall 213 select a component link with the minimum latency variation value 214 or not. It can also indicate whether one end-to-end LSP shall 215 select a FA or trigger a FA-LSP creation with the minimum latency 216 variation value or not when it traverse a server layer. 218 o Request Maximum Acceptable Latency Value: a value indicates that a 219 traffic flow shall select a component link with a maximum 220 acceptable latency value. It can also indicate one end-to-end LSP 221 shall select a FA or trigger a FA-LSP creation with a maximum 222 acceptable latency value when it traverse a server layer. It MUST 223 be quantified in units of microseconds and encoded as an integer 224 value. 226 o Request Maximum Acceptable Latency Variation Value: a value 227 indicates that a traffic flow shall select a component link with a 228 maximum acceptable latency variation value. It can also indicate 229 one end-to-end LSP shall select a FA or trigger a FA-LSP creation 230 with a maximum acceptable latency variation value when it traverse 231 a server layer. It MUST be quantified in units of nanosecond and 232 encoded as an integer value. 234 Following is an example about how to use these parameters. Assume 235 there are following component links within one composite link. 237 o Component link1: latency = 50 ms, latency variation = 15 ns 239 o Component link2: latency = 100 ms, latency variation = 6 ns 241 o Component link3: latency = 200 ms, latency variation = 3 ns 243 o Component link4: latency = 300 ms, latency variation = 1 ns 245 Assume there are following request information. 247 o Request minimum latency = FALSE 249 o Request minimum latency variation= FALSE 251 o Maximum Acceptable Latency Value= 150 ms 253 o Maximum Acceptable Latency Variation Value = 10 ns 255 Only Component link2 could be qualified. 257 o Request minimum latency = FALSE 259 o Request minimum latency variation= FALSE 260 o Maximum Acceptable Latency Value= 350 ms 262 o Maximum Acceptable Latency Variation Value = 10 ns 264 Component link2/3/4 could be qualified. Which component link is 265 selected depends on local policy. 267 o Request minimum latency = FALSE 269 o Request minimum latency variation= TRUE 271 o Maximum Acceptable Latency Value= 350 ms 273 o Maximum Acceptable Latency Variation Value = 10 ns 275 Only Component link4 could be qualified. 277 o Request minimum latency = TRUE 279 o Request minimum latency variation= FALSE 281 o Maximum Acceptable Latency Value= 350 ms 283 o Maximum Acceptable Latency Variation Value = 10 ns 285 Only Component link2 could be qualified. 287 Request minimum latency = TRUE 289 Request minimum latency variation= TRUE 291 Maximum Acceptable Latency Value= 350 ms 293 Maximum Acceptable Latency Variation Value = 10 ns 295 In this case, there is no any qualified component links. But 296 priority may be used for latency and variation, so one of component 297 links could be still selected. 299 2.1.2. Signaling Procedure 301 When a intermediate node receives a PATH message containing ERO and 302 finds that there is a Latency SLA Parameters ERO subobject 303 immediately behind the IP address or link address sub-object related 304 to itself, if the node determines that it's a region edge node of FA- 305 LSP or an end point of a composite link [CL-REQ], then, this node 306 extracts latency SLA parameters (i.e.,request minimum, request 307 maximum acceptable and request maximum acceptable latency variation 308 value) from Latency SLA Parameters ERO subobject. This node used 309 these latency parameters for FA selection, FA-LSP creation or 310 component link selection. If the intermediate node couldn't support 311 the latency SLA, it MUST generate a PathErr message with a "Latency 312 SLA unsupported" indication (TBD by INNA). If the intermediate node 313 couldn't select a FA or component link, or create a FA-LSP which meet 314 the latency constraint defined in Latency SLA Parameters ERO 315 subobject, it must generate a PathErr message with a "Latency SLA 316 parameters couldn't be met" indication (TBD by INNA). 318 3. Performance Accumulation and Verification 320 Latency accumulation and verification applies where the full path of 321 an multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) TE LSP 322 can't be or is not determined at the ingress node of the TE LSP. 323 This is most likely to arise owing to TE visibility limitations. If 324 all domains support to communicate latency as a traffic engineering 325 metric parameter, one end-to-end optimized path with delay constraint 326 (e.g., less than 10 ms) which satisfies latency SLAs parameter could 327 be computed by BRPC [RFC5441] in PCE. Otherwise, it could use the 328 mechanism defined in this section to accumulat the latency of each 329 links and nodes along the path which is across multi-domain. 331 Latency accumulation and verification also applies where not all 332 domains could support the communication latency as a traffic 333 engineering metric parameter. The required latency could be signaled 334 by RSVP-TE (i.e., Path and Resv message). Intermediate nodes could 335 reject the request (Path or Resv message) if the accumulated latency 336 is not achievable. This is essential in multiple AS use cases, but 337 may not be needed in a single IGP level/area if the IGP is extended 338 to convey latency information. 340 One domain may need to know that other domains support latency 341 accumulation. It could be discovered in some automatic way. PCEs in 342 different domains may play a role here. It is for further study. 344 3.1. Signaling Extensions 346 3.1.1. Latency Accumulation Object 348 An Latency Accumulation Object is defined in this document to support 349 the accumulation and verification of the latency. This object which 350 can be carried in a Path/Resv message may includes two sub-TLVs. 351 Latency Accumulation Object has the following format. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type(IANA) | Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Latency Accumulation sub-TLV (from source to sink) | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Latency Accumulation sub-TLV (from sink to source) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 2: Format of Accumulated Latency Object 365 o Latency Accumulation sub-TLV (from source to sink):It is used to 366 accumulate the latency from source to sink along the 367 unidirectional or bidirectional LSP. A Path message for 368 unidirectional and bidirectional LSP must includes this sub-TLV. 369 When sink node receives the Path message including this sub-TLV, 370 it must copy this sub-TLV into Resv message. So the source node 371 can receive the latency accumulated value (i.e., sum) from itself 372 to sink node which can be used for latency verification. 374 o Latency Accumulation sub-TLV (from sink to source):It is used to 375 accumulate the latency from sink to source along the bidirectional 376 LSP. A Resv message for the bidirectional LSP must includes this 377 sub-TLV. So the source node can get the latency accumulated value 378 (i.e., sum) of round-trip which can be used for latency 379 verification. It MUST be quantified in units of microseconds and 380 encoded as an integer value. 382 3.1.1.1. Latency Accumulation sub-TLV 384 The Sub-TLV format is defined in the next picture. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Accumulated Estimated Latency Value | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Accumulated Estimated Latency Variation Value | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Figure 3: Format of Latency Accumulation sub-TLV 398 o Type: sub-TLV type 399 * 0: It indicates the sub-TLV is for the latency accumulation 400 from source to sink node along the LSP. 402 * 1: It indicates the sub-TLV is for the latency accumulation 403 from sink to source node along the LSP. 405 o Length: length of the sub-TLV value in bytes. 407 o Accumulated Estimated Latency Value: a value indicates the sum of 408 each links and nodes' latency along one direction of LSP. It MUST 409 be quantified in units of microseconds and encoded as an integer 410 value. 412 o Accumulated Estimated Latency Variation Value: a value indicates 413 the sume of each links and nodes' latency variation along one 414 direction of LSP. Since latecny variation is accumulated non- 415 linearly. Latency variation accumulatoin should be in a lower 416 priority. It MUST be quantified in units of nanosecond and 417 encoded as an integer value. 419 3.1.2. Required Latency Object 421 A required latency could be signaled by RSVP-TE message (i.e., Path 422 and Resv). This object is carried in the LSP_ATTRIBUTES object of 423 Path/Resv message, object that is defined in [RFC5420]. Intermediate 424 nodes could reject the request (Path or Resv message) if the 425 accumulated latency exceeds require latency value in the Required 426 Latency Object. 428 If the accumulated latency is not achievable, there is no necessary 429 to accumulate the latency for remaining domain or nodes. In order to 430 balance the load across network links more efficiently if the 431 absolute minimum latency is not required, intermediate nodes could 432 choose a cost-effective path if the requested latency could easily be 433 met. Note that this would apply inter-AS if the IGP is extended to 434 advertise latency. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type (INNA) | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Required Latency Value | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Required Latency Variation Value | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 4: Required Latency Object 448 o Required Latency Value: The accumulated estimated latency value 449 should not exceed this value. It MUST be quantified in units of 450 microseconds and encoded as an integer value. 452 o Required Latency Variation Value: The accumulated estimated 453 latency variation value should not exceed this value. It MUST be 454 quantified in units of microseconds and encoded as an integer 455 value. 457 3.1.3. Signaling Procedures 459 When the source node desires to accumulate (i.e., sum) the total 460 latency of one end-to-end LSP, the "Latency Accumulating desired" 461 flag (value TBD) should be set in the LSP_ATTRIBUTES object of Path/ 462 Resv message, object that is defined in [RFC5420]. If the source 463 node makes the intermediate node have the capability to verify the 464 accumulated latency, the "Latency Verifying desired" flag (value TBD) 465 should be also set in the LSP_ATTRIBUTES object of Path/Resv message. 467 A source node initiates latency accumulation for a given LSP by 468 adding Latency Accumulation object to the Path message. The Latency 469 Accumulation object only includes one sub-TLV (sub-TLV type=0) where 470 it is going to accumulate the latency value of each links and nodes 471 along path from source to sink. If latency verifying is desired, the 472 source node also adds the Required Latency Object to the Path 473 message. 475 When the downstream node receives Path message and if the "Latency 476 Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates 477 the latency of link and node based on the accumulated latency value 478 of the sub-TLV (sub-TLV type=0) in Latency Accumulation object before 479 it sends Path message to downsteam. 481 If the "Latency Verifying desired" is set in the LSP_ATTRIBUTES, 482 downstream node will check whether the Accumulated Estimated Latency 483 and Variation value exceeds the Required Latency and Variation value. 484 If the accumulated latency is not achievable, there is no necessary 485 to accumulate the latency for remaining domain or nodes. It MUST 486 generate a error message with a "Accumulated Latency couldn't meet 487 the required latency" indication (TBD by INNA). 489 If the intermediate node (e.g., entry node of one domain) couldn't 490 support the latency accumulation function, it MUST generate a error 491 message with a "Latency Accumulation unsupported" indication (TBD by 492 INNA). 494 If the intermediate node (e.g., entry node of one domain) couldn't 495 support the latency verify function, it MUST generate a error message 496 with a "Latency Verify unsupported" indication (TBD by INNA). 498 When the sink node of LSP receives the Path message and the "Latency 499 Accumulating desired" is set in the LSP_ATTRIBUTES, it copy the 500 Accumulated Estimated Latency and Variation value in the Latency 501 Accumulation sub-TLV (sub-TLV type=0) of Path message into the one of 502 Resv message which will be forwarded hop by hop in the upstream 503 direction until it arrives the source node. Then source node can get 504 the latency sum value from source to sink for unidirectional and 505 bidirectional LSP. 507 If the LSP is a bidirectional one and the "Latency Accumulating 508 desired" is set in the LSP_ATTRIBUTES, it adds another Latency 509 Accumulation sub-TLV (sub-TLV type=1) into the Latency Accumulation 510 object of Resv message where latency of each links and nodes along 511 path will be accumulated from sink to source into this sub-TLV. 513 If the LSP is a bidirectional one and the "Latency Verifying desired" 514 is set in the LSP_ATTRIBUTES, it copy the Required Latency and 515 Variation value in the Required Latency Object of Path message into 516 the one of Resv message. 518 When the upstream node receives Resv message and if the "Latency 519 Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates 520 the latency of link and node based on the latency value in sub-TLV 521 (sub-TLV type=1) before it continues to sends Resv message. 523 If the "Latency Verifying desired" is set in the LSP_ATTRIBUTES, it 524 will check whether the latency sum of Accumulated Estimated Latency 525 and Variation value in each Latency Accumulation sub-TLV exceeds the 526 Required Latency and Variation value. If the accumulated latency is 527 not achievable, there is no necessary to accumulate the latency for 528 remaining domain or nodes. It MUST generate a error message with a 529 "Accumulated Latency couldn't meet the required latency" indication 530 (TBD by INNA). 532 After source node receive Resv message, it can get the total latency 533 value of one way or round-trip from Latency Accumulation object. So 534 it can confirm whether the latency value meet the latency SLA or not. 536 4. Security Considerations 538 TBD 540 5. IANA Considerations 542 TBD 544 6. References 546 6.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 552 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 553 Tunnels", RFC 3209, December 2001. 555 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 556 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 557 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 559 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 560 in Resource ReSerVation Protocol - Traffic Engineering 561 (RSVP-TE)", RFC 3477, January 2003. 563 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 564 (TE) Extensions to OSPF Version 2", RFC 3630, 565 September 2003. 567 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 568 of Generalized Multi-Protocol Label Switching (GMPLS)", 569 RFC 4203, October 2005. 571 6.2. Informative References 573 [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite 574 Link", draft-ietf-rtgwg-cl-requirement-02 . 576 [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical 577 Transport Network (OTN)", December 2009. 579 [LATENCY-REQ] 580 X. Fu, "GMPLS extensions to communicate latency as a 581 traffic engineering performance metric", 582 draft-wang-ccamp-latency-te-metric-03 . 584 Authors' Addresses 586 Xihua Fu 587 ZTE 589 Email: fu.xihua@zte.com.cn 591 Malcolm Betts 592 ZTE 594 Email: malcolm.betts@zte.com.cn 596 Qilei Wang 597 ZTE 599 Email: wang.qilei@zte.com.cn 601 Dave McDysan 602 Verizon 604 Email: dave.mcdysan@verizon.com 606 Andrew Malis 607 Verizon 609 Email: andrew.g.malis@verizon.com