<?xml version="1.0" encoding="US-ASCII"?> encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3031 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY rfc3985 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3985.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-detnet-tsn-vpn-over-mpls-07" ipr="trust200902"
         submissionType="IETF"> submissionType="IETF" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" consensus="true" number="9024">

  <front>
    <title abbrev="TSN over DetNet MPLS">
    DetNet
    Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time Sensitive Time-Sensitive Networking over MPLS</title>
    <seriesInfo name="RFC" value="9024"/>
    <author role="editor" fullname="Bal&aacute;zs fullname="Balázs Varga" initials="B." surname="Varga">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Magyar Tudosok krt. 11.</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
        </postal>
        <email>balazs.a.varga@ericsson.com</email>
      </address>
    </author>
    <author fullname="J&aacute;nos fullname="János Farkas" initials="J." surname="Farkas">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Magyar Tudosok krt. 11.</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1117</code>
        </postal>
        <email>janos.farkas@ericsson.com</email>
      </address>
    </author>
    <author fullname="Andrew G. Malis" initials="A.G." initials="A." surname="Malis">
      <organization>Malis Consulting</organization>
      <address>
        <email>agmalis@gmail.com</email>
      </address>
    </author>
    <author fullname="Stewart Bryant" initials="S." surname="Bryant">
      <organization>Futurewei Technologies</organization>
      <address>
        <email>stewart.bryant@gmail.com</email>
        <email>sb@stewartbryant.com</email>
      </address>
    </author>
    <author fullname="Don Fedyk" initials="D." surname="Fedyk">
      <organization>LabN Consulting, L.L.C.</organization>
      <address>
        <email>dfedyk@labn.net</email>
      </address>
    </author>
    <date /> month="June" year="2021"/>
    <workgroup>DetNet</workgroup>

<keyword>interconnecting TSN networks</keyword>
    <abstract>
      <t>
     This document specifies the Deterministic Networking data plane
     when TSN Time-Sensitive Networking (TSN) networks are interconnected over a DetNet MPLS Network. network.
      </t>
    </abstract>

  </front>
  <middle>
    <section title="Introduction" anchor="sec_intro"> anchor="sec_intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        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 a an L3 network to DetNet flows.  General background and concepts
        of DetNet can be found in <xref target="RFC8655"/>. target="RFC8655" format="default"/>.
      </t>
      <t>
        This document specifies the use of a DetNet MPLS network to interconnect TSN
        nodes/network segments. The DetNet MPLS data plane is defined in
           <xref target="RFC8964"/>.
        <vspace blankLines="100" /> target="RFC8964" format="default"/>.
      </t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <section title="Terms numbered="true" toc="default">
        <name>Terms Used in This Document"> Document</name>
        <t>
        This document uses the terminology and concepts established in the DetNet
        architecture <xref target="RFC8655"/> and target="RFC8655" format="default"/>
        <xref target="RFC8938"/>, and target="RFC8938" format="default"/>
        <xref target="RFC8964"/>.  TSN specific target="RFC8964" format="default"/>.  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.
        </t>
      </section>
      <section title="Abbreviations"> numbered="true" toc="default">
        <name>Abbreviations</name>
        <t>
   The following abbreviations are used in this document:
   <list style="hanging" hangIndent="14">
    <t hangText="AC">Attachment Circuit.</t>
    <t hangText="CE">Customer Edge equipment.</t>
    <t hangText="d-CW">DetNet
        </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>AC</dt>
          <dd>Attachment Circuit</dd>
          <dt>CE</dt>
          <dd>Customer Edge equipment</dd>
          <dt>d-CW</dt>
          <dd>DetNet Control Word.</t>
    <t hangText="DetNet">Deterministic Networking.</t>
    <t hangText="DF">DetNet Flow.</t>
    <t hangText="FRER">Frame Word</dd>
          <dt>DetNet</dt>
          <dd>Deterministic Networking</dd>
          <dt>DF</dt>
          <dd>DetNet Flow</dd>
          <dt>FRER</dt>
          <dd>Frame Replication and Elimination for Redundancy
        (TSN function).</t>
    <t hangText="L2">Layer 2.</t>
    <t hangText="L2VPN">Layer function)</dd>
          <dt>L2</dt>
          <dd>Layer 2</dd>
          <dt>L2VPN</dt>
          <dd>Layer 2 Virtual Private Network.</t>
    <t hangText="L3">Layer 3.</t>
    <t hangText="LSR">Label Network</dd>
          <dt>L3</dt>
          <dd>Layer 3</dd>
          <dt>LSP</dt><dd>Label Switched Path</dd>
          <dt>LSR</dt>
          <dd>Label Switching Router.</t>
    <t hangText="MPLS">Multiprotocol Router</dd>
          <dt>MPLS</dt>
          <dd>Multiprotocol Label Switching.</t>
    <t hangText="MPLS-TE">Multiprotocol Switching</dd>
          <dt>MPLS-TE</dt>
          <dd>Multiprotocol Label Switching - Traffic Engineering.</t>
    <t hangText="NSP">Native Service Processing.</t>
    <t hangText="OAM">Operations, Engineering</dd>
          <dt>NSP</dt>
          <dd>Native Service Processing</dd>
          <dt>OAM</dt>
          <dd>Operations, Administration, and Maintenance.</t>
    <t hangText="PE">Provider Edge.</t>
    <t hangText="PREOF">Packet Maintenance</dd>
          <dt>PE</dt>
          <dd>Provider Edge</dd>
          <dt>PREOF</dt>
          <dd>Packet Replication, Elimination and Ordering Functions.</t>
    <t hangText="PW">PseudoWire.</t>
    <t hangText="S-PE">Switching Functions</dd>
          <dt>PW</dt>
          <dd>Pseudowire</dd>
          <dt>S-PE</dt>
          <dd>Switching Provider Edge.</t>
    <t hangText="T-PE">Terminating Edge</dd>
          <dt>T-PE</dt>
          <dd>Terminating Provider Edge.</t>
    <t hangText="TSN">Time-Sensitive Network.</t>
   </list>
  </t> Edge</dd>
          <dt>TSN</dt>
          <dd>Time-Sensitive Network</dd>
        </dl>
      </section>
      <section title="Requirements Language"> numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
    "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
    BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>

    </section>  <!-- end of terminology -->

