idnits 2.17.1 draft-ietf-detnet-mpls-over-tsn-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 1418 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 181, but not defined == Unused Reference: 'I-D.ietf-detnet-ip' is defined on line 537, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-06 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-06 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-10 Summary: 0 errors (**), 0 flaws (~~), 6 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 June 8, 2020 11 DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-mpls-over-tsn-03 14 Abstract 16 This document specifies the Deterministic Networking MPLS data plane 17 when operating over a TSN sub-network. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 10, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 56 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 4 59 4. DetNet MPLS Operation Over IEEE 802.1 TSN Sub-Networks . . . 5 60 4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 7 61 4.2. TSN requirements of MPLS DetNet nodes . . . . . . . . . . 7 62 4.3. Service protection within the TSN sub-network . . . . . . 9 63 4.4. Aggregation during DetNet flow to TSN Stream mapping . . 9 64 5. Management and Control Implications . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Deterministic Networking (DetNet) is a service that can be offered by 76 a network to DetNet flows. DetNet provides these flows with a low 77 packet loss rates and assured maximum end-to-end delivery latency. 78 General background and concepts of DetNet can be found in [RFC8655]. 80 The DetNet Architecture decomposes the DetNet related data plane 81 functions into two sub-layers: a service sub-layer and a forwarding 82 sub-layer. The service sub-layer is used to provide DetNet service 83 protection and reordering. The forwarding sub-layer is used to 84 provides congestion protection (low loss, assured latency, and 85 limited reordering) leveraging MPLS Traffic Engineering mechanisms. 87 [I-D.ietf-detnet-mpls] specifies the DetNet data plane operation for 88 MPLS-based Packet Switched Network (PSN). MPLS encapsulated DetNet 89 flows can be carried over network technologies that can provide the 90 DetNet required level of service. This document focuses on the 91 scenario where MPLS (DetNet) nodes are interconnected by a IEEE 802.1 92 TSN sub-network. 94 2. Terminology 96 2.1. Terms Used in This Document 98 This document uses the terminology established in the DetNet 99 architecture [RFC8655] and [I-D.ietf-detnet-mpls], and the reader is 100 assumed to be familiar with that document and its terminology. 102 2.2. Abbreviations 104 The following abbreviations are used in this document: 106 CW Control Word. 108 DetNet Deterministic Networking. 110 DF DetNet Flow. 112 FRER Frame Replication and Elimination for Redundancy (TSN 113 function). 115 L2 Layer 2. 117 L3 Layer 3. 119 LSR Label Switching Router. 121 MPLS Multiprotocol Label Switching. 123 PE Provider Edge. 125 PREOF Packet Replication, Elimination and Ordering Functions. 127 PSN Packet Switched Network. 129 PW PseudoWire. 131 S-PE Switching Provider Edge. 133 T-PE Terminating Provider Edge. 135 TSN Time-Sensitive Network. 137 2.3. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. DetNet MPLS Data Plane Overview 147 The basic approach defined in [I-D.ietf-detnet-mpls] supports the 148 DetNet service sub-layer based on existing pseudowire (PW) 149 encapsulations and mechanisms, and supports the DetNet forwarding 150 sub-layer based on existing MPLS Traffic Engineering encapsulations 151 and mechanisms. 153 A node operating on a DetNet flow in the Detnet service sub-layer, 154 i.e. a node processing a DetNet packet which has the S-Label as top 155 of stack uses the local context associated with that S-Label, for 156 example a received F-Label, to determine what local DetNet 157 operation(s) are applied to that packet. An S-Label may be unique 158 when taken from the platform label space [RFC3031], which would 159 enable correct DetNet flow identification regardless of which input 160 interface or LSP the packet arrives on. The service sub-layer 161 functions (i.e., PREOF) use a DetNet control word (d-CW). 163 The DetNet MPLS data plane builds on MPLS Traffic Engineering 164 encapsulations and mechanisms to provide a forwarding sub-layer that 165 is responsible for providing resource allocation and explicit routes. 166 The forwarding sub-layer is supported by one or more forwarding 167 labels (F-Labels). 169 Edge Transit Relay 170 Node Node Node 171 (T-PE) (LSR) (S-PE) 172 +---------+ 173 <--|Svc Proxy|-- End to End Service -----------> 174 +---------+ +---------+ 175 |IP | |Svc|<-- DetNet flow ---| Service |---> 176 +---+ +---+ +---------+ +---------+ 177 |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| 178 +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ 179 : / ,-----. \ : Link : : 180 .....+ +-[TSN Sub]-+ +........+ +..... 181 [Network] 182 `-----' 183 |<----------- LSP ---------->| |<--- LSP -->| 184 |<------------- DetNet MPLS ------------ 186 Figure 1: Part of a Simple DetNet MPLS Network using a TSN sub-net 188 Figure 1 illustrates an extract of a DetNet enabled MPLS network. 189 Edge/relay nodes sit at MPLS LSP boundaries and transit nodes are 190 LSRs. In this figure, two MPLS nodes (the edge node and the transit 191 node) are interconnected by a TSN sub-network. 193 DetNet edge/relay nodes are DetNet service sub-layer aware, 194 understand the particular needs of DetNet flows and provide both 195 DetNet service and forwarding sub-layer functions. They add, remove 196 and process d-CWs, S-Labels and F-labels as needed. MPLS enabled 197 DetNet nodes can enhance the reliability of delivery by enabling the 198 replication of packets where multiple copies, possibly over multiple 199 paths, are forwarded through the DetNet domain. They can also 200 eliminate surplus previously replicated copies of DetNet packets. 201 MPLS (DetNet) nodes also include DetNet forwarding sub-layer 202 functions, support for notably explicit routes, and resources 203 allocation to eliminate (or reduce) congestion loss and jitter. 205 DetNet transit nodes reside wholly within a DetNet domain, and also 206 provide DetNet forwarding sub-layer functions in accordance with the 207 performance required by a DetNet flow carried over an LSP. Unlike 208 other DetNet node types, transit nodes provide no service sub-layer 209 processing. 211 4. DetNet MPLS Operation Over IEEE 802.1 TSN Sub-Networks 213 The DetNet WG collaborates with IEEE 802.1 TSN in order to define a 214 common architecture for both Layer 2 and Layer 3, what maintains 215 consistency across diverse networks. Both DetNet MPLS and TSN use 216 the same techniques to provide their deterministic service: 218 o Service protection. 220 o Resource allocation. 222 o Explicit routes. 224 As described in the DetNet architecture [RFC8655] and also 225 illustrated here in Figure 1 a sub-network provides from MPLS 226 perspective a single hop connection between MPLS (DetNet) nodes. 227 Functions used for resource allocation and explicit routes are 228 treated as domain internal functions and does not require function 229 interworking across the DetNet MPLS network and the TSN sub-network. 231 In case of the service protection function due to the similarities of 232 the DetNet PREOF and TSN FRER functions some level of interworking is 233 possible. However, such interworking is out-of-scope in this 234 document and left for further study. 236 Figure 2 illustrates a scenario, where two MPLS (DetNet) nodes are 237 interconnected by a TSN sub-network. Node-1 is single homed and 238 Node-2 is dual-homed to the TSN sub-network. 240 MPLS (DetNet) MPLS (DetNet) 241 Node-1 Node-2 243 +----------+ +----------+ 244 <--| Service* |-- DetNet flow ---| Service* |--> 245 +----------+ +----------+ 246 |Forwarding| |Forwarding| 247 +--------.-+ <-TSN Str-> +-.-----.--+ 248 \ ,-------. / / 249 +----[ TSN-Sub ]---+ / 250 [ Network ]--------+ 251 `-------' 252 <---------------- DetNet MPLS ---------------> 254 Note: * no service sub-layer required for transit nodes 256 Figure 2: DetNet Enabled MPLS Network Over a TSN Sub-Network 258 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 259 Working Group have defined (and are defining) a number of amendments 260 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 261 bounded latency in bridged networks. Furthermore IEEE 802.1CB 262 [IEEE8021CB] defines frame replication and elimination functions for 263 reliability that should prove both compatible with and useful to, 264 DetNet networks. All these functions have to identify flows those 265 require TSN treatment. 267 TSN capabilities of the TSN sub-network are made available for MPLS 268 (DetNet) flows via the protocol interworking function defined in 269 Annex C.5 of IEEE 802.1CB [IEEE8021CB]. For example, applied on the 270 TSN edge port it can convert an ingress unicast MPLS (DetNet) flow to 271 use a specific Layer-2 multicast destination MAC address and a VLAN, 272 in order to direct the packet through a specific path inside the 273 bridged network. A similar interworking function pair at the other 274 end of the TSN sub-network would restore the packet to its original 275 Layer-2 destination MAC address and VLAN. 277 Placement of TSN functions depends on the TSN capabilities of nodes. 278 MPLS (DetNet) Nodes may or may not support TSN functions. For a 279 given TSN Stream (i.e., DetNet flow) an MPLS (DetNet) node is treated 280 as a Talker or a Listener inside the TSN sub-network. 282 4.1. Functions for DetNet Flow to TSN Stream Mapping 284 Mapping of a DetNet MPLS flow to a TSN Stream is provided via the 285 combination of a passive and an active stream identification function 286 that operate at the frame level. The passive stream identification 287 function is used to catch the MPLS label(s) of a DetNet MPLS flow and 288 the active stream identification function is used to modify the 289 Ethernet header according to the ID of the mapped TSN Stream. 291 Clause 6.8 of IEEE P802.1CBdb [IEEEP8021CBdb] defines a Mask-and- 292 Match Stream identification function that can be used as a passive 293 function for MPLS DetNet flows. 295 Clause 6.6 of IEEE 802.1CB [IEEE8021CB] defines an Active Destination 296 MAC and VLAN Stream identification function, what can replace some 297 Ethernet header fields namely (1) the destination MAC-address, (2) 298 the VLAN-ID and (3) priority parameters with alternate values. 299 Replacement is provided for the frame passed down the stack from the 300 upper layers or up the stack from the lower layers. 302 Active Destination MAC and VLAN Stream identification can be used 303 within a Talker to set flow identity or a Listener to recover the 304 original addressing information. It can be used also in a TSN bridge 305 that is providing translation as a proxy service for an End System. 307 4.2. TSN requirements of MPLS DetNet nodes 309 This section covers required behavior of a TSN-aware MPLS (DetNet) 310 node using a TSN sub-network. The implementation of TSN packet 311 processing functions MUST be compliant with the relevant IEEE 802.1 312 standards. 314 From the TSN sub-network perspective MPLS (DetNet) nodes are treated 315 as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. 317 In cases of TSN-unaware MPLS DetNet nodes the TSN relay nodes within 318 the TSN sub-network must modify the Ethernet encapsulation of the 319 DetNet MPLS flow (e.g., MAC translation, VLAN-ID setting, Sequence 320 number addition, etc.) to allow proper TSN specific handling inside 321 the sub-network. There are no requirements defined for TSN-unaware 322 MPLS DetNet nodes in this document. 324 MPLS (DetNet) nodes being TSN-aware can be treated as a combination 325 of a TSN-unaware Talker/Listener and a TSN-Relay, as shown in 326 Figure 3. In such cases the MPLS (DetNet) node must provide the TSN 327 sub-network specific Ethernet encapsulation over the link(s) towards 328 the sub-network. 330 MPLS (DetNet) 331 Node 332 <----------------------------------> 334 +----------+ 335 <--| Service* |-- DetNet flow ------------------ 336 +----------+ 337 |Forwarding| 338 +----------+ +---------------+ 339 | L2 | | L2 Relay with |<--- TSN --- 340 | | | TSN function | Stream 341 +-----.----+ +--.------.---.-+ 342 \__________/ \ \______ 343 \_________ 344 TSN-unaware 345 Talker / TSN-Bridge 346 Listener Relay 347 <----- TSN Sub-network ----- 348 <------- TSN-aware Tlk/Lstn -------> 350 Note: * no service sub-layer required for transit nodes 352 Figure 3: MPLS (DetNet) Node with TSN Functions 354 A TSN-aware MPLS (DetNet) node impementations MUST support the Stream 355 Identification TSN component for recognizing flows. 357 A Stream identification component MUST be able to instantiate the 358 following functions (1) Active Destination MAC and VLAN Stream 359 identification function, (2) Mask-and-Match Stream identification 360 function and (3) the related managed objects in Clause 9 of IEEE 361 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]. 363 A TSN-aware MPLS (DetNet) node implementations MUST support the 364 Sequencing function and the Sequence encode/decode function as 365 defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is 366 used inside the TSN sub-network. 368 The Sequence encode/decode function MUST support the Redundancy tag 369 (R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB]. 371 A TSN-aware MPLS (DetNet) node implementations MUST support the 372 Stream splitting function and the Individual recovery function as 373 defined in Clause 7.7 and 7.5 of IEEE 802.1CB [IEEE8021CB] when the 374 node is a replication or elimination point for FRER. 376 4.3. Service protection within the TSN sub-network 378 TSN Streams supporting DetNet flows may use Frame Replication and 379 Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE 380 802.1CB [IEEE8021CB] based on the loss service requirements of the 381 TSN Stream, which is derived from the DetNet service requirements of 382 the DetNet mapped flow. The specific operation of FRER is not 383 modified by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB]. 385 FRER function and the provided service recovery is available only 386 within the TSN sub-network as the TSN Stream-ID and the TSN sequence 387 number are not valid outside the sub-network. An MPLS (DetNet) node 388 represents a L3 border and as such it terminates all related 389 information elements encoded in the L2 frames. 391 As the Stream-ID and the TSN sequence number are paired with the 392 similar MPLS flow parameters, FRER can be combined with PREOF 393 functions. Such service protection interworking scenarios may 394 require to move sequence number fields among TSN (L2) and PW (MPLS) 395 encapsulations and they are left for further study. 397 4.4. Aggregation during DetNet flow to TSN Stream mapping 399 Implementations of this document SHALL use management and control 400 information to map a DetNet flow to a TSN Stream. N:1 mapping 401 (aggregating DetNet flows in a single TSN Stream) SHALL be supported. 402 The management or control function that provisions flow mapping SHALL 403 ensure that adequate resources are allocated and configured to 404 provide proper service requirements of the mapped flows. 406 5. Management and Control Implications 408 DetNet flow and TSN Stream mapping related information are required 409 only for TSN-aware MPLS (DetNet) nodes. From the Data Plane 410 perspective there is no practical difference based on the origin of 411 flow mapping related information (management plane or control plane). 413 The following summarizes the set of information that is needed to 414 configure DetNet MPLS over TSN: 416 o DetNet MPLS related configuration information according to the 417 DetNet role of the DetNet MPLS node, as per 418 [I-D.ietf-detnet-mpls]. 420 o TSN related configuration information according to the TSN role of 421 the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and 422 [IEEEP8021CBdb]. 424 o Mapping between DetNet MPLS flow(s) (label information: A-labels, 425 S-labels and F-labels as defined in [I-D.ietf-detnet-mpls]) and 426 TSN Stream(s) (as stream identification information defined in 427 [IEEEP8021CBdb]). Note, that managed objects for TSN Stream 428 identification can be found in [IEEEP8021CBcv]. 430 This information MUST be provisioned per DetNet flow. 432 TSN-aware MPLS DetNet nodes are member of both the DetNet domain and 433 the TSN sub-network. Within the TSN sub-network the TSN-aware MPLS 434 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 435 management and control plane functionalities must be implemented. 436 There are many similarities in the management plane techniques used 437 in DetNet and TSN, but that is not the case for the control plane 438 protocols. For example, RSVP-TE and MSRP behaves differently. 439 Therefore management and control plane design is an important aspect 440 of scenarios, where mapping between DetNet and TSN is required. 442 In order to use a TSN sub-network between DetNet nodes, DetNet 443 specific information must be converted to TSN sub-network specific 444 ones. DetNet flow ID and flow related parameters/requirements must 445 be converted to a TSN Stream ID and stream related parameters/ 446 requirements. Note that, as the TSN sub-network is just a portion of 447 the end2end DetNet path (i.e., single hop from MPLS perspective), 448 some parameters (e.g., delay) may differ significantly. Other 449 parameters (like bandwidth) also may have to be tuned due to the L2 450 encapsulation used within the TSN sub-network. 452 In some case it may be challenging to determine some TSN Stream 453 related information. For example, on a TSN-aware MPLS (DetNet) node 454 that acts as a Talker, it is quite obvious which DetNet node is the 455 Listener of the mapped TSN stream (i.e., the MPLS Next-Hop). However 456 it may be not trivial to locate the point/interface where that 457 Listener is connected to the TSN sub-network. Such attributes may 458 require interaction between control and management plane functions 459 and between DetNet and TSN domains. 461 Mapping between DetNet flow identifiers and TSN Stream identifiers, 462 if not provided explicitly, can be done by a TSN-aware MPLS (DetNet) 463 node locally based on information provided for configuration of the 464 TSN Stream identification functions (Mask-and-match Stream 465 identification and active Stream identification function). 467 Triggering the setup/modification of a TSN Stream in the TSN sub- 468 network is an example where management and/or control plane 469 interactions are required between the DetNet and TSN sub-network. 470 TSN-unaware MPLS (DetNet) nodes make such a triggering even more 471 complicated as they are fully unaware of the sub-network and run 472 independently. 474 Configuration of TSN specific functions (e.g., FRER) inside the TSN 475 sub-network is a TSN domain specific decision and may not be visible 476 in the DetNet domain. Service protection interworking scenarios are 477 left for further study. 479 6. Security Considerations 481 Security considerations for DetNet are described in detail in 482 [I-D.ietf-detnet-security]. General security considerations are 483 described in [RFC8655]. DetNet MPLS data plane specific 484 considerations are summarized in [I-D.ietf-detnet-mpls]. This 485 section considers exclusively security considerations which are 486 specific to the DetNet MPLS over TSN sub-network scenario. 488 The sub-network between DetNet nodes needs to be subject to 489 appropriate confidentiality. Additionally, knowledge of what DetNet/ 490 TSN services are provided by a sub-network may supply information 491 that can be used in a variety of security attacks. The ability to 492 modify information exchanges between connected DetNet nodes may 493 result in bogus operations. Therefore, it is important that the 494 interface between DetNet nodes and TSN sub-network are subject to 495 authorization, authentication, and encryption. 497 The TSN sub-network operates at Layer-2 so various security 498 mechanisms defined by IEEE can be used to secure the connection 499 between the DetNet nodes (e.g., encryption may be provided using 500 MACSec [IEEE802.1AE-2018]). 502 7. IANA Considerations 504 This document makes no IANA requests. 506 8. Acknowledgements 508 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 509 Christophe Mangin and Jouni Korhonen for their various contributions 510 to this work. 512 9. References 514 9.1. Normative References 516 [I-D.ietf-detnet-mpls] 517 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 518 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 519 detnet-mpls-06 (work in progress), April 2020. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 527 Label Switching Architecture", RFC 3031, 528 DOI 10.17487/RFC3031, January 2001, 529 . 531 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 532 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 533 May 2017, . 535 9.2. Informative References 537 [I-D.ietf-detnet-ip] 538 Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. 539 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06 540 (work in progress), April 2020. 542 [I-D.ietf-detnet-security] 543 Mizrahi, T. and E. Grossman, "Deterministic Networking 544 (DetNet) Security Considerations", draft-ietf-detnet- 545 security-10 (work in progress), May 2020. 547 [IEEE802.1AE-2018] 548 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 549 Security (MACsec)", 2018, 550 . 552 [IEEE8021CB] 553 Finn, N., "Draft Standard for Local and metropolitan area 554 networks - Seamless Redundancy", IEEE P802.1CB 555 /D2.1 P802.1CB, December 2015, 556 . 559 [IEEE8021Q] 560 IEEE 802.1, "Standard for Local and metropolitan area 561 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 562 2014)", 2014, . 564 [IEEEP8021CBcv] 565 Kehrer, S., "FRER YANG Data Model and Management 566 Information Base Module", IEEE P802.1CBcv 567 /D0.3 P802.1CBcv, May 2020, 568 . 571 [IEEEP8021CBdb] 572 Mangin, C., "Extended Stream identification functions", 573 IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019, 574 . 577 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 578 "Deterministic Networking Architecture", RFC 8655, 579 DOI 10.17487/RFC8655, October 2019, 580 . 582 Authors' Addresses 584 Balazs Varga (editor) 585 Ericsson 586 Magyar Tudosok krt. 11. 587 Budapest 1117 588 Hungary 590 Email: balazs.a.varga@ericsson.com 592 Janos Farkas 593 Ericsson 594 Magyar Tudosok krt. 11. 595 Budapest 1117 596 Hungary 598 Email: janos.farkas@ericsson.com 600 Andrew G. Malis 601 Malis Consulting 603 Email: agmalis@gmail.com 605 Stewart Bryant 606 Futurewei Technologies 608 Email: stewart.bryant@gmail.com