--- 1/draft-ietf-detnet-use-cases-00.txt 2016-02-09 15:19:04.906847995 -0800 +++ 2/draft-ietf-detnet-use-cases-01.txt 2016-02-09 15:19:05.502862917 -0800 @@ -1,32 +1,38 @@ Internet Engineering Task Force E. Grossman, Ed. Internet-Draft DOLBY Intended status: Informational C. Gunther -Expires: June 17, 2016 HARMAN +Expires: August 12, 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 - December 15, 2015 + B. Varga + J. Farkas + Ericsson + F. Goetz + J. Schmitt + Siemens + February 9, 2016 Deterministic Networking Use Cases - draft-ietf-detnet-use-cases-00 + draft-ietf-detnet-use-cases-01 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. @@ -48,71 +54,71 @@ 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 June 17, 2016. + This Internet-Draft will expire on August 12, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6 2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 6 - 2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 6 + 2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7 2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8 - 2.3. Additional Stream Requirements . . . . . . . . . . . . . 8 - 2.3.1. Deterministic Time to Establish Streaming . . . . . . 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 . . . . . . . 9 - 2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 10 - 2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 10 + 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 . . . . 11 - 2.5. Security Considerations . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 13 3. Utility Telecom Use Cases . . . . . . . . . . . . . . . . . . 13 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Telecommunications Trends and General telecommunications - Requirements . . . . . . . . . . . . . . . . . . . . . . 14 - 3.2.1. General Telecommunications Requirements . . . . . . . 14 - 3.2.1.1. Migration to Packet-Switched Network . . . . . . 15 - 3.2.2. Applications, Use cases and traffic patterns . . . . 16 - 3.2.2.1. Transmission use cases . . . . . . . . . . . . . 16 + Requirements . . . . . . . . . . . . . . . . . . . . . . 15 + 3.2.1. General Telecommunications Requirements . . . . . . . 15 + 3.2.1.1. Migration to Packet-Switched Network . . . . . . 16 + 3.2.2. Applications, Use cases and traffic patterns . . . . 17 + 3.2.2.1. Transmission use cases . . . . . . . . . . . . . 17 3.2.2.2. Distribution use case . . . . . . . . . . . . . . 26 3.2.2.3. Generation use case . . . . . . . . . . . . . . . 29 3.2.3. Specific Network topologies of Smart Grid Applications . . . . . . . . . . . . . . . . . . . . 30 3.2.4. Precision Time Protocol . . . . . . . . . . . . . . . 31 3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 32 3.4. Security Considerations . . . . . . . . . . . . . . . . . 32 3.4.1. Current Practices and Their Limitations . . . . . . . 32 3.4.2. Security Trends in Utility Networks . . . . . . . . . 34 3.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 35 @@ -139,48 +145,57 @@ 5.3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . 53 5.4. Operations of Interest for DetNet and PCE . . . . . . . . 54 5.4.1. Packet Marking and Handling . . . . . . . . . . . . . 55 5.4.1.1. Tagging Packets for Flow Identification . . . . . 55 5.4.1.2. Replication, Retries and Elimination . . . . . . 55 5.4.1.3. Differentiated Services Per-Hop-Behavior . . . . 56 5.4.2. Topology and capabilities . . . . . . . . . . . . . . 56 5.5. Security Considerations . . . . . . . . . . . . . . . . . 57 5.6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 57 6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 57 - 6.1. Introduction and background . . . . . . . . . . . . . . . 58 + 6.1. Introduction and background . . . . . . . . . . . . . . . 57 6.2. Network architecture . . . . . . . . . . . . . . . . . . 61 6.3. Time synchronization requirements . . . . . . . . . . . . 62 6.4. Time-sensitive stream requirements . . . . . . . . . . . 63 6.5. Security considerations . . . . . . . . . . . . . . . . . 64 - 7. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 64 + 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 65 - 7.2. Critical Delay Requirements . . . . . . . . . . . . . . . 66 - 7.3. Coordinated multipoint processing (CoMP) . . . . . . . . 66 - 7.3.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 66 - 7.3.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 67 - 7.4. Industrial Automation . . . . . . . . . . . . . . . . . . 68 - 7.5. Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . 68 - 7.6. Gaming, Media and Virtual Reality . . . . . . . . . . . . 69 - 8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 69 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 - 10. Informative References . . . . . . . . . . . . . . . . . . . 70 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 + 7.2. Terminology and Definitions . . . . . . . . . . . . . . . 65 + 7.3. Machine to Machine communication over IP networks . . . . 65 + 7.4. Machine to Machine communication requirements . . . . . . 66 + 7.4.1. Transport parameters . . . . . . . . . . . . . . . . 67 + 7.4.2. Flow maintenance . . . . . . . . . . . . . . . . . . 67 + 7.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 67 + 7.6. Security Considerations . . . . . . . . . . . . . . . . . 68 + 7.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 68 + 8. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 68 + 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 68 + 8.2. Critical Delay Requirements . . . . . . . . . . . . . . . 69 + 8.3. Coordinated multipoint processing (CoMP) . . . . . . . . 70 + 8.3.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 70 + 8.3.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 71 + 8.4. Industrial Automation . . . . . . . . . . . . . . . . . . 71 + 8.5. Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . 71 + 8.6. Gaming, Media and Virtual Reality . . . . . . . . . . . . 72 + 9. Use Case Common Elements . . . . . . . . . . . . . . . . . . 72 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73 + 11. Informative References . . . . . . . . . . . . . . . . . . . 73 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 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?) - For DetNet, use cases explicitly do not define requirements; The DetNet WG will consider the use cases, decide which elements are in scope for DetNet, and the results will be incorporated into future drafts. Similarly, the DetNet use case draft explicitly does not suggest any specific design, architecture or protocols, which will be topics of future drafts. We present for each use case the answers to the following questions: o What is the use case? @@ -2417,37 +2431,35 @@ added, modified, or removed, for instance if it appears that a Track does not perform as expected for, say, PDR. For that case, the expectation is that a protocol that flows along a Track (to be), in a fashion similar to classical Traffic Engineering (TE) [CCAMP], may be used to update the state in the devices. 6TiSCH provides means for a device to negotiate a timeSlot with a neighbor, but in general that flow was not designed and no protocol was selected and it is expected that DetNet will determine the appropriate end-to-end protocols to be used in that case. - Stream Management Entity - Operational System and HMI -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- PCE PCE PCE PCE -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- 6TiSCH / Device Device Device Device \ Device- - 6TiSCH \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device ----Device------Device------Device------Device-- - Figure 8 + Figure 8: Stream Management Entity 5.4.1. Packet Marking and Handling Section "Packet Marking and Handling" of [I-D.ietf-6tisch-architecture] describes the packet tagging and marking that is expected in 6TiSCH networks. 5.4.1.1. Tagging Packets for Flow Identification For packets that are routed by a PCE along a Track, the tuple formed @@ -2885,26 +2896,181 @@ Establishing time-sensitive streams in the network entails reserving networking resources sometimes for a considerable long time. It is important that these reservation requests must be authenticated to prevent malicious reservation attempts from hostile nodes or even accidental misconfiguration. This is specifically important in a case where the reservation requests span administrative domains. Furthermore, the reservation information itself should be digitally signed to reduce the risk where a legitimate node pushed a stale or hostile configuration into the networking node. -7. Other Use Cases +7. Industrial M2M - (This section was derived from draft-zha-detnet-use-case-00) + (This section was derived from draft-varga-industrial-m2m-00) 7.1. Introduction + Traditional "industrial automation" and terminology usually refers to + automation of manufacturing, quality control and material processing. + In practice, it means that machine units in a plant floor need cyclic + control data exchange to upstream or downstream machine modules or to + a supervisory control in a local network, which is often based on + proprietary networking technologies today. + + For such communication between industrial entities, it is critical to + ensure proper and deterministic end to end delivery time of messages + with (very) high reliability and robustness, especially in closed + loop automation control. + + Moreover, the recent trend is to use standard networking technologies + in the local network and for connecting remote industrial automation + sites, e.g., over an enterprise or metro network which also carries + other types of traffic. Therefore, deterministic flows should be + guaranteed regardless of the amount of other flows in those networks + for the deployment of future industrial automation. + + This document covers a selected industrial application, identifies + representative solutions used today, and points on new use cases an + IETF DetNet solution may enable. + +7.2. Terminology and Definitions + + DetNet: Deterministic Networking. [IETFDetNet] + + M2M: Machine to Machine. + + MES: Manufacturing-Execution-System. + + PLC: Programmable Logic Control. + + S-PLC: Supervisory Programmable Logic Control. + +7.3. Machine to Machine communication over IP networks + + In case of industrial automation, the actors of Machine to Machine + (M2M) communication are Programmable Logic Controls (PLC). The + communication between PLCs and between PLCs and the supervisory PLC + (S-PLC) is achieved via critical Control-Data-Streams Figure 10. + This draft focuses on PLC related communications and communication to + Manufacturing-Execution-System (MES) are out-of-scope. The PLC + related Control-Data-Streams are transmitted periodically and they + are established either with (i) a pre-configured payload or (ii) a + payload configuration during runtime. + + S (Sensor) + \ +-----+ + PLC__ \.--. .--. ---| MES | + \_( `. _( `./ +-----+ + A------( Local )-------------( L2 ) + ( Net ) ( Net ) +-------+ + /`--(___.-' `--(___.-' ----| S-PLC | + S_/ / PLC .--. / +-------+ + A_/ \_( `. + (Actuator) ( Local ) + ( Net ) + /`--(___.-'\ + / \ A + S A + + Figure 10: Current generic industrial M2M network architecture + + The network topologies used today by applications of industrial + automation are (i) daisy chain, (ii) ring and (iii) hub and spoke. + Such topologies are often used in telecommunication networks too. In + industrial networks comb (being a subset of daisy-chain) is also + used. + + Some industrial applications require Time Synchronization (Sync) to + end nodes, which is also similar to some telecommunication networks, + e.g., mobile Radio Access Networks. For such time coordinated PLCs, + accuracy of 1 microseconds is required. In case of non-time + coordinated PLCs, a requirement for Time Sync may still exist, e.g., + for time stamping of collected measurement (sensor) data. + +7.4. Machine to Machine communication requirements + + The requirements listed here refer to critical Control-Data-Streams. + Non-critical traffic of industrial automation applications can be + served with currently available prioritizing techniques. + + In an industrial environment, non-time-critical traffic is related to + (i) communication of state, configuration, set-up, etc., (ii) + connection to Manufacturing-Execution-System (MES) and (iii) database + communication. Such type of traffic can use up to 80% of the + available bandwidth. There is a subset of non-time-critical traffic + that their bandwidth should be guaranteed. + + The rest of this chapter is dealing only with time-critical traffic. + +7.4.1. Transport parameters + + The Cycle Time defines the frequency of message(s) between industrial + entities. The Cycle Time is application dependent, it is in the + range of 1ms - 100ms for critical Control-Data-Streams. + + As industrial applications assume deterministic transport instead of + defining latency and delay variation parameters for critical Control- + Data-Stream parameters, it is enough to fulfill the upper bound of + latency (maximum latency). The communication must ensure a maximum + end to end delivery time of messages in the range of 100 microseconds + to 50 milliseconds depending on the control loop application. + + Bandwidth requirements of Control-Data-Streams are usually calculated + directly from the bytes per cycle parameter of the control loop. For + PLC to PLC communication one can expect 2 - 32 streams with packet + size in the range of 100 - 700 bytes. For S-PLC to PLCs the number + of streams is higher up-to 256 streams need to be supported. Usually + no more than 20% of available bandwidth is used for critical Control- + Data-Streams in today's networks, which comprise Gbps links. + + Usual PLC control loops are rather tolerant for packet loss. + Critical Control-Data-Streams accept no more than 1 packet loss per + consecutive communication cycles. The required network availability + is rather high, it hits the 5 nines (99,999%). + + Based on the above parameters, it can be concluded that some form of + redundancy might be required for M2M communication. The actual + solution depends on several parameters, like cycle time, delivery + time, etc. + +7.4.2. Flow maintenance + + Most Critical Control-Data-Streams get created at startup, however, + flexibility is also needed during runtime (e.g. add / remove + machine). In an industrial environment, critical Control-Data- + Streams are created rather infrequent: ~10 times per day / week / + month. With the future advent of flexible production systems, flow + maintenance parameters are expected to increase significantly. + +7.5. Summary + + This document specifies an industrial machine-to-machine use-case in + the DetNet context. + +7.6. Security Considerations + + Industrial network scenarios require advanced security solutions. + Many of the current industrial production networks are physically + separated. Protection of critical flows are handled today by + gateways / firewalls. + +7.7. Acknowledgements + + The authors would like to thank Feng Chen and Marcel Kiessling for + their comments and suggestions. + +8. Other Use Cases + + (This section was derived from draft-zha-detnet-use-case-00) + +8.1. Introduction + The rapid growth of the today's communication system and its access into almost all aspects of daily life has led to great dependency on services it provides. The communication network, as it is today, has applications such as multimedia and peer-to-peer file sharing distribution that require Quality of Service (QoS) guarantees in terms of delay and jitter to maintain a certain level of performance. Meanwhile, mobile wireless communications has become an important part to support modern sociality with increasing importance over the last years. A communication network of hard real-time and high reliability is essential for the next concurrent and next generation @@ -2934,21 +3100,21 @@ provisioning is just relative [rfc3393], which is not sufficient to some delay critical service since delay violation in an instance cannot be tolerated. Overall, the requirements from vertical industries seem to be well aligned with the expected low latency and high determinist performance of future networks This document describes several use cases and scenarios with requirements on deterministic delay guarantee within the scope of the deterministic network [I-D.finn-detnet-problem-statement]. -7.2. Critical Delay Requirements +8.2. Critical Delay Requirements Delay and jitter requirement has been take into account as a major component in QoS provisioning since the birth of Internet. The delay sensitive networking with increasing importance become the root of mobile wireless communications as well as the applicable areas which are all greatly relied on low delay communications. Due to the best effort feature of the IP networking, mitigate contention and buffering is the main solution to serve the delay sensitive service. More bandwidth is assigned to keep the link low loaded or in another word, reduce the probability of congestion. However, not only lack @@ -2970,28 +3136,29 @@ as 100 times of connected devices. As a result to that, simply adding redundant bandwidth provisioning can be no longer an efficient solution due to the high bandwidth requirements more than ever before. In addition to the bandwidth provisioning, the critical flow within its reserved resource should not be affected by other flows no matter the pressure of the network. Robust defense of critical flow is also not depended on redundant bandwidth allocation. Deterministic networking techniques in both layer-2 and layer-3 using IETF protocol solutions can be promising to serve these scenarios. -7.3. Coordinated multipoint processing (CoMP) +8.3. Coordinated multipoint processing (CoMP) In the wireless communication system, Coordinated multipoint processing (CoMP) is considered as an effective technique to solve the inter-cell interference problem to improve the cell-edge user throughput [CoMP]. -7.3.1. CoMP Architecture +8.3.1. CoMP Architecture + +--------------------------+ | CoMP | +--+--------------------+--+ | | +----------+ +------------+ | Uplink | | Downlink | +-----+----+ +--------+---+ | | ------------------- ----------------------- | | | | | | @@ -3000,92 +3167,92 @@ |Reception| | | | | |Transmission| | CB | | | +---------+ +----+ +-----+ +------------+ +-----+ +-----+ | | |----------- |------------- | | | | +------------+ +---------+ +----------+ +------------+ | Joint | | Soft | | Coherent | | Non- | |Equalization| |Combining| | JT | | Coherent JT| +------------+ +---------+ +----------+ +------------+ - Figure 10: Framework of CoMP Technology + Figure 11: Framework of CoMP Technology - As shown in Figure 10, CoMP reception and transmission is a framework + As shown in Figure 11, CoMP reception and transmission is a framework that multiple geographically distributed antenna nodes cooperate to improve the performance of the users served in the common cooperation area. The design principal of CoMP is to extend the current single- cell to multi-UEs transmission to a multi-cell- to-multi-UEs transmission by base station cooperation. In contrast to single-cell scenario, CoMP has critical issues such as: Backhaul latency, CSI (Channel State Information) reporting and accuracy and Network complexity. Clearly the first two requirements are very much delay sensitive and will be discussed in next section. -7.3.2. Delay Sensitivity in CoMP +8.3.2. Delay Sensitivity in CoMP As the essential feature of CoMP, signaling is exchanged between eNBs, the backhaul latency is the dominating limitation of the CoMP performance. Generally, JT and JP may benefit from coordinating the scheduling (distributed or centralized) of different cells in case that the signaling exchanging between eNBs is limited to 4-10ms. For C-RAN the backhaul latency requirement is 250us while for D-RAN it is 4-15ms. And this delay requirement is not only rigid but also absolute since any uncertainty in delay will down the performance significantly. Note that, some operator's transport network is not build to support Layer-3 transfer in aggregation layer. In such case, the signaling is exchanged through EPC which means delay is supposed to be larger. CoMP has high requirement on delay and reliability which is lack by current mobile network systems and may impact the architecture of the mobile network. -7.4. Industrial Automation +8.4. Industrial Automation Traditional "industrial automation" terminology usually refers to automation of manufacturing, quality control and material processing. "Industrial internet" and "industrial 4.0" [EA12] is becoming a hot topic based on the Internet of Things. This high flexible and dynamic engineering and manufacturing will result in a lot of so- called smart approaches such as Smart Factory, Smart Products, Smart Mobility, and Smart Home/Buildings. No doubt that ultra high reliability and robustness is a must in data transmission, especially in the closed loop automation control application where delay requirement is below 1ms and packet loss less than 10E-9. All these critical requirements on both latency and loss cannot be fulfilled by current 4G communication networks. Moreover, the collaboration of the industrial automation from remote campus with cellular and fixed network has to be built on an integrated, cloud-based platform. In this way, the deterministic flows should be guaranteed regardless of the amount of other flows in the network. The lack of this mechanism becomes the main obstacle in deployment on of industrial automation. -7.5. Vehicle to Vehicle +8.5. Vehicle to Vehicle V2V communication has gained more and more attention in the last few years and will be increasingly growth in the future. Not only equipped with direct communication system which is short ranged, V2V communication also requires wireless cellular networks to cover wide range and more sophisticated services. V2V application in the area autonomous driving has very stringent requirements of latency and reliability. It is critical that the timely arrival of information for safety issues. In addition, due to the limitation of processing of individual vehicle, passing information to the cloud can provide more functions such as video processing, audio recognition or navigation systems. All of those requirements lead to a highly reliable connectivity to the cloud. On the other hand, it is natural that the provisioning of low latency communication is one of the main challenges to be overcome as a result of the high mobility, the high penetration losses caused by the vehicle itself. As result of that, the data transmission with latency below 5ms and a high reliability of PER below 10E-6 are demanded. It can benefit from the deployment of deterministic networking with high reliability. -7.6. Gaming, Media and Virtual Reality +8.6. Gaming, Media and Virtual Reality Online gaming and cloud gaming is dominating the gaming market since it allow multiple players to play together with more challenging and competing. Connected via current internet, the latency can be a big issue to degrade the end users' experience. There different types of games and FPS (First Person Shooting) gaming has been considered to be the most latency sensitive online gaming due to the high requirements of timing precision and computing of moving target. Virtual reality is also receiving more interests than ever before as a novel gaming experience. The delay here can be very critical to @@ -3099,21 +3266,21 @@ jitter requirements have to be taken into account to meet the user demand. To make the smoothness of the video and audio, delay and jitter has to be guaranteed to avoid possible interruption which is the killer of all online media on demand service. Now with 4K and 8K video in the near future, the delay guarantee become one of the most challenging issue than ever before. 4K/8K UHD video service requires 6Gbps-100Gbps for uncompressed video and compressed video starting from 60Mbps. The delay requirement is 100ms while some specific interactive applications may require 10ms delay [UHD-video]. -8. Use Case Common Elements +9. Use Case Common Elements Looking at the use cases collectively, the following common desires for the DetNet-based networks of the future emerge: o Open standards-based network (replace various proprietary networks, reduce cost, create multi-vendor market) o Centrally administered (though such administration may be distributed for scale and resiliency) @@ -3143,28 +3310,28 @@ loops may be less than 1ms, but larger for wide area networks) o High availability (99.9999 percent up time requested, but may be up to twelve 9s) o Reliability, redundancy (lives at stake) o Security (from failures, attackers, misbehaving devices - sensitive to both packet content and arrival time) -9. Acknowledgments +10. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Jing Huang, Junru Lin, Lehong Niu and Oilver Huang. -10. Informative References +11. Informative References [ACE] IETF, "Authentication and Authorization for Constrained Environments", . [bacnetip] ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP", January 1999. [CCAMP] IETF, "Common Control and Measurement Plane", @@ -3343,20 +3510,30 @@ . [IEEE8021CM] Farkas, J., "Time-Sensitive Networking for Fronthaul", Unapproved PAR, PAR for a New IEEE Standard; IEEE P802.1CM, April 2015, . + [IEEE8021TSN] + IEEE 802.1, "The charter of the TG is to provide the + specifications that will allow time-synchronized low + latency streaming services through 802 networks.", 2016, + . + + [IETFDetNet] + IETF, "Charter for IETF DetNet Working Group", 2015, + . + [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", . [ISA100.11a] ISA/ANSI, "Wireless Systems for Industrial Automation: Process Control and Related Applications - ISA100.11a-2011 - IEC 62734", 2011, . [ISO7240-16] @@ -3632,10 +3809,41 @@ Applied Communication Sciences 150 Mount Airy Road, Basking Ridge New Jersey, 07920, USA Email: sdas@appcomsci.com Yiyong Zha Huawei Technologies Email: zhayiyong@huawei.com + + Balazs Varga + Ericsson + Konyves Kalman krt. 11/B + Budapest 1097 + Hungary + + Email: balazs.a.varga@ericsson.com + Janos Farkas + Ericsson + Konyves Kalman krt. 11/B + Budapest 1097 + Hungary + + Email: janos.farkas@ericsson.com + + Franz-Josef Goetz + Siemens + Gleiwitzerstr. 555 + Nurnberg 90475 + Germany + + Email: franz-josef.goetz@siemens.com + + Juergen Schmitt + Siemens + Gleiwitzerstr. 555 + Nurnberg 90475 + Germany + + Email: juergen.jues.schmitt@siemens.com