draft-ietf-detnet-use-cases-02.txt   draft-ietf-detnet-use-cases-03.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: August 13, 2016 HARMAN Expires: August 19, 2016 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
February 10, 2016 February 16, 2016
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-02 draft-ietf-detnet-use-cases-03
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 20
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 August 13, 2016. This Internet-Draft will expire on August 19, 2016.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5 2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6 2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6
2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 6 2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 6
2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7 2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7
2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8 2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8
2.3. Additional Stream Requirements . . . . . . . . . . . . . 8 2.3. Additional Stream Requirements . . . . . . . . . . . . . 9
2.3.1. Deterministic Time to Establish Streaming . . . . . . 9 2.3.1. Deterministic Time to Establish Streaming . . . . . . 9
2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9 2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9
2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9 2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10
2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10 2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10
2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10 2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10
2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 10 2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 10
2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 10 2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 11
2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11 2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11
2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11 2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11
2.4. Integration of Reserved Streams into IT Networks . . . . 11 2.4. Integration of Reserved Streams into IT Networks . . . . 12
2.5. Security Considerations . . . . . . . . . . . . . . . . . 12 2.5. Security Considerations . . . . . . . . . . . . . . . . . 12
2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12 2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12
2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12 2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12
2.6. A State-of-the-Art Broadcast Installation Hits Technology 2.6. A State-of-the-Art Broadcast Installation Hits Technology
Limits . . . . . . . . . . . . . . . . . . . . . . . . . 12 Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 13
3. Utility Telecom Use Cases . . . . . . . . . . . . . . . . . . 13 3. Utility Telecom Use Cases . . . . . . . . . . . . . . . . . . 13
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Telecommunications Trends and General telecommunications 3.2. Telecommunications Trends and General telecommunications
Requirements . . . . . . . . . . . . . . . . . . . . . . 14 Requirements . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. General Telecommunications Requirements . . . . . . . 14 3.2.1. General Telecommunications Requirements . . . . . . . 14
3.2.1.1. Migration to Packet-Switched Network . . . . . . 15 3.2.1.1. Migration to Packet-Switched Network . . . . . . 15
3.2.2. Applications, Use cases and traffic patterns . . . . 16 3.2.2. Applications, Use cases and traffic patterns . . . . 16
3.2.2.1. Transmission use cases . . . . . . . . . . . . . 16 3.2.2.1. Transmission use cases . . . . . . . . . . . . . 16
3.2.2.2. Distribution use case . . . . . . . . . . . . . . 26 3.2.2.2. Distribution use case . . . . . . . . . . . . . . 26
3.2.2.3. Generation use case . . . . . . . . . . . . . . . 29 3.2.2.3. Generation use case . . . . . . . . . . . . . . . 29
3.2.3. Specific Network topologies of Smart Grid 3.2.3. Specific Network topologies of Smart Grid
Applications . . . . . . . . . . . . . . . . . . . . 30 Applications . . . . . . . . . . . . . . . . . . . . 30
3.2.4. Precision Time Protocol . . . . . . . . . . . . . . . 31 3.2.4. Precision Time Protocol . . . . . . . . . . . . . . . 31
3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 32 3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 32
3.4. Security Considerations . . . . . . . . . . . . . . . . . 32 3.4. Security Considerations . . . . . . . . . . . . . . . . . 32
3.4.1. Current Practices and Their Limitations . . . . . . . 32 3.4.1. Current Practices and Their Limitations . . . . . . . 32
3.4.2. Security Trends in Utility Networks . . . . . . . . . 34 3.4.2. Security Trends in Utility Networks . . . . . . . . . 34
3.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 35 4. Building Automation Systems . . . . . . . . . . . . . . . . . 35
4. Building Automation Systems Use Cases . . . . . . . . . . . . 35 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 35
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36 4.2. Building Automation Systems Today . . . . . . . . . . . . 36
4.2. BAS Functionality . . . . . . . . . . . . . . . . . . . . 36 4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 36
4.3. BAS Architecture . . . . . . . . . . . . . . . . . . . . 37 4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 37
4.4. Deployment Model . . . . . . . . . . . . . . . . . . . . 38 4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 39
4.5. Use cases and Field Network Requirements . . . . . . . . 40 4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 39
4.5.1. Environmental Monitoring . . . . . . . . . . . . . . 40 4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 39
4.5.2. Fire Detection . . . . . . . . . . . . . . . . . . . 40 4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 40
4.5.3. Feedback Control . . . . . . . . . . . . . . . . . . 41 4.2.4. Security Considerations . . . . . . . . . . . . . . . 40
4.6. Security Considerations . . . . . . . . . . . . . . . . . 42 4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 40
5. Wireless for Industrial Use Cases . . . . . . . . . . . . . . 43 4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 43 5. Wireless for Industrial Use Cases . . . . . . . . . . . . . . 41
5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 44 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 41
5.3. 6TiSCH Overview . . . . . . . . . . . . . . . . . . . . . 44 5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.1. TSCH and 6top . . . . . . . . . . . . . . . . . . . . 47 5.3. 6TiSCH Overview . . . . . . . . . . . . . . . . . . . . . 43
5.3.2. SlotFrames and Priorities . . . . . . . . . . . . . . 47 5.3.1. TSCH and 6top . . . . . . . . . . . . . . . . . . . . 46
5.3.3. Schedule Management by a PCE . . . . . . . . . . . . 47 5.3.2. SlotFrames and Priorities . . . . . . . . . . . . . . 46
5.3.4. Track Forwarding . . . . . . . . . . . . . . . . . . 48 5.3.3. Schedule Management by a PCE . . . . . . . . . . . . 46
5.3.4.1. Transport Mode . . . . . . . . . . . . . . . . . 50 5.3.4. Track Forwarding . . . . . . . . . . . . . . . . . . 47
5.3.4.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . 51 5.3.4.1. Transport Mode . . . . . . . . . . . . . . . . . 49
5.3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . 52 5.3.4.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . 50
5.4. Operations of Interest for DetNet and PCE . . . . . . . . 53 5.3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . 51
5.4.1. Packet Marking and Handling . . . . . . . . . . . . . 54 5.4. Operations of Interest for DetNet and PCE . . . . . . . . 51
5.4.1.1. Tagging Packets for Flow Identification . . . . . 54 5.4.1. Packet Marking and Handling . . . . . . . . . . . . . 52
5.4.1.2. Replication, Retries and Elimination . . . . . . 54 5.4.1.1. Tagging Packets for Flow Identification . . . . . 52
5.4.1.3. Differentiated Services Per-Hop-Behavior . . . . 55 5.4.1.2. Replication, Retries and Elimination . . . . . . 52
5.4.2. Topology and capabilities . . . . . . . . . . . . . . 55 5.4.1.3. Differentiated Services Per-Hop-Behavior . . . . 53
5.5. Security Considerations . . . . . . . . . . . . . . . . . 56 5.4.2. Topology and capabilities . . . . . . . . . . . . . . 53
5.6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 56 5.5. Security Considerations . . . . . . . . . . . . . . . . . 54
6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 56 6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 54
6.1. Introduction and background . . . . . . . . . . . . . . . 56 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 54
6.2. Network architecture . . . . . . . . . . . . . . . . . . 60 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 54
6.3. Time synchronization requirements . . . . . . . . . . . . 61 6.1.2. Time Synchronization Requirements . . . . . . . . . . 55
6.4. Time-sensitive stream requirements . . . . . . . . . . . 62 6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 57
6.5. Security considerations . . . . . . . . . . . . . . . . . 63 6.1.4. Security Considerations . . . . . . . . . . . . . . . 57
7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 63 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 58
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 64 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 58
7.2. Industrial M2M Communication Today . . . . . . . . . . . 65 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 60
7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 65 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 60
7.2.2. Stream Creation and Destruction . . . . . . . . . . . 66 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 60
7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 66 7.2. Industrial M2M Communication Today . . . . . . . . . . . 62
7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 66 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 62
7.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 67 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 63
8. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 67 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 63
8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 67 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 63
8.2. Critical Delay Requirements . . . . . . . . . . . . . . . 68 8. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 64
8.3. Coordinated multipoint processing (CoMP) . . . . . . . . 69 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 64
8.3.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 69 8.2. Critical Delay Requirements . . . . . . . . . . . . . . . 65
8.3.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 70 8.3. Coordinated multipoint processing (CoMP) . . . . . . . . 65
8.4. Industrial Automation . . . . . . . . . . . . . . . . . . 70 8.3.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 65
8.5. Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . 70 8.3.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 66
8.6. Gaming, Media and Virtual Reality . . . . . . . . . . . . 71 8.4. Industrial Automation . . . . . . . . . . . . . . . . . . 67
9. Use Case Common Elements . . . . . . . . . . . . . . . . . . 71 8.5. Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . 67
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72 8.6. Gaming, Media and Virtual Reality . . . . . . . . . . . . 68
11. Informative References . . . . . . . . . . . . . . . . . . . 73 9. Use Case Common Elements . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 69
10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 69
10.3. Building Automation Systems . . . . . . . . . . . . . . 70
10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 70
10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 70
10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 70
10.7. Other . . . . . . . . . . . . . . . . . . . . . . . . . 70
11. Informative References . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79
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 5, line 27 skipping to change at page 5, line 39
o What do you want the IETF to deliver? o What do you want the IETF to deliver?
The level of detail in each use case should be sufficient to express The level of detail in each use case should be sufficient to express
the relevant elements of the use case, but not more. the relevant elements of the use case, but not more.
At the end we consider the use cases collectively, and examine the At the end we consider the use cases collectively, and examine the
most significant goals they have in common. most significant goals they have in common.
2. Pro Audio Use Cases 2. Pro Audio Use Cases
(This section was derived from draft-gunther-detnet-proaudio-req-01)
2.1. Introduction 2.1. Introduction
The professional audio and video industry includes music and film The professional audio and video industry includes music and film
content creation, broadcast, cinema, and live exposition as well as content creation, broadcast, cinema, and live exposition as well as
public address, media and emergency systems at large venues public address, media and emergency systems at large venues
(airports, stadiums, churches, theme parks). These industries have (airports, stadiums, churches, theme parks). These industries have
already gone through the transition of audio and video signals from already gone through the transition of audio and video signals from
analog to digital, however the interconnect systems remain primarily analog to digital, however the interconnect systems remain primarily
point-to-point with a single (or small number of) signals per link, point-to-point with a single (or small number of) signals per link,
interconnected with purpose-built hardware. interconnected with purpose-built hardware.
skipping to change at page 13, line 11 skipping to change at page 13, line 24
they possibly could with packet-based technology. They constructed they possibly could with packet-based technology. They constructed
seven individual studios using layer 2 LANS (using IEEE 802.1 AVB) seven individual studios using layer 2 LANS (using IEEE 802.1 AVB)
that were entirely effective at routing audio within the LANs, and that were entirely effective at routing audio within the LANs, and
they were very happy with the results, however to interconnect these they were very happy with the results, however to interconnect these
layer 2 LAN islands together they ended up using dedicated links layer 2 LAN islands together they ended up using dedicated links
because there is no standards-based routing solution available. because there is no standards-based routing solution available.
This is the kind of motivation we have to develop these standards This is the kind of motivation we have to develop these standards
because customers are ready and able to use them. because customers are ready and able to use them.
2.7. Acknowledgements
The editors would like to acknowledge the help of the following
individuals and the companies they represent:
Jeff Koftinoff, Meyer Sound
Jouni Korhonen, Associate Technical Director, Broadcom
Pascal Thubert, CTAO, Cisco
Kieran Tyrrell, Sienda New Media Technologies GmbH
3. Utility Telecom Use Cases 3. Utility Telecom Use Cases
(This section was derived from draft-wetterwald-detnet-utilities-
reqs-02)
3.1. Overview 3.1. Overview
[I-D.finn-detnet-problem-statement] defines the characteristics of a [I-D.finn-detnet-problem-statement] defines the characteristics of a
deterministic flow as a data communication flow with a bounded deterministic flow as a data communication flow with a bounded
latency, extraordinarily low frame loss, and a very narrow jitter. latency, extraordinarily low frame loss, and a very narrow jitter.
This document intends to define the utility requirements for This document intends to define the utility requirements for
deterministic networking. deterministic networking.
Utility Telecom Networks Utility Telecom Networks
skipping to change at page 35, line 40 skipping to change at page 35, line 40
associated with implementing security solutions in OT networks. associated with implementing security solutions in OT networks.
Securing OT (Operation technology) telecommunications over packet- Securing OT (Operation technology) telecommunications over packet-
switched IP networks follow the same principles that are foundational switched IP networks follow the same principles that are foundational
for securing the IT infrastructure, i.e., consideration must be given for securing the IT infrastructure, i.e., consideration must be given
to enforcing electronic access control for both person-to-machine and to enforcing electronic access control for both person-to-machine and
machine-to-machine communications, and providing the appropriate machine-to-machine communications, and providing the appropriate
levels of data privacy, device and platform integrity, and threat levels of data privacy, device and platform integrity, and threat
detection and mitigation. detection and mitigation.
3.5. Acknowledgements 4. Building Automation Systems
Faramarz Maghsoodlou, Ph. D. IoT Connected Industries and Energy
Practice Cisco
Pascal Thubert, CTAO Cisco
4. Building Automation Systems Use Cases
4.1. Introduction
Building Automation System (BAS) is a system that manages various
equipment and sensors in buildings (e.g., heating, cooling and
ventilating) for improving residents' comfort, reduction of energy
consumption and automatic responses in case of failure and emergency.
For example, BAS measures temperature of a room by using various
sensors and then controls the HVAC (Heating, Ventilating, and air
Conditioning) system automatically to maintain the temperature level
and minimize the energy consumption.
There are typically two layers of network in a BAS. Upper one is 4.1. Use Case Description
called management network and the lower one is called field network.
In management networks, an IP-based communication protocol is used
while in field network, non-IP based communication protocols (a.k.a.,
field protocol) are mainly used.
There are many field protocols used in today's deployment in which A Building Automation System (BAS) manages equipment and sensors in a
some medium access control and physical layers protocols are building for improving residents' comfort, reducing energy
standards-based and others are proprietary based. Therefore the BAS consumption, and responding to failures and emergencies. For
needs to have multiple MAC/PHY modules and interfaces to make use of example, the BAS measures the temperature of a room using sensors and
multiple field protocols based devices. This situation not only then controls the HVAC (heating, ventilating, and air conditioning)
makes BAS more expensive with large development cycle of multiple to maintain a set temperature and minimize energy consumption.
devices but also creates the issue of vendor lock-in with multiple
types of management applications.
The other issue with some of the existing field networks and A BAS primarily performs the following functions:
protocols are security. When these protocols and network were
developed, it was assumed that the field networks are isolated
physically from external networks and therefore the network and
protocol security was not a concern. However, in today's world many
BASes are managed remotely and is connected to shared IP networks and
it is also not uncommon that same IT infrastructure is used be it
office, home or in enterprise networks. Adding network and protocol
security to existing system is a non-trivial task.
This document first describes the BAS functionalities, its o Periodically measures states of devices, for example humidity and
architecture and current deployment models. Then we discuss the use illuminance of rooms, open/close state of doors, FAN speed, etc.
cases and field network requirements that need to be satisfied by
deterministic networking.
4.2. BAS Functionality o Stores the measured data.
Building Automation System (BAS) is a system that manages various o Provides the measured data to BAS systems and operators.
devices in buildings automatically. BAS primarily performs the
following functions:
o Measures states of devices in a regular interval. For example, o Generates alarms for abnormal state of devices.
temperature or humidity or illuminance of rooms, on/off state of
room lights, open/close state of doors, FAN speed, valve, running
mode of HVAC, and its power consumption.
o Stores the measured data into a database (Note: The database keeps o Controls devices (e.g. turn off room lights at 10:00 PM).
the data for several years).
o Provides the measured data for BAS operators for visualization. 4.2. Building Automation Systems Today
o Generates alarms for abnormal state of devices (e.g., calling 4.2.1. BAS Architecture
operator's cellular phone, sending an e-mail to operators and so
on).
o Controls devices on demand. A typical BAS architecture of today is shown in Figure 1.
o Controls devices with a pre-defined operation schedule (e.g., turn +----------------------------+
off room lights at 10:00 PM). | |
| BMS HMI |
| | | |
| +----------------------+ |
| | Management Network | |
| +----------------------+ |
| | | |
| LC LC |
| | | |
| +----------------------+ |
| | Field Network | |
| +----------------------+ |
| | | | | |
| Dev Dev Dev Dev |
| |
+----------------------------+
4.3. BAS Architecture BMS := Building Management Server
HMI := Human Machine Interface
LC := Local Controller
A typical BAS architecture is described below in Figure 1. There are Figure 1: BAS architecture
several elements in a BAS.
+----------------------------+ | | | BMS HMI | | | | | There are typically two layers of network in a BAS. The upper one is
| +----------------------+ | | | Management Network | | | called the Management Network and the lower one is called the Field
+----------------------+ | | | | | | LC LC | | | | | | Network. In management networks an IP-based communication protocol
+----------------------+ | | | Field Network | | | +----------------------+ is used, while in field networks non-IP based communication protocols
| | | | | | | | Dev Dev Dev Dev | | | +----------------------------+ BMS := ("field protocols") are mainly used. Field networks have specific
Building Management Server HMI := Human Machine Interface LC := Local timing requirements, whereas management networks can be best-effort.
Controller
Figure 1: BAS architecture A Human Machine Interface (HMI) is typically a desktop PC used by
operators to monitor and display device states, send device control
commands to Local Controllers (LCs), and configure building schedules
(for example "turn off all room lights in the building at 10:00 PM").
Human Machine Interface (HMI): It is commonly a computing platform A Building Management Server (BMS) performs the following operations.
(e.g., desktop PC) used by operators. Operators perform the
following operations through HMI.
o Monitoring devices: HMI displays measured device states. For o Collect and store device states from LCs at regular intervals.
example, latest device states, a history chart of states, a popup
window with an alert message. Typically, the measured device
states are stored in BMS (Building Management Server).
o Controlling devices: HMI provides ability to control the devices. o Send control values to LCs according to a building schedule.
For example, turn on a room light, set a target temperature to
HVAC. Several parameters (a target device, a control value,
etc.), can be set by the operators which then HMI sends to a LC
(Local Controller) via the management network.
o Configuring an operational schedule: HMI provides scheduling o Send an alarm signal to operators if it detects abnormal devices
capability through which operational schedule is defined. For states.
example, schedule includes 1) a time to control, 2) a target
device to control, and 3) a control value. A specific operational
example could be turn off all room lights in the building at 10:00
PM. This schedule is typically stored in BMS.
Building Management Server (BMS) collects device states from LCs The BMS and HMI communicate with LCs via IP-based "management
(Local Controllers) and stores it into a database. According to its protocols" (see standards [bacnetip], [knx]).
configuration, BMS executes the following operation automatically.
o BMS collects device states from LCs in a regular interval and then A LC is typically a Programmable Logic Controller (PLC) which is
stores the information into a database. connected to several tens or hundreds of devices using "field
protocols". An LC performs the following kinds of operations:
o BMS sends control values to LCs according to a pre-configured o Measure device states and provide the information to BMS or HMI.
schedule.
o BMS sends an alarm signal to operators if it detects abnormal o Send control values to devices, unilaterally or as part of a
devices states. For example, turning on a red lamp, calling feedback control loop.
operators' cellular phone, sending an e-mail to operators.
BMS and HMI communicate with Local Controllers (LCs) via IP-based There are many field protocols used today; some are standards-based
communication protocol standardized by BACnet/IP [bacnetip], KNX/IP and others are proprietary (see standards [lontalk], [modbus],
[knx]. These protocols are commonly called as management protocols. [profibus] and [flnet]). The result is that BASs have multiple MAC/
LCs measure device states and provide the information to BMS or HMI. PHY modules and interfaces. This makes BASs more expensive, slower
These devices may include HVAC, FAN, doors, valves, lights, sensors to develop, and can result in "vendor lock-in" with multiple types of
(e.g., temperature, humidity, and illuminance). LC can also set management applications.
control values to the devices. LC sometimes has additional
functions, for example, sending a device state to BMS or HMI if the
device state exceeds a certain threshold value, feedback control to a
device to keep the device state at a certain state. Typical example
of LC is a PLC (Programmable Logic Controller).
Each LC is connected with a different field network and communicates 4.2.2. BAS Deployment Model
with several tens or hundreds of devices via the field network.
Today there are many field protocols used in the field network.
Based on the type of field protocol used, LC interfaces and its
hardware/software could be different. Field protocols are currently
non-IP based in which some of them are standards-based (e.g., LonTalk
[lontalk], Modbus [modbus], Profibus [profibus], FL-net [flnet],) and
others are proprietary.
4.4. Deployment Model An example BAS for medium or large buildings is shown in Figure 2.
The physical layout spans multiple floors, and there is a monitoring
room where the BAS management entities are located. Each floor will
have one or more LCs depending upon the number of devices connected
to the field network.
An example BAS system deployment model for medium and large buildings +--------------------------------------------------+
is depicted in Figure 2 below. In this case the physical layout of | Floor 3 |
the entire system spans across multiple floors in which there is | +----LC~~~~+~~~~~+~~~~~+ |
normally a monitoring room where the BAS management entities are | | | | | |
located. Each floor will have one or more LCs depending upon the | | Dev Dev Dev |
number of devices connected to the field network. | | |
|--- | ------------------------------------------|
| | Floor 2 |
| +----LC~~~~+~~~~~+~~~~~+ Field Network |
| | | | | |
| | Dev Dev Dev |
| | |
|--- | ------------------------------------------|
| | Floor 1 |
| +----LC~~~~+~~~~~+~~~~~+ +-----------------|
| | | | | | Monitoring Room |
| | Dev Dev Dev | |
| | | BMS HMI |
| | Management Network | | | |
| +--------------------------------+-----+ |
| | |
+--------------------------------------------------+
+--------------------------------------------------+ | Figure 2: BAS Deployment model for Medium/Large Buildings
Floor 3 | | +----LC~~~~+~~~~~+~~~~~+ | | | | | | | | | Dev Dev Dev | | | |
|--- | ------------------------------------------| | | Floor 2 | |
+----LC~~~~+~~~~~+~~~~~+ Field Network | | | | | | | | | Dev Dev Dev | | | |
|--- | ------------------------------------------| | | Floor 1 | |
+----LC~~~~+~~~~~+~~~~~+ +-----------------| | | | | | | Monitoring Room | |
| Dev Dev Dev | | | | | BMS HMI | | | Management Network | | | | |
+--------------------------------+-----+ | | | |
+--------------------------------------------------+
Figure 2: Deployment model for Medium/Large Buildings Each LC is connected to the monitoring room via the Management
network, and the management functions are performed within the
building. In most cases, fast Ethernet (e.g. 100BASE-T) is used for
the management network. Since the management network is non-
realtime, use of Ethernet without quality of service is sufficient
for today's deployment.
Each LC is then connected to the monitoring room via the management In the field network a variety of physical interfaces such as RS232C
network. In this scenario, the management functions are performed and RS485 are used, which have specific timing requirements. Thus if
locally and reside within the building. In most cases, fast Ethernet a field network is to be replaced with an Ethernet or wireless
(e.g. 100BASE-TX) is used for the management network. In the field network, such networks must support time-critical deterministic
network, variety of physical interfaces such as RS232C, and RS485 are flows.
used. Since management network is non-real time, Ethernet without
quality of service is sufficient for today's deployment. However,
the requirements are different for field networks when they are
replaced by either Ethernet or any wireless technologies supporting
real time requirements (Section 3.4).
Figure 3 depicts a deployment model in which the management can be In Figure 3, another deployment model is presented in which the
hosted remotely. This deployment is becoming popular for small management system is hosted remotely. This is becoming popular for
office and residential buildings whereby having a standalone small office and residential buildings in which a standalone
monitoring system is not a cost effective solution. In such monitoring system is not cost-effective.
scenario, multiple buildings are managed by a remote management
monitoring system.
+---------------+ | Remote Center | | | | BMS HMI | +---------------+
+------------------------------------+ | | | | | Floor 2 | | +---+---+ | | | Remote Center |
+----LC~~~~+~~~~~+ Field Network| | | | | | | | | | Router | | | Dev Dev | | |
+-------|-------+ | | | | |--- | ------------------------------| | | | Floor | BMS HMI |
1 | | | +----LC~~~~+~~~~~+ | | | | | | | | | | Dev Dev | | | | | | | | +------------------------------------+ | | | |
Management Network | WAN | | +------------------------Router-------------+ | | Floor 2 | | +---+---+ |
| +------------------------------------+ | +----LC~~~~+~~~~~+ Field Network| | | |
| | | | | | Router |
| | Dev Dev | +-------|-------+
| | | |
|--- | ------------------------------| |
| | Floor 1 | |
| +----LC~~~~+~~~~~+ | |
| | | | | |
| | Dev Dev | |
| | | |
| | Management Network | WAN |
| +------------------------Router-------------+
| |
+------------------------------------+
Figure 3: Deployment model for Small Buildings Figure 3: Deployment model for Small Buildings
In either case, interoperability today is only limited to the Some interoperability is possible today in the Management Network,
management network and its protocols. In existing deployment, there but not in today's field networks due to their non-IP-based design.
are limited interoperability opportunity in the field network due to
its nature of non-IP-based design and requirements.
4.5. Use cases and Field Network Requirements 4.2.3. Use Cases for Field Networks
In this section, we describe several use cases and corresponding Below are use cases for Environmental Monitoring, Fire Detection, and
network requirements. Feedback Control, and their implications for field network
performance.
4.5.1. Environmental Monitoring 4.2.3.1. Environmental Monitoring
In this use case, LCs measure environmental data (e.g. temperatures, The BMS polls each LC at a maximum measurement interval of 100ms (for
humidity, illuminance, CO2, etc.) from several sensor devices at each example to draw a historical chart of 1 second granularity with a 10x
measurement interval. LCs keep latest value of each sensor. BMS sampling interval) and then performs the operations as specified by
sends data requests to LCs to collect the latest values, then stores the operator. Each LC needs to measure each of its several hundred
the collected values into a database. Operators check the latest sensors once per measurement interval. Latency is not critical in
environmental data that are displayed by the HMI. BMS also checks this scenario as long as all sensor values are completed in the
the collected data automatically to notify the operators if a room measurement interval. Availability is expected to be 99.999 %.
condition was going to bad (e.g., too hot or cold). The following
table lists the field network requirements in which the number of
devices in a typical building will be ~100s per LC.
+----------------------+-------------+ 4.2.3.2. Fire Detection
| Metric | Requirement |
+----------------------+-------------+
| Measurement interval | 100 msec |
| | |
| Availability | 99.999 % |
+----------------------+-------------+
Table 11: Field Network Requirements for Environmental Monitoring On detection of a fire, the BMS must stop the HVAC, close the fire
shutters, turn on the fire sprinklers, send an alarm, etc. There are
typically ~10s of sensors per LC that BMS needs to manage. In this
scenario the measurement interval is 10-50ms, the communication delay
is 10ms, and the availability must be 99.9999 %.
There is a case that BMS sends data requests at each 1 second in 4.2.3.3. Feedback Control
order to draw a historical chart of 1 second granularity. Therefore
100 msec measurement interval is sufficient for this use case,
because typically 10 times granularity (compared with the interval of
data requests) is considered enough accuracy in this use case. A LC
needs to measure values of all sensors connected with itself at each
measurement interval. Each communication delay in this scenario is
not so critical. The important requirement is completing
measurements of all sensor values in the specified measurement
interval. The availability in this use case is very high (Three 9s).
4.5.2. Fire Detection BAS systems utilize feedback control in various ways; the most time-
critial is control of DC motors, which require a short feedback
interval (1-5ms) with low communication delay (10ms) and jitter
(1ms). The feedback interval depends on the characteristics of the
device and a target quality of control value. There are typically
~10s of such devices per LC.
In the case of fire detection, HMI needs to show a popup window with Communication delay is expected to be less than 10 ms, jitter less
an alert message within a few seconds after an abnormal state is than 1 sec while the availability must be 99.9999% .
detected. BMS needs to do some operations if it detects fire. For
example, stopping a HVAC, closing fire shutters, and turning on fire
sprinklers. The following table describes requirements in which the
number of devices in a typical building will be ~10s per LC.
+----------------------+---------------+ 4.2.4. Security Considerations
| Metric | Requirement |
+----------------------+---------------+
| Measurement interval | 10s of msec |
| | |
| Communication delay | < 10s of msec |
| | |
| Availability | 99.9999 % |
+----------------------+---------------+
Table 12: Field Network Requirements for Fire Detection When BAS field networks were developed it was assumed that the field
networks would always be physically isolated from external networks
and therefore security was not a concern. In today's world many BASs
are managed remotely and are thus connected to shared IP networks and
so security is definitely a concern, yet security features are not
available in the majority of BAS field network deployments .
In order to perform the above operation within a few seconds (1 or 2 The management network, being an IP-based network, has the protocols
seconds) after detecting fire, LCs should measure sensor values at a available to enable network security, but in practice many BAS
regular interval of less than 10s of msec. If a LC detects an systems do not implement even the available security features such as
abnormal sensor value, it sends an alarm information to BMS and HMI device authentication or encryption for data in transit.
immediately. BMS then controls HVAC or fire shutters or fire
sprinklers. HMI then displays a pop up window and generates the
alert message. Since the management network does not operate in real
time, and software run on BMS or HMI requires 100s of ms, the
communication delay should be less than ~10s of msec. The
availability in this use case is very high (Four 9s).
4.5.3. Feedback Control 4.3. BAS Future
Feedback control is used to keep a device state at a certain value. In the future we expect more fine-grained environmental monitoring
For example, keeping a room temperature at 27 degree Celsius, keeping and lower energy consumption, which will require more sensors and
a water flow rate at 100 L/m and so on. The target device state is devices, thus requiring larger and more complex building networks.
normally pre-defined in LCs or provided from BMS or from HMI.
In feedback control procedure, a LC repeats the following actions at We expect building networks to be connected to or converged with
a regular interval (feedback interval). other networks (Enterprise network, Home network, and Internet).
1. The LC measures device states of the target device. Therefore better facilities for network management, control,
reliability and security are critical in order to improve resident
and operator convenience and comfort. For example the ability to
monitor and control building devices via the internet would enable
(for example) control of room lights or HVAC from a resident's
desktop PC or phone application.
2. The LC calculates a control value by considering the measured 4.4. BAS Asks
device state.
3. The LC sends the control value to the target device. The community would like to see an interoperable protocol
specification that can satisfy the timing, security, availability and
QoS constraints described above, such that the resulting converged
network can replace the disparate field networks. Ideally this
connectivity could extend to the open Internet.
The feedback interval highly depends on the characteristics of the This would imply an architecture that can guarantee
device and a target quality of control value. While several tens of
milliseconds feedback interval is sufficient to control a valve that
regulates a water flow, controlling DC motors requires several
milliseconds interval. The following table describes the field
network requirements in which the number of devices in a typical
building will be ~10s per LC.
+----------------------+---------------+ o Low communication delays (from <10ms to 100ms in a network of
| Metric | Requirement | several hundred devices)
+----------------------+---------------+
| Feedback interval | ~10ms - 100ms |
| | |
| Communication delay | < 10s of msec |
| | |
| Communication jitter | < 1 msec |
| | |
| Availability | 99.9999 % |
+----------------------+---------------+
Table 13: Field Network Requirements for Feedback Control o Low jitter (< 1 ms)
Small communication delay and jitter are required in this use case in o Tight feedback intervals (1ms - 10ms)
order to provide high quality of feedback control. This is currently
offered in production environment with hgh availability (Four 9s).
4.6. Security Considerations o High network availability (up to 99.9999% )
Both network and physical security of BAS are important. While o Availability of network data in disaster scenario
physical security is present in today's deployment, adequate network
security and access control are either not implemented or configured
properly. This was sufficient in networks while they are isolated
and not connected to the IT or other infrastructure networks but when
IT and OT (Operational Technology) are connected in the same
infrastructure network, network security is essential. The
management network being an IP-based network does have the protocols
and knobs to enable the network security but in many cases BAS for
example, does not use device authentication or encryption for data in
transit. On the contrary, many of today's field networks do not
provide any security at all. Following are the high level security
requirements that the network should provide:
o Authentication between management and field devices (both local o Authentication between management and field devices (both local
and remote) and remote)
o Integrity and data origin authentication of communication data o Integrity and data origin authentication of communication data
between field and management devices between field and management devices
o Confidentiality of data when communicated to a remote device o Confidentiality of data when communicated to a remote device
o Availability of network data for normal and disaster scenario
5. Wireless for Industrial Use Cases 5. Wireless for Industrial Use Cases
(This section was derived from draft-thubert-6tisch-4detnet-01) (This section was derived from draft-thubert-6tisch-4detnet-01)
5.1. Introduction 5.1. Introduction
The emergence of wireless technology has enabled a variety of new The emergence of wireless technology has enabled a variety of new
devices to get interconnected, at a very low marginal cost per devices to get interconnected, at a very low marginal cost per
device, at any distance ranging from Near Field to interplanetary, device, at any distance ranging from Near Field to interplanetary,
and in circumstances where wiring may not be practical, for instance and in circumstances where wiring may not be practical, for instance
skipping to change at page 56, line 26 skipping to change at page 54, line 30
5.5. Security Considerations 5.5. Security Considerations
On top of the classical protection of control signaling that can be On top of the classical protection of control signaling that can be
expected to support DetNet, it must be noted that 6TiSCH networks expected to support DetNet, it must be noted that 6TiSCH networks
operate on limited resources that can be depleted rapidly if an operate on limited resources that can be depleted rapidly if an
attacker manages to operate a DoS attack on the system, for instance attacker manages to operate a DoS attack on the system, for instance
by placing a rogue device in the network, or by obtaining management by placing a rogue device in the network, or by obtaining management
control and to setup extra paths. control and to setup extra paths.
5.6. Acknowledgments
This specification derives from the 6TiSCH architecture, which is the
result of multiple interactions, in particular during the 6TiSCH
(bi)Weekly Interim call, relayed through the 6TiSCH mailing list at
the IETF.
The authors wish to thank: Kris Pister, Thomas Watteyne, Xavier
Vilajosana, Qin Wang, Tom Phinney, Robert Assimiti, Michael
Richardson, Zhuo Chen, Malisa Vucinic, Alfredo Grieco, Martin Turon,
Dominique Barthel, Elvis Vogli, Guillaume Gaillard, Herman Storey,
Maria Rita Palattella, Nicola Accettura, Patrick Wetterwald, Pouria
Zand, Raghuram Sudhaakar, and Shitanshu Shah for their participation
and various contributions.
6. Cellular Radio Use Cases 6. Cellular Radio Use Cases
(This section was derived from draft-korhonen-detnet-telreq-00) 6.1. Use Case Description
6.1. Introduction and background
The recent developments in telecommunication networks, especially in
the cellular domain, are heading towards transport networks where
precise time synchronization support has to be one of the basic
building blocks. While the transport networks themselves have
practically transitioned to all-AP packet based networks to meet the
bandwidth and cost requirements, a highly accurate clock distribution
has become a challenge. Earlier the transport networks in the
cellular domain were typically time division and multiplexing (TDM)
-based and provided frequency synchronization capabilities as a part
of the transport media. Alternatively other technologies such as
Global Positioning System (GPS) or Synchronous Ethernet (SyncE)
[SyncE] were used. New radio access network deployment models and
architectures may require time sensitive networking services with
strict requirements on other parts of the network that previously
were not considered to be packetized at all. The time and
synchronization support are already topical for backhaul and midhaul
packet networks [MEF], and becoming a real issue for fronthaul
networks. Specifically in the fronthaul networks the timing and
synchronization requirements can be extreme for packet based
technologies, for example, in order of sub +-20 ns packet delay
variation (PDV) and frequency accuracy of +0.002 PPM [Fronthaul].
Both Ethernet and IP/MPLS [RFC3031] (and PseudoWires (PWE) [RFC3985]
for legacy transport support) have become popular tools to build and
manage new all-IP radio access networks (RAN)
[I-D.kh-spring-ip-ran-use-case]. Although various timing and
synchronization optimizations have already been proposed and
implemented including 1588 PTP enhancements
[I-D.ietf-tictoc-1588overmpls][I-D.mirsky-mpls-residence-time], these
solution are not necessarily sufficient for the forthcoming RAN
architectures or guarantee the higher time-synchronization
requirements [CPRI]. There are also existing solutions for the TDM
over IP [RFC5087] [RFC4553] or Ethernet transports [RFC5086]. The
really interesting and important existing work for time sensitive
networking has been done for Ethernet [TSNTG], which specifies the
use of IEEE 1588 time precision protocol (PTP) [IEEE1588] in the
context of IEEE 802.1D and IEEE 802.1Q. While IEEE 802.1AS
[IEEE8021AS] specifies a Layer-2 time synchronizing service other
specification, such as IEEE 1722 [IEEE1722] specify Ethernet-based
Layer-2 transport for time-sensitive streams. New promising work
seeks to enable the transport of time-sensitive fronthaul streams in
Ethernet bridged networks [IEEE8021CM]. Similarly to IEEE 1722 there
is an ongoing standardization effort to define Layer-2 transport
encapsulation format for transporting radio over Ethernet (RoE) in
IEEE 1904.3 Task Force [IEEE19043].
As already mentioned all-IP RANs and various "haul" networks would
benefit from time synchronization and time-sensitive transport
services. Although Ethernet appears to be the unifying technology
for the transport there is still a disconnect providing Layer-3
services. The protocol stack typically has a number of layers below
the Ethernet Layer-2 that shows up to the Layer-3 IP transport. It
is not uncommon that on top of the lowest layer (optical) transport
there is the first layer of Ethernet followed one or more layers of
MPLS, PseudoWires and/or other tunneling protocols finally carrying
the Ethernet layer visible to the user plane IP traffic. While there
are existing technologies, especially in MPLS/PWE space, to establish
circuits through the routed and switched networks, there is a lack of
signaling the time synchronization and time-sensitive stream
requirements/reservations for Layer-3 flows in a way that the entire
transport stack is addressed and the Ethernet layers that needs to be
configured are addressed. Furthermore, not all "user plane" traffic
will be IP. Therefore, the same solution need also address the use
cases where the user plane traffic is again another layer or Ethernet
frames. There is existing work describing the problem statement
[I-D.finn-detnet-problem-statement] and the architecture
[I-D.finn-detnet-architecture] for deterministic networking (DetNet)
that eventually targets to provide solutions for time-sensitive (IP/
transport) streams with deterministic properties over Ethernet-based
switched networks.
This document describes requirements for deterministic networking in
a cellular telecom transport networks context. The requirements
include time synchronization, clock distribution and ways of
establishing time-sensitive streams for both Layer-2 and Layer-3 user
plane traffic using IETF protocol solutions.
The recent developments in telecommunication networks, especially in
the cellular domain, are heading towards transport networks where
precise time synchronization support has to be one of the basic
building blocks. While the transport networks themselves have
practically transitioned to all-AP packet based networks to meet the
bandwidth and cost requirements, a highly accurate clock distribution
has become a challenge. Earlier the transport networks in the
cellular domain were typically time division and multiplexing (TDM)
-based and provided frequency synchronization capabilities as a part
of the transport media. Alternatively other technologies such as
Global Positioning System (GPS) or Synchronous Ethernet (SyncE)
[SyncE] were used. New radio access network deployment models and
architectures may require time sensitive networking services with
strict requirements on other parts of the network that previously
were not considered to be packetized at all. The time and
synchronization support are already topical for backhaul and midhaul
packet networks [MEF], and becoming a real issue for fronthaul
networks. Specifically in the fronthaul networks the timing and
synchronization requirements can be extreme for packet based
technologies, for example, in order of sub +-20 ns packet delay
variation (PDV) and frequency accuracy of +0.002 PPM [Fronthaul].
Both Ethernet and IP/MPLS [RFC3031] (and PseudoWires (PWE) [RFC3985]
for legacy transport support) have become popular tools to build and
manage new all-IP radio access networks (RAN)
[I-D.kh-spring-ip-ran-use-case]. Although various timing and
synchronization optimizations have already been proposed and
implemented including 1588 PTP enhancements
[I-D.ietf-tictoc-1588overmpls][I-D.mirsky-mpls-residence-time], these
solution are not necessarily sufficient for the forthcoming RAN
architectures or guarantee the higher time-synchronization
requirements [CPRI]. There are also existing solutions for the TDM
over IP [RFC5087] [RFC4553] or Ethernet transports [RFC5086]. The
really interesting and important existing work for time sensitive
networking has been done for Ethernet [TSNTG], which specifies the
use of IEEE 1588 time precision protocol (PTP) [IEEE1588] in the
context of IEEE 802.1D and IEEE 802.1Q. While IEEE 802.1AS
[IEEE8021AS] specifies a Layer-2 time synchronizing service other
specification, such as IEEE 1722 [IEEE1722] specify Ethernet-based
Layer-2 transport for time-sensitive streams. New promising work
seeks to enable the transport of time-sensitive fronthaul streams in
Ethernet bridged networks [IEEE8021CM]. Similarly to IEEE 1722 there
is an ongoing standardization effort to define Layer-2 transport
encapsulation format for transporting radio over Ethernet (RoE) in
IEEE 1904.3 Task Force [IEEE19043].
As already mentioned all-IP RANs and various "haul" networks would
benefit from time synchronization and time-sensitive transport
services. Although Ethernet appears to be the unifying technology
for the transport there is still a disconnect providing Layer-3
services. The protocol stack typically has a number of layers below
the Ethernet Layer-2 that shows up to the Layer-3 IP transport. It
is not uncommon that on top of the lowest layer (optical) transport
there is the first layer of Ethernet followed one or more layers of
MPLS, PseudoWires and/or other tunneling protocols finally carrying
the Ethernet layer visible to the user plane IP traffic. While there
are existing technologies, especially in MPLS/PWE space, to establish
circuits through the routed and switched networks, there is a lack of
signaling the time synchronization and time-sensitive stream
requirements/reservations for Layer-3 flows in a way that the entire
transport stack is addressed and the Ethernet layers that needs to be
configured are addressed. Furthermore, not all "user plane" traffic
will be IP. Therefore, the same solution need also address the use
cases where the user plane traffic is again another layer or Ethernet
frames. There is existing work describing the problem statement
[I-D.finn-detnet-problem-statement] and the architecture
[I-D.finn-detnet-architecture] for deterministic networking (DetNet)
that eventually targets to provide solutions for time-sensitive (IP/
transport) streams with deterministic properties over Ethernet-based
switched networks.
This document describes requirements for deterministic networking in
a cellular telecom transport networks context. The requirements
include time synchronization, clock distribution and ways of
establishing time-sensitive streams for both Layer-2 and Layer-3 user
plane traffic using IETF protocol solutions.
6.2. Network architecture
Figure Figure 9 illustrates a typical, 3GPP defined, cellular network This use case describes the application of deterministic networking
architecture, which also has fronthaul and midhaul network segments. in the context of cellular telecom transport networks. Important
The fronthaul refers to the network connecting base stations (base elements include time synchronization, clock distribution, and ways
band processing units) to the remote radio heads (antennas). The of establishing time-sensitive streams for both Layer-2 and Layer-3
midhaul network typically refers to the network inter-connecting base user plane traffic.
stations (or small/pico cells).
Fronthaul networks build on the available excess time after the base 6.1.1. Network Architecture
band processing of the radio frame has completed. Therefore, the
available time for networking is actually very limited, which in
practise determines how far the remote radio heads can be from the
base band processing units (i.e. base stations). For example, in a
case of LTE radio the Hybrid ARQ processing of a radio frame is
allocated 3 ms. Typically the processing completes way earlier (say
up to 400 us, could be much less, though) thus allowing the remaining
time to be used e.g. for fronthaul network. 200 us equals roughly 40
km of optical fiber based transport (assuming round trip time would
be total 2*200 us). The base band processing time and the available
"delay budget" for the fronthaul is a subject to change, possibly
dramatically, in the forthcoming "5G" to meet, for example, the
envisioned reduced radio round trip times, and other architecural and
service requirements [NGMN].
The maximum "delay budget" is then consumed by all nodes and required Figure 9 illustrates a typical 3GPP-defined cellular network
buffering between the remote radio head and the base band processing architecture, which includes "Fronthaul" and "Midhaul" network
in addition to the distance incurred delay. Packet delay variation segments. The "Fronthaul" is the network connecting base stations
(PDV) is problematic to fronthaul networks and must be minimized. If (baseband processing units) to the remote radio heads (antennas).
the transport network cannot guarantee low enough PDV additional The "Midhaul" is the network inter-connecting base stations (or small
buffering has to be introduced at the edges of the network to buffer cell sites).
out the jitter. Any buffering will eat up the total available delay
budget, though. Section Section 6.3 will discuss the PDV
requirements in more detail.
Y (remote radios) 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 |
/`--(___.-' \ `--(___.-' +------+ /`--(___.-' \ `--(___.-' +------+
Y_/ / \.--. \ Y_/ / \.--. \
Y_/ _( Mid`. \ Y_/ _( Mid`. \
( Haul ) \ ( Haul ) \
( ` . ) ) \ ( ` . ) ) \
`--(___.-'\_____+---+ (small cells) `--(___.-'\_____+---+ (small cell sites)
\ |SCe|__Y \ |SCe|__Y
+---+ +---+ +---+ +---+
Y__|eNB|__Y Y__|eNB|__Y
+---+ +---+
Y_/ \_Y ("local" radios) Y_/ \_Y ("local" radios)
Figure 9: Generic 3GPP-based cellular network architecture with Figure 9: Generic 3GPP-based Cellular Network Architecture
Front/Mid/Backhaul networks
6.3. Time synchronization requirements
Cellular networks starting from long term evolution (LTE) [TS36300] The available processing time for Fronthaul networking overhead is
[TS23401] radio the phase synchronization is also needed in addition limited to the available time after the baseband processing of the
to the frequency synchronization. The commonly referenced fronthaul radio frame has completed. For example in Long Term Evolution (LTE)
network synchronization requirements are typically drawn from the radio, processing of a radio frame is allocated 3ms, but typically
common public radio interface (CPRI) [CPRI] specification that the processing completes much earlier (<400us) allowing the remaining
defines the transport protocol between the base band processing - time to be used by the Fronthaul network. This ultimately determines
radio equipment controller (REC) and the remote antenna - radio the distance the remote radio heads can be located from the base
equipment (RE). However, the fundamental requirements still stations (200us equals roughly 40 km of optical fiber-based
originate from the respective cellular system and radio transport, thus round trip time is 2*200us = 400us).
specifications such as the 3GPP ones [TS25104][TS36104][TS36211]
[TS36133].
The fronthaul time synchronization requirements for the current 3GPP The remainder of the "maximum delay budget" is consumed by all nodes
LTE-based networks are listed below: and buffering between the remote radio head and the baseband
processing, plus the distance-incurred delay.
Transport link contribution to radio frequency error: The baseband processing time and the available "delay budget" for the
fronthaul is likely to change in the forthcoming "5G" due to reduced
radio round trip times and other architectural and service
requirements [NGMN].
+-2 PPB. The given value is considered to be "available" for the 6.1.2. Time Synchronization Requirements
fronthaul link out of the total 50 PPB budget reserved for the
radio interface.
Delay accuracy: Fronthaul time synchronization requirements are given by [TS25104],
[TS36104], [TS36211], and [TS36133]. These can be summarized for the
current 3GPP LTE-based networks as:
+-8.138 ns i.e. +-1/32 Tc (UMTS Chip time, Tc, 1/3.84 MHz) to Delay Accuracy:
downlink direction and excluding the (optical) cable length in one +-8ns (i.e. +-1/32 Tc, where Tc is the UMTS Chip time of 1/3.84
direction. Round trip accuracy is then +-16.276 ns. The value is MHz) resulting in a round trip accuracy of +-16ns. The value is
this low to meet the 3GPP timing alignment error (TAE) measurement this low to meet the 3GPP Timing Alignment Error (TAE) measurement
requirements. requirements.
Packet delay variation (PDV): Packet Delay Variation:
Packet Delay Variation (PDV aka Jitter aka Timing Alignment Error)
is problematic to Fronthaul networks and must be minimized. If
the transport network cannot guarantee low enough PDV then
additional buffering has to be introduced at the edges of the
network to buffer out the jitter. Buffering is not desirable as
it reduces the total available delay budget.
* For multiple input multiple output (MIMO) or TX diversity * For multiple input multiple output (MIMO) or TX diversity
transmissions, at each carrier frequency, TAE shall not exceed transmissions, at each carrier frequency, TAE shall not exceed
65 ns (i.e. 1/4 Tc). 65 ns (i.e. 1/4 Tc).
* For intra-band contiguous carrier aggregation, with or without * For intra-band contiguous carrier aggregation, with or without
MIMO or TX diversity, TAE shall not exceed 130 ns (i.e. 1/2 MIMO or TX diversity, TAE shall not exceed 130 ns (i.e. 1/2
Tc). Tc).
* For intra-band non-contiguous carrier aggregation, with or * For intra-band non-contiguous carrier aggregation, with or
without MIMO or TX diversity, TAE shall not exceed 260 ns (i.e. without MIMO or TX diversity, TAE shall not exceed 260 ns (i.e.
one Tc). one Tc).
* For inter-band carrier aggregation, with or without MIMO or TX * For inter-band carrier aggregation, with or without MIMO or TX
diversity, TAE shall not exceed 260 ns. diversity, TAE shall not exceed 260 ns.
The above listed time synchronization requirements are hard to meet Transport link contribution to radio frequency error:
even with point to point connected networks, not to mention cases +-2 PPB. This value is considered to be "available" for the
where the underlying transport network actually constitutes of Fronthaul link out of the total 50 PPB budget reserved for the
multiple hops. It is expected that network deployments have to deal radio interface. Note: the reason that the transport link
with the jitter requirements buffering at the very ends of the contributes to radio frequency error is as follows. The current
connections, since trying to meet the jitter requirements in every way of doing Fronthaul is from the radio unit to remote radio head
intermediate node is likely to be too costly. However, every measure directly. The remote radio head is essentially a passive device
to reduce jitter and delay on the path are valuable to make it easier (without buffering etc.) The transport drives the antenna
to meet the end to end requirements. directly by feeding it with samples and everything the transport
adds will be introduced to radio as-is. So if the transport
causes additional frequence error that shows immediately on the
radio as well.
The above listed time synchronization requirements are difficult to
meet with point-to-point connected networks, and more difficult when
the network includes multiple hops. It is expected that networks
must include buffering at the ends of the connections as imposed by
the jitter requirements, since trying to meet the jitter requirements
in every intermediate node is likely to be too costly. However,
every measure to reduce jitter and delay on the path makes it easier
to meet the end-to-end requirements.
In order to meet the timing requirements both senders and receivers In order to meet the timing requirements both senders and receivers
must is perfect sync. This asks for a very accurate clock must remain time synchronized, demanding very accurate clock
distribution solution. Basically all means and hardware support for distribution, for example support for IEEE 1588 transparent clocks in
guaranteeing accurate time synchronization in the network is needed. every intermediate node.
As an example support for 1588 transparent clocks (TC) in every
intermediate node would be helpful.
6.4. Time-sensitive stream requirements In cellular networks from the LTE radio era onward, phase
synchronization is needed in addition to frequency synchronization
([TS36300], [TS23401]).
6.1.3. Time-Sensitive Stream Requirements
In addition to the time synchronization requirements listed in In addition to the time synchronization requirements listed in
Section Section 6.3 the fronthaul networks assume practically error Section Section 6.1.2 the Fronthaul networks assume practically
free transport. The maximum bit error rate (BER) has been defined to error-free transport. The maximum bit error rate (BER) has been
be 10^-12. When packetized that would equal roughly to packet error defined to be 10^-12. When packetized that would imply a packet
rate (PER) of 2.4*10^-9 (assuming ~300 bytes packets). error rate (PER) of 2.4*10^-9 (assuming ~300 bytes packets).
Retransmitting lost packets and/or using forward error coding (FEC) Retransmitting lost packets and/or using forward error correction
to circumvent bit errors are practically impossible due additional (FEC) to circumvent bit errors is practically impossible due to the
incurred delay. Using redundant streams for better guarantees for additional delay incurred. Using redundant streams for better
delivery is also practically impossible due to high bandwidth guarantees for delivery is also practically impossible in many cases
requirements fronthaul networks have. For instance, current due to high bandwidth requirements of Fronthaul networks. For
uncompressed CPRI bandwidth expansion ratio is roughly 20:1 compared instance, current uncompressed CPRI bandwidth expansion ratio is
to the IP layer user payload it carries in a "radio sample form". roughly 20:1 compared to the IP layer user payload it carries.
Protection switching is also a candidate but current technologies for
the path switch are too slow. We do not currently know of a better
solution for this issue.
The other fundamental assumption is that fronthaul links are Fronthaul links are assumed to be symmetric, and all Fronthaul
symmetric. Last, all fronthaul streams (carrying radio data) have streams (i.e. those carrying radio data) have equal priority and
equal priority and cannot delay or pre-empt each other. This implies cannot delay or pre-empt each other. This implies that the network
the network has always be sufficiently under subscribed to guarantee must guarantee that each time-sensitive flow meets their schedule.
each time-sensitive flow meets their schedule.
Mapping the fronthaul requirements to [I-D.finn-detnet-architecture] 6.1.4. Security Considerations
Section 3 "Providing the DetNet Quality of Service" what is seemed
usable are:
(a) Zero congestion loss. Establishing time-sensitive streams in the network entails reserving
networking resources for long periods of time. It is important that
these reservation requests be authenticated to prevent malicious
reservation attempts from hostile nodes (or accidental
misconfiguration). This is particularly important in the case where
the reservation requests span administrative domains. Furthermore,
the reservation information itself should be digitally signed to
reduce the risk of a legitimate node pushing a stale or hostile
configuration into another networking node.
(b) Pinned-down paths. 6.2. Cellular Radio Networks Today
The current time-sensitive networking features may still not be Today's Fronthaul networks typically consist of:
sufficient for fronthaul traffic. Therefore, having specific
profiles that take the requirements of fronthaul into account are o Dedicated point-to-point fiber connection is common
deemed to be useful [IEEE8021CM].
o Proprietary protocols and framings
o Custom equipment and no real networking
Today's Midhaul and Backhaul networks typically consist of:
o Mostly normal IP networks, MPLS-TP, etc.
o Clock distribution and sync using 1588 and SyncE
Telecommunication networks in the cellular domain are already heading
towards transport networks where precise time synchronization support
is one of the basic building blocks. While the transport networks
themselves have practically transitioned to all-IP packet based
networks to meet the bandwidth and cost requirements, highly accurate
clock distribution has become a challenge.
Transport networks in the cellular domain are typically based on Time
Division Multiplexing (TDM-based) and provide frequency
synchronization capabilities as a part of the transport media.
Alternatively other technologies such as Global Positioning System
(GPS) or Synchronous Ethernet (SyncE) are used [SyncE].
Both Ethernet and IP/MPLS [RFC3031] (and PseudoWires (PWE) [RFC3985]
for legacy transport support) have become popular tools to build and
manage new all-IP Radio Access Networks (RAN)
[I-D.kh-spring-ip-ran-use-case]. Although various timing and
synchronization optimizations have already been proposed and
implemented including 1588 PTP enhancements
[I-D.ietf-tictoc-1588overmpls][I-D.mirsky-mpls-residence-time], these
solution are not necessarily sufficient for the forthcoming RAN
architectures or guarantee the higher time-synchronization
requirements [CPRI]. There are also existing solutions for the TDM
over IP [RFC5087] [RFC4553] or Ethernet transports [RFC5086].
6.3. Cellular Radio Networks Future
We would like to see the following in future Cellular Radio networks:
o Unified standards-based transport protocols and standard
networking equipment that can make use of underlying deterministic
link-layer services
o Unified and standards-based network management systems and
protocols in all parts of the network (including Fronthaul)
New radio access network deployment models and architectures may
require time sensitive networking services with strict requirements
on other parts of the network that previously were not considered to
be packetized at all. The time and synchronization support are
already topical for Backhaul and Midhaul packet networks [MEF], and
becoming a real issue for Fronthaul networks. Specifically in the
Fronthaul networks the timing and synchronization requirements can be
extreme for packet based technologies, for example, on the order of
sub +-20 ns packet delay variation (PDV) and frequency accuracy of
+0.002 PPM [Fronthaul].
The actual transport protocols and/or solutions to establish required The actual transport protocols and/or solutions to establish required
transport "circuits" (pinned-down paths) for fronthaul traffic are transport "circuits" (pinned-down paths) for Fronthaul traffic are
still undefined. Those are likely to include but not limited to still undefined. Those are likely to include (but are not limited
solutions directly over Ethernet, over IP, and MPLS/PseudoWire to) solutions directly over Ethernet, over IP, and MPLS/PseudoWire
transport. transport.
6.5. Security considerations Even the current time-sensitive networking features may not be
sufficient for Fronthaul traffic. Therefore, having specific
profiles that take the requirements of Fronthaul into account is
desirable [IEEE8021CM].
Establishing time-sensitive streams in the network entails reserving The really interesting and important existing work for time sensitive
networking resources sometimes for a considerable long time. It is networking has been done for Ethernet [TSNTG], which specifies the
important that these reservation requests must be authenticated to use of IEEE 1588 time precision protocol (PTP) [IEEE1588] in the
prevent malicious reservation attempts from hostile nodes or even context of IEEE 802.1D and IEEE 802.1Q. While IEEE 802.1AS
accidental misconfiguration. This is specifically important in a [IEEE8021AS] specifies a Layer-2 time synchronizing service other
case where the reservation requests span administrative domains. specification, such as IEEE 1722 [IEEE1722] specify Ethernet-based
Furthermore, the reservation information itself should be digitally Layer-2 transport for time-sensitive streams. New promising work
signed to reduce the risk where a legitimate node pushed a stale or seeks to enable the transport of time-sensitive fronthaul streams in
hostile configuration into the networking node. Ethernet bridged networks [IEEE8021CM]. Similarly to IEEE 1722 there
is an ongoing standardization effort to define Layer-2 transport
encapsulation format for transporting radio over Ethernet (RoE) in
IEEE 1904.3 Task Force [IEEE19043].
All-IP RANs and various "haul" networks would benefit from time
synchronization and time-sensitive transport services. Although
Ethernet appears to be the unifying technology for the transport
there is still a disconnect providing Layer-3 services. The protocol
stack typically has a number of layers below the Ethernet Layer-2
that shows up to the Layer-3 IP transport. It is not uncommon that
on top of the lowest layer (optical) transport there is the first
layer of Ethernet followed one or more layers of MPLS, PseudoWires
and/or other tunneling protocols finally carrying the Ethernet layer
visible to the user plane IP traffic. While there are existing
technologies, especially in MPLS/PWE space, to establish circuits
through the routed and switched networks, there is a lack of
signaling the time synchronization and time-sensitive stream
requirements/reservations for Layer-3 flows in a way that the entire
transport stack is addressed and the Ethernet layers that needs to be
configured are addressed.
Furthermore, not all "user plane" traffic will be IP. Therefore, the
same solution also must address the use cases where the user plane
traffic is again another layer or Ethernet frames. There is existing
work describing the problem statement
[I-D.finn-detnet-problem-statement] and the architecture
[I-D.finn-detnet-architecture] for deterministic networking (DetNet)
that targets solutions for time-sensitive (IP/transport) streams with
deterministic properties over Ethernet-based switched networks.
6.4. Cellular Radio Networks Asks
A standard for data plane transport specification which is:
o Unified among all *hauls
o Deployed in a highly deterministic network environment
A standard for data flow information models that are:
o Aware of the time sensitivity and constraints of the target
networking environment
o Aware of underlying deterministic networking services (e.g. on the
Ethernet layer)
Mapping the Fronthaul requirements to IETF DetNet
[I-D.finn-detnet-architecture] Section 3 "Providing the DetNet
Quality of Service", the relevant features are:
o Zero congestion loss.
o Pinned-down paths.
7. Industrial M2M 7. Industrial M2M
7.1. Use Case Description 7.1. Use Case Description
Industrial Automation in general refers to automation of Industrial Automation in general refers to automation of
manufacturing, quality control and material processing. 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 Machine to Machine (M2M) communication are Programmable The actors of M2M communication are Programmable Logic Controllers
Logic Controls (PLCs). The communication between PLCs and between (PLCs). Communication between PLCs and between PLCs and the
PLCs and the supervisory PLC (S-PLC) is achieved via critical supervisory PLC (S-PLC) is achieved via critical control/data streams
Control-Data-Streams Figure 10. Figure 10.
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 10: Current Generic Industrial M2M Network Architecture Figure 10: Current Generic Industrial M2M Network Architecture
This use case addresses 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 addresses only critical Control-Data-Streams; non- This use case covers only critical control/data streams; non-critical
critical traffic between industrial automation applications (such as traffic between industrial automation applications (such as
communication of state, configuration, set-up, connection to communication of state, configuration, set-up, and database
Manufacturing-Execution-System (MES) and database communication) are communication) are adequately served by currently available
adequately served by currently available prioritizing techniques. prioritizing techniques. Such traffic can use up to 80% of the total
Such traffic can use up to 80% of the total bandwidth required. bandwidth required. There is also a subset of non-time-critical
There is also a subset of non-time-critical traffic that must be traffic that must be reliable even though it is not time sensitive.
reliable even though it is not time critical.
In this use case the primary need for deterministic networking is to In this use case the primary need for deterministic networking is to
provide end-to-end delivery of M2M messages within specific timing provide end-to-end delivery of M2M messages within specific timing
constraints, for example in closed loop automation control. Today constraints, for example in closed loop automation control. Today
this level of determinism is provided by proprietary networking this level of determinism is provided by proprietary networking
technologies. In addition, standard networking technologies are used technologies. In addition, standard networking technologies are used
to connect the local network to remote industrial automation sites, to connect the local network to remote industrial automation sites,
e.g. over an enterprise or metro network which also carries other e.g. over an enterprise or metro network which also carries other
types of traffic. Therefore, deterministic flows need to be types of traffic. Therefore, flows that should be forwarded with
sustained regardless of the amount of other flows in those networks. deterministic guarantees need to be sustained regardless of the
amount of other flows in those networks.
7.2. Industrial M2M Communication Today 7.2. Industrial M2M Communication Today
Today, proprietary networks fulfill the needed timing and Today, proprietary networks fulfill the needed timing and
availability for M2M networks, as described in this section. availability for M2M networks.
The network topologies used today by industrial automation are The network topologies used today by industrial automation are
similar to those used by telecom networks: Daisy Chain, Ring, Hub and similar to those used by telecom networks: Daisy Chain, Ring, Hub and
Spoke, and Comb (a subset of Daisy Chain). Spoke, and Comb (a subset of Daisy Chain).
PLC-related Control-Data-Streams are transmitted periodically and PLC-related control/data streams are transmitted periodically and
they are established either with a pre-configured payload or a carry either a pre-configured payload or a payload configured during
payload configured during runtime. runtime.
Some industrial applications require time synchronization ("time Some industrial applications require time synchronization at the end
sync") at the end nodes. For such time-coordinated PLCs, accuracy of nodes. For such time-coordinated PLCs, accuracy of 1 microsecond is
1 microsecond is required. Even in the case of "non-time- required. Even in the case of "non-time-coordinated" PLCs time sync
coordinated" PLCs time sync may be needed e.g. for timestamping of may be needed e.g. for timestamping of sensor data.
sensor data.
Industrial network scenarios require advanced security solutions. Industrial network scenarios require advanced security solutions.
Many of the current industrial production networks are physically Many of the current industrial production networks are physically
separated. Protection of critical flows are handled today by separated. Preventing critical flows from be leaked outside a domain
gateways / firewalls. is handled today by filtering policies that are typically enforced in
firewalls.
7.2.1. Transport Parameters 7.2.1. Transport Parameters
The Cycle Time defines the frequency of message(s) between industrial The Cycle Time defines the frequency of message(s) between industrial
actors. The Cycle Time is application dependent, in the range of 1ms actors. The Cycle Time is application dependent, in the range of 1ms
- 100ms for critical Control-Data-Streams. - 100ms for critical control/data streams.
Because industrial applications assume deterministic transport for Because industrial applications assume deterministic transport for
critical Control-Data-Stream parameters (instead of defining latency critical Control-Data-Stream parameters (instead of defining latency
and delay variation parameters) it is sufficient to fulfill the upper and delay variation parameters) it is sufficient to fulfill the upper
bound of latency (maximum latency). The communication must ensure a bound of latency (maximum latency). The underlying networking
maximum end to end delivery time of messages in the range of 100 infrastructure must ensure a maximum end-to-end delivery time of
microseconds to 50 milliseconds depending on the control loop messages in the range of 100 microseconds to 50 milliseconds
application. depending on the control loop application.
Bandwidth requirements of Control-Data-Streams are usually calculated The bandwidth requirements of control/data streams are usually
directly from the bytes-per-cycle parameter of the control loop. For calculated directly from the bytes-per-cycle parameter of the control
PLC-to-PLC communication one can expect 2 - 32 streams with packet loop. For PLC-to-PLC communication one can expect 2 - 32 streams
size in the range of 100 - 700 bytes. For S-PLC to PLCs the number with packet size in the range of 100 - 700 bytes. For S-PLC to PLCs
of streams is higher - up to 256 streams. Usually no more than 20% the number of streams is higher - up to 256 streams. Usually no more
of available bandwidth is used for critical Control-Data-Streams. In than 20% of available bandwidth is used for critical control/data
today's networks 1Gbps links are commonly used. streams. In today's networks 1Gbps links are commonly used.
Most PLC control loops are rather tolerant of packet loss, however Most PLC control loops are rather tolerant of packet loss, however
critical Control-Data-Streams accept no more than 1 packet loss per critical control/data streams accept no more than 1 packet loss per
consecutive communication cycle (i.e. if a packet gets lost in cycle consecutive communication cycle (i.e. if a packet gets lost in cycle
"n", then the next cycle ("n+1") must be lossless). After two or "n", then the next cycle ("n+1") must be lossless). After two or
more consecutive packet losses the network may be considered to be more consecutive packet losses the network may be considered to be
"down" by the Application. "down" by the Application.
As network downtime may impact the whole production system the As network downtime may impact the whole production system the
required network availability is rather high (99,999%). required network availability is rather high (99,999%).
Based on the above parameters we expect that some form of redundancy Based on the above parameters we expect that some form of redundancy
will be required for M2M communications, however any individual will be required for M2M communications, however any individual
solution depends on several parameters including cycle time, delivery solution depends on several parameters including cycle time, delivery
time, etc. time, etc.
7.2.2. Stream Creation and Destruction 7.2.2. Stream Creation and Destruction
In an industrial environment, critical Control-Data-Streams are In an industrial environment, critical control/data streams are
created rather infrequently, on the order of ~10 times per day / week created rather infrequently, on the order of ~10 times per day / week
/ month. Most of these critical Control-Data-Streams get created at / month. Most of these critical control/data streams get created at
machine startup, however flexibility is also needed during runtime, machine startup, however flexibility is also needed during runtime,
for example when adding or removing a machine. Going forward as for example when adding or removing a machine. Going forward as
production systems become more flexible, we expect a significant production systems become more flexible, we expect a significant
increase in the rate at which streams are created, changed and increase in the rate at which streams are created, changed and
destroyed. destroyed.
7.3. Industrial M2M Future 7.3. Industrial M2M Future
We would like to see the various proprietary networks replaced with a We would like to see the various proprietary networks replaced with a
converged standards-based network with deterministic properties that converged IP-standards-based network with deterministic properties
can satisfy the timing and reliability constraints described above. that can satisfy the timing, security and reliability constraints
described above.
7.4. Industrial M2M Asks 7.4. Industrial M2M Asks
We can summarize the current requirements stated above as follows: o Converged IP-based network
+-------------------------+--------------+ o Deterministic behavior (bounded latency and jitter )
| Metric | Requirement |
+-------------------------+--------------+
| Sync Accuracy | 1 usec |
| | |
| Message Delivery Time | 100us - 50ms |
| | |
| Packet loss (burstless) | 0.1-1 % |
| | |
| Availability | 99.999 % |
+-------------------------+--------------+
Table 14: Actor-to-Actor Timing Parameters o High availability (presumably through redundancy) (99.999 %)
7.5. Acknowledgements o Low message delivery time (100us - 50ms)
The authors would like to thank Feng Chen and Marcel Kiessling for o Low packet loss (burstless, 0.1-1 %)
their comments and suggestions.
8. Other Use Cases o Precise time synchronization accuracy (1us)
(This section was derived from draft-zha-detnet-use-case-00) o Security (e.g. prevent critical flows from being leaked between
physically separated networks)
8. Other Use Cases
8.1. Introduction 8.1. Introduction
The rapid growth of the today's communication system and its access The rapid growth of the today's communication system and its access
into almost all aspects of daily life has led to great dependency on into almost all aspects of daily life has led to great dependency on
services it provides. The communication network, as it is today, has services it provides. The communication network, as it is today, has
applications such as multimedia and peer-to-peer file sharing applications such as multimedia and peer-to-peer file sharing
distribution that require Quality of Service (QoS) guarantees in distribution that require Quality of Service (QoS) guarantees in
terms of delay and jitter to maintain a certain level of performance. terms of delay and jitter to maintain a certain level of performance.
Meanwhile, mobile wireless communications has become an important Meanwhile, mobile wireless communications has become an important
skipping to change at page 72, line 46 skipping to change at page 69, line 32
o High availability (99.9999 percent up time requested, but may be o High availability (99.9999 percent up time requested, but may be
up to twelve 9s) up to twelve 9s)
o Reliability, redundancy (lives at stake) o Reliability, redundancy (lives at stake)
o Security (from failures, attackers, misbehaving devices - o Security (from failures, attackers, misbehaving devices -
sensitive to both packet content and arrival time) sensitive to both packet content and arrival time)
10. Acknowledgments 10. Acknowledgments
10.1. Pro Audio
This section was derived from draft-gunther-detnet-proaudio-req-01.
The editors would like to acknowledge the help of the following
individuals and the companies they represent:
Jeff Koftinoff, Meyer Sound
Jouni Korhonen, Associate Technical Director, Broadcom
Pascal Thubert, CTAO, Cisco
Kieran Tyrrell, Sienda New Media Technologies GmbH
10.2. Utility Telecom
This section was derived from draft-wetterwald-detnet-utilities-reqs-
02.
Faramarz Maghsoodlou, Ph. D. IoT Connected Industries and Energy
Practice Cisco
Pascal Thubert, CTAO Cisco
10.3. Building Automation Systems
This section was derived from draft-bas-usecase-detnet-00.
10.4. Wireless for Industrial
This section was derived from draft-thubert-6tisch-4detnet-01.
This specification derives from the 6TiSCH architecture, which is the
result of multiple interactions, in particular during the 6TiSCH
(bi)Weekly Interim call, relayed through the 6TiSCH mailing list at
the IETF.
The authors wish to thank: Kris Pister, Thomas Watteyne, Xavier
Vilajosana, Qin Wang, Tom Phinney, Robert Assimiti, Michael
Richardson, Zhuo Chen, Malisa Vucinic, Alfredo Grieco, Martin Turon,
Dominique Barthel, Elvis Vogli, Guillaume Gaillard, Herman Storey,
Maria Rita Palattella, Nicola Accettura, Patrick Wetterwald, Pouria
Zand, Raghuram Sudhaakar, and Shitanshu Shah for their participation
and various contributions.
10.5. Cellular Radio
This section was derived from draft-korhonen-detnet-telreq-00.
10.6. Industrial M2M
The authors would like to thank Feng Chen and Marcel Kiessling for
their comments and suggestions.
10.7. Other
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.
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/>.
 End of changes. 125 change blocks. 
704 lines changed or deleted 621 lines changed or added

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