path: root/doc/rfc/rfc9024.txt

Internet Engineering Task Force (IETF)                     B. Varga, Ed.
Request for Comments: 9024                                     J. Farkas
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                                 A. Malis
                                                        Malis Consulting
                                                               S. Bryant
                                                  Futurewei Technologies
                                                                D. Fedyk
                                                 LabN Consulting, L.L.C.
                                                               June 2021


Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive
                          Networking over MPLS

Abstract

   This document specifies the Deterministic Networking data plane when
   Time-Sensitive Networking (TSN) networks are interconnected over a
   DetNet MPLS network.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9024.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
     2.1.  Terms Used in This Document
     2.2.  Abbreviations
     2.3.  Requirements Language
   3.  IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario
   4.  DetNet MPLS Data Plane
     4.1.  Overview
     4.2.  TSN over DetNet MPLS Encapsulation
   5.  TSN over MPLS Data Plane Procedures
     5.1.  Edge Node TSN Procedures
     5.2.  Edge Node DetNet Service Proxy Procedures
     5.3.  Edge Node DetNet Service and Forwarding Sub-Layer
           Procedures
   6.  Controller Plane (Management and Control) Considerations
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1.  Introduction

   The Time-Sensitive Networking Task Group (TSN TG) within the IEEE
   802.1 Working Group deals with deterministic services through IEEE
   802 networks.  Deterministic Networking (DetNet) defined by the IETF
   is a service that can be offered by an L3 network to DetNet flows.
   General background and concepts of DetNet can be found in [RFC8655].

   This document specifies the use of a DetNet MPLS network to
   interconnect TSN nodes/network segments.  The DetNet MPLS data plane
   is defined in [RFC8964].

2.  Terminology

2.1.  Terms Used in This Document

   This document uses the terminology and concepts established in the
   DetNet architecture [RFC8655] [RFC8938] [RFC8964].  TSN-specific
   terms are defined in the TSN TG of the IEEE 802.1 Working Group.  The
   reader is assumed to be familiar with these documents and their
   terminology.

2.2.  Abbreviations

   The following abbreviations are used in this document:

   AC            Attachment Circuit

   CE            Customer Edge equipment

   d-CW          DetNet Control Word

   DetNet        Deterministic Networking

   DF            DetNet Flow

   FRER          Frame Replication and Elimination for Redundancy (TSN
                 function)

   L2            Layer 2

   L2VPN         Layer 2 Virtual Private Network

   L3            Layer 3

   LSP           Label Switched Path

   LSR           Label Switching Router

   MPLS          Multiprotocol Label Switching

   MPLS-TE       Multiprotocol Label Switching - Traffic Engineering

   NSP           Native Service Processing

   OAM           Operations, Administration, and Maintenance

   PE            Provider Edge

   PREOF         Packet Replication, Elimination and Ordering Functions

   PW            Pseudowire

   S-PE          Switching Provider Edge

   T-PE          Terminating Provider Edge

   TSN           Time-Sensitive Network

