idnits 2.17.00 (12 Aug 2021) /tmp/idnits27066/draft-wang-ccamp-latency-te-metric-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 (February 17, 2011) is 4111 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: 'G.8021' is mentioned on line 143, but not defined == Missing Reference: 'RFC3471' is mentioned on line 430, but not defined == Missing Reference: 'RFC5441' is mentioned on line 519, but not defined == Missing Reference: 'RFC5420' is mentioned on line 601, but not defined == Outdated reference: draft-ietf-rtgwg-cl-requirement has been published as RFC 7226 Summary: 0 errors (**), 0 flaws (~~), 6 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: August 21, 2011 ZTE Corporation 6 February 17, 2011 8 GMPLS extensions to communicate latency as a traffic engineering 9 performance metric 10 draft-wang-ccamp-latency-te-metric-02 12 Abstract 14 Latency is such requirement that must be achieved according to the 15 Service Level Agreement (SLA) between customers and service 16 providers. A SLA is a part of a service contract where the level of 17 service is formally defined between service providers and customers. 18 For example, the service level includes platinum, golden, silver and 19 bronze. Different service level may associate with different 20 protection/restoration requirement. Latency can also be associated 21 with different service level. The user may select a private line 22 provider based on the ability to meet a latency SLA. 24 The key driver for latency is stock/commodity trading applications 25 that use data base mirroring. A few milli seconds can impact a 26 transaction. Financial or trading companies are very focused on end- 27 to-end private pipe line latency optimizations that improve things 28 2-3 ms. Latency and latency SLA is one of the key parameters that 29 these "high value" customers use to select a private pipe line 30 provider. Other key applications like video gaming, conferencing and 31 storage area networks require stringent latency and bandwidth. 33 This document describes the requirements and mechanisms to 34 communicate latency as a traffic engineering performance metric in 35 today's network which is consisting of potentially multiple layers of 36 packet transport network and optical transport network in order to 37 meet the latency SLA between service provider and his customers. 38 This document also extends RSVP-TE and IGP to support these 39 requirement. These extensions are intended to advertise and convey 40 the latency information of nodes and links as traffic engineering 41 performance metric. 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on August 21, 2011. 60 Copyright Notice 62 Copyright (c) 2011 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 79 2. Identification of Requirements . . . . . . . . . . . . . . . . 5 80 3. Control Plane Solution . . . . . . . . . . . . . . . . . . . . 9 81 3.1. Latency Advertisement . . . . . . . . . . . . . . . . . . 9 82 3.1.1. Routing Extensions . . . . . . . . . . . . . . . . . . 10 83 3.1.1.1. OSPF-TE Extension . . . . . . . . . . . . . . . . 10 84 3.1.1.2. IS-IS-TE Extension . . . . . . . . . . . . . . . . 10 85 3.2. Latency SLA Parameters Conveying . . . . . . . . . . . . . 10 86 3.2.1. Signaling Extensions . . . . . . . . . . . . . . . . . 10 87 3.2.1.1. Latency SLA Parameters ERO subobject . . . . . . . 11 88 3.2.1.2. Signaling Procedure . . . . . . . . . . . . . . . 12 89 3.3. Latency Accumulation and Verification . . . . . . . . . . 12 90 3.3.1. Signaling Extensions . . . . . . . . . . . . . . . . . 12 91 3.3.1.1. Latency Accumulation Object . . . . . . . . . . . 12 92 3.3.1.2. Latency Accumulation sub-TLV . . . . . . . . . . . 13 93 3.3.1.3. Signaling Procedures . . . . . . . . . . . . . . . 14 94 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 96 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 98 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 101 1. Introduction 103 In a network, latency, a synonym for delay, is an expression of how 104 much time it takes for a packet/frame of data to get from one 105 designated point to another. In some usages, latency is measured by 106 sending a packet/frame that is returned to the sender and the round- 107 trip time is considered the latency of bidirectional co-routed or 108 associated LSP. One way time is considered as the latency of 109 unidirectional LSP. The one way latency may not be half of the 110 round-trip latency in the case that the transmit and receive 111 directions of the path are of unequal lengths. 113 Latency on a connection has two sources: Node latency which is caused 114 by the node as a result of process time in each node and: Link 115 latency as a result of packet/frame transit time between two 116 neighbouring nodes or a FA-LSP/Composit Link [CL-REQ]. Latency 117 variation is a parameter that is used to indicate the variation range 118 of the latency value. These values should be made available to the 119 control plane and management plane prior to path computation. This 120 allows path computation to select a path that will meet the latency 121 SLA. 123 In many cases, latency is a sensitive topic. For example, two stock 124 exchanges (e.g.,one in Chicago and another in New York) need to 125 communicate with each other. A few ms can result in large impact on 126 service. Some customers would pay for the latency performance. SLA 127 contract which includes the requirement of latency is signed between 128 service providers and customers. Service provider should assure that 129 the network path latency MUST be limited to a value lower than the 130 upper limit. In the future, latency optimization will be needed by 131 more and more customers. For example, some customers pay for a 132 private pipe line with latency constraint (e.g., less than 10 ms) 133 which connects to Data Center. If this "provisioned" latency of this 134 private pipe line couldn't meet the SLA, service provider may 135 transfer customer's service to other Data Centers. Service provider 136 may have many layers of pre-defined restoration for this transfer, 137 but they have to duplicate restoration resources at significant cost. 138 So service provider needs some mechanisms to avoid the duplicate 139 restoration and reduce the network cost. 141 Measurement mechanism for link latency has been defined in many 142 technologies. For example, the measurement mechanism for link 143 latency has been provided in ITU-T [G.8021] and [Y.1731] for 144 Ethernet. The link transit latency between two Ethernet equipments 145 can be measured by using this mechanism. Similarly, overhead byte 146 and measurement mechanism of latency has been provided in OTN (i.e., 147 ITU-T [G.709]). In order to measure the link latency between two OTN 148 nodes, PM&TCM which include Path Latency Measurement field and flag 149 used to indicate the beginning of measurement of latency is added to 150 the overhead of ODUk. Node latency can also be recorded at each node 151 by recording the process time between the beginning and the end. The 152 measurement mechanism of links and nodes is out scope of this 153 document. 155 Current operation and maintenance mode of latency measurement is high 156 in cost and low in efficiency. The latency can only be measured 157 after the connection has been established, if the measurement 158 indicates that the latency SLA is not met then another path is 159 computed, set up and measured. This "trial and error" process is 160 very inefficient. To avoid this problem a means of making an 161 accurate prediction of latency before a path is establish is 162 required. 164 This document describes the requirements and mechanisms to 165 communicate latency as a traffic engineering performance metric in 166 today's network which is consisting of potentially multiple layers of 167 packet transport network and optical transport network in order to 168 meet the latency SLA between service provider and his customers. 169 This document extends IGP to advertise and convey the latency 170 attributes and latency variation as traffic engineering performance 171 metric. Thus path computation entity can have a good knowledge of 172 the latency traffic engineering database. 174 This document extends RSVP-TE protocol to accumulate (e.g., sum) 175 latency information of links and nodes along one LSP across multi- 176 domain (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency 177 verification can be made at source node. One-way and round-trip 178 latency collection along the LSP by signaling protocol can be 179 supported. So the end points of this LSP can verify whether the 180 total amount of latency could meet the latency agreement between 181 operator and his user. 183 1.1. Conventions Used in This Document 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 2. Identification of Requirements 191 End-to-end service optimization based on latency (e.g., minimum 192 latency) is a key requirement for service provider. This type of 193 function will be adopted by their "premium" service customers. They 194 would like to pay for this "premium" service. After these premium 195 services are deployed, they will also expand to their own customers. 197 Following key requirements associated with latency is identified. 199 o Communication latency of links and nodes including minimum latency 200 and latency variation as a traffic engineering performance metric 201 is a very important requirement. The latency performance metric 202 MUST be advertised into path computation entity by IGP(etc., 203 OSPF-TE or IS-IS-TE) to perform route computation and network 204 planning based on latecny SLA target. Latency characteristics of 205 these links may change dynamically. In order to control IGP 206 messaging and avoid being unstable when the latency and latency 207 variation value changes, a threshold and a limit on rate of change 208 MUST be configured to control plane. 210 * Data plane is responsible for measuring the latency (e.g., 211 minimum latency and latency variation). Latency measurement 212 can be provided by different technologies. This information 213 will be provided to the Control Plane. In order to monitor the 214 performance, pro-active latency measurement is required. 215 Generally, every 15 minutes or 24 hours, the value of latency 216 and latency variation should be collected. Similarly, on 217 demand latency measurement is required due to the goal of 218 maintenance. This can be done every fixed time interval (e.g., 219 5 minutes or 1 hour). The method used to measure the latency 220 of links and nodes is out scope of this document. 222 * Control plane is responsible for advertising and collecting the 223 latency value of links and nodes by IGP (i.e., OSPF-TE/ 224 IS-IS-TE). 226 o End-to-end service optimization based on latency (e.g., minimum 227 latency) is a key requirement for service provider. Latency on a 228 route level will help carriers' customers to make his provider 229 selection decision. Path computation entity MUST have the 230 capability to compute one end-to-end path with latency constraint. 231 For example, it MUST have the capability to compute a route with x 232 amount bandwidth and less than y ms of latency limit based on the 233 latency traffic engineering database. It should also support 234 combined routing constraints with pre-defined priorities, e.g., 235 SRLG diversity, latency and cost. 237 o One end-to-end LSP may be across some Composite Links [CL-REQ]. 238 Even if the transport technology (e.g., OTN) implementing the 239 component links is identical, the latency characteristics of the 240 component links may differ. When the composite link is advertised 241 into IGP, the latency of composite link should be the maximum 242 latency value of all component links. 244 In order to assigne the LSP to one of component links with 245 different latency characteristics, RSVP-TE message MUST convey 246 latency SLA parameter (e.g., minimum latency) to the end points of 247 Composite Links where it can select one of component links or 248 trigger the creation of lower layer connection which MUST meet 249 latency SLA parameter. Following related requirements are from 250 [CL-REQ]. 252 * The solution SHALL provide a means to indicate that a traffic 253 flow shall select a component link with the minimum latency 254 value. 256 * The solution SHALL provide a means to indicate that a traffic 257 flow shall select a component link with a maximum acceptable 258 latency value as specified by protocol. 260 * The solution SHALL provide a means to indicate that a traffic 261 flow shall select a component link with a maximum acceptable 262 latency variation value as specified by protocol. 264 The RSVP-TE message needs to carry minimum latency, maximum 265 acceptable latency and maximum acceptable delay variation for the 266 component link selection or creation. The composite link will 267 take these parameters into account when assigning traffic of LSP 268 to a component link. 270 o One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may 271 traverse a FA-LSP of server layer (e.g., OTN rings). The boundary 272 nodes of the FA-LSP SHOULD be aware of the latency information of 273 this FA-LSP (e.g., minimum latency and latency variation). If the 274 FA-LSP is able to form a routing adjacency and/or as a TE link in 275 the client network, the latency value of the FA-LSP can be as an 276 input to a transformation that results in a FA traffic engineering 277 metric and advertised into the client layer routing instances. 278 Note that this metric will include the latency of the links and 279 nodes that the trail traverses. 281 If the latency information of the FA-LSP changes (e.g., due to a 282 maintenance action or failure in OTN rings), the boundary node of 283 the FA-LSP will receive the TE link information advertisement 284 including the latency value which is already changed and if it is 285 over than the threshold and a limit on rate of change, then it 286 will compute the total latency value of the FA-LSP again. If the 287 total latency value of FA-LSP changes, the client layer MUST also 288 be notified about the latest value of FA. The client layer can 289 then decide if it will accept the increased latency or request a 290 new path that meets the latency requirement. 292 When one end-to-end LSP traverse a server layer, there will be 293 some latency constraint requirement for the segment route in 294 server layer. So RSVP-TE message needs to carry minimum latency, 295 maximum acceptable latency and maximum acceptable delay variation 296 for the FA selection or FA-LSP creation. The boundary nodes of 297 FA-LSP will take these parameters into account for FA selection or 298 FA-LSP creation. 300 o Standardized measurement should be a goal for SLA validation. It 301 is out scope of this document. RSPV-TE should support the 302 accumulation (e.g., sum) of latency information of links and nodes 303 along one LSP across multi-domain (e.g., Inter-AS, Inter-Area or 304 Multi-Layer) so that an latency validation decision can be made at 305 the source node. One-way and round-trip latency collection along 306 the LSP by signaling protocol and latency verification at the end 307 of LSP should be supported. 309 o Restoration, protection and equipment variations can impact 310 "provisioned" latency (e.g., latency increase). The change of one 311 end-to-end LSP latency performance MUST be known by source and/or 312 sink node. So it can inform the higher layer network of a latency 313 change. The latency change of links and nodes will affect one 314 end-to-end LSP's total amount of latency. Applications can fail 315 beyond an application-specific threshold. Some remedy mechanism 316 could be used. 318 * Congestion in packet network can affect the latency. If the 319 latency of a provisioned end-to-end LSP could not meet the 320 latency agreement between operator and his user again, a 321 mechanism may cause the LSPs for some traffic flows to move to 322 some points in the network that is not congested. It is out 323 scope of this document. 325 * Some customers may insist on having the ability to re-route if 326 the latency SLA is not being met. If a "provisioned" end-to- 327 end LSP latency could not meet the latency agreement (e.g., 328 minimum latency or latency variation) between operator and his 329 user, then re-routing could be triggered based on the local 330 policy. Pre-defined or dynamic re-routing could be triggered 331 to handle this case. The latency performance of pre-defined or 332 dynamic re-routing LSP MUST meet the latency SLA parameter. In 333 the case of predefined re-routing, the large amounts of 334 redundant capacity may have a significant negative impact on 335 the overall network cost. Dynamic re-routing also has to face 336 the risk of resource limitation. So the choice of mechanism 337 MUST be based on SLA or policy. 339 * As a result of the change of links and nodes latency in the 340 LSP, current LSP may be frequently switched to a new LSP with a 341 appropriate latency value. In order to avoid this, the 342 solution SHOULD indicate the switchover of the LSP according to 343 maximum acceptable change latency value. 345 3. Control Plane Solution 347 In order to meet the requirements which have been identified in 348 section 3, this document defines following four phases. 350 o The first phase is the advertisement of the latency information by 351 routing protocol (i.e., OSPF-TE/IS-IS-TE), including latency of 352 nodes and links, a FA-LSP or Composite Link [CL-REQ] between two 353 neighbour and latency variation, so path computation entity can be 354 aware of the latency of nodes and links. 356 o In the second phase, path computation entity is responsible for 357 end-to-end path computation with latency constraint (e.g., less 358 than 10 ms) combining other routing constraint parameters (e.g., 359 SRLG, cost and bandwidth). 361 o The third phase is to convey the latency SLA parameters for the 362 selection or creation of component link or FA/FA-LSP. One end-to- 363 end LSP may be across some Composite Links or server layers, so it 364 can convey latency SLA parameters by RSVP-TE message. 366 o The last phase is the latency collection and verification. This 367 stage could be optional. It could accumulate (e.g., sum) latency 368 information along the LSP across multi-domain (e.g., Inter-AS, 369 Inter-Area or Multi-Layer) by RSVP-TE signaling message to verify 370 the total latency at the end of path. 372 3.1. Latency Advertisement 374 A node in the packet transport network or optical transport network 375 can detect the latency value of link which connects to it. Also the 376 node latency can be recorded at every node. Then latency values of 377 TE links, Composit Links [CL-REQ] or FAs, latency values of nodes and 378 latency variation are notified to the IGP and/or PCE. If any latency 379 values change and over than the threshold and a limit on rate of 380 change, then the change MUST be notified to the IGP and/or PCE again. 381 As a result, path computation entity can have every node and link 382 latency values and latency variation in its view of the network, and 383 it can compute one end-to-end path with latency constraint. It needs 384 to extend IGP protocol (i.e., OSPF-TE/IS-IS-TE). 386 3.1.1. Routing Extensions 388 Following is the extensions to OSPF-TE/IS-IS-TE to support the 389 advertisement of the node latency value, link latency and latency 390 variation. 392 3.1.1.1. OSPF-TE Extension 394 OSPF-TE routing protocol can be used to carry latency performance 395 metric by adding a sub-TLV to the TE link defined in [RFC4203]. As 396 defined in [RFC3630] and [RFC4203], the top-level TLV can take one of 397 two values (1) Router address or (2) Link. Latency sub-TLV of node 398 and link is added behind the top-level TLV. The link latency sub-TLV 399 has the same format as node latency sub-TLV. They both include 400 minimum latency and latency variation value. Following is the 401 Latency sub-TLV format. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type(IANA) | Length | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Minimum Latency Value | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Latency Variation Value | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 1: Format of the Latency sub-TLV 415 o Minimum Latency Value: a value indicates the minumum latency of 416 link or node. 418 o Latency Variation Value: a value indicates the variation range of 419 the minimum latency value. 421 3.1.1.2. IS-IS-TE Extension 423 TBD 425 3.2. Latency SLA Parameters Conveying 427 3.2.1. Signaling Extensions 429 This document defines extensions to and describes the use of RSVP-TE 430 [RFC3209], [RFC3471], [RFC3473] to explicitly convey the latency SLA 431 parameter for the selection or creation of component link or FA/ 432 FA-LSP. Specifically, in this document, Latency SLA Parameters TLV 433 are defined and added into ERO as a subobject. 435 3.2.1.1. Latency SLA Parameters ERO subobject 437 A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used 438 to specify the latency SLA parameters including minimum latency, 439 maximum acceptable latency and maximum acceptable latency variation. 440 It can be used for the following scenarios. 442 o One end-to-end LSP may traverse a server layer FA-LSP. This 443 subobject of ERO can indicate that FA selection or FA-LSP creation 444 shall be based on this latency constraint. The boundary nodes of 445 multi-layer will take these parameters into account for FA 446 selection or FA-LSP creation. 448 o One end-to-end LSP may be across some Composite Links [CL-REQ]. 449 This subobject of ERO can indicate that a traffic flow shall 450 select a component link with some latency constraint values as 451 specified in this subobject. 453 This Latency SLA Parameters ERO subobject has the following format. 454 It follows a subobject containing the IP address, or the link 455 identifier [RFC3477], associated with the TE link on which it is to 456 be used. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type(IANA) | Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Minimum Latency Value | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Maximum Acceptable Latency Value | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Maximum Acceptable Latency Variation Value | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 2: Format of Latency SLA Parameters TLV 472 o Minimum Latency Value: a value indicates that a traffic flow shall 473 select a component link with the minimum latency value [CL-REQ]. 474 It can also indicate one end-to-end LSP shall select a FA or 475 trigger a FA-LSP creation with the minimum latency value when it 476 traverse a server layer. 478 o Maximum Acceptable Latency Value: a value indicates that a traffic 479 flow shall select a component link with a maximum acceptable 480 latency value [CL-REQ]. It can also indicate one end-to-end LSP 481 shall select a FA or trigger a FA-LSP creation with a maximum 482 acceptable latency value when it traverse a server layer. 484 o Maximum Acceptable Latency Variation Value: a value indicates that 485 a traffic flow shall select a component link with a maximum 486 acceptable latency variation value [CL-REQ]. It can also indicate 487 one end-to-end LSP shall select a FA or trigger a FA-LSP creation 488 with a maximum acceptable latency variation value when it traverse 489 a server layer. 491 3.2.1.2. Signaling Procedure 493 When a intermediate node receives a PATH message containing ERO and 494 finds that there is a Latency SLA Parameters ERO subobject 495 immediately behind the IP address or link address sub-object related 496 to itself, if the node determines that it's a region edge node of FA- 497 LSP or an end point of a composite link [CL-REQ], then, this node 498 extracts latency SLA parameters (i.e., minimum, maximum acceptable 499 and maximum acceptable latency variation value) from Latency SLA 500 Parameters ERO subobject. This node used these latency parameters 501 for FA selection, FA-LSP creation or component link selection. If 502 the intermediate node couldn't support the latency SLA, it MUST 503 generate a PathErr message with a "Latency SLA unsupported" 504 indication (TBD by INNA). If the intermediate node couldn't select a 505 FA or component link, or create a FA-LSP which meet the latency 506 constraint defined in Latency SLA Parameters ERO subobject, it must 507 generate a PathErr message with a "Latency SLA parameters couldn't be 508 met" indication (TBD by INNA). 510 3.3. Latency Accumulation and Verification 512 Latency accumulation and verification applies where the full path of 513 an multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) TE LSP 514 can't be or is not determined at the ingress node of the TE LSP. 515 This is most likely to arise owing to TE visibility limitations. If 516 all domains support to communicate latency as a traffic engineering 517 metric parameter, one end-to-end optimized path with delay constraint 518 (e.g., less than 10 ms) which satisfies latency SLAs parameter could 519 be computed by BRPC [RFC5441] in PCE. Otherwise, it could use the 520 mechanism defined in this section to accumulat the latency of each 521 links and nodes along the path which is across multi-domain. Latency 522 accumulation and verification also applies where not all domains 523 could support the communication latency as a traffic engineering 524 metric parameter. 526 3.3.1. Signaling Extensions 528 3.3.1.1. Latency Accumulation Object 530 An Latency Accumulation Object is defined in this document to support 531 the accumulation and verification of the latency. This object which 532 can be carried in a Path/Resv message may includes two sub-TLVs. 533 Latency Accumulation Object has the following format. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type(IANA) | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Latency Accumulation sub-TLV (from source to sink) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Latency Accumulation sub-TLV (from sink to source) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 3: Format of Accumulated Latency Object 547 o Latency Accumulation sub-TLV (from source to sink):It is used to 548 accumulate the latency from source to sink along the 549 unidirectional or bidirectional LSP. A Path message for 550 unidirectional and bidirectional LSP must includes this sub-TLV. 551 When sink node receives the Path message including this sub-TLV, 552 it must copy this sub-TLV into Resv message. So the source node 553 can receive the latency accumulated value (i.e., sum) from itself 554 to sink node which can be used for latency verification. 556 o Latency Accumulation sub-TLV (from sink to source):It is used to 557 accumulate the latency from sink to source along the bidirectional 558 LSP. A Resv message for the bidirectional LSP must includes this 559 sub-TLV. So the source node can get the latency accumulated value 560 (i.e., sum) of round-trip which can be used for latency 561 verification. 563 3.3.1.2. Latency Accumulation sub-TLV 565 The Sub-TLV format is defined in the next picture. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Accumulated Minimum Latency Value | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Accumulated Latency Variation Value | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 4: Format of Latency Accumulation sub-TLV 579 o Type: sub-TLV type 581 * 0: It indicates the sub-TLV is for the latency accumulation 582 from source to sink node along the LSP. 584 * 1: It indicates the sub-TLV is for the latency accumulation 585 from sink to source node along the LSP. 587 o Length: length of the sub-TLV value in bytes. 589 o Accumulated Minimum Latency Value: a value indicates the sum of 590 each links and nodes' minumum latency along one direction of LSP. 592 o Accumulated Latency Variation Value: a value indicates the sume of 593 each links and nodes' minumum latency variation along one 594 direction of LSP. 596 3.3.1.3. Signaling Procedures 598 When the source node desires to accumulate (i.e., sum) the total 599 latency of one end-to-end LSP, the "Latency Accumulating desired" 600 flag (value TBD) should be set in the LSP_ATTRIBUTES object of Path/ 601 Resv message, object that is defined in [RFC5420]. 603 A source node initiates latency accumulation for a given LSP by 604 adding Latency Accumulation object to the Path message. The Latency 605 Accumulation object only includes one sub-TLV (sub-TLV type=0) where 606 it is going to accumulate the latency value of each links and nodes 607 along path from source to sink. 609 When the downstream node receives Path message and if the "Latency 610 Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates 611 the latency of link and node based on the accumulated latency value 612 of the sub-TLV (sub-TLV type=0) in Latency Accumulation object before 613 it sends Path message to downsteam. 615 If the intermediate node couldn't support the latency accumulation 616 function, it MUST generate a PathErr message with a "Latency 617 Accumulation unsupported" indication (TBD by INNA). 619 When the sink node of LSP receives the Path message and the "Latency 620 Accumulating desired" is set in the LSP_ATTRIBUTES, it copy the 621 latency value in the Latency Accumulation sub-TLV (sub-TLV type=0) of 622 Path message into the Resv message which will be forwarded hop by hop 623 in the upstream direction until it arrives the source node. Then 624 source node can get the latency sum value from source to sink for 625 unidirectional and bidirectional LSP. 627 If the LSP is a bidirectional one and the "Latency Accumulating 628 desired" is set in the LSP_ATTRIBUTES, it adds another Latency 629 Accumulation sub-TLV (sub-TLV type=1) into the Latency Accumulation 630 object of Resv message where latency of each links and nodes along 631 path will be accumulated from sink to source into this sub-TLV. 633 When the upstream node receives Resv message and if the "Latency 634 Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates 635 the latency of link and node based on the latency value in sub-TLV 636 (sub-TLV type=1) before it continues to sends Resv message. 638 After source node receive Resv message, it can get the total latency 639 value of one way or round-trip from Latency Accumulation object. So 640 it can confirm whether the latency value meet the latency SLA or not. 642 4. Security Considerations 644 TBD 646 5. IANA Considerations 648 TBD 650 6. References 652 6.1. Normative References 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 658 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 659 Tunnels", RFC 3209, December 2001. 661 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 662 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 663 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 665 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 666 in Resource ReSerVation Protocol - Traffic Engineering 667 (RSVP-TE)", RFC 3477, January 2003. 669 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 670 (TE) Extensions to OSPF Version 2", RFC 3630, 671 September 2003. 673 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 674 of Generalized Multi-Protocol Label Switching (GMPLS)", 675 RFC 4203, October 2005. 677 6.2. Informative References 679 [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite 680 Link", draft-ietf-rtgwg-cl-requirement-02 . 682 [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical 683 Transport Network (OTN)", December 2009. 685 Authors' Addresses 687 Xihua Fu 688 ZTE Corporation 690 Email: fu.xihua@zte.com.cn 692 Malcolm Betts 693 ZTE Corporation 695 Email: malcolm.betts@zte.com.cn 697 Qilei Wang 698 ZTE Corporation 700 Email: wang.qilei@zte.com.cn