rfc8939v4.txt		rfc8939.txt
	skipping to change at line 16 ¶		skipping to change at line 16 ¶
	D. Fedyk		D. Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	S. Bryant		S. Bryant
	Futurewei Technologies		Futurewei Technologies
	November 2020		November 2020
	Deterministic Networking (DetNet) Data Plane: IP		Deterministic Networking (DetNet) Data Plane: IP
	Abstract		Abstract
	This document specifies the Deterministic Networking (DetNet) data-		This document specifies the Deterministic Networking (DetNet) data
	plane operation for IP hosts and routers that provide DetNet service		plane operation for IP hosts and routers that provide DetNet service
	to IP-encapsulated data. No DetNet-specific encapsulation is defined		to IP-encapsulated data. No DetNet-specific encapsulation is defined
	to support IP flows; instead, the existing IP-layer and higher-layer		to support IP flows; instead, the existing IP-layer and higher-layer
	protocol header information is used to support flow identification		protocol header information is used to support flow identification
	and DetNet service delivery. This document builds on the DetNet		and DetNet service delivery. This document builds on the DetNet
	architecture (RFC 8655) and data-plane framework (RFC 8938).		architecture (RFC 8655) and data plane framework (RFC 8938).
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 61 ¶		skipping to change at line 61 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Terminology		2. Terminology
	2.1. Terms Used in This Document		2.1. Terms Used in This Document
	2.2. Abbreviations		2.2. Abbreviations
	2.3. Requirements Language		2.3. Requirements Language
	3. Overview of the DetNet IP Data Plane		3. Overview of the DetNet IP Data Plane
	4. DetNet IP Data-Plane Considerations		4. DetNet IP Data Plane Considerations
	4.1. End-System-Specific Considerations		4.1. End-System-Specific Considerations
	4.2. DetNet Domain-Specific Considerations		4.2. DetNet Domain-Specific Considerations
	4.3. Forwarding Sub-Layer Considerations		4.3. Forwarding Sub-Layer Considerations
	4.3.1. Class of Service		4.3.1. Class of Service
	4.3.2. Quality of Service		4.3.2. Quality of Service
	4.3.3. Path Selection		4.3.3. Path Selection
	4.4. DetNet Flow Aggregation		4.4. DetNet Flow Aggregation
	4.5. Bidirectional Traffic		4.5. Bidirectional Traffic
	5. DetNet IP Data-Plane Procedures		5. DetNet IP Data Plane Procedures
	5.1. DetNet IP Flow Identification Procedures		5.1. DetNet IP Flow Identification Procedures
	5.1.1. IP Header Information		5.1.1. IP Header Information
	5.1.2. Other Protocol Header Information		5.1.2. Other Protocol Header Information
	5.2. Forwarding Procedures		5.2. Forwarding Procedures
	5.3. DetNet IP Traffic Treatment Procedures		5.3. DetNet IP Traffic Treatment Procedures
	6. Management and Control Information Summary		6. Management and Control Information Summary
	7. Security Considerations		7. Security Considerations
	8. IANA Considerations		8. IANA Considerations
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	skipping to change at line 94 ¶		skipping to change at line 94 ¶
	Authors' Addresses		Authors' Addresses
	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 with		a network to DetNet flows. DetNet provides these flows with
	extremely low packet loss rates and assured maximum end-to-end		extremely low packet loss rates and assured maximum end-to-end
	delivery latency. General background and concepts of DetNet can be		delivery latency. General background and concepts of DetNet can be
	found in the DetNet 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;		DetNet-specific encapsulation is defined to support IP flows;
	instead, the existing IP-layer and higher-layer protocol header		instead, the existing IP-layer and higher-layer protocol header
	information is used to support flow identification and DetNet service		information is used to support flow identification and DetNet service
	delivery. Common data-plane procedures and control information for		delivery. Common data plane procedures and control information for
	all DetNet data planes can be found in [RFC8938].		all DetNet data planes can be found in [RFC8938].
	The DetNet architecture models the DetNet-related data-plane		The DetNet architecture models the DetNet-related data plane
	functions as two sub-layers: a service sub-layer and a forwarding		functions as two sub-layers: a service sub-layer and a forwarding
	sub-layer. The service sub-layer is used to provide DetNet service		sub-layer. The service sub-layer is used to provide DetNet service
	protection (e.g., by the Packet Replication Function (PRF) and Packet		protection (e.g., by the Packet Replication Function (PRF) and Packet
	Elimination Function (PEF)) and reordering. The forwarding sub-layer		Elimination Function (PEF)) and reordering. The forwarding sub-layer
	is used to provide congestion protection (low loss, assured latency,		is used to provide congestion protection (low loss, assured latency,
	and limited out-of-order delivery). The service sub-layer generally		and limited out-of-order delivery). The service sub-layer generally
	requires additional header fields to provide its service; for		requires additional header fields to provide its service; for
	example, see [DetNet-MPLS]. Since no DetNet-specific fields are		example, see [DetNet-MPLS]. Since no DetNet-specific fields are
	added to support DetNet IP flows, only the forwarding sub-layer		added to support DetNet IP flows, only the forwarding sub-layer
	functions are supported using the DetNet IP defined by this document.		functions are supported using the DetNet IP defined by this document.
	Service protection can be provided on a per-sub-network basis using		Service protection can be provided on a per-sub-network basis using
	technologies such as MPLS [DetNet-MPLS-DP] and Ethernet, as specified		technologies such as MPLS [DetNet-MPLS] and Ethernet, as specified by
	by the IEEE 802.1 TSN (Time-Sensitive Networking) task group		the IEEE 802.1 TSN (Time-Sensitive Networking) task group (referred
	(referred to in this document simply as "IEEE 802.1 TSN"). See		to in this document simply as "IEEE 802.1 TSN"). See
	[IEEE802.1TSNTG].		[IEEE802.1TSNTG].
	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 and considerations that apply to providing DetNet services		Section 3 and considerations that apply to providing DetNet services
	via the DetNet IP data plane in Section 4. Section 5 provides the		via 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 line 179 ¶		skipping to change at line 179 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Overview of the DetNet IP Data Plane		3. Overview of the DetNet IP Data Plane
	This document describes how IP is used by DetNet nodes, i.e., hosts		This document describes how IP is used by DetNet nodes, i.e., hosts
	and routers, to identify DetNet flows and provide a DetNet service		and routers, to identify DetNet flows and provide a DetNet service
	using an IP data plane. From a data-plane perspective, an end-to-end		using an IP data plane. From a data plane perspective, an end-to-end
	IP model is followed. As mentioned above, existing IP-layer and		IP model is followed. As mentioned above, existing IP-layer and
	higher-layer protocol header information is used to support flow		higher-layer protocol header information is used to support flow
	identification and DetNet service delivery. Common data-plane		identification and DetNet service delivery. Common data plane
	procedures and control information for all DetNet data planes can be		procedures and control information for all DetNet data planes can be
	found in [RFC8938].		found in [RFC8938].
	The DetNet IP data plane primarily uses 6-tuple-based flow		The DetNet IP data plane primarily uses 6-tuple-based flow
	identification, where "6-tuple" refers to information carried in IP-		identification, where "6-tuple" refers to information carried in IP-
	layer and higher-layer protocol headers. The 6-tuple referred to in		layer and higher-layer protocol headers. The 6-tuple referred to in
	this document is the same as that defined in [RFC3290].		this document is the same as that defined in [RFC3290].
	Specifically, the 6-tuple is destination address, source address, IP		Specifically, the 6-tuple is destination address, source address, IP
	protocol, source port, destination port, and DSCP. General		protocol, source port, destination port, and DSCP. General
	background on the use of IP headers and 5-tuples to identify flows		background on the use of IP headers and 5-tuples to identify flows
	skipping to change at line 289 ¶		skipping to change at line 289 ¶
	the DetNet domain and provide DetNet service proxies for the end		the DetNet domain and provide DetNet service proxies for the end
	applications by initiating and terminating DetNet service for the		applications by initiating and terminating DetNet service for the
	application's IP flows. The existing header information or an		application's IP flows. The existing header information or an
	approach such as described in Section 4.4 can be used to support		approach such as described in Section 4.4 can be used to support
	DetNet flow identification.		DetNet flow identification.
	Note that Figures 1 and 2 can be collapsed, so IP DetNet end systems		Note that Figures 1 and 2 can be collapsed, so IP DetNet end systems
	can communicate over a DetNet IP network with IP end systems.		can communicate over a DetNet IP network with IP end systems.
	As non-DetNet and DetNet IP packets have the same protocol header		As non-DetNet and DetNet IP packets have the same protocol header
	format on the wire, from a data-plane perspective, the only		format on the wire, from a data plane perspective, the only
	difference is that there is flow-associated DetNet information on		difference is that there is flow-associated DetNet information on
	each DetNet node that defines the flow-related characteristics and		each DetNet node that defines the flow-related characteristics and
	required forwarding behavior. As shown above, edge nodes provide a		required forwarding behavior. As shown above, edge nodes provide a
	Service Proxy function that "associates" one or more IP flows with		Service Proxy function that "associates" one or more IP flows with
	the appropriate DetNet flow-specific information and ensures that the		the appropriate DetNet flow-specific information and ensures that the
	flow receives the proper traffic treatment within the domain.		flow receives the proper traffic treatment within the domain.
	| Note: The operation of IEEE 802.1 TSN end systems over DetNet-		| Note: The operation of IEEE 802.1 TSN end systems over DetNet-
	| enabled IP networks is not described in this document. TSN		| enabled IP networks is not described in this document. TSN
	| over MPLS is described in [DetNet-TSN-over-MPLS].		| over MPLS is described in [DetNet-TSN-over-MPLS].
	4. DetNet IP Data-Plane Considerations		4. DetNet IP Data Plane Considerations
	This section provides considerations related to providing DetNet		This section provides considerations related to providing DetNet
	service to flows that are identified based on their header		service to flows that are identified based on their header
	information.		information.
	4.1. End-System-Specific Considerations		4.1. End-System-Specific Considerations
	Data flows requiring DetNet service are generated and terminated on		Data flows requiring DetNet service are generated and terminated on
	end systems. This document deals only with IP end systems. The		end systems. This document deals only with IP end systems. The
	protocols used by an IP end system are specific to an application,		protocols used by an IP end system are specific to an application,
	skipping to change at line 496 ¶		skipping to change at line 496 ¶
	* Discarding packets associated with an incomplete reservation.		* Discarding packets associated with an incomplete reservation.
	* Re-marking packets associated with an incomplete reservation. Re-		* Re-marking packets associated with an incomplete reservation. Re-
	marking can be accomplished by changing the value of the DSCP		marking can be accomplished by changing the value of the DSCP
	field to a value that results in the packet no longer matching any		field to a value that results in the packet no longer 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 the scope		While path selection algorithms and mechanisms are out of the scope
	of the DetNet data-plane definition, it is important to highlight the		of 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 optional (flow		flows using 6-tuple header information as well as the optional (flow
	label) header field. DetNet generally allows for both flow-specific		label) header field. DetNet generally allows for both flow-specific
	traffic treatment and flow-specific next hops.		traffic treatment and flow-specific next hops.
	In non-DetNet IP forwarding, it is generally assumed that the same		In non-DetNet IP forwarding, it is generally assumed that the same
	series of next hops, i.e., the same path, will be used for a		series of next hops, i.e., the same path, will be used for a
	particular 5-tuple or, in some cases (e.g., [RFC5120]), for a		particular 5-tuple or, in some cases (e.g., [RFC5120]), for a
	particular 6-tuple. Using different next hops for different 5-tuples		particular 6-tuple. Using different next hops for different 5-tuples
	skipping to change at line 523 ¶		skipping to change at line 523 ¶
	being split across multiple next hops. Understanding of the		being split across multiple next hops. Understanding of the
	application and transport protocol impact of using different next		application and transport protocol impact of using different next
	hops for the same 5-tuple is required. Again, this only indirectly		hops for the same 5-tuple is required. Again, this only indirectly
	impacts path selection for DetNet flows and this document.		impacts path selection for DetNet flows and this document.
	4.4. DetNet Flow Aggregation		4.4. DetNet Flow Aggregation
	As described in [RFC8938], the ability to aggregate individual flows		As described in [RFC8938], the ability to aggregate individual flows
	and their associated resource control into a larger aggregate is an		and their associated resource control into a larger aggregate is an
	important technique for improving scaling by reducing the state per		important technique for improving scaling by reducing the state per
	hop. DetNet IP data-plane aggregation can take place within a single		hop. DetNet IP data plane aggregation can take place within a single
	node, when that node maintains state about both the aggregated and		node, when that node maintains state about both the aggregated and
	individual flows. It can also take place between nodes, when one		individual flows. It can also take place between nodes, when one
	node maintains state about only flow aggregates while the other node		node maintains state about only flow aggregates while the other node
	maintains state on all or a portion of the component flows. In		maintains state on all or a portion of the component flows. In
	either case, the management or control function that provisions the		either case, the management or control function that provisions the
	aggregate flows must ensure that adequate resources are allocated and		aggregate flows must ensure that adequate resources are allocated and
	configured to provide the combined service requirements of the		configured to provide the combined service requirements of the
	individual flows. As DetNet is concerned about latency and jitter,		individual flows. As DetNet is concerned about latency and jitter,
	more than just bandwidth needs to be considered.		more than just 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 flow		discussed above, IP flow identification uses the IP 6-tuple for flow
	identification. DetNet IP flows can be aggregated using any of the		identification. DetNet IP flows can be aggregated using any of the
	6-tuple fields and optionally also by the flow label. The use of		6-tuple fields and optionally also by the flow label. The use of
	prefixes, wildcards, lists, and value ranges allows a DetNet node to		prefixes, wildcards, lists, and value ranges allows a DetNet node to
	identify aggregate DetNet flows. From a resource allocation		identify aggregate DetNet flows. From a resource allocation
	perspective, DetNet nodes ought to provide service to an aggregate		perspective, DetNet nodes ought to provide service to an aggregate
	rather than on a component flow basis.		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
	skipping to change at line 559 ¶		skipping to change at line 559 ¶
	are satisfied by the aggregate; see Section 5.3.		are satisfied by the aggregate; see Section 5.3.
	The DetNet Controller Plane MUST ensure that non-congestion-		The DetNet Controller Plane MUST ensure that non-congestion-
	responsive DetNet traffic is not forwarded outside a DetNet domain.		responsive DetNet traffic is not forwarded outside a DetNet domain.
	4.5. Bidirectional Traffic		4.5. Bidirectional Traffic
	While the DetNet IP data plane must support bidirectional DetNet		While the DetNet IP data plane must support bidirectional DetNet
	flows, there are no special bidirectional features within the data		flows, there are no special bidirectional features within the data
	plane. The special case of co-routed bidirectional DetNet flows is		plane. The special case of co-routed bidirectional DetNet flows is
	solely represented at the management- and control-plane levels,		solely represented at the management and control plane levels,
	without specific support or knowledge within the DetNet data plane.		without specific support or knowledge within the DetNet data plane.
	Fate sharing and associated or co-routed bidirectional flows can be		Fate sharing and associated or co-routed bidirectional flows can be
	managed at the control level.		managed at the control level.
	Control and management mechanisms need to support bidirectional		Control and management mechanisms need to support bidirectional
	flows, but the specification of such mechanisms is out of the scope		flows, but the specification of such mechanisms is out of the scope
	of this document. An example control-plane solution for MPLS can be		of this document. An example control plane solution for MPLS can be
	found in [RFC7551].		found in [RFC7551].
	5. DetNet IP Data-Plane Procedures		5. DetNet IP Data Plane Procedures
	This section provides DetNet IP data-plane procedures. These		This section provides DetNet IP data plane procedures. These
	procedures have been divided into the following areas: flow		procedures have been divided into the following areas: flow
	identification, forwarding, and traffic treatment. Flow		identification, forwarding, and traffic treatment. Flow
	identification includes those procedures related to matching IP-layer		identification includes those procedures related to matching IP-layer
	and higher-layer protocol header information to DetNet flow (state)		and 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		sometimes called "traffic classification"; for example, see
	[RFC5777]. Forwarding includes those procedures related to next-hop		[RFC5777]. Forwarding includes those procedures related to next-hop
	selection and delivery. Traffic treatment includes those procedures		selection and delivery. Traffic treatment includes those procedures
	related to providing an identified flow with the required DetNet		related to providing an identified flow with the required DetNet
	service.		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 to 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 it 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
	[DetNet-YANG].		[DetNet-YANG].
	skipping to change at line 853 ¶		skipping to change at line 853 ¶
	The primary consideration for the DetNet data plane is to maintain		The primary consideration for the DetNet data plane is to maintain
	integrity of data and delivery of the associated DetNet service		integrity of data and delivery of the associated DetNet service
	traversing the DetNet network. Since no DetNet-specific fields are		traversing the DetNet network. Since no DetNet-specific fields are
	available in the DetNet IP data plane, the integrity and		available in the DetNet IP data plane, the integrity and
	confidentiality of application flows can be protected through		confidentiality of application flows can be protected through
	whatever means are provided by the underlying technology. For		whatever means are provided by the underlying technology. For
	example, encryption may be used, such as that provided by IPsec		example, encryption may be used, such as that provided by IPsec
	[RFC4301] for IP flows and/or by an underlying sub-network using		[RFC4301] for IP flows and/or by an underlying sub-network using
	MACsec [IEEE802.1AE-2018] for IP over Ethernet (Layer 2) flows.		MACsec [IEEE802.1AE-2018] for IP over Ethernet (Layer 2) flows.
	From a data-plane perspective, this document does not add or modify		From a data plane perspective, this document does not add or modify
	any header information.		any header information.
	At the management and control level, DetNet flows are identified on a		At the management and control level, DetNet flows are identified on a
	per-flow basis, which may provide Controller-Plane attackers with		per-flow basis, which may provide Controller Plane attackers with
	additional information about the data flows (when compared to		additional information about the data flows (when compared to
	Controller Planes that do not include per-flow identification). This		Controller Planes that do not include per-flow identification). This
	is an inherent property of DetNet that has security implications that		is an inherent property of DetNet that has security implications that
	should be considered when determining if DetNet is a suitable		should be considered when determining if DetNet is a suitable
	technology for any given use case.		technology for any given use case.
	To provide uninterrupted availability of the DetNet service,		To provide uninterrupted availability of the DetNet service,
	provisions can be made against DoS attacks and delay attacks. To		provisions can be made against DoS attacks and delay attacks. To
	protect against DoS attacks, excess traffic due to malicious or		protect against DoS attacks, excess traffic due to malicious or
	malfunctioning devices can be prevented or mitigated -- for example,		malfunctioning devices can be prevented or mitigated -- for example,
	skipping to change at line 947 ¶		skipping to change at line 947 ¶
	(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>.
	[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/rfc/rfc8938>.		<https://www.rfc-editor.org/rfc/rfc8938>.
	9.2. Informative References		9.2. Informative References
	[DetNet-Flow-Info]		[DetNet-Flow-Info]
	Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.		Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
	Fedyk, "DetNet Flow Information Model", Work in Progress,		Fedyk, "DetNet Flow Information Model", Work in Progress,
	Internet-Draft, draft-ietf-detnet-flow-information-model-		Internet-Draft, draft-ietf-detnet-flow-information-model-
	11, 21 October 2020, <https://tools.ietf.org/html/draft-		11, 21 October 2020, <https://tools.ietf.org/html/draft-
	skipping to change at line 978 ¶		skipping to change at line 978 ¶
	Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,		Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,
	"DetNet Data Plane: IP over IEEE 802.1 Time Sensitive		"DetNet Data Plane: IP over IEEE 802.1 Time Sensitive
	Networking (TSN)", Work in Progress, Internet-Draft,		Networking (TSN)", Work in Progress, Internet-Draft,
	draft-ietf-detnet-ip-over-tsn-04, 2 November 2020,		draft-ietf-detnet-ip-over-tsn-04, 2 November 2020,
	<https://tools.ietf.org/html/draft-ietf-detnet-ip-over-		<https://tools.ietf.org/html/draft-ietf-detnet-ip-over-
	tsn-04>.		tsn-04>.
	[DetNet-MPLS]		[DetNet-MPLS]
	Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,		Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
	S., and J. Korhonen, "DetNet Data Plane: MPLS", Work in		S., and J. Korhonen, "DetNet Data Plane: MPLS", Work in
	Progress, Internet-Draft, draft-ietf-detnet-mpls-13,		Progress, Internet-Draft, draft-ietf-detnet-mpls-13, 11
	October 2020,		October 2020,
	<https://tools.ietf.org/html/draft-ietf-detnet-mpls-13>.		<https://tools.ietf.org/html/draft-ietf-detnet-mpls-13>.
	[DetNet-MPLS-DP]
	Korhonen, J., Ed. and B. Varga, Ed., "DetNet MPLS Data
	Plane Encapsulation", Work in Progress, Internet-Draft,
	draft-ietf-detnet-dp-sol-mpls-02, 10 March 2019,
	<https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-
	mpls-02>.
	[DetNet-Security]		[DetNet-Security]
	Mizrahi, T. and E. Grossman, Ed., "Deterministic		Grossman, E., Ed., Mizrahi, T., and A. Hacker,
	Networking (DetNet) Security Considerations", Work in		"Deterministic Networking (DetNet) Security
	Progress, Internet-Draft, draft-ietf-detnet-security-12,		Considerations", Work in Progress, Internet-Draft, draft-
	October 2020, <https://tools.ietf.org/html/draft-ietf-		ietf-detnet-security-12, 2 October 2020,
	detnet-security-12>.		<https://tools.ietf.org/html/draft-ietf-detnet-security-
			12>.
	[DetNet-TSN-over-MPLS]		[DetNet-TSN-over-MPLS]
	Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D.		Varga, B., Ed., 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", Work in Progress, Internet-Draft,		Networking over MPLS", Work in Progress, Internet-Draft,
	draft-ietf-detnet-tsn-vpn-over-mpls-04, 2 November 2020,		draft-ietf-detnet-tsn-vpn-over-mpls-04, 2 November 2020,
	<https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-		<https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-
	over-mpls-04>.		over-mpls-04>.
	[DetNet-YANG]		[DetNet-YANG]
	Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and		Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and
	Z. Li, "Deterministic Networking (DetNet) Configuration		Z. Li, "Deterministic Networking (DetNet) Configuration
	YANG Model", Work in Progress, Internet-Draft, draft-ietf-		YANG Model", Work in Progress, Internet-Draft, draft-ietf-
	detnet-yang-08, 12 October 2020,		detnet-yang-09, 16 November 2020,
	<https://tools.ietf.org/html/draft-ietf-detnet-yang-08>.		<https://tools.ietf.org/html/draft-ietf-detnet-yang-09>.
	[IEEE802.1AE-2018]		[IEEE802.1AE-2018]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE, "IEEE Standard for Local and metropolitan area
	networks-Media Access Control (MAC) Security", IEEE		networks-Media Access Control (MAC) Security", IEEE
	802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December		802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
	2018, <https://ieeexplore.ieee.org/document/8585421>.		2018, <https://ieeexplore.ieee.org/document/8585421>.
	[IEEE802.1TSNTG]		[IEEE802.1TSNTG]
	IEEE, "Time-Sensitive Networking (TSN) Task Group",		IEEE, "Time-Sensitive Networking (TSN) Task Group",
	<https://1.ieee802.org/tsn/>.		<https://1.ieee802.org/tsn/>.
	skipping to change at line 1106 ¶		skipping to change at line 1100 ¶
	Alvaro Retana, Benjamin Kaduk, Rob Wilton, and Érik Vyncke.		Alvaro Retana, Benjamin Kaduk, Rob Wilton, and Érik Vyncke.
	Contributors		Contributors
	The editor of this document wishes to thank and acknowledge the		The editor of this document wishes to thank and acknowledge the
	following people who contributed substantially to the content of this		following people who contributed substantially to the content of this
	document and should be considered coauthors:		document and should be considered coauthors:
	Jouni Korhonen		Jouni Korhonen
	Email: Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
	Andrew G. Malis		Andrew G. Malis
	Malis Consulting		Malis Consulting
	Email: agmalis@gmail.com		Email: agmalis@gmail.com
	Authors' Addresses		Authors' Addresses
	Balázs Varga (editor)		Balázs Varga (editor)
	Ericsson		Ericsson
End of changes. 28 change blocks.
	41 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/