2.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario

   Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN-aware
   DetNet service running over an MPLS network.  DetNet edge nodes sit
   at the boundary of a DetNet domain.  They are responsible for mapping
   non-DetNet-aware L2 traffic to DetNet services.  They also support
   the imposition and disposition of the required DetNet encapsulation.
   These are functionally similar to PW T-PE nodes, which use MPLS-TE
   LSPs.  In this example, TSN Streams are simple applications over
   DetNet flows.  The specifics of this operation are discussed later in
   this document.

      TSN           Edge          Transit         Edge          TSN
   End System       Node           Node           Node       End System
                   (T-PE)         (LSR)          (T-PE)

   +----------+                                             +----------+
   |   TSN    | <-------- End-to-End TSN Service ---------> |   TSN    |
   |  Applic. |                                             |  Applic. |
   +----------+  +.........+                   +.........+  +----------+
   |          |  | \S-Proxy:                   :S-Proxy/ |  |          |
   |   TSN    |  |   +.+---+<-- DetNet flow -->+---+ |   |  |   TSN    |
   |          |  |TSN| |Svc|                   |Svc| |TSN|  |          |
   +----------+  +---+ +---+    +----------+   +---+ +---+  +----------+
   |   L2     |  | L2| |Fwd|    |Forwarding|   |Fwd| |L2 |  |   L2     |
   +------.---+  +-.-+ +-.-+    +---.----.-+   +--.+ +-.-+  +---.------+
          :  Link  :     /  ,-----.  \   :  Link  :   /  ,-----. \
          +........+     +-[  Sub- ]-+   +........+   +-[  TSN  ]-+
                           [Network]                    [Network]
                            `-----'                      `-----'

                       |<------ DetNet MPLS ------>|
           |<---------------------- TSN   --------------------->|

              Figure 1: A TSN over DetNet MPLS-Enabled Network

   In this example, edge nodes provide a service proxy function that
   "associates" the DetNet flows and native flows (i.e., TSN Streams) at
   the edge of the DetNet domain.  TSN Streams are treated as App-flows
   for DetNet.  The whole DetNet domain behaves as a TSN relay node for
   the TSN Streams.  The service proxy behaves as a port of that TSN
   relay node.

   Figure 2 illustrates how DetNet can provide services for IEEE 802.1
   TSN end systems, CE1 and CE2, over a DetNet-enabled MPLS network.
   Edge nodes E1 and E2 insert and remove the required DetNet data plane
   encapsulation.  The 'X' in the edge nodes and relay node, R1,
   represent a potential DetNet compound flow packet replication and
   elimination point.  This conceptually parallels L2VPN services and
   could leverage existing related solutions as discussed below.

        TSN    |<------- End-to-End DetNet Service ------>|  TSN
       Service |         Transit          Transit         | Service
   TSN  (AC)   |        |<-Tnl->|        |<-Tnl->|        |  (AC)  TSN
   End    |    V        V    1  V        V   2   V        V   |    End
   System |    +--------+       +--------+       +--------+   |  System
   +---+  |    |   E1   |=======|   R1   |=======|   E2   |   |   +---+
   |   |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---|   |
   |CE1|  |    |    \   |       |   X    |       |   /    |   |   |CE2|
   |   |       |     \_.|..DF2..|._/ \_..|..DF4..|._/     |       |   |
   +---+       |        |=======|        |=======|        |       +---+
       ^       +--------+       +--------+       +--------+       ^
       |        Edge Node       Relay Node        Edge Node       |
       |          (T-PE)           (S-PE)          (T-PE)         |
       |                                                          |
       |<- TSN -> <------- TSN over DetNet MPLS -------> <- TSN ->|
       |                                                          |
       |<-------- Time-Sensitive Networking (TSN) Service ------->|

       X   = Service protection
       DFx = DetNet member flow x over a TE LSP
           AC  = Attachment Circuit
           Tnl = Tunnel

                    Figure 2: IEEE 802.1TSN over DetNet

4.  DetNet MPLS Data Plane

