draft-ietf-detnet-use-cases-01.txt   draft-ietf-detnet-use-cases-02.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 12, 2016 HARMAN Expires: August 13, 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 9, 2016 February 10, 2016
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-01 draft-ietf-detnet-use-cases-02
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 12, 2016. This Internet-Draft will expire on August 13, 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . 9 2.3. Additional Stream Requirements . . . . . . . . . . . . . 8
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 . . . . . . . 10 2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9
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 . . . . . . . . . . . . . . . . . 11 2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 10
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 . . . . 12 2.4. Integration of Reserved Streams into IT Networks . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 Limits . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 15 Requirements . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. General Telecommunications Requirements . . . . . . . 15 3.2.1. General Telecommunications Requirements . . . . . . . 14
3.2.1.1. Migration to Packet-Switched Network . . . . . . 16 3.2.1.1. Migration to Packet-Switched Network . . . . . . 15
3.2.2. Applications, Use cases and traffic patterns . . . . 17 3.2.2. Applications, Use cases and traffic patterns . . . . 16
3.2.2.1. Transmission use cases . . . . . . . . . . . . . 17 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 3.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 35
4. Building Automation Systems Use Cases . . . . . . . . . . . . 35 4. Building Automation Systems Use Cases . . . . . . . . . . . . 35
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36
4.2. BAS Functionality . . . . . . . . . . . . . . . . . . . . 36 4.2. BAS Functionality . . . . . . . . . . . . . . . . . . . . 36
4.3. BAS Architecture . . . . . . . . . . . . . . . . . . . . 37 4.3. BAS Architecture . . . . . . . . . . . . . . . . . . . . 37
4.4. Deployment Model . . . . . . . . . . . . . . . . . . . . 39 4.4. Deployment Model . . . . . . . . . . . . . . . . . . . . 38
4.5. Use cases and Field Network Requirements . . . . . . . . 40 4.5. Use cases and Field Network Requirements . . . . . . . . 40
4.5.1. Environmental Monitoring . . . . . . . . . . . . . . 41 4.5.1. Environmental Monitoring . . . . . . . . . . . . . . 40
4.5.2. Fire Detection . . . . . . . . . . . . . . . . . . . 41 4.5.2. Fire Detection . . . . . . . . . . . . . . . . . . . 40
4.5.3. Feedback Control . . . . . . . . . . . . . . . . . . 42 4.5.3. Feedback Control . . . . . . . . . . . . . . . . . . 41
4.6. Security Considerations . . . . . . . . . . . . . . . . . 43 4.6. Security Considerations . . . . . . . . . . . . . . . . . 42
5. Wireless for Industrial Use Cases . . . . . . . . . . . . . . 44 5. Wireless for Industrial Use Cases . . . . . . . . . . . . . . 43
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 44 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 43
5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 45 5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 44
5.3. 6TiSCH Overview . . . . . . . . . . . . . . . . . . . . . 45 5.3. 6TiSCH Overview . . . . . . . . . . . . . . . . . . . . . 44
5.3.1. TSCH and 6top . . . . . . . . . . . . . . . . . . . . 48 5.3.1. TSCH and 6top . . . . . . . . . . . . . . . . . . . . 47
5.3.2. SlotFrames and Priorities . . . . . . . . . . . . . . 48 5.3.2. SlotFrames and Priorities . . . . . . . . . . . . . . 47
5.3.3. Schedule Management by a PCE . . . . . . . . . . . . 48 5.3.3. Schedule Management by a PCE . . . . . . . . . . . . 47
5.3.4. Track Forwarding . . . . . . . . . . . . . . . . . . 49 5.3.4. Track Forwarding . . . . . . . . . . . . . . . . . . 48
5.3.4.1. Transport Mode . . . . . . . . . . . . . . . . . 51 5.3.4.1. Transport Mode . . . . . . . . . . . . . . . . . 50
5.3.4.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . 52 5.3.4.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . 51
5.3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . 53 5.3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . 52
5.4. Operations of Interest for DetNet and PCE . . . . . . . . 54 5.4. Operations of Interest for DetNet and PCE . . . . . . . . 53
5.4.1. Packet Marking and Handling . . . . . . . . . . . . . 55 5.4.1. Packet Marking and Handling . . . . . . . . . . . . . 54
5.4.1.1. Tagging Packets for Flow Identification . . . . . 55 5.4.1.1. Tagging Packets for Flow Identification . . . . . 54
5.4.1.2. Replication, Retries and Elimination . . . . . . 55 5.4.1.2. Replication, Retries and Elimination . . . . . . 54
5.4.1.3. Differentiated Services Per-Hop-Behavior . . . . 56 5.4.1.3. Differentiated Services Per-Hop-Behavior . . . . 55
5.4.2. Topology and capabilities . . . . . . . . . . . . . . 56 5.4.2. Topology and capabilities . . . . . . . . . . . . . . 55
5.5. Security Considerations . . . . . . . . . . . . . . . . . 57 5.5. Security Considerations . . . . . . . . . . . . . . . . . 56
5.6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 57 5.6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 56
6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 57 6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 56
6.1. Introduction and background . . . . . . . . . . . . . . . 57 6.1. Introduction and background . . . . . . . . . . . . . . . 56
6.2. Network architecture . . . . . . . . . . . . . . . . . . 61 6.2. Network architecture . . . . . . . . . . . . . . . . . . 60
6.3. Time synchronization requirements . . . . . . . . . . . . 62 6.3. Time synchronization requirements . . . . . . . . . . . . 61
6.4. Time-sensitive stream requirements . . . . . . . . . . . 63 6.4. Time-sensitive stream requirements . . . . . . . . . . . 62
6.5. Security considerations . . . . . . . . . . . . . . . . . 64 6.5. Security considerations . . . . . . . . . . . . . . . . . 63
7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 64 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 63
7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 65 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 64
7.2. Terminology and Definitions . . . . . . . . . . . . . . . 65 7.2. Industrial M2M Communication Today . . . . . . . . . . . 65
7.3. Machine to Machine communication over IP networks . . . . 65 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 65
7.4. Machine to Machine communication requirements . . . . . . 66 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 66
7.4.1. Transport parameters . . . . . . . . . . . . . . . . 67 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 66
7.4.2. Flow maintenance . . . . . . . . . . . . . . . . . . 67 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 66
7.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 67
7.6. Security Considerations . . . . . . . . . . . . . . . . . 68 8. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 67
7.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 68 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 67
8. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 68 8.2. Critical Delay Requirements . . . . . . . . . . . . . . . 68
8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 68 8.3. Coordinated multipoint processing (CoMP) . . . . . . . . 69
8.2. Critical Delay Requirements . . . . . . . . . . . . . . . 69 8.3.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 69
8.3. Coordinated multipoint processing (CoMP) . . . . . . . . 70 8.3.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 70
8.3.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 70 8.4. Industrial Automation . . . . . . . . . . . . . . . . . . 70
8.3.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 71 8.5. Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . 70
8.4. Industrial Automation . . . . . . . . . . . . . . . . . . 71 8.6. Gaming, Media and Virtual Reality . . . . . . . . . . . . 71
8.5. Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . 71 9. Use Case Common Elements . . . . . . . . . . . . . . . . . . 71
8.6. Gaming, Media and Virtual Reality . . . . . . . . . . . . 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72
9. Use Case Common Elements . . . . . . . . . . . . . . . . . . 72
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73
11. Informative References . . . . . . . . . . . . . . . . . . . 73 11. Informative References . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
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?)
For DetNet, use cases explicitly do not define requirements; The For DetNet, use cases explicitly do not define requirements; The
DetNet WG will consider the use cases, decide which elements are in DetNet WG will consider the use cases, decide which elements are in
scope for DetNet, and the results will be incorporated into future scope for DetNet, and the results will be incorporated into future
drafts. Similarly, the DetNet use case draft explicitly does not drafts. Similarly, the DetNet use case draft explicitly does not
suggest any specific design, architecture or protocols, which will be suggest any specific design, architecture or protocols, which will be
topics of future drafts. topics of future drafts.
We present for each use case the answers to the following questions: We present for each use case the answers to the following questions:
o What is the use case? o What is the use case?
skipping to change at page 7, line 24 skipping to change at page 7, line 22
example the amount of time delay between when you speak into a example the amount of time delay between when you speak into a
microphone and when your voice emerges from the speaker. Any delay microphone and when your voice emerges from the speaker. Any delay
longer than about 10-15 milliseconds is noticeable by most live longer than about 10-15 milliseconds is noticeable by most live
performers, and greater latency makes the system unusable because it performers, and greater latency makes the system unusable because it
prevents them from playing in time with the other players (see slide prevents them from playing in time with the other players (see slide
6 of [SRP_LATENCY]). 6 of [SRP_LATENCY]).
The 15ms latency bound is made even more challenging because it is The 15ms latency bound is made even more challenging because it is
often the case in network based music production with live electric often the case in network based music production with live electric
instruments that multiple stages of signal processing are used, instruments that multiple stages of signal processing are used,
connected in series (i.e. from one to the other for example from connected in series (i.e. from one to the other for example from
guitar through a series of digital effects processors) in which case guitar through a series of digital effects processors) in which case
the latencies add, so the latencies of each individual stage must all the latencies add, so the latencies of each individual stage must all
together remain less than 15ms. together remain less than 15ms.
In some situations it is acceptable at the local location for content In some situations it is acceptable at the local location for content
from the live remote site to be delayed to allow for a statistically from the live remote site to be delayed to allow for a statistically
acceptable amount of latency in order to reduce jitter. However, acceptable amount of latency in order to reduce jitter. However,
once the content begins playing in the local location any audio once the content begins playing in the local location any audio
artifacts caused by the local network are unacceptable, especially in artifacts caused by the local network are unacceptable, especially in
those situations where a live local performer is mixed into the feed those situations where a live local performer is mixed into the feed
skipping to change at page 37, line 29 skipping to change at page 37, line 29
o Controls devices on demand. o Controls devices on demand.
o Controls devices with a pre-defined operation schedule (e.g., turn o Controls devices with a pre-defined operation schedule (e.g., turn
off room lights at 10:00 PM). off room lights at 10:00 PM).
4.3. BAS Architecture 4.3. BAS Architecture
A typical BAS architecture is described below in Figure 1. There are A typical BAS architecture is described below in Figure 1. There are
several elements in a BAS. several elements in a BAS.
+----------------------------+ +----------------------------+ | | | BMS HMI | | | | |
| | | +----------------------+ | | | Management Network | | |
| BMS HMI | +----------------------+ | | | | | | LC LC | | | | | |
| | | | +----------------------+ | | | Field Network | | | +----------------------+
| +----------------------+ | | | | | | | | | Dev Dev Dev Dev | | | +----------------------------+ BMS :=
| | Management Network | | Building Management Server HMI := Human Machine Interface LC := Local
| +----------------------+ | Controller
| | | |
| LC LC |
| | | |
| +----------------------+ |
| | Field Network | |
| +----------------------+ |
| | | | | |
| Dev Dev Dev Dev |
| |
+----------------------------+
BMS := Building Management Server
HMI := Human Machine Interface
LC := Local Controller
Figure 1: BAS architecture Figure 1: BAS architecture
Human Machine Interface (HMI): It is commonly a computing platform Human Machine Interface (HMI): It is commonly a computing platform
(e.g., desktop PC) used by operators. Operators perform the (e.g., desktop PC) used by operators. Operators perform the
following operations through HMI. following operations through HMI.
o Monitoring devices: HMI displays measured device states. For o Monitoring devices: HMI displays measured device states. For
example, latest device states, a history chart of states, a popup example, latest device states, a history chart of states, a popup
window with an alert message. Typically, the measured device window with an alert message. Typically, the measured device
skipping to change at page 39, line 23 skipping to change at page 39, line 7
4.4. Deployment Model 4.4. Deployment Model
An example BAS system deployment model for medium and large buildings An example BAS system deployment model for medium and large buildings
is depicted in Figure 2 below. In this case the physical layout of is depicted in Figure 2 below. In this case the physical layout of
the entire system spans across multiple floors in which there is the entire system spans across multiple floors in which there is
normally a monitoring room where the BAS management entities are normally a monitoring room where the BAS management entities are
located. Each floor will have one or more LCs depending upon the located. Each floor will have one or more LCs depending upon the
number of devices connected to the field network. number of devices connected to the field network.
+--------------------------------------------------+ +--------------------------------------------------+ |
| Floor 3 | Floor 3 | | +----LC~~~~+~~~~~+~~~~~+ | | | | | | | | | Dev Dev Dev | | | |
| +----LC~~~~+~~~~~+~~~~~+ | |--- | ------------------------------------------| | | Floor 2 | |
| | | | | | +----LC~~~~+~~~~~+~~~~~+ Field Network | | | | | | | | | Dev Dev Dev | | | |
| | Dev Dev Dev | |--- | ------------------------------------------| | | Floor 1 | |
| | | +----LC~~~~+~~~~~+~~~~~+ +-----------------| | | | | | | Monitoring Room | |
|--- | ------------------------------------------| | Dev Dev Dev | | | | | BMS HMI | | | Management Network | | | | |
| | 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 Figure 2: Deployment model for Medium/Large Buildings
Each LC is then connected to the monitoring room via the management Each LC is then connected to the monitoring room via the management
network. In this scenario, the management functions are performed network. In this scenario, the management functions are performed
locally and reside within the building. In most cases, fast Ethernet locally and reside within the building. In most cases, fast Ethernet
(e.g. 100BASE-TX) is used for the management network. In the field (e.g. 100BASE-TX) is used for the management network. In the field
network, variety of physical interfaces such as RS232C, and RS485 are network, variety of physical interfaces such as RS232C, and RS485 are
used. Since management network is non-real time, Ethernet without used. Since management network is non-real time, Ethernet without
quality of service is sufficient for today's deployment. However, quality of service is sufficient for today's deployment. However,
skipping to change at page 40, line 17 skipping to change at page 39, line 37
replaced by either Ethernet or any wireless technologies supporting replaced by either Ethernet or any wireless technologies supporting
real time requirements (Section 3.4). real time requirements (Section 3.4).
Figure 3 depicts a deployment model in which the management can be Figure 3 depicts a deployment model in which the management can be
hosted remotely. This deployment is becoming popular for small hosted remotely. This deployment is becoming popular for small
office and residential buildings whereby having a standalone office and residential buildings whereby having a standalone
monitoring system is not a cost effective solution. In such monitoring system is not a cost effective solution. In such
scenario, multiple buildings are managed by a remote management scenario, multiple buildings are managed by a remote management
monitoring system. monitoring system.
+---------------+ +---------------+ | Remote Center | | | | BMS HMI |
| Remote Center | +------------------------------------+ | | | | | Floor 2 | | +---+---+ | |
| | +----LC~~~~+~~~~~+ Field Network| | | | | | | | | | Router | | | Dev Dev |
| BMS HMI | +-------|-------+ | | | | |--- | ------------------------------| | | | Floor
+------------------------------------+ | | | | 1 | | | +----LC~~~~+~~~~~+ | | | | | | | | | | Dev Dev | | | | | | | |
| Floor 2 | | +---+---+ | Management Network | WAN | | +------------------------Router-------------+ |
| +----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 In either case, interoperability today is only limited to the
management network and its protocols. In existing deployment, there management network and its protocols. In existing deployment, there
are limited interoperability opportunity in the field network due to are limited interoperability opportunity in the field network due to
its nature of non-IP-based design and requirements. its nature of non-IP-based design and requirements.
4.5. Use cases and Field Network Requirements 4.5. Use cases and Field Network Requirements
skipping to change at page 64, line 47 skipping to change at page 64, line 4
networking resources sometimes for a considerable long time. It is networking resources sometimes for a considerable long time. It is
important that these reservation requests must be authenticated to important that these reservation requests must be authenticated to
prevent malicious reservation attempts from hostile nodes or even prevent malicious reservation attempts from hostile nodes or even
accidental misconfiguration. This is specifically important in a accidental misconfiguration. This is specifically important in a
case where the reservation requests span administrative domains. case where the reservation requests span administrative domains.
Furthermore, the reservation information itself should be digitally Furthermore, the reservation information itself should be digitally
signed to reduce the risk where a legitimate node pushed a stale or signed to reduce the risk where a legitimate node pushed a stale or
hostile configuration into the networking node. hostile configuration into the networking node.
7. Industrial M2M 7. Industrial M2M
7.1. Use Case Description
(This section was derived from draft-varga-industrial-m2m-00) Industrial Automation in general refers to automation of
manufacturing, quality control and material processing. In this
7.1. Introduction "machine to machine" (M2M) use case we consider machine units in a
plant floor which periodically exchange data with upstream or
Traditional "industrial automation" and terminology usually refers to downstream machine modules and/or a supervisory controller within a
automation of manufacturing, quality control and material processing. local area network.
In practice, it means that machine units in a plant floor need cyclic
control data exchange to upstream or downstream machine modules or to
a supervisory control in a local network, which is often based on
proprietary networking technologies today.
For such communication between industrial entities, it is critical to
ensure proper and deterministic end to end delivery time of messages
with (very) high reliability and robustness, especially in closed
loop automation control.
Moreover, the recent trend is to use standard networking technologies
in the local network and for connecting remote industrial automation
sites, e.g., over an enterprise or metro network which also carries
other types of traffic. Therefore, deterministic flows should be
guaranteed regardless of the amount of other flows in those networks
for the deployment of future industrial automation.
This document covers a selected industrial application, identifies
representative solutions used today, and points on new use cases an
IETF DetNet solution may enable.
7.2. Terminology and Definitions
DetNet: Deterministic Networking. [IETFDetNet]
M2M: Machine to Machine.
MES: Manufacturing-Execution-System.
PLC: Programmable Logic Control.
S-PLC: Supervisory Programmable Logic Control.
7.3. Machine to Machine communication over IP networks
In case of industrial automation, the actors of Machine to Machine The actors of Machine to Machine (M2M) communication are Programmable
(M2M) communication are Programmable Logic Controls (PLC). The Logic Controls (PLCs). The communication between PLCs and between
communication between PLCs and between PLCs and the supervisory PLC PLCs and the supervisory PLC (S-PLC) is achieved via critical
(S-PLC) is achieved via critical Control-Data-Streams Figure 10. Control-Data-Streams Figure 10.
This draft focuses on PLC related communications and communication to
Manufacturing-Execution-System (MES) are out-of-scope. The PLC
related Control-Data-Streams are transmitted periodically and they
are established either with (i) a pre-configured payload or (ii) a
payload configuration during runtime.
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
The network topologies used today by applications of industrial This use case addresses PLC-related communications; communication to
automation are (i) daisy chain, (ii) ring and (iii) hub and spoke. Manufacturing-Execution-Systems (MESs) are not addressed.
Such topologies are often used in telecommunication networks too. In
industrial networks comb (being a subset of daisy-chain) is also
used.
Some industrial applications require Time Synchronization (Sync) to This use case addresses only critical Control-Data-Streams; non-
end nodes, which is also similar to some telecommunication networks, critical traffic between industrial automation applications (such as
e.g., mobile Radio Access Networks. For such time coordinated PLCs, communication of state, configuration, set-up, connection to
accuracy of 1 microseconds is required. In case of non-time Manufacturing-Execution-System (MES) and database communication) are
coordinated PLCs, a requirement for Time Sync may still exist, e.g., adequately served by currently available prioritizing techniques.
for time stamping of collected measurement (sensor) data. Such traffic can use up to 80% of the total bandwidth required.
There is also a subset of non-time-critical traffic that must be
reliable even though it is not time critical.
7.4. Machine to Machine communication requirements In this use case the primary need for deterministic networking is to
provide end-to-end delivery of M2M messages within specific timing
constraints, for example in closed loop automation control. Today
this level of determinism is provided by proprietary networking
technologies. In addition, standard networking technologies are used
to connect the local network to remote industrial automation sites,
e.g. over an enterprise or metro network which also carries other
types of traffic. Therefore, deterministic flows need to be
sustained regardless of the amount of other flows in those networks.
The requirements listed here refer to critical Control-Data-Streams. 7.2. Industrial M2M Communication Today
Non-critical traffic of industrial automation applications can be
served with currently available prioritizing techniques.
In an industrial environment, non-time-critical traffic is related to Today, proprietary networks fulfill the needed timing and
(i) communication of state, configuration, set-up, etc., (ii) availability for M2M networks, as described in this section.
connection to Manufacturing-Execution-System (MES) and (iii) database
communication. Such type of traffic can use up to 80% of the
available bandwidth. There is a subset of non-time-critical traffic
that their bandwidth should be guaranteed.
The rest of this chapter is dealing only with time-critical traffic. The network topologies used today by industrial automation are
similar to those used by telecom networks: Daisy Chain, Ring, Hub and
Spoke, and Comb (a subset of Daisy Chain).
7.4.1. Transport parameters PLC-related Control-Data-Streams are transmitted periodically and
they are established either with a pre-configured payload or a
payload configured during runtime.
Some industrial applications require time synchronization ("time
sync") at the end nodes. For such time-coordinated PLCs, accuracy of
1 microsecond is required. Even in the case of "non-time-
coordinated" PLCs time sync may be needed e.g. for timestamping of
sensor data.
Industrial network scenarios require advanced security solutions.
Many of the current industrial production networks are physically
separated. Protection of critical flows are handled today by
gateways / firewalls.
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
entities. The Cycle Time is application dependent, it is in the actors. The Cycle Time is application dependent, in the range of 1ms
range of 1ms - 100ms for critical Control-Data-Streams. - 100ms for critical Control-Data-Streams.
As industrial applications assume deterministic transport instead of Because industrial applications assume deterministic transport for
defining latency and delay variation parameters for critical Control- critical Control-Data-Stream parameters (instead of defining latency
Data-Stream parameters, it is enough to fulfill the upper bound of and delay variation parameters) it is sufficient to fulfill the upper
latency (maximum latency). The communication must ensure a maximum bound of latency (maximum latency). The communication must ensure a
end to end delivery time of messages in the range of 100 microseconds maximum end to end delivery time of messages in the range of 100
to 50 milliseconds depending on the control loop application. microseconds to 50 milliseconds depending on the control loop
application.
Bandwidth requirements of Control-Data-Streams are usually calculated Bandwidth requirements of Control-Data-Streams are usually calculated
directly from the bytes per cycle parameter of the control loop. For directly from the bytes-per-cycle parameter of the control loop. For
PLC to PLC communication one can expect 2 - 32 streams with packet PLC-to-PLC communication one can expect 2 - 32 streams with packet
size in the range of 100 - 700 bytes. For S-PLC to PLCs the number size in the range of 100 - 700 bytes. For S-PLC to PLCs the number
of streams is higher up-to 256 streams need to be supported. Usually of streams is higher - up to 256 streams. Usually no more than 20%
no more than 20% of available bandwidth is used for critical Control- of available bandwidth is used for critical Control-Data-Streams. In
Data-Streams in today's networks, which comprise Gbps links. today's networks 1Gbps links are commonly used.
Usual PLC control loops are rather tolerant for packet loss. 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 cycles. The required network availability consecutive communication cycle (i.e. if a packet gets lost in cycle
is rather high, it hits the 5 nines (99,999%). "n", then the next cycle ("n+1") must be lossless). After two or
more consecutive packet losses the network may be considered to be
"down" by the Application.
Based on the above parameters, it can be concluded that some form of As network downtime may impact the whole production system the
redundancy might be required for M2M communication. The actual required network availability is rather high (99,999%).
solution depends on several parameters, like cycle time, delivery
Based on the above parameters we expect that some form of redundancy
will be required for M2M communications, however any individual
solution depends on several parameters including cycle time, delivery
time, etc. time, etc.
7.4.2. Flow maintenance 7.2.2. Stream Creation and Destruction
Most Critical Control-Data-Streams get created at startup, however, In an industrial environment, critical Control-Data-Streams are
flexibility is also needed during runtime (e.g. add / remove created rather infrequently, on the order of ~10 times per day / week
machine). In an industrial environment, critical Control-Data- / month. Most of these critical Control-Data-Streams get created at
Streams are created rather infrequent: ~10 times per day / week / machine startup, however flexibility is also needed during runtime,
month. With the future advent of flexible production systems, flow for example when adding or removing a machine. Going forward as
maintenance parameters are expected to increase significantly. production systems become more flexible, we expect a significant
increase in the rate at which streams are created, changed and
destroyed.
7.5. Summary 7.3. Industrial M2M Future
This document specifies an industrial machine-to-machine use-case in We would like to see the various proprietary networks replaced with a
the DetNet context. converged standards-based network with deterministic properties that
can satisfy the timing and reliability constraints described above.
7.6. Security Considerations 7.4. Industrial M2M Asks
Industrial network scenarios require advanced security solutions. We can summarize the current requirements stated above as follows:
Many of the current industrial production networks are physically
separated. Protection of critical flows are handled today by
gateways / firewalls.
7.7. Acknowledgements +-------------------------+--------------+
| 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
7.5. Acknowledgements
The authors would like to thank Feng Chen and Marcel Kiessling for The authors would like to thank Feng Chen and Marcel Kiessling for
their comments and suggestions. their comments and suggestions.
8. Other Use Cases 8. Other Use Cases
(This section was derived from draft-zha-detnet-use-case-00) (This section was derived from draft-zha-detnet-use-case-00)
8.1. Introduction 8.1. Introduction
skipping to change at page 77, line 40 skipping to change at page 76, line 40
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks". Wireless Personal Area Networks".
[IEEE802154e] [IEEE802154e]
IEEE standard for Information Technology, "IEEE standard IEEE standard for Information Technology, "IEEE standard
for Information Technology, IEEE std. 802.15.4, Part. for Information Technology, IEEE std. 802.15.4, Part.
15.4: Wireless Medium Access Control (MAC) and Physical 15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks, June 2011 as amended by IEEE std. Area Networks, June 2011 as amended by IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer", April Networks (LR-WPANs) Amendment 1: MAC sublayer", April
2012. 2012.
[IEEE8021AS] [IEEE8021AS]
IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)",
IEEE 802.1AS-2001, 2011, IEEE 802.1AS-2001, 2011,
<http://standards.ieee.org/getIEEE802/ <http://standards.ieee.org/getIEEE802/
download/802.1AS-2011.pdf>. download/802.1AS-2011.pdf>.
[IEEE8021CM] [IEEE8021CM]
 End of changes. 43 change blocks. 
240 lines changed or deleted 199 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/