idnits 2.17.1 draft-ietf-detnet-tsn-vpn-over-mpls-05.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 (December 13, 2020) is 1223 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 182, but not defined == Unused Reference: 'RFC5921' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC8660' is defined on line 605, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-12 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: June 16, 2021 A. Malis 6 Malis Consulting 7 S. Bryant 8 Futurewei Technologies 9 D. Fedyk 10 LabN Consulting, L.L.C. 11 December 13, 2020 13 DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS 14 draft-ietf-detnet-tsn-vpn-over-mpls-05 16 Abstract 18 This document specifies the Deterministic Networking data plane when 19 TSN networks are interconnected over a DetNet MPLS Network. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 16, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 58 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 59 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4 61 4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6 62 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7 64 5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8 65 5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8 66 5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 9 67 5.3. Edge Node DetNet Service and Forwarding Sub-Layer 68 Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Controller Plane (Management and Control) Considerations . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 10.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1 81 Working Group deals with deterministic services through IEEE 802 82 networks. Deterministic Networking (DetNet) defined by IETF is a 83 service that can be offered by a L3 network to DetNet flows. General 84 background and concepts of DetNet can be found in [RFC8655]. 86 This document specifies the use of a DetNet MPLS network to 87 interconnect TSN nodes/network segments. DetNet MPLS data plane is 88 defined in [I-D.ietf-detnet-mpls]. 90 2. Terminology 92 2.1. Terms Used in This Document 94 This document uses the terminology and concepts established in the 95 DetNet architecture [RFC8655] and [RFC8938], and 96 [I-D.ietf-detnet-mpls]. The reader is assumed to be familiar with 97 these documents and their terminology. 99 2.2. Abbreviations 101 The following abbreviations are used in this document: 103 AC Attachment Circuit. 105 CE Customer Edge equipment. 107 CW Control Word. 109 DetNet Deterministic Networking. 111 DF DetNet Flow. 113 FRER Frame Replication and Elimination for Redundancy (TSN 114 function). 116 L2 Layer 2. 118 L2VPN Layer 2 Virtual Private Network. 120 L3 Layer 3. 122 LSR Label Switching Router. 124 MPLS Multiprotocol Label Switching. 126 MPLS-TE Multiprotocol Label Switching - Traffic Engineering. 128 MPLS-TP Multiprotocol Label Switching - Transport Profile. 130 NSP Native Service Processing. 132 OAM Operations, Administration, and Maintenance. 134 PE Provider Edge. 136 PREOF Packet Replication, Elimination and Ordering Functions. 138 PW PseudoWire. 140 S-PE Switching Provider Edge. 142 T-PE Terminating Provider Edge. 144 TSN Time-Sensitive Network. 146 2.3. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario 156 Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware 157 DetNet service running over an MPLS network. DetNet Edge Nodes sit 158 at the boundary of a DetNet domain. They are responsible for mapping 159 non-DetNet aware L2 traffic to DetNet services. They also support 160 the imposition and disposition of the required DetNet encapsulation. 161 These are functionally similar to pseudowire (PW) Terminating 162 Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example 163 TSN Streams are simple applications over DetNet flows. The specific 164 of this operation are discussed later in this document. 166 TSN Edge Transit Edge TSN 167 End System Node Node Node End System 168 (T-PE) (LSR) (T-PE) 170 +----------+ +----------+ 171 | TSN | <---------End to End TSN Service----------> | TSN | 172 | Applic. | | Applic. | 173 +----------+ +.........+ +.........+ +----------+ 174 | | | \S-Proxy: :S-Proxy/ | | | 175 | TSN | | +.+---+<-- DetNet flow -->+---+ | | | TSN | 176 | | |TSN| |Svc| |Svc| |TSN| | | 177 +----------+ +---+ +---+ +----------+ +---+ +---+ +----------+ 178 | L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 | 179 +------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+ 180 : Link : / ,-----. \ : Link : / ,-----. \ 181 +........+ +-[ Sub ]-+ +........+ +-[ TSN ]-+ 182 [Network] [Network] 183 `-----' `-----' 185 |<------ DetNet MPLS ------>| 186 |<---------------------- TSN --------------------->| 188 Figure 1: A TSN over DetNet MPLS Enabled Network 190 In this example, edge nodes provide a service proxy function that 191 "associates" the DetNet flows and native flows (i.e., TSN Streams) at 192 the edge of the DetNet domain. TSN streams are treated as App-flows 193 for DetNet. The whole DetNet domain behaves as a TSN relay node for 194 the TSN streams. The service proxy behaves as a port of that TSN 195 relay node. 197 Figure 2 illustrates how DetNet can provide services for IEEE 802.1 198 TSN end systems, CE1 and CE2, over a DetNet enabled MPLS network. 199 Edge nodes, E1 and E2, insert and remove required DetNet data plane 200 encapsulation. The 'X' in the edge nodes and relay node, R1, 201 represent a potential DetNet compound flow packet replication and 202 elimination point. This conceptually parallels L2VPN services, and 203 could leverage existing related solutions as discussed below. 205 TSN |<------- End to End DetNet Service ------>| TSN 206 Service | Transit Transit | Service 207 TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN 208 End | V V 1 V V 2 V V | End 209 System | +--------+ +--------+ +--------+ | System 210 +---+ | | E1 |=======| R1 |=======| E2 | | +---+ 211 | |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| | 212 |CE1| | | \ | | X | | / | | |CE2| 213 | | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | | 214 +---+ | |=======| |=======| | +---+ 215 ^ +--------+ +--------+ +--------+ ^ 216 | Edge Node Relay Node Edge Node | 217 | (T-PE) (S-PE) (T-PE) | 218 | | 219 |<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->| 220 | | 221 |<-------- Time Sensitive Networking (TSN) Service ------->| 223 X = Service protection 224 DFx = DetNet member flow x over a TE LSP 226 Figure 2: IEEE 802.1TSN Over DetNet 228 4. DetNet MPLS Data Plane 230 4.1. Overview 232 The basic approach defined in [I-D.ietf-detnet-mpls] supports the 233 DetNet service sub-layer based on existing pseudowire (PW) 234 encapsulations and mechanisms, and supports the DetNet forwarding 235 sub-layer based on existing MPLS Traffic Engineering encapsulations 236 and mechanisms. 238 A node operating on a DetNet flow in the Detnet service sub-layer, 239 i.e. a node processing a DetNet packet which has the S-Label as top 240 of stack uses the local context associated with that S-Label, for 241 example a received F-Label, to determine what local DetNet 242 operation(s) are applied to that packet. An S-Label may be unique 243 when taken from the platform label space [RFC3031], which would 244 enable correct DetNet flow identification regardless of which input 245 interface or LSP the packet arrives on. The service sub-layer 246 functions (i.e., PREOF) use a DetNet control word (d-CW). 248 The DetNet MPLS data plane builds on MPLS Traffic Engineering 249 encapsulations and mechanisms to provide a forwarding sub-layer that 250 is responsible for providing resource allocation and explicit routes. 252 The forwarding sub-layer is supported by one or more forwarding 253 labels (F-Labels). 255 DetNet edge/relay nodes are DetNet service sub-layer aware, 256 understand the particular needs of DetNet flows and provide both 257 DetNet service and forwarding sub-layer functions. They add, remove 258 and process d-CWs, S-Labels and F-labels as needed. MPLS DetNet 259 nodes and transit nodes include DetNet forwarding sub-layer 260 functions, support for notably explicit routes, and resources 261 allocation to eliminate (or reduce) congestion loss and jitter. 262 Unlike other DetNet node types, transit nodes provide no service sub- 263 layer processing. 265 4.2. TSN over DetNet MPLS Encapsulation 267 The basic encapsulation approach is to treat a TSN Stream as an App- 268 flow from the DetNet MPLS perspective. The corresponding example 269 shown in Figure 3. 271 /-> +------+ +------+ +------+ TSN ^ ^ 272 | | X | | X | | X |<- Appli : : 273 App-Flow <-+ +------+ +------+ +------+ cation : :(1) 274 for MPLS | |TSN-L2| |TSN-L2| |TSN-L2| : v 275 \-> +---+======+--+======+--+======+-----+ : 276 | d-CW | | d-CW | | d-CW | : 277 DetNet-MPLS +------+ +------+ +------+ :(2) 278 |Labels| |Labels| |Labels| v 279 +---+======+--+======+--+======+-----+ 280 Link/Sub-Network | L2 | | TSN | | UDP | 281 +------+ +------+ +------+ 282 | IP | 283 +------+ 284 | L2 | 285 +------+ 286 (1) TSN Stream 287 (2) DetNet MPLS Flow 289 Figure 3: Example TSN over MPLS Encapsulation Formats 291 In the figure, "Application" indicates the application payload 292 carried by the TSN network. "MPLS App-Flow" indicates that the TSN 293 Stream is the payload from the perspective of the DetNet MPLS data 294 plane defined in [I-D.ietf-detnet-mpls]. A single DetNet MPLS flow 295 can aggregate multiple TSN Streams. 297 5. TSN over MPLS Data Plane Procedures 299 Description of Edge Nodes procedures and functions for TSN over 300 DetNet MPLS scenario follows the concept of [RFC3985] and covers the 301 Edge Nodes components shown on Figure 1. In this section the 302 following procedures of DetNet Edge Nodes are described: 304 o TSN related (Section 5.1) 306 o DetNet Service Proxy (Section 5.2) 308 o DetNet service and forwarding sub-layer (Section 5.3) 310 The sub-sections describe procedures for forwarding packets by DetNet 311 Edge nodes, where such packets are received from either directly 312 connected CEs (TSN nodes) or some other DetNet Edge nodes. 314 5.1. Edge Node TSN Procedures 316 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 317 Working Group have defined (and are defining) a number of amendments 318 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 319 bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB] 320 defines packet replication and elimination functions for a TSN 321 network. 323 The implementation of TSN entity (i.e., TSN packet processing 324 functions) must be compliant with the relevant IEEE 802.1 standards. 326 TSN specific functions are executed on the data received by the 327 DetNet Edge Node from the connected CE before forwarded to connected 328 CE(s) or presentation to the DetNet Service Proxy function for 329 transmission across the DetNet domain, or on the data received from a 330 DetNet PW by a PE before it is output on the Attachment Circuit(s) 331 (AC). 333 TSN packet processing function(s) of Edge Nodes (T-PE) are belonging 334 to the native service processing (NSP) [RFC3985] block. This is 335 similar to other functionalities being defined by standard bodies 336 other than the IETF (for example in case of Ethernet: stripping, 337 overwriting or adding VLAN tags, etc.). Depending on the TSN role of 338 the Edge Node in the end-to-end TSN service selected TSN functions 339 are supported. 341 When a PE receives a packet from a CE, on a given AC with DetNet 342 service, it first checks via Stream Identification (see Clause 6. of 343 IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]) 344 whether the packet belongs to a configured TSN Stream (i.e., App-flow 345 from DetNet perspective). If no Stream ID is matched and no other 346 (VPN) service is configured for the AC then packet MUST be dropped. 347 If there is a matching TSN Stream then the Stream-ID specific TSN 348 functions are executed (e.g., ingress policing, header field 349 manipulation in case of active Stream Identification, FRER, etc.). 350 Source MAC lookup may also be used for local MAC address learning. 352 If the PE decides to forward the packet, the packet MUST be forwarded 353 according to the TSN Stream specific configuration to connected CE(s) 354 (in case of local bridging) and/or to the DetNet Service Proxy (in 355 case of forwarding to remote CE(s) required). If there are no TSN 356 Stream specific forwarding configurations the PE MUST flood the 357 packet to other locally attached CE(s) and to the DetNet Service 358 Proxy. If the administrative policy on the PE does not allow 359 flooding the PE MUST drop the packet. 361 When a TSN entity of the PE receives a packet from the DetNet Service 362 Proxy, it first checks via Stream Identification (see Clause 6. of 363 IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]) 364 whether the packet belongs to a configured TSN Stream. If no Stream 365 ID is matched then packet is dropped. If there is a matching TSN 366 Stream then the Stream ID specific TSN functions are executed (e.g., 367 header field manipulation in case of active Stream Identification, 368 FRER, etc.). Source MAC lookup may also be used for local MAC 369 address learning. 371 If the PE decides to forward the packet, the packet is forwarded 372 according to the TSN Stream specific configuration to connected 373 CE(s). If there are no TSN Stream specific forwarding configurations 374 the PE floods the packet to locally attached CE(s). If the 375 administrative policy on the PE does not allow flooding the PE drops 376 the packet. 378 Implementations of this document SHALL use management and control 379 information to ensure TSN specific functions of the Edge Node 380 according to the expectations of the connected TSN network. 382 5.2. Edge Node DetNet Service Proxy Procedures 384 The Service Proxy function maps between App-flows and DetNet flows. 385 The DetNet Edge Node TSN entity MUST support the TSN Stream 386 identification functions and the related managed objects as defined 387 in Clause 6. and Clause 9. of IEEE 802.1CB [IEEE8021CB] and IEEE 388 P802.1CBdb [IEEEP8021CBdb] to recognize the App-flow related packets. 389 The Service Proxy presents TSN Streams as an App-flow to a DetNet 390 Flow. 392 When a DetNet Service Proxy receives a packet from the TSN Entity it 393 MUST check whether such an App-flow is present in its mapping table. 394 If present it associates the internal DetNet flow-ID to the packet 395 and MUST forward it to the DetNet Service and Forwarding sub-layers. 396 If no matching statement is present it MUST drop the packet. 398 When a DetNet Service Proxy receives a packet from the DetNet Service 399 and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN 400 Entity. 402 Implementations of this document SHALL use management and control 403 information to map a TSN Stream to a DetNet flow. N:1 mapping 404 (aggregating multiple TSN Streams in a single DetNet flow) SHALL be 405 supported. The management or control function that provisions flow 406 mapping SHALL ensure that adequate resources are allocated and 407 configured to provide proper service requirements of the mapped 408 flows. 410 Due to the (intentional) similarities of the DetNet PREOF and TSN 411 FRER functions service protection function interworking is possible 412 between the TSN and the DetNet domains. Such service protection 413 interworking scenarios MAY require to copy sequence number fields 414 from TSN (L2) to PW (MPLS) encapsulation. However, such interworking 415 is out-of-scope in this document and left for further study. 417 5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures 419 In the design of [I-D.ietf-detnet-mpls] an MPLS service label (the 420 S-Label), similar to a pseudowire (PW) label [RFC3985], is used to 421 identify both the DetNet flow identity and the payload MPLS payload 422 type. The DetNet sequence number is carried in the DetNet Control 423 word (d-CW) which carries the Data/OAM discriminator as well. In 424 [I-D.ietf-detnet-mpls] two sequence number sizes are supported: a 16 425 bit sequence number and a 28 bit sequence number. 427 PREOF functions and the provided service recovery is available only 428 within the DetNet domain as the DetNet flow-ID and the DetNet 429 sequence number are not valid outside the DetNet network. MPLS 430 (DetNet) Edge node terminates all related information elements 431 encoded in the MPLS labels. 433 When a PE receives a packet from the Service Proxy function it MUST 434 handle the packet as defined in [I-D.ietf-detnet-mpls]. 436 When a PE receives an MPLS packet from a remote PE, then, after 437 processing the MPLS label stack, if the top MPLS label ends up being 438 a DetNet S-label that was advertised by this node, then the PE MUST 439 forward the packet according to the configured DetNet Service and 440 Forwarding sub-layer rules to other PE nodes or via the Detnet 441 Service Proxy function towards locally connected CE(s). 443 For further details on DetNet Service and Forwarding sub-layers see 444 [I-D.ietf-detnet-mpls]. 446 6. Controller Plane (Management and Control) Considerations 448 TSN Stream(s) to DetNet flow mapping related information are required 449 only for the service proxy function of MPLS (DetNet) Edge nodes. 450 From the Data Plane perspective there is no practical difference 451 based on the origin of flow mapping related information (management 452 plane or control plane). 454 The following summarizes the set of information that is needed to 455 configure TSN over DetNet MPLS: 457 o TSN related configuration information according to the TSN role of 458 the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and 459 [IEEEP8021CBdb]. 461 o DetNet MPLS related configuration information according to the 462 DetNet role of the DetNet MPLS node, as per 463 [I-D.ietf-detnet-mpls]. 465 o App-Flow identification information to map received TSN Stream(s) 466 to the DetNet flow. Parameters of TSN stream identification are 467 defined in [IEEE8021CB] and [IEEEP8021CBdb]. 469 This information MUST be provisioned per DetNet flow. 471 Mappings between DetNet and TSN management and control planes are out 472 of scope of the document. Some of the challanges are highligthed 473 below. 475 MPLS DetNet Edge nodes are member of both the DetNet domain and the 476 connected TSN network. From the TSN network perspective the MPLS 477 (DetNet) Edge node has a "TSN relay node" role, so TSN specific 478 management and control plane functionalities must be implemented. 479 There are many similarities in the management plane techniques used 480 in DetNet and TSN, but that is not the case for the control plane 481 protocols. For example, RSVP-TE and MSRP behaves differently. 482 Therefore management and control plane design is an important aspect 483 of scenarios, where mapping between DetNet and TSN is required. 485 Note that, as the DetNet network is just a portion of the end to end 486 TSN path (i.e., single hop from Ethernet perspective), some 487 parameters (e.g., delay) may differ significantly. Since there is no 488 interworking function the bandwidth of DetNet network is assumed to 489 be set large enough to handle all TSN Flows it will support. At the 490 egress of the Detnet Domain the MPLS headers are stripped and the TSN 491 flow continues on as a normal TSN flow. 493 In order to use a DetNet network to interconnect TSN segments, TSN 494 specific information must be converted to DetNet domain specific 495 ones. TSN Stream ID(s) and stream(s) related parameters/requirements 496 must be converted to a DetNet flow-ID and flow related parameters/ 497 requirements. 499 In some case it may be challenging to determine some egress node 500 related information. For example, it may be not trivial to locate 501 the egress point/interface of a TSN Streams with a multicast 502 destination MAC address. Such scenarios may require interaction 503 between control and management plane functions and between DetNet and 504 TSN domains. 506 Mapping between DetNet flow identifiers and TSN Stream identifiers, 507 if not provided explicitly, can be done by the service proxy function 508 of an MPLS (DetNet) Edge node locally based on information provided 509 for configuration of the TSN Stream identification functions (e.g., 510 Mask-and-Match Stream identification). 512 Triggering the setup/modification of a DetNet flow in the DetNet 513 network is an example where management and/or control plane 514 interactions are required between the DetNet and the TSN network. 516 Configuration of TSN specific functions (e.g., FRER) inside the TSN 517 network is a TSN domain specific decision and may not be visible in 518 the DetNet domain. Service protection interworking scenarios are 519 left for further study. 521 7. Security Considerations 523 Security considerations for DetNet are described in detail in 524 [I-D.ietf-detnet-security]. General security considerations are 525 described in [RFC8655]. 527 DetNet MPLS data plane specific considerations are summarized and 528 described in [I-D.ietf-detnet-mpls] including any application flow 529 types. This document focuses on the scenario where TSN Streams are 530 the application flows for DetNet and it is already covered by those 531 DetNet MPLS data plane security considerations. 533 8. IANA Considerations 535 This document makes no IANA requests. 537 9. Acknowledgements 539 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 540 Christophe Mangin and Jouni Korhonen for their various contributions 541 to this work. 543 10. References 545 10.1. Normative References 547 [I-D.ietf-detnet-mpls] 548 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 549 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 550 detnet-mpls-13 (work in progress), October 2020. 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 558 Label Switching Architecture", RFC 3031, 559 DOI 10.17487/RFC3031, January 2001, 560 . 562 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 563 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 564 May 2017, . 566 10.2. Informative References 568 [I-D.ietf-detnet-security] 569 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 570 Networking (DetNet) Security Considerations", draft-ietf- 571 detnet-security-12 (work in progress), October 2020. 573 [IEEE8021CB] 574 IEEE 802.1, "Standard for Local and metropolitan area 575 networks - Frame Replication and Elimination for 576 Reliability (IEEE Std 802.1CB-2017)", 2017, 577 . 579 [IEEE8021Q] 580 IEEE 802.1, "Standard for Local and metropolitan area 581 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 582 2018)", 2018, . 584 [IEEEP8021CBdb] 585 Mangin, C., "Extended Stream identification functions", 586 IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020, 587 . 590 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 591 Edge-to-Edge (PWE3) Architecture", RFC 3985, 592 DOI 10.17487/RFC3985, March 2005, 593 . 595 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 596 L., and L. Berger, "A Framework for MPLS in Transport 597 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 598 . 600 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 601 "Deterministic Networking Architecture", RFC 8655, 602 DOI 10.17487/RFC8655, October 2019, 603 . 605 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 606 Decraene, B., Litkowski, S., and R. Shakir, "Segment 607 Routing with the MPLS Data Plane", RFC 8660, 608 DOI 10.17487/RFC8660, December 2019, 609 . 611 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 612 Bryant, "Deterministic Networking (DetNet) Data Plane 613 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 614 . 616 Authors' Addresses 618 Balazs Varga (editor) 619 Ericsson 620 Magyar Tudosok krt. 11. 621 Budapest 1117 622 Hungary 624 Email: balazs.a.varga@ericsson.com 625 Janos Farkas 626 Ericsson 627 Magyar Tudosok krt. 11. 628 Budapest 1117 629 Hungary 631 Email: janos.farkas@ericsson.com 633 Andrew G. Malis 634 Malis Consulting 636 Email: agmalis@gmail.com 638 Stewart Bryant 639 Futurewei Technologies 641 Email: stewart.bryant@gmail.com 643 Don Fedyk 644 LabN Consulting, L.L.C. 646 Email: dfedyk@labn.net