<!-- =========================================== -->
<!--            TSN over DetNet MPLS             -->
<!-- =========================================== -->

<section title="IEEE anchor="sec_tsn_mpls_dt_dp_scen" numbered="true" toc="default">
      <name>IEEE 802.1 TSN Over over DetNet MPLS Data Plane Scenario"
             anchor="sec_tsn_mpls_dt_dp_scen"> Scenario</name>
      <t>
   <xref target="fig_tsn_mpls_detnet"/> target="fig_tsn_mpls_detnet" format="default"/> shows IEEE 802.1 TSN end
   stations operating over a TSN aware TSN-aware DetNet service running over an MPLS
   network.  DetNet Edge Nodes edge nodes sit at the boundary of a DetNet domain. They are
   responsible for mapping non-DetNet aware 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 PW
   T-PE nodes, which use MPLS-TE LSPs.  In this
   example
   example, TSN Streams are simple applications over DetNet flows.  The specific specifics
   of this operation are discussed later in this document.
      </t>
      <figure anchor="fig_tsn_mpls_detnet" align="center"
title="A anchor="fig_tsn_mpls_detnet">
        <name>A TSN over DetNet MPLS Enabled Network"> MPLS-Enabled Network</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
   TSN           Edge          Transit         Edge          TSN
End System       Node           Node           Node       End System
                (T-PE)         (LSR)          (T-PE)

+----------+                                             +----------+
|   TSN    | <---------End to End <-------- End-to-End TSN Service----------> 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   --------------------->|

]]></artwork>
      </figure>
      <t>
        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 Streams are treated as App-flows
		for DetNet. The whole DetNet domain behaves as a TSN relay node for
		the TSN streams. Streams. The service proxy behaves as a port of that TSN
		relay node.
      </t>
      <t>

   <xref target="fig_8021_detnet"/> target="fig_8021_detnet" format="default"/> illustrates how DetNet can provide services
   for IEEE 802.1 TSN end systems, CE1 and CE2, over a DetNet enabled DetNet-enabled MPLS
   network.  Edge nodes, nodes E1 and E2, 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, services and could
   leverage existing related solutions as discussed below.
      </t>
      <figure align="center" anchor="fig_8021_detnet"
  title="IEEE anchor="fig_8021_detnet">
        <name>IEEE 802.1TSN Over DetNet">
  <artwork><![CDATA[ over DetNet</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     TSN    |<------- End to End 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 over DetNet MPLS -------> <- TSN ->|
    |                                                          |
    |<-------- Time Sensitive Time-Sensitive Networking (TSN) Service ------->|

    X   = Service protection
    DFx = DetNet member flow x over a TE LSP
	AC  = Attachment Circuit
	Tnl = Tunnel
]]>
</artwork>
]]></artwork>
      </figure>
    </section>

