idnits 2.17.00 (12 Aug 2021) /tmp/idnits44251/draft-ietf-detnet-tsn-vpn-over-mpls-03.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 (June 8, 2020) is 712 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 183, but not defined == Unused Reference: 'IEEE802.1AE-2018' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 622, but no explicit reference was found in the text == Outdated reference: draft-ietf-detnet-mpls has been published as RFC 8964 == Outdated reference: draft-ietf-detnet-data-plane-framework has been published as RFC 8938 == Outdated reference: draft-ietf-detnet-security has been published as RFC 9055 Summary: 0 errors (**), 0 flaws (~~), 7 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: December 10, 2020 A. Malis 6 Malis Consulting 7 S. Bryant 8 Futurewei Technologies 9 D. Fedyk 10 LabN Consulting, L.L.C. 11 June 8, 2020 13 DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS 14 draft-ietf-detnet-tsn-vpn-over-mpls-03 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 December 10, 2020. 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 . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 13 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 10.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 96 [I-D.ietf-detnet-data-plane-framework], and [I-D.ietf-detnet-mpls]. 97 The reader is assumed to be familiar with these documents and their 98 terminology. 100 2.2. Abbreviations 102 The following abbreviations are used in this document: 104 AC Attachment Circuit. 106 CE Customer Edge equipment. 108 CW Control Word. 110 DetNet Deterministic Networking. 112 DF DetNet Flow. 114 FRER Frame Replication and Elimination for Redundancy (TSN 115 function). 117 L2 Layer 2. 119 L2VPN Layer 2 Virtual Private Network. 121 L3 Layer 3. 123 LSR Label Switching Router. 125 MPLS Multiprotocol Label Switching. 127 MPLS-TE Multiprotocol Label Switching - Traffic Engineering. 129 MPLS-TP Multiprotocol Label Switching - Transport Profile. 131 NSP Native Service Processing. 133 OAM Operations, Administration, and Maintenance. 135 PE Provider Edge. 137 PREOF Packet Replication, Elimination and Ordering Functions. 139 PW PseudoWire. 141 S-PE Switching Provider Edge. 143 T-PE Terminating Provider Edge. 145 TSN Time-Sensitive Network. 147 2.3. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario 157 Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware 158 DetNet service running over an MPLS network. DetNet Edge Nodes sit 159 at the boundary of a DetNet domain. They are responsible for mapping 160 non-DetNet aware L2 traffic to DetNet services. They also support 161 the imposition and disposition of the required DetNet encapsulation. 162 These are functionally similar to pseudowire (PW) Terminating 163 Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example 164 TSN Streams are simple applications over DetNet flows. The specific 165 of this operation are discussed later in this document. 167 TSN Edge Transit Edge TSN 168 End System Node Node Node End System 169 (T-PE) (LSR) (T-PE) 171 +----------+ +----------+ 172 | TSN | <---------End to End TSN Service----------> | TSN | 173 | Applic. | | Applic. | 174 +----------+ +.........+ +.........+ +----------+ 175 | | | \S-Proxy: :S-Proxy/ | | | 176 | TSN | | +.+---+<-- DetNet flow -->+---+ | | | TSN | 177 | | |TSN| |Svc| |Svc| |TSN| | | 178 +----------+ +---+ +---+ +----------+ +---+ +---+ +----------+ 179 | L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 | 180 +------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+ 181 : Link : / ,-----. \ : Link : / ,-----. \ 182 +........+ +-[ Sub ]-+ +........+ +-[ TSN ]-+ 183 [Network] [Network] 184 `-----' `-----' 186 |<------ DetNet MPLS ------>| 187 |<---------------------- TSN --------------------->| 189 Figure 1: A TSN over DetNet MPLS Enabled Network 191 In this example, edge nodes provide a service proxy function that 192 "associates" the DetNet flows and native flows (i.e., TSN Streams) at 193 the edge of the DetNet domain. TSN streams are treated as App-flows 194 for DetNet. The whole DetNet domain behaves as a TSN relay node for 195 the TSN streams. The service proxy behaves as a port of that TSN 196 relay node. 198 Figure 2 illustrates how DetNet can provide services for IEEE 802.1 199 TSN end systems, CE1 and CE2, over a DetNet enabled MPLS network. 200 Edge nodes, E1 and E2, insert and remove required DetNet data plane 201 encapsulation. The 'X' in the edge nodes and relay node, R1, 202 represent a potential DetNet compound flow packet replication and 203 elimination point. This conceptually parallels L2VPN services, and 204 could leverage existing related solutions as discussed below. 206 TSN |<------- End to End DetNet Service ------>| TSN 207 Service | Transit Transit | Service 208 TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN 209 End | V V 1 V V 2 V V | End 210 System | +--------+ +--------+ +--------+ | System 211 +---+ | | E1 |=======| R1 |=======| E2 | | +---+ 212 | |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| | 213 |CE1| | | \ | | X | | / | | |CE2| 214 | | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | | 215 +---+ | |=======| |=======| | +---+ 216 ^ +--------+ +--------+ +--------+ ^ 217 | Edge Node Relay Node Edge Node | 218 | (T-PE) (S-PE) (T-PE) | 219 | | 220 |<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->| 221 | | 222 |<-------- Time Sensitive Networking (TSN) Service ------->| 224 X = Service protection 225 DFx = DetNet member flow x over a TE LSP 227 Figure 2: IEEE 802.1TSN Over DetNet 229 4. DetNet MPLS Data Plane 231 4.1. Overview 233 The basic approach defined in [I-D.ietf-detnet-mpls] supports the 234 DetNet service sub-layer based on existing pseudowire (PW) 235 encapsulations and mechanisms, and supports the DetNet forwarding 236 sub-layer based on existing MPLS Traffic Engineering encapsulations 237 and mechanisms. 239 A node operating on a DetNet flow in the Detnet service sub-layer, 240 i.e. a node processing a DetNet packet which has the S-Label as top 241 of stack uses the local context associated with that S-Label, for 242 example a received F-Label, to determine what local DetNet 243 operation(s) are applied to that packet. An S-Label may be unique 244 when taken from the platform label space [RFC3031], which would 245 enable correct DetNet flow identification regardless of which input 246 interface or LSP the packet arrives on. The service sub-layer 247 functions (i.e., PREOF) use a DetNet control word (d-CW). 249 The DetNet MPLS data plane builds on MPLS Traffic Engineering 250 encapsulations and mechanisms to provide a forwarding sub-layer that 251 is responsible for providing resource allocation and explicit routes. 253 The forwarding sub-layer is supported by one or more forwarding 254 labels (F-Labels). 256 DetNet edge/relay nodes are DetNet service sub-layer aware, 257 understand the particular needs of DetNet flows and provide both 258 DetNet service and forwarding sub-layer functions. They add, remove 259 and process d-CWs, S-Labels and F-labels as needed. MPLS enabled 260 DetNet nodes can enhance the reliability of delivery by enabling the 261 replication of packets where multiple copies, possibly over multiple 262 paths, are forwarded through the DetNet domain. They can also 263 eliminate surplus previously replicated copies of DetNet packets. 264 MPLS (DetNet) nodes also include DetNet forwarding sub-layer 265 functions, support for notably explicit routes, and resources 266 allocation to eliminate (or reduce) congestion loss and jitter. 268 DetNet transit nodes reside wholly within a DetNet domain, and also 269 provide DetNet forwarding sub-layer functions in accordance with the 270 performance required by a DetNet flow carried over an LSP. Unlike 271 other DetNet node types, transit nodes provide no service sub-layer 272 processing. 274 4.2. TSN over DetNet MPLS Encapsulation 276 The basic encapsulation approach is to treat a TSN Stream as an App- 277 flow from the DetNet MPLS perspective. The corresponding example 278 shown in Figure 3. 280 /-> +------+ +------+ +------+ TSN ^ ^ 281 | | X | | X | | X |<- Appli : : 282 App-Flow <-+ +------+ +------+ +------+ cation : :(1) 283 for MPLS | |TSN-L2| |TSN-L2| |TSN-L2| : v 284 \-> +---+======+--+======+--+======+-----+ : 285 | d-CW | | d-CW | | d-CW | : 286 DetNet-MPLS +------+ +------+ +------+ :(2) 287 |Labels| |Labels| |Labels| v 288 +---+======+--+======+--+======+-----+ 289 Link/Sub-Network | L2 | | TSN | | UDP | 290 +------+ +------+ +------+ 291 | IP | 292 +------+ 293 | L2 | 294 +------+ 295 (1) TSN Stream 296 (2) DetNet MPLS Flow 298 Figure 3: Example TSN over MPLS Encapsulation Formats 300 In the figure, "Application" indicates the application payload 301 carried by the TSN network. "MPLS App-Flow" indicates that the TSN 302 Stream is the payload from the perspective of the DetNet MPLS data 303 plane defined in [I-D.ietf-detnet-mpls]. A single DetNet MPLS flow 304 can aggregate multiple TSN Streams. 306 5. TSN over MPLS Data Plane Procedures 308 Description of Edge Nodes procedures and functions for TSN over 309 DetNet MPLS scenario follows the concept of [RFC3985] and covers the 310 Edge Nodes components shown on Figure 1. In this section the 311 following procedures of DetNet Edge Nodes are described: 313 o TSN related (Section 5.1) 315 o DetNet Service Proxy (Section 5.2) 317 o DetNet service and forwarding sub-layer (Section 5.3) 319 The sub-sections describe procedures for forwarding packets by DetNet 320 Edge nodes, where such packets are received from either directly 321 connected CEs (TSN nodes) or some other DetNet Edge nodes. 323 5.1. Edge Node TSN Procedures 325 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 326 Working Group have defined (and are defining) a number of amendments 327 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 328 bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB] 329 defines packet replication and elimination functions for a TSN 330 network. 332 The implementation of TSN entity (i.e., TSN packet processing 333 functions) MUST be compliant with the relevant IEEE 802.1 standards. 335 TSN specific functions are executed on the data received by the 336 DetNet Edge Node from the connected CE before forwarded to connected 337 CE(s) or presentation to the DetNet Service Proxy function for 338 transmission across the DetNet domain, or on the data received from a 339 DetNet PW by a PE before it is output on the Attachment Circuit(s) 340 (AC). 342 TSN packet processing function(s) of Edge Nodes (T-PE) are belonging 343 to the native service processing (NSP) [RFC3985] block. This is 344 similar to other functionalities being defined by standard bodies 345 other than the IETF (for example in case of Ethernet: stripping, 346 overwriting or adding VLAN tags, etc.). Depending on the TSN role of 347 the Edge Node in the end-to-end TSN service selected TSN functions 348 are supported. 350 When a PE receives a packet from a CE, on a given AC with DetNet 351 service, it MUST first check via Stream Identification (see Clause 6. 352 of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]) 353 whether the packet belongs to a configured TSN Stream (i.e., App-flow 354 from DetNet perspective). If no Stream ID is matched and no other 355 (VPN) service is configured for the AC then packet MUST be dropped. 356 If there is a matching TSN Stream then the Stream-ID specific TSN 357 functions MUST be executed (e.g., ingress policing, header field 358 manipulation in case of active Stream Identification, FRER, etc.). 359 Source MAC lookup MAY also be used for local MAC address learning. 361 If the PE decides to forward the packet, the packet MUST be forwarded 362 according to the TSN Stream specific configuration to connected CE(s) 363 (in case of local bridging) and/or to the DetNet Service Proxy (in 364 case of forwarding to remote CE(s) required). If there are no TSN 365 Stream specific forwarding configurations the PE MUST flood the 366 packet to other locally attached CE(s) and to the DetNet Service 367 Proxy. If the administrative policy on the PE does not allow 368 flooding the PE MUST drop the packet. 370 When a TSN entity of the PE receives a packet from the DetNet Service 371 Proxy, it MUST first check via Stream Identification (see Clause 6. 372 of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]) 373 whether the packet belongs to a configured TSN Stream. If no Stream 374 ID is matched then packet MUST be dropped. If there is a matching 375 TSN Stream then the Stream ID specific TSN functions MUST be executed 376 (e.g., header field manipulation in case of active Stream 377 Identification, FRER, etc.). Source MAC lookup MAY also be used for 378 local MAC address learning. 380 If the PE decides to forward the packet, the packet MUST be forwarded 381 according to the TSN Stream specific configuration to connected 382 CE(s). If there are no TSN Stream specific forwarding configurations 383 the PE MUST flood the packet to locally attached CE(s). If the 384 administrative policy on the PE does not allow flooding the PE MUST 385 drop the packet. 387 Implementations of this document SHALL use management and control 388 information to ensure TSN specific functions of the Edge Node 389 according to the expectations of the connected TSN network. 391 5.2. Edge Node DetNet Service Proxy Procedures 393 The Service Proxy function maps between App-flows and DetNet flows. 394 The DetNet Edge Node TSN entity MUST support the TSN Stream 395 identification functions and the related managed objects as defined 396 in Clause 6. and Clause 9. of IEEE 802.1CB [IEEE8021CB] and IEEE 397 P802.1CBdb [IEEEP8021CBdb] to recognize the App-flow related packets. 398 The Service Proxy presents TSN Streams as an App-flow to a DetNet 399 Flow. 401 When a DetNet Service Proxy receives a packet from the TSN Entity it 402 MUST check whether such an App-flow is present in its mapping table. 403 If present it associates the internal DetNet flow-ID to the packet 404 and MUST forward it to the DetNet Service and Forwarding sub-layers. 405 If no matching statement is present it MUST drop the packet. 407 When a DetNet Service Proxy receives a packet from the DetNet Service 408 and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN 409 Entity. 411 Implementations of this document SHALL use management and control 412 information to map a TSN Stream to a DetNet flow. N:1 mapping 413 (aggregating multiple TSN Streams in a single DetNet flow) SHALL be 414 supported. The management or control function that provisions flow 415 mapping SHALL ensure that adequate resources are allocated and 416 configured to provide proper service requirements of the mapped 417 flows. 419 Due to the (intentional) similarities of the DetNet PREOF and TSN 420 FRER functions service protection function interworking is possible 421 between the TSN and the DetNet domains. Such service protection 422 interworking scenarios MAY require to copy sequence number fields 423 from TSN (L2) to PW (MPLS) encapsulation. However, such interworking 424 is out-of-scope in this document and left for further study. 426 A MPLS DetNet flow is configured to carry any number of TSN flows. 427 The DetNet flow specific bandwidth profile SHOULD match the required 428 bandwidth of the App-flow aggregate. 430 5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures 432 In the design of [I-D.ietf-detnet-mpls] an MPLS service label (the 433 S-Label), similar to a pseudowire (PW) label [RFC3985], is used to 434 identify both the DetNet flow identity and the payload MPLS payload 435 type. The DetNet sequence number is carried in the DetNet Control 436 word (d-CW) which carries the Data/OAM discriminator as well. In 437 [I-D.ietf-detnet-mpls] two sequence number sizes are supported: a 16 438 bit sequence number and a 28 bit sequence number. 440 PREOF functions and the provided service recovery is available only 441 within the DetNet domain as the DetNet flow-ID and the DetNet 442 sequence number are not valid outside the DetNet network. MPLS 443 (DetNet) Edge node terminates all related information elements 444 encoded in the MPLS labels. 446 The LSP used to forward the DetNet packet may be of any type (MPLS- 447 LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR [RFC8660]). The LSP 448 (F-Label) label and/or the S-Label may be used to indicate the queue 449 processing as well as the forwarding parameters. 451 When a PE receives a packet from the Service Proxy function it MUST 452 add to the packet the DetNet flow-ID specific S-label and create a 453 d-CW. The PE MUST forward the packet according to the configured 454 DetNet Service and Forwarding sub-layer rules to other PE nodes. 456 When a PE receives an MPLS packet from a remote PE, then, after 457 processing the MPLS label stack, if the top MPLS label ends up being 458 a DetNet S-label that was advertised by this node, then the PE MUST 459 forward the packet according to the configured DetNet Service and 460 Forwarding sub-layer rules to other PE nodes or via the Detnet 461 Service Proxy function towards locally connected CE(s). 463 For further details on DetNet Service and Forwarding sub-layers see 464 [I-D.ietf-detnet-mpls]. 466 6. Controller Plane (Management and Control) Considerations 468 TSN Stream(s) to DetNet flow mapping related information are required 469 only for the service proxy function of MPLS (DetNet) Edge nodes. 470 From the Data Plane perspective there is no practical difference 471 based on the origin of flow mapping related information (management 472 plane or control plane). 474 The following summarizes the set of information that is needed to 475 configure TSN over DetNet MPLS: 477 o TSN related configuration information according to the TSN role of 478 the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and 479 [IEEEP8021CBdb]. 481 o DetNet MPLS related configuration information according to the 482 DetNet role of the DetNet MPLS node, as per 483 [I-D.ietf-detnet-mpls]. 485 o App-Flow identification information to map received TSN Stream(s) 486 to the DetNet flow. Parameters fo TSN stream identification are 487 defined in [IEEE8021CB] and [IEEEP8021CBdb]. 489 This information MUST be provisioned per DetNet flow. 491 MPLS DetNet Edge nodes are member of both the DetNet domain and the 492 connected TSN network. From the TSN network perspective the MPLS 493 (DetNet) Edge node has a "TSN relay node" role, so TSN specific 494 management and control plane functionalities must be implemented. 495 There are many similarities in the management plane techniques used 496 in DetNet and TSN, but that is not the case for the control plane 497 protocols. For example, RSVP-TE and MSRP behaves differently. 498 Therefore management and control plane design is an important aspect 499 of scenarios, where mapping between DetNet and TSN is required. 501 Note that, as the DetNet network is just a portion of the end to end 502 TSN path (i.e., single hop from Ethernet perspective), some 503 parameters (e.g., delay) may differ significantly. Since there is no 504 interworking function the bandwidth of DetNet network is assumed to 505 be set large enough to handle all TSN Flows it will support. At the 506 egress of the Detnet Domain the MPLS headers are stripped and the TSN 507 flow continues on as a normal TSN flow. 509 In order to use a DetNet network to interconnect TSN segments, TSN 510 specific information must be converted to DetNet domain specific 511 ones. TSN Stream ID(s) and stream(s) related parameters/requirements 512 must be converted to a DetNet flow-ID and flow related parameters/ 513 requirements. 515 In some case it may be challenging to determine some egress node 516 related information. For example, it may be not trivial to locate 517 the egress point/interface of a TSN Streams with a multicast 518 destination MAC address. Such scenarios may require interaction 519 between control and management plane functions and between DetNet and 520 TSN domains. 522 Mapping between DetNet flow identifiers and TSN Stream identifiers, 523 if not provided explicitly, can be done by the service proxy function 524 of an MPLS (DetNet) Edge node locally based on information provided 525 for configuration of the TSN Stream identification functions (e.g., 526 Mask-and-Match Stream identification). 528 Triggering the setup/modification of a DetNet flow in the DetNet 529 network is an example where management and/or control plane 530 interactions are required between the DetNet and the TSN network. 532 Configuration of TSN specific functions (e.g., FRER) inside the TSN 533 network is a TSN domain specific decision and may not be visible in 534 the DetNet domain. Service protection interworking scenarios are 535 left for further study. 537 7. Security Considerations 539 Security considerations for DetNet are described in detail in 540 [I-D.ietf-detnet-security]. General security considerations are 541 described in [RFC8655]. 543 DetNet MPLS data plane specific considerations are summarized and 544 described in [I-D.ietf-detnet-mpls] including any application flow 545 types. This document focuses on the scenario where TSN Streams are 546 the application flows for DetNet and it is already covered by those 547 DetNet MPLS data plane security considerations. 549 8. IANA Considerations 551 This document makes no IANA requests. 553 9. Acknowledgements 555 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 556 Christophe Mangin and Jouni Korhonen for their various contributions 557 to this work. 559 10. References 561 10.1. Normative References 563 [I-D.ietf-detnet-mpls] 564 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 565 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 566 detnet-mpls-06 (work in progress), April 2020. 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, 570 DOI 10.17487/RFC2119, March 1997, 571 . 573 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 574 Label Switching Architecture", RFC 3031, 575 DOI 10.17487/RFC3031, January 2001, 576 . 578 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 579 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 580 May 2017, . 582 10.2. Informative References 584 [I-D.ietf-detnet-data-plane-framework] 585 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 586 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 587 data-plane-framework-06 (work in progress), May 2020. 589 [I-D.ietf-detnet-security] 590 Mizrahi, T. and E. Grossman, "Deterministic Networking 591 (DetNet) Security Considerations", draft-ietf-detnet- 592 security-10 (work in progress), May 2020. 594 [IEEE802.1AE-2018] 595 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 596 Security (MACsec)", 2018, 597 . 599 [IEEE8021CB] 600 Finn, N., "Draft Standard for Local and metropolitan area 601 networks - Seamless Redundancy", IEEE P802.1CB 602 /D2.1 P802.1CB, December 2015, 603 . 606 [IEEE8021Q] 607 IEEE 802.1, "Standard for Local and metropolitan area 608 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 609 2014)", 2014, . 611 [IEEEP8021CBdb] 612 Mangin, C., "Extended Stream identification functions", 613 IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019, 614 . 617 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 618 Edge-to-Edge (PWE3) Architecture", RFC 3985, 619 DOI 10.17487/RFC3985, March 2005, 620 . 622 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 623 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 624 December 2005, . 626 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 627 L., and L. Berger, "A Framework for MPLS in Transport 628 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 629 . 631 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 632 "Deterministic Networking Architecture", RFC 8655, 633 DOI 10.17487/RFC8655, October 2019, 634 . 636 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 637 Decraene, B., Litkowski, S., and R. Shakir, "Segment 638 Routing with the MPLS Data Plane", RFC 8660, 639 DOI 10.17487/RFC8660, December 2019, 640 . 642 Authors' Addresses 644 Balazs Varga (editor) 645 Ericsson 646 Magyar Tudosok krt. 11. 647 Budapest 1117 648 Hungary 650 Email: balazs.a.varga@ericsson.com 652 Janos Farkas 653 Ericsson 654 Magyar Tudosok krt. 11. 655 Budapest 1117 656 Hungary 658 Email: janos.farkas@ericsson.com 660 Andrew G. Malis 661 Malis Consulting 663 Email: agmalis@gmail.com 665 Stewart Bryant 666 Futurewei Technologies 668 Email: stewart.bryant@gmail.com 670 Don Fedyk 671 LabN Consulting, L.L.C. 673 Email: dfedyk@labn.net