idnits 2.17.1 draft-ietf-detnet-mpls-02.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 (October 16, 2019) is 1654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Network' is mentioned on line 270, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-02 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-ip-over-mpls-01 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-mpls-over-tsn-00 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-05 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: April 18, 2020 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 A. Malis 9 Independent 10 S. Bryant 11 Futurewei Technologies 12 J. Korhonen 13 October 16, 2019 15 DetNet Data Plane: MPLS 16 draft-ietf-detnet-mpls-02 18 Abstract 20 This document specifies the Deterministic Networking data plane when 21 operating over an MPLS Packet Switched Networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 18, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 60 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 62 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 63 3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 64 3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 65 4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 66 4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 67 4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 68 4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 69 4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11 70 4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 71 4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 16 72 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 73 4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17 74 4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 17 75 4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 76 4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19 77 4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 19 78 4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 79 4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 80 4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 20 81 5. Management and Control Information Summary . . . . . . . . . 21 82 5.1. Service Sub-Layer Information Summary . . . . . . . . . . 21 83 5.1.1. Service Aggregation Information Summary . . . . . . . 22 84 5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 90 9.2. Informative References . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 93 1. Introduction 95 Deterministic Networking (DetNet) is a service that can be offered by 96 a network to DetNet flows. DetNet provides these flows extremely low 97 packet loss rates and assured maximum end-to-end delivery latency. 98 General background and concepts of DetNet can be found in 99 [I-D.ietf-detnet-architecture]. 101 The DetNet Architecture models the DetNet related data plane 102 functions decomposed into two sub-layers: a service sub-layer and a 103 forwarding sub-layer. The service sub-layer is used to provide 104 DetNet service functions such as protection and reordering. The 105 forwarding sub-layer is used to provide forwarding assurance (low 106 loss, assured latency, and limited reordering). 108 This document specifies the DetNet data plane operation and the on- 109 wire encapsulation of DetNet flows over an MPLS-based Packet Switched 110 Network (PSN) using the service sub-layer reference model. MPLS 111 encapsulation already provides a solid foundation of building blocks 112 to enable the DetNet service and forwarding sub-layer functions. 113 MPLS encapsulated DetNet can be carried over a variety of different 114 network technologies that can provide the DetNet required level of 115 service. However, the specific details of how DetNet MPLS is carried 116 over different network technologies is out of scope of this document. 118 MPLS encapsulated DetNet flows can carry different types of traffic. 119 The details of the types of traffic that are carried in DetNet are 120 also out of scope of this document. An example of IP using DetNet 121 MPLS sub-networks can be found in [I-D.ietf-detnet-ip]. DetNet MPLS 122 may use an associated controller and Operations, Administration, and 123 Maintenance (OAM) functions that are defined outside of this 124 document. 126 Background information common to all data planes for DetNet can be 127 found in the DetNet Data Plane Framework 128 [I-D.ietf-detnet-data-plane-framework]. 130 2. Terminology 132 2.1. Terms Used in This Document 134 This document uses the terminology established in the DetNet 135 architecture [I-D.ietf-detnet-architecture] and the the DetNet Data 136 Plane Framework [I-D.ietf-detnet-data-plane-framework]. The reader 137 is assumed to be familiar with these documents and any terminology 138 defined therein. 140 The following terminology is introduced in this document: 142 F-Label A Detnet "forwarding" label that identifies the LSP 143 used to forward a DetNet flow across an MPLS PSN, e.g., 144 a hop-by-hop label used between label switching routers 145 (LSR). 147 S-Label A DetNet "service" label that is used between DetNet 148 nodes that implement also the DetNet service sub-layer 149 functions. An S-Label is also used to identify a 150 DetNet flow at DetNet service sub-layer. 152 A-Label A special case of an S-Label, whose aggregation 153 properties are known only at the aggregation and 154 deaggregation end-points. 156 d-CW A DetNet Control Word (d-CW) is used for sequencing 157 information of a DetNet flow at the DetNet service sub- 158 layer. 160 2.2. Abbreviations 162 The following abbreviations are used in this document: 164 CoS Class of Service. 166 CW Control Word. 168 DetNet Deterministic Networking. 170 LSR Label Switching Router. 172 MPLS Multiprotocol Label Switching. 174 MPLS-TE Multiprotocol Label Switching - Traffic Engineering. 176 MPLS-TP Multiprotocol Label Switching - Transport Profile. 178 OAM Operations, Administration, and Maintenance. 180 PE Provider Edge. 182 PEF Packet Elimination Function. 184 PRF Packet Replication Function. 186 PREOF Packet Replication, Elimination and Ordering Functions. 188 POF Packet Ordering Function. 190 PSN Packet Switched Network. 192 PW PseudoWire. 194 QoS Quality of Service. 196 S-PE Switching Provider Edge. 198 T-PE Terminating Provider Edge. 200 TSN Time-Sensitive Network. 202 2.3. Requirements Language 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 3. DetNet MPLS Data Plane Overview 212 3.1. Layers of DetNet Data Plane 214 MPLS provides a wide range of capabilities that can be utilised by 215 DetNet. A straight forward approach utilizing MPLS for a DetNet 216 service sub-layer is based on the existing pseudowire (PW) 217 encapsulations and by utilizing existing MPLS Traffic Engineering 218 encapsulations and mechanisms. Background on PWs can be found in 219 [RFC3985] and [RFC3031]. Background on MPLS Traffic Engineering can 220 be found in [RFC3272] and [RFC3209]. 222 DetNet MPLS 223 . 224 Bottom of Stack . 225 (inner label) +------------+ 226 | Service | d-CW, S-Label (A-Label) 227 +------------+ 228 | Forwarding | F-Label(s) 229 +------------+ 230 Top of Stack . 231 (outer label) . 233 Figure 1: DetNet Adaptation to MPLS Data Plane 235 The DetNet MPLS data plane representation is illustrated in Figure 1. 236 The service sub-layer includes a DetNet control word (d-CW) and a 237 identifying service label (S-Label). The DetNet control word (d-CW) 238 conforms to the Generic PW MPLS Control Word (PWMCW) defined in 239 [RFC4385]. An aggregation label (A-Label) is a special case of 240 S-Label used for aggregation. 242 A node operating on a DetNet flow in the Detnet service sub- 243 layer,uses the local context associated with that S-Label, provided 244 by a received F-Label, to determine what local DetNet operation(s) 245 are applied to that packet. An S-Label may be taken from the 246 platform label space [RFC3031], making it unique, enabling DetNet 247 flow identification regardless of which input interface or LSP the 248 packet arrives on. 250 The DetNet forwarding sub-layer is supported by zero or more 251 forwarding labels (F-Labels). MPLS Traffic Engineering 252 encapsulations and mechanisms can be utilized to provide a forwarding 253 sub-layer that is responsible for providing resource allocation and 254 explicit routes. 256 3.2. DetNet MPLS Data Plane Scenarios 258 DetNet MPLS Relay Transit Relay DetNet MPLS 259 End System Node Node Node End System 260 (T-PE) (S-PE) (LSR) (S-PE) (T-PE) 261 +----------+ +----------+ 262 | Appl. |<------------ End to End Service ----------->| Appl. | 263 +----------+ +---------+ +---------+ +----------+ 264 | Service |<--| Service |-- DetNet flow --| Service |-->| Service | 265 +----------+ +---------+ +----------+ +---------+ +----------+ 266 |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| 267 +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ 268 : Link : / ,-----. \ : Link : / ,-----. \ 269 +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ 270 [Network] [Network] 271 `-----' `-----' 272 |<- LSP -->| |<-------- LSP -----------| |<--- LSP -->| 274 |<----------------- DetNet MPLS --------------------->| 276 Figure 2: A DetNet MPLS Network 278 Figure 2 illustrates a hypothetical DetNet MPLS-only network composed 279 of DetNet aware MPLS enabled end systems, operating over a DetNet 280 aware MPLS network. In this figure, the relay nodes are PE devices 281 that define the MPLS LSP boundaries and the transit nodes are LSRs. 283 DetNet end system and relay nodes understand the particular needs of 284 DetNet flows and provide both DetNet service and forwarding sub-layer 285 functions. In the case of MPLS, DetNet service-aware nodes add, 286 remove and process d-CWs, S-Labels and F-labels as needed. DetNet 287 MPLS nodes provide functionality analogous to T-PEs when they sit at 288 the edge of an MPLS domain, and S-PEs when they are in the middle of 289 an MPLS domain, see [RFC6073]. 291 In a DetNet MPLS network, transit nodes may be DetNet service aware 292 or may be DetNet unaware MPLS Label Switching Routers (LSRs). In 293 this latter case, such LSRs would be unaware of the special 294 requirements of the DetNet service sub-layer, but would still provide 295 traffic engineering functions and the QoS capabilities needed to 296 ensure that the (TE) LSPs meet the service requirements of the 297 carried DetNet flows. 299 The application of DetNet using MPLS supports a number of control 300 plane/management plane types. These types support certain MPLS data 301 plane deployments. For example RSVP-TE, MPLS-TP, or MPLS Segment 302 Routing (when extended to support resource allocation) are all valid 303 MPLS deployment cases. 305 Figure 3 illustrates how an end-to-end MPLS-based DetNet service is 306 provided in a more detail. In this figure, the customer end systems, 307 CE1 and CE2, are able to send and receive MPLS encapsulated DetNet 308 flows, and R1, R2 and R3 are relay nodes in the middle of a DetNet 309 network. The 'X' in the end systems, and relay nodes represents 310 potential DetNet compound flow packet replication and elimination 311 points. In this example, service protection is supported utilizing 312 at least two DetNet member flows and TE LSPs. For a unidirectional 313 flow, R1 supports PRF and R3 supports PEF and POF. Note that the 314 relay nodes may change the underlying forwarding sub-layer, for 315 example tunneling MPLS over IEEE 802.1 TSN 316 [I-D.ietf-detnet-mpls-over-tsn], or simply over interconnect network 317 links. 319 DetNet DetNet 320 MPLS Service Transit Transit Service MPLS 321 DetNet | |<-Tnl->| |<-Tnl->| | DetNet 322 End | V 1 V V 2 V | End 323 System | +--------+ +--------+ +--------+ | System 324 +---+ | | R1 |=======| R2 |=======| R3 | | +---+ 325 | X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X | 326 |CE1|========| \ | | X | | / |======|CE2| 327 | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | 328 +---+ | |=======| |=======| | +---+ 329 ^ +--------+ +--------+ +--------+ ^ 330 | Relay Node Relay Node Relay Node | 331 | (S-PE) (S-PE) (S-PE) | 332 | | 333 |<---------------------- DetNet MPLS --------------------->| 334 | | 335 |<--------------- End to End DetNet Service -------------->| 337 -------------------------- Data Flow -------------------------> 339 X = Optional service protection (none, PRF, PREOF, PEF/POF) 340 DFx = DetNet member flow x over a TE LSP 342 Figure 3: MPLS-Based Native DetNet 344 4. MPLS-Based DetNet Data Plane Solution 346 4.1. DetNet Over MPLS Encapsulation Components 348 To carry DetNet over MPLS the following is required: 350 1. A method of identifying the MPLS payload type. 352 2. A method of identifying the DetNet flow group to the processing 353 element. 355 3. A method of distinguishing DetNet OAM packets from DetNet data 356 packets. 358 4. A method of carrying the DetNet sequence number. 360 5. A suitable LSP to deliver the packet to the egress PE. 362 6. A method of carrying queuing and forwarding indication. 364 In this design an MPLS service label (the S-Label), similar to a 365 pseudowire (PW) label [RFC3985], is used to identify both the DetNet 366 flow identity and the payload MPLS payload type satisfying (1) and 367 (2) in the list above. OAM traffic discrimination happens through 368 the use of the Associated Channel method described in [RFC4385]. The 369 DetNet sequence number is carried in the DetNet Control word which 370 carries the Data/OAM discriminator. To simplify implementation and 371 to maximize interoperability two sequence number sizes are supported: 372 a 16 bit sequence number and a 28 bit sequence number. The 16 bit 373 sequence number is needed to support some types of legacy clients. 374 The 28 bit sequence number is used in situations where it is 375 necessary ensure that in high speed networks the sequence number 376 space does not wrap whilst packets are in flight. 378 The LSP used to forward the DetNet packet may be of any type (MPLS- 379 LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR 380 [I-D.ietf-spring-segment-routing-mpls]). The LSP (F-Label) label 381 and/or the S-Label may be used to indicate the queue processing as 382 well as the forwarding parameters. Note that the possible use of 383 Penultimate Hop Popping (PHP) means that the S-Label may be the only 384 label received at the terminating DetNet service. 386 4.2. MPLS Data Plane Encapsulation 388 Figure 4 illustrates a DetNet data plane MPLS encapsulation. The 389 MPLS-based encapsulation of the DetNet flows is well suited for the 390 scenarios described in [I-D.ietf-detnet-data-plane-framework]. 391 Furthermore, an end to end DetNet service i.e., native DetNet 392 deployment (see Section 3.2) is also possible if DetNet end systems 393 are capable of initiating and termination MPLS encapsulated packets. 395 The MPLS-based DetNet data plane encapsulation consists of: 397 o DetNet control word (d-CW) containing sequencing information for 398 packet replication and duplicate elimination purposes, and the OAM 399 indicator. 401 o DetNet service Label (S-Label) that identifies a DetNet flow at 402 the receiving DetNet service sub-layer processing node. 404 o Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to 405 direct the packet along the label switched path (LSP) to the next 406 service sub-layer processing node along the path. When 407 Penultimate Hop Popping is in use there may be no label F-Label in 408 the protocol stack on the final hop. 410 o The necessary data-link encapsulation is then applied prior to 411 transmission over the physical media. 413 DetNet MPLS-based encapsulation 415 +---------------------------------+ 416 | | 417 | DetNet App-Flow | 418 | Payload Packet | 419 | | 420 +---------------------------------+ <--\ 421 | DetNet Control Word | | 422 +---------------------------------+ +--> DetNet data plane 423 | S-Label | | MPLS encapsulation 424 +---------------------------------+ | 425 | [ F-Label(s) ] | | 426 +---------------------------------+ <--/ 427 | Data-Link | 428 +---------------------------------+ 429 | Physical | 430 +---------------------------------+ 432 Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN 434 4.2.1. DetNet Control Word and the DetNet Sequence Number 436 A DetNet control word (d-CW) conforms to the Generic PW MPLS Control 437 Word (PWMCW) defined in [RFC4385]. The d-CW formatted as shown in 438 Figure 5 MUST be present in all DetNet packets containing app-flow 439 data. 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |0 0 0 0| Sequence Number | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 5: DetNet Control Word 449 (bits 0 to 3) 451 Per [RFC4385], MUST be set to zero (0). 453 Sequence Number (bits 4 to 31) 455 An unsigned value implementing the DetNet sequence number. 457 A separate sequence number space MUST be maintained by the node that 458 adds the d-CW for each DetNet app-flow. The following sequence 459 number field lengths MUST be supported: 461 0 bits 463 16 bits 465 28 bits 467 The sequence number length MUST be provisioned on a per app-flow 468 basis via configuration, i.e., via the controller plane described in 469 [I-D.ietf-detnet-data-plane-framework]. 471 A 0 bit sequence number field length indicates that there is no 472 DetNet sequence number used for the flow. When the length is zero, 473 the sequence number field MUST be set to zero (0) on all packets sent 474 for the flow. 476 When the sequence number field length is 16 or 28 bits for a flow, 477 the sequence number MUST be incremented by one for each new app-flow 478 packet sent. When the field length is 16 bits, d-CW bits 4 to 15 479 MUST be set to zero (0). The values carried in this field can wrap 480 and it is important to note that zero (0) is a valid field value. 481 For example, were the sequence number size is 16 bits, the sequence 482 will contain: 65535, 0, 1, where zero (0) is an ordinary sequence 483 number. 485 It is important to note that this document differs from [RFC4448] 486 where a sequence number of zero (0) is used to indicate that the 487 sequence number check algorithm is not used. 489 The sequence number is optionally used during receive processing as 490 described below in Section 4.2.2.1 and Section 4.2.2.2. 492 4.2.2. S-Labels 494 App-flow identification at a DetNet service sub-layer is realized by 495 an S-Label. MPLS-aware DetNet end systems and edge nodes, which are 496 by definition MPLS ingress and egress nodes, MUST add and remove an 497 app-flow specific d-CW and S-Label. Relay nodes MAY swap S-Label 498 values when processing an app-flow. 500 The S-Label value MUST be provisioned per app-flow via configuration, 501 e.g., via the controller plane described in 502 [I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide 503 app-flow identification at the downstream DetNet service sub-layer 504 receiver, not the sender. As such, S-Labels MUST be allocated by the 505 entity that controls the service sub-layer receiving node's label 506 space, and MAY be allocated from the platform label space [RFC3031]. 507 Because S-Labels are local to each node rather than being a global 508 identifier within a domain, they must be advertised to their upstream 509 DetNet service-aware peer nodes (e.g., a DetNet MPLS End System or a 510 DetNet Relay or Edge Node and interpreted in the context of their 511 received F-Label. 513 The S-Label will normally be at the bottom of the label stack once 514 the last F-Label is removed, immediately preceding the d-CW. To 515 support service sub-layer level OAM, an OAM Associated Channel Header 516 (ACH) [RFC4385] together with a Generic Associated Channel Label 517 (GAL) [RFC5586] MAY be used in place of a d-CW. 519 Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) 520 [RFC6790] MAY be carried below the S-Label in the label stack in 521 networks where DetNet flows would otherwise received ECMP treatment. 522 When ELs are used, the same EL value SHOULD be used for all of the 523 packets sent using a specific S-Label to force the flow to follow the 524 same path. However, as outlines in 525 [I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet 526 flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows 527 within a DetNet domain. 529 When receiving a DetNet MPLS flow, an implementation MUST identify 530 the app-flow associated with the incoming packet based on the 531 S-Label. When a node is using platform labels for S-Labels, no 532 additional information is needed as the S-label uniquely identifies 533 the app-flow. In the case where platform labels are not used, zero 534 or more F-Labels and optionally, the incoming interface, proceeding 535 the S-Label MUST be used together with the S-Label to uniquely 536 identify the app-flows associated with a received packet. The 537 incoming interface MAY also be used to together with any present 538 F-Label(s) and the S-Label to uniquely identify an incoming app- 539 flows, for example, to in the case where PHP is used. Note that 540 choice to use platform label space for S-Label or S-Label plus one or 541 more F-Labels to identify app flows is a local implementation choice, 542 with one caveat. When one or more F-labels, or incoming interface, 543 is needed together with an S-Label to uniquely identify, the 544 controller plane MUST ensure that incoming DetNet MPLS packets arrive 545 with the needed information (F-label(s) and/or incoming interface); 546 the details of such are outside the scope of this document. 548 The use of platform labels for S-Labels matches other pseudowire 549 encapsulations for consistency but there is no hard requirement in 550 this regard. 552 4.2.2.1. Packet Elimination Function Processing 554 Implementations MAY support the Packet Elimination Function (PEF) for 555 received DetNet MPLS flows. When supported, use of the PEF for a 556 particular app-flow MUST be provisioned via configuration, e.g., via 557 the controller plane described in 558 [I-D.ietf-detnet-data-plane-framework]. 560 After an app-flow is identified for a received DetNet MPLS packet, as 561 described above, an implementation MUST check if PEF is configured 562 for that app-flow. When configured, the implementation MUST track 563 the sequence number contained in received d-CWs and MUST ensure that 564 duplicate (replicated) instances of a particular sequence number are 565 discarded. The specific mechanisms used for an implementation to 566 identify which received packets are duplicates and which are new is 567 an implementation choice. Note that per Section 4.2.1 the sequence 568 number field length may be 16 or 28 bits, and the field value can 569 wrap. 571 Note that an implementation MAY wish to constrain the maximum number 572 sequence numbers that are tracked, on platform-wide or per flow 573 basis. Some implementations MAY support the provisioning of the 574 maximum number sequence numbers that are tracked number on either a 575 platform-wide or per flow basis. 577 4.2.2.2. Packet Ordering Function Processing 579 A function that is related to in-order delivery is the Packet 580 Ordering Function (POF). Implementations MAY support POF. When 581 supported, use of the POF for a particular app-flow MUST be 582 provisioned via configuration, e.g., via the controller plane 583 described by [I-D.ietf-detnet-data-plane-framework]. Implementations 584 MAY required that PEF and POF be used in combination. There is no 585 requirement related to the order of execution of the Packet 586 Elimination and Ordering Functions in an implementation. 588 After an app-flow is identified for a received DetNet MPLS packet, as 589 described above, an implementation MUST check if POF is configured 590 for that app-flow. When configured, the implementation MUST track 591 the sequence number contained in received d-CWs and MUST ensure that 592 packets are processed in the order indicated in the received d-CW 593 sequence number field, which may not be in the order the packets are 594 received. As defined in Section 4.2.1 the sequence number field 595 length may be 16 or 28 bits, is incremented by one (1) for each new 596 app-flow packet sent, and the field value can wrap. The specific 597 mechanisms used for an implementation to identify the order of 598 received packets is an implementation choice. 600 Note that an implementation MAY wish to constrain the maximum number 601 of out of order packets that can be processed, on platform-wide or 602 per flow basis. Some implementations MAY support the provisioning of 603 this number on either a platform-wide or per flow basis. The number 604 of out of order packets that can be processed also impacts the 605 latency of a flow. 607 4.2.3. F-Labels 609 F-Labels are supported the DetNet forwarding sub-layer. F-Labels are 610 used to provide LSP-based connectivity between DetNet service sub- 611 layer processing nodes. 613 4.2.3.1. Service Sub-Layer and Packet Replication Function Processing 615 DetNet MPLS end systems, edge nodes and relay nodes may operate at 616 the DetNet service sub-layer with understand of app-flows and their 617 requirements. As mentioned earlier, when operating at this layer 618 such nodes can push, pop or swap (pop then push) S-Labels. In all 619 cases, the F-Labels used for the app-flow are always replaced and the 620 following procedures apply. 622 When sending a DetNet flow, zero or more F-Labels MAY be pushed on 623 top of an S-Label by the node pushing an S-Label. The F-Labels to be 624 pushed when sending a particular app-flow MUST be provisioned per 625 app-flow via configuration, e.g., via the controller plane discussed 626 in [I-D.ietf-detnet-data-plane-framework]. F-Labels can also provide 627 context for an S-Label. To allow for the omission of F-Labels, an 628 implementation SHOULD also allow an outgoing interface to be used. 630 The Packet Replication Function (PRF) function MAY be supported by an 631 implementation for outgoing DetNet flows. When replication is 632 supported, the same app-flow data will be sent over multiple outgoing 633 forwarding sub-layer LSPs. To support PRF an implementation MUST 634 support the setting of different sets of F-Labels. To allow for the 635 omission of F-Labels, an implementation SHOULD also allow multiple 636 outgoing interfaces to be provisioned. PRF MUST NOT be used with 637 app-flows configured with a d-CW sequence number field length of 0 638 bits. 640 When a single set of F-Labels is provisioned for a particular 641 outgoing app-flow, that set of F-labels MUST be pushed after the 642 S-Label is pushed. The outgoing packet is then forwarded as 643 described below in Section 4.2.3.2. When a single outgoing interface 644 is provisioned, the outgoing packet is then forwarded as described 645 below in Section 4.2.3.2. 647 When multiple sets of F-Labels or interfaces are provisioned for a 648 particular outgoing app-flow, a copy of the outgoing packet, 649 including the pushed S-Label, MUST be made per F-label set and 650 outgoing interface. Each set of provisioned F-Labels are then pushed 651 onto a copy of the packet. Each copy is then forwarded as described 652 below in Section 4.2.3.2. 654 As described in the previous section, when receiving a DetNet MPLS 655 flow, an implementation identifies the app-flow associated with the 656 incoming packet based on the S-Label. When a node is using platform 657 labels for S-Labels, any F-Labels can be popped and the S-label 658 uniquely identifies the app-flow. In the case where platform labels 659 are not used, F-Label(s) and, optionally, the incoming interface MUST 660 also be provisioned for incoming app-flows. The provisioned 661 information MUST then be used to identify incoming app-flows based on 662 the combination of S-Label and F-Label(s) or incoming interface. 664 4.2.3.2. Common F-Label Processing 666 All DetNet aware MPLS nodes process F-Labels as needed to meet the 667 service requirements of the DetNet flow or flows carried in the LSPs 668 represented by the F-Labels. This includes normal push, pop and swap 669 operations. Such processing is essentially the same type of 670 processing provided for TE LSPs, although the specific service 671 parameters, or traffic specification, can differ. When the DetNet 672 service parameters of the app-flow or flows carried in an LSP 673 represented by an F-Label can be met by an exiting TE mechanism, the 674 forwarding sub-layer processing node MAY be a DetNet unaware, i.e., 675 standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service 676 as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], 677 [RFC3473], [RFC4875], [RFC5440], and [RFC8306]. 679 More specifically, as mentioned above, the DetNet forwarding sub- 680 layer provides explicit routes and allocated resources, and F-Labels 681 are used to map to each. Explicit routes are supported based on the 682 topmost (outermost) F-Label that is pushed or swapped and the LSP 683 that corresponds to this label. This topmost (outgoing) label MUST 684 be associated with a provisioned outgoing interface and, for non- 685 point-to-point outgoing interfaces, a next hop LSR. Note that this 686 information MUST be provisioned via configuration or the controller 687 plane. In the previously mentioned special case where there are no 688 added F-labels and the outgoing interface is not a point-to-point 689 interface, the outgoing interface MUST also be associated with a next 690 hop LSR. 692 Resources may be allocated in a hierarchical fashion per LSP that is 693 represented by each F-Label. Each LSP MAY be provisioned with a 694 service parameters that dictates the specific traffic treatment to be 695 received by the traffic carried over that LSP. Implementations of 696 this document MUST ensure that traffic carried over each LSP 697 represented by one or more F-Labels receives the traffic treatment 698 provisioned for that LSP. Typical mechanisms used to provide 699 different treatment to different flows includes the allocation of 700 system resources (such as queues and buffers) and provisioning or 701 related parameters (such as shaping, and policing). Support can also 702 be provided via an underlying network technology such IEEE802.1 TSN 703 [I-D.ietf-detnet-mpls-over-tsn]. The specific mechanisms used by a 704 DetNet node to ensure DetNet service delivery requirements are met 705 for supported DetNet flows is outside the scope of this document. 707 Packets that are marked in a way that do not correspond to allocated 708 resources, e.g., lack a provisioned F-Label, can disrupt the QoS 709 offered to properly reserved DetNet flows by using resources 710 allocated to the reserved flows. Therefore, the network nodes of a 711 DetNet network: 713 o MUST defend the DetNet QoS by discarding or remarking (to an 714 allocated DetNet flow or non-competing non-DetNet flow) packets 715 received that are not associated with a completed resource 716 allocation. 718 o MUST NOT use a DetNet allocated resource, e.g. a queue or shaper 719 reserved for DetNet flows, for any packet that does match the 720 corresponding DetNet flow. 722 o MUST ensure a QoS flow does not exceed its allocated resources or 723 provisioned service level, 725 o MUST ensure a CoS flow or service class does not impact the 726 service delivered to other flows. This requirement is similar to 727 requirement for MPLS LSRs to that CoS LSPs do not impact the 728 resources allocated to TE LSPs, e.g., via [RFC3473]. 730 Subsequent sections provide additional considerations related to CoS 731 (Section 4.6.1), QoS (Section 4.6.2) and aggregation (Section 4.4). 733 4.3. OAM Indication 735 OAM follows the procedures set out in [RFC5085] with the restriction 736 that only Virtual Circuit Connectivity Verification (VCCV) type 1 is 737 supported. 739 As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW 740 is 0x0 the payload following the d-CW is normal user data. However, 741 when the first nibble of the d-CW is 0X1, the payload that follows 742 the d-DW is an OAM payload with the OAM type indicated by the value 743 in the d-CW Channel Type field. 745 The reader is referred to [RFC5085] for a more detailed description 746 of the Associated Channel mechanism, and to the DetNet work on OAM 747 for more information DetNet OAM. 749 4.4. Flow Aggregation 751 The ability to aggregate individual flows, and their associated 752 resource control, into a larger aggregate is an important technique 753 for improving scaling of control in the data, management and control 754 planes. The DetNet data plane allows for the aggregation of DetNet 755 flows, to improved scaling. There are two methods of supporting flow 756 aggregation covered in this section. 758 The resource control and management aspects of aggregation (including 759 the configuration of queuing, shaping, and policing) are the 760 responsibility of the DetNet controller plane and is out of scope of 761 this documents. It is also the responsibility of the controller 762 plane to ensure that consistent aggregation methods are used. 764 4.4.1. Aggregation Via LSP Hierarchy 766 DetNet flows forwarded via MPLS can leverage MPLS-TE's existing 767 support for hierarchical LSPs (H-LSPs), see [RFC4206]. H-LSPs are 768 typically used to aggregate control and resources, they may also be 769 used to provide OAM or protection for the aggregated LSPs. Arbitrary 770 levels of aggregation naturally falls out of the definition for 771 hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which 772 support aggregation (LSP hierarchy) map one or more LSPs (labels) 773 into and from an H-LSP. Both carried LSPs and H-LSPs may or may not 774 use the TC field, i.e., L-LSPs or E-LSPs. Such nodes will need to 775 ensure that individual LSPs and H-LSPs receive the traffic treatment 776 required to ensure the required DetNet service is preserved. 778 Additional details of the traffic control capabilities needed at a 779 DetNet-aware node may be covered in the new service definitions 780 mentioned above or in separate future documents. Controller plane 781 mechanisms will also need to ensure that the service required on the 782 aggregate flow are provided, which may include the discarding or 783 remarking mentioned in the previous sections. 785 4.4.2. Aggregating DetNet Flows as a new DetNet flow 787 An aggregate can be built by layering DetNet flows, including both 788 their S-Label and, when present, F-Labels as shown below: 790 +---------------------------------+ 791 | | 792 | DetNet Flow | 793 | Payload Packet | 794 | | 795 +---------------------------------+ <--\ 796 | DetNet Control Word | | 797 +=================================+ | 798 | S-Label | | 799 +---------------------------------+ | 800 | [ F-Label(s) ] | +----DetNet data plane 801 +---------------------------------+ | 802 | DetNet Control Word | | 803 +=================================+ | 804 | A-Label | | 805 +---------------------------------+ | 806 | F-Label(s) | <--/ 807 +---------------------------------+ 808 | Data-Link | 809 +---------------------------------+ 810 | Physical | 811 +---------------------------------+ 813 Figure 6: DetNet Aggregation as a new DetNet Flow 815 Both the aggregation label, which is referred to as an A-Label, and 816 the individual flow's S-Label have their MPLS S bit set indicating 817 bottom of stack, and the d-CW allows the PREOF to work. An A-Label 818 is a special case of an S-Label, whose properties are known only at 819 the aggregation and deaggregation end-points. 821 It is a property of the A-Label that what follows is a d-CW followed 822 by an MPLS label stack. A relay node processing the A-Label would 823 not know the underlying payload type, and the A-Label would be 824 process as a normal S-Label. This would only be known to a node that 825 was a peer of the node imposing the S-Label. However there is no 826 real need for it to know the payload type during aggregation 827 processing. 829 As in the previous section, nodes supporting this type of aggregation 830 will need to ensure that individual and aggregated flows receive the 831 traffic treatment required to ensure the required DetNet service is 832 preserved. Also, it is the controller plane's responsibility to to 833 ensure that the service required on the aggregate flow are properly 834 provisioned. 836 4.5. Service Sub-Layer Considerations 838 The edge and relay node internal procedures related to PREOF are 839 implementation specific. The order of a packet elimination or 840 replication is out of scope in this specification. 842 It is important that the DetNet layer is configured such that a 843 DetNet node never receives its own replicated packets. If it were to 844 receive such packets the replication function would make the loop 845 more destructive of bandwidth than a conventional unicast loop. 846 Ultimately the TTL in the S-Label will cause the packet to die during 847 a transient loop, but given the sensitivity of applications to packet 848 latency the impact on the DetNet application would be severe. To 849 avoid the problem of a transient forwarding loop, changes to an LSP 850 supporting DetNet MUST be loop-free. 852 4.5.1. Edge Node Processing 854 An edge node is responsible for matching ingress packets to the 855 service they require and encapsulating them accordingly. An edge 856 node may participate in the packet replication and duplicate packet 857 elimination. 859 The DetNet-aware forwarder selects the egress DetNet member flow 860 segment based on the flow identification. The mapping of ingress 861 DetNet member flow segment to egress DetNet member flow segment may 862 be statically or dynamically configured. Additionally the DetNet- 863 aware forwarder does duplicate frame elimination based on the flow 864 identification and the sequence number combination. The packet 865 replication is also done within the DetNet-aware forwarder. During 866 elimination and the replication process the sequence number of the 867 DetNet member flow MUST be preserved and copied to the egress DetNet 868 member flow. 870 The internal design of a relay node is out of scope of this document. 871 However the reader's attention is drawn to the need to make any PREOF 872 state available to the packet processor(s) dealing with packets to 873 which the PREOF functions must be applied, and to maintain that state 874 is such as way that it is available to the packet processor operation 875 on the next packet in the DetNet flow (which may be a duplicate, a 876 late packet, or the next packet in sequence. 878 4.5.2. Relay Node Processing 880 A DetNet Relay node operates in the DetNet forwarding sub-layer . 881 For DetNet using MPLS this processing is performed on the F-Label. 882 This processing is done within an extended forwarder function. 883 Whether an ingress DetNet member flow receives DetNet specific 884 processing depends on how the forwarding is programmed. Some relay 885 nodes may be DetNet service aware, while others may be unmodified 886 LSRs that only understand how to switch MPLS-TE LSPs. 888 It is also possible to treat the relay node as a transit node, see 889 Section 4.4. Again, this is entirely up to how the forwarding has 890 been programmed. 892 4.6. Forwarding Sub-Layer Considerations 894 4.6.1. Class of Service 896 Class and quality of service, i.e., CoS and QoS, are terms that are 897 often used interchangeably and confused with each other. In the 898 context of DetNet, CoS is used to refer to mechanisms that provide 899 traffic forwarding treatment based on aggregate group basis and QoS 900 is used to refer to mechanisms that provide traffic forwarding 901 treatment based on a specific DetNet flow basis. Examples of 902 existing network level CoS mechanisms include DiffServ which is 903 enabled by IP header differentiated services code point (DSCP) field 904 [RFC2474] and MPLS label traffic class field [RFC5462], and at Layer- 905 2, by IEEE 802.1p priority code point (PCP). 907 CoS for DetNet flows carried in PWs and MPLS is provided using the 908 existing MPLS Differentiated Services (DiffServ) architecture 909 [RFC3270]. Both E-LSP and L-LSP MPLS DiffServ modes MAY be used to 910 support DetNet flows. The Traffic Class field (formerly the EXP 911 field) of an MPLS label follows the definition of [RFC5462] and 912 [RFC3270]. The Uniform, Pipe, and Short Pipe DiffServ tunneling and 913 TTL processing models are described in [RFC3270] and [RFC3443] and 914 MAY be used for MPLS LSPs supporting DetNet flows. MPLS ECN MAY also 915 be used as defined in ECN [RFC5129] and updated by [RFC5462]. 917 4.6.2. Quality of Service 919 In addition to explicit routes, and packet replication and 920 elimination, described in Section 4 above, DetNet provides zero 921 congestion loss and bounded latency and jitter. As described in 922 [I-D.ietf-detnet-architecture], there are different mechanisms that 923 maybe used separately or in combination to deliver a zero congestion 924 loss service. This includes Quality of Service (QoS) mechanisms at 925 the MPLS layer, that may be combined with the mechanisms defined by 926 the underlying network layer such as 802.1TSN. 928 Quality of Service (QoS) mechanisms for flow specific traffic 929 treatment typically includes a guarantee/agreement for the service, 930 and allocation of resources to support the service. Example QoS 931 mechanisms include discrete resource allocation, admission control, 932 flow identification and isolation, and sometimes path control, 933 traffic protection, shaping, policing and remarking. Example 934 protocols that support QoS control include Resource ReSerVation 935 Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. 936 The existing MPLS mechanisms defined to support CoS [RFC3270] can 937 also be used to reserve resources for specific traffic classes. 939 A baseline set of QoS capabilities for DetNet flows carried in PWs 940 and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE) 941 [RFC3209] and [RFC3473]. TE LSPs can also support explicit routes 942 (path pinning). Current service definitions for packet TE LSPs can 943 be found in "Specification of the Controlled Load Quality of 944 Service", [RFC2211], "Specification of Guaranteed Quality of 945 Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. 946 Additional service definitions are expected in future documents to 947 support the full range of DetNet services. In all cases, the 948 existing label-based marking mechanisms defined for TE-LSPs and even 949 E-LSPs are use to support the identification of flows requiring 950 DetNet QoS. 952 5. Management and Control Information Summary 954 The specific information needed for the processing of each DetNet 955 service depends on the DetNet node type and the functions being 956 provided on the node. This section summarizes based on the DetNet 957 sub-layer and if the DetNet traffic is being sent or received. All 958 DetNet node types are DetNet forwarding sub-layer aware, while all 959 but transit nodes are service sub-layer aware. This is shown in 960 Figure 2. 962 Much like other MPLS labels, there are a number of alternatives 963 available for DetNet S-Label and F-Label advertisement to an upstream 964 peer node. These include distributed signaling protocols such as 965 RSVP-TE, centralized label distribution via a controller that manages 966 both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., 967 and hybrid combinations of the two. The details of the controller 968 plane solution required for the label distribution and the management 969 of the label number space are out of scope of this document. There 970 are particular DetNet considerations and requirements that are 971 discussed in [I-D.ietf-detnet-data-plane-framework]. 973 5.1. Service Sub-Layer Information Summary 975 The following summarizes the information that is needed on service 976 sub-layer aware nodes that send DetNet MPLS traffic, on a per service 977 basis: 979 o App-Flow identification information, e.g., an incoming service on 980 a relay node or IP information as defined in 981 [I-D.ietf-detnet-ip-over-mpls]. 983 o The sequence number length to be used for the service. Valid 984 values included 0, 16 and 28 bits. 0 bits cannot be used when PRF 985 is configured for the service. 987 o The S-Label for the service. 989 o If PRF is to be provided for the service. 991 o The forwarding sub-layer information associated with the output of 992 the service sub-layer. Note that when the PRF function is 993 provisioned, this information is per DetNet member flow. 994 Logically this is a pointer to details provided below for 995 transmission of Detnet flows at the forwarding sub-layer. 997 The following summarizes the information that is needed on service 998 sub-layer aware nodes that receives DetNet MPLS traffic, on a per 999 service basis: 1001 o The forwarding sub-layer information associated with the input of 1002 the service sub-layer. Note that when the PEF function is 1003 provisioned, this information is per DetNet member flow. 1004 Logically this is a pointer to details provided below related to 1005 the reception of Detnet flows at the forwarding sub-layer or 1006 A-Label. 1008 o The S-Label for the received service. 1010 o If PEF or POF is to be provided for the service. 1012 o The sequence number length to be used for the service. Valid 1013 values included 0, 16 and 28 bits. 0 bits cannot be used when PEF 1014 or POF are configured for the service. 1016 5.1.1. Service Aggregation Information Summary 1018 Nodes performing aggregation using A-Labels, per 1019 Section Section 4.4.2, require the additional information summarized 1020 in this section. 1022 The following summarizes the information that is needed on a node 1023 that sends aggregated flows using A-Labels: 1025 o The S-Labels or F-Labels that are to be carried over each 1026 aggregated service. 1028 o The A-Label associated with each aggregated service. 1030 o The other S-Label information summarized above. 1032 On the receiving node, the A-Label provides the forwarding context of 1033 an incoming interface or an F-Label and is used in subsequent service 1034 or forwarding sub-layer receive processing, as appropriated. The 1035 related addition configuration that may be provided discussed 1036 elsewhere in this section. 1038 5.2. Forwarding Sub-Layer Information Summary 1040 The following summarizes the information that is needed on forwarding 1041 sub-layer aware nodes that send DetNet MPLS traffic, on a per 1042 forwarding sub-layer flow basis: 1044 o The outgoing F-Label stack to be pushed. The stack may include 1045 H-LSP labels. 1047 o The traffic parameters associated with a specific label in the 1048 stack. Note that there may be multiple sets of traffic paramters 1049 associated with specific labels in the stack, e.g., when H-LSPs 1050 are used. 1052 o Outgoing interface and, for unicast traffic, the next hop 1053 information. 1055 o Sub-network specific parameters on a technology specific basis. 1056 For example, see [I-D.ietf-detnet-mpls-over-tsn]. 1058 The following summarizes the information that is needed on forwarding 1059 sub-layer aware nodes that receive DetNet MPLS traffic, on a per 1060 forwarding sub-layer flow basis: 1062 o The incoming interface. For some implementations and deployment 1063 scenarios, this information may not be needed. 1065 o The incoming F-Label stack to be popped. The stack may include 1066 H-LSP labels. 1068 o How the incoming forwarding sub-layer flow is to be handled, i.e., 1069 forwarded as a transit node, or provided to the service sub-layer. 1071 It is the responsibility of the DetNet controller plane to properly 1072 provision both flow identification information and the flow specific 1073 resources needed to provided the traffic treatment needed to meet 1074 each flow's service requirements. This applies for aggregated and 1075 individual flows. 1077 6. Security Considerations 1079 Security considerations for DetNet are described in detail in 1080 [I-D.ietf-detnet-security]. General security considerations are 1081 described in [I-D.ietf-detnet-architecture]. This section considers 1082 exclusively security considerations which are specific to the DetNet 1083 MPLS data plane. 1085 Security aspects which are unique to DetNet are those whose aim is to 1086 provide the specific quality of service aspects of DetNet, which are 1087 primarily to deliver data flows with extremely low packet loss rates 1088 and bounded end-to-end delivery latency. 1090 The primary considerations for the data plane is to maintain 1091 integrity of data and delivery of the associated DetNet service 1092 traversing the DetNet network. Application flows can be protected 1093 through whatever means is provided by the underlying technology. For 1094 example, encryption may be used, such as that provided by IPSec 1095 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 1096 [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 1098 From a data plane perspective this document does not add or modify 1099 any header information. 1101 At the management and control level DetNet flows are identified on a 1102 per-flow basis, which may provide controller plane attackers with 1103 additional information about the data flows (when compared to 1104 controller planes that do not include per-flow identification). This 1105 is an inherent property of DetNet which has security implications 1106 that should be considered when determining if DetNet is a suitable 1107 technology for any given use case. 1109 To provide uninterrupted availability of the DetNet service, 1110 provisions can be made against DOS attacks and delay attacks. To 1111 protect against DOS attacks, excess traffic due to malicious or 1112 malfunctioning devices can be prevented or mitigated, for example 1113 through the use of existing mechanism such as policing and shaping 1114 applied at the input of a DetNet domain. To prevent DetNet packets 1115 from being delayed by an entity external to a DetNet domain, DetNet 1116 technology definition can allow for the mitigation of Man-In-The- 1117 Middle attacks, for example through use of authentication and 1118 authorization of devices within the DetNet domain. 1120 7. IANA Considerations 1122 This document makes no IANA requests. 1124 8. Acknowledgements 1126 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 1127 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 1128 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 1129 Bernardos for their various contributions to this work. 1131 9. References 1133 9.1. Normative References 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, 1137 DOI 10.17487/RFC2119, March 1997, 1138 . 1140 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 1141 Network Element Service", RFC 2211, DOI 10.17487/RFC2211, 1142 September 1997, . 1144 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1145 of Guaranteed Quality of Service", RFC 2212, 1146 DOI 10.17487/RFC2212, September 1997, 1147 . 1149 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1150 Label Switching Architecture", RFC 3031, 1151 DOI 10.17487/RFC3031, January 2001, 1152 . 1154 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1155 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1156 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1157 . 1159 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1160 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1161 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1162 . 1164 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1165 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1166 Protocol Label Switching (MPLS) Support of Differentiated 1167 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 1168 . 1170 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 1171 in Multi-Protocol Label Switching (MPLS) Networks", 1172 RFC 3443, DOI 10.17487/RFC3443, January 2003, 1173 . 1175 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1176 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1177 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1178 DOI 10.17487/RFC3473, January 2003, 1179 . 1181 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1182 Hierarchy with Generalized Multi-Protocol Label Switching 1183 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1184 DOI 10.17487/RFC4206, October 2005, 1185 . 1187 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1188 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1189 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1190 February 2006, . 1192 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1193 Circuit Connectivity Verification (VCCV): A Control 1194 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1195 December 2007, . 1197 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1198 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 1199 2008, . 1201 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1202 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1203 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 1204 2009, . 1206 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1207 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1208 May 2017, . 1210 9.2. Informative References 1212 [I-D.ietf-detnet-architecture] 1213 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1214 "Deterministic Networking Architecture", draft-ietf- 1215 detnet-architecture-13 (work in progress), May 2019. 1217 [I-D.ietf-detnet-data-plane-framework] 1218 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 1219 Bryant, S., and J. Korhonen, "DetNet Data Plane 1220 Framework", draft-ietf-detnet-data-plane-framework-02 1221 (work in progress), September 2019. 1223 [I-D.ietf-detnet-ip] 1224 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 1225 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 1226 draft-ietf-detnet-ip-01 (work in progress), July 2019. 1228 [I-D.ietf-detnet-ip-over-mpls] 1229 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 1230 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over 1231 MPLS", draft-ietf-detnet-ip-over-mpls-01 (work in 1232 progress), July 2019. 1234 [I-D.ietf-detnet-mpls-over-tsn] 1235 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 1236 Korhonen, "DetNet Data Plane: MPLS over IEEE 802.1 Time 1237 Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over- 1238 tsn-00 (work in progress), May 2019. 1240 [I-D.ietf-detnet-security] 1241 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 1242 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 1243 Networking (DetNet) Security Considerations", draft-ietf- 1244 detnet-security-05 (work in progress), August 2019. 1246 [I-D.ietf-spring-segment-routing-mpls] 1247 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1248 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1249 data plane", draft-ietf-spring-segment-routing-mpls-22 1250 (work in progress), May 2019. 1252 [IEEE802.1AE-2018] 1253 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 1254 Security (MACsec)", 2018, 1255 . 1257 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1258 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1259 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1260 September 1997, . 1262 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1263 "Definition of the Differentiated Services Field (DS 1264 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1265 DOI 10.17487/RFC2474, December 1998, 1266 . 1268 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 1269 Xiao, "Overview and Principles of Internet Traffic 1270 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 1271 . 1273 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1274 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1275 DOI 10.17487/RFC3985, March 2005, 1276 . 1278 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1279 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1280 December 2005, . 1282 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1283 "Encapsulation Methods for Transport of Ethernet over MPLS 1284 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1285 . 1287 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1288 Yasukawa, Ed., "Extensions to Resource Reservation 1289 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1290 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1291 DOI 10.17487/RFC4875, May 2007, 1292 . 1294 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1295 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1296 DOI 10.17487/RFC5440, March 2009, 1297 . 1299 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1300 "MPLS Generic Associated Channel", RFC 5586, 1301 DOI 10.17487/RFC5586, June 2009, 1302 . 1304 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 1305 L., and L. Berger, "A Framework for MPLS in Transport 1306 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 1307 . 1309 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 1310 RFC 6003, DOI 10.17487/RFC6003, October 2010, 1311 . 1313 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1314 Aissaoui, "Segmented Pseudowire", RFC 6073, 1315 DOI 10.17487/RFC6073, January 2011, 1316 . 1318 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1319 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1320 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1321 . 1323 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 1324 "Extensions to the Path Computation Element Communication 1325 Protocol (PCEP) for Point-to-Multipoint Traffic 1326 Engineering Label Switched Paths", RFC 8306, 1327 DOI 10.17487/RFC8306, November 2017, 1328 . 1330 Authors' Addresses 1332 Balazs Varga (editor) 1333 Ericsson 1334 Magyar Tudosok krt. 11. 1335 Budapest 1117 1336 Hungary 1338 Email: balazs.a.varga@ericsson.com 1340 Janos Farkas 1341 Ericsson 1342 Magyar Tudosok krt. 11. 1343 Budapest 1117 1344 Hungary 1346 Email: janos.farkas@ericsson.com 1348 Lou Berger 1349 LabN Consulting, L.L.C. 1351 Email: lberger@labn.net 1352 Don Fedyk 1353 LabN Consulting, L.L.C. 1355 Email: dfedyk@labn.net 1357 Andrew G. Malis 1358 Independent 1360 Email: agmalis@gmail.com 1362 Stewart Bryant 1363 Futurewei Technologies 1365 Email: stewart.bryant@gmail.com 1367 Jouni Korhonen 1369 Email: jouni.nospam@gmail.com