<!-- ================================================= -->
<!--            DetNet MPLS data plane OVERVIEW        -->
<!-- ================================================= -->

 <section title="DetNet anchor="sec_dt_dp" numbered="true" toc="default">
      <name>DetNet MPLS Data Plane" anchor="sec_dt_dp"> Plane</name>
      <section title="Overview" anchor="sec_dt_dp_ov"> anchor="sec_dt_dp_ov" numbered="true" toc="default">
        <name>Overview</name>
        <t>
        The basic approach defined in <xref target="RFC8964"/> target="RFC8964" format="default"/>
        supports the DetNet service sub-layer based on existing pseudowire (PW) PW
        encapsulations and mechanisms, mechanisms and supports the DetNet forwarding
        sub-layer based on existing MPLS Traffic Engineering encapsulations
        and mechanisms.
        </t>
        <t>
        A node operating on a DetNet flow in the Detnet DetNet service sub-layer, i.e. i.e., a node processing a DetNet packet which that has the S-Label as top of stack stack,
        uses the local context associated with that S-Label, for example S-Label. For example, a received
        F-Label,
        F-Label can be used to determine what local DetNet operation(s) are is applied to that
        packet. An S-Label may be unique when taken from the platform
        label space <xref target="RFC3031"/>, target="RFC3031" format="default"/>, 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).
        </t>
        <t>
    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).
        </t>
        <t>
        DetNet edge/relay nodes are DetNet service sub-layer
        aware, understand the particular needs of DetNet flows flows, and
        provide both DetNet service and forwarding sub-layer functions.
        They add, remove remove, and process d-CWs, S-Labels S-Labels, and F-labels F-Labels as
        needed.  MPLS DetNet nodes and transit nodes include
        DetNet forwarding sub-layer functions, 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.
        </t>
      </section>
      <section anchor="tom-encap"
               title="TSN numbered="true" toc="default">
        <name>TSN over DetNet MPLS Encapsulation"> Encapsulation</name>
        <t>
        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
        <xref target="fig_tsn_mpls_ex"/>. Note, target="fig_tsn_mpls_ex" format="default"/>. Note that three example flows are
		shown in the figure.
        </t>
        <figure title="Examples anchor="fig_tsn_mpls_ex">
          <name>Examples of TSN over MPLS Encapsulation Formats"
              anchor="fig_tsn_mpls_ex"> Formats</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[

           /->     +------+  +------+  +------+   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
    ]]>
        </artwork>
        ]]></artwork>
        </figure>
        <t>
        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
        <xref target="RFC8964"/>. target="RFC8964" format="default"/>. A single DetNet MPLS flow
        can aggregate multiple TSN Streams.
        </t>
<aside>
        <t>
		Note: In order to avoid Network fragmentation (see section 5.3 of
		<xref target="RFC3985"/>), 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 has to make sure MUST ensure that all the DetNet encapsulation overhead plus the maximum TSN App-flow do frame size does not exceed the DetNet network's MTU.
 </t>
        </t></aside>
      </section>
    </section>  <!-- end of DetNet MPLS data plane overview -->

