idnits 2.17.1 draft-ietf-detnet-data-plane-framework-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 == Line 197 has weird spacing: '...e stack v ...' -- The document date (May 5, 2019) is 1789 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-12 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-03 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-01 -- No information found for draft-mpls-over-tsn - is the name correct? -- No information found for draft-mpls-over-udp-ip - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga, Ed. 3 Internet-Draft J. Farkas 4 Intended status: Informational Ericsson 5 Expires: November 6, 2019 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 A. Malis 9 S. Bryant 10 Huawei Technologies 11 J. Korhonen 12 May 5, 2019 14 DetNet Data Plane Framework 15 draft-ietf-detnet-data-plane-framework-00 17 Abstract 19 This document provides an overall framework for the Deterministic 20 Networking data plane. It covers concepts and considerations that 21 are generally common to any Deterministic Networking data plane 22 specification. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 6, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 62 3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 5 63 3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6 64 3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.4. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8 67 3.5. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 8 68 3.6. Further DetNet Data Plane Considerations . . . . . . . . 9 69 3.6.1. Service Protection . . . . . . . . . . . . . . . . . 11 70 3.6.2. Aggregation Considerations . . . . . . . . . . . . . 13 71 3.6.3. End-System Specific Considerations . . . . . . . . . 14 72 3.6.4. Sub-Network Considerations . . . . . . . . . . . . . 14 73 4. Controller Plane (Management and Control) 74 Considerations . . . . . . . . . . . . . . . . . . . . . . . 15 75 4.1. DetNet Controller Plane Requirements . . . . . . . . . . 15 76 4.2. Generic Controller Plane Considerations . . . . . . . . . 16 77 4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 17 78 4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 18 79 4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19 80 4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 19 81 4.3. IP-Specific Controller Plane Considerations . . . . . . . 20 82 4.3.1. Flow Identification and Aggregation . . . . . . . . . 20 83 4.4. MPLS-Specific Controller Plane Considerations . . . . . . 20 84 4.4.1. S-Label and F-Label Assignment and Distribution . . . 20 85 4.5. Packet Replication, Elimination, and Ordering (PREOF) . . 22 86 4.6. Contention Loss and Jitter Reduction . . . . . . . . . . 22 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 93 9.2. Informative References . . . . . . . . . . . . . . . . . 25 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 96 1. Introduction 98 Deterministic Networking (DetNet) provides a capability to carry 99 specified unicast or multicast data flows for real-time applications 100 with extremely low packet loss rates and assured maximum end-to-end 101 delivery latency. A description of the general background and 102 concepts of DetNet can be found in [I-D.ietf-detnet-architecture]. 104 This document describes the concepts needed by any DetNet data plane 105 specification and provides considerations for any corresponding 106 implementation. It covers the building blocks that provide the 107 DetNet service, the forwarding sub-layer functions, and the flow 108 identification as described in the DetNet Architecture. 110 The DetNet Architecture models the DetNet related data plane 111 functions decomposed into two sub-layers: a service sub-layer and a 112 forwarding sub-layer. The service sub-layer is used to provide 113 DetNet service protection and reordering. The forwarding sub-layer 114 is used to provide congestion protection (low loss, assured latency, 115 and limited reordering) and leverages Traffic Engineering mechanisms. 117 As part of the service sub-layer functions, this document describes 118 typical DetNet node data plane operation. It describes the function 119 and operation of the Packet Replication (PRF) Packet Elimination 120 (PEF) and the Packet Ordering (POF) functions within the service sub- 121 layer. It also describes the forwarding sub-layer that is used to 122 eliminate (or reduce) contention loss and provide bounded latency for 123 DetNet flows. 125 DetNet flows may be carried over network technologies that can 126 provide the DetNet required level of service. For example, DetNet 127 MPLS flows can be carried over IEEE 802.1 Time Sensitive Network 128 (TSN) [IEEE802.1TSNTG] sub-networks. However, IEEE 802.1 TSN support 129 is not required and some of the DetNet benefits can be gained by 130 running over a data link layer that has not been specifically 131 enhanced to support TSN. 133 Different traffic types, or application flows, can be mapped on top 134 of DetNet. DetNet can optionally reuse header information provided 135 by, or shared with, applications. An example of shared header fields 136 can be found in [I-D.ietf-detnet-ip]. 138 This document also covers concepts related to the controller plane 139 and Operations, Administration, and Maintenance (OAM) functions. 141 2. Terminology 143 2.1. Terms Used in This Document 145 This document uses the terminology established in the DetNet 146 architecture [I-D.ietf-detnet-architecture], and the reader is 147 assumed to be familiar with that document and its terminology. 149 2.2. Abbreviations 151 The following abbreviations are used in this document: 153 CW Control Word. 155 DetNet Deterministic Networking. 157 L2 Layer 2. 159 L2VPN Layer 2 Virtual Private Network. 161 LSR Label Switching Router. 163 MPLS Multiprotocol Label Switching. 165 MPLS-TE Multiprotocol Label Switching - Traffic Engineering. 167 OAM Operations, Administration, and Maintenance. 169 PEF Packet Elimination Function. 171 PRF Packet Replication Function. 173 PREOF Packet Replication, Elimination and Ordering Functions. 175 POF Packet Ordering Function. 177 PSN Packet Switched Network. 179 PW PseudoWire. 181 QoS Quality of Service. 183 TSN Time-Sensitive Network. 185 3. DetNet Data Plane Overview 187 This document describes how application flows, or app-flows, are 188 carried over DetNet networks. The DetNet Architecture, 189 [I-D.ietf-detnet-architecture], models the DetNet related data plane 190 functions decomposed into two sub-layers: a service sub-layer and a 191 forwarding sub-layer. 193 Figure 1 reproduced from the [I-D.ietf-detnet-architecture],shows a 194 logical DetNet service with the two sub-layers. 196 | packets going | ^ packets coming ^ 197 v down the stack v | up the stack | 198 +-----------------------+ +-----------------------+ 199 | Source | | Destination | 200 +-----------------------+ +-----------------------+ 201 | Service sub-layer: | | Service sub-layer: | 202 | Packet sequencing | | Duplicate elimination | 203 | Flow replication | | Flow merging | 204 | Packet encoding | | Packet decoding | 205 +-----------------------+ +-----------------------+ 206 | Forwarding sub-layer: | | Forwarding sub-layer: | 207 | Resource allocation | | Resource allocation | 208 | Explicit routes | | Explicit routes | 209 +-----------------------+ +-----------------------+ 210 | Lower layers | | Lower layers | 211 +-----------------------+ +-----------------------+ 212 v ^ 213 \_________________________/ 215 Figure 1: DetNet data plane protocol stack 217 The DetNet forwarding sub-layer may be directly provided by the 218 DetNet service sub-layer, for example by IP or MPLS. Alternatively 219 an overlay approach may be used in which the packet is natively 220 carried between key nodes within the DetNet network (say between 221 PREOF nodes) and a sub-layer is used to provide the information 222 needed to reach the next hop in the overlay. 224 This forwarding sub-layer provides the quality underpin needed by the 225 DetNet Service sub-layer. It may do this directly through the use of 226 queuing techniques and traffic engineering methods, or it may do this 227 through the assistance of its underlying connectivity. For example 228 it may call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN 229 [IEEE802.1TSNTG]. 231 The service sub-layer provides additional support beyond the 232 connectivity function of the forwarding sub-layer. An example of 233 this is Packet Replication, Elimination, and Ordering (PREOF) 234 function see Section 4.5. 236 The method of instantiating each of the layers is specific to the 237 particular DetNet data plane method. There may be more than approach 238 that is applicable to a given bearer network type. 240 3.1. Data Plane Characteristics 242 There are two major characteristics to the data plane: 244 1. How the data plane is constructed: The DetNet service sub-layer 245 provides its functions for the DetNet application flows by using 246 or applying existing standardized headers and/or encapsulations. 247 The Detnet forwarding sub-layer may provide capabilities 248 leveraging that same header or encapsulation technology e.g. 249 Figure 2 or it may be achieved by other standardized technologies 250 e.g. Figure 3. 252 2. Extensibility of that Data Plane: Whether or not the DetNet data 253 plane includes the facility to carry additional information 254 (metadata) that can be used to provide an enhanced service to the 255 DetNet packet. 257 DetNet +-------+ +---------+ 258 Services | DN IP | | DN MPLS | 259 +-------+ +---------+ 261 Figure 2: DetNet Services 263 +-----+ 264 | TSN | 265 +-------+ +-+-----+-+ 266 DetNet | DN IP | | DN MPLS | 267 Service +--+--+----+----+ +-+---+-----+-+ 268 Examples | TSN | DN MPLS | | TSN | DN IP | 269 +-----+---------+ +-----+-------+ 271 Figure 3: DetNet Service Encapsulations 273 3.2. Encapsulation 275 The encapsulation of the DetNet flows allows them to be sent over a 276 data plane of a type other than their native type. Encapsulation is 277 essential if, for example, it is required to send Ethernet TSN stream 278 as a DetNet Application over a data plane such as MPLS. Figure 3 279 illustrates some encapsulation combinations. 281 The use of encapsulation is also required if additional information 282 (meta-data) is needed by the DetNet data plane and their is either no 283 ability to include it in the client data packet, or the specification 284 of the client data plane does not permit the modification of the 285 packet to include additional data. An example of such meta-data is 286 the inclusion of a sequence number required by the PREOF function. 288 Encapsulation is also needed if the DetNet flow or aggregate flow is 289 not easily recognised from its encapsulation. 291 3.3. Metadata 293 Metadata can be a useful way of identifying packets that need to be 294 treated as a flow or flow aggregate. It is also useful as a way of 295 including a sequence number the packet for use by the PREOF function 296 or as a place to carry OAM indications or OAM information to 297 instrument DetNet data plane operation. 299 Explicit inclusion of metadata is possible through the use of IP 300 options or IP extension headers. New IP options are almost 301 impossible to get standardized or to deploy in an operational network 302 and will not be discussed further in this text. IPv6 extensions 303 headers are finding popularity in current IPv6 development work, 304 particularly in connection with Segment Routing of IPv6 (SRv6) and IP 305 OAM. The design of a new IPv6 extension header or the modification 306 of an existing one is a technique available in the tool box of the 307 DetNet IP data plane designer. 309 Explicit inclusion of metadata in an IP packet is also possible 310 through the inclusion of an MPLS label stack and the MPLS DetNet 311 Control Word using one of the methods for carrying MPLS over IP 312 [I-D.mpls-over-udp-ip]. This is described in more detail in 313 Section 3.6.4. 315 Implicit metadata can be included through the use of the network 316 programming paradigm [I-D.spring-srv6-network-programming] in which 317 the suffix of an IPv6 address is used to encode additional 318 information for use by the network of the receiving host. Examples 319 of such information include the sequence number for use by the PREOF 320 function, or even all the essential information being included into 321 the DetNet over MPLS label stack (the DetNet Control Word and the 322 DetNet Service label). 324 3.4. DetNet IP Data Plane 326 An IP data plane may operate natively or through the use of an 327 encapsulation. There are many IP encapsulations that may be 328 interposed between the DetNet data plane IP header and the DetNet 329 payload, and it is anticipated that more than one encapsulation may 330 be deployed. 332 One method of operating an IP DetNet data plane without encapsulation 333 is to use "6-tuple" based flow identification, where "6-tuple" refers 334 to information carried in IP and higher layer protocol headers. 335 General background on the use of IP headers, and "5-tuples", to 336 identify flows and support Quality of Service (QoS) can be found in 337 [RFC3670]. [RFC7657] also provides useful background on the delivery 338 differentiated services (DiffServ) and "tuple" based flow 339 identification. DetNet flow aggregation may be enabled via the use 340 of wildcards, masks, prefixes and ranges. The operation of this 341 method is described in detail in [I-D.ietf-detnet-ip]. 343 The DetNet forwarding plane may use explicit route capabilities and 344 traffic engineering capabilities to provide a forwarding sub-layer 345 that is responsible for providing resource allocation and explicit 346 routes. It is possible to include metadata in a native IP packet 347 explicitly, or implicitly. 349 3.5. DetNet MPLS Data Plane 351 MPLS provides the ability to forward traffic over implicit and 352 explicit paths to the point in the network where the next DetNet 353 service sub-layer action needs to take place. It does this through 354 the use of a stack of one or more labels with various forwarding 355 semantics. 357 MPLS also provides the ability to identify a service instance that is 358 used to process the packet through the use of a label that maps the 359 packet to a service instance. 361 In cases where metadata is needed to process an MPLS encapsulated 362 packet at the service sub-layer, this has been been provided through 363 the use of a shim layer also called a control word (CW) [RFC4385]. 364 Although such CWs are frequently 32 bits long, there is no 365 architectural constraint on its size of this structure, only the 366 requirement that it is fully understood by all parties operating on 367 it in the DetNet service sub-layer. The operation of this method is 368 described in detail in [I-D.ietf-detnet-mpls]. 370 3.6. Further DetNet Data Plane Considerations 372 This section needs further work. 374 This section provides informative considerations related to providing 375 DetNet service to flows which are identified based on their header 376 information. At a high level, the following are provided on a per 377 flow basis: 379 Reservation and Allocation of resources: 381 Reservation of resources can allocate resources to specific DetNet 382 flows. This can eliminate packet contention and loss for DetNet 383 traffic. This also can reduce jitter for the DetNet traffic. 384 DetNet flows are assumed to behave with respect to the reserved 385 traffic profile. If other traffic shares the link resources, the 386 use of (queuing, policing, shaping) policies can be used to ensure 387 that the allocation of resources reserved for DetNet is met. 388 Queuing and shaping of DetNet traffic could be required to ensure 389 that DetNet traffic does not exceed its reserved profile but this 390 would impact the DetNet service characteristics. 392 Explicit routes: 394 Use of a specific path for a flow. This allows control of the 395 network delay by steering the packet with the ability to influence 396 the physical path. Explicit routes complement reservation by 397 ensuring that a consistent path can be associated with its 398 resources for the duration of that path. Coupled with the traffic 399 mechanism, this limits misordering and bounds latency. Explicit 400 route computation can encompass a wide set of constraints and 401 optimize the path for a certain characteristic e.g. highest 402 bandwidth or lowest jitter. In these cases the "best" path for 403 any set of characteristics may not be a shortest path. The 404 selection of path can take into account multiple network metrics. 405 Some of these metrics are measured and distributed by the routing 406 system as traffic engineering metrics. 408 Service protection: 410 Use of multiple packet streams using multiple paths, for example 411 1+1 or 1:1 linear protection. For DetNet this primarily relates 412 to packet replication and elimination capabilities. Changing the 413 explicit path after a failure is detected to an already 414 established path in order to restore delivery of the required 415 DetNet service characteristics is another protection mechanism for 416 example MPLS hitless protection. Path changes, even in the case 417 of failure recovery, can lead to the out of order delivery of data 418 requiring packet ordering functions either within the DetNet 419 service or at a high layer in the application traffic. 420 Establishment of new paths after a failure is out of scope for 421 DetNet services. 423 Network Coding: 425 Network Coding, not to be confused with network programming, 426 comprises several techniques where multiple data flows are 427 encoded. These resulting flows can then be sent on different 428 paths. The encoding operation can combine flows and error 429 recovery information. When the encoded flows are decoded and 430 recombined the original flows can be recovered. Note that Network 431 coding uses an alternative to packet by packet PREOF. Therefore, 432 for certain network topologies and traffic loads, Network Coding 433 can be used to improve a network's throughput, efficiency, 434 latency, and scalability, as well as resilience to partition, 435 attacks, and eavesdropping, as compared to traditional methods. 436 DetNet could utilized Network coding as an alternative to other 437 protection means. Network coding is often applied in wireless 438 networks and is being explored for other network types. 440 Load sharing: 442 Use of packet by packet distribution of the same DetNet flow over 443 multiple paths is not recommended except for the cases listed 444 above where PREOF is utilized to improve protection of traffic and 445 maintain order. Packet by packet load sharing, e.g., via ECMP or 446 UCMP, impacts ordering and possibly jitter. 448 Troubleshooting: 450 Since Detnet leverages many different forwarding sub-layers, those 451 technologies also support a number of tools to troubleshoot 452 connectivity for example, to support identification of misbehaving 453 flows. At the service layer again there are existing mechanisms 454 to troubleshoot or monitor flows. Many of these mechanisms exist 455 for IP and MPLS networks. A client of a DetNet service can 456 introduce any monitoring applications which can detect and monitor 457 delay and loss. 459 Recognize flow(s) for analytics: 461 To a large degree this follows the logic in the previous section. 462 Analytics can be inherited from the two sub-layers. At the DetNet 463 service edge packet and bit counters e.g. sent, received, dropped, 464 and out of sequence are maintained. 466 Correlate events with flows: 468 The provider of a DetNet service may allow other capabilities to 469 monitor flows such as more detail loss statistics and time 470 stamping of events. The details of these capabilities are 471 currently out of scope for this document. 473 Several of these capabilities are expanded upon in more detail below. 475 3.6.1. Service Protection 477 Service protection allow DetNet services to increase reliability and 478 maintain a DetNet Service Assurance in the case of network congestion 479 or some failures. Detnet relies on the underlying technology 480 capabilities for various protection schemes. Protection schemes 481 enable partial or complete coverage of the network paths and active 482 protection with combinations of PRF, PRE, and POF. 484 3.6.1.1. Linear Service Protection 486 An example DetNet MPLS network fragment and packet flow is 487 illustrated in Figure 4. 489 1 1.1 1.1 1.2.1 1.2.1 1.2.2 490 CE1----EN1--------R1-------R2-------R3--------EN2-----CE2 491 \ 1.2.1 / / 492 \1.2 /-----+ / 493 +------R4------------------------+ 494 1.2.2 496 Figure 4: Example Packet Flow in DetNet protected Network 498 In Figure 4 the numbers are used to identify the instance of a 499 packet. Packet 1 is the original packet, and packets 1.1, and 1.2 500 are two first generation copies of packet 1. Packet 1.2.1 is a 501 second generation copy of packet 1.2 etc. Note that these numbers 502 never appear in the packet, and are not to be confused with sequence 503 numbers, labels or any other identifier that appears in the packet. 504 They simply indicate the generation number of the original packet so 505 that its passage through the network fragment can be identified to 506 the reader. 508 Customer Equipment CE1 sends a packet into the DetNet enabled 509 network. This is packet (1). Edge Node EN1 encapsulates the packet 510 as a DetNet Packet and sends it to Relay node R1 (packet 1.1). EN1 511 makes a copy of the packet (1.2), encapsulates it and sends this copy 512 to Relay node R4. 514 Note that along the path from EN1 to R1 there may be zero or more 515 nodes which, for clarity, are not shown. The same is true for any 516 other path between two DetNet entities shown in Figure 4 . 518 Relay node R4 has been configured to send one copy of the packet to 519 Relay Node R2 (packet 1.2.1) and one copy to Edge Node EN2 (packet 520 1.2.2). 522 R2 receives packet copy 1.2.1 before packet copy 1.1 arrives, and, 523 having been configured to perform packet elimination on this DetNet 524 flow, forwards packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of 525 no further use and so is discarded by R2. 527 Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives 528 packet copy 1.2.1 from R2 via relay Node R3. EN2 therefore strips 529 any DetNet encapsulation from packet copy 1.2.2 and forwards the 530 packet to CE2. When EN2 receives the later packet copy 1.2.1 this is 531 discarded. 533 The above is of course illustrative of many network scenarios that 534 can be configured. Between a pair of relay nodes there may be one or 535 more transit nodes that simply forward the DetNet traffic, but these 536 are omitted for clarity. 538 This example also illustrates 1:1 protection scheme meaning there is 539 traffic and path for each segment of the end to end path. Local 540 DetNet relay nodes determine which packets are eliminated and which 541 packets are forwarded. A 1+1 scheme where only one path is used for 542 traffic at a time, could use the same topology. In this case there 543 is no PRF function and traffic is switched upon detection of failure. 544 An OAM scheme that monitors the paths detects the loss of path or 545 traffic is required to initiate the switch. A POF may still be used 546 in this case to prevent misordering of packets. In both cases the 547 protection paths are established and maintained for the duration of 548 the DetNet service. 550 3.6.1.2. Ring Service Protection 552 Ring protection may also be supported if the underlying technology 553 supports it. Many of the same concepts apply however Rings are 554 normally 1+1 protection for data efficiency reasons. [RFC8227] is an 555 example of MPLS-TP data plane that supports Ring protection. 557 3.6.2. Aggregation Considerations 559 The DetNet data plane also allows for the aggregation of DetNet 560 flows, to improved scaling by reducing the state per hop. How this 561 is done is data plane or control plane dependent. When DetNet flows 562 are aggregated, transit nodes provide service to the aggregate and 563 not on a per-DetNet flow basis. When aggregating DetNet flows the 564 flows should be compatible i.e. the same or very similar QoS and CoS 565 characteristics. In this case, nodes performing aggregation will 566 ensure that per-flow service requirements are achieved. 568 If bandwidth reservations are used, the sum of the reservations 569 should be the sum of all the individual reservations, in other words, 570 the reservations should not create an over subscription of bandwidth 571 reservation. If maximum delay bounds are used the system should 572 ensure that the aggregate does not exceed the delay bounds of the 573 component flows. 575 DetNet encapsulation is a data plane mechanism that can be used to 576 aggregate traffic. Encapsulation can either be in the same service 577 type or in a different service type see Figure 3 for examples. When 578 an encapsulation is used the choice of reserving a maximum resource 579 level and then tracking the services in the aggregated service or 580 adjusting the aggregated resources as the services are added is 581 implementation and technology specific. 583 DetNet flows at edges must be able to handle rejection to an 584 aggregation group due to lack of resources as well as conditions 585 where general requirements are not satisfied. 587 3.6.2.1. IP Aggregation 589 IP aggregation has both data plane and controller plane aspects. For 590 the data plane flows may be aggregated for treatment based on shared 591 characteristics such as 5-tuple. Alternatively, an IP encapsulation 592 may be used to tunnel an aggregate number of DetNet Flows between 593 relay nodes. 595 3.6.2.2. MPLS Aggregation 597 MPLS aggregation similarly has data plane and controller plane 598 aspects. In the case of MPLS flows are often tunneled in a 599 forwarding sub-layer and reservation is associated with that MPLS 600 tunnel. 602 3.6.3. End-System Specific Considerations 604 Data-flows requiring DetNet service are generated and terminated on 605 end-systems. Encapsulation depends on application and its 606 preferences. For example, a DetNet MPLS domain the DN functions use 607 the d-CWs, S-Labels and F-Labels to provide DetNet services. 608 However, an application may exchange further flow related parameters 609 (e.g., time-stamp), which are not provided by DN functions. 611 As a general rule, DetNet domains are capable of forwarding any 612 DetNet flows and the DetNet domain does not mandate the end-system or 613 edge system encapsulation format. Unless there is a proxy of some 614 form present, end-systems peer with similar end-systems using the 615 same application encapsulation format. For example, as shown in 616 Figure 5, IP applications peer with IP applications and Ethernet 617 L2VPN applications peer with Ethernet L2VPN applications. 619 +-----+ 620 | X | +-----+ 621 +-----+ | X | 622 | Eth | ________ +-----+ 623 +-----+ _____ / \ | Eth | 624 \ / \__/ \___ +-----+ 625 \ / \ / 626 0======== tunnel-1 ========0_ 627 | \ 628 \ | 629 0========= tunnel-2 =========0 630 / \ __/ \ 631 +-----+ \__ DetNet MPLS domain / \ 632 | X | \ __ / +-----+ 633 +-----+ \_______/ \_____/ | X | 634 | IP | +-----+ 635 +-----+ | IP | 636 +-----+ 638 Figure 5: End-Systems and The DetNet MPLS Domain 640 3.6.4. Sub-Network Considerations 642 Any of the DetNet service types may be transported by another DetNet 643 service. MPLS nodes may interconnected by different sub-network 644 technologies, which may include point-to-point links. Each of these 645 sub-network technologies need to provide appropriate service to 646 DetNet flows. In some cases, e.g., on dedicated point-to-point links 647 or TDM technologies, all that is required is for a DetNet node to 648 appropriately queue its output traffic. In other cases, DetNet nodes 649 will need to map DetNet flows to the flow semantics (i.e., 650 identifiers) and mechanisms used by an underlying sub-network 651 technology. Figure 6 shows several examples of header formats that 652 can be used to carry DetNet MPLS flows over different sub-network 653 technologies. L2 represent a generic layer-2 encapsulation that 654 might be used on a point-to-point link. TSN represents the 655 encapsulation used on an IEEE 802.1 TSN network, as described in 656 [I-D.mpls-over-tsn]. UDP/IP represents the encapsulation used on a 657 DetNet IP PSN, as described in [I-D.mpls-over-udp-ip]. 659 +------+ +------+ +------+ 660 App-Flow | X | | X | | X | 661 +-----+======+--+======+--+======+-----+ 662 DetNet-MPLS | d-CW | | d-CW | | d-CW | 663 +------+ +------+ +------+ 664 |Labels| |Labels| |Labels| 665 +-----+======+--+======+--+======+-----+ 666 Sub-Network | L2 | | TSN | | UDP | 667 +------+ +------+ +------+ 668 | IP | 669 +------+ 670 | L2 | 671 +------+ 673 Figure 6: Example DetNet MPLS Sub-Network Formats 675 4. Controller Plane (Management and Control) Considerations 677 4.1. DetNet Controller Plane Requirements 679 While the definition of controller plane for DetNet is out of the 680 scope of this document, there are particular considerations and 681 requirements for such that result from the unique characteristics of 682 the DetNet architecture [I-D.ietf-detnet-architecture] and data plane 683 as defined herein. 685 The primary requirements of the DetNet controller plane are that it 686 must be able to: 688 o Instantiate DetNet flows in a DetNet domain (which may include 689 some or all of explicit path determination, link bandwidth 690 reservations, restricting flows to IEEE 802.1 TSN links, node 691 buffer and other resource reservations, specification of required 692 queuing disciplines along the path, ability to manage 693 bidirectional flows, etc.) as needed for a flow. 695 o In the case of MPLS Manage DetNet S-Label and F-Label allocation 696 and distribution, where the DetNet MPLS encapsulation is in use 697 see Section 4.4. 699 o The ability to support DetNet flow aggregation. 701 o Advertise static and dynamic node and link resources such as 702 capabilities and adjacencies to other network nodes (for dynamic 703 signaling approaches) or to network controllers (for centralized 704 approaches). 706 o Scale to handle the number of DetNet flows expected in a domain 707 (which may require per-flow signaling or provisioning). 709 o Provision flow identification information at each of the nodes 710 along the path. Flow identification may differ depending on the 711 location in the network and the DetNet functionality (e.g. transit 712 node vs. relay node). 714 These requirements, as stated earlier, could be satisfied using 715 distributed control protocol signaling (such as RSVP-TE), centralized 716 network management provisioning mechanisms (such as BGP, PCEP, YANG 717 [I-D.ietf-detnet-flow-information-model], etc.) or hybrid 718 combinations of the two, and could also make use of MPLS-based 719 segment routing. 721 In the abstract, the results of either distributed signaling or 722 centralized provisioning are equivalent from a DetNet data plane 723 perspective - flows are instantiated, explicit routes are determined, 724 resources are reserved, and packets are forwarded through the domain 725 using the DetNet data plane. 727 However, from a practical and implementation standpoint, they are not 728 equivalent at all. Some approaches are more scalable than others in 729 terms of signaling load on the network. Some can take advantage of 730 global tracking of resources in the DetNet domain for better overall 731 network resource optimization. Some are more resilient than others 732 if link, node, or management equipment failures occur. While a 733 detailed analysis of the control plane alternatives is out of the 734 scope of this document, the requirements from this document can be 735 used as the basis of a later analysis of the alternatives. 737 4.2. Generic Controller Plane Considerations 739 This section covers control plane considerations that are independent 740 of the data plane technology used for DetNet service delivery. 742 While management plane and control planes are traditionally 743 considered separately, from the Data Plane perspective there is no 744 practical difference based on the origin of flow provisioning 745 information, and the DetNet architecture 746 [I-D.ietf-detnet-architecture] refers to these collectively as the 747 'Controller Plane'. This document therefore does not distinguish 748 between information provided by distributed control plane protocols, 749 e.g., RSVP-TE [RFC3209] and [RFC3473], or by centralized network 750 management mechanisms, e.g., RestConf [RFC8040], YANG [RFC7950], and 751 the Path Computation Element Communication Protocol (PCEP) 752 [I-D.ietf-pce-pcep-extension-for-pce-controller] or any combination 753 thereof. Specific considerations and requirements for the DetNet 754 Controller Plane are discussed in Section 4.1. 756 4.2.1. Flow Aggregation Control 758 Flow aggregation includes aggregation accomplished through the use of 759 hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and 760 TSN, both of which aggregate multiple DetNet flows into a single new 761 DetNet flow. It can also be grouping of IP flows that share 5-tuple 762 of 6-tuple attributes or flow identifiers at the DetNet sub-layer. 764 Control of aggregation involves a set of procedures not necessarily 765 in a strict order: 767 o Traffic engineering resource collection and distribution: 769 Available resources are tracked through control plane or 770 management plane databases and distributed amongst controllers 771 or nodes that can manage resources. 773 o Path computation and resource allocation: 775 When DetNet services are provisioned or requested one or more 776 paths meeting the requirements are selected and the resources 777 verified and recorded. 779 o Resource assignment and data plane co-ordination: 781 The assignment of resources along the path depends on the 782 technology and it includes assignment of specific links and 783 coordination of the queuing and other traffic management 784 capabilities. 786 o Assigned Resource recording and updating: 788 Depending on the specific technology the assigned resources are 789 updated and distributed in the databases preventing over 790 subscription. 792 4.2.2. Explicit Routes 794 Explicit routes are used to ensure that packets are routed through 795 the resources that have been reserved for them, and hence provide the 796 DetNet application with the required service. A requirement for the 797 DetNet Controller Plane will be the ability to assign a particular 798 identified DetNet IP flow to a path through the DetNet domain that 799 has been assigned the required nodal resources. This provides the 800 appropriate traffic treatment for the flow and also includes 801 particular links as a part of the path that are able to support the 802 DetNet flow. For example, by using IEEE 802.1 TSN links (as 803 discussed in [I-D.mpls-over-tsn] ) DetNet parameters can be 804 maintained. Further considerations and requirements for the DetNet 805 Controller Plane are discussed in Section 4.1. 807 Whether configuring, calculating and instantiating these routes is a 808 single-stage or multi-stage process, or in a centralized or 809 distributed manner, is out of scope of this document. 811 There are several of approaches that could be used to provide 812 explicit routes and resource allocation in the DetNet forwarding sub- 813 layer. For example: 815 o The path could be explicitly set up by a controller which 816 calculates the path and explicitly configures each node along that 817 path with the appropriate forwarding and resource allocation 818 information. 820 o The path could use a distributed control plane such as RSVP 821 [RFC2205] or RSVP-TE [RFC3473] extended to support DetNet IP 822 flows. 824 o The path could be implemented using IPv6-based segment routing 825 when extended to support resource allocation. 827 See Section 4.1 for further discussion of these alternatives. In 828 addition, [RFC2386] contains useful background information on QoS- 829 based routing, and [RFC5575] discusses a specific mechanism used by 830 BGP for traffic flow specification and policy-based routing. 832 4.2.3. Contention Loss and Jitter Reduction 834 As discussed in Section 1, this document does not specify the 835 mechanisms needed to eliminate packet contention, packet loss or 836 reduce jitter for DetNet flows at the DetNet forwarding sub-layer. 837 The ability to manage node and link resources to be able to provide 838 these functions is a necessary part of the DetNet controller plane. 839 It is also necessary to be able to control the required queuing 840 mechanisms used to provide these functions along a flow's path 841 through the network. See [I-D.ietf-detnet-ip] --> and Section 4.1 842 for further discussion of these requirements. 844 4.2.4. Bidirectional Traffic 846 DetNet applications typically generate bidirectional traffic. IP and 847 MPLS typically treat each direction separately and do not force 848 interdependence of each direction. MPLS has considered bidirectional 849 traffic requirements and the MPLS definitions from [RFC5654] are 850 useful to illustrate terms such as associated bidirectional flows and 851 co-routed bidirectional flows. MPLS defines a point-to-point 852 associated bidirectional LSP as consisting of two unidirectional 853 point-to-point LSPs, one from A to B and the other from B to A, which 854 are regarded as providing a single logical bidirectional forwarding 855 path. This is analogous to standard IP routing. MPLS defines a 856 point-to-point co-routed bidirectional LSP as an associated 857 bidirectional LSP which satisfies the additional constraint that its 858 two unidirectional component LSPs follow the same path (in terms of 859 both nodes and links) in both directions. An important property of 860 co-routed bidirectional LSPs is that their unidirectional component 861 LSPs share fate. In both types of bidirectional LSPs, resource 862 reservations may differ in each direction. The concepts of 863 associated bidirectional flows and co-routed bidirectional flows can 864 also be applied to DetNet IP flows. 866 While the DetNet IP data plane must support bidirectional DetNet 867 flows, there are no special bidirectional features with respect to 868 the data plane other than the need for the two directions of a co- 869 routed bidirectional flow to take the same path. That is to say that 870 bidirectional DetNet flows are solely represented at the management 871 and control plane levels, without specific support or knowledge 872 within the DetNet data plane. Fate sharing and associated or co- 873 routed bidirectional flows, can be managed at the control level. 875 DetNet's use of PREOF may increase the complexity of using co-routing 876 bidirectional flows, since if PREOF is used, then the replication 877 points in one direction would have to match the elimination points in 878 the other direction, and vice versa, and the optimal points for these 879 functions in one direction may not match the optimal points in the 880 other subsequent to the network and traffic constraints. 882 Control and management mechanisms need to support bidirectional 883 flows, but the specification of such mechanisms are out of scope of 884 this document. An example control plane solution for MPLS can be 885 found in . Related control plan mechanisms have been defined in 886 [RFC3473] , [RFC6387] and [RFC7551]. 888 This is further discussed in Section 4.1. 890 4.3. IP-Specific Controller Plane Considerations 892 This section covers IP data plane specific control plane 893 considerations. 895 4.3.1. Flow Identification and Aggregation 897 Section 3 discussed the use of the IP "6-tuple" for flow 898 identification, and goes on to discuss how identified flows use 899 specific QoS mechanisms for flow-specific traffic treatment, 900 including path control and resource allocation. [I-D.ietf-detnet-ip] 901 contains detailed DetNet IP flow identification procedures. Flow 902 identification will play an important role for the DetNet controller 903 plane. 905 Section 3.6.2 and Section 3.6.2.1 discuss the use of flow aggregation 906 in DetNet. Flow aggregation can be accomplished using any of the 907 6-tuple fields defined in [I-D.ietf-detnet-ip] , using a DSCP 908 identified traffic class or other field. It will be the 909 responsibility of the DetNet controller plane to be able to properly 910 provision the use of these aggregation mechanisms. These 911 requirements are included in Section 4.1. 913 4.4. MPLS-Specific Controller Plane Considerations 915 This section covers MPLS data plane specific control plane 916 considerations. This section needs generalizing. 918 4.4.1. S-Label and F-Label Assignment and Distribution 920 [Editor's note - we may need additional text on resource allocation 921 in this section.] 923 DetNet S-Labels [I-D.ietf-detnet-mpls] for their definition) are 924 similar to other MPLS service labels that denote the contents of the 925 MPLS packet payload such as a layer 2 pseudowire, an IP packet that 926 is routed in a VPN context with a private address, or an Ethernet 927 virtual private network (EVPN) service. 929 S-Labels are expected to be allocated in the same manner as any other 930 service labels. S-Labels uniquely identify a particular DetNet flow, 931 and are local to the node on which the label is allocated. In the 932 DetNet service sub-layer the explicit route consists of the set of 933 Relay Nodes that the DetNet flow must traverse. They can be used to 934 identify the DetNet flow that a packet belongs to as it traverses a 935 particular node in a DetNet domain. Because labels are local to each 936 node rather than being a global identifier within a domain, they must 937 be advertised to their upstream DetNet service-aware peer nodes 938 (e.g., a DetNet MPLS End System or a DetNet Relay or Edge Node and 939 interpreted in the context of their received F-Label. 941 As discussed in Section 3, the forwarding sub-layer uses one or more 942 F-Labels to forward DetNet packets between DetNet service-aware nodes 943 along explicitly defined routes at the DetNet forwarding sub-layer, 944 which in the context of this document is MPLS. F-Labels can also 945 provide context for an S-Label. In the DetNet Forwarding (MPLS) sub- 946 layer the explicit route consists of the set of DetNet nodes which 947 are LSRs, links, and possibly link bundle members and queues that the 948 DetNet packets of a flow must traverse between nodes in the DetNet 949 service sub-layer (i.e. between a specific Edge Node and the next hop 950 Relay Node, between specific Relay Nodes, and between a specific 951 Relay node and the egress Edge Node. Resource allocation 952 corresponding to the set of Services supported over the forwarding 953 sub-layer, which may or may not include aggregation, is required at 954 this sub-layer. Explicit routes are used to ensure that packets are 955 routed through the resources that have been reserved for them, and 956 hence provide the DetNet application with the required service. 957 Multiple F-Labels may be pushed after an S-Label and there is no 958 requirement for all F-Labels to be controlled via the same controller 959 mechanisms. For example in EVPN, some labels are distributed using 960 BGP while others are distributed using LDP or RSVP. 962 Whether configuring, calculating and instantiating these routes is a 963 single-stage or multi-stage process, or in a centralized or 964 distributed manner, is out of scope of this document. 966 There are a number of approaches that could be used to provide 967 explicit routes and resource allocation in the MPLS forwarding sub- 968 layer: 970 o The path could be explicitly set up by a controller which 971 calculates the path and explicitly configures each node along that 972 path with the appropriate forwarding and resource allocation 973 information. 975 o The path could be set up using RSVP-TE signaling. 977 o The path could be implemented using MPLS-based segment routing 978 when extended to support resource allocation. 980 Much like other MPLS labels, there are a number of alternatives 981 available for DetNet S-Label and F-Label advertisement to an upstream 982 peer node. These include distributed signaling protocols such as 983 RSVP-TE, centralized label distribution via a controller that manages 984 both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., 985 and hybrid combinations of the two. The details of the controller 986 plane solution required for the label distribution and the management 987 of the label number space are out of scope of this document, but as 988 mentioned above, there are particular DetNet considerations and 989 requirements that are discussed in Section 4.1. 991 4.5. Packet Replication, Elimination, and Ordering (PREOF) 993 The controller plane protocol solution required for managing the 994 PREOF processing is outside the scope of this document. That said, 995 it should be noted that the ability to determine, for a particular 996 flow, optimal packet replication and elimination points in the DetNet 997 domain requires explicit support. There are be capabilities that can 998 be used, or extended, for example GMPLS end-to-end recovery [RFC4872] 999 and GMPLS segment recovery [RFC4873]. 1001 4.6. Contention Loss and Jitter Reduction 1003 As discussed in Section 1, this document does not specify the 1004 mechanisms needed to eliminate contention loss or reduce jitter for 1005 DetNet flows at the DetNet forwarding sub-layer. The ability to 1006 manage node and link resources to be able to provide these functions 1007 will be a necessary part of the DetNet controller plane. It will 1008 also be necessary to be able to control the required queuing 1009 mechanisms used to provide these functions along a flow's path 1010 through the network. See Section 4.1 for further discussion of these 1011 requirements. 1013 5. Security Considerations 1015 The security considerations of DetNet in general are discussed in 1016 [I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other 1017 security considerations will be added in a future version of this 1018 draft. 1020 6. IANA Considerations 1022 This document makes no IANA requests. 1024 7. Contributors 1026 RFC7322 limits the number of authors listed on the front page of a 1027 draft to a maximum of 5, far fewer than the many individuals below 1028 who made important contributions to this draft. The editor wishes to 1029 thank and acknowledge each of the following authors for contributing 1030 text to this draft. See also Section 8. 1032 Loa Andersson 1033 Huawei 1034 Email: loa@pi.nu 1036 Yuanlong Jiang 1037 Huawei 1038 Email: jiangyuanlong@huawei.com 1040 Norman Finn 1041 Huawei 1042 3101 Rio Way 1043 Spring Valley, CA 91977 1044 USA 1045 Email: norman.finn@mail01.huawei.com 1047 Janos Farkas 1048 Ericsson 1049 Magyar Tudosok krt. 11. 1050 Budapest 1117 1051 Hungary 1052 Email: janos.farkas@ericsson.com 1054 Carlos J. Bernardos 1055 Universidad Carlos III de Madrid 1056 Av. Universidad, 30 1057 Leganes, Madrid 28911 1058 Spain 1059 Email: cjbc@it.uc3m.es 1061 Tal Mizrahi 1062 Marvell 1063 6 Hamada st. 1064 Yokneam 1065 Israel 1066 Email: talmi@marvell.com 1067 Lou Berger 1068 LabN Consulting, L.L.C. 1069 Email: lberger@labn.net 1071 Stewart Bryant 1072 Huawei Technologies 1073 Email: stewart.bryant@gmail.com 1075 Mach Chen 1076 Huawei Technologies 1077 Email: mach.chen@huawei.com 1079 Andrew G. Malis 1080 Huawei Technologies 1081 Email: agmalis@gmail.com 1083 Don Fedyk 1084 LabN Consulting, L.L.C. 1085 Email: dfedyk@labn.net 1087 8. Acknowledgements 1089 The author(s) ACK and NACK. 1091 The following people were part of the DetNet Data Plane Solution 1092 Design Team: 1094 Jouni Korhonen 1096 Janos Farkas 1098 Norman Finn 1100 Balazs Varga 1102 Loa Andersson 1104 Tal Mizrahi 1106 David Mozes 1108 Yuanlong Jiang 1110 Andrew Malis 1112 Carlos J. Bernardos 1114 The DetNet chairs serving during the DetNet Data Plane Solution 1115 Design Team: 1117 Lou Berger 1119 Pat Thaler 1121 9. References 1123 9.1. Normative References 1125 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1126 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1127 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1128 . 1130 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1131 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1132 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1133 DOI 10.17487/RFC3473, January 2003, 1134 . 1136 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1137 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1138 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1139 February 2006, . 1141 9.2. Informative References 1143 [I-D.ietf-detnet-architecture] 1144 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1145 "Deterministic Networking Architecture", draft-ietf- 1146 detnet-architecture-12 (work in progress), March 2019. 1148 [I-D.ietf-detnet-flow-information-model] 1149 Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet 1150 Flow Information Model", draft-ietf-detnet-flow- 1151 information-model-03 (work in progress), March 2019. 1153 [I-D.ietf-detnet-ip] 1154 Korhonen, J., Varga, B., "DetNet Data Plane: IP", 2019. 1156 [I-D.ietf-detnet-mpls] 1157 Korhonen, J., Varga, B., "DetNet Data Plane: MPLS", 2019. 1159 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1160 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 1161 and Protocol Extensions for Using PCE as a Central 1162 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1163 extension-for-pce-controller-01 (work in progress), 1164 February 2019. 1166 [I-D.mpls-over-tsn] 1167 Korhonen, J., Varga, B., "DetNet Data Plane: MPLS over 1168 IEEE 802.1 Time Sensitive Networking (TSN)", 2019. 1170 [I-D.mpls-over-udp-ip] 1171 Korhonen, J., Varga, B., "DetNet Data Plane: MPLS over 1172 IP", 2019. 1174 [I-D.sdt-detnet-security] 1175 Mizrahi, T., Grossman, E., Hacker, A., Das, S., 1176 "Deterministic Networking (DetNet) Security 1177 Considerations, draft-sdt-detnet-security, work in 1178 progress", 2017. 1180 [I-D.spring-srv6-network-programming] 1181 Filsfils, C., Camarillo, P., "SRv6 Network Programming, 1182 draft-filsfils-spring-srv6-network-programming, work in 1183 progress", 2019. 1185 [IEEE802.1TSNTG] 1186 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 1187 Networking Task Group", . 1189 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1190 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1191 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1192 September 1997, . 1194 [RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A 1195 Framework for QoS-based Routing in the Internet", 1196 RFC 2386, DOI 10.17487/RFC2386, August 1998, 1197 . 1199 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 1200 W. Weiss, "Information Model for Describing Network Device 1201 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 1202 January 2004, . 1204 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 1205 Ed., "RSVP-TE Extensions in Support of End-to-End 1206 Generalized Multi-Protocol Label Switching (GMPLS) 1207 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 1208 . 1210 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1211 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1212 May 2007, . 1214 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1215 and D. McPherson, "Dissemination of Flow Specification 1216 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1217 . 1219 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 1220 Sprecher, N., and S. Ueno, "Requirements of an MPLS 1221 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 1222 September 2009, . 1224 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 1225 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 1226 Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, 1227 September 2011, . 1229 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1230 Extensions for Associated Bidirectional Label Switched 1231 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1232 . 1234 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 1235 (Diffserv) and Real-Time Communication", RFC 7657, 1236 DOI 10.17487/RFC7657, November 2015, 1237 . 1239 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1240 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1241 . 1243 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1244 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1245 . 1247 [RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. 1248 Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for 1249 Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August 1250 2017, . 1252 Authors' Addresses 1254 Balazs Varga (editor) 1255 Ericsson 1256 Magyar Tudosok krt. 11. 1257 Budapest 1117 1258 Hungary 1260 Email: balazs.a.varga@ericsson.com 1262 Janos Farkas 1263 Ericsson 1264 Magyar Tudosok krt. 11. 1265 Budapest 1117 1266 Hungary 1268 Email: janos.farkas@ericsson.com 1270 Lou Berger 1271 LabN Consulting, L.L.C. 1273 Email: lberger@labn.net 1275 Don Fedyk 1276 LabN Consulting, L.L.C. 1278 Email: dfedyk@labn.net 1280 Andrew G. Malis 1281 Huawei Technologies 1283 Email: agmalis@gmail.com 1285 Stewart Bryant 1286 Huawei Technologies 1288 Email: stewart.bryant@gmail.com 1290 Jouni Korhonen 1292 Email: jouni.nospam@gmail.com