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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?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 category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-detnet-ip-over-tsn-07" number="9023" ipr="trust200902"
     submissionType="IETF"> submissionType="IETF" category="info" consensus="true"
obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
version="3">

  <front>
    <title abbrev="DetNet IP over TSN">
    DetNet
    Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time Sensitive Time-Sensitive Networking (TSN)</title>
    <seriesInfo name="RFC" value="9023"/>
    <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>
    <date year="2021" month="June" />
    <workgroup>DetNet</workgroup>

<keyword>sub-network</keyword>
<keyword>flow mapping</keyword>

    <abstract>
      <t>
     This document specifies the Deterministic Networking IP data plane when
     operating over a TSN Time-Sensitive Networking (TSN) sub-network. This
     document does not define new procedures or processes.  Whenever this
     document makes statements or recommendations, these are taken from
     normative text in the referenced RFCs.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sec_intro"> anchor="sec_intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows.
        DetNet provides these flows extremely low packet loss packet-loss rates and assured maximum end-to-end
        delivery latency.  General background and concepts of DetNet can
        be found in the DetNet Architecture <xref target="RFC8655"/>. target="RFC8655" format="default"/>.
      </t>
      <t>
        <xref target="RFC8939"/> target="RFC8939" format="default"/> specifies the DetNet data plane operation for IP
        hosts and routers that provide DetNet service to IP encapsulated IP-encapsulated
        data.  This document focuses on the scenario where DetNet IP nodes
		are interconnected by a TSN Time-Sensitive Networking (TSN) sub-network.
      </t>
      <t>
        The DetNet Architecture decomposes the DetNet related DetNet-related data plane
        functions into two sub-layers: a service sub-layer and a forwarding
        sub-layer.  The service sub-layer is used to provide DetNet service
        protection and reordering. The forwarding sub-layer is used to
        provides provide
        congestion protection (low loss, assured latency, and limited
        reordering). As described in <xref target="RFC8939"/> target="RFC8939"
        format="default"/>, no DetNet specific DetNet-specific headers are added to support
        DetNet IP flows. So, only the forwarding sub-layer functions can be
        supported inside the DetNet IP domain.

Service protection can be
        provided on a per sub-network per-sub-network basis as shown here for the IEEE802.1 IEEE 802.1
        TSN sub-network scenario.
      </t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <section title="Terms numbered="true" toc="default">
        <name>Terms Used In in This Document"> Document</name>
        <t>
          This document uses the terminology and concepts established in the
          DetNet architecture Architecture <xref
          target="RFC8655"/>.  TSN (Time-Sensitive Networking) specific target="RFC8655" format="default"/>.
          TSN-specific terms are defined in by the TSN TG Task Group 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="DetNet">Deterministic Networking.</t>
			<t hangText="FRER">Frame
        </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>DetNet</dt>
          <dd>Deterministic Networking</dd>
          <dt>FRER</dt>
          <dd>Frame Replication and Elimination for Redundancy (TSN function).</t>
            <t hangText="L2">Layer-2.</t>
            <t hangText="L3">Layer-3.</t>
            <t hangText="TSN">Time-Sensitive Networking,
          function)</dd>
          <dt>L2</dt>
          <dd>Layer 2</dd>
          <dt>L3</dt>
          <dd>Layer 3</dd>
          <dt>TSN</dt>
          <dd>Time-Sensitive Networking; TSN is a Task Group of the IEEE
            802.1 Working Group.</t>
          </list>
        </t>
      </section>

<!--	  <section title="Requirements Language">
      <t>
        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 <xref target="RFC2119"/> <xref
        target="RFC8174"/> when, and only when, they appear in all
        capitals, as shown here.
      </t> Group.</dd>
        </dl>
      </section> -->

</section>
    <section title="DetNet anchor="sec_dt_dp" numbered="true" toc="default">
      <name>DetNet IP Data Plane Overview" anchor="sec_dt_dp"> Overview</name>
      <t>
        <xref target="RFC8939"/> target="RFC8939" format="default"/> describes how IP is used by
        DetNet nodes, i.e., hosts and routers, to identify DetNet flows and
        provide a DetNet service. From a data plane perspective, an end-to-end
        IP model is followed.  DetNet uses "6-tuple" based flow identification, identification based on
        a "6-tuple", where "6-tuple" refers to information carried in IP IP- and higher layer
        higher-layer protocol headers as defined in <xref target="RFC8939"/>.
