--- 1/draft-ietf-detnet-use-cases-06.txt 2016-03-05 01:16:45.816199260 -0800 +++ 2/draft-ietf-detnet-use-cases-07.txt 2016-03-05 01:16:45.956202792 -0800 @@ -1,38 +1,38 @@ Internet Engineering Task Force E. Grossman, Ed. Internet-Draft DOLBY Intended status: Informational C. Gunther -Expires: September 5, 2016 HARMAN +Expires: September 6, 2016 HARMAN P. Thubert P. Wetterwald CISCO J. Raymond HYDRO-QUEBEC J. Korhonen BROADCOM Y. Kaneko Toshiba S. Das Applied Communication Sciences Y. Zha HUAWEI B. Varga J. Farkas Ericsson F. Goetz J. Schmitt Siemens - March 4, 2016 + March 5, 2016 Deterministic Networking Use Cases - draft-ietf-detnet-use-cases-06 + draft-ietf-detnet-use-cases-07 Abstract This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which 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. @@ -54,155 +54,155 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6 - 2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 7 - 2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7 - 2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8 - 2.3. Additional Stream Requirements . . . . . . . . . . . . . 9 - 2.3.1. Deterministic Time to Establish Streaming . . . . . . 9 - 2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9 - 2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10 - 2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10 - 2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10 - 2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 11 - 2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 11 - 2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11 - 2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11 - 2.4. Integration of Reserved Streams into IT Networks . . . . 12 - 2.5. Security Considerations . . . . . . . . . . . . . . . . . 12 - 2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12 - 2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12 - 2.6. A State-of-the-Art Broadcast Installation Hits Technology - Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 13 - 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 13 + 2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Use Case Description . . . . . . . . . . . . . . . . . . 5 + 2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6 + 2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 7 + 2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7 + 2.1.4. Deterministic Time to Establish Streaming . . . . . . 8 + 2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8 + 2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8 + 2.1.5.2. Digital Rights Management (DRM) . . . . . . . . . 8 + 2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 9 + 2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9 + 2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9 + 2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9 + 2.3.3. Link Aggregation . . . . . . . . . . . . . . . . . . 10 + 2.3.4. Integration of Reserved Streams into IT Networks . . 10 + 2.3.5. Use of Unused Reservations by Best-Effort Traffic . . 10 + 2.3.6. Traffic Segregation . . . . . . . . . . . . . . . . . 10 + 2.3.6.1. Packet Forwarding Rules, VLANs and Subnets . . . 11 + 2.3.6.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11 + 2.3.7. Latency Optimization by a Central Controller . . . . 11 + 2.3.8. Reduced Device Cost Due To Reduced Buffer Memory . . 12 + 2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12 + 3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12 + 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12 3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 13 3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 13 - 3.1.1.2. Intra-Substation Process Bus Communications . . . 19 - 3.1.1.3. Wide Area Monitoring and Control Systems . . . . 20 + 3.1.1.2. Intra-Substation Process Bus Communications . . . 18 + 3.1.1.3. Wide Area Monitoring and Control Systems . . . . 19 3.1.1.4. IEC 61850 WAN engineering guidelines requirement - classification . . . . . . . . . . . . . . . . . 21 - 3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 22 - 3.1.3. Distribution use case . . . . . . . . . . . . . . . . 23 + classification . . . . . . . . . . . . . . . . . 20 + 3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21 + 3.1.3. Distribution use case . . . . . . . . . . . . . . . . 22 3.1.3.1. Fault Location Isolation and Service Restoration - (FLISR) . . . . . . . . . . . . . . . . . . . . . 23 - 3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 24 - 3.2.1. Security Current Practices and Limitations . . . . . 24 - 3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 26 - 3.3.1. Migration to Packet-Switched Network . . . . . . . . 26 - 3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 27 - 3.3.2.1. General Telecommunications Requirements . . . . . 27 + (FLISR) . . . . . . . . . . . . . . . . . . . . . 22 + 3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 23 + 3.2.1. Security Current Practices and Limitations . . . . . 23 + 3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 25 + 3.3.1. Migration to Packet-Switched Network . . . . . . . . 25 + 3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 26 + 3.3.2.1. General Telecommunications Requirements . . . . . 26 3.3.2.2. Specific Network topologies of Smart Grid - Applications . . . . . . . . . . . . . . . . . . 28 - 3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 29 - 3.3.3. Security Trends in Utility Networks . . . . . . . . . 30 - 3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 32 - 4. Building Automation Systems . . . . . . . . . . . . . . . . . 32 - 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 32 - 4.2. Building Automation Systems Today . . . . . . . . . . . . 32 - 4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 33 - 4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 34 - 4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 36 - 4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 36 - 4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 36 - 4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 37 - 4.2.4. Security Considerations . . . . . . . . . . . . . . . 37 - 4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 37 - 4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 38 - 5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 38 - 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 38 - 5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 39 - 5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 39 + Applications . . . . . . . . . . . . . . . . . . 27 + 3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 28 + 3.3.3. Security Trends in Utility Networks . . . . . . . . . 29 + 3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 31 + 4. Building Automation Systems . . . . . . . . . . . . . . . . . 31 + 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 31 + 4.2. Building Automation Systems Today . . . . . . . . . . . . 31 + 4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 32 + 4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 33 + 4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 35 + 4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 35 + 4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 35 + 4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 36 + 4.2.4. Security Considerations . . . . . . . . . . . . . . . 36 + 4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 36 + 4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 37 + 5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 37 + 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 37 + 5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 38 + 5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 38 - 5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 40 - 5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 40 - 5.3.1. Unified Wireless Network and Management . . . . . . . 40 - 5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 42 - 5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 43 - 5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 43 - 5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 44 - 5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 44 - 5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 45 - 6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 45 - 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 45 - 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 45 - 6.1.2. Time Synchronization Requirements . . . . . . . . . . 46 - 6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 48 - 6.1.4. Security Considerations . . . . . . . . . . . . . . . 48 - 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 49 - 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 49 - 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 51 - 7. Cellular Coordinated Multipoint Processing (CoMP) . . . . . . 51 - 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 51 - 7.1.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 52 - 7.1.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 53 - 7.2. CoMP Today . . . . . . . . . . . . . . . . . . . . . . . 53 - 7.3. CoMP Future . . . . . . . . . . . . . . . . . . . . . . . 53 - 7.3.1. Mobile Industry Overall Goals . . . . . . . . . . . . 53 - 7.3.2. CoMP Infrastructure Goals . . . . . . . . . . . . . . 54 - 7.4. CoMP Asks . . . . . . . . . . . . . . . . . . . . . . . . 54 - 8. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 55 - 8.1. Use Case Description . . . . . . . . . . . . . . . . . . 55 - 8.2. Industrial M2M Communication Today . . . . . . . . . . . 56 - 8.2.1. Transport Parameters . . . . . . . . . . . . . . . . 56 - 8.2.2. Stream Creation and Destruction . . . . . . . . . . . 57 - 8.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 57 - 8.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 58 - 9. Internet-based Applications . . . . . . . . . . . . . . . . . 58 - 9.1. Use Case Description . . . . . . . . . . . . . . . . . . 58 - 9.1.1. Media Content Delivery . . . . . . . . . . . . . . . 58 - 9.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 58 - 9.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 58 - 9.2. Internet-Based Applications Today . . . . . . . . . . . . 59 - 9.3. Internet-Based Applications Future . . . . . . . . . . . 59 - 9.4. Internet-Based Applications Asks . . . . . . . . . . . . 59 - 10. Use Case Common Elements . . . . . . . . . . . . . . . . . . 59 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 - 11.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 60 - 11.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 61 - 11.3. Building Automation Systems . . . . . . . . . . . . . . 61 - 11.4. Wireless for Industrial . . . . . . . . . . . . . . . . 61 - 11.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 61 - 11.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 61 - 11.7. Internet Applications and CoMP . . . . . . . . . . . . . 61 - 12. Informative References . . . . . . . . . . . . . . . . . . . 62 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 + 5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 39 + 5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 39 + 5.3.1. Unified Wireless Network and Management . . . . . . . 39 + 5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 41 + 5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 42 + 5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 42 + 5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 43 + 5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 43 + 5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 44 + 6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 44 + 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 44 + 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 44 + 6.1.2. Time Synchronization Requirements . . . . . . . . . . 45 + 6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 47 + 6.1.4. Security Considerations . . . . . . . . . . . . . . . 47 + 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 48 + 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 48 + 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 50 + 7. Cellular Coordinated Multipoint Processing (CoMP) . . . . . . 50 + 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 50 + 7.1.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 51 + 7.1.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 52 + 7.2. CoMP Today . . . . . . . . . . . . . . . . . . . . . . . 52 + 7.3. CoMP Future . . . . . . . . . . . . . . . . . . . . . . . 52 + 7.3.1. Mobile Industry Overall Goals . . . . . . . . . . . . 52 + 7.3.2. CoMP Infrastructure Goals . . . . . . . . . . . . . . 53 + 7.4. CoMP Asks . . . . . . . . . . . . . . . . . . . . . . . . 53 + 8. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 54 + 8.1. Use Case Description . . . . . . . . . . . . . . . . . . 54 + 8.2. Industrial M2M Communication Today . . . . . . . . . . . 55 + 8.2.1. Transport Parameters . . . . . . . . . . . . . . . . 55 + 8.2.2. Stream Creation and Destruction . . . . . . . . . . . 56 + 8.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 56 + 8.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 57 + 9. Internet-based Applications . . . . . . . . . . . . . . . . . 57 + 9.1. Use Case Description . . . . . . . . . . . . . . . . . . 57 + 9.1.1. Media Content Delivery . . . . . . . . . . . . . . . 57 + 9.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 57 + 9.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 57 + 9.2. Internet-Based Applications Today . . . . . . . . . . . . 58 + 9.3. Internet-Based Applications Future . . . . . . . . . . . 58 + 9.4. Internet-Based Applications Asks . . . . . . . . . . . . 58 + 10. Use Case Common Elements . . . . . . . . . . . . . . . . . . 58 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 + 11.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 59 + 11.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 60 + 11.3. Building Automation Systems . . . . . . . . . . . . . . 60 + 11.4. Wireless for Industrial . . . . . . . . . . . . . . . . 60 + 11.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 60 + 11.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 60 + 11.7. Internet Applications and CoMP . . . . . . . . . . . . . 60 + 12. Informative References . . . . . . . . . . . . . . . . . . . 61 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 1. Introduction This draft presents use cases from diverse industries which have in common a need for deterministic streams, but which also differ notably in their network topologies and specific desired behavior. Together, they provide broad industry context for DetNet and a yardstick against which proposed DetNet designs can be measured (to what extent does a proposed design satisfy these various use cases?) @@ -222,387 +222,354 @@ o How would you like it to be addressed in the future? o What do you want the IETF to deliver? The level of detail in each use case should be sufficient to express the relevant elements of the use case, but not more. At the end we consider the use cases collectively, and examine the most significant goals they have in common. -2. Pro Audio Use Cases - -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. +2. Pro Audio and Video - These industries are now attempting to transition to packet based - infrastructure for distributing audio and video in order to reduce - cost, increase routing flexibility, and integrate with existing IT - infrastructure. +2.1. Use Case Description - However, there are several requirements for making a network the - primary infrastructure for audio and video which are not met by - todays networks and these are our concern in this draft. + The professional audio and video industry ("ProAV") includes: - The principal requirement is that pro audio and video applications - 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). + o Music and film content creation - Some proprietary systems have been created which enable deterministic - streams at layer 3 however they are engineered networks in that they - 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. + o Broadcast + o Cinema - It would be highly desirable if such streams could be routed over the - 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. + o Live sound - We also present more fine grained requirements of the audio and video - industries such as safety and security, redundant paths, devices with - 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. + o Public address, media and emergency systems at large venues + (airports, stadiums, churches, theme parks). -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 - deterministic latency as described in this section. Additional - stream requirements are described in a subsequent section. + These industries are now transitioning to packet-based infrastructure + to reduce cost, increase routing flexibility, and integrate with + 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 - activities because guaranteed delivery cannot be achieved by re- - trying the transmission; by the time the missing or corrupt packet - 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). + It would be highly desirable if such streams could be routed over the + open Internet, however solutions with more limited scope (e.g. + enterprise networks) would still provide a substantial improvement. - Providing a way to reserve a specific amount of bandwidth for a given - stream is a key requirement. + The following sections describe specific ProAV use cases. -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 - when a signal is sent over a stream and when it is received, for - example the amount of time delay between when you speak into a - microphone and when your voice emerges from the speaker. Any delay - longer than about 10-15 milliseconds is noticeable by most live - performers, and greater latency makes the system unusable because it - prevents them from playing in time with the other players (see slide - 6 of [SRP_LATENCY]). + Transmitting audio and video streams for live playback is unlike + common file transfer because uninterrupted stream playback in the + presence of network errors cannot be achieved by re-trying the + transmission; by the time the missing or corrupt packet has been + identified it is too late to execute a re-try operation. Buffering + can be used to provide enough delay to allow time for one or more + retries, however this is not an effective solution in applications + where large delays (latencies) are not acceptable (as discussed + below). - The 15ms latency bound is made even more challenging because it is - often the case in network based music production with live electric - instruments that multiple stages of signal processing are used, - connected in series (i.e. from one to the other for example from - 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. + Streams with guaranteed bandwidth can eliminate congestion on the + network as a cause of transmission errors that would lead to playback + interruption. Use of redundant paths can further mitigate + transmission errors to provide greater stream reliability. - In some situations it is acceptable at the local location for content - 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. +2.1.2. Synchronized Stream Playback - In addition to being bounded to within some predictable and - acceptable amount of time (which may be 15 milliseconds or more or - less depending on the application) the latency also has to be - consistent. For example when playing a film consisting of a video - stream and audio stream over a network, those two streams must be - synchronized so that the voice and the picture match up. A common - tolerance for audio/video sync is one NTSC video frame (about 33ms) - and to maintain the audience perception of correct lip sync the + Latency in this context is the time between when a signal is + initially sent over a stream and when it is received. A common + example in ProAV is time-synchronizing audio and video when they take + separate paths through the playback system. In this case the latency + of both the audio and video streams must be bounded and consistent if + the sound is to remain matched to the movement in the video. A + common tolerance for audio/video sync is one NTSC video frame (about + 33ms) and to maintain the audience perception of correct lip sync the latency needs to be consistent within some reasonable tolerance, for example 10%. A common architecture for synchronizing multiple streams that have different paths through the network (and thus potentially different 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 a presentation time which is based on the longest required delay. This implies that all sinks must maintain a common time reference of sufficient accuracy, which can be achieved by any of various techniques. This type of architecture is commonly implemented using a central controller that determines path delays and arbitrates buffering delays. -2.2.2.1. Optimizations - - 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]. +2.1.3. Sound Reinforcement - 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]. + Consider the latency (delay) from when a person speaks into a + microphone to when their voice emerges from the speaker. If this + delay is longer than about 10-15 milliseconds it is noticeable and + 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 - 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. + Note that the 15ms latency bound includes all parts of the signal + path, not just the network, so the network latency must be + significantly less than 15ms. -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 - multiple audio and video industry applications. + In cases where audio phase is a consideration, for example beam- + 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, hospitals) have unique requirements with regards to health, safety and fire concerns. One such requirement is a maximum of 3 seconds for a system to respond to an emergency detection and begin sending appropriate warning signals and alarms without human intervention. For this requirement to be met, the system must support a bounded and acceptable time from a notification signal to specific stream establishment. For further details see [ISO7240-16]. Similar requirements apply when the system is restarted after a power cycle, cable re-connection, or system reconfiguration. In many cases such re-establishment of streaming state must be achieved by the peer devices themselves, i.e. without a central controller (since such a controller may only be present during initial network configuration). Video systems introduce related requirements, for example when - transitioning from one camera feed to another. Such systems - currently use purpose-built hardware to switch feeds smoothly, - 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. + transitioning from one camera feed (video stream) to another (see + [STUDIO_IP] and [ESPN_DC2]). - This also addresses a concern of IT network administrators that are - 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.1.5. Secure Transmission -2.3.3. Layer 3 Interconnecting Layer 2 Islands +2.1.5.1. Safety - As an intermediate step (short of providing guaranteed bandwidth - across the open internet) it would be valuable to provide a way to - connect multiple Layer 2 networks. For example layer 2 techniques - could be used to create a LAN for a single broadcast studio, and - several such studios could be interconnected via layer 3 links. + Professional audio systems can include amplifiers that are capable of + 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). -2.3.4. Secure Transmission +2.1.5.2. Digital Rights Management (DRM) Digital Rights Management (DRM) is very important to the audio and video industries. Any time protected content is introduced into a network there are DRM concerns that must be maintained (see [CONTENT_PROTECTION]). Many aspects of DRM are outside the scope of network technology, however there are cases when a secure link supporting authentication and encryption is required by content owners to carry their audio or video content when it is outside their own secure environment (for example see [DCI]). As an example, two techniques are Digital Transmission Content Protection (DTCP) and High-Bandwidth Digital Content Protection (HDCP). HDCP content is not approved for retransmission within any 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 uses HDCP protection it is only allowed to be placed on the network 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 - links that seamlessly act to deliver the content when the primary - link fails for any reason. In point-to-point systems this is + Some proprietary systems have been created which enable deterministic + streams at Layer 3 however they are "engineered networks" which + 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 requirement in a packet-based system is to provide an alternate path through the network such that no individual link can bring down the system. -2.3.6. Link Aggregation +2.3.3. Link Aggregation For transmitting streams that require more bandwidth than a single link in the target network can support, link aggregation is a technique for combining (aggregating) the bandwidth available on multiple physical links to create a single logical link of the required bandwidth. However, if aggregation is to be used, the network controller (or equivalent) must be able to determine the - maximum latency of any path through the aggregate link (see Bounded - and Consistent Latency section above). + maximum latency of any path through the aggregate link. -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. In order to not overwhelm the CPUs in these devices it is important to limit the amount of traffic that these devices must process. As an example, consider the use of individual seat speakers in a cinema. These speakers are typically required to be cost reduced since the quantities in a single theater can reach hundreds of seats. Discovery protocols alone in a one thousand seat theater can generate enough broadcast traffic to overwhelm a low powered CPU. Thus an installation like this will benefit greatly from some type of traffic segregation that can define groups of seats to reduce traffic within each group. All seats in the theater must still be able to communicate with a central controller. There are many techniques that can be used to support this 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 streaming traffic from reaching potentially low powered sink devices, however there may be other types of broadcast traffic that should be 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 of shared links to a minimum. Because of the MAC Address forwarding nature of Layer 2 bridges it is important that a multicast MAC address is only associated with one stream. This will prevent reservations from forwarding packets from one stream down a path that has no interested sinks simply because there is another stream on that same path that shares the same multicast MAC address. Since each multicast MAC Address can represent 32 different IPv4 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, however due to their continued prevalence, solutions that are 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 - 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. + A central network 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]. -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 - 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.3.8. Reduced Device Cost Due To Reduced Buffer Memory -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 - 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.4. Pro Audio Asks -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 - 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. + o Content delivery with bounded, lowest possible latency -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 - 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] ). + o Single network for A/V and IT traffic - In designing DC2 they replaced as much point-to-point technology as - 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. + o Standards-based, interoperable, multi-vendor - This is the kind of motivation we have to develop these standards - because customers are ready and able to use them. + o IT department friendly + + o Enterprise-wide networks (e.g. size of San Francisco but not the + whole Internet (yet...)) 3. Electrical Utilities 3.1. Use Case Description Many systems that an electrical utility deploys today rely on high availability and deterministic behavior of the underlying networks. Here we present use cases in Transmission, Generation and Distribution, including key timing and reliability metrics. We also discuss security issues and industry trends which affect the