draft-ietf-detnet-use-cases-11.txt   draft-ietf-detnet-use-cases-12.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: April 6, 2017 HARMAN Expires: October 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
J. Schmitt J. Schmitt
Siemens Siemens
X. Vilajosana X. Vilajosana
Worldsensing Worldsensing
T. Mahmoodi T. Mahmoodi
King's College London King's College London
S. Spirou S. Spirou
Intracom Telecom Intracom Telecom
P. Vizarreta P. Vizarreta
Technical University of Munich, TUM Technical University of Munich, TUM
October 3, 2016 April 3, 2017
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-11 draft-ietf-detnet-use-cases-12
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 28 skipping to change at page 2, line 28
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2017. This Internet-Draft will expire on October 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 6 2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 6
2.1. Use Case Description . . . . . . . . . . . . . . . . . . 6 2.1. Use Case Description . . . . . . . . . . . . . . . . . . 6
2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6 2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 7
2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 7 2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 7
2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7 2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 8
2.1.4. Deterministic Time to Establish Streaming . . . . . . 8 2.1.4. Deterministic Time to Establish Streaming . . . . . . 8
2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8 2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8
2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8 2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8
2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 9 2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 9
2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9 2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9 2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9
2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9 2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9
2.3.3. Integration of Reserved Streams into IT Networks . . 9 2.3.3. Integration of Reserved Streams into IT Networks . . 9
2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 10 2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 10
2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10 2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10
skipping to change at page 4, line 40 skipping to change at page 4, line 40
6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 54 6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 54
6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 55 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 55
6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 57 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 57
7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 57 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 57
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 57 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 57
7.2. Industrial M2M Communication Today . . . . . . . . . . . 58 7.2. Industrial M2M Communication Today . . . . . . . . . . . 58
7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 59 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 59
7.2.2. Stream Creation and Destruction . . . . . . . . . . . 60 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 60
7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 60 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 60
7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 60 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 60
8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 60 8. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 60
9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 61 8.1. Unified, standards-based network . . . . . . . . . . . . 61
9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 62 8.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 61
9.2. Internet-based Applications . . . . . . . . . . . . . . . 62 8.1.2. Centrally Administered . . . . . . . . . . . . . . . 61
9.2.1. Use Case Description . . . . . . . . . . . . . . . . 62 8.1.3. Standardized Data Flow Information Models . . . . . . 61
9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 63 8.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . . 61
9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 63 8.1.5. Guaranteed End-to-End Delivery . . . . . . . . . . . 61
9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 63 8.1.6. Replacement for Multiple Proprietary Deterministic
9.2.2. Internet-Based Applications Today . . . . . . . . . . 63 Networks . . . . . . . . . . . . . . . . . . . . . . 61
9.2.3. Internet-Based Applications Future . . . . . . . . . 63 8.1.7. Mix of Deterministic and Best-Effort Traffic . . . . 62
9.2.4. Internet-Based Applications Asks . . . . . . . . . . 63 8.1.8. Unused Reserved BW to be Available to Best Effort
9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 64 Traffic . . . . . . . . . . . . . . . . . . . . . . . 62
9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 64
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 8.1.9. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 62
10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 65 8.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . . 62
10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 65 8.3. Scalable Timing Parameters and Accuracy . . . . . . . . . 62
10.3. Building Automation Systems . . . . . . . . . . . . . . 65 8.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . . 62
10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 65 8.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . . 63
10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 66 8.3.3. Symmetrical Path Delays . . . . . . . . . . . . . . . 63
10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 66 8.4. High Reliability and Availability . . . . . . . . . . . . 63
10.7. Internet Applications and CoMP . . . . . . . . . . . . . 66 8.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 63
10.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 66 8.6. Deterministic Flows . . . . . . . . . . . . . . . . . . . 64
11. Informative References . . . . . . . . . . . . . . . . . . . 66 9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 64
9.2. Internet-based Applications . . . . . . . . . . . . . . . 65
9.2.1. Use Case Description . . . . . . . . . . . . . . . . 65
9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 65
9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 65
9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 65
9.2.2. Internet-Based Applications Today . . . . . . . . . . 65
9.2.3. Internet-Based Applications Future . . . . . . . . . 65
9.2.4. Internet-Based Applications Asks . . . . . . . . . . 66
9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 66
9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 66
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67
10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 67
10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 67
10.3. Building Automation Systems . . . . . . . . . . . . . . 67
10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 67
10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 68
10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 68
10.7. Internet Applications and CoMP . . . . . . . . . . . . . 68
10.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 68
11. Informative References . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
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 8, line 16 skipping to change at page 8, line 33
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 Note: The WG has decided that guidelines for deterministic time to
startup time) is within scope of DetNet. establish stream startup is not within scope of DetNet. If bounded
timing of establishing or re-establish streams is required in a given
Some audio systems installed in public environments (airports, use case, it is up to the application/system to achieve this. (The
hospitals) have unique requirements with regards to health, safety supporting text from this section has been removed as of draft 12).
and fire concerns. One such requirement is a maximum of 3 seconds
for a system to respond to an emergency detection and begin sending
appropriate warning signals and alarms without human intervention.
For this requirement to be met, the system must support a bounded and
acceptable time from a notification signal to specific stream
establishment. For further details see [ISO7240-16].
Similar requirements apply when the system is restarted after a power
cycle, cable re-connection, or system reconfiguration.
In many cases such re-establishment of streaming state must be
achieved by the peer devices themselves, i.e. without a central
controller (since such a controller may only be present during
initial network configuration).
Video systems introduce related requirements, for example when
transitioning from one camera feed (video stream) to another (see
[STUDIO_IP] and [ESPN_DC2]).
2.1.5. Secure Transmission 2.1.5. Secure Transmission
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
skipping to change at page 53, line 7 skipping to change at page 53, line 7
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.
In order to meet the timing requirements both senders and receivers In order to meet the timing requirements both senders and receivers
must remain time synchronized, demanding very accurate clock must remain time synchronized, demanding very accurate clock
distribution, for example support for IEEE 1588 transparent clocks in distribution, for example support for IEEE 1588 transparent clocks or
every intermediate node. boundary clocks in every intermediate node.
In cellular networks from the LTE radio era onward, phase In cellular networks from the LTE radio era onward, phase
synchronization is needed in addition to frequency synchronization synchronization is needed in addition to frequency synchronization
([TS36300], [TS23401]). ([TS36300], [TS23401]).
6.1.4. Transport Loss Constraints 6.1.4. Transport Loss Constraints
Fronthaul and Midhaul networks assume almost error-free transport. Fronthaul and Midhaul networks assume almost error-free transport.
Errors can result in a reset of the radio interfaces, which can cause Errors can result in a reset of the radio interfaces, which can cause
reduced throughput or broken radio connectivity for mobile customers. reduced throughput or broken radio connectivity for mobile customers.
skipping to change at page 60, line 48 skipping to change at page 60, line 48
o High availability (presumably through redundancy) (99.999 %) o High availability (presumably through redundancy) (99.999 %)
o Low message delivery time (100us - 50ms) o Low message delivery time (100us - 50ms)
o Low packet loss (burstless, 0.1-1 %) o Low packet loss (burstless, 0.1-1 %)
o Security (e.g. prevent critical flows from being leaked between o Security (e.g. prevent critical flows from being leaked between
physically separated networks) physically separated networks)
8. Use Case Common Elements 8. Use Case Common Themes
Looking at the use cases collectively, the following common desires This section summarizes the expected properties of a DetNet network,
for the DetNet-based networks of the future emerge: based on the use cases as described in this draft.
o Open standards-based network (replace various proprietary 8.1. Unified, standards-based network
networks, reduce cost, create multi-vendor market)
o Centrally administered (though such administration may be 8.1.1. Extensions to Ethernet
distributed for scale and resiliency)
o Integrates L2 (bridged) and L3 (routed) environments (independent A DetNet network is not "a new kind of network" - it based on
of the Link layer, e.g. can be used with Ethernet, 6TiSCH, etc.) extensions to existing Ethernet standards, including elements of IEEE
802.1 AVB/TSN and related standards. Presumably it will be possible
to run DetNet over other underlying transports besides Ethernet, but
Ethernet is explicitly supported.
o Carries both deterministic and best-effort traffic (guaranteed 8.1.2. Centrally Administered
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, In general a DetNet network is not expected to be "plug and play" -
bounded service interruption (applications include replacement of it is expected that there is some centralized network configuration
failed devices as well as plug and play) and control system. Such a system may be in a single central
location, or it maybe distributed across multiple control entities
that function together as a unified control system for the network.
However, the ability to "hot swap" components (e.g. due to
malfunction) is similar enough to "plug and play" that this kind of
behavior may be expected in DetNet networks, depending on the
implementation.
o Uses standardized data flow information models capable of 8.1.3. Standardized Data Flow Information Models
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 Data Flow Information Models to be used with DetNet networks are to
(within a single machine), many hops (radio repeaters, microwave be specified by DetNet.
links, fiber links...) and short hops (single machine))
o Scalable timing parameters and accuracy (bounded latency, 8.1.4. L2 and L3 Integration
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 A DetNet network is intended to integrate between Layer 2 (bridged)
up to twelve 9s) network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g.
using IP-based protocols). One example of this is "making AVB/TSN-
type deterministic performance available from Layer 3 applications,
e.g. using RTP". Another example is "connecting two AVB/TSN LANs
("islands") together through a standard router".
o Reliability, redundancy (lives at stake) 8.1.5. Guaranteed End-to-End Delivery
o Security (from failures, attackers, misbehaving devices - Packets sent over DetNet are guaranteed not to be dropped by the
sensitive to both packet content and arrival time) network due to congestion. (Packets may however be dropped for
intended reasons, e.g. per security measures).
8.1.6. Replacement for Multiple Proprietary Deterministic Networks
There are many proprietary non-interoperable deterministic Ethernet-
based networks currently available; DetNet is intended to provide an
open-standards-based alternative to such networks.
8.1.7. Mix of Deterministic and Best-Effort Traffic
DetNet is intended to support coexistance of time-sensitive
operational (OT) traffic and information (IT) traffic on the same
("unified") network.
8.1.8. Unused Reserved BW to be Available to Best Effort Traffic
If bandwidth reservations are made for a stream but the associated
bandwidth is not used at any point in time, that bandwidth is made
available on the network for best-effort traffic. If the owner of
the reserved stream then starts transmitting again, the bandwidth is
no longer available for best-effort traffic, on a moment-to-moment
basis. Note that such "temporarily available" bandwidth is not
available for time-sensitive traffic, which must have its own
reservation.
8.1.9. Lower Cost, Multi-Vendor Solutions
The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus
promoting device diversity and potentially higher numbers of each
device manufactured, promoting cost reduction and cost competition
among vendors. The intent is that DetNet networks should be able to
be created at lower cost and with greater diversity of available
devices than existing proprietary networks.
8.2. Scalable Size
DetNet networks range in size from very small, e.g. inside a single
industrial machine, to very large, for example a Utility Grid network
spanning a whole country, and involving many "hops" over various
kinds of links for example radio repeaters, microwave linkes, fiber
optic links, etc.. However recall that the scope of DetNet is
confined to networks that are centrally administered, and explicitly
excludes unbounded decentralized networks such as the Internet.
8.3. Scalable Timing Parameters and Accuracy
8.3.1. Bounded Latency
The DetNet Data Flow Information Model is expected to provide means
to configure the network that include parameters for querying network
path latency, requesting bounded latency for a given stream,
requesting worst case maximum and/or minimum latency for a given path
or stream, and so on. It is an expected case that the network may
not be able to provide a given requested service level, and if so the
network control system should reply that the requested services is
not available (as opposed to accepting the parameter but then not
delivering the desired behavior).
8.3.2. Low Latency
Applications may require "extremely low latency" however depending on
the application these may mean very different latency values; for
example "low latency" across a Utility grid network is on a different
time scale than "low latency" in a motor control loop in a small
machine. The intent is that the mechanisms for specifying desired
latency include wide ranges, and that architecturally there is
nothing to prevent arbirtrarily low latencies from being implemented
in a given network.
8.3.3. Symmetrical Path Delays
Some applications would like to specify that the transit delay time
values be equal for both the transmit and return paths.
8.4. High Reliability and Availability
Reliablity is of critical importance to many DetNet applications, in
which consequences of failure can be extraordinarily high in terms of
cost and even human life. DetNet based systems are expected to be
implemented with essentially arbitrarily high availability (for
example 99.9999% up time, or even 12 nines). The intent is that the
DetNet designs should not make any assumptions about the level of
reliability and availability that may be required of a given system,
and should define parameters for communicating these kinds of metrics
within the network.
A strategy used by DetNet for providing such extraordinarily high
levels of reliability is to provide redundant paths that can be
seamlessly switched between, while maintaining the required
performance of that system.
8.5. Security
Security is of critical importance to many DetNet applications. A
DetNet network must be able to be made secure against devices
failures, attackers, misbehaving devices, and so on. In a DetNet
network the data traffic is expected to be be time-sensitive, thus in
addition to arriving with the data content as intended, the data must
also arrive at the expected time. This may present "new" security
challenges to implementers, and must be addressed accordingly. There
are other security implications, including (but not limited to) the
change in attack surface presented by packet replication and
elimination.
8.6. Deterministic Flows
Reserved bandwidth data flows must be isolated from each other and
from best-effort traffic, so that even if the network is saturated
with best-effort (and/or reserved bandwidth) traffic, the configured
flows are not adversely affected.
9. Use Cases Explicitly Out of Scope for DetNet 9. Use Cases Explicitly Out of Scope for DetNet
This section contains use case text that has been determined to be This section contains use case text that has been determined to be
outside of the scope of the present DetNet work. outside of the scope of the present DetNet work.
9.1. DetNet Scope Limitations 9.1. DetNet Scope Limitations
The scope of DetNet is deliberately limited to specific use cases The scope of DetNet is deliberately limited to specific use cases
that are consistent with the WG charter, subject to the that are consistent with the WG charter, subject to the
skipping to change at page 68, line 17 skipping to change at page 70, line 22
Statement", draft-finn-detnet-problem-statement-05 (work Statement", draft-finn-detnet-problem-statement-05 (work
in progress), March 2016. in progress), March 2016.
[I-D.ietf-6tisch-6top-interface] [I-D.ietf-6tisch-6top-interface]
Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
(6top) Interface", draft-ietf-6tisch-6top-interface-04 (6top) Interface", draft-ietf-6tisch-6top-interface-04
(work in progress), July 2015. (work in progress), July 2015.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work
in progress), June 2016. in progress), January 2017.
[I-D.ietf-6tisch-coap] [I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-03 (work Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
in progress), March 2015. in progress), March 2015.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-07 (work in 802.15.4e", draft-ietf-6tisch-terminology-08 (work in
progress), March 2016. progress), December 2016.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.ietf-mpls-residence-time] [I-D.ietf-mpls-residence-time]
Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and S. Vainshtein, "Residence Time Measurement in MPLS and S. Vainshtein, "Residence Time Measurement in MPLS
network", draft-ietf-mpls-residence-time-11 (work in network", draft-ietf-mpls-residence-time-15 (work in
progress), July 2016. progress), March 2017.
[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. 26 change blocks. 
93 lines changed or deleted 209 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/