draft-ietf-detnet-mpls-over-udp-ip-00.txt		draft-ietf-detnet-mpls-over-udp-ip-01.txt
	DetNet B. Varga, Ed.		DetNet B. Varga, Ed.
	Internet-Draft J. Farkas		Internet-Draft J. Farkas
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: November 6, 2019 L. Berger		Expires: January 2, 2020 L. Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	A. Malis		A. Malis
	S. Bryant		S. Bryant
	Huawei Technologies		Futurewei Technologies
	J. Korhonen		J. Korhonen
	May 5, 2019		July 1, 2019
	DetNet Data Plane: MPLS over IP		DetNet Data Plane: MPLS over UDP/IP
	draft-ietf-detnet-mpls-over-udp-ip-00		draft-ietf-detnet-mpls-over-udp-ip-01
	Abstract		Abstract
	This document specifies the MPLS Deterministic Networking data plane		This document specifies the MPLS Deterministic Networking data plane
	operation and encapsulation over an IP network. The approach is		operation and encapsulation over an IP network. The approach is
	modeled on the operation of MPLS and PseudoWires (PW) over IP.		modeled on the operation of MPLS and over UDP/IP packet switched
			networks.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 6, 2019.		This Internet-Draft will expire on January 2, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 16 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3		2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
	3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
	4. DetNet MPLS Operation over DetNet		3. DetNet MPLS Operation over DetNet
	IP PSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		IP PSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. DetNet Data Plane Procedures . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. Management and Control Information Summary . . . . . . . . . 6
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 7
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Deterministic Networking (DetNet) is a service that can be offered by		Deterministic Networking (DetNet) is a service that can be offered by
	a network to DetNet flows. DetNet provides these flows with a low		a network to DetNet flows. DetNet provides these flows with a low
	packet loss rates and assured maximum end-to-end delivery latency.		packet loss rates and assured maximum end-to-end delivery latency.
	General background and concepts of DetNet can be found in		General background and concepts of DetNet can be found in
	[I-D.ietf-detnet-architecture].		[I-D.ietf-detnet-architecture].
	The DetNet Architecture decomposes the DetNet related data plane
	functions into two sub-layers: a service sub-layer and a forwarding
	sub-layer. The service sub-layer is used to provide DetNet service
	protection and reordering. The forwarding sub-layer is used to
	provides congestion protection (low loss, assured latency, and
	limited reordering) leveraging MPLS Traffic Engineering mechanisms.
	This document specifies use of the MPLS DetNet encapsulation over an		This document specifies use of the MPLS DetNet encapsulation over an
	IP network. The approach is modeled on the operation of MPLS and		IP network. The approach is modeled on the operation of MPLS over an
	PseudoWires (PW) over an IP Packet Switched Network (PSN)		IP Packet Switched Network (PSN) [RFC7510]. It maps the MPLS data
	[RFC3985][RFC4385][RFC7510]. It maps the MPLS data plane		plane encapsulation described in [I-D.ietf-detnet-mpls] to the DetNet
	encapsulation described in [I-D.ietf-detnet-mpls] to the DetNet IP		IP data plane defined in [I-D.ietf-detnet-ip].
	data plane defined in [I-D.ietf-detnet-ip].
	To carry DetNet with full functionality at the DetNet layer over an		To carry DetNet flows with full functionality at the DetNet layer
	IP network, the following components are required (these are a subset		over an IP network, the following components are required (these are
	of the requirements for MPLS encapsulation listed in		a subset of the requirements for MPLS encapsulation listed in
	[I-D.ietf-detnet-mpls]):		[I-D.ietf-detnet-mpls]):
	1. A method of identifying the DetNet flow group to the processing		1. A method of identifying the DetNet flow group to the processing
	element.		element.
	2. A method of carrying the DetNet sequence number.		2. A method of carrying the DetNet sequence number.
	3. A method of distinguishing DetNet OAM packets from DetNet data		3. A method of distinguishing DetNet OAM packets from DetNet data
	packets.		packets.
	4. A method of carrying queuing and forwarding indication.		4. A method of carrying queuing and forwarding indication.
	These requirements are satisfied by the DetNet over MPLS		These requirements are satisfied by the DetNet over MPLS
	Encapsulation described in [I-D.ietf-detnet-mpls].		Encapsulation described in [I-D.ietf-detnet-mpls] and they are partly
			satisfied by the DetNet IP data plane defined in [I-D.ietf-detnet-ip]
	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 [I-D.ietf-detnet-architecture], and the reader is
	assumed to be familiar with that document and its terminology.		assumed to be familiar with 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:
	CW Control Word.
	d-CW A DetNet Control Word (d-CW) is used for sequencing and		d-CW A DetNet Control Word (d-CW) is used for sequencing and
	identifying duplicate packets of a DetNet flow at the		identifying duplicate packets of a DetNet flow at the
	DetNet service sub-layer.		DetNet service sub-layer.
	DetNet Deterministic Networking.		DetNet Deterministic Networking.
			A-Label A special case of an S-Label, whose properties are
			known only at the aggregation and deaggregation end-
			points.
	F-Label A Detnet "forwarding" label that identifies the LSP		F-Label A Detnet "forwarding" label that identifies the LSP
	used to forward a DetNet flow across an MPLS PSN, e.g.,		used to forward a DetNet flow across an MPLS PSN, e.g.,
	a hop-by-hop label used between label switching routers		a hop-by-hop label used between label switching
	(LSR).		routers.
	LSR Label Switching Router.
	MPLS Multiprotocol Label Switching.		MPLS Multiprotocol Label Switching.
	OAM Operations, Administration, and Maintenance.		OAM Operations, Administration, and Maintenance.
	PEF Packet Elimination Function.		PEF Packet Elimination Function.
	PRF Packet Replication Function.
	PREOF Packet Replication, Elimination and Ordering Functions.
	POF Packet Ordering Function.		POF Packet Ordering Function.
	PSN Packet Switched Network.		PRF Packet Replication Function.
	PW PseudoWire.		PSN Packet Switched Network.
	S-Label A DetNet "service" label that is used between DetNet		S-Label A DetNet "service" label that is used between DetNet
	nodes that implement also the DetNet service sub-layer		nodes that implement also the DetNet service sub-layer
	functions. An S-Label is also used to identify a		functions. An S-Label is also used to identify a
	DetNet flow at DetNet service sub-layer.		DetNet flow at DetNet service sub-layer.
	3. Requirements Language		2.3. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	4. DetNet MPLS Operation over DetNet IP PSNs		3. DetNet MPLS Operation over DetNet IP PSNs
	This document builds on the specification of MPLS over UDP and IP		This document builds on the specification of MPLS over UDP defined in
	defined in [RFC7510]. It replaces the F-Label(s) used in		[RFC7510]. It may replace partly or entirely the F-Label(s) used in
	[I-D.ietf-detnet-mpls] with UDP and IP headers. The UDP and IP		[I-D.ietf-detnet-mpls] with UDP and IP headers. The UDP and IP
	header information is used to identify DetNet flows, including member		header information is used to identify DetNet flows, including member
	flows, per [I-D.ietf-detnet-ip]. The resulting encapsulation is		flows, per [I-D.ietf-detnet-ip]. The resulting encapsulation is
	shown in Figure 1.		shown in Figure 1. There may be zero or more F-label(s) between the
			S-label and the UDP header.
	Note that this encapsulation works equally well with IPv4, IPv6, and		Note that this encapsulation works equally well with IPv4, IPv6, and
	IPv6-based Segment Routing [I-D.ietf-6man-segment-routing-header].		IPv6-based Segment Routing [I-D.ietf-6man-segment-routing-header].
	+---------------------------------+		+---------------------------------+
	| |		| |
	| DetNet App-Flow |		| DetNet App-Flow |
	| Payload Packet |		| Payload Packet |
	| |		| |
	+---------------------------------+ <--\		+---------------------------------+ <--\
	| DetNet Control Word | |		| DetNet Control Word | |
	+---------------------------------+ +--> DetNet data plane		+---------------------------------+ +--> DetNet data plane
	| S-Label | | MPLS encapsulation		| S-Label | | MPLS encapsulation
			+---------------------------------+ |
			| [ F-label(s) ] | |
	+---------------------------------+ <--+		+---------------------------------+ <--+
	| UDP Header | |		| UDP Header | |
	+---------------------------------+ +--> DetNet data plane		+---------------------------------+ +--> DetNet data plane
	| IP Header | | IP encapsulation		| IP Header | | IP encapsulation
	+---------------------------------+ <--/		+---------------------------------+ <--/
	| Data-Link |		| Data-Link |
	+---------------------------------+		+---------------------------------+
	| Physical |		| Physical |
	+---------------------------------+		+---------------------------------+
	Figure 1: IP Encapsulation of DetNet MPLS		Figure 1: UDP/IP Encapsulation of DetNet MPLS
	d-CW and and S-Labels are used as defined in [I-D.ietf-detnet-mpls]
	and are not modified by this document.
	To support outgoing DetNet MPLS over IP, an implementation MUST		d-CW, S-Labels and zero or more F-Labels are used as defined in
	support the provisioning of IP/UDP header information in place of		[I-D.ietf-detnet-mpls] and are not modified by this document. In
	sets of F-Labels. Note that multiple sets of F-Labels can be		case of aggregates the A-Label is treated as an S-Label and it too is
	provisioned to support PRF on transmitted DetNet flows and therefore,		not modified.
	when PRF is supported, multiple IP/UDP headers MAY be provisioned.
	When multiple IP/UDP headers are provisioned for a particular
	outgoing app-flow, a copy of the outgoing packet, including the
	pushed S-Label, MUST be made for each. The headers for each outgoing
	packet MUST be based on the configuration information and as defined
	in [RFC7510], with one exception. The one exception is that the UDP
	Source Port value MUST be set to uniquely identify the DetNet
	(forwarding sub-layer) flow. The packet MUST then be handed as a
	DetNet IP packet, per [I-D.ietf-detnet-ip].
	To support receive processing an implementation MUST also support the		4. DetNet Data Plane Procedures
	provisioning of received IP/UDP header information. When S-Labels
	are taken from platform label space, all that is required is to
	provision that receiving IP/UDP encapsulated DetNet MPLS packets is
	permitted. Once the IP/UDP header is stripped, the S-label uniquely
	identifies the app-flow. When S-Labels are not taken from platform
	label space, IP/UDP header information MUST be provisioned. The
	provisioned information MUST then be used to identify incoming app-
	flows based on the combination of S-Label and incoming IP/UDP header.
	Normal receive processing, including PEOF can then take place.
	5. Security Considerations		To support outgoing DetNet MPLS over UDP/IP encapsulation, an
			implementation MUST support the provisioning of UDP and IP header
			information in addition or in place of F-Label(s). Note, when PRF is
			performed at the MPLS service sub-layer, there will be multiple
			member flows, and each member flow will require the provisioning of
			their own UDP and IP header information. The headers for each
			outgoing packet MUST be formatted on the configuration information
			and as defined in [RFC7510], with one exception. Note that the UDP
			Source Port value MUST be set to uniquely identify the DetNet flow.
			The packet MUST then be handed as a DetNet IP packet, per
			[I-D.ietf-detnet-ip]. This includes QoS related traffic treatment.
	The security considerations of DetNet in general are discussed in		To support receive processing an implementation MUST also support the
	[I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other		provisioning of received UDP and IP header information. The
	security considerations will be added in a future version of this		provisioned information MUST be used to identify incoming app-flows
	draft.		based on the combination of S-Label and incoming encapsulation header
			information. Normal receive processing as defined in
			[I-D.ietf-detnet-mpls], including PEF and POF, can then take place.
	6. IANA Considerations		5. Management and Control Information Summary
	This document makes no IANA requests.		The following summarizes the set of information that is needed to
			configure DetNet MPLS over UDP/IP:
	7. Contributors		o Label information (S-label or F-label) to be mapped to UDP/IP
			flow. Note that a single S-Label can map to multiple sets of UPD/
			IP information when PREOF is used.
	RFC7322 limits the number of authors listed on the front page of a		o IPv4 and IPv6 source address field.
	draft to a maximum of 5, far fewer than the many individuals below
	who made important contributions to this draft. The editor wishes to
	thank and acknowledge each of the following authors for contributing
	text to this draft. See also Section 8.
	Loa Andersson		o IPv4 and IPv6 destination address field.
	Huawei
	Email: loa@pi.nu
	Yuanlong Jiang		o IPv4 Type of Service and IPv6 Traffic Class Fields.
	Huawei
	Email: jiangyuanlong@huawei.com
	Norman Finn		o UDP Source Port.
	Huawei
	3101 Rio Way
	Spring Valley, CA 91977
	USA
	Email: norman.finn@mail01.huawei.com
	Janos Farkas		o UDP Destination Port.
	Ericsson
	Magyar Tudosok krt. 11.
	Budapest 1117
	Hungary
	Email: janos.farkas@ericsson.com
	Carlos J. Bernardos		This information MUST be provisioned per DetNet flow via
	Universidad Carlos III de Madrid		configuration, e.g., via the controller or management plane.
	Av. Universidad, 30
	Leganes, Madrid 28911
	Spain
	Email: cjbc@it.uc3m.es
	Tal Mizrahi		It is the responsibility of the DetNet controller plane to properly
	Marvell		provision both flow identification information and the flow specific
	6 Hamada st.		resources needed to provided the traffic treatment needed to meet
	Yokneam		each flow's service requirements. This applies for aggregated and
	Israel		individual flows.
	Email: talmi@marvell.com
	Lou Berger		6. Security Considerations
	LabN Consulting, L.L.C.
	Email: lberger@labn.net
	Stewart Bryant		The security considerations of DetNet in general are discussed in
	Huawei Technologies		[I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. MPLS
	Email: stewart.bryant@gmail.com		and IP specific security considerations are described in
			[I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip]. This draft does not
			have additional security considerations.
	Mach Chen		7. IANA Considerations
	Huawei Technologies
	Email: mach.chen@huawei.com
	Andrew G. Malis		This document makes no IANA requests.
	Huawei Technologies
	Email: agmalis@gmail.com
	8. Acknowledgements		8. Acknowledgements
	The author(s) ACK and NACK.		The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
			David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
	The following people were part of the DetNet Data Plane Solution		Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
	Design Team:		Bernardos for their various contributions to this work.
	Jouni Korhonen
	Janos Farkas
	Norman Finn
	Balazs Varga
	Loa Andersson
	Tal Mizrahi
	David Mozes
	Yuanlong Jiang
	Andrew Malis
	Carlos J. Bernardos
	The DetNet chairs serving during the DetNet Data Plane Solution
	Design Team:
	Lou Berger
	Pat Thaler
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-detnet-ip]		[I-D.ietf-detnet-ip]
	Korhonen, J., Varga, B., "DetNet IP", 2019.		Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
			Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
			draft-ietf-detnet-ip-00 (work in progress), May 2019.
	[I-D.ietf-detnet-mpls]		[I-D.ietf-detnet-mpls]
	Korhonen, J., Varga, B., "DetNet MPLS", 2019.		Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
			Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
			draft-ietf-detnet-mpls-00 (work in progress), May 2019.
	[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>.
	[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
	Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
	February 2006, <https://www.rfc-editor.org/info/rfc4385>.
	[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,		[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
	"Encapsulating MPLS in UDP", RFC 7510,		"Encapsulating MPLS in UDP", RFC 7510,
	DOI 10.17487/RFC7510, April 2015,		DOI 10.17487/RFC7510, April 2015,
	<https://www.rfc-editor.org/info/rfc7510>.		<https://www.rfc-editor.org/info/rfc7510>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-6man-segment-routing-header]		[I-D.ietf-6man-segment-routing-header]
	Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and		Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
	d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header		Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
	(SRH)", draft-ietf-6man-segment-routing-header-18 (work in		Routing Header (SRH)", draft-ietf-6man-segment-routing-
	progress), April 2019.		header-21 (work in progress), June 2019.
	[I-D.ietf-detnet-architecture]		[I-D.ietf-detnet-architecture]
	Finn, N., Thubert, P., Varga, B., and J. Farkas,		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", draft-ietf-		"Deterministic Networking Architecture", draft-ietf-
	detnet-architecture-12 (work in progress), March 2019.		detnet-architecture-13 (work in progress), May 2019.
	[I-D.sdt-detnet-security]
	Mizrahi, T., Grossman, E., Hacker, A., Das, S.,
	"Deterministic Networking (DetNet) Security
	Considerations, draft-sdt-detnet-security, work in
	progress", 2017.
	[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation		[I-D.ietf-detnet-security]
	Edge-to-Edge (PWE3) Architecture", RFC 3985,		Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
	DOI 10.17487/RFC3985, March 2005,		J., Austad, H., Stanton, K., and N. Finn, "Deterministic
	<https://www.rfc-editor.org/info/rfc3985>.		Networking (DetNet) Security Considerations", draft-ietf-
			detnet-security-04 (work in progress), March 2019.
	Authors' Addresses		Authors' Addresses
	Balazs Varga (editor)		Balazs Varga (editor)
	Ericsson		Ericsson
	Magyar Tudosok krt. 11.		Magyar Tudosok krt. 11.
	Budapest 1117		Budapest 1117
	Hungary		Hungary
	Email: balazs.a.varga@ericsson.com		Email: balazs.a.varga@ericsson.com
	skipping to change at page 9, line 45 ¶		skipping to change at page 8, line 35 ¶
	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
	Andrew G. Malis		Andrew G. Malis
	Huawei Technologies		Futurewei Technologies
	Email: agmalis@gmail.com		Email: agmalis@gmail.com
	Stewart Bryant		Stewart Bryant
	Huawei Technologies		Futurewei Technologies
	Email: stewart.bryant@gmail.com		Email: stewart.bryant@gmail.com
	Jouni Korhonen		Jouni Korhonen
	Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
End of changes. 52 change blocks.
	186 lines changed or deleted		116 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/