Diff: rfc9056xml2.original.xml

	rfc9056xml2.original.xml	rfc9056.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-mpls-09" number="9056" ipr="trust200902" submissionType="IETF" category="std"
	<?rfc sortrefs="yes"?>	consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRef
	<?rfc iprnotified="no"?>	s="true" sortRefs="true" version="3">
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std"
	docName="draft-ietf-detnet-ip-over-mpls-09"
	ipr="trust200902"
	submissionType="IETF">
	<front>	<front>

	<title abbrev="DetNet IP over DetNet MPLS Data Plane">	<title abbrev="DetNet Data Plane: IP over MPLS">
	DetNet Data Plane: IP over MPLS</title>	Deterministic Networking (DetNet) Data Plane: IP over MPLS</title>


	<author role="editor" fullname="Balázs Varga" initials="B." surname="	<seriesInfo name="RFC" value="9056"/>
	Varga">	<author role="editor" fullname="Balázs Varga" initials="B." surname="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">
	<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="Lou Berger" initials="L." surname="Berger">	<author fullname="Lou Berger" initials="L." surname="Berger">
	<organization>LabN Consulting, L.L.C.</organization>	<organization>LabN Consulting, L.L.C.</organization>
	<address>	<address>
	<email>lberger@labn.net</email>	<email>lberger@labn.net</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Don Fedyk" initials="D." surname="Fedyk">	<author fullname="Don Fedyk" initials="D." surname="Fedyk">
	<organization>LabN Consulting, L.L.C.</organization>	<organization>LabN Consulting, L.L.C.</organization>
	<address>	<address>
	<email>dfedyk@labn.net</email>	<email>dfedyk@labn.net</email>
	</address>	</address>
	</author>	</author>


	<!--
	<author fullname="Andrew G. Malis" initials="A.G." surname="Malis">
	<organization>Independent</organization>
	<address>
	<email>agmalis@gmail.com</email>
	</address>
	</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>
	<author fullname="Jouni Korhonen" initials="J." surname="Korhonen">	<author fullname="Jouni Korhonen" initials="J." surname="Korhonen">

	<!--organization abbrev="Nordic">Nordic Semiconductor</organization-->
	<address>	<address>
	<email>jouni.nospam@gmail.com</email>	<email>jouni.nospam@gmail.com</email>
	</address>	</address>
	</author>	</author>


	<!--author fullname="Donald Fauntleroy Duck" initials="D. F." surname="Duck"	<date year="2021" month="October" />
	>
	<organization abbrev="Royal Bros.">Royal Bros.</organization>
	<address>
	<postal>
	<street>13 Paradise Road</street>
	<city>Duckburg</city>
	<region>Calisota</region>
	<country>USA</country>
	</postal>
	</address>
	</author-->
	<date />
	<workgroup>DetNet</workgroup>	<workgroup>DetNet</workgroup>


		<keyword>sub-network</keyword>

	<abstract>	<abstract>
	<t>	<t>
	This document specifies the Deterministic Networking data plane	This document specifies the Deterministic Networking data plane

	when encapsulating IP over an MPLS packet switched network.	when encapsulating IP over an MPLS packet-switched network.
	</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	Deterministic Networking (DetNet) is a service that can be offered by a
	network to DetNet flows.	network to DetNet flows.
	DetNet provides a capability for the delivery of data flows with	DetNet provides a capability for the delivery of data flows with
	extremely low packet loss rates and bounded end-to-end delivery	extremely low packet loss rates and bounded end-to-end delivery
	latency.	latency.
	General background and concepts of DetNet can be found in the DetNet	General background and concepts of DetNet can be found in the DetNet

	Architecture <xref target="RFC8655"/>.	architecture <xref target="RFC8655" format="default"/>.
	</t>
	<!-- <t>
	This document specifies the DetNet data plane operation for IP
	hosts and routers that provide DetNet service to IP encapsulated
	data. No DetNet specific encapsulation is defined to support IP
	flows, rather existing IP and higher layer protocol header information i
	s used to support
	flow identification and DetNet service delivery.
	</t>
	<t>
	The DetNet Architecture decomposes the 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 congestion protection (low loss, assured latency, and
	limited reordering). Since no DetNet specific headers are added to
	support DetNet IP flows, only the forwarding sub-layer functions are
	supported using the DetNet IP defined by this document. Service
	protection can be provided on a per sub-net
	basis using technologies such as MPLS <xref
	target="I-D.ietf-detnet-mpls"/> and IEEE802.1 TSN.
	</t>	</t>


	<t>	<t>
	This document specifies use of the IP DetNet encapsulation over an	This document specifies use of the IP DetNet encapsulation over an

	MPLS network. It maps the IP data plane encapsulation described	MPLS network. It maps the IP data plane encapsulation described
	in <xref	in <xref target="RFC8939" format="default"/> to the DetNet MPLS data plane defin
	target="I-D.ietf-detnet-ip"/> to the DetNet MPLS data plane defi	ed in <xref target="RFC8964" format="default"/>.
	ned in <xref
	target="I-D.ietf-detnet-mpls"/>.
	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Terminology">	<name>Terminology</name>
	<section title="Terms Used In This Document">	<section numbered="true" toc="default">
		<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 target="RFC8655"/>	DetNet architecture <xref target="RFC8655" format="default"/> and in
	and <xref target="I-D.ietf-detnet-data-plane-framework"/>, the	<xref target="RFC8938" format="default"/>. The reader is assumed to
	reader is assumed to be familiar with these documents and thei	be familiar with these documents and their terminology.
	r
	terminology.
	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Abbreviations">	<name>Abbreviations</name>
	<t>	<t>
	This document uses the abbreviations defined in the DetNet	This document uses the abbreviations defined in the DetNet

	architecture <xref target="RFC8655"/> and	architecture <xref target="RFC8655" format="default"/> and in <xref
	<xref target="I-D.ietf-detnet-data-plane-framework"/>.	target="RFC8938" format="default"/>. This document uses the
	This document uses the following abbreviations:	following abbreviations:
	<list style="hanging" hangIndent="14">
	<t hangText="CE">Customer Edge equipment.</t>
	<t hangText="d-CW">DetNet Control Word.</t>
	<t hangText="DetNet">Deterministic Networking.</t>
	<t hangText="DF">DetNet Flow.</t>
	<t hangText="DN">DetNet.</t>
	<t hangText="L2">Layer-2.</t>
	<t hangText="LSP">Label-switched path.</t>
	<t hangText="MPLS">Multiprotocol Label Switching.</t>
	<t hangText="PEF">Packet Elimination Function.</t>
	<t hangText="PRF">Packet Replication Function.</t>
	<t hangText="PREOF">Packet Replication, Elimination and Ordering Fun
	ctions.</t>
	<t hangText="POF">Packet Ordering Function.</t>
	<t hangText="PW">Pseudowire.</t>
	<t hangText="S-Label">DetNet "service" label.</t>
	<t hangText="S-PE">Switching Provider Edge.</t>
	<t hangText="T-PE">Terminating Provider Edge.</t>
	<t hangText="TE">Traffic Engineering.</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>CE</dt>
		<dd>Customer Edge (equipment)</dd>
		<dt>d-CW</dt>
		<dd>DetNet Control Word</dd>
		<dt>DetNet</dt>
		<dd>Deterministic Networking</dd>
		<dt>DF</dt>
		<dd>DetNet Flow</dd>
		<dt>DN</dt>
		<dd>DetNet</dd>
		<dt>L2</dt>
		<dd>Layer 2</dd>
		<dt>LSP</dt>
		<dd>Label-Switched Path</dd>
		<dt>MPLS</dt>
		<dd>Multiprotocol Label Switching</dd>
		<dt>PEF</dt>
		<dd>Packet Elimination Function</dd>
		<dt>PRF</dt>
		<dd>Packet Replication Function</dd>
		<dt>PREOF</dt>
		<dd>Packet Replication, Elimination, and Ordering Functions</dd>
		<dt>POF</dt>
		<dd>Packet Ordering Function</dd>
		<dt>PW</dt>
		<dd>Pseudowire</dd>
		<dt>S-Label</dt>
		<dd>DetNet "service" Label</dd>
		<dt>S-PE</dt>
		<dd>Switching Provider Edge</dd>
		<dt>T-PE</dt>
		<dd>Terminating Provider Edge</dd>
		<dt>TE</dt>
		<dd>Traffic Engineering</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 numbered="true" toc="default">
		<name>Requirements Language</name>


	<section title="Requirements Language">	<t>
	<t>	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	described in BCP 14 <xref target="RFC2119"/> <xref	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	target="RFC8174"/> when, and only when, they appear in all	are to be interpreted as described in BCP 14 <xref target="RFC2119"
	capitals, as shown here.	format="default"/> <xref target="RFC8174" format="default"/> when, and
	</t>	only when, they appear in all capitals, as shown here.
	</section>	</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="fig_ip_detnet"/> illustrates an IP DetNet, with an MPLS ba	<xref target="fig_ip_detnet" format="default"/> illustrates an IP
	sed DetNet	DetNet with an MPLS-based DetNet network as a sub-network between the
	network as a sub-network between the relay nodes. An IP flow is	relay nodes. An IP flow is mapped to one or more PWs and MPLS (TE)
	mapped to one or more PWs and MPLS (TE) LSPs. The end systems	LSPs. The end systems still originate IP-encapsulated traffic,
	still originate IP encapsulated traffic, identified as	identified as DetNet flows. The relay nodes follow procedures defined
	DetNet flows. The relay nodes follow procedures defined in	in <xref target="ip-over-mpls" format="default"/> to map each DetNet
	<xref target="ip-over-mpls"/> to map each DetNet	flow to MPLS LSPs. While not shown, relay nodes can provide service
	flow to MPLS LSPs. While not shown, relay nodes can provide	sub-layer functions such as PREOF using DetNet over MPLS, and this is
	service sub-layer functions such as PREOF using DetNet over MPLS,	indicated by the solid line for the MPLS-facing portion of the Service
	and this is indicated by the solid line for the MPLS	component. Note that the Transit node is MPLS (TE) LSP aware and
	facing portion of the Service component. Note that the Transit	performs switching based on MPLS labels; it need not have any
	node is MPLS (TE) LSP aware and performs switching based on MPLS	specific knowledge of the DetNet service or the corresponding DetNet
	labels, and need not have any specific knowledge of the DetNet	flow identification. See <xref target="ip-over-mpls"
	service or the corresponding DetNet flow identification. See	format="default"/> for details on the mapping of IP flows to MPLS, and
	<xref target="ip-over-mpls"/> for details on the mapping of IP	<xref target="RFC8964" format="default"/> for general support of
	flows to MPLS, and <xref target="I-D.ietf-detnet-mpls"/>	DetNet services using MPLS.
	for general support of DetNet services using MPLS.
	</t>	</t>


	<figure align="center" anchor="fig_ip_detnet"	<figure anchor="fig_ip_detnet">
	title="Architecture: DetNet IP Over DetNet MPLS Network">	<name>Architecture: DetNet IP over DetNet MPLS Network</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	DetNet IP Relay Transit Relay DetNet IP	DetNet IP Relay Transit Relay DetNet IP
	End System Node Node Node End System	End System Node Node Node End System

	+----------+ +----------+	+----------+ +----------+
	\| Appl. \|<------------- End to End Service ---------->\| Appl. \|	\| Appl. \|<------------- End to End Service ---------->\| Appl. \|
	+----------+ .....-----+ +-----..... +----------+	+----------+ .....-----+ +-----..... +----------+
	\| Service \|<--: Service \|--DetNet flow ---\| Service :-->\| Service \|	\| Service \|<--: Service \|--DetNet flow ---\| Service :-->\| Service \|
	\| \| : \|<-DN MPLS flow ->\| : \| \|	\| \| : \|<-DN MPLS flow ->\| : \| \|
	+----------+ +---------+ +----------+ +---------+ +----------+	+----------+ +---------+ +----------+ +---------+ +----------+
	\|Forwarding\| \|Fwd\| \|Fwd\| \|Forwarding\| \|Fwd\| \|Fwd\| \|Forwarding\|	\|Forwarding\| \|Fwd\| \|Fwd\| \|Forwarding\| \|Fwd\| \|Fwd\| \|Forwarding\|
	+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+	+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
	: Link : / ,-----. \ : Link : / ,-----. \	: Link : / ,-----. \ : Link : / ,-----. \
	+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+	+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+
	[Network] [Network]	[Network] [Network]
	`-----' `-----'	`-----' `-----'

	\|<---- DetNet MPLS ---->\|	\|<---- DetNet MPLS ---->\|
	\|<--------------------- DetNet IP ------------------>\|	\|<--------------------- DetNet IP ------------------>\|
	]]></artwork>	]]></artwork>
	</figure>	</figure>

		</section>


	</section>	<section anchor="ip-over-mpls" numbered="true" toc="default">
		<name>DetNet IP over DetNet MPLS</name>
	<!-- ===================================================================== -
	->

	<section anchor="ip-over-mpls" title="IP over DetNet MPLS">
	<t>	<t>

	This section defines how IP encapsulated flows are carried over	This section defines how IP-encapsulated flows are carried over a
	a DetNet MPLS data plane as defined in <xref	DetNet MPLS data plane as defined in <xref target="RFC8964"
	target="I-D.ietf-detnet-mpls"/>. Since both Non-DetNet and	format="default"/>. Since both non-DetNet and DetNet IP packets are
	DetNet IP packet are identical on the wire, this section is	identical on the wire, this section is applicable to any node that
	applicable to any node that supports IP over DetNet MPLS, and	supports IP over DetNet MPLS, and this section refers to both cases as
	this section refers to both cases as DetNet IP over DetNet MPLS.	DetNet IP over DetNet MPLS.
	</t>	</t>

		<section anchor="sec_ip_mpls_dt_dp_scen" numbered="true" toc="default">
	<section title="IP Over DetNet MPLS Data Plane Scenarios"	<name>DetNet IP over DetNet MPLS Data Plane Scenarios</name>
	anchor="sec_ip_mpls_dt_dp_scen">
	<t>	<t>
	An example use of DetNet IP over DetNet MPLS is presented here.	An example use of DetNet IP over DetNet MPLS is presented here.
	</t>	</t>
	<t>	<t>

	<xref target="fig_ip_detnet"/> illustrates IP DetNet
	enabled End Systems (hosts) connected to DetNet (DN) enabled
	IP networks, operating over a DetNet aware MPLS network.
	In this Figure we have a case where the Relay nodes act as
	T-PEs and sit at the boundary of the MPLS
	domain since the non-MPLS domain is DetNet aware. This case
	is very similar to the DetNet MPLS Network Figure 2 in <xref
	target="I-D.ietf-detnet-mpls"/>. However, in <xref
	target="I-D.ietf-detnet-mpls"/> Figure 2, the T-PEs are locat
	ed at the
	end system and MPLS spans the whole DetNet service.


	The primary difference in this document is that the Relay nodes are at	<xref target="fig_ip_detnet" format="default"/> illustrates IP
	the edges of the	DetNet-enabled End Systems (hosts) connected to DetNet-enabled IP
	MPLS domain and therefore function as T-PEs, and that MPLS service	networks (DN IP), operating over a DetNet-aware MPLS network. In this
	sub-layer functions are not provided over the DetNet IP	figure, we have a case where the relay nodes act as T-PEs and sit at
	network. The transit node functions shown above are identical	the boundary of the MPLS domain since the non-MPLS domain is DetNet
	to those described in <xref	aware. This case is very similar to the DetNet MPLS Network (Figure
	target="I-D.ietf-detnet-mpls"/>.	2 in <xref target="RFC8964" format="default"/>). However, in Figure
		2 of <xref target="RFC8964" format="default"/>, the T-PEs are
		located at the end system and MPLS spans the whole DetNet service.

		The primary difference in this document is that the relay nodes are
		at the edges of the MPLS domain and therefore function as T-PEs, and
		that MPLS service sub-layer functions are not provided over the
		DetNet IP network. The transit node functions shown above are
		identical to those described in <xref target="RFC8964"
		format="default"/>.
	</t>	</t>

	<t>	<t>

	<xref target="fig_ip_pw_detnet"/> illustrates how relay nodes	<xref target="fig_ip_pw_detnet" format="default"/> illustrates how
	can provide service protection over an MPLS domain. In this	relay nodes can provide service protection over an MPLS domain. In
	case, CE1 and CE2 are IP DetNet end systems which are	this case, CE1 and CE2 are IP DetNet end systems that are
	interconnected via a MPLS domain such as described in <xref	interconnected via an MPLS domain such as that described in <xref
	target="I-D.ietf-detnet-mpls"/>. Note that R1 and R3	target="RFC8964" format="default"/>. Note that R1 and R3 sit at the
	sit at the edges of an MPLS domain and therefore are similar	edges of an MPLS domain and therefore are similar to T-PEs, while R2
	to T-PEs, while R2 sits in the middle of the domain and is	sits in the middle of the domain and is therefore similar to an
	therefore similar to an S-PE.	S-PE.
	</t>	</t>

		<figure anchor="fig_ip_pw_detnet">
	<figure align="center" anchor="fig_ip_pw_detnet"	<name>Service Protection over DetNet MPLS Network for DetNet IP</name>
	title="Service Protection Over DetNet MPLS Network for DetNet IP	<artwork name="" type="" align="left" alt=""><![CDATA[
	">
	<artwork><![CDATA[
	DetNet DetNet	DetNet DetNet
	IP Service Transit Transit Service IP	IP Service Transit Transit Service IP
	DetNet \|<-Tnl->\| \|<-Tnl->\| DetNet	DetNet \|<-Tnl->\| \|<-Tnl->\| DetNet
	End \| V 1 V V 2 V \| End	End \| V 1 V V 2 V \| End
	System \| +--------+ +--------+ +--------+ \| System	System \| +--------+ +--------+ +--------+ \| System
	+---+ \| \| R1 \|=======\| R2 \|=======\| R3 \| \| +---+	+---+ \| \| R1 \|=======\| R2 \|=======\| R3 \| \| +---+
	\| \|-------\|._X_....\|..DF1..\|.__ ___.\|..DF3..\|...._X_.\|-------\| \|	\| \|-------\|._X_....\|..DF1..\|.__ ___.\|..DF3..\|...._X_.\|-------\| \|
	\|CE1\| \| \| \ \| \| X \| \| / \| \| \|CE2\|	\|CE1\| \| \| \ \| \| X \| \| / \| \| \|CE2\|
	\| \| \| \| \_.\|..DF2..\|._/ \__.\|..DF4..\|._/ \| \| \| \|	\| \| \| \| \_.\|..DF2..\|._/ \__.\|..DF4..\|._/ \| \| \| \|
	+---+ \| \|=======\| \|=======\| \| +---+	+---+ \| \|=======\| \|=======\| \| +---+

	skipping to change at line 317 ¶	skipping to change at line 272 ¶
	\| (T-PE) (S-PE) (T-PE) \|	\| (T-PE) (S-PE) (T-PE) \|
	\| \|	\| \|
	\|<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->\|	\|<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->\|
	\| \|	\| \|
	\|<-------------- End to End DetNet Service --------------->\|	\|<-------------- End to End DetNet Service --------------->\|

	-------------------------- Data Flow ------------------------->	-------------------------- Data Flow ------------------------->

	X = Service protection (PRF, PREOF, PEF/POF)	X = Service protection (PRF, PREOF, PEF/POF)
	DFx = DetNet member flow x over a TE LSP	DFx = DetNet member flow x over a TE LSP

	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>	<t>

	<xref target="fig_ip_detnet"/> illustrates DetNet	<xref target="fig_ip_detnet" format="default"/> illustrates
	enabled End Systems connected to DetNet (DN) enabled	DetNet-enabled end systems connected to DetNet-enabled (DN) MPLS
	MPLS network. A similar situation occurs when	networks. A similar situation occurs when end systems are not DetNet
	end systems are not DetNet aware. In this case, edge nodes sit at	aware. In this case, edge nodes sit at the boundary of the MPLS
	the boundary of the MPLS domain since it is also a DetNet domain	domain since it is also a DetNet domain boundary. The edge nodes
	boundary. The edge nodes provide DetNet service proxies for the	provide DetNet service proxies for the end applications by
	end applications by initiating and terminating DetNet service	initiating and terminating DetNet service for the application's IP
	for the application's IP flows. While the node types differ,	flows. While the node types differ, there is essentially no
	there is essentially no difference in data plane processing	difference in data plane processing between relays and edges. There
	between relay and edges. There are likely to be differences	are likely to be differences in Controller Plane operation,
	in controller plane operation, particularly when distributed	particularly when distributed control plane protocols are used.
	control plane protocols are used.
	</t>	</t>


	<t>	<t>
	It is still possible to provide DetNet service protection for	It is still possible to provide DetNet service protection for

	non-DetNet aware end systems. This case is basically the	non-DetNet-aware end systems. This case is basically the
	same as <xref target="fig_ip_pw_detnet"/>, with the exception	same as <xref target="fig_ip_pw_detnet" format="default"/>, with the e
	that CE1 and CE2 are non-DetNet aware end systems and R1 and R3	xception
		that CE1 and CE2 are non-DetNet-aware end systems and R1 and R3
	become edge nodes.	become edge nodes.
	</t>	</t>

		</section>


	</section>	<section anchor="iom-overview" numbered="true" toc="default">
	<section anchor="iom-overview"	<name>DetNet IP over DetNet MPLS Encapsulation</name>
	title="DetNet IP over DetNet MPLS Encapsulation">	<t>
	<t>	The basic encapsulation approach is to treat a DetNet IP flow as an
	The basic encapsulation	App-flow from the DetNet MPLS perspective. The corresponding example
	approach is to treat a DetNet IP flow as an app-flow from the	DetNet Sub-network format is shown in <xref
	DetNet MPLS perspective. The corresponding example DetNet	target="fig_dn_ip_mpls_sn_ex" format="default"/>.
	Sub-Network format is shown in <xref	</t>
	target="fig_dn_ip_mpls_sn_ex"/>.
	</t>	<figure anchor="fig_dn_ip_mpls_sn_ex">
	<!--	<name>Example DetNet IP over MPLS Sub-network Formats</name>
	<t>	<artwork align="center" name="" type="" alt=""><![CDATA[
	[Editor's note: several proposed changes on the figure.
	Intention is to clarify relationship of the various flows.]
	</t>
	-->
	<figure title="Example DetNet IP over MPLS Sub-Network Formats"
	anchor="fig_dn_ip_mpls_sn_ex">
	<artwork align="center"><![CDATA[

	/-> +------+ +------+ +------+ ^ ^	/-> +------+ +------+ +------+ ^ ^

	\| \| X \| \| X \| \| X \|<- App-Flow : :	\| \| X \| \| X \| \| X \|<- App-flow : :
	\| +------+ +------+ +------+ : :	\| +------+ +------+ +------+ : :

	App-Flow <-+ \|NProto\| \|NProto\| \|NProto\| : :(1)	App-flow <-+ \|NProto\| \|NProto\| \|NProto\| : :(1)
	for MPLS \| +------+ +------+ +------+ : :	for MPLS \| +------+ +------+ +------+ : :
	\| \| IP \| \| IP \| \| IP \| : v	\| \| IP \| \| IP \| \| IP \| : v
	\-> +---+======+--+======+--+======+-----+ :	\-> +---+======+--+======+--+======+-----+ :
	DetNet-MPLS \| d-CW \| \| d-CW \| \| d-CW \| :	DetNet-MPLS \| d-CW \| \| d-CW \| \| d-CW \| :
	+------+ +------+ +------+ :(2)	+------+ +------+ +------+ :(2)
	\|Labels\| \|Labels\| \|Labels\| v	\|Labels\| \|Labels\| \|Labels\| v
	+---+======+--+======+--+======+-----+	+---+======+--+======+--+======+-----+

	Link/Sub-Network \| L2 \| \| TSN \| \| UDP \|	Link/Sub-network \| L2 \| \| TSN \| \| UDP \|
	+------+ +------+ +------+	+------+ +------+ +------+
	\| IP \|	\| IP \|
	+------+	+------+
	\| L2 \|	\| L2 \|
	+------+	+------+
	(1) DetNet IP Flow (or simply IP flow)	(1) DetNet IP Flow (or simply IP flow)
	(2) DetNet MPLS Flow	(2) DetNet MPLS Flow

	]]>	]]></artwork>
	</artwork>	</figure>
	</figure>	<t>
	<t>	In <xref target="fig_dn_ip_mpls_sn_ex" format="default"/>, "App-flow"
	In <xref target="fig_dn_ip_mpls_sn_ex"/> "App-Flow" indicates the payloa	indicates the payload carried by the DetNet IP data plane. "IP" and
	d carried by	"NProto" indicate the fields described in Sections <xref
	the DetNet IP data plane. "IP" and "NProto" indicate the fields	target="RFC8939" sectionFormat="bare"
	described in Section 5.1.1. (IP Header Information) and Section 5.1.2.	section="5.1.1"/> (IP Header Information) and <xref target="RFC8939"
	(Other Protocol Header Information) of <xref target="I-D.ietf-detnet-ip"	sectionFormat="bare" section="5.1.2"/> (Other
	/>,	Protocol Header Information) of <xref target="RFC8939"
	respectively.	format="default"/>, respectively.


	"App-Flow for MPLS" indicates	"App-flow for MPLS" indicates that an individual DetNet IP
	that an individual DetNet IP flow is the payload from the	flow is the payload from the perspective of the DetNet MPLS
	perspective of the DetNet MPLS data plane defined in <xref	data plane defined in <xref target="RFC8964"
	target="I-D.ietf-detnet-mpls"/>.	format="default"/>.
	</t>	</t>
	<t>
	Per Section 5.1 of <xref target="I-D.ietf-detnet-mpls"/>, the DetNet	<t>
	MPLS data plane uses a single S-Label to support a single app flo	Per <xref target="RFC8964" sectionFormat="of" section="5.1"
	w.	format="default"/>, the DetNet MPLS data plane uses a single
	DetNet IP Flow Identification Procedures in Section 4.4 of	S-Label to support a single App-flow. DetNet IP Flow
	<xref target="I-D.ietf-detnet-ip"/> states that a single DetNet f	Identification Procedures in <xref target="RFC8939"
	low	sectionFormat="of" section="5.1" format="default"/> states that a
	is identified based on IP, and next level protocol, header inform	single DetNet flow is identified based on IP- and next-level
	ation.	protocol header information. <xref target="RFC8939"
	Section 4.4. (Aggregation Considerations) of <xref	sectionFormat="of" section="4.4" format="default"/> (DetNet Flow
	target="I-D.ietf-detnet-ip"/> defines the ways in which aggregation is	Aggregation) defines the ways in which aggregation is supported
	supported through the use of prefixes, wildcards, lists, and port	through the use of prefixes, wildcards, lists, and port ranges.
	ranges. Collectively, this results in the fairly straightforward	Collectively, this results in the fairly straightforward
	procedures defined in the next section.	procedures defined in the next section.
	</t>	</t>
	<t>	<t>
	As shown in <xref target="fig_ip_pw_detnet"/>, DetNet relay nodes	As shown in <xref target="fig_ip_pw_detnet" format="default"/>, DetNet r
		elay nodes
	are responsible for the mapping of a DetNet flow, at the service	are responsible for the mapping of a DetNet flow, at the service
	sub-layer, from the IP to MPLS DetNet data planes and back	sub-layer, from the IP to MPLS DetNet data planes and back
	again. Their related DetNet IP over DetNet MPLS data plane	again. Their related DetNet IP over DetNet MPLS data plane
	operation is comprised of two sets of procedures: the mapping of	operation is comprised of two sets of procedures: the mapping of

	flow identifiers, and ensuring proper traffic treatment.	flow identifiers and ensuring proper traffic treatment.
	</t>	</t>
	<t>	<t>
	Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows.	Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows.
	The six-tuple of IP is mapped to the S-Label in both cases.	The six-tuple of IP is mapped to the S-Label in both cases.
	The various fields may be mapped or ignored when going from IP to MPLS.	The various fields may be mapped or ignored when going from IP to MPLS.

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

	</section>	</section>
		<section anchor="iom-proc" numbered="true" toc="default">
	<section anchor="iom-proc" title="IP over DetNet MPLS Procedures">	<name>DetNet IP over DetNet MPLS Procedures</name>
	<t>	<t>
	The main differences of mapping IP to DetNet MPLS (compared to plain MPL S) are	The main differences of mapping IP to DetNet MPLS (compared to plain MPL S) are
	that (1) there is a mandatory flow identification to make the for warding	that (1) there is a mandatory flow identification to make the for warding
	decision (i.e., forwarding is not based on FEC), (2) the d-CW (De tNet	decision (i.e., forwarding is not based on FEC), (2) the d-CW (De tNet

	Control Word) is mandatory for the MPLS encapsulation and (3) dur	Control Word) is mandatory for the MPLS encapsulation, and
	ing
	forwarding over the DetNet MPLS network DetNet flow specific trea
	tment
	is needed.
	</t>


	<section anchor="iom-ids"	(3) during forwarding over the DetNet MPLS network, treatment specific to
	title="DetNet IP over DetNet MPLS Flow Identification	DetNet flows is needed.
	and Aggregation Procedures">
	<!--
	<t>
	[Editor's note: several proposed changes to clarify referred
	components. Confusing usage of app-flow terminology.]
	</t>	</t>

	-->	<section anchor="iom-ids" numbered="true" toc="default">
		<name>DetNet IP over DetNet MPLS Flow Identification and Aggregation
		Procedures</name>

	<t>	<t>

	A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a	A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over
	DetNet MPLS network	a DetNet MPLS network <bcp14>MUST</bcp14> map a DetNet IP flow, as
	MUST map a DetNet IP flow, as identified in <xref target="I-D.ietf-det	identified in <xref target="RFC8939" format="default"/>, into a
	net-ip"/> into a single MPLS DetNet flow and MUST	single MPLS DetNet flow and <bcp14>MUST</bcp14> process it in
	process it in accordance to the procedures defined in	accordance to the procedures defined in <xref target="RFC8964"
	<xref target="I-D.ietf-detnet-mpls"/>. PRF MAY be	format="default"/>. PRF <bcp14>MAY</bcp14> be supported at the MPLS
	supported at the MPLS level for DetNet IP flows sent over an DetNet MP	level for DetNet IP flows sent over a DetNet MPLS network.
	LS network.	Aggregation <bcp14>MAY</bcp14> be supported as defined in <xref
	Aggregation MAY be supported as defined in <xref	sectionFormat="of" section="4.4" target="RFC8964"
	target="I-D.ietf-detnet-mpls"/> Section 4.4. Aggregation	format="default"/>. Aggregation considerations in <xref
	considerations in <xref target="I-D.ietf-detnet-ip"/> MAY be used to	target="RFC8939" format="default"/> <bcp14>MAY</bcp14> be used to
	identify an individual DetNet IP flow. The provisioning of the	identify an individual DetNet IP flow. The provisioning of the

	mapping of DetNet IP flows to DetNet MPLS flows MUST	mapping of DetNet IP flows to DetNet MPLS flows <bcp14>MUST</bcp14>
	be supported via configuration, e.g., via the controller plane.	be supported via configuration, e.g., via the Controller Plane.
	</t>	</t>
	<t>	<t>

	A DetNet relay node (egress T-PE) MAY be provisioned to handle packets	A DetNet relay node (egress T-PE) <bcp14>MAY</bcp14> be provisioned
	received via the	to handle packets received via the DetNet MPLS data plane as DetNet
	DetNet MPLS data plane as DetNet IP flows. A single incoming DetNet M	IP flows. A single incoming DetNet MPLS flow <bcp14>MAY</bcp14> be
	PLS	treated as a single DetNet IP flow, without examination of IP
	flow MAY be treated as a single DetNet IP flow, without	headers. Alternatively, packets received via the DetNet MPLS data
	examination of IP headers. Alternatively, packets received via the	plane <bcp14>MAY</bcp14> follow the normal DetNet IP flow
	DetNet MPLS data plane MAY follow the normal DetNet IP flow	identification procedures defined in <xref target="RFC8939"
	identification procedures defined in <xref	sectionFormat="of" section="5.1" format="default"/>.
	target="I-D.ietf-detnet-ip"/> Section 5.1.
	</t>	</t>
	<t>	<t>

	An implementation MUST support the provisioning for handling any	An implementation <bcp14>MUST</bcp14> support the provisioning for
	packet flows received via DetNet MPLS data plane as DetNet IP f	handling any packet flows received via the DetNet MPLS data plane as
	lows	DetNet IP flows via configuration. Note that such configuration
	via configuration.	<bcp14>MAY</bcp14> include support from PREOF on the incoming DetNet
	Note that such configuration MAY include support from PREOF on the	MPLS flow.
	incoming DetNet MPLS flow.
	</t>
	<t>
	Note: using Layer-4 (L4) transport protocols e.g., for multipath are
	out of scope of this document both for a single flow and aggreg
	ate
	flows.
	</t>	</t>

		<aside>
		<t>
		Note: Using Layer 4 (L4) transport protocols (e.g., for multipath) are
		out of scope of this document both for a single flow and aggregate
		flows.
		</t>
		</aside>
	</section>	</section>

	<section anchor="iom-svc"	<section anchor="iom-svc" numbered="true" toc="default">
	title="DetNet IP over DetNet MPLS Traffic Treatment Procedures">	<name>DetNet IP over DetNet MPLS Traffic Treatment Procedures</name>
	<t>	<t>
	The traffic treatment required for a particular DetNet IP flow is	The traffic treatment required for a particular DetNet IP flow is

	provisioned via configuration or the controller plane. When a DetNet	provisioned via configuration or the Controller Plane. When a DetNet
	IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure that	IP flow is sent over DetNet MPLS, a DetNet relay node
	the	<bcp14>MUST</bcp14> ensure that the provisioned DetNet IP traffic
	provisioned DetNet IP traffic treatment is provided at the forwarding	treatment is provided at the forwarding sub-layer as described in
	sub-layer as described in <xref target="I-D.ietf-detnet-mpls"/>	<xref target="RFC8964" sectionFormat="of" section="5.2"
	Section 5.2. Note that the PRF function MAY be utilized when sending	format="default"/>. Note that PRF
	IP over MPLS.	<bcp14>MAY</bcp14> be utilized when sending IP over MPLS.
	</t>	</t>
	<t>	<t>

	Traffic treatment for DetNet IP flows received over the DetNet	Traffic treatment for DetNet IP flows received over the DetNet MPLS
	MPLS data plane MUST follow Section 5.3 DetNet IP Traffic	data plane <bcp14>MUST</bcp14> follow <xref target="RFC8939"
	Treatment Procedures in <xref target="I-D.ietf-detnet-ip"/>.	sectionFormat="of" section="5.3" format="default"/> (DetNet IP
		Traffic Treatment Procedures).
	</t>	</t>
	</section>	</section>
	</section>	</section>


	<!-- ===================================================================== -	<section anchor="mc_summary" numbered="true" toc="default">
	->	<name>Management and Control Information Summary</name>

	<section anchor="mc_summary"
	title="Management and Control Information Summary">
	<t>	<t>
	The following summarizes the set of information that is needed to	The following summarizes the set of information that is needed to
	support DetNet IP over DetNet MPLS at the MPLS ingress node:	support DetNet IP over DetNet MPLS at the MPLS ingress node:

	<list style="symbols">
	<t>
	Each MPLS App-Flow is identified using the IP flow
	identification information as defined in <xref
	target="I-D.ietf-detnet-ip"/>. The information is summarized
	in Section 5.1 of that document, and includes all wildcards,
	port ranges and the ability to ignore specific IP fields.
	</t>
	<t>
	The DetNet MPLS service that is to be used to send the
	matching IP traffic. This matching information is
	provided in <xref
	target="I-D.ietf-detnet-mpls"/> Section 5.1, and includes
	both service and traffic delivery information.
	</t>
	</list>
	</t>	</t>

		<ul spacing="normal">

		<li>

		Each MPLS App-Flow is selected from the incoming IP traffic using the IP flow
		identification information defined in <xref target="RFC8939"
		format="default"/>. This information is summarized in Section <xref
		target="RFC8939" sectionFormat="bare" section="5.1"/> of that document and
		includes all wildcards, port ranges, and the ability to ignore specific IP
		fields.

		</li>

		<li>
		The DetNet MPLS service that is to be used to send the matching IP
		traffic. This matching information is provided in <xref
		target="RFC8964" sectionFormat="of" section="5.1"
		format="default"/> and includes both service and traffic delivery
		information.
		</li>
		</ul>
	<t>	<t>
	The following summarizes the set of information that is needed to	The following summarizes the set of information that is needed to
	support DetNet IP over DetNet MPLS at the MPLS egress node:	support DetNet IP over DetNet MPLS at the MPLS egress node:

	<list style="symbols">
	<t>
	S-Label values that are carrying MPLS over IP encapsulated
	traffic.
	</t>
	<t>
	For each S-Label, how the received traffic is to be
	handled. The traffic may be processed according as any other
	DetNet IP traffic as defined in this document or in <xref
	target="I-D.ietf-detnet-ip"/>, or the traffic may be
	directly treated as an MPLS App-flow for additional
	processing according to <xref
	target="I-D.ietf-detnet-mpls"/>.
	</t>
	</list>
	</t>	</t>

		<ul spacing="normal">
		<li>

		The S-Label value that identifies the encapsulated App-flow traffic.

		</li>
		<li>
		For each S-Label, how the received traffic is to be handled. The
		traffic may be processed as any other DetNet IP traffic as defined
		in this document or in <xref target="RFC8939" format="default"/>,
		or the traffic may be directly treated as an MPLS App-flow for
		additional processing according to <xref target="RFC8964"
		format="default"/>.
		</li>
		</ul>
	<t>	<t>

	It is the responsibility of the DetNet controller plane to	It is the responsibility of the DetNet Controller Plane to
	properly provision both flow identification information and	properly provision both flow identification information and
	the flow-specific resources needed to provide the traffic	the flow-specific resources needed to provide the traffic
	treatment to meet each flow's service requirements.	treatment to meet each flow's service requirements.
	This applies for aggregated and individual flows.	This applies for aggregated and individual flows.
	</t>	</t>
	</section>	</section>

	<section title="Security Considerations">	<section numbered="true" toc="default">
	<t>	<name>Security Considerations</name>
		<t>
	General security	General security

	considerations for DetNet are described in detail in <xref	considerations for DetNet are described in detail in <xref target="RFC905
	target="I-D.ietf-detnet-security"/>.	5" format="default"/>.
	DetNet MPLS and DetNet IP security considerations equally apply to this d ocument and	DetNet MPLS and DetNet IP security considerations equally apply to this d ocument and

	are described in <xref target="I-D.ietf-detnet-mpls"/>	are described in <xref target="RFC8964" format="default"/>
	and <xref target="I-D.ietf-detnet-ip"/>.	and <xref target="RFC8939" format="default"/>.
	</t>	</t>
	<t>	<t>

	Security aspects which are unique to DetNet are those whose aim is to	Security aspects that are unique to DetNet are those whose aim is to
	protect the support of specific quality of service aspects of DetNet, whi	protect the support of specific quality-of-service aspects of DetNet, whi
	ch are	ch are
	primarily to deliver data flows with extremely low packet loss rates	primarily to deliver data flows with extremely low packet loss rates
	and bounded end-to-end delivery latency.	and bounded end-to-end delivery latency.

	</t>	</t>
	<t>	<t>
	The primary considerations for the data plane are to maintain	The primary considerations for the data plane are to maintain

	integrity of data and delivery of the associated DetNet service traversi	integrity of data and delivery of the associated DetNet service
	ng	traversing the DetNet network. Application flows can be protected
	the DetNet network.	through whatever means is provided by the underlying technology. For
	Application flows can be protected through whatever means is	example, encryption may be used, such as that provided by IPsec <xref
	provided by the underlying technology. For example, encryption may be	target="RFC4301" format="default"/> for IP flows and/or by an
	used, such as that provided by IPSec <xref target="RFC4301"/> for IP	underlying sub-net using MACsec <xref target="IEEE802.1AE-2018"
	flows and/or by an underlying sub-net using MACSec	format="default"/> for IP-over-Ethernet (Layer 2) flows.
	<xref target="IEEE802.1AE-2018"/> for IP over Ethernet (Layer-2) flows.	</t>
	</t>	<t>
	<t>	From a data plane perspective, this document does not add or modify any
	From a data plane perspective this document does not add or modify any
	header information.	header information.

	</t>	</t>
	<t>
	At the management and control level DetNet flows are identified on a
	per-flow basis, which may provide controller plane
	attackers with additional information about the data flows (when
	compared to controller planes that do not include per-flow identificatio
	n).
	This is an inherent property of DetNet which has security
	implications that should be considered when determining if DetNet is
	a suitable technology for any given use case.
	</t>
	<t>
	To provide uninterrupted availability of the DetNet
	service, provisions can be made against DOS attacks and delay
	attacks. To protect against DOS attacks, excess traffic due to
	malicious or malfunctioning devices can be prevented or mitigated,
	for example through the use of existing mechanism such as policing and s
	haping applied at
	the input of a DetNet domain. To prevent DetNet packets from
	being delayed by an entity external to a DetNet domain, DetNet
	technology definition can allow for the mitigation of
	Man-In-The-Middle attacks, for example through use of
	authentication and authorization of devices within the DetNet domain.
	</t>

	</section>

	<section anchor="iana" title="IANA Considerations">
	<t>	<t>

	This document makes no IANA requests.	At the management and control level, DetNet flows are identified on a
		per-flow basis, which may provide Controller Plane attackers with
		additional information about the data flows (when compared to
		Controller Planes that do not include per-flow identification). This
		is an inherent property of DetNet, which has security implications that
		should be considered when determining if DetNet is a suitable
		technology for any given use case.
	</t>	</t>

	</section>

	<section anchor="acks" title="Acknowledgements">
	<t>	<t>

	The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,	To provide uninterrupted availability of the DetNet service,
	David Black,	provisions can be made against DoS attacks and delay attacks. To
	Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig	protect against DoS attacks, excess traffic due to malicious or
	Gunther,	malfunctioning devices can be prevented or mitigated, for example,
	George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their	through the use of existing mechanisms such as policing and shaping
	various contributions to this work.	applied at the input of a DetNet domain. To prevent DetNet packets
		from being delayed by an entity external to a DetNet domain, DetNet
		technology definitions can allow for the mitigation of
		man-in-the-middle attacks (for example, through use of authentication
		and authorization of devices within the DetNet domain).
	</t>	</t>
	</section>	</section>

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

	RFC7322 limits the number of authors listed on the front page of	This document has no IANA actions.
	a draft to a maximum of 5. The editor wishes to thank and
	acknowledge the follow authors for contributing text to this
	draft.
	</t>	</t>

	<figure> <artwork><![CDATA[	</section>
	Janos Farkas
	Ericsson
	Email: janos.farkas@ericsson.com


	Andrew G. Malis	</middle>
	Malis Consulting	<back>
	Email: agmalis@gmail.com	<references>
	]]></artwork>	<name>References</name>
	</figure>	<references>
	<!-- </section> -->	<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8655.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
		C.8939.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
		C.8938.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
		C.8964.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
		C.9055.xml"/>

		</references>
		<references>
		<name>Informative References</name>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4301.xml"/>


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

		</references>
		</references>

		<section anchor="acks" numbered="false" toc="default">
		<name>Acknowledgements</name>
	<t>	<t>

	Janos Farkas contributed substantially to the content of this	The authors wish to thank <contact fullname="Pat Thaler"/>, <contact
	document.	fullname="Norman Finn"/>, <contact fullname="Loa Andersson"/>, <contact
		fullname="David Black"/>, <contact fullname="Rodney Cummings"/>, <contact
		fullname="Ethan Grossman"/>, <contact fullname="Tal Mizrahi"/>, <contact
		fullname="David Mozes"/>, <contact fullname="Craig Gunther"/>, <contact
		fullname="George Swallow"/>, <contact fullname="Yuanlong Jiang"/>, and
		<contact fullname="Carlos J. Bernardos"/> for their various contributions to
		this work.

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

		<section anchor="contrib" numbered="false" toc="default">
		<name>Contributors</name>
		<t>
		RFC 7322 limits the number of authors listed on the front page to a
		maximum of 5. The editor wishes to thank and acknowledge the following
		authors for contributing text to this document.
		</t>


	</middle>	<author fullname="János Farkas" initials="J." surname="Farkas">
		<organization>Ericsson</organization>
	<back>	<address>
	<references title="Normative references">	<email>janos.farkas@ericsson.com</email>
	<?rfc include="reference.RFC.2119"?>	</address>
	<?rfc include="reference.RFC.8174"?>	</author>
	<?rfc include="reference.RFC.8655"?>
	<?rfc include="reference.I-D.ietf-detnet-data-plane-framework"?>
	<?rfc include="reference.I-D.ietf-detnet-mpls'?>
	<?rfc include="reference.I-D.ietf-detnet-ip'?>
	<?rfc include="reference.I-D.ietf-detnet-security"?>
	</references>


	<references title="Informative references">	<author fullname="Andrew G. Malis" initials="A. G." surname="Malis">
	<?rfc include="reference.RFC.4301"?>	<organization>Malis Consulting</organization>
	<reference anchor="IEEE802.1AE-2018"	<address>
	target="https://ieeexplore.ieee.org/document/8585421">	<email>agmalis@gmail.com</email>
	<front>	</address>
	<title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title>	</author>
	<author>
	<organization>IEEE Standards Association</organization>
	</author>
	<date year="2018" />
	</front>
	</reference>


	</references>	<t>
		<contact fullname="János Farkas"/> contributed substantially to the cont
		ent of this
		document.
		</t>
		</section>

	</back>	</back>
	</rfc>	</rfc>

End of changes. 88 change blocks.
	481 lines changed or deleted	440 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/