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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/