4.1.  Overview

   The basic approach defined in [RFC8964] supports the DetNet service
   sub-layer based on existing PW encapsulations and mechanisms and
   supports the DetNet forwarding sub-layer based on existing MPLS
   Traffic Engineering encapsulations and mechanisms.

   A node operating on a DetNet flow in the DetNet service sub-layer,
   i.e., a node processing a DetNet packet that has the S-Label as top
   of stack, uses the local context associated with that S-Label.  For
   example, a received F-Label can be used to determine what local
   DetNet operation(s) is applied to that packet.  An S-Label may be
   unique when taken from the platform label space [RFC3031], which
   would enable correct DetNet flow identification regardless of which
   input interface or LSP the packet arrives on.  The service sub-layer
   functions (i.e., PREOF) use a DetNet control word (d-CW).

   The DetNet MPLS data plane builds on MPLS Traffic Engineering
   encapsulations and mechanisms to provide a forwarding sub-layer that
   is responsible for providing resource allocation and explicit routes.
   The forwarding sub-layer is supported by one or more forwarding
   labels (F-Labels).

   DetNet edge/relay nodes are DetNet service sub-layer aware,
   understand the particular needs of DetNet flows, and provide both
   DetNet service and forwarding sub-layer functions.  They add, remove,
   and process d-CWs, S-Labels, and F-Labels as needed.  MPLS DetNet
   nodes and transit nodes include DetNet forwarding sub-layer functions
   -- notably, support for explicit routes and resource allocation to
   eliminate (or reduce) congestion loss and jitter.  Unlike other
   DetNet node types, transit nodes provide no service sub-layer
   processing.

4.2.  TSN over DetNet MPLS Encapsulation

   The basic encapsulation approach is to treat a TSN Stream as an App-
   flow from the DetNet MPLS perspective.  The corresponding example is
   shown in Figure 3.  Note that three example flows are shown in the
   figure.

                /->     +------+  +------+  +------+   TSN      ^ ^
       MPLS     |       |  X   |  |  X   |  |  X   |<- Appli    : :
     App-Flow <-+       +------+  +------+  +------+   cation   : :(1)
                |       |TSN-L2|  |TSN-L2|  |TSN-L2|            : v
                \-> +---+======+--+======+--+======+-----+      :
                        | d-CW |  | d-CW |  | d-CW |            :
     DetNet-MPLS        +------+  +------+  +------+            :(2)
                        |Labels|  |Labels|  |Labels|            v
                    +---+======+--+======+--+======+-----+
     Link/Sub-Network   |  L2  |  | TSN  |  | UDP  |
                        +------+  +------+  +------+
                                            |  IP  |
                                            +------+
                                            |  L2  |
                                            +------+
         (1) TSN Stream
         (2) DetNet MPLS Flow

         Figure 3: Examples of TSN over MPLS Encapsulation Formats

   In the figure, "Application" indicates the application payload
   carried by the TSN network.  "MPLS App-Flow" indicates that the TSN
   Stream is the payload from the perspective of the DetNet MPLS data
   plane defined in [RFC8964].  A single DetNet MPLS flow can aggregate
   multiple TSN Streams.

      |  Note: Network fragmentation for DetNet is not supported and
      |  MUST be avoided.  The reason for this is that network
      |  fragmentation is not consistent with the packet delivery times
      |  needed for DetNet.  Therefore, when IP is used as the sub-
      |  network, IPv6 fragmentation MUST NOT be used, and IPv4 packets
      |  MUST be sent with the DF bit set.  This means that the network
      |  operator MUST ensure that all the DetNet encapsulation overhead
      |  plus the maximum TSN App-flow frame size does not exceed the
      |  DetNet network's MTU.

5.  TSN over MPLS Data Plane Procedures

   The description of edge node procedures and functions for TSN over
   DetNet MPLS scenarios follows the concepts from [RFC3985] and covers
   the edge node components shown in Figure 1.  In this section, the
   following procedures of DetNet edge nodes are described:

   *  TSN related (Section 5.1)

   *  DetNet Service Proxy (Section 5.2)

   *  DetNet service and forwarding sub-layer (Section 5.3)

   The subsections describe procedures for forwarding packets by DetNet
   edge nodes, where such packets are received from either directly
   connected CEs (TSN nodes) or some other DetNet edge nodes.

