idnits 2.17.00 (12 Aug 2021) /tmp/idnits48528/draft-han-tsvwg-enhanced-diffserv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 922 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2581' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'EPC' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'HU5G' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'I-D.falk-xcp-spec' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'I-D.han-iccrg-arvr-transport-problem' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'I-D.han-tsvwg-cc' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-dctcp' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-tcpm-ctcp' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'QU2016' is defined on line 552, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) == Outdated reference: draft-ietf-tcpm-dctcp has been published as RFC 8257 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG Working Group L. Han 3 Internet-Draft Y. Qu 4 Intended status: Informational R. Li 5 Expires: May 7, 2020 Futurewei Technologies 6 November 4, 2019 8 Enhanced DiffServ by In-band Signaling 9 draft-han-tsvwg-enhanced-diffserv-00 11 Abstract 13 There are real-time applications requiring deterministic services in 14 terms of bandwidth and latency in various industries, such as network 15 based AR/VR (Augmented Reality and Virtual Reality), industrial 16 internet. This document proposes a solution which enhances DiffServ 17 in IPv6 to provide end to end bandwidth guaranteed service and 18 latency guaranteed service. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 7, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. DiffServ and IntServ . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Differentiated Services . . . . . . . . . . . . . . . . . 4 58 3.2. Integrated Services . . . . . . . . . . . . . . . . . . . 5 59 4. In-band Signaling . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Design Targets . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Processing Procedure . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6 63 6.2. The purpose of in-band signaling . . . . . . . . . . . . 7 64 6.3. The info carried in in-band signaling . . . . . . . . . . 7 65 6.4. Admission process with in-band signaling . . . . . . . . 8 66 6.5. User traffic classification and New DSCP class . . . . . 8 67 6.6. User traffic conformity checking . . . . . . . . . . . . 9 68 6.7. Queuing and Scheduling Consideration . . . . . . . . . . 9 69 6.8. Class Based Traffic Shaper . . . . . . . . . . . . . . . 10 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 9.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 76 Appendix B. Testing Results . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 [RFC8557][RFC8578] identifies some use cases from different 82 industries which have a common need for "deterministic flows". Such 83 flows require guaranteed bandwidth and bounded latency. 85 This document proposes to use in-band signaling together with 86 DiffServ to provide Latency Guaranteed Service and Bandwidth 87 Guaranteed Service. Network traffic is classified according to 88 application requirements and resources such as bandwidth and buffer 89 are dedicated to provide a reliable and scalable service, while 90 unused reserved resources could be used by best effort traffic. 92 The solution is compatible with existing Quality-of-Service (QoS) 93 mechanism as long as there is enough network resources, and is not 94 restricted to network topologies. Resource Reservation is done by 95 in-band signaling [I-D.han-tsvwg-ip-transport-qos], and IP path can 96 be achieved using existing routing protocols (IGP or BPG), or the 97 explicit path routing such as segment routing [RFC8402]. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in 105 all capitals, as shown here. 107 Abbreviations used in this documents: 109 E2E 110 End-to-end. 112 EH 113 IPv6 Extension Header or Extension Option. 115 QoS 116 Quality of Service. 118 OAM 119 Operation and Management. 121 In-band Signaling 122 In telecommunications, in-band signaling is sending control 123 information within the same band or channel used for voice or 124 video. 126 Out-of-band Signaling 127 out-of-band signaling is that the control information sent over 128 a different channel, or even over a separate network. 130 IP flow 131 For non-IPSec, an IP flow is identified by the source, 132 destination IP address, the protocol number, the source and 133 destination port number. 135 IP path 136 An IP path is the route that IP flow will traverse. It could 137 be the shortest path determined by routing protocols (IGP or 138 BPG), or the explicit path such as segment routing [RFC8402]. 140 QoS channel 141 A forwarding channel that is QoS guaranteed. It provides 142 additional QoS service to IP forwarding. A QoS channel can be 143 used for one or multiple IP flows depending on the granularity 144 of in-band signaling. 146 srTCM 147 Single Rate Three Color Marker [RFC2697] 149 trTCM 150 Two Rate Three Color Marker [RFC4115] 152 LGS 153 Latency Guaranteed Service 155 BGS 156 Bandwidth Guaranteed Service 158 BES 159 Best Effort Service 161 CIR 162 Committed Information Rate. 164 PIR 165 Peak Information Rate. 167 HbH-EH 168 IPv6 Hop-by-Hop Extension Header. 170 Dst-EH 171 IPv6 Destination Extension Header. 173 HbH-EH-aware node 174 Network nodes that are configured to process the IPv6 Hop-by- 175 Hop Extension Header. 177 3. DiffServ and IntServ 179 3.1. Differentiated Services 181 Differentiated services or DiffServ [RFC2475] provides a simple, 182 scalable and coarse-grained mechanism to support quality of services 183 on IP networks by classifying and managing network traffic. 185 DiffServ uses DiffServ Code Point (DSCP) which is the first 6 bits of 186 the TOS field [RFC2474] to classify packets when they enter the 187 network and then are separated into different queues. With DiffServ 188 each router handles each packet differently. Per-Hop Forwarding 189 Behavior (PHB) is a way of forwarding a particular flow or group of 190 flows marked with a particular DSCP value using a particular method 191 on a DiffServ node. 193 3.2. Integrated Services 195 IntServ [RFC3175] or integrated services specifies more fine-grained 196 QoS, which is often contrasted with DiffServ's coarse-grained control 197 system. IntServ definitely can support the applications requiring 198 special QoS guarantee if it is deployed in a network, supported by 199 Host OS and integrated with application. However, IntServ works on a 200 small-scale only. When you scale up the network, it is difficult to 201 keep track of all of the reservations and session states. Thus, 202 IntServ is not scalable. Another problem of IntServ is it is not 203 application driven, tedious provisioning cross different network must 204 be done earlier. The provisioning is slow and hard to maintain. 206 4. In-band Signaling 208 In-band signaling messages are carried along with the payload, and it 209 is guaranteed that the signaling follows the same path as the data 210 flow. 212 In-band QoS signaling for IPv6 was discussed by Lawrence Roberts in 213 2005 [I-D.roberts-inband-qos-ipv6]. The requirements of IP in-band 214 signaling was proposed by Jon Haper in 2007 215 [I-D.harper-inband-signalling-requirements]. Telecommunications 216 Industry Association (TIA) published a standard for "QoS Signaling 217 for IP QoS Support and Sender Authentication" in 2006 [TIA]. 219 This draft uses the in-band signaling method proposed by 220 [I-D.han-tsvwg-ip-transport-qos], which offers a solution in IPv6 for 221 QoS service using in-band signaling to guarantee certain level of 222 service quality. Advantages of using in-band signaling and what 223 parameters are carried etc. are discussed in great details. Please 224 refer to [I-D.han-tsvwg-ip-transport-qos] for signaling details, 225 which is not in the scope of this document. 227 5. Design Targets 229 The design targets of the proposal are outlined as follows: 231 1. Service Guarantee: 233 * Provide guaranteed and minimized (queuing) latency for LGS 234 (Latency Guaranteed Service) flows. The maximum latency is 235 guaranteed, minimized and predictable at each hop, if LGS flow 236 rate is confirmed with their pre-claimed parameters 237 (CIR,PIR,CBS,EBS). 239 * Provide guaranteed bandwidth for BGS (Bandwidth Guaranteed 240 Service) flows. The bandwidth of CIR is guaranteed at each 241 hop, if BGS flow rate is confirmed with their pre-claimed 242 parameters (CIR,PIR,CBS,EBS). 244 2. No Starvation: LGS flows will never starve other types of lower 245 priority flows (BGS and BES). BGS flows will never starve BE 246 flows. 248 3. No sacrifice of link utilization: When the total rate of LGS flow 249 is less than the committed rate (sum of CIR of all LGS flows), 250 other class flows (BGS and BES) can use the remained bandwidth. 251 When the total rate of LGS flow is less than the committed rate 252 (sum of CIR of all LGS flows), and, the total rate of BGS flow is 253 less than the committed rate (sum of CIR of all BGS flows), other 254 class flows (BES) can use the remained bandwidth. 256 4. Fairness within the same class: All LGS flows will share the 257 bandwidth within its class. All BGS flows will share the 258 bandwidth within its class. All BE flows will share the 259 bandwidth within BE class. 261 5. Backward compatible with current DiffServ, and can coexist and 262 can be deployed incrementally. 264 6. Processing Procedure 266 6.1. Introduction 268 The section will describe more details about the in-band signaling 269 integrated with DiffServ to achieve the guaranteed service. It is 270 composed of following contents: 272 1. The purpose of in-band signaling for enhanced DiffServ. 274 2. The info carried in the signaling. 276 3. The admission process with in-band signaling. 278 4. User traffic classification. 280 5. User traffic classification and New DSCP class. 282 6. Queuing and Scheduling Consideration. 284 7. Class Based Traffic Shaper. 286 The document [Enhanced_DSCP] has more details for the experiments 287 using the proposal to achieve the latency guaranteed service. The 288 theoretical formula to estimate the maximum latency is given. 289 Different tests with different combination of traffic are done. 290 Results are analyzed and further researches are discussed. 292 6.2. The purpose of in-band signaling 294 The in-band signaling procedures described in 295 [I-D.han-tsvwg-ip-transport-qos] is to make network support new 296 services. There are two types of new services provided: 298 1. Latency Guaranteed Service (LGS): Provide guaranteed and 299 minimized queuing latency. The maximum latency of a LGS flow is 300 guaranteed, minimized and predictable at each hop if the LGS flow 301 rate is confirmed with its pre-claimed parameters (CIR, PIR, CBS, 302 EBS). 304 2. Bandwidth Guaranteed Service (BGS): provide guaranteed bandwidth. 305 The CIR bandwidth of a BGS flow is guaranteed at each hop if the 306 BGS flow rate is confirmed with its pre-claimed parameters. 308 In addition to above, the use of in-band signaling with DiffServ will 309 make the flow level QoS expectation available at each network device 310 on the IP path. Then network device could collect all flows 311 signaling info to form an accurate instruction for QoS programming 312 automatically. Without such automation process, DiffServ will only 313 be able to rely on the network management procedures to configure the 314 QoS for each class at each hop one by one, this is called Per Hop 315 Behavior. 317 6.3. The info carried in in-band signaling 319 The detailed info carried in the signaling was described in the draft 320 [I-D.han-tsvwg-ip-transport-qos]. 322 In order to achieve the service guarantees, admission control is 323 needed for user's service expectation. Also to get the best service 324 guarantee in network, some network device need to do traffic shaping 325 to measure and control traffic for difference service. 327 To satisfy above two requirements, each flow's service expectation 328 and traffic pattern should be carried in the signaling. 330 To describe one or multiple flows traffic character, Single Rate 331 Three Color Marker (srTCM from [RFC2697]) or Two Rate Three Color 332 Marker (trTCM from RFC4115) could be used. The minimum requirement 333 from user's signaling is the Cir (Committed information rate) when 334 srTCM is used, CIR plus PIR (Peak information rate) when trTCM is 335 used. Optionally, the signaling can carry more info about the 336 traffic, such as CBS, EBS. The exact requirements for signaling will 337 be decided by IETF. 339 6.4. Admission process with in-band signaling 341 The admission control should be enforced at any ingress interface 342 connecting to user's device or accepting user's traffic, and also 343 enforced at the egress interfaces that will send the user's traffic 344 to next network device. In addition to other irrelevant admission 345 checking, the admission process for the E-DiffServ minimally has 346 three major steps: 348 1. If a user is allowed to request the desired service described in 349 its in-band signaling. This may include the security, 350 authentication and billing checks. 352 2. After adding the new flow for a user's request, if the total rate 353 for all flows in the same class at the same ingress interface 354 exceeds the total bandwidth allocated for the class for the 355 ingress interface, this allocated bandwidth is from management 356 procedures and is less than the ingress interface link rate. 358 3. After adding the new flow for a user's request, if the total rate 359 for all flows in the same class at the same egress interface 360 exceeds the total bandwidth allocated for the class for the 361 egress interface, this allocated bandwidth is from management 362 procedures and is less than the egress interface link rate. 364 In above admission control process, if a flow is not allowed, the in- 365 band signaling of the flow is updated accordingly to indicate the 366 desired service is rejected, and the in-band signaling will finally 367 notify the user's host. If a flow is allowed, the in-band signaling 368 of the flow will proceed to continue. For the details of how the 369 closed loop control is formed by in-band signaling, please refer to 370 [I-D.han-tsvwg-ip-transport-qos]. 372 6.5. User traffic classification and New DSCP class 374 After passed the admission control process, user's traffic is 375 classified to different class based on its requested service. This 376 is also done at the ingress interface like the admission control. 377 There are two options for the classification: 379 1. For a network without DiffServ enabled, the LGS flows can be 380 classified as EF class to achieve the shortest latency; The BGS 381 flows can be classified as any type of AFxy class; The BE flows 382 can be classified as BE class. 384 2. For a network that DiffServ is enabled, the LGS and BGS flows can 385 be classified as two new class; The BE flows can be classified as 386 BE class. To be backward compatible and not interrupting 387 existing DiffServ services, new DSCP classes are proposed for LGS 388 and BGS. The values are TBD. 390 6.6. User traffic conformity checking 392 After a user's request service passes the admission control and is 393 accepted, user's traffic is still needed to be checked for its 394 conformity. i.e, if the traffic is conforming to the traffic pattern 395 claimed in the service request. 397 This is done by a traffic meter (shaper) associated to ingress 398 interface. The algorithm in the meter is using either srTCM or 399 trTCM. The action of the meter will determine what exact class the 400 traffic will be classified as. Only the Green traffic will be marked 401 to the designated class described in 5.5. Other colored traffic 402 (Yellow or Red) will be classified as lower priority class or just 403 discarded. The exact action is up to the decision of IETF. 405 6.7. Queuing and Scheduling Consideration 407 The most important factor to provide the guaranteed service is the 408 queuing and scheduling selection at egress interface on each router. 409 There are many researches about this topic. The current widely 410 accepted methods are Class based Strict Priority Queuing (PQ) and 411 Weighed Fair Queuing (WFQ). It is recommended that the PQ+WFQ are 412 used for different service flows. PQ is the best candidate to 413 provide the shortest latency for LGS flows. The WFQ can be used for 414 BGS flows. There are two options for the Queuing and Scheduling 415 selection: 417 1. For a network without DiffServ enabled, the LGS flows can be 418 queued into the Highest Priority Queue to achieve the shortest 419 latency; The BGS and BE flows can be queued into different 420 Weighted Fair Queues to share bandwidth. The weight for BGS can 421 be obtained from the sum of all BGS flows' CIR. The weight for 422 BE can be calculated from the link rate deducting the bandwidth 423 allocated for LGS and BGS flows. 425 2. For a network with DiffServ enabled, the LGS flows can be queued 426 into the Secondary Highest Priority Queue just below EF queue; 427 The BGS and BE flows can be queued into different Weighted Fair 428 Queues to share bandwidth with other existing classes. The 429 weight for BGS can be obtained from the sum of all BGS flows' 430 CIR. The weight for BE can be calculated from the link rate 431 deducting the bandwidth allocated for all AFxy classes, LGS and 432 BGS flows. 434 6.8. Class Based Traffic Shaper 436 To guarantee each class's traffic are confirming to the pre-allocated 437 bandwidth or resource for the class, class-based traffic shaper can 438 be used for traffics before they are queued into different queues. 439 Only Green traffic will be queued into the queue described above. 440 Other colored traffic (Yellow or Red) will be queued into a lower 441 priority queue or discard. The exact actions will be decided by 442 IETF. The purpose of using traffic shaper for each class is to 443 protect the service for each class when other class traffic is 444 exceeding its allocation. This is critical to satisfy the design 445 target outlined in section 5. 447 The algorithm for the shaper is similar to the ingress traffic shaper 448 described in section 6.6. The algorithm in the meter is using either 449 srTCM or trTCM. 451 The Traffic Shaper's Parameter such as PIR, CIR, CBS, EBS can be 452 obtained from all flow's traffic parameters embedded into the in-band 453 signaling. i.e, PIR or CIR can be calculated by the sum of all 454 allowed (same class) flow's PIR or CIR values. CBS and EBS can also 455 be obtained from flow's signaling message if it carries, or from 456 management process. The detailed standard will be decided by IETF. 458 7. IANA Considerations 460 The new DSCP values are required to be allocated by IANA. 462 8. Security Considerations 464 TBD. 466 9. References 468 9.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, 472 DOI 10.17487/RFC2119, March 1997, 473 . 475 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 476 Control", RFC 2581, DOI 10.17487/RFC2581, April 1999, 477 . 479 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 480 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 481 May 2017, . 483 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 484 (IPv6) Specification", STD 86, RFC 8200, 485 DOI 10.17487/RFC8200, July 2017, 486 . 488 9.2. Informative References 490 [Enhanced_DSCP] 491 "Enhanced DSCP by In-band Signaling", 2018, 492 . 495 [EPC] 3GPP, "The Evolved Packet Core", 2018, 496 . 499 [HU5G] Huawei, "5G Vision: 100 Billion connections, 1 ms Latency, 500 and 10 Gbps Throughput", 2015, 501 . 503 [I-D.falk-xcp-spec] 504 Falk, A., "Specification for the Explicit Control Protocol 505 (XCP)", draft-falk-xcp-spec-03 (work in progress), July 506 2007. 508 [I-D.han-iccrg-arvr-transport-problem] 509 Han, L. and K. Smith, "Problem Statement: Transport 510 Support for Augmented and Virtual Reality Applications", 511 draft-han-iccrg-arvr-transport-problem-01 (work in 512 progress), March 2017. 514 [I-D.han-tsvwg-cc] 515 Han, L., Qu, Y., and T. Nadeau, "A New Congestion Control 516 in Bandwidth Guaranteed Network", draft-han-tsvwg-cc-00 517 (work in progress), March 2018. 519 [I-D.han-tsvwg-ip-transport-qos] 520 Han, L., Qu, Y., Dong, L., Li, R., Nadeau, T., Smith, K., 521 and J. Tantsura, "Resource Reservation Protocol for IP 522 Transport QoS", draft-han-tsvwg-ip-transport-qos-03 (work 523 in progress), October 2019. 525 [I-D.harper-inband-signalling-requirements] 526 Harper, J., "Requirements for In-Band QoS Signalling", 527 draft-harper-inband-signalling-requirements-00 (work in 528 progress), January 2007. 530 [I-D.ietf-tcpm-dctcp] 531 Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., 532 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 533 Control for Datacenters", draft-ietf-tcpm-dctcp-03 (work 534 in progress), November 2016. 536 [I-D.roberts-inband-qos-ipv6] 537 Roberts, L. and J. Harford, "In-Band QoS Signaling for 538 IPv6", draft-roberts-inband-qos-ipv6-00 (work in 539 progress), July 2005. 541 [I-D.sridharan-tcpm-ctcp] 542 Sridharan, M., Tan, K., Bansal, D., and D. Thaler, 543 "Compound TCP: A New TCP Congestion Control for High-Speed 544 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 545 (work in progress), November 2008. 547 [IPv6_Parameters] 548 IANA, "Internet Protocol Version 6 (IPv6) Parameters", 549 2015, . 552 [QU2016] Qualcomm, "Leading the world to 5G", 2016, 553 . 556 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 557 "Definition of the Differentiated Services Field (DS 558 Field) in the IPv4 and IPv6 Headers", RFC 2474, 559 DOI 10.17487/RFC2474, December 1998, 560 . 562 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 563 and W. Weiss, "An Architecture for Differentiated 564 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 565 . 567 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 568 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 569 . 571 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 572 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 573 RFC 3175, DOI 10.17487/RFC3175, September 2001, 574 . 576 [RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service 577 Two-Rate, Three-Color Marker with Efficient Handling of 578 in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 579 2005, . 581 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 582 Decraene, B., Litkowski, S., and R. Shakir, "Segment 583 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 584 July 2018, . 586 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 587 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 588 . 590 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 591 RFC 8578, DOI 10.17487/RFC8578, May 2019, 592 . 594 [TIA] TIA 1039 Revision A, "QoS Signaling for IP QoS Support and 595 Sender Authentication", 2015, . 599 Appendix A. Acknowledgements 601 TBD. 603 Appendix B. Testing Results 605 The analysis of the queuing delay and testing results can be found at 606 [Enhanced_DSCP] . 608 Authors' Addresses 609 Lin Han 610 Futurewei Technologies 611 2330 Central Expressway 612 Santa Clara, CA 95050 613 USA 615 Email: lin.han@futurewei.com 617 Yingzhen Qu 618 Futurewei Technologies 619 2330 Central Expressway 620 Santa Clara, CA 95050 621 USA 623 Email: yingzhen.qu@futurewei.com 625 Richard Li 626 Futurewei Technologies 627 2330 Central Expressway 628 Santa Clara, CA 95050 629 USA 631 Email: richard.li@futurewei.com