rfc9634.original.xml		rfc9634.xml
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="UTF-8"?>
			<!-- pre-edited by ST 03/14/24 -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902
	" docName="draft-ietf-detnet-ip-oam-13" obsoletes="" updates="" submissionType="		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902
	IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true		" docName="draft-ietf-detnet-ip-oam-13" number="9634" consensus="true" obsoletes
	" version="3">		="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3
	<!-- xml2rfc v2v3 conversion 3.6.0 -->		" symRefs="true" sortRefs="true" version="3">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<front>		<front>
	<title abbrev="OAM for DetNet over IP">Operations, Administration, and Maint		<title abbrev="OAM for DetNet over IP">Operations, Administration, and Maint
	enance (OAM) for Deterministic Networks (DetNet) with IP Data Plane</title>		enance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane</title
	<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-ip-oam-13"/>		>
			<!-- [rfced] We have updated the document title along the lines of
			RFC 9546 and other cited RFCs, which define "DetNet" as
			"Deterministic Networking". Please let us know any concerns.
			Original:
			Operations, Administration, and Maintenance (OAM) for Deterministic
			Networks (DetNet) with IP Data Plane
			Currently:
			Operations, Administration, and Maintenance (OAM) for Deterministic
			Networking (DetNet) with the IP Data Plane -->
			<seriesInfo name="RFC" value="9634"/>
	<author initials="G." surname="Mirsky" fullname="Greg Mirsky">		<author initials="G." surname="Mirsky" fullname="Greg Mirsky">
	<organization>Ericsson</organization>		<organization>Ericsson</organization>
	<address>		<address>
	<email>gregimirsky@gmail.com</email>		<email>gregimirsky@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">		<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
	<organization>Huawei</organization>		<organization>Huawei</organization>
	<address>		<address>
	<postal>
	<street/>
	<city/>
	<code/>
	<country/>
	</postal>
	<email>mach.chen@huawei.com</email>		<email>mach.chen@huawei.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="D" surname="Black" fullname="David Black">		<author initials="D." surname="Black" fullname="David Black">
	<organization>Dell EMC</organization>		<organization>Dell EMC</organization>
	<address>		<address>
	<postal>		<postal>
	<street>176 South Street</street>		<street>176 South Street</street>
	<city>Hopkinton, MA</city>		<city>Hopkinton</city><region>MA</region>
	<code>01748</code>		<code>01748</code>
	<country>United States of America</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>david.black@dell.com</email>		<email>david.black@dell.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2024"/>		<date month="August" year="2024"/>
	<area>Routing</area>		<area>RTG</area>
	<workgroup>DetNet Working Group</workgroup>		<workgroup>detnet</workgroup>
	<keyword>Internet-Draft</keyword>
	<keyword>DetNet</keyword>		<keyword>DetNet</keyword>
	<keyword>OAM</keyword>		<keyword>OAM</keyword>
	<abstract>		<abstract>
	<t>		<t>
	This document discusses the use of existing IP Operations,		This document discusses the use of existing IP Operations,
	Administration, and Maintenance protocols and mechanisms in		Administration, and Maintenance protocols and mechanisms in
	Deterministic Networking networks that use the IP data plane.		Deterministic Networking networks that use the IP data plane.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="intro" numbered="true" toc="default">		<section anchor="intro" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	<xref target="RFC8655" format="default"/> introduces and explains Determinist ic Networks (DetNet)		<xref target="RFC8655" format="default"/> introduces and explains the Determi nistic Networking (DetNet)
	architecture.		architecture.
	</t>		</t>
	<t>		<t>
	Operations, Administration, and Maintenance (OAM) protocols are used		Operations, Administration, and Maintenance (OAM) protocols are used
	to detect and localize defects in the network as well as to monitor network		to detect and localize defects in the network as well as to monitor network
	performance. Some OAM functions (e.g., failure detection), work in		performance. Some OAM functions (e.g., failure detection) work in
	the network proactively, while others (e.g., defect localization) are		the network proactively, while others (e.g., defect localization) are
	usually performed on-demand. These tasks are achieved by a combination		usually performed on demand. These tasks are achieved by a combination
	of active and hybrid OAM methods, as defined in <xref target="RFC7799"/>.		of active and hybrid OAM methods, as defined in <xref target="RFC7799"/>.
	</t>		</t>
	<t>		<t>
	<xref target="I-D.ietf-detnet-oam-framework" format="default"/> lists the OAM		<xref target="RFC9551" format="default"/> lists the OAM functional requiremen
	functional requirements		ts
	for DetNet, and defines the principles for OAM use within DetNet		for DetNet and defines the principles for OAM use within DetNet
	networks utilizing the IP data plane. The functional requirements		networks utilizing the IP data plane. The functional requirements
	can be compared against current OAM tools to identify gaps and		can be compared against current OAM tools to identify gaps and
	potential enhancements required to enable proactive and on-demand		potential enhancements required to enable proactive and on-demand
	path monitoring and service validation.		path monitoring and service validation.
	</t>		</t>
	<t>		<t>
	This document discusses the use of existing IP OAM protocols and mechan isms in		This document discusses the use of existing IP OAM protocols and mechan isms in
	DetNet networks that use the IP data plane.		DetNet networks that use the IP data plane.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Conventions used in this document</name>		<name>Conventions Used in This Document</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>		<t>
	The term "DetNet OAM" used in this document interchangeably with longer version		The term "DetNet OAM" as used in this document also means "a set of OAM protocol
	"set of OAM protocols, methods and tools for Deterministic Networks".		s, methods, and tools for Deterministic Networking".
	</t>		</t>
	<t>DetNet: Deterministic Networks</t>		<dl spacing="normal">
	<t>OAM: Operations, Administration, and Maintenance</t>		<dt>DetNet:</dt><dd>Deterministic Networking</dd>
	<t>ICMP: Internet Control Message Protocol</t>		<dt>OAM:</dt><dd>Operations, Administration, and Maintenance</dd>
	<t>Underlay Network or Underlay Layer: The network that provides		<dt>ICMP:</dt><dd>Internet Control Message Protocol</dd>
	connectivity between DetNet nodes. MPLS networks providing LSP		<dt>Underlay Network or Underlay Layer:</dt><dd>The network that provide
			s
			connectivity between DetNet nodes. MPLS networks providing Label Switched Pa
			th (LSP)
	connectivity between DetNet nodes are an example of the DetNet IP network und erlay		connectivity between DetNet nodes are an example of the DetNet IP network und erlay
	layer.</t>		layer.</dd>
	<t>DetNet Node: a node that is an actor in the DetNet domain. DetNet
			<!-- [rfced] Section 2.1: We defined "LSP" as "Label Switched Path"
			per RFC 9546. If this is incorrect, please provide the correct
			definition of "LSP".
			Original:
			MPLS networks providing LSP
			connectivity between DetNet nodes are an example of the DetNet IP
			network underlay layer.
			Currently:
			MPLS networks providing Label
			Switched Path (LSP) connectivity between DetNet nodes are an
			example of the DetNet IP network underlay layer. -->
			<dt>DetNet Node:</dt><dd>A node that is an actor in the DetNet domain.
			DetNet
	domain edge nodes and nodes that perform the Packet Replication and Eliminati on Function within the domain are		domain edge nodes and nodes that perform the Packet Replication and Eliminati on Function within the domain are
	examples of a DetNet node.</t>		examples of a DetNet node.</dd>
	</section>
	<!--		<!-- [rfced] Section 2.1: Does "Packet Replication and Elimination
	<section numbered="true" toc="default">		Function" mean "Packet Replication, Elimination, and Ordering
	<name>Keywords</name>		Functions" (as used in RFC 9546 and Section 3.3 of this document),
	<t>		"Packet Replication Function", "Packet Elimination and Replication
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		Functions", or something else?
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", and "OPTIONAL" in this document are to be interpreted as		Original:
	described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="R		DetNet
	FC8174" format="default"/>		domain edge nodes and nodes that perform the Packet Replication and
	when, and only when, they appear in all capitals, as shown here.		Elimination Function within the domain are examples of a DetNet node. -->
	</t>
			</dl>
	</section>		</section>
	-->
	</section>		</section>
	<section anchor="oam-data-plane" numbered="true" toc="default">		<section anchor="oam-data-plane" numbered="true" toc="default">
	<name>Active OAM for DetNet Networks with the IP Data Plane</name>		<name>Active OAM for DetNet Networks with the IP Data Plane</name>
	<t>		<t>
	OAM protocols and mechanisms act within the data plane of the particular network ing layer.		OAM protocols and mechanisms act within the data plane of the particular network ing layer.
	Thus, it is critical that the data plane encapsulation supports OAM mechanisms a nd enables them to be		Thus, it is critical that the data plane encapsulation support OAM mechanisms an d enable them to be
	configured so that DetNet OAM packets follow the same path		configured so that DetNet OAM packets follow the same path
	(unidirectional or bidirectional) through the network and receive		(unidirectional or bidirectional) through the network and receive
	the same forwarding treatment in the DetNet forwarding sub-layer		the same forwarding treatment in the DetNet forwarding sub-layer
	as the DetNet flow being monitored.		as the DetNet flow being monitored.
	</t>		</t>
	<t>		<t>
	The DetNet data plane encapsulation in a transport network with IP encapsulation s is specified		The DetNet data plane encapsulation in a transport network with IP encapsulation s is specified
	in Section 6 of <xref target="RFC8939" format="default"/>.		in <xref target="RFC8939" sectionFormat="of" section="6"/>.
	For the IP underlay network, DetNet flows are identified		For the IP underlay network, DetNet flows are identified
	by the ordered match to the provisioned information set that, among other elemen ts, includes the IP protocol, source port number,		by the ordered match to the provisioned information set that, among other elemen ts, includes the IP protocol type, source port number, and
	destination port number. Active IP OAM		destination port number. Active IP OAM
	protocols like Bidirectional Forwarding Detection (BFD) <xref target="RFC5880" f		protocols like Bidirectional Forwarding Detection (BFD) <xref target="RFC5880" f
	ormat="default"/> or		ormat="default"/> or the
	Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762" format		Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762" format
	="default"/>,		="default"/>
	use UDP transport and the well-known UDP port numbers as the destination port.		use UDP transport and the well-known UDP port numbers as the destination port.
	For BFD, the UDP destination port is specific to the BFD variant,		For BFD, the UDP destination port is specific to the BFD variant,
	e.g., Multihop BFD uses port 4784 <xref target="RFC5883"/>.		e.g., multihop BFD uses port 4784 <xref target="RFC5883"/>.
			<!-- [rfced] Section 3: This sentence reads oddly, as it seems to
			mix both singular and plural. Should "the well-known UDP port
			numbers" be "the well-known UDP port number", or should "the
			destination port" be "the destination ports"?
			Original:
			Active
			IP OAM protocols like Bidirectional Forwarding Detection (BFD)
			[RFC5880] or Simple Two-way Active Measurement Protocol (STAMP)
			[RFC8762], use UDP transport and the well-known UDP port numbers as
			the destination port. -->
	</t>		</t>
	<t>		<t>
	Thus a DetNet node must be		Thus, a DetNet node must be
	able to associate an IP DetNet flow with the particular test session to ensure t hat test packets experience the		able to associate an IP DetNet flow with the particular test session to ensure t hat test packets experience the
	same treatment as the DetNet flow packets. For example, in a network where path selection and DetNet functionality		same treatment as the DetNet flow packets. For example, in a network where path selection and DetNet functionality
	are based on 3-tuples (destination and source IP addresses		are based on 3-tuples (destination and source IP addresses
	in combination with the Differentiated Services Code Point value) that assoc iation can be achieved		in combination with the Differentiated Services Code Point value), that assoc iation can be achieved
	by having the OAM traffic use the same 3-tuple as the monitored		by having the OAM traffic use the same 3-tuple as the monitored
	IP DetNet flow.		IP DetNet flow.
	In such a scenario, an IP OAM session between the same pair of IP nodes would sh are the network treatment		In such a scenario, an IP OAM session between the same pair of IP nodes would sh are the network treatment
	with the monitored IP DetNet flow regardless of whether ICMP, BFD, or STAMP prot ocol is used.		with the monitored IP DetNet flow regardless of whether ICMP, BFD, or STAMP is u sed.
	</t>		</t>
	<t>		<t>
	In IP networks, the majority of on-demand failure detection and localization is achieved through the use		In IP networks, the majority of on-demand failure detection and localization is achieved through the use
	of the Internet Control Message Protocol (ICMP), utilizing Echo Request and Echo Reply messages,		of ICMP, utilizing Echo Request and Echo Reply messages,
	along with a set of defined error messages such as Destination Unreachable, whic h provide detailed information through assigned code points.		along with a set of defined error messages such as Destination Unreachable, whic h provide detailed information through assigned code points.
	<xref target="RFC0792"/> and <xref target="RFC4443"/> define the ICMP for IPv4 a nd IPv6 networks, respectively.		<xref target="RFC0792"/> and <xref target="RFC4443"/> define ICMP for IPv4 and I Pv6 networks, respectively.
	To utilize ICMP effectively for these purposes within DetNet, DetNet nodes must establish the association		To utilize ICMP effectively for these purposes within DetNet, DetNet nodes must establish the association
	of ICMP traffic between DetNet nodes with IP DetNet traffic. This entails ensuri ng that such		of ICMP traffic between DetNet nodes with IP DetNet traffic. This entails ensuri ng that such
	ICMP traffic traverses the same interfaces and receives identical QoS treatment as the monitored DetNet IP flow.		ICMP traffic traverses the same interfaces and receives QoS treatment that is id entical to the monitored DetNet IP flow.
	Failure to do so may result in ICMP being unable to detect and localize failures specific to the DetNet IP data plane.		Failure to do so may result in ICMP being unable to detect and localize failures specific to the DetNet IP data plane.
	</t>		</t>
	<section anchor="native-ip-section" numbered="true" toc="default">		<section anchor="native-ip-section" numbered="true" toc="default">
	<name>Mapping Active OAM and IP DetNet flows</name>		<name>Mapping Active OAM and IP DetNet Flows</name>
	<t>		<t>
	IP OAM protocols are used to detect failures (e.g., BFD <xref target="RFC5880"/> )		IP OAM protocols are used to detect failures (e.g., BFD <xref target="RFC5880"/> )
	and performance degradation (e.g., STAMP <xref target="RFC8762"/>) that affect a n IP DetNet flow.		and performance degradation (e.g., STAMP <xref target="RFC8762"/>) that affect a n IP DetNet flow.
	It is essential to ensure that specially constructed OAM packets traverse the sa me set of nodes and links		It is essential to ensure that specially constructed OAM packets traverse the sa me set of nodes and links
	and receive the same network QoS treatment as the monitored data flow, e.g., a D etNet flow, for making active OAM useful.		and receive the same network QoS treatment as the monitored data flow, e.g., a D etNet flow, for making active OAM useful.
	When the UDP destination port		When the UDP destination port
	number used by the OAM protocol is assigned by IANA, then judicious		number used by the OAM protocol is assigned by IANA, judicious
	selection of the UDP source port may be able to achieve co-routedness		selection of the UDP source port may help achieve co-routedness
	of OAM with the monitored IP DetNet flow in multipath environments,		of OAM with the monitored IP DetNet flow in multipath environments,
	e.g., Link Aggregation Group or Equal Cost Multipath, via use of a		e.g., Link Aggregation Group or Equal Cost Multipath, via the use of a
	UDP source port value that results in the OAM traffic and the		UDP source port value that results in the OAM traffic and the
	monitored IP DetNet flow hashing to the same path based on the packet		monitored IP DetNet flow hashing to the same path based on the packet
	header hashes used for path selection. This does assume that forwarding		header hashes used for path selection. This does assume that forwarding
	equipment along the multipath makes consistent hashing decisions, which		equipment along the multipath makes consistent hashing decisions, which
	might not always be true in a heterogeneous environment.		might not always be true in a heterogeneous environment.
	(That also applies to encapsulation techniques described in <xref target="ip-udp		(That also applies to the encapsulation techniques described in
	-section"/> and <xref target="detnet-udp-section"/>.)		Sections&nbsp;<xref target="ip-udp-section" format="counter"/> and <xref target=
			"detnet-udp-section" format="counter"/>.)
	To ensure the accuracy of OAM results in detecting failures and		To ensure the accuracy of OAM results in detecting failures and
	monitoring the performance of IP DetNet, it is essential that test packets not o nly traverse the same path as the monitored IP DetNet flow		monitoring the performance of IP DetNet, it is essential that test packets not o nly traverse the same path as the monitored IP DetNet flow
	but also receive the same treatment by the nodes, e.g., shaping, filtering, poli cing, and availability of the pre-allocated resources,		but also receive the same treatment by the nodes, e.g., shaping, filtering, poli cing, and availability of the pre-allocated resources,
	as experienced by the IP DetNet packet. That correlation between the particular IP OAM session and the monitored IP DetNet flow		as experienced by the IP DetNet packet. That correlation between the particular IP OAM session and the monitored IP DetNet flow
	can be achieved by using DetNet provisioning information (e.g., <xref target="I-		can be achieved by using DetNet provisioning information (e.g., <xref target="RF
	D.ietf-detnet-yang"/>). Each IP OAM protocol session		C9633"/>). Each IP OAM protocol session
	is presented as a DetNet Application with related service and forwarding sub-lay		is presented as a DetNet application with related service and forwarding sub-lay
	ers. The forwarding sub-layer of the IP OAM session		ers. The forwarding sub-layer of the IP OAM session
	is identical to the forwarding sub-layer of the monitored IP DetNet flow, except for information		is identical to the forwarding sub-layer of the monitored IP DetNet flow, except for information
	in the grouping ip-header, defined in <xref target="I-D.ietf-detnet-yang"/>.		in the "ip-header" grouping item as defined in <xref target="RFC9633"/>.
	<!--
			<!-- [rfced] Section 3.1: We had trouble following what "for making
			active OAM useful" applies to. If the suggested text is not correct,
			please provide clarifying text.
			Original:
			It is essential to ensure that specially constructed
			OAM packets traverse the same set of nodes and links and receive the
			same network QoS treatment as the monitored data flow, e.g., a DetNet
			flow, for making active OAM useful.
			Suggested:
			For active OAM to be useful, it is essential to ensure that
			specially constructed OAM packets traverse the same set of nodes and
			links and receive the same network QoS treatment as the monitored
			data flow, e.g., a DetNet flow. -->
	</t>		</t>
	</section>		</section>
	<section anchor="ip-udp-section" numbered="true" toc="default">		<section anchor="ip-udp-section" numbered="true" toc="default">
	<name>Active OAM Using IP-in-UDP Encapsulation</name>		<name>Active OAM Using IP-in-UDP Encapsulation</name>
	<t>		<t>
	As described above, active IP OAM is realized through several protocols. Some pr otocols use UDP transport,		As described above, active IP OAM is realized through several protocols. Some pr otocols use UDP transport,
	while ICMP is a network-layer protocol. The amount of operational work mapping I P OAM protocols		while ICMP is a network-layer protocol. The amount of operational work mapping I P OAM protocols
	to the monitored DetNet flow can be reduced by using an IP/UDP tunnel to carry I P test packets (<xref target="RFC2003"/>).		to the monitored DetNet flow can be reduced by using an IP/UDP tunnel to carry I P test packets <xref target="RFC2003"/>.
	Then, to ensure that OAM packets traverse the same set of nodes and links, the I P/UDP tunnel		Then, to ensure that OAM packets traverse the same set of nodes and links, the I P/UDP tunnel
	must be mapped to the monitored DetNet flow. Note that the DetNet domain for the		must be mapped to the monitored DetNet flow. Note that in such a case, the DetNe
	test packet		t domain for the test packet
	is seen as a single IP link in such a case. As a result, transit DetNet IP nodes		is seen as a single IP link. As a result, transit DetNet IP nodes cannot be trac
	cannot be traced		ed
	using the usual traceroute procedure, and a modification of the traceroute may b e required.		using the usual traceroute procedure, and a modification of the traceroute may b e required.
			<!-- [rfced] Section 3.2: We couldn't verify this citation, as we
			don't see "test packets" or "test" mentioned in RFC 2003. Would it
			help to rephrase as suggested?
			Original:
			The amount of operational work mapping IP
			OAM protocols to the monitored DetNet flow can be reduced by using an
			IP/UDP tunnel to carry IP test packets ([RFC2003]).
			Suggested (move the citation):
			The amount of operational work mapping IP
			OAM protocols to the monitored DetNet flow can be reduced by using an
			IP/UDP tunnel [RFC2003] to carry IP test packets. -->
	</t>		</t>
	</section>		</section>
	<section anchor="detnet-udp-section" numbered="true" toc="default">		<section anchor="detnet-udp-section" numbered="true" toc="default">
	<name>Active OAM Using DetNet-in-UDP Encapsulation</name>		<name>Active OAM Using DetNet-in-UDP Encapsulation</name>
	<t>		<t>
	Active OAM in IP DetNet can be realized using DetNet-in-UDP encapsulation.		Active OAM in IP DetNet can be realized using DetNet-in-UDP encapsulation.
	Using DetNet-in-UDP tunnel between IP DetNet nodes ensures that active OAM tes t packets follow the same path through		Using a DetNet-in-UDP tunnel between IP DetNet nodes ensures that active OAM tes t packets follow the same path through
	the network as the monitored IP DetNet flow packets and receive		the network as the monitored IP DetNet flow packets and receive
	the same forwarding treatment in the DetNet forwarding sub-layer		the same forwarding treatment in the DetNet forwarding sub-layer
	(see Section 4.1.2 of <xref target="RFC8655"/>) as the IP DetNet flow		(see <xref target="RFC8655" sectionFormat="of" section="4.1.2"/>)
			as the IP DetNet flow
	being monitored.		being monitored.
	</t>		</t>
	<t>		<t>
	<xref target="I-D.ietf-detnet-mpls-over-ip-preof"/> describes how DetNet with MP		<xref target="RFC9566"/> describes how DetNet with the MPLS-over-UDP/IP data pla
	LS over UDP/IP data plane <xref target="RFC9025"/> can be used		ne <xref target="RFC9025"/> can be used
	to support Packet Replication, Elimination, and Ordering Functions to potentiall		to support Packet Replication, Elimination, and Ordering Functions (PREOF) to po
	y lower packet loss, improve the probability of on-time packet delivery		tentially lower packet loss, improve the probability of on-time packet delivery,
	and ensure in-order packet delivery in IP DetNet's service sub-layer. To ensure that an active OAM test packet follows the path of the monitored		and ensure in-order packet delivery in IP DetNet's service sub-layer. To ensure that an active OAM test packet follows the path of the monitored
	DetNet flow in the DetNet service sub-layer the encapsulation shown in <xref tar get="ip-detnet-udp-oam"/> is used.		DetNet flow in the DetNet service sub-layer, the encapsulation shown in <xref ta rget="ip-detnet-udp-oam"/> is used.
	</t>		</t>
	<figure anchor="ip-detnet-udp-oam">		<figure anchor="ip-detnet-udp-oam">
	<name>DetNet Associated Channel Header Format</name>		<name>DetNet Associated Channel Header Format</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[ +---------
	+---------------------------------+		------------------------+
	| |		| |
	| DetNet App-Flow |		| DetNet App-Flow |
	| (original IP) Packet |		| (original IP) Packet |
	| |		| |
	+---------------------------------+ <--\		+---------------------------------+ <--\
	| DetNet ACH | |		| DetNet ACH | |
	+---------------------------------+ +--> PREOF capable		+---------------------------------+ +--> PREOF-capable
	| Service-ID (S-Label) | | DetNet IP data		| Service-ID (S-Label) | | DetNet IP data
	+---------------------------------+ | plane encapsulation		+---------------------------------+ | plane encapsulation
	| UDP Header | |		| UDP Header | |
	+---------------------------------+ |		+---------------------------------+ |
	| IP Header | |		| IP Header | |
	+---------------------------------+ <--/		+---------------------------------+ <--/
	| Data-Link |		| Data-Link |
	+---------------------------------+		+---------------------------------+
	| Physical |		| Physical |
	+---------------------------------+		+---------------------------------+
	skipping to change at line 245 ¶		skipping to change at line 312 ¶
	| Service-ID (S-Label) | | DetNet IP data		| Service-ID (S-Label) | | DetNet IP data
	+---------------------------------+ | plane encapsulation		+---------------------------------+ | plane encapsulation
	| UDP Header | |		| UDP Header | |
	+---------------------------------+ |		+---------------------------------+ |
	| IP Header | |		| IP Header | |
	+---------------------------------+ <--/		+---------------------------------+ <--/
	| Data-Link |		| Data-Link |
	+---------------------------------+		+---------------------------------+
	| Physical |		| Physical |
	+---------------------------------+		+---------------------------------+
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>		<t>
	where:		Where:
	</t>		</t>
	<ul empty="true">		<t indent="3">DetNet ACH is the DetNet Associated Channel Header defined
	<li>DetNet ACH is the DetNet Associated Channel Header defined in <xref		in <xref target="RFC9546"/>.</t>
	target="I-D.ietf-detnet-mpls-oam"/>.</li>		<t indent="3">PREOF if DetNet service sub-layer defined in <xref target=
	<li>PREOF - Packet Replication, Elimination, and Ordering Functions if D		"RFC8655"/>.</t>
	etNet service sub-layer defined in <xref target="RFC8655"/>.</li>
	</ul>		<!-- [rfced] Section 3.3: This sentence/phrase does not parse; it
			appears that some words are missing. If the suggested text is not
			correct, please clarify what "if" refers to.
			Original (the previous entry is included for context):
			DetNet ACH is the DetNet Associated Channel Header defined in
			[I-D.ietf-detnet-mpls-oam].
			PREOF - Packet Replication, Elimination, and Ordering Functions if
			DetNet service sub-layer defined in [RFC8655].
			Suggested:
			DetNet ACH is the DetNet Associated Channel Header defined in
			[RFC9546].
			PREOF is used for the DetNet service sub-layer as defined in
			[RFC8655]. -->
	</section>		</section>
	<section anchor="over-gre-section" numbered="true" toc="default">		<section anchor="over-gre-section" numbered="true" toc="default">
	<name>The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation</n ame>		<name>The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation</n ame>
	<t>		<t>
	<xref target="RFC8086" format="default"/> has defined the method of encapsulatin g GRE (Generic Routing Encapsulation) headers		<xref target="RFC8086" format="default"/> has defined the method of encapsulatin g GRE (Generic Routing Encapsulation) headers
	in UDP. GRE-in-UDP encapsulation can be used for IP DetNet OAM as it eases the t		in UDP. GRE-in-UDP encapsulation can be used for IP DetNet OAM, as it eases the
	ask of mapping an OAM test session		task of mapping an OAM test session
	to a particular IP DetNet flow that is identified by N-tuple. Matching a GRE-in-		to a particular IP DetNet flow that is identified by an N-tuple. Matching a GRE-
	UDP tunnel to the monitored IP DetNet flow		in-UDP tunnel to the monitored IP DetNet flow
	enables the use of Y.1731/G.8013 <xref target="ITU-T.1731" format="default"/> as		enables the use of Y.1731/G.8013 <xref target="ITU.Y1731" format="default"/> as
	a comprehensive toolset of OAM. The Protocol Type field		a comprehensive toolset of OAM. The Protocol Type field
	in GRE header must be set to 0x8902, assigned by IANA to IEEE 802.1ag Connectivi		in the GRE header must be set to 0x8902, assigned by IANA to the IEEE 802.1ag Co
	ty Fault Management (CFM) Protocol / ITU-T Recommendation Y.1731.		nnectivity Fault Management (CFM) protocol / ITU-T Recommendation Y.1731.
	Y.1731/G.8013 supports the necessary functions required for IP DetNet OAM, i.e.,		Y.1731/G.8013 supports the necessary functions required for IP DetNet OAM, i.e.,
	continuity check, one-way packet loss and packet delay measurement.		continuity checks, one-way packet loss, and packet delay measurements.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<!--
	<section anchor="hybrid-oam" title="Use of Hybrid OAM in DetNet">
	<t>Hybrid OAM methods are used in performance monitoring and defined in <xref ta
	rget="RFC7799"/> as:
	<list>
	<t>Hybrid Methods are Methods of Measurement that use a combination of
	Active Methods and Passive Methods.</t>
	</list>
	A hybrid measurement method may produce metrics as close to passive,
	but it still alters something in a data packet even if that is the value of a
	designated field in the packet encapsulation. One example of such a hybrid me
	asurement method
	is the Alternate Marking method (AMM) described in <xref target="RFC8321"/>.
	One of the advantages
	of the use of AMM in a DetNet domain with the IP data plane is that the marki
	ng is applied to a data flow,
	thus ensuring that measured metrics are directly applicable to the DetNet flo
	w.
	</t>
	</section>
	<section anchor="ip-over-tsn-sec" numbered="true" toc="default">		<section anchor="ip-over-tsn-sec" numbered="true" toc="default">
	<name>Active OAM for DetNet IP Interworking with OAM of non-IP DetNet doma ins</name>		<name>Active OAM for DetNet IP Interworking with OAM for Non-IP DetNet Domai ns</name>
	<t>		<t>
	A domain in which IP data plane provides DetNet service could be used		A domain in which the IP data plane provides DetNet service could be used
	in conjunction with a TSN and a DetNet domain with MPLS data plane to deliver en		in conjunction with a Time-Sensitive Networking (TSN) network and a DetNet domai
	d-to-end service.		n with the MPLS data plane to deliver end-to-end service.
	In such scenarios, the ability to detect defects and monitor performance using O AM is essential.		In such scenarios, the ability to detect defects and monitor performance using O AM is essential.
	<xref target="I-D.ietf-detnet-mpls-oam" format="default"/> identified two OAM in		<xref target="RFC9546" format="default"/> identifies two OAM interworking models
	terworking models - peering and tunneling.		-- peering and tunneling.
	Interworking between DetNet domains with IP and MPLS data planes analyzed in Sec		Interworking between DetNet domains with IP and MPLS data planes is analyzed in
	tion 4.2 of <xref target="I-D.ietf-detnet-mpls-oam" format="default"/>.		<xref target="RFC9546" sectionFormat="of" section="4.2"/>.
	In addition, OAM interworking requirements and recommendations that apply		In addition, OAM interworking requirements and recommendations that apply
	between a DetNet Domain with the MPLS dataplane and an adjacent TSN		between a DetNet domain with the MPLS data plane and an adjacent TSN
	network also apply between a DetNet domain with the IP dataplane and		network also apply between a DetNet domain with the IP data plane and
	an adjacent TSN network.		an adjacent TSN network.
	</t>		</t>
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>		<t>
	This document does not have any requests for IANA allocation. This section can be deleted before the publication of the draft.		This document has no IANA actions.
	</t>		</t>
	</section>		</section>
	<section anchor="security-considerations" numbered="true" toc="default">		<section anchor="security-considerations" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	This document describes the applicability of the existing Fault Management an d		This document describes the applicability of the existing Fault Management an d
	Performance Monitoring IP OAM protocols.		Performance Monitoring IP OAM protocols.
	It does not raise any security concerns or issues in addition to ones common to networking or		It does not raise any security concerns or issues in addition to those common to networking or
	already documented in <xref target="RFC0792"/>, <xref target="RFC4443"/>, <xr ef target="RFC5880"/>,		already documented in <xref target="RFC0792"/>, <xref target="RFC4443"/>, <xr ef target="RFC5880"/>,
	and <xref target="RFC8762"/> for the referenced DetNet and OAM protocols.		and <xref target="RFC8762"/> for the referenced DetNet and OAM protocols.
	</t>		</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<!-- References split into informative and normative -->
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<!--		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		792.xml"/>
	FC.2119.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		443.xml"/>
	FC.8174.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	-->		086.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.0792.xml"/>		655.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.4443.xml"/>		<!-- draft-ietf-detnet-mpls-oam-15 (RFC 9546; published) -->
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	FC.8086.xml"/>		546.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8655.xml"/>		939.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-de		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	tnet-mpls-oam.xml"/>		025.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	FC.8939.xml"/>		003.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.9025.xml"/>		<!-- draft-ietf-detnet-yang (RFC YYY1)
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		Note: Title updated per YANG Doctors; should be OK. In AUTH48 as of 8/19/24
	FC.2003.xml"/>		-->
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-		<reference anchor="RFC9633" target="https://www.rfc-editor.org/info/rfc9633">
	detnet-yang.xml"/>		<front>
	<!--		<title>Deterministic Networking (DetNet) YANG Data Model</title>
	<?rfc include="reference.RFC.6310"?>		<author initials="X." surname="Geng" fullname="Xuesong Geng">
	<?rfc include="reference.RFC.7023"?>		<organization>Huawei Technologies</organization>
	<?rfc include="reference.I-D.ietf-detnet-ip-over-mpls"?>		</author>
	<?rfc include="reference.I-D.ietf-detnet-ip-over-tsn"?>		<author initials="Y." surname="Ryoo" fullname="Yeoncheol Ryoo">
	-->		<organization>ETRI</organization>
			</author>
			<author initials="D." surname="Fedyk" fullname="Don Fedyk">
			<organization>LabN Consulting, L.L.C.</organization>
			</author>
			<author initials="R." surname="Rahman" fullname="Reshad Rahman">
			<organization>Equinix</organization>
			</author>
			<author initials="Z." surname="Li" fullname="Zhenqiang Li">
			<organization>China Mobile</organization>
			</author>
			<date month="August" year="2024" />
			</front>
			<seriesInfo name="RFC" value="9633"/>
			<seriesInfo name="DOI" value="10.17487/RFC9633"/>
			</reference>
	</references>		</references>
	<references>		<references>
	<name>Informational References</name>		<name>Informative References</name>
	<reference anchor="ITU-T.1731">
			<reference anchor="ITU.Y1731">
	<front>		<front>
	<title>Operations, administration and maintenance (OAM) functions an d mechanisms for Ethernet-based networks</title>		<title>Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks</title>
	<author>		<author>
	<organization>ITU-T</organization>		<organization>ITU-T</organization>
	</author>		</author>
	<date month="August" year="2015"/>		<date month="June" year="2023"/>
	</front>		</front>
	<seriesInfo name="ITU-T" value="G.8013/Y.1731"/>		<seriesInfo name="ITU-T Recommendation" value="G.8013/Y.1731"/>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.7799.xml"/>		<!-- [rfced] References: The August 2015 version of this
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		specification is marked "Superseded" on
	FC.8762.xml"/>		<https://www.itu.int/rec/T-REC-G.8013/en>. As the citation in
	<!-- <?rfc include="reference.RFC.8321"?> -->		Section 3.4 appears to be general in nature, we updated this listing
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5		per RFC 9546 accordingly. Please let us know any concerns.
	880.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5		Original:
	883.xml"/>		[ITU-T.1731]
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-de		ITU-T, "Operations, administration and maintenance (OAM)
	tnet-oam-framework.xml"/>		functions and mechanisms for Ethernet-based networks",
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-det		ITU-T G.8013/Y.1731, August 2015.
	net-mpls-over-ip-preof.xml"/>
			Currently:
			[ITU.Y1731]
			ITU-T, "Operation, administration and maintenance (OAM)
			functions and mechanisms for Ethernet-based networks",
			ITU-T Recommendation G.8013/Y.1731, June 2023. -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			799.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			762.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
			80.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
			83.xml"/>
			<!-- draft-ietf-detnet-oam-framework (RFC 9551; published) -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
			51.xml"/>
			<!-- ietf-detnet-mpls-over-ip-preof (RFC 9566; published) -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
			66.xml"/>
	</references>		</references>
	</references>		</references>
	</back>		</back>
			<!-- [rfced] Please review the "Inclusive Language" portion of the
			online Style Guide at
			<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
			and let us know if any changes are needed.
			Note that our script did not flag any words in particular, but this
			should still be reviewed as a best practice. -->
	</rfc>		</rfc>
End of changes. 63 change blocks.
	194 lines changed or deleted		306 lines changed or added
This html diff was produced by rfcdiff 1.48.