idnits 2.17.00 (12 Aug 2021) /tmp/idnits26742/draft-eckert-detnet-mpls-tc-tcqf-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 : ---------------------------------------------------------------------------- == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 255: '... LSR MUST support 3 and 4 cycles. T...' RFC 2119 keyword, line 259: '... MUST support configuration of cycle...' RFC 2119 keyword, line 283: '... used, the value MUST be -1. This is ...' RFC 2119 keyword, line 313: '...tcqf-mpls-tc-tag MUST NOT use values t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 233 has weird spacing: '...if-name if:...' == Line 235 has weird spacing: '...f-cycle uint8...' == Line 236 has weird spacing: '...f-cycle uint8...' == Line 241 has weird spacing: '...w cycle uint8...' == Line 242 has weird spacing: '...--rw tc uin...' -- The document date (8 September 2021) is 255 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: 'Network' is mentioned on line 140, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-10 == Outdated reference: A later version (-10) exists of draft-ietf-detnet-bounded-latency-07 -- No information found for draft-qiang-DetNet-large-scale-DetNet - is the name correct? Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DETNET T. Eckert 3 Internet-Draft Futurewei Technologies USA 4 Intended status: Standards Track S. Bryant 5 Expires: 12 March 2022 University of Surrey ICS 6 8 September 2021 8 Deterministic Networking (DetNet) Data Plane - MPLS TC Tagging for 9 Cyclic Queuing and Forwarding (MPLS-TC TCQF) 10 draft-eckert-detnet-mpls-tc-tcqf-00 12 Abstract 14 This memo defines the use of the MPLS TC field of MPLS Label Stack 15 Entries (LSE) to support cycle tagging of packets for Multiple Buffer 16 Cyclic Queuing and Forwarding (TCQF). TCQF is a mechanism to support 17 bounded latency forwarding in DetNet network. 19 Target benefits of TCQF include low end-to-end jitter, ease of high- 20 speed hardware implementation, optional ability to support large 21 number of flow in large networks via DiffServ style aggregation by 22 applying TCQF to the DetNet aggregate instead of each DetNet flow 23 individually, and support of wide-area DetNet networks with arbitrary 24 link latencies and latency variations. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 12 March 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Using TCQF with DetNet MPLS (informative) . . . . . . . . . . 3 61 3. Data model and tag processing for MPLS TC TCQF (normative) . 6 62 4. TCQF with labels stack operations (normative) . . . . . . . . 8 63 5. TCQF Pseudocode (normative) . . . . . . . . . . . . . . . . . 8 64 6. TCQF YANG Model (normative) TBD . . . . . . . . . . . . . . . 9 65 7. Computing cycle mappings (informative) . . . . . . . . . . . 9 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 10. Informative References . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 Cyclic Queuing and Forwarding [CQF], is an IEEE standardized queuing 74 mechanism in support of deterministic bounded latency. See also 75 [I-D.ietf-detnet-bounded-latency], Section 6.6. 77 CQF benefits for Deterministic QoS include the tightly bounded jitter 78 it provides as well as the per-flow stateless operation, minimizing 79 the complexity of high-speed hardware implementations and allowing to 80 support on transit hops arbitrary number of DetNet flow in the 81 forwarding plane because of the absence of per-hop, per-flow QoS 82 processing. In the terms of the IETF QoS architecture, CQF can be 83 called DiffServ QoS technology, operating only on a traffic 84 aggregate. 86 CQFs is limited to only limited-scale wide-area network deployments 87 because it cannot take the propagation latency of links into account, 88 nor potential variations thereof. It also requires very high 89 precision clock synchronization, which is uncommon in wide-area 90 network equipment beyond mobile network fronthaul. See 91 [I-D.eckert-detnet-bounded-latency-problems] for more details. 93 This specification introduces and utilizes an enhanced form of CQF 94 where packets are tagged with a cycle identifier, and a limited 95 number of cycles, e.g.: 3...7 are used to overcome these distance and 96 clock synchronization limitations. Because this memo defines how to 97 use the TC field of MPLS LSE as the tag to carry the cycle 98 identifier, it calls this scheme TC Tagged multiple buffer CQF (TC 99 TCQF). See [I-D.qiang-DetNet-large-scale-DetNet] and 100 [I-D.dang-queuing-with-multiple-cyclic-buffers] for more details of 101 the theory of operations of TCQF. Note that TCQF is not necessarily 102 limited to deterministic operations but could also be used in 103 conjunction with congestion controlled traffic, but those 104 considerations are outside the scope of this memo. 106 TCQF is likely especially beneficial when MPLS networks are designed 107 to avoid per-hop, per-flow state even for traffic steering, which is 108 the case for networks using SR-MPLS [RFC8402] for traffic steering of 109 MPLS unicast traffic and/or BIER-TE [I-D.ietf-bier-te-arch] for tree 110 engineering of MPLS multicast traffic. In these networks, it is 111 specifically undesirable to require per-flow signaling to P-LSR 112 solely for DetNet QoS because such per-flow state is unnecessary for 113 traffic steering and would only be required for the bounded latency 114 QoS mechanism and require likely even more complex hardware and 115 manageability support than what was previously required for per-hop 116 steering state (e.g. In RSVP-TE). Note that the DetNet architecture 117 [RFC8655] does not include full support for this DiffServ model, 118 which is why this memo describes how to use MPLS TC TCQF with the 119 DetNet architecture per-hop, per-flow processing as well as without 120 it. 122 2. Using TCQF with DetNet MPLS (informative) 124 This section gives an overview of how the operations of T-CQF relates 125 to the DetNet architecture. We first revisit QoS with DetNet in the 126 absence of T-CQF. 128 DetNet MPLS Relay Transit Relay DetNet MPLS 129 End System Node Node Node End System 130 T-PE1 S-PE1 LSR-P S-PE2 T-PE2 131 +----------+ +----------+ 132 | Appl. |<------------ End-to-End Service ----------->| Appl. | 133 +----------+ +---------+ +---------+ +----------+ 134 | Service |<--| Service |-- DetNet flow --| Service |-->| Service | 135 +----------+ +---------+ +----------+ +---------+ +----------+ 136 |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| 137 +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ 138 : Link : / ,-----. \ : Link : / ,-----. \ 139 +........+ +-[ Sub- ]-+ +......+ +-[ Sub- ]-+ 140 [Network] [Network] 141 `-----' `-----' 142 |<- LSP -->| |<-------- LSP -----------| |<--- LSP -->| 144 |<----------------- DetNet MPLS --------------------->| 146 Figure 1: A DetNet MPLS Network 148 The above Figure 1, is copied from [RFC8964], Figure 2, and only 149 enhanced by numbering the nodes to be able to better refer to them in 150 the following text. 152 Assume a DetNet flow is sent from T-PE1 to T-PE2 across S-PE1, LSR, 153 S-PE2. In general, bounded latency QoS processing is then required 154 on the outgoing interface of T-PE1 towards S-PE1, and any further 155 outgoing interface along the path. When T-PE1 and S-PE2 know that 156 their next-hop is a service LSR, their DetNet flow label stack may 157 simply have the DetNet flows Service Label (S-Label) as its Top of 158 Stack (ToS) LSE, explicitly indicating one DetNet flow. 160 On S-PE1, the next-hop LSR is not DetNet aware, which is why S-PE1 161 would need to send a label stack where the S-Label is followed by a 162 Forwarding Label (F-Label), and LSR-P would need to perform bounded 163 latency based QoS on that F-Label. 165 For bounded latency QoS mechanisms relying on per-flow regulator 166 state, such as in [TSN-ATS], this requires the use of a per-detnet 167 flow F-Label across the network from S-PE1 to S-PE2, for example 168 through RSVP-TE [RFC3209] enhanced as necessary with QoS parameters 169 matching the underlying bounded latency mechanism (such as 170 [TSN-ATS]). 172 With TC TCQF, a sequence of LSR and DetNet service node implements TC 173 TCQF, ideally from T-PE1 (ingress) to T-PE2 (egress). The ingress 174 node needs to perform per-DetNet-flow per-packet "shaping" to assign 175 each packet of a flow to a particular TCQF cycle. This ingress-edge- 176 function is currently out of scope of this document (TBD), but would 177 be based on the same type of edge function as used in CQF. 179 All LSR/Service node after the ingress node only have to map a 180 received TCQF tagged DetNet packet to the configured cycle on the 181 output interface, not requiring any per-DetNet-flow QoS state. These 182 LSR/Service nodes do therefore also not require per-flow interactions 183 with the controller plane for the purpose of bounded latency. 185 Per-flow state therefore is therefore only required on nodes that are 186 DetNet service nodes, or when explicit, per-DetNet flow steering 187 state is desired, instead of ingress steering through e.g.: SR-MPLS. 189 Operating TCQF per-flow stateless across a service node, such as 190 S-PE1, S-PE2 in the picture is only an option. It is of course 191 equally feasible to Have one TCQF domain from T-PE1 to S-PE2, start a 192 new TCQF domain there, running for example up to S-PE2 and start 193 another one to T-PE2. 195 A service node must act as an egress/ingress edge of a TCQF domain if 196 it needs to perform operations that do change the timing of packets 197 other than the type of latency that can be considered in 198 configuration of TCQF (see Section 7). 200 For example, if T-PE1 is ingress for a TCQF domain, and T-PE2 is the 201 egress, S-PE1 could perform the DetNet Packet Replication Function 202 (PRF) without having to be a TQCF edge node as long as it does not 203 introduce latencies not included in the TCQF setup and the controller 204 plane reserves resources for the multitude of flows created by the 205 replication taking the allocation of resources in the TCQF cycles 206 into account. 208 Likewise, S-PE2 could perform the Packet Elimination Function without 209 being a TCQF edge node as this most likely does not introduce any 210 non-TCQF acceptable latency - and the controller plane accordingly 211 reserves only for one flow the resources on the S-PE2->T-PE2 leg. 213 If on the other hand, S-PE2 was to perform the Packet Reordering 214 Function (PRF), this could create large peaks of packets when out-of- 215 order packets are released together. A PRF would either have to take 216 care of shaping out those bursts for the traffic of a flow to again 217 conform to the admitted CIR/PIR, or else the service node would have 218 to be a TCQF egress/ingress, performing that shaping itself as an 219 ingress function. 221 3. Data model and tag processing for MPLS TC TCQF (normative) 223 module ietf-detnet-tcqf 224 augment TBD 225 +--rw tcqf-config 226 | +--rw cycles uint16 227 | +--rw cycle-time uint16 228 | +--rw cycle-clock-offset uint32 229 | +--rw tcqf-if-config* [oif-name] 230 | +--rw oif-name if:interface-ref 231 | +--rw cycle-clock-offset int32 232 | +--rw tcqf-iif-cycle-map* [iif-name] 233 | +--rw iif-name if:interface-ref 234 | +--rw iif-cycle-map* [iif-cycle] 235 | +--rw iif-cycle uint8 236 | +--rw oif-cycle uint8 237 | 238 +--rw tcqf-mpls-tc-tag* [name] 239 +--rw name if:interface-ref 240 +--rw cycle* [cycle] 241 +--rw cycle uint8 242 +--rw tc uint8 244 Figure 2: TCQF Data Model 246 tcqf-config is the router/LSR wide configuration of TCQF parameters, 247 independent of the tagging of the method with which cycles are tagged 248 on any interface. This YANG model represents a single TQCF domain, 249 which is a set of interfaces acting both as ingress (iif) and egress 250 (oif) interfaces, capable to forward TCQF packets amongst each other. 251 When multiple independent instances or TCQF domains are used, they 252 can have separate parameters. 254 cycles is the number of cycles used across all interfaces. router/ 255 LSR MUST support 3 and 4 cycles. To support interfaces with MPLS TC 256 tagging, 7 or less cycles must be used. 258 The cycle time is cycle-time in units of micro-seconds. router/LSR 259 MUST support configuration of cycle-times of 260 20,50,100,200,500,1000,2000 usec. 262 Cycles start at an offset of cycle-clock-offset in units of nsec as 263 follows. Let clock1 be a timestamp of the local reference clock for 264 TCQF, at which cycle 1 starts, then: 266 cycle-clock-offset = (clock1 mod (cycle-time * cycles) ) 267 The local reference clock is expected to be synchronized with the 268 neighboring nodes. cycle-clock-offset can be configurable, or it may 269 be derived from immutable properties of the implementation, in which 270 case it is read-only. 272 tcqf-if-config is the optional per-interface configuration of TCQF 273 parameters. 275 The cycle-clock-offset in tcqf-oif-config may be different from the 276 router/LSR wide cycle-clock-offset, for example, when interfaces are 277 on line cards with independently synchronized clocks, or when non- 278 uniform ingress-to-egress propagation latency over a complex router/ 279 LSR fabric makes it beneficial to allow per-egress interface or line 280 card configuration of cycle-clock-offset. 282 If cycle-clock-offset is unused and therefore the router/LSR wide 283 cycle-clock-offset is used, the value MUST be -1. This is the only 284 permitted negative number. 286 tcqf-iif-cycle-map is defining how to map the cycle iif-cycle of a 287 packet received from an incoming interface (iif-name) once the LSR 288 has determined that the packet needs to be sent to oif-name and sent 289 with TCQF. The packet is then assigned to cycle oif-cycle on oif- 290 name. 292 Note that all parameters so far allow for different methods of 293 tagging the cycle in the packet across different interfaces and 294 allowing TCQF to operate across them, even if future work would 295 introduce different tagging methods than the following MPLS TC 296 mapping. 298 tcqf-mpls-tc-tag defines the mapping of cycle number to MPLS TC tag. 299 This mapping is configured for all interfaces that use MPLS TC 300 tagging. When a packet is received with a ToS LSE indicating a TC 301 for which there is a mapping to a cycle in tcqf-mpls-tc-tag, then 302 this packet is assigned to the configured cycle. 304 If the packet is forwarded to another interface with tcqf configured, 305 the cycle number derived from mapping the received ToS LSE TC field 306 to the cycle number when receiving the packet will be mapped 307 according to tcqf-oif-config after all label stack changes are 308 applied and the packet is to be sent. If that outgoing interface is 309 also using MPLS TC TCQF tagging, then the TC value of the ToS LSE 310 will be rewritten according to the tcqf-mpls-tc-tag configuration of 311 that outgoing interface. 313 tc in tcqf-mpls-tc-tag MUST NOT use values to be used for non-TCQF 314 traffic, most commonly 0 for Best Effort (BE) traffic. 316 4. TCQF with labels stack operations (normative) 318 TCQF QoS as defined here is in the terminology of [RFC3270] a TC- 319 Inferred-PSC LSP (E-LSP) behavior. Packets are determined to belong 320 to the TCQF PSC solely based on the TC of he received packet. 322 Packets originated into the TCQF PSC on the ingress LSR are assumed 323 for the purpose of this specification to be received from an internal 324 interface for which the cycle mapping table on every interface is 325 1:1. This allows to distinguish the case of originated TCQF packets 326 from those received from another LSR. 328 Note that this ingress mapping rule does not represent the shaping 329 necessary on an ingress TCQF router. TBD. 331 Label swap in the case of LDP or RSVP-TE LSP, or label pop in the 332 case of SR-MPLS traffic steering, or any other operation may result 333 in a different label to become the ToS LSE. Whenever a packet has an 334 associated TCQF cycle and is sent to an interface with TCQF, the 335 cycle is mapped to that outgoing interfaces cycle space and the TC of 336 the ToS LSE accordingly updated. 338 5. TCQF Pseudocode (normative) 340 The following pseudocode restates the prior two section text in an 341 algorithmic fashion. It uses the objects of the TCQF YANG data model 342 defined in Section 3. 344 tcqf = ietf-detnet-tcqf 345 void receive(pak) { 347 // Receive side TCQF - remember cycle in 348 // packet internal header 349 iif = pak.context.iif 350 if(tcqf.tcqf-if-config[iif]) { // TCQF enabled 351 if(tcqf.tcqf-mpls-tc-tag[iif]) { // TC-TCQF 352 pak.context.tcqf_cycle = 353 map_tc2cycle(pak.mpls_header.lse[tos].tc, 354 tcqf.tcqf-mpls-tc-tag[iif]) 355 } else // other future encap/tagging options for TCQF 356 } 358 // Forwarding including any LSE operations 359 oif = pak.context.oif = forward_process(pak) 361 // ... optional DetNet PREOF functions here 362 // ... if router is DetNet service node 363 if(pak.context.tcqf_cycle && // non TCQF packets value is 0 364 tcqf.tcqf-if-config[oif]) { // TCQF enabled 365 // Map tcqf_cycle for iif to oif mapping table 366 cycle = pak.context.tcqf_cycle = 367 map_cycle(cycle, 368 tcqf.tcqf-if-config[oif].tcqf-iif-cycle-map[[iif]) 370 if(tcqf.tcqf-mpls-tc-tag[iif]) { // TC-TCQF 371 pak.mpls_header.lse[tos].tc = 372 map_cycle2tc(cycle, tcqf.tcqf-mpls-tc-tag[oif]) 373 } else // other future encap/tagging options for TCQF 375 tcqf_enqueue(pak, oif.cycleq[cycle]) 376 } 377 } 379 // Started when TCQF is enabled on an interface 380 void send_tcqf(oif) { 381 cycle = 1 382 cc = tcqf.tcqf-config.cycle-time * 383 tcqf.tcqf-config.cycle-time 384 o = tcqf.tcqf-config.cycle-clock-offset 385 nextcyclestart = floor(tnow / cc) * cc + cc + o 387 while(1) { 388 while(tnow < nextcyclestart) { } 389 while(pak = dequeue(oif.cycleq(cycle)) { 390 send(pak) 391 } 392 cycle = (cycle + 1) mod tcqf.tcqf-config.cycles + 1 393 nextcyclestart += tcqf.tcqf-config.cycle-time 394 } 395 } 397 Figure 3: TCQF Pseudocode 399 6. TCQF YANG Model (normative) TBD 401 TBD - according to Section 3. 403 7. Computing cycle mappings (informative) 405 The cycle mapping is computed by the controller plane by taking at 406 minimum the link, interface serialization and node internal 407 forwarding latencies as well as the cycle-clock-offsets into account. 409 Router . O1 410 R1 . | cycle 1 | cycle 2 | cycle 3 | cycle 1 | 411 . . 412 . ............... Delay D 413 . . 414 . O1' 415 . | cycle 1 | 416 Router . | cycle 1 | cycle 2 | cycle 3 | cycle 1 | 417 R2 . O2 419 CT = cycle-time 420 C = cycles 421 CC = CT * C 422 O1 = cycle-clock-offset router R1, interface towards R2 423 O2 = cycle-clock-offset router R2, output interface of interest 424 O1' = O1 + D 426 Figure 4: Calculation reference 428 Consider in {#Calc1} that Router R1 sends packets via C = 3 cycles 429 with a cycle-clock offset of O1 towards Router R2. These packets 430 arrive at R2 with a cycle-clock offset of O1' which includes through 431 D all latencies incurred between releasing a packet on R1 from the 432 cycle buffer until it can be put into a cycle buffer on R2: 433 serialization delay on R1, link delay, non-CQF delays in R1 and R2, 434 especially forwarding in R2, potentially across an internal fabric to 435 the output interface with the sending cycle buffers. 437 A = ( ceil( ( O1' - O2 ) / CT) + C + 1) mod CC 438 map(i) = (i - 1 + A) mod C + 1 440 Figure 5: Calculating cycle mapping 442 {#Calc2} shows a formula to calculate the cycle mapping between R1 443 and R2, using the first available cycle on R2. In the example of 444 {#Calc1} with CT = 1, (O1' - O2) =~ 1.8, A will be 0, resulting in 445 map(1) to be 1, map(2) to be 2 and map(3) to be 3. 447 The offset "C" for the calculation of A is included so that a 448 negative (O1 - O2) will still lead to a positive A. 450 In general, D will be variable [Dmin...Dmax], for example because of 451 differences in serialization latency between min and max size 452 packets, variable link latency because of temperature based length 453 variations, link-layer variability (radio links) or in-router 454 processing variability. In addition, D also needs to account for the 455 drift between the synchronized clocks for R1 and R2. This is called 456 the Maximum Time Interval Error (MTIE). 458 Let A(d) be A where O1' is calculated with D = d. To account for the 459 variability of latency and clock synchronization, map(i) has to be 460 calculated with A(Dmax), and the controller plane needs to ensure 461 that that A(Dmin)...A(Dmax) does cover at most (C - 1) cycles. 463 If it does cover C cycles, then C and/or CT are chosen too small, and 464 the controller plane needs to use larger numbers for either. 466 This (C - 1) limitation is based on the understanding that there is 467 only one buffer for each cycle, so a cycle cannot receive packets 468 when it is sending packets. While this could be changed by using 469 double buffers, this would create additional implementation 470 complexity and not solve the limitation for all cases, because the 471 number of cycles to cover [Dmin...Dmax] could also be (C + 1) or 472 larger, in which case a tag of 1...C would not suffice. 474 8. Security Considerations 476 TBD. 478 9. IANA Considerations 480 This document has no IANA considerations. 482 10. Informative References 484 [CQF] IEEE Time-Sensitive Networking (TSN) Task Group., "IEEE 485 Std 802.1Qch-2017: IEEE Standard for Local and 486 Metropolitan Area Networks - Bridges and Bridged Networks 487 - Amendment 29: Cyclic Queuing and Forwarding", 2017. 489 [I-D.dang-queuing-with-multiple-cyclic-buffers] 490 Liu, B. and J. Dang, "A Queuing Mechanism with Multiple 491 Cyclic Buffers", Work in Progress, Internet-Draft, draft- 492 dang-queuing-with-multiple-cyclic-buffers-00, 22 February 493 2021, . 496 [I-D.eckert-detnet-bounded-latency-problems] 497 Eckert, T. and S. Bryant, "Problems with existing DetNet 498 bounded latency queuing mechanisms", Work in Progress, 499 Internet-Draft, draft-eckert-detnet-bounded-latency- 500 problems-00, 12 July 2021, 501 . 504 [I-D.ietf-bier-te-arch] 505 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 506 for Bit Index Explicit Replication (BIER-TE)", Work in 507 Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9 508 July 2021, . 511 [I-D.ietf-detnet-bounded-latency] 512 Finn, N., Boudec, J. L., Mohammadpour, E., Zhang, J., 513 Varga, B., and J. Farkas, "DetNet Bounded Latency", Work 514 in Progress, Internet-Draft, draft-ietf-detnet-bounded- 515 latency-07, 1 September 2021, 516 . 519 [I-D.qiang-DetNet-large-scale-DetNet] 520 Qiang, L., Geng, X., Liu, B., Eckert, T., Geng, L., and G. 521 Li, "Large-Scale Deterministic IP Network", Work in 522 Progress, Internet-Draft, draft-qiang-DetNet-large-scale- 523 DetNet-05, 2 September 2019, 524 . 527 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 528 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 529 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 530 . 532 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 533 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 534 Protocol Label Switching (MPLS) Support of Differentiated 535 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 536 . 538 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 539 Decraene, B., Litkowski, S., and R. Shakir, "Segment 540 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 541 July 2018, . 543 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 544 "Deterministic Networking Architecture", RFC 8655, 545 DOI 10.17487/RFC8655, October 2019, 546 . 548 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 549 S., and J. Korhonen, "Deterministic Networking (DetNet) 550 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 551 2021, . 553 [TSN-ATS] Specht, J., "P802.1Qcr - Bridges and Bridged Networks 554 Amendment: Asynchronous Traffic Shaping", IEEE , 9 July 555 2020, . 557 Authors' Addresses 559 Toerless Eckert 560 Futurewei Technologies USA 561 2220 Central Expressway 562 Santa Clara, CA 95050 563 United States of America 565 Email: tte@cs.fau.de 567 Stewart Bryant 568 University of Surrey ICS 570 Email: s.bryant@surrey.ac.uk