<!-- ================================================= -->
<!--            TSN over DetNet MPLS procedures        -->
<!-- ================================================= -->

 <section title="TSN anchor="tom_proc" numbered="true" toc="default">
      <name>TSN over MPLS Data Plane Procedures" anchor="tom_proc"> Procedures</name>
      <t>
        The description of Edge Nodes edge node procedures and functions for TSN over DetNet MPLS
        scenarios follows the concepts from <xref target="RFC3985"/>, target="RFC3985" format="default"/> and covers the
        Edge Nodes
        edge node components shown in <xref target="fig_tsn_mpls_detnet"/>. target="fig_tsn_mpls_detnet" format="default"/>. In
        this section section, the following procedures of DetNet Edge Nodes edge nodes are described:
        <list style="symbols">
                <t>
      </t>
      <ul spacing="normal">
        <li>
                        TSN related (<xref target="tom_tsn_proc"/>)
                </t><t> target="tom_tsn_proc" format="default"/>)
                </li>
        <li>
                        DetNet Service Proxy (<xref target="tom_svc_prx_proc"/>)
                </t><t> target="tom_svc_prx_proc" format="default"/>)
                </li>
        <li>
                        DetNet service and forwarding sub-layer (<xref target="tom_dn_sub_proc"/>)
                </t>
        </list>
  </t> target="tom_dn_sub_proc" format="default"/>)
                </li>
      </ul>
      <t>
		The sub-sections subsections describe procedures for forwarding packets by DetNet
		Edge
		edge nodes, where such packets are received from either directly
		connected CEs (TSN nodes) or some other DetNet Edge edge nodes.
      </t>
      <section title="Edge anchor="tom_tsn_proc" numbered="true" toc="default">
        <name>Edge Node TSN Procedures" anchor="tom_tsn_proc"> Procedures</name>
        <t>
        The Time-Sensitive Networking (TSN) Task Group TSN TG of the IEEE 802.1
                Working Group have has defined (and are is defining) a number of amendments
                to <xref target="IEEE8021Q"/> target="IEEE8021Q" format="default"/> that provide zero
                congestion loss and bounded latency in bridged networks.
        <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> defines packet
                replication and elimination functions for a TSN network.
        </t>
        <t>
		  	  The implementation of a TSN entity (i.e., TSN packet processing
			  functions) must be compliant with the relevant IEEE 802.1
			  standards.
        </t>
        <t>
                TSN specific
                TSN-specific functions are executed on the data received by
                the DetNet Edge Node edge node from the connected CE before being forwarded to
				connected CE(s) or presented to the DetNet Service Proxy service proxy function for
                transmission across the DetNet domain. TSN specific TSN-specific functions
				are also executed on the data received from a DetNet PW by a PE
				before the data is output on the Attachment Circuit(s) (AC). AC(s).
        </t>
        <t>
                The TSN packet processing function(s) of Edge Nodes edge nodes (T-PE) are belonging belongs to the
                native service processing (NSP)
                NSP <xref target="RFC3985"/> target="RFC3985" format="default"/>
                block. This is similar to other functionalities being defined by standard standards
                bodies other than the IETF (for example example, in the case of Ethernet: Ethernet, stripping,
                overwriting
                overwriting, or adding VLAN tags, etc.). Depending on the TSN role of
                the Edge Node edge node in the end-to-end TSN service service, selected TSN functions
                are supported.
        </t>
        <t>
			When a PE receives a packet from a CE, CE on a given AC with DetNet service,
			it first checks via Stream Identification identification
			(see Clause 6. 6 of <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> and
            <xref target="IEEEP8021CBdb"/>) target="IEEEP8021CBdb" format="default"/>)
			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 <bcp14>MUST</bcp14> be dropped. If there is a matching TSN
			Stream, then the Stream ID specific Stream-ID-specific TSN functions are executed
			(e.g., ingress policing, header field manipulation in the case
			of active Stream Identification, identification, FRER, etc.). Source MAC Media Access Control (MAC) lookup
			may also be used for local MAC address learning.
        </t>
        <t>
			If the PE decides to forward the packet, the packet MUST <bcp14>MUST</bcp14> be forwarded
			according to the TSN Stream specific TSN-Stream-specific configuration to connected CE(s)
			(in case of local bridging) and/or to the DetNet Service Proxy service proxy
			(in case of forwarding to remote CE(s)). If there are no
			TSN Stream specific
			TSN-Stream-specific forwarding configurations, the PE MUST <bcp14>MUST</bcp14> flood
			the packet to other locally attached CE(s) and to the DetNet Service
			Proxy. service
			proxy. If the administrative policy on the PE does not allow
			flooding, the PE MUST <bcp14>MUST</bcp14> drop the packet.
        </t>
        <t>
			When a TSN entity of the PE receives a packet from the DetNet
			Service Proxy,
			service proxy, it first checks via Stream Identification identification
			(see Clause 6. 6 of <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> and
            <xref target="IEEEP8021CBdb"/>) target="IEEEP8021CBdb" format="default"/>) 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 Stream-ID-specific TSN functions are executed
			(e.g., header field manipulation in case of active Stream
			Identification,
			identification, FRER, etc.). Source MAC lookup may also be used for
			local MAC address learning.
        </t>
        <t>
			If the PE decides to forward the packet, the packet is forwarded
			according to the TSN Stream specific TSN-Stream-specific configuration to connected CE(s).
			If there are no TSN Stream specific 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.
        </t>
        <t>
            Implementations of this document SHALL <bcp14>SHALL</bcp14> use management and
            control information to ensure TSN specific TSN-specific functions of the Edge Node edge node
            according to the expectations of the connected TSN network.
        </t>
      </section>
      <section title="Edge anchor="tom_svc_prx_proc" numbered="true" toc="default">
        <name>Edge Node DetNet Service Proxy Procedures" anchor="tom_svc_prx_proc"> Procedures</name>
        <t>
                The Service Proxy service proxy
                function maps between App-flows and DetNet flows.
				The DetNet Edge Node edge node TSN entity MUST <bcp14>MUST</bcp14> support the TSN Stream
                identification functions (as defined in Clause 6 of <xref target="IEEE8021CB" format="default"/> and <xref target="IEEEP8021CBdb" format="default"/>) and the related managed objects as (as
                defined in Clause 6. and Clause 9. 9 of <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> and <xref target="IEEEP8021CBdb"/> target="IEEEP8021CBdb" format="default"/>)	to
                recognize the App-flow packets related packets. to App-flow.  The Service Proxy service proxy
                presents TSN Streams as an App-flow to a DetNet Flow. flow.
        </t>
        <t>
			When a DetNet Service Proxy service proxy receives a packet from the TSN Entity entity,
			it MUST <bcp14>MUST</bcp14> check whether such an App-flow is present in its mapping table.
			If present present, it associates the internal DetNet flow-ID flow ID to the packet and
			MUST
			<bcp14>MUST</bcp14> forward it to the DetNet Service service and Forwarding forwarding sub-layers. If
			no match is found found, it MUST <bcp14>MUST</bcp14> drop the packet.
        </t>
        <t>
			When a DetNet Service Proxy service proxy receives a packet from the DetNet Service service
			and Forwarding sub-layers forwarding sub-layers, it MUST <bcp14>MUST</bcp14> be forwarded to the Edge Node edge node
			TSN Entity. entity.
        </t>
        <t>
                Implementations of this document SHALL <bcp14>SHALL</bcp14> 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 <bcp14>SHALL</bcp14> be supported. The management or control
                function that provisions flow mapping SHALL <bcp14>SHALL</bcp14> ensure that
                adequate resources are allocated and configured to
                fulfil
                fulfill the service requirements of the mapped flows.
        </t>
        <t>
                Due to the (intentional) similarities of the DetNet PREOF and
                TSN FRER functions functions, service protection function interworking is
                possible between the TSN and the DetNet domains. Such service
                protection interworking scenarios might require to copy copying of sequence
                number fields from TSN (L2) to PW (MPLS) encapsulation.
                However, such interworking is out-of-scope out of scope in this document and
                is left for further study.
        </t>
      </section>
      <section title="Edge anchor="tom_dn_sub_proc" numbered="true" toc="default">
        <name>Edge Node DetNet Service and Forwarding Sub-Layer Procedures" anchor="tom_dn_sub_proc"> Procedures</name>
        <t>
                In the design of presented in <xref target="RFC8964"/> target="RFC8964" format="default"/>, an MPLS service
                label (the S-Label), similar to a pseudowire (PW) PW label
                <xref target="RFC3985"/>, target="RFC3985" format="default"/>, 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) d-CW, which carries the
                Data/OAM discriminator as well. In
                <xref target="RFC8964"/> target="RFC8964" format="default"/>, two sequence number sizes
                are supported: a 16 bit 16-bit sequence number and a 28 bit 28-bit sequence number.
        </t>
        <t>
                PREOF functions and the provided service recovery is are available
                only within the DetNet domain as the DetNet flow-ID flow ID and the DetNet
                sequence number are not valid outside the DetNet network.  MPLS
                (DetNet) Edge edge nodes terminate all related information elements
                encoded in the MPLS labels.
        </t>
        <t>
			When a PE receives a packet from the Service Proxy function service proxy function, it MUST <bcp14>MUST</bcp14>
			handle the packet as defined in <xref target="RFC8964"/>. target="RFC8964" format="default"/>.
        </t>
        <t>
			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 S-Label that was advertised by this node, then the PE
			MUST
			<bcp14>MUST</bcp14> forward the packet according to the configured DetNet Service service and
			Forwarding
			forwarding sub-layer rules to other PE nodes or via the Detnet Service
			Proxy DetNet service
			proxy function towards locally connected CE(s).
        </t>
        <t>
                For further details on DetNet Service service and Forwarding sub-layers forwarding sub-layers,
				see <xref target="RFC8964"/>. target="RFC8964" format="default"/>.
        </t>
      </section>
    </section>  <!-- End of Procedures Section -->

