draft-ietf-detnet-tsn-vpn-over-mpls-00.txt		draft-ietf-detnet-tsn-vpn-over-mpls-01.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: November 6, 2019 A. Malis		Expires: April 29, 2020 A. Malis
			Independent
	S. Bryant		S. Bryant
	Huawei Technologies		Futurewei Technologies
	J. Korhonen		D. Fedyk
	May 5, 2019		LabN Consulting, L.L.C.
			October 27, 2019
	DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS		DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
	draft-ietf-detnet-tsn-vpn-over-mpls-00		draft-ietf-detnet-tsn-vpn-over-mpls-01
	Abstract		Abstract
	This document specifies the Deterministic Networking data plane when		This document specifies the Deterministic Networking data plane when
	TSN networks interconnected over an MPLS Packet Switched Networks.		TSN networks are interconnected over a DetNet MPLS 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.
	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 November 6, 2019.		This Internet-Draft will expire on April 29, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Terms Used in This Document . . . . . . . . . . . . . . . 2		2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
	3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
	4. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4		3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4
	5. DetNet MPLS Data Plane Considerations . . . . . . . . . . . . 6		4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6
	5.1. End-System Specific Considerations . . . . . . . . . . . 7		4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8		4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7
	6.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8		5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8
	6.2. TSN over MPLS Data Plane Encapsulation . . . . . . . . . 9		5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8
	6.2.1. Edge Node Processing . . . . . . . . . . . . . . . . 9		5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 9
	6.2.2. Layer 2 Addressing and QoS Considerations . . . . . . 10		5.3. Edge Node DetNet Service and Forwarding Sub-Layer
	7. Controller Plane (Management and Control)		Procedures . . . . . . . . . . . . . . . . . . . . . . . 9
	Considerations . . . . . . . . . . . . . . . . . . . . . . . 11		6. Controller Plane (Management and Control) Considerations . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. Example of TSN over DetNet Data Plane Operation . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	[Editor's note: Introduction to be made specific to TSN over DetNet		The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1
	scenario. Do we intend to cover both TSN over DetNet IP and TSN over		Working Group deals with deterministic services through IEEE 802
	DetNet MPLS? Or this document is limited to MPLS scenarios?].		networks. Deterministic Networking (DetNet) defined by IETF is a
			service that can be offered by a L3 network to DetNet flows. General
			background and concepts of DetNet can be found in
			[I-D.ietf-detnet-architecture].
	2. Terminology		This document specifies the use of a DetNet MPLS network to
			interconnect TSN nodes/network segments. DetNet MPLS data plane is
			defined in [I-D.ietf-detnet-mpls].
	[Editor's note: text to be review what is really needed here.].		2. Terminology
	2.1. Terms Used in This Document		2.1. Terms Used in This Document
	This document uses the terminology established in the DetNet		This document uses the terminology and concepts established in the
	architecture [I-D.ietf-detnet-architecture], and the reader is		DetNet architecture [I-D.ietf-detnet-architecture] and
	assumed to be familiar with that document and its terminology.		[I-D.ietf-detnet-data-plane-framework], and [I-D.ietf-detnet-mpls].
			The reader is assumed to be familiar with these documents and their
	The following terminology is introduced in this document:		terminology.
	F-Label A Detnet "forwarding" label that identifies the LSP
	used to forward a DetNet flow across an MPLS PSN, e.g.,
	a hop-by-hop label used between label switching routers
	(LSR).
	S-Label A DetNet "service" label that is used between DetNet
	nodes that implement also the DetNet service sub-layer
	functions. An S-Label is also used to identify a
	DetNet flow at DetNet service sub-layer.
	d-CW A DetNet Control Word (d-CW) is used for sequencing and
	identifying duplicate packets of a DetNet flow at the
	DetNet service sub-layer.
	2.2. Abbreviations		2.2. Abbreviations
	[Editor's note: text to be cleaned up].
	The following abbreviations are used in this document:		The following abbreviations are used in this document:
	AC Attachment Circuit.		AC Attachment Circuit.
	CE Customer Edge equipment.		CE Customer Edge equipment.
	CoS Class of Service.		CoS Class of Service.
	CW Control Word.		CW Control Word.
	DetNet Deterministic Networking.		DetNet Deterministic Networking.
	DF DetNet Flow.		DF DetNet Flow.
	DN-IWF DetNet Inter-Working Function.		FRER Frame Replication and Elimination for Redundancy (TSN
			function).
	L2 Layer 2.		L2 Layer 2.
	L2VPN Layer 2 Virtual Private Network.		L2VPN Layer 2 Virtual Private Network.
	L3 Layer 3.		L3 Layer 3.
	LSR Label Switching Router.		LSR Label Switching Router.
	MPLS Multiprotocol Label Switching.		MPLS Multiprotocol Label Switching.
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 27 ¶
	PW PseudoWire.		PW PseudoWire.
	QoS Quality of Service.		QoS Quality of Service.
	S-PE Switching Provider Edge.		S-PE Switching Provider Edge.
	T-PE Terminating Provider Edge.		T-PE Terminating Provider Edge.
	TSN Time-Sensitive Network.		TSN Time-Sensitive Network.
	3. Requirements Language		2.3. Requirements Language
	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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	4. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario		3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario
	[Author's note: review required on his part.]		Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware
	TSN Edge Transit Edge TSN		DetNet service running over an MPLS network. DetNet Edge Nodes sit
	End System Node Node Node End System		at the boundary of a DetNet domain. They are responsible for mapping
			non-DetNet aware L2 traffic to DetNet services. They also support
			the imposition and disposition of the required DetNet encapsulation.
			These are functionally similar to pseudowire (PW) Terminating
			Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example
			TSN Streams are simple applicaions over DetNet flows. The specific
			of this operation are discussed later in this document.
			TSN Edge Transit Edge TSN
			End System Node Node Node End System
	(T-PE) (LSR) (T-PE)		(T-PE) (LSR) (T-PE)
			+----------+ +----------+
			| TSN | <---------End to End TSN Service----------> | TSN |
			| Applic. | | Applic. |
	+----------+ +.........+ +.........+ +----------+		+----------+ +.........+ +.........+ +----------+
	| Appl. |<-:Svc Proxy:--End to End Svc.--:Svc Proxy:->| Appl. |		| | | \S-Proxy: :S-Proxy/ | | |
	+----------+ +---------+ +---------+ +----------+		| TSN | | +.+---+<-- DetNet flow -->+---+ | | | TSN |
	| TSN | |TSN| |Svc|<-- DetNet flow -->|Svc| |TSN| | TSN |		| | |TSN| |Svc| |Svc| |TSN| | |
	+----------+ +---+ +---+ +----------+ +---+ +---+ +----------+		+----------+ +---+ +---+ +----------+ +---+ +---+ +----------+
	|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|		| L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 |
	+------.---+ +--.+ +-.-+ +---.----.-+ +--.+ +-.-+ +----.-----+		+------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+
	: Link : / ,-----. \ : Link : / ,-----. \		: Link : / ,-----. \ : Link : / ,-----. \
	+.........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+		+........+ +-[ Sub ]-+ +........+ +-[ TSN ]-+
	[Network] [Network]		[Network] [Network]
	`-----' `-----'		`-----' `-----'
	|<- TSN ->| |<------ DetNet MPLS ------>| |<-- TSN --->|		|<------ DetNet MPLS ------>|
			|<---------------------- TSN --------------------->|
	Figure 1: A TSN over DetNet MPLS Enabled Network		Figure 1: A TSN over DetNet MPLS Enabled Network
	Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware		In this example, edge nodes provide a service proxy function that
	DetNet service running over an MPLS network. DetNet Edge Nodes sit		"associates" the DetNet flows and native flows (i.e., TSN Streams) at
	at the boundary of a DetNet domain. They are responsible for mapping		the edge of the DetNet domain. TSN streams are treated as App-flows
	non-DetNet aware L2 traffic to DetNet services. They also support		for DetNet. The whole DetNet domain behaves as a TSN relay node for
	the imposition and disposition of the required DetNet encapsulation.		the TSN streams. The service proxy behaves as a port of that TSN
	These are functionally similar to pseudowire (PW) Terminating		relay node.
	Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example
	they understand and support IEEE 802.1 TSN and are able to map TSN
	flows into DetNet flows. The specific of this operation are
	discussed later in this document.
	Native TSN flow and DetNet MPLS flow differ not only by the
	additional MPLS specific encapsulation, but DetNet MPLS flows have on
	each DetNet node an associated DetNet specific data structure, what
	defines flow related characteristics and required forwarding
	functions. In this example, edge Nodes provide a service proxy
	function that "associates" the DetNet flows and native flows at the
	edge of the DetNet domain. This ensures that the DN Flow is properly
	served at the Edge node (and inside the domain).
	Figure 2 illustrates how DetNet can provide services for IEEE		Figure 2 illustrates how DetNet can provide services for IEEE 802.1
	802.1TSN end systems, CE1 and CE2, over a DetNet enabled MPLS		TSN end systems, CE1 and CE2, over a DetNet enabled MPLS network.
	network. Edge nodes, E1 and E2, insert and remove required DetNet		Edge nodes, E1 and E2, insert and remove required DetNet data plane
	data plane encapsulation. The 'X' in the edge nodes and relay node,		encapsulation. The 'X' in the edge nodes and relay node, R1,
	R1, represent a potential DetNet compound flow packet replication and		represent a potential DetNet compound flow packet replication and
	elimination point. This conceptually parallels L2VPN services, and		elimination point. This conceptually parallels L2VPN services, and
	could leverage existing related solutions as discussed below.		could leverage existing related solutions as discussed below.
	TSN |<------- End to End DetNet Service ------>| TSN		TSN |<------- End to End DetNet Service ------>| TSN
	Service | Transit Transit | Service		Service | Transit Transit | Service
	TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN		TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN
	End | V V 1 V V 2 V V | End		End | V V 1 V V 2 V V | End
	System | +--------+ +--------+ +--------+ | System		System | +--------+ +--------+ +--------+ | System
	+---+ | | E1 |=======| R1 |=======| E2 | | +---+		+---+ | | E1 |=======| R1 |=======| E2 | | +---+
	| |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| |		| |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| |
	|CE1| | | \ | | X | | / | | |CE2|		|CE1| | | \ | | X | | / | | |CE2|
	| | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | |		| | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | |
	+---+ | |=======| |=======| | +---+		+---+ | |=======| |=======| | +---+
	^ +--------+ +--------+ +--------+ ^		^ +--------+ +--------+ +--------+ ^
	| Edge Node Relay Node Edge Node |		| Edge Node Relay Node Edge Node |
	| (T-PE) (S-PE) (T-PE) |		| (T-PE) (S-PE) (T-PE) |
	| |		| |
	|<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->|		|<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->|
	| |		| |
	|<--- Emulated Time Sensitive Networking (TSN) Service --->|		|<-------- Time Sensitive Networking (TSN) Service ------->|
	X = Service protection		X = Service protection
	DFx = DetNet member flow x over a TE LSP		DFx = DetNet member flow x over a TE LSP
	Figure 2: IEEE 802.1TSN Over DetNet		Figure 2: IEEE 802.1TSN Over DetNet
	5. DetNet MPLS Data Plane Considerations		4. DetNet MPLS Data Plane
	[Editor's note: Needs clean up, what is relevant for TSN over DetNet
	scenarios.].
	This section provides informative considerations related to providing
	DetNet service to flows which are identified based on their header
	information. At a high level, the following are provided on a per
	flow basis:
	Eliminating contention loss and jitter reduction:
	Use of allocated resources (queuing, policing, shaping) to ensure
	that the congestion-related loss and latency/jitter requirements
	of a DetNet flow are met.
	Explicit routes:		4.1. Overview
	Use of a specific path for a flow. This limits misordering and		The basic approach defined in [I-D.ietf-detnet-mpls] supports the
	bounds latency.		DetNet service sub-layer based on existing pseudowire (PW)
			encapsulations and mechanisms, and supports the DetNet forwarding
			sub-layer based on existing MPLS Traffic Engineering encapsulations
			and mechanisms.
	Service protection:		A node operating on a DetNet flow in the Detnet service sub-layer,
			i.e. a node processing a DetNet packet which has the S-Label as top
			of stack uses the local context associated with that S-Label, for
			example a received F-Label, to determine what local DetNet
			operation(s) are applied to that packet. An S-Label may be unique
			when taken from the platform label space [RFC3031], which would
			enable correct DetNet flow identification regardless of which input
			interface or LSP the packet arrives on. The service sub-layer
			functions (i.e., PREOF) use a DetNet control word (d-CW).
	Which in the case of this document primarily relates to		The DetNet MPLS data plane builds on MPLS Traffic Engineering
	replication and elimination. Changing the explicit path after a		encapsulations and mechanisms to provide a forwarding sub-layer that
	failure is detected in order to restore delivery of the required		is responsible for providing resource allocation and explicit routes.
	DetNet service characteristics is also possible. Path changes,
	even in the case of failure recovery, can lead to the out of order
	delivery of data.
	Load sharing:		The forwarding sub-layer is supported by one or more forwarding
			labels (F-Labels).
	Generally, distributing packets of the same DetNet flow over		DetNet edge/relay nodes are DetNet service sub-layer aware,
	multiple paths is not recommended. Such load sharing, e.g., via		understand the particular needs of DetNet flows and provide both
	ECMP or UCMP, impacts ordering and possibly jitter.		DetNet service and forwarding sub-layer functions. They add, remove
			and process d-CWs, S-Labels and F-labels as needed. MPLS enabled
			DetNet nodes can enhance the reliability of delivery by enabling the
			replication of packets where multiple copies, possibly over multiple
			paths, are forwarded through the DetNet domain. They can also
			eliminate surplus previously replicated copies of DetNet packets.
			MPLS (DetNet) nodes also include DetNet forwarding sub-layer
			functions, support for notably explicit routes, and resources
			allocation to eliminate (or reduce) congestion loss and jitter.
	Troubleshooting:		DetNet transit nodes reside wholly within a DetNet domain, and also
			provide DetNet forwarding sub-layer functions in accordance with the
			performance required by a DetNet flow carried over an LSP. Unlike
			other DetNet node types, transit nodes provide no service sub-layer
			processing.
	For example, to support identification of misbehaving flows.		4.2. TSN over DetNet MPLS Encapsulation
	Recognize flow(s) for analytics:		The basic encapsulation approach is to treat a TSN Stream as an app-
			flow from the DetNet MPLS perspective. The corresponding example
			shown in Figure 3.
	For example, increase counters.		/-> +------+ +------+ +------+ TSN ^ ^
			| | X | | X | | X |<- Appli : :
			App-Flow <-+ +------+ +------+ +------+ cation : :(1)
			for MPLS | |TSN-L2| |TSN-L2| |TSN-L2| : v
			\-> +---+======+--+======+--+======+-----+ :
			| d-CW | | d-CW | | d-CW | :
			DetNet-MPLS +------+ +------+ +------+ :(2)
			|Labels| |Labels| |Labels| v
			+---+======+--+======+--+======+-----+
			Link/Sub-Network | L2 | | TSN | | UDP |
			+------+ +------+ +------+
			| IP |
			+------+
			| L2 |
			+------+
			(1) TSN Stream
			(2) DetNet MPLS Flow
	Correlate events with flows:		Figure 3: Example TSN over MPLS Encapsulation Formats
	For example, unexpected loss.		In the figure, "Application" indicates the application payload
			carried by the TSN network. "MPLS App-Flow" indicates that the TSN
			Stream is the payload from the perspective of the DetNet MPLS data
			plane defined in [I-D.ietf-detnet-mpls]. A single DetNet MPLS flow
			can aggregate multiple TSN Streams.
	The DetNet data plane also allows for the aggregation of DetNet		5. TSN over MPLS Data Plane Procedures
	flows, e.g., via MPLS hierarchical LSPs, to improved scaling. When
	DetNet flows are aggregated, transit nodes provide service to the
	aggregate and not on a per-DetNet flow basis. In this case, nodes
	performing aggregation will ensure that per-flow service requirements
	are achieved.
	5.1. End-System Specific Considerations		Description of Edge Nodes procedures and functions for TSN over
			DetNet MPLS scenario follows the concept of [RFC3985] and covers the
			Edge Nodes components shown on Figure 1. In this section the
			following procedures of DetNet Edge Nodes are described:
	Data-flows requiring DetNet service are generated and terminated on		o TSN related (Section 5.1)
	end-systems. Encapsulation depends on application and its
	preferences. In a DetNet MPLS domain the DN functions use the d-CWs,
	S-Labels and F-Labels to provide DetNet services. However, an
	application may exchange further flow related parameters (e.g., time-
	stamp), which are not provided by DN functions.
	Specifics related to non-MPLS DetNet end station behavior are out		o DetNet Service Proxy (Section 5.2)
	side the scope of this document. For example, details on support for
	DetNet IP data flows can be found in [I-D.ietf-detnet-dp-sol-ip].
	This document is also useful for end stations that map IP flows to
	DetNet flows.
	As a general rule, DetNet MPLS domains are capable of forwarding any		o DetNet service and forwarding sub-layer (Section 5.3)
	DetNet MPLS flows and the DetNet domain does not mandate the end-
	system or edge system encapsulation format. Unless there is a proxy
	of some form present, end-systems peer with similar end-systems using
	the same application encapsulation format. For example, as shown in
	Figure 3, IP applications peer with IP applications and Ethernet
	L2VPN applications peer with Ethernet L2VPN applications.
	+-----+		5.1. Edge Node TSN Procedures
	| X | +-----+
	+-----+ | X |
	| Eth | ________ +-----+
	+-----+ _____ / \ | Eth |
	\ / \__/ \___ +-----+
	\ / \ /
	0======== tunnel-1 ========0_
	| \
	\ |
	0========= tunnel-2 =========0
	/ \ __/ \
	+-----+ \__ DetNet MPLS domain / \
	| X | \ __ / +-----+
	+-----+ \_______/ \_____/ | X |
	| IP | +-----+
	+-----+ | IP |
	+-----+
	Figure 3: End-Systems and The DetNet MPLS Domain		The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
			Working Group have defined (and are defining) a number of amendments
			to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and
			bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]
			defines packet replication and elimination functions for a TSN
			network.
	6. MPLS-Based DetNet Data Plane Solution		TSN specific functions are executed on the data received by the PE
			from the CE before presentation to the DetNet PW for transmission
			across the DetNet domain, or on the data received from a DetNet PW by
			a PE before it is output on the Attachment Circuit (AC).
	[Editor's note: Needs clean up. Text should focus on Edge node		TSN specific function(s) of Edge Nodes (T-PE) are belonging to the
	related topics.].		native service processing (NSP) [RFC3985] block. This is similar to
			other functionalities being defined by standard bodies other than the
			IETF (for example in case of Ethernet: stripping, overwriting or
			adding VLAN tags, etc.). Depending on the TSN role of the Edge Node
			in the end-to-end TSN service selected TSN functions must be
			supported.
	6.1. DetNet Over MPLS Encapsulation Components		Implementations of this document SHALL use management and control
			information to ensure TSN specific functions of the Edge Node
			according to the expectations of the connected TSN network.
	To carry DetNet over MPLS the following is required:		5.2. Edge Node DetNet Service Proxy Procedures
	1. A method of identifying the MPLS payload type.		The Service Proxy function maps between App-flows and DetNet flows.
			The DetNet Edge Node TSN function MUST support the TSN Stream
			identification functions and the related managed objects as defined
			in IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb] to
			recognize the App-flow related packets. The Service Proxy presents
			TSN Streams as an App-flow to a DetNet Flow.
	2. A method of identifying the DetNet flow group to the processing		Implementations of this document SHALL use management and control
	element.		information to map a TSN Stream to a DetNet flow. N:1 mapping
			(aggregating multiple TSN Streams in a single DetNet flow) SHALL be
			supported. The management or control function that provisions flow
			mapping SHALL ensure that adequate resources are allocated and
			configured to provide proper service requirements of the mapped
			flows.
	3. A method of distinguishing DetNet OAM packets from DetNet data		Due to the (intentional) similarities of the DetNet PREOF and TSN
	packets.		FRER functions service protection function interworking is possible
			between the TSN and the DetNet domains. Such service protection
			interworking scenarios MAY require to copy sequence number fields
			from TSN (L2) to PW (MPLS) encapsulation. However, such interworking
			is out-of-scope in this document and left for further study.
	4. A method of carrying the DetNet sequence number.		A MPLS DetNet flow is configured to carry any number of TSN flows.
			The DetNet flow specific bandwidth profile SHOULD match the required
			bandwidth of the App-flow aggregate.
	5. A suitable LSP to deliver the packet to the egress PE.		5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures
	6. A method of carrying queuing and forwarding indication.		In the design of [I-D.ietf-detnet-mpls] an MPLS service label (the
			S-Label), similar to a pseudowire (PW) label [RFC3985], is used to
			identify both the DetNet flow identity and the payload MPLS payload
			type. The DetNet sequence number is carried in the DetNet Control
			word (d-CW) which carries the Data/OAM discriminator as well. In
			[I-D.ietf-detnet-mpls] two sequence number sizes are supported: a 16
			bit sequence number and a 28 bit sequence number.
	In this design an MPLS service label (the S-Label), similar to a		PREOF functions and the provided service recovery is available only
	pseudowire (PW) label [RFC3985], is used to identify both the DetNet		within the DetNet domain as the DetNet flow-ID and the DetNet
	flow identity and the payload MPLS payload type satisfying (1) and		sequence number are not valid outside the DetNet network. MPLS
	(2) in the list above. OAM traffic discrimination happens through		(DetNet) Edge node terminates all related information elements
	the use of the Associated Channel method described in [RFC4385]. The		encoded in the MPLS labels.
	DetNet sequence number is carried in the DetNet Control word which
	carries the Data/OAM discriminator. To simplify implementation and
	to maximize interoperability two sequence number sizes are supported:
	a 16 bit sequence number and a 28 bit sequence number. The 16 bit
	sequence number is needed to support some types of legacy clients.
	The 28 bit sequence number is used in situations where it is
	necessary ensure that in high speed networks the sequence number
	space does not wrap whilst packets are in flight.
	The LSP used to forward the DetNet packet may be of any type (MPLS-		The LSP used to forward the DetNet packet may be of any type (MPLS-
	LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR		LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR
	[I-D.ietf-spring-segment-routing-mpls]). The LSP (F-Label) label		[I-D.ietf-spring-segment-routing-mpls]). The LSP (F-Label) label
	and/or the S-Label may be used to indicate the queue processing as		and/or the S-Label may be used to indicate the queue processing as
	well as the forwarding parameters. Note that the possible use of		well as the forwarding parameters.
	Penultimate Hop Popping (PHP) means that the only label in a received
	label stack may be the S-Label.
	6.2. TSN over MPLS Data Plane Encapsulation
	6.2.1. Edge Node Processing
	An edge node is resposable for matching ingress packets to the
	service they require and encapsulating them accordingly.An edge node
	may participate in the packet replication and duplication
	elimination.
	The DetNet-aware forwarder selects the egress DetNet member flow
	segment based on the flow identification. The mapping of ingress
	DetNet member flow segment to egress DetNet member flow segment may
	be statically or dynamically configured. Additionally the DetNet-
	aware forwarder does duplicate frame elimination based on the flow
	identification and the sequence number combination. The packet
	replication is also done within the DetNet-aware forwarder. During
	elimination and the replication process the sequence number of the
	DetNet member flow MUST be preserved and copied to the egress DetNet
	member flow.
	The internal design of a relay node is out of scope of this document.
	However the reader's attention is drawn to the need to make any PREOF
	state available to the packet processor(s) dealing with packets to
	which the PREOF functions must be applied, and to maintain that state
	is such as way that it is available to the packet processor operation
	on the next packet in the DetNet flow (which may be a duplicate, a
	late packet, or the next packet in sequence.
	[Editor's note: I think the rest of this section belongs in a new
	"802.1 TSN (island Interconnect) over DetNet MPLS" section.]
	This may be done in the DetNet layer, or where the native service
	processing (NSP) [RFC3985] is IEEE 802.1CB [IEEE8021CB] capable, the
	packet replication and duplicate elimination MAY entirely be done in
	the NSP, bypassing the DetNet flow encapsulation and logic entirely.
	This enables operating over unmodified implementations and
	deployments. The NSP approach works only between edge nodes and
	cannot make use of relay nodes.
	The NSP approach is useful end to end tunnel and for for "island		For further details see [I-D.ietf-detnet-mpls].
	interconnect" scenarios. However, when there is a need to do PREOF
	in a middle of the network, such plain edge to edge operation is not
	sufficient.
	The extended forwarder MAY copy the sequencing information from the		6. Controller Plane (Management and Control) Considerations
	native DetNet packet into the DetNet sequence number field and vice
	versa. If there is no existing sequencing information available in
	the native packet or the forwarder chose not to copy it from the
	native packet, then the extended forwarder MUST maintain a sequence
	number counter for each DetNet flow (indexed by the DetNet flow
	identification).
	6.2.2. Layer 2 Addressing and QoS Considerations		TSN Stream(s) to DetNet flow mapping related information are required
			only for the service proxy function of MPLS (DetNet) Edge nodes.
			From the Data Plane perspective there is no practical difference
			based on the origin of flow mapping related information (management
			plane or control plane).
	[Editor's NOTE: review and simplify this section if possible.]		MPLS DetNet Edge nodes are member of both the DetNet domain and the
			connected TSN network. From the TSN network perspective the MPLS
			(DetNet) Edge node has a "TSN relay node" role, so TSN specific
			management and control plane functionalities must be implemented.
			There are many similarities in the management plane techniques used
			in DetNet and TSN, but that is not the case for the control plane
			protocols. For example, RSVP-TE and MSRP behaves differently.
			Therefore management and control plane design is an important aspect
			of scenarios, where mapping between DetNet and TSN is required.
	The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1		Note that, as the DetNet network is just a portion of the end to end
	Working Group have defined (and are defining) a number of amendments		TSN path (i.e., single hop from Ethernet perspective), some
	to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and		parameters (e.g., delay) may differ significantly. Since there is no
	bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]		interworking function the bandwidth of DetNet network is assumed to
	defines packet replication and elimination functions that should		be set large enough to handle all TSN Flows it will support. At the
	prove both compatible with and useful to, DetNet networks.		egress of the Detnet Domain the MPLS headers are stripped and the TSN
			flow continues on as a normal TSN flow.
	As is the case for DetNet, a Layer 2 network node such as a bridge		In order to use a DetNet network to interconnect TSN segments, TSN
	may need to identify the specific DetNet flow to which a packet		specific information must be converted to DetNet domain specific
	belongs in order to provide the TSN/DetNet QoS for that packet. It		ones. TSN Stream ID(s) and stream(s) related parameters/requirements
	also will likely need a CoS marking, such as the priority field of an		must be converted to a DetNet flow-ID and flow related parameters/
	IEEE Std 802.1Q VLAN tag, to give the packet proper service.		requirements.
	Although the flow identification methods described in IEEE 802.1CB		In some case it may be challenging to determine some egress node
	[IEEE8021CB] are flexible, and in fact, include IP 5-tuple		related information. For example, it may be not trivial to locate
	identification methods, the baseline TSN standards assume that every		the egress point/interface of a TSN Streams with a multicast
	Ethernet frame belonging to a TSN stream (i.e. DetNet flow) carries		destination MAC address. Such scenarios may require interaction
	a multicast destination MAC address that is unique to that flow		between control and management plane functions and between DetNet and
	within the bridged network over which it is carried. Furthermore,		TSN domains.
	IEEE 802.1CB [IEEE8021CB] describes three methods by which a packet
	sequence number can be encoded in an Ethernet frame.
	Ensuring that the proper Ethernet VLAN tag priority and destination		Mapping between DetNet flow identifiers and TSN Stream identifiers,
	MAC address are used on a DetNet/TSN packet may require further		if not provided explicitly, can be done by the service proxy function
	clarification of the customary L2/L3 transformations carried out by		of an MPLS (DetNet) Edge node locally based on information provided
	routers and edge label switches. Edge nodes may also have to move		for configuration of the TSN Stream identification functions (e.g.,
	sequence number fields among Layer 2, PW, and IP encapsulations.		Mask-and-Match Stream identification).
	7. Controller Plane (Management and Control) Considerations		Triggering the setup/modification of a DetNet flow in the DetNet
			network is an example where management and/or control plane
			interactions are required between the DetNet and the TSN network.
	[Editor's note: requires considerations related to TSN over DetNet.].		Configuration of TSN specific functions (e.g., FRER) inside the TSN
			network is a TSN domain specific decision and may not be visible in
			the DetNet domain. Service protection interworking scenarios are
			left for further study.
	8. Security Considerations		7. Security Considerations
	The security considerations of DetNet in general are discussed in		Security considerations for DetNet are described in detail in
	[I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other		[I-D.ietf-detnet-security]. General security considerations are
	security considerations will be added in a future version of this		described in [I-D.ietf-detnet-architecture]. DetNet MPLS data plane
	draft.		specific considerations are summarized in [I-D.ietf-detnet-mpls].
			The primary considerations for the data plane is to maintain
			integrity of data and delivery of the associated DetNet service
			traversing the DetNet network. Application flows can be protected
			through whatever means is provided by the underlying technology. For
			example, encryption may be used, such as that provided by IPSec
			[RFC4301] for IP flows and/or by an underlying sub-net using MACSec
			[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
	9. IANA Considerations		8. IANA Considerations
	This document makes no IANA requests.		This document makes no IANA requests.
	10. Acknowledgements		9. Acknowledgements
	Thanks for Norman Finn and Lou Berger for their comments and		The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
	contributions.		Christophe Mangin and Jouni Korhonen for their various contributions
			to this work.
	11. References		10. References
	11.1. Normative References		10.1. Normative References
	[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>.
	[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
	Network Element Service", RFC 2211, DOI 10.17487/RFC2211,
	September 1997, <https://www.rfc-editor.org/info/rfc2211>.
	[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
	of Guaranteed Quality of Service", RFC 2212,
	DOI 10.17487/RFC2212, September 1997,
	<https://www.rfc-editor.org/info/rfc2212>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
	Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
	Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
	<https://www.rfc-editor.org/info/rfc3032>.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
	<https://www.rfc-editor.org/info/rfc3209>.
	[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
	P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
	Protocol Label Switching (MPLS) Support of Differentiated
	Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
	<https://www.rfc-editor.org/info/rfc3270>.
	[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
	in Multi-Protocol Label Switching (MPLS) Networks",
	RFC 3443, DOI 10.17487/RFC3443, January 2003,
	<https://www.rfc-editor.org/info/rfc3443>.
	[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation Protocol-
	Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
	DOI 10.17487/RFC3473, January 2003,
	<https://www.rfc-editor.org/info/rfc3473>.
	[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
	Hierarchy with Generalized Multi-Protocol Label Switching
	(GMPLS) Traffic Engineering (TE)", RFC 4206,
	DOI 10.17487/RFC4206, October 2005,
	<https://www.rfc-editor.org/info/rfc4206>.
	[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
	Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
	February 2006, <https://www.rfc-editor.org/info/rfc4385>.
	[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
	Circuit Connectivity Verification (VCCV): A Control
	Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
	December 2007, <https://www.rfc-editor.org/info/rfc5085>.
	[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
	Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
	2008, <https://www.rfc-editor.org/info/rfc5129>.
	[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
	(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
	Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
	2009, <https://www.rfc-editor.org/info/rfc5462>.
	[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
	"Encapsulating MPLS in UDP", RFC 7510,
	DOI 10.17487/RFC7510, April 2015,
	<https://www.rfc-editor.org/info/rfc7510>.
	[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>.
	11.2. Informative References		10.2. Informative References
	[G.8275.1]
	International Telecommunication Union, "Precision time
	protocol telecom profile for phase/time synchronization
	with full timing support from the network", ITU-T
	G.8275.1/Y.1369.1 G.8275.1, June 2016,
	<https://www.itu.int/rec/T-REC-G.8275.1/en>.
	[G.8275.2]
	International Telecommunication Union, "Precision time
	protocol telecom profile for phase/time synchronization
	with partial timing support from the network", ITU-T
	G.8275.2/Y.1369.2 G.8275.2, June 2016,
	<https://www.itu.int/rec/T-REC-G.8275.2/en>.
	[I-D.ietf-detnet-architecture]		[I-D.ietf-detnet-architecture]
	Finn, N., Thubert, P., Varga, B., and J. Farkas,		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", draft-ietf-		"Deterministic Networking Architecture", draft-ietf-
	detnet-architecture-12 (work in progress), March 2019.		detnet-architecture-13 (work in progress), May 2019.
	[I-D.ietf-detnet-dp-sol-ip]		[I-D.ietf-detnet-data-plane-framework]
	Korhonen, J., Varga, B., "DetNet IP Data Plane		Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
	Encapsulation", 2018.		Bryant, S., and J. Korhonen, "DetNet Data Plane
			Framework", draft-ietf-detnet-data-plane-framework-02
			(work in progress), September 2019.
	[I-D.ietf-detnet-flow-information-model]		[I-D.ietf-detnet-mpls]
	Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet		Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
	Flow Information Model", draft-ietf-detnet-flow-		Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
	information-model-03 (work in progress), March 2019.		draft-ietf-detnet-mpls-01 (work in progress), July 2019.
	[I-D.ietf-pce-pcep-extension-for-pce-controller]		[I-D.ietf-detnet-security]
	Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures		Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
	and Protocol Extensions for Using PCE as a Central		J., Austad, H., Stanton, K., and N. Finn, "Deterministic
	Controller (PCECC) of LSPs", draft-ietf-pce-pcep-		Networking (DetNet) Security Considerations", draft-ietf-
	extension-for-pce-controller-01 (work in progress),		detnet-security-05 (work in progress), August 2019.
	February 2019.
	[I-D.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,		Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS		Litkowski, S., and R. Shakir, "Segment Routing with MPLS
	data plane", draft-ietf-spring-segment-routing-mpls-22		data plane", draft-ietf-spring-segment-routing-mpls-22
	(work in progress), May 2019.		(work in progress), May 2019.
	[I-D.sdt-detnet-security]		[IEEE802.1AE-2018]
	Mizrahi, T., Grossman, E., Hacker, A., Das, S.,		IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
	"Deterministic Networking (DetNet) Security		Security (MACsec)", 2018,
	Considerations, draft-sdt-detnet-security, work in		<https://ieeexplore.ieee.org/document/8585421>.
	progress", 2017.
	[IEEE1588]
	IEEE, "IEEE 1588 Standard for a Precision Clock
	Synchronization Protocol for Networked Measurement and
	Control Systems Version 2", 2008.
	[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/		<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-
	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/>.
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.		[IEEEP8021CBdb]
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Mangin, C., "Extended Stream identification functions",
	Functional Specification", RFC 2205, DOI 10.17487/RFC2205,		IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019,
	September 1997, <https://www.rfc-editor.org/info/rfc2205>.		<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-
			1CB-d2-1.pdf>.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,
	DOI 10.17487/RFC2474, December 1998,
	<https://www.rfc-editor.org/info/rfc2474>.
	[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
	Xiao, "Overview and Principles of Internet Traffic
	Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
	<https://www.rfc-editor.org/info/rfc3272>.
	[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation		[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
	Edge-to-Edge (PWE3) Architecture", RFC 3985,		Edge-to-Edge (PWE3) Architecture", RFC 3985,
	DOI 10.17487/RFC3985, March 2005,		DOI 10.17487/RFC3985, March 2005,
	<https://www.rfc-editor.org/info/rfc3985>.		<https://www.rfc-editor.org/info/rfc3985>.
	[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	"Encapsulation Methods for Transport of Ethernet over MPLS		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	<https://www.rfc-editor.org/info/rfc4448>.
	[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
	Ed., "RSVP-TE Extensions in Support of End-to-End
	Generalized Multi-Protocol Label Switching (GMPLS)
	Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
	<https://www.rfc-editor.org/info/rfc4872>.
	[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
	"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
	May 2007, <https://www.rfc-editor.org/info/rfc4873>.
	[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
	Yasukawa, Ed., "Extensions to Resource Reservation
	Protocol - Traffic Engineering (RSVP-TE) for Point-to-
	Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
	DOI 10.17487/RFC4875, May 2007,
	<https://www.rfc-editor.org/info/rfc4875>.
	[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009,
	<https://www.rfc-editor.org/info/rfc5440>.
	[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	"MPLS Generic Associated Channel", RFC 5586,
	DOI 10.17487/RFC5586, June 2009,
	<https://www.rfc-editor.org/info/rfc5586>.
	[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
	Sprecher, N., and S. Ueno, "Requirements of an MPLS
	Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
	September 2009, <https://www.rfc-editor.org/info/rfc5654>.
	[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,		[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
	L., and L. Berger, "A Framework for MPLS in Transport		L., and L. Berger, "A Framework for MPLS in Transport
	Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,		Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
	<https://www.rfc-editor.org/info/rfc5921>.		<https://www.rfc-editor.org/info/rfc5921>.
	[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
	RFC 6003, DOI 10.17487/RFC6003, October 2010,
	<https://www.rfc-editor.org/info/rfc6003>.
	[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
	Ali, Z., and J. Meuric, "Extensions to the Path
	Computation Element Communication Protocol (PCEP) for
	Point-to-Multipoint Traffic Engineering Label Switched
	Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010,
	<https://www.rfc-editor.org/info/rfc6006>.
	[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
	Aissaoui, "Segmented Pseudowire", RFC 6073,
	DOI 10.17487/RFC6073, January 2011,
	<https://www.rfc-editor.org/info/rfc6073>.
	[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
	Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
	Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387,
	September 2011, <https://www.rfc-editor.org/info/rfc6387>.
	[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
	L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
	RFC 6790, DOI 10.17487/RFC6790, November 2012,
	<https://www.rfc-editor.org/info/rfc6790>.
	[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
	Extensions for Associated Bidirectional Label Switched
	Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
	<https://www.rfc-editor.org/info/rfc7551>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
	and A. Vainshtein, "Residence Time Measurement in MPLS
	Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017,
	<https://www.rfc-editor.org/info/rfc8169>.
	Appendix A. Example of TSN over DetNet Data Plane Operation
	[Editor's note: Add a simplified example of DetNet data plane and how
	labels etc work in the case of TSN over DetNet MPLS and utilizing
	e.g., PREOF.]
	Authors' Addresses		Authors' Addresses
	Balazs Varga (editor)		Balazs Varga (editor)
	Ericsson		Ericsson
	Magyar Tudosok krt. 11.		Magyar Tudosok krt. 11.
	Budapest 1117		Budapest 1117
	Hungary		Hungary
	Email: balazs.a.varga@ericsson.com		Email: balazs.a.varga@ericsson.com
	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
	Huawei Technologies		Independent
	Email: agmalis@gmail.com		Email: agmalis@gmail.com
	Stewart Bryant		Stewart Bryant
	Huawei Technologies		Futurewei Technologies
	Email: stewart.bryant@gmail.com		Email: stewart.bryant@gmail.com
	Jouni Korhonen		Don Fedyk
			LabN Consulting, L.L.C.
	Email: jouni.nospam@gmail.com		Email: dfedyk@labn.net
End of changes. 89 change blocks.
	502 lines changed or deleted		313 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/