[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

DetNet                                                     B. Varga, Ed.
Internet-Draft                                                 J. Farkas
Intended status: Standards Track                                Ericsson
Expires: September 7, 2020                                      A. Malis
                                                             Independent
                                                               S. Bryant
                                                  Futurewei Technologies
                                                                D. Fedyk
                                                 LabN Consulting, L.L.C.
                                                           March 6, 2020


   DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
                 draft-ietf-detnet-tsn-vpn-over-mpls-02

Abstract

   This document specifies the Deterministic Networking data plane when
   TSN networks are interconnected over a DetNet MPLS Network.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 7, 2020.

Copyright Notice

   Copyright (c) 2020 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



Varga, et al.           Expires September 7, 2020               [Page 1]


Internet-Draft            TSN over DetNet MPLS                March 2020


   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms Used in This Document . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . .   4
   4.  DetNet MPLS Data Plane  . . . . . . . . . . . . . . . . . . .   6
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  TSN over DetNet MPLS Encapsulation  . . . . . . . . . . .   7
   5.  TSN over MPLS Data Plane Procedures . . . . . . . . . . . . .   8
     5.1.  Edge Node TSN Procedures  . . . . . . . . . . . . . . . .   8
     5.2.  Edge Node DetNet Service Proxy Procedures . . . . . . . .   9
     5.3.  Edge Node DetNet Service and Forwarding Sub-Layer
           Procedures  . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Controller Plane (Management and Control) Considerations  . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1
   Working Group deals with deterministic services through IEEE 802
   networks.  Deterministic Networking (DetNet) defined by IETF is a
   service that can be offered by a 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.  DetNet MPLS data plane is
   defined in [I-D.ietf-detnet-mpls].











Varga, et al.           Expires September 7, 2020               [Page 2]


Internet-Draft            TSN over DetNet MPLS                March 2020


2.  Terminology

2.1.  Terms Used in This Document

   This document uses the terminology and concepts established in the
   DetNet architecture [RFC8655] and
   [I-D.ietf-detnet-data-plane-framework], and [I-D.ietf-detnet-mpls].
   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.

   CW            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.

   LSR           Label Switching Router.

   MPLS          Multiprotocol Label Switching.

   MPLS-TE       Multiprotocol Label Switching - Traffic Engineering.

   MPLS-TP       Multiprotocol Label Switching - Transport Profile.

   NSP           Native Service Processing.

   OAM           Operations, Administration, and Maintenance.

   PE            Provider Edge.

   PREOF         Packet Replication, Elimination and Ordering Functions.



Varga, et al.           Expires September 7, 2020               [Page 3]


Internet-Draft            TSN over DetNet MPLS                March 2020


   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 pseudowire (PW) Terminating
   Provider Edge (T-PE) nodes which use MPLS-TE LSPs.  In this example
   TSN Streams are simple applicaions over DetNet flows.  The specific
   of this operation are discussed later in this document.
























Varga, et al.           Expires September 7, 2020               [Page 4]


Internet-Draft            TSN over DetNet MPLS                March 2020


      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 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.












Varga, et al.           Expires September 7, 2020               [Page 5]


Internet-Draft            TSN over DetNet MPLS                March 2020


        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


                    Figure 2: IEEE 802.1TSN Over DetNet

4.  DetNet MPLS Data Plane

4.1.  Overview

   The basic approach defined in [I-D.ietf-detnet-mpls] supports the
   DetNet service sub-layer based on existing pseudowire (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 which has the S-Label as top
   of stack uses the local context associated with that S-Label, for
   example a received F-Label, to determine what local DetNet
   operation(s) are 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.




Varga, et al.           Expires September 7, 2020               [Page 6]


Internet-Draft            TSN over DetNet MPLS                March 2020


   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 enabled
   DetNet nodes can enhance the reliability of delivery by enabling the
   replication of packets where multiple copies, possibly over multiple
   paths, are forwarded through the DetNet domain.  They can also
   eliminate surplus previously replicated copies of DetNet packets.
   MPLS (DetNet) nodes also include DetNet forwarding sub-layer
   functions, support for notably explicit routes, and resources
   allocation to eliminate (or reduce) congestion loss and jitter.

   DetNet transit nodes reside wholly within a DetNet domain, and also
   provide DetNet forwarding sub-layer functions in accordance with the
   performance required by a DetNet flow carried over an LSP.  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
   shown in Figure 3.


                /->     +------+  +------+  +------+   TSN      ^ ^
                |       |  X   |  |  X   |  |  X   |<- Appli    : :
     App-Flow <-+       +------+  +------+  +------+   cation   : :(1)
      for MPLS  |       |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: Example TSN over MPLS Encapsulation Formats



Varga, et al.           Expires September 7, 2020               [Page 7]


Internet-Draft            TSN over DetNet MPLS                March 2020


   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 [I-D.ietf-detnet-mpls].  A single DetNet MPLS flow
   can aggregate multiple TSN Streams.

5.  TSN over MPLS Data Plane Procedures

   Description of Edge Nodes procedures and functions for TSN over
   DetNet MPLS scenario follows the concept of [RFC3985] and covers the
   Edge Nodes components shown on Figure 1.  In this section the
   following procedures of DetNet Edge Nodes are described:

   o  TSN related (Section 5.1)

   o  DetNet Service Proxy (Section 5.2)

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

   The sub-sections 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 Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
   Working Group have defined (and are defining) a number of amendments
   to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and
   bounded latency in bridged networks.  IEEE 802.1CB [IEEE8021CB]
   defines packet replication and elimination functions for a TSN
   network.

   TSN specific functions are executed on the data received by the
   DetNet Edge Node from the connected CE before forwarded to connected
   CE(s) or presentation to the DetNet Service Proxy function for
   transmission across the DetNet domain, or on the data received from a
   DetNet PW by a PE before it is output on the Attachment Circuit(s)
   (AC).

   TSN specific function(s) of Edge Nodes (T-PE) are belonging to the
   native service processing (NSP) [RFC3985] block.  This is similar to
   other functionalities being defined by standard bodies other than the
   IETF (for example in 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 must be
   supported.





Varga, et al.           Expires September 7, 2020               [Page 8]


Internet-Draft            TSN over DetNet MPLS                March 2020


   When a PE receives a packet from a CE, on a given AC with DetNet
   service, it MUST first check via Stream Identification whether the
   packet belongs to a configured TSN Stream (i.e., App-flow from DetNet
   perspective).  If no Stream ID is matched and no other (VPN) service
   is configured for the AC then packet MUST be dropped.  If there is a
   matching TSN Stream then the Stream-ID specific TSN functions MUST be
   executed (e.g., ingress policing, 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 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) required).  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 MUST first check via Stream Identification whether the
   packet belongs to a configured TSN Stream.  If no Stream ID is
   matched then packet MUST be dropped.  If there is a matching TSN
   Stream then the Stream ID specific TSN functions MUST be 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 MUST be forwarded
   according to the TSN Stream specific configuration to connected
   CE(s).  If there are no TSN Stream specific forwarding configurations
   the PE MUST flood the packet to locally attached CE(s).  If the
   administrative policy on the PE does not allow flooding the PE MUST
   drop 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 and the related managed objects as defined
   in IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb] to
   recognize the App-flow related packets.  The Service Proxy presents
   TSN Streams as an App-flow to a DetNet Flow.




Varga, et al.           Expires September 7, 2020               [Page 9]


Internet-Draft            TSN over DetNet MPLS                March 2020


   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 matching statement is present 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 provide proper 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 MAY require to copy sequence number fields
   from TSN (L2) to PW (MPLS) encapsulation.  However, such interworking
   is out-of-scope in this document and left for further study.

   A MPLS DetNet flow is configured to carry any number of TSN flows.
   The DetNet flow specific bandwidth profile SHOULD match the required
   bandwidth of the App-flow aggregate.

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

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

   PREOF functions and the provided service recovery is 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 node terminates all related information elements
   encoded in the MPLS labels.

   The LSP used to forward the DetNet packet may be of any type (MPLS-
   LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR [RFC8660]).  The LSP




Varga, et al.           Expires September 7, 2020              [Page 10]


Internet-Draft            TSN over DetNet MPLS                March 2020


   (F-Label) label and/or the S-Label may be used to indicate the queue
   processing as well as the forwarding parameters.

   When a PE receives a packet from the Service Proxy function it MUST
   add to the packet the DetNet flow-ID specific S-label and create a
   d-CW.  The PE MUST forward the packet according to the configured
   DetNet Service and Forwarding sub-layer rules to other PE nodes.

   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
   [I-D.ietf-detnet-mpls].

6.  Controller Plane (Management and Control) Considerations

   TSN Stream(s) to DetNet flow mapping related information are 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).

   MPLS DetNet Edge nodes are 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 behaves 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 Ethernet perspective), some
   parameters (e.g., delay) may differ significantly.  Since there is no
   interworking function the bandwidth of 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
   ones.  TSN Stream ID(s) and stream(s) related parameters/requirements