<!-- ========================================================== -->
<!--          Management and Control Plane Considerations       -->
<!-- ========================================================== -->

 <section title="Controller anchor="cp_considerations" numbered="true" toc="default">
      <name>Controller Plane (Management and Control) Considerations" anchor="cp_considerations"> Considerations</name>
      <t>
        Information related to TSN Stream(s) to DetNet flow mapping related information are is
        required only for the service proxy function of MPLS (DetNet) Edge edge nodes.
        From the Data Plane perspective data plane perspective, there is no practical difference
		based on the origin of flow mapping related flow-mapping-related information	(management
		plane or control plane).
      </t>
      <t>
            The following summarizes the set of information that is needed to
            configure TSN over DetNet MPLS:
            <list style="symbols">
			  <t>TSN related
      </t>
      <ul spacing="normal">
        <li>TSN-related configuration information according to the
			     TSN role of the DetNet MPLS node, as per
				 <xref target="IEEE8021Q"/>, target="IEEE8021Q" format="default"/>, <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/>, and
			     <xref target="IEEEP8021CBdb"/>. </t>
			  <t>DetNet MPLS related target="IEEEP8021CBdb" format="default"/>. </li>
        <li>DetNet MPLS-related configuration information according to the
			     DetNet role of the DetNet MPLS node, as per
			     <xref target="RFC8964"/>. </t>
              <t>App-Flow target="RFC8964" format="default"/>. </li>
        <li>App-flow identification information to map received TSN
			  Stream(s) to the DetNet flow. Parameters of TSN stream Stream
			  identification are defined in <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> and
			  <xref target="IEEEP8021CBdb"/>. </t>
            </list> target="IEEEP8021CBdb" format="default"/>. </li>
      </ul>
      <t>
            This information MUST <bcp14>MUST</bcp14> be provisioned per DetNet flow.
      </t>
      <t>
			Mappings between DetNet and TSN management and control planes are
			out of scope of the document. Some of the challanges challenges are
			highligthed
			highlighted below.
      </t>
      <t>
        MPLS DetNet Edge edge nodes are a member of both the DetNet domain and the
        connected TSN network. From the TSN network perspective perspective, the MPLS
        (DetNet) Edge edge node has a "TSN relay node" role, so TSN specific 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 behave differently.
		Therefore
		Therefore, management and control plane design is an important aspect
		of scenarios, scenarios where mapping between DetNet and TSN is required.
      </t>
      <t>
        Note that, that as the DetNet network is just a portion of the end to end 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
        function, the bandwidth of the DetNet network is assumed to be set large enough to
        handle all TSN Flows flows it will support.  At the egress of the Detnet Domain DetNet domain, the MPLS
        headers are stripped stripped, and the TSN flow continues on as a normal TSN
        flow.
      </t>

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

      <t>
        In some case cases, it may be challenging to determine some egress node information related information. 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.
      </t>
      <t>
        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 edge node locally based on information
        provided for the configuration of the TSN Stream identification functions
        (e.g., Mask-and-Match Stream identification).
      </t>
      <t>
        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.
      </t>
      <t>
        Configuration of TSN specific TSN-specific functions (e.g., FRER)
        inside the TSN network is a TSN domain specific TSN-domain-specific decision
        and may not be visible in the DetNet domain. Service protection
        interworking scenarios are left for further study.
      </t>
    </section> <!-- End of Management and Control Plane COnsiderations -->

