idnits 2.17.00 (12 Aug 2021) /tmp/idnits2693/draft-fuxh-mpls-delay-loss-te-framework-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3031]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2011) is 3904 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: 'RFC3031' is mentioned on line 30, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 42, but not defined == Unused Reference: 'RFC2119' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 438, but no explicit reference was found in the text == Outdated reference: draft-ietf-rtgwg-cl-requirement has been published as RFC 7226 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group X. Fu 2 Internet-Draft ZTE 3 Intended status: Standards Track V. Manral 4 Expires: March 15, 2012 Hewlett-Packard Corp. 5 S. Giacalone 6 Thomson Reuters 7 M. Betts 8 Q. Wang 9 ZTE 10 D. McDysan 11 A. Malis 12 Verizon 13 J. Drake 14 Juniper Networks 15 September 12, 2011 17 Traffic Engineering architecture for services aware MPLS 18 draft-fuxh-mpls-delay-loss-te-framework-01 20 Abstract 22 With more and more enterprises using cloud based services, the 23 distances between the user and the applications are growing. A lot 24 of the current applications are designed to work across LAN's and 25 have various inherent assumptions. For multiple applications such as 26 High Performance Computing and Electronic Financial markets, the 27 response times are critical as is packet loss, while other 28 applications require more throughput. 30 [RFC3031] describes the architecture of MPLS based networks. This 31 draft extends the MPLS architecture to allow for latency, loss and 32 jitter as properties. 34 Note MPLS architecture for Multicast will be taken up in a future 35 version of the draft. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC 2119]. 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 March 15, 2012. 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 2. Architecture requirements overview . . . . . . . . . . . . . . 4 79 2.1. Requirement for Composite Link . . . . . . . . . . . . . . 4 80 2.2. Requirement for Hierarchy LSP . . . . . . . . . . . . . . 5 81 3. End-to-End Latency Measurements . . . . . . . . . . . . . . . 5 82 4. End-to-End Jitter Measurements . . . . . . . . . . . . . . . . 6 83 5. End-to-End Loss Measurements . . . . . . . . . . . . . . . . . 7 84 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7 85 7. Restoration, Protection and Rerouting . . . . . . . . . . . . 8 86 8. Control Plane Implication . . . . . . . . . . . . . . . . . . 8 87 8.1. Implications for Routing . . . . . . . . . . . . . . . . . 8 88 8.1.1. Implications for Signaling . . . . . . . . . . . . . . 9 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 94 1. Introduction 96 In High Frequency trading for Electronic Financial markets, computers 97 make decisions based on the Electronic Data received, without human 98 intervention. These trades now account for a majority of the trading 99 volumes and rely exclusively on ultra-low-latency direct market 100 access. 102 Extremely low latency measurements for MPLS LSP tunnels are defined 103 in [draft-ietf-mpls-loss-delay]. They allow a mechanism to measure 104 and monitor performance metrics for packet loss, and one-way and two- 105 way delay, as well as related metrics like delay variation and 106 channel throughput. 108 The measurements are however effective only after the LSP is created 109 and cannot be used by MPLS Path computation engine to define paths 110 that have the latest latency. This draft defines the architecture 111 used, so that end-to-end tunnels can be set up based on latency, loss 112 or jitter characteristics. 114 End-to-end service optimization based on latency and packet loss is a 115 key requirement for service provider. This type of function will be 116 adopted by their "premium" service customers. They would like to pay 117 for this "premium" service. Latency and loss on a route level will 118 help carriers' customers to make his provider selection decision. 120 2. Architecture requirements overview 122 The solution MUST provide a means to communicate latency, latency 123 variation and packet loss of links and nodes as a traffic engineering 124 performance metric into IGP. 126 Path computation entity MUST have the capability to compute one end- 127 to-end path with latency and packet loss constraint. For example, it 128 has the capability to compute a route with X amount of bandwidth with 129 less than Y ms of latency and Z% packet loss limit based on the 130 latency and packet loss traffic engineering database. It MUST also 131 support the path computation with routing constraints combination 132 with pre-defined priorities, e.g., SRLG diversity, latency, loss and 133 cost. 135 2.1. Requirement for Composite Link 137 One end-to-end LSP may traverses some Composite Links [CL-REQ]. Even 138 if the transport technology (e.g., OTN) component links are 139 identical, the latency and packet loss characteristics of the 140 component links may differ. 142 The solution MUST provide a means to indicate that a traffic flow 143 should select a component link with minimum latency and/or packet 144 loss, maximum acceptable latency and/or packet loss value and maximum 145 acceptable delay variation value as specified by protocol. The 146 endpoints of Composite Link will take these parameters into account 147 for component link selection or creation. The exact details for 148 component links will be taken up seperately and are not part of this 149 document. 151 2.2. Requirement for Hierarchy LSP 153 One end-to-end LSP may traverse a server layer. There will be some 154 latency and packet loss constraint requirement for the segment route 155 in server layer. 157 The solution MUST provide a means to indicate FA selection or FA-LSP 158 creation with minimum latency and/or packet loss, maximum acceptable 159 latency and/or packet loss value and maximum acceptable delay 160 variation value. The boundary nodes of FA-LSP will take these 161 parameters into account for FA selection or FA-LSP creation. 163 3. End-to-End Latency Measurements 165 Procedures to measure latency and loss has been provided in ITU-T 166 [Y.1731], [G.709] and [ietf-mpls-loss-delay]. The control plane can 167 is independent of the mechanism used and different mechanisms can be 168 used for measurement based on different standards. 170 Latency on a path has two sources: Node latency which is caused by 171 the node as a result of process time in each node and: Link latency 172 as a result of packet/frame transit time between two neighbouring 173 nodes or a FA-LSP/ Composite Link [CL-REQ]. 175 Latency or one-way delay is the time it takes for a packet within a 176 stream going from measurement point 1 to measurement point 2. 178 The architecture uses assumption that the sum of the latencies of the 179 individual components approximately adds up to the average latency of 180 an LSP. Though using the sum may not be perfect, it however gives a 181 good approximation that can be used for Traffic Engineering (TE) 182 purposes. 184 The total latency of an LSP consists of the sum of the latency of the 185 LSP hop, as well as the average latency of switching on a device, 186 which may vary based on queuing and buffering. 188 Hop latency can be measured by getting the latency measurement 189 between the egress of one MPLS LSR to the ingress of the nexthop LSR. 190 This value may be constant for most part, unless there is protection 191 switching, or other similar changes at a lower layer. 193 The switching latency on a device, can be measured internally, and 194 multiple mechanisms and data structures to do the same have been 195 defined. Add references to papers by Verghese, Kompella, Duffield. 196 Though the mechanisms define how to do flow based measurements, the 197 amount of information gathered in such a case, may become too 198 cumbersome for the Path Computation element to effectively use. 200 An approximation of Flow based measurement is the per DSCP value, 201 measurement from the ingress of one port to the egress of every other 202 port in the device. 204 Another approximation that can be used is per interface DSCP based 205 measurement, which can be an agrregate of the average measurements 206 per interface. The average can itself be calculated in ways, so as 207 to provide closer approximation. 209 For the purpose of this draft it is assumed that the node latency is 210 a small factor of the total latency in the networks where this 211 solution is deployed. The node latency is hence ignored for the 212 benefit of simplicity. 214 The delay is measured in terms of 10's of nano-seconds. 216 4. End-to-End Jitter Measurements 218 Jitter or Packet Delay Variation of a packet within a stream of 219 packets is defined for a selected pair of packets in the stream going 220 from measurement point 1 to measurement point 2. 222 The architecture uses assumption that the sum of the jitter of the 223 individual components approximately adds up to the average jitter of 224 an LSP. Though using the sum may not be perfect, it however gives a 225 good approximation that can be used for Traffic Engineering (TE) 226 purposes. 228 There may be very less jitter on a link-hop basis. 230 The buffering and queuing within a device will lead to the jitter. 231 Just like latency measurements, jitter measurements can be 232 appproximated as either per DSCP per port pair (Ingresss and Egress) 233 or as per DSCP per egress port. 235 For the purpose of this draft it is assumed that the node latency is 236 a small factor of the total latency in the networks where this 237 solution is deployed. The node latency is hence ignored for the 238 benefit of simplicity. 240 The jitter is measured in terms of 10's of nano-seconds. 242 5. End-to-End Loss Measurements 244 Loss or Packet Drop probability of a packet within a stream of 245 packets is defined as the number of packets dropped within a given 246 interval. 248 The architecture uses assumption that the sum of the loss of the 249 individual components approximately adds up to the average loss of an 250 LSP. Though using the sum may not be perfect, it however gives a 251 good approximation that can be used for Traffic Engineering (TE) 252 purposes. 254 There may be very less loss on a link-hop basis, except in case of 255 physical link issues. 257 The buffering and queuing mechanisms within a device will decide 258 which packet is to be dropped. Just like latency and jitter 259 measurements, the loss can best be appproximated as either per DSCP 260 per port pair (Ingresss and Egress) or as per DSCP per egress port. 262 The loss is measured in terms of the number of packets per million 263 packets. 265 6. Protocol Considerations 267 The protocol metrics above can be sent in IGP protocol packets RFC 268 3630. They can then be used by the Path Computation engine to 269 dervice paths with the desired path properties. 271 As Link-state IGP information is flooded throughout an area, frequent 272 changes can cause a lot of control traffic. To prevent such 273 flooding, data should only be flooded when it crosses a certain 274 configured maximum. 276 A seperate measurement should be done for an LSP when it is UP. Also 277 LSP's path should only be recalculated when the end-to-end metrics 278 changes in a way it becomes more then desired. 280 7. Restoration, Protection and Rerouting 282 Some customers may insist on having the ability to re-route if the 283 latency and loss SLA is not being met. If a "provisioned" end-to-end 284 LSP latency and/or loss could not meet the latency and loss agreement 285 between operator and his user, the solution SHOULD support pre- 286 defined or dynamic re-routing to handle this case based on the local 287 policy. 289 If a "provisioned" end-to-end LSP latency and/or loss performance is 290 improved (i.e., beyond a configurable minimum value) because of some 291 segment performance promotion, the solution SHOULD support the re- 292 routing to optimize latency and/or loss end-to-end cost. 294 The latency performance of pre-defined protection or dynamic re- 295 routing LSP MUST meet the latency SLA parameter. The difference of 296 latency value between primary and protection/restoration path SHOULD 297 be zero. 299 As a result of the change of latency and loss in the LSP, current LSP 300 may be frequently switched to a new LSP with a appropriate latency 301 and packet loss value. In order to avoid this, the solution SHOULD 302 indicate the switchover of the LSP according to maximum acceptable 303 change latency and packet loss value. 305 8. Control Plane Implication 307 8.1. Implications for Routing 309 The latency and packet loss performance metric MUST be advertised 310 into path computation entity by IGP (etc., OSPF-TE or IS-IS-TE) to 311 perform route computation and network planning based on latency and 312 packet loss SLA target. 314 Latency, latecny variation and packet loss value MUST be reported as 315 a average value which is calculated by data plane. 317 Latency and packet loss characteristics of these links and nodes may 318 change dynamically. In order to control IGP messaging and avoid 319 being unstable when the latency, latency variation and packet loss 320 value changes, a threshold and a limit on rate of change MUST be 321 configured to control plane. 323 If any latency and packet loss values change and over than the 324 threshold and a limit on rate of change, then the latency and loss 325 change of link MUST be notified to the IGP again. The receiving node 326 detrimines whether the link affects any of these LSPs for which it is 327 ingress. If there are, it must determine whether those LSPs still 328 meet end-to-end performance objectives. 330 A minimum value MUST be configured to control plane. If the link 331 performance improves beyond a configurable minimum value, it must be 332 re-advertised. The receiving node detrimines whether a "provisioned" 333 end-to-end LSP latency and/or loss performance is improved because of 334 some segment performance promotion. 336 It is sometimes important for paths that desire low latency is to 337 avoid nodes that have a significant contribution to latency. Control 338 plane should report two components of the delay, "static" and 339 "dynamic". The dynamic component is always caused by traffic loading 340 and queuing. The "dynamic" portion SHOULD be reported as an 341 approximate value. It should be a fixed latency through the node 342 without any queuing. Link latency attribute should also take into 343 account the latency of node, i.e., the latency between the incoming 344 port and the outgoing port of a network element. Half of the fixed 345 node latency can be added to each link. 347 8.1.1. Implications for Signaling 349 In order to assign the LSP to one of component links with different 350 latency and loss characteristics, RSVP-TE message needs to carry a 351 indication of request minimum latency and/or packet loss, maximum 352 acceptable latency and/or packet loss value and maximum acceptable 353 delay variation value for the component link selection or creation. 354 The composite link will take these parameters into account when 355 assigning traffic of LSP to a component link. 357 One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse 358 a FA-LSP of server layer (e.g., OTN rings). There will be some 359 latency and packet loss constraint requirement for the segment route 360 in server layer. So RSVP-TE message needs to carry a indication of 361 request minimum latency and/or packet loss, maximum acceptable 362 latency and/or packet loss value and maximum acceptable delay 363 variation value. The boundary nodes of FA-LSP will take these 364 parameters into account for FA selection or FA-LSP creation. 366 RSVP-TE needs to be extended to accumulate (e.g., sum) latency 367 information of links and nodes along one LSP across multi-domain 368 (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency 369 verification can be made at end points. One-way and round-trip 370 latency collection along the LSP by signaling protocol can be 371 supported. So the end points of this LSP can verify whether the 372 total amount of latency could meet the latency agreement between 373 operator and his user. When RSVP-TE signaling is used, the source 374 can determine if the latency requirement is met much more rapidly 375 than performing the actual end-to-end latency measurement. 377 Restoration, protection and equipment variations can impact 378 "provisioned" latency and packet loss (e.g., latency and packet loss 379 increase). For example, restoration/provisioning action in transport 380 network that increases latency seen by packet network observable by 381 customers, possibly violating SLAs. The change of one end-to-end LSP 382 latency and packet loss performance MUST be known by source and/or 383 sink node. So it can inform the higher layer network of a latency 384 and packet loss change. The latency or packet loss change of links 385 and nodes will affect one end-to-end LSPs total amount of latency or 386 packet loss. Applications can fail beyond an application-specific 387 threshold. Some remedy mechanism could be used. 389 Pre-defined protection or dynamic re-routing could be triggered to 390 handle this case. In the case of predefined protection, large 391 amounts of redundant capacity may have a significant negative impact 392 on the overall network cost. Service provider may have many layers 393 of pre-defined restoration for this transfer, but they have to 394 duplicate restoration resources at significant cost. Solution should 395 provides some mechanisms to avoid the duplicate restoration and 396 reduce the network cost. Dynamic re-routing also has to face the 397 risk of resource limitation. So the choice of mechanism MUST be 398 based on SLA or policy. In the case where the latency SLA can not be 399 met after a re-route is attempted, control plane should report an 400 alarm to management plane. It could also try restoration for several 401 times which could be configured. 403 9. IANA Considerations 405 No new IANA consideration are raised by this document. 407 10. Security Considerations 409 This document raises no new security issues. 411 11. Acknowledgements 413 TBD. 415 12. References 417 12.1. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 423 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 424 Tunnels", RFC 3209, December 2001. 426 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 427 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 428 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 430 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 431 in Resource ReSerVation Protocol - Traffic Engineering 432 (RSVP-TE)", RFC 3477, January 2003. 434 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 435 (TE) Extensions to OSPF Version 2", RFC 3630, 436 September 2003. 438 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 439 of Generalized Multi-Protocol Label Switching (GMPLS)", 440 RFC 4203, October 2005. 442 7.2. Informative References 444 [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite 445 Link", draft-ietf-rtgwg-cl-requirement-02 . 447 [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical 448 Transport Network (OTN)", December 2009. 450 [Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms 451 for Ethernet based networks", Feb 2008. 453 [ietf-mpls-loss-delay] 454 D. Frost, "Packet Loss and Delay Measurement for MPLS 455 Networks", draft-ietf-mpls-loss-delay-03 . 457 Authors' Addresses 459 Xihua Fu 460 ZTE 462 Email: fu.xihua@zte.com.cn 464 Vishwas Manral 465 Hewlett-Packard Corp. 466 191111 Pruneridge Ave. 467 Cupertino, CA 95014 468 US 470 Phone: 408-447-1497 471 Email: vishwas.manral@hp.com 472 URI: 474 Spencer Giacalone 475 Thomson Reuters 476 195 Broadway 477 New York, NY 10007 478 US 480 Phone: 646-822-3000 481 Email: spencer.giacalone@thomsonreuters.com 482 URI: 484 Malcolm Betts 485 ZTE 487 Email: malcolm.betts@zte.com.cn 489 Qilei Wang 490 ZTE 492 Email: wang.qilei@zte.com.cn 494 Dave McDysan 495 Verizon 497 Email: dave.mcdysan@verizon.com 498 Andrew Malis 499 Verizon 501 Email: andrew.g.malis@verizon.com 503 John Drake 504 Juniper Networks 506 Email: jdrake@juniper.net