draft-ietf-detnet-ip-over-tsn-02.txt		draft-ietf-detnet-ip-over-tsn-03.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: September 7, 2020 A. Malis		Expires: December 10, 2020 A. Malis
	Independent		Malis Consulting
	S. Bryant		S. Bryant
	Futurewei Technologies		Futurewei Technologies
	March 6, 2020		June 8, 2020
	DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)		DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)
	draft-ietf-detnet-ip-over-tsn-02		draft-ietf-detnet-ip-over-tsn-03
	Abstract		Abstract
	This document specifies the Deterministic Networking IP data plane		This document specifies the Deterministic Networking IP data plane
	when operating over a TSN sub-network.		when operating over a TSN sub-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 35 ¶		skipping to change at page 1, line 35 ¶
	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 September 7, 2020.		This Internet-Draft will expire on December 10, 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 21 ¶		skipping to change at page 2, line 21 ¶
	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 . . . . . . . . . . . . . . . . . . 3		2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3
	3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 3		3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 3
	4. DetNet IP Flows over an IEEE 802.1 TSN sub-network . . . . 5		4. DetNet IP Flows over an IEEE 802.1 TSN sub-network . . . . 5
	4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 6		4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 6
	4.2. TSN requirements of IP DetNet nodes . . . . . . . . . . . 6		4.2. TSN requirements of IP DetNet nodes . . . . . . . . . . . 6
	4.3. Service protection within the TSN sub-network . . . . . . 8		4.3. Service protection within the TSN sub-network . . . . . . 8
	4.4. Aggregation during DetNet flow to TSN Stream mapping . . 8		4.4. Aggregation during DetNet flow to TSN Stream mapping . . 8
	5. Management and Control Implications . . . . . . . . . . . . . 8		5. Management and Control Implications . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative references . . . . . . . . . . . . . . . . . . 10		9.1. Normative references . . . . . . . . . . . . . . . . . . 10
	9.2. Informative references . . . . . . . . . . . . . . . . . 10		9.2. Informative references . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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 extremely low
	packet loss rates and assured maximum end-to-end delivery latency.		packet loss rates and assured maximum end-to-end delivery latency.
	General background and concepts of DetNet can be found in the DetNet		General background and concepts of DetNet can be found in the DetNet
	Architecture [RFC8655].		Architecture [RFC8655].
	[I-D.ietf-detnet-ip] specifies the DetNet data plane operation for IP		[I-D.ietf-detnet-ip] specifies the DetNet data plane operation for IP
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	masks, prefixes and ranges. IP tunnels may also be used to support		masks, prefixes and ranges. IP tunnels may also be used to support
	flow aggregation. In these cases, it is expected that DetNet aware		flow aggregation. In these cases, it is expected that DetNet aware
	intermediate nodes will provide DetNet service assurance on the		intermediate nodes will provide DetNet service assurance on the
	aggregate through resource allocation and congestion control		aggregate through resource allocation and congestion control
	mechanisms.		mechanisms.
	Congestion protection, latency control and the resource allocation		Congestion protection, latency control and the resource allocation
	(queuing, policing, shaping) are supported using the underlying link		(queuing, policing, shaping) are supported using the underlying link
	/ sub-net specific mechanisms. Service protections (packet		/ sub-net specific mechanisms. Service protections (packet
	replication and packet elimination functions) are not provided at the		replication and packet elimination functions) are not provided at the
	DetNet layer end to end due the lack of a unified end to end		DetNet layer end-to-end due the lack of a unified end-to-end
	sequencing information that would be available for intermediate		sequencing information that would be available for intermediate
	nodes. However, such service protection can be provided on a per		nodes. However, such service protection can be provided on a per
	underlying L2 link and sub-network basis.		underlying L2 link and sub-network basis.
	Edge Transit Relay		Edge Transit Relay
	Node Node Node		Node Node Node
	+.........+		+.........+
	<--:Svc Proxy:-- End to End Service ----------->		<--:Svc Proxy:-- End to End Service ----------->
	+-----....+ +..........+		+-----....+ +..........+
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 49 ¶
	domain and provide DetNet service proxies for the end applications by		domain and provide DetNet service proxies for the end applications by
	initiating and terminating DetNet service for the application's IP		initiating and terminating DetNet service for the application's IP
	flows. Node and interface resources are allocated to ensure DetNet		flows. Node and interface resources are allocated to ensure DetNet
	service requirements. Dotted lines around the Service components of		service requirements. Dotted lines around the Service components of
	the Edge and Relay Nodes indicate that they are DetNet service aware		the Edge and Relay Nodes indicate that they are DetNet service aware
	but do not perform any DetNet service sub-layer function, e.g., PREOF		but do not perform any DetNet service sub-layer function, e.g., PREOF
	(Packet Replication, Elimination, and Ordering Functions). In this		(Packet Replication, Elimination, and Ordering Functions). In this
	example the Edge Node and the Transit Node are interconnected by a		example the Edge Node and the Transit Node are interconnected by a
	TSN sub-network, being the primary focus of this document.		TSN sub-network, being the primary focus of this document.
	DetNet routers ensure that detnet service requirements are met per		DetNet routers ensure that DetNet service requirements are met per
	hop by allocating local resources, both receive and transmit, and by		hop by allocating local resources, both receive and transmit, and by
	mapping the service requirements of each flow to appropriate sub-		mapping the service requirements of each flow to appropriate sub-
	network mechanisms. Such mappings are sub-network technology		network mechanisms. Such mappings are sub-network technology
	specific. The mapping of DetNet IP flows to TSN streams and TSN		specific. The mapping of DetNet IP flows to TSN streams and TSN
	protection mechanisms are covered in Section 4.		protection mechanisms are covered in Section 4.
	4. DetNet IP Flows over an IEEE 802.1 TSN sub-network		4. DetNet IP Flows over an IEEE 802.1 TSN sub-network
	This section covers how DetNet IP flows operate over an IEEE 802.1		This section covers how DetNet IP flows operate over an IEEE 802.1
	TSN sub-network. Figure 2 illustrates such a scenario, where two IP		TSN sub-network. Figure 2 illustrates such a scenario, where two IP
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	+----[ TSN-Sub ]---+ /		+----[ TSN-Sub ]---+ /
	[ Network ]--------+		[ Network ]--------+
	`-------'		`-------'
	<----------------- DetNet IP ----------------->		<----------------- DetNet IP ----------------->
	Figure 2: DetNet (DN) Enabled IP Network over a TSN sub-network		Figure 2: DetNet (DN) Enabled IP Network over a TSN sub-network
	The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1		The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
	Working Group have defined (and are defining) a number of amendments		Working Group have defined (and are defining) a number of amendments
	to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and		to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and
	bounded latency in bridged networks. Furthermore IEEE 802.1CB		bounded latency in bridged networks. Furthermore, IEEE 802.1CB
	[IEEE8021CB] defines frame replication and elimination functions for		[IEEE8021CB] defines frame replication and elimination functions for
	reliability that should prove both compatible with and useful to		reliability that should prove both compatible with and useful to
	DetNet networks. All these functions have to identify flows that		DetNet networks. All these functions have to identify flows that
	require TSN treatment.		require TSN treatment.
	TSN capabilities of the TSN sub-network are made available for IP		TSN capabilities of the TSN sub-network are made available for IP
	(DetNet) flows via the protocol interworking function defined in IEEE		(DetNet) flows via the protocol interworking function desribed in
	802.1CB [IEEE8021CB]. For example, applied on the TSN edge port it		Annex C.5 of IEEE 802.1CB [IEEE8021CB]. For example, applied on the
	can convert an ingress unicast IP (DetNet) flow to use a specific		TSN edge port it can convert an ingress unicast IP (DetNet) flow to
	Layer-2 multicast destination MAC address and a VLAN, in order to		use a specific Layer-2 multicast destination MAC address and a VLAN,
	direct the packet through a specific path inside the bridged network.		in order to direct the packet through a specific path inside the
	A similar interworking function pair at the other end of the TSN sub-		bridged network. A similar interworking function pair at the other
	network would restore the packet to its original Layer-2 destination		end of the TSN sub-network would restore the packet to its original
	MAC address and VLAN.		Layer-2 destination MAC address and VLAN.
	Placement of TSN functions depends on the TSN capabilities of nodes.		Placement of TSN functions depends on the TSN capabilities of nodes.
	IP (DetNet) Nodes may or may not support TSN functions. For a given		IP (DetNet) Nodes may or may not support TSN functions. For a given
	TSN Stream (i.e., DetNet flow) an IP (DetNet) node is treated as a		TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is
	Talker or a Listener inside the TSN sub-network.		treated as a Talker or a Listener inside the TSN sub-network.
	4.1. Functions for DetNet Flow to TSN Stream Mapping		4.1. Functions for DetNet Flow to TSN Stream Mapping
	Mapping of a DetNet IP flow to a TSN Stream is provided via the		Mapping of a DetNet IP flow to a TSN Stream is provided via the
	combination of a passive and an active stream identification function		combination of a passive and an active stream identification function
	that operate at the frame level. The passive stream identification		that operate at the frame level (Layer-2). The passive stream
	function is used to catch the 6-tuple of a DetNet IP flow and the		identification function is used to catch the 6-tuple of a DetNet IP
	active stream identification function is used to modify the Ethernet		flow and the active stream identification function is used to modify
	header according to ID of the mapped TSN Stream.		the Ethernet header according to the ID of the mapped TSN Stream.
	IEEE 802.1CB [IEEE8021CB] defines an IP Stream identification		Clause 6.7 of IEEE 802.1CB [IEEE8021CB] defines an IP Stream
	function that can be used as a passive function for IP DetNet flows		identification function that can be used as a passive function for IP
	using UDP or TCP. IEEE P802.1CBdb [IEEEP8021CBdb] defines a Mask-		DetNet flows using UDP or TCP. Clause 6.8 of IEEE P802.1CBdb
	and-Match Stream identification function that can be used as a		[IEEEP8021CBdb] defines a Mask-and-Match Stream identification
	passive function for any IP DetNet flows.		function that can be used as a passive function for any IP DetNet
			flows.
	IEEE 802.1CB [IEEE8021CB] defines an Active Destination MAC and VLAN		Clause 6.6 of IEEE 802.1CB [IEEE8021CB] defines an Active Destination
	Stream identification function, what can replace some Ethernet header		MAC and VLAN Stream identification function, what can replace some
	fields namely (1) the destination MAC-address, (2) the VLAN-ID and		Ethernet header fields namely (1) the destination MAC-address, (2)
	(3) priority parameters with alternate values. Replacement is		the VLAN-ID and (3) priority parameters with alternate values.
	provided for the frame passed down the stack from the upper layers or		Replacement is provided for the frame passed down the stack from the
	up the stack from the lower layers.		upper layers or up the stack from the lower layers.
	Active Destination MAC and VLAN Stream identification can be used		Active Destination MAC and VLAN Stream identification can be used
	within a Talker to set flow identity or a Listener to recover the		within a Talker to set flow identity or a Listener to recover the
	original addressing information. It can be used also in a TSN bridge		original addressing information. It can be used also in a TSN bridge
	that is providing translation as a proxy service for an End System.		that is providing translation as a proxy service for an End System.
	4.2. TSN requirements of IP DetNet nodes		4.2. TSN requirements of IP DetNet nodes
	This section covers required behavior of a TSN-aware DetNet node		This section covers required behavior of a TSN-aware DetNet node
	using a TSN sub-network.		using a TSN sub-network. The implementation of TSN packet processing
			functions MUST be compliant with the relevant IEEE 802.1 standards.
	From the TSN sub-network perspective DetNet IP nodes are treated as		From the TSN sub-network perspective DetNet IP nodes are treated as
	Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware.		Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware.
	In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within		In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within
	the TSN sub-network must modify the Ethernet encapsulation of the		the TSN sub-network must modify the Ethernet encapsulation of the
	DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence		DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence
	number addition, etc.) to allow proper TSN specific handling inside		number addition, etc.) to allow proper TSN specific handling inside
	the sub-network. There are no requirements defined for TSN-unaware		the sub-network. There are no requirements defined for TSN-unaware
	IP DetNet nodes in this document.		IP DetNet nodes in this document.
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 45 ¶
	A Stream identification component MUST be able to instantiate the		A Stream identification component MUST be able to instantiate the
	following functions (1) Active Destination MAC and VLAN Stream		following functions (1) Active Destination MAC and VLAN Stream
	identification function, (2) IP Stream identification function, (3)		identification function, (2) IP Stream identification function, (3)
	Mask-and-Match Stream identification function and (4) the related		Mask-and-Match Stream identification function and (4) the related
	managed objects in Clause 9 of IEEE 802.1CB [IEEE8021CB] and IEEE		managed objects in Clause 9 of IEEE 802.1CB [IEEE8021CB] and IEEE
	P802.1CBdb [IEEEP8021CBdb].		P802.1CBdb [IEEEP8021CBdb].
	A TSN-aware IP (DetNet) node implementations MUST support the		A TSN-aware IP (DetNet) node implementations MUST support the
	Sequencing function and the Sequence encode/decode function as		Sequencing function and the Sequence encode/decode function as
	defined in IEEE 802.1CB [IEEE8021CB] if FRER is used inside the TSN		defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is
	sub-network.		used inside the TSN sub-network.
	The Sequence encode/decode function MUST support the Redundancy tag		The Sequence encode/decode function MUST support the Redundancy tag
	(R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB].		(R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB].
	A TSN-aware IP (DetNet) node implementations MUST support the Stream		A TSN-aware IP (DetNet) node implementations MUST support the Stream
	splitting function and the Individual recovery function as defined in		splitting function and the Individual recovery function as defined in
	IEEE 802.1CB [IEEE8021CB] when the node is a replication or		Clause 7.7 and 7.5 of IEEE 802.1CB [IEEE8021CB] when the node is a
	elimination point for FRER.		replication or elimination point for FRER.
	4.3. Service protection within the TSN sub-network		4.3. Service protection within the TSN sub-network
	TSN Streams supporting DetNet flows may use Frame Replication and		TSN Streams supporting DetNet flows may use Frame Replication and
	Elimination for Redundancy (FRER) as defined in IEEE 802.1CB		Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE
	[IEEE8021CB] based on the loss service requirements of the TSN		802.1CB [IEEE8021CB] based on the loss service requirements of the
	Stream, which is derived from the DetNet service requirements of the		TSN Stream, which is derived from the DetNet service requirements of
	DetNet mapped flow. The specific operation of FRER is not modified		the DetNet mapped flow. The specific operation of FRER is not
	by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB].		modified by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB].
	FRER function and the provided service recovery is available only		FRER function and the provided service recovery is available only
	within the TSN sub-network as the TSN Stream-ID and the TSN sequence		within the TSN sub-network as the TSN Stream-ID and the TSN sequence
	number are not valid outside the sub-network. An IP (DetNet) node		number are not valid outside the sub-network. An IP (DetNet) node
	represents a L3 border and as such it terminates all related		represents a L3 border and as such it terminates all related
	information elements encoded in the L2 frames.		information elements encoded in the L2 frames.
	4.4. Aggregation during DetNet flow to TSN Stream mapping		4.4. Aggregation during DetNet flow to TSN Stream mapping
	Implementations of this document SHALL use management and control		Implementations of this document SHALL use management and control
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 38 ¶
	ensure that adequate resources are allocated and configured to		ensure that adequate resources are allocated and configured to
	provide proper service requirements of the mapped flows.		provide proper service requirements of the mapped flows.
	5. Management and Control Implications		5. Management and Control Implications
	DetNet flow and TSN Stream mapping related information are required		DetNet flow and TSN Stream mapping related information are required
	only for TSN-aware IP (DetNet) nodes. From the Data Plane		only for TSN-aware IP (DetNet) nodes. From the Data Plane
	perspective there is no practical difference based on the origin of		perspective there is no practical difference based on the origin of
	flow mapping related information (management plane or control plane).		flow mapping related information (management plane or control plane).
			The following summarizes the set of information that is needed to
			configure DetNet IP over TSN:
			o DetNet IP related configuration information according to the
			DetNet role of the DetNet IP node, as per [I-D.ietf-detnet-ip].
			o TSN related configuration information according to the TSN role of
			the DetNet IP node, as per [IEEE8021Q], [IEEE8021CB] and
			[IEEEP8021CBdb].
			o Mapping between DetNet IP flow(s) (as flow identification defined
			in [I-D.ietf-detnet-ip], it is summarized in Section 5.1 of that
			document, and includes all wildcards, port ranges and the ability
			to ignore specific IP fields) and TSN Stream(s) (as stream
			identification information defined in [IEEE8021CB] and
			[IEEEP8021CBdb]). Note, that managed objects for TSN Stream
			identification can be found in [IEEEP8021CBcv].
			This information MUST be provisioned per DetNet flow.
	TSN-aware IP DetNet nodes are member of both the DetNet domain and		TSN-aware IP DetNet nodes are member of both the DetNet domain and
	the TSN sub-network. Within the TSN sub-network the TSN-aware IP		the TSN sub-network. Within the TSN sub-network the TSN-aware IP
	(DetNet) node has a TSN-aware Talker/Listener role, so TSN specific		(DetNet) node has a TSN-aware Talker/Listener role, so TSN specific
	management and control plane functionalities must be implemented.		management and control plane functionalities must be implemented.
	There are many similarities in the management plane techniques used		There are many similarities in the management plane techniques used
	in DetNet and TSN, but that is not the case for the control plane		in DetNet and TSN, but that is not the case for the control plane
	protocols. For example, RSVP-TE and MSRP behaves differently.		protocols. For example, RSVP-TE and MSRP behaves differently.
	Therefore management and control plane design is an important aspect		Therefore management and control plane design is an important aspect
	of scenarios, where mapping between DetNet and TSN is required.		of scenarios, where mapping between DetNet and TSN is required.
	In order to use a TSN sub-network between DetNet nodes, DetNet		In order to use a TSN sub-network between DetNet nodes, DetNet
	specific information must be converted to TSN sub-network specific		specific information must be converted to TSN sub-network specific
	ones. DetNet flow ID and flow related parameters/requirements must		ones. DetNet flow ID and flow related parameters/requirements must
	be converted to a TSN Stream ID and stream related parameters/		be converted to a TSN Stream ID and stream related parameters/
	requirements. Note that, as the TSN sub-network is just a portion of		requirements. Note that, as the TSN sub-network is just a portion of
	the end2end DetNet path (i.e., single hop from IP perspective), some		the end-to-end DetNet path (i.e., single hop from IP perspective),
	parameters (e.g., delay) may differ significantly. Other parameters		some parameters (e.g., delay) may differ significantly. Other
	(like bandwidth) also may have to be tuned due to the L2		parameters (like bandwidth) also may have to be tuned due to the L2
	encapsulation used within the TSN sub-network.		encapsulation used within the TSN sub-network.
	In some case it may be challenging to determine some TSN Stream		In some case it may be challenging to determine some TSN Stream
	related information. For example, on a TSN-aware IP (DetNet) node		related information. For example, on a TSN-aware IP (DetNet) node
	that acts as a Talker, it is quite obvious which DetNet node is the		that acts as a Talker, it is quite obvious which DetNet node is the
	Listener of the mapped TSN stream (i.e., the IP Next-Hop). However		Listener of the mapped TSN stream (i.e., the IP Next-Hop). However
	it may be not trivial to locate the point/interface where that		it may be not trivial to locate the point/interface where that
	Listener is connected to the TSN sub-network. Such attributes may		Listener is connected to the TSN sub-network. Such attributes may
	require interaction between control and management plane functions		require interaction between control and management plane functions
	and between DetNet and TSN domains.		and between DetNet and TSN domains.
	skipping to change at page 9, line 36 ¶		skipping to change at page 10, line 11 ¶
	TSN-unaware IP (DetNet) nodes make such a triggering even more		TSN-unaware IP (DetNet) nodes make such a triggering even more
	complicated as they are fully unaware of the sub-network and run		complicated as they are fully unaware of the sub-network and run
	independently.		independently.
	Configuration of TSN specific functions (e.g., FRER) inside the TSN		Configuration of TSN specific functions (e.g., FRER) inside the TSN
	sub-network is a TSN domain specific decision and may not be visible		sub-network is a TSN domain specific decision and may not be visible
	in the DetNet domain.		in the DetNet domain.
	6. Security Considerations		6. Security Considerations
	The security considerations of DetNet in general are discussed in		Security considerations for DetNet are described in detail in
	[RFC8655] and [I-D.ietf-detnet-security]. DetNet IP data plane		[I-D.ietf-detnet-security]. General security considerations are
	specific considerations are summarized in [I-D.ietf-detnet-ip].		described in [RFC8655]. DetNet IP data plane specific considerations
	Encryption may provided by an underlying sub-net using MACSec		are summarized in [I-D.ietf-detnet-ip]. This section considers
	[IEEE802.1AE-2018] for DetNet IP over TSN flows.		exclusively security considerations which are specific to the DetNet
			IP over TSN sub-network scenario.
			The sub-network between DetNet nodes needs to be subject to
			appropriate confidentiality. Additionally, knowledge of what DetNet/
			TSN services are provided by a sub-network may supply information
			that can be used in a variety of security attacks. The ability to
			modify information exchanges between connected DetNet nodes may
			result in bogus operations. Therefore, it is important that the
			interface between DetNet nodes and TSN sub-network are subject to
			authorization, authentication, and encryption.
			The TSN sub-network operates at Layer-2 so various security
			mechanisms defined by IEEE can be used to secure the connection
			between the DetNet nodes (e.g., encryption may be provided using
			MACSec [IEEE802.1AE-2018]).
	7. IANA Considerations		7. IANA Considerations
	None.		None.
	8. Acknowledgements		8. Acknowledgements
	The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,		The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
	Christophe Mangin and Jouni Korhonen for their various contributions		Christophe Mangin and Jouni Korhonen for their various contributions
	to this work.		to this work.
	9. References		9. References
	9.1. Normative references		9.1. Normative references
	[I-D.ietf-detnet-ip]		[I-D.ietf-detnet-ip]
	Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,		Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
	and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-		Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06
	ip-05 (work in progress), February 2020.		(work in progress), April 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative references		9.2. Informative references
	[I-D.ietf-detnet-flow-information-model]		[I-D.ietf-detnet-flow-information-model]
	Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D.		Varga, B., Farkas, J., 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-07 (work in progress), March 2020.		flow-information-model-10 (work in progress), May 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-08 (work in progress), February 2020.		security-10 (work in progress), May 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>.
	[IEEE8021CB]		[IEEE8021CB]
	Finn, N., "Draft Standard for Local and metropolitan area		Finn, N., "Draft Standard for Local and metropolitan area
	networks - Seamless Redundancy", IEEE P802.1CB		networks - Seamless Redundancy", IEEE P802.1CB
	/D2.1 P802.1CB, December 2015,		/D2.1 P802.1CB, December 2015,
	<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-		<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-
	1CB-d2-1.pdf>.		1CB-d2-1.pdf>.
	[IEEE8021Q]		[IEEE8021Q]
	IEEE 802.1, "Standard for Local and metropolitan area		IEEE 802.1, "Standard for Local and metropolitan area
	networks--Bridges and Bridged Networks (IEEE Std 802.1Q-		networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
	2014)", 2014, <http://standards.ieee.org/about/get/>.		2014)", 2014, <http://standards.ieee.org/about/get/>.
			[IEEEP8021CBcv]
			Kehrer, S., "FRER YANG Data Model and Management
			Information Base Module", IEEE P802.1CBcv
			/D0.3 P802.1CBcv, May 2020,
			<http://www.ieee802.org/1/files/private/cv-drafts/d0/802-
			1CBcv-d0-3.pdf>.
	[IEEEP8021CBdb]		[IEEEP8021CBdb]
	Mangin, C., "Extended Stream identification functions",		Mangin, C., "Extended Stream identification functions",
	IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019,		IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019,
	<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-		<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-
	1CB-d2-1.pdf>.		1CB-d2-1.pdf>.
	[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>.
	skipping to change at page 11, line 35 ¶		skipping to change at page 12, line 35 ¶
	Janos Farkas		Janos Farkas
	Ericsson		Ericsson
	Magyar Tudosok krt. 11.		Magyar Tudosok krt. 11.
	Budapest 1117		Budapest 1117
	Hungary		Hungary
	Email: janos.farkas@ericsson.com		Email: janos.farkas@ericsson.com
	Andrew G. Malis		Andrew G. Malis
	Independent		Malis Consulting
	Email: agmalis@gmail.com		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. 28 change blocks.
	65 lines changed or deleted		108 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/