idnits 2.17.1 draft-wang-ccamp-latency-te-metric-03.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 (March 14, 2011) is 4791 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 156, but not defined == Missing Reference: 'RFC3471' is mentioned on line 489, but not defined == Missing Reference: 'RFC5441' is mentioned on line 648, but not defined == Missing Reference: 'RFC5420' is mentioned on line 771, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-cl-requirement-02 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: September 15, 2011 ZTE 6 D. McDysan 7 A. Malis 8 Verizon 9 March 14, 2011 11 GMPLS extensions to communicate latency as a traffic engineering 12 performance metric 13 draft-wang-ccamp-latency-te-metric-03 15 Abstract 17 Latency is such requirement that must be achieved according to the 18 Service Level Agreement (SLA) between customers and service 19 providers. Network Performance Objective (NPO) defined in ITU-T 20 Y.1540 and Y.1541 is used for describing the meaning and numerical 21 values performance parameters traversing multiple packet networks. 22 The definitions of the packet network performance parameters are 23 often also used as the basis of SLAs service providers, but possibly 24 with different numerical values. A SLA is a part of a service 25 contract where the level of service is formally defined between 26 service providers and customers. For example, the service level 27 includes platinum, golden, silver and bronze. Different service 28 level may associate with different protection/restoration 29 requirement. Latency can also be associated with different service 30 level. The user may select a private line provider based on the 31 ability to meet a latency SLA. 33 The key driver for latency is stock/commodity trading applications 34 that use data base mirroring. A few milli seconds can impact a 35 transaction. Financial or trading companies are very focused on end- 36 to-end private pipe line latency optimizations that improve things 37 2-3 ms. Latency and latency SLA is one of the key parameters that 38 these "high value" customers use to select a private pipe line 39 provider. Other key applications like video gaming, conferencing and 40 storage area networks require stringent latency and bandwidth. 42 This document describes the requirements and mechanisms to 43 communicate latency as a traffic engineering performance metric in 44 today's network which is consisting of potentially multiple layers of 45 packet transport network and optical transport network in order to 46 meet the latency SLA between service provider and his customers. 47 This document also extends RSVP-TE and IGP to support these 48 requirement. These extensions are intended to advertise and convey 49 the latency information of nodes and links as traffic engineering 50 performance metric. 52 Status of this Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at http://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on September 15, 2011. 69 Copyright Notice 71 Copyright (c) 2011 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 87 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 88 2. Requirements Identification and Solution Consideration . . . . 6 89 2.1. Requirements Identification . . . . . . . . . . . . . . . 6 90 2.2. Solution Consideration . . . . . . . . . . . . . . . . . . 7 91 3. Control Plane Solution . . . . . . . . . . . . . . . . . . . . 9 92 3.1. Latency Advertisement . . . . . . . . . . . . . . . . . . 10 93 3.1.1. Routing Extensions . . . . . . . . . . . . . . . . . . 10 94 3.1.1.1. OSPF-TE Extension . . . . . . . . . . . . . . . . 10 95 3.1.1.2. IS-IS-TE Extension . . . . . . . . . . . . . . . . 11 96 3.1.1.3. Routing Extensions for Bundle Link/Composite 97 Link . . . . . . . . . . . . . . . . . . . . . . . 11 98 3.2. Latency SLA Parameters Conveying . . . . . . . . . . . . . 11 99 3.2.1. Signaling Extensions . . . . . . . . . . . . . . . . . 11 100 3.2.1.1. Latency SLA Parameters ERO subobject . . . . . . . 12 101 3.2.1.2. Signaling Procedure . . . . . . . . . . . . . . . 14 102 3.3. Latency Accumulation and Verification . . . . . . . . . . 15 103 3.3.1. Signaling Extensions . . . . . . . . . . . . . . . . . 15 104 3.3.1.1. Latency Accumulation Object . . . . . . . . . . . 15 105 3.3.1.2. Required Latency Object . . . . . . . . . . . . . 17 106 3.3.1.3. Signaling Procedures . . . . . . . . . . . . . . . 17 107 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 108 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 109 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 110 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 111 6.2. Informative References . . . . . . . . . . . . . . . . . . 20 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 114 1. Introduction 116 In a network, latency, a synonym for delay, is an expression of how 117 much time it takes for a packet/frame of data to get from one 118 designated point to another. In some usages, latency is measured by 119 sending a packet/frame that is returned to the sender and the round- 120 trip time is considered the latency of bidirectional co-routed or 121 associated LSP. One way time is considered as the latency of 122 unidirectional LSP. The one way latency may not be half of the 123 round-trip latency in the case that the transmit and receive 124 directions of the path are of unequal lengths. 126 Latency on a connection has two sources: Node latency which is caused 127 by the node as a result of process time in each node and: Link 128 latency as a result of packet/frame transit time between two 129 neighbouring nodes or a FA-LSP/Composit Link [CL-REQ]. Latency 130 variation is a parameter that is used to indicate the variation range 131 of the latency value. These values should be made available to the 132 control plane and management plane prior to path computation. This 133 allows path computation to select a path that will meet the latency 134 SLA. 136 In many cases, latency is a sensitive topic. For example, two stock 137 exchanges (e.g.,one in Chicago and another in New York) need to 138 communicate with each other. A few ms can result in large impact on 139 service. Some customers would pay for the latency performance. SLA 140 contract which includes the requirement of latency is signed between 141 service providers and customers. Service provider should assure that 142 the network path latency MUST be limited to a value lower than the 143 upper limit. In the future, latency optimization will be needed by 144 more and more customers. For example, some customers pay for a 145 private pipe line with latency constraint (e.g., less than 10 ms) 146 which connects to Data Center. If this "provisioned" latency of this 147 private pipe line couldn't meet the SLA, service provider may 148 transfer customer's service to other Data Centers. Service provider 149 may have many layers of pre-defined restoration for this transfer, 150 but they have to duplicate restoration resources at significant cost. 151 So service provider needs some mechanisms to avoid the duplicate 152 restoration and reduce the network cost. 154 Measurement mechanism for link latency has been defined in many 155 technologies. For example, the measurement mechanism for link 156 latency has been provided in ITU-T [G.8021] and [Y.1731] for 157 Ethernet. The link transit latency between two Ethernet equipments 158 can be measured by using this mechanism. Similarly, overhead byte 159 and measurement mechanism of latency has been provided in OTN (i.e., 160 ITU-T [G.709]). In order to measure the link latency between two OTN 161 nodes, PM&TCM which include Path Latency Measurement field and flag 162 used to indicate the beginning of measurement of latency is added to 163 the overhead of ODUk. Node latency can also be recorded at each node 164 by recording the process time between the beginning and the end. The 165 measurement mechanism of links and nodes is out scope of this 166 document. 168 Current operation and maintenance mode of latency measurement is high 169 in cost and low in efficiency. The latency can only be measured 170 after the connection has been established, if the measurement 171 indicates that the latency SLA is not met then another path is 172 computed, set up and measured. This "trial and error" process is 173 very inefficient. To avoid this problem a means of making an 174 accurate prediction of latency before a path is establish is 175 required. 177 This document describes the requirements and mechanisms to 178 communicate latency as a traffic engineering performance metric in 179 today's network which is consisting of potentially multiple layers of 180 packet transport network and optical transport network in order to 181 meet the latency SLA between service provider and his customers. 182 This document extends IGP to advertise and convey the latency 183 attributes and latency variation as traffic engineering performance 184 metric. Thus path computation entity can have a good knowledge of 185 the latency traffic engineering database. 187 This document extends RSVP-TE protocol to accumulate (e.g., sum) 188 latency information of links and nodes along one LSP across multi- 189 domain (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency 190 verification can be made at source node. One-way and round-trip 191 latency collection along the LSP by signaling protocol can be 192 supported. So the end points of this LSP can verify whether the 193 total amount of latency could meet the latency agreement between 194 operator and his user. 196 When RSVP-TE signaling is used, the source can determine if the 197 latency requirement is met much more rapidly than performing the 198 actual end-to-end latency measurement. 200 The required latency could be signaled by RSVP-TE (i.e., Path and 201 Resv message). Intermediate nodes could reject the request (Path or 202 Resv message) if the accumulated latency is not achievable. this is 203 essential in multiple AS use cases, but may not be needed in a single 204 IGP level/area if the IGP is extended to convey latency information. 206 1.1. Conventions Used in This Document 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 212 2. Requirements Identification and Solution Consideration 214 2.1. Requirements Identification 216 End-to-end service optimization based on latency is a key requirement 217 for service provider. This type of function will be adopted by their 218 "premium" service customers. They would like to pay for this 219 "premium" service. After these premium services are deployed, they 220 will also expand to their own customers. Following key requirements 221 associated with latency is identified. 223 o Communication latency of links and nodes including latency and 224 latency variation as a traffic engineering performance metric is a 225 very important requirement. 227 o End-to-end service optimization based on latency constraint is a 228 key requirement for service provider. Latency on a route level 229 will help carriers' customers to make his provider selection 230 decision. 232 * Path computation entity MUST have the capability to compute one 233 end-to-end path with latency constraint. For example, it MUST 234 have the capability to compute a route with x amount bandwidth 235 and less than y ms of latency limit based on the latency 236 traffic engineering database. 238 * It should also support combined routing constraints with pre- 239 defined priorities, e.g., SRLG diversity, latency and cost. 241 o One end-to-end LSP may be across some Composite Links [CL-REQ]. 242 Even if the transport technology (e.g., OTN) implementing the 243 component links is identical, the latency characteristics of the 244 component links may differ. In order to assign the LSP to one of 245 component links with different latency characteristics, following 246 related requirements are from [CL-REQ]. 248 * The solution SHALL provide a means to indicate that a traffic 249 flow shall select a component link with the minimum latency 250 value. 252 * The solution SHALL provide a means to indicate that a traffic 253 flow shall select a component link with a maximum acceptable 254 latency value as specified by protocol. 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 variation value as specified by protocol. 260 o RSPV-TE should support the accumulation (e.g., sum) of latency 261 information of links and nodes along one LSP across multi-domain 262 (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency 263 validation decision can be made at the source node. One-way and 264 round-trip latency collection along the LSP by signaling protocol 265 and latency verification at the end of LSP should be supported. 267 2.2. Solution Consideration 269 o The latency performance metric MUST be advertised into path 270 computation entity by IGP (etc., OSPF-TE or IS-IS-TE) to perform 271 route computation and network planning based on latecny SLA 272 target. 274 * Data plane is responsible for measuring the latency (e.g., 275 latency and latency variation). Latency measurement can be 276 provided by different technologies. This information will be 277 provided to the Control Plane. In order to monitor the 278 performance, pro-active latency measurement is required. 279 Generally, every 15 minutes or 24 hours, the value of latency 280 and latency variation should be collected. Similarly, on 281 demand latency measurement is required due to the goal of 282 maintenance. This can be done every fixed time interval (e.g., 283 5 minutes or 1 hour). The method used to measure the latency 284 of links and nodes is out scope of this document. 286 * Control plane is responsible for advertising and collecting the 287 latency value of links and nodes by IGP (i.e., OSPF-TE/ 288 IS-IS-TE). Latency characteristics of these links and nodes 289 may change dynamically. In order to control IGP messaging and 290 avoid being unstable when the latency and latency variation 291 value changes, a threshold and a limit on rate of change MUST 292 be configured to control plane. 294 o When the Composite Links [CL-REQ] is advertised into IGP, there 295 are following solution consideration. 297 * The latency of composite link may be the range (e.g., at least 298 minimum and maximum) latency value of all component links. The 299 latency of composite link may also be the maximum latency value 300 of all component links. In these cases, only partial 301 information is transmited in the IGP. So the path computation 302 entity has insufficient information to determine whether a 303 particular path can support its delay requirements. This leads 304 to signaling crankback. 306 * The IGP may be extended to advertise latency of each component 307 link within one Composite Link. 309 o In order to assign the LSP to one of component links with 310 different latency characteristics, RSVP-TE message MUST convey 311 latency SLA parameter to the end points of Composite Links where 312 it can select one of component links or trigger the creation of 313 lower layer connection which MUST meet latency SLA parameter. 315 * The RSVP-TE message needs to carry a indication of request 316 minimum latency, maximum acceptable latency value and maximum 317 acceptable delay variation value for the component link 318 selection or creation. The composite link will take these 319 parameters into account when assigning traffic of LSP to a 320 component link. 322 o One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may 323 traverse a FA-LSP of server layer (e.g., OTN rings). The boundary 324 nodes of the FA-LSP SHOULD be aware of the latency information of 325 this FA-LSP (e.g., latency and latency variation). 327 * If the FA-LSP is able to form a routing adjacency and/or as a 328 TE link in the client network, the latency value of the FA-LSP 329 can be as an input to a transformation that results in a FA 330 traffic engineering metric and advertised into the client layer 331 routing instances. Note that this metric will include the 332 latency of the links and nodes that the trail traverses. 334 * If the latency information of the FA-LSP changes (e.g., due to 335 a maintenance action or failure in OTN rings), the boundary 336 node of the FA-LSP will receive the TE link information 337 advertisement including the latency value which is already 338 changed and if it is over than the threshold and a limit on 339 rate of change, then it will compute the total latency value of 340 the FA-LSP again. If the total latency value of FA-LSP 341 changes, the client layer MUST also be notified about the 342 latest value of FA. The client layer can then decide if it 343 will accept the increased latency or request a new path that 344 meets the latency requirement. 346 * When one end-to-end LSP traverse a server layer, there will be 347 some latency constraint requirement for the segment route in 348 server layer. So RSVP-TE message needs to carry a indication 349 of request minimum latency, maximum acceptable latency value 350 and maximum acceptable delay variation value for the FA 351 selection or FA-LSP creation. The boundary nodes of FA-LSP 352 will take these parameters into account for FA selection or FA- 353 LSP creation. 355 o Restoration, protection and equipment variations can impact 356 "provisioned" latency (e.g., latency increase). The change of one 357 end-to-end LSP latency performance MUST be known by source and/or 358 sink node. So it can inform the higher layer network of a latency 359 change. The latency change of links and nodes will affect one 360 end-to-end LSP's total amount of latency. Applications can fail 361 beyond an application-specific threshold. Some remedy mechanism 362 could be used. 364 * Some customers may insist on having the ability to re-route if 365 the latency SLA is not being met. If a "provisioned" end-to- 366 end LSP latency could not meet the latency agreement (e.g., 367 latency or latency variation) between operator and his user, 368 then re-routing could be triggered based on the local policy. 369 Pre-defined or dynamic re-routing could be triggered to handle 370 this case. The latency performance of pre-defined or dynamic 371 re-routing LSP MUST meet the latency SLA parameter. In the 372 case of predefined re-routing, the large amounts of redundant 373 capacity may have a significant negative impact on the overall 374 network cost. Dynamic re-routing also has to face the risk of 375 resource limitation. So the choice of mechanism MUST be based 376 on SLA or policy. In the case where the latency SLA cannot be 377 met after a re-route is attempted, control plane should report 378 an alarm to management plane. It could also try restoration 379 for several times which could be configured. 381 * As a result of the change of links and nodes latency in the 382 LSP, current LSP may be frequently switched to a new LSP with a 383 appropriate latency value. In order to avoid this, the 384 solution SHOULD indicate the switchover of the LSP according to 385 maximum acceptable change latency value. 387 3. Control Plane Solution 389 In order to meet the requirements which have been identified in 390 section 3, this document defines following four phases. 392 o The first phase is the advertisement of the latency information by 393 routing protocol (i.e., OSPF-TE/IS-IS-TE), including latency of 394 nodes and links, a FA-LSP or Composite Link [CL-REQ] between two 395 neighbour and latency variation, so path computation entity can be 396 aware of the latency of nodes and links. 398 o In the second phase, path computation entity is responsible for 399 end-to-end path computation with latency constraint (e.g., less 400 than 10 ms) combining other routing constraint parameters (e.g., 401 SRLG, cost and bandwidth). How does the path computation entity 402 compute the latency variation of one end-to-end connection can be 403 refered to ITU-T Y.1540. 405 o The third phase is to convey the latency SLA parameters for the 406 selection or creation of component link or FA/FA-LSP. One end-to- 407 end LSP may be across some Composite Links or server layers, so it 408 can convey latency SLA parameters by RSVP-TE message. 410 o The last phase is the latency collection and verification. This 411 stage could be optional. It could accumulate (e.g., sum) latency 412 information along the LSP across multi-domain (e.g., Inter-AS, 413 Inter-Area or Multi-Layer) by RSVP-TE signaling message to verify 414 the total latency at the end of path. 416 3.1. Latency Advertisement 418 A node in the packet transport network or optical transport network 419 can detect the latency value of link which connects to it. Also the 420 node latency can be recorded at every node. Then latency values of 421 TE links, Composit Links [CL-REQ] or FAs, latency values of nodes and 422 latency variation are notified to the IGP. If any latency values 423 change and over than the threshold and a limit on rate of change, 424 then the change MUST be notified to the IGP again. As a result, path 425 computation entity can have every node and link latency values and 426 latency variation in its view of the network, and it can compute one 427 end-to-end path with latency constraint. It needs to extend IGP 428 protocol (i.e., OSPF-TE/IS-IS-TE). 430 3.1.1. Routing Extensions 432 Following is the extensions to OSPF-TE/IS-IS-TE to support the 433 advertisement of the node latency value, link latency and latency 434 variation. 436 3.1.1.1. OSPF-TE Extension 438 OSPF-TE routing protocol can be used to carry latency performance 439 metric by adding a sub-TLV to the TE link defined in [RFC4203]. As 440 defined in [RFC3630] and [RFC4203], the top-level TLV can take one of 441 two values (1) Router address or (2) Link. Latency sub-TLV of link 442 is added behind the top-level TLV. It includes estimated latency and 443 latency variation value. 445 This link attribute may also take into account the latency of a 446 network element (node), i.e., the latency between the incoming port 447 and the outgoing port of a network element. If the link attribute 448 were to include node latency AND link latency, then when the latency 449 calculation is done for paths traversing links on the same node then 450 the node latency can be subtracted out. Following is the link 451 Latency sub-TLV format. 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Type(IANA) | Length | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Estimated Latency Value | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Estimated Latency Variation Value | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 1: Format of the Latency sub-TLV 465 o Estimated Latency Value: a value indicates the latency of link or 466 node. 468 o Estimated Latency Variation Value: a value indicates the variation 469 range of the estimated latency value. 471 3.1.1.2. IS-IS-TE Extension 473 TBD 475 3.1.1.3. Routing Extensions for Bundle Link/Composite Link 477 [Editor Notes:Some discussion have been raised in RTGWG Mailing 478 list.] 480 Some people are discussing having an IGP adjacency (and metric) for a 481 composite link but a separate advertisement that contains parameters, 482 such as those listed here. 484 3.2. Latency SLA Parameters Conveying 486 3.2.1. Signaling Extensions 488 This document defines extensions to and describes the use of RSVP-TE 489 [RFC3209], [RFC3471], [RFC3473] to explicitly convey the latency SLA 490 parameter for the selection or creation of component link or FA/ 491 FA-LSP. Specifically, in this document, Latency SLA Parameters TLV 492 are defined and added into ERO as a subobject. 494 3.2.1.1. Latency SLA Parameters ERO subobject 496 A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used 497 to specify the latency SLA parameters including a indication of 498 request minimum latency, request maximum acceptable latency value and 499 request maximum acceptable latency variation value. It can be used 500 for the following scenarios. 502 o One end-to-end LSP may traverse a server layer FA-LSP. This 503 subobject of ERO can indicate that FA selection or FA-LSP creation 504 shall be based on this latency constraint. The boundary nodes of 505 multi-layer will take these parameters into account for FA 506 selection or FA-LSP creation. 508 o One end-to-end LSP may be across some Composite Links [CL-REQ]. 509 This subobject of ERO can indicate that a traffic flow shall 510 select a component link with some latency constraint values as 511 specified in this subobject. 513 This Latency SLA Parameters ERO subobject has the following format. 514 It follows a subobject containing the IP address, or the link 515 identifier [RFC3477], associated with the TE link on which it is to 516 be used. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type(IANA) | Length | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 |I|V| Reserved | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Request Maximum Acceptable Latency Value | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Request Maximum Acceptable Latency Variation Value | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 2: Format of Latency SLA Parameters TLV 532 o I bit: a one bit field indicates whether a traffic flow shall 533 select a component link with the minimum latency value or not. It 534 can also indicate whether one end-to-end LSP shall select a FA or 535 trigger a FA-LSP creation with the minimum latency value or not 536 when it traverse a server layer. 538 o V bit: a one bit field indicates whether a traffic flow shall 539 select a component link with the minimum latency variation value 540 or not. It can also indicate whether one end-to-end LSP shall 541 select a FA or trigger a FA-LSP creation with the minimum latency 542 variation value or not when it traverse a server layer. 544 o Request Maximum Acceptable Latency Value: a value indicates that a 545 traffic flow shall select a component link with a maximum 546 acceptable latency value. It can also indicate one end-to-end LSP 547 shall select a FA or trigger a FA-LSP creation with a maximum 548 acceptable latency value when it traverse a server layer. 550 o Request Maximum Acceptable Latency Variation Value: a value 551 indicates that a traffic flow shall select a component link with a 552 maximum acceptable latency variation value. It can also indicate 553 one end-to-end LSP shall select a FA or trigger a FA-LSP creation 554 with a maximum acceptable latency variation value when it traverse 555 a server layer. 557 Following is an example about how to use these parameters. Assume 558 there are following component links within one composite link. 560 o Component link1: latency = 5ms, latency variation = 15 us 562 o Component link2: latency = 10ms, latency variation = 6 us 564 o Component link3: latency = 20ms, latency variation = 3 us 566 o Component link4: latency = 30ms, latency variation = 1 us 568 Assume there are following request information. 570 o Request minimum latency = FALSE 572 o Request minimum latency variation= FALSE 574 o Maximum Acceptable Latency Value= 15 ms 576 o Maximum Acceptable Latency Variation Value = 10us 578 Only Component link2 could be qualified. 580 o Request minimum latency = FALSE 582 o Request minimum latency variation= FALSE 584 o Maximum Acceptable Latency Value= 35 ms 586 o Maximum Acceptable Latency Variation Value = 10us 587 Component link2/3/4 could be qualified. Which component link is 588 selected depends on local policy. 590 o Request minimum latency = FALSE 592 o Request minimum latency variation= TRUE 594 o Maximum Acceptable Latency Value= 35 ms 596 o Maximum Acceptable Latency Variation Value = 10us 598 Only Component link4 could be qualified. 600 o Request minimum latency = TRUE 602 o Request minimum latency variation= FALSE 604 o Maximum Acceptable Latency Value= 35 ms 606 o Maximum Acceptable Latency Variation Value = 10us 608 Only Component link2 could be qualified. 610 Request minimum latency = TRUE 612 Request minimum latency variation= TRUE 614 Maximum Acceptable Latency Value= 35 ms 616 Maximum Acceptable Latency Variation Value = 10us 618 In this case, there is no any qualified component links. 620 3.2.1.2. Signaling Procedure 622 When a intermediate node receives a PATH message containing ERO and 623 finds that there is a Latency SLA Parameters ERO subobject 624 immediately behind the IP address or link address sub-object related 625 to itself, if the node determines that it's a region edge node of FA- 626 LSP or an end point of a composite link [CL-REQ], then, this node 627 extracts latency SLA parameters (i.e.,request minimum, request 628 maximum acceptable and request maximum acceptable latency variation 629 value) from Latency SLA Parameters ERO subobject. This node used 630 these latency parameters for FA selection, FA-LSP creation or 631 component link selection. If the intermediate node couldn't support 632 the latency SLA, it MUST generate a PathErr message with a "Latency 633 SLA unsupported" indication (TBD by INNA). If the intermediate node 634 couldn't select a FA or component link, or create a FA-LSP which meet 635 the latency constraint defined in Latency SLA Parameters ERO 636 subobject, it must generate a PathErr message with a "Latency SLA 637 parameters couldn't be met" indication (TBD by INNA). 639 3.3. Latency Accumulation and Verification 641 Latency accumulation and verification applies where the full path of 642 an multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) TE LSP 643 can't be or is not determined at the ingress node of the TE LSP. 644 This is most likely to arise owing to TE visibility limitations. If 645 all domains support to communicate latency as a traffic engineering 646 metric parameter, one end-to-end optimized path with delay constraint 647 (e.g., less than 10 ms) which satisfies latency SLAs parameter could 648 be computed by BRPC [RFC5441] in PCE. Otherwise, it could use the 649 mechanism defined in this section to accumulat the latency of each 650 links and nodes along the path which is across multi-domain. Latency 651 accumulation and verification also applies where not all domains 652 could support the communication latency as a traffic engineering 653 metric parameter. 655 One domain may need to know that other domains support latency 656 accumulation. It could be discovered in some automatic way. PCEs in 657 different domains may play a role here. It is for further study. 659 3.3.1. Signaling Extensions 661 3.3.1.1. Latency Accumulation Object 663 An Latency Accumulation Object is defined in this document to support 664 the accumulation and verification of the latency. This object which 665 can be carried in a Path/Resv message may includes two sub-TLVs. 666 Latency Accumulation Object has the following format. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Type(IANA) | Length | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Latency Accumulation sub-TLV (from source to sink) | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Latency Accumulation sub-TLV (from sink to source) | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Figure 3: Format of Accumulated Latency Object 680 o Latency Accumulation sub-TLV (from source to sink):It is used to 681 accumulate the latency from source to sink along the 682 unidirectional or bidirectional LSP. A Path message for 683 unidirectional and bidirectional LSP must includes this sub-TLV. 684 When sink node receives the Path message including this sub-TLV, 685 it must copy this sub-TLV into Resv message. So the source node 686 can receive the latency accumulated value (i.e., sum) from itself 687 to sink node which can be used for latency verification. 689 o Latency Accumulation sub-TLV (from sink to source):It is used to 690 accumulate the latency from sink to source along the bidirectional 691 LSP. A Resv message for the bidirectional LSP must includes this 692 sub-TLV. So the source node can get the latency accumulated value 693 (i.e., sum) of round-trip which can be used for latency 694 verification. 696 3.3.1.1.1. Latency Accumulation sub-TLV 698 The Sub-TLV format is defined in the next picture. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type | Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Accumulated Estimated Latency Value | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Accumulated Estimated Latency Variation Value | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Figure 4: Format of Latency Accumulation sub-TLV 712 o Type: sub-TLV type 714 * 0: It indicates the sub-TLV is for the latency accumulation 715 from source to sink node along the LSP. 717 * 1: It indicates the sub-TLV is for the latency accumulation 718 from sink to source node along the LSP. 720 o Length: length of the sub-TLV value in bytes. 722 o Accumulated Estimated Latency Value: a value indicates the sum of 723 each links and nodes' latency along one direction of LSP. 725 o Accumulated Estimated Latency Variation Value: a value indicates 726 the sume of each links and nodes' latency variation along one 727 direction of LSP. Since latecny variation is accumulated non- 728 linearly. Latency variation accumulatoin should be in a lower 729 priority. 731 3.3.1.2. Required Latency Object 733 A required latency could be signaled by RSVP-TE message (i.e., Path 734 and Resv). This object is carried in the LSP_ATTRIBUTES object of 735 Path/Resv message, object that is defined in [RFC5420]. Intermediate 736 nodes could reject the request (Path or Resv message) if the 737 accumulated latency exceeds require latency value in the Required 738 Latency Object. 740 If the accumulated latency is not achievable, there is no necessary 741 to accumulate the latency for remaining domain or nodes. In order to 742 balance the load across network links more efficiently if the 743 absolute minimum latency is not required, intermediate nodes could 744 choose a cost-effective path if the requested latency could easily be 745 met. Note that this would apply inter-AS if the IGP is extended to 746 advertise latency. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type (INNA) | Length | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Required Latency Value | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Required Latency Variation Value | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Figure 5: Required Latency Object 760 o Required Latency Value: The accumulated estimated latency value 761 should not exceed this value. 763 o Required Latency Variation Value: The accumulated estimated 764 latency variation value should not exceed this value. 766 3.3.1.3. Signaling Procedures 768 When the source node desires to accumulate (i.e., sum) the total 769 latency of one end-to-end LSP, the "Latency Accumulating desired" 770 flag (value TBD) should be set in the LSP_ATTRIBUTES object of Path/ 771 Resv message, object that is defined in [RFC5420]. If the source 772 node makes the intermediate node have the capability to verify the 773 accumulated latency, the "Latency Verifying desred" flag (value TBD) 774 should be also set in the LSP_ATTRIBUTES object of Path/Resv message. 776 A source node initiates latency accumulation for a given LSP by 777 adding Latency Accumulation object to the Path message. The Latency 778 Accumulation object only includes one sub-TLV (sub-TLV type=0) where 779 it is going to accumulate the latency value of each links and nodes 780 along path from source to sink. If latency verifying is desred, the 781 source node also adds the Required Latency Object to the Path 782 message. 784 When the downstream node receives Path message and if the "Latency 785 Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates 786 the latency of link and node based on the accumulated latency value 787 of the sub-TLV (sub-TLV type=0) in Latency Accumulation object before 788 it sends Path message to downsteam. 790 If the "Latency Verifying desred" is set in the LSP_ATTRIBUTES, 791 downstream node will check whether the Accumulated Estimated Latency 792 and Variation value exceeds the Required Latency and Variation value. 793 If the accumulated latency is not achievable, there is no necessary 794 to accumulate the latency for remaining domain or nodes. It MUST 795 generate a error message with a "Accumulated Latency couldn't meet 796 the required latency" indication (TBD by INNA). 798 If the intermediate node (e.g., entry node of one domain) couldn't 799 support the latency accumulation function, it MUST generate a error 800 message with a "Latency Accumulation unsupported" indication (TBD by 801 INNA). 803 If the intermediate node (e.g., entry node of one domain) couldn't 804 support the latency verify function, it MUST generate a error message 805 with a "Latency Verify unsupported" indication (TBD by INNA). 807 When the sink node of LSP receives the Path message and the "Latency 808 Accumulating desired" is set in the LSP_ATTRIBUTES, it copy the 809 Accumulated Estimated Latency and Variation value in the Latency 810 Accumulation sub-TLV (sub-TLV type=0) of Path message into the one of 811 Resv message which will be forwarded hop by hop in the upstream 812 direction until it arrives the source node. Then source node can get 813 the latency sum value from source to sink for unidirectional and 814 bidirectional LSP. 816 If the LSP is a bidirectional one and the "Latency Accumulating 817 desired" is set in the LSP_ATTRIBUTES, it adds another Latency 818 Accumulation sub-TLV (sub-TLV type=1) into the Latency Accumulation 819 object of Resv message where latency of each links and nodes along 820 path will be accumulated from sink to source into this sub-TLV. 822 If the LSP is a bidirectional one and the "Latency Verifying desired" 823 is set in the LSP_ATTRIBUTES, it copy the Required Latency and 824 Variation value in the Required Latency Object of Path message into 825 the one of Resv message. 827 When the upstream node receives Resv message and if the "Latency 828 Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates 829 the latency of link and node based on the latency value in sub-TLV 830 (sub-TLV type=1) before it continues to sends Resv message. 832 If the "Latency Verifying desred" is set in the LSP_ATTRIBUTES, it 833 will check whether the latency sum of Accumulated Estimated Latency 834 and Variation value in each Latency Accumulation sub-TLV exceeds the 835 Required Latency and Variation value. If the accumulated latency is 836 not achievable, there is no necessary to accumulate the latency for 837 remaining domain or nodes. It MUST generate a error message with a 838 "Accumulated Latency couldn't meet the required latency" indication 839 (TBD by INNA). 841 After source node receive Resv message, it can get the total latency 842 value of one way or round-trip from Latency Accumulation object. So 843 it can confirm whether the latency value meet the latency SLA or not. 845 4. Security Considerations 847 TBD 849 5. IANA Considerations 851 TBD 853 6. References 855 6.1. Normative References 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 861 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 862 Tunnels", RFC 3209, December 2001. 864 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 865 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 866 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 868 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 869 in Resource ReSerVation Protocol - Traffic Engineering 870 (RSVP-TE)", RFC 3477, January 2003. 872 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 873 (TE) Extensions to OSPF Version 2", RFC 3630, 874 September 2003. 876 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 877 of Generalized Multi-Protocol Label Switching (GMPLS)", 878 RFC 4203, October 2005. 880 6.2. Informative References 882 [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite 883 Link", draft-ietf-rtgwg-cl-requirement-02 . 885 [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical 886 Transport Network (OTN)", December 2009. 888 Authors' Addresses 890 Xihua Fu 891 ZTE 893 Email: fu.xihua@zte.com.cn 895 Malcolm Betts 896 ZTE 898 Email: malcolm.betts@zte.com.cn 900 Qilei Wang 901 ZTE 903 Email: wang.qilei@zte.com.cn 905 Dave McDysan 906 Verizon 908 Email: dave.mcdysan@verizon.com 909 Andrew Malis 910 Verizon 912 Email: andrew.g.malis@verizon.com