< draft-ietf-detnet-tsn-vpn-over-mpls-05.txt		draft-ietf-detnet-tsn-vpn-over-mpls-06.txt >
	DetNet B. Varga, Ed.		DetNet B. Varga, Ed.
	Internet-Draft J. Farkas		Internet-Draft J. Farkas
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: June 16, 2021 A. Malis		Expires: August 16, 2021 A. Malis
	Malis Consulting		Malis Consulting
	S. Bryant		S. Bryant
	Futurewei Technologies		Futurewei Technologies
	D. Fedyk		D. Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	December 13, 2020		February 12, 2021
	DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS		DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
	draft-ietf-detnet-tsn-vpn-over-mpls-05		draft-ietf-detnet-tsn-vpn-over-mpls-06
	Abstract		Abstract
	This document specifies the Deterministic Networking data plane when		This document specifies the Deterministic Networking data plane when
	TSN networks are interconnected over a DetNet MPLS Network.		TSN networks are interconnected over a DetNet MPLS Network.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 June 16, 2021.		This Internet-Draft will expire on August 16, 2021.
	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
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	1. Introduction		1. Introduction
	The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1		The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1
	Working Group deals with deterministic services through IEEE 802		Working Group deals with deterministic services through IEEE 802
	networks. Deterministic Networking (DetNet) defined by IETF is a		networks. Deterministic Networking (DetNet) defined by IETF is a
	service that can be offered by a L3 network to DetNet flows. General		service that can be offered by a L3 network to DetNet flows. General
	background and concepts of DetNet can be found in [RFC8655].		background and concepts of DetNet can be found in [RFC8655].
	This document specifies the use of a DetNet MPLS network to		This document specifies the use of a DetNet MPLS network to
	interconnect TSN nodes/network segments. DetNet MPLS data plane is		interconnect TSN nodes/network segments. DetNet MPLS data plane is
	defined in [I-D.ietf-detnet-mpls].		defined in [RFC8964].
	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 [RFC8938], and		DetNet architecture [RFC8655] and [RFC8938], and [RFC8964]. TSN
	[I-D.ietf-detnet-mpls]. The reader is assumed to be familiar with		specific terms are defined in the TSN TG of IEEE 802.1 Working Group.
	these documents and their terminology.		The reader is assumed to be familiar with these documents and their
			terminology.
	2.2. Abbreviations		2.2. Abbreviations
	The following abbreviations are used in this document:		The following abbreviations are used in this document:
	AC Attachment Circuit.		AC Attachment Circuit.
	CE Customer Edge equipment.		CE Customer Edge equipment.
	CW Control Word.		CW Control Word.
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	^ +--------+ +--------+ +--------+ ^		^ +--------+ +--------+ +--------+ ^
	| Edge Node Relay Node Edge Node |		| Edge Node Relay Node Edge Node |
	| (T-PE) (S-PE) (T-PE) |		| (T-PE) (S-PE) (T-PE) |
	| |		| |
	|<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->|		|<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->|
	| |		| |
	|<-------- Time Sensitive Networking (TSN) Service ------->|		|<-------- Time Sensitive Networking (TSN) Service ------->|
	X = Service protection		X = Service protection
	DFx = DetNet member flow x over a TE LSP		DFx = DetNet member flow x over a TE LSP
			AC = Attachment Circuit
			Tnl = Tunnel
	Figure 2: IEEE 802.1TSN Over DetNet		Figure 2: IEEE 802.1TSN Over DetNet
	4. DetNet MPLS Data Plane		4. DetNet MPLS Data Plane
	4.1. Overview		4.1. Overview
	The basic approach defined in [I-D.ietf-detnet-mpls] supports the		The basic approach defined in [RFC8964] supports the DetNet service
	DetNet service sub-layer based on existing pseudowire (PW)		sub-layer based on existing pseudowire (PW) encapsulations and
	encapsulations and mechanisms, and supports the DetNet forwarding		mechanisms, and supports the DetNet forwarding sub-layer based on
	sub-layer based on existing MPLS Traffic Engineering encapsulations		existing MPLS Traffic Engineering encapsulations and mechanisms.
	and mechanisms.
	A node operating on a DetNet flow in the Detnet service sub-layer,		A node operating on a DetNet flow in the Detnet service sub-layer,
	i.e. a node processing a DetNet packet which has the S-Label as top		i.e. a node processing a DetNet packet which has the S-Label as top
	of stack uses the local context associated with that S-Label, for		of stack uses the local context associated with that S-Label, for
	example a received F-Label, to determine what local DetNet		example a received F-Label, to determine what local DetNet
	operation(s) are applied to that packet. An S-Label may be unique		operation(s) are applied to that packet. An S-Label may be unique
	when taken from the platform label space [RFC3031], which would		when taken from the platform label space [RFC3031], which would
	enable correct DetNet flow identification regardless of which input		enable correct DetNet flow identification regardless of which input
	interface or LSP the packet arrives on. The service sub-layer		interface or LSP the packet arrives on. The service sub-layer
	functions (i.e., PREOF) use a DetNet control word (d-CW).		functions (i.e., PREOF) use a DetNet control word (d-CW).
	skipping to change at page 7, line 47 ¶		skipping to change at page 7, line 47 ¶
	| L2 |		| L2 |
	+------+		+------+
	(1) TSN Stream		(1) TSN Stream
	(2) DetNet MPLS Flow		(2) DetNet MPLS Flow
	Figure 3: Example TSN over MPLS Encapsulation Formats		Figure 3: Example TSN over MPLS Encapsulation Formats
	In the figure, "Application" indicates the application payload		In the figure, "Application" indicates the application payload
	carried by the TSN network. "MPLS App-Flow" indicates that the TSN		carried by the TSN network. "MPLS App-Flow" indicates that the TSN
	Stream is the payload from the perspective of the DetNet MPLS data		Stream is the payload from the perspective of the DetNet MPLS data
	plane defined in [I-D.ietf-detnet-mpls]. A single DetNet MPLS flow		plane defined in [RFC8964]. A single DetNet MPLS flow can aggregate
	can aggregate multiple TSN Streams.		multiple TSN Streams.
	5. TSN over MPLS Data Plane Procedures		5. TSN over MPLS Data Plane Procedures
	Description of Edge Nodes procedures and functions for TSN over		Description of Edge Nodes procedures and functions for TSN over
	DetNet MPLS scenario follows the concept of [RFC3985] and covers the		DetNet MPLS scenario follows the concept of [RFC3985] and covers the
	Edge Nodes components shown on Figure 1. In this section the		Edge Nodes components shown on Figure 1. In this section the
	following procedures of DetNet Edge Nodes are described:		following procedures of DetNet Edge Nodes are described:
	o TSN related (Section 5.1)		o TSN related (Section 5.1)
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]		bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]
	defines packet replication and elimination functions for a TSN		defines packet replication and elimination functions for a TSN
	network.		network.
	The implementation of TSN entity (i.e., TSN packet processing		The implementation of TSN entity (i.e., TSN packet processing
	functions) must be compliant with the relevant IEEE 802.1 standards.		functions) must be compliant with the relevant IEEE 802.1 standards.
	TSN specific functions are executed on the data received by the		TSN specific functions are executed on the data received by the
	DetNet Edge Node from the connected CE before forwarded to connected		DetNet Edge Node from the connected CE before forwarded to connected
	CE(s) or presentation to the DetNet Service Proxy function for		CE(s) or presentation to the DetNet Service Proxy function for
	transmission across the DetNet domain, or on the data received from a		transmission across the DetNet domain. TSN specific functions are
	DetNet PW by a PE before it is output on the Attachment Circuit(s)		also executed on the data received from a DetNet PW by a PE before
	(AC).		the data is output on the Attachment Circuit(s) (AC).
	TSN packet processing function(s) of Edge Nodes (T-PE) are belonging		TSN packet processing function(s) of Edge Nodes (T-PE) are belonging
	to the native service processing (NSP) [RFC3985] block. This is		to the native service processing (NSP) [RFC3985] block. This is
	similar to other functionalities being defined by standard bodies		similar to other functionalities being defined by standard bodies
	other than the IETF (for example in case of Ethernet: stripping,		other than the IETF (for example in case of Ethernet: stripping,
	overwriting or adding VLAN tags, etc.). Depending on the TSN role of		overwriting or adding VLAN tags, etc.). Depending on the TSN role of
	the Edge Node in the end-to-end TSN service selected TSN functions		the Edge Node in the end-to-end TSN service selected TSN functions
	are supported.		are supported.
	When a PE receives a packet from a CE, on a given AC with DetNet		When a PE receives a packet from a CE, on a given AC with DetNet
	service, it first checks via Stream Identification (see Clause 6. of		service, it first checks via Stream Identification (see Clause 6. of
	IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])		IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
	whether the packet belongs to a configured TSN Stream (i.e., App-flow		whether the packet belongs to a configured TSN Stream (i.e., App-flow
	from DetNet perspective). If no Stream ID is matched and no other		from DetNet perspective). If no Stream ID is matched and no other
	(VPN) service is configured for the AC then packet MUST be dropped.		(VPN) service is configured for the AC, then packet MUST be dropped.
	If there is a matching TSN Stream then the Stream-ID specific TSN		If there is a matching TSN Stream, then the Stream ID specific TSN
	functions are executed (e.g., ingress policing, header field		functions are executed (e.g., ingress policing, header field
	manipulation in case of active Stream Identification, FRER, etc.).		manipulation in case of active Stream Identification, FRER, etc.).
	Source MAC lookup may also be used for local MAC address learning.		Source MAC lookup may also be used for local MAC address learning.
	If the PE decides to forward the packet, the packet MUST be forwarded		If the PE decides to forward the packet, the packet MUST be forwarded
	according to the TSN Stream specific configuration to connected CE(s)		according to the TSN Stream specific configuration to connected CE(s)
	(in case of local bridging) and/or to the DetNet Service Proxy (in		(in case of local bridging) and/or to the DetNet Service Proxy (in
	case of forwarding to remote CE(s) required). If there are no TSN		case of forwarding to remote CE(s)). If there are no TSN Stream
	Stream specific forwarding configurations the PE MUST flood the		specific forwarding configurations, the PE MUST flood the packet to
	packet to other locally attached CE(s) and to the DetNet Service		other locally attached CE(s) and to the DetNet Service Proxy. If the
	Proxy. If the administrative policy on the PE does not allow		administrative policy on the PE does not allow flooding, the PE MUST
	flooding the PE MUST drop the packet.		drop the packet.
	When a TSN entity of the PE receives a packet from the DetNet Service		When a TSN entity of the PE receives a packet from the DetNet Service
	Proxy, it first checks via Stream Identification (see Clause 6. of		Proxy, it first checks via Stream Identification (see Clause 6. of
	IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])		IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
	whether the packet belongs to a configured TSN Stream. If no Stream		whether the packet belongs to a configured TSN Stream. If no Stream
	ID is matched then packet is dropped. If there is a matching TSN		ID is matched, then packet is dropped. If there is a matching TSN
	Stream then the Stream ID specific TSN functions are executed (e.g.,		Stream, then the Stream ID specific TSN functions are executed (e.g.,
	header field manipulation in case of active Stream Identification,		header field manipulation in case of active Stream Identification,
	FRER, etc.). Source MAC lookup may also be used for local MAC		FRER, etc.). Source MAC lookup may also be used for local MAC
	address learning.		address learning.
	If the PE decides to forward the packet, the packet is forwarded		If the PE decides to forward the packet, the packet is forwarded
	according to the TSN Stream specific configuration to connected		according to the TSN Stream specific configuration to connected
	CE(s). If there are no TSN Stream specific forwarding configurations		CE(s). If there are no TSN Stream specific forwarding
	the PE floods the packet to locally attached CE(s). If the		configurations, the PE floods the packet to locally attached CE(s).
	administrative policy on the PE does not allow flooding the PE drops		If the administrative policy on the PE does not allow flooding, the
	the packet.		PE drops the packet.
	Implementations of this document SHALL use management and control		Implementations of this document SHALL use management and control
	information to ensure TSN specific functions of the Edge Node		information to ensure TSN specific functions of the Edge Node
	according to the expectations of the connected TSN network.		according to the expectations of the connected TSN network.
	5.2. Edge Node DetNet Service Proxy Procedures		5.2. Edge Node DetNet Service Proxy Procedures
	The Service Proxy function maps between App-flows and DetNet flows.		The Service Proxy function maps between App-flows and DetNet flows.
	The DetNet Edge Node TSN entity MUST support the TSN Stream		The DetNet Edge Node TSN entity MUST support the TSN Stream
	identification functions and the related managed objects as defined		identification functions and the related managed objects as defined
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 32 ¶
	Due to the (intentional) similarities of the DetNet PREOF and TSN		Due to the (intentional) similarities of the DetNet PREOF and TSN
	FRER functions service protection function interworking is possible		FRER functions service protection function interworking is possible
	between the TSN and the DetNet domains. Such service protection		between the TSN and the DetNet domains. Such service protection
	interworking scenarios MAY require to copy sequence number fields		interworking scenarios MAY require to copy sequence number fields
	from TSN (L2) to PW (MPLS) encapsulation. However, such interworking		from TSN (L2) to PW (MPLS) encapsulation. However, such interworking
	is out-of-scope in this document and left for further study.		is out-of-scope in this document and left for further study.
	5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures		5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures
	In the design of [I-D.ietf-detnet-mpls] an MPLS service label (the		In the design of [RFC8964] an MPLS service label (the S-Label),
	S-Label), similar to a pseudowire (PW) label [RFC3985], is used to		similar to a pseudowire (PW) label [RFC3985], is used to identify
	identify both the DetNet flow identity and the payload MPLS payload		both the DetNet flow identity and the payload MPLS payload type. The
	type. The DetNet sequence number is carried in the DetNet Control		DetNet sequence number is carried in the DetNet Control word (d-CW)
	word (d-CW) which carries the Data/OAM discriminator as well. In		which carries the Data/OAM discriminator as well. In [RFC8964] two
	[I-D.ietf-detnet-mpls] two sequence number sizes are supported: a 16		sequence number sizes are supported: a 16 bit sequence number and a
	bit sequence number and a 28 bit sequence number.		28 bit sequence number.
	PREOF functions and the provided service recovery is available only		PREOF functions and the provided service recovery is available only
	within the DetNet domain as the DetNet flow-ID and the DetNet		within the DetNet domain as the DetNet flow-ID and the DetNet
	sequence number are not valid outside the DetNet network. MPLS		sequence number are not valid outside the DetNet network. MPLS
	(DetNet) Edge node terminates all related information elements		(DetNet) Edge node terminates all related information elements
	encoded in the MPLS labels.		encoded in the MPLS labels.
	When a PE receives a packet from the Service Proxy function it MUST		When a PE receives a packet from the Service Proxy function it MUST
	handle the packet as defined in [I-D.ietf-detnet-mpls].		handle the packet as defined in [RFC8964].
	When a PE receives an MPLS packet from a remote PE, then, after		When a PE receives an MPLS packet from a remote PE, then, after
	processing the MPLS label stack, if the top MPLS label ends up being		processing the MPLS label stack, if the top MPLS label ends up being
	a DetNet S-label that was advertised by this node, then the PE MUST		a DetNet S-label that was advertised by this node, then the PE MUST
	forward the packet according to the configured DetNet Service and		forward the packet according to the configured DetNet Service and
	Forwarding sub-layer rules to other PE nodes or via the Detnet		Forwarding sub-layer rules to other PE nodes or via the Detnet
	Service Proxy function towards locally connected CE(s).		Service Proxy function towards locally connected CE(s).
	For further details on DetNet Service and Forwarding sub-layers see		For further details on DetNet Service and Forwarding sub-layers see
	[I-D.ietf-detnet-mpls].		[RFC8964].
	6. Controller Plane (Management and Control) Considerations		6. Controller Plane (Management and Control) Considerations
	TSN Stream(s) to DetNet flow mapping related information are required		TSN Stream(s) to DetNet flow mapping related information are required
	only for the service proxy function of MPLS (DetNet) Edge nodes.		only for the service proxy function of MPLS (DetNet) Edge nodes.
	From the Data Plane perspective there is no practical difference		From the Data Plane perspective there is no practical difference
	based on the origin of flow mapping related information (management		based on the origin of flow mapping related information (management
	plane or control plane).		plane or control plane).
	The following summarizes the set of information that is needed to		The following summarizes the set of information that is needed to
	configure TSN over DetNet MPLS:		configure TSN over DetNet MPLS:
	o TSN related configuration information according to the TSN role of		o TSN related configuration information according to the TSN role of
	the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and		the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and
	[IEEEP8021CBdb].		[IEEEP8021CBdb].
	o DetNet MPLS related configuration information according to the		o DetNet MPLS related configuration information according to the
	DetNet role of the DetNet MPLS node, as per		DetNet role of the DetNet MPLS node, as per [RFC8964].
	[I-D.ietf-detnet-mpls].
	o App-Flow identification information to map received TSN Stream(s)		o App-Flow identification information to map received TSN Stream(s)
	to the DetNet flow. Parameters of TSN stream identification are		to the DetNet flow. Parameters of TSN stream identification are
	defined in [IEEE8021CB] and [IEEEP8021CBdb].		defined in [IEEE8021CB] and [IEEEP8021CBdb].
	This information MUST be provisioned per DetNet flow.		This information MUST be provisioned per DetNet flow.
	Mappings between DetNet and TSN management and control planes are out		Mappings between DetNet and TSN management and control planes are out
	of scope of the document. Some of the challanges are highligthed		of scope of the document. Some of the challanges are highligthed
	below.		below.
	skipping to change at page 12, line 44 ¶		skipping to change at page 12, line 43 ¶
	the DetNet domain. Service protection interworking scenarios are		the DetNet domain. Service protection interworking scenarios are
	left for further study.		left for further study.
	7. Security Considerations		7. 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 [RFC8655].		described in [RFC8655].
	DetNet MPLS data plane specific considerations are summarized and		DetNet MPLS data plane specific considerations are summarized and
	described in [I-D.ietf-detnet-mpls] including any application flow		described in [RFC8964] including any application flow types. This
	types. This document focuses on the scenario where TSN Streams are		document focuses on the scenario where TSN Streams are the
	the application flows for DetNet and it is already covered by those		application flows for DetNet and it is already covered by those
	DetNet MPLS data plane security considerations.		DetNet MPLS data plane security considerations.
	8. IANA Considerations		8. IANA Considerations
	This document makes no IANA requests.		This document makes no IANA requests.
	9. Acknowledgements		9. Acknowledgements
	The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,		The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
	Christophe Mangin and Jouni Korhonen for their various contributions		Christophe Mangin and Jouni Korhonen for their various contributions
	to this work.		to this work.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-detnet-mpls]
	Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
	and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
	detnet-mpls-13 (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>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
	[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>.
			[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>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-detnet-security]		[I-D.ietf-detnet-security]
	Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic		Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
	Networking (DetNet) Security Considerations", draft-ietf-		Networking (DetNet) Security Considerations", draft-ietf-
	detnet-security-12 (work in progress), October 2020.		detnet-security-13 (work in progress), December 2020.
	[IEEE8021CB]		[IEEE8021CB]
	IEEE 802.1, "Standard for Local and metropolitan area		IEEE 802.1, "Standard for Local and metropolitan area
	networks - Frame Replication and Elimination for		networks - Frame Replication and Elimination for
	Reliability (IEEE Std 802.1CB-2017)", 2017,		Reliability (IEEE Std 802.1CB-2017)", 2017,
	<http://standards.ieee.org/about/get/>.		<http://standards.ieee.org/about/get/>.
	[IEEE8021Q]		[IEEE8021Q]
	IEEE 802.1, "Standard for Local and metropolitan area		IEEE 802.1, "Standard for Local and metropolitan area
	networks--Bridges and Bridged Networks (IEEE Std 802.1Q-		networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
	skipping to change at page 14, line 21 ¶		skipping to change at page 14, line 21 ¶
	Mangin, C., "Extended Stream identification functions",		Mangin, C., "Extended Stream identification functions",
	IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020,		IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020,
	<http://www.ieee802.org/1/files/private/db-drafts/d1/802-		<http://www.ieee802.org/1/files/private/db-drafts/d1/802-
	1CBdb-d1-0.pdf>.		1CBdb-d1-0.pdf>.
	[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation		[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
	Edge-to-Edge (PWE3) Architecture", RFC 3985,		Edge-to-Edge (PWE3) Architecture", RFC 3985,
	DOI 10.17487/RFC3985, March 2005,		DOI 10.17487/RFC3985, March 2005,
	<https://www.rfc-editor.org/info/rfc3985>.		<https://www.rfc-editor.org/info/rfc3985>.
	[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
	L., and L. Berger, "A Framework for MPLS in Transport
	Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
	<https://www.rfc-editor.org/info/rfc5921>.
	[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>.
	[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
	Decraene, B., Litkowski, S., and R. Shakir, "Segment
	Routing with the MPLS Data Plane", RFC 8660,
	DOI 10.17487/RFC8660, December 2019,
	<https://www.rfc-editor.org/info/rfc8660>.
	[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.		[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, "Deterministic Networking (DetNet) Data Plane		Bryant, "Deterministic Networking (DetNet) Data Plane
	Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,		Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
	<https://www.rfc-editor.org/info/rfc8938>.		<https://www.rfc-editor.org/info/rfc8938>.
	Authors' Addresses		Authors' Addresses
	Balazs Varga (editor)		Balazs Varga (editor)
	Ericsson		Ericsson
	Magyar Tudosok krt. 11.		Magyar Tudosok krt. 11.
End of changes. 25 change blocks.
	63 lines changed or deleted		53 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/