rfc9566.original		rfc9566.txt
	DetNet B. Varga		Internet Engineering Task Force (IETF) B. Varga
	Internet-Draft J. Farkas		Request for Comments: 9566 J. Farkas
	Intended status: Informational Ericsson		Category: Informational Ericsson
	Expires: 25 August 2024 A. Malis		ISSN: 2070-1721 A. Malis
	Malis Consulting		Malis Consulting
	22 February 2024		April 2024
	Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP		Deterministic Networking (DetNet) Packet Replication, Elimination, and
	draft-ietf-detnet-mpls-over-ip-preof-11		Ordering Functions (PREOF) via MPLS over UDP/IP
	Abstract		Abstract
	This document describes how DetNet IP data plane can support the		This document describes how the DetNet IP data plane can support the
	Packet Replication, Elimination, and Ordering Functions (PREOF) built		Packet Replication, Elimination, and Ordering Functions (PREOF) built
	on the existing MPLS PREOF solution defined for DetNet MPLS Data		on the existing MPLS PREOF solution defined for the DetNet MPLS data
	Plane and the mechanisms defined by MPLS-over-UDP technology.		plane and the mechanisms defined by MPLS-over-UDP technology.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are candidates for any level of Internet
			Standard; see Section 2 of RFC 7841.
	This Internet-Draft will expire on 25 August 2024.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9566.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology
	2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3		2.1. Terms Used in This Document
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations
	3. Requirements for adding PREOF to DetNet IP . . . . . . . . . 4		3. Requirements for Adding PREOF to DetNet IP
	4. Adding PREOF to DetNet IP . . . . . . . . . . . . . . . . . . 4		4. Adding PREOF to DetNet IP
	4.1. Solution Basics . . . . . . . . . . . . . . . . . . . . . 4		4.1. Solution Basics
	4.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Encapsulation
	4.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 5		4.3. Packet Processing
	4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 6		4.4. Flow Aggregation
	4.5. PREOF Processing . . . . . . . . . . . . . . . . . . . . 7		4.5. PREOF Processing
	4.6. PREOF capable DetNet IP domain . . . . . . . . . . . . . 8		4.6. PREOF-Capable DetNet IP Domain
	5. Control and Management Plane Parameters . . . . . . . . . . . 8		5. Control and Management Plane Parameters
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		8. References
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		8.1. Normative References
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		8.2. Informative References
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses
	1. Introduction		1. Introduction
	The DetNet Working Group has defined Packet Replication (PRF), Packet		The DetNet Working Group has defined Packet Replication (PRF), Packet
	Elimination (PEF) and Packet Ordering (POF) functions (represented as		Elimination (PEF), and Packet Ordering (POF) Functions (represented
	PREOF) to provide service protection by the DetNet service sub-layer		as PREOF) to provide service protection by the DetNet service sub-
	[RFC8655]. The PREOF service protection method relies on copies of		layer [RFC8655]. The PREOF service protection method relies on
	the same packet sent over multiple maximally disjoint paths and uses		copies of the same packet sent over multiple maximally disjoint paths
	sequencing information to eliminate duplicates. A possible		and uses sequencing information to eliminate duplicates. A possible
	implementation of the PRF and PEF functions is described in		implementation of PRF and PEF is described in [IEEE8021CB], and the
	[IEEE8021CB] and the related YANG data model is defined in		related YANG data model is defined in [IEEE8021CBcv]. A possible
	[IEEEP8021CBcv]. A possible implementation of the POF function is		implementation of POF is described in [RFC9550]. Figure 1 shows a
	described in [I-D.ietf-detnet-pof]. Figure 1 shows a DetNet flow on		DetNet flow on which PREOF are applied during forwarding from the
	which PREOF functions are applied during forwarding from the source		source to the destination.
	to the destination.
	+------------+		+------------+
	+---------------E1---+ | |		+---------------E1---+ | |
	+---+ | | +---R3---+ | +---+		+---+ | | +---R3---+ | +---+
	|src|------R1 +---+ | E3----O----+dst|		|src|------R1 +---+ | E3----O----+dst|
	+---+ | | E2-------+ +---+		+---+ | | E2-------+ +---+
	+----------R2 |		+----------R2 |
	+-----------------+		+-----------------+
	R: replication function (PRF)		R: Replication Function (PRF)
	E: elimination function (PEF)		E: Elimination Function (PEF)
	O: ordering function (POF)		O: Ordering Function (POF)
	Figure 1: PREOF scenario in a DetNet network		Figure 1: PREOF Scenario in a DetNet Network
	In general, the use of PREOF functions require sequencing information		In general, the use of PREOF require sequencing information to be
	to be included in the packets of a DetNet compound flow. This can be		included in the packets of a DetNet compound flow. This can be done
	done by adding a sequence number or time stamp as part of DetNet		by adding a sequence number or timestamp as part of DetNet
	encapsulation. Sequencing information is typically added once, at or		encapsulation. Sequencing information is typically added once, at or
	close to the source.		close to the source.
	The DetNet MPLS data plane [RFC8964] specifies how sequencing		The DetNet MPLS data plane [RFC8964] specifies how sequencing
	information is encoded in the MPLS header. However, the DetNet IP		information is encoded in the MPLS header. However, the DetNet IP
	data plane described in [RFC8939] does not specify how sequencing		data plane described in [RFC8939] does not specify how sequencing
	information can be encoded in the IP packet. This document provides		information can be encoded in the IP packet. This document provides
	sequencing information to DetNet IP nodes, so it results in an		sequencing information to DetNet IP nodes, so it results in an
	improved version of the DetNet IP data plane. As suggested by		improved version of the DetNet IP data plane. As suggested by
	[RFC8938], the solution uses existing standardized headers and		[RFC8938], the solution uses existing standardized headers and
	encapsulations. The improvement is achieved by re-using the DetNet		encapsulations. The improvement is achieved by reusing the DetNet
	MPLS over UDP/IP data plane [RFC9025] with the restriction of using		MPLS-over-UDP/IP data plane [RFC9025] with the restriction of using
	zero F-labels.		zero F-Labels.
	2. Terminology		2. Terminology
	2.1. Terms Used in This Document		2.1. Terms Used in This Document
	This document uses the terminology established in the DetNet		This document uses the terminology established in the DetNet
	architecture [RFC8655], and the reader is assumed to be familiar with		architecture [RFC8655], and it is assumed that the reader is familiar
	that document and its terminology.		with that document and its terminology.
	2.2. Abbreviations		2.2. Abbreviations
	The following abbreviations are used in this document:		The following abbreviations are used in this document:
	DetNet Deterministic Networking.		DetNet Deterministic Networking
	PEF Packet Elimination Function.		PEF Packet Elimination Function
	POF Packet Ordering Function.		POF Packet Ordering Function
	PREOF Packet Replication, Elimination and Ordering Functions.		PREOF Packet Replication, Elimination, and Ordering Functions
	PRF Packet Replication Function.		PRF Packet Replication Function
	3. Requirements for adding PREOF to DetNet IP		3. Requirements for Adding PREOF to DetNet IP
	The requirements for adding PREOF to DetNet IP are:		The requirements for adding PREOF to DetNet IP are:
	* to reuse existing DetNet data plane solutions (e.g., [RFC8964],		* to reuse existing DetNet data plane solutions (e.g., [RFC8964],
	[RFC9025]).		[RFC9025]), and
	* to allow the DetNet service sub-layer for IP packet switched		* to allow the DetNet service sub-layer for IP packet-switched
	networks with minimal implementation effort.		networks with minimal implementation effort.
	The described solution practically gains from MPLS header fields		The described solution leverages MPLS header fields without requiring
	without requiring the support of the MPLS forwarding plane.		the support of the MPLS forwarding plane.
	4. Adding PREOF to DetNet IP		4. Adding PREOF to DetNet IP
	4.1. Solution Basics		4.1. Solution Basics
	The DetNet IP encapsulation supporting DetNet Service sub-layer is		The DetNet IP encapsulation supporting the DetNet service sub-layer
	based on the "UDP tunneling" concept. The solution creates a set of		is based on the "UDP tunneling" concept. The solution creates a set
	underlay UDP/IP tunnels between an overlay set of DetNet relay nodes.		of underlay UDP/IP tunnels between an overlay set of DetNet relay
			nodes.
	At the edge of a PREOF capable DetNet IP domain the DetNet flow is		At the edge of a PREOF-capable DetNet IP domain, the DetNet flow is
	encapsulated in an UDP packet containing the sequence number used by		encapsulated in a UDP packet containing the sequence number used by
	PREOF functions within the domain. This solution maintains the 6-		PREOF within the domain. This solution maintains the 6-tuple-based
	tuple-based DetNet flow identification in DetNet transit nodes, which		DetNet flow identification in DetNet transit nodes, which operate at
	operate at the DetNet forwarding sub-layer between the DetNet service		the DetNet forwarding sub-layer between the DetNet service sub-layer
	sub-layer nodes; therefore, it is compatible with [RFC8939].		nodes; therefore, it is compatible with [RFC8939]. Figure 2 shows
	Figure 2 shows how the PREOF capable DetNet IP data plane fits into		how the PREOF-capable DetNet IP data plane fits into the DetNet sub-
	the DetNet sub-layers.		layers.
	DetNet IP		DetNet IP
	.		.
	.		.
	+------------+		+------------+
	| Service | d-CW, Service-ID (S-label)		| Service | d-CW, Service-ID (S-Label)
	+------------+		+------------+
	| Forwarding | UDP/IP Header		| Forwarding | UDP/IP Header
	+------------+		+------------+
	*d-CW: DetNet Control Word		*d-CW: DetNet Control Word
	Figure 2: PREOF capable DetNet IP data plane		Figure 2: PREOF-Capable DetNet IP Data Plane
	4.2. Encapsulation		4.2. Encapsulation
	The PREOF capable DetNet IP encapsulation builds on encapsulating		The PREOF-capable DetNet IP encapsulation builds on encapsulating
	DetNet PseudoWire (PW) directly over UDP. That is, it combines		DetNet pseudowire (PW) directly over UDP. That is, it combines
	DetNet MPLS [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without		DetNet MPLS [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without
	using any F-Labels as shown in Figure 3. DetNet flows are identified		using any F-Labels, as shown in Figure 3. DetNet flows are
	at the receiving DetNet service sub-layer processing node via the		identified at the receiving DetNet service sub-layer processing node
	S-Label and/or the UDP/IP header information. Sequencing information		via the S-Label and/or the UDP/IP header information. Sequencing
	for PREOF is provided by the DetNet Control Word (d-CW) as per		information for PREOF is provided by the DetNet Control Word (d-CW)
	[RFC8964]. The S-label is used to identify both the DetNet flow and		per [RFC8964]. The S-Label is used to identify both the DetNet flow
	the DetNet App-flow type. The UDP tunnel is used to direct the		and the DetNet App-flow type. The UDP tunnel is used to direct the
	packet across the DetNet domain to the next DetNet service sub-layer		packet across the DetNet domain to the next DetNet service sub-layer
	processing node.		processing node.
	+---------------------------------+		+---------------------------------+
	| |		| |
	| DetNet App-Flow |		| DetNet App-Flow |
	| (original IP) Packet |		| (Original IP) Packet |
	| |		| |
	+---------------------------------+ <--\		+---------------------------------+ <--\
	| DetNet Control Word | |		| DetNet Control Word | |
	+---------------------------------+ +--> 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 |
	+---------------------------------+		+---------------------------------+
	Figure 3: PREOF capable DetNet IP encapsulation		Figure 3: PREOF-Capable DetNet IP Encapsulation
	4.3. Packet Processing		4.3. Packet Processing
	IP ingress and egress nodes of the PREOF capable DetNet IP domain add		IP ingress and egress nodes of the PREOF-capable DetNet IP domain add
	and remove a DetNet service-specific d-CW and Service-ID (i.e.,		and remove a DetNet service-specific d-CW and Service-ID (i.e.,
	S-Label). Relay nodes can change Service-ID values when processing a		S-Label). Relay nodes can change Service-ID values when processing a
	DetNet flow, i.e., incoming and outgoing Service-IDs of a DetNet flow		DetNet flow, i.e., incoming and outgoing Service-IDs of a DetNet flow
	can be different. Service-ID values are provisioned per DetNet		can be different. Service-ID values are provisioned per DetNet
	service via configuration, e.g., via the Controller Plane described		service via configuration, e.g., via the Controller Plane described
	in [RFC8938]. In some PREOF topologies, the node performing		in [RFC8938]. In some PREOF topologies, the node performing
	replication sends the packets to multiple nodes performing e.g., PEF		replication sends the packets to multiple nodes performing, e.g., PEF
	or POF and the replication node can use different Service-ID values		or POF, and the replication node can use different Service-ID values
	for the different member flows for the same DetNet service.		for the different member flows for the same DetNet service.
	Note, that Service-IDs is a local ID on the receiver side providing		Note that the Service-ID is a local ID on the receiver side that
	identification of the DetNet flow at the downstream DetNet service		identifies the DetNet flow at the downstream DetNet service sub-layer
	sub-layer receiver.		receiver.
	4.4. Flow Aggregation		4.4. Flow Aggregation
	Two methods can be used for flow aggregation:		Two methods can be used for flow aggregation:
	* aggregation using same UDP tunnel,		* aggregation using same UDP tunnel, and
	* aggregating DetNet flows as a new DetNet flow.		* aggregation of DetNet flows as a new DetNet flow.
	In the first case, the different DetNet PseudoWires use the same UDP		In the first method, the different DetNet pseudowires use the same
	tunnel, so they are treated as a single (aggregated) flow at the		UDP tunnel, so they are treated as a single (aggregated) flow at the
	forwarding sub-layer. At the service sub-layer, each flow uses a		forwarding sub-layer. At the service sub-layer, each flow uses a
	different Service ID (see Figure 3 ).		different Service-ID (see Figure 3).
	For the second option, an additional hierarchy is created thanks to		For the second method, an additional hierarchy is created by adding
	an additional Service-ID and d-CW tuple added to the encapsulation.		an additional Service-ID and d-CW tuple to the encapsulation. The
	The Aggregate-ID is a special case of a Service-ID, whose properties		Aggregate-ID is a special case of a Service-ID, whose properties are
	are known only at the aggregation and de-aggregation end points. It		known only at the aggregation and deaggregation end points. It is a
	is a property of the Aggregate-ID that it is followed by a d-CW		property of the Aggregate-ID that it is followed by a d-CW followed
	followed by a Service-ID/d-CW tuple. Figure 4 shows the		by a Service-ID/d-CW tuple. Figure 4 shows the encapsulation in the
	encapsulation in case of aggregation.		case of aggregation.
	+---------------------------------+		+---------------------------------+
	| |		| |
	| DetNet App-Flow |		| DetNet App-Flow |
	| Payload Packet |		| Payload Packet |
	| |		| |
	+---------------------------------+ <--\		+---------------------------------+ <--\
	| DetNet Control Word | |		| DetNet Control Word | |
	+---------------------------------+ +--> PREOF capable		+---------------------------------+ +--> PREOF-capable
	| Service-ID (S-Label) | | DetNet IP data		| Service-ID (S-Label) | | DetNet IP data
	+---------------------------------+ | plane encapsulation		+---------------------------------+ | plane encapsulation
	| DetNet Control Word | |		| DetNet Control Word | |
	+---------------------------------+ |		+---------------------------------+ |
	| Aggregate-ID (A-Label) | |		| Aggregate-ID (A-Label) | |
	+---------------------------------+ |		+---------------------------------+ |
	| UDP Header | |		| UDP Header | |
	+---------------------------------+ |		+---------------------------------+ |
	| IP Header | |		| IP Header | |
	+---------------------------------+ <--/		+---------------------------------+ <--/
	| Data-Link |		| Data-Link |
	+---------------------------------+		+---------------------------------+
	| Physical |		| Physical |
	+---------------------------------+		+---------------------------------+
	Figure 4: Aggregating DetNet flows as a new DetNet flow		Figure 4: Aggregating DetNet Flows as a New DetNet Flow
	The option used for aggregation is known by configuration of the		The aggregation method is configured in the aggregation/deaggregation
	aggregation/de-aggregation nodes.		nodes.
	If several Detnet flows are aggregated in a single UDP tunnel, they		If several DetNet flows are aggregated in a single UDP tunnel, they
	all need to follow the same path in the network.		all need to follow the same path in the network.
	4.5. PREOF Processing		4.5. PREOF Processing
	A node operating on a received DetNet flow at the DetNet service sub-		A node operating on a received DetNet flow at the DetNet service sub-
	layer uses the local context associated with a received Service-ID to		layer uses the local context associated with a received Service-ID to
	determine which local DetNet operation(s) are applied to received		determine which local DetNet operation(s) are applied to the received
	packet. A Service-ID can be allocated to be unique and enabling		packet. A unique Service-ID can be allocated and can be used to
	DetNet flow identification regardless of which input interface or UDP		identify a DetNet flow regardless of which input interface or UDP
	tunnel the packet is received. It is important to note that Service-		tunnel receives the packet. It is important to note that Service-ID
	ID values are driven by the receiver, not the sender.		values are driven by the receiver, not the sender.
	The DetNet forwarding sub-layer is supported by the UDP tunnel and is		The DetNet forwarding sub-layer is supported by the UDP tunnel and is
	responsible for providing resource allocation and explicit routes.		responsible for providing resource allocation and explicit routes.
	The outgoing PREOF encapsulation and processing can be implemented		The outgoing PREOF encapsulation and processing can be implemented
	via the provisioning of UDP and IP header information. Note, when		via the provisioning of UDP and IP header information. Note, when
	PRF is performed at the DetNet service sub-layer, there are multiple		PRF is performed at the DetNet service sub-layer, there are multiple
	member flows, and each member flow requires their own Service-ID, UDP		member flows, and each member flow requires its own Service-ID, UDP
	and IP header information. The headers for each outgoing packet are		header information, and IP header information. The headers for each
	formatted according to the configuration information, and the UDP		outgoing packet are formatted according to the configuration
	Source Port value is set to uniquely identify the DetNet flow. The		information, and the UDP Source Port value is set to uniquely
	packet is then handled as a PREOF capable DetNet IP packet.		identify the DetNet flow. The packet is then handled as a PREOF-
			capable DetNet IP packet.
	The incoming PREOF processing can be implemented via the provisioning		The incoming PREOF processing can be implemented by assigning a
	of received Service-ID, UDP and IP header information. The		Service-ID to the received DetNet flow and processing the information
	provisioned information is used to identify incoming app-flows based		in the UDP and IP headers. The provisioned information is used to
	on the combination of Service-ID and/or incoming encapsulation header		identify incoming App-flows based on the combination of Service-ID
	information.		and/or incoming encapsulation header information.
	4.6. PREOF capable DetNet IP domain		4.6. PREOF-Capable DetNet IP Domain
	Figure 5 shows using PREOF in a PREOF capable DetNet IP network,		Figure 5 shows using PREOF in a PREOF-capable DetNet IP network,
	where service protection is provided end to end, an not only within		where service protection is provided end to end, and not only within
	sub-networks like depicted in Figure 4 of [RFC8939].		sub-networks, as is depicted in Figure 4 <https://www.rfc-
			editor.org/rfc/rfc8939#figure-4> of [RFC8939].
	<---------- PREOF capable DetNet IP --------------->		<---------- PREOF-capable DetNet IP --------------->
	______		______
	____ / \__		____ / \__
	____ / \__/ \____________		____ / \__/ \____________
	+----+ __/ \____/ \ +----+		+----+ __/ \____/ \ +----+
	|src |_____/ \___| dst|		|src |_____/ \___| dst|
	+----+ \_______ DetNet network __________/ +----+		+----+ \_______ DetNet network __________/ +----+
	\_______ _/		\_______ _/
	\ __ __/		\ __ __/
	\_______/ \___/		\_______/ \___/
	+------------+		+------------+
	+---------------E1---+ | |		+---------------E1---+ | |
	+----+ | | +---R3---+ | +----+		+----+ | | +---R3---+ | +----+
	|src |------R1 +---+ | E3----O----+ dst|		|src |------R1 +---+ | E3----O----+ dst|
	+----+ | | E2-------+ +----+		+----+ | | E2-------+ +----+
	+----------R2 |		+----------R2 |
	+-----------------+		+-----------------+
	Figure 5: PREOF capable DetNet IP domain		Figure 5: PREOF-Capable DetNet IP Domain
	5. Control and Management Plane Parameters		5. Control and Management Plane Parameters
	The information needed to identify individual and aggregated DetNet		The information needed to identify individual and aggregated DetNet
	flows is summarized as follows:		flows is summarized as follows:
	* Service-ID information to be mapped to UDP/IP flows. Note that,		* Service-ID information to be mapped to UDP/IP flows. Note that,
	for example, a single Service-ID can map to multiple sets of UDP/		for example, a single Service-ID can map to multiple sets of UDP/
	IP information when PREOF is used.		IP information when PREOF is used.
	* IPv4 or IPv6 source address field.		* IPv4 or IPv6 Source Address field.
	* IPv4 or IPv6 source address prefix length, where a zero (0) value		* IPv4 or IPv6 source address prefix length, where a zero (0) value
	effectively means that the address field is ignored.		effectively means that the address field is ignored.
	* IPv4 or IPv6 destination address field.		* IPv4 or IPv6 Destination Address field.
	* IPv4 or IPv6 destination address prefix length, where a zero (0)		* IPv4 or IPv6 destination address prefix length, where a zero (0)
	effectively means that the address field is ignored.		effectively means that the address field is ignored.
	* IPv6 flow label field.		* IPv6 Flow Label field.
	* IPv4 protocol field being equal to "UDP".		* IPv4 Protocol field being equal to "UDP".
	* IPv6 (last) next header field being equal to "UDP".		* IPv6 (last) Next Header field being equal to "UDP".
	* For the IPv4 Type of Service and IPv6 Traffic Class Fields:		* For the IPv4 Type of Service and IPv6 Traffic Class fields:
	- Whether or not the DSCP field is used in flow identification as		- Whether or not the Differentiated Services Code Point (DSCP)
	the use of the DSCP field for flow identification is optional.		field is used in flow identification, as the use of the DSCP
			field for flow identification is optional.
	- If the DSCP field is used to identify a flow, then the flow		- If the DSCP field is used to identify a flow, then the flow
	identification information (for that flow) includes a list of		identification information (for that flow) includes a list of
	DSCPs used by the given DetNet flow.		DSCPs used by the given DetNet flow.
	* UDP Source Port. Support for both exact and wildcard matching is		* UDP Source Port. Support for both exact and wildcard matching is
	required. Port ranges can optionally be used.		required. Port ranges can optionally be used.
	* UDP Destination Port. Support for both exact and wildcard		* UDP Destination Port. Support for both exact and wildcard
	matching is required. Port ranges can optionally be used.		matching is required. Port ranges can optionally be used.
	* For end systems, an optional maximum IP packet size that should be		* For end systems, an optional maximum IP packet size that should be
	used for that outgoing DetNet IP flow.		used for that outgoing DetNet IP flow.
	This information is provisioned per DetNet flow via configuration,		This information is provisioned per DetNet flow via configuration,
	e.g., via the controller plane.		e.g., via the Controller Plane.
	Ordering of the set of information used to identify an individual		Ordering of the set of information used to identify an individual
	DetNet flow can, for example, be used to provide a DetNet service for		DetNet flow can, for example, be used to provide a DetNet service for
	a specific UDP flow, with unique Source and Destination Port field		a specific UDP flow, with unique Source and Destination Port field
	values, while providing a different service for the aggregate of all		values, while providing a different service for the aggregate of all
	other flows with that same UDP Destination Port value.		other flows with that same UDP Destination Port value.
	The minimum set of information for the configuration of the DetNet		The minimum set of information for the configuration of the DetNet
	service sub-layer is summarized as follows:		service sub-layer is summarized as follows:
	* App-flow identification information.		* App-flow identification information
	* Sequence number length.		* Sequence number length
	* PREOF + related Service-ID(s).		* Type of PREOF to be executed on the DetNet flow
	* Associated forwarding sub-layer information.		* Service-ID(s) used by the member flows
	* Service aggregation information.		* Associated forwarding sub-layer information
			* Service aggregation information
	The minimum set of information for the configuration of the DetNet		The minimum set of information for the configuration of the DetNet
	forwarding sub-layer is summarized as follows:		forwarding sub-layer is summarized as follows:
	* UDP tunnel specific information.		* UDP tunnel-specific information
	* Traffic parameters.		* Traffic parameters
	These parameters are defined in the DetNet Flow and Service		These parameters are defined in the DetNet flow and service
	information model [RFC9016] and the DetNet YANG model.		information model [RFC9016] and the DetNet YANG model.
	Note: this document focuses on the use of MPLS over UDP/IP		Note: this document focuses on the use of MPLS-over-UDP/IP
	encapsulation throughout an entire DetNet IP network, making MPLS-		encapsulation throughout an entire DetNet IP network, making MPLS-
	based DetNet OAM techniques applicable [I-D.ietf-detnet-mpls-oam].		based DetNet Operations, Administration, and Maintenance (OAM)
	Using the described encapsulation only for a portion of a DetNet IP		techniques applicable [RFC9546]. Using the described encapsulation
	network that handles the PREOF functionality would complicate OAM.		only for a portion of a DetNet IP network that handles PREOF would
			complicate OAM.
	6. Security Considerations		6. Security Considerations
	There are no new DetNet related security considerations introduced by		There are no new DetNet-related security considerations introduced by
	this solution. Security considerations of DetNet MPLS [RFC8964] and		this solution. Security considerations of DetNet MPLS [RFC8964] and
	DetNet MPLS over UDP/IP [RFC9025] apply.		DetNet MPLS over UDP/IP [RFC9025] apply.
	7. IANA Considerations		7. IANA Considerations
	This document makes no IANA requests.		This document has no IANA actions.
	8. Acknowledgements
	Authors extend their appreciation to Stewart Bryant, Pascal Thubert,
	David Black, Shirley Yangfan and Greg Mirsky for their insightful
	comments and productive discussion that helped to improve the
	document.
	9. References
	9.1. Normative References		8. References
	[I-D.ietf-detnet-mpls-oam]		8.1. Normative References
	Mirsky, G., Chen, M., and B. Varga, "Operations,
	Administration and Maintenance (OAM) for Deterministic
	Networks (DetNet) with MPLS Data Plane", Work in Progress,
	Internet-Draft, draft-ietf-detnet-mpls-oam-15, 12 January
	2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
	detnet-mpls-oam-15>.
	[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,		[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", RFC 8655,		"Deterministic Networking Architecture", RFC 8655,
	DOI 10.17487/RFC8655, October 2019,		DOI 10.17487/RFC8655, October 2019,
	<https://www.rfc-editor.org/info/rfc8655>.		<https://www.rfc-editor.org/info/rfc8655>.
	[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.		[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, "Deterministic Networking (DetNet) Data Plane		Bryant, "Deterministic Networking (DetNet) Data Plane
	Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,		Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
	<https://www.rfc-editor.org/info/rfc8938>.		<https://www.rfc-editor.org/info/rfc8938>.
	skipping to change at page 11, line 40 ¶		skipping to change at line 475 ¶
	Fedyk, "Flow and Service Information Model for		Fedyk, "Flow and Service Information Model for
	Deterministic Networking (DetNet)", RFC 9016,		Deterministic Networking (DetNet)", RFC 9016,
	DOI 10.17487/RFC9016, March 2021,		DOI 10.17487/RFC9016, March 2021,
	<https://www.rfc-editor.org/info/rfc9016>.		<https://www.rfc-editor.org/info/rfc9016>.
	[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.		[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, "Deterministic Networking (DetNet) Data Plane:		Bryant, "Deterministic Networking (DetNet) Data Plane:
	MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April		MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April
	2021, <https://www.rfc-editor.org/info/rfc9025>.		2021, <https://www.rfc-editor.org/info/rfc9025>.
	9.2. Informative References		[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,
			Administration, and Maintenance (OAM) for Deterministic
			Networking (DetNet) with the MPLS Data Plane", RFC 9546,
			DOI 10.17487/RFC9546, February 2024,
			<https://www.rfc-editor.org/info/rfc9546>.
	[I-D.ietf-detnet-pof]		8.2. Informative References
	Varga, B., Farkas, J., Kehrer, S., and T. Heer,
	"Deterministic Networking (DetNet): Packet Ordering
	Function", Work in Progress, Internet-Draft, draft-ietf-
	detnet-pof-11, 15 January 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
	pof-11>.
	[IEEE8021CB]		[IEEE8021CB]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE, "IEEE Standard for Local and metropolitan area
	networks -- Frame Replication and Elimination for		networks -- Frame Replication and Elimination for
	Reliability", DOI 10.1109/IEEESTD.2017.8091139, October		Reliability", IEEE Std 802.1CB-2017,
	2017,		DOI 10.1109/IEEESTD.2017.8091139, October 2017,
	<https://standards.ieee.org/standard/802_1CB-2017.html>.		<https://doi.org/10.1109/IEEESTD.2017.8091139>.
	[IEEEP8021CBcv]		[IEEE8021CBcv]
	Kehrer, S., "FRER YANG Data Model and Management		IEEE, "IEEE Standard for Local and metropolitan area
	Information Base Module", IEEE P802.1CBcv		networks -- Frame Replication and Elimination for
	/D1.2 P802.1CBcv, March 2021,		Reliability - Amendment 1: Information Model, YANG Data
	<https://www.ieee802.org/1/files/private/cv-drafts/d1/802-		Model, and Management Information Base Module", Amendment
	1CBcv-d1-2.pdf>.		to IEEE Std 802.1CB-2017, IEEE Std 802.1CBcv-2021,
			DOI 10.1109/IEEESTD.2022.9715061, February 2022,
			<https://doi.org/10.1109/IEEESTD.2022.9715061>.
			[RFC9550] Varga, B., Ed., Farkas, J., Kehrer, S., and T. Heer,
			"Deterministic Networking (DetNet): Packet Ordering
			Function", RFC 9550, DOI 10.17487/RFC9550, March 2024,
			<https://www.rfc-editor.org/info/rfc9550>.
			Acknowledgements
			Authors extend their appreciation to Stewart Bryant, Pascal Thubert,
			David Black, Shirley Yangfan, and Greg Mirsky for their insightful
			comments and productive discussion that helped to improve the
			document.
	Authors' Addresses		Authors' Addresses
	Balazs Varga		Balazs Varga
	Ericsson		Ericsson
	Budapest		Budapest
	Magyar Tudosok krt. 11.		Magyar Tudosok krt. 11.
	1117		1117
	Hungary		Hungary
	Email: balazs.a.varga@ericsson.com		Email: balazs.a.varga@ericsson.com
End of changes. 79 change blocks.
	207 lines changed or deleted		210 lines changed or added
This html diff was produced by rfcdiff 1.48.