Varga, et al.           Expires September 7, 2020              [Page 11]


Internet-Draft            TSN over DetNet MPLS                March 2020


   must be converted to a DetNet flow-ID and flow related parameters/
   requirements.

   In some case it may be challenging to determine some egress node
   related information.  For example, it may be not trivial to locate
   the egress point/interface of a TSN Streams 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 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
   [I-D.ietf-detnet-security].  General security considerations are
   described in [RFC8655].  DetNet MPLS data plane specific
   considerations are summarized in [I-D.ietf-detnet-mpls].  The primary
   considerations for the data plane is to maintain integrity of data
   and delivery of the associated DetNet service traversing the DetNet
   network.  Application flows can be protected through whatever means
   is provided by the underlying technology.  For example, encryption
   may be used, such as that provided by IPSec [RFC4301] for IP flows
   and/or by an underlying sub-net using MACSec [IEEE802.1AE-2018] for
   IP over Ethernet (Layer-2) flows.

8.  IANA Considerations

   This document makes no IANA requests.

9.  Acknowledgements

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



Varga, et al.           Expires September 7, 2020              [Page 12]


Internet-Draft            TSN over DetNet MPLS                March 2020


10.  References

10.1.  Normative References

   [I-D.ietf-detnet-mpls]
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
              draft-ietf-detnet-mpls-05 (work in progress), February
              2020.

   [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>.

10.2.  Informative References

   [I-D.ietf-detnet-data-plane-framework]
              Varga, B., Farkas, J., Berger, L., Malis, A., and S.
              Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
              data-plane-framework-04 (work in progress), February 2020.

   [I-D.ietf-detnet-security]
              Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
              J., Austad, H., and N. Finn, "Deterministic Networking
              (DetNet) Security Considerations", draft-ietf-detnet-
              security-08 (work in progress), February 2020.

   [IEEE802.1AE-2018]
              IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
              Security (MACsec)", 2018,
              <https://ieeexplore.ieee.org/document/8585421>.

   [IEEE8021CB]
              Finn, N., "Draft Standard for Local and metropolitan area
              networks - Seamless Redundancy", IEEE P802.1CB
              /D2.1 P802.1CB, December 2015,
              <http://www.ieee802.org/1/files/private/cb-drafts/d2/802-
              1CB-d2-1.pdf>.



Varga, et al.           Expires September 7, 2020              [Page 13]


Internet-Draft            TSN over DetNet MPLS                March 2020


   [IEEE8021Q]
              IEEE 802.1, "Standard for Local and metropolitan area
              networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
              2014)", 2014, <http://standards.ieee.org/about/get/>.

   [IEEEP8021CBdb]
              Mangin, C., "Extended Stream identification functions",
              IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019,
              <http://www.ieee802.org/1/files/private/cb-drafts/d2/802-
              1CB-d2-1.pdf>.

   [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>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
              L., and L. Berger, "A Framework for MPLS in Transport
              Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
              <https://www.rfc-editor.org/info/rfc5921>.

   [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>.

   [RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing with the MPLS Data Plane", RFC 8660,
              DOI 10.17487/RFC8660, December 2019,
              <https://www.rfc-editor.org/info/rfc8660>.

Authors' Addresses

   Balazs Varga (editor)
   Ericsson
   Magyar Tudosok krt. 11.
   Budapest  1117
   Hungary

   Email: balazs.a.varga@ericsson.com






Varga, et al.           Expires September 7, 2020              [Page 14]


Internet-Draft            TSN over DetNet MPLS                March 2020


   Janos Farkas
   Ericsson
   Magyar Tudosok krt. 11.
   Budapest  1117
   Hungary

   Email: janos.farkas@ericsson.com


   Andrew G. Malis
   Independent

   Email: agmalis@gmail.com


   Stewart Bryant
   Futurewei Technologies

   Email: stewart.bryant@gmail.com


   Don Fedyk
   LabN Consulting, L.L.C.

   Email: dfedyk@labn.net


























Varga, et al.           Expires September 7, 2020              [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/