draft-ietf-detnet-use-cases-09.txt   draft-ietf-detnet-use-cases-10.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: September 22, 2016 HARMAN Expires: January 5, 2017 HARMAN
P. Thubert P. Thubert
P. Wetterwald P. Wetterwald
CISCO CISCO
J. Raymond J. Raymond
HYDRO-QUEBEC HYDRO-QUEBEC
J. Korhonen J. Korhonen
BROADCOM BROADCOM
Y. Kaneko Y. Kaneko
Toshiba Toshiba
S. Das S. Das
Applied Communication Sciences Applied Communication Sciences
Y. Zha Y. Zha
HUAWEI HUAWEI
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
F. Goetz F. Goetz
J. Schmitt J. Schmitt
Siemens Siemens
March 21, 2016 July 4, 2016
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-09 draft-ietf-detnet-use-cases-10
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 September 22, 2016. This Internet-Draft will expire on January 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 5 2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 5
2.1. Use Case Description . . . . . . . . . . . . . . . . . . 5 2.1. Use Case Description . . . . . . . . . . . . . . . . . . 5
2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6 2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6
2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 6 2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 6
2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7 2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7
2.1.4. Deterministic Time to Establish Streaming . . . . . . 7 2.1.4. Deterministic Time to Establish Streaming . . . . . . 8
2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8 2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8
2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8 2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8
2.1.5.2. Digital Rights Management (DRM) . . . . . . . . . 8 2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 8
2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 9
2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9 2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9 2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9
2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9 2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9
2.3.3. Link Aggregation . . . . . . . . . . . . . . . . . . 9 2.3.3. Integration of Reserved Streams into IT Networks . . 9
2.3.4. Integration of Reserved Streams into IT Networks . . 10 2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 9
2.3.5. Use of Unused Reservations by Best-Effort Traffic . . 10 2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10
2.3.6. Traffic Segregation . . . . . . . . . . . . . . . . . 10 2.3.5.1. Packet Forwarding Rules, VLANs and Subnets . . . 10
2.3.6.1. Packet Forwarding Rules, VLANs and Subnets . . . 11 2.3.5.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 10
2.3.6.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11 2.3.6. Latency Optimization by a Central Controller . . . . 11
2.3.7. Latency Optimization by a Central Controller . . . . 11 2.3.7. Reduced Device Cost Due To Reduced Buffer Memory . . 11
2.3.8. Reduced Device Cost Due To Reduced Buffer Memory . . 12
2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12 2.4. Pro Audio Asks . . . . . . . . . . . . . . . . . . . . . 12
3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12 3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 12
3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 12
3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 13 3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 12
3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 13 3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 12
3.1.1.2. Intra-Substation Process Bus Communications . . . 18 3.1.1.2. Intra-Substation Process Bus Communications . . . 18
3.1.1.3. Wide Area Monitoring and Control Systems . . . . 19 3.1.1.3. Wide Area Monitoring and Control Systems . . . . 19
3.1.1.4. IEC 61850 WAN engineering guidelines requirement 3.1.1.4. IEC 61850 WAN engineering guidelines requirement
classification . . . . . . . . . . . . . . . . . 20 classification . . . . . . . . . . . . . . . . . 20
3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21 3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 21
3.1.3. Distribution use case . . . . . . . . . . . . . . . . 22 3.1.3. Distribution use case . . . . . . . . . . . . . . . . 22
3.1.3.1. Fault Location Isolation and Service Restoration 3.1.3.1. Fault Location Isolation and Service Restoration
(FLISR) . . . . . . . . . . . . . . . . . . . . . 22 (FLISR) . . . . . . . . . . . . . . . . . . . . . 22
3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 23 3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 23
3.2.1. Security Current Practices and Limitations . . . . . 23 3.2.1. Security Current Practices and Limitations . . . . . 23
skipping to change at page 4, line 4 skipping to change at page 3, line 50
4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 35 4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 35
4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 35 4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 35
4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 36 4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 36
4.2.4. Security Considerations . . . . . . . . . . . . . . . 36 4.2.4. Security Considerations . . . . . . . . . . . . . . . 36
4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 36
4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 37
5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 37 5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 37
5.1. Use Case Description . . . . . . . . . . . . . . . . . . 37 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 37
5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 38 5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 38
5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 38 5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 38
5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 39 5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 39
5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 39 5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 39
5.3.1. Unified Wireless Network and Management . . . . . . . 39 5.3.1. Unified Wireless Network and Management . . . . . . . 39
5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 41 5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 41
5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 42 5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 42
5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 42 5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 42
5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 43 5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 43
5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 43 5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 44
5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 44 5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 44
6. Cellular Radio . . . . . . . . . . . . . . . . . . . . . . . 44 6. Cellular Radio . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Use Case Description . . . . . . . . . . . . . . . . . . 44 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 44
6.1.1. Network Architecture . . . . . . . . . . . . . . . . 44 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 44
6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 45 6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 45
6.1.3. Time Synchronization Constraints . . . . . . . . . . 46 6.1.3. Time Synchronization Constraints . . . . . . . . . . 46
6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 48 6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 48
6.1.5. Security Considerations . . . . . . . . . . . . . . . 48 6.1.5. Security Considerations . . . . . . . . . . . . . . . 48
6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 48 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 49
6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 48 6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 49
6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 49 6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 49
6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 49 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 50
6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 51 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 52
7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 52 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 52 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 52
7.2. Industrial M2M Communication Today . . . . . . . . . . . 53 7.2. Industrial M2M Communication Today . . . . . . . . . . . 53
7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 53 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 54
7.2.2. Stream Creation and Destruction . . . . . . . . . . . 54 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 55
7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 54 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 55
7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 54 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 55
8. Internet-based Applications . . . . . . . . . . . . . . . . . 55 8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 55
8.1. Use Case Description . . . . . . . . . . . . . . . . . . 55 9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 56
8.1.1. Media Content Delivery . . . . . . . . . . . . . . . 55 9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 57
8.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 55 9.2. Internet-based Applications . . . . . . . . . . . . . . . 57
8.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 55 9.2.1. Use Case Description . . . . . . . . . . . . . . . . 57
8.2. Internet-Based Applications Today . . . . . . . . . . . . 55 9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 58
8.3. Internet-Based Applications Future . . . . . . . . . . . 55 9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 58
8.4. Internet-Based Applications Asks . . . . . . . . . . . . 56 9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 58
9. Use Case Common Elements . . . . . . . . . . . . . . . . . . 56 9.2.2. Internet-Based Applications Today . . . . . . . . . . 58
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 9.2.3. Internet-Based Applications Future . . . . . . . . . 58
10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 57 9.2.4. Internet-Based Applications Asks . . . . . . . . . . 58
10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 57 9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 59
10.3. Building Automation Systems . . . . . . . . . . . . . . 58 9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 59
10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 58 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 58 10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 60
10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 58 10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 60
10.7. Internet Applications and CoMP . . . . . . . . . . . . . 58 10.3. Building Automation Systems . . . . . . . . . . . . . . 60
11. Informative References . . . . . . . . . . . . . . . . . . . 58 10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 61
10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 61
10.7. Internet Applications and CoMP . . . . . . . . . . . . . 61
11. Informative References . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
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 7, line 47 skipping to change at page 8, line 7
remote broadcast. In such cases the latencies of the broadcast remote broadcast. In such cases the latencies of the broadcast
stream and the local performer must be adjusted to match each other, stream and the local performer must be adjusted to match each other,
with a worst case of one video frame (33ms for NTSC video). with a worst case of one video frame (33ms for NTSC video).
In cases where audio phase is a consideration, for example beam- In cases where audio phase is a consideration, for example beam-
forming using multiple speakers, latency requirements can be in the forming using multiple speakers, latency requirements can be in the
10 microsecond range (1 audio sample at 96kHz). 10 microsecond range (1 audio sample at 96kHz).
2.1.4. Deterministic Time to Establish Streaming 2.1.4. Deterministic Time to Establish Streaming
Note: It is still under WG discussion whether this topic (stream
startup time) is within scope of DetNet.
Some audio systems installed in public environments (airports, Some audio systems installed in public environments (airports,
hospitals) have unique requirements with regards to health, safety hospitals) have unique requirements with regards to health, safety
and fire concerns. One such requirement is a maximum of 3 seconds and fire concerns. One such requirement is a maximum of 3 seconds
for a system to respond to an emergency detection and begin sending for a system to respond to an emergency detection and begin sending
appropriate warning signals and alarms without human intervention. appropriate warning signals and alarms without human intervention.
For this requirement to be met, the system must support a bounded and For this requirement to be met, the system must support a bounded and
acceptable time from a notification signal to specific stream acceptable time from a notification signal to specific stream
establishment. For further details see [ISO7240-16]. establishment. For further details see [ISO7240-16].
Similar requirements apply when the system is restarted after a power Similar requirements apply when the system is restarted after a power
cycle, cable re-connection, or system reconfiguration. cycle, cable re-connection, or system reconfiguration.
In many cases such re-establishment of streaming state must be In many cases such re-establishment of streaming state must be
achieved by the peer devices themselves, i.e. without a central achieved by the peer devices themselves, i.e. without a central
controller (since such a controller may only be present during controller (since such a controller may only be present during
skipping to change at page 8, line 32 skipping to change at page 8, line 42
2.1.5.1. Safety 2.1.5.1. Safety
Professional audio systems can include amplifiers that are capable of Professional audio systems can include amplifiers that are capable of
generating hundreds or thousands of watts of audio power which if generating hundreds or thousands of watts of audio power which if
used incorrectly can cause hearing damage to those in the vicinity. used incorrectly can cause hearing damage to those in the vicinity.
Apart from the usual care required by the systems operators to Apart from the usual care required by the systems operators to
prevent such incidents, the network traffic that controls these prevent such incidents, the network traffic that controls these
devices must be secured (as with any sensitive application traffic). devices must be secured (as with any sensitive application traffic).
2.1.5.2. Digital Rights Management (DRM)
Digital Rights Management (DRM) is very important to the audio and
video industries. Any time protected content is introduced into a
network there are DRM concerns that must be maintained (see
[CONTENT_PROTECTION]). Many aspects of DRM are outside the scope of
network technology, however there are cases when a secure link
supporting authentication and encryption is required by content
owners to carry their audio or video content when it is outside their
own secure environment (for example see [DCI]).
As an example, two techniques are Digital Transmission Content
Protection (DTCP) and High-Bandwidth Digital Content Protection
(HDCP). HDCP content is not approved for retransmission within any
other type of DRM, while DTCP may be retransmitted under HDCP.
Therefore if the source of a stream is outside of the network and it
uses HDCP protection it is only allowed to be placed on the network
with that same HDCP protection.
2.2. Pro Audio Today 2.2. Pro Audio Today
Some proprietary systems have been created which enable deterministic Some proprietary systems have been created which enable deterministic
streams at Layer 3 however they are "engineered networks" which streams at Layer 3 however they are "engineered networks" which
require careful configuration to operate, often require that the require careful configuration to operate, often require that the
system be over-provisioned, and it is implied that all devices on the system be over-provisioned, and it is implied that all devices on the
network voluntarily play by the rules of that network. To enable network voluntarily play by the rules of that network. To enable
these industries to successfully transition to an interoperable these industries to successfully transition to an interoperable
multi-vendor packet-based infrastructure requires effective open multi-vendor packet-based infrastructure requires effective open
standards, and we believe that establishing relevant IETF standards standards, and we believe that establishing relevant IETF standards
skipping to change at page 9, line 47 skipping to change at page 9, line 35
2.3.2. High Reliability Stream Paths 2.3.2. High Reliability Stream Paths
On-air and other live media streams are often backed up with On-air and other live media streams are often backed up with
redundant links that seamlessly act to deliver the content when the redundant links that seamlessly act to deliver the content when the
primary link fails for any reason. In point-to-point systems this is primary link fails for any reason. In point-to-point systems this is
provided by an additional point-to-point link; the analogous provided by an additional point-to-point link; the analogous
requirement in a packet-based system is to provide an alternate path requirement in a packet-based system is to provide an alternate path
through the network such that no individual link can bring down the through the network such that no individual link can bring down the
system. system.
2.3.3. Link Aggregation 2.3.3. Integration of Reserved Streams into IT Networks
For transmitting streams that require more bandwidth than a single
link in the target network can support, link aggregation is a
technique for combining (aggregating) the bandwidth available on
multiple physical links to create a single logical link of the
required bandwidth. However, if aggregation is to be used, the
network controller (or equivalent) must be able to determine the
maximum latency of any path through the aggregate link.
2.3.4. Integration of Reserved Streams into IT Networks
A commonly cited goal of moving to a packet based media A commonly cited goal of moving to a packet based media
infrastructure is that costs can be reduced by using off the shelf, infrastructure is that costs can be reduced by using off the shelf,
commodity network hardware. In addition, economy of scale can be commodity network hardware. In addition, economy of scale can be
realized by combining media infrastructure with IT infrastructure. realized by combining media infrastructure with IT infrastructure.
In keeping with these goals, stream reservation technology should be In keeping with these goals, stream reservation technology should be
compatible with existing protocols, and not compromise use of the compatible with existing protocols, and not compromise use of the
network for best effort (non-time-sensitive) traffic. network for best effort (non-time-sensitive) traffic.
2.3.5. Use of Unused Reservations by Best-Effort Traffic 2.3.4. Use of Unused Reservations by Best-Effort Traffic
In cases where stream bandwidth is reserved but not currently used In cases where stream bandwidth is reserved but not currently used
(or is under-utilized) that bandwidth must be available to best- (or is under-utilized) that bandwidth must be available to best-
effort (i.e. non-time-sensitive) traffic. For example a single effort (i.e. non-time-sensitive) traffic. For example a single
stream may be nailed up (reserved) for specific media content that stream may be nailed up (reserved) for specific media content that
needs to be presented at different times of the day, ensuring timely needs to be presented at different times of the day, ensuring timely
delivery of that content, yet in between those times the full delivery of that content, yet in between those times the full
bandwidth of the network can be utilized for best-effort tasks such bandwidth of the network can be utilized for best-effort tasks such
as file transfers. as file transfers.
This also addresses a concern of IT network administrators that are This also addresses a concern of IT network administrators that are
considering adding reserved bandwidth traffic to their networks that considering adding reserved bandwidth traffic to their networks that
("users will reserve large quantities of bandwidth and then never un- ("users will reserve large quantities of bandwidth and then never un-
reserve it even though they are not using it, and soon the network reserve it even though they are not using it, and soon the network
will have no bandwidth left"). will have no bandwidth left").
2.3.6. Traffic Segregation 2.3.5. Traffic Segregation
Note: It is still under WG discussion whether this topic will be
addressed by DetNet.
Sink devices may be low cost devices with limited processing power. Sink devices may be low cost devices with limited processing power.
In order to not overwhelm the CPUs in these devices it is important In order to not overwhelm the CPUs in these devices it is important
to limit the amount of traffic that these devices must process. to limit the amount of traffic that these devices must process.
As an example, consider the use of individual seat speakers in a As an example, consider the use of individual seat speakers in a
cinema. These speakers are typically required to be cost reduced cinema. These speakers are typically required to be cost reduced
since the quantities in a single theater can reach hundreds of seats. since the quantities in a single theater can reach hundreds of seats.
Discovery protocols alone in a one thousand seat theater can generate Discovery protocols alone in a one thousand seat theater can generate
enough broadcast traffic to overwhelm a low powered CPU. Thus an enough broadcast traffic to overwhelm a low powered CPU. Thus an
installation like this will benefit greatly from some type of traffic installation like this will benefit greatly from some type of traffic
segregation that can define groups of seats to reduce traffic within segregation that can define groups of seats to reduce traffic within
each group. All seats in the theater must still be able to each group. All seats in the theater must still be able to
communicate with a central controller. communicate with a central controller.
There are many techniques that can be used to support this There are many techniques that can be used to support this
requirement including (but not limited to) the following examples. requirement including (but not limited to) the following examples.
2.3.6.1. Packet Forwarding Rules, VLANs and Subnets 2.3.5.1. Packet Forwarding Rules, VLANs and Subnets
Packet forwarding rules can be used to eliminate some extraneous Packet forwarding rules can be used to eliminate some extraneous
streaming traffic from reaching potentially low powered sink devices, streaming traffic from reaching potentially low powered sink devices,
however there may be other types of broadcast traffic that should be however there may be other types of broadcast traffic that should be
eliminated using other means for example VLANs or IP subnets. eliminated using other means for example VLANs or IP subnets.
2.3.6.2. Multicast Addressing (IPv4 and IPv6) 2.3.5.2. Multicast Addressing (IPv4 and IPv6)
Multicast addressing is commonly used to keep bandwidth utilization Multicast addressing is commonly used to keep bandwidth utilization
of shared links to a minimum. of shared links to a minimum.
Because of the MAC Address forwarding nature of Layer 2 bridges it is Because of the MAC Address forwarding nature of Layer 2 bridges it is
important that a multicast MAC address is only associated with one important that a multicast MAC address is only associated with one
stream. This will prevent reservations from forwarding packets from stream. This will prevent reservations from forwarding packets from
one stream down a path that has no interested sinks simply because one stream down a path that has no interested sinks simply because
there is another stream on that same path that shares the same there is another stream on that same path that shares the same
multicast MAC address. multicast MAC address.
Since each multicast MAC Address can represent 32 different IPv4 Since each multicast MAC Address can represent 32 different IPv4
multicast addresses there must be a process put in place to make sure multicast addresses there must be a process put in place to make sure
this does not occur. Requiring use of IPv6 address can achieve this, this does not occur. Requiring use of IPv6 address can achieve this,
however due to their continued prevalence, solutions that are however due to their continued prevalence, solutions that are
effective for IPv4 installations are also required. effective for IPv4 installations are also required.
2.3.7. Latency Optimization by a Central Controller 2.3.6. Latency Optimization by a Central Controller
A central network controller might also perform optimizations based A central network controller might also perform optimizations based
on the individual path delays, for example sinks that are closer to on the individual path delays, for example sinks that are closer to
the source can inform the controller that they can accept greater the source can inform the controller that they can accept greater
latency since they will be buffering packets to match presentation latency since they will be buffering packets to match presentation
times of farther away sinks. The controller might then move a stream times of farther away sinks. The controller might then move a stream
reservation on a short path to a longer path in order to free up reservation on a short path to a longer path in order to free up
bandwidth for other critical streams on that short path. See slides bandwidth for other critical streams on that short path. See slides
3-5 of [SRP_LATENCY]. 3-5 of [SRP_LATENCY].
Additional optimization can be achieved in cases where sinks have Additional optimization can be achieved in cases where sinks have
differing latency requirements, for example in a live outdoor concert differing latency requirements, for example in a live outdoor concert
the speaker sinks have stricter latency requirements than the the speaker sinks have stricter latency requirements than the
recording hardware sinks. See slide 7 of [SRP_LATENCY]. recording hardware sinks. See slide 7 of [SRP_LATENCY].
2.3.8. Reduced Device Cost Due To Reduced Buffer Memory 2.3.7. Reduced Device Cost Due To Reduced Buffer Memory
Device cost can be reduced in a system with guaranteed reservations Device cost can be reduced in a system with guaranteed reservations
with a small bounded latency due to the reduced requirements for with a small bounded latency due to the reduced requirements for
buffering (i.e. memory) on sink devices. For example, a theme park buffering (i.e. memory) on sink devices. For example, a theme park
might broadcast a live event across the globe via a layer 3 protocol; might broadcast a live event across the globe via a layer 3 protocol;
in such cases the size of the buffers required is proportional to the in such cases the size of the buffers required is proportional to the
latency bounds and jitter caused by delivery, which depends on the latency bounds and jitter caused by delivery, which depends on the
worst case segment of the end-to-end network path. For example on worst case segment of the end-to-end network path. For example on
todays open internet the latency is typically unacceptable for audio todays open internet the latency is typically unacceptable for audio
and video streaming without many seconds of buffering. In such and video streaming without many seconds of buffering. In such
skipping to change at page 14, line 26 skipping to change at page 14, line 9
require particularly long time to operate and take up the majority of require particularly long time to operate and take up the majority of
the total clearance time, leaving only a 10ms window for the the total clearance time, leaving only a 10ms window for the
telecommunications part of the protection scheme, independent of the telecommunications part of the protection scheme, independent of the
distance to travel. Given the sensitivity of the issue, new networks distance to travel. Given the sensitivity of the issue, new networks
impose requirements that are even more stringent: IEC standard 61850 impose requirements that are even more stringent: IEC standard 61850
limits the transfer time for protection messages to 1/4 - 1/2 cycle limits the transfer time for protection messages to 1/4 - 1/2 cycle
or 4 - 8ms (for 60Hz lines) for the most critical messages. or 4 - 8ms (for 60Hz lines) for the most critical messages.
3.1.1.1.3. Symmetric Channel Delay 3.1.1.1.3. Symmetric Channel Delay
Note: It is currently under WG discussion whether symmetric path
delays are to be guaranteed by DetNet.
Teleprotection channels which are differential must be synchronous, Teleprotection channels which are differential must be synchronous,
which means that any delays on the transmit and receive paths must which means that any delays on the transmit and receive paths must
match each other. Teleprotection systems ideally support zero match each other. Teleprotection systems ideally support zero
asymmetric delay; typical legacy relays can tolerate delay asymmetric delay; typical legacy relays can tolerate delay
discrepancies of up to 750us. discrepancies of up to 750us.
Some tools available for lowering delay variation below this Some tools available for lowering delay variation below this
threshold are: threshold are:
o For legacy systems using Time Division Multiplexing (TDM), jitter o For legacy systems using Time Division Multiplexing (TDM), jitter
skipping to change at page 39, line 15 skipping to change at page 39, line 15
resources in a manner that minimizes the interaction with and the resources in a manner that minimizes the interaction with and the
load placed on resource-constrained devices. For example, a tiny IoT load placed on resource-constrained devices. For example, a tiny IoT
device may have just enough buffers to store one or a few IPv6 device may have just enough buffers to store one or a few IPv6
packets, and will have limited bandwidth between peers such that it packets, and will have limited bandwidth between peers such that it
can maintain only a small amount of peer information, and will not be can maintain only a small amount of peer information, and will not be
able to store many packets waiting to be forwarded. It is able to store many packets waiting to be forwarded. It is
advantageous then for it to only be required to carry out the advantageous then for it to only be required to carry out the
specific behavior assigned to it by the PCE/NME (as opposed to specific behavior assigned to it by the PCE/NME (as opposed to
maintaining its own IP stack, for example). maintaining its own IP stack, for example).
6TiSCH depends on [PCE] and [I-D.finn-detnet-architecture], and we Note: Current WG discussion indicates that some peer-to-peer
expect that DetNet will maintain consistency with [IEEE802.1TSNTG]. communication must be assumed, i.e. the PCE may communicate only
indirectly with any given device, enabling hierarchical configuration
of the system.
6TiSCH depends on [PCE] and [I-D.finn-detnet-architecture].
6TiSCH also depends on the fact that DetNet will maintain consistency
with [IEEE802.1TSNTG].
5.2. Wireless Industrial Today 5.2. Wireless Industrial Today
Today industrial wireless is accomplished using multiple Today industrial wireless is accomplished using multiple
deterministic wireless networks which are incompatible with each deterministic wireless networks which are incompatible with each
other and with IP traffic. other and with IP traffic.
6TiSCH is not yet fully specified, so it cannot be used in today's 6TiSCH is not yet fully specified, so it cannot be used in today's
applications. applications.
skipping to change at page 41, line 28 skipping to change at page 41, line 32
o / o o---o----/ o o / o o---o----/ o
o o---o--/ o o o o o o o---o--/ o o o o o
o \ / o o LLN o o \ / o o LLN o
o v <---- Replication o v <---- Replication
o o
Figure 6: 6TiSCH Network with PRE Figure 6: 6TiSCH Network with PRE
5.3.1.1. PCE and 6TiSCH ARQ Retries 5.3.1.1. PCE and 6TiSCH ARQ Retries
Note: The possible use of ARQ techniques in DetNet is currently
considered a possible design alternative.
6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism 6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism
to provide higher reliability of packet delivery. ARQ is related to to provide higher reliability of packet delivery. ARQ is related to
packet replication and elimination because there are two independent packet replication and elimination because there are two independent
paths for packets to arrive at the destination, and if an expected paths for packets to arrive at the destination, and if an expected
packed does not arrive on one path then it checks for the packet on packed does not arrive on one path then it checks for the packet on
the second path. the second path.
Although to date this mechanism is only used by wireless networks, Although to date this mechanism is only used by wireless networks,
this may be a technique that would be appropriate for DetNet and so this may be a technique that would be appropriate for DetNet and so
aspects of the enabling protocol could be co-developed. aspects of the enabling protocol could be co-developed.
For example, in Figure 6, a Track is laid out from a field device in For example, in Figure 6, a Track is laid out from a field device in
a 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN a 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN
backbone. backbone.
The Replication function in the field device sends a copy of each In ARQ the Replication function in the field device sends a copy of
packet over two different branches, and the PCE schedules each hop of each packet over two different branches, and the PCE schedules each
both branches so that the two copies arrive in due time at the hop of both branches so that the two copies arrive in due time at the
gateway. In case of a loss on one branch, hopefully the other copy gateway. In case of a loss on one branch, hopefully the other copy
of the packet still arrives within the allocated time. If two copies of the packet still arrives within the allocated time. If two copies
make it to the IoT gateway, the Elimination function in the gateway make it to the IoT gateway, the Elimination function in the gateway
ignores the extra packet and presents only one copy to upper layers. ignores the extra packet and presents only one copy to upper layers.
At each 6TiSCH hop along the Track, the PCE may schedule more than At each 6TiSCH hop along the Track, the PCE may schedule more than
one timeSlot for a packet, so as to support Layer-2 retries (ARQ). one timeSlot for a packet, so as to support Layer-2 retries (ARQ).
In current deployments, a TSCH Track does not necessarily support PRE In current deployments, a TSCH Track does not necessarily support PRE
but is systematically multi-path. This means that a Track is but is systematically multi-path. This means that a Track is
skipping to change at page 42, line 46 skipping to change at page 43, line 5
enables recognizing that a certain packet belongs to a certain path, enables recognizing that a certain packet belongs to a certain path,
etc. etc.
For a static configuration that serves a certain purpose for a long For a static configuration that serves a certain purpose for a long
period of time, it is expected that a node will be provisioned in one period of time, it is expected that a node will be provisioned in one
shot with a full schedule, which incorporates the aggregation of its shot with a full schedule, which incorporates the aggregation of its
behavior for multiple paths. 6TiSCH expects that the programing of behavior for multiple paths. 6TiSCH expects that the programing of
the schedule will be done over COAP as discussed in the schedule will be done over COAP as discussed in
[I-D.ietf-6tisch-coap]. [I-D.ietf-6tisch-coap].
6TiSCH expects that the PCE commands will be issued directly as CoAP 6TiSCH expects that the PCE commands will be mapped back and forth
requests or be mapped back and forth into CoAP by a gateway function into CoAP by a gateway function at the edge of the 6TiSCH network.
at the edge of the 6TiSCH network. For instance, it is possible that For instance, it is possible that a mapping entity on the backbone
a mapping entity on the backbone transforms a non-CoAP protocol such transforms a non-CoAP protocol such as PCEP into the RESTful
as PCEP into the RESTful interfaces that the 6TiSCH devices support. interfaces that the 6TiSCH devices support. This architecture will
This architecture will be refined to comply with DetNet be refined to comply with DetNet [I-D.finn-detnet-architecture] when
[I-D.finn-detnet-architecture] when the work is formalized. Related the work is formalized. Related information about 6TiSCH can be
information about 6TiSCH can be found at found at [I-D.ietf-6tisch-6top-interface] and RPL [RFC6550].
[I-D.ietf-6tisch-6top-interface] and RPL [RFC6550].
If it appears that a path through the network does not perform as A protocol may be used to update the state in the devices during
expected, a protocol may be used to update the state in the devices, runtime, for example if it appears that a path through the network
but in 6TiSCH that flow was not designed and no protocol was selected has ceased to perform as expected, but in 6TiSCH that flow was not
and it is expected that DetNet will determine the appropriate end-to- designed and no protocol was selected. We would like to see DetNet
end protocols to be used in that case. define the appropriate end-to-end protocols to be used in that case.
The implication is that these state updates take place once the
system is configured and running, i.e. they are not limited to the
initial communication of the configuration of the system.
A "slotFrame" is the base object that the PCE needs to manipulate to A "slotFrame" is the base object that a PCE would manipulate to
program a schedule into an LLN node ([I-D.ietf-6tisch-architecture]). program a schedule into an LLN node ([I-D.ietf-6tisch-architecture]).
The PCE should be able to read energy data from devices, and compute We would like to see the PCE read energy data from devices, and
paths that will implement policies on how energy in devices is compute paths that will implement policies on how energy in devices
consumed, for instance to ensure that the spent energy does not is consumed, for instance to ensure that the spent energy does not
exceeded the available energy over a period of time. exceeded the available energy over a period of time. Note: this
statement implies that an extensible protocol for communicating
device info to the PCE and enabling the PCE to act on it will be part
of the DetNet architecture, however for subnets with specific
protocols (e.g. CoAP) a gateway may be required.
6TiSCH devices can discover their neighbors over the radio using a 6TiSCH devices can discover their neighbors over the radio using a
mechanism such as beacons, but even though the neighbor information mechanism such as beacons, but even though the neighbor information
is available in the 6TiSCH interface data model, 6TiSCH does not is available in the 6TiSCH interface data model, 6TiSCH does not
describe a protocol to proactively push the neighborhood information describe a protocol to proactively push the neighborhood information
to a PCE. DetNet should define this protocol, and it and should to a PCE. We would like to see DetNet define such a protocol; one
operate over CoAP. The protocol should be able to carry multiple possible design alternative is that it could operate over CoAP,
metrics, in particular the same metrics as used for RPL operations alternatively it could be converted to/from CoAP by a gateway. We
[RFC6551] would like to see such a protocol carry multiple metrics, for example
similar to those used for RPL operations [RFC6551]
5.3.2.2. 6TiSCH IP Interface 5.3.2.2. 6TiSCH IP Interface
"6top" ([I-D.wang-6tisch-6top-sublayer]) is a logical link control "6top" ([I-D.wang-6tisch-6top-sublayer]) is a logical link control
sitting between the IP layer and the TSCH MAC layer which provides sitting between the IP layer and the TSCH MAC layer which provides
the link abstraction that is required for IP operations. The 6top the link abstraction that is required for IP operations. The 6top
data model and management interfaces are further discussed in data model and management interfaces are further discussed in
[I-D.ietf-6tisch-6top-interface] and [I-D.ietf-6tisch-coap]. [I-D.ietf-6tisch-6top-interface] and [I-D.ietf-6tisch-coap].
An IP packet that is sent along a 6TiSCH path uses the Differentiated An IP packet that is sent along a 6TiSCH path uses the Differentiated
skipping to change at page 44, line 15 skipping to change at page 44, line 28
5.4. Wireless Industrial Asks 5.4. Wireless Industrial Asks
6TiSCH depends on DetNet to define: 6TiSCH depends on DetNet to define:
o Configuration (state) and operations for deterministic paths o Configuration (state) and operations for deterministic paths
o End-to-end protocols for deterministic forwarding (tagging, IP) o End-to-end protocols for deterministic forwarding (tagging, IP)
o Protocol for packet replication and elimination o Protocol for packet replication and elimination
o Protocol for packet automatic retries (ARQ) (specific to wireless)
6. Cellular Radio 6. Cellular Radio
6.1. Use Case Description 6.1. Use Case Description
This use case describes the application of deterministic networking This use case describes the application of deterministic networking
in the context of cellular telecom transport networks. Important in the context of cellular telecom transport networks. Important
elements include time synchronization, clock distribution, and ways elements include time synchronization, clock distribution, and ways
of establishing time-sensitive streams for both Layer-2 and Layer-3 of establishing time-sensitive streams for both Layer-2 and Layer-3
user plane traffic. user plane traffic.
skipping to change at page 46, line 40 skipping to change at page 46, line 40
6.1.3. Time Synchronization Constraints 6.1.3. Time Synchronization Constraints
Fronthaul time synchronization requirements are given by [TS25104], Fronthaul time synchronization requirements are given by [TS25104],
[TS36104], [TS36211], and [TS36133]. These can be summarized for the [TS36104], [TS36211], and [TS36133]. These can be summarized for the
current 3GPP LTE-based networks as: current 3GPP LTE-based networks as:
Delay Accuracy: Delay Accuracy:
+-8ns (i.e. +-1/32 Tc, where Tc is the UMTS Chip time of 1/3.84 +-8ns (i.e. +-1/32 Tc, where Tc is the UMTS Chip time of 1/3.84
MHz) resulting in a round trip accuracy of +-16ns. The value is MHz) resulting in a round trip accuracy of +-16ns. The value is
this low to meet the 3GPP Timing Alignment Error (TAE) measurement this low to meet the 3GPP Timing Alignment Error (TAE) measurement
requirements. requirements. Note: performance guarantees of low nanosecond
values such as these are considered to be below the DetNet layer -
it is assumed that the underlying implementation, e.g. the
hardware, will provide sufficient support (e.g. buffering) to
enable this level of accuracy. These values are maintained in the
use case to give an indication of the overall application.
Timing Alignment Error: Timing Alignment Error:
Timing Alignment Error (TAE) is problematic to Fronthaul networks Timing Alignment Error (TAE) is problematic to Fronthaul networks
and must be minimized. If the transport network cannot guarantee and must be minimized. If the transport network cannot guarantee
low enough TAE then additional buffering has to be introduced at low enough TAE then additional buffering has to be introduced at
the edges of the network to buffer out the jitter. Buffering is the edges of the network to buffer out the jitter. Buffering is
not desirable as it reduces the total available delay budget. not desirable as it reduces the total available delay budget.
Packet Delay Variation (PDV) requirements can be derived from TAE Packet Delay Variation (PDV) requirements can be derived from TAE
for packet based Fronthaul networks. for packet based Fronthaul networks.
skipping to change at page 47, line 31 skipping to change at page 47, line 34
+-2 PPB. This value is considered to be "available" for the +-2 PPB. This value is considered to be "available" for the
Fronthaul link out of the total 50 PPB budget reserved for the Fronthaul link out of the total 50 PPB budget reserved for the
radio interface. Note: the reason that the transport link radio interface. Note: the reason that the transport link
contributes to radio frequency error is as follows. The current contributes to radio frequency error is as follows. The current
way of doing Fronthaul is from the radio unit to remote radio head way of doing Fronthaul is from the radio unit to remote radio head
directly. The remote radio head is essentially a passive device directly. The remote radio head is essentially a passive device
(without buffering etc.) The transport drives the antenna (without buffering etc.) The transport drives the antenna
directly by feeding it with samples and everything the transport directly by feeding it with samples and everything the transport
adds will be introduced to radio as-is. So if the transport adds will be introduced to radio as-is. So if the transport
causes additional frequency error that shows immediately on the causes additional frequency error that shows immediately on the
radio as well. radio as well. Note: performance guarantees of low nanosecond
values such as these are considered to be below the DetNet layer -
it is assumed that the underlying implementation, e.g. the
hardware, will provide sufficient support to enable this level of
performance. These values are maintained in the use case to give
an indication of the overall application.
The above listed time synchronization requirements are difficult to The above listed time synchronization requirements are difficult to
meet with point-to-point connected networks, and more difficult when meet with point-to-point connected networks, and more difficult when
the network includes multiple hops. It is expected that networks the network includes multiple hops. It is expected that networks
must include buffering at the ends of the connections as imposed by must include buffering at the ends of the connections as imposed by
the jitter requirements, since trying to meet the jitter requirements the jitter requirements, since trying to meet the jitter requirements
in every intermediate node is likely to be too costly. However, in every intermediate node is likely to be too costly. However,
every measure to reduce jitter and delay on the path makes it easier every measure to reduce jitter and delay on the path makes it easier
to meet the end-to-end requirements. to meet the end-to-end requirements.
skipping to change at page 48, line 40 skipping to change at page 48, line 49
Establishing time-sensitive streams in the network entails reserving Establishing time-sensitive streams in the network entails reserving
networking resources for long periods of time. It is important that networking resources for long periods of time. It is important that
these reservation requests be authenticated to prevent malicious these reservation requests be authenticated to prevent malicious
reservation attempts from hostile nodes (or accidental reservation attempts from hostile nodes (or accidental
misconfiguration). This is particularly important in the case where misconfiguration). This is particularly important in the case where
the reservation requests span administrative domains. Furthermore, the reservation requests span administrative domains. Furthermore,
the reservation information itself should be digitally signed to the reservation information itself should be digitally signed to
reduce the risk of a legitimate node pushing a stale or hostile reduce the risk of a legitimate node pushing a stale or hostile
configuration into another networking node. configuration into another networking node.
Note: This is considered important for the security policy of the
network, but does not affect the core DetNet architecture and design.
6.2. Cellular Radio Networks Today 6.2. Cellular Radio Networks Today
6.2.1. Fronthaul 6.2.1. Fronthaul
Today's Fronthaul networks typically consist of: Today's Fronthaul networks typically consist of:
o Dedicated point-to-point fiber connection is common o Dedicated point-to-point fiber connection is common
o Proprietary protocols and framings o Proprietary protocols and framings
skipping to change at page 51, line 41 skipping to change at page 52, line 9
There is existing work describing the problem statement There is existing work describing the problem statement
[I-D.finn-detnet-problem-statement] and the architecture [I-D.finn-detnet-problem-statement] and the architecture
[I-D.finn-detnet-architecture] for deterministic networking (DetNet) [I-D.finn-detnet-architecture] for deterministic networking (DetNet)
that targets solutions for time-sensitive (IP/transport) streams with that targets solutions for time-sensitive (IP/transport) streams with
deterministic properties over Ethernet-based switched networks. deterministic properties over Ethernet-based switched networks.
6.4. Cellular Radio Networks Asks 6.4. Cellular Radio Networks Asks
A standard for data plane transport specification which is: A standard for data plane transport specification which is:
o Unified among all xHauls o Unified among all xHauls (meaning that different flows with
diverse DetNet requirements can coexist in the same network and
traverse the same nodes without interfering with each other)
o Deployed in a highly deterministic network environment o Deployed in a highly deterministic network environment
A standard for data flow information models that are: A standard for data flow information models that are:
o Aware of the time sensitivity and constraints of the target o Aware of the time sensitivity and constraints of the target
networking environment networking environment
o Aware of underlying deterministic networking services (e.g., on o Aware of underlying deterministic networking services (e.g., on
the Ethernet layer) the Ethernet layer)
skipping to change at page 54, line 45 skipping to change at page 55, line 30
7.3. Industrial M2M Future 7.3. Industrial M2M Future
We would like to see a converged IP-standards-based network with We would like to see a converged IP-standards-based network with
deterministic properties that can satisfy the timing, security and deterministic properties that can satisfy the timing, security and
reliability constraints described above. Today's proprietary reliability constraints described above. Today's proprietary
networks could then be interfaced to such a network via gateways or, networks could then be interfaced to such a network via gateways or,
in the case of new installations, devices could be connected directly in the case of new installations, devices could be connected directly
to the converged network. to the converged network.
For this use case we expect time synchronization accuracy on the
order of 1us.
7.4. Industrial M2M Asks 7.4. Industrial M2M Asks
o Converged IP-based network o Converged IP-based network
o Deterministic behavior (bounded latency and jitter ) o Deterministic behavior (bounded latency and jitter )
o High availability (presumably through redundancy) (99.999 %) o High availability (presumably through redundancy) (99.999 %)
o Low message delivery time (100us - 50ms) o Low message delivery time (100us - 50ms)
o Low packet loss (burstless, 0.1-1 %) o Low packet loss (burstless, 0.1-1 %)
o Precise time synchronization accuracy (1us)
o Security (e.g. prevent critical flows from being leaked between o Security (e.g. prevent critical flows from being leaked between
physically separated networks) physically separated networks)
8. Internet-based Applications 8. Use Case Common Elements
8.1. Use Case Description Looking at the use cases collectively, the following common desires
for the DetNet-based networks of the future emerge:
o Open standards-based network (replace various proprietary
networks, reduce cost, create multi-vendor market)
o Centrally administered (though such administration may be
distributed for scale and resiliency)
o Integrates L2 (bridged) and L3 (routed) environments (independent
of the Link layer, e.g. can be used with Ethernet, 6TiSCH, etc.)
o Carries both deterministic and best-effort traffic (guaranteed
end-to-end delivery of deterministic flows, deterministic flows
isolated from each other and from best-effort traffic congestion,
unused deterministic BW available to best-effort traffic)
o Ability to add or remove systems from the network with minimal,
bounded service interruption (applications include replacement of
failed devices as well as plug and play)
o Uses standardized data flow information models capable of
expressing deterministic properties (models express device
capabilities, flow properties. Protocols for pushing models from
controller to devices, devices to controller)
o Scalable size (long distances (many km) and short distances
(within a single machine), many hops (radio repeaters, microwave
links, fiber links...) and short hops (single machine))
o Scalable timing parameters and accuracy (bounded latency,
guaranteed worst case maximum, minimum. Low latency, e.g. control
loops may be less than 1ms, but larger for wide area networks)
o High availability (99.9999 percent up time requested, but may be
up to twelve 9s)
o Reliability, redundancy (lives at stake)
o Security (from failures, attackers, misbehaving devices -
sensitive to both packet content and arrival time)
9. Use Cases Explicitly Out of Scope for DetNet
This section contains use case text that has been determined to be
outside of the scope of the present DetNet work.
9.1. DetNet Scope Limitations
The scope of DetNet is deliberately limited to specific use cases
that are consistent with the WG charter, subject to the
interpretation of the WG. At the time the DetNet Use Cases were
solicited and provided by the authors the scope of DetNet was not
clearly defined, and as that clarity has emerged, certain of the use
cases have been determined to be outside the scope of the present
DetNet work. Such text has been moved into this section to clarify
that these use cases will not be supported by the DetNet work.
The text in this section was moved here based on the following
"exclusion" principles. Or, as an alternative to moving all such
text to this section, some draft text has been modified in situ to
reflect these same principles.
The following principles have been established to clarify the scope
of the present DetNet work.
o The scope of network addressed by DetNet is limited to networks
that can be centrally controlled, i.e. an "enterprise" aka
"corporate" network. This explicitly excludes "the open
Internet".
o Maintaining synchronized time across a DetNet network is crucial
to its operation, however DetNet assumes that time is to be
maintained using other means, for example (but not limited to)
Precision Time Protocol ([IEEE1588]). A use case may state the
accuracy and reliability that it expects from the DetNet network
as part of a whole system, however it is understood that such
timing properties are not guaranteed by DetNet itself. It is
currently an open question as to whether DetNet protocols will
include a way for an application to communicate such timing
expectations to the network, and if so whether they would be
expected to materially affect the performance they would receive
from the network as a result.
9.2. Internet-based Applications
9.2.1. Use Case Description
There are many applications that communicate across the open Internet There are many applications that communicate across the open Internet
that could benefit from guaranteed delivery and bounded latency. The that could benefit from guaranteed delivery and bounded latency. The
following are some representative examples. following are some representative examples.
8.1.1. Media Content Delivery 9.2.1.1. Media Content Delivery
Media content delivery continues to be an important use of the Media content delivery continues to be an important use of the
Internet, yet users often experience poor quality audio and video due Internet, yet users often experience poor quality audio and video due
to the delay and jitter inherent in today's Internet. to the delay and jitter inherent in today's Internet.
8.1.2. Online Gaming 9.2.1.2. Online Gaming
Online gaming is a significant part of the gaming market, however Online gaming is a significant part of the gaming market, however
latency can degrade the end user experience. For example "First latency can degrade the end user experience. For example "First
Person Shooter" (FPS) games are highly delay-sensitive. Person Shooter" (FPS) games are highly delay-sensitive.
8.1.3. Virtual Reality 9.2.1.3. Virtual Reality
Virtual reality (VR) has many commercial applications including real Virtual reality (VR) has many commercial applications including real
estate presentations, remote medical procedures, and so on. Low estate presentations, remote medical procedures, and so on. Low
latency is critical to interacting with the virtual world because latency is critical to interacting with the virtual world because
perceptual delays can cause motion sickness. perceptual delays can cause motion sickness.
8.2. Internet-Based Applications Today 9.2.2. Internet-Based Applications Today
Internet service today is by definition "best effort", with no Internet service today is by definition "best effort", with no
guarantees on delivery or bandwidth. guarantees on delivery or bandwidth.
8.3. Internet-Based Applications Future 9.2.3. Internet-Based Applications Future
We imagine an Internet from which we will be able to play a video We imagine an Internet from which we will be able to play a video
without glitches and play games without lag. without glitches and play games without lag.
For online gaming, the maximum round-trip delay can be 100ms and For online gaming, the maximum round-trip delay can be 100ms and
stricter for FPS gaming which can be 10-50ms. Transport delay is the stricter for FPS gaming which can be 10-50ms. Transport delay is the
dominate part with a 5-20ms budget. dominate part with a 5-20ms budget.
For VR, 1-10ms maximum delay is needed and total network budget is For VR, 1-10ms maximum delay is needed and total network budget is
1-5ms if doing remote VR. 1-5ms if doing remote VR.
Flow identification can be used for gaming and VR, i.e. it can Flow identification can be used for gaming and VR, i.e. it can
recognize a critical flow and provide appropriate latency bounds. recognize a critical flow and provide appropriate latency bounds.
8.4. Internet-Based Applications Asks 9.2.4. Internet-Based Applications Asks
o Unified control and management protocols to handle time-critical o Unified control and management protocols to handle time-critical
data flow data flow
o Application-aware flow filtering mechanism to recognize the timing o Application-aware flow filtering mechanism to recognize the timing
critical flow without doing 5-tuple matching critical flow without doing 5-tuple matching
o Unified control plane to provide low latency service on Layer-3 o Unified control plane to provide low latency service on Layer-3
without changing the data plane without changing the data plane
o OAM system and protocols which can help to provide E2E-delay o OAM system and protocols which can help to provide E2E-delay
sensitive service provisioning sensitive service provisioning
9. Use Case Common Elements 9.3. Pro Audio and Video - Digital Rights Management (DRM)
Looking at the use cases collectively, the following common desires
for the DetNet-based networks of the future emerge:
o Open standards-based network (replace various proprietary
networks, reduce cost, create multi-vendor market)
o Centrally administered (though such administration may be
distributed for scale and resiliency)
o Integrates L2 (bridged) and L3 (routed) environments (independent
of the Link layer, e.g. can be used with Ethernet, 6TiSCH, etc.)
o Carries both deterministic and best-effort traffic (guaranteed
end-to-end delivery of deterministic flows, deterministic flows
isolated from each other and from best-effort traffic congestion,
unused deterministic BW available to best-effort traffic)
o Ability to add or remove systems from the network with minimal,
bounded service interruption (applications include replacement of
failed devices as well as plug and play)
o Uses standardized data flow information models capable of This section was moved here because this is considered a Link layer
expressing deterministic properties (models express device topic, not direct responsibility of DetNet.
capabilities, flow properties. Protocols for pushing models from
controller to devices, devices to controller)
o Scalable size (long distances (many km) and short distances Digital Rights Management (DRM) is very important to the audio and
(within a single machine), many hops (radio repeaters, microwave video industries. Any time protected content is introduced into a
links, fiber links...) and short hops (single machine)) network there are DRM concerns that must be maintained (see
[CONTENT_PROTECTION]). Many aspects of DRM are outside the scope of
network technology, however there are cases when a secure link
supporting authentication and encryption is required by content
owners to carry their audio or video content when it is outside their
own secure environment (for example see [DCI]).
o Scalable timing parameters and accuracy (bounded latency, As an example, two techniques are Digital Transmission Content
guaranteed worst case maximum, minimum. Low latency, e.g. control Protection (DTCP) and High-Bandwidth Digital Content Protection
loops may be less than 1ms, but larger for wide area networks) (HDCP). HDCP content is not approved for retransmission within any
other type of DRM, while DTCP may be retransmitted under HDCP.
Therefore if the source of a stream is outside of the network and it
uses HDCP protection it is only allowed to be placed on the network
with that same HDCP protection.
o High availability (99.9999 percent up time requested, but may be 9.4. Pro Audio and Video - Link Aggregation
up to twelve 9s)
o Reliability, redundancy (lives at stake) Note: The term "Link Aggregation" is used here as defined by the text
in the following paragraph, i.e. not following a more common Network
Industry definition. Current WG consensus is that this item won't be
directly supported by the DetNet architecture, for example because it
implies guarantee of in-order delivery of packets which conflicts
with the core goal of achieving the lowest possible latency.
o Security (from failures, attackers, misbehaving devices - For transmitting streams that require more bandwidth than a single
sensitive to both packet content and arrival time) link in the target network can support, link aggregation is a
technique for combining (aggregating) the bandwidth available on
multiple physical links to create a single logical link of the
required bandwidth. However, if aggregation is to be used, the
network controller (or equivalent) must be able to determine the
maximum latency of any path through the aggregate link.
10. Acknowledgments 10. Acknowledgments
10.1. Pro Audio 10.1. Pro Audio
This section was derived from draft-gunther-detnet-proaudio-req-01. This section was derived from draft-gunther-detnet-proaudio-req-01.
The editors would like to acknowledge the help of the following The editors would like to acknowledge the help of the following
individuals and the companies they represent: individuals and the companies they represent:
skipping to change at page 60, line 12 skipping to change at page 62, line 41
<http://www.ieee1904.org/3/meeting_archive/2015/02/ <http://www.ieee1904.org/3/meeting_archive/2015/02/
tf3_1502_che n_1a.pdf>. tf3_1502_che n_1a.pdf>.
[HART] www.hartcomm.org, "Highway Addressable remote Transducer, [HART] www.hartcomm.org, "Highway Addressable remote Transducer,
a group of specifications for industrial process and a group of specifications for industrial process and
control devices administered by the HART Foundation". control devices administered by the HART Foundation".
[I-D.finn-detnet-architecture] [I-D.finn-detnet-architecture]
Finn, N., Thubert, P., and M. Teener, "Deterministic Finn, N., Thubert, P., and M. Teener, "Deterministic
Networking Architecture", draft-finn-detnet- Networking Architecture", draft-finn-detnet-
architecture-03 (work in progress), March 2016. architecture-04 (work in progress), March 2016.
[I-D.finn-detnet-problem-statement] [I-D.finn-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-finn-detnet-problem-statement-04 (work Statement", draft-finn-detnet-problem-statement-05 (work
in progress), October 2015. in progress), March 2016.
[I-D.ietf-6tisch-6top-interface] [I-D.ietf-6tisch-6top-interface]
Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
(6top) Interface", draft-ietf-6tisch-6top-interface-04 (6top) Interface", draft-ietf-6tisch-6top-interface-04
(work in progress), July 2015. (work in progress), July 2015.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
in progress), November 2015. in progress), June 2016.
[I-D.ietf-6tisch-coap] [I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-03 (work Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
in progress), March 2015. in progress), March 2015.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-06 (work in 802.15.4e", draft-ietf-6tisch-terminology-07 (work in
progress), November 2015. progress), March 2016.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.ietf-mpls-residence-time] [I-D.ietf-mpls-residence-time]
Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and S. Sasha, "Residence Time Measurement in MPLS and S. Vainshtein, "Residence Time Measurement in MPLS
network", draft-ietf-mpls-residence-time-06 (work in network", draft-ietf-mpls-residence-time-09 (work in
progress), March 2016. progress), April 2016.
[I-D.ietf-roll-rpl-industrial-applicability] [I-D.ietf-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-ietf-roll- applicability in industrial networks", draft-ietf-roll-
rpl-industrial-applicability-02 (work in progress), rpl-industrial-applicability-02 (work in progress),
October 2013. October 2013.
[I-D.ietf-tictoc-1588overmpls] [I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS Montini, "Transporting Timing messages over MPLS
 End of changes. 60 change blocks. 
173 lines changed or deleted 266 lines changed or added

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