idnits 2.17.1 draft-ietf-detnet-mpls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2019) is 1818 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: 'I-D.ietf-detnet-ip' is mentioned on line 120, but not defined == Missing Reference: 'Network' is mentioned on line 281, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-12 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: Standards Track 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: MPLS 15 draft-ietf-detnet-mpls-00 17 Abstract 19 This document specifies the Deterministic Networking data plane when 20 operating over an MPLS Packet Switched Networks. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 6, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 59 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 61 4. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 62 4.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 63 4.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 64 5. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 65 5.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 66 5.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 67 5.2.1. DetNet Control Word and the DetNet Sequence Number . 10 68 5.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 12 69 5.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 70 5.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17 71 5.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 72 5.4.1. Aggregation at the LSP . . . . . . . . . . . . . . . 17 73 5.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18 74 5.4.3. Simple Aggregation at the DetNet Layer . . . . . . . 19 75 5.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 76 5.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 20 77 5.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 20 78 5.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 79 5.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 80 5.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21 81 6. Flow Identification Management and Control Information . . . 22 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 88 11.2. Informative References . . . . . . . . . . . . . . . . . 26 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 91 1. Introduction 93 Deterministic Networking (DetNet) is a service that can be offered by 94 a network to DetNet flows. DetNet provides these flows extremely low 95 packet loss rates and assured maximum end-to-end delivery latency. 97 General background and concepts of DetNet can be found in 98 [I-D.ietf-detnet-architecture]. 100 The DetNet Architecture models the DetNet related data plane 101 functions decomposed into two sub-layers: a service sub-layer and a 102 forwarding sub-layer. The service sub-layer is used to provide 103 DetNet service functions such as protection and reordering. The 104 forwarding sub-layer is used to provide forwarding assurance (low 105 loss, assured latency, and limited reordering). 107 This document specifies the DetNet data plane operation and the on- 108 wire encapsulation of DetNet flows over an MPLS-based Packet Switched 109 Network (PSN) using the service sub-layer reference model. MPLS 110 encapsulation already provides a solid foundation of building blocks 111 to enable the DetNet service and forwarding sub-layer functions. 112 MPLS encapsulated DetNet can be carried over a variety of different 113 network technologies that can provide the DetNet required level of 114 service. However, the specific details of how DetNet MPLS is carried 115 over different network technologies is out of scope of this document. 117 MPLS encapsulated DetNet flows can carry different types of traffic. 118 The details of the types of traffic that are carried in DetNet are 119 also out of scope of this document. An example of IP using DetNet 120 MPLS sub-networks can be found in [I-D.ietf-detnet-ip]. DetNet MPLS 121 may use an associated controller and Operations, Administration, and 122 Maintenance (OAM) functions that are defined outside of this 123 document. 125 Important background information common to all data planes for DetNet 126 can be found in the DetNet Data Plane Framework 127 [I-D.ietf-detnet-data-plane-framework]. 129 2. Terminology 131 2.1. Terms Used in This Document 133 This document uses the terminology established in the DetNet 134 architecture [I-D.ietf-detnet-architecture] and the the DetNet Data 135 Plane Framework [I-D.ietf-detnet-data-plane-framework]. The reader 136 is assumed to be familiar with these documents and any terminology 137 defined therein. 139 The following terminology is introduced in this document: 141 F-Label A Detnet "forwarding" label that identifies the LSP 142 used to forward a DetNet flow across an MPLS PSN, e.g., 143 a hop-by-hop label used between label switching routers 144 (LSR). 146 S-Label A DetNet "service" label that is used between DetNet 147 nodes that implement also the DetNet service sub-layer 148 functions. An S-Label is also used to identify a 149 DetNet flow at DetNet service sub-layer. 151 d-CW A DetNet Control Word (d-CW) is used for sequencing 152 information of a DetNet flow at the DetNet service sub- 153 layer. 155 2.2. Abbreviations 157 The following abbreviations are used in this document: 159 AC Attachment Circuit. 161 CE Customer Edge equipment. 163 CoS Class of Service. 165 CW Control Word. 167 DetNet Deterministic Networking. 169 DF DetNet Flow. 171 DN-IWF DetNet Inter-Working Function. 173 L2 Layer 2. 175 L2VPN Layer 2 Virtual Private Network. 177 L3 Layer 3. 179 LSR Label Switching Router. 181 MPLS Multiprotocol Label Switching. 183 MPLS-TE Multiprotocol Label Switching - Traffic Engineering. 185 MPLS-TP Multiprotocol Label Switching - Transport Profile. 187 MS-PW Multi-Segment PseudoWire (MS-PW). 189 NSP Native Service Processing. 191 OAM Operations, Administration, and Maintenance. 193 PE Provider Edge. 195 PEF Packet Elimination Function. 197 PRF Packet Replication Function. 199 PREOF Packet Replication, Elimination and Ordering Functions. 201 POF Packet Ordering Function. 203 PSN Packet Switched Network. 205 PW PseudoWire. 207 QoS Quality of Service. 209 S-PE Switching Provider Edge. 211 T-PE Terminating Provider Edge. 213 TSN Time-Sensitive Network. 215 3. Requirements Language 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 219 "OPTIONAL" in this document are to be interpreted as described in BCP 220 14 [RFC2119] [RFC8174] when, and only when, they appear in all 221 capitals, as shown here. 223 4. DetNet MPLS Data Plane Overview 225 4.1. Layers of DetNet Data Plane 227 MPLS provides a wide range of capabilities that can be utilised by 228 DetNet. A straight forward approach utilizing MPLS for a DetNet 229 service sub-layer is based on the existing pseudowire (PW) 230 encapsulations and by utilizing existing MPLS Traffic Engineering 231 encapsulations and mechanisms. Background on PWs can be found in 232 [RFC3985] and [RFC3031]. Background on MPLS Traffic Engineering can 233 be found in [RFC3272] and [RFC3209]. 235 DetNet MPLS 236 . 237 Bottom of Stack . 238 (inner label) +------------+ 239 | Service | d-CW, S-Label 240 +------------+ 241 | Forwarding | F-Label(s) 242 +------------+ 243 Top of Stack . 244 (outer label) . 246 Figure 1: DetNet Adaptation to MPLS Data Plane 248 The DetNet MPLS data plane representation is illustrated in Figure 1. 249 The service sub-layer includes a DetNet control word (d-CW) and a 250 identifying service label (S-Label). The DetNet control word (d-CW) 251 conforms to the Generic PW MPLS Control Word (PWMCW) defined in 252 [RFC4385]. 254 A node operating on a DetNet flow in the Detnet service sub- 255 layer,uses the local context associated with that S-Label, provided 256 by a received F-Label, to determine what local DetNet operation(s) 257 are applied to that packet. An S-Label may be taken from the 258 platform label space [RFC3031], making it unique, enabling DetNet 259 flow identification regardless of which input interface or LSP the 260 packet arrives on. 262 The DetNet forwarding sub-layer is supported by one or more 263 forwarding labels (F-Labels). MPLS Traffic Engineering 264 encapsulations and mechanisms can be utilized to provide a forwarding 265 sub-layer that is responsible for providing resource allocation and 266 explicit routes. 268 4.2. DetNet MPLS Data Plane Scenarios 269 DetNet MPLS Relay Transit Relay DetNet MPLS 270 End System Node Node Node End System 271 (T-PE) (S-PE) (LSR) (S-PE) (T-PE) 272 +----------+ +----------+ 273 | Appl. |<------------ End to End Service ----------->| Appl. | 274 +----------+ +---------+ +---------+ +----------+ 275 | Service |<--| Service |-- DetNet flow --| Service |-->| Service | 276 +----------+ +---------+ +----------+ +---------+ +----------+ 277 |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| 278 +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ 279 : Link : / ,-----. \ : Link : / ,-----. \ 280 +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ 281 [Network] [Network] 282 `-----' `-----' 283 |<- LSP -->| |<-------- LSP -----------| |<--- LSP -->| 285 |<----------------- DetNet MPLS --------------------->| 287 Figure 2: A DetNet MPLS Network 289 Figure 2 illustrates a hypothetical DetNet MPLS-only network composed 290 of DetNet aware MPLS enabled end systems, operating over a DetNet 291 aware MPLS network. In this figure, the relay nodes are PE devices 292 that define the MPLS LSP boundaries and the transit nodes are LSRs. 294 DetNet end system and relay nodes understand the particular needs of 295 DetNet flows and provide both DetNet service and forwarding sub-layer 296 functions. In the case of MPLS, DetNet nodes add, remove and process 297 d-CWs, S-Labels and F-labels as needed. DetNet MPLS nodes provide 298 functionality analogous to T-PEs when they sit at the edge of an MPLS 299 domain, and S-PEs when they are in the middle of an MPLS domain, see 300 [RFC6073]. 302 In a DetNet MPLS network, transit nodes may be DetNet service aware 303 or may be DetNet unaware MPLS Label Switching Routers (LSRs). In 304 this latter case, such LSRs would be unaware of the special 305 requirements of the DetNet service sub-layer, but would still provide 306 traffic engineering functions and the QoS capabilities needed to 307 ensure that the (TE) LSPs meet the service requirements of the 308 carried DetNet flows. 310 The application of DetNet using MPLS supports a number of control 311 plane/management plane types. These types support certain MPLS data 312 plane deployments. For example RSVP-TE, MPLS-TP, or MPLS Segment 313 Routing (when extended to support resource allocation) are all valid 314 MPLS deployment cases. 316 Figure 3 illustrates how an end-to-end MPLS-based DetNet service is 317 provided in a more detail. In this figure, the customer end systems, 318 CE1 and CE2, are able to send and receive MPLS encapsulated DetNet 319 flows, and R1, R2 and R3 are relay nodes in the middle of a DetNet 320 network. The 'X' in the end systems, and relay nodes represents 321 potential DetNet compound flow packet replication and elimination 322 points. In this example, service protection is supported utilizing 323 least two DetNet member flows and TE LSPs. For a unidirectional 324 flow, R1 supports PRF and R3 supports PEF and POF. Note that the 325 relay nodes may change the underlying forwarding sub-layer, for 326 example tunneling MPLS over IEEE 802.1 TSN 327 [I-D.ietf-detnet-mpls-over-tsn], or simply over interconnect network 328 links. 330 DetNet DetNet 331 MPLS Service Transit Transit Service MPLS 332 DetNet | |<-Tnl->| |<-Tnl->| | DetNet 333 End | V 1 V V 2 V | End 334 System | +--------+ +--------+ +--------+ | System 335 +---+ | | R1 |=======| R2 |=======| R3 | | +---+ 336 | X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X | 337 |CE1|========| \ | | X | | / |======|CE2| 338 | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | 339 +---+ | |=======| |=======| | +---+ 340 ^ +--------+ +--------+ +--------+ ^ 341 | Relay Node Relay Node Relay Node | 342 | (S-PE) (S-PE) (S-PE) | 343 | | 344 |<---------------------- DetNet MPLS --------------------->| 345 | | 346 |<--------------- End to End DetNet Service -------------->| 348 -------------------------- Data Flow -------------------------> 350 X = Optional service protection (none, PRF, PREOF, PEF/POF) 351 DFx = DetNet member flow x over a TE LSP 353 Figure 3: MPLS-Based Native DetNet 355 5. MPLS-Based DetNet Data Plane Solution 357 5.1. DetNet Over MPLS Encapsulation Components 359 To carry DetNet over MPLS the following is required: 361 1. A method of identifying the MPLS payload type. 363 2. A method of identifying the DetNet flow group to the processing 364 element. 366 3. A method of distinguishing DetNet OAM packets from DetNet data 367 packets. 369 4. A method of carrying the DetNet sequence number. 371 5. A suitable LSP to deliver the packet to the egress PE. 373 6. A method of carrying queuing and forwarding indication. 375 In this design an MPLS service label (the S-Label), similar to a 376 pseudowire (PW) label [RFC3985], is used to identify both the DetNet 377 flow identity and the payload MPLS payload type satisfying (1) and 378 (2) in the list above. OAM traffic discrimination happens through 379 the use of the Associated Channel method described in [RFC4385]. The 380 DetNet sequence number is carried in the DetNet Control word which 381 carries the Data/OAM discriminator. To simplify implementation and 382 to maximize interoperability two sequence number sizes are supported: 383 a 16 bit sequence number and a 28 bit sequence number. The 16 bit 384 sequence number is needed to support some types of legacy clients. 385 The 28 bit sequence number is used in situations where it is 386 necessary ensure that in high speed networks the sequence number 387 space does not wrap whilst packets are in flight. 389 The LSP used to forward the DetNet packet may be of any type (MPLS- 390 LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR 391 [I-D.ietf-spring-segment-routing-mpls]). The LSP (F-Label) label 392 and/or the S-Label may be used to indicate the queue processing as 393 well as the forwarding parameters. Note that the possible use of 394 Penultimate Hop Popping (PHP) means that the S-Label may be the only 395 label received at the terminating DetNet service. 397 5.2. MPLS Data Plane Encapsulation 399 Figure 4 illustrates a DetNet data plane MPLS encapsulation. The 400 MPLS-based encapsulation of the DetNet flows is well suited for the 401 scenarios described in [I-D.ietf-detnet-data-plane-framework]. 402 Furthermore, an end to end DetNet service i.e., native DetNet 403 deployment (see Section 4.2) is also possible if DetNet end systems 404 are capable of initiating and termination MPLS encapsulated packets. 406 The MPLS-based DetNet data plane encapsulation consists of: 408 o DetNet control word (d-CW) containing sequencing information for 409 packet replication and duplicate elimination purposes, and the OAM 410 indicator. 412 o DetNet service Label (S-Label) that identifies a DetNet flow at 413 the receiving DetNet service sub-layer processing node. 415 o Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to 416 direct the packet along the label switched path (LSP) to the next 417 service sub-layer processing node along the path. When 418 Penultimate Hop Popping is in use there may be no label F-Label in 419 the protocol stack on the final hop. 421 o The necessary data-link encapsulation is then applied prior to 422 transmission over the physical media. 424 DetNet MPLS-based encapsulation 426 +---------------------------------+ 427 | | 428 | DetNet App-Flow | 429 | Payload Packet | 430 | | 431 +---------------------------------+ <--\ 432 | DetNet Control Word | | 433 +---------------------------------+ +--> DetNet data plane 434 | S-Label | | MPLS encapsulation 435 +---------------------------------+ | 436 | F-Label(s) | | 437 +---------------------------------+ <--/ 438 | Data-Link | 439 +---------------------------------+ 440 | Physical | 441 +---------------------------------+ 443 Figure 4: Encapsulation of a DetNet App-Flow in an MPLS(-TP) PSN 445 5.2.1. DetNet Control Word and the DetNet Sequence Number 447 A DetNet control word (d-CW) conforms to the Generic PW MPLS Control 448 Word (PWMCW) defined in [RFC4385]. The d-CW formatted as shown in 449 Figure 5 MUST be present in all DetNet packets containing app-flow 450 data. 452 0 1 2 3 453 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |0 0 0 0| Sequence Number | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 5: DetNet Control Word 460 (bits 0 to 3) 462 Per [RFC4385], MUST be set to zero (0). 464 Sequence Number (bits 4 to 31) 466 An unsigned value implementing the DetNet sequence number. 468 A separate sequence number space MUST be maintained by the node that 469 adds the d-CW for each DetNet app-flow. The following sequence 470 number field lengths MUST be supported: 472 0 bits 474 16 bits 476 28 bits 478 The sequence number length MUST be provisioned (configured) on a per 479 app-flow basis via configuration, e.g., the controller plane 480 described in [I-D.ietf-detnet-data-plane-framework]. 482 A 0 bit sequence number field length indicates that there is no 483 DetNet sequence number used for the flow. When the length is zero, 484 the sequence number field MUST be set to zero (0) on all packets sent 485 for the flow. 487 When the sequence number field length is 16 or 28 bits for a flow, 488 the sequence number MUST be incremented by one for each new app-flow 489 packet sent. When the field length is 16 bits, d-CW bits 4 to 15 490 MUST be set to zero (0). This values carried in this field can wrap 491 and it is important to note that zero (0) is a valid field value. 492 For example, were the sequence number size is 16 bits, the sequence 493 will contain: 65535, 0, 1. In this case, zero (0) is an ordinary 494 sequence number. This differs from [RFC4448] where a sequence number 495 of zero (0) does not indicate that no sequence number field value is 496 in use. 498 The sequence number is optionally used during receive processing as 499 described below in Section 5.2.2.1 and Section 5.2.2.2. 501 5.2.2. S-Labels 503 App-flow identification at a DetNet service sub-layer is realized by 504 an S-Label. Each app-flow MUST be sent by the node that adds a d-CW 505 with a single specific S-Label value. MPLS-aware DetNet end systems 506 and edge nodes, which are by definition MPLS ingress and egress 507 nodes, MUST add and remove the d-CW and S-Label. Relay nodes MAY 508 swap S-Label values when processing an app-flow. 510 The S-Label value MUST be provisioned per app-flow via configuration, 511 e.g., via the controller plane described in 512 [I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide 513 app-flow identification at the downstream DetNet service sub-layer 514 receiver, not the sender. As such, S-Labels MUST be allocated by the 515 entity that controls the service sub-layer receiving node's label 516 space, and MAY be allocated from the platform label space [RFC3031]. 518 The S-Label will normally be at the bottom of the label stack once 519 the last F-Label is removed, immediately preceding the d-CW. To 520 support service sub-layer level OAM, an OAM Associated Channel Header 521 (ACH) [RFC4385] together with a Generic Associated Channel Label 522 (GAL) [RFC5586] MAY be used in place of a d-CW. 524 Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) 525 [RFC6790] MAY be carried below the S-Label in the label stack in 526 networks where DetNet flows would otherwise received ECMP treatment. 527 When ELs are used, the same EL value SHOULD be used for all of the 528 packets sent using a specific S-Label to force the flow to follow the 529 same path. However, as outlines in 530 [I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet 531 flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows 532 within a DetNet domain. 534 When receiving a DetNet MPLS flow, an implementation MUST identify 535 the app-flow associated with the incoming packet based on the 536 S-Label. When a node is using platform labels for S-Labels, no 537 additional information is needed as the S-label uniquely identifies 538 the app-flow. In the case where platform labels are not used, one or 539 more F-Labels proceeding the S-Label MUST be used together with the 540 S-Label to uniquely identify the incoming app-flows. When PHP is 541 used, the incoming interface MAY also be used to together with any 542 present F-Label(s) and the S-Label to uniquely identify an incoming 543 app-flows. Note that choice to use platform label space for S-Label 544 or S-Label plus one or more F-Labels to identify app flows is a local 545 implementation choice, with one caveat. When one or more F-labels, 546 or incoming interface, is needed together with an S-Label to uniquely 547 identify, the controller plane MUST ensure that incoming DetNet MPLS 548 packets arrive with the needed information (F-label(s) and/or 549 incoming interface); the details of such are outside the scope of 550 this document. 552 The use of platform labels for S-Labels matches other pseudowire 553 encapsulations for consistency but there is no hard requirement in 554 this regard. 556 5.2.2.1. Packet Elimination Function Processing 558 Implementations MAY support the Packet Elimination Function (PEF) for 559 received DetNet MPLS flows. When supported, use of the PEF for a 560 particular app-flow MUST be provisioned via configuration, e.g., via 561 the controller plane described in 562 [I-D.ietf-detnet-data-plane-framework]. 564 After an app-flow is identified for a received DetNet MPLS packet, as 565 described above, an implementation MUST check if PEF is configured 566 for that app-flow. When configured the implementation MUST track the 567 sequence number contained in received d-CWs and MUST ensure that 568 duplicate (replicated) instances of a particular sequence number are 569 discarded. The specific mechanisms used for an implementation to 570 identify which received packets are duplicates and which are new is 571 an implementation choice. Note that per Section 5.2.1 the sequence 572 number field length may be 16 or 28 bits, and the field value can 573 wrap. 575 Note that an implementation MAY wish to constrain the maximum number 576 sequence numbers that are tracked, on platform-wide or per flow 577 basis. Some implementations MAY support the provisioning of the 578 maximum number sequence numbers that are tracked number on either a 579 platform-wide or per flow basis. 581 5.2.2.2. Packet Ordering Function Processing 583 A function that is related to PEF is the Packet Ordering Function 584 (POF). Implementations MAY support POF. When supported, use of the 585 POF for a particular app-flow MUST be provisioned via configuration, 586 e.g., via the controller plane described by 587 [I-D.ietf-detnet-data-plane-framework]. Implementations MAY required 588 that PEF and POF be used in combination. There is no requirement 589 related to the order of execution of the Packet Elimination and 590 Ordering Functions in an implementation. 592 After an app-flow is identified for a received DetNet MPLS packet, as 593 described above, an implementation MUST check if POF is configured 594 for that app-flow. When configured the implementation MUST track the 595 sequence number contained in received d-CWs and MUST ensure that 596 packets are processed in the order indicated in the received d-CW 597 sequence number field, which may not be in the order the packets are 598 received. As defined in Section 5.2.1 the sequence number field 599 length may be 16 or 28 bits, is incremented by one (1) for each new 600 app-flow packet sent, and the field value can wrap. The specific 601 mechanisms used for an implementation to identify the order of 602 received packets is an implementation choice. 604 Note that an implementation MAY wish to constrain the maximum number 605 of out of order packets that can be processed, on platform-wide or 606 per flow basis. Some implementations MAY support the provisioning of 607 this number on either a platform-wide or per flow basis. The number 608 of out of order packets that can be processed also impacts the 609 latency of a flow. 611 5.2.3. F-Labels 613 F-Labels are supported the DetNet forwarding sub-layer. F-Labels are 614 used to provide LSP-based connectivity between DetNet service sub- 615 layer processing nodes. 617 5.2.3.1. Service Sub-Layer and Packet Replication Function Processing 619 DetNet MPLS end systems, edge nodes and relay nodes may operate at 620 the DetNet service sub-layer with understand of app-flows and their 621 requirements. As mentioned earlier, when operating at this layer 622 such nodes can push, pop or swap (pop then push) S-Labels. In all 623 cases, the F-Labels used for the app-flow are always replaced and the 624 following procedures apply. 626 When sending a DetNet flow, Zero or more F-Labels MAY be added on top 627 of an S-Label by the node pushing an S-Label. The F-Labels to be 628 pushed when sending a particular app-flow MUST be provisioned per 629 app-flow via configuration, e.g., via the controller plane discussed 630 in [I-D.ietf-detnet-data-plane-framework]. To allow for the omission 631 of F-Labels, an implementation SHOULD also allow an outgoing 632 interface to be provisioned. 634 The Packet Replication Function (PRF) function MAY be supported by an 635 implementation for outgoing DetNet flows. When replication is 636 supported, the same app-flow data will be sent over multiple outgoing 637 forwarding sub-layer LSPs. To support PRF an implementation MUST 638 support the setting of different sets of F-Labels. Therefore, to 639 allow for the omission of F-Labels, an implementation SHOULD also 640 allow multiple outgoing interfaces to be provisioned. PRF MUST NOT 641 be used with app-flows configured with a d-CW sequence number field 642 length of 0 bits. 644 When a single set of F-Labels is provisioned for a particular 645 outgoing app-flow, that set of F-labels MUST be pushed after the 646 S-Label is pushed. The outgoing packet is then forwarded as 647 described below in Section 5.2.3.2. When a single outgoing interface 648 is provisioned, the outgoing packet is then forwarded as described 649 below in Section 5.2.3.2. 651 When multiple sets of F-Labels or interfaces are provisioned for a 652 particular outgoing app-flow, a copy of the outgoing packet, 653 including the pushed S-Label, MUST be made per F-label set and 654 outgoing interface. Each set of provisioned F-Labels are then pushed 655 onto a copy of the packet. Each copy is then forwarded as described 656 below in Section 5.2.3.2. 658 As described in the previous section, when receiving a DetNet MPLS 659 flow, an implementation identifies the app-flow associated with the 660 incoming packet based on the S-Label. When a node is using platform 661 labels for S-Labels, any F-Labels can be popped and the S-label 662 uniquely identifies the app-flow. In the case where platform labels 663 are not used, F-Label(s) MUST also be provisioned for incoming app- 664 flows. When PHP is used, incoming interface MUST be provisioned. 665 The provisioned information MUST then be used to identify incoming 666 app-flows based on the combination of S-Label and F-Label(s) or 667 incoming interface. 669 5.2.3.2. Common F-Label Processing 671 All DetNet aware MPLS nodes process F-Labels as needed to meet the 672 service requirements of the DetNet flow or flows carried in the LSPs 673 represented by the F-Labels. This includes normal push, pop and swap 674 operations. Such processing is essentially the same type of 675 processing enabled for TE LSPs, although the specific service 676 parameters, or traffic specification, can differ. When the DetNet 677 service parameters of the app-flow or flows carried in an LSP 678 represented by an F-Label can be met by an exiting TE mechanism, the 679 forwarding sub-layer processing node MAY be a DetNet unaware, i.e., 680 standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service 681 as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], 682 [RFC3473], [RFC4875], [RFC5440], and [RFC6006]. 684 More specifically, as mentioned above, the DetNet forwarding sub- 685 layer provides explicit routes and allocated resources, and F-Labels 686 are used to map to each. Explicit routes are supported based on the 687 topmost (outermost) F-Label that is pushed or swapped and the LSP 688 that corresponds to this label. This topmost (outgoing) label MUST 689 be associated with a provisioned outgoing interface and, for non- 690 point-to-point outgoing interfaces, a next hop LSR. Note that this 691 information MUST be provisioned via configuration or the controller 692 plane. In the previously mentioned special case where there is no 693 added F-labels and the outgoing interface is not a point-to-point 694 interface, the outgoing interface MUST also be associated with a next 695 hop LSR. 697 Resources may be allocated in a hierarchical fashion per LSP that is 698 represented by each F-Label. Each LSP MAY be provisioned with a 699 service parameters that dictates the specific traffic treatment to be 700 received by the traffic carried over that LSP. Implementations of 701 this document MUST ensure that traffic carried over each LSP 702 represented by an F-Label receives the traffic treatment provisioned 703 for that LSP. Typical mechanisms used to provide different treatment 704 to different flows includes the allocation of system resources (such 705 as queues and buffers) and provisioning or related parameters (such 706 as shaping, and policing). Support can also be provided via an 707 underlying network technology such IEEE802.1 TSN 708 [I-D.ietf-detnet-mpls-over-tsn]. Other than in the TSN case, the 709 specific mechanisms used by a DetNet node to ensure DetNet service 710 delivery requirements are met for supported DetNet flows is outside 711 the scope of this document. 713 Packets that are marked in a way that does not correspond to 714 allocated resources, e.g., lack a provisioned F-Label, can disrupt 715 the QoS offered to properly reserved DetNet flows by using resources 716 allocated to the reserved flows. Therefore, the network nodes of a 717 DetNet network: 719 o MUST defend the DetNet QoS by discarding or remarking (to an 720 allocated DetNet flow or non-competing non-DetNet flow) packets 721 received that are not associated with a completed resource 722 allocation. 724 o MUST NOT use a DetNet allocated resource, e.g. a queue or shaper 725 reserved for DetNet flows, for any packet that does match the 726 corresponding DetNet flow. 728 o MUST ensure a QoS flow does not exceed its allocated resources or 729 provisioned service level, 731 o MUST ensure a CoS flow or service class does not impact the 732 service delivered to other flows. This requirement is similar to 733 requirement for MPLS LSRs to that CoS LSPs do not impact the 734 resources allocated to TE LSPs, e.g., via [RFC3473]. 736 Subsequent sections provide additional considerations related to CoS 737 (Section 5.6.1), QoS (Section 5.6.2) and aggregation (Section 5.4). 739 5.3. OAM Indication 741 OAM follows the procedures set out in [RFC5085] with the restriction 742 that only Virtual Circuit Connectivity Verification (VCCV) type 1 is 743 supported. 745 As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW 746 is 0x0 the payload following the d-CW is normal user data. However, 747 when the first nibble of the d-CW is 0X1, the payload that follows 748 the d-DW is an OAM payload with the OAM type indicated by the value 749 in the d-CW Channel Type field. 751 The reader is referred to [RFC5085] for a more detailed description 752 of the Associated Channel mechanism, and to the DetNet work on OAM 753 for more information DetNet OAM. 755 5.4. Flow Aggregation 757 [Author's note: need to revisit this section and ensure that we cover 758 (and fully specify) desired types of aggregation.] 760 1. Aggregate at the LSP (Forwarding) 762 2. Aggregating DetNet flows as a new DetNet flow 764 3. Simple Aggregation at the DetNet layer 766 The resource control and management aspects of aggregation (including 767 the queuing/shaping/ policing implications) will be covered in other 768 documents. 770 The ability to aggregate individual flows, and their associated 771 resource control, into a larger aggregate is an important technique 772 for improving scaling of control in the data, management and control 773 planes. The DetNet data plane allows for the aggregation of DetNet 774 flows, to improved scaling. There are three methods of introducing 775 flow aggregation: 777 5.4.1. Aggregation at the LSP 779 DetNet flows forwarded via MPLS can leverage MPLS-TE's existing 780 support for hierarchical LSPs (H-LSPs), see [RFC4206]. H-LSPs are 781 typically used to aggregate control and resources, they may also be 782 used to provide OAM or protection for the aggregated LSPs. Arbitrary 783 levels of aggregation naturally falls out of the definition for 784 hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which 785 support aggregation (LSP hierarchy) map one or more LSPs (labels) 786 into and from an H-LSP. Both carried LSPs and H-LSPs may or may not 787 use the TC field, i.e., L-LSPs or E-LSPs. Such nodes will need to 788 ensure that traffic from aggregated LSPs are placed (shaped/policed/ 789 enqueued) onto the H-LSPs in a fashion that ensures the required 790 DetNet service is preserved. 792 Additional details of the traffic control capabilities needed at a 793 DetNet-aware node may be covered in the new service descriptions 794 mentioned above or in separate future documents. Controller plane 795 mechanisms will also need to ensure that the service required on the 796 aggregate flow (H-LSP or DSCP) are provided, which may include the 797 discarding or remarking mentioned in the previous sections. 799 5.4.2. Aggregating DetNet Flows as a new DetNet flow 801 An aggregate can be built by layering DetNet flows as shown below: 803 +---------------------------------+ 804 | | 805 | DetNet Flow | 806 | Payload Packet | 807 | | 808 +---------------------------------+ <--\ 809 | DetNet Control Word | | 810 +=================================+ | 811 | S-Label | | 812 +---------------------------------+ +----DetNet data plane 813 | DetNet Control Word | | MPLS encapsulation 814 +=================================+ | 815 | A-Label | | 816 +---------------------------------+ | 817 | F-Label(s) | <--/ 818 +---------------------------------+ 819 | Data-Link | 820 +---------------------------------+ 821 | Physical | 822 +---------------------------------+ 824 Figure 6: DetNet Aggregation as a new DetNet Flow 826 Both the Aggregation (A) label and the S-Label have their MPLS S bit 827 set indicating bottom of stack, and the d-CW allows the PREOF to 828 work. 830 It is a property of the A-label that what follows is d-CW followed by 831 an S-Label. A relay node processing the A-label would not know the 832 underlying payload type. This would only be known to a node that was 833 a peer of the node imposing the S-Label. However there is no real 834 need for it to know the payload type during aggregation processing. 836 5.4.3. Simple Aggregation at the DetNet Layer 838 Another approach would be not to include a d-CW for the aggregated 839 flow. This would be functionally similar to aggregation at the 840 forwarding sub-layer using H-LSPs, but would confine knowledge of the 841 aggregation to the DetNet layer. Such an approach shares the 842 disadvantage that PREOF operations would not be possible. OAM 843 operation in this mode is for further study. 845 +---------------------------------+ 846 | | 847 | DetNet Flow | 848 | Payload Packet | 849 | | 850 +---------------------------------+ <--\ 851 | DetNet Control Word | | 852 +=================================+ | 853 | S-Label | +----DetNet data plane 854 +---------------------------------+ | MPLS encapsulation 855 | A-Label | | 856 +---------------------------------+ | 857 | F-Label(s) | <--/ 858 +---------------------------------+ 859 | Data-Link | 860 +---------------------------------+ 861 | Physical | 862 +---------------------------------+ 864 Figure 7: Simple DetNet Aggregation 866 5.5. Service Sub-Layer Considerations 868 The edge and relay node internal procedures related to PREOF are 869 implementation specific. The order of a packet elimination or 870 replication is out of scope in this specification. 872 It is important that the DetNet layer is configured such that a 873 DetNet node never receives its own replicated packets. If it were to 874 receive such packets the replication function would make the loop 875 more destructive of bandwidth than a conventional unicast loop. 876 Ultimately the TTL in the S-Label will cause the packet to die during 877 a transient loop, but given the sensitivity of applications to packet 878 latency the impact on the DetNet application would be severe. 880 5.5.1. Edge Node Processing 882 An edge node is responsible for matching ingress packets to the 883 service they require and encapsulating them accordingly. An edge 884 node may participate in the packet replication and duplicate packet 885 elimination. 887 The DetNet-aware forwarder selects the egress DetNet member flow 888 segment based on the flow identification. The mapping of ingress 889 DetNet member flow segment to egress DetNet member flow segment may 890 be statically or dynamically configured. Additionally the DetNet- 891 aware forwarder does duplicate frame elimination based on the flow 892 identification and the sequence number combination. The packet 893 replication is also done within the DetNet-aware forwarder. During 894 elimination and the replication process the sequence number of the 895 DetNet member flow MUST be preserved and copied to the egress DetNet 896 member flow. 898 The internal design of a relay node is out of scope of this document. 899 However the reader's attention is drawn to the need to make any PREOF 900 state available to the packet processor(s) dealing with packets to 901 which the PREOF functions must be applied, and to maintain that state 902 is such as way that it is available to the packet processor operation 903 on the next packet in the DetNet flow (which may be a duplicate, a 904 late packet, or the next packet in sequence. 906 5.5.2. Relay Node Processing 908 A DetNet Relay node operates in the DetNet forwarding sub-layer . 909 For DetNet using MPLS this processing is performed on the F-Label. 910 This processing is done within an extended forwarder function. 911 Whether an ingress DetNet member flow receives DetNet specific 912 processing depends on how the forwarding is programmed. Some relay 913 nodes may be DetNet service aware, while others may be unmodified 914 LSRs that only understand how to swicth MPLS-TE LSPs. 916 It is also possible to treat the relay node as a transit node, see 917 Section 5.4. Again, this is entirely up to how the forwarding has 918 been programmed. 920 5.6. Forwarding Sub-Layer Considerations 922 5.6.1. Class of Service 924 Class and quality of service, i.e., CoS and QoS, are terms that are 925 often used interchangeably and confused with each other. In the 926 context of DetNet, CoS is used to refer to mechanisms that provide 927 traffic forwarding treatment based on aggregate group basis and QoS 928 is used to refer to mechanisms that provide traffic forwarding 929 treatment based on a specific DetNet flow basis. Examples of 930 existing network level CoS mechanisms include DiffServ which is 931 enabled by IP header differentiated services code point (DSCP) field 932 [RFC2474] and MPLS label traffic class field [RFC5462], and at Layer- 933 2, by IEEE 802.1p priority code point (PCP). 935 CoS for DetNet flows carried in PWs and MPLS is provided using the 936 existing MPLS Differentiated Services (DiffServ) architecture 937 [RFC3270]. Both E-LSP and L-LSP MPLS DiffServ modes MAY be used to 938 support DetNet flows. The Traffic Class field (formerly the EXP 939 field) of an MPLS label follows the definition of [RFC5462] and 940 [RFC3270]. The Uniform, Pipe, and Short Pipe DiffServ tunneling and 941 TTL processing models are described in [RFC3270] and [RFC3443] and 942 MAY be used for MPLS LSPs supporting DetNet flows. MPLS ECN MAY also 943 be used as defined in ECN [RFC5129] and updated by [RFC5462]. 945 5.6.2. Quality of Service 947 In addition to explicit routes, and packet replication and 948 elimination, described in Section 5 above, DetNet provides zero 949 congestion loss and bounded latency and jitter. As described in 950 [I-D.ietf-detnet-architecture], there are different mechanisms that 951 maybe used separately or in combination to deliver a zero congestion 952 loss service. This includes Quality of Service (QoS) mechanisms at 953 the MPLS layer, that may be combined with the mechanisms defined by 954 the underlying network layer such as 802.1TSN. 956 Quality of Service (QoS) mechanisms for flow specific traffic 957 treatment typically includes a guarantee/agreement for the service, 958 and allocation of resources to support the service. Example QoS 959 mechanisms include discrete resource allocation, admission control, 960 flow identification and isolation, and sometimes path control, 961 traffic protection, shaping, policing and remarking. Example 962 protocols that support QoS control include Resource ReSerVation 963 Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. 964 The existing MPLS mechanisms defined to support CoS [RFC3270] can 965 also be used to reserve resources for specific traffic classes. 967 A baseline set of QoS capabilities for DetNet flows carried in PWs 968 and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE) 969 [RFC3209] and [RFC3473]. TE LSPs can also support explicit routes 970 (path pinning). Current service definitions for packet TE LSPs can 971 be found in "Specification of the Controlled Load Quality of 972 Service", [RFC2211], "Specification of Guaranteed Quality of 973 Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. 974 Additional service definitions are expected in future documents to 975 support the full range of DetNet services. In all cases, the 976 existing label-based marking mechanisms defined for TE-LSPs and even 977 E-LSPs are use to support the identification of flows requiring 978 DetNet QoS. 980 6. Flow Identification Management and Control Information 982 [Editor's Note] The following will summarize the set of information 983 that is needed to support the MPLS DetNet data plane. 985 7. Security Considerations 987 The security considerations of DetNet in general are discussed in 988 [I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other 989 security considerations will be added in a future version of this 990 draft. 992 8. IANA Considerations 994 This document makes no IANA requests. 996 9. Contributors 998 RFC7322 limits the number of authors listed on the front page of a 999 draft to a maximum of 5, far fewer than the many individuals below 1000 who made important contributions to this draft. The editor wishes to 1001 thank and acknowledge each of the following authors for contributing 1002 text to this draft. See also Section 10. 1004 Loa Andersson 1005 Huawei 1006 Email: loa@pi.nu 1008 Yuanlong Jiang 1009 Huawei 1010 Email: jiangyuanlong@huawei.com 1012 Norman Finn 1013 Huawei 1014 3101 Rio Way 1015 Spring Valley, CA 91977 1016 USA 1017 Email: norman.finn@mail01.huawei.com 1019 Janos Farkas 1020 Ericsson 1021 Magyar Tudosok krt. 11. 1022 Budapest 1117 1023 Hungary 1024 Email: janos.farkas@ericsson.com 1026 Carlos J. Bernardos 1027 Universidad Carlos III de Madrid 1028 Av. Universidad, 30 1029 Leganes, Madrid 28911 1030 Spain 1031 Email: cjbc@it.uc3m.es 1033 Tal Mizrahi 1034 Marvell 1035 6 Hamada st. 1036 Yokneam 1037 Israel 1038 Email: talmi@marvell.com 1040 Lou Berger 1041 LabN Consulting, L.L.C. 1042 Email: lberger@labn.net 1044 Stewart Bryant 1045 Huawei Technologies 1046 Email: stewart.bryant@gmail.com 1048 Mach Chen 1049 Huawei Technologies 1050 Email: mach.chen@huawei.com 1052 Andrew G. Malis 1053 Huawei Technologies 1054 Email: agmalis@gmail.com 1056 Don Fedyk 1057 LabN Consulting, L.L.C. 1058 Email: dfedyk@labn.net 1060 10. Acknowledgements 1062 The author(s) ACK and NACK. 1064 The following people were part of the DetNet Data Plane Solution 1065 Design Team: 1067 Jouni Korhonen 1069 Janos Farkas 1071 Norman Finn 1072 Balazs Varga 1074 Loa Andersson 1076 Tal Mizrahi 1078 David Mozes 1080 Yuanlong Jiang 1082 Andrew Malis 1084 Carlos J. Bernardos 1086 The DetNet chairs serving during the DetNet Data Plane Solution 1087 Design Team: 1089 Lou Berger 1091 Pat Thaler 1093 Thanks for Stewart Bryant for his extensive review of the previous 1094 versions of the document. 1096 11. References 1098 11.1. Normative References 1100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1101 Requirement Levels", BCP 14, RFC 2119, 1102 DOI 10.17487/RFC2119, March 1997, 1103 . 1105 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 1106 Network Element Service", RFC 2211, DOI 10.17487/RFC2211, 1107 September 1997, . 1109 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1110 of Guaranteed Quality of Service", RFC 2212, 1111 DOI 10.17487/RFC2212, September 1997, 1112 . 1114 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1115 Label Switching Architecture", RFC 3031, 1116 DOI 10.17487/RFC3031, January 2001, 1117 . 1119 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1120 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1121 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1122 . 1124 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1125 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1126 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1127 . 1129 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1130 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1131 Protocol Label Switching (MPLS) Support of Differentiated 1132 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 1133 . 1135 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 1136 in Multi-Protocol Label Switching (MPLS) Networks", 1137 RFC 3443, DOI 10.17487/RFC3443, January 2003, 1138 . 1140 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1141 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1142 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1143 DOI 10.17487/RFC3473, January 2003, 1144 . 1146 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1147 Hierarchy with Generalized Multi-Protocol Label Switching 1148 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1149 DOI 10.17487/RFC4206, October 2005, 1150 . 1152 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1153 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1154 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1155 February 2006, . 1157 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1158 Circuit Connectivity Verification (VCCV): A Control 1159 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1160 December 2007, . 1162 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1163 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 1164 2008, . 1166 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1167 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1168 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 1169 2009, . 1171 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1172 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1173 May 2017, . 1175 11.2. Informative References 1177 [I-D.ietf-detnet-architecture] 1178 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1179 "Deterministic Networking Architecture", draft-ietf- 1180 detnet-architecture-12 (work in progress), March 2019. 1182 [I-D.ietf-detnet-data-plane-framework] 1183 Korhonen, J., Varga, B., "DetNet Data Plane Framework", 1184 2019. 1186 [I-D.ietf-detnet-mpls-over-tsn] 1187 Korhonen, J., Varga, B., "DetNet MPLS over IEEE 802.1 TSN 1188 Sub-Networks", 2019. 1190 [I-D.ietf-spring-segment-routing-mpls] 1191 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1192 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1193 data plane", draft-ietf-spring-segment-routing-mpls-22 1194 (work in progress), May 2019. 1196 [I-D.sdt-detnet-security] 1197 Mizrahi, T., Grossman, E., Hacker, A., Das, S., 1198 "Deterministic Networking (DetNet) Security 1199 Considerations, draft-sdt-detnet-security, work in 1200 progress", 2017. 1202 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1203 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1204 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1205 September 1997, . 1207 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1208 "Definition of the Differentiated Services Field (DS 1209 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1210 DOI 10.17487/RFC2474, December 1998, 1211 . 1213 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 1214 Xiao, "Overview and Principles of Internet Traffic 1215 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 1216 . 1218 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1219 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1220 DOI 10.17487/RFC3985, March 2005, 1221 . 1223 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1224 "Encapsulation Methods for Transport of Ethernet over MPLS 1225 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1226 . 1228 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1229 Yasukawa, Ed., "Extensions to Resource Reservation 1230 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1231 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1232 DOI 10.17487/RFC4875, May 2007, 1233 . 1235 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1236 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1237 DOI 10.17487/RFC5440, March 2009, 1238 . 1240 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1241 "MPLS Generic Associated Channel", RFC 5586, 1242 DOI 10.17487/RFC5586, June 2009, 1243 . 1245 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 1246 L., and L. Berger, "A Framework for MPLS in Transport 1247 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 1248 . 1250 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 1251 RFC 6003, DOI 10.17487/RFC6003, October 2010, 1252 . 1254 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 1255 Ali, Z., and J. Meuric, "Extensions to the Path 1256 Computation Element Communication Protocol (PCEP) for 1257 Point-to-Multipoint Traffic Engineering Label Switched 1258 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 1259 . 1261 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1262 Aissaoui, "Segmented Pseudowire", RFC 6073, 1263 DOI 10.17487/RFC6073, January 2011, 1264 . 1266 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1267 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1268 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1269 . 1271 Authors' Addresses 1273 Balazs Varga (editor) 1274 Ericsson 1275 Magyar Tudosok krt. 11. 1276 Budapest 1117 1277 Hungary 1279 Email: balazs.a.varga@ericsson.com 1281 Janos Farkas 1282 Ericsson 1283 Magyar Tudosok krt. 11. 1284 Budapest 1117 1285 Hungary 1287 Email: janos.farkas@ericsson.com 1289 Lou Berger 1290 LabN Consulting, L.L.C. 1292 Email: lberger@labn.net 1294 Don Fedyk 1295 LabN Consulting, L.L.C. 1297 Email: dfedyk@labn.net 1299 Andrew G. Malis 1300 Huawei Technologies 1302 Email: agmalis@gmail.com 1303 Stewart Bryant 1304 Huawei Technologies 1306 Email: stewart.bryant@gmail.com 1308 Jouni Korhonen 1310 Email: jouni.nospam@gmail.com