draft-ietf-detnet-use-cases-10.txt		draft-ietf-detnet-use-cases-11.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: January 5, 2017 HARMAN		Expires: April 6, 2017 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
	July 4, 2016		X. Vilajosana
			Worldsensing
			T. Mahmoodi
			King's College London
			S. Spirou
			Intracom Telecom
			P. Vizarreta
			Technical University of Munich, TUM
			October 3, 2016
	Deterministic Networking Use Cases		Deterministic Networking Use Cases
	draft-ietf-detnet-use-cases-10		draft-ietf-detnet-use-cases-11
	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 28 ¶
	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 January 5, 2017.		This Internet-Draft will expire on April 6, 2017.
	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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 5		2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Use Case Description . . . . . . . . . . . . . . . . . . 5		2.1. Use Case Description . . . . . . . . . . . . . . . . . . 6
	2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6		2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6
	2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 6		2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 7
	2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7		2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7
	2.1.4. Deterministic Time to Establish Streaming . . . . . . 8		2.1.4. Deterministic Time to Establish Streaming . . . . . . 8
	2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8		2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8
	2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8		2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8
	2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 8		2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 9
	2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9		2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9
	2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9		2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9
	2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9		2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9
	2.3.3. Integration of Reserved Streams into IT Networks . . 9		2.3.3. Integration of Reserved Streams into IT Networks . . 9
	2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 9		2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 10
	2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10		2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10
	2.3.5.1. Packet Forwarding Rules, VLANs and Subnets . . . 10		2.3.5.1. Packet Forwarding Rules, VLANs and Subnets . . . 10
	2.3.5.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 10		2.3.5.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11
	2.3.6. Latency Optimization by a Central Controller . . . . 11		2.3.6. Latency Optimization by a Central Controller . . . . 11
	2.3.7. Reduced Device Cost Due To Reduced Buffer Memory . . 11		2.3.7. Reduced Device Cost Due To Reduced Buffer Memory . . 11
	2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12		2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12
	3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12		3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12
	3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12		3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12
	3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 12		3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 12
	3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 12		3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 12
	3.1.1.2. Intra-Substation Process Bus Communications . . . 18		3.1.1.2. Intra-Substation Process Bus Communications . . . 18
	3.1.1.3. Wide Area Monitoring and Control Systems . . . . 19		3.1.1.3. Wide Area Monitoring and Control Systems . . . . 19
	3.1.1.4. IEC 61850 WAN engineering guidelines requirement		3.1.1.4. IEC 61850 WAN engineering guidelines requirement
	classification . . . . . . . . . . . . . . . . . 20		classification . . . . . . . . . . . . . . . . . 20
	3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21		3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21
	3.1.3. Distribution use case . . . . . . . . . . . . . . . . 22		3.1.2.1. Control of the Generated Power . . . . . . . . . 21
			3.1.2.2. Control of the Generation Infrastructure . . . . 22
			3.1.3. Distribution use case . . . . . . . . . . . . . . . . 27
	3.1.3.1. Fault Location Isolation and Service Restoration		3.1.3.1. Fault Location Isolation and Service Restoration
	(FLISR) . . . . . . . . . . . . . . . . . . . . . 22		(FLISR) . . . . . . . . . . . . . . . . . . . . . 27
	3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 23		3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 28
	3.2.1. Security Current Practices and Limitations . . . . . 23		3.2.1. Security Current Practices and Limitations . . . . . 28
	3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 25		3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 30
	3.3.1. Migration to Packet-Switched Network . . . . . . . . 25		3.3.1. Migration to Packet-Switched Network . . . . . . . . 31
	3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 26		3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 31
	3.3.2.1. General Telecommunications Requirements . . . . . 26		3.3.2.1. General Telecommunications Requirements . . . . . 31
	3.3.2.2. Specific Network topologies of Smart Grid		3.3.2.2. Specific Network topologies of Smart Grid
	Applications . . . . . . . . . . . . . . . . . . 27		Applications . . . . . . . . . . . . . . . . . . 32
	3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 28		3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 33
	3.3.3. Security Trends in Utility Networks . . . . . . . . . 29		3.3.3. Security Trends in Utility Networks . . . . . . . . . 34
	3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 31		3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 36
	4. Building Automation Systems . . . . . . . . . . . . . . . . . 31		4. Building Automation Systems . . . . . . . . . . . . . . . . . 36
	4.1. Use Case Description . . . . . . . . . . . . . . . . . . 31		4.1. Use Case Description . . . . . . . . . . . . . . . . . . 36
	4.2. Building Automation Systems Today . . . . . . . . . . . . 31		4.2. Building Automation Systems Today . . . . . . . . . . . . 37
	4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 32		4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 37
	4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 33		4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 38
	4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 35		4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 40
	4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 35		4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 40
	4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 35		4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 40
	4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 36		4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 41
	4.2.4. Security Considerations . . . . . . . . . . . . . . . 36		4.2.4. Security Considerations . . . . . . . . . . . . . . . 41
	4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 36		4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 41
	4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 37		4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 42
	5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 37		5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 42
	5.1. Use Case Description . . . . . . . . . . . . . . . . . . 37		5.1. Use Case Description . . . . . . . . . . . . . . . . . . 42
	5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 38		5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 43
	5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 38		5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 43
	5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 39		5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 44
	5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 39		5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 44
	5.3.1. Unified Wireless Network and Management . . . . . . . 39		5.3.1. Unified Wireless Network and Management . . . . . . . 44
	5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 41		5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 46
	5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 42		5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 47
	5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 42		5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 47
	5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 43		5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 48
	5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 44		5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 49
	5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 44		5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 49
	6. Cellular Radio . . . . . . . . . . . . . . . . . . . . . . . 44		6. Cellular Radio . . . . . . . . . . . . . . . . . . . . . . . 49
	6.1. Use Case Description . . . . . . . . . . . . . . . . . . 44		6.1. Use Case Description . . . . . . . . . . . . . . . . . . 49
	6.1.1. Network Architecture . . . . . . . . . . . . . . . . 44		6.1.1. Network Architecture . . . . . . . . . . . . . . . . 49
	6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 45		6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 50
	6.1.3. Time Synchronization Constraints . . . . . . . . . . 46		6.1.3. Time Synchronization Constraints . . . . . . . . . . 51
	6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 48		6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 53
	6.1.5. Security Considerations . . . . . . . . . . . . . . . 48		6.1.5. Security Considerations . . . . . . . . . . . . . . . 53
	6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 49		6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 54
	6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 49		6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 54
	6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 49		6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 54
	6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 50		6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 55
	6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 52		6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 57
	7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 52		7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 57
	7.1. Use Case Description . . . . . . . . . . . . . . . . . . 52		7.1. Use Case Description . . . . . . . . . . . . . . . . . . 57
	7.2. Industrial M2M Communication Today . . . . . . . . . . . 53		7.2. Industrial M2M Communication Today . . . . . . . . . . . 58
	7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 54		7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 59
	7.2.2. Stream Creation and Destruction . . . . . . . . . . . 55		7.2.2. Stream Creation and Destruction . . . . . . . . . . . 60
	7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 55		7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 60
	7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 55		7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 60
	8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 55		8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 60
	9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 56		9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 61
	9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 57		9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 62
	9.2. Internet-based Applications . . . . . . . . . . . . . . . 57		9.2. Internet-based Applications . . . . . . . . . . . . . . . 62
	9.2.1. Use Case Description . . . . . . . . . . . . . . . . 57		9.2.1. Use Case Description . . . . . . . . . . . . . . . . 62
	9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 58		9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 63
	9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 58		9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 63
	9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 58		9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 63
	9.2.2. Internet-Based Applications Today . . . . . . . . . . 58		9.2.2. Internet-Based Applications Today . . . . . . . . . . 63
	9.2.3. Internet-Based Applications Future . . . . . . . . . 58		9.2.3. Internet-Based Applications Future . . . . . . . . . 63
	9.2.4. Internet-Based Applications Asks . . . . . . . . . . 58		9.2.4. Internet-Based Applications Asks . . . . . . . . . . 63
	9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 59		9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 64
	9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 59		9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 64
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
	10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 60		10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 65
	10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 60		10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 65
	10.3. Building Automation Systems . . . . . . . . . . . . . . 60		10.3. Building Automation Systems . . . . . . . . . . . . . . 65
	10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 60		10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 65
	10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 61		10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 66
	10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 61		10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 66
	10.7. Internet Applications and CoMP . . . . . . . . . . . . . 61		10.7. Internet Applications and CoMP . . . . . . . . . . . . . 66
	11. Informative References . . . . . . . . . . . . . . . . . . . 61		10.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 66
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70		11. Informative References . . . . . . . . . . . . . . . . . . . 66
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
	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 20, line 25 ¶		skipping to change at page 20, line 25 ¶
	| Bandwidth | 100 Kbps |		| Bandwidth | 100 Kbps |
	| Availability | 99.9999 |		| Availability | 99.9999 |
	| precise timing | Yes |		| precise timing | Yes |
	| required | |		| required | |
	| Recovery time on | less than 50ms - hitless |		| Recovery time on | less than 50ms - hitless |
	| Node failure | |		| Node failure | |
	| performance | Yes, Mandatory |		| performance | Yes, Mandatory |
	| management | |		| management | |
	| Redundancy | Yes |		| Redundancy | Yes |
	| Packet loss | 1% |		| Packet loss | 1% |
			| Consecutive Packet | At least 1 packet per application cycle |
			| Loss | must be received. |
	+----------------------+--------------------------------------------+		+----------------------+--------------------------------------------+
	Table 7: WAMS Special Communication Requirements		Table 7: WAMS Special Communication Requirements
	3.1.1.4. IEC 61850 WAN engineering guidelines requirement		3.1.1.4. IEC 61850 WAN engineering guidelines requirement
	classification		classification
	The IEC (International Electrotechnical Commission) has recently		The IEC (International Electrotechnical Commission) has recently
	published a Technical Report which offers guidelines on how to define		published a Technical Report which offers guidelines on how to define
	and deploy Wide Area Networks for the interconnections of electric		and deploy Wide Area Networks for the interconnections of electric
	skipping to change at page 21, line 31 ¶		skipping to change at page 21, line 31 ¶
	| | 10-6 | 10-4 | | |		| | 10-6 | 10-4 | | |
	| Recovery delay | Zero | 50 ms | 5 s | 50 s |		| Recovery delay | Zero | 50 ms | 5 s | 50 s |
	| Cyber security | extremely | High | Medium | Medium |		| Cyber security | extremely | High | Medium | Medium |
	| | high | | | |		| | high | | | |
	+----------------+------------+------------+------------+-----------+		+----------------+------------+------------+------------+-----------+
	Table 8: 61850-90-12 Communication Requirements; Courtesy of IEC		Table 8: 61850-90-12 Communication Requirements; Courtesy of IEC
	3.1.2. Generation Use Case		3.1.2. Generation Use Case
	The electrical power generation frequency should be maintained within		Energy generation systems are complex infrastructures that require
	a very narrow band. Deviations from the acceptable frequency range		control of both the generated power and the generation
	are detected and the required signals are sent to the power plants		infrastructure.
	for frequency regulation.
	Automatic generation control (AGC) is a system for adjusting the		3.1.2.1. Control of the Generated Power
			The electrical power generation frequency must be maintained within a
			very narrow band. Deviations from the acceptable frequency range are
			detected and the required signals are sent to the power plants for
			frequency regulation.
			Automatic Generation Control (AGC) is a system for adjusting the
	power output of generators at different power plants, in response to		power output of generators at different power plants, in response to
	changes in the load.		changes in the load.
	+---------------------------------------------------+---------------+		+---------------------------------------------------+---------------+
	| FCAG (Frequency Control Automatic Generation) | Attribute |		| FCAG (Frequency Control Automatic Generation) | Attribute |
	| Requirement | |		| Requirement | |
	+---------------------------------------------------+---------------+		+---------------------------------------------------+---------------+
	| One way maximum delay | 500 ms |		| One way maximum delay | 500 ms |
	| Asymetric delay Required | No |		| Asymetric delay Required | No |
	| Maximum jitter | Not critical |		| Maximum jitter | Not critical |
	skipping to change at page 22, line 26 ¶		skipping to change at page 22, line 26 ¶
	| precise timing required | Yes |		| precise timing required | Yes |
	| Recovery time on Node failure | N/A |		| Recovery time on Node failure | N/A |
	| performance management | Yes, |		| performance management | Yes, |
	| | Mandatory |		| | Mandatory |
	| Redundancy | Yes |		| Redundancy | Yes |
	| Packet loss | 1% |		| Packet loss | 1% |
	+---------------------------------------------------+---------------+		+---------------------------------------------------+---------------+
	Table 9: FCAG Communication Requirements		Table 9: FCAG Communication Requirements
			3.1.2.2. Control of the Generation Infrastructure
			The control of the generation infrastructure combines requirements
			from industrial automation systems and energy generation systems. In
			this section we present the use case of the control of the generation
			infrastructure of a wind turbine.
			|
			|
			| +-----------------+
			| | +----+ |
			| | |WTRM| WGEN |
			WROT x==|===| | |
			| | +----+ WCNV|
			| |WNAC |
			| +---+---WYAW---+--+
			| | |
			| | | +----+
			|WTRF | |WMET|
			| | | |
			Wind Turbine | +--+-+
			Controller | |
			WTUR | | |
			WREP | | |
			WSLG | | |
			WALG | WTOW | |
			Figure 1: Wind Turbine Control Network
			Figure 1 presents the subsystems that operate a wind turbine. These
			subsystems include
			o WROT (Rotor Control)
			o WNAC (Nacelle Control) (nacelle: housing containing the generator)
			o WTRM (Transmission Control)
			o WGEN (Generator)
			o WYAW (Yaw Controller) (of the tower head)
			o WCNV (In-Turbine Power Converter)
			o WMET (External Meteorological Station providing real time
			information to the controllers of the tower)
			Traffic characteristics relevant for the network planning and
			dimensioning process in a wind turbine scenario are listed below.
			The values in this section are based mainly on the relevant
			references [Ahm14] and [Spe09]. Each logical node (Figure 1) is a
			part of the metering network and produces analog measurements and
			status information which must comply with their respective data rate
			constraints.
			+-----------+--------+--------+-------------+---------+-------------+
			| Subsystem | Sensor | Analog | Data Rate | Status | Data rate |
			| | Count | Sample | (bytes/sec) | Sample | (bytes/sec) |
			| | | Count | | Count | |
			+-----------+--------+--------+-------------+---------+-------------+
			| WROT | 14 | 9 | 642 | 5 | 10 |
			| WTRM | 18 | 10 | 2828 | 8 | 16 |
			| WGEN | 14 | 12 | 73764 | 2 | 4 |
			| WCNV | 14 | 12 | 74060 | 2 | 4 |
			| WTRF | 12 | 5 | 73740 | 2 | 4 |
			| WNAC | 12 | 9 | 112 | 3 | 6 |
			| WYAW | 7 | 8 | 220 | 4 | 8 |
			| WTOW | 4 | 1 | 8 | 3 | 6 |
			| WMET | 7 | 7 | 228 | - | - |
			+-----------+--------+--------+-------------+---------+-------------+
			Table 10: Wind Turbine Data Rate Constraints
			Quality of Service (QoS) constraints for different services are
			presented in Table 11. These constraints are defined by IEEE 1646
			standard [IEEE1646] and IEC 61400 standard [IEC61400].
			+---------------------+---------+-------------+---------------------+
			| Service | Latency | Reliability | Packet Loss Rate |
			+---------------------+---------+-------------+---------------------+
			| Analogue measure | 16 ms | 99.99% | < 10-6 |
			| Status information | 16 ms | 99.99% | < 10-6 |
			| Protection traffic | 4 ms | 100.00% | < 10-9 |
			| Reporting and | 1 s | 99.99% | < 10-6 |
			| logging | | | |
			| Video surveillance | 1 s | 99.00% | No specific |
			| | | | requirement |
			| Internet connection | 60 min | 99.00% | No specific |
			| | | | requirement |
			| Control traffic | 16 ms | 100.00% | < 10-9 |
			| Data polling | 16 ms | 99.99% | < 10-6 |
			+---------------------+---------+-------------+---------------------+
			Table 11: Wind Turbine Reliability and Latency Constraints
			3.1.2.2.1. Intra-Domain Network Considerations
			A wind turbine is composed of a large set of subsystems including
			sensors and actuators which require time-critical operation. The
			reliability and latency constraints of these different subsystems is
			shown in Table 11. These subsystems are connected to an intra-domain
			network which is used to monitor and control the operation of the
			turbine and connect it to the SCADA subsystems. The different
			components are interconnected using fiber optics, industrial buses,
			industrial Ethernet, EtherCat, or a combination of them. Industrial
			signaling and control protocols such as Modbus, Profibus, Profinet
			and EtherCat are used directly on top of the Layer 2 transport or
			encapsulated over TCP/IP.
			The Data collected from the sensors and condition monitoring systems
			is multiplexed onto fiber cables for transmission to the base of the
			tower, and to remote control centers. The turbine controller
			continuously monitors the condition of the wind turbine and collects
			statistics on its operation. This controller also manages a large
			number of switches, hydraulic pumps, valves, and motors within the
			wind turbine.
			There is usually a controller both at the bottom of the tower and in
			the nacelle. The communication between these two controllers usually
			takes place using fiber optics instead of copper links. Sometimes, a
			third controller is installed in the hub of the rotor and manages the
			pitch of the blades. That unit usually communicates with the nacelle
			unit using serial communications.
			3.1.2.2.2. Inter-Domain network considerations
			A remote control center belonging to a grid operator regulates the
			power output, enables remote actuation, and monitors the health of
			one or more wind parks in tandem. It connects to the local control
			center in a wind park over the Internet (Figure 2) via firewalls at
			both ends. The AS path between the local control center and the Wind
			Park typically involves several ISPs at different tiers. For
			example, a remote control center in Denmark can regulate a wind park
			in Greece over the normal public AS path between the two locations.
			The remote control center is part of the SCADA system, setting the
			desired power output to the wind park and reading back the result
			once the new power output level has been set. Traffic between the
			remote control center and the wind park typically consists of
			protocols like IEC 60870-5-104 [IEC-60870-5-104], OPC XML-DA
			[OPCXML], Modbus [MODBUS], and SNMP [RFC3411]. Currently, traffic
			flows between the wind farm and the remote control center are best
			effort. QoS requirements are not strict, so no SLAs or service
			provisioning mechanisms (e.g., VPN) are employed. In case of events
			like equipment failure, tolerance for alarm delay is on the order of
			minutes, due to redundant systems already in place.
			+--------------+
			| |
			| |
			| Wind Park #1 +----+
			| | | XXXXXX
			| | | X XXXXXXXX +----------------+
			+--------------+ | XXXX X XXXXX | |
			+---+ XXX | Remote Control |
			XXX Internet +----+ Center |
			+----+X XXX | |
			+--------------+ | XXXXXXX XX | |
			| | | XX XXXXXXX +----------------+
			| | | XXXXX
			| Wind Park #2 +----+
			| |
			| |
			+--------------+
			Figure 2: Wind Turbine Control via Internet
			We expect future use cases which require bounded latency, bounded
			jitter and extraordinary low packet loss for inter-domain traffic
			flows due to the softwarization and virtualization of core wind farm
			equipment (e.g. switches, firewalls and SCADA server components).
			These factors will create opportunities for service providers to
			install new services and dynamically manage them from remote
			locations. For example, to enable fail-over of a local SCADA server,
			a SCADA server in another wind farm site (under the administrative
			control of the same operator) could be utilized temporarily
			(Figure 3). In that case local traffic would be forwarded to the
			remote SCADA server and existing intra-domain QoS and timing
			parameters would have to be met for inter-domain traffic flows.
			+--------------+
			| |
			| |
			| Wind Park #1 +----+
			| | | XXXXXX
			| | | X XXXXXXXX +----------------+
			+--------------+ | XXXX XXXXX | |
			+---+ Operator XXX | Remote Control |
			XXX Administered +----+ Center |
			+----+X WAN XXX | |
			+--------------+ | XXXXXXX XX | |
			| | | XX XXXXXXX +----------------+
			| | | XXXXX
			| Wind Park #2 +----+
			| |
			| |
			+--------------+
			Figure 3: Wind Turbine Control via Operator Administered WAN
	3.1.3. Distribution use case		3.1.3. Distribution use case
	3.1.3.1. Fault Location Isolation and Service Restoration (FLISR)		3.1.3.1. Fault Location Isolation and Service Restoration (FLISR)
	Fault Location, Isolation, and Service Restoration (FLISR) refers to		Fault Location, Isolation, and Service Restoration (FLISR) refers to
	the ability to automatically locate the fault, isolate the fault, and		the ability to automatically locate the fault, isolate the fault, and
	restore service in the distribution network. This will likely be the		restore service in the distribution network. This will likely be the
	first widespread application of distributed intelligence in the grid.		first widespread application of distributed intelligence in the grid.
	Static power switch status (open/closed) in the network dictates the		Static power switch status (open/closed) in the network dictates the
	skipping to change at page 23, line 27 ¶		skipping to change at page 28, line 27 ¶
	| precise timing | Yes |		| precise timing | Yes |
	| required | |		| required | |
	| Recovery time on | Depends on customer impact |		| Recovery time on | Depends on customer impact |
	| Node failure | |		| Node failure | |
	| performance | Yes, Mandatory |		| performance | Yes, Mandatory |
	| management | |		| management | |
	| Redundancy | Yes |		| Redundancy | Yes |
	| Packet loss | 0.1% |		| Packet loss | 0.1% |
	+----------------------+--------------------------------------------+		+----------------------+--------------------------------------------+
	Table 10: FLISR Communication Requirements		Table 12: FLISR Communication Requirements
	3.2. Electrical Utilities Today		3.2. Electrical Utilities Today
	Many utilities still rely on complex environments formed of multiple		Many utilities still rely on complex environments formed of multiple
	application-specific proprietary networks, including TDM networks.		application-specific proprietary networks, including TDM networks.
	In this kind of environment there is no mixing of OT and IT		In this kind of environment there is no mixing of OT and IT
	applications on the same network, and information is siloed between		applications on the same network, and information is siloed between
	operational areas.		operational areas.
	skipping to change at page 25, line 37 ¶		skipping to change at page 30, line 37 ¶
	The key to modernizing grid telecommunications is to provide a		The key to modernizing grid telecommunications is to provide a
	common, adaptable, multi-service network infrastructure for the		common, adaptable, multi-service network infrastructure for the
	entire utility organization. Such a network serves as the platform		entire utility organization. Such a network serves as the platform
	for current capabilities while enabling future expansion of the		for current capabilities while enabling future expansion of the
	network to accommodate new applications and services.		network to accommodate new applications and services.
	To meet this diverse set of requirements, both today and in the		To meet this diverse set of requirements, both today and in the
	future, the next generation utility telecommunnications network will		future, the next generation utility telecommunnications network will
	be based on open-standards-based IP architecture. An end-to-end IP		be based on open-standards-based IP architecture. An end-to-end IP
	architecture takes advantage of nearly three decades of IP technology		architecture takes advantage of nearly three decades of IP technology
	development, facilitating interoperability across disparate networks		development, facilitating interoperability and device management
	and devices, as it has been already demonstrated in many mission-		across disparate networks and devices, as it has been already
	critical and highly secure networks.		demonstrated in many mission-critical and highly secure networks.
	IPv6 is seen as a future telecommunications technology for the Smart		IPv6 is seen as a future telecommunications technology for the Smart
	Grid; the IEC (International Electrotechnical Commission) and		Grid; the IEC (International Electrotechnical Commission) and
	different National Committees have mandated a specific adhoc group		different National Committees have mandated a specific adhoc group
	(AHG8) to define the migration strategy to IPv6 for all the IEC TC57		(AHG8) to define the migration strategy to IPv6 for all the IEC TC57
	power automation standards.		power automation standards.
			We expect cloud-based SCADA systems to control and monitor the
			critical and non-critical subsystems of generation systems, for
			example wind farms.
	3.3.1. Migration to Packet-Switched Network		3.3.1. Migration to Packet-Switched Network
	Throughout the world, utilities are increasingly planning for a		Throughout the world, utilities are increasingly planning for a
	future based on smart grid applications requiring advanced		future based on smart grid applications requiring advanced
	telecommunications systems. Many of these applications utilize		telecommunications systems. Many of these applications utilize
	packet connectivity for communicating information and control signals		packet connectivity for communicating information and control signals
	across the utility's Wide Area Network (WAN), made possible by		across the utility's Wide Area Network (WAN), made possible by
	technologies such as multiprotocol label switching (MPLS). The data		technologies such as multiprotocol label switching (MPLS). The data
	that traverses the utility WAN includes:		that traverses the utility WAN includes:
	skipping to change at page 31, line 13 ¶		skipping to change at page 36, line 13 ¶
	detection and mitigation.		detection and mitigation.
	3.4. Electrical Utilities Asks		3.4. Electrical Utilities Asks
	o Mixed L2 and L3 topologies		o Mixed L2 and L3 topologies
	o Deterministic behavior		o Deterministic behavior
	o Bounded latency and jitter		o Bounded latency and jitter
			o Tight feedback intervals
	o High availability, low recovery time		o High availability, low recovery time
	o Redundancy, low packet loss		o Redundancy, low packet loss
	o Precise timing		o Precise timing
	o Centralized computing of deterministic paths		o Centralized computing of deterministic paths
	o Distributed configuration may also be useful		o Distributed configuration may also be useful
	skipping to change at page 32, line 4 ¶		skipping to change at page 37, line 6 ¶
	o Stores the measured data.		o Stores the measured data.
	o Provides the measured data to BAS systems and operators.		o Provides the measured data to BAS systems and operators.
	o Generates alarms for abnormal state of devices.		o Generates alarms for abnormal state of devices.
	o Controls devices (e.g. turn off room lights at 10:00 PM).		o Controls devices (e.g. turn off room lights at 10:00 PM).
	4.2. Building Automation Systems Today		4.2. Building Automation Systems Today
	4.2.1. BAS Architecture		4.2.1. BAS Architecture
	A typical BAS architecture of today is shown in Figure 1.		A typical BAS architecture of today is shown in Figure 4.
	+----------------------------+		+----------------------------+
	| |		| |
	| BMS HMI |		| BMS HMI |
	| | | |		| | | |
	| +----------------------+ |		| +----------------------+ |
	| | Management Network | |		| | Management Network | |
	| +----------------------+ |		| +----------------------+ |
	| | | |		| | | |
	| LC LC |		| LC LC |
	skipping to change at page 32, line 30 ¶		skipping to change at page 37, line 33 ¶
	| +----------------------+ |		| +----------------------+ |
	| | | | | |		| | | | | |
	| Dev Dev Dev Dev |		| Dev Dev Dev Dev |
	| |		| |
	+----------------------------+		+----------------------------+
	BMS := Building Management Server		BMS := Building Management Server
	HMI := Human Machine Interface		HMI := Human Machine Interface
	LC := Local Controller		LC := Local Controller
	Figure 1: BAS architecture		Figure 4: BAS architecture
	There are typically two layers of network in a BAS. The upper one is		There are typically two layers of network in a BAS. The upper one is
	called the Management Network and the lower one is called the Field		called the Management Network and the lower one is called the Field
	Network. In management networks an IP-based communication protocol		Network. In management networks an IP-based communication protocol
	is used, while in field networks non-IP based communication protocols		is used, while in field networks non-IP based communication protocols
	("field protocols") are mainly used. Field networks have specific		("field protocols") are mainly used. Field networks have specific
	timing requirements, whereas management networks can be best-effort.		timing requirements, whereas management networks can be best-effort.
	A Human Machine Interface (HMI) is typically a desktop PC used by		A Human Machine Interface (HMI) is typically a desktop PC used by
	operators to monitor and display device states, send device control		operators to monitor and display device states, send device control
	skipping to change at page 33, line 26 ¶		skipping to change at page 38, line 29 ¶
	There are many field protocols used today; some are standards-based		There are many field protocols used today; some are standards-based
	and others are proprietary (see standards [lontalk], [modbus],		and others are proprietary (see standards [lontalk], [modbus],
	[profibus] and [flnet]). The result is that BASs have multiple MAC/		[profibus] and [flnet]). The result is that BASs have multiple MAC/
	PHY modules and interfaces. This makes BASs more expensive, slower		PHY modules and interfaces. This makes BASs more expensive, slower
	to develop, and can result in "vendor lock-in" with multiple types of		to develop, and can result in "vendor lock-in" with multiple types of
	management applications.		management applications.
	4.2.2. BAS Deployment Model		4.2.2. BAS Deployment Model
	An example BAS for medium or large buildings is shown in Figure 2.		An example BAS for medium or large buildings is shown in Figure 5.
	The physical layout spans multiple floors, and there is a monitoring		The physical layout spans multiple floors, and there is a monitoring
	room where the BAS management entities are located. Each floor will		room where the BAS management entities are located. Each floor will
	have one or more LCs depending upon the number of devices connected		have one or more LCs depending upon the number of devices connected
	to the field network.		to the field network.
	+--------------------------------------------------+		+--------------------------------------------------+
	| Floor 3 |		| Floor 3 |
	| +----LC~~~~+~~~~~+~~~~~+ |		| +----LC~~~~+~~~~~+~~~~~+ |
	| | | | | |		| | | | | |
	| | Dev Dev Dev |		| | Dev Dev Dev |
	skipping to change at page 34, line 28 ¶		skipping to change at page 39, line 28 ¶
	| | Floor 1 |		| | Floor 1 |
	| +----LC~~~~+~~~~~+~~~~~+ +-----------------|		| +----LC~~~~+~~~~~+~~~~~+ +-----------------|
	| | | | | | Monitoring Room |		| | | | | | Monitoring Room |
	| | Dev Dev Dev | |		| | Dev Dev Dev | |
	| | | BMS HMI |		| | | BMS HMI |
	| | Management Network | | | |		| | Management Network | | | |
	| +--------------------------------+-----+ |		| +--------------------------------+-----+ |
	| | |		| | |
	+--------------------------------------------------+		+--------------------------------------------------+
	Figure 2: BAS Deployment model for Medium/Large Buildings		Figure 5: BAS Deployment model for Medium/Large Buildings
	Each LC is connected to the monitoring room via the Management		Each LC is connected to the monitoring room via the Management
	network, and the management functions are performed within the		network, and the management functions are performed within the
	building. In most cases, fast Ethernet (e.g. 100BASE-T) is used for		building. In most cases, fast Ethernet (e.g. 100BASE-T) is used for
	the management network. Since the management network is non-		the management network. Since the management network is non-
	realtime, use of Ethernet without quality of service is sufficient		realtime, use of Ethernet without quality of service is sufficient
	for today's deployment.		for today's deployment.
	In the field network a variety of physical interfaces such as RS232C		In the field network a variety of physical interfaces such as RS232C
	and RS485 are used, which have specific timing requirements. Thus if		and RS485 are used, which have specific timing requirements. Thus if
	a field network is to be replaced with an Ethernet or wireless		a field network is to be replaced with an Ethernet or wireless
	network, such networks must support time-critical deterministic		network, such networks must support time-critical deterministic
	flows.		flows.
	In Figure 3, another deployment model is presented in which the		In Figure 6, another deployment model is presented in which the
	management system is hosted remotely. This is becoming popular for		management system is hosted remotely. This is becoming popular for
	small office and residential buildings in which a standalone		small office and residential buildings in which a standalone
	monitoring system is not cost-effective.		monitoring system is not cost-effective.
	+---------------+		+---------------+
	| Remote Center |		| Remote Center |
	| |		| |
	| BMS HMI |		| BMS HMI |
	+------------------------------------+ | | | |		+------------------------------------+ | | | |
	| Floor 2 | | +---+---+ |		| Floor 2 | | +---+---+ |
	skipping to change at page 35, line 26 ¶		skipping to change at page 40, line 26 ¶
	| | Floor 1 | |		| | Floor 1 | |
	| +----LC~~~~+~~~~~+ | |		| +----LC~~~~+~~~~~+ | |
	| | | | | |		| | | | | |
	| | Dev Dev | |		| | Dev Dev | |
	| | | |		| | | |
	| | Management Network | WAN |		| | Management Network | WAN |
	| +------------------------Router-------------+		| +------------------------Router-------------+
	| |		| |
	+------------------------------------+		+------------------------------------+
	Figure 3: Deployment model for Small Buildings		Figure 6: Deployment model for Small Buildings
	Some interoperability is possible today in the Management Network,		Some interoperability is possible today in the Management Network,
	but not in today's field networks due to their non-IP-based design.		but not in today's field networks due to their non-IP-based design.
	4.2.3. Use Cases for Field Networks		4.2.3. Use Cases for Field Networks
	Below are use cases for Environmental Monitoring, Fire Detection, and		Below are use cases for Environmental Monitoring, Fire Detection, and
	Feedback Control, and their implications for field network		Feedback Control, and their implications for field network
	performance.		performance.
	skipping to change at page 39, line 41 ¶		skipping to change at page 44, line 41 ¶
	6TiSCH is not yet fully specified, so it cannot be used in today's		6TiSCH is not yet fully specified, so it cannot be used in today's
	applications.		applications.
	5.3. Wireless Industrial Future		5.3. Wireless Industrial Future
	5.3.1. Unified Wireless Network and Management		5.3.1. Unified Wireless Network and Management
	We expect DetNet and 6TiSCH together to enable converged transport of		We expect DetNet and 6TiSCH together to enable converged transport of
	deterministic and best-effort traffic flows between real-time		deterministic and best-effort traffic flows between real-time
	industrial devices and wide area networks via IP routing. A high		industrial devices and wide area networks via IP routing. A high
	level view of a basic such network is shown in Figure 4.		level view of a basic such network is shown in Figure 7.
	---+-------- ............ ------------		---+-------- ............ ------------
	| 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 6TiSCH Network		Figure 7: Basic 6TiSCH Network
	Figure 5 shows a backbone router federating multiple synchronized		Figure 8 shows a backbone router federating multiple synchronized
	6TiSCH subnets into a single subnet connected to the external		6TiSCH subnets into a single subnet connected to the external
	network.		network.
	---+-------- ............ ------------		---+-------- ............ ------------
	| External Network |		| External Network |
	| +-----+		| +-----+
	| +-----+ | NME |		| +-----+ | NME |
	+-----+ | +-----+ | |		+-----+ | +-----+ | |
	| | Router | | PCE | +-----+		| | Router | | PCE | +-----+
	| | +--| |		| | +--| |
	skipping to change at page 40, line 45 ¶		skipping to change at page 45, line 45 ¶
	| | |		| | |
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| | 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 6TiSCH Network		Figure 8: Extended 6TiSCH Network
	The backbone router must ensure end-to-end deterministic behavior		The backbone router must ensure end-to-end deterministic behavior
	between the LLN and the backbone. We would like to see this		between the LLN and the backbone. We would like to see this
	accomplished in conformance with the work done in		accomplished in conformance with the work done in
	[I-D.finn-detnet-architecture] with respect to Layer-3 aspects of		[I-D.finn-detnet-architecture] with respect to Layer-3 aspects of
	deterministic networks that span multiple Layer-2 domains.		deterministic networks that span multiple Layer-2 domains.
	The PCE must compute a deterministic path end-to-end across the TSCH		The PCE must compute a deterministic path end-to-end across the TSCH
	network and IEEE802.1 TSN Ethernet backbone, and DetNet protocols are		network and IEEE802.1 TSN Ethernet backbone, and DetNet protocols are
	expected to enable end-to-end deterministic forwarding.		expected to enable end-to-end deterministic forwarding.
	skipping to change at page 41, line 28 ¶		skipping to change at page 46, line 28 ¶
	+--|--+ +--|--+		+--|--+ +--|--+
	| | | 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: 6TiSCH Network with PRE		Figure 9: 6TiSCH Network with PRE
	5.3.1.1. PCE and 6TiSCH ARQ Retries		5.3.1.1. PCE and 6TiSCH ARQ Retries
	Note: The possible use of ARQ techniques in DetNet is currently		Note: The possible use of ARQ techniques in DetNet is currently
	considered a possible design alternative.		considered a possible design alternative.
	6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism		6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism
	to provide higher reliability of packet delivery. ARQ is related to		to provide higher reliability of packet delivery. ARQ is related to
	packet replication and elimination because there are two independent		packet replication and elimination because there are two independent
	paths for packets to arrive at the destination, and if an expected		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		packed does not arrive on one path then it checks for the packet on
	the second path.		the second path.
	Although to date this mechanism is only used by wireless networks,		Although to date this mechanism is only used by wireless networks,
	this may be a technique that would be appropriate for DetNet and so		this may be a technique that would be appropriate for DetNet and so
	aspects of the enabling protocol could be co-developed.		aspects of the enabling protocol could be co-developed.
	For example, in Figure 6, a Track is laid out from a field device in		For example, in Figure 9, 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		a 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN
	backbone.		backbone.
	In ARQ the Replication function in the field device sends a copy of		In ARQ the Replication function in the field device sends a copy of
	each packet over two different branches, and the PCE schedules each		each 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		hop of 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 arrives within the allocated time. If two copies		of the packet still arrives within the allocated time. If two copies
	make it to the IoT gateway, the Elimination function in the gateway		make it to the IoT gateway, the Elimination function in the gateway
	ignores the extra packet and presents only one copy to upper layers.		ignores the extra packet and presents only one copy to upper layers.
	skipping to change at page 44, line 40 ¶		skipping to change at page 49, line 40 ¶
	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 7 illustrates a typical 3GPP-defined cellular network		Figure 10 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 7 "eNB" ("E-UTRAN Node B") is the hardware that is		In Figure 10 "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 45, line 23 ¶		skipping to change at page 50, 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 7: Generic 3GPP-based Cellular Network Architecture		Figure 10: Generic 3GPP-based Cellular Network Architecture
	6.1.2. Delay Constraints		6.1.2. Delay Constraints
	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 the		radio, processing of a radio frame is allocated 3ms but typically the
	processing uses most of it, allowing only a small fraction to be used		processing uses most of it, allowing only a small fraction to be used
	by the Fronthaul network (e.g. up to 250us one-way delay, though the		by the Fronthaul network (e.g. up to 250us one-way delay, though the
	existing spec ([NGMN-fronth]) supports delay only up to 100us). This		existing spec ([NGMN-fronth]) supports delay only up to 100us). This
	skipping to change at page 52, line 37 ¶		skipping to change at page 57, line 37 ¶
	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 8.		Figure 11.
	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 8: Current Generic Industrial M2M Network Architecture		Figure 11: 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 61, line 23 ¶		skipping to change at page 66, line 23 ¶
	10.7. Internet Applications and CoMP		10.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.
			10.8. Electrical Utilities
			The wind power generation use case has been extracted from the study
			of Wind Farms conducted within the 5GPPP Virtuwind Project. The
			project is funded by the European Union's Horizon 2020 research and
			innovation programme under grant agreement No 671648 (VirtuWind).
	11. Informative References		11. Informative References
	[ACE] IETF, "Authentication and Authorization for Constrained		[ACE] IETF, "Authentication and Authorization for Constrained
	Environments", <https://datatracker.ietf.org/doc/charter-		Environments", <https://datatracker.ietf.org/doc/charter-
	ietf-ace/>.		ietf-ace/>.
			[Ahm14] Ahmed, M. and R. Kim, "Communication network architectures
			for smart-wind power farms.", Energies, p. 3900-3921. ,
			June 2014.
	[bacnetip]		[bacnetip]
	ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP",		ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP",
	January 1999.		January 1999.
	[CCAMP] IETF, "Common Control and Measurement Plane",		[CCAMP] IETF, "Common Control and Measurement Plane",
	<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.		<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
	[CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND		[CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND
	ENHANCEMENT", NGMN Alliance NGMN_RANEV_D3_CoMP_Evaluation_		ENHANCEMENT", NGMN Alliance NGMN_RANEV_D3_CoMP_Evaluation_
	and_Enhancement_v2.0, March 2015,		and_Enhancement_v2.0, March 2015,
	skipping to change at page 62, line 25 ¶		skipping to change at page 67, line 35 ¶
	<https://datatracker.ietf.org/doc/charter-ietf-dice/>.		<https://datatracker.ietf.org/doc/charter-ietf-dice/>.
	[EA12] Evans, P. and M. Annunziata, "Industrial Internet: Pushing		[EA12] Evans, P. and M. Annunziata, "Industrial Internet: Pushing
	the Boundaries of Minds and Machines", November 2012.		the Boundaries of Minds and Machines", November 2012.
	[ESPN_DC2]		[ESPN_DC2]
	Daley, D., "ESPN's DC2 Scales AVB Large", 2014,		Daley, D., "ESPN's DC2 Scales AVB Large", 2014,
	<http://sportsvideo.org/main/blog/2014/06/		<http://sportsvideo.org/main/blog/2014/06/
	espns-dc2-scales-avb-large>.		espns-dc2-scales-avb-large>.
	[flnet] Japan Electrical Manufacturers' Association, "JEMA 1479 -		[flnet] Japan Electrical Manufacturers Association, "JEMA 1479 -
	English Edition", September 2012.		English Edition", September 2012.
	[Fronthaul]		[Fronthaul]
	Chen, D. and T. Mustala, "Ethernet Fronthaul		Chen, D. and T. Mustala, "Ethernet Fronthaul
	Considerations", IEEE 1904.3, February 2015,		Considerations", IEEE 1904.3, February 2015,
	<http://www.ieee1904.org/3/meeting_archive/2015/02/		<http://www.ieee1904.org/3/meeting_archive/2015/02/
	tf3_1502_che n_1a.pdf>.		tf3_1502_che n_1a.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.finn-detnet-architecture]		[I-D.finn-detnet-architecture]
	Finn, N., Thubert, P., and M. Teener, "Deterministic		Finn, N. and P. Thubert, "Deterministic Networking
	Networking Architecture", draft-finn-detnet-		Architecture", draft-finn-detnet-architecture-08 (work in
	architecture-04 (work in progress), March 2016.		progress), August 2016.
	[I-D.finn-detnet-problem-statement]		[I-D.finn-detnet-problem-statement]
	Finn, N. and P. Thubert, "Deterministic Networking Problem		Finn, N. and P. Thubert, "Deterministic Networking Problem
	Statement", draft-finn-detnet-problem-statement-05 (work		Statement", draft-finn-detnet-problem-statement-05 (work
	in progress), March 2016.		in progress), March 2016.
	[I-D.ietf-6tisch-6top-interface]		[I-D.ietf-6tisch-6top-interface]
	Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer		Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
	(6top) Interface", draft-ietf-6tisch-6top-interface-04		(6top) Interface", draft-ietf-6tisch-6top-interface-04
	(work in progress), July 2015.		(work in progress), July 2015.
	skipping to change at page 63, line 29 ¶		skipping to change at page 68, line 39 ¶
	progress), March 2016.		progress), March 2016.
	[I-D.ietf-ipv6-multilink-subnets]		[I-D.ietf-ipv6-multilink-subnets]
	Thaler, D. and C. Huitema, "Multi-link Subnet Support in		Thaler, D. and C. Huitema, "Multi-link Subnet Support in
	IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in		IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
	progress), July 2002.		progress), July 2002.
	[I-D.ietf-mpls-residence-time]		[I-D.ietf-mpls-residence-time]
	Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,		Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
	and S. Vainshtein, "Residence Time Measurement in MPLS		and S. Vainshtein, "Residence Time Measurement in MPLS
	network", draft-ietf-mpls-residence-time-09 (work in		network", draft-ietf-mpls-residence-time-11 (work in
	progress), April 2016.		progress), July 2016.
	[I-D.ietf-roll-rpl-industrial-applicability]		[I-D.ietf-roll-rpl-industrial-applicability]
	Phinney, T., Thubert, P., and R. Assimiti, "RPL		Phinney, T., Thubert, P., and R. Assimiti, "RPL
	applicability in industrial networks", draft-ietf-roll-		applicability in industrial networks", draft-ietf-roll-
	rpl-industrial-applicability-02 (work in progress),		rpl-industrial-applicability-02 (work in progress),
	October 2013.		October 2013.
	[I-D.ietf-tictoc-1588overmpls]		[I-D.ietf-tictoc-1588overmpls]
	Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.		Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
	Montini, "Transporting Timing messages over MPLS		Montini, "Transporting Timing messages over MPLS
	skipping to change at page 64, line 15 ¶		skipping to change at page 69, line 25 ¶
	[I-D.thubert-6lowpan-backbone-router]		[I-D.thubert-6lowpan-backbone-router]
	Thubert, P., "6LoWPAN Backbone Router", draft-thubert-		Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
	6lowpan-backbone-router-03 (work in progress), February		6lowpan-backbone-router-03 (work in progress), February
	2013.		2013.
	[I-D.wang-6tisch-6top-sublayer]		[I-D.wang-6tisch-6top-sublayer]
	Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer		Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
	(6top)", draft-wang-6tisch-6top-sublayer-04 (work in		(6top)", draft-wang-6tisch-6top-sublayer-04 (work in
	progress), November 2015.		progress), November 2015.
			[IEC-60870-5-104]
			International Electrotechnical Commission, "International
			Standard IEC 60870-5-104: Network access for IEC
			60870-5-101 using standard transport profiles", June 2006.
			[IEC61400]
			"International standard 61400-25: Communications for
			monitoring and control of wind power plants", June 2013.
	[IEC61850-90-12]		[IEC61850-90-12]
	TC57 WG10, IEC., "IEC 61850-90-12 TR: Communication		TC57 WG10, IEC., "IEC 61850-90-12 TR: Communication
	networks and systems for power utility automation - Part		networks and systems for power utility automation - Part
	90-12: Wide area network engineering guidelines", 2015.		90-12: Wide area network engineering guidelines", 2015.
	[IEC62439-3:2012]		[IEC62439-3:2012]
	TC65, IEC., "IEC 62439-3: Industrial communication		TC65, IEC., "IEC 62439-3: Industrial communication
	networks - High availability automation networks - Part 3:		networks - High availability automation networks - Part 3:
	Parallel Redundancy Protocol (PRP) and High-availability		Parallel Redundancy Protocol (PRP) and High-availability
	Seamless Redundancy (HSR)", 2012.		Seamless Redundancy (HSR)", 2012.
	[IEEE1588]		[IEEE1588]
	IEEE, "IEEE Standard for a Precision Clock Synchronization		IEEE, "IEEE Standard for a Precision Clock Synchronization
	Protocol for Networked Measurement and Control Systems",		Protocol for Networked Measurement and Control Systems",
	IEEE Std 1588-2008, 2008,		IEEE Std 1588-2008, 2008,
	<http://standards.ieee.org/findstds/		<http://standards.ieee.org/findstds/
	standard/1588-2008.html>.		standard/1588-2008.html>.
			[IEEE1646]
			"Communication Delivery Time Performance Requirements for
			Electric Power Substation Automation", IEEE Standard
			1646-2004 , Apr 2004.
	[IEEE1722]		[IEEE1722]
	IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport		IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport
	Protocol for Time Sensitive Applications in a Bridged		Protocol for Time Sensitive Applications in a Bridged
	Local Area Network", IEEE Std 1722-2011, 2011,		Local Area Network", IEEE Std 1722-2011, 2011,
	<http://standards.ieee.org/findstds/		<http://standards.ieee.org/findstds/
	standard/1722-2011.html>.		standard/1722-2011.html>.
	[IEEE19043]		[IEEE19043]
	IEEE Standards Association, "IEEE 1904.3 TF", IEEE 1904.3,		IEEE Standards Association, "IEEE 1904.3 TF", IEEE 1904.3,
	2015, <http://www.ieee1904.org/3/tf3_home.shtml>.		2015, <http://www.ieee1904.org/3/tf3_home.shtml>.
	skipping to change at page 66, line 35 ¶		skipping to change at page 72, line 13 ¶
	MEF_22.1.1.pdf>.		MEF_22.1.1.pdf>.
	[METIS] METIS, "Scenarios, requirements and KPIs for 5G mobile and		[METIS] METIS, "Scenarios, requirements and KPIs for 5G mobile and
	wireless system", ICT-317669-METIS/D1.1 ICT-		wireless system", ICT-317669-METIS/D1.1 ICT-
	317669-METIS/D1.1, April 2013, <https://www.metis2020.com/		317669-METIS/D1.1, April 2013, <https://www.metis2020.com/
	wp-content/uploads/deliverables/METIS_D1.1_v1.pdf>.		wp-content/uploads/deliverables/METIS_D1.1_v1.pdf>.
	[modbus] Modbus Organization, "MODBUS APPLICATION PROTOCOL		[modbus] Modbus Organization, "MODBUS APPLICATION PROTOCOL
	SPECIFICATION V1.1b", December 2006.		SPECIFICATION V1.1b", December 2006.
			[MODBUS] Modbus Organization, Inc., "MODBUS Application Protocol
			Specification", Apr 2012.
	[net5G] Ericsson, "5G Radio Access, Challenges for 2020 and		[net5G] Ericsson, "5G Radio Access, Challenges for 2020 and
	Beyond", Ericsson white paper wp-5g, June 2013,		Beyond", Ericsson white paper wp-5g, June 2013,
	<http://www.ericsson.com/res/docs/whitepapers/wp-5g.pdf>.		<http://www.ericsson.com/res/docs/whitepapers/wp-5g.pdf>.
	[NGMN] NGMN Alliance, "5G White Paper", NGMN 5G White Paper v1.0,		[NGMN] NGMN Alliance, "5G White Paper", NGMN 5G White Paper v1.0,
	February 2015, <https://www.ngmn.org/uploads/media/		February 2015, <https://www.ngmn.org/uploads/media/
	NGMN_5G_White_Paper_V1_0.pdf>.		NGMN_5G_White_Paper_V1_0.pdf>.
	[NGMN-fronth]		[NGMN-fronth]
	NGMN Alliance, "Fronthaul Requirements for C-RAN", March		NGMN Alliance, "Fronthaul Requirements for C-RAN", March
	2015, <https://www.ngmn.org/uploads/media/NGMN_RANEV_D1_C-		2015, <https://www.ngmn.org/uploads/media/NGMN_RANEV_D1_C-
	RAN_Fronthaul_Requirements_v1.0.pdf>.		RAN_Fronthaul_Requirements_v1.0.pdf>.
			[OPCXML] OPC Foundation, "OPC XML-Data Access Specification", Dec
			2004.
	[PCE] IETF, "Path Computation Element",		[PCE] IETF, "Path Computation Element",
	<https://datatracker.ietf.org/doc/charter-ietf-pce/>.		<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
	[profibus]		[profibus]
	IEC, "IEC 61158 Type 3 - Profibus DP", January 2001.		IEC, "IEC 61158 Type 3 - Profibus DP", January 2001.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 67, line 35 ¶		skipping to change at page 73, line 20 ¶
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,		Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
	<http://www.rfc-editor.org/info/rfc3209>.		<http://www.rfc-editor.org/info/rfc3209>.
	[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation		[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
	Metric for IP Performance Metrics (IPPM)", RFC 3393,		Metric for IP Performance Metrics (IPPM)", RFC 3393,
	DOI 10.17487/RFC3393, November 2002,		DOI 10.17487/RFC3393, November 2002,
	<http://www.rfc-editor.org/info/rfc3393>.		<http://www.rfc-editor.org/info/rfc3393>.
			[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
			Architecture for Describing Simple Network Management
			Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
			DOI 10.17487/RFC3411, December 2002,
			<http://www.rfc-editor.org/info/rfc3411>.
	[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between		[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
	Information Models and Data Models", RFC 3444,		Information Models and Data Models", RFC 3444,
	DOI 10.17487/RFC3444, January 2003,		DOI 10.17487/RFC3444, January 2003,
	<http://www.rfc-editor.org/info/rfc3444>.		<http://www.rfc-editor.org/info/rfc3444>.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, DOI 10.17487/RFC3972, March 2005,		RFC 3972, DOI 10.17487/RFC3972, March 2005,
	<http://www.rfc-editor.org/info/rfc3972>.		<http://www.rfc-editor.org/info/rfc3972>.
	[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation		[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
	skipping to change at page 69, line 17 ¶		skipping to change at page 75, line 5 ¶
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,		RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<http://www.rfc-editor.org/info/rfc6775>.		<http://www.rfc-editor.org/info/rfc6775>.
	[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using		[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
	IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the		IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
	Internet of Things (IoT): Problem Statement", RFC 7554,		Internet of Things (IoT): Problem Statement", RFC 7554,
	DOI 10.17487/RFC7554, May 2015,		DOI 10.17487/RFC7554, May 2015,
	<http://www.rfc-editor.org/info/rfc7554>.		<http://www.rfc-editor.org/info/rfc7554>.
			[Spe09] Sperotto, A., Sadre, R., Vliet, F., and A. Pras, "A First
			Look into SCADA Network Traffic", IP Operations and
			Management, p. 518-521. , June 2009.
	[SRP_LATENCY]		[SRP_LATENCY]
	Gunther, C., "Specifying SRP Latency", 2014,		Gunther, C., "Specifying SRP Latency", 2014,
	<http://www.ieee802.org/1/files/public/docs2014/		<http://www.ieee802.org/1/files/public/docs2014/
	cc-cgunther-acceptable-latency-0314-v01.pdf>.		cc-cgunther-acceptable-latency-0314-v01.pdf>.
	[STUDIO_IP]		[STUDIO_IP]
	Mace, G., "IP Networked Studio Infrastructure for		Mace, G., "IP Networked Studio Infrastructure for
	Synchronized & Real-Time Multimedia Transmissions", 2007,		Synchronized & Real-Time Multimedia Transmissions", 2007,
	<http://www.ieee802.org/1/files/public/docs2047/		<http://www.ieee802.org/1/files/public/docs2047/
	avb-mace-ip-networked-studio-infrastructure-0107.pdf>.		avb-mace-ip-networked-studio-infrastructure-0107.pdf>.
	skipping to change at line 3260 ¶		skipping to change at page 79, line 4 ¶
	Email: franz-josef.goetz@siemens.com		Email: franz-josef.goetz@siemens.com
	Juergen Schmitt		Juergen Schmitt
	Siemens		Siemens
	Gleiwitzerstr. 555		Gleiwitzerstr. 555
	Nurnberg 90475		Nurnberg 90475
	Germany		Germany
	Email: juergen.jues.schmitt@siemens.com		Email: juergen.jues.schmitt@siemens.com
			Xavier Vilajosana
			Worldsensing
			483 Arago
			Barcelona, Catalonia 08013
			Spain
			Email: xvilajosana@worldsensing.com
			Toktam Mahmoodi
			King's College London
			Strand, London WC2R 2LS
			London, London WC2R 2LS
			United Kingdom
			Email: toktam.mahmoodi@kcl.ac.uk
			Spiros Spirou
			Intracom Telecom
			19.7 km Markopoulou Ave.
			Peania, Attiki 19002
			Greece
			Email: spis@intracom-telecom.com
			Petra Vizarreta
			Technical University of Munich, TUM
			Maxvorstadt, ArcisstraBe 21
			Munich, Germany 80333
			Germany
			Email: petra.vizarreta@lkn.ei.tum.de
End of changes. 50 change blocks.
	121 lines changed or deleted		388 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/