draft-ietf-detnet-ip-05.txt		draft-ietf-detnet-ip-06.txt
	DetNet B. Varga, Ed.		DetNet B. Varga, Ed.
	Internet-Draft J. Farkas		Internet-Draft J. Farkas
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: August 6, 2020 L. Berger		Expires: October 25, 2020 L. Berger
	D. Fedyk		D. Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	A. Malis
	Independent
	S. Bryant		S. Bryant
	Futurewei Technologies		Futurewei Technologies
	February 3, 2020		April 23, 2020
	DetNet Data Plane: IP		DetNet Data Plane: IP
	draft-ietf-detnet-ip-05		draft-ietf-detnet-ip-06
	Abstract		Abstract
	This document specifies the Deterministic Networking data plane when		This document specifies the Deterministic Networking data plane when
	operating in an IP packet switched network.		operating in an IP packet switched network.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 6, 2020.		This Internet-Draft will expire on October 25, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 15 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3		2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
	2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4		3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4
	4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 6		4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 7
	4.1. End-system-specific Considerations . . . . . . . . . . . 7		4.1. End-system-specific Considerations . . . . . . . . . . . 7
	4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7		4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 7
	4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 9		4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 10
	4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 9		4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 10
	4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10		4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 10
	4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 10		4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 11
	4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 11		4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 11
	4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 12		4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 12
	5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12		5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 12
	5.1. DetNet IP Flow Identification Procedures . . . . . . . . 12		5.1. DetNet IP Flow Identification Procedures . . . . . . . . 13
	5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13		5.1.1. IP Header Information . . . . . . . . . . . . . . . . 13
	5.1.2. Other Protocol Header Information . . . . . . . . . . 14		5.1.2. Other Protocol Header Information . . . . . . . . . . 14
	5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15		5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 15
	5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 15		5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 16
	6. Management and Control Information Summary . . . . . . . . . 16		6. Management and Control Information Summary . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative references . . . . . . . . . . . . . . . . . . 18		11.1. Normative references . . . . . . . . . . . . . . . . . . 19
	11.2. Informative references . . . . . . . . . . . . . . . . . 20		11.2. Informative references . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Deterministic Networking (DetNet) is a service that can be offered by		Deterministic Networking (DetNet) is a service that can be offered by
	a network to DetNet flows. DetNet provides these flows extremely low		a network to DetNet flows. DetNet provides these flows with
	packet loss rates and assured maximum end-to-end delivery latency.		extremely low packet loss rates and assured maximum end-to-end
	General background and concepts of DetNet can be found in the DetNet		delivery latency. General background and concepts of DetNet can be
	Architecture [RFC8655].		found in the DetNet Architecture [RFC8655].
	This document specifies the DetNet data plane operation for IP hosts		This document specifies the DetNet data plane operation for IP hosts
	and routers that provide DetNet service to IP encapsulated data. No		and routers that provide DetNet service to IP encapsulated data. No
	DetNet-specific encapsulation is defined to support IP flows, instead		DetNet-specific encapsulation is defined to support IP flows, instead
	the existing IP and higher layer protocol header information is used		the existing IP and higher layer protocol header information is used
	to support flow identification and DetNet service delivery. Common		to support flow identification and DetNet service delivery. Common
	data plane procedures and control information for all DetNet data		data plane procedures and control information for all DetNet data
	planes can be found in the [I-D.ietf-detnet-data-plane-framework].		planes can be found in the [I-D.ietf-detnet-data-plane-framework].
	The DetNet Architecture models the DetNet related data plane		The DetNet Architecture models the DetNet related data plane
	functions as two sub-layers: functions into two sub-layers: a service		functions as two sub-layers: a service sub-layer and a forwarding
	sub-layer and a forwarding sub-layer. The service sub-layer is used		sub-layer. The service sub-layer is used to provide DetNet service
	to provide DetNet service protection (e.g., by packet replication and		protection (e.g., by packet replication and packet elimination
	packet elimination functions) and reordering. The forwarding sub-		functions) and reordering. The forwarding sub-layer is used to
	layer is used to provide congestion protection (low loss, assured		provide congestion protection (low loss, assured latency, and limited
	latency, and limited out-of-order delivery). The service sub-layer		out-of-order delivery). The service sub-layer generally requires
	generally requires additional fields to provide its service; for		additional header fields to provide its service; for example see
	example see [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields		[I-D.ietf-detnet-mpls]. Since no DetNet-specific fields are added to
	are added to support DetNet IP flows, only the forwarding sub-layer		support DetNet IP flows, only the forwarding sub-layer functions are
	functions are supported using the DetNet IP defined by this document.		supported using the DetNet IP defined by this document. Service
	Service protection can be provided on a per sub-net basis using		protection can be provided on a per sub-net basis using technologies
	technologies such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet		such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified
	as specified in the IEEE 802.1 TSN task group(referred to in this		in the IEEE 802.1 TSN (Time-Sensitive Networking) task group
	document simply as IEEE802.1 TSN).		(referred to in this document simply as IEEE802.1 TSN).
	This document provides an overview of the DetNet IP data plane in		This document provides an overview of the DetNet IP data plane in
	Section 3, considerations that apply to providing DetNet services via		Section 3, considerations that apply to providing DetNet services via
	the DetNet IP data plane in Section 4. Section 5 provides the		the DetNet IP data plane in Section 4. Section 5 provides the
	procedures for hosts and routers that support IP-based DetNet		procedures for hosts and routers that support IP-based DetNet
	services. Section 6 summarizes the set of information that is needed		services. Section 6 summarizes the set of information that is needed
	to identify an individual DetNet flow.		to identify an individual DetNet flow.
	2. Terminology		2. Terminology
	skipping to change at page 4, line 4 ¶		skipping to change at page 3, line 50 ¶
	The following abbreviations used in this document:		The following abbreviations used in this document:
	CoS Class of Service		CoS Class of Service
	DetNet Deterministic Networking		DetNet Deterministic Networking
	DN DetNet		DN DetNet
	DiffServ Differentiated Services		DiffServ Differentiated Services
	DSCP Differentiated Services Code Point
			DSCP Differentiated Services Code Point
	L2 Layer-2		L2 Layer-2
	L3 Layer-3		L3 Layer-3
	LSP Label-switched path		LSP Label-switched path
	MPLS Multiprotocol Label Switching		MPLS Multiprotocol Label Switching
	PREOF Packet Replication, Elimination and Ordering Function		PREOF Packet Replication, Elimination and Ordering Function
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	document is the same as that defined in [RFC3290]. Specifically		document is the same as that defined in [RFC3290]. Specifically
	6-tuple is (destination address, source address, IP protocol, source		6-tuple is (destination address, source address, IP protocol, source
	port, destination port, and differentiated services (DiffServ) code		port, destination port, and differentiated services (DiffServ) code
	point (DSCP). General background on the use of IP headers, and		point (DSCP). General background on the use of IP headers, and
	5-tuples, to identify flows and support Quality of Service (QoS) can		5-tuples, to identify flows and support Quality of Service (QoS) can
	be found in [RFC3670]. [RFC7657] also provides useful background on		be found in [RFC3670]. [RFC7657] also provides useful background on
	the delivery of DiffServ and "tuple" based flow identification. Note		the delivery of DiffServ and "tuple" based flow identification. Note
	that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP		that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP
	component.		component.
			For some of the protocols 5-tuples and 6-tuples cannot be used
			because the port information is not available (e.g., ICMP, IPSec
			ESP). Same can be valid for flow aggregates. In such cases using
			smaller tuples are appropriate, e.g., a 3-tuple (2 IP addresses, IP
			protocol) or even a 2-tuple (all IP traffic between two IP
			addresses).
	The DetNet IP data plane also allows for optional matching on the		The DetNet IP data plane also allows for optional matching on the
	IPv6 flow label field, as defined in [RFC8200].		IPv6 flow label field, as defined in [RFC8200].
	Non-DetNet and DetNet IP packets are identical on the wire.		Non-DetNet and DetNet IP packets are identical on the wire.
	Generally the fields used in flow identification are forwarded		Generally the fields used in flow identification are forwarded
	unmodified, however modification of these fields is allowed, for		unmodified, however modification of these fields is allowed, for
	example to a DSCP value, when required by the DetNet service.		example changing the DSCP value, when required by the DetNet service.
	DetNet flow aggregation may be enabled via the use of wildcards,		DetNet flow aggregation may be enabled via the use of wildcards,
	masks, lists, prefixes and ranges. IP tunnels may also be used to		masks, lists, prefixes and ranges. IP tunnels may also be used to
	support flow aggregation. In these cases, it is expected that		support flow aggregation. In these cases, it is expected that
	DetNet-aware intermediate nodes will provide DetNet service on the		DetNet-aware intermediate nodes will provide DetNet service on the
	aggregate through resource allocation and congestion control		aggregate through resource allocation and congestion control
	mechanisms.		mechanisms.
	DetNet IP Relay Relay DetNet IP		DetNet IP Relay Relay DetNet IP
	End System Node Node End System		End System Node Node End System
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 47 ¶
	: Link : \ ,-----. / \ ,-----. /		: Link : \ ,-----. / \ ,-----. /
	+......+ +----[ Sub ]----+ +-[ Sub ]-+		+......+ +----[ Sub ]----+ +-[ Sub ]-+
	[Network] [Network]		[Network] [Network]
	`-----' `-----'		`-----' `-----'
	|<--------------------- DetNet IP --------------------->|		|<--------------------- DetNet IP --------------------->|
	Figure 1: A Simple DetNet (DN) Enabled IP Network		Figure 1: A Simple DetNet (DN) Enabled IP Network
	Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled		Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled
	end systems originate IP encapsulated traffic those are identified		end systems originate IP encapsulated traffic that is identified
	within the DetNet domain as DetNet flows, relay nodes understand the		within the DetNet domain as DetNet flows. Relay nodes understand the
	forwarding requirements of the DetNet flow and ensure that node,		forwarding requirements of the DetNet flow and ensure that node,
	interface and sub-network resources are allocated to ensure DetNet		interface and sub-network resources are allocated to ensure DetNet
	service requirements. The dotted line around the Service component		service requirements. The dotted line around the Service component
	of the Relay Nodes indicates that the transit routers are DetNet		of the Relay Nodes indicates that the transit routers are DetNet
	service aware but do not perform any DetNet service sub-layer		service aware but do not perform any DetNet service sub-layer
	function, e.g., PREOF.		function, e.g., PREOF (Packet Replication, Elimination and Ordering
			Function).
	Note: The sub-network can represent a TSN, MPLS network or other		Note: The sub-network can represent a TSN, MPLS network or other
	network technology that can carry DetNet IP traffic.		network technology that can carry DetNet IP traffic.
	IP Edge Edge IP		IP Edge Edge IP
	End System Node Node End System		End System Node Node End System
	+----------+ +.........+ +.........+ +----------+		+----------+ +.........+ +.........+ +----------+
	| Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. |		| Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. |
	+----------+ +.........+ +.........+ +----------+		+----------+ +.........+ +.........+ +----------+
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 47 ¶
	Note, that Figure 1 and Figure 2 can be collapsed, so IP DetNet End		Note, that Figure 1 and Figure 2 can be collapsed, so IP DetNet End
	Systems can communicate over DetNet IP network with IP End System.		Systems can communicate over DetNet IP network with IP End System.
	As non-DetNet and DetNet IP packets are identical on the wire, from		As non-DetNet and DetNet IP packets are identical on the wire, from
	data plane perspective, the only difference is that there is flow-		data plane perspective, the only difference is that there is flow-
	associated DetNet information on each DetNet node that defines the		associated DetNet information on each DetNet node that defines the
	flow related characteristics and required forwarding behavior. As		flow related characteristics and required forwarding behavior. As
	shown above, edge nodes provide a Service Proxy function that		shown above, edge nodes provide a Service Proxy function that
	"associates" one or more IP flows with the appropriate DetNet flow-		"associates" one or more IP flows with the appropriate DetNet flow-
	specific information and ensures that the receives the proper traffic		specific information and ensures that the flow receives the proper
	treatment within the domain.		traffic treatment within the domain.
	Note: The operation of IEEE802.1 TSN end systems over DetNet enabled		Note: The operation of IEEE802.1 TSN end systems over DetNet enabled
	IP networks is not described in this document. TSN over MPLS is		IP networks is not described in this document. TSN over MPLS is
	discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls].		discribed in [I-D.ietf-detnet-tsn-vpn-over-mpls].
	4. DetNet IP Data Plane Considerations		4. DetNet IP Data Plane Considerations
	This section provides informative considerations related to providing		This section provides informative considerations related to providing
	DetNet service to flows which are identified based on their header		DetNet service to flows which are identified based on their header
	information.		information.
	skipping to change at page 9, line 42 ¶		skipping to change at page 10, line 9 ¶
	Note that not mixing DetNet and non-DetNet traffic within a single		Note that not mixing DetNet and non-DetNet traffic within a single
	5-tuple, as described above, enables simpler 5-tuple filters to be		5-tuple, as described above, enables simpler 5-tuple filters to be
	used (or re-used) at the edges of a DetNet network to prevent non-		used (or re-used) at the edges of a DetNet network to prevent non-
	congestion-responsive DetNet traffic from escaping the DetNet domain.		congestion-responsive DetNet traffic from escaping the DetNet domain.
	4.3. Forwarding Sub-Layer Considerations		4.3. Forwarding Sub-Layer Considerations
	4.3.1. Class of Service		4.3.1. Class of Service
	Class of Service (CoS) for DetNet flows carried in IPv6 is provided		Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is
	using the standard differentiated services code point (DSCP) field		provided using the standard differentiated services (DSCP) field
	[RFC2474] and related mechanisms.		[RFC2474] and related mechanisms.
	One additional consideration for DetNet nodes which support CoS		One additional consideration for DetNet nodes which support CoS
	services is that they MUST ensure that the CoS service classes do not		services is that they MUST ensure that the CoS service classes do not
	impact the congestion protection and latency control mechanisms used		impact the congestion protection and latency control mechanisms used
	to provide DetNet QoS. This requirement is similar to the		to provide DetNet QoS. This requirement is similar to the
	requirement for MPLS LSRs that CoS LSPs cannot impact the resources		requirement for MPLS LSRs that CoS LSPs cannot impact the resources
	allocated to TE LSPs [RFC3473].		allocated to TE LSPs [RFC3473].
	4.3.2. Quality of Service		4.3.2. Quality of Service
	Quality of Service (QoS) for DetNet service flows carried in IP MUST		Quality of Service (QoS) for DetNet service flows carried in IP MUST
	be provided locally by the DetNet-aware hosts and routers supporting		be provided locally by the DetNet-aware hosts and routers supporting
	DetNet flows. Such support leverages the underlying network layer		DetNet flows. Such support leverages the underlying network layer
	such as 802.1 TSN. The traffic control mechanisms used to deliver		such as 802.1 TSN. The traffic control mechanisms used to deliver
	QoS for IP encapsulated DetNet flows are expected to be defined in a		QoS for IP encapsulated DetNet flows are expected to be defined in a
	future document. From an encapsulation perspective, the combination		future document. From an encapsulation perspective, the combination
	of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and		of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
	previously mentioned optional field, uniquely identifies a DetNet IP		previously mentioned optional field (i.e., flow label), uniquely
	flow.		identifies a DetNet IP flow.
	Packets that are identified as part of a DetNet IP flow but that have		Packets that are identified as part of a DetNet IP flow but that have
	not been the subject of a completed reservation, can disrupt the QoS		not been the subject of a completed reservation, can disrupt the QoS
	offered to properly reserved DetNet flows by using resources		offered to properly reserved DetNet flows by using resources
	allocated to the reserved flows. Therefore, the network nodes of a		allocated to the reserved flows. Therefore, the network nodes of a
	DetNet network MUST ensure that no DetNet allocated resources, e.g.,		DetNet network MUST ensure that no DetNet allocated resources, e.g.,
	queue or shaper, is used by such flows. There are multiple methods		queue or shaper, is used by such flows. There are multiple methods
	that MAY be used by an implementation to defend service delivery to		that MAY be used by an implementation to defend service delivery to
	reserved DetNet flows, including but not limited to:		reserved DetNet flows, including but not limited to:
	o Treating packets associated with an incomplete reservation as non-		o Treating packets associated with an incomplete reservation as non-
	DetNet traffic.		DetNet traffic.
	o Discarding packets associated with an incomplete reservation.		o Discarding packets associated with an incomplete reservation.
	o Remarking packets associated with an incomplete reservation.		o Remarking packets associated with an incomplete reservation.
	Remarking can be accomplished by changing the value of the DSCP,		Remarking can be accomplished by changing the value of the DSCP
	or optional, field to a value that results in the packet no longer		field to a value that results in the packet no longer matching any
	matching any other reserved DetNet IP flow.		other reserved DetNet IP flow.
	4.3.3. Path Selection		4.3.3. Path Selection
	While path selection algorithms and mechanisms are out of scope of		While path selection algorithms and mechanisms are out of scope of
	the DetNet data plane definition, it is important to highlight the		the DetNet data plane definition, it is important to highlight the
	implications of DetNet IP flow identification on path selection and		implications of DetNet IP flow identification on path selection and
	next hops. As mentioned above, the DetNet IP data plane identifies		next hops. As mentioned above, the DetNet IP data plane identifies
	flows using "6-tuple" header information as well as the additional		flows using "6-tuple" header information as well as the additional
	optional header field. DetNet generally allows for both flow-		optional header field. DetNet generally allows for both flow-
	specific traffic treatment and flow-specific next-hops.		specific traffic treatment and flow-specific next-hops.
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 51 ¶
	management or control function that provisions the aggregate flows		management or control function that provisions the aggregate flows
	must ensure that adequate resources are allocated and configured to		must ensure that adequate resources are allocated and configured to
	provide combined service requirements of the individual flows. As		provide combined service requirements of the individual flows. As
	DetNet is concerned about latency and jitter, more than just		DetNet is concerned about latency and jitter, more than just
	bandwidth needs to be considered.		bandwidth needs to be considered.
	From a single node perspective, the aggregation of IP flows impacts		From a single node perspective, the aggregation of IP flows impacts
	DetNet IP data plane flow identification and resource allocation. As		DetNet IP data plane flow identification and resource allocation. As
	discussed above, IP flow identification uses the IP "6-tuple" for		discussed above, IP flow identification uses the IP "6-tuple" for
	flow identification. DetNet IP flows can be aggregated using any of		flow identification. DetNet IP flows can be aggregated using any of
	the 6-tuple, and an additional optional field defined in Section 5.1.		the 6-tuple, and an additional optional field (i.e., flow label).
	The use of prefixes, wildcards, lists, and value ranges allows a		The use of prefixes, wildcards, lists, and value ranges allows a
	DetNet node to identify aggregate DetNet flows. From a resource		DetNet node to identify aggregate DetNet flows. From a resource
	allocation perspective, DetNet nodes must provide service to an		allocation perspective, DetNet nodes ought to provide service to an
	aggregate and not on a component flow basis.		aggregate rather than on a component flow basis.
	It is the responsibility of the DetNet controller plane to properly		It is the responsibility of the DetNet controller plane to properly
	provision the use of these aggregation mechanisms. This includes		provision the use of these aggregation mechanisms. This includes
	ensuring that aggregated flows have compatible e.g., the same or very		ensuring that aggregated flows have compatible e.g., the same or very
	similar QoS and/or CoS characteristics, see Section 4.3.2. It also		similar QoS and/or CoS characteristics, see Section 4.3.2. It also
	includes ensuring that per component-flow service requirements are		includes ensuring that per component-flow service requirements are
	satisfied by the aggregate, see Section 5.3.		satisfied by the aggregate, see Section 5.3.
	4.5. Bidirectional Traffic		4.5. Bidirectional Traffic
	skipping to change at page 12, line 36 ¶		skipping to change at page 12, line 46 ¶
	identification includes those procedures related to matching IP and		identification includes those procedures related to matching IP and
	higher layer protocol header information to DetNet flow (state)		higher layer protocol header information to DetNet flow (state)
	information and service requirements. Flow identification is also		information and service requirements. Flow identification is also
	sometimes called Traffic classification, for example see [RFC5777].		sometimes called Traffic classification, for example see [RFC5777].
	Forwarding includes those procedures related to next hop selection		Forwarding includes those procedures related to next hop selection
	and delivery. Traffic treatment includes those procedures related to		and delivery. Traffic treatment includes those procedures related to
	providing an identified flow with the required DetNet service.		providing an identified flow with the required DetNet service.
	DetNet IP data plane establishment and operational procedures also		DetNet IP data plane establishment and operational procedures also
	have requirements on the control and management systems for DetNet		have requirements on the control and management systems for DetNet
	flows and these are referred in this section. Specifically this		flows and these are referred to in this section. Specifically this
	section identifies a number of information elements that require		section identifies a number of information elements that require
	support via the management and control interfaces supported by a		support via the management and control interfaces supported by a
	DetNet node. The specific mechanism used for such support is out of		DetNet node. The specific mechanism used for such support is out of
	the scope of this document. A summary of the requirements for		the scope of this document. A summary of the requirements for
	management and control related information is included. Conformance		management and control related information is included. Conformance
	language is not used in the summary since applies to future		language is not used in the summary since it applies to future
	mechanisms such as those that may be provided in YANG models		mechanisms such as those that may be provided in YANG models
	[I-D.ietf-detnet-yang].		[I-D.ietf-detnet-yang].
	5.1. DetNet IP Flow Identification Procedures		5.1. DetNet IP Flow Identification Procedures
	IP and higher layer protocol header information is used to identify		IP and higher layer protocol header information is used to identify
	DetNet flows. All DetNet implementations that support this document		DetNet flows. All DetNet implementations that support this document
	MUST identify individual DetNet flows based on the set of information		MUST identify individual DetNet flows based on the set of information
	identified in this section. Note, that additional flow		identified in this section. Note, that additional flow
	identification requirements, e.g., to support other higher layer		identification requirements, e.g., to support other higher layer
	skipping to change at page 14, line 31 ¶		skipping to change at page 14, line 41 ¶
	that support matching based on this field MUST allow for this field		that support matching based on this field MUST allow for this field
	to be ignored for a specific DetNet flow. When this field is used to		to be ignored for a specific DetNet flow. When this field is used to
	identify a specific DetNet flow, implementations MAY exclude the IPv6		identify a specific DetNet flow, implementations MAY exclude the IPv6
	Next Header field and next header information as part of DetNet flow		Next Header field and next header information as part of DetNet flow
	identification.		identification.
	5.1.2. Other Protocol Header Information		5.1.2. Other Protocol Header Information
	Implementations of this document MUST support DetNet flow		Implementations of this document MUST support DetNet flow
	identification based on header information identified in this		identification based on header information identified in this
	section. Support for TCP, UDP and IPsec flows is defined. Future		section. Support for TCP, UDP, ICMP and IPsec flows is defined.
	documents are expected to define support for other protocols.		Future documents are expected to define support for other protocols.
	5.1.2.1. TCP and UDP		5.1.2.1. TCP and UDP
	DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is		DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is
	achieved based on the Source and Destination Port fields carried in		achieved based on the Source and Destination Port fields carried in
	each protocol's header. These fields share a common format and		each protocol's header. These fields share a common format and
	common DetNet flow identification procedures.		common DetNet flow identification procedures.
			The rules defined in this section only apply when the IPv4 Protocol
			or IPv6 Next Header Field contains the IANA defined value for UDP or
			TCP.
	5.1.2.1.1. Source Port Field		5.1.2.1.1. Source Port Field
	Implementations of this document MUST support DetNet flow		Implementations of this document MUST support DetNet flow
	identification based on the Source Port field of a TCP or UDP packet.		identification based on the Source Port field of a TCP or UDP packet.
	Implementations MUST support flow identification based on a		Implementations MUST support flow identification based on a
	particular value carried in the field, i.e., an exact value.		particular value carried in the field, i.e., an exact value.
	Implementations SHOULD support range-based port matching.		Implementations SHOULD support range-based port matching.
	Implementation MUST also allow for the field to be ignored for a		Implementation MUST also allow for the field to be ignored for a
	specific DetNet flow.		specific DetNet flow.
	5.1.2.1.2. Destination Port Field		5.1.2.1.2. Destination Port Field
	Implementations of this document MUST support DetNet flow		Implementations of this document MUST support DetNet flow
	identification based on the Destination Port field of a TCP or UDP		identification based on the Destination Port field of a TCP or UDP
	packet. Implementations MUST support flow identification based on a		packet. Implementations MUST support flow identification based on a
	particular value carried in the field, i.e., an exact value.		particular value carried in the field, i.e., an exact value.
	Implementations SHOULD support range-based port matching.		Implementations SHOULD support range-based port matching.
	Implementation MUST also allow for the field to be ignored for a		Implementation MUST also allow for the field to be ignored for a
	specific DetNet flow.		specific DetNet flow.
	5.1.2.2. IPsec AH and ESP		5.1.2.2. ICMP
			DetNet flow identification for ICMP is achieved based on the
			protocol's header. Note that ICMP type is not included in the flow
			definition.
			5.1.2.3. IPsec AH and ESP
	IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security		IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security
	Payload (ESP) [RFC4303] share a common format for the Security		Payload (ESP) [RFC4303] share a common format for the Security
	Parameters Index (SPI) field. Implementations MUST support flow		Parameters Index (SPI) field. Implementations MUST support flow
	identification based on a particular value carried in the field,		identification based on a particular value carried in the field,
	i.e., an exact value. Implementation SHOULD also allow for the field		i.e., an exact value. Implementation SHOULD also allow for the field
	to be ignored for a specific DetNet flow.		to be ignored for a specific DetNet flow.
			The rules defined in this section only apply when the IPv4 Protocol
			or IPv6 Next Header Field contains the IANA defined value for AH or
			ESP.
	5.2. Forwarding Procedures		5.2. Forwarding Procedures
	General requirements for IP nodes are defined in [RFC1122], [RFC1812]		General requirements for IP nodes are defined in [RFC1122], [RFC1812]
	and [RFC8504], and are not modified by this document. The typical		and [RFC8504], and are not modified by this document. The typical
	next-hop selection process is impacted by DetNet. Specifically,		next-hop selection process is impacted by DetNet. Specifically,
	implementations of this document SHALL use management and control		implementations of this document SHALL use management and control
	information to select the one or more outgoing interfaces and next		information to select the one or more outgoing interfaces and next
	hops to be used for a packet associated with a DetNet flow.		hops to be used for a packet associated with a DetNet flow.
	The use of multiple paths or links, e.g., ECMP, to support a single		The use of multiple paths or links, e.g., ECMP, to support a single
	skipping to change at page 16, line 4 ¶		skipping to change at page 16, line 28 ¶
	Implementations of this document MUST ensure that a DetNet flow		Implementations of this document MUST ensure that a DetNet flow
	receives the traffic treatment that is provisioned for it via		receives the traffic treatment that is provisioned for it via
	configuration or the controller plane, e.g., via		configuration or the controller plane, e.g., via
	[I-D.ietf-detnet-yang]. General information on DetNet service can be		[I-D.ietf-detnet-yang]. General information on DetNet service can be
	found in [I-D.ietf-detnet-flow-information-model]. Typical		found in [I-D.ietf-detnet-flow-information-model]. Typical
	mechanisms used to provide different treatment to different flows		mechanisms used to provide different treatment to different flows
	includes the allocation of system resources (such as queues and		includes the allocation of system resources (such as queues and
	buffers) and provisioning or related parameters (such as shaping, and		buffers) and provisioning or related parameters (such as shaping, and
	policing). Support can also be provided via an underlying network		policing). Support can also be provided via an underlying network
	technology such as MPLS [I-D.ietf-detnet-ip-over-mpls] or IEEE802.1		technology such as MPLS [I-D.ietf-detnet-ip-over-mpls] or IEEE802.1
	TSN [I-D.ietf-detnet-ip-over-tsn]. Other than in the TSN case, the		TSN [I-D.ietf-detnet-ip-over-tsn]. Other mechanisms than the ones
	specific mechanisms used by a DetNet node to ensure DetNet service		used in the TSN case are outside the scope of this document.
	delivery requirements are met for supported DetNet flows is outside
	the scope of this document.
	6. Management and Control Information Summary		6. Management and Control Information Summary
	The following summarizes the set of information that is needed to		The following summarizes the set of information that is needed to
	identify individual and aggregated DetNet flows:		identify individual and aggregated DetNet flows:
	o IPv4 and IPv6 source address field.		o IPv4 and IPv6 source address field.
	o IPv4 and IPv6 source address prefix length, where a zero (0) value		o IPv4 and 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.
	skipping to change at page 16, line 34 ¶		skipping to change at page 17, line 11 ¶
	o IPv4 protocol field. A limited set of values is allowed, and the		o IPv4 protocol field. A limited set of values is allowed, and the
	ability to ignore this field, e.g., via configuration of the value		ability to ignore this field, e.g., via configuration of the value
	zero (0), is desirable.		zero (0), is desirable.
	o IPv6 next header field. A limited set of values is allowed, and		o IPv6 next header field. A limited set of values is allowed, and
	the ability to ignore this field, e.g., via configuration of the		the ability to ignore this field, e.g., via configuration of the
	value zero (0), is desirable.		value zero (0), is desirable.
	o For the IPv4 Type of Service and IPv6 Traffic Class Fields:		o For the IPv4 Type of Service and IPv6 Traffic Class Fields:
	* If the DSCP field is to be used in flow identification.		* Whether or not the DSCP field is used in flow identification.
	Ignoring the DSCP filed is optional.		Use of the DSCP field for flow identification is optional.
	* When the DSCP field is used in flow identification, a list of		* If the DSCP field is used to identify a flow, then the flow
	field values that may be used by a specific flow.		identification information (for that flow) includes a list of
			DSCPs used by that flow.
	o IPv6 flow label field. This field can be optionally used for		o IPv6 flow label field. This field can be optionally used for
	matching. When used, can be used instead of matching against the		matching. When used, can be used instead of matching against the
	Next Header field.		Next Header field.
	o TCP and UDP Source Port. Exact and wildcard matching is required.		o TCP and UDP Source Port. Exact and wildcard matching is required.
	Port ranges can optionally be used.		Port ranges can optionally be used.
	o TCP and UDP Destination Port. Exact and wildcard matching is		o TCP and UDP Destination Port. Exact and wildcard matching is
	required. Port ranges can optionally be used.		required. Port ranges can optionally be used.
	o IPsec Header SPI field. Exact matching is required.		o IPsec Header SPI field. Exact matching is required. Support for
			wildcard matching is recommended.
	This information MUST be provisioned per DetNet flow via		This information MUST be provisioned per DetNet flow via
	configuration, e.g., via the controller or management plane.		configuration, e.g., via the controller or management plane.
	Information identifying a DetNet flow is ordered and implementations		Information identifying a DetNet flow is ordered and implementations
	use the first match. This can, for example, be used to provide a		use the first match. This can, for example, be used to provide a
	DetNet service for a specific UDP flow, with unique Source and		DetNet service for a specific UDP flow, with unique Source and
	Destination Port field values, while providing a different service		Destination Port field values, while providing a different service
	for the aggregate of all other flows with that same UDP Destination		for the aggregate of all other flows with that same UDP Destination
	Port value.		Port value.
	skipping to change at page 18, line 31 ¶		skipping to change at page 19, line 7 ¶
	The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,		The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
	David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David		David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
	Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.		Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
	Bernardos for their various contributions to this work. David Black		Bernardos for their various contributions to this work. David Black
	served as technical advisor to the DetNet working group during the		served as technical advisor to the DetNet working group during the
	development of this document and provided many valuable comments.		development of this document and provided many valuable comments.
	10. Contributors		10. Contributors
	This document is derived from an earlier draft that was edited by		RFC7322 limits the number of authors listed on the front page of a
	Jouni Korhonen (jouni.nospam@gmail.com) and as such, he contributed		draft to a maximum of 5. The editor wishes to thank and acknowledge
	to and authored text in this document.		the follow authors for contributing text to this draft.
			Jouni Korhonen
			Email: jouni.nospam@gmail.com
			Andrew G. Malis
			Malis Consulting
			Email: agmalis@gmail.com
	11. References		11. References
	11.1. Normative references		11.1. Normative references
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,		DOI 10.17487/RFC0768, August 1980,
	<https://www.rfc-editor.org/info/rfc768>.		<https://www.rfc-editor.org/info/rfc768>.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	skipping to change at page 20, line 8 ¶		skipping to change at page 20, line 40 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	11.2. Informative references		11.2. Informative references
	[I-D.ietf-detnet-data-plane-framework]		[I-D.ietf-detnet-data-plane-framework]
	Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,		Varga, B., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, S., and J. Korhonen, "DetNet Data Plane		Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
	Framework", draft-ietf-detnet-data-plane-framework-03		data-plane-framework-04 (work in progress), February 2020.
	(work in progress), October 2019.
	[I-D.ietf-detnet-dp-sol-mpls]		[I-D.ietf-detnet-dp-sol-mpls]
	Korhonen, J. and B. Varga, "DetNet MPLS Data Plane		Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
	Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in		Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in
	progress), March 2019.		progress), March 2019.
	[I-D.ietf-detnet-flow-information-model]		[I-D.ietf-detnet-flow-information-model]
	Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D.		Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D.
	Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-		Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-
	flow-information-model-06 (work in progress), October		flow-information-model-07 (work in progress), March 2020.
	2019.
	[I-D.ietf-detnet-ip-over-mpls]		[I-D.ietf-detnet-ip-over-mpls]
	Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,		Varga, B., Berger, L., Fedyk, D., Malis, A., Bryant, S.,
	Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over		and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft-
	MPLS", draft-ietf-detnet-ip-over-mpls-04 (work in		ietf-detnet-ip-over-mpls-05 (work in progress), February
	progress), November 2019.		2020.
	[I-D.ietf-detnet-ip-over-tsn]		[I-D.ietf-detnet-ip-over-tsn]
	Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet		Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet
	Data Plane: IP over IEEE 802.1 Time Sensitive Networking		Data Plane: IP over IEEE 802.1 Time Sensitive Networking
	(TSN)", draft-ietf-detnet-ip-over-tsn-01 (work in		(TSN)", draft-ietf-detnet-ip-over-tsn-02 (work in
	progress), October 2019.		progress), March 2020.
	[I-D.ietf-detnet-mpls]		[I-D.ietf-detnet-mpls]
	Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,		Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
	Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",		Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
	draft-ietf-detnet-mpls-04 (work in progress), November		draft-ietf-detnet-mpls-05 (work in progress), February
	2019.		2020.
	[I-D.ietf-detnet-security]		[I-D.ietf-detnet-security]
	Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,		Mizrahi, T. and E. Grossman, "Deterministic Networking
	J., Austad, H., and N. Finn, "Deterministic Networking
	(DetNet) Security Considerations", draft-ietf-detnet-		(DetNet) Security Considerations", draft-ietf-detnet-
	security-07 (work in progress), January 2020.		security-09 (work in progress), March 2020.
	[I-D.ietf-detnet-tsn-vpn-over-mpls]		[I-D.ietf-detnet-tsn-vpn-over-mpls]
	Varga, B., Farkas, J., Malis, A., Bryant, S., and D.		Varga, B., Farkas, J., Malis, A., Bryant, S., and D.
	Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive		Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive
	Networking over MPLS", draft-ietf-detnet-tsn-vpn-over-		Networking over MPLS", draft-ietf-detnet-tsn-vpn-over-
	mpls-01 (work in progress), October 2019.		mpls-02 (work in progress), March 2020.
	[I-D.ietf-detnet-yang]		[I-D.ietf-detnet-yang]
	Geng, X., Chen, M., Ryoo, Y., Li, Z., and R. Rahman,		Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D.
	"Deterministic Networking (DetNet) Configuration YANG		Fedyk, "Deterministic Networking (DetNet) Configuration
	Model", draft-ietf-detnet-yang-04 (work in progress),		YANG Model", draft-ietf-detnet-yang-05 (work in progress),
	November 2019.		March 2020.
	[IEEE802.1AE-2018]		[IEEE802.1AE-2018]
	IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC		IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
	Security (MACsec)", 2018,		Security (MACsec)", 2018,
	<https://ieeexplore.ieee.org/document/8585421>.		<https://ieeexplore.ieee.org/document/8585421>.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	<https://www.rfc-editor.org/info/rfc1122>.		<https://www.rfc-editor.org/info/rfc1122>.
	skipping to change at page 23, line 4 ¶		skipping to change at page 23, line 32 ¶
	Lou Berger		Lou Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: lberger@labn.net		Email: lberger@labn.net
	Don Fedyk		Don Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: dfedyk@labn.net		Email: dfedyk@labn.net
	Andrew G. Malis
	Independent
	Email: agmalis@gmail.com
	Stewart Bryant		Stewart Bryant
	Futurewei Technologies		Futurewei Technologies
	Email: stewart.bryant@gmail.com		Email: stewart.bryant@gmail.com
End of changes. 47 change blocks.
	94 lines changed or deleted		114 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/