draft-ietf-detnet-use-cases-04.txt		draft-ietf-detnet-use-cases-05.txt
	Internet Engineering Task Force E. Grossman, Ed.		Internet Engineering Task Force E. Grossman, Ed.
	Internet-Draft DOLBY		Internet-Draft DOLBY
	Intended status: Informational C. Gunther		Intended status: Informational C. Gunther
	Expires: August 25, 2016 HARMAN		Expires: August 26, 2016 HARMAN
	P. Thubert		P. Thubert
	P. Wetterwald		P. Wetterwald
	CISCO		CISCO
	J. Raymond		J. Raymond
	HYDRO-QUEBEC		HYDRO-QUEBEC
	J. Korhonen		J. Korhonen
	BROADCOM		BROADCOM
	Y. Kaneko		Y. Kaneko
	Toshiba		Toshiba
	S. Das		S. Das
	Applied Communication Sciences		Applied Communication Sciences
	Y. Zha		Y. Zha
	HUAWEI		HUAWEI
	B. Varga		B. Varga
	J. Farkas		J. Farkas
	Ericsson		Ericsson
	F. Goetz		F. Goetz
	J. Schmitt		J. Schmitt
	Siemens		Siemens
	February 22, 2016		February 23, 2016
	Deterministic Networking Use Cases		Deterministic Networking Use Cases
	draft-ietf-detnet-use-cases-04		draft-ietf-detnet-use-cases-05
	Abstract		Abstract
	This draft documents requirements in several diverse industries to		This draft documents requirements in several diverse industries to
	establish multi-hop paths for characterized flows with deterministic		establish multi-hop paths for characterized flows with deterministic
	properties. In this context deterministic implies that streams can		properties. In this context deterministic implies that streams can
	be established which provide guaranteed bandwidth and latency which		be established which provide guaranteed bandwidth and latency which
	can be established from either a Layer 2 or Layer 3 (IP) interface,		can be established from either a Layer 2 or Layer 3 (IP) interface,
	and which can co-exist on an IP network with best-effort traffic.		and which can co-exist on an IP network with best-effort traffic.
	skipping to change at page 2, line 20		skipping to change at page 2, line 20
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 August 25, 2016.		This Internet-Draft will expire on August 26, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 43		skipping to change at page 2, line 43
	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 . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5		2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6		2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6
	2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 7		2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 6
	2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7		2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7
	2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8		2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8
	2.3. Additional Stream Requirements . . . . . . . . . . . . . 9		2.3. Additional Stream Requirements . . . . . . . . . . . . . 9
	2.3.1. Deterministic Time to Establish Streaming . . . . . . 9		2.3.1. Deterministic Time to Establish Streaming . . . . . . 9
	2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9		2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9
	2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10		2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10
	2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10		2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10
	2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10		2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10
	2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 11		2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 10
	2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 11		2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 11
	2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11		2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11
	2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11		2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11
	2.4. Integration of Reserved Streams into IT Networks . . . . 12		2.4. Integration of Reserved Streams into IT Networks . . . . 12
	2.5. Security Considerations . . . . . . . . . . . . . . . . . 12		2.5. Security Considerations . . . . . . . . . . . . . . . . . 12
	2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12		2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12
	2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12		2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12
	2.6. A State-of-the-Art Broadcast Installation Hits Technology		2.6. A State-of-the-Art Broadcast Installation Hits Technology
	Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13		Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3. Utility Telecom Use Cases . . . . . . . . . . . . . . . . . . 13		3. Utility Telecom Use Cases . . . . . . . . . . . . . . . . . . 13
	skipping to change at page 3, line 42		skipping to change at page 3, line 42
	4.2. Building Automation Systems Today . . . . . . . . . . . . 36		4.2. Building Automation Systems Today . . . . . . . . . . . . 36
	4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 36		4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 36
	4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 37		4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 37
	4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 39		4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 39
	4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 39		4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 39
	4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 39		4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 39
	4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 40		4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 40
	4.2.4. Security Considerations . . . . . . . . . . . . . . . 40		4.2.4. Security Considerations . . . . . . . . . . . . . . . 40
	4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 40		4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 40
	4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 41		4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 41
	5. Wireless for Industrial Use Cases . . . . . . . . . . . . . . 41		5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 41
	5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 41		5.1. Use Case Description . . . . . . . . . . . . . . . . . . 41
	5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 42		5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 42
	5.3. 6TiSCH Overview . . . . . . . . . . . . . . . . . . . . . 43		5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 42
	5.3.1. TSCH and 6top . . . . . . . . . . . . . . . . . . . . 46		5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 43
	5.3.2. SlotFrames and Priorities . . . . . . . . . . . . . . 46		5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 43
	5.3.3. Schedule Management by a PCE . . . . . . . . . . . . 46		5.3.1. Unified Wireless Network and Management . . . . . . . 43
	5.3.4. Track Forwarding . . . . . . . . . . . . . . . . . . 47		5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 45
	5.3.4.1. Transport Mode . . . . . . . . . . . . . . . . . 49		5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 46
	5.3.4.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . 50		5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 46
	5.3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . 51		5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 47
	5.4. Operations of Interest for DetNet and PCE . . . . . . . . 51		5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 47
	5.4.1. Packet Marking and Handling . . . . . . . . . . . . . 52		5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 48
	5.4.1.1. Tagging Packets for Flow Identification . . . . . 52		6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 48
	5.4.1.2. Replication, Retries and Elimination . . . . . . 52		6.1. Use Case Description . . . . . . . . . . . . . . . . . . 48
	5.4.1.3. Differentiated Services Per-Hop-Behavior . . . . 53		6.1.1. Network Architecture . . . . . . . . . . . . . . . . 48
	5.4.2. Topology and capabilities . . . . . . . . . . . . . . 53		6.1.2. Time Synchronization Requirements . . . . . . . . . . 49
	5.5. Security Considerations . . . . . . . . . . . . . . . . . 54		6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 51
	6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 54		6.1.4. Security Considerations . . . . . . . . . . . . . . . 51
	6.1. Use Case Description . . . . . . . . . . . . . . . . . . 54		6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 52
	6.1.1. Network Architecture . . . . . . . . . . . . . . . . 54		6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 52
	6.1.2. Time Synchronization Requirements . . . . . . . . . . 55		6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 54
	6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 57		7. Cellular Coordinated Multipoint Processing (CoMP) . . . . . . 54
	6.1.4. Security Considerations . . . . . . . . . . . . . . . 57		7.1. Use Case Description . . . . . . . . . . . . . . . . . . 54
	6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 58		7.1.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 55
	6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 58		7.1.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 56
	6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 60		7.2. CoMP Today . . . . . . . . . . . . . . . . . . . . . . . 56
	7. Cellular Coordinated Multipoint Processing (CoMP) . . . . . . 60		7.3. CoMP Future . . . . . . . . . . . . . . . . . . . . . . . 56
	7.1. Use Case Description . . . . . . . . . . . . . . . . . . 60		7.3.1. Mobile Industry Overall Goals . . . . . . . . . . . . 56
	7.1.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 61		7.3.2. CoMP Infrastructure Goals . . . . . . . . . . . . . . 57
	7.1.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 62		7.4. CoMP Asks . . . . . . . . . . . . . . . . . . . . . . . . 57
	7.2. CoMP Today . . . . . . . . . . . . . . . . . . . . . . . 62		8. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 58
	7.3. CoMP Future . . . . . . . . . . . . . . . . . . . . . . . 62		8.1. Use Case Description . . . . . . . . . . . . . . . . . . 58
	7.3.1. Mobile Industry Overall Goals . . . . . . . . . . . . 62		8.2. Industrial M2M Communication Today . . . . . . . . . . . 59
	7.3.2. CoMP Infrastructure Goals . . . . . . . . . . . . . . 63		8.2.1. Transport Parameters . . . . . . . . . . . . . . . . 59
	7.4. CoMP Asks . . . . . . . . . . . . . . . . . . . . . . . . 63		8.2.2. Stream Creation and Destruction . . . . . . . . . . . 60
	8. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 64		8.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 60
	8.1. Use Case Description . . . . . . . . . . . . . . . . . . 64		8.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 61
	8.2. Industrial M2M Communication Today . . . . . . . . . . . 65		9. Internet-based Applications . . . . . . . . . . . . . . . . . 61
	8.2.1. Transport Parameters . . . . . . . . . . . . . . . . 65		9.1. Use Case Description . . . . . . . . . . . . . . . . . . 61
	8.2.2. Stream Creation and Destruction . . . . . . . . . . . 66		9.1.1. Media Content Delivery . . . . . . . . . . . . . . . 61
	8.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 66		9.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 61
	8.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 67		9.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 61
	9. Internet-based Applications . . . . . . . . . . . . . . . . . 67		9.2. Internet-Based Applications Today . . . . . . . . . . . . 62
	9.1. Use Case Description . . . . . . . . . . . . . . . . . . 67		9.3. Internet-Based Applications Future . . . . . . . . . . . 62
	9.1.1. Media Content Delivery . . . . . . . . . . . . . . . 67		9.4. Internet-Based Applications Asks . . . . . . . . . . . . 62
	9.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 67		10. Use Case Common Elements . . . . . . . . . . . . . . . . . . 62
	9.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 67		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
	9.2. Internet-Based Applications Today . . . . . . . . . . . . 68		11.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 63
	9.3. Internet-Based Applications Future . . . . . . . . . . . 68		11.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 64
	9.4. Internet-Based Applications Asks . . . . . . . . . . . . 68		11.3. Building Automation Systems . . . . . . . . . . . . . . 64
	10. Use Case Common Elements . . . . . . . . . . . . . . . . . . 68		11.4. Wireless for Industrial . . . . . . . . . . . . . . . . 64
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69		11.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 64
	11.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 69		11.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 64
	11.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 70		11.7. Internet Applications and CoMP . . . . . . . . . . . . . 64
	11.3. Building Automation Systems . . . . . . . . . . . . . . 70		12. Informative References . . . . . . . . . . . . . . . . . . . 65
	11.4. Wireless for Industrial . . . . . . . . . . . . . . . . 70		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
	11.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 70
	11.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 70
	11.7. Other . . . . . . . . . . . . . . . . . . . . . . . . . 70
	12. Informative References . . . . . . . . . . . . . . . . . . . 71
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79
	1. Introduction		1. Introduction
	This draft presents use cases from diverse industries which have in		This draft presents use cases from diverse industries which have in
	common a need for deterministic streams, but which also differ		common a need for deterministic streams, but which also differ
	notably in their network topologies and specific desired behavior.		notably in their network topologies and specific desired behavior.
	Together, they provide broad industry context for DetNet and a		Together, they provide broad industry context for DetNet and a
	yardstick against which proposed DetNet designs can be measured (to		yardstick against which proposed DetNet designs can be measured (to
	what extent does a proposed design satisfy these various use cases?)		what extent does a proposed design satisfy these various use cases?)
	skipping to change at page 41, line 34		skipping to change at page 41, line 34
	o Availability of network data in disaster scenario		o Availability of network data in disaster scenario
	o Authentication between management and field devices (both local		o Authentication between management and field devices (both local
	and remote)		and remote)
	o Integrity and data origin authentication of communication data		o Integrity and data origin authentication of communication data
	between field and management devices		between field and management devices
	o Confidentiality of data when communicated to a remote device		o Confidentiality of data when communicated to a remote device
	5. Wireless for Industrial Use Cases		5. Wireless for Industrial
	(This section was derived from draft-thubert-6tisch-4detnet-01)		5.1. Use Case Description
	5.1. Introduction		Wireless networks are useful for industrial applications, for example
			when portable, fast-moving or rotating objects are involved, and for
			the resource-constrained devices found in the Internet of Things
			(IoT).
	The emergence of wireless technology has enabled a variety of new		Such network-connected sensors, actuators, control loops (etc.)
	devices to get interconnected, at a very low marginal cost per		typically require that the underlying network support real-time
	device, at any distance ranging from Near Field to interplanetary,		quality of service (QoS), as well as specific classes of other
	and in circumstances where wiring may not be practical, for instance		network properties such as reliability, redundancy, and security.
	on fast-moving or rotating devices.
	At the same time, a new breed of Time Sensitive Networks is being		These networks may also contain very large numbers of devices, for
	developed to enable traffic that is highly sensitive to jitter, quite		example for factories, "big data" acquisition, and the IoT. Given
	sensitive to latency, and with a high degree of operational		the large numbers of devices installed, and the potential
	criticality so that loss should be minimized at all times. Such		pervasiveness of the IoT, this is a huge and very cost-sensitive
	traffic is not limited to professional Audio/ Video networks, but is		market. For example, a 1% cost reduction in some areas could save
	also found in command and control operations such as industrial		$100B
	automation and vehicular sensors and actuators.
	At IEEE802.1, the Audio/Video Task Group [IEEE802.1TSNTG] Time		5.1.1. Network Convergence using 6TiSCH
	Sensitive Networking (TSN) to address Deterministic Ethernet. The
	Medium access Control (MAC) of IEEE802.15.4 [IEEE802154] has evolved
	with the new TimeSlotted Channel Hopping (TSCH) [RFC7554] mode for
	deterministic industrial-type applications. TSCH was introduced with
	the IEEE802.15.4e [IEEE802154e] amendment and will be wrapped up in
	the next revision of the IEEE802.15.4 standard. For all practical
	purpose, this document is expected to be insensitive to the future
	versions of the IEEE802.15.4 standard, which is thus referenced
	undated.
	Though at a different time scale, both TSN and TSCH standards provide		Some wireless network technologies support real-time QoS, and are
	Deterministic capabilities to the point that a packet that pertains		thus useful for these kinds of networks, but others do not. For
	to a certain flow crosses the network from node to node following a		example WiFi is pervasive but does not provide guaranteed timing or
	very precise schedule, as a train that leaves intermediate stations		delivery of packets, and thus is not useful in this context.
	at precise times along its path. With TSCH, time is formatted into
	timeSlots, and an individual cell is allocated to unicast or
	broadcast communication at the MAC level. The time-slotted operation
	reduces collisions, saves energy, and enables to more closely
	engineer the network for deterministic properties. The channel
	hopping aspect is a simple and efficient technique to combat multi-
	path fading and co-channel interferences (for example by Wi-Fi
	emitters).
	The 6TiSCH Architecture [I-D.ietf-6tisch-architecture] defines a		In this use case we focus on one specific wireless network technology
	remote monitoring and scheduling management of a TSCH network by a		which does provide the required deterministic QoS, which is "IPv6
	Path Computation Element (PCE), which cooperates with an abstract		over the TSCH mode of IEEE 802.15.4e" (6TiSCH, where TSCH stands for
	Network Management Entity (NME) to manage timeSlots and device		"Time-Slotted Channel Hopping", see [I-D.ietf-6tisch-architecture],
			[IEEE802154], [IEEE802154e], and [RFC7554]).
			There are other deterministic wireless busses and networks available
			today, however they are imcompatible with each other, and
			incompatible with IP traffic (for example [ISA100], [WirelessHART]).
			Thus the primary goal of this use case is to apply 6TiSH as a
			converged IP- and standards-based wireless network for industrial
			applications, i.e. to replace multiple proprietary and/or
			incompatible wireless networking and wireless network management
			standards.
			5.1.2. Common Protocol Development for 6TiSCH
			Today there are a number of protocols required by 6TiSCH which are
			still in development, and a second intent of this use case is to
			highlight the ways in which these "missing" protocols share goals in
			common with DetNet. Thus it is possible that some of the protocol
			technology developed for DetNet will also be applicable to 6TiSCH.
			These protocol goals are identified here, along with their
			relationship to DetNet. It is likely that ultimately the resulting
			protocols will not be identical, but will share design principles
			which contribute to the eficiency of enabling both DetNet and 6TiSCH.
			One such commonality is that although at a different time scale, in
			both TSN [IEEE802.1TSNTG] and TSCH a packet crosses the network from
			node to node follows a precise schedule, as a train that leaves
			intermediate stations at precise times along its path. This kind of
			operation reduces collisions, saves energy, and enables engineering
			the network for deterministic properties.
			Another commonality is remote monitoring and scheduling management of
			a TSCH network by a Path Computation Element (PCE) and Network
			Management Entity (NME). The PCE/NME manage timeslots and device
	resources in a manner that minimizes the interaction with and the		resources in a manner that minimizes the interaction with and the
	load placed on the constrained devices.		load placed on resource-constrained devices. For example, a tiny IoT
			device may have just enough buffers to store one or a few IPv6
			packets, and will have limited bandwidth between peers such that it
			can maintain only a small amount of peer information, and will not be
			able to store many packets waiting to be forwarded. It is
			advantageous then for it to only be required to carry out the
			specific behavior assigned to it by the PCE/NME (as opposed to
			maintaining its own IP stack, for example).
	This Architecture applies the concepts of Deterministic Networking on		6TiSCH depends on [PCE] and [I-D.finn-detnet-architecture], and we
	a TSCH network to enable the switching of timeSlots in a G-MPLS		expect that DetNet will maintain consistency with [IEEE802.1TSNTG].
	manner. This document details the dependencies that 6TiSCH has on
	PCE [PCE] and DetNet [I-D.finn-detnet-architecture] to provide the
	necessary capabilities that may be specific to such networks. In
	turn, DetNet is expected to integrate and maintain consistency with
	the work that has taken place and is continuing at IEEE802.1TSN and
	AVnu.
	5.2. Terminology		5.2. Wireless Industrial Today
	Readers are expected to be familiar with all the terms and concepts		Today industrial wireless is accomplished using multiple
	that are discussed in "Multi-link Subnet Support in IPv6"		deterministic wireless networks which are incompatible with each
	[I-D.ietf-ipv6-multilink-subnets].		other and with IP traffic.
	The draft uses terminology defined or referenced in		6TiSCH is not yet fully specified, so it cannot be used in today's
	[I-D.ietf-6tisch-terminology] and		applications.
	[I-D.ietf-roll-rpl-industrial-applicability].
	The draft also conforms to the terms and models described in		5.3. Wireless Industrial Future
	[RFC3444] and uses the vocabulary and the concepts defined in
	[RFC4291] for the IPv6 Architecture.
	5.3. 6TiSCH Overview		5.3.1. Unified Wireless Network and Management
	The scope of the present work is a subnet that, in its basic		We expect DetNet and 6TiSCH together to enable converged transport of
	configuration, is made of a TSCH [RFC7554] MAC Low Power Lossy		deterministic and best-effort traffic flows between real-time
	Network (LLN).		industrial devices and wide area networks via IP routing. A high
			level view of a basic such network is shown in Figure 4.
	---+-------- ............ ------------		---+-------- ............ ------------
	| External Network |		| External Network |
	| +-----+		| +-----+
	+-----+ | NME |		+-----+ | NME |
	| | LLN Border | |		| | LLN Border | |
	| | router +-----+		| | router +-----+
	+-----+		+-----+
	o o o		o o o
	o o o o		o o o o
	o o LLN o o o		o o LLN o o o
	o o o o		o o o o
	o		o
	Figure 4: Basic Configuration of a 6TiSCH Network		Figure 4: Basic 6TiSCH Network
	In the extended configuration, a Backbone Router (6BBR) federates		Figure 5 shows a backbone router federating multiple synchronized
	multiple 6TiSCH in a single subnet over a backbone. 6TiSCH 6BBRs		6TiSCH subnets into a single subnet connected to the external
	synchronize with one another over the backbone, so as to ensure that		network.
	the multiple LLNs that form the IPv6 subnet stay tightly
	synchronized.
	---+-------- ............ ------------		---+-------- ............ ------------
	| External Network |		| External Network |
	| +-----+		| +-----+
	| +-----+ | NME |		| +-----+ | NME |
	+-----+ | +-----+ | |		+-----+ | +-----+ | |
	| | Router | | PCE | +-----+		| | Router | | PCE | +-----+
	| | +--| |		| | +--| |
	+-----+ +-----+		+-----+ +-----+
	| |		| |
	skipping to change at page 44, line 26		skipping to change at page 44, line 30
	| | |		| | |
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| | Backbone | | Backbone | | Backbone		| | Backbone | | Backbone | | Backbone
	o | | router | | router | | router		o | | router | | router | | router
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	o o o o o		o o o o o
	o o o o o o o o o o o		o o o o o o o o o o o
	o o o LLN o o o o		o o o LLN o o o o
	o o o o o o o o o o o o		o o o o o o o o o o o o
	Figure 5: Extended Configuration of a 6TiSCH Network		Figure 5: Extended 6TiSCH Network
	If the Backbone is Deterministic, then the Backbone Router ensures		The backbone router must ensure end-to-end deterministic behavior
	that the end-to-end deterministic behavior is maintained between the		between the LLN and the backbone. We would like to see this
	LLN and the backbone. This SHOULD be done in conformance to the		accomplished in conformance with the work done in
	DetNet Architecture [I-D.finn-detnet-architecture] which studies		[I-D.finn-detnet-architecture] with respect to Layer-3 aspects of
	Layer-3 aspects of Deterministic Networks, and covers networks that		deterministic networks that span multiple Layer-2 domains.
	span multiple Layer-2 domains. One particular requirement is that
	the PCE MUST be able to compute a deterministic path and to end
	across the TSCH network and an IEEE802.1 TSN Ethernet backbone, and
	DetNet MUST enable end-to-end deterministic forwarding.
	6TiSCH defines the concept of a Track, which is a complex form of a		The PCE must compute a deterministic path end-to-end across the TSCH
	uni-directional Circuit ([I-D.ietf-6tisch-terminology]). As opposed		network and IEEE802.1 TSN Ethernet backbone, and DetNet protocols are
	to a simple circuit that is a sequence of nodes and links, a Track is		expected to enable end-to-end deterministic forwarding.
	shaped as a directed acyclic graph towards a destination to support
	multi-path forwarding and route around failures. A Track may also
	branch off and rejoin, for the purpose of the so-called Packet
	Replication and Elimination (PRE), over non congruent branches. PRE
	may be used to complement layer-2 Automatic Repeat reQuest (ARQ) to
	meet industrial expectations in Packet Delivery Ratio (PDR), in
	particular when the Track extends beyond the 6TiSCH network.
	+-----+		+-----+
	| IoT |		| IoT |
	| G/W |		| G/W |
	+-----+		+-----+
	^ <---- Elimination		^ <---- Elimination
	| |		| |
	Track branch | |		Track branch | |
	+-------+ +--------+ Subnet Backbone		+-------+ +--------+ Subnet Backbone
	| |		| |
	+--|--+ +--|--+		+--|--+ +--|--+
	| | | Backbone | | | Backbone		| | | Backbone | | | Backbone
	o | | | router | | | router		o | | | router | | | router
	+--/--+ +--|--+		+--/--+ +--|--+
	o / o o---o----/ o		o / o o---o----/ o
	o o---o--/ o o o o o		o o---o--/ o o o o o
	o \ / o o LLN o		o \ / o o LLN o
	o v <---- Replication		o v <---- Replication
	o		o
	Figure 6: End-to-End deterministic Track		Figure 6: 6TiSCH Network with PRE
	In the example above, a Track is laid out from a field device in a		5.3.1.1. PCE and 6TiSCH ARQ Retries
	6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN
			6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism
			to provide higher reliability of packet delivery. ARQ is related to
			packet replication and elimination because there are two independent
			paths for packets to arrive at the destination, and if an expected
			packed does not arrive on one path then it checks for the packet on
			the second path.
			Although to date this mechanism is only used by wireless networks,
			this may be a technique that would be appropriate for DetNet and so
			aspects of the enabling protocol could be co-developed.
			For example, in Figure 6, a Track is laid out from a field device in
			a 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN
	backbone.		backbone.
	The Replication function in the field device sends a copy of each		The Replication function in the field device sends a copy of each
	packet over two different branches, and the PCE schedules each hop of		packet over two different branches, and the PCE schedules each hop of
	both branches so that the two copies arrive in due time at the		both branches so that the two copies arrive in due time at the
	gateway. In case of a loss on one branch, hopefully the other copy		gateway. In case of a loss on one branch, hopefully the other copy
	of the packet still makes it in due time. If two copies make it to		of the packet still arrives within the allocated time. If two copies
	the IoT gateway, the Elimination function in the gateway ignores the		make it to the IoT gateway, the Elimination function in the gateway
	extra packet and presents only one copy to upper layers.		ignores the extra packet and presents only one copy to upper layers.
	At each 6TiSCH hop along the Track, the PCE may schedule more than		At each 6TiSCH hop along the Track, the PCE may schedule more than
	one timeSlot for a packet, so as to support Layer-2 retries (ARQ).		one timeSlot for a packet, so as to support Layer-2 retries (ARQ).
	It is also possible that the field device only uses the second branch
	if sending over the first branch fails.
	In current deployments, a TSCH Track does not necessarily support PRE		In current deployments, a TSCH Track does not necessarily support PRE
	but is systematically multi-path. This means that a Track is		but is systematically multi-path. This means that a Track is
	scheduled so as to ensure that each hop has at least two forwarding		scheduled so as to ensure that each hop has at least two forwarding
	solutions, and the forwarding decision is to try the preferred one		solutions, and the forwarding decision is to try the preferred one
	and use the other in case of Layer-2 transmission failure as detected		and use the other in case of Layer-2 transmission failure as detected
	by ARQ.		by ARQ.
	5.3.1. TSCH and 6top		5.3.2. Schedule Management by a PCE
	6top is a logical link control sitting between the IP layer and the
	TSCH MAC layer, which provides the link abstraction that is required
	for IP operations. The 6top operations are specified in
	[I-D.wang-6tisch-6top-sublayer].
	The 6top data model and management interfaces are further discussed
	in [I-D.ietf-6tisch-6top-interface] and [I-D.ietf-6tisch-coap].
	The architecture defines "soft" cells and "hard" cells. "Hard" cells
	are owned and managed by an separate scheduling entity (e.g. a PCE)
	that specifies the slotOffset/channelOffset of the cells to be
	added/moved/deleted, in which case 6top can only act as instructed,
	and may not move hard cells in the TSCH schedule on its own.
	5.3.2. SlotFrames and Priorities
	A slotFrame is the base object that the PCE needs to manipulate to
	program a schedule into an LLN node. Elaboration on that concept can
	be found in section "SlotFrames and Priorities" of the 6TiSCH
	architecture [I-D.ietf-6tisch-architecture]. The architecture also
	details how the schedule is constructed and how transmission
	resources called cells can be allocated to particular transmissions
	so as to avoid collisions.
	5.3.3. Schedule Management by a PCE
	6TiSCH supports a mixed model of centralized routes and distributed
	routes. Centralized routes can for example be computed by a entity
	such as a PCE. Distributed routes are computed by RPL.
	Both methods may inject routes in the Routing Tables of the 6TiSCH
	routers. In either case, each route is associated with a 6TiSCH
	topology that can be a RPL Instance topology or a track. The 6TiSCH
	topology is indexed by a Instance ID, in a format that reuses the
	RPLInstanceID as defined in RPL [RFC6550].
	Both RPL and PCE rely on shared sources such as policies to define
	Global and Local RPLInstanceIDs that can be used by either method.
	It is possible for centralized and distributed routing to share a
	same topology. Generally they will operate in different slotFrames,
	and centralized routes will be used for scheduled traffic and will
	have precedence over distributed routes in case of conflict between
	the slotFrames.
	Section "Schedule Management Mechanisms" of the 6TiSCH architecture
	describes 4 paradigms to manage the TSCH schedule of the LLN nodes:
	Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring
	and scheduling management, and Hop-by-hop scheduling. The Track
	operation for DetNet corresponds to a remote monitoring and
	scheduling management by a PCE.
	The 6top interface document [I-D.ietf-6tisch-6top-interface]
	specifies the generic data model that can be used to monitor and
	manage resources of the 6top sublayer. Abstract methods are
	suggested for use by a management entity in the device. The data
	model also enables remote control operations on the 6top sublayer.
	[I-D.ietf-6tisch-coap] defines an mapping of the 6top set of
	commands, which is described in [I-D.ietf-6tisch-6top-interface], to
	CoAP resources. This allows an entity to interact with the 6top
	layer of a node that is multiple hops away in a RESTful fashion.
	[I-D.ietf-6tisch-coap] also defines a basic set CoAP resources and
	associated RESTful access methods (GET/PUT/POST/DELETE). The payload
	(body) of the CoAP messages is encoded using the CBOR format. The
	PCE commands are expected to be issued directly as CoAP requests or
	to be mapped back and forth into CoAP by a gateway function at the
	edge of the 6TiSCH network. For instance, it is possible that a
	mapping entity on the backbone transforms a non-CoAP protocol such as
	PCEP into the RESTful interfaces that the 6TiSCH devices support.
	This architecture will be refined to comply with DetNet
	[I-D.finn-detnet-architecture] when the work is formalized.
	5.3.4. Track Forwarding
	By forwarding, this specification means the per-packet operation that
	allows to deliver a packet to a next hop or an upper layer in this
	node. Forwarding is based on pre-existing state that was installed
	as a result of the routing computation of a Track by a PCE. The
	6TiSCH architecture supports three different forwarding model, G-MPLS
	Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6
	Forwarding (6F) which is the classical IP operation. The DetNet case
	relates to the Track Forwarding operation under the control of a PCE.
	A Track is a unidirectional path between a source and a destination.
	In a Track cell, the normal operation of IEEE802.15.4 Automatic
	Repeat-reQuest (ARQ) usually happens, though the acknowledgment may
	be omitted in some cases, for instance if there is no scheduled cell
	for a retry.
	Track Forwarding is the simplest and fastest. A bundle of cells set
	to receive (RX-cells) is uniquely paired to a bundle of cells that
	are set to transmit (TX-cells), representing a layer-2 forwarding
	state that can be used regardless of the network layer protocol.
	This model can effectively be seen as a Generalized Multi-protocol
	Label Switching (G-MPLS) operation in that the information used to
	switch a frame is not an explicit label, but rather related to other
	properties of the way the packet was received, a particular cell in
	the case of 6TiSCH. As a result, as long as the TSCH MAC (and
	Layer-2 security) accepts a frame, that frame can be switched
	regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN
	fragment, or a frame from an alternate protocol such as WirelessHART
	or ISA100.11a.
	A data frame that is forwarded along a Track normally has a
	destination MAC address that is set to broadcast - or a multicast
	address depending on MAC support. This way, the MAC layer in the
	intermediate nodes accepts the incoming frame and 6top switches it
	without incurring a change in the MAC header. In the case of
	IEEE802.15.4, this means effectively broadcast, so that along the
	Track the short address for the destination of the frame is set to
	0xFFFF.
	A Track is thus formed end-to-end as a succession of paired bundles,
	a receive bundle from the previous hop and a transmit bundle to the
	next hop along the Track, and a cell in such a bundle belongs to at
	most one Track. For a given iteration of the device schedule, the
	effective channel of the cell is obtained by adding a pseudo-random
	number to the channelOffset of the cell, which results in a rotation
	of the frequency that used for transmission. The bundles may be
	computed so as to accommodate both variable rates and
	retransmissions, so they might not be fully used at a given iteration
	of the schedule. The 6TiSCH architecture provides additional means
	to avoid waste of cells as well as overflows in the transmit bundle,
	as follows:
	In one hand, a TX-cell that is not needed for the current iteration
	may be reused opportunistically on a per-hop basis for routed
	packets. When all of the frame that were received for a given Track
	are effectively transmitted, any available TX-cell for that Track can
	be reused for upper layer traffic for which the next-hop router
	matches the next hop along the Track. In that case, the cell that is
	being used is effectively a TX-cell from the Track, but the short
	address for the destination is that of the next-hop router. It
	results that a frame that is received in a RX-cell of a Track with a
	destination MAC address set to this node as opposed to broadcast must
	be extracted from the Track and delivered to the upper layer (a frame
	with an unrecognized MAC address is dropped at the lower MAC layer
	and thus is not received at the 6top sublayer).
	On the other hand, it might happen that there are not enough TX-cells
	in the transmit bundle to accommodate the Track traffic, for instance
	if more retransmissions are needed than provisioned. In that case,
	the frame can be placed for transmission in the bundle that is used
	for layer-3 traffic towards the next hop along the track as long as
	it can be routed by the upper layer, that is, typically, if the frame
	transports an IPv6 packet. The MAC address should be set to the
	next-hop MAC address to avoid confusion. It results that a frame
	that is received over a layer-3 bundle may be in fact associated to a
	Track. In a classical IP link such as an Ethernet, off-track traffic
	is typically in excess over reservation to be routed along the non-
	reserved path based on its QoS setting. But with 6TiSCH, since the
	use of the layer-3 bundle may be due to transmission failures, it
	makes sense for the receiver to recognize a frame that should be re-
	tracked, and to place it back on the appropriate bundle if possible.
	A frame should be re-tracked if the Per-Hop-Behavior group indicated
	in the Differentiated Services Field in the IPv6 header is set to
	Deterministic Forwarding, as discussed in Section 5.4.1. A frame is
	re-tracked by scheduling it for transmission over the transmit bundle
	associated to the Track, with the destination MAC address set to
	broadcast.
	There are 2 modes for a Track, transport mode and tunnel mode.
	5.3.4.1. Transport Mode
	In transport mode, the Protocol Data Unit (PDU) is associated with
	flow-dependant meta-data that refers uniquely to the Track, so the
	6top sublayer can place the frame in the appropriate cell without
	ambiguity. In the case of IPv6 traffic, this flow identification is
	transported in the Flow Label of the IPv6 header. Associated with
	the source IPv6 address, the Flow Label forms a globally unique
	identifier for that particular Track that is validated at egress
	before restoring the destination MAC address (DMAC) and punting to
	the upper layer.
	| ^
	+--------------+ | |
	| IPv6 | | |
	+--------------+ | |
	| 6LoWPAN HC | | |
	+--------------+ ingress egress
	| 6top | sets +----+ +----+ restores
	+--------------+ dmac to | | | | dmac to
	| TSCH MAC | brdcst | | | | self
	+--------------+ | | | | | |
	| LLN PHY | +-------+ +--...-----+ +-------+
	+--------------+
	Track Forwarding, Transport Mode
	5.3.4.2. Tunnel Mode
	In tunnel mode, the frames originate from an arbitrary protocol over
	a compatible MAC that may or may not be synchronized with the 6TiSCH
	network. An example of this would be a router with a dual radio that
	is capable of receiving and sending WirelessHART or ISA100.11a frames
	with the second radio, by presenting itself as an access Point or a
	Backbone Router, respectively.
	In that mode, some entity (e.g. PCE) can coordinate with a
	WirelessHART Network Manager or an ISA100.11a System Manager to
	specify the flows that are to be transported transparently over the
	Track.
	+--------------+
	| IPv6 |
	+--------------+
	| 6LoWPAN HC |
	+--------------+ set restore
	| 6top | +dmac+ +dmac+
	+--------------+ to|brdcst to|nexthop
	| TSCH MAC | | | | |
	+--------------+ | | | |
	| LLN PHY | +-------+ +--...-----+ +-------+
	+--------------+ | ingress egress |
	| |
	+--------------+ | |
	| LLN PHY | | |
	+--------------+ | |
	| TSCH MAC | | |
	+--------------+ | dmac = | dmac =
	|ISA100/WiHART | | nexthop v nexthop
	+--------------+
	Figure 7: Track Forwarding, Tunnel Mode
	In that case, the flow information that identifies the Track at the
	ingress 6TiSCH router is derived from the RX-cell. The dmac is set
	to this node but the flow information indicates that the frame must
	be tunneled over a particular Track so the frame is not passed to the
	upper layer. Instead, the dmac is forced to broadcast and the frame
	is passed to the 6top sublayer for switching.
	At the egress 6TiSCH router, the reverse operation occurs. Based on
	metadata associated to the Track, the frame is passed to the
	appropriate link layer with the destination MAC restored.
	5.3.4.3. Tunnel Metadata
	Metadata coming with the Track configuration is expected to provide
	the destination MAC address of the egress endpoint as well as the
	tunnel mode and specific data depending on the mode, for instance a
	service access point for frame delivery at egress. If the tunnel
	egress point does not have a MAC address that matches the
	configuration, the Track installation fails.
	In transport mode, if the final layer-3 destination is the tunnel		A common feature of 6TiSCH and DetNet is the action of a PCE to
	termination, then it is possible that the IPv6 address of the		configure paths through the network. Specifically, what is needed is
	destination is compressed at the 6LoWPAN sublayer based on the MAC		a protocol and data model that the PCE will use to get/set the
	address. It is thus mandatory at the ingress point to validate that		relevant configuration from/to the devices, as well as perform
	the MAC address that was used at the 6LoWPAN sublayer for compression		operations on the devices. We expect that this protocol will be
	matches that of the tunnel egress point. For that reason, the node		developed by DetNet with consideration for its reuse by 6TiSCH. The
	that injects a packet on a Track checks that the destination is		remainder of this section provides a bit more context from the 6TiSCH
	effectively that of the tunnel egress point before it overwrites it		side.
	to broadcast. The 6top sublayer at the tunnel egress point reverts
	that operation to the MAC address obtained from the tunnel metadata.
	5.4. Operations of Interest for DetNet and PCE		5.3.2.1. PCE Commands and 6TiSCH CoAP Requests
	In a classical system, the 6TiSCH device does not place the request		The 6TiSCH device does not expect to place the request for bandwidth
	for bandwidth between self and another device in the network.		between itself and another device in the network. Rather, an
	Rather, an Operation Control System invoked through an Human/Machine		operation control system invoked through a human interface specifies
	Interface (HMI) indicates the Traffic Specification, in particular in		the required traffic specification and the end nodes (in terms of
	terms of latency and reliability, and the end nodes. With this, the		latency and reliability). Based on this information, the PCE must
	PCE must compute a Track between the end nodes and provision the		compute a path between the end nodes and provision the network with
	network with per-flow state that describes the per-hop operation for		per-flow state that describes the per-hop operation for a given
	a given packet, the corresponding timeSlots, and the flow		packet, the corresponding timeslots, and the flow identification that
	identification that enables to recognize when a certain packet		enables recognizing that a certain packet belongs to a certain path,
	belongs to a certain Track, sort out duplicates, etc...		etc.
	For a static configuration that serves a certain purpose for a long		For a static configuration that serves a certain purpose for a long
	period of time, it is expected that a node will be provisioned in one		period of time, it is expected that a node will be provisioned in one
	shot with a full schedule, which incorporates the aggregation of its		shot with a full schedule, which incorporates the aggregation of its
	behavior for multiple Tracks. 6TiSCH expects that the programing of		behavior for multiple paths. 6TiSCH expects that the programing of
	the schedule will be done over COAP as discussed in 6TiSCH Resource		the schedule will be done over COAP as discussed in
	Management and Interaction using CoAP [I-D.ietf-6tisch-coap].		[I-D.ietf-6tisch-coap].
	But an Hybrid mode may be required as well whereby a single Track is
	added, modified, or removed, for instance if it appears that a Track
	does not perform as expected for, say, PDR. For that case, the
	expectation is that a protocol that flows along a Track (to be), in a
	fashion similar to classical Traffic Engineering (TE) [CCAMP], may be
	used to update the state in the devices. 6TiSCH provides means for a
	device to negotiate a timeSlot with a neighbor, but in general that
	flow was not designed and no protocol was selected and it is expected
	that DetNet will determine the appropriate end-to-end protocols to be
	used in that case.
	Operational System and HMI
	-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	PCE PCE PCE PCE
	-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
	6TiSCH / Device Device Device Device \
	Device- - 6TiSCH
	\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
	----Device------Device------Device------Device--
	Figure 8: Stream Management Entity
	5.4.1. Packet Marking and Handling
	Section "Packet Marking and Handling" of
	[I-D.ietf-6tisch-architecture] describes the packet tagging and
	marking that is expected in 6TiSCH networks.
	5.4.1.1. Tagging Packets for Flow Identification
	For packets that are routed by a PCE along a Track, the tuple formed
	by the IPv6 source address and a local RPLInstanceID is tagged in the
	packets to identify uniquely the Track and associated transmit bundle
	of timeSlots.
	It results that the tagging that is used for a DetNet flow outside		6TiSCH expects that the PCE commands will be issued directly as CoAP
	the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the		requests or be mapped back and forth into CoAP by a gateway function
	packet enters and then leaves the 6TiSCH network.		at the edge of the 6TiSCH network. For instance, it is possible that
			a mapping entity on the backbone transforms a non-CoAP protocol such
			as PCEP into the RESTful interfaces that the 6TiSCH devices support.
			This architecture will be refined to comply with DetNet
			[I-D.finn-detnet-architecture] when the work is formalized. Related
			information about 6TiSCH can be found at
			[I-D.ietf-6tisch-6top-interface] and RPL [RFC6550].
	Note: The method and format used for encoding the RPLInstanceID at		If it appears that a path through the network does not perform as
	6lo is generalized to all 6TiSCH topological Instances, which		expected, a protocol may be used to update the state in the devices,
	includes Tracks.		but in 6TiSCH that flow was not designed and no protocol was selected
			and it is expected that DetNet will determine the appropriate end-to-
			end protocols to be used in that case.
	5.4.1.2. Replication, Retries and Elimination		A "slotFrame" is the base object that the PCE needs to manipulate to
			program a schedule into an LLN node ([I-D.ietf-6tisch-architecture]).
	6TiSCH expects elimination and replication of packets along a complex		The PCE should be able to read energy data from devices, and compute
	Track, but has no position about how the sequence numbers would be		paths that will implement policies on how energy in devices is
	tagged in the packet.		consumed, for instance to ensure that the spent energy does not
			exceeded the available energy over a period of time.
	As it goes, 6TiSCH expects that timeSlots corresponding to copies of		6TiSCH devices can discover their neighbors over the radio using a
	a same packet along a Track are correlated by configuration, and does		mechanism such as beacons, but even though the neighbor information
	not need to process the sequence numbers.		is available in the 6TiSCH interface data model, 6TiSCH does not
			describe a protocol to proactively push the neighborhood information
			to a PCE. DetNet should define this protocol, and it and should
			operate over CoAP. The protocol should be able to carry multiple
			metrics, in particular the same metrics as used for RPL operations
			[RFC6551]
	The semantics of the configuration MUST enable correlated timeSlots		5.3.2.2. 6TiSCH IP Interface
	to be grouped for transmit (and respectively receive) with a 'OR'
	relations, and then a 'AND' relation MUST be configurable between
	groups. The semantics is that if the transmit (and respectively
	receive) operation succeeded in one timeSlot in a 'OR' group, then
	all the other timeSLots in the group are ignored. Now, if there are
	at least two groups, the 'AND' relation between the groups indicates
	that one operation must succeed in each of the groups.
	On the transmit side, timeSlots provisioned for retries along a same		"6top" ([I-D.wang-6tisch-6top-sublayer]) is a logical link control
	branch of a Track are placed a same 'OR' group. The 'OR' relation		sitting between the IP layer and the TSCH MAC layer which provides
	indicates that if a transmission is acknowledged, then further		the link abstraction that is required for IP operations. The 6top
	transmissions SHOULD NOT be attempted for timeSlots in that group.		data model and management interfaces are further discussed in
	There are as many 'OR' groups as there are branches of the Track		[I-D.ietf-6tisch-6top-interface] and [I-D.ietf-6tisch-coap].
	departing from this node. Different 'OR' groups are programmed for
	the purpose of replication, each group corresponding to one branch of
	the Track. The 'AND' relation between the groups indicates that
	transmission over any of branches MUST be attempted regardless of
	whether a transmission succeeded in another branch. It is also
	possible to place cells to different next-hop routers in a same 'OR'
	group. This allows to route along multi-path tracks, trying one
	next-hop and then another only if sending to the first fails.
	On the receive side, all timeSlots are programmed in a same 'OR'		An IP packet that is sent along a 6TiSCH path uses the Differentiated
	group. Retries of a same copy as well as converging branches for		Services Per-Hop-Behavior Group called Deterministic Forwarding, as
	elimination are converged, meaning that the first successful		described in [I-D.svshah-tsvwg-deterministic-forwarding].
	reception is enough and that all the other timeSlots can be ignored.
	5.4.1.3. Differentiated Services Per-Hop-Behavior		5.3.3. 6TiSCH Security Considerations
	Additionally, an IP packet that is sent along a Track uses the		On top of the classical requirements for protection of control
	Differentiated Services Per-Hop-Behavior Group called Deterministic		signaling, it must be noted that 6TiSCH networks operate on limited
	Forwarding, as described in		resources that can be depleted rapidly in a DoS attack on the system,
	[I-D.svshah-tsvwg-deterministic-forwarding].		for instance by placing a rogue device in the network, or by
			obtaining management control and setting up unexpected additional
			paths.
	5.4.2. Topology and capabilities		5.4. Wireless Industrial Asks
	6TiSCH nodes are usually IoT devices, characterized by very limited		6TiSCH depends on DetNet to define:
	amount of memory, just enough buffers to store one or a few IPv6
	packets, and limited bandwidth between peers. It results that a node
	will maintain only a small number of peering information, and will
	not be able to store many packets waiting to be forwarded. Peers can
	be identified through MAC or IPv6 addresses, but a Cryptographically
	Generated Address [RFC3972] (CGA) may also be used.
	Neighbors can be discovered over the radio using mechanism such as		o Configuration (state) and operations for deterministic paths
	beacons, but, though the neighbor information is available in the
	6TiSCH interface data model, 6TiSCH does not describe a protocol to
	pro-actively push the neighborhood information to a PCE. This
	protocol should be described and should operate over CoAP. The
	protocol should be able to carry multiple metrics, in particular the
	same metrics as used for RPL operations [RFC6551]
	The energy that the device consumes in sleep, transmit and receive		o End-to-end protocols for deterministic forwarding (tagging, IP)
	modes can be evaluated and reported. So can the amount of energy
	that is stored in the device and the power that it can be scavenged
	from the environment. The PCE SHOULD be able to compute Tracks that
	will implement policies on how the energy is consumed, for instance
	balance between nodes, ensure that the spent energy does not exceeded
	the scavenged energy over a period of time, etc...
	5.5. Security Considerations		o Protocol for packet replication and elimination
	On top of the classical protection of control signaling that can be		o Protocol for packet automatic retries (ARQ) (specific to wireless)
	expected to support DetNet, it must be noted that 6TiSCH networks
	operate on limited resources that can be depleted rapidly if an
	attacker manages to operate a DoS attack on the system, for instance
	by placing a rogue device in the network, or by obtaining management
	control and to setup extra paths.
	6. Cellular Radio Use Cases		6. Cellular Radio Use Cases
	6.1. Use Case Description		6.1. Use Case Description
	This use case describes the application of deterministic networking		This use case describes the application of deterministic networking
	in the context of cellular telecom transport networks. Important		in the context of cellular telecom transport networks. Important
	elements include time synchronization, clock distribution, and ways		elements include time synchronization, clock distribution, and ways
	of establishing time-sensitive streams for both Layer-2 and Layer-3		of establishing time-sensitive streams for both Layer-2 and Layer-3
	user plane traffic.		user plane traffic.
	6.1.1. Network Architecture		6.1.1. Network Architecture
	Figure 9 illustrates a typical 3GPP-defined cellular network		Figure 7 illustrates a typical 3GPP-defined cellular network
	architecture, which includes "Fronthaul" and "Midhaul" network		architecture, which includes "Fronthaul" and "Midhaul" network
	segments. The "Fronthaul" is the network connecting base stations		segments. The "Fronthaul" is the network connecting base stations
	(baseband processing units) to the remote radio heads (antennas).		(baseband processing units) to the remote radio heads (antennas).
	The "Midhaul" is the network inter-connecting base stations (or small		The "Midhaul" is the network inter-connecting base stations (or small
	cell sites).		cell sites).
	In Figure 9 "eNB" ("E-UTRAN Node B") is the hardware that is		In Figure 7 "eNB" ("E-UTRAN Node B") is the hardware that is
	connected to the mobile phone network which communicates directly		connected to the mobile phone network which communicates directly
	with mobile handsets ([TS36300]).		with mobile handsets ([TS36300]).
	Y (remote radio heads (antennas))		Y (remote radio heads (antennas))
	\		\
	Y__ \.--. .--. +------+		Y__ \.--. .--. +------+
	\_( `. +---+ _(Back`. | 3GPP |		\_( `. +---+ _(Back`. | 3GPP |
	Y------( Front )----|eNB|----( Haul )----| core |		Y------( Front )----|eNB|----( Haul )----| core |
	( ` .Haul ) +---+ ( ` . ) ) | netw |		( ` .Haul ) +---+ ( ` . ) ) | netw |
	/`--(___.-' \ `--(___.-' +------+		/`--(___.-' \ `--(___.-' +------+
	skipping to change at page 55, line 23		skipping to change at page 49, line 23
	Y_/ _( Mid`. \		Y_/ _( Mid`. \
	( Haul ) \		( Haul ) \
	( ` . ) ) \		( ` . ) ) \
	`--(___.-'\_____+---+ (small cell sites)		`--(___.-'\_____+---+ (small cell sites)
	\ |SCe|__Y		\ |SCe|__Y
	+---+ +---+		+---+ +---+
	Y__|eNB|__Y		Y__|eNB|__Y
	+---+		+---+
	Y_/ \_Y ("local" radios)		Y_/ \_Y ("local" radios)
	Figure 9: Generic 3GPP-based Cellular Network Architecture		Figure 7: Generic 3GPP-based Cellular Network Architecture
	The available processing time for Fronthaul networking overhead is		The available processing time for Fronthaul networking overhead is
	limited to the available time after the baseband processing of the		limited to the available time after the baseband processing of the
	radio frame has completed. For example in Long Term Evolution (LTE)		radio frame has completed. For example in Long Term Evolution (LTE)
	radio, processing of a radio frame is allocated 3ms, but typically		radio, processing of a radio frame is allocated 3ms, but typically
	the processing completes much earlier (<400us) allowing the remaining		the processing completes much earlier (<400us) allowing the remaining
	time to be used by the Fronthaul network. This ultimately determines		time to be used by the Fronthaul network. This ultimately determines
	the distance the remote radio heads can be located from the base		the distance the remote radio heads can be located from the base
	stations (200us equals roughly 40 km of optical fiber-based		stations (200us equals roughly 40 km of optical fiber-based
	transport, thus round trip time is 2*200us = 400us).		transport, thus round trip time is 2*200us = 400us).
	skipping to change at page 61, line 39		skipping to change at page 55, line 39
	|Reception| | | | | |Transmission| | CB | | |		|Reception| | | | | |Transmission| | CB | | |
	+---------+ +----+ +-----+ +------------+ +-----+ +-----+		+---------+ +----+ +-----+ +------------+ +-----+ +-----+
	| |		| |
	|----------- |-------------		|----------- |-------------
	| | | |		| | | |
	+------------+ +---------+ +----------+ +------------+		+------------+ +---------+ +----------+ +------------+
	| Joint | | Soft | | Coherent | | Non- |		| Joint | | Soft | | Coherent | | Non- |
	|Equalization| |Combining| | JT | | Coherent JT|		|Equalization| |Combining| | JT | | Coherent JT|
	+------------+ +---------+ +----------+ +------------+		+------------+ +---------+ +----------+ +------------+
	Figure 10: Framework of CoMP Technology		Figure 8: Framework of CoMP Technology
	As shown in Figure 10, CoMP reception and transmission is a framework		As shown in Figure 8, CoMP reception and transmission is a framework
	in which multiple geographically distributed antenna nodes cooperate		in which multiple geographically distributed antenna nodes cooperate
	to improve the performance of the users served in the common		to improve the performance of the users served in the common
	cooperation area. The design principal of CoMP is to extend the		cooperation area. The design principal of CoMP is to extend the
	current single-cell to multi-UE (User Equipment) transmission to a		current single-cell to multi-UE (User Equipment) transmission to a
	multi-cell- to-multi-UEs transmission by base station cooperation.		multi-cell- to-multi-UEs transmission by base station cooperation.
	7.1.2. Delay Sensitivity in CoMP		7.1.2. Delay Sensitivity in CoMP
	In contrast to the single-cell scenario, CoMP has delay-sensitive		In contrast to the single-cell scenario, CoMP has delay-sensitive
	performance parameters, which are "backhaul latency" and "CSI		performance parameters, which are "backhaul latency" and "CSI
	skipping to change at page 64, line 23		skipping to change at page 58, line 23
	Industrial Automation in general refers to automation of		Industrial Automation in general refers to automation of
	manufacturing, quality control and material processing. In this		manufacturing, quality control and material processing. In this
	"machine to machine" (M2M) use case we consider machine units in a		"machine to machine" (M2M) use case we consider machine units in a
	plant floor which periodically exchange data with upstream or		plant floor which periodically exchange data with upstream or
	downstream machine modules and/or a supervisory controller within a		downstream machine modules and/or a supervisory controller within a
	local area network.		local area network.
	The actors of M2M communication are Programmable Logic Controllers		The actors of M2M communication are Programmable Logic Controllers
	(PLCs). Communication between PLCs and between PLCs and the		(PLCs). Communication between PLCs and between PLCs and the
	supervisory PLC (S-PLC) is achieved via critical control/data streams		supervisory PLC (S-PLC) is achieved via critical control/data streams
	Figure 11.		Figure 9.
	S (Sensor)		S (Sensor)
	\ +-----+		\ +-----+
	PLC__ \.--. .--. ---| MES |		PLC__ \.--. .--. ---| MES |
	\_( `. _( `./ +-----+		\_( `. _( `./ +-----+
	A------( Local )-------------( L2 )		A------( Local )-------------( L2 )
	( Net ) ( Net ) +-------+		( Net ) ( Net ) +-------+
	/`--(___.-' `--(___.-' ----| S-PLC |		/`--(___.-' `--(___.-' ----| S-PLC |
	S_/ / PLC .--. / +-------+		S_/ / PLC .--. / +-------+
	A_/ \_( `.		A_/ \_( `.
	(Actuator) ( Local )		(Actuator) ( Local )
	( Net )		( Net )
	/`--(___.-'\		/`--(___.-'\
	/ \ A		/ \ A
	S A		S A
	Figure 11: Current Generic Industrial M2M Network Architecture		Figure 9: Current Generic Industrial M2M Network Architecture
	This use case focuses on PLC-related communications; communication to		This use case focuses on PLC-related communications; communication to
	Manufacturing-Execution-Systems (MESs) are not addressed.		Manufacturing-Execution-Systems (MESs) are not addressed.
	This use case covers only critical control/data streams; non-critical		This use case covers only critical control/data streams; non-critical
	traffic between industrial automation applications (such as		traffic between industrial automation applications (such as
	communication of state, configuration, set-up, and database		communication of state, configuration, set-up, and database
	communication) are adequately served by currently available		communication) are adequately served by currently available
	prioritizing techniques. Such traffic can use up to 80% of the total		prioritizing techniques. Such traffic can use up to 80% of the total
	bandwidth required. There is also a subset of non-time-critical		bandwidth required. There is also a subset of non-time-critical
	skipping to change at page 70, line 45		skipping to change at page 64, line 45
	11.5. Cellular Radio		11.5. Cellular Radio
	This section was derived from draft-korhonen-detnet-telreq-00.		This section was derived from draft-korhonen-detnet-telreq-00.
	11.6. Industrial M2M		11.6. Industrial M2M
	The authors would like to thank Feng Chen and Marcel Kiessling for		The authors would like to thank Feng Chen and Marcel Kiessling for
	their comments and suggestions.		their comments and suggestions.
	11.7. Other		11.7. Internet Applications and CoMP
	This section was derived from draft-zha-detnet-use-case-00.		This section was derived from draft-zha-detnet-use-case-00.
	This document has benefited from reviews, suggestions, comments and		This document has benefited from reviews, suggestions, comments and
	proposed text provided by the following members, listed in		proposed text provided by the following members, listed in
	alphabetical order: Jing Huang, Junru Lin, Lehong Niu and Oilver		alphabetical order: Jing Huang, Junru Lin, Lehong Niu and Oilver
	Huang.		Huang.
	12. Informative References		12. Informative References
End of changes. 61 change blocks.
	560 lines changed or deleted		258 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/