idnits 2.17.1 draft-ietf-detnet-mpls-over-tsn-01.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 27, 2019) is 1643 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 185, but not defined == Unused Reference: 'G.8275.1' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'G.8275.2' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'IEEE1588' is defined on line 539, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-01 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-05 Summary: 0 errors (**), 0 flaws (~~), 8 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: April 29, 2020 A. Malis 6 Independent 7 S. Bryant 8 Futurewei Technologies 9 October 27, 2019 11 DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-mpls-over-tsn-01 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 April 29, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 11 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 79 [I-D.ietf-detnet-architecture]. 81 The DetNet Architecture decomposes the DetNet related data plane 82 functions into two sub-layers: a service sub-layer and a forwarding 83 sub-layer. The service sub-layer is used to provide DetNet service 84 protection and reordering. The forwarding sub-layer is used to 85 provides congestion protection (low loss, assured latency, and 86 limited reordering) leveraging MPLS Traffic Engineering mechanisms. 88 [I-D.ietf-detnet-mpls] specifies the DetNet data plane operation for 89 MPLS-based Packet Switched Network (PSN). MPLS encapsulated DetNet 90 flows can be carried over network technologies that can provide the 91 DetNet required level of service. This document focuses on the 92 scenario where MPLS (DetNet) nodes are interconnected by a IEEE 802.1 93 TSN sub-network. 95 2. Terminology 97 [Editor's note: Needs clean up.]. 99 2.1. Terms Used in This Document 101 This document uses the terminology established in the DetNet 102 architecture [I-D.ietf-detnet-architecture] and 103 [I-D.ietf-detnet-mpls], and the reader is assumed to be familiar with 104 that document and its terminology. 106 2.2. Abbreviations 108 The following abbreviations are used in this document: 110 CW Control Word. 112 DetNet Deterministic Networking. 114 DF DetNet Flow. 116 FRER Frame Replication and Elimination for Redundancy (TSN 117 function). 119 L2 Layer 2. 121 L3 Layer 3. 123 LSR Label Switching Router. 125 MPLS Multiprotocol Label Switching. 127 PE Provider Edge. 129 PREOF Packet Replication, Elimination and Ordering Functions. 131 PSN Packet Switched Network. 133 PW PseudoWire. 135 S-PE Switching Provider Edge. 137 T-PE Terminating Provider Edge. 139 TSN Time-Sensitive Network. 141 2.3. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 3. DetNet MPLS Data Plane Overview 151 The basic approach defined in [I-D.ietf-detnet-mpls] supports the 152 DetNet service sub-layer based on existing pseudowire (PW) 153 encapsulations and mechanisms, and supports the DetNet forwarding 154 sub-layer based on existing MPLS Traffic Engineering encapsulations 155 and mechanisms. 157 A node operating on a DetNet flow in the Detnet service sub-layer, 158 i.e. a node processing a DetNet packet which has the S-Label as top 159 of stack uses the local context associated with that S-Label, for 160 example a received F-Label, to determine what local DetNet 161 operation(s) are applied to that packet. An S-Label may be unique 162 when taken from the platform label space [RFC3031], which would 163 enable correct DetNet flow identification regardless of which input 164 interface or LSP the packet arrives on. The service sub-layer 165 functions (i.e., PREOF) use a DetNet control word (d-CW). 167 The DetNet MPLS data plane builds on MPLS Traffic Engineering 168 encapsulations and mechanisms to provide a forwarding sub-layer that 169 is responsible for providing resource allocation and explicit routes. 170 The forwarding sub-layer is supported by one or more forwarding 171 labels (F-Labels). 173 Edge Transit Relay 174 Node Node Node 175 (T-PE) (LSR) (S-PE) 176 +---------+ 177 <--|Svc Proxy|-- End to End Service -----------> 178 +---------+ +---------+ 179 |IP | |Svc|<-- DetNet flow ---| Service |---> 180 +---+ +---+ +---------+ +---------+ 181 |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| 182 +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ 183 : / ,-----. \ : Link : : 184 .....+ +-[TSN Sub]-+ +........+ +..... 185 [Network] 186 `-----' 187 |<----------- LSP ---------->| |<--- LSP -->| 188 |<------------- DetNet MPLS ------------ 190 Figure 1: Part of a Simple DetNet MPLS Network using a TSN sub-net 192 Figure 1 illustrates an extract of a DetNet enabled MPLS network. 193 Edge/relay nodes sit at MPLS LSP boundaries and transit nodes are 194 LSRs. In this figure, two MPLS nodes (the edge node and the transit 195 node) are interconnected by a TSN sub-network. 197 DetNet edge/relay nodes are DetNet service sub-layer aware, 198 understand the particular needs of DetNet flows and provide both 199 DetNet service and forwarding sub-layer functions. They add, remove 200 and process d-CWs, S-Labels and F-labels as needed. MPLS enabled 201 DetNet nodes can enhance the reliability of delivery by enabling the 202 replication of packets where multiple copies, possibly over multiple 203 paths, are forwarded through the DetNet domain. They can also 204 eliminate surplus previously replicated copies of DetNet packets. 205 MPLS (DetNet) nodes also include DetNet forwarding sub-layer 206 functions, support for notably explicit routes, and resources 207 allocation to eliminate (or reduce) congestion loss and jitter. 209 DetNet transit nodes reside wholly within a DetNet domain, and also 210 provide DetNet forwarding sub-layer functions in accordance with the 211 performance required by a DetNet flow carried over an LSP. Unlike 212 other DetNet node types, transit nodes provide no service sub-layer 213 processing. 215 4. DetNet MPLS Operation Over IEEE 802.1 TSN Sub-Networks 217 The DetNet WG collaborates with IEEE 802.1 TSN in order to define a 218 common architecture for both Layer 2 and Layer 3, what maintains 219 consistency across diverse networks. Both DetNet MPLS and TSN use 220 the same techniques to provide their deterministic service: 222 o Service protection. 224 o Resource allocation. 226 o Explicit routes. 228 As described in the DetNet architecture 229 [I-D.ietf-detnet-architecture] and also illustrated here in Figure 1 230 a sub-network provides from MPLS perspective a single hop connection 231 between MPLS (DetNet) nodes. Functions used for resource allocation 232 and explicit routes are treated as domain internal functions and does 233 not require function interworking across the DetNet MPLS network and 234 the TSN sub-network. 236 In case of the service protection function due to the similarities of 237 the DetNet PREOF and TSN FRER functions some level of interworking is 238 possible. However, such interworking is out-of-scope in this 239 document and left for further study. 241 Figure 2 illustrates a scenario, where two MPLS (DetNet) nodes are 242 interconnected by a TSN sub-network. Node-1 is single homed and 243 Node-2 is dual-homed to the TSN sub-network. 245 MPLS (DetNet) MPLS (DetNet) 246 Node-1 Node-2 248 +----------+ +----------+ 249 <--| Service* |-- DetNet flow ---| Service* |--> 250 +----------+ +----------+ 251 |Forwarding| |Forwarding| 252 +--------.-+ <-TSN Str-> +-.-----.--+ 253 \ ,-------. / / 254 +----[ TSN-Sub ]---+ / 255 [ Network ]--------+ 256 `-------' 257 <---------------- DetNet MPLS ---------------> 259 Note: * no service sub-layer required for transit nodes 261 Figure 2: DetNet Enabled MPLS Network Over a TSN Sub-Network 263 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 264 Working Group have defined (and are defining) a number of amendments 265 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 266 bounded latency in bridged networks. Furthermore IEEE 802.1CB 267 [IEEE8021CB] defines frame replication and elimination functions for 268 reliability that should prove both compatible with and useful to, 269 DetNet networks. All these functions have to identify flows those 270 require TSN treatment. 272 TSN capabilities of the TSN sub-network are made available for MPLS 273 (DetNet) flows via the protocol interworking function defined in IEEE 274 802.1CB [IEEE8021CB]. For example, applied on the TSN edge port it 275 can convert an ingress unicast MPLS (DetNet) flow to use a specific 276 Layer-2 multicast destination MAC address and a VLAN, in order to 277 direct the packet through a specific path inside the bridged network. 278 A similar interworking function pair at the other end of the TSN sub- 279 network would restore the packet to its original Layer-2 destination 280 MAC address and VLAN. 282 Placement of TSN functions depends on the TSN capabilities of nodes. 283 MPLS (DetNet) Nodes may or may not support TSN functions. For a 284 given TSN Stream (i.e., DetNet flow) an MPLS (DetNet) node is treated 285 as a Talker or a Listener inside the TSN sub-network. 287 4.1. Functions for DetNet Flow to TSN Stream Mapping 289 Mapping of a DetNet MPLS flow to a TSN Stream is provided via the 290 combination of a passive and an active stream identification function 291 that operate at the frame level. The passive stream identification 292 function is used to catch the MPLS label(s) of a DetNet MPLS flow and 293 the active stream identification function is used to modify the 294 Ethernet header according to the ID of the mapped TSN Stream. 296 IEEE P802.1CBdb [IEEEP8021CBdb] defines a Mask-and-Match Stream 297 identification function that can be used as a passive function for 298 MPLS DetNet flows. 300 IEEE 802.1CB [IEEE8021CB] defines an Active Destination MAC and VLAN 301 Stream identification function, what can replace some Ethernet header 302 fields namely (1) the destination MAC-address, (2) the VLAN-ID and 303 (3) priority parameters with alternate values. Replacement is 304 provided for the frame passed down the stack from the upper layers or 305 up the stack from the lower layers. 307 Active Destination MAC and VLAN Stream identification can be used 308 within a Talker to set flow identity or a Listener to recover the 309 original addressing information. It can be used also in a TSN bridge 310 that is providing translation as a proxy service for an End System. 312 4.2. TSN requirements of MPLS DetNet nodes 314 This section covers required behavior of a TSN-aware MPLS (DetNet) 315 node using a TSN sub-network. 317 From the TSN sub-network perspective MPLS (DetNet) nodes are treated 318 as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. 320 In cases of TSN-unaware MPLS DetNet nodes the TSN relay nodes within 321 the TSN sub-network must modify the Ethernet encapsulation of the 322 DetNet MPLS flow (e.g., MAC translation, VLAN-ID setting, Sequence 323 number addition, etc.) to allow proper TSN specific handling inside 324 the sub-network. There are no requirements defined for TSN-unaware 325 MPLS DetNet nodes in this document. 327 MPLS (DetNet) nodes being TSN-aware can be treated as a combination 328 of a TSN-unaware Talker/Listener and a TSN-Relay, as shown in 329 Figure 3. In such cases the MPLS (DetNet) node must provide the TSN 330 sub-network specific Ethernet encapsulation over the link(s) towards 331 the sub-network. 333 MPLS (DetNet) 334 Node 335 <----------------------------------> 337 +----------+ 338 <--| Service* |-- DetNet flow ------------------ 339 +----------+ 340 |Forwarding| 341 +----------+ +---------------+ 342 | L2 | | L2 Relay with |<--- TSN --- 343 | | | TSN function | Stream 344 +-----.----+ +--.------.---.-+ 345 \__________/ \ \______ 346 \_________ 347 TSN-unaware 348 Talker / TSN-Bridge 349 Listener Relay 350 <----- TSN Sub-network ----- 351 <------- TSN-aware Tlk/Lstn -------> 353 Note: * no service sub-layer required for transit nodes 355 Figure 3: MPLS (DetNet) Node with TSN Functions 357 A TSN-aware MPLS (DetNet) node impementations MUST support the Stream 358 Identification TSN component for recognizing flows. 360 A Stream identification component MUST be able to instantiate the 361 following functions (1) Active Destination MAC and VLAN Stream 362 identification function, (2) Mask-and-Match Stream identification 363 function and (3) the related managed objects in Clause 9 of IEEE 364 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb]. 366 A TSN-aware MPLS (DetNet) node implementations MUST support the 367 Sequencing function and the Sequence encode/decode function as 368 defined in IEEE 802.1CB [IEEE8021CB] if FRER is used inside the TSN 369 sub-network. 371 The Sequence encode/decode function MUST support the Redundancy tag 372 (R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB]. 374 A TSN-aware MPLS (DetNet) node implementations MUST support the 375 Stream splitting function and the Individual recovery function as 376 defined in IEEE 802.1CB [IEEE8021CB] when the node is a replication 377 or elimination point for FRER. 379 4.3. Service protection within the TSN sub-network 381 TSN Streams supporting DetNet flows may use Frame Replication and 382 Elimination for Redundancy (FRER) as defined in IEEE 802.1CB 383 [IEEE8021CB] based on the loss service requirements of the TSN 384 Stream, which is derived from the DetNet service requirements of the 385 DetNet mapped flow. The specific operation of FRER is not modified 386 by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB]. 388 FRER function and the provided service recovery is available only 389 within the TSN sub-network as the TSN Stream-ID and the TSN sequence 390 number are not valid outside the sub-network. An MPLS (DetNet) node 391 represents a L3 border and as such it terminates all related 392 information elements encoded in the L2 frames. 394 As the Stream-ID and the TSN sequence number are paired with the 395 similar MPLS flow parameters, FRER can be combined with PREOF 396 functions. Such service protection interworking scenarios may 397 require to move sequence number fields among TSN (L2) and PW (MPLS) 398 encapsulations and they are left for further study. 400 4.4. Aggregation during DetNet flow to TSN Stream mapping 402 Implementations of this document SHALL use management and control 403 information to map a DetNet flow to a TSN Stream. N:1 mapping 404 (aggregating DetNet flows in a single TSN Stream) SHALL be supported. 405 The management or control function that provisions flow mapping SHALL 406 ensure that adequate resources are allocated and configured to 407 provide proper service requirements of the mapped flows. 409 5. Management and Control Implications 411 [Editor's note: This section covers management/control plane related 412 implications of creation, mapping, removal of TSN Stream IDs, their 413 related parameters and, when needed, the configuration of FRER.] 414 DetNet flow and TSN Stream mapping related information are required 415 only for TSN-aware MPLS (DetNet) nodes. From the Data Plane 416 perspective there is no practical difference based on the origin of 417 flow mapping related information (management plane or control plane). 419 TSN-aware MPLS DetNet nodes are member of both the DetNet domain and 420 the TSN sub-network. Within the TSN sub-network the TSN-aware MPLS 421 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 422 management and control plane functionalities must be implemented. 423 There are many similarities in the management plane techniques used 424 in DetNet and TSN, but that is not the case for the control plane 425 protocols. For example, RSVP-TE and MSRP behaves differently. 426 Therefore management and control plane design is an important aspect 427 of scenarios, where mapping between DetNet and TSN is required. 429 In order to use a TSN sub-network between DetNet nodes, DetNet 430 specific information must be converted to TSN sub-network specific 431 ones. DetNet flow ID and flow related parameters/requirements must 432 be converted to a TSN Stream ID and stream related parameters/ 433 requirements. Note that, as the TSN sub-network is just a portion of 434 the end2end DetNet path (i.e., single hop from MPLS perspective), 435 some parameters (e.g., delay) may differ significantly. Other 436 parameters (like bandwidth) also may have to be tuned due to the L2 437 encapsulation used within the TSN sub-network. 439 In some case it may be challenging to determine some TSN Stream 440 related information. For example, on a TSN-aware MPLS (DetNet) node 441 that acts as a Talker, it is quite obvious which DetNet node is the 442 Listener of the mapped TSN stream (i.e., the MPLS Next-Hop). However 443 it may be not trivial to locate the point/interface where that 444 Listener is connected to the TSN sub-network. Such attributes may 445 require interaction between control and management plane functions 446 and between DetNet and TSN domains. 448 Mapping between DetNet flow identifiers and TSN Stream identifiers, 449 if not provided explicitly, can be done by a TSN-aware MPLS (DetNet) 450 node locally based on information provided for configuration of the 451 TSN Stream identification functions (Mask-and-match Stream 452 identification and active Stream identification function). 454 Triggering the setup/modification of a TSN Stream in the TSN sub- 455 network is an example where management and/or control plane 456 interactions are required between the DetNet and TSN sub-network. 457 TSN-unaware MPLS (DetNet) nodes make such a triggering even more 458 complicated as they are fully unaware of the sub-network and run 459 independently. 461 Configuration of TSN specific functions (e.g., FRER) inside the TSN 462 sub-network is a TSN domain specific decision and may not be visible 463 in the DetNet domain. Service protection interworking scenarios are 464 left for further study. 466 6. Security Considerations 468 The security considerations of DetNet in general are discussed in 469 [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. 470 DetNet IP data plane specific considerations are summarized in 471 [I-D.ietf-detnet-ip]. Encryption may provided by an underlying sub- 472 net using MACSec [IEEE802.1AE-2018] for DetNet IP over TSN flows. 474 7. IANA Considerations 476 This document makes no IANA requests. 478 8. Acknowledgements 480 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 481 Christophe Mangin and Jouni Korhonen for their various contributions 482 to this work. 484 9. References 486 9.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 494 Label Switching Architecture", RFC 3031, 495 DOI 10.17487/RFC3031, January 2001, 496 . 498 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 499 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 500 May 2017, . 502 9.2. Informative References 504 [G.8275.1] 505 International Telecommunication Union, "Precision time 506 protocol telecom profile for phase/time synchronization 507 with full timing support from the network", ITU-T 508 G.8275.1/Y.1369.1 G.8275.1, June 2016, 509 . 511 [G.8275.2] 512 International Telecommunication Union, "Precision time 513 protocol telecom profile for phase/time synchronization 514 with partial timing support from the network", ITU-T 515 G.8275.2/Y.1369.2 G.8275.2, June 2016, 516 . 518 [I-D.ietf-detnet-architecture] 519 Finn, N., Thubert, P., Varga, B., and J. Farkas, 520 "Deterministic Networking Architecture", draft-ietf- 521 detnet-architecture-13 (work in progress), May 2019. 523 [I-D.ietf-detnet-ip] 524 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 525 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 526 draft-ietf-detnet-ip-01 (work in progress), July 2019. 528 [I-D.ietf-detnet-mpls] 529 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 530 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 531 draft-ietf-detnet-mpls-01 (work in progress), July 2019. 533 [I-D.ietf-detnet-security] 534 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 535 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 536 Networking (DetNet) Security Considerations", draft-ietf- 537 detnet-security-05 (work in progress), August 2019. 539 [IEEE1588] 540 IEEE, "IEEE 1588 Standard for a Precision Clock 541 Synchronization Protocol for Networked Measurement and 542 Control Systems Version 2", 2008. 544 [IEEE802.1AE-2018] 545 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 546 Security (MACsec)", 2018, 547 . 549 [IEEE8021CB] 550 Finn, N., "Draft Standard for Local and metropolitan area 551 networks - Seamless Redundancy", IEEE P802.1CB 552 /D2.1 P802.1CB, December 2015, 553 . 556 [IEEE8021Q] 557 IEEE 802.1, "Standard for Local and metropolitan area 558 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 559 2014)", 2014, . 561 [IEEEP8021CBdb] 562 Mangin, C., "Extended Stream identification functions", 563 IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019, 564 . 567 Authors' Addresses 569 Balazs Varga (editor) 570 Ericsson 571 Magyar Tudosok krt. 11. 572 Budapest 1117 573 Hungary 575 Email: balazs.a.varga@ericsson.com 577 Janos Farkas 578 Ericsson 579 Magyar Tudosok krt. 11. 580 Budapest 1117 581 Hungary 583 Email: janos.farkas@ericsson.com 585 Andrew G. Malis 586 Independent 588 Email: agmalis@gmail.com 590 Stewart Bryant 591 Futurewei Technologies 593 Email: stewart.bryant@gmail.com