. target="RFC8939"
        format="default"/>.
      </t>
      <t>
        DetNet flow aggregation may be enabled via the use of
        wildcards, masks, prefixes prefixes, and ranges. IP tunnels may also be
        used to support flow aggregation. In these cases, it is
        expected that DetNet aware DetNet-aware intermediate nodes will provide
        DetNet service assurance on the aggregate through resource
        allocation and congestion control mechanisms.
      </t>
      <t>
        Congestion protection, latency control control, and the resource allocation
        (queuing, policing, and shaping) are supported using the underlying
        link / sub-net specific sub-net-specific mechanisms.  Service protections (packet
        replication
        (packet-replication and packet elimination packet-elimination functions) are not provided
        at the IP DetNet layer end-to-end end to end due to the lack of a unified
        end-to-end sequencing information that would be available for
        intermediate nodes.  However, such service protection can be provided on a
        per underlying L2 link and sub-network basis. per sub-network.

      </t>

      <t>
   DetNet routers ensure that DetNet service requirements are met per hop by
   allocating local resources, by both receive receiving and transmit, transmitting, and by
   mapping the service requirements of each flow to appropriate sub-network
   mechanisms. Such mappings are sub-network technology specific.  DetNet
   nodes interconnected by a TSN sub-network are the primary focus of this
   document. The mapping of DetNet IP flows to TSN streams Streams and TSN protection
   mechanisms are covered in <xref target="mapping-tsn"/>. target="mapping-tsn" format="default"/>.
      </t>
    </section>

    <!-- ===================================================================== -->

    <section anchor="mapping-tsn" title="DetNet numbered="true" toc="default">
      <name>DetNet IP Flows over an IEEE 802.1 TSN sub-network"> Sub-network</name>
      <t>
        This section covers how DetNet IP flows operate over an IEEE 802.1 TSN
        sub-network.  <xref target="fig_ip_detnet_to_tsn"/> target="fig_ip_detnet_to_tsn" format="default"/>
        illustrates such a
        scenario, scenario where two IP (DetNet) nodes are
        interconnected by a TSN sub-network.  Dotted lines around the Service
        components of the IP (DetNet) Nodes nodes indicate that they are DetNet
        service aware but do not perform any DetNet service sub-layer
        function.  Node-1 is single homed and Node-2 is dual-homed dual homed to the TSN
		sub-network
        sub-network, and they are treated as Talker or Listener inside the TSN
        sub-network. Note, Note that from the TSN perspective perspective, dual-homed
        characteristics of Talker or Listener nodes are transparent to the IP
        Layer.
      </t>
      <figure align="center" anchor="fig_ip_detnet_to_tsn"
              title="DetNet (DN) Enabled anchor="fig_ip_detnet_to_tsn">

        <name>DetNet-Enabled IP Network over a TSN sub-network">
<artwork><![CDATA[ Sub-network</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    IP (DetNet)                   IP (DetNet)
      Node-1                        Node-2

   ............                  ............
<--: Service  :-- DetNet flow ---: Service  :-->
   +----------+                  +----------+
   |Forwarding|                  |Forwarding|
   +--------.-+    <-TSN Str->   +-.-----.--+
             \      ,-------.     /     /
              +----[ TSN-Sub ]---+ TSN Sub-]---+     /
                   [ Network ]--------+
                    `-------'
<----------------- DetNet IP ----------------->
]]></artwork>
      </figure>
      <t>
        At the time of this writing,
		the Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
        Working Group have defined (and are defining) a number of
        amendments to <xref target="IEEE8021Q"/> target="IEEE8021Q" format="default"/> that
        provide zero congestion loss and bounded latency in bridged
        networks. Furthermore, <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/>
		defines frame replication and elimination
        functions for reliability that should prove both compatible with
        and useful to DetNet networks.  All these functions have to
        identify flows that require TSN treatment.
      </t>
      <t>
        TSN capabilities of the TSN sub-network are made available for IP
        (DetNet) flows via the protocol interworking function described in Annex C.5 of
        <xref target="IEEE8021CB"/>. target="IEEE8021CB" format="default"/>. For example,
        applied on the TSN edge port it can convert an ingress unicast
		IP (DetNet) flow to use a specific L2 multicast destination
		MAC
		Media Access Control (MAC) address and a VLAN, VLAN in order to forward the packet through a
		specific path inside the bridged network.
		A similar interworking function pair at the
		other end of the TSN sub-network would restore the packet to its
		original L2 destination MAC address and VLAN.
      </t>
      <t>
        Placement of TSN functions depends on the TSN capabilities of
        nodes. IP (DetNet) Nodes nodes may or may not support TSN functions. For a
        given TSN Stream (i.e., a mapped DetNet flow) flow), an IP (DetNet) node is
        treated as a Talker or a Listener inside the TSN sub-network.
      </t>
      <section title="Functions numbered="true" toc="default">
        <name>Functions for DetNet Flow to TSN Stream Mapping"> Mapping</name>
        <t>
              Mapping of a DetNet IP flow to a TSN Stream is provided via the
              combination of a passive and an active stream Stream identification
              function that operate at the frame level (Layer-2). (Layer 2). The passive stream
              Stream identification function is used to catch the 6-tuple of a
              DetNet IP flow flow, and the active stream Stream identification function is
              used to modify the Ethernet header according to the ID of the
              mapped TSN Stream.
        </t>
        <t>
			  Clause 6.7 of <xref target="IEEE8021CB"/> target="IEEE8021CB"
			  format="default"/> defines an IP Stream
			  identification function that can be used as a
			  passive function for IP DetNet flows using UDP or
			  TCP. Clause 6.8 of <xref target="IEEEP8021CBdb"/> target="IEEEP8021CBdb"
			  format="default"/> defines a Mask-and-Match Stream
			  identification function that can be used as a
			  passive function for any IP DetNet flows.
        </t>
        <t>
			  Clause 6.6 of <xref target="IEEE8021CB"/> target="IEEE8021CB"
			  format="default"/> defines an Active Destination MAC
			  and VLAN Stream identification function,
              what function that can
			  replace some Ethernet header fields namely fields: (1) the
			  destination MAC-address, MAC address, (2) the VLAN-ID VLAN-ID, and (3)
			  priority parameters with alternate
			  values. Replacement is provided for the frame passed
			  down the stack from the upper layers or up the stack
			  from the lower layers.
        </t>
        <t>
              Active Destination MAC and VLAN Stream identification can be
              used within a Talker to set flow identity or within a Listener to
              recover the original addressing information. It can be used also
              in a TSN bridge that is providing translation as a proxy service
              for an End System.
        </t>
      </section>
      <section title="TSN requirements numbered="true" toc="default">
        <name>TSN Requirements of IP DetNet nodes"> Nodes</name>
        <t>
              This section covers the required behavior of a TSN-aware DetNet
              node using a TSN sub-network. The implementation of TSN packet
			  processing
              packet-processing functions must be compliant with the relevant
              IEEE 802.1 standards.
        </t>
        <t>
              From the TSN sub-network perspective perspective, DetNet IP nodes are treated
              as a Talker or Listener, Listener that may be (1) TSN-unaware TSN unaware or (2) TSN-aware.
              TSN aware.
        </t>
        <t>
              In cases of TSN-unaware IP DetNet nodes nodes, the TSN relay nodes
              within the TSN sub-network must modify the Ethernet
              encapsulation of the DetNet IP flow (e.g., MAC translation,
              VLAN-ID setting, Sequence sequence number addition, etc.) to allow proper TSN specific
              TSN-specific handling inside the sub-network.  There are no
              requirements defined for TSN-unaware IP DetNet nodes in this
              document.
        </t>
        <t>
              IP (DetNet) nodes being TSN-aware TSN aware can be treated as a
              combination of a TSN-unaware Talker/Listener and a TSN-Relay, TSN relay, as
              shown in <xref target="fig_ip_with_tsn"/>. target="fig_ip_with_tsn" format="default"/>.  In
              such cases cases, the IP (DetNet) node must provide the TSN sub-network specific
              sub-network-specific Ethernet encapsulation over the link(s)
              towards the sub-network.
        </t>
        <figure align="center" anchor="fig_ip_with_tsn"
                    title="IP anchor="fig_ip_with_tsn">
          <name>IP (DetNet) node Node with TSN functions">
              <artwork><![CDATA[ Functions</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
               IP (DetNet)
                  Node
   <---------------------------------->

   ............
<--: Service  :-- DetNet flow ------------------
   +----------+
   |Forwarding|
   +----------+    +---------------+
   |    L2    |    | L2 Relay with |<--- TSN ---
   |          |    | TSN function  |    Stream
   +-----.----+    +--.------.---.-+
          \__________/        \   \______
                               \_________
    TSN-unaware
     Talker /          TSN-Bridge          TSN Bridge
     Listener             Relay
                                       <----- TSN Sub-network -----
   <------- TSN-aware Tlk/Lstn ------->
]]></artwork>
        </figure>
        <t>
			  A TSN-aware IP (DetNet) node impementations implementation must
			  support the Stream Identification identification TSN component for
			  recognizing flows.
        </t>
        <t>
              A Stream identification component must be able to instantiate
              the following functions following: (1) Active Destination MAC and VLAN Stream identification function,
              identification, (2) IP Stream identification
              function, identification, (3) Mask-and-Match
              Stream identification function identification, and (4) the related managed objects in
              Clause 9 of <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> and
              <xref target="IEEEP8021CBdb"/>. target="IEEEP8021CBdb" format="default"/>.
        </t>

        <t>

			  A TSN-aware IP (DetNet) node implementation must support the
			  Sequencing function and the Sequence encode/decode function as
			  defined in Clause Clauses 7.4 and 7.6 of <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> if FRER
			  is used inside the TSN sub-network.
        </t>
        <t>
              The Sequence encode/decode function must support the Redundancy
              tag (R-TAG) format as per Clause 7.8 of <xref
              target="IEEE8021CB"/>. target="IEEE8021CB" format="default"/>.
        </t>
        <t>
			  A TSN-aware IP (DetNet) node implementations implementation must support the
			  Stream splitting
			  function and the Individual recovery function as defined in Clause Clauses 7.7 and 7.5 of
			  <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> when the node is
			  a replication or elimination point for FRER.
        </t>
      </section>
      <section title="Service protection numbered="true" toc="default">
        <name>Service Protection within the TSN sub-network"> Sub-network</name>
        <t>
              TSN Streams supporting DetNet flows may use Frame Replication
              and Elimination for Redundancy (FRER) FRER as defined in Clause 8. 8 of
			  <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/> based on the
              loss service requirements of the TSN Stream, which is derived
              from the DetNet service requirements of the DetNet mapped flow.
              The specific operation of FRER is not modified by the use of
              DetNet and follows <xref target="IEEE8021CB"/>. target="IEEE8021CB" format="default"/>.
        </t>
        <t>
              The FRER function and the provided service recovery is are available
              only within the TSN sub-network sub-network, as the TSN Stream-ID Stream ID and the TSN
              sequence number are not valid outside the sub-network.  An IP
              (DetNet) node represents a an L3 border and as such such, it terminates
              all related information elements encoded in the L2 frames.
        </t>
      </section>
      <section title="Aggregation numbered="true" toc="default">
        <name>Aggregation during DetNet flow Flow to TSN Stream mapping"> Mapping</name>
        <t>
			Implementations of this document shall use management
			and control information to map a DetNet flow to a TSN
			Stream. N:1 mapping (aggregating DetNet flows in a
			single TSN Stream) 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.
        </t>
      </section>
    </section>
    <section title="Management numbered="true" toc="default">
      <name>Management and Control Implications"> Implications</name>

      <t>
			DetNet flow flows and TSN Stream mapping related Stream-mapping-related information
			are required only for TSN-aware IP (DetNet)
			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 DetNet IP over TSN:
            <list style="symbols">
			  <t>DetNet IP related
      </t>
      <ul spacing="normal">
        <li>DetNet-IP-related configuration information according to the
        DetNet role of the DetNet IP node, as per <xref target="RFC8939"/>. </t>
			  <t>TSN related target="RFC8939"
        format="default"/>. </li>
        <li>TSN-related configuration information according to the TSN role of
        the DetNet IP node, as per <xref target="IEEE8021Q"/>, target="IEEE8021Q"
        format="default"/>, <xref target="IEEE8021CB"/> target="IEEE8021CB" format="default"/>, and
        <xref target="IEEEP8021CBdb"/>. </t>
              <t>Mapping target="IEEEP8021CBdb" format="default"/>. </li>
        <li>Mapping between DetNet IP flow(s) and TSN Stream(s). DetNet IP
        flow identification is summarized in Section 5.1 of <xref target="RFC8939"/>, target="RFC8939"
        sectionFormat="of" section="5.1"/> and includes all wildcards, port
			  ranges
        ranges, and the ability to ignore specific IP fields). For fields. Information on
        TSN
			  Streams stream Stream identification information are is defined in <xref target="IEEE8021CB"/>
        target="IEEE8021CB" format="default"/> and <xref target="IEEEP8021CBdb"/>).
			  Note,
        target="IEEEP8021CBdb" format="default"/>. Note that managed
        objects for TSN Stream identification can be found in <xref target="IEEEP8021CBcv"/>.
			  </t>
            </list>
        target="IEEEP8021CBcv" format="default"/>.
			  </li>
      </ul>
      <t>
            This information must be provisioned per DetNet flow.
      </t>
      <t>
			Mappings between DetNet and TSN management and control planes are
			out of scope of this document. Some of the challenges are
			highligthed
			highlighted below.
      </t>

      <t>
			TSN-aware IP DetNet nodes are members of both the
			DetNet domain and the TSN sub-network.  Within the TSN
			sub-network
			sub-network, the TSN-aware IP (DetNet) node has a
			TSN-aware Talker/Listener 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 the Multiple
			Stream Registration Protocol (MSRP) of IEEE 802.1 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>

 In order to use a TSN sub-network between DetNet nodes,
	      DetNet specific DetNet-specific
 information must be converted to TSN
	      sub-network specific ones. sub-network-specific information.

DetNet flow ID and flow related flow-related parameters/requirements must be converted to a
TSN Stream ID and stream related stream-related parameters/requirements. Note that, as the
TSN sub-network is just a portion of the end-to-end DetNet path (i.e., single
hop from an IP perspective), some parameters (e.g., delay) may differ
significantly. Other parameters (like bandwidth) also may have to be tuned due
to the L2 encapsulation used within the TSN sub-network.
      </t>
      <t>
	      In some cases cases, it may be challenging to determine some TSN
	      Stream related
	      Stream-related information. For example, on a TSN-aware IP
	      (DetNet) node that acts as a Talker, it is quite obvious which
	      DetNet node is the Listener of the mapped TSN stream Stream (i.e., the
	      IP Next-Hop). However next-hop). However, it may be not be trivial to locate the
	      point/interface where that Listener is connected to the TSN
	      sub-network. Such attributes 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 a
	      TSN-aware IP (DetNet) node locally based on information provided
	      for configuration of the TSN Stream identification functions (IP
	      Stream identification,
		  Mask-and-match Mask-and-Match Stream identification identification, and
	      the active Stream identification function).
      </t>
      <t>
	      Triggering the setup/modification of a TSN Stream in the
	      TSN sub-network is an example where management and/or
	      control plane interactions are required between the DetNet
	      and TSN sub-network. TSN-unaware IP (DetNet) nodes make
	      such a triggering even more complicated complicated, as they are fully
	      unaware of the sub-network and run independently.
      </t>
      <t>
	      Configuration of TSN specific TSN-specific functions (e.g., FRER)
	      inside the TSN sub-network is a TSN domain specific TSN-domain-specific decision
		  and may not be visible in the DetNet domain.
      </t>
    </section>

    <!-- ===================================================================== -->

    <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"/>.
	  Considerations specific to the DetNet IP data plane specific considerations are summarized in
	  <xref target="RFC8939"/>. target="RFC8939" format="default"/>.

   This section considers exclusively discusses security considerations which that are specific
   to the DetNet IP over TSN IP-over-TSN sub-network scenario.

      </t>
      <t>
	  The sub-network between DetNet nodes needs to be subject to
	  appropriate confidentiality. Additionally, knowledge of what
	  DetNet/TSN services are provided by a sub-network may supply
	  information that can be used in a variety of security attacks. The
	  ability to modify information exchanges between connected DetNet
	  nodes may result in bogus operations. Therefore, it is important
	  that the interface between DetNet nodes and the TSN sub-network are
	  subject to authorization, authentication, and encryption.
      </t>
      <t>
	  The TSN sub-network operates at Layer-2 Layer 2, so various security mechanisms
	  defined by IEEE can be used to secure the connection between the DetNet
	  nodes (e.g., encryption may be provided using MACSec MACsec
	  <xref target="IEEE802.1AE-2018"/>). target="IEEE802.1AE-2018" format="default"/>).
      </t>
    </section>
    <section anchor="iana" title="IANA Considerations">
      <t>
		None.
      </t>
    </section>

    <section anchor="acks" title="Acknowledgements"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
		The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
		Christophe Mangin and Jouni Korhonen for their various contributions
		to this work.
	This document has no IANA actions.
      </t>
    </section>

  </middle>
  <back>
    <references title="Normative references">
<!--      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.8174"?> -->
      <?rfc include="reference.RFC.8655"?>
      <?rfc include="reference.RFC.8939"?>

<displayreference target="I-D.ietf-detnet-security" to="DETNET-SECURITY"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <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.8939.xml"/>

      <reference anchor="IEEE8021CB"
                 target="http://standards.ieee.org/about/get/"> target="https://standards.ieee.org/standard/802_1CB-2017.html">
          <front>
          <title>Standard
            <title>IEEE Standard for Local and metropolitan area networks -
		  Frame
            networks--Frame Replication and Elimination for Reliability
		  (IEEE Std 802.1CB-2017)</title>
</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="DOI" value="10.1109/IEEESTD.2017.8091139" />
<refcontent>IEEE 802.1CB-2017</refcontent>
        </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
         <refcontent>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"/> / D1.3</refcontent>
</reference>

      </references>
    <references title="Informative references">
<!--      <?rfc include="reference.I-D.ietf-detnet-flow-information-model"?>  -->
      <?rfc include="reference.I-D.ietf-detnet-security"?>
      <references>
        <name>Informative References</name>

<reference anchor='I-D.ietf-detnet-security'>
<front>
<title>Deterministic Networking (DetNet) Security 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 month='March' year='2021' />

</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-detnet-security-16' />

</reference>

        <reference anchor="IEEE802.1AE-2018" target="https://ieeexplore.ieee.org/document/8585421">
          <front>
            <title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title> Standard for Local and metropolitan area networks--Media Access Control (MAC) Security</title>
            <author>
          <organization>IEEE Standards Association</organization>
              <organization>IEEE</organization>
            </author>
            <date year="2018" /> month="December" year="2018"/>
          </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421" />
<refcontent>IEEE 802.1AE-2018</refcontent>
        </reference>

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

 <reference anchor="IEEEP8021CBcv"
                 target="https://www.ieee802.org/1/files/private/cv-drafts/d0/802-1CBcv-d0-4.pdf"> target="https://1.ieee802.org/tsn/802-1cbcv/">
          <front>
          <title>FRER
            <title>Draft Standard for Local and metropolitan area networks--Frame Replication and
Elimination for Reliability--Amendment: Information Model, YANG Data Model and Management Information
Base Module</title>
          <author initials="S." surname="Kehrer" fullname="Stephan Kehrer">
            <author>
              <organization>IEEE 802.1</organization>
            </author>
            <date month="August" year="2020"/> month="February" year="2021"/>
          </front>
        <seriesInfo name="IEEE P802.1CBcv /D0.4" value="P802.1CBcv"/>
        <format type="PDF" target="https://www.ieee802.org/1/files/private/cv-drafts/d0/802-1CBcv-d0-4.pdf"/>
          <refcontent>IEEE P802.1CBcv, Draft 1.1</refcontent>
 </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>