idnits 2.17.1 draft-chen-detnet-sr-based-bounded-latency-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: ---------------------------------------------------------------------------- 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 (May 7, 2019) is 1816 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.geng-detnet-conf-yang' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'I-D.geng-detnet-info-distribution' is defined on line 545, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-finn-detnet-bounded-latency-03 == Outdated reference: A later version (-04) exists of draft-geng-detnet-info-distribution-03 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-12 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 M. Chen 3 Internet-Draft X. Geng 4 Intended status: Informational Huawei 5 Expires: November 8, 2019 Z. Li 6 China Mobile 7 May 7, 2019 9 Segment Routing (SR) Based Bounded Latency 10 draft-chen-detnet-sr-based-bounded-latency-01 12 Abstract 14 One of the goals of DetNet is to provide bounded end-to-end latency 15 for critical flows. This document defines how to leverage Segment 16 Routing (SR) to implement bounded latency. Specifically, the SR 17 Identifier (SID) is used to specify transmission time (cycles) of a 18 packet. When forwarding devices along the path follow the 19 instructions carried in the packet, the bounded latency is achieved. 20 This is called Cycle Specified Queuing and Forwarding (CSQF) in this 21 document. 23 Since SR is a source routing technology, no per-flow state is 24 maintained at intermediate and egress nodes, SR-based CSQF naturally 25 supports flow aggregation that is deemed to be a key capability to 26 allow DetNet to scale to large networks. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 8, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Cycle Specified Queuing and Forwarding . . . . . . . . . . . 4 70 3.1. CSQF Basic Concepts . . . . . . . . . . . . . . . . . . . 4 71 3.2. CSQF Queuing Model . . . . . . . . . . . . . . . . . . . 5 72 3.3. CSQF Timing Model . . . . . . . . . . . . . . . . . . . . 7 73 3.4. Congestion Protection and Resource Reservation . . . . . 8 74 3.5. An Example of CSQF . . . . . . . . . . . . . . . . . . . 9 75 4. Segment Routing Extensions for CSQF . . . . . . . . . . . . . 10 76 4.1. Time Aware Adjacency Segment(TA-Adj-SID) . . . . . . . . 11 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 8.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 Deterministic Networking (DetNet) [I-D.ietf-detnet-architecture] is 88 defined to provide end-to-end bounded latency and extremely low 89 packet loss rates for critical flows. For a specific path, the end- 90 to-end latency consists of two parts: 1) the accumulated latency on 91 the wire, 2) the accumulated latency of nodes along the path. The 92 former can be considered as constant once the path has been 93 determined. The latter is contributed by the latency within each 94 node along the path. So, to guarantee the end-to-end bounded 95 latency, control the bounded latency within a node is the key. If 96 every node along the path can guarantee bounded latency, then end-to- 97 end bounded latency can be achieved. 99 [I-D.finn-detnet-bounded-latency] gives a framework that describes 100 how bounded latency and zero congestion loss are achieved. It 101 introduces a parameterized timing model that can be used by DetNet 102 solutions by selecting a corresponding Quality of Service (QoS) 103 algorithm and resource reservation algorithm to achieve the bounded 104 latency and zero congestion loss goal. 106 This document defines how to leverage Segment Routing (SR) [RFC8402] 107 to implement bounded latency, which is called Time Aware Segment 108 Routing(TA-SR). A segment is associated with a topological 109 instruction, which instruct a node to forward the packet via a 110 specific outgoing interface, as it is defined in [RFC8402]. At the 111 same time, the segment is also associated with DetNet bounded latency 112 service. Specifically, the segment ID(SID) is used to carry and 113 specify the "sending time" of a packet, and some mechanisms can be 114 used to ensure that the packet will be transmitted in that specified 115 period of sending time, which is called Time Aware Segment 116 Routing(TA-SR). 118 The TA-SR architecture supports any type of control plane: 119 distributed (IS-IS or OSPF or BGP), centralized (NETCONF or PCEP or 120 BGP), or hybrid (PCEP or BGP). 122 The TA-SR architecture can be instantiated on various data planes, 123 including TA-SR over MPLS (TA-SR MPLS) or TA-SR over IPv6 (TA-SRv6). 125 2. Terminology 127 All the terminologies used in this document are extensions of 128 [RFC8402]. 130 Time Aware Segment: 132 Time Aware SID: 134 TA-SR MPLS SID: 136 TA-SRv6 SID: 138 TA-SR Domain: 140 TA-SR Globle Block (SRGB): 142 TA-SR Local Block (SRGB): 144 TA-Adjacency Segment: 146 Forwarding Time Base: besides: the node uses the SID as an entry to 147 get the Egress interface with Forwarding Information Base(FIB); 148 Similarl, the node can use the SID as an entry to get the sending 149 time of the packet, with Forwarding Time Base. 151 3. Cycle Specified Queuing and Forwarding 153 3.1. CSQF Basic Concepts 155 By specifying the sending cycle of a packet at a node and making sure 156 that the packet will be transmitted in that cycle, CSQF can achieve 157 bounded latency within the node. By specifying the sending cycle at 158 every node along a path, the end-to-end bounded latency can be 159 achieved. 161 To support CSQF, similar to Cyclic Queuing and Forwarding (CQF) 162 [IEEE802.1Qch], the sending time of an output interface of a node is 163 divided into a series of equal time intervals with the duration of T. 164 Each time interval is called a "cycle", and each cycle corresponds to 165 a queue. During a cycle, only the corresponding queue is open and 166 all the packets in that queue will be transmitted. CSQF can not only 167 control the bounded latency at every node along a path, but regulate 168 the traffic at each node as planned. Therefore, no congestion will 169 occur. 171 Figure 1 provides an overview of CSQF. 173 +---+ +---+ +---+ +---+ 174 | A |---| B |---| C |---| D | 175 +-+-+ +---+ +---+ +---+ 177 A |---X---+-------+-------+-------+-------+-------+-------| 179 B |-------+-------+---X---+-------+-------+-------+-------| 181 C |-------+-------+-------+-------+---X---+-------+-------| 183 E |-------+-------+-------+-------+-------+-------+---X---| 185 cycle1 cycle2 cycle3 cycle4 cycle5 cycle6 cycle7 187 DetNet path: A->B->C->D 188 Specified cycle list of packet X: <1, 3, 5, 7> 190 Figure 1: CSQF Overview 192 CSQF has the following characteristics: 194 o The sending time (cycle) of a packet at each node along a path is 195 specified so that the packet will be transmitted in the specified 196 cycles, hence to guarantee the end-to-end bounded latency. 198 o The specified cycles are calculated by fully considering the link 199 delay, processing delay and the available cycle resources, 200 resulting in no bandwidth waste and no congestion (cycle-based 201 traffic regulation). 203 o Segment routing (SR) is used. Specifically, a SID is used to 204 indicate in which cycle and to which output interface that a 205 packet is specified to transmit, and an SR SID list is used to 206 carry the specified cycles along a path. With SR, there is no 207 per-flow states maintained at the intermediate and egress node. 208 As a result, scalability is greatly improved compared to a 209 solution that maintains flow state at each hop. 211 o Flow aggregation is naturally supported by introducing SR and 212 cycle-based scheduling. 214 3.2. CSQF Queuing Model 216 In Cyclic Queuing and Forwarding (CQF) [IEEE802.1Qch], time is 217 divided into numbered time intervals, and each time interval is 218 called a cycle; the critical traffic is then transmitted and queued 219 for transmission along a path in a cyclic manner. With CQF, the 220 delays experienced by a given packet are as follows: 222 o The maximum end-to-end delay = (N+1) * T; 224 o The minimum end-to-end delay = (N-1) * T; 226 o Where the N is the number of hops and T is the duration of the 227 cycle. 229 CQF assumes that a packet is transmitted from an upstream node in a 230 cycle and the packet must be received at the downstream node in the 231 same cycle, and it must be transmitted in the next cycle to the 232 nexthop node. This assumption leads to very low bandwidth 233 utilization when the link delay, processing delay, etc., factors 234 cannot be considered as trivial. To guarantee this assumption, more 235 bandwidth has to be reserved as a guard band for each cycle, and the 236 effective bandwidth for DetNet service will be greatly reduced. 238 CSQF improves on CQF by explicitly specifying the sending cycles at 239 every node along the path. This relieves the limitation that the 240 sending (at the upstream node) and receiving (at the downstream node) 241 have to be in the same cycle. For CSQF, the cycle to use depends on 242 traffic planning and path calculation. The path calculation will 243 consider the available cycle resources, bandwidth, and delay 244 constraints. 246 +--------+ +--------+ +--------+ 247 Queue1 | SQ --> --> TQ | --> RQ | 248 +--------+ +--------+ +--------+ 249 Queue2 --> RQ | | SQ --> --> TQ | 250 +--------+ +--------+ +--------+ 251 Queue3 --> TQ | --> RQ | | SQ --> 252 +--------+ +--------+ +--------+ 253 Cycle 1 Cycle2 Cycle3 255 +--->SQ---->RQ---->TQ----> 256 | | 257 +------------<-----------+ 259 Figure 2: CSQF Queuing Model 261 For CSQF, three queues (in theory, two or more queues work as well) 262 for each output interface are used. During a particular cycle, only 263 one queue is open and the packets in that queue will be transmitted. 264 This queue is called the sending queue (SQ). The other two queues 265 are closed and can enqueue packets. One of them is called the 266 receiving queue (RQ). The third queue is called the tolerating queue 267 (TQ). 269 The RQ is used for receiving the packets that are expected to be 270 transmitted in the next cycle. The TQ is used for tolerating the 271 packets that come a bit early due to processing delay variation 272 (processing jitter) or other reasons (e.g., packets are not 273 transmitted as required by the traffic specification). Both RQ and 274 TQ can have the capability to absorb a certain amount of processing 275 jitter and traffic bursts. The upper bound of the absorbing capacity 276 is 2T. In order to increase the jitter/burst absorbing capacity, a 277 four or more-queue model can be used. If the processing delay and 278 traffic bursts are small, two-queue model works as well. 280 The roles of the three queues are not fixed, and on the contrary, 281 they rotate with each cycle change. As showed in Figure 2, during 282 cycle 1, queue 1 is SQ, queue 2 is RG and queue 3 is TQ; during cycle 283 2, queue 1 is TQ, queue 2 is SQ and queue 3 is RQ, during cycle 3, 284 queue 1 is RQ, queue 2 is TQ and queue 3 is SQ. That means, for a 285 particular queue, its role will rotate as "...->SQ->RQ->TQ->SQ->...", 286 the starting role of a queue can be any one of the three roles. 288 In CSQF, a cycle corresponds to a queue. There are several ways to 289 do cycle to queue mapping. The simplest mapping between cycles and 290 queues is 1:1 mapping. There could be N:1 mapping, but that requires 291 more identifiers, which in the case of segment routing, would require 292 more SIDs. This document does not specify which mapping should be 293 used. The mapping choice is left to the operator. 295 3.3. CSQF Timing Model 297 DetNet relay node A DetNet relay node B 298 +-------------------+ +-------------------+ 299 | Reg. Queue | | Reg. Queue | 300 | +-+-+ +-+-+-+ | | +-+-+ +-+-+-+ | 301 -->+ | | | | | | + +------->+ | | | | | | + +--> 302 | +-+-+ +-+-+-+ | | +-+-+ +-+-+-+ | 303 | | | | 304 +-------------------+ +-------------------+ 305 -->|<->|<-->|<---->|<->|<------>|<->|<-->|<---->|<->|<-- 306 2,3 4 5 6 1 2,3 4 5 6 1 2,3 307 1: Output delay 3: Preemption delay 308 2: Link delay 4: Processing delay 309 5: Regulation delay 6: Queuing delay. 311 Figure 3: Timing model for DetNet 313 The DetNet timing model in Figure 3 is defined in 314 [I-D.finn-detnet-bounded-latency]. It details the delays that a 315 packet can experience from hop to hop. There are six delays, the 316 detailed explanation of which can be found in 317 [I-D.finn-detnet-bounded-latency]. This document simplifies the 318 above model as follows: 320 DetNet relay node A DetNet relay node B 321 +-------------------+ +-------------------+ 322 | Reg. Queue | | Reg. Queue | 323 | +-+-+ +-+-+-+ | | +-+-+ +-+-+-+ | 324 -->+ | | | | | | + +------->+ | | | | | | + +--> 325 | +-+-+ +-+-+-+ | | +-+-+ +-+-+-+ | 326 | | | | 327 +-------------------+ +-------------------+ 328 -->|<->|<------------->|<------>|<->|<------------->|<-- 329 2 3 1 2 3 1 2 330 1: Queuing delay 331 2: Link delay 332 3: Processing delay 334 Figure 4: Simplified Timing model for DetNet 336 In this simplified timing model, only three delays are defined. The 337 queuing delay in this new model includes the output delay, regulation 338 delay, and queuing delay that are defined in the DetNet timing model 339 (Figure 3). The link delay defined in this document includes the 340 link delay and the preemption delay defined in 341 [I-D.finn-detnet-bounded-latency]. The processing delay is the same 342 as defined in [I-D.finn-detnet-bounded-latency]. 344 To further simplify the model, it assumes that the link delay only 345 depends on the distance of the link. Once the DetNet path has been 346 determined, the link delay can be considered as constant. The 347 processing delay and queuing delay are variable but have their upper 348 bounds. 350 For the processing delay, there are two bounds: minimum processing 351 delay (Min-P-Delay) and maximum processing delay (Max-P-Delay). 353 o Thus, the maximum processing jitter (Max-P-Jitter) = Max-P-Delay - 354 Min-P-Delay. 356 As described in Section 2.2, both the RQ and TQ can be used for 357 absorbing processing jitter, and the upper bound of the absorbing 358 capacity is 2T. So, if the processing jitter is less than 2T, the 359 three-queue model can work. Otherwise, more buffer is needed to 360 absorb the jitter, through increasing the duration of the cycle or by 361 adding more queues. Increasing the duration of the cycles is 362 equivalent to increasing the depth of the queues (adding more buffer 363 for each queue). 365 With above, for CSQF, the delays experienced by a given packet are as 366 follows: 368 o The maximum end-to-end delay = Link delay + N * (Max-P-Delay + 369 2T); 371 o The maximum end-to-end jitter = 2T; 373 o Where N is the number of hops and T is the duration of a cycle. 375 3.4. Congestion Protection and Resource Reservation 377 Congestion protection is the key for bounded latency and zero 378 congestion loss. An essential component of DetNet is Traffic 379 Engineering (TE), so that dedicated resources can be reserved for the 380 exclusive use of DetNet flows. To avoid congestion, two or more 381 flows must be prevented from contending for the same resource. For 382 normal TE, the critical resource is bandwidth, but in the case of 383 CSQF, the critical resource is interface occupation time. Bandwidth 384 is an average value, which can generally guarantee the quality of 385 service generally, but bursts and congestion may still occur. By 386 comparison, the interface occupation time is an absolute value, which 387 can avoid packet packets conflicting for the same resource by 388 controller computation and time allocation for different flows. The 389 unit of time allocation is the cycle, and a Traffic Specification, 390 the flow transmission description, is necessary for the computation. 392 CSQF uses segment routing SIDs to carry the time allocation 393 information (the cycle), and it ensures that a node can schedule 394 different packets without conflict and forward the packets at the 395 proper time. The resource reservation is not explicitly implemented 396 by a control plane protocol, such as Resource Reservation Protocol - 397 Traffic Engineering (RSVP-TE) or Stream Reservation Protocol (SRP). 398 Rather, it is guaranteed by the SR controller, which maintains the 399 status of different flows and time occupation of all the network 400 devices in the domain. This is called the Virtual Resource 401 Reservation (VRR) in this document. 403 3.5. An Example of CSQF 405 +---+ +---+ +---+ +---+ 406 | A |----| B |----| C |----| E | 407 +-+-+ +---+ +-+-+ +---+ 408 | +---+ | 409 +------| D |------+ 410 +---+ 412 A |---X---+-------+-------+-------+-------+-------+-------| 414 B |-------+-------+---X---+-------+-------+-------+-------| 416 C |-------+-------+-------+-------+---X---+-------+-------| 418 E |-------+-------+-------+-------+-------+-------+---X---| 420 cycle1 cycle2 cycle3 cycle4 cycle5 cycle6 cycle7 422 DetNet path: A->B->C->E 423 Specified cycle list <1, 3, 5, 7> 425 Figure 5: CSQF Example 427 As showed in Figure 5, there is a DetNet path (A->B->C->E), and a 428 packet (X) is expected to be transmitted in cycle 1 at node A, in 429 cycle 3 at node B, in cycle 5 at node C and in cycle 7 at node E. A 430 cycle list <1, 3, 5, 7> is attached to the packet, and the packet 431 will be transmitted along the path as the specified cycles. 433 Given the topology as above, assume the duration of a cycle is 10us; 434 the link delays between nodes are the same (e.g., 100us); the minimum 435 processing delay at each node = 10us, the maximum processing delay at 436 each node is 20us, so the maximum processing jitter is 10us. 438 For a given packet that is transmitted along the path(A->B->C->D->E), 439 the experienced maximum end-to-end delay is: 441 (N-1) * link delay + N * (maximum processing delay + 2T) 443 = 3*100 + 4* 40 445 = 460 (us) 447 The maximum end-to-end jitter is always 2T (20us). 449 4. Segment Routing Extensions for CSQF 451 This document defines a new segment that is called a Cycle Segment, 452 which is used to identify a cycle. A Cycle Segment is a local 453 segment and is allocated from the Segment Routing Local Block 454 (SRLB)[RFC8402]. 456 A Cycle Segment has two meanings: 1) identify an interface/link, just 457 like the adjacency segment does; 2) identify a cycle of the 458 interface/link. To specify to which interface and in which cycle a 459 packet should be transmitted, it just needs to attach a Cycle Segment 460 to the packet. By attaching a list of Cycle Segments to a packet, it 461 can not only implement the explicit route of the packet that is 462 required by DetNet [I-D.ietf-detnet-architecture], but also specify 463 the sending cycle at each node along the path without maintaining 464 per-flow states at the intermediate and egress nodes. Hence, it 465 naturally supports flow aggregation, and that allows DetNet to 466 support large number of DetNet flows and scale to large networks. 468 Normally, several SR SIDs are required to be allocated for each CSQF 469 capable interface. How many SIDs are allocated depends on how many 470 cycles are used. Given a three-queue model and a 1:1 cycle to queue 471 mapping is used, three SIDs will be allocated for each CSQF capable 472 interface. For example, given node A, SR-MPLS SIDs 1001, 1002, and 473 1003 are allocated to one of its interfaces. SID 1001 identifies 474 cycle 1, SID 1002 identifies cycle 2, SID 1003 identifies cycle 3. 476 The SR [RFC8402] can be instantiated on various data planes. There 477 are two data-plane instantiations of SR: SR over MPLS (SR-MPLS) and 478 SR over IPv6 (SRv6). Both SR-MPLS and SRv6 SIDs can be used for CSQF 479 cycle identification. The mapping (IGP extensions) between a cycle 480 and a SID will be defined in a separate document. 482 4.1. Time Aware Adjacency Segment(TA-Adj-SID) 484 An Time Aware Adjacency segment is an IGP segment attached to a 485 specified sending time of a unidirectional adjacency, which 486 inheriting all the definitions of Adjacency segment defined in 487 [RFC8402], adding new capability: 489 When a node binds a group of AT-Adj-SIDs V1-Vn to a local data-link 490 L, the node MUST install the following FIB entry: 492 Incoming Active Segment: V1-Vn 494 Ingress Operation: NEXT 496 Egress Interface: L 498 When a node binds an TA-Adj-SID V1 to sending time: Cycle 1, the node 499 MUST install the following Forwarding Time Base (FTB) entry: 501 Incoming Active Segment: V1 503 Sending Time: Cycle 1 505 Output Queue: Queue 1 507 So a packet with TA-Adj-SID V1 will be transmitted go through output 508 queue 1 of egress interface L within cycle 1. 510 5. IANA Considerations 512 This document makes no request of IANA. 514 Note to RFC Editor: this section may be removed on publication as an 515 RFC. 517 6. Security Considerations 519 7. Acknowledgements 521 The authors would like to thank Andrew G. Malis, Norman Finn for his 522 review, suggestion and comments to this document. 524 8. References 526 8.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, 530 DOI 10.17487/RFC2119, March 1997, 531 . 533 8.2. Informative References 535 [I-D.finn-detnet-bounded-latency] 536 Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga, 537 B., and J. Farkas, "DetNet Bounded Latency", draft-finn- 538 detnet-bounded-latency-03 (work in progress), March 2019. 540 [I-D.geng-detnet-conf-yang] 541 Geng, X., Chen, M., Li, Z., and R. Rahman, "DetNet 542 Configuration YANG Model", draft-geng-detnet-conf-yang-06 543 (work in progress), October 2018. 545 [I-D.geng-detnet-info-distribution] 546 Geng, X., Chen, M., and Z. Li, "IGP-TE Extensions for 547 DetNet Information Distribution", draft-geng-detnet-info- 548 distribution-03 (work in progress), October 2018. 550 [I-D.ietf-detnet-architecture] 551 Finn, N., Thubert, P., Varga, B., and J. Farkas, 552 "Deterministic Networking Architecture", draft-ietf- 553 detnet-architecture-12 (work in progress), March 2019. 555 [IEEE802.1Qch] 556 IEEE, "IEEE, "Cyclic Queuing and Forwarding (IEEE Draft 557 P802.1Qch)", 2017, 558 .", 559 2016. 561 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 562 Decraene, B., Litkowski, S., and R. Shakir, "Segment 563 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 564 July 2018, . 566 Authors' Addresses 568 Mach(Guoyi) Chen 569 Huawei 571 Email: mach.chen@huawei.com 572 Xuesong Geng 573 Huawei 575 Email: gengxuesong@huawei.com 577 Zhenqiang Li 578 China Mobile 580 Email: lizhenqiang@chinamobile.com