<section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
     Security considerations for DetNet are described in detail in <xref
             target="I-D.ietf-detnet-security"/>. target="I-D.ietf-detnet-security" format="default"/>. General security
     considerations are described in <xref
             target="RFC8655"/>. target="RFC8655" format="default"/>.
      </t>
      <t>
     Considerations specific to the DetNet MPLS data plane specific considerations are summarized and
	 described in <xref target="RFC8964"/> target="RFC8964" format="default"/>, including any
	 application flow types. This document focuses on the a scenario where TSN Streams are the application flows for DetNet and it DetNet, which is already covered
	 by those DetNet MPLS data plane security considerations.
      </t>
    </section>
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This document makes has no IANA requests.
  </t>
</section>

<section anchor="acks" title="Acknowledgements">
   <t>
    The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
	Christophe Mangin and Jouni Korhonen for their various contributions
	to this work. actions.
      </t>
    </section>
  </middle>
  <back>
  <references title="Normative References">
   &rfc2119;
   <?rfc include="reference.RFC.3031"?>
   <?rfc include="reference.RFC.8174"?>
   <?rfc include="reference.RFC.8655"?>
   <?rfc include="reference.RFC.8938"?>
   <?rfc include="reference.RFC.8964"?>
<displayreference target="I-D.ietf-detnet-security" to="DETNET-SEC"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
        <reference anchor="IEEE8021CB"
                 target="http://standards.ieee.org/about/get/"> target="https://ieeexplore.ieee.org/document/8091139">
          <front>
            <title>Standard for Local and metropolitan area networks - -- Frame Replication and Elimination for Reliability
		  (IEEE Std 802.1CB-2017)</title> Reliability</title>
            <author>
            <organization>IEEE 802.1</organization>
              <organization>IEEE</organization>
            </author>
            <date month="October" year="2017"/>
          </front>
        <format type="PDF" target="http://standards.ieee.org/about/get/"/>
