idnits 2.17.00 (12 Aug 2021) /tmp/idnits49437/draft-eckert-detnet-mpls-tc-tcqf-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 : ---------------------------------------------------------------------------- == There are 8 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 266: '...main. router/LSR MUST support 3 and 4 ...' RFC 2119 keyword, line 267: '..., 7 or less cycles MUST be used across...' RFC 2119 keyword, line 270: '...micro-seconds. router/LSR MUST support...' RFC 2119 keyword, line 322: '...nal cycle number SHOULD be assigned fr...' RFC 2119 keyword, line 325: '... SHOULD be assigned from the interna...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 201 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 151, 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 (~~), 5 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: 28 April 2022 University of Surrey ICS 6 A.G. Malis 7 Malis Consulting 8 25 October 2021 10 Deterministic Networking (DetNet) Data Plane - MPLS TC Tagging for 11 Cyclic Queuing and Forwarding (MPLS-TC TCQF) 12 draft-eckert-detnet-mpls-tc-tcqf-01 14 Abstract 16 This memo defines the use of the MPLS TC field of MPLS Label Stack 17 Entries (LSE) to support cycle tagging of packets for Multiple Buffer 18 Cyclic Queuing and Forwarding (TCQF). TCQF is a mechanism to support 19 bounded latency forwarding in DetNet network. 21 Target benefits of TCQF include low end-to-end jitter, ease of high- 22 speed hardware implementation, optional ability to support large 23 number of flow in large networks via DiffServ style aggregation by 24 applying TCQF to the DetNet aggregate instead of each DetNet flow 25 individually, and support of wide-area DetNet networks with arbitrary 26 link latencies and latency variations. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 28 April 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction (informative) . . . . . . . . . . . . . . . . . 2 62 2. Using TCQF in the DetNet Archticture and MPLS forwarding plane 63 (informative) . . . . . . . . . . . . . . . . . . . . . . 3 64 3. MPLS T-CQF forwarding (normative) . . . . . . . . . . . . . . 6 65 3.1. Configuration Data model and tag processing for MPLS TC 66 TCQF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Packet processing . . . . . . . . . . . . . . . . . . . . 6 68 3.3. TCQF with label stack operations . . . . . . . . . . . . 7 69 3.4. Ingres operations . . . . . . . . . . . . . . . . . . . . 8 70 4. TCQF Pseudocode (normative) . . . . . . . . . . . . . . . . . 8 71 5. Operational considerations (informative) . . . . . . . . . . 9 72 5.1. Controller plane computation of cycle mappings . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 9.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction (informative) 83 Cyclic Queuing and Forwarding [CQF], is an IEEE standardized queuing 84 mechanism in support of deterministic bounded latency. See also 85 [I-D.ietf-detnet-bounded-latency], Section 6.6. 87 CQF benefits for Deterministic QoS include the tightly bounded jitter 88 it provides as well as the per-flow stateless operation, minimizing 89 the complexity of high-speed hardware implementations and allowing to 90 support on transit hops arbitrary number of DetNet flow in the 91 forwarding plane because of the absence of per-hop, per-flow QoS 92 processing. In the terms of the IETF QoS architecture, CQF can be 93 called DiffServ QoS technology, operating only on a traffic 94 aggregate. 96 CQFs is limited to only limited-scale wide-area network deployments 97 because it cannot take the propagation latency of links into account, 98 nor potential variations thereof. It also requires very high 99 precision clock synchronization, which is uncommon in wide-area 100 network equipment beyond mobile network fronthaul. See 101 [I-D.eckert-detnet-bounded-latency-problems] for more details. 103 This specification introduces and utilizes an enhanced form of CQF 104 where packets are tagged with a cycle identifier, and a limited 105 number of cycles, e.g.: 3...7 are used to overcome these distance and 106 clock synchronization limitations. Because this memo defines how to 107 use the TC field of MPLS LSE as the tag to carry the cycle 108 identifier, it calls this scheme TC Tagged multiple buffer CQF (TC 109 TCQF). See [I-D.qiang-DetNet-large-scale-DetNet] and 110 [I-D.dang-queuing-with-multiple-cyclic-buffers] for more details of 111 the theory of operations of TCQF. Note that TCQF is not necessarily 112 limited to deterministic operations but could also be used in 113 conjunction with congestion controlled traffic, but those 114 considerations are outside the scope of this memo. 116 TCQF is likely especially beneficial when MPLS networks are designed 117 to avoid per-hop, per-flow state even for traffic steering, which is 118 the case for networks using SR-MPLS [RFC8402] for traffic steering of 119 MPLS unicast traffic and/or BIER-TE [I-D.ietf-bier-te-arch] for tree 120 engineering of MPLS multicast traffic. In these networks, it is 121 specifically undesirable to require per-flow signaling to P-LSR 122 solely for DetNet QoS because such per-flow state is unnecessary for 123 traffic steering and would only be required for the bounded latency 124 QoS mechanism and require likely even more complex hardware and 125 manageability support than what was previously required for per-hop 126 steering state (e.g. In RSVP-TE). Note that the DetNet architecture 127 [RFC8655] does not include full support for this DiffServ model, 128 which is why this memo describes how to use MPLS TC TCQF with the 129 DetNet architecture per-hop, per-flow processing as well as without 130 it. 132 2. Using TCQF in the DetNet Archticture and MPLS forwarding plane 133 (informative) 135 This section gives an overview of how the operations of T-CQF relates 136 to the DetNet architecture. We first revisit QoS with DetNet in the 137 absence of T-CQF. 139 DetNet MPLS Relay Transit Relay DetNet MPLS 140 End System Node Node Node End System 141 T-PE1 S-PE1 LSR-P S-PE2 T-PE2 142 +----------+ +----------+ 143 | Appl. |<------------ End-to-End Service ----------->| Appl. | 144 +----------+ +---------+ +---------+ +----------+ 145 | Service |<--| Service |-- DetNet flow --| Service |-->| Service | 146 +----------+ +---------+ +----------+ +---------+ +----------+ 147 |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| 148 +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ 149 : Link : / ,-----. \ : Link : / ,-----. \ 150 +........+ +-[ Sub- ]-+ +......+ +-[ Sub- ]-+ 151 [Network] [Network] 152 `-----' `-----' 153 |<- LSP -->| |<-------- LSP -----------| |<--- LSP -->| 155 |<----------------- DetNet MPLS --------------------->| 157 Figure 1: A DetNet MPLS Network 159 The above Figure 1, is copied from [RFC8964], Figure 2, and only 160 enhanced by numbering the nodes to be able to better refer to them in 161 the following text. 163 Assume a DetNet flow is sent from T-PE1 to T-PE2 across S-PE1, LSR, 164 S-PE2. In general, bounded latency QoS processing is then required 165 on the outgoing interface of T-PE1 towards S-PE1, and any further 166 outgoing interface along the path. When T-PE1 and S-PE2 know that 167 their next-hop is a service LSR, their DetNet flow label stack may 168 simply have the DetNet flows Service Label (S-Label) as its Top of 169 Stack (ToS) LSE, explicitly indicating one DetNet flow. 171 On S-PE1, the next-hop LSR is not DetNet aware, which is why S-PE1 172 would need to send a label stack where the S-Label is followed by a 173 Forwarding Label (F-Label), and LSR-P would need to perform bounded 174 latency based QoS on that F-Label. 176 For bounded latency QoS mechanisms relying on per-flow regulator 177 state, such as in [TSN-ATS], this requires the use of a per-detnet 178 flow F-Label across the network from S-PE1 to S-PE2, for example 179 through RSVP-TE [RFC3209] enhanced as necessary with QoS parameters 180 matching the underlying bounded latency mechanism (such as 181 [TSN-ATS]). 183 With TC TCQF, a sequence of LSR and DetNet service node implements TC 184 TCQF, ideally from T-PE1 (ingress) to T-PE2 (egress). The ingress 185 node needs to perform per-DetNet-flow per-packet "shaping" to assign 186 each packet of a flow to a particular TCQF cycle. This ingress-edge- 187 function is currently out of scope of this document (TBD), but would 188 be based on the same type of edge function as used in CQF. 190 All LSR/Service node after the ingress node only have to map a 191 received TCQF tagged DetNet packet to the configured cycle on the 192 output interface, not requiring any per-DetNet-flow QoS state. These 193 LSR/Service nodes do therefore also not require per-flow interactions 194 with the controller plane for the purpose of bounded latency. 196 Per-flow state therefore is therefore only required on nodes that are 197 DetNet service nodes, or when explicit, per-DetNet flow steering 198 state is desired, instead of ingress steering through e.g.: SR-MPLS. 200 Operating TCQF per-flow stateless across a service node, such as 201 S-PE1, S-PE2 in the picture is only an option. It is of course 202 equally feasible to Have one TCQF domain from T-PE1 to S-PE2, start a 203 new TCQF domain there, running for example up to S-PE2 and start 204 another one to T-PE2. 206 A service node must act as an egress/ingress edge of a TCQF domain if 207 it needs to perform operations that do change the timing of packets 208 other than the type of latency that can be considered in 209 configuration of TCQF (see Section 5.1). 211 For example, if T-PE1 is ingress for a TCQF domain, and T-PE2 is the 212 egress, S-PE1 could perform the DetNet Packet Replication Function 213 (PRF) without having to be a TQCF edge node as long as it does not 214 introduce latencies not included in the TCQF setup and the controller 215 plane reserves resources for the multitude of flows created by the 216 replication taking the allocation of resources in the TCQF cycles 217 into account. 219 Likewise, S-PE2 could perform the Packet Elimination Function without 220 being a TCQF edge node as this most likely does not introduce any 221 non-TCQF acceptable latency - and the controller plane accordingly 222 reserves only for one flow the resources on the S-PE2->T-PE2 leg. 224 If on the other hand, S-PE2 was to perform the Packet Reordering 225 Function (PRF), this could create large peaks of packets when out-of- 226 order packets are released together. A PRF would either have to take 227 care of shaping out those bursts for the traffic of a flow to again 228 conform to the admitted CIR/PIR, or else the service node would have 229 to be a TCQF egress/ingress, performing that shaping itself as an 230 ingress function. 232 3. MPLS T-CQF forwarding (normative) 234 3.1. Configuration Data model and tag processing for MPLS TC TCQF 236 tcqf 237 +-- uint16 cycles 238 +-- uint16 cycle_time 239 +-- uint32 cycle_clock_offset 240 +-- if_config[oif] # Outgoing InterFace 241 +-- uint32 cycle_clock_offset 242 +-- cycle_map[iif] # Incoming InterFace 243 +--uint8 oif_cycle[iif_cycle] 245 tcqf_tc[oif] 246 +--uint8 tc[oif_cycle] 248 Figure 2: TCQF Configuration Data Model 250 3.2. Packet processing 252 This section explains the MPLS T-CQF packet processing and through 253 it, introduces the semantic of the objects in Figure 2 255 tcqf contains the router/LSR wide configuration of TCQF parameters, 256 independent of the specific tagging mechanism on any interface. Any 257 interface can have a different tagging method. 259 The model represents a single TQCF domain, which is a set of 260 interfaces acting both as ingress (iif) and egress (oif) interfaces, 261 capable to forward TCQF packets amongst each other. A router/LSR may 262 have multiple TCQF domains each with a set of interfaces disjoint 263 from those of any other TCQF domain. 265 tcqf.cycles is the number of cycles used across all interfaces in the 266 TCQF domain. router/LSR MUST support 3 and 4 cycles. To support 267 interfaces with MPLS TC tagging, 7 or less cycles MUST be used across 268 all interfaces in the CQF domain. 270 The unit of tcqf.cycle_time is micro-seconds. router/LSR MUST support 271 configuration of cycle-times of 20,50,100,200,500,1000,2000 usec. 273 Cycles start at an offset of tcqf.cycle_clock_offset in units of nsec 274 as follows. Let clock1 be a timestamp of the local reference clock 275 for TCQF, at which cycle 1 starts, then: 277 tcqf.cycle_clock_offset = (clock1 mod (tcqf.cycle_time * tcqf.cycles) 278 ) 279 The local reference clock of the LSR/router is expected to be 280 synchronized with the neighboring LSR/router in TCQF domain. 281 tcqf.cycle_clock_offset can be configurable by the operator, or it 282 can be read-only. In either case will the operator be able to 283 configure working TCQF forwarding through appropriately calculated 284 cycle mapping. 286 tcqf.if_config[oif] is optional per-interface configuration of TCQF 287 parameters. tcqf.if_config[oif].cycle_clock_offset may be different 288 from tcqf.cycle_clock_offset, for example, when interfaces are on 289 line cards with independently synchronized clocks, or when non- 290 uniform ingress-to-egress propagation latency over a complex router/ 291 LSR fabric makes it beneficial to allow per-egress interface or line 292 card configuration of cycle_clock_offset. It may be configurable or 293 read-only. 295 The value of -1 for tcqf.if_config[oif].cycle_clock_offset is used to 296 indicate that the domain wide tcqf.cycle_clock_offset is to be used 297 for oif. This is the only permitted negative number for this 298 parameter. 300 When a packet is received from iif with a cycle value of iif_cycle 301 and the packet is routed towards oif, then the cycle value (and 302 buffer) to use on oif is 303 tcqf.if_config[oif].cycle_map[iif].oif_cycle[iif_cycle]. This is 304 called the cycle mapping and is must be configurable. This cycle 305 mapping always happens when the packet is received with a cycle tag 306 on an interface in a TCQF domain and forwarded to another interface 307 in the same TCQF domain. 309 tcqf_tc[oif].tc[oif_cycle] defines how to map from the internal cycle 310 number oif_cycle to an MPLS TC value on interface oif. When 311 tcqf_tc[oif] is configured, oif will use MPLS TC tagging for TCQF. 312 This mapping not only used to map from internal cycle number to MPLS 313 TC tag when sending packets, but also to map from MPLS TC tag to the 314 internal cycle number when receiving packets. 316 3.3. TCQF with label stack operations 318 In the terminology of [RFC3270], TCQF QoS as defined here, is TC- 319 Inferred-PSC LSP (E-LSP) behavior: Packets are determined to belong 320 to the TCQF PSC solely based on the TC of the received packet. 322 The internal cycle number SHOULD be assigned from the Top of Stack 323 (ToS) MPLS label TC bits before any other label stack operations 324 happens. On the egress side, the TC value of the ToS MPLS label 325 SHOULD be assigned from the internal cycle number after any label 326 stack processing. 328 With this order of processing, TCQF can support forwarding of packets 329 with any label stack operations such as label swap in the case of LDP 330 or RSVP-TE created LSP, or no label changes from SID hop-by-hop 331 forwarding and/or SID/label pop as in the case of SR-MPLS traffic 332 steering. 334 3.4. Ingres operations 336 The ingress LSR of a TCQF domain has to mark packets with an internal 337 cycle number and ensure that any such marked traffic complies with 338 the traffic envelope admitted by the controller plane. 340 The algorithms to map packets of traffic flows into cycles are 341 outside the scope of this specification, because there can be 342 multiple ones of varying complexity. In a most simple admission 343 model, a particular flow is allocated a maximum number of bytes in 344 every cycle. This can easily be mapped into an appropriate policing 345 gate. 347 For the purpose of this specification, such ingress operations is 348 simply represented as an (internal/virtual) interface from which the 349 packet is received, complete with a correctly assigned internal cycle 350 number. 352 4. TCQF Pseudocode (normative) 354 The following pseudocode restates the forwarding behavior of 355 Section 3 in an algorithmic fashion as pseudocode. It uses the 356 objects of the TCQF configuration data model defined in Section 3.1. 358 void receive(pak) { 359 // Receive side TCQF - remember cycle in 360 // packet internal header 361 iif = pak.context.iif 362 if (tcqf.if_config[iif]) { // TCQF enabled on iif 363 if (tcqf_tc[iif]) { // MPLS TCQF enabled on iif 364 tc = pak.mpls_header.lse[tos].tc 365 pak.context.tcqf_cycle = map_tc2cycle( tc, tcqf_tc[iif]) 366 } else // other future encap/tagging options for TCQF 367 } 368 forward(pak); 369 } 371 void inject_tcqf_pak(pak, cycle) { 372 pak.context.iif = INTERNAL 373 pak.context.tcqf_cycle = cycle 374 forward(pak); 375 } 376 void forward(pak) { 377 // Forwarding including any LSE operations 378 oif = pak.context.oif = forward_process(pak) 380 // ... optional DetNet PREOF functions here 381 // ... if router is DetNet service node 383 if(pak.context.tcqf_cycle && // non TCQF packets cycle is 0 384 tcqf.if_config[oif]) { // TCQF enabled 385 // Map tcqf_cycle iif to oif 386 cycle = pak.context.tcqf_cycle 387 = map_cycle(cycle, 388 tcqf.if_config[oif].cycle_map[[iif]) 390 if(tcqf.mpls_tc_tag[iif]) { // TC-TCQF 391 pak.mpls_header.lse[tos].tc = 392 map_cycle2tc(cycle, tcqf_tc[oif]) 393 } else // other future encap/tagging options for TCQF 395 tcqf_enqueue(pak, oif.cycleq[cycle]) 396 } 397 } 399 // Started when TCQF is enabled on an interface 400 // dequeues packets from oif.cycleq 401 void send_tcqf(oif) { 402 cycle = 1 403 cc = tcqf.cycle_time * 404 tcqf.cycle_time 405 o = tcqf.cycle_clock_offset 406 nextcyclestart = floor(tnow / cc) * cc + cc + o 408 while(1) { 409 while(tnow < nextcyclestart) { } 410 while(pak = dequeue(oif.cycleq(cycle)) { 411 send(pak) 412 } 413 cycle = (cycle + 1) mod tcqf.cycles + 1 414 nextcyclestart += tcqf.cycle_time 415 } 416 } 418 Figure 3: TCQF Pseudocode 420 5. Operational considerations (informative) 421 5.1. Controller plane computation of cycle mappings 423 The cycle mapping is computed by the controller plane by taking at 424 minimum the link, interface serialization and node internal 425 forwarding latencies as well as the cycle_clock_offsets into account. 427 Router . O1 428 R1 . | cycle 1 | cycle 2 | cycle 3 | cycle 1 | 429 . . 430 . ............... Delay D 431 . . 432 . O1' 433 . | cycle 1 | 434 Router . | cycle 1 | cycle 2 | cycle 3 | cycle 1 | 435 R2 . O2 437 CT = cycle_time 438 C = cycles 439 CC = CT * C 440 O1 = cycle_clock_offset router R1, interface towards R2 441 O2 = cycle_clock_offset router R2, output interface of interest 442 O1' = O1 + D 444 Figure 4: Calculation reference 446 Consider in {#Calc1} that Router R1 sends packets via C = 3 cycles 447 with a cycle_clock offset of O1 towards Router R2. These packets 448 arrive at R2 with a cycle_clock offset of O1' which includes through 449 D all latencies incurred between releasing a packet on R1 from the 450 cycle buffer until it can be put into a cycle buffer on R2: 451 serialization delay on R1, link delay, non_CQF delays in R1 and R2, 452 especially forwarding in R2, potentially across an internal fabric to 453 the output interface with the sending cycle buffers. 455 A = ( ceil( ( O1' - O2 ) / CT) + C + 1) mod CC 456 map(i) = (i - 1 + A) mod C + 1 458 Figure 5: Calculating cycle mapping 460 {#Calc2} shows a formula to calculate the cycle mapping between R1 461 and R2, using the first available cycle on R2. In the example of 462 {#Calc1} with CT = 1, (O1' - O2) =~ 1.8, A will be 0, resulting in 463 map(1) to be 1, map(2) to be 2 and map(3) to be 3. 465 The offset "C" for the calculation of A is included so that a 466 negative (O1 - O2) will still lead to a positive A. 468 In general, D will be variable [Dmin...Dmax], for example because of 469 differences in serialization latency between min and max size 470 packets, variable link latency because of temperature based length 471 variations, link-layer variability (radio links) or in-router 472 processing variability. In addition, D also needs to account for the 473 drift between the synchronized clocks for R1 and R2. This is called 474 the Maximum Time Interval Error (MTIE). 476 Let A(d) be A where O1' is calculated with D = d. To account for the 477 variability of latency and clock synchronization, map(i) has to be 478 calculated with A(Dmax), and the controller plane needs to ensure 479 that that A(Dmin)...A(Dmax) does cover at most (C - 1) cycles. 481 If it does cover C cycles, then C and/or CT are chosen too small, and 482 the controller plane needs to use larger numbers for either. 484 This (C - 1) limitation is based on the understanding that there is 485 only one buffer for each cycle, so a cycle cannot receive packets 486 when it is sending packets. While this could be changed by using 487 double buffers, this would create additional implementation 488 complexity and not solve the limitation for all cases, because the 489 number of cycles to cover [Dmin...Dmax] could also be (C + 1) or 490 larger, in which case a tag of 1...C would not suffice. 492 6. Security Considerations 494 TBD. 496 7. IANA Considerations 498 This document has no IANA considerations. 500 8. Changelog 502 00 504 Initial version 506 01 508 Added new co-author. 510 Changed Data Model to "Configuration Data Model", 512 and changed syntax from YANG tree to a non-YANG tree, removed empty 513 section targeted for YANG model. Reason: the configuration 514 parameters that we need to specify the forwarding behavior is only a 515 subset of what likely would be a good YANG model, and any work to 516 define such a YANG model not necessary to specify the algorithm would 517 be scope creep for this specification. Better done in a separate 518 YANG document. Example additional YANG aspects for such a document 519 are how to map parameters to configuration/operational space, what 520 additional operational/monitoring parameter to support and how to map 521 the YANG objects required into various pre-existing YANG trees. 523 Improved text in forwarding section, simplified sentences, used 524 simplified configuration data model. 526 9. References 528 9.1. Normative References 530 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 531 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 532 Protocol Label Switching (MPLS) Support of Differentiated 533 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 534 . 536 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 537 "Deterministic Networking Architecture", RFC 8655, 538 DOI 10.17487/RFC8655, October 2019, 539 . 541 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 542 S., and J. Korhonen, "Deterministic Networking (DetNet) 543 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 544 2021, . 546 9.2. Informative References 548 [CQF] IEEE Time-Sensitive Networking (TSN) Task Group., "IEEE 549 Std 802.1Qch-2017: IEEE Standard for Local and 550 Metropolitan Area Networks - Bridges and Bridged Networks 551 - Amendment 29: Cyclic Queuing and Forwarding", 2017. 553 [I-D.dang-queuing-with-multiple-cyclic-buffers] 554 Liu, B. and J. Dang, "A Queuing Mechanism with Multiple 555 Cyclic Buffers", Work in Progress, Internet-Draft, draft- 556 dang-queuing-with-multiple-cyclic-buffers-00, 22 February 557 2021, . 560 [I-D.eckert-detnet-bounded-latency-problems] 561 Eckert, T. and S. Bryant, "Problems with existing DetNet 562 bounded latency queuing mechanisms", Work in Progress, 563 Internet-Draft, draft-eckert-detnet-bounded-latency- 564 problems-00, 12 July 2021, 565 . 568 [I-D.ietf-bier-te-arch] 569 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 570 for Bit Index Explicit Replication (BIER-TE)", Work in 571 Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9 572 July 2021, . 575 [I-D.ietf-detnet-bounded-latency] 576 Finn, N., Boudec, J. L., Mohammadpour, E., Zhang, J., 577 Varga, B., and J. Farkas, "DetNet Bounded Latency", Work 578 in Progress, Internet-Draft, draft-ietf-detnet-bounded- 579 latency-07, 1 September 2021, 580 . 583 [I-D.qiang-DetNet-large-scale-DetNet] 584 Qiang, L., Geng, X., Liu, B., Eckert, T., Geng, L., and G. 585 Li, "Large-Scale Deterministic IP Network", Work in 586 Progress, Internet-Draft, draft-qiang-DetNet-large-scale- 587 DetNet-05, 2 September 2019, 588 . 591 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 592 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 593 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 594 . 596 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 597 Decraene, B., Litkowski, S., and R. Shakir, "Segment 598 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 599 July 2018, . 601 [TSN-ATS] Specht, J., "P802.1Qcr - Bridges and Bridged Networks 602 Amendment: Asynchronous Traffic Shaping", IEEE , 9 July 603 2020, . 605 Authors' Addresses 606 Toerless Eckert 607 Futurewei Technologies USA 608 2220 Central Expressway 609 Santa Clara, CA 95050 610 United States of America 612 Email: tte@cs.fau.de 614 Stewart Bryant 615 University of Surrey ICS 617 Email: s.bryant@surrey.ac.uk 619 Andrew G. Malis 620 Malis Consulting 622 Email: agmalis@gmail.com