rfc9056.original		rfc9056.txt
	DetNet B. Varga, Ed.		Internet Engineering Task Force (IETF) B. Varga, Ed.
	Internet-Draft Ericsson		Request for Comments: 9056 Ericsson
	Intended status: Standards Track L. Berger		Category: Standards Track L. Berger
	Expires: April 14, 2021 D. Fedyk		ISSN: 2070-1721 D. Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	S. Bryant		S. Bryant
	Futurewei Technologies		Futurewei Technologies
	J. Korhonen		J. Korhonen
	October 11, 2020		October 2021
	DetNet Data Plane: IP over MPLS		Deterministic Networking (DetNet) Data Plane: IP over MPLS
	draft-ietf-detnet-ip-over-mpls-09
	Abstract		Abstract
	This document specifies the Deterministic Networking data plane when		This document specifies the Deterministic Networking data plane when
	encapsulating IP over an MPLS packet switched network.		encapsulating IP over an MPLS packet-switched network.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on April 14, 2021.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9056.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology
	2.1. Terms Used In This Document . . . . . . . . . . . . . . . 2		2.1. Terms Used in This Document
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations
	2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.3. Requirements Language
	3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4		3. DetNet IP Data Plane Overview
	4. IP over DetNet MPLS . . . . . . . . . . . . . . . . . . . . . 5		4. DetNet IP over DetNet MPLS
	4.1. IP Over DetNet MPLS Data Plane Scenarios . . . . . . . . 5		4.1. DetNet IP over DetNet MPLS Data Plane Scenarios
	4.2. DetNet IP over DetNet MPLS Encapsulation . . . . . . . . 6		4.2. DetNet IP over DetNet MPLS Encapsulation
	5. IP over DetNet MPLS Procedures . . . . . . . . . . . . . . . 8		5. DetNet IP over DetNet MPLS Procedures
	5.1. DetNet IP over DetNet MPLS Flow Identification		5.1. DetNet IP over DetNet MPLS Flow Identification and
	and Aggregation Procedures . . . . . . . . . . . . . . . 8		Aggregation Procedures
	5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures . 9		5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures
	6. Management and Control Information Summary . . . . . . . . . 9		6. Management and Control Information Summary
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		9. References
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11		9.1. Normative References
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9.2. Informative References
	11.1. Normative references . . . . . . . . . . . . . . . . . . 11		Acknowledgements
	11.2. Informative references . . . . . . . . . . . . . . . . . 12		Contributors
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses
	1. Introduction		1. Introduction
	Deterministic Networking (DetNet) is a service that can be offered by		Deterministic Networking (DetNet) is a service that can be offered by
	a network to DetNet flows. DetNet provides a capability for the		a network to DetNet flows. DetNet provides a capability for the
	delivery of data flows with extremely low packet loss rates and		delivery of data flows with extremely low packet loss rates and
	bounded end-to-end delivery latency. General background and concepts		bounded end-to-end delivery latency. General background and concepts
	of DetNet can be found in the DetNet Architecture [RFC8655].		of DetNet can be found in the DetNet architecture [RFC8655].
	This document specifies use of the IP DetNet encapsulation over an		This document specifies use of the IP DetNet encapsulation over an
	MPLS network. It maps the IP data plane encapsulation described in		MPLS network. It maps the IP data plane encapsulation described in
	[I-D.ietf-detnet-ip] to the DetNet MPLS data plane defined in		[RFC8939] to the DetNet MPLS data plane defined in [RFC8964].
	[I-D.ietf-detnet-mpls].
	2. Terminology		2. Terminology
	2.1. Terms Used In This Document		2.1. Terms Used in This Document
	This document uses the terminology and concepts established in the		This document uses the terminology and concepts established in the
	DetNet architecture [RFC8655] and		DetNet architecture [RFC8655] and in [RFC8938]. The reader is
			assumed to be familiar with these documents and their terminology.
	[I-D.ietf-detnet-data-plane-framework], the reader is assumed to be
	familiar with these documents and their terminology.
	2.2. Abbreviations		2.2. Abbreviations
	This document uses the abbreviations defined in the DetNet		This document uses the abbreviations defined in the DetNet
	architecture [RFC8655] and [I-D.ietf-detnet-data-plane-framework].		architecture [RFC8655] and in [RFC8938]. This document uses the
	This document uses the following abbreviations:		following abbreviations:
	CE Customer Edge equipment.		CE Customer Edge (equipment)
	d-CW DetNet Control Word.		d-CW DetNet Control Word
	DetNet Deterministic Networking.		DetNet Deterministic Networking
	DF DetNet Flow.		DF DetNet Flow
	DN DetNet.		DN DetNet
	L2 Layer-2.		L2 Layer 2
	LSP Label-switched path.		LSP Label-Switched Path
	MPLS Multiprotocol Label Switching.		MPLS Multiprotocol Label Switching
	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
	PW Pseudowire.		PW Pseudowire
	S-Label DetNet "service" label.		S-Label DetNet "service" Label
	S-PE Switching Provider Edge.		S-PE Switching Provider Edge
	T-PE Terminating Provider Edge.		T-PE Terminating Provider Edge
	TE Traffic Engineering.		TE Traffic Engineering
	TSN Time-Sensitive Networking, TSN is a Task Group of the		TSN Time-Sensitive Networking; TSN is a Task Group of the
	IEEE 802.1 Working Group.		IEEE 802.1 Working Group
	2.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
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. DetNet IP Data Plane Overview		3. DetNet IP Data Plane Overview
	Figure 1 illustrates an IP DetNet, with an MPLS based DetNet network		Figure 1 illustrates an IP DetNet with an MPLS-based DetNet network
	as a sub-network between the relay nodes. An IP flow is mapped to		as a sub-network between the relay nodes. An IP flow is mapped to
	one or more PWs and MPLS (TE) LSPs. The end systems still originate		one or more PWs and MPLS (TE) LSPs. The end systems still originate
	IP encapsulated traffic, identified as DetNet flows. The relay nodes		IP-encapsulated traffic, identified as DetNet flows. The relay nodes
	follow procedures defined in Section 4 to map each DetNet flow to		follow procedures defined in Section 4 to map each DetNet flow to
	MPLS LSPs. While not shown, relay nodes can provide service sub-		MPLS LSPs. While not shown, relay nodes can provide service sub-
	layer functions such as PREOF using DetNet over MPLS, and this is		layer functions such as PREOF using DetNet over MPLS, and this is
	indicated by the solid line for the MPLS facing portion of the		indicated by the solid line for the MPLS-facing portion of the
	Service component. Note that the Transit node is MPLS (TE) LSP aware		Service component. Note that the Transit node is MPLS (TE) LSP aware
	and performs switching based on MPLS labels, and need not have any		and performs switching based on MPLS labels; it need not have any
	specific knowledge of the DetNet service or the corresponding DetNet		specific knowledge of the DetNet service or the corresponding DetNet
	flow identification. See Section 4 for details on the mapping of IP		flow identification. See Section 4 for details on the mapping of IP
	flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of		flows to MPLS, and [RFC8964] for general support of DetNet services
	DetNet services using MPLS.		using MPLS.
	DetNet IP Relay Transit Relay DetNet IP		DetNet IP Relay Transit Relay DetNet IP
	End System Node Node Node End System		End System Node Node Node End System
	+----------+ +----------+		+----------+ +----------+
	| Appl. |<------------- End to End Service ---------->| Appl. |		| Appl. |<------------- End to End Service ---------->| Appl. |
	+----------+ .....-----+ +-----..... +----------+		+----------+ .....-----+ +-----..... +----------+
	| Service |<--: Service |--DetNet flow ---| Service :-->| Service |		| Service |<--: Service |--DetNet flow ---| Service :-->| Service |
	| | : |<-DN MPLS flow ->| : | |		| | : |<-DN MPLS flow ->| : | |
	+----------+ +---------+ +----------+ +---------+ +----------+		+----------+ +---------+ +----------+ +---------+ +----------+
	|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|		|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
	+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+		+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
	: Link : / ,-----. \ : Link : / ,-----. \		: Link : / ,-----. \ : Link : / ,-----. \
	+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+		+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+
	[Network] [Network]		[Network] [Network]
	`-----' `-----'		`-----' `-----'
	|<---- DetNet MPLS ---->|		|<---- DetNet MPLS ---->|
	|<--------------------- DetNet IP ------------------>|		|<--------------------- DetNet IP ------------------>|
	Figure 1: Architecture: DetNet IP Over DetNet MPLS Network		Figure 1: Architecture: DetNet IP over DetNet MPLS Network
	4. IP over DetNet MPLS		4. DetNet IP over DetNet MPLS
	This section defines how IP encapsulated flows are carried over a		This section defines how IP-encapsulated flows are carried over a
	DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. Since		DetNet MPLS data plane as defined in [RFC8964]. Since both non-
	both Non-DetNet and DetNet IP packet are identical on the wire, this		DetNet and DetNet IP packets are identical on the wire, this section
	section is applicable to any node that supports IP over DetNet MPLS,		is applicable to any node that supports IP over DetNet MPLS, and this
	and this section refers to both cases as DetNet IP over DetNet MPLS.		section refers to both cases as DetNet IP over DetNet MPLS.
	4.1. IP Over DetNet MPLS Data Plane Scenarios		4.1. DetNet IP over DetNet MPLS Data Plane Scenarios
	An example use of DetNet IP over DetNet MPLS is presented here.		An example use of DetNet IP over DetNet MPLS is presented here.
	Figure 1 illustrates IP DetNet enabled End Systems (hosts) connected		Figure 1 illustrates IP DetNet-enabled End Systems (hosts) connected
	to DetNet (DN) enabled IP networks, operating over a DetNet aware		to DetNet-enabled IP networks (DN IP), operating over a DetNet-aware
	MPLS network. In this Figure we have a case where the Relay nodes		MPLS network. In this figure, we have a case where the relay nodes
	act as T-PEs and sit at the boundary of the MPLS domain since the		act as T-PEs and sit at the boundary of the MPLS domain since the
	non-MPLS domain is DetNet aware. This case is very similar to the		non-MPLS domain is DetNet aware. This case is very similar to the
	DetNet MPLS Network Figure 2 in [I-D.ietf-detnet-mpls]. However, in		DetNet MPLS Network (Figure 2 in [RFC8964]). However, in Figure 2 of
	[I-D.ietf-detnet-mpls] Figure 2, the T-PEs are located at the end		[RFC8964], the T-PEs are located at the end system and MPLS spans the
	system and MPLS spans the whole DetNet service. The primary		whole DetNet service. The primary difference in this document is
	difference in this document is that the Relay nodes are at the edges		that the relay nodes are at the edges of the MPLS domain and
	of the MPLS domain and therefore function as T-PEs, and that MPLS		therefore function as T-PEs, and that MPLS service sub-layer
	service sub-layer functions are not provided over the DetNet IP		functions are not provided over the DetNet IP network. The transit
	network. The transit node functions shown above are identical to		node functions shown above are identical to those described in
	those described in [I-D.ietf-detnet-mpls].		[RFC8964].
	Figure 2 illustrates how relay nodes can provide service protection		Figure 2 illustrates how relay nodes can provide service protection
	over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end		over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end
	systems which are interconnected via a MPLS domain such as described		systems that are interconnected via an MPLS domain such as that
	in [I-D.ietf-detnet-mpls]. Note that R1 and R3 sit at the edges of		described in [RFC8964]. Note that R1 and R3 sit at the edges of an
	an MPLS domain and therefore are similar to T-PEs, while R2 sits in		MPLS domain and therefore are similar to T-PEs, while R2 sits in the
	the middle of the domain and is therefore similar to an S-PE.		middle of the domain and is therefore similar to an S-PE.
	DetNet DetNet		DetNet DetNet
	IP Service Transit Transit Service IP		IP Service Transit Transit Service IP
	DetNet |<-Tnl->| |<-Tnl->| DetNet		DetNet |<-Tnl->| |<-Tnl->| DetNet
	End | V 1 V V 2 V | End		End | V 1 V V 2 V | End
	System | +--------+ +--------+ +--------+ | System		System | +--------+ +--------+ +--------+ | System
	+---+ | | R1 |=======| R2 |=======| R3 | | +---+		+---+ | | R1 |=======| R2 |=======| R3 | | +---+
	| |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| |		| |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| |
	|CE1| | | \ | | X | | / | | |CE2|		|CE1| | | \ | | X | | / | | |CE2|
	| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |		| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
	skipping to change at page 6, line 28 ¶		skipping to change at line 238 ¶
	| |		| |
	|<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|		|<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|
	| |		| |
	|<-------------- End to End DetNet Service --------------->|		|<-------------- End to End DetNet Service --------------->|
	-------------------------- Data Flow ------------------------->		-------------------------- Data Flow ------------------------->
	X = Service protection (PRF, PREOF, PEF/POF)		X = Service protection (PRF, PREOF, PEF/POF)
	DFx = DetNet member flow x over a TE LSP		DFx = DetNet member flow x over a TE LSP
	Figure 2: Service Protection Over DetNet MPLS Network for DetNet IP		Figure 2: Service Protection over DetNet MPLS Network for DetNet IP
	Figure 1 illustrates DetNet enabled End Systems connected to DetNet		Figure 1 illustrates DetNet-enabled end systems connected to DetNet-
	(DN) enabled MPLS network. A similar situation occurs when end		enabled (DN) MPLS networks. A similar situation occurs when end
	systems are not DetNet aware. In this case, edge nodes sit at the		systems are not DetNet aware. In this case, edge nodes sit at the
	boundary of the MPLS domain since it is also a DetNet domain		boundary of the MPLS domain since it is also a DetNet domain
	boundary. The edge nodes provide DetNet service proxies for the end		boundary. The edge nodes provide DetNet service proxies for the end
	applications by initiating and terminating DetNet service for the		applications by initiating and terminating DetNet service for the
	application's IP flows. While the node types differ, there is		application's IP flows. While the node types differ, there is
	essentially no difference in data plane processing between relay and		essentially no difference in data plane processing between relays and
	edges. There are likely to be differences in controller plane		edges. There are likely to be differences in Controller Plane
	operation, particularly when distributed control plane protocols are		operation, particularly when distributed control plane protocols are
	used.		used.
	It is still possible to provide DetNet service protection for non-		It is still possible to provide DetNet service protection for non-
	DetNet aware end systems. This case is basically the same as		DetNet-aware end systems. This case is basically the same as
	Figure 2, with the exception that CE1 and CE2 are non-DetNet aware		Figure 2, with the exception that CE1 and CE2 are non-DetNet-aware
	end systems and R1 and R3 become edge nodes.		end systems and R1 and R3 become edge nodes.
	4.2. DetNet IP over DetNet MPLS Encapsulation		4.2. DetNet IP over DetNet MPLS Encapsulation
	The basic encapsulation approach is to treat a DetNet IP flow as an		The basic encapsulation approach is to treat a DetNet IP flow as an
	app-flow from the DetNet MPLS perspective. The corresponding example		App-flow from the DetNet MPLS perspective. The corresponding example
	DetNet Sub-Network format is shown in Figure 3.		DetNet Sub-network format is shown in Figure 3.
	/-> +------+ +------+ +------+ ^ ^		/-> +------+ +------+ +------+ ^ ^
	| | X | | X | | X |<- App-Flow : :		| | X | | X | | X |<- App-flow : :
	| +------+ +------+ +------+ : :		| +------+ +------+ +------+ : :
	App-Flow <-+ |NProto| |NProto| |NProto| : :(1)		App-flow <-+ |NProto| |NProto| |NProto| : :(1)
	for MPLS | +------+ +------+ +------+ : :		for MPLS | +------+ +------+ +------+ : :
	| | IP | | IP | | IP | : v		| | IP | | IP | | IP | : v
	\-> +---+======+--+======+--+======+-----+ :		\-> +---+======+--+======+--+======+-----+ :
	DetNet-MPLS | d-CW | | d-CW | | d-CW | :		DetNet-MPLS | d-CW | | d-CW | | d-CW | :
	+------+ +------+ +------+ :(2)		+------+ +------+ +------+ :(2)
	|Labels| |Labels| |Labels| v		|Labels| |Labels| |Labels| v
	+---+======+--+======+--+======+-----+		+---+======+--+======+--+======+-----+
	Link/Sub-Network | L2 | | TSN | | UDP |		Link/Sub-network | L2 | | TSN | | UDP |
	+------+ +------+ +------+		+------+ +------+ +------+
	| IP |		| IP |
	+------+		+------+
	| L2 |		| L2 |
	+------+		+------+
	(1) DetNet IP Flow (or simply IP flow)		(1) DetNet IP Flow (or simply IP flow)
	(2) DetNet MPLS Flow		(2) DetNet MPLS Flow
	Figure 3: Example DetNet IP over MPLS Sub-Network Formats		Figure 3: Example DetNet IP over MPLS Sub-network Formats
	In Figure 3 "App-Flow" indicates the payload carried by the DetNet IP		In Figure 3, "App-flow" indicates the payload carried by the DetNet
	data plane. "IP" and "NProto" indicate the fields described in		IP data plane. "IP" and "NProto" indicate the fields described in
	Section 5.1.1. (IP Header Information) and Section 5.1.2. (Other		Sections 5.1.1 (IP Header Information) and 5.1.2 (Other Protocol
	Protocol Header Information) of [I-D.ietf-detnet-ip], respectively.		Header Information) of [RFC8939], respectively. "App-flow for MPLS"
	"App-Flow for MPLS" indicates that an individual DetNet IP flow is		indicates that an individual DetNet IP flow is the payload from the
	the payload from the perspective of the DetNet MPLS data plane		perspective of the DetNet MPLS data plane defined in [RFC8964].
	defined in [I-D.ietf-detnet-mpls].
	Per Section 5.1 of [I-D.ietf-detnet-mpls], the DetNet MPLS data plane		Per Section 5.1 of [RFC8964], the DetNet MPLS data plane uses a
	uses a single S-Label to support a single app flow. DetNet IP Flow		single S-Label to support a single App-flow. DetNet IP Flow
	Identification Procedures in Section 4.4 of [I-D.ietf-detnet-ip]		Identification Procedures in Section 5.1 of [RFC8939] states that a
	states that a single DetNet flow is identified based on IP, and next		single DetNet flow is identified based on IP- and next-level protocol
	level protocol, header information. Section 4.4. (Aggregation		header information. Section 4.4 of [RFC8939] (DetNet Flow
	Considerations) of [I-D.ietf-detnet-ip] defines the ways in which		Aggregation) defines the ways in which aggregation is supported
	aggregation is supported through the use of prefixes, wildcards,		through the use of prefixes, wildcards, lists, and port ranges.
	lists, and port ranges. Collectively, this results in the fairly		Collectively, this results in the fairly straightforward procedures
	straightforward procedures defined in the next section.		defined in the next section.
	As shown in Figure 2, DetNet relay nodes are responsible for the		As shown in Figure 2, DetNet relay nodes are responsible for the
	mapping of a DetNet flow, at the service sub-layer, from the IP to		mapping of a DetNet flow, at the service sub-layer, from the IP to
	MPLS DetNet data planes and back again. Their related DetNet IP over		MPLS DetNet data planes and back again. Their related DetNet IP over
	DetNet MPLS data plane operation is comprised of two sets of		DetNet MPLS data plane operation is comprised of two sets of
	procedures: the mapping of flow identifiers, and ensuring proper		procedures: the mapping of flow identifiers and ensuring proper
	traffic treatment.		traffic treatment.
	Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP		Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP
	flows. The six-tuple of IP is mapped to the S-Label in both cases.		flows. The six-tuple of IP is mapped to the S-Label in both cases.
	The various fields may be mapped or ignored when going from IP to		The various fields may be mapped or ignored when going from IP to
	MPLS.		MPLS.
	5. IP over DetNet MPLS Procedures		5. DetNet IP over DetNet MPLS Procedures
	The main differences of mapping IP to DetNet MPLS (compared to plain		The main differences of mapping IP to DetNet MPLS (compared to plain
	MPLS) are that (1) there is a mandatory flow identification to make		MPLS) are that (1) there is a mandatory flow identification to make
	the forwarding decision (i.e., forwarding is not based on FEC), (2)		the forwarding decision (i.e., forwarding is not based on FEC), (2)
	the d-CW (DetNet Control Word) is mandatory for the MPLS		the d-CW (DetNet Control Word) is mandatory for the MPLS
	encapsulation and (3) during forwarding over the DetNet MPLS network		encapsulation, and (3) during forwarding over the DetNet MPLS
	DetNet flow specific treatment is needed.		network, treatment specific to DetNet flows is needed.
	5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation		5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation
	Procedures		Procedures
	A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a		A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a
	DetNet MPLS network MUST map a DetNet IP flow, as identified in		DetNet MPLS network MUST map a DetNet IP flow, as identified in
	[I-D.ietf-detnet-ip] into a single MPLS DetNet flow and MUST process		[RFC8939], into a single MPLS DetNet flow and MUST process it in
	it in accordance to the procedures defined in [I-D.ietf-detnet-mpls].		accordance to the procedures defined in [RFC8964]. PRF MAY be
	PRF MAY be supported at the MPLS level for DetNet IP flows sent over		supported at the MPLS level for DetNet IP flows sent over a DetNet
	an DetNet MPLS network. Aggregation MAY be supported as defined in		MPLS network. Aggregation MAY be supported as defined in Section 4.4
	[I-D.ietf-detnet-mpls] Section 4.4. Aggregation considerations in		of [RFC8964]. Aggregation considerations in [RFC8939] MAY be used to
	[I-D.ietf-detnet-ip] MAY be used to identify an individual DetNet IP		identify an individual DetNet IP flow. The provisioning of the
	flow. The provisioning of the mapping of DetNet IP flows to DetNet		mapping of DetNet IP flows to DetNet MPLS flows MUST be supported via
	MPLS flows MUST be supported via configuration, e.g., via the		configuration, e.g., via the Controller Plane.
	controller plane.
	A DetNet relay node (egress T-PE) MAY be provisioned to handle		A DetNet relay node (egress T-PE) MAY be provisioned to handle
	packets received via the DetNet MPLS data plane as DetNet IP flows.		packets received via the DetNet MPLS data plane as DetNet IP flows.
	A single incoming DetNet MPLS flow MAY be treated as a single DetNet		A single incoming DetNet MPLS flow MAY be treated as a single DetNet
	IP flow, without examination of IP headers. Alternatively, packets		IP flow, without examination of IP headers. Alternatively, packets
	received via the DetNet MPLS data plane MAY follow the normal DetNet		received via the DetNet MPLS data plane MAY follow the normal DetNet
	IP flow identification procedures defined in [I-D.ietf-detnet-ip]		IP flow identification procedures defined in Section 5.1 of
	Section 5.1.		[RFC8939].
	An implementation MUST support the provisioning for handling any		An implementation MUST support the provisioning for handling any
	packet flows received via DetNet MPLS data plane as DetNet IP flows		packet flows received via the DetNet MPLS data plane as DetNet IP
	via configuration. Note that such configuration MAY include support		flows via configuration. Note that such configuration MAY include
	from PREOF on the incoming DetNet MPLS flow.		support from PREOF on the incoming DetNet MPLS flow.
	Note: using Layer-4 (L4) transport protocols e.g., for multipath are		| Note: Using Layer 4 (L4) transport protocols (e.g., for
	out of scope of this document both for a single flow and aggregate		| multipath) are out of scope of this document both for a single
	flows.		| flow and aggregate flows.
	5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures		5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures
	The traffic treatment required for a particular DetNet IP flow is		The traffic treatment required for a particular DetNet IP flow is
	provisioned via configuration or the controller plane. When a DetNet		provisioned via configuration or the Controller Plane. When a DetNet
	IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure		IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure
	that the provisioned DetNet IP traffic treatment is provided at the		that the provisioned DetNet IP traffic treatment is provided at the
	forwarding sub-layer as described in [I-D.ietf-detnet-mpls]		forwarding sub-layer as described in Section 5.2 of [RFC8964]. Note
	Section 5.2. Note that the PRF function MAY be utilized when sending		that PRF MAY be utilized when sending IP over MPLS.
	IP over MPLS.
	Traffic treatment for DetNet IP flows received over the DetNet MPLS		Traffic treatment for DetNet IP flows received over the DetNet MPLS
	data plane MUST follow Section 5.3 DetNet IP Traffic Treatment		data plane MUST follow Section 5.3 of [RFC8939] (DetNet IP Traffic
	Procedures in [I-D.ietf-detnet-ip].		Treatment Procedures).
	6. Management and Control Information Summary		6. Management and Control Information Summary
	The following summarizes the set of information that is needed to		The following summarizes the set of information that is needed to
	support DetNet IP over DetNet MPLS at the MPLS ingress node:		support DetNet IP over DetNet MPLS at the MPLS ingress node:
	o Each MPLS App-Flow is identified using the IP flow identification		* Each MPLS App-Flow is selected from the incoming IP traffic using
	information as defined in [I-D.ietf-detnet-ip]. The information		the IP flow identification information defined in [RFC8939]. This
	is summarized in Section 5.1 of that document, and includes all		information is summarized in Section 5.1 of that document and
	wildcards, port ranges and the ability to ignore specific IP		includes all wildcards, port ranges, and the ability to ignore
	fields.		specific IP fields.
	o The DetNet MPLS service that is to be used to send the matching IP		* The DetNet MPLS service that is to be used to send the matching IP
	traffic. This matching information is provided in		traffic. This matching information is provided in Section 5.1 of
	[I-D.ietf-detnet-mpls] Section 5.1, and includes both service and		[RFC8964] and includes both service and traffic delivery
	traffic delivery information.		information.
	The following summarizes the set of information that is needed to		The following summarizes the set of information that is needed to
	support DetNet IP over DetNet MPLS at the MPLS egress node:		support DetNet IP over DetNet MPLS at the MPLS egress node:
	o S-Label values that are carrying MPLS over IP encapsulated		* The S-Label value that identifies the encapsulated App-flow
	traffic.		traffic.
	o For each S-Label, how the received traffic is to be handled. The		* For each S-Label, how the received traffic is to be handled. The
	traffic may be processed according as any other DetNet IP traffic		traffic may be processed as any other DetNet IP traffic as defined
	as defined in this document or in [I-D.ietf-detnet-ip], or the		in this document or in [RFC8939], or the traffic may be directly
	traffic may be directly treated as an MPLS App-flow for additional		treated as an MPLS App-flow for additional processing according to
	processing according to [I-D.ietf-detnet-mpls].		[RFC8964].
	It is the responsibility of the DetNet controller plane to properly		It is the responsibility of the DetNet Controller Plane to properly
	provision both flow identification information and the flow-specific		provision both flow identification information and the flow-specific
	resources needed to provide the traffic treatment to meet each flow's		resources needed to provide the traffic treatment to meet each flow's
	service requirements. This applies for aggregated and individual		service requirements. This applies for aggregated and individual
	flows.		flows.
	7. Security Considerations		7. Security Considerations
	General security considerations for DetNet are described in detail in		General security considerations for DetNet are described in detail in
	[I-D.ietf-detnet-security]. DetNet MPLS and DetNet IP security		[RFC9055]. DetNet MPLS and DetNet IP security considerations equally
	considerations equally apply to this document and are described in		apply to this document and are described in [RFC8964] and [RFC8939].
	[I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip].
	Security aspects which are unique to DetNet are those whose aim is to		Security aspects that are unique to DetNet are those whose aim is to
	protect the support of specific quality of service aspects of DetNet,		protect the support of specific quality-of-service aspects of DetNet,
	which are primarily to deliver data flows with extremely low packet		which are primarily to deliver data flows with extremely low packet
	loss rates and bounded end-to-end delivery latency.		loss rates and bounded end-to-end delivery latency.
	The primary considerations for the data plane are to maintain		The primary considerations for the data plane are 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
	example, encryption may be used, such as that provided by IPSec		example, encryption may be used, such as that provided by IPsec
	[RFC4301] for IP flows and/or by an underlying sub-net using MACSec		[RFC4301] for IP flows and/or by an underlying sub-net using MACsec
	[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.		[IEEE802.1AE-2018] for IP-over-Ethernet (Layer 2) flows.
	From a data plane perspective this document does not add or modify		From a data plane perspective, this document does not add or modify
	any header information.		any header information.
	At the management and control level DetNet flows are identified on a		At the management and control level, DetNet flows are identified on a
	per-flow basis, which may provide controller plane attackers with		per-flow basis, which may provide Controller Plane attackers with
	additional information about the data flows (when compared to		additional information about the data flows (when compared to
	controller planes that do not include per-flow identification). This		Controller Planes that do not include per-flow identification). This
	is an inherent property of DetNet which has security implications		is an inherent property of DetNet, which has security implications
	that should be considered when determining if DetNet is a suitable		that should be considered when determining if DetNet is a suitable
	technology for any given use case.		technology for any given use case.
	To provide uninterrupted availability of the DetNet service,		To provide uninterrupted availability of the DetNet service,
	provisions can be made against DOS attacks and delay attacks. To		provisions can be made against DoS attacks and delay attacks. To
	protect against DOS attacks, excess traffic due to malicious or		protect against DoS attacks, excess traffic due to malicious or
	malfunctioning devices can be prevented or mitigated, for example		malfunctioning devices can be prevented or mitigated, for example,
	through the use of existing mechanism such as policing and shaping		through the use of existing mechanisms such as policing and shaping
	applied at the input of a DetNet domain. To prevent DetNet packets		applied at the input of a DetNet domain. To prevent DetNet packets
	from being delayed by an entity external to a DetNet domain, DetNet		from being delayed by an entity external to a DetNet domain, DetNet
	technology definition can allow for the mitigation of Man-In-The-		technology definitions can allow for the mitigation of man-in-the-
	Middle attacks, for example through use of authentication and		middle attacks (for example, through use of authentication and
	authorization of devices within the DetNet domain.		authorization of devices within the DetNet domain).
	8. IANA Considerations		8. IANA Considerations
	This document makes no IANA requests.		This document has no IANA actions.
	9. Acknowledgements
	The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
	David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
	Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
	Bernardos for their various contributions to this work.
	10. Contributors
	RFC7322 limits the number of authors listed on the front page of a
	draft to a maximum of 5. The editor wishes to thank and acknowledge
	the follow authors for contributing text to this draft.
	Janos Farkas
	Ericsson
	Email: janos.farkas@ericsson.com
	Andrew G. Malis
	Malis Consulting
	Email: agmalis@gmail.com
	Janos Farkas contributed substantially to the content of this
	document.
	11. References
	11.1. Normative references
	[I-D.ietf-detnet-data-plane-framework]
	Varga, B., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
	data-plane-framework-06 (work in progress), May 2020.
	[I-D.ietf-detnet-ip]
	Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
	Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07
	(work in progress), July 2020.
	[I-D.ietf-detnet-mpls]		9. References
	Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
	and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
	detnet-mpls-12 (work in progress), September 2020.
	[I-D.ietf-detnet-security]		9.1. Normative References
	Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
	Networking (DetNet) Security Considerations", draft-ietf-
	detnet-security-12 (work in progress), October 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,		[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", RFC 8655,		"Deterministic Networking Architecture", RFC 8655,
	DOI 10.17487/RFC8655, October 2019,		DOI 10.17487/RFC8655, October 2019,
	<https://www.rfc-editor.org/info/rfc8655>.		<https://www.rfc-editor.org/info/rfc8655>.
	11.2. Informative references		[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
			Bryant, "Deterministic Networking (DetNet) Data Plane
			Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
			<https://www.rfc-editor.org/info/rfc8938>.
			[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
			Bryant, "Deterministic Networking (DetNet) Data Plane:
			IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
			<https://www.rfc-editor.org/info/rfc8939>.
			[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
			S., and J. Korhonen, "Deterministic Networking (DetNet)
			Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
			2021, <https://www.rfc-editor.org/info/rfc8964>.
			[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
			"Deterministic Networking (DetNet) Security
			Considerations", RFC 9055, DOI 10.17487/RFC9055, June
			2021, <https://www.rfc-editor.org/info/rfc9055>.
			9.2. Informative References
	[IEEE802.1AE-2018]		[IEEE802.1AE-2018]
	IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC		IEEE, "IEEE Standard for Local and metropolitan area
	Security (MACsec)", 2018,		networks-Media Access Control (MAC) Security", IEEE
	<https://ieeexplore.ieee.org/document/8585421>.		802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
			2018, <https://ieeexplore.ieee.org/document/8585421>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
			Acknowledgements
			The authors wish to thank Pat Thaler, Norman Finn, Loa Andersson,
			David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
			Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, and Carlos
			J. Bernardos for their various contributions to this work.
			Contributors
			RFC 7322 limits the number of authors listed on the front page to a
			maximum of 5. The editor wishes to thank and acknowledge the
			following authors for contributing text to this document.
			János Farkas
			Ericsson
			Email: janos.farkas@ericsson.com
			Andrew G. Malis
			Malis Consulting
			Email: agmalis@gmail.com
			János Farkas contributed substantially to the content of this
			document.
	Authors' Addresses		Authors' Addresses
	Balazs Varga (editor)		Balázs Varga (editor)
	Ericsson		Ericsson
			Budapest
	Magyar Tudosok krt. 11.		Magyar Tudosok krt. 11.
	Budapest 1117		1117
	Hungary		Hungary
	Email: balazs.a.varga@ericsson.com		Email: balazs.a.varga@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		Don Fedyk
	skipping to change at page 13, line 4 ¶		skipping to change at line 542 ¶
	Lou Berger		Lou Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: lberger@labn.net		Email: lberger@labn.net
	Don Fedyk		Don Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: dfedyk@labn.net		Email: dfedyk@labn.net
	Stewart Bryant		Stewart Bryant
	Futurewei Technologies		Futurewei Technologies
	Email: stewart.bryant@gmail.com		Email: sb@stewartbryant.com
	Jouni Korhonen		Jouni Korhonen
	Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
End of changes. 90 change blocks.
	249 lines changed or deleted		243 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/