<seriesInfo name="IEEE" value="802.1CB-2017"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139"/>
        </reference>
        <reference anchor="IEEEP8021CBdb"
                 target="http://www.ieee802.org/1/files/private/db-drafts/d1/802-1CBdb-d1-0.pdf"> target=" https://1.ieee802.org/tsn/802-1cbdb">
          <front>
          <title>Extended
            <title>Draft Standard for Local and metropolitan area networks - Frame Replication and Elimination for Reliability - Amendment: Extended Stream identification functions</title>
          <author initials="C. M." surname="Mangin" fullname="Christophe Mangin">
            <organization>IEEE 802.1</organization> Identification Functions</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="September" year="2020"/> month="April" year="2021"/>
          </front>
          <seriesInfo name="IEEE P802.1CBdb /D1.0" value="P802.1CBdb"/>
        <format type="PDF" target="http://www.ieee802.org/1/files/private/db-drafts/d1/802-1CBdb-d1-0.pdf"/> P802.1CBdb" value="D1.3"/>
        </reference>
      </references>
  <references title="Informative References">
   &rfc3985;
      <?rfc include="reference.I-D.ietf-detnet-security"?>
<!--      <?rfc include="reference.RFC.4301"?> -->

<!--
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3985.xml"/>

<reference anchor="IEEE802.1AE-2018"
      target="https://ieeexplore.ieee.org/document/8585421"> anchor='I-D.ietf-detnet-security'>
<front>
        <title>IEEE Std 802.1AE-2018 MAC
<title>Deterministic Networking (DetNet) Security (MACsec)</title>
        <author>
          <organization>IEEE Standards Association</organization> Considerations</title>

<author initials='E' surname='Grossman' fullname='Ethan Grossman' role="editor">
    <organization />
</author>

<author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'>
    <organization />
</author>

<author initials='A' surname='Hacker' fullname='Andrew Hacker'>
    <organization />
</author>

<date year="2018" month='March' day='2' year='2021' />

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-detnet-security-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-detnet-security.txt' />
</reference>  -->

      <reference anchor="IEEE8021Q"
                 target="http://standards.ieee.org/about/get/"> target="https://ieeexplore.ieee.org/document/8403927">
          <front>
            <title>Standard for Local and metropolitan area networks--Bridges Metropolitan Area Networks--Bridges
          and Bridged Networks (IEEE Std 802.1Q-2018)</title> Networks</title>
            <author>
            <organization>IEEE 802.1</organization>
              <organization>IEEE</organization>
            </author>
            <date year="2018"/> year="2018" month="July"/>
          </front>
        <format type="PDF" target="http://standards.ieee.org/about/get/"/>
<seriesInfo name="IEEE Std." value="802.1Q-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>

        </reference>
      </references>
    </references>
    <section anchor="acks" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
    The authors wish to thank <contact fullname="Norman Finn"/>, <contact fullname="Lou Berger"/>, <contact fullname="Craig Gunther"/>,
	<contact fullname="Christophe Mangin"/>, and <contact fullname="Jouni Korhonen"/> for their various contributions
	to this work.
      </t>
    </section>
  </back>
</rfc>