draft-ietf-detnet-use-cases-10.txt   draft-ietf-detnet-use-cases-11.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: January 5, 2017 HARMAN Expires: April 6, 2017 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
Applied Communication Sciences Applied Communication Sciences
Y. Zha Y. Zha
HUAWEI HUAWEI
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
F. Goetz F. Goetz
J. Schmitt J. Schmitt
Siemens Siemens
July 4, 2016 X. Vilajosana
Worldsensing
T. Mahmoodi
King's College London
S. Spirou
Intracom Telecom
P. Vizarreta
Technical University of Munich, TUM
October 3, 2016
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-10 draft-ietf-detnet-use-cases-11
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.
skipping to change at page 2, line 20 skipping to change at page 2, line 28
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 http://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 January 5, 2017. This Internet-Draft will expire on April 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 5 2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 6
2.1. Use Case Description . . . . . . . . . . . . . . . . . . 5 2.1. Use Case Description . . . . . . . . . . . . . . . . . . 6
2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6 2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6
2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 6 2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 7
2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7 2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7
2.1.4. Deterministic Time to Establish Streaming . . . . . . 8 2.1.4. Deterministic Time to Establish Streaming . . . . . . 8
2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8 2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8
2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8 2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8
2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 8 2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 9
2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9 2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9 2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9
2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9 2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9
2.3.3. Integration of Reserved Streams into IT Networks . . 9 2.3.3. Integration of Reserved Streams into IT Networks . . 9
2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 9 2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 10
2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10 2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10
2.3.5.1. Packet Forwarding Rules, VLANs and Subnets . . . 10 2.3.5.1. Packet Forwarding Rules, VLANs and Subnets . . . 10
2.3.5.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 10 2.3.5.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11
2.3.6. Latency Optimization by a Central Controller . . . . 11 2.3.6. Latency Optimization by a Central Controller . . . . 11
2.3.7. Reduced Device Cost Due To Reduced Buffer Memory . . 11 2.3.7. Reduced Device Cost Due To Reduced Buffer Memory . . 11
2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12 2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12
3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12 3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12
3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12
3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 12 3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 12
3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 12 3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 12
3.1.1.2. Intra-Substation Process Bus Communications . . . 18 3.1.1.2. Intra-Substation Process Bus Communications . . . 18
3.1.1.3. Wide Area Monitoring and Control Systems . . . . 19 3.1.1.3. Wide Area Monitoring and Control Systems . . . . 19
3.1.1.4. IEC 61850 WAN engineering guidelines requirement 3.1.1.4. IEC 61850 WAN engineering guidelines requirement
classification . . . . . . . . . . . . . . . . . 20 classification . . . . . . . . . . . . . . . . . 20
3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21 3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21
3.1.3. Distribution use case . . . . . . . . . . . . . . . . 22 3.1.2.1. Control of the Generated Power . . . . . . . . . 21
3.1.2.2. Control of the Generation Infrastructure . . . . 22
3.1.3. Distribution use case . . . . . . . . . . . . . . . . 27
3.1.3.1. Fault Location Isolation and Service Restoration 3.1.3.1. Fault Location Isolation and Service Restoration
(FLISR) . . . . . . . . . . . . . . . . . . . . . 22 (FLISR) . . . . . . . . . . . . . . . . . . . . . 27
3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 23 3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 28
3.2.1. Security Current Practices and Limitations . . . . . 23 3.2.1. Security Current Practices and Limitations . . . . . 28
3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 25 3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 30
3.3.1. Migration to Packet-Switched Network . . . . . . . . 25 3.3.1. Migration to Packet-Switched Network . . . . . . . . 31
3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 26 3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 31
3.3.2.1. General Telecommunications Requirements . . . . . 26 3.3.2.1. General Telecommunications Requirements . . . . . 31
3.3.2.2. Specific Network topologies of Smart Grid 3.3.2.2. Specific Network topologies of Smart Grid
Applications . . . . . . . . . . . . . . . . . . 27 Applications . . . . . . . . . . . . . . . . . . 32
3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 28 3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 33
3.3.3. Security Trends in Utility Networks . . . . . . . . . 29 3.3.3. Security Trends in Utility Networks . . . . . . . . . 34
3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 31 3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 36
4. Building Automation Systems . . . . . . . . . . . . . . . . . 31 4. Building Automation Systems . . . . . . . . . . . . . . . . . 36
4.1. Use Case Description . . . . . . . . . . . . . . . . . . 31 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 36
4.2. Building Automation Systems Today . . . . . . . . . . . . 31 4.2. Building Automation Systems Today . . . . . . . . . . . . 37
4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 32 4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 37
4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 33 4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 38
4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 35 4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 40
4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 35 4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 40
4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 35 4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 40
4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 36 4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 41
4.2.4. Security Considerations . . . . . . . . . . . . . . . 36 4.2.4. Security Considerations . . . . . . . . . . . . . . . 41
4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 41
4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 37 5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 42
5.1. Use Case Description . . . . . . . . . . . . . . . . . . 37 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 42
5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 38 5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 43
5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 38 5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 43
5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 39 5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 44
5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 39 5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 44
5.3.1. Unified Wireless Network and Management . . . . . . . 39 5.3.1. Unified Wireless Network and Management . . . . . . . 44
5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 41 5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 46
5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 42 5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 47
5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 42 5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 47
5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 43 5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 48
5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 44 5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 49
5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 44 5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 49
6. Cellular Radio . . . . . . . . . . . . . . . . . . . . . . . 44 6. Cellular Radio . . . . . . . . . . . . . . . . . . . . . . . 49
6.1. Use Case Description . . . . . . . . . . . . . . . . . . 44 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 49
6.1.1. Network Architecture . . . . . . . . . . . . . . . . 44 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 49
6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 45 6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 50
6.1.3. Time Synchronization Constraints . . . . . . . . . . 46 6.1.3. Time Synchronization Constraints . . . . . . . . . . 51
6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 48 6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 53
6.1.5. Security Considerations . . . . . . . . . . . . . . . 48 6.1.5. Security Considerations . . . . . . . . . . . . . . . 53
6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 49 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 54
6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 49 6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 54
6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 49 6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 54
6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 50 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 55
6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 52 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 57
7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 52 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 57
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 52 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 57
7.2. Industrial M2M Communication Today . . . . . . . . . . . 53 7.2. Industrial M2M Communication Today . . . . . . . . . . . 58
7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 54 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 59
7.2.2. Stream Creation and Destruction . . . . . . . . . . . 55 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 60
7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 55 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 60
7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 55 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 60
8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 55 8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 60
9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 56 9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 61
9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 57 9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 62
9.2. Internet-based Applications . . . . . . . . . . . . . . . 57 9.2. Internet-based Applications . . . . . . . . . . . . . . . 62
9.2.1. Use Case Description . . . . . . . . . . . . . . . . 57 9.2.1. Use Case Description . . . . . . . . . . . . . . . . 62
9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 58 9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 63
9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 58 9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 63
9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 58 9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 63
9.2.2. Internet-Based Applications Today . . . . . . . . . . 58 9.2.2. Internet-Based Applications Today . . . . . . . . . . 63
9.2.3. Internet-Based Applications Future . . . . . . . . . 58 9.2.3. Internet-Based Applications Future . . . . . . . . . 63
9.2.4. Internet-Based Applications Asks . . . . . . . . . . 58 9.2.4. Internet-Based Applications Asks . . . . . . . . . . 63
9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 59 9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 64
9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 59 9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 64
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 60 10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 65
10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 60 10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 65
10.3. Building Automation Systems . . . . . . . . . . . . . . 60 10.3. Building Automation Systems . . . . . . . . . . . . . . 65
10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 60 10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 65
10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 61 10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 66
10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 61 10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 66
10.7. Internet Applications and CoMP . . . . . . . . . . . . . 61 10.7. Internet Applications and CoMP . . . . . . . . . . . . . 66
11. Informative References . . . . . . . . . . . . . . . . . . . 61 10.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 11. Informative References . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
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 20, line 25 skipping to change at page 20, line 25
| Bandwidth | 100 Kbps | | Bandwidth | 100 Kbps |
| Availability | 99.9999 | | Availability | 99.9999 |
| precise timing | Yes | | precise timing | Yes |
| required | | | required | |
| Recovery time on | less than 50ms - hitless | | Recovery time on | less than 50ms - hitless |
| Node failure | | | Node failure | |
| performance | Yes, Mandatory | | performance | Yes, Mandatory |
| management | | | management | |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 1% | | Packet loss | 1% |
| Consecutive Packet | At least 1 packet per application cycle |
| Loss | must be received. |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
Table 7: WAMS Special Communication Requirements Table 7: WAMS Special Communication Requirements
3.1.1.4. IEC 61850 WAN engineering guidelines requirement 3.1.1.4. IEC 61850 WAN engineering guidelines requirement
classification classification
The IEC (International Electrotechnical Commission) has recently The IEC (International Electrotechnical Commission) has recently
published a Technical Report which offers guidelines on how to define published a Technical Report which offers guidelines on how to define
and deploy Wide Area Networks for the interconnections of electric and deploy Wide Area Networks for the interconnections of electric
skipping to change at page 21, line 31 skipping to change at page 21, line 31
| | 10-6 | 10-4 | | | | | 10-6 | 10-4 | | |
| Recovery delay | Zero | 50 ms | 5 s | 50 s | | Recovery delay | Zero | 50 ms | 5 s | 50 s |
| Cyber security | extremely | High | Medium | Medium | | Cyber security | extremely | High | Medium | Medium |
| | high | | | | | | high | | | |
+----------------+------------+------------+------------+-----------+ +----------------+------------+------------+------------+-----------+
Table 8: 61850-90-12 Communication Requirements; Courtesy of IEC Table 8: 61850-90-12 Communication Requirements; Courtesy of IEC
3.1.2. Generation Use Case 3.1.2. Generation Use Case
The electrical power generation frequency should be maintained within Energy generation systems are complex infrastructures that require
a very narrow band. Deviations from the acceptable frequency range control of both the generated power and the generation
are detected and the required signals are sent to the power plants infrastructure.
for frequency regulation.
Automatic generation control (AGC) is a system for adjusting the 3.1.2.1. Control of the Generated Power
The electrical power generation frequency must be maintained within a
very narrow band. Deviations from the acceptable frequency range are
detected and the required signals are sent to the power plants for
frequency regulation.
Automatic Generation Control (AGC) is a system for adjusting the
power output of generators at different power plants, in response to power output of generators at different power plants, in response to
changes in the load. changes in the load.
+---------------------------------------------------+---------------+ +---------------------------------------------------+---------------+
| FCAG (Frequency Control Automatic Generation) | Attribute | | FCAG (Frequency Control Automatic Generation) | Attribute |
| Requirement | | | Requirement | |
+---------------------------------------------------+---------------+ +---------------------------------------------------+---------------+
| One way maximum delay | 500 ms | | One way maximum delay | 500 ms |
| Asymetric delay Required | No | | Asymetric delay Required | No |
| Maximum jitter | Not critical | | Maximum jitter | Not critical |
skipping to change at page 22, line 26 skipping to change at page 22, line 26
| precise timing required | Yes | | precise timing required | Yes |
| Recovery time on Node failure | N/A | | Recovery time on Node failure | N/A |
| performance management | Yes, | | performance management | Yes, |
| | Mandatory | | | Mandatory |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 1% | | Packet loss | 1% |
+---------------------------------------------------+---------------+ +---------------------------------------------------+---------------+
Table 9: FCAG Communication Requirements Table 9: FCAG Communication Requirements
3.1.2.2. Control of the Generation Infrastructure
The control of the generation infrastructure combines requirements
from industrial automation systems and energy generation systems. In
this section we present the use case of the control of the generation
infrastructure of a wind turbine.
|
|
| +-----------------+
| | +----+ |
| | |WTRM| WGEN |
WROT x==|===| | |
| | +----+ WCNV|
| |WNAC |
| +---+---WYAW---+--+
| | |
| | | +----+
|WTRF | |WMET|
| | | |
Wind Turbine | +--+-+
Controller | |
WTUR | | |
WREP | | |
WSLG | | |
WALG | WTOW | |
Figure 1: Wind Turbine Control Network
Figure 1 presents the subsystems that operate a wind turbine. These
subsystems include
o WROT (Rotor Control)
o WNAC (Nacelle Control) (nacelle: housing containing the generator)
o WTRM (Transmission Control)
o WGEN (Generator)
o WYAW (Yaw Controller) (of the tower head)
o WCNV (In-Turbine Power Converter)
o WMET (External Meteorological Station providing real time
information to the controllers of the tower)
Traffic characteristics relevant for the network planning and
dimensioning process in a wind turbine scenario are listed below.
The values in this section are based mainly on the relevant
references [Ahm14] and [Spe09]. Each logical node (Figure 1) is a
part of the metering network and produces analog measurements and
status information which must comply with their respective data rate
constraints.
+-----------+--------+--------+-------------+---------+-------------+
| Subsystem | Sensor | Analog | Data Rate | Status | Data rate |
| | Count | Sample | (bytes/sec) | Sample | (bytes/sec) |
| | | Count | | Count | |
+-----------+--------+--------+-------------+---------+-------------+
| WROT | 14 | 9 | 642 | 5 | 10 |
| WTRM | 18 | 10 | 2828 | 8 | 16 |
| WGEN | 14 | 12 | 73764 | 2 | 4 |
| WCNV | 14 | 12 | 74060 | 2 | 4 |
| WTRF | 12 | 5 | 73740 | 2 | 4 |
| WNAC | 12 | 9 | 112 | 3 | 6 |
| WYAW | 7 | 8 | 220 | 4 | 8 |
| WTOW | 4 | 1 | 8 | 3 | 6 |
| WMET | 7 | 7 | 228 | - | - |
+-----------+--------+--------+-------------+---------+-------------+
Table 10: Wind Turbine Data Rate Constraints
Quality of Service (QoS) constraints for different services are
presented in Table 11. These constraints are defined by IEEE 1646
standard [IEEE1646] and IEC 61400 standard [IEC61400].
+---------------------+---------+-------------+---------------------+
| Service | Latency | Reliability | Packet Loss Rate |
+---------------------+---------+-------------+---------------------+
| Analogue measure | 16 ms | 99.99% | < 10-6 |
| Status information | 16 ms | 99.99% | < 10-6 |
| Protection traffic | 4 ms | 100.00% | < 10-9 |
| Reporting and | 1 s | 99.99% | < 10-6 |
| logging | | | |
| Video surveillance | 1 s | 99.00% | No specific |
| | | | requirement |
| Internet connection | 60 min | 99.00% | No specific |
| | | | requirement |
| Control traffic | 16 ms | 100.00% | < 10-9 |
| Data polling | 16 ms | 99.99% | < 10-6 |
+---------------------+---------+-------------+---------------------+
Table 11: Wind Turbine Reliability and Latency Constraints
3.1.2.2.1. Intra-Domain Network Considerations
A wind turbine is composed of a large set of subsystems including
sensors and actuators which require time-critical operation. The
reliability and latency constraints of these different subsystems is
shown in Table 11. These subsystems are connected to an intra-domain
network which is used to monitor and control the operation of the
turbine and connect it to the SCADA subsystems. The different
components are interconnected using fiber optics, industrial buses,
industrial Ethernet, EtherCat, or a combination of them. Industrial
signaling and control protocols such as Modbus, Profibus, Profinet
and EtherCat are used directly on top of the Layer 2 transport or
encapsulated over TCP/IP.
The Data collected from the sensors and condition monitoring systems
is multiplexed onto fiber cables for transmission to the base of the
tower, and to remote control centers. The turbine controller
continuously monitors the condition of the wind turbine and collects
statistics on its operation. This controller also manages a large
number of switches, hydraulic pumps, valves, and motors within the
wind turbine.
There is usually a controller both at the bottom of the tower and in
the nacelle. The communication between these two controllers usually
takes place using fiber optics instead of copper links. Sometimes, a
third controller is installed in the hub of the rotor and manages the
pitch of the blades. That unit usually communicates with the nacelle
unit using serial communications.
3.1.2.2.2. Inter-Domain network considerations
A remote control center belonging to a grid operator regulates the
power output, enables remote actuation, and monitors the health of
one or more wind parks in tandem. It connects to the local control
center in a wind park over the Internet (Figure 2) via firewalls at
both ends. The AS path between the local control center and the Wind
Park typically involves several ISPs at different tiers. For
example, a remote control center in Denmark can regulate a wind park
in Greece over the normal public AS path between the two locations.
The remote control center is part of the SCADA system, setting the
desired power output to the wind park and reading back the result
once the new power output level has been set. Traffic between the
remote control center and the wind park typically consists of
protocols like IEC 60870-5-104 [IEC-60870-5-104], OPC XML-DA
[OPCXML], Modbus [MODBUS], and SNMP [RFC3411]. Currently, traffic
flows between the wind farm and the remote control center are best
effort. QoS requirements are not strict, so no SLAs or service
provisioning mechanisms (e.g., VPN) are employed. In case of events
like equipment failure, tolerance for alarm delay is on the order of
minutes, due to redundant systems already in place.
+--------------+
| |
| |
| Wind Park #1 +----+
| | | XXXXXX
| | | X XXXXXXXX +----------------+
+--------------+ | XXXX X XXXXX | |
+---+ XXX | Remote Control |
XXX Internet +----+ Center |
+----+X XXX | |
+--------------+ | XXXXXXX XX | |
| | | XX XXXXXXX +----------------+
| | | XXXXX
| Wind Park #2 +----+
| |
| |
+--------------+
Figure 2: Wind Turbine Control via Internet
We expect future use cases which require bounded latency, bounded
jitter and extraordinary low packet loss for inter-domain traffic
flows due to the softwarization and virtualization of core wind farm
equipment (e.g. switches, firewalls and SCADA server components).
These factors will create opportunities for service providers to
install new services and dynamically manage them from remote
locations. For example, to enable fail-over of a local SCADA server,
a SCADA server in another wind farm site (under the administrative
control of the same operator) could be utilized temporarily
(Figure 3). In that case local traffic would be forwarded to the
remote SCADA server and existing intra-domain QoS and timing
parameters would have to be met for inter-domain traffic flows.
+--------------+
| |
| |
| Wind Park #1 +----+
| | | XXXXXX
| | | X XXXXXXXX +----------------+
+--------------+ | XXXX XXXXX | |
+---+ Operator XXX | Remote Control |
XXX Administered +----+ Center |
+----+X WAN XXX | |
+--------------+ | XXXXXXX XX | |
| | | XX XXXXXXX +----------------+
| | | XXXXX
| Wind Park #2 +----+
| |
| |
+--------------+
Figure 3: Wind Turbine Control via Operator Administered WAN
3.1.3. Distribution use case 3.1.3. Distribution use case
3.1.3.1. Fault Location Isolation and Service Restoration (FLISR) 3.1.3.1. Fault Location Isolation and Service Restoration (FLISR)
Fault Location, Isolation, and Service Restoration (FLISR) refers to Fault Location, Isolation, and Service Restoration (FLISR) refers to
the ability to automatically locate the fault, isolate the fault, and the ability to automatically locate the fault, isolate the fault, and
restore service in the distribution network. This will likely be the restore service in the distribution network. This will likely be the
first widespread application of distributed intelligence in the grid. first widespread application of distributed intelligence in the grid.
Static power switch status (open/closed) in the network dictates the Static power switch status (open/closed) in the network dictates the
skipping to change at page 23, line 27 skipping to change at page 28, line 27
| precise timing | Yes | | precise timing | Yes |
| required | | | required | |
| Recovery time on | Depends on customer impact | | Recovery time on | Depends on customer impact |
| Node failure | | | Node failure | |
| performance | Yes, Mandatory | | performance | Yes, Mandatory |
| management | | | management | |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 0.1% | | Packet loss | 0.1% |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
Table 10: FLISR Communication Requirements Table 12: FLISR Communication Requirements
3.2. Electrical Utilities Today 3.2. Electrical Utilities Today
Many utilities still rely on complex environments formed of multiple Many utilities still rely on complex environments formed of multiple
application-specific proprietary networks, including TDM networks. application-specific proprietary networks, including TDM networks.
In this kind of environment there is no mixing of OT and IT In this kind of environment there is no mixing of OT and IT
applications on the same network, and information is siloed between applications on the same network, and information is siloed between
operational areas. operational areas.
skipping to change at page 25, line 37 skipping to change at page 30, line 37
The key to modernizing grid telecommunications is to provide a The key to modernizing grid telecommunications is to provide a
common, adaptable, multi-service network infrastructure for the common, adaptable, multi-service network infrastructure for the
entire utility organization. Such a network serves as the platform entire utility organization. Such a network serves as the platform
for current capabilities while enabling future expansion of the for current capabilities while enabling future expansion of the
network to accommodate new applications and services. network to accommodate new applications and services.
To meet this diverse set of requirements, both today and in the To meet this diverse set of requirements, both today and in the
future, the next generation utility telecommunnications network will future, the next generation utility telecommunnications network will
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 across disparate networks development, facilitating interoperability and device management
and devices, as it has been already demonstrated in many mission- across disparate networks and devices, as it has been already
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.
We expect cloud-based SCADA systems to control and monitor the
critical and non-critical subsystems of generation systems, for
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
packet connectivity for communicating information and control signals packet connectivity for communicating information and control signals
across the utility's Wide Area Network (WAN), made possible by across the utility's Wide Area Network (WAN), made possible by
technologies such as multiprotocol label switching (MPLS). The data technologies such as multiprotocol label switching (MPLS). The data
that traverses the utility WAN includes: that traverses the utility WAN includes:
skipping to change at page 31, line 13 skipping to change at page 36, line 13
detection and mitigation. detection and mitigation.
3.4. Electrical Utilities Asks 3.4. Electrical Utilities Asks
o Mixed L2 and L3 topologies o Mixed L2 and L3 topologies
o Deterministic behavior o Deterministic behavior
o Bounded latency and jitter o Bounded latency and jitter
o Tight feedback intervals
o High availability, low recovery time o High availability, low recovery time
o Redundancy, low packet loss o Redundancy, low packet loss
o Precise timing o Precise timing
o Centralized computing of deterministic paths o Centralized computing of deterministic paths
o Distributed configuration may also be useful o Distributed configuration may also be useful
skipping to change at page 32, line 4 skipping to change at page 37, line 6
o Stores the measured data. o Stores the measured data.
o Provides the measured data to BAS systems and operators. o Provides the measured data to BAS systems and operators.
o Generates alarms for abnormal state of devices. o Generates alarms for abnormal state of devices.
o Controls devices (e.g. turn off room lights at 10:00 PM). o Controls devices (e.g. turn off room lights at 10:00 PM).
4.2. Building Automation Systems Today 4.2. Building Automation Systems Today
4.2.1. BAS Architecture 4.2.1. BAS Architecture
A typical BAS architecture of today is shown in Figure 1. A typical BAS architecture of today is shown in Figure 4.
+----------------------------+ +----------------------------+
| | | |
| BMS HMI | | BMS HMI |
| | | | | | | |
| +----------------------+ | | +----------------------+ |
| | Management Network | | | | Management Network | |
| +----------------------+ | | +----------------------+ |
| | | | | | | |
| LC LC | | LC LC |
skipping to change at page 32, line 30 skipping to change at page 37, line 33
| +----------------------+ | | +----------------------+ |
| | | | | | | | | | | |
| Dev Dev Dev Dev | | Dev Dev Dev Dev |
| | | |
+----------------------------+ +----------------------------+
BMS := Building Management Server BMS := Building Management Server
HMI := Human Machine Interface HMI := Human Machine Interface
LC := Local Controller LC := Local Controller
Figure 1: BAS architecture Figure 4: BAS architecture
There are typically two layers of network in a BAS. The upper one is There are typically two layers of network in a BAS. The upper one is
called the Management Network and the lower one is called the Field called the Management Network and the lower one is called the Field
Network. In management networks an IP-based communication protocol Network. In management networks an IP-based communication protocol
is used, while in field networks non-IP based communication protocols is used, while in field networks non-IP based communication protocols
("field protocols") are mainly used. Field networks have specific ("field protocols") are mainly used. Field networks have specific
timing requirements, whereas management networks can be best-effort. timing requirements, whereas management networks can be best-effort.
A Human Machine Interface (HMI) is typically a desktop PC used by A Human Machine Interface (HMI) is typically a desktop PC used by
operators to monitor and display device states, send device control operators to monitor and display device states, send device control
skipping to change at page 33, line 26 skipping to change at page 38, line 29
There are many field protocols used today; some are standards-based There are many field protocols used today; some are standards-based
and others are proprietary (see standards [lontalk], [modbus], and others are proprietary (see standards [lontalk], [modbus],
[profibus] and [flnet]). The result is that BASs have multiple MAC/ [profibus] and [flnet]). The result is that BASs have multiple MAC/
PHY modules and interfaces. This makes BASs more expensive, slower PHY modules and interfaces. This makes BASs more expensive, slower
to develop, and can result in "vendor lock-in" with multiple types of to develop, and can result in "vendor lock-in" with multiple types of
management applications. management applications.
4.2.2. BAS Deployment Model 4.2.2. BAS Deployment Model
An example BAS for medium or large buildings is shown in Figure 2. An example BAS for medium or large buildings is shown in Figure 5.
The physical layout spans multiple floors, and there is a monitoring The physical layout spans multiple floors, and there is a monitoring
room where the BAS management entities are located. Each floor will room where the BAS management entities are located. Each floor will
have one or more LCs depending upon the number of devices connected have one or more LCs depending upon the number of devices connected
to the field network. to the field network.
+--------------------------------------------------+ +--------------------------------------------------+
| Floor 3 | | Floor 3 |
| +----LC~~~~+~~~~~+~~~~~+ | | +----LC~~~~+~~~~~+~~~~~+ |
| | | | | | | | | | | |
| | Dev Dev Dev | | | Dev Dev Dev |
skipping to change at page 34, line 28 skipping to change at page 39, line 28
| | Floor 1 | | | Floor 1 |
| +----LC~~~~+~~~~~+~~~~~+ +-----------------| | +----LC~~~~+~~~~~+~~~~~+ +-----------------|
| | | | | | Monitoring Room | | | | | | | Monitoring Room |
| | Dev Dev Dev | | | | Dev Dev Dev | |
| | | BMS HMI | | | | BMS HMI |
| | Management Network | | | | | | Management Network | | | |
| +--------------------------------+-----+ | | +--------------------------------+-----+ |
| | | | | |
+--------------------------------------------------+ +--------------------------------------------------+
Figure 2: BAS Deployment model for Medium/Large Buildings Figure 5: BAS Deployment model for Medium/Large Buildings
Each LC is connected to the monitoring room via the Management Each LC is connected to the monitoring room via the Management
network, and the management functions are performed within the network, and the management functions are performed within the
building. In most cases, fast Ethernet (e.g. 100BASE-T) is used for building. In most cases, fast Ethernet (e.g. 100BASE-T) is used for
the management network. Since the management network is non- the management network. Since the management network is non-
realtime, use of Ethernet without quality of service is sufficient realtime, use of Ethernet without quality of service is sufficient
for today's deployment. for today's deployment.
In the field network a variety of physical interfaces such as RS232C In the field network a variety of physical interfaces such as RS232C
and RS485 are used, which have specific timing requirements. Thus if and RS485 are used, which have specific timing requirements. Thus if
a field network is to be replaced with an Ethernet or wireless a field network is to be replaced with an Ethernet or wireless
network, such networks must support time-critical deterministic network, such networks must support time-critical deterministic
flows. flows.
In Figure 3, another deployment model is presented in which the In Figure 6, another deployment model is presented in which the
management system is hosted remotely. This is becoming popular for management system is hosted remotely. This is becoming popular for
small office and residential buildings in which a standalone small office and residential buildings in which a standalone
monitoring system is not cost-effective. monitoring system is not cost-effective.
+---------------+ +---------------+
| Remote Center | | Remote Center |
| | | |
| BMS HMI | | BMS HMI |
+------------------------------------+ | | | | +------------------------------------+ | | | |
| Floor 2 | | +---+---+ | | Floor 2 | | +---+---+ |
skipping to change at page 35, line 26 skipping to change at page 40, line 26
| | Floor 1 | | | | Floor 1 | |
| +----LC~~~~+~~~~~+ | | | +----LC~~~~+~~~~~+ | |
| | | | | | | | | | | |
| | Dev Dev | | | | Dev Dev | |
| | | | | | | |
| | Management Network | WAN | | | Management Network | WAN |
| +------------------------Router-------------+ | +------------------------Router-------------+
| | | |
+------------------------------------+ +------------------------------------+
Figure 3: Deployment model for Small Buildings Figure 6: Deployment model for Small Buildings
Some interoperability is possible today in the Management Network, Some interoperability is possible today in the Management Network,
but not in today's field networks due to their non-IP-based design. but not in today's field networks due to their non-IP-based design.
4.2.3. Use Cases for Field Networks 4.2.3. Use Cases for Field Networks
Below are use cases for Environmental Monitoring, Fire Detection, and Below are use cases for Environmental Monitoring, Fire Detection, and
Feedback Control, and their implications for field network Feedback Control, and their implications for field network
performance. performance.
skipping to change at page 39, line 41 skipping to change at page 44, line 41
6TiSCH is not yet fully specified, so it cannot be used in today's 6TiSCH is not yet fully specified, so it cannot be used in today's
applications. applications.
5.3. Wireless Industrial Future 5.3. Wireless Industrial Future
5.3.1. Unified Wireless Network and Management 5.3.1. Unified Wireless Network and Management
We expect DetNet and 6TiSCH together to enable converged transport of We expect DetNet and 6TiSCH together to enable converged transport of
deterministic and best-effort traffic flows between real-time deterministic and best-effort traffic flows between real-time
industrial devices and wide area networks via IP routing. A high industrial devices and wide area networks via IP routing. A high
level view of a basic such network is shown in Figure 4. level view of a basic such network is shown in Figure 7.
---+-------- ............ ------------ ---+-------- ............ ------------
| External Network | | External Network |
| +-----+ | +-----+
+-----+ | NME | +-----+ | NME |
| | LLN Border | | | | LLN Border | |
| | router +-----+ | | router +-----+
+-----+ +-----+
o o o o o o
o o o o o o o o
o o LLN o o o o o LLN o o o
o o o o o o o o
o o
Figure 4: Basic 6TiSCH Network Figure 7: Basic 6TiSCH Network
Figure 5 shows a backbone router federating multiple synchronized Figure 8 shows a backbone router federating multiple synchronized
6TiSCH subnets into a single subnet connected to the external 6TiSCH subnets into a single subnet connected to the external
network. network.
---+-------- ............ ------------ ---+-------- ............ ------------
| External Network | | External Network |
| +-----+ | +-----+
| +-----+ | NME | | +-----+ | NME |
+-----+ | +-----+ | | +-----+ | +-----+ | |
| | Router | | PCE | +-----+ | | Router | | PCE | +-----+
| | +--| | | | +--| |
skipping to change at page 40, line 45 skipping to change at page 45, line 45
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone | | Backbone | | Backbone | | Backbone
o | | router | | router | | router o | | router | | router | | router
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o
o o o LLN o o o o o o o LLN o o o o
o o o o o o o o o o o o o o o o o o o o o o o o
Figure 5: Extended 6TiSCH Network Figure 8: Extended 6TiSCH Network
The backbone router must ensure end-to-end deterministic behavior The backbone router must ensure end-to-end deterministic behavior
between the LLN and the backbone. We would like to see this between the LLN and the backbone. We would like to see this
accomplished in conformance with the work done in accomplished in conformance with the work done in
[I-D.finn-detnet-architecture] with respect to Layer-3 aspects of [I-D.finn-detnet-architecture] with respect to Layer-3 aspects of
deterministic networks that span multiple Layer-2 domains. deterministic networks that span multiple Layer-2 domains.
The PCE must compute a deterministic path end-to-end across the TSCH The PCE must compute a deterministic path end-to-end across the TSCH
network and IEEE802.1 TSN Ethernet backbone, and DetNet protocols are network and IEEE802.1 TSN Ethernet backbone, and DetNet protocols are
expected to enable end-to-end deterministic forwarding. expected to enable end-to-end deterministic forwarding.
skipping to change at page 41, line 28 skipping to change at page 46, line 28
+--|--+ +--|--+ +--|--+ +--|--+
| | | Backbone | | | Backbone | | | Backbone | | | Backbone
o | | | router | | | router o | | | router | | | router
+--/--+ +--|--+ +--/--+ +--|--+
o / o o---o----/ o o / o o---o----/ o
o o---o--/ o o o o o o o---o--/ o o o o o
o \ / o o LLN o o \ / o o LLN o
o v <---- Replication o v <---- Replication
o o
Figure 6: 6TiSCH Network with PRE Figure 9: 6TiSCH Network with PRE
5.3.1.1. PCE and 6TiSCH ARQ Retries 5.3.1.1. PCE and 6TiSCH ARQ Retries
Note: The possible use of ARQ techniques in DetNet is currently Note: The possible use of ARQ techniques in DetNet is currently
considered a possible design alternative. considered a possible design alternative.
6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism 6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism
to provide higher reliability of packet delivery. ARQ is related to to provide higher reliability of packet delivery. ARQ is related to
packet replication and elimination because there are two independent packet replication and elimination because there are two independent
paths for packets to arrive at the destination, and if an expected paths for packets to arrive at the destination, and if an expected
packed does not arrive on one path then it checks for the packet on packed does not arrive on one path then it checks for the packet on
the second path. the second path.
Although to date this mechanism is only used by wireless networks, Although to date this mechanism is only used by wireless networks,
this may be a technique that would be appropriate for DetNet and so this may be a technique that would be appropriate for DetNet and so
aspects of the enabling protocol could be co-developed. aspects of the enabling protocol could be co-developed.
For example, in Figure 6, a Track is laid out from a field device in For example, in Figure 9, a Track is laid out from a field device in
a 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN a 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN
backbone. backbone.
In ARQ the Replication function in the field device sends a copy of In ARQ the Replication function in the field device sends a copy of
each packet over two different branches, and the PCE schedules each each packet over two different branches, and the PCE schedules each
hop of both branches so that the two copies arrive in due time at the hop of both branches so that the two copies arrive in due time at the
gateway. In case of a loss on one branch, hopefully the other copy gateway. In case of a loss on one branch, hopefully the other copy
of the packet still arrives within the allocated time. If two copies of the packet still arrives within the allocated time. If two copies
make it to the IoT gateway, the Elimination function in the gateway make it to the IoT gateway, the Elimination function in the gateway
ignores the extra packet and presents only one copy to upper layers. ignores the extra packet and presents only one copy to upper layers.
skipping to change at page 44, line 40 skipping to change at page 49, line 40
6.1. Use Case Description 6.1. Use Case Description
This use case describes the application of deterministic networking This use case describes the application of deterministic networking
in the context of cellular telecom transport networks. Important in the context of cellular telecom transport networks. Important
elements include time synchronization, clock distribution, and ways elements include time synchronization, clock distribution, and ways
of establishing time-sensitive streams for both Layer-2 and Layer-3 of establishing time-sensitive streams for both Layer-2 and Layer-3
user plane traffic. user plane traffic.
6.1.1. Network Architecture 6.1.1. Network Architecture
Figure 7 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" and "Midhaul" network
segments. The "Fronthaul" is the network connecting base stations segments. The "Fronthaul" is the network connecting base stations
(baseband processing units) to the remote radio heads (antennas). (baseband processing units) to the remote radio heads (antennas).
The "Midhaul" is the network inter-connecting base stations (or small The "Midhaul" is the network inter-connecting base stations (or small
cell sites). cell sites).
In Figure 7 "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 |
( ` .Haul ) +---+ ( ` . ) ) | netw | ( ` .Haul ) +---+ ( ` . ) ) | netw |
/`--(___.-' \ `--(___.-' +------+ /`--(___.-' \ `--(___.-' +------+
skipping to change at page 45, line 23 skipping to change at page 50, line 23
Y_/ _( Mid`. \ Y_/ _( Mid`. \
( Haul ) \ ( Haul ) \
( ` . ) ) \ ( ` . ) ) \
`--(___.-'\_____+---+ (small cell sites) `--(___.-'\_____+---+ (small cell sites)
\ |SCe|__Y \ |SCe|__Y
+---+ +---+ +---+ +---+
Y__|eNB|__Y Y__|eNB|__Y
+---+ +---+
Y_/ \_Y ("local" radios) Y_/ \_Y ("local" radios)
Figure 7: Generic 3GPP-based Cellular Network Architecture Figure 10: Generic 3GPP-based Cellular Network Architecture
6.1.2. Delay Constraints 6.1.2. Delay Constraints
The available processing time for Fronthaul networking overhead is The available processing time for Fronthaul networking overhead is
limited to the available time after the baseband processing of the limited to the available time after the baseband processing of the
radio frame has completed. For example in Long Term Evolution (LTE) radio frame has completed. For example in Long Term Evolution (LTE)
radio, processing of a radio frame is allocated 3ms but typically the radio, processing of a radio frame is allocated 3ms but typically the
processing uses most of it, allowing only a small fraction to be used processing uses most of it, allowing only a small fraction to be used
by the Fronthaul network (e.g. up to 250us one-way delay, though the by the Fronthaul network (e.g. up to 250us one-way delay, though the
existing spec ([NGMN-fronth]) supports delay only up to 100us). This existing spec ([NGMN-fronth]) supports delay only up to 100us). This
skipping to change at page 52, line 37 skipping to change at page 57, line 37
Industrial Automation in general refers to automation of Industrial Automation in general refers to automation of
manufacturing, quality control and material processing. In this manufacturing, quality control and material processing. In this
"machine to machine" (M2M) use case we consider machine units in a "machine to machine" (M2M) use case we consider machine units in a
plant floor which periodically exchange data with upstream or plant floor which periodically exchange data with upstream or
downstream machine modules and/or a supervisory controller within a downstream machine modules and/or a supervisory controller within a
local area network. local area network.
The actors of M2M communication are Programmable Logic Controllers The actors of M2M communication are Programmable Logic Controllers
(PLCs). Communication between PLCs and between PLCs and the (PLCs). Communication between PLCs and between PLCs and the
supervisory PLC (S-PLC) is achieved via critical control/data streams supervisory PLC (S-PLC) is achieved via critical control/data streams
Figure 8. Figure 11.
S (Sensor) S (Sensor)
\ +-----+ \ +-----+
PLC__ \.--. .--. ---| MES | PLC__ \.--. .--. ---| MES |
\_( `. _( `./ +-----+ \_( `. _( `./ +-----+
A------( Local )-------------( L2 ) A------( Local )-------------( L2 )
( Net ) ( Net ) +-------+ ( Net ) ( Net ) +-------+
/`--(___.-' `--(___.-' ----| S-PLC | /`--(___.-' `--(___.-' ----| S-PLC |
S_/ / PLC .--. / +-------+ S_/ / PLC .--. / +-------+
A_/ \_( `. A_/ \_( `.
(Actuator) ( Local ) (Actuator) ( Local )
( Net ) ( Net )
/`--(___.-'\ /`--(___.-'\
/ \ A / \ A
S A S A
Figure 8: Current Generic Industrial M2M Network Architecture Figure 11: Current Generic Industrial M2M Network Architecture
This use case focuses on PLC-related communications; communication to This use case focuses on PLC-related communications; communication to
Manufacturing-Execution-Systems (MESs) are not addressed. Manufacturing-Execution-Systems (MESs) are not addressed.
This use case covers only critical control/data streams; non-critical This use case covers only critical control/data streams; non-critical
traffic between industrial automation applications (such as traffic between industrial automation applications (such as
communication of state, configuration, set-up, and database communication of state, configuration, set-up, and database
communication) are adequately served by currently available communication) are adequately served by currently available
prioritizing techniques. Such traffic can use up to 80% of the total prioritizing techniques. Such traffic can use up to 80% of the total
bandwidth required. There is also a subset of non-time-critical bandwidth required. There is also a subset of non-time-critical
skipping to change at page 61, line 23 skipping to change at page 66, line 23
10.7. Internet Applications and CoMP 10.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
The wind power generation use case has been extracted from the study
of Wind Farms conducted within the 5GPPP Virtuwind Project. The
project is funded by the European Union's Horizon 2020 research and
innovation programme under grant agreement No 671648 (VirtuWind).
11. Informative References 11. Informative References
[ACE] IETF, "Authentication and Authorization for Constrained [ACE] IETF, "Authentication and Authorization for Constrained
Environments", <https://datatracker.ietf.org/doc/charter- Environments", <https://datatracker.ietf.org/doc/charter-
ietf-ace/>. ietf-ace/>.
[Ahm14] Ahmed, M. and R. Kim, "Communication network architectures
for smart-wind power farms.", Energies, p. 3900-3921. ,
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",
<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>. <https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND [CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND
ENHANCEMENT", NGMN Alliance NGMN_RANEV_D3_CoMP_Evaluation_ ENHANCEMENT", NGMN Alliance NGMN_RANEV_D3_CoMP_Evaluation_
and_Enhancement_v2.0, March 2015, and_Enhancement_v2.0, March 2015,
skipping to change at page 62, line 25 skipping to change at page 67, line 35
<https://datatracker.ietf.org/doc/charter-ietf-dice/>. <https://datatracker.ietf.org/doc/charter-ietf-dice/>.
[EA12] Evans, P. and M. Annunziata, "Industrial Internet: Pushing [EA12] Evans, P. and M. Annunziata, "Industrial Internet: Pushing
the Boundaries of Minds and Machines", November 2012. the Boundaries of Minds and Machines", November 2012.
[ESPN_DC2] [ESPN_DC2]
Daley, D., "ESPN's DC2 Scales AVB Large", 2014, Daley, D., "ESPN's DC2 Scales AVB Large", 2014,
<http://sportsvideo.org/main/blog/2014/06/ <http://sportsvideo.org/main/blog/2014/06/
espns-dc2-scales-avb-large>. espns-dc2-scales-avb-large>.
[flnet] Japan Electrical Manufacturers' Association, "JEMA 1479 - [flnet] Japan Electrical Manufacturers Association, "JEMA 1479 -
English Edition", September 2012. English Edition", September 2012.
[Fronthaul] [Fronthaul]
Chen, D. and T. Mustala, "Ethernet Fronthaul Chen, D. and T. Mustala, "Ethernet Fronthaul
Considerations", IEEE 1904.3, February 2015, Considerations", IEEE 1904.3, February 2015,
<http://www.ieee1904.org/3/meeting_archive/2015/02/ <http://www.ieee1904.org/3/meeting_archive/2015/02/
tf3_1502_che n_1a.pdf>. tf3_1502_che n_1a.pdf>.
[HART] www.hartcomm.org, "Highway Addressable remote Transducer, [HART] www.hartcomm.org, "Highway Addressable remote Transducer,
a group of specifications for industrial process and a group of specifications for industrial process and
control devices administered by the HART Foundation". control devices administered by the HART Foundation".
[I-D.finn-detnet-architecture] [I-D.finn-detnet-architecture]
Finn, N., Thubert, P., and M. Teener, "Deterministic Finn, N. and P. Thubert, "Deterministic Networking
Networking Architecture", draft-finn-detnet- Architecture", draft-finn-detnet-architecture-08 (work in
architecture-04 (work in progress), March 2016. progress), August 2016.
[I-D.finn-detnet-problem-statement] [I-D.finn-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem Finn, N. and P. Thubert, "Deterministic Networking Problem
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.
skipping to change at page 63, line 29 skipping to change at page 68, line 39
progress), March 2016. progress), March 2016.
[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-09 (work in network", draft-ietf-mpls-residence-time-11 (work in
progress), April 2016. progress), July 2016.
[I-D.ietf-roll-rpl-industrial-applicability] [I-D.ietf-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-ietf-roll- applicability in industrial networks", draft-ietf-roll-
rpl-industrial-applicability-02 (work in progress), rpl-industrial-applicability-02 (work in progress),
October 2013. October 2013.
[I-D.ietf-tictoc-1588overmpls] [I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS Montini, "Transporting Timing messages over MPLS
skipping to change at page 64, line 15 skipping to change at page 69, line 25
[I-D.thubert-6lowpan-backbone-router] [I-D.thubert-6lowpan-backbone-router]
Thubert, P., "6LoWPAN Backbone Router", draft-thubert- Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
6lowpan-backbone-router-03 (work in progress), February 6lowpan-backbone-router-03 (work in progress), February
2013. 2013.
[I-D.wang-6tisch-6top-sublayer] [I-D.wang-6tisch-6top-sublayer]
Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
(6top)", draft-wang-6tisch-6top-sublayer-04 (work in (6top)", draft-wang-6tisch-6top-sublayer-04 (work in
progress), November 2015. progress), November 2015.
[IEC-60870-5-104]
International Electrotechnical Commission, "International
Standard IEC 60870-5-104: Network access for IEC
60870-5-101 using standard transport profiles", June 2006.
[IEC61400]
"International standard 61400-25: Communications for
monitoring and control of wind power plants", June 2013.
[IEC61850-90-12] [IEC61850-90-12]
TC57 WG10, IEC., "IEC 61850-90-12 TR: Communication TC57 WG10, IEC., "IEC 61850-90-12 TR: Communication
networks and systems for power utility automation - Part networks and systems for power utility automation - Part
90-12: Wide area network engineering guidelines", 2015. 90-12: Wide area network engineering guidelines", 2015.
[IEC62439-3:2012] [IEC62439-3:2012]
TC65, IEC., "IEC 62439-3: Industrial communication TC65, IEC., "IEC 62439-3: Industrial communication
networks - High availability automation networks - Part 3: networks - High availability automation networks - Part 3:
Parallel Redundancy Protocol (PRP) and High-availability Parallel Redundancy Protocol (PRP) and High-availability
Seamless Redundancy (HSR)", 2012. Seamless Redundancy (HSR)", 2012.
[IEEE1588] [IEEE1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008, 2008, IEEE Std 1588-2008, 2008,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/1588-2008.html>. standard/1588-2008.html>.
[IEEE1646]
"Communication Delivery Time Performance Requirements for
Electric Power Substation Automation", IEEE Standard
1646-2004 , Apr 2004.
[IEEE1722] [IEEE1722]
IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport
Protocol for Time Sensitive Applications in a Bridged Protocol for Time Sensitive Applications in a Bridged
Local Area Network", IEEE Std 1722-2011, 2011, Local Area Network", IEEE Std 1722-2011, 2011,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/1722-2011.html>. standard/1722-2011.html>.
[IEEE19043] [IEEE19043]
IEEE Standards Association, "IEEE 1904.3 TF", IEEE 1904.3, IEEE Standards Association, "IEEE 1904.3 TF", IEEE 1904.3,
2015, <http://www.ieee1904.org/3/tf3_home.shtml>. 2015, <http://www.ieee1904.org/3/tf3_home.shtml>.
skipping to change at page 66, line 35 skipping to change at page 72, line 13
MEF_22.1.1.pdf>. MEF_22.1.1.pdf>.
[METIS] METIS, "Scenarios, requirements and KPIs for 5G mobile and [METIS] METIS, "Scenarios, requirements and KPIs for 5G mobile and
wireless system", ICT-317669-METIS/D1.1 ICT- wireless system", ICT-317669-METIS/D1.1 ICT-
317669-METIS/D1.1, April 2013, <https://www.metis2020.com/ 317669-METIS/D1.1, April 2013, <https://www.metis2020.com/
wp-content/uploads/deliverables/METIS_D1.1_v1.pdf>. wp-content/uploads/deliverables/METIS_D1.1_v1.pdf>.
[modbus] Modbus Organization, "MODBUS APPLICATION PROTOCOL [modbus] Modbus Organization, "MODBUS APPLICATION PROTOCOL
SPECIFICATION V1.1b", December 2006. SPECIFICATION V1.1b", December 2006.
[MODBUS] Modbus Organization, Inc., "MODBUS Application Protocol
Specification", Apr 2012.
[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/NGMN_RANEV_D1_C-
RAN_Fronthaul_Requirements_v1.0.pdf>. RAN_Fronthaul_Requirements_v1.0.pdf>.
[OPCXML] OPC Foundation, "OPC XML-Data Access Specification", Dec
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>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 67, line 35 skipping to change at page 73, line 20
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc3393>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<http://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>. <http://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>. <http://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
skipping to change at page 69, line 17 skipping to change at page 75, line 5
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>. <http://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>. <http://www.rfc-editor.org/info/rfc7554>.
[Spe09] Sperotto, A., Sadre, R., Vliet, F., and A. Pras, "A First
Look into SCADA Network Traffic", IP Operations and
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>.
[STUDIO_IP] [STUDIO_IP]
Mace, G., "IP Networked Studio Infrastructure for Mace, G., "IP Networked Studio Infrastructure for
Synchronized & Real-Time Multimedia Transmissions", 2007, Synchronized & Real-Time Multimedia Transmissions", 2007,
<http://www.ieee802.org/1/files/public/docs2047/ <http://www.ieee802.org/1/files/public/docs2047/
avb-mace-ip-networked-studio-infrastructure-0107.pdf>. avb-mace-ip-networked-studio-infrastructure-0107.pdf>.
skipping to change at line 3260 skipping to change at page 79, line 4
Email: franz-josef.goetz@siemens.com Email: franz-josef.goetz@siemens.com
Juergen Schmitt Juergen Schmitt
Siemens Siemens
Gleiwitzerstr. 555 Gleiwitzerstr. 555
Nurnberg 90475 Nurnberg 90475
Germany Germany
Email: juergen.jues.schmitt@siemens.com Email: juergen.jues.schmitt@siemens.com
Xavier Vilajosana
Worldsensing
483 Arago
Barcelona, Catalonia 08013
Spain
Email: xvilajosana@worldsensing.com
Toktam Mahmoodi
King's College London
Strand, London WC2R 2LS
London, London WC2R 2LS
United Kingdom
Email: toktam.mahmoodi@kcl.ac.uk
Spiros Spirou
Intracom Telecom
19.7 km Markopoulou Ave.
Peania, Attiki 19002
Greece
Email: spis@intracom-telecom.com
Petra Vizarreta
Technical University of Munich, TUM
Maxvorstadt, ArcisstraBe 21
Munich, Germany 80333
Germany
Email: petra.vizarreta@lkn.ei.tum.de
 End of changes. 50 change blocks. 
121 lines changed or deleted 388 lines changed or added

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