draft-ietf-detnet-use-cases-06.txt		draft-ietf-detnet-use-cases-07.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: September 5, 2016 HARMAN		Expires: September 6, 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
	March 4, 2016		March 5, 2016
	Deterministic Networking Use Cases		Deterministic Networking Use Cases
	draft-ietf-detnet-use-cases-06		draft-ietf-detnet-use-cases-07
	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 September 5, 2016.		This Internet-Draft will expire on September 6, 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
	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 Use Cases . . . . . . . . . . . . . . . . . . . . . 5		2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Use Case Description . . . . . . . . . . . . . . . . . . 5
	2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6		2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6
	2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 7		2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 7
	2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7		2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7
	2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8		2.1.4. Deterministic Time to Establish Streaming . . . . . . 8
	2.3. Additional Stream Requirements . . . . . . . . . . . . . 9		2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8
	2.3.1. Deterministic Time to Establish Streaming . . . . . . 9		2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8
	2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9		2.1.5.2. Digital Rights Management (DRM) . . . . . . . . . 8
	2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10		2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 9
	2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10		2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9
	2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10		2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9
	2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 11		2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9
	2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 11		2.3.3. Link Aggregation . . . . . . . . . . . . . . . . . . 10
	2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11		2.3.4. Integration of Reserved Streams into IT Networks . . 10
	2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11		2.3.5. Use of Unused Reservations by Best-Effort Traffic . . 10
	2.4. Integration of Reserved Streams into IT Networks . . . . 12		2.3.6. Traffic Segregation . . . . . . . . . . . . . . . . . 10
	2.5. Security Considerations . . . . . . . . . . . . . . . . . 12		2.3.6.1. Packet Forwarding Rules, VLANs and Subnets . . . 11
	2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12		2.3.6.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11
	2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12		2.3.7. Latency Optimization by a Central Controller . . . . 11
	2.6. A State-of-the-Art Broadcast Installation Hits Technology		2.3.8. Reduced Device Cost Due To Reduced Buffer Memory . . 12
	Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13		2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12
	3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 13		3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12
	3.1. Use Case Description . . . . . . . . . . . . . . . . . . 13		3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12
	3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 13		3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 13
	3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 13		3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 13
	3.1.1.2. Intra-Substation Process Bus Communications . . . 19		3.1.1.2. Intra-Substation Process Bus Communications . . . 18
	3.1.1.3. Wide Area Monitoring and Control Systems . . . . 20		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 . . . . . . . . . . . . . . . . . 21		classification . . . . . . . . . . . . . . . . . 20
	3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 22		3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21
	3.1.3. Distribution use case . . . . . . . . . . . . . . . . 23		3.1.3. Distribution use case . . . . . . . . . . . . . . . . 22
	3.1.3.1. Fault Location Isolation and Service Restoration		3.1.3.1. Fault Location Isolation and Service Restoration
	(FLISR) . . . . . . . . . . . . . . . . . . . . . 23		(FLISR) . . . . . . . . . . . . . . . . . . . . . 22
	3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 24		3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 23
	3.2.1. Security Current Practices and Limitations . . . . . 24		3.2.1. Security Current Practices and Limitations . . . . . 23
	3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 26		3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 25
	3.3.1. Migration to Packet-Switched Network . . . . . . . . 26		3.3.1. Migration to Packet-Switched Network . . . . . . . . 25
	3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 27		3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 26
	3.3.2.1. General Telecommunications Requirements . . . . . 27		3.3.2.1. General Telecommunications Requirements . . . . . 26
	3.3.2.2. Specific Network topologies of Smart Grid		3.3.2.2. Specific Network topologies of Smart Grid
	Applications . . . . . . . . . . . . . . . . . . 28		Applications . . . . . . . . . . . . . . . . . . 27
	3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 29		3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 28
	3.3.3. Security Trends in Utility Networks . . . . . . . . . 30		3.3.3. Security Trends in Utility Networks . . . . . . . . . 29
	3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 32		3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 31
	4. Building Automation Systems . . . . . . . . . . . . . . . . . 32		4. Building Automation Systems . . . . . . . . . . . . . . . . . 31
	4.1. Use Case Description . . . . . . . . . . . . . . . . . . 32		4.1. Use Case Description . . . . . . . . . . . . . . . . . . 31
	4.2. Building Automation Systems Today . . . . . . . . . . . . 32		4.2. Building Automation Systems Today . . . . . . . . . . . . 31
	4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 33		4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 32
	4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 34		4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 33
	4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 36		4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 35
	4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 36		4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 35
	4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 36		4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 35
	4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 37		4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 36
	4.2.4. Security Considerations . . . . . . . . . . . . . . . 37		4.2.4. Security Considerations . . . . . . . . . . . . . . . 36
	4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 37		4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 36
	4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 38		4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 37
	5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 38		5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 37
	5.1. Use Case Description . . . . . . . . . . . . . . . . . . 38		5.1. Use Case Description . . . . . . . . . . . . . . . . . . 37
	5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 39		5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 38
	5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 39		5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 38
	5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 40		5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 39
	5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 40		5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 39
	5.3.1. Unified Wireless Network and Management . . . . . . . 40		5.3.1. Unified Wireless Network and Management . . . . . . . 39
	5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 42		5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 41
	5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 43		5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 42
	5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 43		5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 42
	5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 44		5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 43
	5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 44		5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 43
	5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 45		5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 44
	6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 45		6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 44
	6.1. Use Case Description . . . . . . . . . . . . . . . . . . 45		6.1. Use Case Description . . . . . . . . . . . . . . . . . . 44
	6.1.1. Network Architecture . . . . . . . . . . . . . . . . 45		6.1.1. Network Architecture . . . . . . . . . . . . . . . . 44
	6.1.2. Time Synchronization Requirements . . . . . . . . . . 46		6.1.2. Time Synchronization Requirements . . . . . . . . . . 45
	6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 48		6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 47
	6.1.4. Security Considerations . . . . . . . . . . . . . . . 48		6.1.4. Security Considerations . . . . . . . . . . . . . . . 47
	6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 49		6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 48
	6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 49		6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 48
	6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 51		6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 50
	7. Cellular Coordinated Multipoint Processing (CoMP) . . . . . . 51		7. Cellular Coordinated Multipoint Processing (CoMP) . . . . . . 50
	7.1. Use Case Description . . . . . . . . . . . . . . . . . . 51		7.1. Use Case Description . . . . . . . . . . . . . . . . . . 50
	7.1.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 52		7.1.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 51
	7.1.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 53		7.1.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 52
	7.2. CoMP Today . . . . . . . . . . . . . . . . . . . . . . . 53		7.2. CoMP Today . . . . . . . . . . . . . . . . . . . . . . . 52
	7.3. CoMP Future . . . . . . . . . . . . . . . . . . . . . . . 53		7.3. CoMP Future . . . . . . . . . . . . . . . . . . . . . . . 52
	7.3.1. Mobile Industry Overall Goals . . . . . . . . . . . . 53		7.3.1. Mobile Industry Overall Goals . . . . . . . . . . . . 52
	7.3.2. CoMP Infrastructure Goals . . . . . . . . . . . . . . 54		7.3.2. CoMP Infrastructure Goals . . . . . . . . . . . . . . 53
	7.4. CoMP Asks . . . . . . . . . . . . . . . . . . . . . . . . 54		7.4. CoMP Asks . . . . . . . . . . . . . . . . . . . . . . . . 53
	8. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 55		8. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 54
	8.1. Use Case Description . . . . . . . . . . . . . . . . . . 55		8.1. Use Case Description . . . . . . . . . . . . . . . . . . 54
	8.2. Industrial M2M Communication Today . . . . . . . . . . . 56		8.2. Industrial M2M Communication Today . . . . . . . . . . . 55
	8.2.1. Transport Parameters . . . . . . . . . . . . . . . . 56		8.2.1. Transport Parameters . . . . . . . . . . . . . . . . 55
	8.2.2. Stream Creation and Destruction . . . . . . . . . . . 57		8.2.2. Stream Creation and Destruction . . . . . . . . . . . 56
	8.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 57		8.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 56
	8.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 58		8.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 57
	9. Internet-based Applications . . . . . . . . . . . . . . . . . 58		9. Internet-based Applications . . . . . . . . . . . . . . . . . 57
	9.1. Use Case Description . . . . . . . . . . . . . . . . . . 58		9.1. Use Case Description . . . . . . . . . . . . . . . . . . 57
	9.1.1. Media Content Delivery . . . . . . . . . . . . . . . 58		9.1.1. Media Content Delivery . . . . . . . . . . . . . . . 57
	9.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 58		9.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 57
	9.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 58		9.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 57
	9.2. Internet-Based Applications Today . . . . . . . . . . . . 59		9.2. Internet-Based Applications Today . . . . . . . . . . . . 58
	9.3. Internet-Based Applications Future . . . . . . . . . . . 59		9.3. Internet-Based Applications Future . . . . . . . . . . . 58
	9.4. Internet-Based Applications Asks . . . . . . . . . . . . 59		9.4. Internet-Based Applications Asks . . . . . . . . . . . . 58
	10. Use Case Common Elements . . . . . . . . . . . . . . . . . . 59		10. Use Case Common Elements . . . . . . . . . . . . . . . . . . 58
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
	11.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 60		11.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 59
	11.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 61		11.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 60
	11.3. Building Automation Systems . . . . . . . . . . . . . . 61		11.3. Building Automation Systems . . . . . . . . . . . . . . 60
	11.4. Wireless for Industrial . . . . . . . . . . . . . . . . 61		11.4. Wireless for Industrial . . . . . . . . . . . . . . . . 60
	11.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 61		11.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 60
	11.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 61		11.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 60
	11.7. Internet Applications and CoMP . . . . . . . . . . . . . 61		11.7. Internet Applications and CoMP . . . . . . . . . . . . . 60
	12. Informative References . . . . . . . . . . . . . . . . . . . 62		12. Informative References . . . . . . . . . . . . . . . . . . . 61
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
	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 5, line 42		skipping to change at page 5, line 42
	o How would you like it to be addressed in the future?		o How would you like it to be addressed in the future?
	o What do you want the IETF to deliver?		o What do you want the IETF to deliver?
	The level of detail in each use case should be sufficient to express		The level of detail in each use case should be sufficient to express
	the relevant elements of the use case, but not more.		the relevant elements of the use case, but not more.
	At the end we consider the use cases collectively, and examine the		At the end we consider the use cases collectively, and examine the
	most significant goals they have in common.		most significant goals they have in common.
	2. Pro Audio Use Cases		2. Pro Audio and Video
	2.1. Introduction
	The professional audio and video industry includes music and film
	content creation, broadcast, cinema, and live exposition as well as
	public address, media and emergency systems at large venues
	(airports, stadiums, churches, theme parks). These industries have
	already gone through the transition of audio and video signals from
	analog to digital, however the interconnect systems remain primarily
	point-to-point with a single (or small number of) signals per link,
	interconnected with purpose-built hardware.
	These industries are now attempting to transition to packet based		2.1. Use Case Description
	infrastructure for distributing audio and video in order to reduce
	cost, increase routing flexibility, and integrate with existing IT
	infrastructure.
	However, there are several requirements for making a network the		The professional audio and video industry ("ProAV") includes:
	primary infrastructure for audio and video which are not met by
	todays networks and these are our concern in this draft.
	The principal requirement is that pro audio and video applications		o Music and film content creation
	become able to establish streams that provide guaranteed (bounded)
	bandwidth and latency from the Layer 3 (IP) interface. Such streams
	can be created today within standards-based layer 2 islands however
	these are not sufficient to enable effective distribution over wider
	areas (for example broadcast events that span wide geographical
	areas).
	Some proprietary systems have been created which enable deterministic		o Broadcast
	streams at layer 3 however they are engineered networks in that they		o Cinema
	require careful configuration to operate, often require that the
	system be over designed, and it is implied that all devices on the
	network voluntarily play by the rules of that network. To enable
	these industries to successfully transition to an interoperable
	multi-vendor packet-based infrastructure requires effective open
	standards, and we believe that establishing relevant IETF standards
	is a crucial factor.
	It would be highly desirable if such streams could be routed over the		o Live sound
	open Internet, however even intermediate solutions with more limited
	scope (such as enterprise networks) can provide a substantial
	improvement over todays networks, and a solution that only provides
	for the enterprise network scenario is an acceptable first step.
	We also present more fine grained requirements of the audio and video		o Public address, media and emergency systems at large venues
	industries such as safety and security, redundant paths, devices with		(airports, stadiums, churches, theme parks).
	limited computing resources on the network, and that reserved stream
	bandwidth is available for use by other best-effort traffic when that
	stream is not currently in use.
	2.2. Fundamental Stream Requirements		These industries have already transitioned audio and video signals
			from analog to digital. However, the digital interconnect systems
			remain primarily point-to-point with a single (or small number of)
			signals per link, interconnected with purpose-built hardware.
	The fundamental stream properties are guaranteed bandwidth and		These industries are now transitioning to packet-based infrastructure
	deterministic latency as described in this section. Additional		to reduce cost, increase routing flexibility, and integrate with
	stream requirements are described in a subsequent section.		existing IT infrastructure.
	2.2.1. Guaranteed Bandwidth		Today ProAV applications have no way to establish deterministic
			streams from a standards-based Layer 3 (IP) interface, which is a
			fundamental limitation to the use cases described here. Today
			deterministic streams can be created within standards-based layer 2
			LANs (e.g. using IEEE 802.1 AVB) however these are not routable via
			IP and thus are not effective for distribution over wider areas (for
			example broadcast events that span wide geographical areas).
	Transmitting audio and video streams is unlike common file transfer		It would be highly desirable if such streams could be routed over the
	activities because guaranteed delivery cannot be achieved by re-		open Internet, however solutions with more limited scope (e.g.
	trying the transmission; by the time the missing or corrupt packet		enterprise networks) would still provide a substantial improvement.
	has been identified it is too late to execute a re-try operation and
	stream playback is interrupted, which is unacceptable in for example
	a live concert. In some contexts large amounts of buffering can be
	used to provide enough delay to allow time for one or more retries,
	however this is not an effective solution when live interaction is
	involved, and is not considered an acceptable general solution for
	pro audio and video. (Have you ever tried speaking into a microphone
	through a sound system that has an echo coming back at you? It makes
	it almost impossible to speak clearly).
	Providing a way to reserve a specific amount of bandwidth for a given		The following sections describe specific ProAV use cases.
	stream is a key requirement.
	2.2.2. Bounded and Consistent Latency		2.1.1. Uninterrupted Stream Playback
	Latency in this context means the amount of time that passes between		Transmitting audio and video streams for live playback is unlike
	when a signal is sent over a stream and when it is received, for		common file transfer because uninterrupted stream playback in the
	example the amount of time delay between when you speak into a		presence of network errors cannot be achieved by re-trying the
	microphone and when your voice emerges from the speaker. Any delay		transmission; by the time the missing or corrupt packet has been
	longer than about 10-15 milliseconds is noticeable by most live		identified it is too late to execute a re-try operation. Buffering
	performers, and greater latency makes the system unusable because it		can be used to provide enough delay to allow time for one or more
	prevents them from playing in time with the other players (see slide		retries, however this is not an effective solution in applications
	6 of [SRP_LATENCY]).		where large delays (latencies) are not acceptable (as discussed
			below).
	The 15ms latency bound is made even more challenging because it is		Streams with guaranteed bandwidth can eliminate congestion on the
	often the case in network based music production with live electric		network as a cause of transmission errors that would lead to playback
	instruments that multiple stages of signal processing are used,		interruption. Use of redundant paths can further mitigate
	connected in series (i.e. from one to the other for example from		transmission errors to provide greater stream reliability.
	guitar through a series of digital effects processors) in which case
	the latencies add, so the latencies of each individual stage must all
	together remain less than 15ms.
	In some situations it is acceptable at the local location for content		2.1.2. Synchronized Stream Playback
	from the live remote site to be delayed to allow for a statistically
	acceptable amount of latency in order to reduce jitter. However,
	once the content begins playing in the local location any audio
	artifacts caused by the local network are unacceptable, especially in
	those situations where a live local performer is mixed into the feed
	from the remote location.
	In addition to being bounded to within some predictable and		Latency in this context is the time between when a signal is
	acceptable amount of time (which may be 15 milliseconds or more or		initially sent over a stream and when it is received. A common
	less depending on the application) the latency also has to be		example in ProAV is time-synchronizing audio and video when they take
	consistent. For example when playing a film consisting of a video		separate paths through the playback system. In this case the latency
	stream and audio stream over a network, those two streams must be		of both the audio and video streams must be bounded and consistent if
	synchronized so that the voice and the picture match up. A common		the sound is to remain matched to the movement in the video. A
	tolerance for audio/video sync is one NTSC video frame (about 33ms)		common tolerance for audio/video sync is one NTSC video frame (about
	and to maintain the audience perception of correct lip sync the		33ms) and to maintain the audience perception of correct lip sync the
	latency needs to be consistent within some reasonable tolerance, for		latency needs to be consistent within some reasonable tolerance, for
	example 10%.		example 10%.
	A common architecture for synchronizing multiple streams that have		A common architecture for synchronizing multiple streams that have
	different paths through the network (and thus potentially different		different paths through the network (and thus potentially different
	latencies) is to enable measurement of the latency of each path, and		latencies) is to enable measurement of the latency of each path, and
	have the data sinks (for example speakers) buffer (delay) all packets		have the data sinks (for example speakers) delay (buffer) all packets
	on all but the slowest path. Each packet of each stream is assigned		on all but the slowest path. Each packet of each stream is assigned
	a presentation time which is based on the longest required delay.		a presentation time which is based on the longest required delay.
	This implies that all sinks must maintain a common time reference of		This implies that all sinks must maintain a common time reference of
	sufficient accuracy, which can be achieved by any of various		sufficient accuracy, which can be achieved by any of various
	techniques.		techniques.
	This type of architecture is commonly implemented using a central		This type of architecture is commonly implemented using a central
	controller that determines path delays and arbitrates buffering		controller that determines path delays and arbitrates buffering
	delays.		delays.
	2.2.2.1. Optimizations		2.1.3. Sound Reinforcement
	The controller might also perform optimizations based on the
	individual path delays, for example sinks that are closer to the
	source can inform the controller that they can accept greater latency
	since they will be buffering packets to match presentation times of
	farther away sinks. The controller might then move a stream
	reservation on a short path to a longer path in order to free up
	bandwidth for other critical streams on that short path. See slides
	3-5 of [SRP_LATENCY].
	Additional optimization can be achieved in cases where sinks have		Consider the latency (delay) from when a person speaks into a
	differing latency requirements, for example in a live outdoor concert		microphone to when their voice emerges from the speaker. If this
	the speaker sinks have stricter latency requirements than the		delay is longer than about 10-15 milliseconds it is noticeable and
	recording hardware sinks. See slide 7 of [SRP_LATENCY].		can make a sound reinforcement system unusable (see slide 6 of
			[SRP_LATENCY]). (If you have ever tried to speak in the presence of
			a delayed echo of your voice you may know this experience).
	Device cost can be reduced in a system with guaranteed reservations		Note that the 15ms latency bound includes all parts of the signal
	with a small bounded latency due to the reduced requirements for		path, not just the network, so the network latency must be
	buffering (i.e. memory) on sink devices. For example, a theme park		significantly less than 15ms.
	might broadcast a live event across the globe via a layer 3 protocol;
	in such cases the size of the buffers required is proportional to the
	latency bounds and jitter caused by delivery, which depends on the
	worst case segment of the end-to-end network path. For example on
	todays open internet the latency is typically unacceptable for audio
	and video streaming without many seconds of buffering. In such
	scenarios a single gateway device at the local network that receives
	the feed from the remote site would provide the expensive buffering
	required to mask the latency and jitter issues associated with long
	distance delivery. Sink devices in the local location would have no
	additional buffering requirements, and thus no additional costs,
	beyond those required for delivery of local content. The sink device
	would be receiving the identical packets as those sent by the source
	and would be unaware that there were any latency or jitter issues
	along the path.
	2.3. Additional Stream Requirements		In some cases local performers must perform in synchrony with a
			remote broadcast. In such cases the latencies of the broadcast
			stream and the local performer must be adjusted to match each other,
			with a worst case of one video frame (33ms for NTSC video).
	The requirements in this section are more specific yet are common to		In cases where audio phase is a consideration, for example beam-
	multiple audio and video industry applications.		forming using multiple speakers, latency requirements can be in the
			10 microsecond range (1 audio sample at 96kHz).
	2.3.1. Deterministic Time to Establish Streaming		2.1.4. Deterministic Time to Establish Streaming
	Some audio systems installed in public environments (airports,		Some audio systems installed in public environments (airports,
	hospitals) have unique requirements with regards to health, safety		hospitals) have unique requirements with regards to health, safety
	and fire concerns. One such requirement is a maximum of 3 seconds		and fire concerns. One such requirement is a maximum of 3 seconds
	for a system to respond to an emergency detection and begin sending		for a system to respond to an emergency detection and begin sending
	appropriate warning signals and alarms without human intervention.		appropriate warning signals and alarms without human intervention.
	For this requirement to be met, the system must support a bounded and		For this requirement to be met, the system must support a bounded and
	acceptable time from a notification signal to specific stream		acceptable time from a notification signal to specific stream
	establishment. For further details see [ISO7240-16].		establishment. For further details see [ISO7240-16].
	Similar requirements apply when the system is restarted after a power		Similar requirements apply when the system is restarted after a power
	cycle, cable re-connection, or system reconfiguration.		cycle, cable re-connection, or system reconfiguration.
	In many cases such re-establishment of streaming state must be		In many cases such re-establishment of streaming state must be
	achieved by the peer devices themselves, i.e. without a central		achieved by the peer devices themselves, i.e. without a central
	controller (since such a controller may only be present during		controller (since such a controller may only be present during
	initial network configuration).		initial network configuration).
	Video systems introduce related requirements, for example when		Video systems introduce related requirements, for example when
	transitioning from one camera feed to another. Such systems		transitioning from one camera feed (video stream) to another (see
	currently use purpose-built hardware to switch feeds smoothly,		[STUDIO_IP] and [ESPN_DC2]).
	however there is a current initiative in the broadcast industry to
	switch to a packet-based infrastructure (see [STUDIO_IP] and the ESPN
	DC2 use case described below).
	2.3.2. Use of Unused Reservations by Best-Effort Traffic
	In cases where stream bandwidth is reserved but not currently used
	(or is under-utilized) that bandwidth must be available to best-
	effort (i.e. non-time-sensitive) traffic. For example a single
	stream may be nailed up (reserved) for specific media content that
	needs to be presented at different times of the day, ensuring timely
	delivery of that content, yet in between those times the full
	bandwidth of the network can be utilized for best-effort tasks such
	as file transfers.
	This also addresses a concern of IT network administrators that are		2.1.5. Secure Transmission
	considering adding reserved bandwidth traffic to their networks that
	users will just reserve a ton of bandwidth and then never un-reserve
	it even though they are not using it, and soon they will have no
	bandwidth left.
	2.3.3. Layer 3 Interconnecting Layer 2 Islands		2.1.5.1. Safety
	As an intermediate step (short of providing guaranteed bandwidth		Professional audio systems can include amplifiers that are capable of
	across the open internet) it would be valuable to provide a way to		generating hundreds or thousands of watts of audio power which if
	connect multiple Layer 2 networks. For example layer 2 techniques		used incorrectly can cause hearing damage to those in the vicinity.
	could be used to create a LAN for a single broadcast studio, and		Apart from the usual care required by the systems operators to
	several such studios could be interconnected via layer 3 links.		prevent such incidents, the network traffic that controls these
			devices must be secured (as with any sensitive application traffic).
	2.3.4. Secure Transmission		2.1.5.2. Digital Rights Management (DRM)
	Digital Rights Management (DRM) is very important to the audio and		Digital Rights Management (DRM) is very important to the audio and
	video industries. Any time protected content is introduced into a		video industries. Any time protected content is introduced into a
	network there are DRM concerns that must be maintained (see		network there are DRM concerns that must be maintained (see
	[CONTENT_PROTECTION]). Many aspects of DRM are outside the scope of		[CONTENT_PROTECTION]). Many aspects of DRM are outside the scope of
	network technology, however there are cases when a secure link		network technology, however there are cases when a secure link
	supporting authentication and encryption is required by content		supporting authentication and encryption is required by content
	owners to carry their audio or video content when it is outside their		owners to carry their audio or video content when it is outside their
	own secure environment (for example see [DCI]).		own secure environment (for example see [DCI]).
	As an example, two techniques are Digital Transmission Content		As an example, two techniques are Digital Transmission Content
	Protection (DTCP) and High-Bandwidth Digital Content Protection		Protection (DTCP) and High-Bandwidth Digital Content Protection
	(HDCP). HDCP content is not approved for retransmission within any		(HDCP). HDCP content is not approved for retransmission within any
	other type of DRM, while DTCP may be retransmitted under HDCP.		other type of DRM, while DTCP may be retransmitted under HDCP.
	Therefore if the source of a stream is outside of the network and it		Therefore if the source of a stream is outside of the network and it
	uses HDCP protection it is only allowed to be placed on the network		uses HDCP protection it is only allowed to be placed on the network
	with that same HDCP protection.		with that same HDCP protection.
	2.3.5. Redundant Paths		2.2. Pro Audio Today
	On-air and other live media streams must be backed up with redundant		Some proprietary systems have been created which enable deterministic
	links that seamlessly act to deliver the content when the primary		streams at Layer 3 however they are "engineered networks" which
	link fails for any reason. In point-to-point systems this is		require careful configuration to operate, often require that the
			system be over-provisioned, and it is implied that all devices on the
			network voluntarily play by the rules of that network. To enable
			these industries to successfully transition to an interoperable
			multi-vendor packet-based infrastructure requires effective open
			standards, and we believe that establishing relevant IETF standards
			is a crucial factor.
			2.3. Pro Audio Future
			2.3.1. Layer 3 Interconnecting Layer 2 Islands
			It would be valuable to enable IP to connect multiple Layer 2 LANs.
			As an example, ESPN recently constructed a state-of-the-art 194,000
			sq ft, $125 million broadcast studio called DC2. The DC2 network is
			capable of handling 46 Tbps of throughput with 60,000 simultaneous
			signals. Inside the facility are 1,100 miles of fiber feeding four
			audio control rooms (see [ESPN_DC2] ).
			In designing DC2 they replaced as much point-to-point technology as
			they could with packet-based technology. They constructed seven
			individual studios using layer 2 LANS (using IEEE 802.1 AVB) that
			were entirely effective at routing audio within the LANs. However to
			interconnect these layer 2 LAN islands together they ended up using
			dedicated paths in a custom SDN (Software Defined Networking) router
			because there is no standards-based routing solution available.
			2.3.2. High Reliability Stream Paths
			On-air and other live media streams are often backed up with
			redundant links that seamlessly act to deliver the content when the
			primary link fails for any reason. In point-to-point systems this is
	provided by an additional point-to-point link; the analogous		provided by an additional point-to-point link; the analogous
	requirement in a packet-based system is to provide an alternate path		requirement in a packet-based system is to provide an alternate path
	through the network such that no individual link can bring down the		through the network such that no individual link can bring down the
	system.		system.
	2.3.6. Link Aggregation		2.3.3. Link Aggregation
	For transmitting streams that require more bandwidth than a single		For transmitting streams that require more bandwidth than a single
	link in the target network can support, link aggregation is a		link in the target network can support, link aggregation is a
	technique for combining (aggregating) the bandwidth available on		technique for combining (aggregating) the bandwidth available on
	multiple physical links to create a single logical link of the		multiple physical links to create a single logical link of the
	required bandwidth. However, if aggregation is to be used, the		required bandwidth. However, if aggregation is to be used, the
	network controller (or equivalent) must be able to determine the		network controller (or equivalent) must be able to determine the
	maximum latency of any path through the aggregate link (see Bounded		maximum latency of any path through the aggregate link.
	and Consistent Latency section above).
	2.3.7. Traffic Segregation		2.3.4. Integration of Reserved Streams into IT Networks
			A commonly cited goal of moving to a packet based media
			infrastructure is that costs can be reduced by using off the shelf,
			commodity network hardware. In addition, economy of scale can be
			realized by combining media infrastructure with IT infrastructure.
			In keeping with these goals, stream reservation technology should be
			compatible with existing protocols, and not compromise use of the
			network for best effort (non-time-sensitive) traffic.
			2.3.5. Use of Unused Reservations by Best-Effort Traffic
			In cases where stream bandwidth is reserved but not currently used
			(or is under-utilized) that bandwidth must be available to best-
			effort (i.e. non-time-sensitive) traffic. For example a single
			stream may be nailed up (reserved) for specific media content that
			needs to be presented at different times of the day, ensuring timely
			delivery of that content, yet in between those times the full
			bandwidth of the network can be utilized for best-effort tasks such
			as file transfers.
			This also addresses a concern of IT network administrators that are
			considering adding reserved bandwidth traffic to their networks that
			("users will reserve large quantities of bandwidth and then never un-
			reserve it even though they are not using it, and soon the network
			will have no bandwidth left").
			2.3.6. Traffic Segregation
	Sink devices may be low cost devices with limited processing power.		Sink devices may be low cost devices with limited processing power.
	In order to not overwhelm the CPUs in these devices it is important		In order to not overwhelm the CPUs in these devices it is important
	to limit the amount of traffic that these devices must process.		to limit the amount of traffic that these devices must process.
	As an example, consider the use of individual seat speakers in a		As an example, consider the use of individual seat speakers in a
	cinema. These speakers are typically required to be cost reduced		cinema. These speakers are typically required to be cost reduced
	since the quantities in a single theater can reach hundreds of seats.		since the quantities in a single theater can reach hundreds of seats.
	Discovery protocols alone in a one thousand seat theater can generate		Discovery protocols alone in a one thousand seat theater can generate
	enough broadcast traffic to overwhelm a low powered CPU. Thus an		enough broadcast traffic to overwhelm a low powered CPU. Thus an
	installation like this will benefit greatly from some type of traffic		installation like this will benefit greatly from some type of traffic
	segregation that can define groups of seats to reduce traffic within		segregation that can define groups of seats to reduce traffic within
	each group. All seats in the theater must still be able to		each group. All seats in the theater must still be able to
	communicate with a central controller.		communicate with a central controller.
	There are many techniques that can be used to support this		There are many techniques that can be used to support this
	requirement including (but not limited to) the following examples.		requirement including (but not limited to) the following examples.
	2.3.7.1. Packet Forwarding Rules, VLANs and Subnets		2.3.6.1. Packet Forwarding Rules, VLANs and Subnets
	Packet forwarding rules can be used to eliminate some extraneous		Packet forwarding rules can be used to eliminate some extraneous
	streaming traffic from reaching potentially low powered sink devices,		streaming traffic from reaching potentially low powered sink devices,
	however there may be other types of broadcast traffic that should be		however there may be other types of broadcast traffic that should be
	eliminated using other means for example VLANs or IP subnets.		eliminated using other means for example VLANs or IP subnets.
	2.3.7.2. Multicast Addressing (IPv4 and IPv6)		2.3.6.2. Multicast Addressing (IPv4 and IPv6)
	Multicast addressing is commonly used to keep bandwidth utilization		Multicast addressing is commonly used to keep bandwidth utilization
	of shared links to a minimum.		of shared links to a minimum.
	Because of the MAC Address forwarding nature of Layer 2 bridges it is		Because of the MAC Address forwarding nature of Layer 2 bridges it is
	important that a multicast MAC address is only associated with one		important that a multicast MAC address is only associated with one
	stream. This will prevent reservations from forwarding packets from		stream. This will prevent reservations from forwarding packets from
	one stream down a path that has no interested sinks simply because		one stream down a path that has no interested sinks simply because
	there is another stream on that same path that shares the same		there is another stream on that same path that shares the same
	multicast MAC address.		multicast MAC address.
	Since each multicast MAC Address can represent 32 different IPv4		Since each multicast MAC Address can represent 32 different IPv4
	multicast addresses there must be a process put in place to make sure		multicast addresses there must be a process put in place to make sure
	this does not occur. Requiring use of IPv6 address can achieve this,		this does not occur. Requiring use of IPv6 address can achieve this,
	however due to their continued prevalence, solutions that are		however due to their continued prevalence, solutions that are
	effective for IPv4 installations are also required.		effective for IPv4 installations are also required.
	2.4. Integration of Reserved Streams into IT Networks		2.3.7. Latency Optimization by a Central Controller
	A commonly cited goal of moving to a packet based media		A central network controller might also perform optimizations based
	infrastructure is that costs can be reduced by using off the shelf,		on the individual path delays, for example sinks that are closer to
	commodity network hardware. In addition, economy of scale can be		the source can inform the controller that they can accept greater
	realized by combining media infrastructure with IT infrastructure.		latency since they will be buffering packets to match presentation
	In keeping with these goals, stream reservation technology should be		times of farther away sinks. The controller might then move a stream
	compatible with existing protocols, and not compromise use of the		reservation on a short path to a longer path in order to free up
	network for best effort (non-time-sensitive) traffic.		bandwidth for other critical streams on that short path. See slides
			3-5 of [SRP_LATENCY].
	2.5. Security Considerations		Additional optimization can be achieved in cases where sinks have
			differing latency requirements, for example in a live outdoor concert
			the speaker sinks have stricter latency requirements than the
			recording hardware sinks. See slide 7 of [SRP_LATENCY].
	Many industries that are moving from the point-to-point world to the		2.3.8. Reduced Device Cost Due To Reduced Buffer Memory
	digital network world have little understanding of the pitfalls that
	they can create for themselves with improperly implemented network
	infrastructure. DetNet should consider ways to provide security
	against DoS attacks in solutions directed at these markets. Some
	considerations are given here as examples of ways that we can help
	new users avoid common pitfalls.
	2.5.1. Denial of Service		Device cost can be reduced in a system with guaranteed reservations
			with a small bounded latency due to the reduced requirements for
			buffering (i.e. memory) on sink devices. For example, a theme park
			might broadcast a live event across the globe via a layer 3 protocol;
			in such cases the size of the buffers required is proportional to the
			latency bounds and jitter caused by delivery, which depends on the
			worst case segment of the end-to-end network path. For example on
			todays open internet the latency is typically unacceptable for audio
			and video streaming without many seconds of buffering. In such
			scenarios a single gateway device at the local network that receives
			the feed from the remote site would provide the expensive buffering
			required to mask the latency and jitter issues associated with long
			distance delivery. Sink devices in the local location would have no
			additional buffering requirements, and thus no additional costs,
			beyond those required for delivery of local content. The sink device
			would be receiving the identical packets as those sent by the source
			and would be unaware that there were any latency or jitter issues
			along the path.
	One security pitfall that this author is aware of involves the use of		2.4. Pro Audio Asks
	technology that allows a presenter to throw the content from their
	tablet or smart phone onto the A/V system that is then viewed by all
	those in attendance. The facility introducing this technology was
	quite excited to allow such modern flexibility to those who came to
	speak. One thing they hadn't realized was that since no security was
	put in place around this technology it left a hole in the system that
	allowed other attendees to "throw" their own content onto the A/V
	system.
	2.5.2. Control Protocols		o Layer 3 routing on top of AVB (and/or other high QoS networks)
	Professional audio systems can include amplifiers that are capable of		o Content delivery with bounded, lowest possible latency
	generating hundreds or thousands of watts of audio power which if
	used incorrectly can cause hearing damage to those in the vicinity.
	Apart from the usual care required by the systems operators to
	prevent such incidents, the network traffic that controls these
	devices must be secured (as with any sensitive application traffic).
	In addition, it would be desirable if the configuration protocols
	that are used to create the network paths used by the professional
	audio traffic could be designed to protect devices that are not meant
	to receive high-amplitude content from having such potentially
	damaging signals routed to them.
	2.6. A State-of-the-Art Broadcast Installation Hits Technology Limits		o IntServ and DiffServ integration with AVB (where practical)
	ESPN recently constructed a state-of-the-art 194,000 sq ft, $125		o Single network for A/V and IT traffic
	million broadcast studio called DC2. The DC2 network is capable of
	handling 46 Tbps of throughput with 60,000 simultaneous signals.
	Inside the facility are 1,100 miles of fiber feeding four audio
	control rooms. (See details at [ESPN_DC2] ).
	In designing DC2 they replaced as much point-to-point technology as		o Standards-based, interoperable, multi-vendor
	they possibly could with packet-based technology. They constructed
	seven individual studios using layer 2 LANS (using IEEE 802.1 AVB)
	that were entirely effective at routing audio within the LANs, and
	they were very happy with the results, however to interconnect these
	layer 2 LAN islands together they ended up using dedicated links
	because there is no standards-based routing solution available.
	This is the kind of motivation we have to develop these standards		o IT department friendly
	because customers are ready and able to use them.
			o Enterprise-wide networks (e.g. size of San Francisco but not the
			whole Internet (yet...))
	3. Electrical Utilities		3. Electrical Utilities
	3.1. Use Case Description		3.1. Use Case Description
	Many systems that an electrical utility deploys today rely on high		Many systems that an electrical utility deploys today rely on high
	availability and deterministic behavior of the underlying networks.		availability and deterministic behavior of the underlying networks.
	Here we present use cases in Transmission, Generation and		Here we present use cases in Transmission, Generation and
	Distribution, including key timing and reliability metrics. We also		Distribution, including key timing and reliability metrics. We also
	discuss security issues and industry trends which affect the		discuss security issues and industry trends which affect the
End of changes. 58 change blocks.
	336 lines changed or deleted		303 lines changed or added
This html diff was produced by rfcdiff 1.43. The latest version is available from http://tools.ietf.org/tools/rfcdiff/