Diff: rfc9023xml2.original.xml

	rfc9023xml2.original.xml	rfc9023.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	]>	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-detnet-ip-ov
	<?rfc symrefs="yes"?>	er-tsn-07" number="9023" ipr="trust200902" submissionType="IETF" category="info"
	<?rfc sortrefs="yes"?>	consensus="true"
	<?rfc iprnotified="no"?>	obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs=
	<?rfc strict="yes"?>	"true"
	<?rfc compact="yes"?>	version="3">
	<?rfc subcompact="no"?>
	<rfc category="info"
	docName="draft-ietf-detnet-ip-over-tsn-07"
	ipr="trust200902"
	submissionType="IETF">
	<front>	<front>
	<title abbrev="DetNet IP over TSN">	<title abbrev="DetNet IP over TSN">

	DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)</title	Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensit
	>	ive Networking (TSN)</title>
		<seriesInfo name="RFC" value="9023"/>
	<author role="editor" fullname="Balázs Varga" initials="B." surname="	<author role="editor" fullname="Balázs Varga" initials="B." surname="Varga">
	Varga">
	<organization>Ericsson</organization>	<organization>Ericsson</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Magyar Tudosok krt. 11.</street>	<street>Magyar Tudosok krt. 11.</street>
	<city>Budapest</city>	<city>Budapest</city>
	<country>Hungary</country>	<country>Hungary</country>
	<code>1117</code>	<code>1117</code>
	</postal>	</postal>
	<email>balazs.a.varga@ericsson.com</email>	<email>balazs.a.varga@ericsson.com</email>
	</address>	</address>
	</author>	</author>

		<author fullname="János Farkas" initials="J." surname="Farkas">
	<author fullname="János Farkas" initials="J." surname="Farkas">
	<organization>Ericsson</organization>	<organization>Ericsson</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Magyar Tudosok krt. 11.</street>	<street>Magyar Tudosok krt. 11.</street>
	<city>Budapest</city>	<city>Budapest</city>
	<country>Hungary</country>	<country>Hungary</country>
	<code>1117</code>	<code>1117</code>
	</postal>	</postal>
	<email>janos.farkas@ericsson.com</email>	<email>janos.farkas@ericsson.com</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Andrew G. Malis" initials="A." surname="Malis">
	<author fullname="Andrew G. Malis" initials="A.G." surname="Malis">
	<organization>Malis Consulting</organization>	<organization>Malis Consulting</organization>
	<address>	<address>
	<email>agmalis@gmail.com</email>	<email>agmalis@gmail.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Stewart Bryant" initials="S." surname="Bryant">	<author fullname="Stewart Bryant" initials="S." surname="Bryant">
	<organization>Futurewei Technologies</organization>	<organization>Futurewei Technologies</organization>
	<address>	<address>

	<email>stewart.bryant@gmail.com</email>	<email>sb@stewartbryant.com</email>
	</address>	</address>
	</author>	</author>

		<date year="2021" month="June" />
	<date />
	<workgroup>DetNet</workgroup>	<workgroup>DetNet</workgroup>


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

	<abstract>	<abstract>
	<t>	<t>

	This document specifies the Deterministic Networking IP data plane	This document specifies the Deterministic Networking IP data plane when
	when operating over a TSN sub-network. This document does not define	operating over a Time-Sensitive Networking (TSN) sub-network. This
	new procedures or processes. Whenever this document makes	document does not define new procedures or processes. Whenever this
	statements or recommendations, these are taken from normative text in th	document makes statements or recommendations, these are taken from
	e	normative text in the referenced RFCs.
	referenced RFCs.
	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

	<section title="Introduction" anchor="sec_intro">	<section anchor="sec_intro" numbered="true" toc="default">
		<name>Introduction</name>
	<t>	<t>
	Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows.	Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows.

	DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end	DetNet provides these flows extremely low packet-loss rates and assured maximum end-to-end
	delivery latency. General background and concepts of DetNet can	delivery latency. General background and concepts of DetNet can

	be found in the DetNet Architecture <xref target="RFC8655"/>.	be found in the DetNet Architecture <xref target="RFC8655" format="defau lt"/>.
	</t>	</t>
	<t>	<t>

	<xref target="RFC8939"/> specifies the DetNet data plane operation for I	<xref target="RFC8939" format="default"/> specifies the DetNet data plan
	P	e operation for IP
	hosts and routers that provide DetNet service to IP encapsulated	hosts and routers that provide DetNet service to IP-encapsulated
	data. This document focuses on the scenario where DetNet IP nodes	data. This document focuses on the scenario where DetNet IP nodes

	are interconnected by a TSN sub-network.	are interconnected by a Time-Sensitive Networking (TSN) sub-netwo rk.
	</t>	</t>
	<t>	<t>

	The DetNet Architecture decomposes the DetNet related data plane	The DetNet Architecture decomposes the DetNet-related data plane
	functions into two sub-layers: a service sub-layer and a forwarding	functions into two sub-layers: a service sub-layer and a forwarding
	sub-layer. The service sub-layer is used to provide DetNet service	sub-layer. The service sub-layer is used to provide DetNet service

	protection and reordering. The forwarding sub-layer is used to	protection and reordering. The forwarding sub-layer is used to provide
	provides congestion protection (low loss, assured latency, and	congestion protection (low loss, assured latency, and limited
	limited reordering). As described in <xref target="RFC8939"/>	reordering). As described in <xref target="RFC8939"
	no DetNet specific headers are added to	format="default"/>, no DetNet-specific headers are added to support
	support DetNet IP flows. So, only the forwarding sub-layer functions can	DetNet IP flows. So, only the forwarding sub-layer functions can be
	be	supported inside the DetNet IP domain.
	supported inside the DetNet IP domain. Service
	protection can be provided on a per sub-network	Service protection can be
	basis as shown here for the IEEE802.1 TSN sub-network scenario.	provided on a per-sub-network basis as shown here for the IEEE 802.1
		TSN sub-network scenario.
	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Terminology">	<name>Terminology</name>
		<section numbered="true" toc="default">
	<section title="Terms Used In This Document">	<name>Terms Used in This Document</name>
	<t>	<t>

	This document uses the terminology and concepts established in	This document uses the terminology and concepts established in the
	the DetNet architecture <xref	DetNet Architecture <xref target="RFC8655" format="default"/>.
	target="RFC8655"/>. TSN (Time-Sensitive Networking) specific terms ar	TSN-specific terms are defined by the TSN Task Group of the IEEE 802.1
	e defined in the TSN TG	Working
	of IEEE 802.1 Working Group. The reader is assumed	Group. The reader is assumed to be familiar with these documents
	to be familiar with these documents and their terminology.	and their terminology.
	</t>	</t>

	</section>


	<section title="Abbreviations">	</section>
		<section numbered="true" toc="default">
		<name>Abbreviations</name>
	<t>	<t>

	The following abbreviations used in this document:	The following abbreviations are used in this document:
	<list style="hanging" hangIndent="14">
	<t hangText="DetNet">Deterministic Networking.</t>
	<t hangText="FRER">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, TSN is a Task Group of
	the IEEE
	802.1 Working Group.</t>
	</list>
	</t>	</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)</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.</dd>
		</dl>
	</section>	</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>
	</section> -->
	</section>	</section>

		<section anchor="sec_dt_dp" numbered="true" toc="default">
	<section title="DetNet IP Data Plane Overview" anchor="sec_dt_dp">	<name>DetNet IP Data Plane Overview</name>
	<t>	<t>

	<xref target="RFC8939"/> describes how IP is used by DetNet	<xref target="RFC8939" format="default"/> describes how IP is used by
	nodes, i.e., hosts and routers, to identify DetNet flows and prov	DetNet nodes, i.e., hosts and routers, to identify DetNet flows and
	ide a	provide a DetNet service. From a data plane perspective, an end-to-end
	DetNet service. From a data plane perspective, an end-to-end IP m	IP model is followed. DetNet uses flow identification based on
	odel	a "6-tuple", where "6-tuple" refers to information carried in IP- and
	is followed. DetNet uses "6-tuple" based flow identification, where	higher-layer protocol headers as defined in <xref target="RFC8939"
	"6-tuple" refers to information carried in IP and higher layer pr	format="default"/>.
	otocol
	headers as defined in <xref target="RFC8939"/>.
	.
	</t>	</t>
	<t>	<t>
	DetNet flow aggregation may be enabled via the use of	DetNet flow aggregation may be enabled via the use of

	wildcards, masks, prefixes and ranges. IP tunnels may also be	wildcards, masks, prefixes, and ranges. IP tunnels may also be
	used to support flow aggregation. In these cases, it is	used to support flow aggregation. In these cases, it is

	expected that DetNet aware intermediate nodes will provide	expected that DetNet-aware intermediate nodes will provide
	DetNet service assurance on the aggregate through resource	DetNet service assurance on the aggregate through resource
	allocation and congestion control mechanisms.	allocation and congestion control mechanisms.
	</t>	</t>

	<t>
	Congestion protection, latency control and the resource allocation
	(queuing, policing, shaping) are supported using the underlying l
	ink
	/ sub-net specific mechanisms. Service protections (packet
	replication and packet elimination functions) are not provided at
	the IP DetNet layer end-to-end due to the lack of a unified end-t
	o-end
	sequencing information that would be available for intermediate n
	odes.
	However, such service protection can be provided on a per underly
	ing
	L2 link and sub-network basis.
	</t>
	<t>	<t>

	DetNet routers ensure that DetNet service requirements are met per ho	Congestion protection, latency control, and the resource allocation
	p	(queuing, policing, and shaping) are supported using the underlying
	by allocating local resources, both receive and transmit, and by	link / sub-net-specific mechanisms. Service protections
	mapping	(packet-replication and packet-elimination functions) are not provided
	the service requirements of each flow to appropriate sub-network	at the IP DetNet layer end to end due to the lack of unified
	mechanisms. Such mappings are sub-network technology specific.	end-to-end sequencing information that would be available for
	DetNet nodes interconnected by a TSN sub-network are the primary	intermediate nodes. However, such service protection can be provided
	focus	per underlying L2 link and per sub-network.
	of this document.
	The mapping of DetNet IP flows to TSN streams and TSN protection
	mechanisms are covered in <xref target="mapping-tsn"/>.
	</t>	</t>


		<t>
		DetNet routers ensure that DetNet service requirements are met per hop by
		allocating local resources, by both receiving and 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 and TSN protection
		mechanisms are covered in <xref target="mapping-tsn" format="default"/>.
		</t>
	</section>	</section>


	<!-- ===================================================================== -	<section anchor="mapping-tsn" numbered="true" toc="default">
	->	<name>DetNet IP Flows over an IEEE 802.1 TSN Sub-network</name>

	<section anchor="mapping-tsn" title="DetNet IP Flows over an IEEE 802.1
	TSN sub-network">
	<t>	<t>
	This section covers how DetNet IP flows operate over an IEEE 802.1 TSN	This section covers how DetNet IP flows operate over an IEEE 802.1 TSN

	sub-network. <xref target="fig_ip_detnet_to_tsn"/> illustrates such a	sub-network. <xref target="fig_ip_detnet_to_tsn" format="default"/>
	scenario, where two IP (DetNet) nodes are interconnected by a TSN	illustrates such a scenario where two IP (DetNet) nodes are
	sub-network.	interconnected by a TSN sub-network. Dotted lines around the Service
	Dotted lines around the Service components of the IP (DetNet) Nod	components of the IP (DetNet) nodes indicate that they are DetNet
	es	service aware but do not perform any DetNet service sub-layer
	indicate that they are DetNet service aware but do not perform an	function. Node-1 is single homed and Node-2 is dual homed to the TSN
	y	sub-network, and they are treated as Talker or Listener inside the TSN
	DetNet service sub-layer function.	sub-network. Note that from the TSN perspective, dual-homed
	Node-1 is single homed and Node-2 is dual-homed to the TSN	characteristics of Talker or Listener nodes are transparent to the IP
	sub-network and they are treated as Talker or Listener inside	Layer.
	the TSN sub-network. Note, that from TSN perspective dual-homed
	characteristics of Talker or Listener nodes are transparent to
	the IP Layer.
	</t>	</t>

		<figure anchor="fig_ip_detnet_to_tsn">


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

	............ ............	............ ............
	<--: Service :-- DetNet flow ---: Service :-->	<--: Service :-- DetNet flow ---: Service :-->
	+----------+ +----------+	+----------+ +----------+
	\|Forwarding\| \|Forwarding\|	\|Forwarding\| \|Forwarding\|
	+--------.-+ <-TSN Str-> +-.-----.--+	+--------.-+ <-TSN Str-> +-.-----.--+
	\ ,-------. / /	\ ,-------. / /

	+----[ TSN-Sub ]---+ /	+----[ TSN Sub-]---+ /
	[ Network ]--------+	[ Network ]--------+
	`-------'	`-------'
	<----------------- DetNet IP ----------------->	<----------------- DetNet IP ----------------->
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>	<t>
	At the time of this writing,	At the time of this writing,
	the Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1	the Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
	Working Group have defined (and are defining) a number of	Working Group have defined (and are defining) a number of

	amendments to <xref target="IEEE8021Q"/> that	amendments to <xref target="IEEE8021Q" format="default"/> that
	provide zero congestion loss and bounded latency in bridged	provide zero congestion loss and bounded latency in bridged

	networks. Furthermore, <xref target="IEEE8021CB"/>	networks. Furthermore, <xref target="IEEE8021CB" format="default"/>
	defines frame replication and elimination	defines frame replication and elimination
	functions for reliability that should prove both compatible with	functions for reliability that should prove both compatible with
	and useful to DetNet networks. All these functions have to	and useful to DetNet networks. All these functions have to
	identify flows that require TSN treatment.	identify flows that require TSN treatment.

	</t>	</t>
	<t>	<t>
	TSN capabilities of the TSN sub-network are made available for IP	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	(DetNet) flows via the protocol interworking function described in Annex C.5 of

	<xref target="IEEE8021CB"/>. For example,	<xref target="IEEE8021CB" format="default"/>. For example,
	applied on the TSN edge port it can convert an ingress unicast	applied on the TSN edge port it can convert an ingress unicast
	IP (DetNet) flow to use a specific L2 multicast destination	IP (DetNet) flow to use a specific L2 multicast destination

	MAC address and a VLAN, in order to forward the packet through a	Media Access Control (MAC) address and a VLAN in order to forward the packet through a
	specific path inside the bridged network.	specific path inside the bridged network.
	A similar interworking function pair at the	A similar interworking function pair at the
	other end of the TSN sub-network would restore the packet to its	other end of the TSN sub-network would restore the packet to its
	original L2 destination MAC address and VLAN.	original L2 destination MAC address and VLAN.
	</t>	</t>
	<t>	<t>
	Placement of TSN functions depends on the TSN capabilities of	Placement of TSN functions depends on the TSN capabilities of

	nodes. IP (DetNet) Nodes may or may not support TSN functions. For	nodes. IP (DetNet) nodes may or may not support TSN functions. For a
	a given TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is	given TSN Stream (i.e., a mapped DetNet flow), an IP (DetNet) node is
	treated as a Talker or a Listener inside the TSN sub-network.	treated as a Talker or a Listener inside the TSN sub-network.
	</t>	</t>

		<section numbered="true" toc="default">
	<section title="Functions for DetNet Flow to TSN Stream Mapping">	<name>Functions for DetNet Flow to TSN Stream Mapping</name>
	<t>	<t>
	Mapping of a DetNet IP flow to a TSN Stream is provided via	Mapping of a DetNet IP flow to a TSN Stream is provided via the
	the combination of a passive and an active stream ident	combination of a passive and an active Stream identification
	ification	function that operate at the frame level (Layer 2). The passive
	function that operate at the frame level (Layer-2). The	Stream identification function is used to catch the 6-tuple of a
	passive stream	DetNet IP flow, and the active Stream identification function is
	identification function is used to catch the 6-tuple of	used to modify the Ethernet header according to the ID of the
	a DetNet	mapped TSN Stream.
	IP flow and the active stream identification function i	</t>
	s used to	<t>
	modify the Ethernet header according to the ID of the m	Clause 6.7 of <xref target="IEEE8021CB"
	apped TSN	format="default"/> defines an IP Stream
	Stream.	identification function that can be used as a
	</t>	passive function for IP DetNet flows using UDP or
	<t>	TCP. Clause 6.8 of <xref target="IEEEP8021CBdb"
	Clause 6.7 of <xref target="IEEE8021CB"/> defines an IP	format="default"/> defines a Mask-and-Match Stream
	Stream	identification function that can be used as a
	identification function that can be used as a passive f	passive function for any IP DetNet flows.
	unction	</t>
	for IP DetNet flows using UDP or TCP. Clause 6.8 of	<t>
	<xref target="IEEEP8021CBdb"/> defines a	Clause 6.6 of <xref target="IEEE8021CB"
	Mask-and-Match Stream identification function that can	format="default"/> defines an Active Destination MAC
	be used	and VLAN Stream identification function that can
	as a passive function for any IP DetNet flows.	replace some Ethernet header fields: (1) the
	</t>	destination MAC address, (2) the VLAN-ID, and (3)
	<t>	priority parameters with alternate
	Clause 6.6 of <xref target="IEEE8021CB"/> defines an	values. Replacement is provided for the frame passed
	Active Destination MAC and VLAN Stream identification function,	down the stack from the upper layers or up the stack
	what can replace some Ethernet header fields namely (1) the	from the lower layers.
	destination MAC-address, (2) the VLAN-ID and (3) priority	</t>
	parameters with alternate values. Replacement is provided for	<t>
	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	Active Destination MAC and VLAN Stream identification can be

	used within a Talker to set flow identity or a Listener to	used within a Talker to set flow identity or within a Listener to
	recover the original addressing information. It can be used also	recover the original addressing information. It can be used also
	in a TSN bridge that is providing translation as a proxy service	in a TSN bridge that is providing translation as a proxy service
	for an End System.	for an End System.

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="TSN requirements of IP DetNet nodes">	<name>TSN Requirements of IP DetNet Nodes</name>
	<t>	<t>
	This section covers the required behavior of a TSN-aware DetNet no	This section covers the required behavior of a TSN-aware DetNet
	de	node using a TSN sub-network. The implementation of TSN
	using a TSN sub-network. The implementation of TSN pack	packet-processing functions must be compliant with the relevant
	et	IEEE 802.1 standards.
	processing functions must be compliant with the relevan	</t>
	t IEEE 802.1	<t>
	standards.	From the TSN sub-network perspective, DetNet IP nodes are treated
	</t>	as a Talker or Listener that may be (1) TSN unaware or (2)
	<t>	TSN aware.
	From the TSN sub-network perspective DetNet IP nodes are treated	</t>
	as Talker or Listener, that may be (1) TSN-unaware or	<t>
	(2) TSN-aware.	In cases of TSN-unaware IP DetNet nodes, the TSN relay nodes
	</t>	within the TSN sub-network must modify the Ethernet
	<t>	encapsulation of the DetNet IP flow (e.g., MAC translation,
	In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within	VLAN-ID setting, sequence number addition, etc.) to allow proper
	the TSN sub-network must modify the Ethernet encapsulat	TSN-specific handling inside the sub-network. There are no
	ion of the	requirements defined for TSN-unaware IP DetNet nodes in this
	DetNet IP flow (e.g., MAC translation, VLAN-ID setting,	document.
	Sequence	</t>
	number addition, etc.) to allow proper TSN specific han	<t>
	dling	IP (DetNet) nodes being TSN aware can be treated as a
	inside the sub-network. There are no requirements defi	combination of a TSN-unaware Talker/Listener and a TSN relay, as
	ned for	shown in <xref target="fig_ip_with_tsn" format="default"/>. In
	TSN-unaware IP DetNet nodes in this document.	such cases, the IP (DetNet) node must provide the TSN
	</t>	sub-network-specific Ethernet encapsulation over the link(s)
	<t>	towards the sub-network.
	IP (DetNet) nodes being TSN-aware can be treated as a	</t>
	combination of a TSN-unaware Talker/Listener and a TSN-Relay, as	<figure anchor="fig_ip_with_tsn">
	shown in <xref target="fig_ip_with_tsn"/>. In such cases the IP	<name>IP (DetNet) Node with TSN Functions</name>
	(DetNet) node must provide the TSN sub-network specific Ethernet	<artwork name="" type="" align="left" alt=""><![CDATA[
	encapsulation over the link(s) towards the sub-network.
	</t>

	<figure align="center" anchor="fig_ip_with_tsn"
	title="IP (DetNet) node with TSN functions">
	<artwork><![CDATA[
	IP (DetNet)	IP (DetNet)
	Node	Node
	<---------------------------------->	<---------------------------------->

	............	............
	<--: Service :-- DetNet flow ------------------	<--: Service :-- DetNet flow ------------------
	+----------+	+----------+
	\|Forwarding\|	\|Forwarding\|
	+----------+ +---------------+	+----------+ +---------------+
	\| L2 \| \| L2 Relay with \|<--- TSN ---	\| L2 \| \| L2 Relay with \|<--- TSN ---
	\| \| \| TSN function \| Stream	\| \| \| TSN function \| Stream
	+-----.----+ +--.------.---.-+	+-----.----+ +--.------.---.-+
	\__________/ \ \______	\__________/ \ \______
	\_________	\_________
	TSN-unaware	TSN-unaware

	Talker / TSN-Bridge	Talker / TSN Bridge
	Listener Relay	Listener Relay
	<----- TSN Sub-network -----	<----- TSN Sub-network -----
	<------- TSN-aware Tlk/Lstn ------->	<------- TSN-aware Tlk/Lstn ------->
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>
	<t>	A TSN-aware IP (DetNet) node implementation must
	A TSN-aware IP (DetNet) node impementations must suppor	support the Stream identification TSN component for
	t the	recognizing flows.
	Stream Identification TSN component for recognizing flo	</t>
	ws.	<t>
	</t>
	<t>
	A Stream identification component must be able to instantiate	A Stream identification component must be able to instantiate

	the following functions (1) Active Destination MAC and VLAN	the following: (1) Active Destination MAC and VLAN Stream
	Stream identification function, (2) IP Stream identification	identification, (2) IP Stream identification, (3) Mask-and-Match
	function, (3) Mask-and-Match Stream identification function and	Stream identification, and (4) the related managed objects in
	(4) the related managed objects in Clause 9 of	Clause 9 of <xref target="IEEE8021CB" format="default"/> and
	<xref target="IEEE8021CB"/> and	<xref target="IEEEP8021CBdb" format="default"/>.
	<xref target="IEEEP8021CBdb"/>.	</t>
	</t>
	<t>	<t>

	A TSN-aware IP (DetNet) node implementation must suppor t the	A TSN-aware IP (DetNet) node implementation must suppor t the
	Sequencing function and the Sequence encode/decode func tion as	Sequencing function and the Sequence encode/decode func tion as

	defined in Clause 7.4 and 7.6 of <xref target="IEEE8021 CB"/> if FRER	defined in Clauses 7.4 and 7.6 of <xref target="IEEE802 1CB" format="default"/> if FRER
	is used inside the TSN sub-network.	is used inside the TSN sub-network.

	</t>	</t>
	<t>	<t>
	The Sequence encode/decode function must support the Redundancy	The Sequence encode/decode function must support the Redundancy

	tag (R-TAG) format as per Clause 7.8 of <xref	tag (R-TAG) format as per Clause 7.8 of <xref target="IEEE8021CB"
	target="IEEE8021CB"/>.	format="default"/>.
	</t>	</t>
	<t>	<t>
	A TSN-aware IP (DetNet) node implementations must suppo	A TSN-aware IP (DetNet) node implementation must suppor
	rt the	t the
	Stream splitting	Stream splitting

	function and the Individual recovery function as define	function and the Individual recovery function as define
	d in Clause 7.7 and 7.5 of	d in Clauses 7.7 and 7.5 of
	<xref target="IEEE8021CB"/> when the node is	<xref target="IEEE8021CB" format="default"/> when the n
		ode is
	a replication or elimination point for FRER.	a replication or elimination point for FRER.

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Service protection within the TSN sub-network">	<name>Service Protection within the TSN Sub-network</name>
	<t>	<t>
	TSN Streams supporting DetNet flows may use Frame Replication	TSN Streams supporting DetNet flows may use FRER as defined in Cla
	and Elimination for Redundancy (FRER) as defined in Clause 8. of	use 8 of
	<xref target="IEEE8021CB"/> based on the	<xref target="IEEE8021CB" format="default"/> based on t
		he
	loss service requirements of the TSN Stream, which is derived	loss service requirements of the TSN Stream, which is derived
	from the DetNet service requirements of the DetNet mapped flow.	from the DetNet service requirements of the DetNet mapped flow.
	The specific operation of FRER is not modified by the use of	The specific operation of FRER is not modified by the use of

	DetNet and follows <xref target="IEEE8021CB"/>.	DetNet and follows <xref target="IEEE8021CB" format="default"/>.
	</t>	</t>
	<t>	<t>
	FRER function and the provided service recovery is available	The FRER function and the provided service recovery are available
	only within the TSN sub-network as the TSN Stream-ID and the TSN	only within the TSN sub-network, as the TSN Stream ID and the TSN
	sequence number are not valid outside the sub-network. An IP	sequence number are not valid outside the sub-network. An IP

	(DetNet) node represents a L3 border and as such it terminates	(DetNet) node represents an L3 border and as such, it terminates
	all related information elements encoded in the L2 frames.	all related information elements encoded in the L2 frames.

	</t>
	</section>

	<section title="Aggregation during DetNet flow to TSN Stream mapping">
	<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 provid
	e
	proper service requirements of the mapped flows.
	</t>
	</section>
	</section>

	<section title="Management and Control Implications">
	<t>
	DetNet flow and TSN Stream mapping related information ar
	e
	required only for TSN-aware IP (DetNet) 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).
	</t>	</t>

		</section>
		<section numbered="true" toc="default">
		<name>Aggregation during DetNet Flow to TSN Stream Mapping</name>
	<t>	<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 numbered="true" toc="default">
		<name>Management and Control Implications</name>

		<t>
		DetNet flows and TSN Stream-mapping-related information
		are required only for TSN-aware IP (DetNet)
		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).
		</t>
		<t>
	The following summarizes the set of information that is needed to	The following summarizes the set of information that is needed to
	configure DetNet IP over TSN:	configure DetNet IP over TSN:

	<list style="symbols">	</t>
	<t>DetNet IP related configuration information accordin	<ul spacing="normal">
	g to the	<li>DetNet-IP-related configuration information according to the
	DetNet role of the DetNet IP node, as per	DetNet role of the DetNet IP node, as per <xref target="RFC8939"
	<xref target="RFC8939"/>. </t>	format="default"/>. </li>
	<t>TSN related configuration information according to t	<li>TSN-related configuration information according to the TSN role of
	he	the DetNet IP node, as per <xref target="IEEE8021Q"
	TSN role of the DetNet IP node, as per	format="default"/>, <xref target="IEEE8021CB" format="default"/>, and
	<xref target="IEEE8021Q"/>, <xref target="IEEE80	<xref target="IEEEP8021CBdb" format="default"/>. </li>
	21CB"/> and	<li>Mapping between DetNet IP flow(s) and TSN Stream(s). DetNet IP
	<xref target="IEEEP8021CBdb"/>. </t>	flow identification is summarized in <xref target="RFC8939"
	<t>Mapping between DetNet IP flow(s) and TSN Stream(s). DetNet IP	sectionFormat="of" section="5.1"/> and includes all wildcards, port
	flow identification is summarized in Section 5.1 of	ranges, and the ability to ignore specific IP fields. Information on
	<xref target="RFC8939"/>, and includes all wildcards, p	TSN Stream identification information is defined in <xref
	ort	target="IEEE8021CB" format="default"/> and <xref
	ranges and the ability to ignore specific IP fields). F	target="IEEEP8021CBdb" format="default"/>. Note that managed
	or TSN	objects for TSN Stream identification can be found in <xref
	Streams stream identification information are defined i	target="IEEEP8021CBcv" format="default"/>.
	n	</li>
	<xref target="IEEE8021CB"/> and <xref target="IEEEP8021	</ul>
	CBdb"/>).	<t>
	Note, that managed objects for TSN Stream identificatio
	n can be
	found in <xref target="IEEEP8021CBcv"/>.
	</t>
	</list>
	This information must be provisioned per DetNet flow.	This information must be provisioned per DetNet flow.

	</t>	</t>
	<t>	<t>
	Mappings between DetNet and TSN management and control pl anes are	Mappings between DetNet and TSN management and control pl anes are
	out of scope of this document. Some of the challenges are	out of scope of this document. Some of the challenges are

	highligthed below.	highlighted below.
	</t>	</t>
	<t>
	TSN-aware IP DetNet nodes are members of both the DetNet	<t>
	domain and the TSN sub-network. Within the TSN	TSN-aware IP DetNet nodes are members of both the
	sub-network the TSN-aware IP (DetNet) node has a TSN-awar	DetNet domain and the TSN sub-network. Within the TSN
	e	sub-network, the TSN-aware IP (DetNet) node has a
	Talker/Listener role, so TSN specific management and	TSN-aware Talker/Listener role, so TSN-specific
	control plane functionalities must be implemented. There	management and control plane functionalities must be
	are many similarities in the management plane techniques	implemented. There are many similarities in the
	used in DetNet and TSN, but that is not the case for the	management plane techniques used in DetNet and TSN,
	control plane protocols. For example, RSVP-TE and MSRP	but that is not the case for the control plane
	behaves differently. Therefore management and control	protocols. For example, RSVP-TE and the Multiple
	plane design is an important aspect of scenarios, where	Stream Registration Protocol (MSRP) of IEEE 802.1 behave
		differently. Therefore, management and control plane
		design is an important aspect of scenarios where
	mapping between DetNet and TSN is required.	mapping between DetNet and TSN is required.

	</t>	</t>
	<t>	<t>
	In order to use a TSN sub-network between DetNet nodes,
	DetNet specific information must be converted to TSN	In order to use a TSN sub-network between DetNet nodes, DetNet-specific
	sub-network specific ones. DetNet flow ID and flow related	information must be converted to TSN sub-network-specific information.
	parameters/requirements must be converted to a TSN Stream
	ID and stream related parameters/requirements. Note that,	DetNet flow ID and flow-related parameters/requirements must be converted to a
	as the TSN sub-network is just a portion of the end-to-end	TSN Stream ID and stream-related parameters/requirements. Note that, as the
	DetNet path (i.e., single hop from IP perspective), some	TSN sub-network is just a portion of the end-to-end DetNet path (i.e., single
	parameters (e.g., delay) may differ significantly. Other	hop from an IP perspective), some parameters (e.g., delay) may differ
	parameters (like bandwidth) also may have to be tuned due	significantly. Other parameters (like bandwidth) also may have to be tuned due
	to the L2 encapsulation used within the TSN sub-network.	to the L2 encapsulation used within the TSN sub-network.
	</t>	</t>
	<t>	<t>
	In some cases it may be challenging to determine some TSN	In some cases, it may be challenging to determine some TSN
	Stream related information. For example, on a TSN-aware IP	Stream-related information. For example, on a TSN-aware IP
	(DetNet) node that acts as a Talker, it is quite obvious	(DetNet) node that acts as a Talker, it is quite obvious which
	which DetNet node is the Listener of the mapped TSN stream	DetNet node is the Listener of the mapped TSN Stream (i.e., the
	(i.e., the IP Next-Hop). However it may be not trivial to	IP next-hop). However, it may not be trivial to locate the
	locate the point/interface where that Listener is	point/interface where that Listener is connected to the TSN
	connected to the TSN sub-network. Such attributes may	sub-network. Such attributes may require interaction between
	require interaction between control and management plane	control and management plane functions and between DetNet and
	functions and between DetNet and TSN domains.	TSN domains.
	</t>	</t>
	<t>	<t>
	Mapping between DetNet flow identifiers and TSN Stream	Mapping between DetNet flow identifiers and TSN Stream
	identifiers, if not provided explicitly, can be done by a	identifiers, if not provided explicitly, can be done by a

	TSN-aware IP (DetNet) node locally based on information	TSN-aware IP (DetNet) node locally based on information provided
	provided for configuration of the TSN Stream	for configuration of the TSN Stream identification functions (IP
	identification functions (IP Stream identification,	Stream identification, Mask-and-Match Stream identification, and
	Mask-and-match Stream identification and active Stream	the active Stream identification function).
	identification function).	</t>
	</t>	<t>
	<t>
	Triggering the setup/modification of a TSN Stream in the	Triggering the setup/modification of a TSN Stream in the
	TSN sub-network is an example where management and/or	TSN sub-network is an example where management and/or
	control plane interactions are required between the DetNet	control plane interactions are required between the DetNet
	and TSN sub-network. TSN-unaware IP (DetNet) nodes make	and TSN sub-network. TSN-unaware IP (DetNet) nodes make

	such a triggering even more complicated as they are fully	such a triggering even more complicated, as they are fully
	unaware of the sub-network and run independently.	unaware of the sub-network and run independently.

	</t>	</t>
	<t>	<t>
	Configuration of TSN specific functions (e.g., FRER)	Configuration of TSN-specific functions (e.g., FRER)
	inside the TSN sub-network is a TSN domain specific decision	inside the TSN sub-network is a TSN-domain-specific decision
	and may not be visible in the DetNet domain.	and may not be visible in the DetNet domain.

	</t>	</t>
	</section>	</section>

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


	<section title="Security Considerations">	<section numbered="true" toc="default">
		<name>Security Considerations</name>
	<t>	<t>
	Security considerations for DetNet are described in detail in	Security considerations for DetNet are described in detail in

	<xref target="I-D.ietf-detnet-security"/>. General security considerati	<xref target="I-D.ietf-detnet-security" format="default"/>. General sec
	ons	urity considerations
	are described in <xref target="RFC8655"/>.	are described in <xref target="RFC8655" format="default"/>.
	DetNet IP data plane specific considerations are summarized in	Considerations specific to the DetNet IP data plane are summarized in
	<xref target="RFC8939"/>.	<xref target="RFC8939" format="default"/>.
	This section considers exclusively security considerations which are
	specific to the DetNet IP over TSN sub-network scenario.	This section discusses security considerations that are specific
		to the DetNet IP-over-TSN sub-network scenario.

	</t>	</t>
	<t>	<t>

	The sub-network between DetNet nodes needs to be subject to appropriate	The sub-network between DetNet nodes needs to be subject to
	confidentiality. Additionally, knowledge of what DetNet/TSN services ar	appropriate confidentiality. Additionally, knowledge of what
	e	DetNet/TSN services are provided by a sub-network may supply
	provided by a sub-network may supply information that can be used in a	information that can be used in a variety of security attacks. The
	variety of security attacks. The ability to modify information exchange	ability to modify information exchanges between connected DetNet
	s	nodes may result in bogus operations. Therefore, it is important
	between connected DetNet nodes may result in bogus operations. Therefor	that the interface between DetNet nodes and the TSN sub-network are
	e,	subject to authorization, authentication, and encryption.
	it is important that the interface between DetNet nodes and TSN
	sub-network are subject to authorization, authentication, and encryptio
	n.
	</t>	</t>
	<t>	<t>

	The TSN sub-network operates at Layer-2 so various security mechanisms	The TSN sub-network operates at Layer 2, so various security mechanisms
	defined by IEEE can be used to secure the connection between the DetNet	defined by IEEE can be used to secure the connection between the DetNet

	nodes (e.g., encryption may be provided using MACSec	nodes (e.g., encryption may be provided using MACsec
	<xref target="IEEE802.1AE-2018"/>).	<xref target="IEEE802.1AE-2018" format="default"/>).
	</t>	</t>
	</section>	</section>

		<section anchor="iana" numbered="true" toc="default">
	<section anchor="iana" title="IANA Considerations">	<name>IANA Considerations</name>
	<t>	<t>

	None.	This document has no IANA actions.
	</t>	</t>
	</section>	</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 contributi
	ons
	to this work.
	</t>
	</section>
	</middle>	</middle>


	<back>	<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"?>


	<reference anchor="IEEE8021CB"	<displayreference target="I-D.ietf-detnet-security" to="DETNET-SECURITY"/>
	target="http://standards.ieee.org/about/get/">
	<front>
	<title>Standard for Local and metropolitan area networks -
	Frame Replication and Elimination for Reliability
	(IEEE Std 802.1CB-2017)</title>
	<author>
	<organization>IEEE 802.1</organization>
	</author>
	<date year="2017"/>
	</front>
	<format type="PDF" target="http://standards.ieee.org/about/get/"/>
	</reference>


	<reference anchor="IEEEP8021CBdb"	<references>
	target="http://www.ieee802.org/1/files/private/db-drafts/d1/802	<name>References</name>
	-1CBdb-d1-0.pdf">	<references>
	<front>	<name>Normative References</name>
	<title>Extended Stream identification functions</title>
	<author initials="C. M." surname="Mangin" fullname="Christophe Mangin"
	>
	<organization>IEEE 802.1</organization>
	</author>
	<date month="September" year="2020"/>
	</front>
	<seriesInfo name="IEEE P802.1CBdb /D1.0" value="P802.1CBdb"/>
	<format type="PDF" target="http://www.ieee802.org/1/files/private/db-dra
	fts/d1/802-1CBdb-d1-0.pdf"/>
	</reference>


	</references>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<references title="Informative references">	FC.8655.xml"/>
	<!-- <?rfc include="reference.I-D.ietf-detnet-flow-information-model"?> --	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	>	FC.8939.xml"/>
	<?rfc include="reference.I-D.ietf-detnet-security"?>


	<reference anchor="IEEE802.1AE-2018"	<reference anchor="IEEE8021CB" target="https://standards.ieee.org/standard
	target="https://ieeexplore.ieee.org/document/8585421">	/802_1CB-2017.html">
	<front>	<front>
	<title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title>	<title>IEEE Standard for Local and metropolitan area
	<author>	networks--Frame Replication and Elimination for Reliability
	<organization>IEEE Standards Association</organization>	</title>
	</author>	<author>
	<date year="2018" />	<organization>IEEE</organization>
	</front>	</author>
	</reference>	<date month="October" year="2017"/>
		</front>
		<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139" />
		<refcontent>IEEE 802.1CB-2017</refcontent>
		</reference>


	<reference anchor="IEEE8021Q"	<reference anchor="IEEEP8021CBdb" target="https://1.ieee802.org/tsn/802-1cbdb/">
	target="http://standards.ieee.org/about/get/">	<front>
	<front>	<title>Draft Standard for Local and metropolitan area networks --
	<title>Standard for Local and metropolitan area networks--Bridges	Frame Replication and Elimination for Reliability -- Amendment:
	and Bridged Networks (IEEE Std 802.1Q-2018)</title>	Extended Stream Identification Functions</title>
	<author>	<author>
	<organization>IEEE 802.1</organization>	<organization>IEEE</organization>
	</author>	</author>
	<date year="2018"/>	<date month="April" year="2021"/>
	</front>	</front>
	<format type="PDF" target="http://standards.ieee.org/about/get/"/>	<refcontent>IEEE P802.1CBdb / D1.3</refcontent>
	</reference>	</reference>


	<reference anchor="IEEEP8021CBcv"	</references>
	target="https://www.ieee802.org/1/files/private/cv-drafts/d0/80	<references>
	2-1CBcv-d0-4.pdf">	<name>Informative References</name>
	<front>
	<title>FRER YANG Data Model and Management Information Base Module</ti	<reference anchor='I-D.ietf-detnet-security'>
	tle>	<front>
	<author initials="S." surname="Kehrer" fullname="Stephan Kehrer">	<title>Deterministic Networking (DetNet) Security Considerations</title>
	<organization>IEEE 802.1</organization>
	</author>	<author initials='E' surname='Grossman' fullname='Ethan Grossman' role="editor">
	<date month="August" year="2020"/>	<organization />
	</front>	</author>
	<seriesInfo name="IEEE P802.1CBcv /D0.4" value="P802.1CBcv"/>
	<format type="PDF" target="https://www.ieee802.org/1/files/private/cv-dr	<author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'>
	afts/d0/802-1CBcv-d0-4.pdf"/>	<organization />
	</reference>	</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 Standard for Local and metropolitan area networks--Media
		Access Control (MAC) Security</title>
		<author>
		<organization>IEEE</organization>
		</author>
		<date 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="https://ieeexplore.ieee.org/docume
		nt/8403927">
		<front>
		<title>IEEE Standard for Local and Metropolitan Area Network--Bridge
		s and Bridged Networks
		</title>
		<author>
		<organization>IEEE</organization>
		</author>
		<date month="July" year="2018"/>
		</front>
		<refcontent>IEEE Std 802.1Q-2018</refcontent>
		<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
		</reference>

		<reference anchor="IEEEP8021CBcv" target="https://1.ieee802.org/tsn/802-1cbcv/"
		>
		<front>
		<title>Draft Standard for Local and metropolitan area networks--Fram
		e Replication and
		Elimination for Reliability--Amendment: Information Model, YANG Data Model and M
		anagement Information
		Base Module</title>
		<author>
		<organization>IEEE 802.1</organization>
		</author>
		<date month="February" year="2021"/>
		</front>
		<refcontent>IEEE P802.1CBcv, Draft 1.1</refcontent>
		</reference>

		</references>
	</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>	</back>
	</rfc>	</rfc>

End of changes. 84 change blocks.
	496 lines changed or deleted	486 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/