draft-ietf-detnet-data-plane-framework-03.txt		draft-ietf-detnet-data-plane-framework-04.txt
	DetNet B. Varga, Ed.		DetNet B. Varga, Ed.
	Internet-Draft J. Farkas		Internet-Draft J. Farkas
	Intended status: Informational Ericsson		Intended status: Informational Ericsson
	Expires: April 29, 2020 L. Berger		Expires: August 6, 2020 L. Berger
	D. Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	A. Malis		A. Malis
	Independent		Independent
	S. Bryant		S. Bryant
	Futurewei Technologies		Futurewei Technologies
	J. Korhonen		February 3, 2020
	October 27, 2019
	DetNet Data Plane Framework		DetNet Data Plane Framework
	draft-ietf-detnet-data-plane-framework-03		draft-ietf-detnet-data-plane-framework-04
	Abstract		Abstract
	This document provides an overall framework for the DetNet data		This document provides an overall framework for the DetNet data
	plane. It covers concepts and considerations that are generally		plane. It covers concepts and considerations that are generally
	common to any Deterministic Networking data plane specification.		common to any Deterministic Networking data plane specification.
	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
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 38 ¶
	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 April 29, 2020.		This Internet-Draft will expire on August 6, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4		2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
	3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 5		3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 4
	3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6		3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6
	3.1.1. Data Plane Technology . . . . . . . . . . . . . . . . 6		3.1.1. Data Plane Technology . . . . . . . . . . . . . . . . 6
	3.1.2. Data Plane Format . . . . . . . . . . . . . . . . . . 6		3.1.2. Data Plane Format . . . . . . . . . . . . . . . . . . 6
	3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6		3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
	3.3. DetNet Specific Metadata . . . . . . . . . . . . . . . . 7		3.3. DetNet Specific Metadata . . . . . . . . . . . . . . . . 7
	3.4. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8		3.4. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8
	3.5. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 9		3.5. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 9
	3.6. Further DetNet Data Plane Considerations . . . . . . . . 9		3.6. Further DetNet Data Plane Considerations . . . . . . . . 9
	3.6.1. Per Flow Related Functions . . . . . . . . . . . . . 9		3.6.1. Per Flow Related Functions . . . . . . . . . . . . . 9
	3.6.2. Service Protection . . . . . . . . . . . . . . . . . 11		3.6.2. Service Protection . . . . . . . . . . . . . . . . . 11
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 41 ¶
	4.1. DetNet Controller Plane Requirements . . . . . . . . . . 16		4.1. DetNet Controller Plane Requirements . . . . . . . . . . 16
	4.2. Generic Controller Plane Considerations . . . . . . . . . 17		4.2. Generic Controller Plane Considerations . . . . . . . . . 17
	4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 18		4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 18
	4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 19		4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 19
	4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19		4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19
	4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 20		4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 20
	4.3. Packet Replication, Elimination, and Ordering (PREOF) . . 21		4.3. Packet Replication, Elimination, and Ordering (PREOF) . . 21
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 21		5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.1. Normative References . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.2. Informative References . . . . . . . . . . . . . . . . . 22		9.1. Normative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		9.2. Informative References . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	DetNet (Deterministic Networking) provides a capability to carry		DetNet (Deterministic Networking) provides a capability to carry
	specified unicast or multicast data flows for real-time applications		specified unicast or multicast data flows for real-time applications
	with extremely low packet loss rates and assured maximum end-to-end		with extremely low packet loss rates and assured maximum end-to-end
	delivery latency. A description of the general background and		delivery latency. A description of the general background and
	concepts of DetNet can be found in [I-D.ietf-detnet-architecture].		concepts of DetNet can be found in [RFC8655].
	This document describes the concepts needed by any DetNet data plane		This document describes the concepts needed by any DetNet data plane
	specification and provides considerations for any corresponding		specification and provides considerations for any corresponding
	implementation. It covers the building blocks that provide the		implementation. It covers the building blocks that provide the
	DetNet service, the DetNet service sub-layer and the DetNet		DetNet service, the DetNet service sub-layer and the DetNet
	forwarding sub-layer functions as described in the DetNet		forwarding sub-layer functions as described in the DetNet
	Architecture.		Architecture.
	The DetNet Architecture models the DetNet related data plane		The DetNet Architecture models the DetNet related data plane
	functions decomposed into two sub-layers: a service sub-layer and a		functions decomposed into two sub-layers: a service sub-layer and a
	forwarding sub-layer. The service sub-layer is used to provide		forwarding sub-layer. The service sub-layer is used to provide
	DetNet service protection and reordering. The forwarding sub-layer		DetNet service protection and reordering. The forwarding sub-layer
	leverages Traffic Engineering mechanisms and provides congestion		leverages Traffic Engineering mechanisms and provides congestion
	protection (low loss, assured latency, and limited out-of-order		protection (low loss, assured latency, and limited out-of-order
	delivery).		delivery). A particular forwarding sub-layer may have capabilities
			that are not available on other forwarding-sub layers. DetNet makes
			use of the existing forwarding sub-layers with their respective
			capabilities and does not require 1:1 equivalence between different
			forwarding sub-layer capabilities.
	As part of the service sub-layer functions, this document describes		As part of the service sub-layer functions, this document describes
	typical DetNet node data plane operation. It describes the function		typical DetNet node data plane operation. It describes the function
	and operation of the Packet Replication (PRF) Packet Elimination		and operation of the Packet Replication (PRF) Packet Elimination
	(PEF) and the Packet Ordering (POF) functions within the service sub-		(PEF) and the Packet Ordering (POF) functions within the service sub-
	layer. Furthermore, it also describes the forwarding sub-layer.		layer. Furthermore, it also describes the forwarding sub-layer.
	DetNet flows may be carried over network technologies that can		DetNet flows may be carried over network technologies that can
	provide the DetNet required service characteristics. For example,		provide the DetNet required service characteristics. For example,
	DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive		DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive
	Network (TSN) [IEEE802.1TSNTG] sub-networks. However, IEEE 802.1 TSN		Network (TSN) [IEEE802.1TSNTG] sub-networks. However, IEEE 802.1 TSN
	support is not required and some of the DetNet benefits can be gained		support is not required in DetNet. TSN frame preemption is an
	by running over a data link layer that has not been specifically		example of a forwarding layer capability that is typically not
	enhanced to support TSN.		replicated in other forwarding technologies. Most of DetNet benefits
			can be gained by running over a data link layer that has not been
			specifically enhanced to support all TSN capabilities but for certain
			networks and traffic mixes delay and jitter performance may vary due
			to the forwarding sub-layer intrinsic properties.
	Different application flows (e.g., Ethernet, IP, etc.), can be mapped		Different application flows (e.g., Ethernet, IP, etc.), can be mapped
	on top of DetNet. DetNet can optionally reuse header information		on top of DetNet. DetNet can optionally reuse header information
	provided by, or shared with, applications. An example of shared		provided by, or shared with, applications. An example of shared
	header fields can be found in [I-D.ietf-detnet-ip].		header fields can be found in [I-D.ietf-detnet-ip].
	This document also covers basic concepts related to the controller		This document also covers basic concepts related to the controller
	plane and Operations, Administration, and Maintenance (OAM). Data		plane and Operations, Administration, and Maintenance (OAM). Data
	plane OAM specifics are out of scope for this docuement.		plane OAM specifics are out of scope for this document.
	2. Terminology		2. Terminology
	2.1. Terms Used in This Document		2.1. Terms Used in This Document
	This document uses the terminology established in the DetNet		This document uses the terminology established in the DetNet
	architecture [I-D.ietf-detnet-architecture], and the reader is		architecture [RFC8655], and the reader is assumed to be familiar with
	assumed to be familiar with that document and its terminology.		that document and its terminology.
	2.2. Abbreviations		2.2. Abbreviations
	The following abbreviations are used in this document:		The following abbreviations are used in this document:
			BGP Border Gateway Protocol.
	CW Control Word.		CW Control Word.
	d-CW DetNet Control Word.		d-CW DetNet Control Word.
	DetNet Deterministic Networking.		DetNet Deterministic Networking.
	DN DetNet.		DN DetNet.
			GMPLS Generalized Multiprotocol Label Switching.
	GRE Generic Routing Encapsulation.		GRE Generic Routing Encapsulation.
	IPSec IP Security.		IPSec IP Security.
	L2 Layer 2.		L2 Layer 2.
			LSP Label Switched Path.
	LSR Label Switching Router.		LSR Label Switching Router.
	MPLS Multiprotocol Label Switching.		MPLS Multiprotocol Label Switching.
	MPLS-TE Multiprotocol Label Switching - Traffic Engineering.		MPLS-TE Multiprotocol Label Switching - Traffic Engineering.
	OAM Operations, Administration, and Maintenance.		OAM Operations, Administration, and Maintenance.
			PCEP Path Computation Element Communication Protocol.
	PEF Packet Elimination Function.		PEF Packet Elimination Function.
	PRF Packet Replication Function.		PRF Packet Replication Function.
	PREOF Packet Replication, Elimination and Ordering Functions.		PREOF Packet Replication, Elimination and Ordering Functions.
	POF Packet Ordering Function.		POF Packet Ordering Function.
	PSN Packet Switched Network.		PSN Packet Switched Network.
	PW PseudoWire.		PW PseudoWire.
	QoS Quality of Service.		QoS Quality of Service.
	S-Label DetNet "service" label.		S-Label DetNet "service" label.
	TDM Time-Division Multiplexing.		TDM Time-Division Multiplexing.
	TSN Time-Sensitive Network.		TSN Time-Sensitive Network.
			YANG Yet Another Next Generation.
	3. DetNet Data Plane Overview		3. DetNet Data Plane Overview
	This document describes how application flows, or app-flows, are		This document describes how application flows, or app-flows, are
	carried over DetNet networks. The DetNet Architecture,		carried over DetNet networks. The DetNet Architecture, [RFC8655],
	[I-D.ietf-detnet-architecture], models the DetNet related data plane		models the DetNet related data plane functions as decomposed into two
	functions as decomposed into two sub-layers: a service sub-layer and		sub-layers: a service sub-layer and a forwarding sub-layer.
	a forwarding sub-layer.
	Figure 1 reproduced from the [I-D.ietf-detnet-architecture],shows a		Figure 1 reproduced from the [RFC8655],shows a logical DetNet service
	logical DetNet service with the two sub-layers.		with the two sub-layers.
	| packets going | ^ packets coming ^		| packets going | ^ packets coming ^
	v down the stack v | up the stack |		v down the stack v | up the stack |
	+-----------------------+ +-----------------------+		+-----------------------+ +-----------------------+
	| Source | | Destination |		| Source | | Destination |
	+-----------------------+ +-----------------------+		+-----------------------+ +-----------------------+
	| Service sub-layer: | | Service sub-layer: |		| Service sub-layer: | | Service sub-layer: |
	| Packet sequencing | | Duplicate elimination |		| Packet sequencing | | Duplicate elimination |
	| Flow replication | | Flow merging |		| Flow replication | | Flow merging |
	| Packet encoding | | Packet decoding |		| Packet encoding | | Packet decoding |
	skipping to change at page 6, line 6 ¶		skipping to change at page 5, line 38 ¶
	Alternatively, an overlay approach may be used in which the packet is		Alternatively, an overlay approach may be used in which the packet is
	natively carried between key nodes within the DetNet network (say		natively carried between key nodes within the DetNet network (say
	between PREOF nodes) and a sub-layer is used to provide the		between PREOF nodes) and a sub-layer is used to provide the
	information needed to reach the next hop in the overlay.		information needed to reach the next hop in the overlay.
	The forwarding sub-layer provides the QoS related functions needed by		The forwarding sub-layer provides the QoS related functions needed by
	the DetNet flow. It may do this directly through the use of queuing		the DetNet flow. It may do this directly through the use of queuing
	techniques and traffic engineering methods, or it may do this through		techniques and traffic engineering methods, or it may do this through
	the assistance of its underlying connectivity. For example it may		the assistance of its underlying connectivity. For example it may
	call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN		call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN
	[IEEE802.1TSNTG].		[IEEE802.1TSNTG]. The forwarding sub-layer uses buffer resources for
			packet queuing, as well as reservation and allocation of bandwidth
			capacity resources.
	The service sub-layer provides additional support beyond the		The service sub-layer provides additional support beyond the
	connectivity function of the forwarding sub-layer. An example of		connectivity function of the forwarding sub-layer. An example of
	this is Packet Replication, Elimination, and Ordering functions see		this is Packet Replication, Elimination, and Ordering functions see
	Section 4.3.		Section 4.3. The ordering (POF) uses sequence numbers added to
			packets enabling a range of packet order protection from simple
			ordering and dropping out-of-order packets to more complex reordering
			of a fixed number of out-of-order, minimally delayed packets.
			Reordering requires buffer resources and has impact on the delay and
			jitter of packets in the DetNet flow.
	The method of instantiating each of the layers is specific to the		The method of instantiating each of the layers is specific to the
	particular DetNet data plane method, and more than one approach may		particular DetNet data plane method, and more than one approach may
	be applicable to a given bearer network type.		be applicable to a given bearer network type.
	3.1. Data Plane Characteristics		3.1. Data Plane Characteristics
	There are two major characteristics to the data plane: the technology		There are two major characteristics to the data plane: the technology
	and the encapsulation, as discussed below.		and the encapsulation, as discussed below.
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 32 ¶
	it may be achieved by other technologies (e.g., Figure 2). DetNet is		it may be achieved by other technologies (e.g., Figure 2). DetNet is
	currently defined for operation over packet switched (IP) networks or		currently defined for operation over packet switched (IP) networks or
	label switched (MPLS) networks.		label switched (MPLS) networks.
	3.1.2. Data Plane Format		3.1.2. Data Plane Format
	DetNet encodes specific flow attributes (flow identity and sequence		DetNet encodes specific flow attributes (flow identity and sequence
	number) in packets. For example, in DetNet IP, zero encapsulation is		number) in packets. For example, in DetNet IP, zero encapsulation is
	used and no sequence number is available, and in DetNet MPLS, DetNet		used and no sequence number is available, and in DetNet MPLS, DetNet
	specific information may be added explicitly to the packets in the		specific information may be added explicitly to the packets in the
	format of S-label and d-CW.		format of S-label and d-CW [I-D.ietf-detnet-mpls] .
	3.2. Encapsulation		3.2. Encapsulation
	The encapsulation of a DetNet flow allows it to be sent over a data		The encapsulation of a DetNet flow allows it to be sent over a data
	plane technology other than its native type. DetNet uses header		plane technology other than its native type. DetNet uses header
	information to perform traffic classification, i.e., identify DetNet		information to perform traffic classification, i.e., identify DetNet
	flows, and provide DetNet service and forwarding functions. As		flows, and provide DetNet service and forwarding functions. As
	mentioned above, DetNet may add headers, as is the case for DN MPLS,		mentioned above, DetNet may add headers, as is the case for DN MPLS,
	or may use headers that are already present, as is the case in DN IP.		or may use headers that are already present, as is the case in DN IP.
	Figure 2 illustrates some relationships between the components.		Figure 2 illustrates some relationships between the components.
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 7 ¶
	detail in [I-D.ietf-detnet-ip].		detail in [I-D.ietf-detnet-ip].
	The DetNet forwarding plane may use explicit route capabilities and		The DetNet forwarding plane may use explicit route capabilities and
	traffic engineering capabilities to provide a forwarding sub-layer		traffic engineering capabilities to provide a forwarding sub-layer
	that is responsible for providing resource allocation and explicit		that is responsible for providing resource allocation and explicit
	routes. It is possible to include such information in a native IP		routes. It is possible to include such information in a native IP
	packet explicitly, or implicitly.		packet explicitly, or implicitly.
	3.5. DetNet MPLS Data Plane		3.5. DetNet MPLS Data Plane
	MPLS provides the ability to forward traffic over implicit and		MPLS provides a forwarding sub-layer for traffic over implicit and
	explicit paths to the point in the network where the next DetNet		explicit paths to the point in the network where the next DetNet
	service sub-layer action needs to take place. It does this through		service sub-layer action needs to take place. It does this through
	the use of a stack of one or more labels with various forwarding		the use of a stack of one or more labels with various forwarding
	semantics.		semantics.
	MPLS also provides the ability to identify a service instance that is		MPLS also provides the ability to identify a service instance that is
	used to process the packet through the use of a label that maps the		used to process the packet through the use of a label that maps the
	packet to a service instance.		packet to a service instance.
	In cases where metadata is needed to process an MPLS encapsulated		In cases where metadata is needed to process an MPLS encapsulated
	packet at the service sub-layer, a shim layer called a control word		packet at the service sub-layer, the d-CW [I-D.ietf-detnet-mpls],
	(CW) [RFC4385] can be used. Although such CWs are frequently 32 bits		[RFC4385],can be used. Although such d-CWs are frequently 32 bits
	long, there is no architectural constraint on its size of this		long, there is no architectural constraint on its size of this
	structure, only the requirement that it is fully understood by all		structure, only the requirement that it is fully understood by all
	parties operating on it in the DetNet service sub-layer. The		parties operating on it in the DetNet service sub-layer. The
	operation of this method is described in detail in		operation of this method is described in detail in
	[I-D.ietf-detnet-mpls].		[I-D.ietf-detnet-mpls].
	3.6. Further DetNet Data Plane Considerations		3.6. Further DetNet Data Plane Considerations
	This section provides informative considerations related to providing		This section provides informative considerations related to providing
	DetNet service to flows which are identified based on their header		DetNet service to flows which are identified based on their header
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 45 ¶
	basis.		basis.
	3.6.1.1. Reservation and Allocation of resources		3.6.1.1. Reservation and Allocation of resources
	Reservation of resources can allocate resources to specific DetNet		Reservation of resources can allocate resources to specific DetNet
	flows. This can eliminate packet contention and packet loss for		flows. This can eliminate packet contention and packet loss for
	DetNet traffic. This also can reduce jitter for DetNet traffic.		DetNet traffic. This also can reduce jitter for DetNet traffic.
	Resources allocated to a DetNet flow protect it from other traffic		Resources allocated to a DetNet flow protect it from other traffic
	flows. On the other hand, DetNet flows are assumed to behave with		flows. On the other hand, DetNet flows are assumed to behave with
	respect to the reserved traffic profile. Misbehaving DetNet flows		respect to the reserved traffic profile. Misbehaving DetNet flows
	must be detected and it have to be ensured that they do not		must be able to be detected and ensure that they do not compromise
	compromise QoS of other flows. The use of (queuing, policing,		QoS of other flows. Queuing, policing, and shaping policies can be
	shaping) policies can be used to ensure that the allocation of		used to ensure that the allocation of resources reserved for DetNet
	resources reserved for DetNet is met.		is met.
	3.6.1.2. Explicit routes		3.6.1.2. Explicit routes
	Use of a specific path for a flow. This allows control of the		Use of a specific path for a flow. This allows control of the
	network delay by steering the packet with the ability to influence		network delay by steering the packet with the ability to influence
	the physical path. Explicit routes complement reservation by		the physical path. Explicit routes complement reservation by
	ensuring that a consistent path can be associated with its resources		ensuring that a consistent path can be associated with its resources
	for the duration of that path. Coupled with the traffic mechanism,		for the duration of that path. Coupled with the traffic mechanism,
	this limits misordering and bounds latency. Explicit route		this limits misordering and bounds latency. Explicit route
	computation can encompass a wide set of constraints and optimize the		computation can encompass a wide set of constraints and optimize the
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 36 ¶
	number of protection schemes. MPLS hitless protection can be used to		number of protection schemes. MPLS hitless protection can be used to
	switch traffic to an already established path in order to restore		switch traffic to an already established path in order to restore
	delivery rapidly after a failure. Path changes, even in the case of		delivery rapidly after a failure. Path changes, even in the case of
	failure recovery, can lead to the out of order delivery of data		failure recovery, can lead to the out of order delivery of data
	requiring packet ordering functions either within the DetNet service		requiring packet ordering functions either within the DetNet service
	or at a high layer in the application traffic. Establishment of new		or at a high layer in the application traffic. Establishment of new
	paths after a failure is out of scope for DetNet services.		paths after a failure is out of scope for DetNet services.
	3.6.1.4. Network Coding		3.6.1.4. Network Coding
	Network Coding, not to be confused with network programming,		Network Coding, [nwcrg] not to be confused with network programming,
	comprises several techniques where multiple data flows are encoded.		comprises several techniques where multiple data flows are encoded.
	These resulting flows can then be sent on different paths. The		These resulting flows can then be sent on different paths. The
	encoding operation can combine flows and error recovery information.		encoding operation can combine flows and error recovery information.
	When the encoded flows are decoded and recombined the original flows		When the encoded flows are decoded and recombined the original flows
	can be recovered. Note that Network coding uses an alternative to		can be recovered. Note that Network coding uses an alternative to
	packet by packet PREOF. Therefore, for certain network topologies		packet by packet PREOF. Therefore, for certain network topologies
	and traffic loads, Network Coding can be used to improve a network's		and traffic loads, Network Coding can be used to improve a network's
	throughput, efficiency, latency, and scalability, as well as		throughput, efficiency, latency, and scalability, as well as
	resilience to partition, attacks, and eavesdropping, as compared to		resilience to partition, attacks, and eavesdropping, as compared to
	traditional methods. DetNet could utilized Network coding as an		traditional methods. DetNet could utilized Network coding as an
	skipping to change at page 13, line 17 ¶		skipping to change at page 13, line 17 ¶
	nodes determine which packets are eliminated and which packets are		nodes determine which packets are eliminated and which packets are
	forwarded. A 1+1 scheme where only one path is used for traffic at a		forwarded. A 1+1 scheme where only one path is used for traffic at a
	time, could use the same topology. In this case there is no PRF		time, could use the same topology. In this case there is no PRF
	function and traffic is switched upon detection of failure. An OAM		function and traffic is switched upon detection of failure. An OAM
	scheme that monitors the paths detects the loss of path or traffic is		scheme that monitors the paths detects the loss of path or traffic is
	required to initiate the switch. A POF may still be used in this		required to initiate the switch. A POF may still be used in this
	case to prevent misordering of packets. In both cases the protection		case to prevent misordering of packets. In both cases the protection
	paths are established and maintained for the duration of the DetNet		paths are established and maintained for the duration of the DetNet
	service.		service.
	3.6.2.2. Ring Service Protection		3.6.2.2. Path Differential Delay
			In the preceding example, proper working of duplicate elimination and
			reordering of packets are dependent on the number of out-of-order
			packets that can be buffered and the delay difference of arriving
			packets. DetNet uses flow specific requirements (e.g., maximum
			number of out-of-order packets, maximum latency of the flow, etc.)
			for configuration of POF related buffers. If the differential delay
			between paths is excessively large or there is excessive mis-ordering
			of the packets, then packets may be dropped instead of being
			reordered. Likewise, PEF uses the sequence number to identify
			duplicate packets, and large differential delays combined with high
			numbers of packets may exceed the ability of the PEF to work
			properly.
			3.6.2.3. Ring Service Protection
	Ring protection may also be supported if the underlying technology		Ring protection may also be supported if the underlying technology
	supports it. Many of the same concepts apply however rings are		supports it. Many of the same concepts apply however rings are
	normally 1+1 protection for data efficiency reasons. [RFC8227] is an		normally 1+1 protection for data efficiency reasons. [RFC8227] is an
	example of MPLS-TP data plane that supports Ring protection.		example of MPLS-TP data plane that supports Ring protection.
	3.6.3. Aggregation Considerations		3.6.3. Aggregation Considerations
	The DetNet data plane also allows for the aggregation of DetNet		The DetNet data plane also allows for the aggregation of DetNet
	flows, which can improve scalability by reducing the per-hop state.		flows, which can improve scalability by reducing the per-hop state.
	skipping to change at page 16, line 25 ¶		skipping to change at page 16, line 25 ¶
	+------+		+------+
	| L2 |		| L2 |
	+------+		+------+
	Figure 5: Example DetNet MPLS Sub-Network Formats		Figure 5: Example DetNet MPLS Sub-Network Formats
	4. Controller Plane (Management and Control) Considerations		4. Controller Plane (Management and Control) Considerations
	4.1. DetNet Controller Plane Requirements		4.1. DetNet Controller Plane Requirements
	While the definition of controller plane for DetNet is out of the		The Controller Plane corresponds to the aggregation of the Control
	scope of this document, there are particular considerations and		and Management Planes discussed in [RFC7426] and [RFC8655]. While
	requirements for such that result from the unique characteristics of		more details of any DetNet controller plane are out of the scope of
	the DetNet architecture [I-D.ietf-detnet-architecture] and data plane		this document, there are particular considerations and requirements
	as defined herein.		for such that result from the unique characteristics of the DetNet
			architecture [RFC8655] and data plane as defined herein.
	The primary requirements of the DetNet controller plane are that it		The primary requirements of the DetNet controller plane are that it
	must be able to:		must be able to:
	o Instantiate DetNet flows in a DetNet domain (which may include		o Instantiate DetNet flows in a DetNet domain (which may include
	some or all of explicit path determination, link bandwidth		some or all of explicit path determination, link bandwidth
	reservations, restricting flows to IEEE 802.1 TSN links, node		reservations, restricting flows to IEEE 802.1 TSN links, node
	buffer and other resource reservations, specification of required		buffer and other resource reservations, specification of required
	queuing disciplines along the path, ability to manage		queuing disciplines along the path, ability to manage
	bidirectional flows, etc.) as needed for a flow.		bidirectional flows, etc.) as needed for a flow.
	skipping to change at page 17, line 44 ¶		skipping to change at page 17, line 44 ¶
	used as the basis of a later analysis of the alternatives.		used as the basis of a later analysis of the alternatives.
	4.2. Generic Controller Plane Considerations		4.2. Generic Controller Plane Considerations
	This section covers control plane considerations that are independent		This section covers control plane considerations that are independent
	of the data plane technology used for DetNet service delivery.		of the data plane technology used for DetNet service delivery.
	While management plane and control planes are traditionally		While management plane and control planes are traditionally
	considered separately, from the Data Plane perspective there is no		considered separately, from the Data Plane perspective there is no
	practical difference based on the origin of flow provisioning		practical difference based on the origin of flow provisioning
	information, and the DetNet architecture		information, and the DetNet architecture [RFC8655] refers to these
	[I-D.ietf-detnet-architecture] refers to these collectively as the		collectively as the 'Controller Plane'. This document therefore does
	'Controller Plane'. This document therefore does not distinguish		not distinguish between information provided by distributed control
	between information provided by distributed control plane protocols,		plane protocols, e.g., RSVP-TE [RFC3209] and [RFC3473], or by
	e.g., RSVP-TE [RFC3209] and [RFC3473], or by centralized network		centralized network management mechanisms, e.g., RestConf [RFC8040],
	management mechanisms, e.g., RestConf [RFC8040], YANG [RFC7950], and		YANG [RFC7950], and the Path Computation Element Communication
	the Path Computation Element Communication Protocol (PCEP)		Protocol (PCEP) [I-D.ietf-pce-pcep-extension-for-pce-controller] or
	[I-D.ietf-pce-pcep-extension-for-pce-controller] or any combination		any combination thereof. Specific considerations and requirements
	thereof. Specific considerations and requirements for the DetNet		for the DetNet Controller Plane are discussed in Section 4.1.
	Controller Plane are discussed in Section 4.1.
	Each respective data plane document also covers the control plane		Each respective data plane document also covers the control plane
	considerations for that technology. For example [I-D.ietf-detnet-ip]		considerations for that technology. For example [I-D.ietf-detnet-ip]
	covers IP control plane normative considerations and		covers IP control plane normative considerations and
	[I-D.ietf-detnet-mpls] covers MPLS control plane normative		[I-D.ietf-detnet-mpls] covers MPLS control plane normative
	considerations.		considerations.
	4.2.1. Flow Aggregation Control		4.2.1. Flow Aggregation Control
	Flow aggregation means that multiple App-flows are served by a single		Flow aggregation means that multiple App-flows are served by a single
	skipping to change at page 20, line 6 ¶		skipping to change at page 20, line 6 ¶
	4.2.3. Contention Loss and Jitter Reduction		4.2.3. Contention Loss and Jitter Reduction
	As discussed in Section 1, this document does not specify the		As discussed in Section 1, this document does not specify the
	mechanisms needed to eliminate packet contention, packet loss or		mechanisms needed to eliminate packet contention, packet loss or
	reduce jitter for DetNet flows at the DetNet forwarding sub-layer.		reduce jitter for DetNet flows at the DetNet forwarding sub-layer.
	The ability to manage node and link resources to be able to provide		The ability to manage node and link resources to be able to provide
	these functions is a necessary part of the DetNet controller plane.		these functions is a necessary part of the DetNet controller plane.
	It is also necessary to be able to control the required queuing		It is also necessary to be able to control the required queuing
	mechanisms used to provide these functions along a flow's path		mechanisms used to provide these functions along a flow's path
	through the network. See [I-D.ietf-detnet-ip] and Section 4.1 for		through the network. See [I-D.ietf-detnet-ip] and Section 4.1 for
	further discussion of these requirements.		further discussion of these requirements. Some forms of protection
			may minimize packet loss or change jitter characteristics in the
			cases where packets are reordered when out-of-order packets are
			received at the service sub-layer.
	4.2.4. Bidirectional Traffic		4.2.4. Bidirectional Traffic
	DetNet applications typically generate bidirectional traffic. IP and		In many cases DetNet flows can be considered unidirectional and
	MPLS typically treat each direction separately and do not force		independent. However, there are cases where the DetNet service
	interdependence of each direction. MPLS has considered bidirectional		requires bidirectional traffic from a DetNet application service
	traffic requirements and the MPLS definitions from [RFC5654] are		perspective. IP and MPLS typically treat each direction separately
	useful to illustrate terms such as associated bidirectional flows and		and do not force interdependence of each direction. MPLS has
	co-routed bidirectional flows. MPLS defines a point-to-point		considered bidirectional traffic requirements and the MPLS
	associated bidirectional LSP as consisting of two unidirectional		definitions from [RFC5654] are useful to illustrate terms such as
	point-to-point LSPs, one from A to B and the other from B to A, which		associated bidirectional flows and co-routed bidirectional flows.
	are regarded as providing a single logical bidirectional forwarding		MPLS defines a point-to-point associated bidirectional LSP as
	path. This is analogous to standard IP routing. MPLS defines a		consisting of two unidirectional point-to-point LSPs, one from A to B
	point-to-point co-routed bidirectional LSP as an associated		and the other from B to A, which are regarded as providing a single
	bidirectional LSP which satisfies the additional constraint that its		logical bidirectional forwarding path. This is analogous to standard
	two unidirectional component LSPs follow the same path (in terms of		IP routing. MPLS defines a point-to-point co-routed bidirectional
	both nodes and links) in both directions. An important property of		LSP as an associated bidirectional LSP which satisfies the additional
	co-routed bidirectional LSPs is that their unidirectional component		constraint that its two unidirectional component LSPs follow the same
	LSPs share fate. In both types of bidirectional LSPs, resource		path (in terms of both nodes and links) in both directions. An
	reservations may differ in each direction. The concepts of		important property of co-routed bidirectional LSPs is that their
	associated bidirectional flows and co-routed bidirectional flows can		unidirectional component LSPs share fate. In both types of
	also be applied to DetNet IP flows.		bidirectional LSPs, resource reservations may differ in each
			direction. The concepts of associated bidirectional flows and co-
			routed bidirectional flows can also be applied to DetNet IP flows.
	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 with respect to		flows, there are no special bidirectional features with respect to
	the data plane other than the need for the two directions of a co-		the data plane other than the need for the two directions of a co-
	routed bidirectional flow to take the same path. That is to say that		routed bidirectional flow to take the same path. That is to say that
	bidirectional DetNet flows are solely represented at the management		bidirectional DetNet flows are solely represented at the management
	and control plane levels, without specific support or knowledge		and control plane levels, without specific support or knowledge
	within the DetNet data plane. Fate sharing and associated or co-		within the DetNet data plane. Fate sharing and associated or co-
	routed bidirectional flows, can be managed at the control level.		routed bidirectional flows, can be managed at the control level.
	skipping to change at page 21, line 25 ¶		skipping to change at page 21, line 28 ¶
	it should be noted that the ability to determine, for a particular		it should be noted that the ability to determine, for a particular
	flow, optimal packet replication and elimination points in the DetNet		flow, optimal packet replication and elimination points in the DetNet
	domain requires explicit support. There may be capabilities that can		domain requires explicit support. There may be capabilities that can
	be used, or extended, for example GMPLS end-to-end recovery [RFC4872]		be used, or extended, for example GMPLS end-to-end recovery [RFC4872]
	and GMPLS segment recovery [RFC4873].		and GMPLS segment recovery [RFC4873].
	5. Security Considerations		5. Security Considerations
	Security considerations for DetNet are described in detail in		Security considerations for DetNet are described in detail in
	[I-D.ietf-detnet-security]. General security considerations are		[I-D.ietf-detnet-security]. General security considerations are
	described in [I-D.ietf-detnet-architecture]. This section considers		described in [RFC8655]. This section considers general security
	general security considerations applicable to all data planes.		considerations applicable to all data planes.
	Security aspects which are unique to DetNet are those whose aim is to		Security aspects which are unique to DetNet are those whose aim is to
	provide the specific quality of service aspects of DetNet, which are		provide the specific quality of service aspects of DetNet, which are
	primarily to deliver data flows with extremely low packet loss rates		primarily to deliver data flows with extremely low packet loss rates
	and bounded end-to-end delivery latency.		and bounded end-to-end delivery latency.
	The primary considerations for the data plane is to maintain		The primary considerations for the 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. Application flows can be protected		traversing the DetNet network. Application flows can be protected
	through whatever means is provided by the underlying technology. For		through whatever means is provided by the underlying technology. For
	skipping to change at page 22, line 26 ¶		skipping to change at page 22, line 31 ¶
	This document makes no IANA requests.		This document makes no IANA requests.
	7. Acknowledgements		7. Acknowledgements
	The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,		The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
	David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David		David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
	Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.		Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
	Bernardos for their various contributions to this work.		Bernardos for their various contributions to this work.
	8. References		8. Contributors
	8.1. Normative References		The following people contributed substantially to the content of this
			document:
			Don Fedyk
			Jouni Korhonen
			9. References
			9.1. Normative References
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,		Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
	<https://www.rfc-editor.org/info/rfc3209>.		<https://www.rfc-editor.org/info/rfc3209>.
	[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation Protocol-		Switching (GMPLS) Signaling Resource ReserVation Protocol-
	Traffic Engineering (RSVP-TE) Extensions", RFC 3473,		Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
	DOI 10.17487/RFC3473, January 2003,		DOI 10.17487/RFC3473, January 2003,
	<https://www.rfc-editor.org/info/rfc3473>.		<https://www.rfc-editor.org/info/rfc3473>.
	[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,		[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for		"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
	Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,		Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
	February 2006, <https://www.rfc-editor.org/info/rfc4385>.		February 2006, <https://www.rfc-editor.org/info/rfc4385>.
	8.2. Informative References		[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
			"Deterministic Networking Architecture", RFC 8655,
			DOI 10.17487/RFC8655, October 2019,
			<https://www.rfc-editor.org/info/rfc8655>.
	[I-D.ietf-detnet-architecture]		9.2. Informative References
	Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", draft-ietf-
	detnet-architecture-13 (work in progress), May 2019.
	[I-D.ietf-detnet-flow-information-model]		[I-D.ietf-detnet-flow-information-model]
	Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D.		Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D.
	Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-		Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-
	flow-information-model-05 (work in progress), September		flow-information-model-06 (work in progress), October
	2019.		2019.
	[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., Malis, A.,
	Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",		Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
	draft-ietf-detnet-ip-01 (work in progress), July 2019.		draft-ietf-detnet-ip-04 (work in progress), November 2019.
	[I-D.ietf-detnet-mpls]		[I-D.ietf-detnet-mpls]
	Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,		Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
	Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",		Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
	draft-ietf-detnet-mpls-01 (work in progress), July 2019.		draft-ietf-detnet-mpls-04 (work in progress), November
			2019.
	[I-D.ietf-detnet-mpls-over-tsn]		[I-D.ietf-detnet-mpls-over-tsn]
	Varga, B., Farkas, J., Malis, A., Bryant, S., and J.		Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet
	Korhonen, "DetNet Data Plane: MPLS over IEEE 802.1 Time		Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking
	Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over-		(TSN)", draft-ietf-detnet-mpls-over-tsn-01 (work in
	tsn-00 (work in progress), May 2019.		progress), October 2019.
	[I-D.ietf-detnet-mpls-over-udp-ip]		[I-D.ietf-detnet-mpls-over-udp-ip]
	Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,		Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
	and J. Korhonen, "DetNet Data Plane: MPLS over UDP/IP",		and J. Korhonen, "DetNet Data Plane: MPLS over UDP/IP",
	draft-ietf-detnet-mpls-over-udp-ip-02 (work in progress),		draft-ietf-detnet-mpls-over-udp-ip-04 (work in progress),
	October 2019.		November 2019.
	[I-D.ietf-detnet-security]		[I-D.ietf-detnet-security]
	Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,		Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
	J., Austad, H., Stanton, K., and N. Finn, "Deterministic		J., Austad, H., and N. Finn, "Deterministic Networking
	Networking (DetNet) Security Considerations", draft-ietf-		(DetNet) Security Considerations", draft-ietf-detnet-
	detnet-security-05 (work in progress), August 2019.		security-07 (work in progress), January 2020.
	[I-D.ietf-pce-pcep-extension-for-pce-controller]		[I-D.ietf-pce-pcep-extension-for-pce-controller]
	Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures		Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
	and Protocol Extensions for Using PCE as a Central		and Protocol Extensions for Using PCE as a Central
	Controller (PCECC) of LSPs", draft-ietf-pce-pcep-		Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
	extension-for-pce-controller-02 (work in progress), July		extension-for-pce-controller-03 (work in progress),
	2019.		November 2019.
	[I-D.ietf-spring-srv6-network-programming]		[I-D.ietf-spring-srv6-network-programming]
	Filsfils, C., Camarillo, P., Leddy, J.,		Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
	daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6		Matsushima, S., and Z. Li, "SRv6 Network Programming",
	Network Programming", draft-ietf-spring-srv6-network-		draft-ietf-spring-srv6-network-programming-08 (work in
	programming-05 (work in progress), October 2019.		progress), January 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>.
	[IEEE802.1TSNTG]		[IEEE802.1TSNTG]
	IEEE Standards Association, "IEEE 802.1 Time-Sensitive		IEEE Standards Association, "IEEE 802.1 Time-Sensitive
	Networking Task Group", <http://www.ieee802.org/1/tsn>.		Networking Task Group", <http://www.ieee802.org/1/tsn>.
			[nwcrg] IRTF, "Coding for efficient NetWork Communications
			Research Group (nwcrg)",
			<https://datatracker.ietf.org/rg/nwcrg/about>.
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, DOI 10.17487/RFC2205,		Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
	September 1997, <https://www.rfc-editor.org/info/rfc2205>.		September 1997, <https://www.rfc-editor.org/info/rfc2205>.
	[RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A		[RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A
	Framework for QoS-based Routing in the Internet",		Framework for QoS-based Routing in the Internet",
	RFC 2386, DOI 10.17487/RFC2386, August 1998,		RFC 2386, DOI 10.17487/RFC2386, August 1998,
	<https://www.rfc-editor.org/info/rfc2386>.		<https://www.rfc-editor.org/info/rfc2386>.
	skipping to change at page 25, line 10 ¶		skipping to change at page 25, line 30 ¶
	[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,		[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
	Sprecher, N., and S. Ueno, "Requirements of an MPLS		Sprecher, N., and S. Ueno, "Requirements of an MPLS
	Transport Profile", RFC 5654, DOI 10.17487/RFC5654,		Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
	September 2009, <https://www.rfc-editor.org/info/rfc5654>.		September 2009, <https://www.rfc-editor.org/info/rfc5654>.
	[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.		[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
	Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label		Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
	Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387,		Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387,
	September 2011, <https://www.rfc-editor.org/info/rfc6387>.		September 2011, <https://www.rfc-editor.org/info/rfc6387>.
			[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
			Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
			Defined Networking (SDN): Layers and Architecture
			Terminology", RFC 7426, DOI 10.17487/RFC7426, January
			2015, <https://www.rfc-editor.org/info/rfc7426>.
	[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE		[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
	Extensions for Associated Bidirectional Label Switched		Extensions for Associated Bidirectional Label Switched
	Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,		Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
	<https://www.rfc-editor.org/info/rfc7551>.		<https://www.rfc-editor.org/info/rfc7551>.
	[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services		[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
	(Diffserv) and Real-Time Communication", RFC 7657,		(Diffserv) and Real-Time Communication", RFC 7657,
	DOI 10.17487/RFC7657, November 2015,		DOI 10.17487/RFC7657, November 2015,
	<https://www.rfc-editor.org/info/rfc7657>.		<https://www.rfc-editor.org/info/rfc7657>.
	skipping to change at page 26, line 4 ¶		skipping to change at page 26, line 27 ¶
	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
	Lou Berger		Lou Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: lberger@labn.net		Email: lberger@labn.net
	Don Fedyk
	LabN Consulting, L.L.C.
	Email: dfedyk@labn.net
	Andrew G. Malis		Andrew G. Malis
	Independent		Independent
	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
	Jouni Korhonen
	Email: jouni.nospam@gmail.com
End of changes. 67 change blocks.
	126 lines changed or deleted		159 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/