5.1.  Edge Node TSN Procedures

   The TSN TG of the IEEE 802.1 Working Group has defined (and is
   defining) a number of amendments to [IEEE8021Q] that provide zero
   congestion loss and bounded latency in bridged networks.
   [IEEE8021CB] defines packet replication and elimination functions for
   a TSN network.

   The implementation of a TSN entity (i.e., TSN packet processing
   functions) must be compliant with the relevant IEEE 802.1 standards.

   TSN-specific functions are executed on the data received by the
   DetNet edge node from the connected CE before being forwarded to
   connected CE(s) or presented to the DetNet service proxy function for
   transmission across the DetNet domain.  TSN-specific functions are
   also executed on the data received from a DetNet PW by a PE before
   the data is output on the AC(s).

   The TSN packet processing function(s) of edge nodes (T-PE) belongs to
   the NSP [RFC3985] block.  This is similar to other functionalities
   being defined by standards bodies other than the IETF (for example,
   in the case of Ethernet, stripping, overwriting, or adding VLAN tags,
   etc.).  Depending on the TSN role of the edge node in the end-to-end
   TSN service, selected TSN functions are supported.

   When a PE receives a packet from a CE on a given AC with DetNet
   service, it first checks via Stream identification (see Clause 6 of
   [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a
   configured TSN Stream (i.e., App-flow from the DetNet perspective).
   If no Stream ID is matched and no other (VPN) service is configured
   for the AC, then the packet MUST be dropped.  If there is a matching
   TSN Stream, then the Stream-ID-specific TSN functions are executed
   (e.g., ingress policing, header field manipulation in the case of
   active Stream identification, FRER, etc.).  Source Media Access
   Control (MAC) lookup may also be used for local MAC address learning.

   If the PE decides to forward the packet, the packet MUST be forwarded
   according to the TSN-Stream-specific configuration to connected CE(s)
   (in case of local bridging) and/or to the DetNet service proxy (in
   case of forwarding to remote CE(s)).  If there are no TSN-Stream-
   specific forwarding configurations, the PE MUST flood the packet to
   other locally attached CE(s) and to the DetNet service proxy.  If the
   administrative policy on the PE does not allow flooding, the PE MUST
   drop the packet.

   When a TSN entity of the PE receives a packet from the DetNet service
   proxy, it first checks via Stream identification (see Clause 6 of
   [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a
   configured TSN Stream.  If no Stream ID is matched, then the packet
   is dropped.  If there is a matching TSN Stream, then the Stream-ID-
   specific TSN functions are executed (e.g., header field manipulation
   in case of active Stream identification, FRER, etc.).  Source MAC
   lookup may also be used for local MAC address learning.

   If the PE decides to forward the packet, the packet is forwarded
   according to the TSN-Stream-specific configuration to connected
   CE(s).  If there are no TSN-Stream-specific forwarding
   configurations, the PE floods the packet to locally attached CE(s).
   If the administrative policy on the PE does not allow flooding, the
   PE drops the packet.

   Implementations of this document SHALL use management and control
   information to ensure TSN-specific functions of the edge node
   according to the expectations of the connected TSN network.

5.2.  Edge Node DetNet Service Proxy Procedures

   The service proxy function maps between App-flows and DetNet flows.
   The DetNet edge node TSN entity MUST support the TSN Stream
   identification functions (as defined in Clause 6 of [IEEE8021CB] and
   [IEEEP8021CBdb]) and the related managed objects (as defined in
   Clause 9 of [IEEE8021CB] and [IEEEP8021CBdb]) to recognize the
   packets related to App-flow.  The service proxy presents TSN Streams
   as an App-flow to a DetNet flow.

   When a DetNet service proxy receives a packet from the TSN entity, it
   MUST check whether such an App-flow is present in its mapping table.
   If present, it associates the internal DetNet flow ID to the packet
   and MUST forward it to the DetNet service and forwarding sub-layers.
   If no match is found, it MUST drop the packet.

   When a DetNet service proxy receives a packet from the DetNet service
   and forwarding sub-layers, it MUST be forwarded to the edge node TSN
   entity.

   Implementations of this document SHALL use management and control
   information to map a TSN Stream to a DetNet flow.  N:1 mapping
   (aggregating multiple TSN Streams in a single DetNet flow) SHALL be
   supported.  The management or control function that provisions flow
   mapping SHALL ensure that adequate resources are allocated and
   configured to fulfill the service requirements of the mapped flows.

   Due to the (intentional) similarities of the DetNet PREOF and TSN
   FRER functions, service protection function interworking is possible
   between the TSN and the DetNet domains.  Such service protection
   interworking scenarios might require copying of sequence number
   fields from TSN (L2) to PW (MPLS) encapsulation.  However, such
   interworking is out of scope in this document and is left for further
   study.

5.3.  Edge Node DetNet Service and Forwarding Sub-Layer Procedures

   In the design presented in [RFC8964], an MPLS service label (the
   S-Label), similar to a PW label [RFC3985], is used to identify both
   the DetNet flow identity and the MPLS payload type.  The DetNet
   sequence number is carried in the d-CW, which carries the Data/OAM
   discriminator as well.  In [RFC8964], two sequence number sizes are
   supported: a 16-bit sequence number and a 28-bit sequence number.

   PREOF functions and the provided service recovery are available only
   within the DetNet domain as the DetNet flow ID and the DetNet
   sequence number are not valid outside the DetNet network.  MPLS
   (DetNet) edge nodes terminate all related information elements
   encoded in the MPLS labels.

   When a PE receives a packet from the service proxy function, it MUST
   handle the packet as defined in [RFC8964].

   When a PE receives an MPLS packet from a remote PE, then, after
   processing the MPLS label stack, if the top MPLS label ends up being
   a DetNet S-Label that was advertised by this node, then the PE MUST
   forward the packet according to the configured DetNet service and
   forwarding sub-layer rules to other PE nodes or via the DetNet
   service proxy function towards locally connected CE(s).

   For further details on DetNet service and forwarding sub-layers, see
   [RFC8964].

6.  Controller Plane (Management and Control) Considerations

   Information related to TSN Stream(s) to DetNet flow mapping is
   required only for the service proxy function of MPLS (DetNet) edge
   nodes.  From the data plane perspective, there is no practical
   difference based on the origin of flow-mapping-related information
   (management plane or control plane).

   The following summarizes the set of information that is needed to
   configure TSN over DetNet MPLS:

   *  TSN-related configuration information according to the TSN role of
      the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB], and
      [IEEEP8021CBdb].

   *  DetNet MPLS-related configuration information according to the
      DetNet role of the DetNet MPLS node, as per [RFC8964].

   *  App-flow identification information to map received TSN Stream(s)
      to the DetNet flow.  Parameters of TSN Stream identification are
      defined in [IEEE8021CB] and [IEEEP8021CBdb].

   This information MUST be provisioned per DetNet flow.

   Mappings between DetNet and TSN management and control planes are out
   of scope of the document.  Some of the challenges are highlighted
   below.

   MPLS DetNet edge nodes are a member of both the DetNet domain and the
   connected TSN network.  From the TSN network perspective, the MPLS
   (DetNet) edge node has a "TSN relay node" role, so TSN-specific
   management and control plane functionalities must be implemented.
   There are many similarities in the management plane techniques used
   in DetNet and TSN, but that is not the case for the control plane
   protocols.  For example, RSVP-TE and MSRP behave differently.
   Therefore, management and control plane design is an important aspect
   of scenarios where mapping between DetNet and TSN is required.

   Note that as the DetNet network is just a portion of the end-to-end
   TSN path (i.e., single hop from the Ethernet perspective), some
   parameters (e.g., delay) may differ significantly.  Since there is no
   interworking function, the bandwidth of the DetNet network is assumed
   to be set large enough to handle all TSN flows it will support.  At
   the egress of the DetNet domain, the MPLS headers are stripped, and
   the TSN flow continues on as a normal TSN flow.

   In order to use a DetNet network to interconnect TSN segments, TSN-
   specific information must be converted to DetNet-domain-specific
   information.  TSN Stream ID(s) and stream-related parameters/
   requirements must be converted to a DetNet flow ID and flow-related
   parameters/requirements.

   In some cases, it may be challenging to determine some information
   related to the egress-node.  For example, it may be not trivial to
   locate the egress point/interface of a TSN Stream with a multicast
   destination MAC address.  Such scenarios may require interaction
   between control and management plane functions and between DetNet and
   TSN domains.

   Mapping between DetNet flow identifiers and TSN Stream identifiers,
   if not provided explicitly, can be done by the service proxy function
   of an MPLS (DetNet) edge node locally based on information provided
   for the configuration of the TSN Stream identification functions
   (e.g., Mask-and-Match Stream identification).

   Triggering the setup/modification of a DetNet flow in the DetNet
   network is an example where management and/or control plane
   interactions are required between the DetNet and the TSN network.

   Configuration of TSN-specific functions (e.g., FRER) inside the TSN
   network is a TSN-domain-specific decision and may not be visible in
   the DetNet domain.  Service protection interworking scenarios are
   left for further study.

7.  Security Considerations

   Security considerations for DetNet are described in detail in
   [DETNET-SEC].  General security considerations are described in
   [RFC8655].

   Considerations specific to the DetNet MPLS data plane are summarized
   and described in [RFC8964], including any application flow types.
   This document focuses on a scenario where TSN Streams are the
   application flows for DetNet, which is already covered by those
   DetNet MPLS data plane security considerations.

8.  IANA Considerations

   This document has no IANA actions.

9.  References

9.1.  Normative References

   [IEEE8021CB]
              IEEE, "Standard for Local and metropolitan area networks
              -- Frame Replication and Elimination for Reliability",
              IEEE 802.1CB-2017, DOI 10.1109/IEEESTD.2017.8091139,
              October 2017,
              <https://ieeexplore.ieee.org/document/8091139>.

   [IEEEP8021CBdb]
              IEEE, "Draft Standard for Local and metropolitan area
              networks - Frame Replication and Elimination for
              Reliability - Amendment: Extended Stream Identification
              Functions", IEEE P802.1CBdb D1.3, April 2021,
              <https://1.ieee802.org/tsn/802-1cbdb>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8938]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane
              Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
              <https://www.rfc-editor.org/info/rfc8938>.

   [RFC8964]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
              S., and J. Korhonen, "Deterministic Networking (DetNet)
              Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
              2021, <https://www.rfc-editor.org/info/rfc8964>.

9.2.  Informative References

   [DETNET-SEC]
              Grossman, E., Ed., Mizrahi, T., and A. Hacker,
              "Deterministic Networking (DetNet) Security
              Considerations", Work in Progress, Internet-Draft, draft-
              ietf-detnet-security-16, 2 March 2021,
              <https://tools.ietf.org/html/draft-ietf-detnet-security-
              16>.

   [IEEE8021Q]
              IEEE, "Standard for Local and Metropolitan Area Networks--
              Bridges and Bridged Networks", IEEE Std. 802.1Q-2018,
              DOI 10.1109/IEEESTD.2018.8403927, July 2018,
              <https://ieeexplore.ieee.org/document/8403927>.

   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, March 2005,
              <https://www.rfc-editor.org/info/rfc3985>.

Acknowledgements

   The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
   Christophe Mangin, and Jouni Korhonen for their various contributions
   to this work.

Authors' Addresses

   Balázs Varga (editor)
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary

   Email: balazs.a.varga@ericsson.com


   János Farkas
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary

   Email: janos.farkas@ericsson.com


   Andrew G. Malis
   Malis Consulting

   Email: agmalis@gmail.com


   Stewart Bryant
   Futurewei Technologies

   Email: sb@stewartbryant.com


   Don Fedyk
   LabN Consulting, L.L.C.

   Email: dfedyk@labn.net