< draft-ietf-detnet-use-cases-12.txt   draft-ietf-detnet-use-cases-13.txt >
Internet Engineering Task Force E. Grossman, Ed. Internet Engineering Task Force E. Grossman, Ed.
Internet-Draft DOLBY Internet-Draft DOLBY
Intended status: Informational C. Gunther Intended status: Informational C. Gunther
Expires: October 5, 2017 HARMAN Expires: March 22, 2018 HARMAN
P. Thubert P. Thubert
P. Wetterwald P. Wetterwald
CISCO CISCO
J. Raymond J. Raymond
HYDRO-QUEBEC HYDRO-QUEBEC
J. Korhonen J. Korhonen
BROADCOM BROADCOM
Y. Kaneko Y. Kaneko
Toshiba Toshiba
S. Das S. Das
skipping to change at page 1, line 34 skipping to change at page 1, line 34
J. Schmitt J. Schmitt
Siemens Siemens
X. Vilajosana X. Vilajosana
Worldsensing Worldsensing
T. Mahmoodi T. Mahmoodi
King's College London King's College London
S. Spirou S. Spirou
Intracom Telecom Intracom Telecom
P. Vizarreta P. Vizarreta
Technical University of Munich, TUM Technical University of Munich, TUM
April 3, 2017 D. Huang
ZTE Corporation, Inc.
X. Geng
HUAWEI
D. Dujovne
UDP
M. Seewald
CISCO
September 18, 2017
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-12 draft-ietf-detnet-use-cases-13
Abstract Abstract
This draft documents requirements in several diverse industries to This draft documents requirements in several diverse industries to
establish multi-hop paths for characterized flows with deterministic establish multi-hop paths for characterized flows with deterministic
properties. In this context deterministic implies that streams can properties. In this context deterministic implies that streams can
be established which provide guaranteed bandwidth and latency which be established which provide guaranteed bandwidth and latency which
can be established from either a Layer 2 or Layer 3 (IP) interface, can be established from either a Layer 2 or Layer 3 (IP) interface,
and which can co-exist on an IP network with best-effort traffic. and which can co-exist on an IP network with best-effort traffic.
Additional requirements include optional redundant paths, very high Additional requirements include optional redundant paths, very high
reliability paths, time synchronization, and clock distribution. reliability paths, time synchronization, and clock distribution.
Industries considered include professional audio, electrical
Industries considered include wireless for industrial applications, utilities, building automation systems, wireless for industrial,
professional audio, electrical utilities, building automation cellular radio, industrial machine-to-machine, mining, private
systems, radio/mobile access networks, automotive, and gaming. blockchain, and network slicing.
For each case, this document will identify the application, identify For each case, this document will identify the application, identify
representative solutions used today, and what new uses an IETF DetNet representative solutions used today, and the improvements IETF DetNet
solution may enable. solutions may enable.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at 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 October 5, 2017. This Internet-Draft will expire on March 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 6 2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 7
2.1. Use Case Description . . . . . . . . . . . . . . . . . . 6 2.1. Use Case Description . . . . . . . . . . . . . . . . . . 7
2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 7 2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 8
2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 7 2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 8
2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 8 2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 9
2.1.4. Deterministic Time to Establish Streaming . . . . . . 8 2.1.4. Deterministic Time to Establish Streaming . . . . . . 9
2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8 2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 9
2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8 2.1.5.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 . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9 2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10
2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9 2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 10
2.3.3. Integration of Reserved Streams into IT Networks . . 9 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 . . 11
2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10 2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 11
2.3.5.1. Packet Forwarding Rules, VLANs and Subnets . . . 10 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) . . . . . . 12
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 . . 11 2.3.7. Reduced Device Cost Due To Reduced Buffer Memory . . 12
2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12 2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 13
3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12 3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 13
3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 13
3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 12 3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 13
3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 12 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 . . . 19
3.1.1.3. Wide Area Monitoring and Control Systems . . . . 19 3.1.1.3. Wide Area Monitoring and Control Systems . . . . 20
3.1.1.4. IEC 61850 WAN engineering guidelines requirement 3.1.1.4. IEC 61850 WAN engineering guidelines requirement
classification . . . . . . . . . . . . . . . . . 20 classification . . . . . . . . . . . . . . . . . 21
3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21 3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 22
3.1.2.1. Control of the Generated Power . . . . . . . . . 21 3.1.2.1. Control of the Generated Power . . . . . . . . . 22
3.1.2.2. Control of the Generation Infrastructure . . . . 22 3.1.2.2. Control of the Generation Infrastructure . . . . 23
3.1.3. Distribution use case . . . . . . . . . . . . . . . . 27 3.1.3. Distribution use case . . . . . . . . . . . . . . . . 28
3.1.3.1. Fault Location Isolation and Service Restoration 3.1.3.1. Fault Location Isolation and Service Restoration
(FLISR) . . . . . . . . . . . . . . . . . . . . . 27 (FLISR) . . . . . . . . . . . . . . . . . . . . . 28
3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 28 3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 29
3.2.1. Security Current Practices and Limitations . . . . . 28 3.2.1. Security Current Practices and Limitations . . . . . 29
3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 30 3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 31
3.3.1. Migration to Packet-Switched Network . . . . . . . . 31 3.3.1. Migration to Packet-Switched Network . . . . . . . . 32
3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 31 3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 32
3.3.2.1. General Telecommunications Requirements . . . . . 31 3.3.2.1. General Telecommunications Requirements . . . . . 32
3.3.2.2. Specific Network topologies of Smart Grid 3.3.2.2. Specific Network topologies of Smart Grid
Applications . . . . . . . . . . . . . . . . . . 32 Applications . . . . . . . . . . . . . . . . . . 33
3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 33 3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 34
3.3.3. Security Trends in Utility Networks . . . . . . . . . 34 3.3.3. Security Trends in Utility Networks . . . . . . . . . 35
3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 36 3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 37
4. Building Automation Systems . . . . . . . . . . . . . . . . . 36 4. Building Automation Systems . . . . . . . . . . . . . . . . . 37
4.1. Use Case Description . . . . . . . . . . . . . . . . . . 36 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 37
4.2. Building Automation Systems Today . . . . . . . . . . . . 37 4.2. Building Automation Systems Today . . . . . . . . . . . . 38
4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 37 4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 38
4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 38 4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 39
4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 40 4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 41
4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 40 4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 41
4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 40 4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 41
4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 41 4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 42
4.2.4. Security Considerations . . . . . . . . . . . . . . . 41 4.2.4. Security Considerations . . . . . . . . . . . . . . . 42
4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 41 4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 42
4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 42 4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 43
5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 42 5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 43
5.1. Use Case Description . . . . . . . . . . . . . . . . . . 42 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 43
5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 43 5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 44
5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 43 5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 44
5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 44 5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 45
5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 44 5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 45
5.3.1. Unified Wireless Network and Management . . . . . . . 44 5.3.1. Unified Wireless Network and Management . . . . . . . 45
5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 46 5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 47
5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 47 5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 48
5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 47 5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 48
5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 48 5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 49
5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 49 5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 50
5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 49 5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 50
6. Cellular Radio . . . . . . . . . . . . . . . . . . . . . . . 49 6. Cellular Radio . . . . . . . . . . . . . . . . . . . . . . . 50
6.1. Use Case Description . . . . . . . . . . . . . . . . . . 49 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 50
6.1.1. Network Architecture . . . . . . . . . . . . . . . . 49 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 50
6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 50 6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 51
6.1.3. Time Synchronization Constraints . . . . . . . . . . 51 6.1.3. Time Synchronization Constraints . . . . . . . . . . 53
6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 53 6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 55
6.1.5. Security Considerations . . . . . . . . . . . . . . . 53 6.1.5. Security Considerations . . . . . . . . . . . . . . . 55
6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 54 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 56
6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 54 6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 56
6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 54 6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 56
6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 55 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 57
6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 57 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 59
7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 57 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 59
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 57 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 59
7.2. Industrial M2M Communication Today . . . . . . . . . . . 58 7.2. Industrial M2M Communication Today . . . . . . . . . . . 60
7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 59 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 61
7.2.2. Stream Creation and Destruction . . . . . . . . . . . 60 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 62
7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 60 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 62
7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 60 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 62
8. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 60
8.1. Unified, standards-based network . . . . . . . . . . . . 61
8.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 61
8.1.2. Centrally Administered . . . . . . . . . . . . . . . 61
8.1.3. Standardized Data Flow Information Models . . . . . . 61
8.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . . 61
8.1.5. Guaranteed End-to-End Delivery . . . . . . . . . . . 61
8.1.6. Replacement for Multiple Proprietary Deterministic
Networks . . . . . . . . . . . . . . . . . . . . . . 61
8.1.7. Mix of Deterministic and Best-Effort Traffic . . . . 62
8.1.8. Unused Reserved BW to be Available to Best Effort
Traffic . . . . . . . . . . . . . . . . . . . . . . . 62
8.1.9. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 62 8. Mining Industry . . . . . . . . . . . . . . . . . . . . . . . 63
8.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . . 62 8.1. Use Case Description . . . . . . . . . . . . . . . . . . 63
8.3. Scalable Timing Parameters and Accuracy . . . . . . . . . 62 8.2. Mining Industry Today . . . . . . . . . . . . . . . . . . 63
8.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . . 62 8.3. Mining Industry Future . . . . . . . . . . . . . . . . . 64
8.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . . 63 8.4. Mining Industry Asks . . . . . . . . . . . . . . . . . . 65
8.3.3. Symmetrical Path Delays . . . . . . . . . . . . . . . 63 9. Private Blockchain . . . . . . . . . . . . . . . . . . . . . 65
8.4. High Reliability and Availability . . . . . . . . . . . . 63 9.1. Use Case Description . . . . . . . . . . . . . . . . . . 65
8.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 63 9.1.1. Blockchain Operation . . . . . . . . . . . . . . . . 65
8.6. Deterministic Flows . . . . . . . . . . . . . . . . . . . 64 9.1.2. Blockchain Network Architecture . . . . . . . . . . . 66
9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 64 9.1.3. Security Considerations . . . . . . . . . . . . . . . 66
9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 64 9.2. Private Blockchain Today . . . . . . . . . . . . . . . . 66
9.2. Internet-based Applications . . . . . . . . . . . . . . . 65 9.3. Private Blockchain Future . . . . . . . . . . . . . . . . 67
9.2.1. Use Case Description . . . . . . . . . . . . . . . . 65 9.4. Private Blockchain Asks . . . . . . . . . . . . . . . . . 67
9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 65 10. Network Slicing . . . . . . . . . . . . . . . . . . . . . . . 67
9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 65 10.1. Use Case Description . . . . . . . . . . . . . . . . . . 67
9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 65 10.2. Network Slicing Use Cases . . . . . . . . . . . . . . . 68
9.2.2. Internet-Based Applications Today . . . . . . . . . . 65 10.2.1. Enhanced Mobile Broadband (eMBB) . . . . . . . . . . 68
9.2.3. Internet-Based Applications Future . . . . . . . . . 65 10.2.2. Ultra-Reliable and Low Latency Communications
9.2.4. Internet-Based Applications Asks . . . . . . . . . . 66 (URLLC) . . . . . . . . . . . . . . . . . . . . . . 68
9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 66 10.2.3. massive Machine Type Communications (mMTC) . . . . . 68
9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 66 10.3. Using DetNet in Network Slicing . . . . . . . . . . . . 68
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 10.4. Network Slicing Today and Future . . . . . . . . . . . . 69
10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 67 10.5. Network Slicing Asks . . . . . . . . . . . . . . . . . . 69
10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 67 11. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 69
10.3. Building Automation Systems . . . . . . . . . . . . . . 67 11.1. Unified, standards-based network . . . . . . . . . . . . 69
10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 67 11.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 69
10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 68 11.1.2. Centrally Administered . . . . . . . . . . . . . . . 69
10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 68 11.1.3. Standardized Data Flow Information Models . . . . . 70
10.7. Internet Applications and CoMP . . . . . . . . . . . . . 68 11.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . 70
10.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 68 11.1.5. Guaranteed End-to-End Delivery . . . . . . . . . . . 70
11. Informative References . . . . . . . . . . . . . . . . . . . 68 11.1.6. Replacement for Multiple Proprietary Deterministic
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 Networks . . . . . . . . . . . . . . . . . . . . . . 70
11.1.7. Mix of Deterministic and Best-Effort Traffic . . . . 70
11.1.8. Unused Reserved BW to be Available to Best Effort
Traffic . . . . . . . . . . . . . . . . . . . . . . 70
11.1.9. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 71
11.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . 71
11.3. Scalable Timing Parameters and Accuracy . . . . . . . . 71
11.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . 71
11.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . 71
11.3.3. Symmetrical Path Delays . . . . . . . . . . . . . . 72
11.4. High Reliability and Availability . . . . . . . . . . . 72
11.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 72
11.6. Deterministic Flows . . . . . . . . . . . . . . . . . . 72
12. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 72
12.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 73
12.2. Internet-based Applications . . . . . . . . . . . . . . 73
12.2.1. Use Case Description . . . . . . . . . . . . . . . . 73
12.2.1.1. Media Content Delivery . . . . . . . . . . . . . 74
12.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . 74
12.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . 74
12.2.2. Internet-Based Applications Today . . . . . . . . . 74
12.2.3. Internet-Based Applications Future . . . . . . . . . 74
12.2.4. Internet-Based Applications Asks . . . . . . . . . . 74
12.3. Pro Audio and Video - Digital Rights Management (DRM) . 75
12.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 75
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
13.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 76
13.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 76
13.3. Building Automation Systems . . . . . . . . . . . . . . 76
13.4. Wireless for Industrial . . . . . . . . . . . . . . . . 76
13.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 77
13.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 77
13.7. Internet Applications and CoMP . . . . . . . . . . . . . 77
13.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 77
13.9. Network Slicing . . . . . . . . . . . . . . . . . . . . 77
13.10. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 77
13.11. Private Blockchain . . . . . . . . . . . . . . . . . . . 77
14. Informative References . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
This draft presents use cases from diverse industries which have in This draft presents use cases from diverse industries which have in
common a need for deterministic streams, but which also differ common a need for deterministic streams, but which also differ
notably in their network topologies and specific desired behavior. notably in their network topologies and specific desired behavior.
Together, they provide broad industry context for DetNet and a Together, they provide broad industry context for DetNet and a
yardstick against which proposed DetNet designs can be measured (to yardstick against which proposed DetNet designs can be measured (to
what extent does a proposed design satisfy these various use cases?) what extent does a proposed design satisfy these various use cases?)
skipping to change at page 18, line 29 skipping to change at page 19, line 29
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 1% | | Packet loss | 1% |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
Table 5: Inter-Substation Protection requirements Table 5: Inter-Substation Protection requirements
3.1.1.2. Intra-Substation Process Bus Communications 3.1.1.2. Intra-Substation Process Bus Communications
This use case describes the data flow from the CT/VT to the IEDs in This use case describes the data flow from the CT/VT to the IEDs in
the substation via the MU. The CT/VT in the substation send the the substation via the MU. The CT/VT in the substation send the
sampled value (analog voltage or current) to the MU over hard wire. analog voltage or current values to the MU over hard wire. The MU
The MU sends the time-synchronized 61850-9-2 sampled values to the converts the analog values into digital format (typically time-
IEDs in the substation in GOOSE message format. The GPS Master Clock synchronized Sampled Values as specified by IEC 61850-9-2) and sends
can send 1PPS or IRIG-B format to the MU through a serial port or them to the IEDs in the substation. The GPS Master Clock can send
IEEE 1588 protocol via a network. Process bus communication using 1PPS or IRIG-B format to the MU through a serial port or IEEE 1588
61850 simplifies connectivity within the substation and removes the protocol via a network. Process bus communication using 61850
simplifies connectivity within the substation and removes the
requirement for multiple serial connections and removes the slow requirement for multiple serial connections and removes the slow
serial bus architectures that are typically used. This also ensures serial bus architectures that are typically used. This also ensures
increased flexibility and increased speed with the use of multicast increased flexibility and increased speed with the use of multicast
messaging between multiple devices. messaging between multiple devices.
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
| Intra-Substation protection | Attribute | | Intra-Substation protection | Attribute |
| Requirement | | | Requirement | |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
| One way maximum delay | 5 ms | | One way maximum delay | 5 ms |
skipping to change at page 30, line 45 skipping to change at page 31, 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. power automation standards. The AHG8 has recently finalised the work
on the migration strategy and the following Technical Report has been
issued: IEC TR 62357-200:2015: Guidelines for migration from Internet
Protocol version 4 (IPv4) to Internet Protocol version 6 (IPv6).
We expect cloud-based SCADA systems to control and monitor the We expect cloud-based SCADA systems to control and monitor the
critical and non-critical subsystems of generation systems, for critical and non-critical subsystems of generation systems, for
example wind farms. example wind 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
future based on smart grid applications requiring advanced future based on smart grid applications requiring advanced
telecommunications systems. Many of these applications utilize telecommunications systems. Many of these applications utilize
skipping to change at page 34, line 14 skipping to change at page 35, line 14
PTP was designed assuming a multicast communication model, however PTP was designed assuming a multicast communication model, however
PTP also supports a unicast communication model as long as the PTP also supports a unicast communication model as long as the
behavior of the protocol is preserved. behavior of the protocol is preserved.
Like all message-based time transfer protocols, PTP time accuracy Like all message-based time transfer protocols, PTP time accuracy
is degraded by delay asymmetry in the paths taken by event is degraded by delay asymmetry in the paths taken by event
messages. Asymmetry is not detectable by PTP, however, if such messages. Asymmetry is not detectable by PTP, however, if such
delays are known a priori, PTP can correct for asymmetry. delays are known a priori, PTP can correct for asymmetry.
IEC 61850 will recommend the use of the IEEE PTP 1588 Utility Profile IEC 61850 defines the use of IEC/IEEE 61850-9-3:2016. The title is:
(as defined in [IEC62439-3:2012] Annex B) which offers the support of Precision time protocol profile for power utility automation. It is
redundant attachment of clocks to Parallel Redundancy Protcol (PRP) based on Annex B/IEC 62439 which offers the support of redundant
and High-availability Seamless Redundancy (HSR) networks. attachment of clocks to Parallel Redundancy Protocol (PRP) and High-
availability Seamless Redundancy (HSR) networks.
3.3.3. Security Trends in Utility Networks 3.3.3. Security Trends in Utility Networks
Although advanced telecommunications networks can assist in Although advanced telecommunications networks can assist in
transforming the energy industry by playing a critical role in transforming the energy industry by playing a critical role in
maintaining high levels of reliability, performance, and maintaining high levels of reliability, performance, and
manageability, they also introduce the need for an integrated manageability, they also introduce the need for an integrated
security infrastructure. Many of the technologies being deployed to security infrastructure. Many of the technologies being deployed to
support smart grid projects such as smart meters and sensors can support smart grid projects such as smart meters and sensors can
increase the vulnerability of the grid to attack. Top security increase the vulnerability of the grid to attack. Top security
skipping to change at page 49, line 41 skipping to change at page 50, line 41
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 typical 3GPP-defined cellular network
architecture, which includes "Fronthaul" and "Midhaul" network architecture, which includes "Fronthaul", "Midhaul" and "Backhaul"
segments. The "Fronthaul" is the network connecting base stations network segments. The "Fronthaul" is the network connecting base
(baseband processing units) to the remote radio heads (antennas). stations (baseband processing units) to the remote radio heads
The "Midhaul" is the network inter-connecting base stations (or small (antennas). The "Midhaul" is the network inter-connecting base
cell sites). stations (or small cell sites). The "Backhaul" is the network or
links connecting the radio base station sites to the network
controller/gateway sites (i.e. the core of the 3GPP cellular
network).
In Figure 10 "eNB" ("E-UTRAN Node B") is the hardware that is 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 |
Y------( Front )----|eNB|----( Haul )----| core | Y------( Front )----|eNB|----( Haul )----| core |
skipping to change at page 50, line 50 skipping to change at page 51, line 50
For packet-based transport the allocated transport time (e.g. CPRI For packet-based transport the allocated transport time (e.g. CPRI
would allow for 100us delay [CPRI]) is consumed by all nodes and would allow for 100us delay [CPRI]) is consumed by all nodes and
buffering between the remote radio head and the baseband processing buffering between the remote radio head and the baseband processing
unit, plus the distance-incurred delay. unit, plus the distance-incurred delay.
The baseband processing time and the available "delay budget" for the The baseband processing time and the available "delay budget" for the
fronthaul is likely to change in the forthcoming "5G" due to reduced fronthaul is likely to change in the forthcoming "5G" due to reduced
radio round trip times and other architectural and service radio round trip times and other architectural and service
requirements [NGMN]. requirements [NGMN].
The transport time budget, as noted above, places limitations on the
distance that remote radio heads can be located from base stations
(i.e. the link length). In the above analysis, the entire transport
time budget is assumed to be available for link propagation delay.
However the transport time budget can be broken down into three
components: scheduling /queueing delay, transmission delay, and link
propagation delay. Using today's Fronthaul networking technology,
the queuing, scheduling and transmission components might become the
dominant factors in the total transport time rather than the link
propagation delay. This is especially true in cases where the
Fronthaul link is relatively short and it is shared among multiple
Fronthaul flows, for example in indoor and small cell networks,
massive MIMO antenna networks, and split Fronthaul architectures.
DetNet technology can improve this application by controlling and
reducing the time required for the queuing, scheduling and
transmission operations by properly assigning the network resources,
thus leaving more of the transport time budget available for link
propagation, and thus enabling longer link lengths. However, link
length is usually a given parameter and is not a controllable network
parameter, since RRH and BBU sights are usually located in
predetermined locations. However, the number of antennas in an RRH
sight might increase for example by adding more antennas, increasing
the MIMO capability of the network or support of massive MIMO. This
means increasing the number of the fronthaul flows sharing the same
fronthaul link. DetNet can now control the bandwidth assignment of
the fronthaul link and the scheduling pf fronthaul packets over this
link and provide adequate buffer provisioning for each flow to reduce
the packet loss rate.
Another way in which DetNet technology can aid Fronthaul networks is
by providing effective isolation from best-effort (and other classes
of) traffic, which can arise as a result of network slicing in 5G
networks where Fronthaul traffic generated in different network
slices might have differing performance requirements. DetNet
technology can also dynamically control the bandwidth assignment,
scheduling and packet forwarding decisions and the buffer
provisioning of the Fronthaul flows to guarantee the end-to-end delay
of the Fronthaul packets and minimize the packet loss rate.
[METIS] documents the fundamental challenges as well as overall [METIS] documents the fundamental challenges as well as overall
technical goals of the future 5G mobile and wireless system as the technical goals of the future 5G mobile and wireless system as the
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
skipping to change at page 53, line 12 skipping to change at page 55, line 7
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.
In order to meet the timing requirements both senders and receivers In order to meet the timing requirements both senders and receivers
must remain time synchronized, demanding very accurate clock must remain time synchronized, demanding very accurate clock
distribution, for example support for IEEE 1588 transparent clocks or distribution, for example support for IEEE 1588 transparent clocks or
boundary clocks in every intermediate node. boundary clocks in every intermediate node.
In cellular networks from the LTE radio era onward, phase In cellular networks from the LTE radio era onward, phase
synchronization is needed in addition to frequency synchronization synchronization is needed in addition to frequency synchronization
([TS36300], [TS23401]). ([TS36300], [TS23401]). Time constraints are also important due to
their impact on packet loss. If a packet is delivered too late, then
the packet may be dropped by the host.
6.1.4. Transport Loss Constraints 6.1.4. Transport Loss Constraints
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. Current caused by BER, congestion, or network failure scenarios. Different
tools for elminating packet loss for Fronthaul and Midhaul networks fronthaul functional splits are being considered by 3GPP, requiring
have serious challenges, for example retransmitting lost packets and/ strict frame loss ratio (FLR) guarantees. As one example (referring
or using forward error correction (FEC) to circumvent bit errors is to the legacy CPRI split which is option 8 in 3GPP) lower layers
splits may imply an FLR of less than 10E-7 for data traffic and less
than 10E-6 for control and management traffic. Current tools for
eliminating packet loss for Fronthaul and Midhaul networks have
serious challenges, for example retransmitting lost packets and/or
using forward error correction (FEC) to circumvent bit errors is
practically impossible due to the additional delay incurred. Using practically impossible due to the additional delay incurred. Using
redundant streams for better guarantees for delivery is also redundant streams for better guarantees for delivery is also
practically impossible in many cases due to high bandwidth practically impossible in many cases due to high bandwidth
requirements of Fronthaul and Midhaul networks. Protection switching requirements of Fronthaul and Midhaul networks. Protection switching
is also a candidate but current technologies for the path switch are is also a candidate but current technologies for the path switch are
too slow to avoid reset of mobile interfaces. 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
skipping to change at page 55, line 21 skipping to change at page 57, line 21
Future Cellular Radio Networks will be based on a mix of different Future Cellular Radio Networks will be based on a mix of different
xHaul networks (xHaul = front-, mid- and backhaul), and future xHaul networks (xHaul = front-, mid- and backhaul), and future
transport networks should be able to support all of them transport networks should be able to support all of them
simultaneously. It is already envisioned today that: simultaneously. It is already envisioned today that:
o Not all "cellular radio network" traffic will be IP, for example o Not all "cellular radio network" traffic will be IP, for example
some will remain at Layer 2 (e.g. Ethernet based). DetNet some will remain at Layer 2 (e.g. Ethernet based). DetNet
solutions must address all traffic types (Layer 2, Layer 3) with solutions must address all traffic types (Layer 2, Layer 3) with
the same tools and allow their transport simultaneously. the same tools and allow their transport simultaneously.
o All form of xHaul networks will need some form of DetNet o All forms of xHaul networks will need some form of DetNet
solutions. For example with the advent of 5G some Backhaul solutions. For example with the advent of 5G some Backhaul
traffic will also have DetNet requirements (e.g. traffic belonging traffic will also have DetNet requirements, for example traffic
to time-critical 5G applications). belonging to time-critical 5G applications.
o Different splits of the functionality run on the base stations and
the on-site units could co-exist on the same Fronthaul and
Backhaul network.
We would like to see the following in future Cellular Radio networks: We would like to see the following in future Cellular Radio networks:
o Unified standards-based transport protocols and standard o Unified standards-based transport protocols and standard
networking equipment that can make use of underlying deterministic networking equipment that can make use of underlying deterministic
link-layer services link-layer services
o Unified and standards-based network management systems and o Unified and standards-based network management systems and
protocols in all parts of the network (including Fronthaul) protocols in all parts of the network (including Fronthaul)
skipping to change at page 57, line 15 skipping to change at page 59, line 15
6.4. Cellular Radio Networks Asks 6.4. Cellular Radio Networks Asks
A standard for data plane transport specification which is: A standard for data plane transport specification which is:
o Unified among all xHauls (meaning that different flows with o Unified among all xHauls (meaning that different flows with
diverse DetNet requirements can coexist in the same network and diverse DetNet requirements can coexist in the same network and
traverse the same nodes without interfering with each other) traverse the same nodes without interfering with each other)
o Deployed in a highly deterministic network environment o Deployed in a highly deterministic network environment
o Capable of supporting multiple functional splits simultaneously,
including existing Backhaul and CPRI Fronthaul and potentially new
modes as defined for example in 3GPP; these goals can be supported
by the existing DetNet Use Case Common Themes, notably "Mix of
Deterministic and Best-Effort Traffic", "Bounded Latency", "Low
Latency", "Symmetrical Path Delays", and "Deterministic Flows".
o Capable of supporting Network Slicing and Multi-tenancy; these
goals can be supported by the same DetNet themes noted above.
o Capable of transporting both in-band and out-band control traffic
(OAM info, ...).
o Deployable over multiple data link technologies (e.g., IEEE 802.3,
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 M2M
skipping to change at page 60, line 48 skipping to change at page 63, line 5
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 (burstless, 0.1-1 %)
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. Use Case Common Themes 8. Mining Industry
8.1. Use Case Description
The mining industry is highly dependent on networks to monitor and
control their systems both in open-pit and underground extraction,
transport and refining processes. In order to reduce risks and
increase operational efficiency in mining operations, a number of
processes have migrated the operators from the extraction site to
remote control and monitoring.
In the case of open pit mining, autonomous trucks are used to
transport the raw materials from the open pit to the refining factory
where the final product (e.g. Copper) is obtained. Although the
operation is autonomous, the tracks are remotely monitored from a
central facility.
In pit mines, the monitoring of the tailings or mine dumps is
critical in order to avoid any environmental pollution. In the past,
monitoring has been conducted through manual inspection of pre-
installed dataloggers. Cabling is not usually exploited in such
scenarios due to the cost and complex deployment requirements.
Currently, wireless technologies are being employed to monitor these
cases permanently. Slopes are also monitored in order to anticipate
possible mine collapse. Due to the unstable terrain, cable
maintenance is costly and complex and hence wireless technologies are
employed.
In the underground monitoring case, autonomous vehicles with
extraction tools travel autonomously through the tunnels, but their
operational tasks (such as excavation, stone breaking and transport)
are controlled remotely from a central facility. This generates
video and feedback upstream traffic plus downstream actuator control
traffic.
8.2. Mining Industry Today
Currently the mining industry uses a packet switched architecture
supported by high speed ethernet. However in order to achieve the
delay and packet loss requirements the network bandwidth is
overestimated, thus providing very low efficiency in terms of
resource usage.
QoS is implemented at the Routers to separate video, management,
monitoring and process control traffic for each stream.
Since mobility is involved in this process, the connection between
the backbone and the mobile devices (e.g. trucks, trains and
excavators) is solved using a wireless link. These links are based
on 802.11 for open-pit mining and leaky feeder for underground
mining.
Lately in pit mines the use of LPWAN technologies has been extended:
Tailings, slopes and mine dumps are monitored by battery-powered
dataloggers that make use of robust long range radio technologies.
Reliability is usually ensured through retransmissions at L2.
Gateways or concentrators act as bridges forwarding the data to the
backbone ethernet network. Deterministic requirements are biased
towards reliability rather than latency as events are slowly
triggered or can be anticipated in advance.
At the mineral processing stage, conveyor belts and refining
processes are controlled by a SCADA system, which provides the in-
factory delay-constrained networking requirements.
Voice communications are currently served by a redundant trunking
infrastructure, independent from current data networks.
8.3. Mining Industry Future
Mining operations and management are currently converging towards a
combination of autonomous operation and teleoperation of transport
and extraction machines. This means that video, audio, monitoring
and process control traffic will increase dramatically. Ideally, all
activities on the mine will rely on network infrastructure.
Wireless for open-pit mining is already a reality with LPWAN
technologies and it is expected to evolve to more advanced LPWAN
technologies such as those based on LTE to increase last hop
reliability or novel LPWAN flavours with deterministic access.
One area in which DetNet can improve this use case is in the wired
networks that make up the "backbone network" of the system, which
connect together many wireless access points (APs). The mobile
machines (which are connected to the network via wireless) transition
from one AP to the next as they move about. A deterministic,
reliable, low latency backbone can enable these transitions to be
more reliable.
Connections which extend all the way from the base stations to the
machinery via a mix of wired and wireless hops would also be
beneficial, for example to improve remote control responsiveness of
digging machines. However to guarantee deterministic performance of
a DetNet, the end-to-end underlying network must be deterministic.
Thus for this use case if a deterministic wireless transport is
integrated with a wire-based DetNet network, it could create the
desired wired plus wireless end-to-end deterministic network.
8.4. Mining Industry Asks
o Improved bandwidth efficiency
o Very low delay to enable machine teleoperation
o Dedicated bandwidth usage for high resolution video streams
o Predictable delay to enable realtime monitoring
o Potential to construct a unified DetNet network over a combination
of wired and deterministic wireless links
9. Private Blockchain
9.1. Use Case Description
Blockchain was created with bitcoin, as a 'public' blockchain on the
open Internet, however blockchain has also spread far beyond its
original host into various industries such as smart manufacturing,
logistics, security, legal rights and others. In these industries
blockchain runs in designated and carefully managed network in which
deterministic networking requirements could be addressed by Detnet.
Such implementations are referred to as 'private' blockchain.
The sole distinction between public and private blockchain is related
to who is allowed to participate in the network, execute the
consensus protocol and maintain the shared ledger.
Today's networks treat the traffic from blockchain on a best-effort
basis, but blockchain operation could be made much more efficient if
deterministic networking service were available to minimize latency
and packet loss in the network.
9.1.1. Blockchain Operation
A 'block' runs as a container of a batch of primary items such as
transactions, property records etc. The blocks are chained in such a
way that the hash of the previous block works as the pointer header
of the new block, where confirmation of each block requires a
consensus mechanism. When an item arrives at a blockchain node, the
latter broadcasts this item to the rest of nodes which receive and
verify it and put it in the ongoing block. Block confirmation
process begins as the amount of items reaches the predefined block
capacity, and the node broadcasts its proved block to the rest of
nodes to be verified and chained.
9.1.2. Blockchain Network Architecture
Blockchain node communication and coordination is achieved mainly
through frequent point to multi-point communication, however
persistent point-to-point connections are used to transport both the
items and the blocks to the other nodes.
When a node initiates, it first requests the other nodes' address
from a specific entity such as DNS, then it creates persistent
connections each of with other nodes. If node A confirms an item, it
sends the item to the other nodes via the persistent connections.
As a new block in a node completes and gets proved among the nodes,
it starts propagating this block towards its neighbor nodes. Assume
node A receives a block, it sends invite message after verification
to its neighbor B, B checks if the designated block is available, it
responds get message to A if it is unavailable, and A send the
complete block to B. B repeats the process as A to start the next
round of block propagation.
The challenge of blockchain network operation is not overall data
rates, since the volume from both block and item stays between
hundreds of bytes to a couple of mega bytes per second, but is in
transporting the blocks with minimum latency to maximize efficiency
of the blockchain consensus process.
9.1.3. Security Considerations
Security is crucial to blockchain applications, and todayt blockchain
addresses its security issues mainly at the application level, where
cryptography as well as hash-based consensus play a leading role
preventing both double-spending and malicious service attack.
However, there is concern that in the proposed use case of a private
blockchain network which is dependent on deterministic properties,
the network could be vulnerable to delays and other specific attacks
against determinism which could interrupt service.
9.2. Private Blockchain Today
Today private blockchain runs in L2 or L3 VPN, in general without
guaranteed determinism. The industry players are starting to realize
that improving determinism in their blockchain networks could improve
the performance of their service, but as of today these goals are not
being met.
9.3. Private Blockchain Future
Blockchain system performance can be greatly improved through
deterministic networking service primarily because it would
accelerate the consensus process. It would be valuable to be able to
design a private blockchain network with the following properties:
o Transport of point to multi-point traffic in a coordinated network
architecture rather than at the application layer (which typically
uses point-to-point connections)
o Guaranteed transport latency
o Reduced packet loss (to the point where packet retransmission-
incurred delay would be negligible.)
9.4. Private Blockchain Asks
o Layer 2 and Layer 3 multicast of blockchain traffic
o Item and block delivery with bounded, low latency and negligible
packet loss
o Coexistence in a single network of blockchain and IT traffic.
o Ability to scale the network by distributing the centralized
control of the network across multiple control entities.
10. Network Slicing
10.1. Use Case Description
Network slicing divides one physical network infrastructure into
multiple logical networks. Each slice, corresponding to a logical
network, uses resources and network functions independently from each
other. Network slicing provides flexibility of resource allocation
and service quality customization.
Future services will demand network performance with a wide variety
of characteristics such as high data rate, low latency, low loss
rate, security and many other parameters. Ideally every service
would have its own physical network satisfying its particular
performance requirements, however that would be prohibitively
expensive. Network slicing can provide a customized slice for a
single service, and multiple slices can share the same physical
network. This method can optimize the performance for the service at
lower cost, and the flexibility of setting up and release the slices
also allows the user to allocate the network resources dynamically.
Unlike other DetNet use cases, Network slicing is not a specific
application with specific deterministic requirements; it is proposed
as a new requirement for the future network, which is still in
discussion, and DetNet is a candidate solution for it.
10.2. Network Slicing Use Cases
Network Slicing is a core feature of 5G defined in 3GPP, which is
currently under development. A Network Slice in mobile network is a
complete logical network including Radio Access Network (RAN) and
Core Network (CN). It provides telecommunication services and
network capabilities, which may vary (or not) from slice to slice.
A 5G bearer network is a typical use case of network slicing,
including 3 service scenarios: enhanced Mobile Broadband (eMBB),
Ultra-Reliable and Low Latency Communications (URLLC), and massive
Machine Type Communications (mMTC). Each of these are described
below.
10.2.1. Enhanced Mobile Broadband (eMBB)
eMBB focuses on services characterized by high data rates, such as
high definition (HD) videos, virtual reality (VR), augmented reality
(AR), and fixed mobile convergence (FMC).
10.2.2. Ultra-Reliable and Low Latency Communications (URLLC)
URLLC focuses on latency-sensitive services, such as self-driving
vehicles, remote surgery, or drone control.
10.2.3. massive Machine Type Communications (mMTC)
mMTC focuses on services that have high requirements for connection
density, such as those typical for smart city and smart agriculture
use cases.
10.3. Using DetNet in Network Slicing
One of the requirements discussed for network slicing is the "hard"
separation of various users' deterministic performance. That is, it
should be impossible for activity, lack of activity, or changes in
activity of one or more users to have any appreciable effect on the
deterministic performance parameters of any other users. Typical
techniques used today, which share a physical network among users, do
not offer this kind of insulation. DetNet can supply point-to-point
or point-to-multipoint paths that offer bandwidth and latency
guarantees to a user that cannot be affected by other users' data
traffic.
Thus DetNet is a powerful tool when latency and reliability are
required in Network Slicing. However, DetNet cannot cover every
Network Slicing use case, and there are some other problems to be
solved. Firstly, DetNet is a point-to-point or point-to-multipoint
technology while Network Slicing needs multi-point to multi-point
guarantee. Second, the number of flows that can be carried by DetNet
is limited by DetNet scalability. Flow aggregation and queuing
management modification may help to fix the problem. More work and
discussions are needed in these topics.
10.4. Network Slicing Today and Future
Network slicing can satisfy the requirements of a lot of future
deployment scenario, but it is still a collection of ideas and
analysis, without a specific technical solution. A lot of
technologies, such as Flex-E, Segment Routing, and DetNet have
potential to be used in Network Slicing. For more details please see
IETF99 Network Slicing BOF session agenda and materials.
10.5. Network Slicing Asks
o Isolation from other flows through Queuing Management
o Service Quality Customization and Guarantee
o Security
11. Use Case Common Themes
This section summarizes the expected properties of a DetNet network, This section summarizes the expected properties of a DetNet network,
based on the use cases as described in this draft. based on the use cases as described in this draft.
8.1. Unified, standards-based network 11.1. Unified, standards-based network
8.1.1. Extensions to Ethernet 11.1.1. Extensions to Ethernet
A DetNet network is not "a new kind of network" - it based on A DetNet network is not "a new kind of network" - it based on
extensions to existing Ethernet standards, including elements of IEEE extensions to existing Ethernet standards, including elements of IEEE
802.1 AVB/TSN and related standards. Presumably it will be possible 802.1 AVB/TSN and related standards. Presumably it will be possible
to run DetNet over other underlying transports besides Ethernet, but to run DetNet over other underlying transports besides Ethernet, but
Ethernet is explicitly supported. Ethernet is explicitly supported.
8.1.2. Centrally Administered 11.1.2. Centrally Administered
In general a DetNet network is not expected to be "plug and play" - In general a DetNet network is not expected to be "plug and play" -
it is expected that there is some centralized network configuration it is expected that there is some centralized network configuration
and control system. Such a system may be in a single central and control system. Such a system may be in a single central
location, or it maybe distributed across multiple control entities location, or it maybe distributed across multiple control entities
that function together as a unified control system for the network. that function together as a unified control system for the network.
However, the ability to "hot swap" components (e.g. due to However, the ability to "hot swap" components (e.g. due to
malfunction) is similar enough to "plug and play" that this kind of malfunction) is similar enough to "plug and play" that this kind of
behavior may be expected in DetNet networks, depending on the behavior may be expected in DetNet networks, depending on the
implementation. implementation.
8.1.3. Standardized Data Flow Information Models 11.1.3. Standardized Data Flow Information Models
Data Flow Information Models to be used with DetNet networks are to Data Flow Information Models to be used with DetNet networks are to
be specified by DetNet. be specified by DetNet.
8.1.4. L2 and L3 Integration 11.1.4. L2 and L3 Integration
A DetNet network is intended to integrate between Layer 2 (bridged) A DetNet network is intended to integrate between Layer 2 (bridged)
network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g. network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g.
using IP-based protocols). One example of this is "making AVB/TSN- using IP-based protocols). One example of this is "making AVB/TSN-
type deterministic performance available from Layer 3 applications, type deterministic performance available from Layer 3 applications,
e.g. using RTP". Another example is "connecting two AVB/TSN LANs e.g. using RTP". Another example is "connecting two AVB/TSN LANs
("islands") together through a standard router". ("islands") together through a standard router".
8.1.5. Guaranteed End-to-End Delivery 11.1.5. Guaranteed End-to-End Delivery
Packets sent over DetNet are guaranteed not to be dropped by the Packets sent over DetNet are guaranteed not to be dropped by the
network due to congestion. (Packets may however be dropped for network due to congestion. (Packets may however be dropped for
intended reasons, e.g. per security measures). intended reasons, e.g. per security measures).
8.1.6. Replacement for Multiple Proprietary Deterministic Networks 11.1.6. 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 currently available; DetNet is intended to provide an
open-standards-based alternative to such networks. open-standards-based alternative to such networks.
8.1.7. Mix of Deterministic and Best-Effort Traffic 11.1.7. 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.
8.1.8. Unused Reserved BW to be Available to Best Effort Traffic 11.1.8. 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.
8.1.9. Lower Cost, Multi-Vendor Solutions 11.1.9. Lower Cost, Multi-Vendor Solutions
The DetNet network specifications are intended to enable an ecosystem The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus in which multiple vendors can create interoperable products, thus
promoting device diversity and potentially higher numbers of each promoting device diversity and potentially higher numbers of each
device manufactured, promoting cost reduction and cost competition device manufactured, promoting cost reduction and cost competition
among vendors. The intent is that DetNet networks should be able to among vendors. The intent is that DetNet networks should be able to
be created at lower cost and with greater diversity of available be created at lower cost and with greater diversity of available
devices than existing proprietary networks. devices than existing proprietary networks.
8.2. Scalable Size 11.2. Scalable Size
DetNet networks range in size from very small, e.g. inside a single DetNet networks range in size from very small, e.g. inside a single
industrial machine, to very large, for example a Utility Grid network industrial machine, to very large, for example a Utility Grid network
spanning a whole country, and involving many "hops" over various spanning a whole country, and involving many "hops" over various
kinds of links for example radio repeaters, microwave linkes, fiber kinds of links for example radio repeaters, microwave linkes, fiber
optic links, etc.. However recall that the scope of DetNet is optic links, etc.. However recall that the scope of DetNet is
confined to networks that are centrally administered, and explicitly confined to networks that are centrally administered, and explicitly
excludes unbounded decentralized networks such as the Internet. excludes unbounded decentralized networks such as the Internet.
8.3. Scalable Timing Parameters and Accuracy 11.3. Scalable Timing Parameters and Accuracy
8.3.1. Bounded Latency 11.3.1. Bounded Latency
The DetNet Data Flow Information Model is expected to provide means The DetNet Data Flow Information Model is expected to provide means
to configure the network that include parameters for querying network to configure the network that include parameters for querying network
path latency, requesting bounded latency for a given stream, path latency, requesting bounded latency for a given stream,
requesting worst case maximum and/or minimum latency for a given path requesting worst case maximum and/or minimum latency for a given path
or stream, and so on. It is an expected case that the network may or stream, and so on. It is an expected case that the network may
not be able to provide a given requested service level, and if so the not be able to provide a given requested service level, and if so the
network control system should reply that the requested services is network control system should reply that the requested services is
not available (as opposed to accepting the parameter but then not not available (as opposed to accepting the parameter but then not
delivering the desired behavior). delivering the desired behavior).
8.3.2. Low Latency 11.3.2. Low Latency
Applications may require "extremely low latency" however depending on Applications may require "extremely low latency" however depending on
the application these may mean very different latency values; for the application these may mean very different latency values; for
example "low latency" across a Utility grid network is on a different example "low latency" across a Utility grid network is on a different
time scale than "low latency" in a motor control loop in a small time scale than "low latency" in a motor control loop in a small
machine. The intent is that the mechanisms for specifying desired machine. The intent is that the mechanisms for specifying desired
latency include wide ranges, and that architecturally there is latency include wide ranges, and that architecturally there is
nothing to prevent arbirtrarily low latencies from being implemented nothing to prevent arbirtrarily low latencies from being implemented
in a given network. in a given network.
8.3.3. Symmetrical Path Delays 11.3.3. Symmetrical Path Delays
Some applications would like to specify that the transit delay time Some applications would like to specify that the transit delay time
values be equal for both the transmit and return paths. values be equal for both the transmit and return paths.
8.4. High Reliability and Availability 11.4. High Reliability and Availability
Reliablity is of critical importance to many DetNet applications, in Reliablity is of critical importance to many DetNet applications, in
which consequences of failure can be extraordinarily high in terms of which consequences of failure can be extraordinarily high in terms of
cost and even human life. DetNet based systems are expected to be cost and even human life. DetNet based systems are expected to be
implemented with essentially arbitrarily high availability (for implemented with essentially arbitrarily high availability (for
example 99.9999% up time, or even 12 nines). The intent is that the example 99.9999% up time, or even 12 nines). The intent is that the
DetNet designs should not make any assumptions about the level of DetNet designs should not make any assumptions about the level of
reliability and availability that may be required of a given system, reliability and availability that may be required of a given system,
and should define parameters for communicating these kinds of metrics and should define parameters for communicating these kinds of metrics
within the network. within the network.
A strategy used by DetNet for providing such extraordinarily high A strategy used by DetNet for providing such extraordinarily high
levels of reliability is to provide redundant paths that can be levels of reliability is to provide redundant paths that can be
seamlessly switched between, while maintaining the required seamlessly switched between, while maintaining the required
performance of that system. performance of that system.
8.5. Security 11.5. Security
Security is of critical importance to many DetNet applications. A Security is of critical importance to many DetNet applications. A
DetNet network must be able to be made secure against devices DetNet network must be able to be made secure against devices
failures, attackers, misbehaving devices, and so on. In a DetNet failures, attackers, misbehaving devices, and so on. In a DetNet
network the data traffic is expected to be be time-sensitive, thus in network the data traffic is expected to be be time-sensitive, thus in
addition to arriving with the data content as intended, the data must addition to arriving with the data content as intended, the data must
also arrive at the expected time. This may present "new" security also arrive at the expected time. This may present "new" security
challenges to implementers, and must be addressed accordingly. There challenges to implementers, and must be addressed accordingly. There
are other security implications, including (but not limited to) the are other security implications, including (but not limited to) the
change in attack surface presented by packet replication and change in attack surface presented by packet replication and
elimination. elimination.
8.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.
9. Use Cases Explicitly Out of Scope for DetNet 12. Use Cases Explicitly Out of Scope for DetNet
This section contains use case text that has been determined to be This section contains use case text that has been determined to be
outside of the scope of the present DetNet work. outside of the scope of the present DetNet work.
9.1. DetNet Scope Limitations 12.1. DetNet Scope Limitations
The scope of DetNet is deliberately limited to specific use cases The scope of DetNet is deliberately limited to specific use cases
that are consistent with the WG charter, subject to the that are consistent with the WG charter, subject to the
interpretation of the WG. At the time the DetNet Use Cases were interpretation of the WG. At the time the DetNet Use Cases were
solicited and provided by the authors the scope of DetNet was not solicited and provided by the authors the scope of DetNet was not
clearly defined, and as that clarity has emerged, certain of the use clearly defined, and as that clarity has emerged, certain of the use
cases have been determined to be outside the scope of the present cases have been determined to be outside the scope of the present
DetNet work. Such text has been moved into this section to clarify DetNet work. Such text has been moved into this section to clarify
that these use cases will not be supported by the DetNet work. that these use cases will not be supported by the DetNet work.
skipping to change at page 65, line 5 skipping to change at page 73, line 42
Precision Time Protocol ([IEEE1588]). A use case may state the Precision Time Protocol ([IEEE1588]). A use case may state the
accuracy and reliability that it expects from the DetNet network accuracy and reliability that it expects from the DetNet network
as part of a whole system, however it is understood that such as part of a whole system, however it is understood that such
timing properties are not guaranteed by DetNet itself. It is timing properties are not guaranteed by DetNet itself. It is
currently an open question as to whether DetNet protocols will currently an open question as to whether DetNet protocols will
include a way for an application to communicate such timing include a way for an application to communicate such timing
expectations to the network, and if so whether they would be expectations to the network, and if so whether they would be
expected to materially affect the performance they would receive expected to materially affect the performance they would receive
from the network as a result. from the network as a result.
9.2. Internet-based Applications 12.2. Internet-based Applications
9.2.1. Use Case Description 12.2.1. Use Case Description
There are many applications that communicate across the open Internet There are many applications that communicate across the open Internet
that could benefit from guaranteed delivery and bounded latency. The that could benefit from guaranteed delivery and bounded latency. The
following are some representative examples. following are some representative examples.
9.2.1.1. Media Content Delivery 12.2.1.1. Media Content Delivery
Media content delivery continues to be an important use of the Media content delivery continues to be an important use of the
Internet, yet users often experience poor quality audio and video due Internet, yet users often experience poor quality audio and video due
to the delay and jitter inherent in today's Internet. to the delay and jitter inherent in today's Internet.
9.2.1.2. Online Gaming 12.2.1.2. Online Gaming
Online gaming is a significant part of the gaming market, however Online gaming is a significant part of the gaming market, however
latency can degrade the end user experience. For example "First latency can degrade the end user experience. For example "First
Person Shooter" (FPS) games are highly delay-sensitive. Person Shooter" (FPS) games are highly delay-sensitive.
9.2.1.3. Virtual Reality 12.2.1.3. Virtual Reality
Virtual reality (VR) has many commercial applications including real Virtual reality (VR) has many commercial applications including real
estate presentations, remote medical procedures, and so on. Low estate presentations, remote medical procedures, and so on. Low
latency is critical to interacting with the virtual world because latency is critical to interacting with the virtual world because
perceptual delays can cause motion sickness. perceptual delays can cause motion sickness.
9.2.2. Internet-Based Applications Today 12.2.2. Internet-Based Applications Today
Internet service today is by definition "best effort", with no Internet service today is by definition "best effort", with no
guarantees on delivery or bandwidth. guarantees on delivery or bandwidth.
9.2.3. Internet-Based Applications Future 12.2.3. Internet-Based Applications Future
We imagine an Internet from which we will be able to play a video We imagine an Internet from which we will be able to play a video
without glitches and play games without lag. without glitches and play games without lag.
For online gaming, the maximum round-trip delay can be 100ms and 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 stricter for FPS gaming which can be 10-50ms. Transport delay is the
dominate part with a 5-20ms budget. dominate part with a 5-20ms budget.
For VR, 1-10ms maximum delay is needed and total network budget is For VR, 1-10ms maximum delay is needed and total network budget is
1-5ms if doing remote VR. 1-5ms if doing remote VR.
Flow identification can be used for gaming and VR, i.e. it can Flow identification can be used for gaming and VR, i.e. it can
recognize a critical flow and provide appropriate latency bounds. recognize a critical flow and provide appropriate latency bounds.
9.2.4. Internet-Based Applications Asks 12.2.4. Internet-Based Applications Asks
o Unified control and management protocols to handle time-critical o Unified control and management protocols to handle time-critical
data flow data flow
o Application-aware flow filtering mechanism to recognize the timing o Application-aware flow filtering mechanism to recognize the timing
critical flow without doing 5-tuple matching critical flow without doing 5-tuple matching
o Unified control plane to provide low latency service on Layer-3 o Unified control plane to provide low latency service on Layer-3
without changing the data plane without changing the data plane
o OAM system and protocols which can help to provide E2E-delay o OAM system and protocols which can help to provide E2E-delay
sensitive service provisioning sensitive service provisioning
9.3. Pro Audio and Video - Digital Rights Management (DRM) 12.3. Pro Audio and Video - Digital Rights Management (DRM)
This section was moved here because this is considered a Link layer This section was moved here because this is considered a Link layer
topic, not direct responsibility of DetNet. topic, not direct responsibility of DetNet.
Digital Rights Management (DRM) is very important to the audio and Digital Rights Management (DRM) is very important to the audio and
video industries. Any time protected content is introduced into a video industries. Any time protected content is introduced into a
network there are DRM concerns that must be maintained (see network there are DRM concerns that must be maintained (see
[CONTENT_PROTECTION]). Many aspects of DRM are outside the scope of [CONTENT_PROTECTION]). Many aspects of DRM are outside the scope of
network technology, however there are cases when a secure link network technology, however there are cases when a secure link
supporting authentication and encryption is required by content supporting authentication and encryption is required by content
skipping to change at page 66, line 41 skipping to change at page 75, line 33
own secure environment (for example see [DCI]). own secure environment (for example see [DCI]).
As an example, two techniques are Digital Transmission Content As an example, two techniques are Digital Transmission Content
Protection (DTCP) and High-Bandwidth Digital Content Protection Protection (DTCP) and High-Bandwidth Digital Content Protection
(HDCP). HDCP content is not approved for retransmission within any (HDCP). HDCP content is not approved for retransmission within any
other type of DRM, while DTCP may be retransmitted under HDCP. other type of DRM, while DTCP may be retransmitted under HDCP.
Therefore if the source of a stream is outside of the network and it Therefore if the source of a stream is outside of the network and it
uses HDCP protection it is only allowed to be placed on the network uses HDCP protection it is only allowed to be placed on the network
with that same HDCP protection. with that same HDCP protection.
9.4. Pro Audio and Video - Link Aggregation 12.4. Pro Audio and Video - Link Aggregation
Note: The term "Link Aggregation" is used here as defined by the text 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 in the following paragraph, i.e. not following a more common Network
Industry definition. Current WG consensus is that this item won't be Industry definition. Current WG consensus is that this item won't be
directly supported by the DetNet architecture, for example because it directly supported by the DetNet architecture, for example because it
implies guarantee of in-order delivery of packets which conflicts implies guarantee of in-order delivery of packets which conflicts
with the core goal of achieving the lowest possible latency. with the core goal of achieving the lowest possible latency.
For transmitting streams that require more bandwidth than a single For transmitting streams that require more bandwidth than a single
link in the target network can support, link aggregation is a link in the target network can support, link aggregation is a
technique for combining (aggregating) the bandwidth available on technique for combining (aggregating) the bandwidth available on
multiple physical links to create a single logical link of the multiple physical links to create a single logical link of the
required bandwidth. However, if aggregation is to be used, the required bandwidth. However, if aggregation is to be used, the
network controller (or equivalent) must be able to determine the network controller (or equivalent) must be able to determine the
maximum latency of any path through the aggregate link. maximum latency of any path through the aggregate link.
10. Acknowledgments 13. Acknowledgments
10.1. Pro Audio 13.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
10.2. Utility Telecom 13.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
10.3. Building Automation Systems 13.3. Building Automation Systems
This section was derived from draft-bas-usecase-detnet-00. This section was derived from draft-bas-usecase-detnet-00.
10.4. Wireless for Industrial 13.4. Wireless for Industrial
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.
10.5. Cellular Radio 13.5. Cellular Radio
This section was derived from draft-korhonen-detnet-telreq-00. This section was derived from draft-korhonen-detnet-telreq-00.
10.6. Industrial M2M 13.6. Industrial 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.
10.7. Internet Applications and CoMP 13.7. Internet Applications and CoMP
This section was derived from draft-zha-detnet-use-case-00. This section was derived from draft-zha-detnet-use-case-00.
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.
10.8. Electrical Utilities 13.8. Electrical Utilities
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).
11. Informative References 13.9. Network Slicing
This section was written by Xuesong Geng, who would like to
acknowledge Norm Finn and Mach Chen for their useful comments.
13.10. Mining
This section was written by Diego Dujovne in conjunction with Xavier
Vilasojana.
13.11. Private Blockchain
This section was written by Daniel Huang.
14. Informative References
[ACE] IETF, "Authentication and Authorization for Constrained [ACE] IETF, "Authentication and Authorization for Constrained
Environments", <https://datatracker.ietf.org/doc/charter- Environments",
ietf-ace/>. <https://datatracker.ietf.org/doc/charter-ietf-ace/>.
[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.
[CCAMP] IETF, "Common Control and Measurement Plane", [CCAMP] IETF, "Common Control and Measurement Plane",
skipping to change at page 70, line 22 skipping to change at page 79, line 32
Statement", draft-finn-detnet-problem-statement-05 (work Statement", draft-finn-detnet-problem-statement-05 (work
in progress), March 2016. in progress), March 2016.
[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-11 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
in progress), January 2017. in progress), August 2017.
[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-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-08 (work in 802.15.4e", draft-ietf-6tisch-terminology-09 (work in
progress), December 2016. progress), June 2017.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.ietf-mpls-residence-time] [I-D.ietf-mpls-residence-time]
Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and S. Vainshtein, "Residence Time Measurement in MPLS and S. Vainshtein, "Residence Time Measurement in MPLS
network", draft-ietf-mpls-residence-time-15 (work in network", draft-ietf-mpls-residence-time-15 (work in
skipping to change at page 74, line 31 skipping to change at page 83, line 42
[net5G] Ericsson, "5G Radio Access, Challenges for 2020 and [net5G] Ericsson, "5G Radio Access, Challenges for 2020 and
Beyond", Ericsson white paper wp-5g, June 2013, Beyond", Ericsson white paper wp-5g, June 2013,
<http://www.ericsson.com/res/docs/whitepapers/wp-5g.pdf>. <http://www.ericsson.com/res/docs/whitepapers/wp-5g.pdf>.
[NGMN] NGMN Alliance, "5G White Paper", NGMN 5G White Paper v1.0, [NGMN] NGMN Alliance, "5G White Paper", NGMN 5G White Paper v1.0,
February 2015, <https://www.ngmn.org/uploads/media/ February 2015, <https://www.ngmn.org/uploads/media/
NGMN_5G_White_Paper_V1_0.pdf>. NGMN_5G_White_Paper_V1_0.pdf>.
[NGMN-fronth] [NGMN-fronth]
NGMN Alliance, "Fronthaul Requirements for C-RAN", March NGMN Alliance, "Fronthaul Requirements for C-RAN", March
2015, <https://www.ngmn.org/uploads/media/NGMN_RANEV_D1_C- 2015, <https://www.ngmn.org/uploads/media/
RAN_Fronthaul_Requirements_v1.0.pdf>. NGMN_RANEV_D1_C-RAN_Fronthaul_Requirements_v1.0.pdf>.
[OPCXML] OPC Foundation, "OPC XML-Data Access Specification", Dec [OPCXML] OPC Foundation, "OPC XML-Data Access Specification", Dec
2004. 2004.
[PCE] IETF, "Path Computation Element", [PCE] IETF, "Path Computation Element",
<https://datatracker.ietf.org/doc/charter-ietf-pce/>. <https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[profibus] [profibus]
IEC, "IEC 61158 Type 3 - Profibus DP", January 2001. IEC, "IEC 61158 Type 3 - Profibus DP", January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002, DOI 10.17487/RFC3393, November 2002,
<http://www.rfc-editor.org/info/rfc3393>. <https://www.rfc-editor.org/info/rfc3393>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002, DOI 10.17487/RFC3411, December 2002,
<http://www.rfc-editor.org/info/rfc3411>. <https://www.rfc-editor.org/info/rfc3411>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005, DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>. <https://www.rfc-editor.org/info/rfc3985>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
<http://www.rfc-editor.org/info/rfc4553>. <https://www.rfc-editor.org/info/rfc4553>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007, DOI 10.17487/RFC4903, June 2007,
<http://www.rfc-editor.org/info/rfc4903>. <https://www.rfc-editor.org/info/rfc4903>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>. <https://www.rfc-editor.org/info/rfc4919>.
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
P. Pate, "Structure-Aware Time Division Multiplexed (TDM) P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network Circuit Emulation Service over Packet Switched Network
(CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007,
<http://www.rfc-editor.org/info/rfc5086>. <https://www.rfc-editor.org/info/rfc5086>.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
"Time Division Multiplexing over IP (TDMoIP)", RFC 5087, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087,
DOI 10.17487/RFC5087, December 2007, DOI 10.17487/RFC5087, December 2007,
<http://www.rfc-editor.org/info/rfc5087>. <https://www.rfc-editor.org/info/rfc5087>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<http://www.rfc-editor.org/info/rfc6551>. <https://www.rfc-editor.org/info/rfc6551>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-editor.org/info/rfc7554>. <https://www.rfc-editor.org/info/rfc7554>.
[Spe09] Sperotto, A., Sadre, R., Vliet, F., and A. Pras, "A First [Spe09] Sperotto, A., Sadre, R., Vliet, F., and A. Pras, "A First
Look into SCADA Network Traffic", IP Operations and Look into SCADA Network Traffic", IP Operations and
Management, p. 518-521. , June 2009. Management, p. 518-521. , June 2009.
[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>.
skipping to change at page 81, line 27 skipping to change at page 91, line 4
Email: toktam.mahmoodi@kcl.ac.uk Email: toktam.mahmoodi@kcl.ac.uk
Spiros Spirou Spiros Spirou
Intracom Telecom Intracom Telecom
19.7 km Markopoulou Ave. 19.7 km Markopoulou Ave.
Peania, Attiki 19002 Peania, Attiki 19002
Greece Greece
Email: spis@intracom-telecom.com Email: spis@intracom-telecom.com
Petra Vizarreta Petra Vizarreta
Technical University of Munich, TUM Technical University of Munich, TUM
Maxvorstadt, ArcisstraBe 21 Maxvorstadt, ArcisstraBe 21
Munich, Germany 80333 Munich, Germany 80333
Germany Germany
Email: petra.vizarreta@lkn.ei.tum.de Email: petra.vizarreta@lkn.ei.tum.de
Daniel Huang
ZTE Corporation, Inc.
No. 50 Software Avenue
Nanjing, Jiangsu 210012
P.R. China
Email: huang.guangping@zte.com.cn
Xuesong Geng
Huawei Technologies
Email: gengxuesong@huawei.com
Diego Dujovne
Universidad Diego Portales
Email: diego.dujovne@mail.udp.cl
Maik Seewald
Cisco Systems
Email: maseewal@cisco.com
 End of changes. 92 change blocks. 
237 lines changed or deleted 674 lines changed or added

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