--- 1/draft-ietf-detnet-use-cases-19.txt 2018-12-19 19:13:16.201851556 -0800 +++ 2/draft-ietf-detnet-use-cases-20.txt 2018-12-19 19:13:16.373855718 -0800 @@ -1,18 +1,18 @@ Internet Engineering Task Force E. Grossman, Ed. Internet-Draft DOLBY -Intended status: Informational October 8, 2018 -Expires: April 11, 2019 +Intended status: Informational December 19, 2018 +Expires: June 22, 2019 Deterministic Networking Use Cases - draft-ietf-detnet-use-cases-19 + draft-ietf-detnet-use-cases-20 Abstract This draft presents use cases from diverse industries which have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time- sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for DetNet. For each use case, this document will @@ -29,21 +29,21 @@ 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 https://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 April 11, 2019. + This Internet-Draft will expire on June 22, 2019. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,27 +62,27 @@ 2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 8 2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 8 2.1.4. Secure Transmission . . . . . . . . . . . . . . . . . 9 2.1.4.1. Safety . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . 10 2.3.3. Integration of Reserved Streams into IT Networks . . 10 2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 10 - 2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10 + 2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 11 2.3.5.1. Packet Forwarding Rules, VLANs and Subnets . . . 11 2.3.5.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11 - 2.3.6. Latency Optimization by a Central Controller . . . . 11 + 2.3.6. Latency Optimization by a Central Controller . . . . 12 2.3.7. Reduced Device Cost Due To Reduced Buffer Memory . . 12 2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12 - 3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12 + 3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 13 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 13 3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 13 3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 20 3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21 3.1.2.1. Control of the Generated Power . . . . . . . . . 21 3.1.2.2. Control of the Generation Infrastructure . . . . 22 @@ -105,21 +105,21 @@ 4.2. Building Automation Systems Today . . . . . . . . . . . . 37 4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 37 4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 38 4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 40 4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 40 4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 40 4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 41 4.2.4. Security Considerations . . . . . . . . . . . . . . . 41 4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 41 4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 42 - 5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 42 + 5. Wireless for Industrial Applications . . . . . . . . . . . . 42 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 42 5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 43 5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 43 5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 44 5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 44 5.3.1. Unified Wireless Network and Management . . . . . . . 44 5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 46 5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 47 5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 47 5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 48 @@ -130,105 +130,105 @@ 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 49 6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 50 6.1.3. Time Synchronization Constraints . . . . . . . . . . 52 6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 54 6.1.5. Security Considerations . . . . . . . . . . . . . . . 54 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 55 6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 55 6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 55 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 56 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 58 - 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 59 + 7. Industrial Machine to Machine (M2M) . . . . . . . . . . . . . 59 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 59 7.2. Industrial M2M Communication Today . . . . . . . . . . . 60 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 60 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 61 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 61 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 62 8. Mining Industry . . . . . . . . . . . . . . . . . . . . . . . 62 8.1. Use Case Description . . . . . . . . . . . . . . . . . . 62 8.2. Mining Industry Today . . . . . . . . . . . . . . . . . . 63 8.3. Mining Industry Future . . . . . . . . . . . . . . . . . 63 8.4. Mining Industry Asks . . . . . . . . . . . . . . . . . . 64 9. Private Blockchain . . . . . . . . . . . . . . . . . . . . . 64 9.1. Use Case Description . . . . . . . . . . . . . . . . . . 64 9.1.1. Blockchain Operation . . . . . . . . . . . . . . . . 65 9.1.2. Blockchain Network Architecture . . . . . . . . . . . 65 9.1.3. Security Considerations . . . . . . . . . . . . . . . 66 9.2. Private Blockchain Today . . . . . . . . . . . . . . . . 66 9.3. Private Blockchain Future . . . . . . . . . . . . . . . . 66 - 9.4. Private Blockchain Asks . . . . . . . . . . . . . . . . . 66 + 9.4. Private Blockchain Asks . . . . . . . . . . . . . . . . . 67 10. Network Slicing . . . . . . . . . . . . . . . . . . . . . . . 67 10.1. Use Case Description . . . . . . . . . . . . . . . . . . 67 10.2. DetNet Applied to Network Slicing . . . . . . . . . . . 67 10.2.1. Resource Isolation Across Slices . . . . . . . . . . 67 - 10.2.2. Deterministic Services Within Slices . . . . . . . . 67 + 10.2.2. Deterministic Services Within Slices . . . . . . . . 68 10.3. A Network Slicing Use Case Example - 5G Bearer Network . 68 - 10.4. Non-5G Applications of Network Slicing . . . . . . . . . 68 + 10.4. Non-5G Applications of Network Slicing . . . . . . . . . 69 10.5. Limitations of DetNet in Network Slicing . . . . . . . . 69 10.6. Network Slicing Today and Future . . . . . . . . . . . . 69 10.7. Network Slicing Asks . . . . . . . . . . . . . . . . . . 69 11. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 69 - 11.1. Unified, standards-based network . . . . . . . . . . . . 69 - 11.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 69 - 11.1.2. Centrally Administered . . . . . . . . . . . . . . . 69 + 11.1. Unified, standards-based network . . . . . . . . . . . . 70 + 11.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 70 + 11.1.2. Centrally Administered . . . . . . . . . . . . . . . 70 11.1.3. Standardized Data Flow Information Models . . . . . 70 11.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . 70 11.1.5. Consideration for IPv4 . . . . . . . . . . . . . . . 70 - 11.1.6. Guaranteed End-to-End Delivery . . . . . . . . . . . 70 + 11.1.6. Guaranteed End-to-End Delivery . . . . . . . . . . . 71 11.1.7. Replacement for Multiple Proprietary Deterministic - Networks . . . . . . . . . . . . . . . . . . . . . . 70 + Networks . . . . . . . . . . . . . . . . . . . . . . 71 11.1.8. Mix of Deterministic and Best-Effort Traffic . . . . 71 - 11.1.9. Unused Reserved BW to be Available to Best Effort + 11.1.9. Unused Reserved BW to be Available to Best-Effort Traffic . . . . . . . . . . . . . . . . . . . . . . 71 11.1.10. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 71 11.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . 71 - 11.2.1. Scalable Number of Flows . . . . . . . . . . . . . . 71 + 11.2.1. Scalable Number of Flows . . . . . . . . . . . . . . 72 11.3. Scalable Timing Parameters and Accuracy . . . . . . . . 72 11.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . 72 11.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . 72 11.3.3. Bounded Jitter (Latency Variation) . . . . . . . . . 72 11.3.4. Symmetrical Path Delays . . . . . . . . . . . . . . 72 - 11.4. High Reliability and Availability . . . . . . . . . . . 72 + 11.4. High Reliability and Availability . . . . . . . . . . . 73 11.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 73 11.6. Deterministic Flows . . . . . . . . . . . . . . . . . . 73 - 12. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 73 - 12.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 73 - 12.2. Internet-based Applications . . . . . . . . . . . . . . 74 - 12.2.1. Use Case Description . . . . . . . . . . . . . . . . 74 - 12.2.1.1. Media Content Delivery . . . . . . . . . . . . . 74 - 12.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . 74 - 12.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . 74 - 12.2.2. Internet-Based Applications Today . . . . . . . . . 75 - 12.2.3. Internet-Based Applications Future . . . . . . . . . 75 - 12.2.4. Internet-Based Applications Asks . . . . . . . . . . 75 - 12.3. Pro Audio and Video - Digital Rights Management (DRM) . 75 - 12.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 76 - 12.5. Pro Audio and Video - Deterministic Time to Establish - Streaming . . . . . . . . . . . . . . . . . . . . . . . 76 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 76 - 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77 - 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 - 15.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 78 - 15.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 79 - 15.3. Building Automation Systems . . . . . . . . . . . . . . 79 - 15.4. Wireless for Industrial . . . . . . . . . . . . . . . . 79 - 15.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 79 - 15.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 79 - 15.7. Internet Applications and CoMP . . . . . . . . . . . . . 80 - 15.8. Network Slicing . . . . . . . . . . . . . . . . . . . . 80 - 15.9. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 80 - 15.10. Private Blockchain . . . . . . . . . . . . . . . . . . . 80 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 - 17. Informative References . . . . . . . . . . . . . . . . . . . 80 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 87 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 73 + 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 74 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 75 + 14.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 75 + 14.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 76 + 14.3. Building Automation Systems . . . . . . . . . . . . . . 76 + 14.4. Wireless for Industrial Applications . . . . . . . . . . 76 + 14.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 76 + 14.6. Industrial Machine to Machine (M2M) . . . . . . . . . . 77 + 14.7. Internet Applications and CoMP . . . . . . . . . . . . . 77 + 14.8. Network Slicing . . . . . . . . . . . . . . . . . . . . 77 + 14.9. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 77 + 14.10. Private Blockchain . . . . . . . . . . . . . . . . . . . 77 + 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 + 16. Informative References . . . . . . . . . . . . . . . . . . . 77 + Appendix A. Use Cases Explicitly Out of Scope for DetNet . . . . 84 + A.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 85 + A.2. Internet-based Applications . . . . . . . . . . . . . . . 85 + A.2.1. Use Case Description . . . . . . . . . . . . . . . . 86 + A.2.1.1. Media Content Delivery . . . . . . . . . . . . . 86 + A.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 86 + A.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 86 + A.2.2. Internet-Based Applications Today . . . . . . . . . . 86 + A.2.3. Internet-Based Applications Future . . . . . . . . . 86 + A.2.4. Internet-Based Applications Asks . . . . . . . . . . 86 + A.3. Pro Audio and Video - Digital Rights Management (DRM) . . 87 + A.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 87 + A.5. Pro Audio and Video - Deterministic Time to Establish + Streaming . . . . . . . . . . . . . . . . . . . . . . . . 87 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 88 1. Introduction This draft documents use cases in diverse industries which require deterministic flows over multi-hop paths. DetNet flows can be established from either a Layer 2 or Layer 3 (IP) interface, and such flows can co-exist on an IP network with best-effort traffic. DetNet also provides for highly reliable flows through provision for redundant paths. @@ -253,24 +253,24 @@ long term reference to the problems they expect to be served by the technology, both in the short term deliverables and as the technology evolves in the future. The DetNet Use Cases document has served as a "yardstick" against which proposed DetNet designs can be measured, answering the question "to what extent does a proposed design satisfy these various use cases?" The Use Case industries covered are professional audio, electrical - utilities, building automation systems, wireless for industrial, - cellular radio, industrial machine-to-machine, mining, private - blockchain, and network slicing. For each use case the following - questions are answered: + utilities, building automation systems, wireless for industrial + applications, cellular radio, industrial machine-to-machine, mining, + private blockchain, and network slicing. For each use case the + following questions are answered: o What is the use case? o How is it addressed today? o How should it be addressed in the future? o What should the IETF deliver to enable this use case? The level of detail in each use case is intended to be sufficient to @@ -333,20 +333,23 @@ 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). 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. + Additional techniques such as forward error correction can also be + used to improve stream reliability. + 2.1.2. Synchronized Stream Playback 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 @@ -411,25 +414,25 @@ multi-vendor packet-based infrastructure requires effective open standards, and 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] ). + As an example, ESPN 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 @@ -443,38 +446,38 @@ system. 2.3.3. 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. + network for best-effort (non-time-sensitive) traffic. 2.3.4. 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- + "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"). + will have no bandwidth left". 2.3.5. 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. @@ -612,21 +615,21 @@ o Dependability: The ability to issue and receive valid commands in the presence of interference and/or noise, by minimizing the probability of missing command (PMC). Dependability targets are typically set for a specific bit error rate (BER) level. o Security: The ability to prevent false tripping due to a noisy environment, by minimizing the probability of unwanted commands (PUC). Security targets are also set for a specific bit error rate (BER) level. - Additional elements of the the teleprotection system that impact its + Additional elements of the teleprotection system that impact its performance include: o Network bandwidth o Failure recovery capacity (aka resiliency) 3.1.1.1.2. Fault Detection and Clearance Timing Most power line equipment can tolerate short circuits or faults for up to approximately five power cycles before sustaining irreversible @@ -903,26 +906,26 @@ | Packet loss | 1% | | Consecutive Packet | At least 1 packet per application cycle | | Loss | must be received. | +----------------------+--------------------------------------------+ Table 7: WAMS Special Communication Requirements 3.1.1.4. IEC 61850 WAN engineering guidelines requirement classification - The IEC (International Electrotechnical Commission) has recently - published a Technical Report which offers guidelines on how to define - and deploy Wide Area Networks for the interconnections of electric - substations, generation plants and SCADA operation centers. The IEC - 61850-90-12 is providing a classification of WAN communication - requirements into 4 classes. Table 8 summarizes these requirements: + The IEC (International Electrotechnical Commission) has published a + Technical Report which offers guidelines on how to define and deploy + Wide Area Networks for the interconnections of electric substations, + generation plants and SCADA operation centers. The IEC 61850-90-12 + is providing a classification of WAN communication requirements into + 4 classes. Table 8 summarizes these requirements: +----------------+------------+------------+------------+-----------+ | WAN | Class WA | Class WB | Class WC | Class WD | | Requirement | | | | | +----------------+------------+------------+------------+-----------+ | Application | EHV (Extra | HV (High | MV (Medium | General | | field | High | Voltage) | Voltage) | purpose | | | Voltage) | | | | | Latency | 5 ms | 10 ms | 100 ms | > 100 ms | | Jitter | 10 us | 100 us | 1 ms | 10 ms | @@ -1112,26 +1115,26 @@ both ends. The AS path between the local control center and the Wind Park typically involves several ISPs at different tiers. For example, a remote control center in Denmark can regulate a wind park in Greece over the normal public AS path between the two locations. The remote control center is part of the SCADA system, setting the desired power output to the wind park and reading back the result once the new power output level has been set. Traffic between the remote control center and the wind park typically consists of protocols like IEC 60870-5-104 [IEC-60870-5-104], OPC XML-DA - [OPCXML], Modbus [MODBUS], and SNMP [RFC3411]. Currently, traffic - flows between the wind farm and the remote control center are best - effort. QoS requirements are not strict, so no SLAs or service - provisioning mechanisms (e.g., VPN) are employed. In case of events - like equipment failure, tolerance for alarm delay is on the order of - minutes, due to redundant systems already in place. + [OPCXML], Modbus [MODBUS], and SNMP [RFC3411]. At the time of this + writing, traffic flows between the wind farm and the remote control + center are best effort. QoS requirements are not strict, so no SLAs + or service provisioning mechanisms (e.g., VPN) are employed. In case + of events like equipment failure, tolerance for alarm delay is on the + order of minutes, due to redundant systems already in place. +--------------+ | | | | | Wind Park #1 +----+ | | | XXXXXX | | | X XXXXXXXX +----------------+ +--------------+ | XXXX X XXXXX | | +---+ XXX | Remote Control | XXX Internet +----+ Center | @@ -1329,22 +1332,22 @@ be based on open-standards-based IP architecture. An end-to-end IP architecture takes advantage of nearly three decades of IP technology development, facilitating interoperability and device management across disparate networks and devices, as it has been already demonstrated in many mission-critical and highly secure networks. IPv6 is seen as a future telecommunications technology for the Smart Grid; the IEC (International Electrotechnical Commission) and different National Committees have mandated a specific adhoc group (AHG8) to define the migration strategy to IPv6 for all the IEC TC57 - power automation standards. The AHG8 has recently finalised the work - on the migration strategy and the following Technical Report has been + power automation standards. The AHG8 has finalised the work on the + migration strategy and the following Technical Report has been issued: IEC TR 62357-200:2015: Guidelines for migration from Internet Protocol version 4 (IPv4) to Internet Protocol version 6 (IPv6). Cloud-based SCADA systems will control and monitor the critical and non-critical subsystems of generation systems, for example wind farms. 3.3.1. Migration to Packet-Switched Network Throughout the world, utilities are increasingly planning for a @@ -1448,21 +1451,21 @@ Going forward, one network will support operation and maintenance of electrical networks (generation, transmission, and distribution), voice and data services for ten of thousands of employees and for exchange with neighboring interconnections, and administrative services. To meet those requirements, utility may deploy several physical networks leveraging different technologies across the country: an optical network and a microwave network for instance. Each protection and automatism system between two points has two telecommunications circuits, one on each network. Path diversity between two substations is key. Regardless of the event type - (hurricane, ice storm, etc.), one path shall stay available so the + (hurricane, ice storm, etc.), one path needs to stay available so the system can still operate. In the optical network, signals are transmitted over more than tens of thousands of circuits using fiber optic links, microwave and telephone cables. This network is the nervous system of the utility's power transmission operations. The optical network represents ten of thousands of km of cable deployed along the power lines, with individual runs as long as 280 km. 3.3.2.3. Precision Time Protocol @@ -1543,22 +1546,22 @@ telecommunications assets used to operate, monitor, and control power flow and measurement. "Cyber security" refers to all the security issues in automation and telecommunications that affect any functions related to the operation of the electric power systems. Specifically, it involves the concepts of: o Integrity : data cannot be altered undetectably - o Authenticity : the telecommunications parties involved must be - validated as genuine + o Authenticity (data origin authentication): the telecommunications + parties involved must be validated as genuine o Authorization : only requests and commands from the authorized users can be accepted by the system o Confidentiality : data must not be accessible to any unauthenticated users When designing and deploying new smart grid devices and telecommunications systems, it is imperative to understand the various impacts of these new components under a variety of attack @@ -1688,26 +1691,26 @@ A LC is typically a Programmable Logic Controller (PLC) which is connected to several tens or hundreds of devices using "field protocols". An LC performs the following kinds of operations: o Measure device states and provide the information to BMS or HMI. o Send control values to devices, unilaterally or as part of a feedback control loop. - There are many field protocols used today; some are standards-based - and others are proprietary (see standards [lontalk], [modbus], - [profibus] and [flnet]). The result is that BASs have multiple MAC/ - PHY modules and interfaces. This makes BASs more expensive, slower - to develop, and can result in "vendor lock-in" with multiple types of - management applications. + There are many field protocols used at the time of this writing; some + are standards-based and others are proprietary (see standards + [lontalk], [modbus], [profibus] and [flnet]). The result is that + BASs have multiple MAC/PHY modules and interfaces. This makes BASs + more expensive, slower to develop, and can result in "vendor lock-in" + with multiple types of management applications. 4.2.2. BAS Deployment Model An example BAS for medium or large buildings is shown in Figure 5. The physical layout spans multiple floors, and there is a monitoring room where the BAS management entities are located. Each floor will have one or more LCs depending upon the number of devices connected to the field network. +--------------------------------------------------+ @@ -1867,47 +1870,45 @@ o Availability of network data in disaster scenario o Authentication between management and field devices (both local and remote) o Integrity and data origin authentication of communication data between field and management devices o Confidentiality of data when communicated to a remote device -5. Wireless for Industrial +5. Wireless for Industrial Applications 5.1. Use Case Description Wireless networks are useful for industrial applications, for example when portable, fast-moving or rotating objects are involved, and for the resource-constrained devices found in the Internet of Things (IoT). Such network-connected sensors, actuators, control loops (etc.) typically require that the underlying network support real-time quality of service (QoS), as well as specific classes of other network properties such as reliability, redundancy, and security. These networks may also contain very large numbers of devices, for example for factories, "big data" acquisition, and the IoT. Given the large numbers of devices installed, and the potential pervasiveness of the IoT, this is a huge and very cost-sensitive - market. For example, a 1% cost reduction in some areas could save - $100B + market such that small cost reductions can save large amounts of + money. 5.1.1. Network Convergence using 6TiSCH Some wireless network technologies support real-time QoS, and are - thus useful for these kinds of networks, but others do not. For - example WiFi is pervasive but does not provide guaranteed timing or - delivery of packets, and thus is not useful in this context. + thus useful for these kinds of networks, but others do not. This use case focuses on one specific wireless network technology which provides the required deterministic QoS, which is "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH, where TSCH stands for "Time-Slotted Channel Hopping", see [I-D.ietf-6tisch-architecture], [IEEE802154], [IEEE802154e], and [RFC7554]). There are other deterministic wireless busses and networks available today, however they are imcompatible with each other, and incompatible with IP traffic (for example [ISA100], [WirelessHART]). @@ -1944,24 +1945,23 @@ resources in a manner that minimizes the interaction with and the load placed on resource-constrained devices. For example, a tiny IoT device may have just enough buffers to store one or a few IPv6 packets, and will have limited bandwidth between peers such that it can maintain only a small amount of peer information, and will not be able to store many packets waiting to be forwarded. It is advantageous then for it to only be required to carry out the specific behavior assigned to it by the PCE/NME (as opposed to maintaining its own IP stack, for example). - Note: Current WG discussion indicates that some peer-to-peer - communication must be assumed, i.e. the PCE may communicate only - indirectly with any given device, enabling hierarchical configuration - of the system. + It is possible that there will be some peer-to-peer communication, + for example the PCE may communicate only indirectly with some devices + in order to enable hierarchical configuration of the system. 6TiSCH depends on [PCE] and [I-D.ietf-detnet-architecture]. 6TiSCH also depends on the fact that DetNet will maintain consistency with [IEEE802.1TSNTG]. 5.2. Wireless Industrial Today Today industrial wireless is accomplished using multiple deterministic wireless networks which are incompatible with each @@ -2047,23 +2047,20 @@ o / o o---o----/ o o o---o--/ o o o o o o \ / o o LLN o o v <---- Replication o Figure 9: 6TiSCH Network with PRE 5.3.1.1. PCE and 6TiSCH ARQ Retries - Note: The possible use of ARQ techniques in DetNet is currently - considered a possible design alternative. - 6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism to provide higher reliability of packet delivery. ARQ is related to packet replication and elimination because there are two independent paths for packets to arrive at the destination, and if an expected packed does not arrive on one path then it checks for the packet on the second path. Although to date this mechanism is only used by wireless networks, this may be a technique that would be appropriate for DetNet and so aspects of the enabling protocol could be co-developed. @@ -2076,26 +2073,26 @@ each packet over two different branches, and the PCE schedules each hop of both branches so that the two copies arrive in due time at the gateway. In case of a loss on one branch, hopefully the other copy of the packet still arrives within the allocated time. If two copies make it to the IoT gateway, the Elimination function in the gateway ignores the extra packet and presents only one copy to upper layers. At each 6TiSCH hop along the Track, the PCE may schedule more than one timeSlot for a packet, so as to support Layer-2 retries (ARQ). - In current deployments, a TSCH Track does not necessarily support PRE - but is systematically multi-path. This means that a Track is - scheduled so as to ensure that each hop has at least two forwarding - solutions, and the forwarding decision is to try the preferred one - and use the other in case of Layer-2 transmission failure as detected - by ARQ. + In deployments at the time of this writing, a TSCH Track does not + necessarily support PRE but is systematically multi-path. This means + that a Track is scheduled so as to ensure that each hop has at least + two forwarding solutions, and the forwarding decision is to try the + preferred one and use the other in case of Layer-2 transmission + failure as detected by ARQ. 5.3.2. Schedule Management by a PCE A common feature of 6TiSCH and DetNet is the action of a PCE to configure paths through the network. Specifically, what is needed is a protocol and data model that the PCE will use to get/set the relevant configuration from/to the devices, as well as perform operations on the devices. This protocol should be developed by DetNet with consideration for its reuse by 6TiSCH. The remainder of this section provides a bit more context from the 6TiSCH side. @@ -2196,28 +2193,28 @@ 6.1. Use Case Description This use case describes the application of deterministic networking in the context of cellular telecom transport networks. Important elements include time synchronization, clock distribution, and ways of establishing time-sensitive streams for both Layer-2 and Layer-3 user plane traffic. 6.1.1. Network Architecture - Figure 10 illustrates a typical 3GPP-defined cellular network - architecture, which includes "Fronthaul", "Midhaul" and "Backhaul" - network segments. The "Fronthaul" is the network connecting base - stations (baseband processing units) to the remote radio heads - (antennas). The "Midhaul" is the network inter-connecting base - stations (or small cell sites). The "Backhaul" is the network or - links connecting the radio base station sites to the network - controller/gateway sites (i.e. the core of the 3GPP cellular + Figure 10 illustrates a 3GPP-defined cellular network architecture + typical at the time of this writing, which includes "Fronthaul", + "Midhaul" and "Backhaul" network segments. The "Fronthaul" is the + network connecting base stations (baseband processing units) to the + remote radio heads (antennas). The "Midhaul" is the network inter- + connecting base stations (or small cell sites). The "Backhaul" is + the network or links connecting the radio base station sites to the + network controller/gateway sites (i.e. the core of the 3GPP cellular network). In Figure 10 "eNB" ("E-UTRAN Node B") is the hardware that is connected to the mobile phone network which communicates directly with mobile handsets ([TS36300]). Y (remote radio heads (antennas)) \ Y__ \.--. .--. +------+ \_( `. +---+ _(Back`. | 3GPP | @@ -2307,42 +2304,42 @@ starting point. These future systems should support much higher data volumes and rates and significantly lower end-to-end latency for 100x more connected devices (at similar cost and energy consumption levels as today's system). For Midhaul connections, delay constraints are driven by Inter-Site radio functions like Coordinated Multipoint Processing (CoMP, see [CoMP]). CoMP reception and transmission is a framework in which 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-UE (User Equipment) transmission to a multi-cell-to- - multi-UEs transmission by base station cooperation. + area. The design principal of CoMP is to extend single-cell to + multi-UE (User Equipment) transmission to a multi-cell-to-multi-UEs + transmission by base station cooperation. CoMP has delay-sensitive performance parameters, which are "midhaul latency" and "CSI (Channel State Information) reporting and accuracy". The essential feature of CoMP is signaling between eNBs, so Midhaul latency is the dominating limitation of CoMP performance. Generally, CoMP can benefit from coordinated scheduling (either distributed or centralized) of different cells if the signaling delay between eNBs is within 1-10ms. This delay requirement is both rigid and absolute because any uncertainty in delay will degrade the performance significantly. Inter-site CoMP is one of the key requirements for 5G and is also a - near-term goal for the current 4.5G network architecture. + goal for 4.5G network architecture. 6.1.3. Time Synchronization Constraints Fronthaul time synchronization requirements are given by [TS25104], [TS36104], [TS36211], and [TS36133]. These can be summarized for the - current 3GPP LTE-based networks as: + 3GPP LTE-based networks as: Delay Accuracy: +-8ns (i.e. +-1/32 Tc, where Tc is the UMTS Chip time of 1/3.84 MHz) resulting in a round trip accuracy of +-16ns. The value is this low to meet the 3GPP Timing Alignment Error (TAE) measurement requirements. Note: performance guarantees of low nanosecond values such as these are considered to be below the DetNet layer - it is assumed that the underlying implementation, e.g. the hardware, will provide sufficient support (e.g. buffering) to enable this level of accuracy. These values are maintained in the @@ -2369,33 +2366,33 @@ without MIMO or TX diversity, TAE shall not exceed 260 ns (i.e. one Tc). * For inter-band carrier aggregation, with or without MIMO or TX diversity, TAE shall not exceed 260 ns. Transport link contribution to radio frequency error: +-2 PPB. This value is considered to be "available" for the Fronthaul link out of the total 50 PPB budget reserved for the radio interface. Note: the reason that the transport link - contributes to radio frequency error is as follows. The current - way of doing Fronthaul is from the radio unit to remote radio head - directly. The remote radio head is essentially a passive device - (without buffering etc.) The transport drives the antenna - directly by feeding it with samples and everything the transport - adds will be introduced to radio as-is. So if the transport - causes additional frequency error that shows immediately on the - radio as well. Note: performance guarantees of low nanosecond - values such as these are considered to be below the DetNet layer - - it is assumed that the underlying implementation, e.g. the - hardware, will provide sufficient support to enable this level of - performance. These values are maintained in the use case to give - an indication of the overall application. + contributes to radio frequency error is as follows. At the time + of this writing, Fronthaul communication is from the radio unit to + remote radio head directly. The remote radio head is essentially + a passive device (without buffering etc.) The transport drives + the antenna directly by feeding it with samples and everything the + transport adds will be introduced to radio as-is. So if the + transport causes additional frequency error that shows immediately + on the radio as well. Note: performance guarantees of low + nanosecond values such as these are considered to be below the + DetNet layer - it is assumed that the underlying implementation, + e.g. the hardware, will provide sufficient support to enable this + level of performance. These values are maintained in the use case + to give an indication of the overall application. The above listed time synchronization requirements are difficult to meet with point-to-point connected networks, and more difficult when the network includes multiple hops. It is expected that networks must include buffering at the ends of the connections as imposed by the jitter requirements, since trying to meet the jitter requirements in every intermediate node is likely to be too costly. However, every measure to reduce jitter and delay on the path makes it easier to meet the end-to-end requirements. @@ -2415,30 +2412,32 @@ Fronthaul and Midhaul networks assume almost error-free transport. Errors can result in a reset of the radio interfaces, which can cause reduced throughput or broken radio connectivity for mobile customers. For packetized Fronthaul and Midhaul connections packet loss may be caused by BER, congestion, or network failure scenarios. Different fronthaul functional splits are being considered by 3GPP, requiring strict frame loss ratio (FLR) guarantees. As one example (referring to the legacy CPRI split which is option 8 in 3GPP) lower layers splits may imply an FLR of less than 10E-7 for data traffic and less - than 10E-6 for control and management traffic. Current tools for - eliminating packet loss for Fronthaul and Midhaul networks have - serious challenges, for example retransmitting lost packets and/or - using forward error correction (FEC) to circumvent bit errors is - practically impossible due to the additional delay incurred. Using - redundant streams for better guarantees for delivery is also - practically impossible in many cases due to high bandwidth - requirements of Fronthaul and Midhaul networks. Protection switching - is also a candidate but current technologies for the path switch are - too slow to avoid reset of mobile interfaces. + than 10E-6 for control and management traffic. + + Many of the tools available for eliminating packet loss for Fronthaul + and Midhaul networks have serious challenges, for example + retransmitting lost packets and/or using forward error correction + (FEC) to circumvent bit errors is practically impossible due to the + additional delay incurred. Using redundant streams for better + guarantees for delivery is also practically impossible in many cases + due to high bandwidth requirements of Fronthaul and Midhaul networks. + Protection switching is also a candidate but at the time of this + writing, available technologies for the path switch are too slow to + avoid reset of mobile interfaces. Fronthaul links are assumed to be symmetric, and all Fronthaul streams (i.e. those carrying radio data) have equal priority and cannot delay or pre-empt each other. This implies that the network must guarantee that each time-sensitive flow meets their schedule. 6.1.5. Security Considerations Establishing time-sensitive streams in the network entails reserving networking resources for long periods of time. It is important that @@ -2458,22 +2457,22 @@ 6.2.1. Fronthaul Today's Fronthaul networks typically consist of: o Dedicated point-to-point fiber connection is common o Proprietary protocols and framings o Custom equipment and no real networking - Current solutions for Fronthaul are direct optical cables or - Wavelength-Division Multiplexing (WDM) connections. + At the time of this writing, solutions for Fronthaul are direct + optical cables or Wavelength-Division Multiplexing (WDM) connections. 6.2.2. Midhaul and Backhaul Today's Midhaul and Backhaul networks typically consist of: o Mostly normal IP networks, MPLS-TP, etc. o Clock distribution and sync using 1588 and SyncE Telecommunication networks in the Mid- and Backhaul are already @@ -2544,55 +2543,53 @@ extreme for packet based technologies, for example, on the order of sub +-20 ns packet delay variation (PDV) and frequency accuracy of +0.002 PPM [Fronthaul]. The actual transport protocols and/or solutions to establish required transport "circuits" (pinned-down paths) for Fronthaul traffic are still undefined. Those are likely to include (but are not limited to) solutions directly over Ethernet, over IP, and using MPLS/ PseudoWire transport. - Even the current time-sensitive networking features may not be - sufficient for Fronthaul traffic. Therefore, having specific - profiles that take the requirements of Fronthaul into account is - desirable [IEEE8021CM]. - Interesting and important work for time-sensitive networking has been done for Ethernet [TSNTG], which specifies the use of IEEE 1588 time precision protocol (PTP) [IEEE1588] in the context of IEEE 802.1D and IEEE 802.1Q. [IEEE8021AS] specifies a Layer 2 time synchronizing service, and other specifications such as IEEE 1722 [IEEE1722] specify Ethernet-based Layer-2 transport for time-sensitive streams. + However even these Ethernet TSN features may not be sufficient for + Fronthaul traffic. Therefore, having specific profiles that take the + requirements of Fronthaul into account is desirable [IEEE8021CM]. + New promising work seeks to enable the transport of time-sensitive fronthaul streams in Ethernet bridged networks [IEEE8021CM]. Analogous to IEEE 1722 there is an ongoing standardization effort to define the Layer-2 transport encapsulation format for transporting radio over Ethernet (RoE) in the IEEE 1904.3 Task Force [IEEE19143]. As mentioned in Section 6.1.2, 5G communications will provide one of the most challenging cases for delay sensitive networking. In order to meet the challenges of ultra-low latency and ultra-high throughput, 3GPP has studied various "functional splits" for 5G, i.e., physical decomposition of the gNodeB base station and deployment of its functional blocks in different locations [TR38801]. These splits are numbered from split option 1 (Dual Connectivity, a split in which the radio resource control is centralized and other radio stack layers are in distributed units) to split option 8 (a PHY-RF split in which RF functionality is in a distributed unit and the rest of the radio stack is in the centralized unit), with each intermediate split having its own data rate and delay requirements. - Packetized versions of different splits have recently been proposed - including eCPRI [eCPRI] and RoE (as previously noted). Both provide - Ethernet encapsulations, and eCPRI is also capable of IP - encapsulation. + Packetized versions of different splits have been proposed including + eCPRI [eCPRI] and RoE (as previously noted). Both provide Ethernet + encapsulations, and eCPRI is also capable of IP encapsulation. All-IP RANs and xHaul networks would benefit from time synchronization and time-sensitive transport services. Although Ethernet appears to be the unifying technology for the transport, there is still a disconnect providing Layer 3 services. The protocol stack typically has a number of layers below the Ethernet Layer 2 that shows up to the Layer 3 IP transport. It is not uncommon that on top of the lowest layer (optical) transport there is the first layer of Ethernet followed one or more layers of MPLS, PseudoWires and/or other tunneling protocols finally carrying the Ethernet layer @@ -2642,21 +2639,21 @@ mmWave, etc.). A standard for data flow information models that are: o Aware of the time sensitivity and constraints of the target networking environment o Aware of underlying deterministic networking services (e.g., on the Ethernet layer) -7. Industrial M2M +7. Industrial Machine to Machine (M2M) 7.1. Use Case Description Industrial Automation in general refers to automation of manufacturing, quality control and material processing. This "machine to machine" (M2M) use case considers machine units in a plant floor which periodically exchange data with upstream or downstream machine modules and/or a supervisory controller within a local area network. @@ -2681,24 +2678,25 @@ S A Figure 11: Current Generic Industrial M2M Network Architecture This use case focuses on PLC-related communications; communication to Manufacturing-Execution-Systems (MESs) are not addressed. This use case covers only critical control/data streams; non-critical traffic between industrial automation applications (such as communication of state, configuration, set-up, and database - communication) are adequately served by currently available - prioritizing techniques. Such traffic can use up to 80% of the total - bandwidth required. There is also a subset of non-time-critical - traffic that must be reliable even though it is not time sensitive. + communication) are adequately served by prioritizing techniques + available at the time of this writing. Such traffic can use up to + 80% of the total bandwidth required. There is also a subset of non- + time-critical traffic that must be reliable even though it is not + time-sensitive. In this use case the primary need for deterministic networking is to provide end-to-end delivery of M2M messages within specific timing constraints, for example in closed loop automation control. Today this level of determinism is provided by proprietary networking technologies. In addition, standard networking technologies are used to connect the local network to remote industrial automation sites, e.g. over an enterprise or metro network which also carries other types of traffic. Therefore, flows that should be forwarded with deterministic guarantees need to be sustained regardless of the @@ -2715,25 +2713,25 @@ PLC-related control/data streams are transmitted periodically and carry either a pre-configured payload or a payload configured during runtime. Some industrial applications require time synchronization at the end nodes. For such time-coordinated PLCs, accuracy of 1 microsecond is required. Even in the case of "non-time-coordinated" PLCs time sync may be needed e.g. for timestamping of sensor data. - Industrial network scenarios require advanced security solutions. - Many of the current industrial production networks are physically - separated. Preventing critical flows from be leaked outside a domain - is handled today by filtering policies that are typically enforced in - firewalls. + Industrial network scenarios require advanced security solutions. At + the time of this writing, many industrial production networks are + physically separated. Preventing critical flows from being leaked + outside a domain is handled by filtering policies that are typically + enforced in firewalls. 7.2.1. Transport Parameters The Cycle Time defines the frequency of message(s) between industrial actors. The Cycle Time is application dependent, in the range of 1ms - 100ms for critical control/data streams. Because industrial applications assume deterministic transport for critical Control-Data-Stream parameters (instead of defining latency and delay variation parameters) it is sufficient to fulfill the upper @@ -2751,61 +2749,61 @@ streams. In today's networks 1Gbps links are commonly used. Most PLC control loops are rather tolerant of packet loss, however critical control/data streams accept no more than 1 packet loss per consecutive communication cycle (i.e. if a packet gets lost in cycle "n", then the next cycle ("n+1") must be lossless). After two or more consecutive packet losses the network may be considered to be "down" by the Application. As network downtime may impact the whole production system the - required network availability is rather high (99,999%). + required network availability is rather high (99.999%). Based on the above parameters some form of redundancy will be required for M2M communications, however any individual solution depends on several parameters including cycle time, delivery time, etc. 7.2.2. Stream Creation and Destruction In an industrial environment, critical control/data streams are created rather infrequently, on the order of ~10 times per day / week / month. Most of these critical control/data streams get created at machine startup, however flexibility is also needed during runtime, for example when adding or removing a machine. Going forward as production systems become more flexible, there will be a significant increase in the rate at which streams are created, changed and destroyed. 7.3. Industrial M2M Future - A converged IP-standards-based network with deterministic properties - that can satisfy the timing, security and reliability constraints - described above. Today's proprietary networks could then be - interfaced to such a network via gateways or, in the case of new + We foresee a converged IP-standards-based network with deterministic + properties that can satisfy the timing, security and reliability + constraints described above. Today's proprietary networks could then + be interfaced to such a network via gateways or, in the case of new installations, devices could be connected directly to the converged network. For this use case time synchronization accuracy on the order of 1us is expected. 7.4. Industrial M2M Asks o Converged IP-based network o Deterministic behavior (bounded latency and jitter ) o High availability (presumably through redundancy) (99.999 %) o Low message delivery time (100us - 50ms) - o Low packet loss (burstless, 0.1-1 %) + o Low packet loss (with bounded number of consecutive lost packets) o Security (e.g. prevent critical flows from being leaked between physically separated networks) 8. Mining Industry 8.1. Use Case Description The mining industry is highly dependent on networks to monitor and control their systems both in open-pit and underground extraction, @@ -2814,77 +2812,81 @@ processes have migrated the operators from the extraction site to remote control and monitoring. In the case of open pit mining, autonomous trucks are used to transport the raw materials from the open pit to the refining factory where the final product (e.g. Copper) is obtained. Although the operation is autonomous, the tracks are remotely monitored from a central facility. In pit mines, the monitoring of the tailings or mine dumps is - critical in order to avoid any environmental pollution. In the past, + critical in order to minimize environmental pollution. In the past, monitoring has been conducted through manual inspection of pre- installed dataloggers. Cabling is not usually exploited in such - scenarios due to the cost and complex deployment requirements. - Currently, wireless technologies are being employed to monitor these - cases permanently. Slopes are also monitored in order to anticipate - possible mine collapse. Due to the unstable terrain, cable - maintenance is costly and complex and hence wireless technologies are - employed. + scenarios due to the cost and complex deployment requirements. At + the time of this writing, wireless technologies are being employed to + monitor these cases permanently. Slopes are also monitored in order + to anticipate possible mine collapse. Due to the unstable terrain, + cable maintenance is costly and complex and hence wireless + technologies are employed. In the underground monitoring case, autonomous vehicles with extraction tools travel autonomously through the tunnels, but their operational tasks (such as excavation, stone breaking and transport) are controlled remotely from a central facility. This generates video and feedback upstream traffic plus downstream actuator control traffic. 8.2. Mining Industry Today - Currently the mining industry uses a packet switched architecture - supported by high speed ethernet. However in order to achieve the - delay and packet loss requirements the network bandwidth is - overestimated, thus providing very low efficiency in terms of - resource usage. + At the time of this writing, the mining industry uses a packet + switched architecture supported by high speed ethernet. However in + order to achieve the delay and packet loss requirements the network + bandwidth is overestimated, thus providing very low efficiency in + terms of resource usage. QoS is implemented at the Routers to separate video, management, monitoring and process control traffic for each stream. Since mobility is involved in this process, the connection between the backbone and the mobile devices (e.g. trucks, trains and excavators) is solved using a wireless link. These links are based - on 802.11 for open-pit mining and leaky feeder for underground - mining. + on 802.11 for open-pit mining and "leaky feeder" communications for + underground mining. (A "leaky feeder" communication system consists + of a coaxial cable run along tunnels which emits and receives radio + waves, functioning as an extended antenna. The cable is "leaky" in + that it has gaps or slots in its outer conductor to allow the radio + signal to leak into or out of the cable along its entire length.) Lately in pit mines the use of LPWAN technologies has been extended: Tailings, slopes and mine dumps are monitored by battery-powered dataloggers that make use of robust long range radio technologies. Reliability is usually ensured through retransmissions at L2. Gateways or concentrators act as bridges forwarding the data to the backbone ethernet network. Deterministic requirements are biased towards reliability rather than latency as events are slowly triggered or can be anticipated in advance. At the mineral processing stage, conveyor belts and refining processes are controlled by a SCADA system, which provides the in- factory delay-constrained networking requirements. - Voice communications are currently served by a redundant trunking - infrastructure, independent from current data networks. + At the time of this writing, voice communications are served by a + redundant trunking infrastructure, independent from data networks. 8.3. Mining Industry Future - Mining operations and management are currently converging towards a - combination of autonomous operation and teleoperation of transport - and extraction machines. This means that video, audio, monitoring - and process control traffic will increase dramatically. Ideally, all - activities on the mine will rely on network infrastructure. + Mining operations and management are converging towards a combination + of autonomous operation and teleoperation of transport and extraction + machines. This means that video, audio, monitoring and process + control traffic will increase dramatically. Ideally, all activities + on the mine will rely on network infrastructure. Wireless for open-pit mining is already a reality with LPWAN technologies and it is expected to evolve to more advanced LPWAN technologies such as those based on LTE to increase last hop reliability or novel LPWAN flavours with deterministic access. One area in which DetNet can improve this use case is in the wired networks that make up the "backbone network" of the system, which connect together many wireless access points (APs). The mobile machines (which are connected to the network via wireless) transition @@ -2911,103 +2913,110 @@ o Predictable delay to enable realtime monitoring o Potential to construct a unified DetNet network over a combination of wired and deterministic wireless links 9. Private Blockchain 9.1. Use Case Description - Blockchain was created with bitcoin, as a 'public' blockchain on the + Blockchain was created with bitcoin as a 'public' blockchain on the open Internet, however blockchain has also spread far beyond its original host into various industries such as smart manufacturing, logistics, security, legal rights and others. In these industries - blockchain runs in designated and carefully managed network in which - deterministic networking requirements could be addressed by Detnet. + blockchain runs in designated and carefully managed networks in which + deterministic networking requirements could be addressed by DetNet. Such implementations are referred to as 'private' blockchain. - The sole distinction between public and private blockchain is related - to who is allowed to participate in the network, execute the - consensus protocol and maintain the shared ledger. + The sole distinction between public and private blockchain is defined + by who is allowed to participate in the network, execute the + consensus protocol, and maintain the shared ledger. Today's networks treat the traffic from blockchain on a best-effort basis, but blockchain operation could be made much more efficient if - deterministic networking service were available to minimize latency + deterministic networking services were available to minimize latency and packet loss in the network. 9.1.1. Blockchain Operation A 'block' runs as a container of a batch of primary items such as transactions, property records etc. The blocks are chained in such a - way that the hash of the previous block works as the pointer header - of the new block, where confirmation of each block requires a + way that the hash of the previous block works as the pointer to the + header of the new block. Confirmation of each block requires a consensus mechanism. When an item arrives at a blockchain node, the - latter broadcasts this item to the rest of nodes which receive and - verify it and put it in the ongoing block. Block confirmation - process begins as the amount of items reaches the predefined block - capacity, and the node broadcasts its proved block to the rest of - nodes to be verified and chained. + latter broadcasts this item to the rest of the nodes which receive + and verify it and put it in the ongoing block. The block + confirmation process begins as the number of items reaches the + predefined block capacity, at which time the node broadcasts its + proved block to the rest of the nodes, to be verified and chained. + The result is that block N+1 of each chain transitively vouches for + blocks N and before of that chain. 9.1.2. Blockchain Network Architecture Blockchain node communication and coordination is achieved mainly - through frequent point to multi-point communication, however + through frequent point-to-multi-point communication, however persistent point-to-point connections are used to transport both the - items and the blocks to the other nodes. + items and the blocks to the other nodes. For example, consider the + following implementation. - When a node initiates, it first requests the other nodes' address + When a node is initiated, it first requests the other nodes' address from a specific entity such as DNS, then it creates persistent - connections each of with other nodes. If node A confirms an item, it - sends the item to the other nodes via the persistent connections. + connections each of with other nodes. If a node confirms an item, it + sends the item to the other nodes via these persistent connections. - As a new block in a node completes and gets proved among the nodes, - it starts propagating this block towards its neighbor nodes. Assume - node A receives a block, it sends invite message after verification - to its neighbor B, B checks if the designated block is available, it - responds get message to A if it is unavailable, and A send the - complete block to B. B repeats the process as A to start the next - round of block propagation. + As a new block in a node is completed and is proven by the + surrounding nodes, it propagates towards its neighbor nodes. When + node A receives a block, it verifies it, then sends an invite message + to its neighbor B. Neighbor B checks to see if the designated block + is available, and responds to A if it is unavailable, then A sends + the complete block to B. B repeats the process (as done by A above) + to start the next round of block propagation. The challenge of blockchain network operation is not overall data rates, since the volume from both block and item stays between hundreds of bytes to a couple of mega bytes per second, but is in transporting the blocks with minimum latency to maximize efficiency - of the blockchain consensus process. + of the blockchain consensus process. The efficiency of differing + implementations of the consensus process may be affected to a + differing degree by the latency (and variation of latency) of the + network. 9.1.3. Security Considerations - Security is crucial to blockchain applications, and todayt blockchain - addresses its security issues mainly at the application level, where - cryptography as well as hash-based consensus play a leading role - preventing both double-spending and malicious service attack. - However, there is concern that in the proposed use case of a private - blockchain network which is dependent on deterministic properties, - the network could be vulnerable to delays and other specific attacks - against determinism which could interrupt service. + Security is crucial to blockchain applications, and at the time of + this writing, blockchain systems address security issues mainly at + the application level, where cryptography as well as hash-based + consensus play a leading role in preventing both double-spending and + malicious service attacks. However, there is concern that in the + proposed use case of a private blockchain network which is dependent + on deterministic properties, the network could be vulnerable to + delays and other specific attacks against determinism which could + interrupt service. 9.2. Private Blockchain Today Today private blockchain runs in L2 or L3 VPN, in general without guaranteed determinism. The industry players are starting to realize that improving determinism in their blockchain networks could improve the performance of their service, but as of today these goals are not being met. 9.3. Private Blockchain Future Blockchain system performance can be greatly improved through deterministic networking service primarily because it would accelerate the consensus process. It would be valuable to be able to design a private blockchain network with the following properties: - o Transport of point to multi-point traffic in a coordinated network + o Transport of point-to-multi-point traffic in a coordinated network architecture rather than at the application layer (which typically uses point-to-point connections) o Guaranteed transport latency o Reduced packet loss (to the point where packet retransmission- incurred delay would be negligible.) 9.4. Private Blockchain Asks @@ -3071,26 +3080,27 @@ might be implemented using DetNet, and thus the slice can provide service guarantees and isolation to its users without any particular DetNet awareness on the part of the users' applications. Alternatively, a "non-DetNet-aware" slice may host an application that itself implements DetNet services and thus can enjoy similar service guarantees. 10.3. A Network Slicing Use Case Example - 5G Bearer Network Network Slicing is a core feature of 5G defined in 3GPP, which is - currently under development. A network slice in a mobile network is - a complete logical network including Radio Access Network (RAN) and - Core Network (CN). It provides telecommunication services and - network capabilities, which may vary from slice to slice. A 5G - bearer network is a typical use case of Network Slicing; for example - consider three 5G service scenarios: eMMB, URLLC, and mMTC. + under development at the time of this writing [TR38501]. A network + slice in a mobile network is a complete logical network including + Radio Access Network (RAN) and Core Network (CN). It provides + telecommunication services and network capabilities, which may vary + from slice to slice. A 5G bearer network is a typical use case of + Network Slicing; for example consider three 5G service scenarios: + eMMB, URLLC, and mMTC. o eMBB (Enhanced Mobile Broadband) focuses on services characterized by high data rates, such as high definition videos, virtual reality, augmented reality, and fixed mobile convergence. o URLLC (Ultra-Reliable and Low Latency Communications) focuses on latency-sensitive services, such as self-driving vehicles, remote surgery, or drone control. o mMTC (massive Machine Type Communications) focuses on services @@ -3192,40 +3202,41 @@ of the use cases described (and their associated industries) are explicitly based on IPv4 (as opposed to IPv6) and it is not considered practical to expect them to migrate to IPv6 in order to use DetNet. Thus the expectation is that even if not every feature of DetNet is available in an IPv4 context, at least some of the significant benefits (such as guaranteed end-to-end delivery and low latency) are expected to be available. 11.1.6. Guaranteed End-to-End Delivery - Packets sent over DetNet are guaranteed not to be dropped by the + Packets in a DetNet flow are guaranteed not to be dropped by the network due to congestion. However, the network may drop packets for - intended reasons, e.g. per security measures. Also note that this - guarantee applies to the actions of DetNet protocol software, and - does not provide any guarantee against lower level errors such as - media errors or checksum errors. + intended reasons, e.g. per security measures. Similarly best-effort + traffic on a DetNet is subject to being dropped (as on a non-DetNet + IP network). Also note that this guarantee applies to the actions of + DetNet protocol software, and does not provide any guarantee against + lower level errors such as media errors or checksum errors. 11.1.7. Replacement for Multiple Proprietary Deterministic Networks There are many proprietary non-interoperable deterministic Ethernet- - based networks currently available; DetNet is intended to provide an - open-standards-based alternative to such networks. + based networks available; DetNet is intended to provide an open- + standards-based alternative to such networks. 11.1.8. Mix of Deterministic and Best-Effort Traffic DetNet is intended to support coexistance of time-sensitive operational (OT) traffic and information (IT) traffic on the same ("unified") network. -11.1.9. Unused Reserved BW to be Available to Best Effort Traffic +11.1.9. Unused Reserved BW to be Available to Best-Effort Traffic If bandwidth reservations are made for a stream but the associated bandwidth is not used at any point in time, that bandwidth is made available on the network for best-effort traffic. If the owner of the reserved stream then starts transmitting again, the bandwidth is no longer available for best-effort traffic, on a moment-to-moment basis. Note that such "temporarily available" bandwidth is not available for time-sensitive traffic, which must have its own reservation. @@ -3322,194 +3333,40 @@ change in attack surface presented by packet replication and elimination. 11.6. Deterministic Flows Reserved bandwidth data flows must be isolated from each other and from best-effort traffic, so that even if the network is saturated with best-effort (and/or reserved bandwidth) traffic, the configured flows are not adversely affected. -12. Use Cases Explicitly Out of Scope for DetNet - - This section contains use case text that has been determined to be - outside of the scope of the present DetNet work. - -12.1. DetNet Scope Limitations - - The scope of DetNet is deliberately limited to specific use cases - that are consistent with the WG charter, subject to the - interpretation of the WG. At the time the DetNet Use Cases were - solicited and provided by the authors the scope of DetNet was not - clearly defined, and as that clarity has emerged, certain of the use - cases have been determined to be outside the scope of the present - DetNet work. Such text has been moved into this section to clarify - that these use cases will not be supported by the DetNet work. - - The text in this section was moved here based on the following - "exclusion" principles. Or, as an alternative to moving all such - text to this section, some draft text has been modified in situ to - reflect these same principles. - - The following principles have been established to clarify the scope - of the present DetNet work. - - o The scope of network addressed by DetNet is limited to networks - that can be centrally controlled, i.e. an "enterprise" aka - "corporate" network. This explicitly excludes "the open - Internet". - - o Maintaining synchronized time across a DetNet network is crucial - to its operation, however DetNet assumes that time is to be - maintained using other means, for example (but not limited to) - Precision Time Protocol ([IEEE1588]). A use case may state the - accuracy and reliability that it expects from the DetNet network - as part of a whole system, however it is understood that such - timing properties are not guaranteed by DetNet itself. It is - currently an open question as to whether DetNet protocols will - include a way for an application to communicate such timing - expectations to the network, and if so whether they would be - expected to materially affect the performance they would receive - from the network as a result. - -12.2. Internet-based Applications - - There are many applications that communicate over the open Internet - that could benefit from guaranteed delivery and bounded latency. - However as noted above, all such applications when run over the open - Internet are out of scope for DetNet. These same applications may be - in-scope when run in constrained environments, i.e. within a - centrally controlled DetNet network. The following are some examples - of such applications. - -12.2.1. Use Case Description - -12.2.1.1. Media Content Delivery - - Media content delivery continues to be an important use of the - Internet, yet users often experience poor quality audio and video due - to the delay and jitter inherent in today's Internet. - -12.2.1.2. Online Gaming - - Online gaming is a significant part of the gaming market, however - latency can degrade the end user experience. For example "First - Person Shooter" games are highly delay-sensitive. - -12.2.1.3. Virtual Reality - - Virtual reality has many commercial applications including real - estate presentations, remote medical procedures, and so on. Low - latency is critical to interacting with the virtual world because - perceptual delays can cause motion sickness. - -12.2.2. Internet-Based Applications Today - - Internet service today is by definition "best effort", with no - guarantees on delivery or bandwidth. - -12.2.3. Internet-Based Applications Future - - An Internet from which one can play a video without glitches and play - games without lag. - - For online gaming, the maximum round-trip delay can be 100ms and - stricter for FPS gaming which can be 10-50ms. Transport delay is the - dominate part with a 5-20ms budget. - - For VR, 1-10ms maximum delay is needed and total network budget is - 1-5ms if doing remote VR. - - Flow identification can be used for gaming and VR, i.e. it can - recognize a critical flow and provide appropriate latency bounds. - -12.2.4. Internet-Based Applications Asks - - o Unified control and management protocols to handle time-critical - data flow - - o Application-aware flow filtering mechanism to recognize the timing - critical flow without doing 5-tuple matching - - o Unified control plane to provide low latency service on Layer-3 - without changing the data plane - - o OAM system and protocols which can help to provide E2E-delay - sensitive service provisioning - -12.3. Pro Audio and Video - Digital Rights Management (DRM) - - This section was moved here because this is considered a Link layer - topic, not direct responsibility of DetNet. - - 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. - -12.4. Pro Audio and Video - Link Aggregation - - Note: The term "Link Aggregation" is used here as defined by the text - in the following paragraph, i.e. not following a more common Network - Industry definition. Current WG consensus is that this item won't be - directly supported by the DetNet architecture, for example because it - implies guarantee of in-order delivery of packets which conflicts - with the core goal of achieving the lowest possible latency. - - 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. - -12.5. Pro Audio and Video - Deterministic Time to Establish Streaming - - The DetNet Working Group has decided that guidelines for establishing - a deterministic time to establish stream startup are not within scope - of DetNet. If bounded timing of establishing or re-establish streams - is required in a given use case, it is up to the application/system - to achieve this. - -13. Security Considerations +12. Security Considerations This document covers a number of representative applications and network scenarios that are expected to make use of DetNet technologies. Each of the potential DetNet uses cases will have security considerations from both the use-specific and DetNet technology perspectives. While some use-specific security considerations are discussed above, a more comprehensive discussion of such considerations is captured in DetNet Security Considerations [I-D.ietf-detnet-security]. Readers are encouraged to review this document to gain a more complete understanding of DetNet related security considerations. -14. Contributors +13. Contributors RFC7322 limits the number of authors listed on the front page of a draft to a maximum of 5, far fewer than the 20 individuals below who made important contributions to this draft. The editor wishes to thank and acknowledge each of the following authors for contributing - text to this draft. See also Section 15. + text to this draft. See also Section 14. Craig Gunther (Harman International) 10653 South River Front Parkway, South Jordan,UT 84095 phone +1 801 568-7675, email craig.gunther@harman.com Pascal Thubert (Cisco Systems, Inc) Building D, 45 Allee des Ormes - BP1200, MOUGINS Sophia Antipolis 06254 FRANCE phone +33 497 23 26 34, email pthubert@cisco.com @@ -3570,110 +3427,110 @@ Xuesong Geng (Huawei Technologies) email gengxuesong@huawei.com Diego Dujovne (Universidad Diego Portales) email diego.dujovne@mail.udp.cl Maik Seewald (Cisco Systems) email maseewal@cisco.com -15. Acknowledgments +14. Acknowledgments -15.1. Pro Audio +14.1. Pro Audio This section was derived from draft-gunther-detnet-proaudio-req-01. The editors would like to acknowledge the help of the following individuals and the companies they represent: Jeff Koftinoff, Meyer Sound - Jouni Korhonen, Associate Technical Director, Broadcom Pascal Thubert, CTAO, Cisco + Kieran Tyrrell, Sienda New Media Technologies GmbH -15.2. Utility Telecom +14.2. Utility Telecom This section was derived from draft-wetterwald-detnet-utilities-reqs- 02. Faramarz Maghsoodlou, Ph. D. IoT Connected Industries and Energy Practice Cisco Pascal Thubert, CTAO Cisco The wind power generation use case has been extracted from the study of Wind Farms conducted within the 5GPPP Virtuwind Project. The project is funded by the European Union's Horizon 2020 research and innovation programme under grant agreement No 671648 (VirtuWind). -15.3. Building Automation Systems +14.3. Building Automation Systems This section was derived from draft-bas-usecase-detnet-00. -15.4. Wireless for Industrial +14.4. Wireless for Industrial Applications This section was derived from draft-thubert-6tisch-4detnet-01. This specification derives from the 6TiSCH architecture, which is the result of multiple interactions, in particular during the 6TiSCH (bi)Weekly Interim call, relayed through the 6TiSCH mailing list at the IETF. The authors wish to thank: Kris Pister, Thomas Watteyne, Xavier Vilajosana, Qin Wang, Tom Phinney, Robert Assimiti, Michael Richardson, Zhuo Chen, Malisa Vucinic, Alfredo Grieco, Martin Turon, Dominique Barthel, Elvis Vogli, Guillaume Gaillard, Herman Storey, Maria Rita Palattella, Nicola Accettura, Patrick Wetterwald, Pouria Zand, Raghuram Sudhaakar, and Shitanshu Shah for their participation and various contributions. -15.5. Cellular Radio +14.5. Cellular Radio This section was derived from draft-korhonen-detnet-telreq-00. -15.6. Industrial M2M +14.6. Industrial Machine to Machine (M2M) The authors would like to thank Feng Chen and Marcel Kiessling for their comments and suggestions. -15.7. Internet Applications and CoMP +14.7. Internet Applications and CoMP This section was derived from draft-zha-detnet-use-case-00 by Yiyong Zha. 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. -15.8. Network Slicing +14.8. Network Slicing This section was written by Xuesong Geng, who would like to acknowledge Norm Finn and Mach Chen for their useful comments. -15.9. Mining +14.9. Mining This section was written by Diego Dujovne in conjunction with Xavier Vilasojana. -15.10. Private Blockchain +14.10. Private Blockchain This section was written by Daniel Huang. -16. IANA Considerations +15. IANA Considerations This memo includes no requests from IANA. -17. Informative References +16. Informative References [Ahm14] Ahmed, M. and R. Kim, "Communication network architectures for smart-wind power farms.", Energies, p. 3900-3921. , June 2014. [bacnetip] ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP", January 1999. [CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND @@ -3713,43 +3570,43 @@ . [I-D.ietf-6tisch-6top-interface] Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer (6top) Interface", draft-ietf-6tisch-6top-interface-04 (work in progress), July 2015. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work - in progress), April 2018. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work + in progress), December 2018. [I-D.ietf-6tisch-coap] Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Interaction using CoAP", draft-ietf-6tisch-coap-03 (work in progress), March 2015. [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- - detnet-architecture-08 (work in progress), September 2018. + detnet-architecture-09 (work in progress), October 2018. [I-D.ietf-detnet-problem-statement] Finn, N. and P. Thubert, "Deterministic Networking Problem - Statement", draft-ietf-detnet-problem-statement-07 (work - in progress), October 2018. + Statement", draft-ietf-detnet-problem-statement-08 (work + in progress), December 2018. [I-D.ietf-detnet-security] Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, J., Austad, H., Stanton, K., and N. Finn, "Deterministic Networking (DetNet) Security Considerations", draft-ietf- - detnet-security-02 (work in progress), April 2018. + detnet-security-03 (work in progress), October 2018. [I-D.ietf-tictoc-1588overmpls] Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Montini, "Transporting Timing messages over MPLS Networks", draft-ietf-tictoc-1588overmpls-07 (work in progress), October 2015. [I-D.kh-spring-ip-ran-use-case] Khasnabish, B., hu, f., and L. Contreras, "Segment Routing in IP RAN use case", draft-kh-spring-ip-ran-use-case-02 @@ -3949,24 +3806,29 @@ [SRP_LATENCY] Gunther, C., "Specifying SRP Latency", 2014, . [SyncE] ITU-T, "G.8261 : Timing and synchronization aspects in packet networks", Recommendation G.8261, August 2013, . - [TR38801] IEEE Standards Association, "3GPP TR 38.801, Technical - Specification Group Radio Access Network; Study on new - radio access technology: Radio access architecture and - interfaces (Release 14)", 2017, + [TR38501] 3GPP, "3GPP TS 38.501, Technical Specification System + Architecture for the 5G System (Release 15)", 2017, + . + + [TR38801] 3GPP, "3GPP TR 38.801, Technical Specification Group Radio + Access Network; Study on new radio access technology: + Radio access architecture and interfaces (Release 14)", + 2017, . [TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. [TS25104] 3GPP, "Base Station (BS) radio transmission and reception (FDD)", 3GPP TS 25.104 3.14.0, March 2007. @@ -3989,20 +3851,171 @@ [TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive Networks Task Group", 2013, . [WirelessHART] www.hartcomm.org, "Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART - IEC 62591", 2010. +Appendix A. Use Cases Explicitly Out of Scope for DetNet + + This section contains use case text that has been determined to be + outside of the scope of the present DetNet work. + +A.1. DetNet Scope Limitations + + The scope of DetNet is deliberately limited to specific use cases + that are consistent with the WG charter, subject to the + interpretation of the WG. At the time the DetNet Use Cases were + solicited and provided by the authors the scope of DetNet was not + clearly defined, and as that clarity has emerged, certain of the use + cases have been determined to be outside the scope of the present + DetNet work. Such text has been moved into this section to clarify + that these use cases will not be supported by the DetNet work. + + The text in this section was moved here based on the following + "exclusion" principles. Or, as an alternative to moving all such + text to this section, some draft text has been modified in situ to + reflect these same principles. + + The following principles have been established to clarify the scope + of the present DetNet work. + + o The scope of network addressed by DetNet is limited to networks + that can be centrally controlled, i.e. an "enterprise" aka + "corporate" network. This explicitly excludes "the open + Internet". + + o Maintaining synchronized time across a DetNet network is crucial + to its operation, however DetNet assumes that time is to be + maintained using other means, for example (but not limited to) + Precision Time Protocol ([IEEE1588]). A use case may state the + accuracy and reliability that it expects from the DetNet network + as part of a whole system, however it is understood that such + timing properties are not guaranteed by DetNet itself. At the + time of this writing it is an open question as to whether DetNet + protocols will include a way for an application to communicate + such timing expectations to the network, and if so whether they + would be expected to materially affect the performance they would + receive from the network as a result. + +A.2. Internet-based Applications + + There are many applications that communicate over the open Internet + that could benefit from guaranteed delivery and bounded latency. + However as noted above, all such applications when run over the open + Internet are out of scope for DetNet. These same applications may be + in-scope when run in constrained environments, i.e. within a + centrally controlled DetNet network. The following are some examples + of such applications. + +A.2.1. Use Case Description + +A.2.1.1. Media Content Delivery + + Media content delivery continues to be an important use of the + Internet, yet users often experience poor quality audio and video due + to the delay and jitter inherent in today's Internet. + +A.2.1.2. Online Gaming + + Online gaming is a significant part of the gaming market, however + latency can degrade the end user experience. For example "First + Person Shooter" games are highly delay-sensitive. + +A.2.1.3. Virtual Reality + + Virtual reality has many commercial applications including real + estate presentations, remote medical procedures, and so on. Low + latency is critical to interacting with the virtual world because + perceptual delays can cause motion sickness. + +A.2.2. Internet-Based Applications Today + + Internet service today is by definition "best-effort", with no + guarantees on delivery or bandwidth. + +A.2.3. Internet-Based Applications Future + + An Internet from which one can play a video without glitches and play + games without lag. + + For online gaming, the maximum round-trip delay can be 100ms and + stricter for FPS gaming which can be 10-50ms. Transport delay is the + dominate part with a 5-20ms budget. + + For VR, 1-10ms maximum delay is needed and total network budget is + 1-5ms if doing remote VR. + + Flow identification can be used for gaming and VR, i.e. it can + recognize a critical flow and provide appropriate latency bounds. + +A.2.4. Internet-Based Applications Asks + + o Unified control and management protocols to handle time-critical + data flow + + o Application-aware flow filtering mechanism to recognize the timing + critical flow without doing 5-tuple matching + + o Unified control plane to provide low latency service on Layer-3 + without changing the data plane + + o OAM system and protocols which can help to provide E2E-delay + sensitive service provisioning + +A.3. Pro Audio and Video - Digital Rights Management (DRM) + + This section was moved here because this is considered a Link layer + topic, not direct responsibility of DetNet. + + 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. + +A.4. Pro Audio and Video - Link Aggregation + + Note: The term "Link Aggregation" is used here as defined by the text + in the following paragraph, i.e. not following a more common Network + Industry definition. + + 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. + +A.5. Pro Audio and Video - Deterministic Time to Establish Streaming + + The DetNet Working Group has decided that guidelines for establishing + a deterministic time to establish stream startup are not within scope + of DetNet. If bounded timing of establishing or re-establish streams + is required in a given use case, it is up to the application/system + to achieve this. + Author's Address Ethan Grossman (editor) Dolby Laboratories, Inc. 1275 Market Street San Francisco, CA 94103 USA Phone: +1 415 645 4726 Email: ethan.grossman@dolby.com