draft-ietf-detnet-problem-statement-07.txt		draft-ietf-detnet-problem-statement-08.txt
	DetNet N. Finn		DetNet N. Finn
	Internet-Draft Huawei Technologies Co. Ltd		Internet-Draft Huawei Technologies Co. Ltd
	Intended status: Informational P. Thubert		Intended status: Informational P. Thubert
	Expires: April 6, 2019 Cisco		Expires: June 9, 2019 Cisco
	October 3, 2018		December 6, 2018
	Deterministic Networking Problem Statement		Deterministic Networking Problem Statement
	draft-ietf-detnet-problem-statement-07		draft-ietf-detnet-problem-statement-08
	Abstract		Abstract
	This paper documents the needs in various industries to establish		This paper documents the needs in various industries to establish
	multi-hop paths for characterized flows with deterministic		multi-hop paths for characterized flows with deterministic
	properties.		properties.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 6, 2019.		This Internet-Draft will expire on June 9, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 47 ¶		skipping to change at page 2, line 47 ¶
	LAN boundaries. For instance, IACS segregates the network along the		LAN boundaries. For instance, IACS segregates the network along the
	broad lines of the Purdue Enterprise Reference Architecture (PERA)		broad lines of the Purdue Enterprise Reference Architecture (PERA)
	[ISA95], typically using deterministic local area networks for level		[ISA95], typically using deterministic local area networks for level
	2 control systems, whereas public infrastructures such as Electricity		2 control systems, whereas public infrastructures such as Electricity
	Automation require deterministic properties over the Wide Area. The		Automation require deterministic properties over the Wide Area. The
	realization is now coming that the convergence of IT and Operational		realization is now coming that the convergence of IT and Operational
	Technology (OT) networks requires Layer-3, as well as Layer-2,		Technology (OT) networks requires Layer-3, as well as Layer-2,
	capabilities.		capabilities.
	While the initial user base has focused almost entirely on Ethernet		While the initial user base has focused almost entirely on Ethernet
	physical media and Ethernet-based bridging protocol (from several		physical media and Ethernet-based bridging protocol from several
	Standards Development Organizations), the need for Layer-3 expressed		Standards Development Organizations, the need for Layer-3 expressed
	above, must not be confined to Ethernet and Ethernet-like media, and		above, must not be confined to Ethernet and Ethernet-like media.
	while such media must be encompassed by any useful Deterministic		While such media must be encompassed by any useful Deterministic
	Networking (DetNet) Architecture, cooperation between IETF and other		Networking (DetNet) Architecture, cooperation between IETF and other
	SDOs must not be limited to IEEE or IEEE 802. Furthermore, while the		SDOs must not be limited to IEEE or IEEE 802. Furthermore, while the
	work completed and ongoing in other SDOs, and in IEEE 802 in		work completed and ongoing in other SDOs, and in IEEE 802 in
	particular, provide an obvious starting point for a DetNet		particular, provide an obvious starting point for a DetNet
	architecture, we must not assume that these other SDOs' work confines		architecture, we must not assume that these other SDOs' work confines
	the space in which the DetNet architecture progresses.		the space in which the DetNet architecture progresses.
	The properties of deterministic networks will have specific		The properties of deterministic networks will have specific
	requirements for the use of routed networks to support these		requirements for the use of routed networks to support these
	applications and a new model must be proposed to integrate		applications and a new model must be proposed to integrate
	determinism in IT technology. The proposed model should enable a		determinism in IT technology. The proposed model should enable a
	fully scheduled operation orchestrated by a central controller, and		fully scheduled operation orchestrated by a central controller, and
	may support a more distributed operation with probably lesser		may support a more distributed operation with probably lesser
	capabilities. In any fashion, the model should not compromise the		capabilities. In any fashion, the model should not compromise the
	ability of a network to keep carrying the sorts of traffic that is		ability of a network to keep carrying the sorts of traffic that is
	already carried today in conjunction with new, more deterministic		already carried today in conjunction with new, more deterministic
	flows. Forward note: The DetNet Architecture		flows. Forward note: The DetNet Architecture
	[I-D.ietf-detnet-architecture] is the document produced by the DetNet		[I-D.ietf-detnet-architecture] is the document produced by the DetNet
	WG to describe that model.		WG to describe that model.
	Once the abstract model is agreed upon, the IETF will need to specify		At the time of this writing, the expectation is that once the
	the signaling elements to be used to establish a path and the tagging		abstract model is agreed upon, the IETF will specify the signaling
	elements to be used identify the flows that are to be forwarded along		elements to be used to establish a path and the tagging elements to
	that path. The IETF will also need to specify the necessary		be used identify the flows that are to be forwarded along that path.
			The expectation is also that IETF will specify the necessary
	protocols, or protocol additions, based on relevant IETF		protocols, or protocol additions, based on relevant IETF
	technologies, to implement the selected model.		technologies, to implement the selected model.
	As a result of this work, it will be possible to establish a multi-		A desirable outcome of the work is the capability to establish a
	hop path over the IP or MPLS network, for a particular flow with		multi-hop path over the IP or MPLS network, for a particular flow
	given timing and precise throughput requirements, and carry this		with given timing and precise throughput requirements, and carry this
	particular flow along the multi-hop path with such characteristics as		particular flow along the multi-hop path with such characteristics as
	low latency and ultra-low jitter, reordering and/or replication and		low latency and ultra-low jitter, reordering and/or replication and
	elimination of packets over non-congruent paths for a higher delivery		elimination of packets over non-congruent paths for a higher delivery
	ratio, and/or zero congestion loss, regardless of the amount of other		ratio, and/or zero congestion loss, regardless of the amount of other
	flows in the network.		flows in the network.
	Depending on the network capabilities and on the current state,		Depending on the network capabilities and on the current state,
	requests to establish a path by an end-node or a network management		requests to establish a path by an end-node or a network management
	entity may be granted or rejected, an existing path may be moved or		entity may be granted or rejected, an existing path may be moved or
	removed, and DetNet flows exceeding their contract may face packet		removed, and DetNet flows exceeding their contract may face packet
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 16 ¶
	basing all of these disparate digital technologies on packet		basing all of these disparate digital technologies on packet
	networks.		networks.
	The goals of Deterministic Networking are to enable the migration of		The goals of Deterministic Networking are to enable the migration of
	applications with critical timing and reliability issues that		applications with critical timing and reliability issues that
	currently use special-purpose fieldbus technologies (HDMI, CANbus,		currently use special-purpose fieldbus technologies (HDMI, CANbus,
	ProfiBus, etc... even RS-232!) to packet technologies in general, and		ProfiBus, etc... even RS-232!) to packet technologies in general, and
	the Internet Protocol in particular, and to support both these new		the Internet Protocol in particular, and to support both these new
	applications, and existing packet network applications, over the same		applications, and existing packet network applications, over the same
	physical network. In other words, a Deterministic Network is		physical network. In other words, a Deterministic Network is
	backwards compatible with - capable of transporting - statistically		backwards compatible with (capable of transporting) statistically
	multiplexed traffic while preserving the properties of the accepted		multiplexed traffic while preserving the properties of the accepted
	deterministic flows.		deterministic flows.
	Considerable experience ([ODVA]/[EIP],[AVnu],		Considerable experience from automation and professional audio/video
	[Profinet],[HART],[IEC62439], [ISA100.11a] and [WirelessHART],		networks (e.g., [ODVA]/[EIP], [AVnu], [Profinet], [HART], [IEC62439],
	etc...) has shown that these applications need a some or all of a		[ISA100.11a] and [WirelessHART]) has shown that these applications
	suite of features that includes:		need a some or all of a suite of features that includes:
	1. Time synchronization of all host and network nodes (routers and/		1. Time synchronization of all host and network nodes (routers and/
	or bridges), accurate to something between 10 nanoseconds and 10		or bridges), accurate to something between 10 nanoseconds and 10
	microseconds, depending on the application.		microseconds, depending on the application.
	2. Support for Deterministic packet flows that:		2. Support for Deterministic packet flows that:
	* Can be unicast or multicast;		* Can be unicast or multicast;
	* Need absolute guarantees of minimum and maximum latency end-		* Need absolute guarantees of minimum and maximum latency end-
	skipping to change at page 6, line 24 ¶		skipping to change at page 6, line 24 ¶
	3.1. Supported topologies		3.1. Supported topologies
	In some use cases, the end point which run the application is		In some use cases, the end point which run the application is
	involved in the deterministic networking operation, for instance by		involved in the deterministic networking operation, for instance by
	controlling certain aspects of its throughput such as rate or precise		controlling certain aspects of its throughput such as rate or precise
	time of emission. In that case, the deterministic path is end-to-end		time of emission. In that case, the deterministic path is end-to-end
	from application host to application host.		from application host to application host.
	On the other end, the deterministic portion of a path may be a tunnel		On the other end, the deterministic portion of a path may be a tunnel
	between and ingress and an egress router. In any case, routers and		between an ingress and an egress router. In any case, routers and
	switches in between should not need to be aware whether the path is		switches in between should not need to be aware whether the path is
	end-to-end of a tunnel.		end-to-end or a tunnel.
	While it is clear that DetNet does not aim at setting up		While it is clear that DetNet does not aim at setting up
	deterministic paths over the global Internet, there is still a lack		deterministic paths over the global Internet, there is still a lack
	of clarity on the limits of a domain where a deterministic path can		of clarity on the limits of a domain where a deterministic path can
	be set up. These limits may depend in the technology that is used to		be set up. These limits may depend in the technology that is used to
	set the path up, whether it is centralized or distributed.		set the path up, whether it is centralized or distributed.
	3.2. Flow Characterization		3.2. Flow Characterization
	Deterministic forwarding can only apply on flows with well-defined		Deterministic forwarding can only apply on flows with well-defined
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 33 ¶
	o support for life cycle management for a path		o support for life cycle management for a path
	(instantiate/modify/update/delete)		(instantiate/modify/update/delete)
	o support for adaptability to cope with various events such as loss		o support for adaptability to cope with various events such as loss
	of a link, etc...		of a link, etc...
	o expose the status of the path to the end devices (UNI interface)		o expose the status of the path to the end devices (UNI interface)
	o provide additional reliability through redundancy, in particular		o provide additional reliability through redundancy, in particular
	with packet replication and elimination;		with packet Packet Replication, Elimination and Ordering Functions
			(PREOF) where the former may generate an out-of-order delivery
			that may need to be corrected corrected by the latter;
	o indicate the flows and packet sequences in-band with the flows;		o indicate the flows and packet sequences in-band with the flows,
			this is needed for flows that require PREOF in order to isolate
			duplicates and reorder in the end;
	3.4. Distributed Path Setup		3.4. Distributed Path Setup
	Whether a distributed alternative without a PCE can be valuable could		Whether a distributed alternative without a PCE can be valuable could
	be studied as well. Such an alternative could for instance inherit		be studied as well. Such an alternative could for instance inherit
	from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE) flows.		from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE) flows.
	But the focus of the work should be to deliver the centralized		But the focus of the work should be to deliver the centralized
	approach first.		approach first.
	To enable a RSVP-TE like functionality, the following steps would		To enable a RSVP-TE like functionality, the following steps would
	skipping to change at page 9, line 24 ¶		skipping to change at page 9, line 28 ¶
	The specific threats against DetNet are further discussed in the		The specific threats against DetNet are further discussed in the
	DetNet Security Considerations [I-D.ietf-detnet-security] document.		DetNet Security Considerations [I-D.ietf-detnet-security] document.
	5. IANA Considerations		5. IANA Considerations
	This document does not require an action from IANA.		This document does not require an action from IANA.
	6. Acknowledgments		6. Acknowledgments
	The authors wish to thank Lou Berger, Stewart Bryant, Janos Farkas,		The authors wish to thank Lou Berger, Pat Thaler, Jouni Korhonen,
	Andrew Malis, Jouni Korhonen, Erik Nordmark, George Swallow, Lou		Janos Farkas, Stewart Bryant, Andrew Malis, Ethan Grossman, Patrick
	Berger, Ines Robles, Shwetha Bhandari, Rudy Klecka, Anca Zamfir,		Wetterwald, Subha Dhesikan, Matthew Miller, Erik Nordmark, George
	David Black, Thomas Watteyne, Shitanshu Shah, Kiran Makhijani, Craig		Swallow, Rodney Cummings, Ines Robles, Shwetha Bhandari, Rudy Klecka,
	Gunther, Rodney Cummings, Wilfried Steiner, Marcel Kiessling, Karl		Anca Zamfir, David Black, Thomas Watteyne, Shitanshu Shah, Kiran
	Weber, Ethan Grossman, Patrick Wetterwald, Subha Dhesikan, Rudy		Makhijani, Craig Gunther, Warren Kumari, Wilfried Steiner, Marcel
	Klecka and Pat Thaler for their various contributions to this work.		Kiessling, Karl Weber, Alissa Cooper, and Benjamin Kaduk for their
			various contributions to this work.
	7. Informative References		7. Informative References
	[AVnu] http://www.avnu.org/, "The AVnu Alliance tests and		[AVnu] http://www.avnu.org/, "The AVnu Alliance tests and
	certifies devices for interoperability, providing a simple		certifies devices for interoperability, providing a simple
	and reliable networking solution for AV network		and reliable networking solution for AV network
	implementation based on the IEEE Audio Video Bridging		implementation based on the IEEE Audio Video Bridging
	(AVB) and Time-Sensitive Networking (TSN) standards.".		(AVB) and Time-Sensitive Networking (TSN) standards.".
	[EIP] http://www.odva.org/, "EtherNet/IP provides users with the		[EIP] http://www.odva.org/, "EtherNet/IP provides users with the
	skipping to change at page 10, line 8 ¶		skipping to change at page 10, line 21 ¶
	Publications_Numbered/		Publications_Numbered/
	PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>.		PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>.
	[HART] www.hartcomm.org, "Highway Addressable Remote Transducer,		[HART] www.hartcomm.org, "Highway Addressable Remote Transducer,
	a group of specifications for industrial process and		a group of specifications for industrial process and
	control devices administered by the HART Foundation".		control devices administered by the HART Foundation".
	[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-08 (work in progress), September 2018.		detnet-architecture-09 (work in progress), October 2018.
	[I-D.ietf-detnet-security]		[I-D.ietf-detnet-security]
	Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,		Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
	J., Austad, H., Stanton, K., and N. Finn, "Deterministic		J., Austad, H., Stanton, K., and N. Finn, "Deterministic
	Networking (DetNet) Security Considerations", draft-ietf-		Networking (DetNet) Security Considerations", draft-ietf-
	detnet-security-02 (work in progress), April 2018.		detnet-security-03 (work in progress), October 2018.
	[I-D.ietf-detnet-use-cases]		[I-D.ietf-detnet-use-cases]
	Grossman, E., "Deterministic Networking Use Cases", draft-		Grossman, E., "Deterministic Networking Use Cases", draft-
	ietf-detnet-use-cases-18 (work in progress), September		ietf-detnet-use-cases-19 (work in progress), October 2018.
	2018.
	[IEC62439]		[IEC62439]
	IEC, "Industrial communication networks - High		IEC, "Industrial communication networks - High
	availability automation networks - Part 3: Parallel		availability automation networks - Part 3: Parallel
	Redundancy Protocol (PRP) and High-availability Seamless		Redundancy Protocol (PRP) and High-availability Seamless
	Redundancy (HSR) - IEC62439-3", 2012,		Redundancy (HSR) - IEC62439-3", 2012,
	<https://webstore.iec.ch/publication/7018>.		<https://webstore.iec.ch/publication/7018>.
	[IEEE802.1TSNTG]		[IEEE802.1TSNTG]
	IEEE Standards Association, "IEEE 802.1 Time-Sensitive		IEEE Standards Association, "IEEE 802.1 Time-Sensitive
End of changes. 16 change blocks.
	35 lines changed or deleted		40 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/