draft-ietf-detnet-use-cases-00.txt   draft-ietf-detnet-use-cases-01.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: June 17, 2016 HARMAN Expires: August 12, 2016 HARMAN
P. Thubert P. Thubert
P. Wetterwald P. Wetterwald
CISCO CISCO
J. Raymond J. Raymond
HYDRO-QUEBEC HYDRO-QUEBEC
J. Korhonen J. Korhonen
BROADCOM BROADCOM
Y. Kaneko Y. Kaneko
Toshiba Toshiba
S. Das S. Das
Applied Communication Sciences Applied Communication Sciences
Y. Zha Y. Zha
HUAWEI HUAWEI
December 15, 2015 B. Varga
J. Farkas
Ericsson
F. Goetz
J. Schmitt
Siemens
February 9, 2016
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-00 draft-ietf-detnet-use-cases-01
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 15 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 June 17, 2016. This Internet-Draft will expire on August 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5 2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6 2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6
2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 6 2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 6
2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 6 2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7
2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8 2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8
2.3. Additional Stream Requirements . . . . . . . . . . . . . 8 2.3. Additional Stream Requirements . . . . . . . . . . . . . 9
2.3.1. Deterministic Time to Establish Streaming . . . . . . 8 2.3.1. Deterministic Time to Establish Streaming . . . . . . 9
2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9 2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9
2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9 2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10
2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 9 2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10
2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10 2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10
2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 10 2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 10
2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 10 2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 11
2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11 2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11
2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11 2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11
2.4. Integration of Reserved Streams into IT Networks . . . . 11 2.4. Integration of Reserved Streams into IT Networks . . . . 12
2.5. Security Considerations . . . . . . . . . . . . . . . . . 11 2.5. Security Considerations . . . . . . . . . . . . . . . . . 12
2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12 2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12
2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12 2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12
2.6. A State-of-the-Art Broadcast Installation Hits Technology 2.6. A State-of-the-Art Broadcast Installation Hits Technology
Limits . . . . . . . . . . . . . . . . . . . . . . . . . 12 Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 13 2.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 13
3. Utility Telecom Use Cases . . . . . . . . . . . . . . . . . . 13 3. Utility Telecom Use Cases . . . . . . . . . . . . . . . . . . 13
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Telecommunications Trends and General telecommunications 3.2. Telecommunications Trends and General telecommunications
Requirements . . . . . . . . . . . . . . . . . . . . . . 14 Requirements . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. General Telecommunications Requirements . . . . . . . 14 3.2.1. General Telecommunications Requirements . . . . . . . 15
3.2.1.1. Migration to Packet-Switched Network . . . . . . 15 3.2.1.1. Migration to Packet-Switched Network . . . . . . 16
3.2.2. Applications, Use cases and traffic patterns . . . . 16 3.2.2. Applications, Use cases and traffic patterns . . . . 17
3.2.2.1. Transmission use cases . . . . . . . . . . . . . 16 3.2.2.1. Transmission use cases . . . . . . . . . . . . . 17
3.2.2.2. Distribution use case . . . . . . . . . . . . . . 26 3.2.2.2. Distribution use case . . . . . . . . . . . . . . 26
3.2.2.3. Generation use case . . . . . . . . . . . . . . . 29 3.2.2.3. Generation use case . . . . . . . . . . . . . . . 29
3.2.3. Specific Network topologies of Smart Grid 3.2.3. Specific Network topologies of Smart Grid
Applications . . . . . . . . . . . . . . . . . . . . 30 Applications . . . . . . . . . . . . . . . . . . . . 30
3.2.4. Precision Time Protocol . . . . . . . . . . . . . . . 31 3.2.4. Precision Time Protocol . . . . . . . . . . . . . . . 31
3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 32 3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 32
3.4. Security Considerations . . . . . . . . . . . . . . . . . 32 3.4. Security Considerations . . . . . . . . . . . . . . . . . 32
3.4.1. Current Practices and Their Limitations . . . . . . . 32 3.4.1. Current Practices and Their Limitations . . . . . . . 32
3.4.2. Security Trends in Utility Networks . . . . . . . . . 34 3.4.2. Security Trends in Utility Networks . . . . . . . . . 34
3.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 35 3.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 35
skipping to change at page 4, line 9 skipping to change at page 4, line 14
5.3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . 53 5.3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . 53
5.4. Operations of Interest for DetNet and PCE . . . . . . . . 54 5.4. Operations of Interest for DetNet and PCE . . . . . . . . 54
5.4.1. Packet Marking and Handling . . . . . . . . . . . . . 55 5.4.1. Packet Marking and Handling . . . . . . . . . . . . . 55
5.4.1.1. Tagging Packets for Flow Identification . . . . . 55 5.4.1.1. Tagging Packets for Flow Identification . . . . . 55
5.4.1.2. Replication, Retries and Elimination . . . . . . 55 5.4.1.2. Replication, Retries and Elimination . . . . . . 55
5.4.1.3. Differentiated Services Per-Hop-Behavior . . . . 56 5.4.1.3. Differentiated Services Per-Hop-Behavior . . . . 56
5.4.2. Topology and capabilities . . . . . . . . . . . . . . 56 5.4.2. Topology and capabilities . . . . . . . . . . . . . . 56
5.5. Security Considerations . . . . . . . . . . . . . . . . . 57 5.5. Security Considerations . . . . . . . . . . . . . . . . . 57
5.6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 57 5.6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 57
6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 57 6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 57
6.1. Introduction and background . . . . . . . . . . . . . . . 58 6.1. Introduction and background . . . . . . . . . . . . . . . 57
6.2. Network architecture . . . . . . . . . . . . . . . . . . 61 6.2. Network architecture . . . . . . . . . . . . . . . . . . 61
6.3. Time synchronization requirements . . . . . . . . . . . . 62 6.3. Time synchronization requirements . . . . . . . . . . . . 62
6.4. Time-sensitive stream requirements . . . . . . . . . . . 63 6.4. Time-sensitive stream requirements . . . . . . . . . . . 63
6.5. Security considerations . . . . . . . . . . . . . . . . . 64 6.5. Security considerations . . . . . . . . . . . . . . . . . 64
7. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 64 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 64
7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 65 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 65
7.2. Critical Delay Requirements . . . . . . . . . . . . . . . 66 7.2. Terminology and Definitions . . . . . . . . . . . . . . . 65
7.3. Coordinated multipoint processing (CoMP) . . . . . . . . 66 7.3. Machine to Machine communication over IP networks . . . . 65
7.3.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 66 7.4. Machine to Machine communication requirements . . . . . . 66
7.3.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 67 7.4.1. Transport parameters . . . . . . . . . . . . . . . . 67
7.4. Industrial Automation . . . . . . . . . . . . . . . . . . 68 7.4.2. Flow maintenance . . . . . . . . . . . . . . . . . . 67
7.5. Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . 68 7.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.6. Gaming, Media and Virtual Reality . . . . . . . . . . . . 69 7.6. Security Considerations . . . . . . . . . . . . . . . . . 68
8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 69 7.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 68
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 8. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 68
10. Informative References . . . . . . . . . . . . . . . . . . . 70 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 8.2. Critical Delay Requirements . . . . . . . . . . . . . . . 69
8.3. Coordinated multipoint processing (CoMP) . . . . . . . . 70
8.3.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 70
8.3.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 71
8.4. Industrial Automation . . . . . . . . . . . . . . . . . . 71
8.5. Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . 71
8.6. Gaming, Media and Virtual Reality . . . . . . . . . . . . 72
9. Use Case Common Elements . . . . . . . . . . . . . . . . . . 72
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73
11. Informative References . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
This draft presents use cases from diverse industries which have in This draft presents use cases from diverse industries which have in
common a need for deterministic streams, but which also differ common a need for deterministic streams, but which also differ
notably in their network topologies and specific desired behavior. notably in their network topologies and specific desired behavior.
Together, they provide broad industry context for DetNet and a Together, they provide broad industry context for DetNet and a
yardstick against which proposed DetNet designs can be measured (to yardstick against which proposed DetNet designs can be measured (to
what extent does a proposed design satisfy these various use cases?) what extent does a proposed design satisfy these various use cases?)
For DetNet, use cases explicitly do not define requirements; The For DetNet, use cases explicitly do not define requirements; The
DetNet WG will consider the use cases, decide which elements are in DetNet WG will consider the use cases, decide which elements are in
scope for DetNet, and the results will be incorporated into future scope for DetNet, and the results will be incorporated into future
drafts. Similarly, the DetNet use case draft explicitly does not drafts. Similarly, the DetNet use case draft explicitly does not
suggest any specific design, architecture or protocols, which will be suggest any specific design, architecture or protocols, which will be
topics of future drafts. topics of future drafts.
We present for each use case the answers to the following questions: We present for each use case the answers to the following questions:
o What is the use case? o What is the use case?
skipping to change at page 9, line 26 skipping to change at page 9, line 40
transitioning from one camera feed to another. Such systems transitioning from one camera feed to another. Such systems
currently use purpose-built hardware to switch feeds smoothly, currently use purpose-built hardware to switch feeds smoothly,
however there is a current initiative in the broadcast industry to however there is a current initiative in the broadcast industry to
switch to a packet-based infrastructure (see [STUDIO_IP] and the ESPN switch to a packet-based infrastructure (see [STUDIO_IP] and the ESPN
DC2 use case described below). DC2 use case described below).
2.3.2. Use of Unused Reservations by Best-Effort Traffic 2.3.2. 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 just reserve a ton of bandwidth and then never un-reserve users will just reserve a ton of bandwidth and then never un-reserve
it even though they are not using it, and soon they will have no it even though they are not using it, and soon they will have no
skipping to change at page 30, line 23 skipping to change at page 30, line 23
For the purpose of AGC we use static frequency measurements and For the purpose of AGC we use static frequency measurements and
averaging methods are used to get a more precise measure of system averaging methods are used to get a more precise measure of system
frequency in steady-state conditions. frequency in steady-state conditions.
During disturbances, more real-time dynamic measurements of system During disturbances, more real-time dynamic measurements of system
frequency are taken using PMUs, especially when different areas of frequency are taken using PMUs, especially when different areas of
the system exhibit different frequencies. But that is outside the the system exhibit different frequencies. But that is outside the
scope of this use case. scope of this use case.
+---------------------------------------------------+---------------+ +---------------------------------------------------+---------------+
| FCAG (Frequency Control Automatic Generation) | Attribute | | FCAG (Frequency Control Automatic Generation) | Attribute |
| Requirement | | | Requirement | |
+---------------------------------------------------+---------------+ +---------------------------------------------------+---------------+
| One way maximum delay | 500 ms | | One way maximum delay | 500 ms |
| Asymetric delay Required | No | | Asymetric delay Required | No |
| Maximum jitter | Not critical | | Maximum jitter | Not critical |
| Topology | Point to | | Topology | Point to |
| | point | | | point |
| Bandwidth | 20 Kbps | | Bandwidth | 20 Kbps |
| Availability | 99.999 | | Availability | 99.999 |
| precise timing required | Yes | | precise timing required | Yes |
skipping to change at page 45, line 27 skipping to change at page 45, line 27
Readers are expected to be familiar with all the terms and concepts Readers are expected to be familiar with all the terms and concepts
that are discussed in "Multi-link Subnet Support in IPv6" that are discussed in "Multi-link Subnet Support in IPv6"
[I-D.ietf-ipv6-multilink-subnets]. [I-D.ietf-ipv6-multilink-subnets].
The draft uses terminology defined or referenced in The draft uses terminology defined or referenced in
[I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-terminology] and
[I-D.ietf-roll-rpl-industrial-applicability]. [I-D.ietf-roll-rpl-industrial-applicability].
The draft also conforms to the terms and models described in The draft also conforms to the terms and models described in
[RFC3444] and uses the vocabulary and the concepts defined in [RFC3444] and uses the vocabulary and the concepts defined in
[RFC4291] for the IPv6 Architecture. [RFC4291] for the IPv6 Architecture.
5.3. 6TiSCH Overview 5.3. 6TiSCH Overview
The scope of the present work is a subnet that, in its basic The scope of the present work is a subnet that, in its basic
configuration, is made of a TSCH [RFC7554] MAC Low Power Lossy configuration, is made of a TSCH [RFC7554] MAC Low Power Lossy
Network (LLN). Network (LLN).
---+-------- ............ ------------ ---+-------- ............ ------------
| External Network | | External Network |
skipping to change at page 46, line 6 skipping to change at page 46, line 6
+-----+ +-----+
o o o o o o
o o o o o o o o
o o LLN o o o o o LLN o o o
o o o o o o o o
o o
Figure 4: Basic Configuration of a 6TiSCH Network Figure 4: Basic Configuration of a 6TiSCH Network
In the extended configuration, a Backbone Router (6BBR) federates In the extended configuration, a Backbone Router (6BBR) federates
multiple 6TiSCH in a single subnet over a backbone. 6TiSCH 6BBRs multiple 6TiSCH in a single subnet over a backbone. 6TiSCH 6BBRs
synchronize with one another over the backbone, so as to ensure that synchronize with one another over the backbone, so as to ensure that
the multiple LLNs that form the IPv6 subnet stay tightly the multiple LLNs that form the IPv6 subnet stay tightly
synchronized. synchronized.
---+-------- ............ ------------ ---+-------- ............ ------------
| External Network | | External Network |
| +-----+ | +-----+
| +-----+ | NME | | +-----+ | NME |
+-----+ | +-----+ | | +-----+ | +-----+ | |
| | Router | | PCE | +-----+ | | Router | | PCE | +-----+
skipping to change at page 54, line 34 skipping to change at page 54, line 34
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 Tracks. 6TiSCH expects that the programing of behavior for multiple Tracks. 6TiSCH expects that the programing of
the schedule will be done over COAP as discussed in 6TiSCH Resource the schedule will be done over COAP as discussed in 6TiSCH Resource
Management and Interaction using CoAP [I-D.ietf-6tisch-coap]. Management and Interaction using CoAP [I-D.ietf-6tisch-coap].
But an Hybrid mode may be required as well whereby a single Track is But an Hybrid mode may be required as well whereby a single Track is
added, modified, or removed, for instance if it appears that a Track added, modified, or removed, for instance if it appears that a Track
does not perform as expected for, say, PDR. For that case, the does not perform as expected for, say, PDR. For that case, the
expectation is that a protocol that flows along a Track (to be), in a expectation is that a protocol that flows along a Track (to be), in a
fashion similar to classical Traffic Engineering (TE) [CCAMP], may be fashion similar to classical Traffic Engineering (TE) [CCAMP], may be
used to update the state in the devices. 6TiSCH provides means for a used to update the state in the devices. 6TiSCH provides means for a
device to negotiate a timeSlot with a neighbor, but in general that device to negotiate a timeSlot with a neighbor, but in general that
flow was not designed and no protocol was selected and it is expected flow was not designed and no protocol was selected and it is expected
that DetNet will determine the appropriate end-to-end protocols to be that DetNet will determine the appropriate end-to-end protocols to be
used in that case. used in that case.
Stream Management Entity
Operational System and HMI Operational System and HMI
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
PCE PCE PCE PCE PCE PCE PCE PCE
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
6TiSCH / Device Device Device Device \ 6TiSCH / Device Device Device Device \
Device- - 6TiSCH Device- - 6TiSCH
\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
----Device------Device------Device------Device-- ----Device------Device------Device------Device--
Figure 8 Figure 8: Stream Management Entity
5.4.1. Packet Marking and Handling 5.4.1. Packet Marking and Handling
Section "Packet Marking and Handling" of Section "Packet Marking and Handling" of
[I-D.ietf-6tisch-architecture] describes the packet tagging and [I-D.ietf-6tisch-architecture] describes the packet tagging and
marking that is expected in 6TiSCH networks. marking that is expected in 6TiSCH networks.
5.4.1.1. Tagging Packets for Flow Identification 5.4.1.1. Tagging Packets for Flow Identification
For packets that are routed by a PCE along a Track, the tuple formed For packets that are routed by a PCE along a Track, the tuple formed
skipping to change at page 61, line 30 skipping to change at page 61, line 24
architecture, which also has fronthaul and midhaul network segments. architecture, which also has fronthaul and midhaul network segments.
The fronthaul refers to the network connecting base stations (base The fronthaul refers to the network connecting base stations (base
band processing units) to the remote radio heads (antennas). The band processing units) to the remote radio heads (antennas). The
midhaul network typically refers to the network inter-connecting base midhaul network typically refers to the network inter-connecting base
stations (or small/pico cells). stations (or small/pico cells).
Fronthaul networks build on the available excess time after the base Fronthaul networks build on the available excess time after the base
band processing of the radio frame has completed. Therefore, the band processing of the radio frame has completed. Therefore, the
available time for networking is actually very limited, which in available time for networking is actually very limited, which in
practise determines how far the remote radio heads can be from the practise determines how far the remote radio heads can be from the
base band processing units (i.e. base stations). For example, in a base band processing units (i.e. base stations). For example, in a
case of LTE radio the Hybrid ARQ processing of a radio frame is case of LTE radio the Hybrid ARQ processing of a radio frame is
allocated 3 ms. Typically the processing completes way earlier (say allocated 3 ms. Typically the processing completes way earlier (say
up to 400 us, could be much less, though) thus allowing the remaining up to 400 us, could be much less, though) thus allowing the remaining
time to be used e.g. for fronthaul network. 200 us equals roughly 40 time to be used e.g. for fronthaul network. 200 us equals roughly 40
km of optical fiber based transport (assuming round trip time would km of optical fiber based transport (assuming round trip time would
be total 2*200 us). The base band processing time and the available be total 2*200 us). The base band processing time and the available
"delay budget" for the fronthaul is a subject to change, possibly "delay budget" for the fronthaul is a subject to change, possibly
dramatically, in the forthcoming "5G" to meet, for example, the dramatically, in the forthcoming "5G" to meet, for example, the
envisioned reduced radio round trip times, and other architecural and envisioned reduced radio round trip times, and other architecural and
service requirements [NGMN]. service requirements [NGMN].
skipping to change at page 64, line 46 skipping to change at page 64, line 46
Establishing time-sensitive streams in the network entails reserving Establishing time-sensitive streams in the network entails reserving
networking resources sometimes for a considerable long time. It is networking resources sometimes for a considerable long time. It is
important that these reservation requests must be authenticated to important that these reservation requests must be authenticated to
prevent malicious reservation attempts from hostile nodes or even prevent malicious reservation attempts from hostile nodes or even
accidental misconfiguration. This is specifically important in a accidental misconfiguration. This is specifically important in a
case where the reservation requests span administrative domains. case where the reservation requests span administrative domains.
Furthermore, the reservation information itself should be digitally Furthermore, the reservation information itself should be digitally
signed to reduce the risk where a legitimate node pushed a stale or signed to reduce the risk where a legitimate node pushed a stale or
hostile configuration into the networking node. hostile configuration into the networking node.
7. Other Use Cases 7. Industrial M2M
(This section was derived from draft-zha-detnet-use-case-00) (This section was derived from draft-varga-industrial-m2m-00)
7.1. Introduction 7.1. Introduction
Traditional "industrial automation" and terminology usually refers to
automation of manufacturing, quality control and material processing.
In practice, it means that machine units in a plant floor need cyclic
control data exchange to upstream or downstream machine modules or to
a supervisory control in a local network, which is often based on
proprietary networking technologies today.
For such communication between industrial entities, it is critical to
ensure proper and deterministic end to end delivery time of messages
with (very) high reliability and robustness, especially in closed
loop automation control.
Moreover, the recent trend is to use standard networking technologies
in the local network and for connecting remote industrial automation
sites, e.g., over an enterprise or metro network which also carries
other types of traffic. Therefore, deterministic flows should be
guaranteed regardless of the amount of other flows in those networks
for the deployment of future industrial automation.
This document covers a selected industrial application, identifies
representative solutions used today, and points on new use cases an
IETF DetNet solution may enable.
7.2. Terminology and Definitions
DetNet: Deterministic Networking. [IETFDetNet]
M2M: Machine to Machine.
MES: Manufacturing-Execution-System.
PLC: Programmable Logic Control.
S-PLC: Supervisory Programmable Logic Control.
7.3. Machine to Machine communication over IP networks
In case of industrial automation, the actors of Machine to Machine
(M2M) communication are Programmable Logic Controls (PLC). The
communication between PLCs and between PLCs and the supervisory PLC
(S-PLC) is achieved via critical Control-Data-Streams Figure 10.
This draft focuses on PLC related communications and communication to
Manufacturing-Execution-System (MES) are out-of-scope. The PLC
related Control-Data-Streams are transmitted periodically and they
are established either with (i) a pre-configured payload or (ii) a
payload configuration during runtime.
S (Sensor)
\ +-----+
PLC__ \.--. .--. ---| MES |
\_( `. _( `./ +-----+
A------( Local )-------------( L2 )
( Net ) ( Net ) +-------+
/`--(___.-' `--(___.-' ----| S-PLC |
S_/ / PLC .--. / +-------+
A_/ \_( `.
(Actuator) ( Local )
( Net )
/`--(___.-'\
/ \ A
S A
Figure 10: Current generic industrial M2M network architecture
The network topologies used today by applications of industrial
automation are (i) daisy chain, (ii) ring and (iii) hub and spoke.
Such topologies are often used in telecommunication networks too. In
industrial networks comb (being a subset of daisy-chain) is also
used.
Some industrial applications require Time Synchronization (Sync) to
end nodes, which is also similar to some telecommunication networks,
e.g., mobile Radio Access Networks. For such time coordinated PLCs,
accuracy of 1 microseconds is required. In case of non-time
coordinated PLCs, a requirement for Time Sync may still exist, e.g.,
for time stamping of collected measurement (sensor) data.
7.4. Machine to Machine communication requirements
The requirements listed here refer to critical Control-Data-Streams.
Non-critical traffic of industrial automation applications can be
served with currently available prioritizing techniques.
In an industrial environment, non-time-critical traffic is related to
(i) communication of state, configuration, set-up, etc., (ii)
connection to Manufacturing-Execution-System (MES) and (iii) database
communication. Such type of traffic can use up to 80% of the
available bandwidth. There is a subset of non-time-critical traffic
that their bandwidth should be guaranteed.
The rest of this chapter is dealing only with time-critical traffic.
7.4.1. Transport parameters
The Cycle Time defines the frequency of message(s) between industrial
entities. The Cycle Time is application dependent, it is in the
range of 1ms - 100ms for critical Control-Data-Streams.
As industrial applications assume deterministic transport instead of
defining latency and delay variation parameters for critical Control-
Data-Stream parameters, it is enough to fulfill the upper bound of
latency (maximum latency). The communication must ensure a maximum
end to end delivery time of messages in the range of 100 microseconds
to 50 milliseconds depending on the control loop application.
Bandwidth requirements of Control-Data-Streams are usually calculated
directly from the bytes per cycle parameter of the control loop. For
PLC to PLC communication one can expect 2 - 32 streams with packet
size in the range of 100 - 700 bytes. For S-PLC to PLCs the number
of streams is higher up-to 256 streams need to be supported. Usually
no more than 20% of available bandwidth is used for critical Control-
Data-Streams in today's networks, which comprise Gbps links.
Usual PLC control loops are rather tolerant for packet loss.
Critical Control-Data-Streams accept no more than 1 packet loss per
consecutive communication cycles. The required network availability
is rather high, it hits the 5 nines (99,999%).
Based on the above parameters, it can be concluded that some form of
redundancy might be required for M2M communication. The actual
solution depends on several parameters, like cycle time, delivery
time, etc.
7.4.2. Flow maintenance
Most Critical Control-Data-Streams get created at startup, however,
flexibility is also needed during runtime (e.g. add / remove
machine). In an industrial environment, critical Control-Data-
Streams are created rather infrequent: ~10 times per day / week /
month. With the future advent of flexible production systems, flow
maintenance parameters are expected to increase significantly.
7.5. Summary
This document specifies an industrial machine-to-machine use-case in
the DetNet context.
7.6. Security Considerations
Industrial network scenarios require advanced security solutions.
Many of the current industrial production networks are physically
separated. Protection of critical flows are handled today by
gateways / firewalls.
7.7. Acknowledgements
The authors would like to thank Feng Chen and Marcel Kiessling for
their comments and suggestions.
8. Other Use Cases
(This section was derived from draft-zha-detnet-use-case-00)
8.1. Introduction
The rapid growth of the today's communication system and its access The rapid growth of the today's communication system and its access
into almost all aspects of daily life has led to great dependency on into almost all aspects of daily life has led to great dependency on
services it provides. The communication network, as it is today, has services it provides. The communication network, as it is today, has
applications such as multimedia and peer-to-peer file sharing applications such as multimedia and peer-to-peer file sharing
distribution that require Quality of Service (QoS) guarantees in distribution that require Quality of Service (QoS) guarantees in
terms of delay and jitter to maintain a certain level of performance. terms of delay and jitter to maintain a certain level of performance.
Meanwhile, mobile wireless communications has become an important Meanwhile, mobile wireless communications has become an important
part to support modern sociality with increasing importance over the part to support modern sociality with increasing importance over the
last years. A communication network of hard real-time and high last years. A communication network of hard real-time and high
reliability is essential for the next concurrent and next generation reliability is essential for the next concurrent and next generation
skipping to change at page 66, line 5 skipping to change at page 69, line 17
provisioning is just relative [rfc3393], which is not sufficient to provisioning is just relative [rfc3393], which is not sufficient to
some delay critical service since delay violation in an instance some delay critical service since delay violation in an instance
cannot be tolerated. Overall, the requirements from vertical cannot be tolerated. Overall, the requirements from vertical
industries seem to be well aligned with the expected low latency and industries seem to be well aligned with the expected low latency and
high determinist performance of future networks high determinist performance of future networks
This document describes several use cases and scenarios with This document describes several use cases and scenarios with
requirements on deterministic delay guarantee within the scope of the requirements on deterministic delay guarantee within the scope of the
deterministic network [I-D.finn-detnet-problem-statement]. deterministic network [I-D.finn-detnet-problem-statement].
7.2. Critical Delay Requirements 8.2. Critical Delay Requirements
Delay and jitter requirement has been take into account as a major Delay and jitter requirement has been take into account as a major
component in QoS provisioning since the birth of Internet. The delay component in QoS provisioning since the birth of Internet. The delay
sensitive networking with increasing importance become the root of sensitive networking with increasing importance become the root of
mobile wireless communications as well as the applicable areas which mobile wireless communications as well as the applicable areas which
are all greatly relied on low delay communications. Due to the best are all greatly relied on low delay communications. Due to the best
effort feature of the IP networking, mitigate contention and effort feature of the IP networking, mitigate contention and
buffering is the main solution to serve the delay sensitive service. buffering is the main solution to serve the delay sensitive service.
More bandwidth is assigned to keep the link low loaded or in another More bandwidth is assigned to keep the link low loaded or in another
word, reduce the probability of congestion. However, not only lack word, reduce the probability of congestion. However, not only lack
skipping to change at page 66, line 41 skipping to change at page 70, line 5
as 100 times of connected devices. As a result to that, simply as 100 times of connected devices. As a result to that, simply
adding redundant bandwidth provisioning can be no longer an efficient adding redundant bandwidth provisioning can be no longer an efficient
solution due to the high bandwidth requirements more than ever solution due to the high bandwidth requirements more than ever
before. In addition to the bandwidth provisioning, the critical flow before. In addition to the bandwidth provisioning, the critical flow
within its reserved resource should not be affected by other flows no within its reserved resource should not be affected by other flows no
matter the pressure of the network. Robust defense of critical flow matter the pressure of the network. Robust defense of critical flow
is also not depended on redundant bandwidth allocation. is also not depended on redundant bandwidth allocation.
Deterministic networking techniques in both layer-2 and layer-3 using Deterministic networking techniques in both layer-2 and layer-3 using
IETF protocol solutions can be promising to serve these scenarios. IETF protocol solutions can be promising to serve these scenarios.
7.3. Coordinated multipoint processing (CoMP) 8.3. Coordinated multipoint processing (CoMP)
In the wireless communication system, Coordinated multipoint In the wireless communication system, Coordinated multipoint
processing (CoMP) is considered as an effective technique to solve processing (CoMP) is considered as an effective technique to solve
the inter-cell interference problem to improve the cell-edge user the inter-cell interference problem to improve the cell-edge user
throughput [CoMP]. throughput [CoMP].
7.3.1. CoMP Architecture 8.3.1. CoMP Architecture
+--------------------------+ +--------------------------+
| CoMP | | CoMP |
+--+--------------------+--+ +--+--------------------+--+
| | | |
+----------+ +------------+ +----------+ +------------+
| Uplink | | Downlink | | Uplink | | Downlink |
+-----+----+ +--------+---+ +-----+----+ +--------+---+
| | | |
------------------- ----------------------- ------------------- -----------------------
| | | | | | | | | | | |
skipping to change at page 67, line 26 skipping to change at page 70, line 36
|Reception| | | | | |Transmission| | CB | | | |Reception| | | | | |Transmission| | CB | | |
+---------+ +----+ +-----+ +------------+ +-----+ +-----+ +---------+ +----+ +-----+ +------------+ +-----+ +-----+
| | | |
|----------- |------------- |----------- |-------------
| | | | | | | |
+------------+ +---------+ +----------+ +------------+ +------------+ +---------+ +----------+ +------------+
| Joint | | Soft | | Coherent | | Non- | | Joint | | Soft | | Coherent | | Non- |
|Equalization| |Combining| | JT | | Coherent JT| |Equalization| |Combining| | JT | | Coherent JT|
+------------+ +---------+ +----------+ +------------+ +------------+ +---------+ +----------+ +------------+
Figure 10: Framework of CoMP Technology Figure 11: Framework of CoMP Technology
As shown in Figure 10, CoMP reception and transmission is a framework As shown in Figure 11, CoMP reception and transmission is a framework
that multiple geographically distributed antenna nodes cooperate to that multiple geographically distributed antenna nodes cooperate to
improve the performance of the users served in the common cooperation improve the performance of the users served in the common cooperation
area. The design principal of CoMP is to extend the current single- area. The design principal of CoMP is to extend the current single-
cell to multi-UEs transmission to a multi-cell- to-multi-UEs cell to multi-UEs transmission to a multi-cell- to-multi-UEs
transmission by base station cooperation. In contrast to single-cell transmission by base station cooperation. In contrast to single-cell
scenario, CoMP has critical issues such as: Backhaul latency, CSI scenario, CoMP has critical issues such as: Backhaul latency, CSI
(Channel State Information) reporting and accuracy and Network (Channel State Information) reporting and accuracy and Network
complexity. Clearly the first two requirements are very much delay complexity. Clearly the first two requirements are very much delay
sensitive and will be discussed in next section. sensitive and will be discussed in next section.
7.3.2. Delay Sensitivity in CoMP 8.3.2. Delay Sensitivity in CoMP
As the essential feature of CoMP, signaling is exchanged between As the essential feature of CoMP, signaling is exchanged between
eNBs, the backhaul latency is the dominating limitation of the CoMP eNBs, the backhaul latency is the dominating limitation of the CoMP
performance. Generally, JT and JP may benefit from coordinating the performance. Generally, JT and JP may benefit from coordinating the
scheduling (distributed or centralized) of different cells in case scheduling (distributed or centralized) of different cells in case
that the signaling exchanging between eNBs is limited to 4-10ms. For that the signaling exchanging between eNBs is limited to 4-10ms. For
C-RAN the backhaul latency requirement is 250us while for D-RAN it is C-RAN the backhaul latency requirement is 250us while for D-RAN it is
4-15ms. And this delay requirement is not only rigid but also 4-15ms. And this delay requirement is not only rigid but also
absolute since any uncertainty in delay will down the performance absolute since any uncertainty in delay will down the performance
significantly. Note that, some operator's transport network is not significantly. Note that, some operator's transport network is not
build to support Layer-3 transfer in aggregation layer. In such build to support Layer-3 transfer in aggregation layer. In such
case, the signaling is exchanged through EPC which means delay is case, the signaling is exchanged through EPC which means delay is
supposed to be larger. CoMP has high requirement on delay and supposed to be larger. CoMP has high requirement on delay and
reliability which is lack by current mobile network systems and may reliability which is lack by current mobile network systems and may
impact the architecture of the mobile network. impact the architecture of the mobile network.
7.4. Industrial Automation 8.4. Industrial Automation
Traditional "industrial automation" terminology usually refers to Traditional "industrial automation" terminology usually refers to
automation of manufacturing, quality control and material processing. automation of manufacturing, quality control and material processing.
"Industrial internet" and "industrial 4.0" [EA12] is becoming a hot "Industrial internet" and "industrial 4.0" [EA12] is becoming a hot
topic based on the Internet of Things. This high flexible and topic based on the Internet of Things. This high flexible and
dynamic engineering and manufacturing will result in a lot of so- dynamic engineering and manufacturing will result in a lot of so-
called smart approaches such as Smart Factory, Smart Products, Smart called smart approaches such as Smart Factory, Smart Products, Smart
Mobility, and Smart Home/Buildings. No doubt that ultra high Mobility, and Smart Home/Buildings. No doubt that ultra high
reliability and robustness is a must in data transmission, especially reliability and robustness is a must in data transmission, especially
in the closed loop automation control application where delay in the closed loop automation control application where delay
requirement is below 1ms and packet loss less than 10E-9. All these requirement is below 1ms and packet loss less than 10E-9. All these
critical requirements on both latency and loss cannot be fulfilled by critical requirements on both latency and loss cannot be fulfilled by
current 4G communication networks. Moreover, the collaboration of current 4G communication networks. Moreover, the collaboration of
the industrial automation from remote campus with cellular and fixed the industrial automation from remote campus with cellular and fixed
network has to be built on an integrated, cloud-based platform. In network has to be built on an integrated, cloud-based platform. In
this way, the deterministic flows should be guaranteed regardless of this way, the deterministic flows should be guaranteed regardless of
the amount of other flows in the network. The lack of this mechanism the amount of other flows in the network. The lack of this mechanism
becomes the main obstacle in deployment on of industrial automation. becomes the main obstacle in deployment on of industrial automation.
7.5. Vehicle to Vehicle 8.5. Vehicle to Vehicle
V2V communication has gained more and more attention in the last few V2V communication has gained more and more attention in the last few
years and will be increasingly growth in the future. Not only years and will be increasingly growth in the future. Not only
equipped with direct communication system which is short ranged, V2V equipped with direct communication system which is short ranged, V2V
communication also requires wireless cellular networks to cover wide communication also requires wireless cellular networks to cover wide
range and more sophisticated services. V2V application in the area range and more sophisticated services. V2V application in the area
autonomous driving has very stringent requirements of latency and autonomous driving has very stringent requirements of latency and
reliability. It is critical that the timely arrival of information reliability. It is critical that the timely arrival of information
for safety issues. In addition, due to the limitation of processing for safety issues. In addition, due to the limitation of processing
of individual vehicle, passing information to the cloud can provide of individual vehicle, passing information to the cloud can provide
more functions such as video processing, audio recognition or more functions such as video processing, audio recognition or
navigation systems. All of those requirements lead to a highly navigation systems. All of those requirements lead to a highly
reliable connectivity to the cloud. On the other hand, it is natural reliable connectivity to the cloud. On the other hand, it is natural
that the provisioning of low latency communication is one of the main that the provisioning of low latency communication is one of the main
challenges to be overcome as a result of the high mobility, the high challenges to be overcome as a result of the high mobility, the high
penetration losses caused by the vehicle itself. As result of that, penetration losses caused by the vehicle itself. As result of that,
the data transmission with latency below 5ms and a high reliability the data transmission with latency below 5ms and a high reliability
of PER below 10E-6 are demanded. It can benefit from the deployment of PER below 10E-6 are demanded. It can benefit from the deployment
of deterministic networking with high reliability. of deterministic networking with high reliability.
7.6. Gaming, Media and Virtual Reality 8.6. Gaming, Media and Virtual Reality
Online gaming and cloud gaming is dominating the gaming market since Online gaming and cloud gaming is dominating the gaming market since
it allow multiple players to play together with more challenging and it allow multiple players to play together with more challenging and
competing. Connected via current internet, the latency can be a big competing. Connected via current internet, the latency can be a big
issue to degrade the end users' experience. There different types of issue to degrade the end users' experience. There different types of
games and FPS (First Person Shooting) gaming has been considered to games and FPS (First Person Shooting) gaming has been considered to
be the most latency sensitive online gaming due to the high be the most latency sensitive online gaming due to the high
requirements of timing precision and computing of moving target. requirements of timing precision and computing of moving target.
Virtual reality is also receiving more interests than ever before as Virtual reality is also receiving more interests than ever before as
a novel gaming experience. The delay here can be very critical to a novel gaming experience. The delay here can be very critical to
skipping to change at page 69, line 33 skipping to change at page 72, line 42
jitter requirements have to be taken into account to meet the user jitter requirements have to be taken into account to meet the user
demand. To make the smoothness of the video and audio, delay and demand. To make the smoothness of the video and audio, delay and
jitter has to be guaranteed to avoid possible interruption which is jitter has to be guaranteed to avoid possible interruption which is
the killer of all online media on demand service. Now with 4K and 8K the killer of all online media on demand service. Now with 4K and 8K
video in the near future, the delay guarantee become one of the most video in the near future, the delay guarantee become one of the most
challenging issue than ever before. 4K/8K UHD video service requires challenging issue than ever before. 4K/8K UHD video service requires
6Gbps-100Gbps for uncompressed video and compressed video starting 6Gbps-100Gbps for uncompressed video and compressed video starting
from 60Mbps. The delay requirement is 100ms while some specific from 60Mbps. The delay requirement is 100ms while some specific
interactive applications may require 10ms delay [UHD-video]. interactive applications may require 10ms delay [UHD-video].
8. Use Case Common Elements 9. Use Case Common Elements
Looking at the use cases collectively, the following common desires Looking at the use cases collectively, the following common desires
for the DetNet-based networks of the future emerge: for the DetNet-based networks of the future emerge:
o Open standards-based network (replace various proprietary o Open standards-based network (replace various proprietary
networks, reduce cost, create multi-vendor market) networks, reduce cost, create multi-vendor market)
o Centrally administered (though such administration may be o Centrally administered (though such administration may be
distributed for scale and resiliency) distributed for scale and resiliency)
skipping to change at page 70, line 30 skipping to change at page 73, line 38
loops may be less than 1ms, but larger for wide area networks) loops may be less than 1ms, but larger for wide area networks)
o High availability (99.9999 percent up time requested, but may be o High availability (99.9999 percent up time requested, but may be
up to twelve 9s) up to twelve 9s)
o Reliability, redundancy (lives at stake) o Reliability, redundancy (lives at stake)
o Security (from failures, attackers, misbehaving devices - o Security (from failures, attackers, misbehaving devices -
sensitive to both packet content and arrival time) sensitive to both packet content and arrival time)
9. Acknowledgments 10. Acknowledgments
This document has benefited from reviews, suggestions, comments and This document has benefited from reviews, suggestions, comments and
proposed text provided by the following members, listed in proposed text provided by the following members, listed in
alphabetical order: Jing Huang, Junru Lin, Lehong Niu and Oilver alphabetical order: Jing Huang, Junru Lin, Lehong Niu and Oilver
Huang. Huang.
10. Informative References 11. Informative References
[ACE] IETF, "Authentication and Authorization for Constrained [ACE] IETF, "Authentication and Authorization for Constrained
Environments", <https://datatracker.ietf.org/doc/charter- Environments", <https://datatracker.ietf.org/doc/charter-
ietf-ace/>. ietf-ace/>.
[bacnetip] [bacnetip]
ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP", ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP",
January 1999. January 1999.
[CCAMP] IETF, "Common Control and Measurement Plane", [CCAMP] IETF, "Common Control and Measurement Plane",
skipping to change at page 74, line 22 skipping to change at page 77, line 36
<http://www.ieee802.org/1/pages/avbridges.html>. <http://www.ieee802.org/1/pages/avbridges.html>.
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks". Wireless Personal Area Networks".
[IEEE802154e] [IEEE802154e]
IEEE standard for Information Technology, "IEEE standard IEEE standard for Information Technology, "IEEE standard
for Information Technology, IEEE std. 802.15.4, Part. for Information Technology, IEEE std. 802.15.4, Part.
15.4: Wireless Medium Access Control (MAC) and Physical 15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks, June 2011 as amended by IEEE std. Area Networks, June 2011 as amended by IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer", April Networks (LR-WPANs) Amendment 1: MAC sublayer", April
2012. 2012.
[IEEE8021AS] [IEEE8021AS]
IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)",
IEEE 802.1AS-2001, 2011, IEEE 802.1AS-2001, 2011,
<http://standards.ieee.org/getIEEE802/ <http://standards.ieee.org/getIEEE802/
download/802.1AS-2011.pdf>. download/802.1AS-2011.pdf>.
[IEEE8021CM] [IEEE8021CM]
Farkas, J., "Time-Sensitive Networking for Fronthaul", Farkas, J., "Time-Sensitive Networking for Fronthaul",
Unapproved PAR, PAR for a New IEEE Standard; Unapproved PAR, PAR for a New IEEE Standard;
IEEE P802.1CM, April 2015, IEEE P802.1CM, April 2015,
<http://www.ieee802.org/1/files/public/docs2015/ <http://www.ieee802.org/1/files/public/docs2015/
new-P802-1CM-dr aft-PAR-0515-v02.pdf>. new-P802-1CM-dr aft-PAR-0515-v02.pdf>.
[IEEE8021TSN]
IEEE 802.1, "The charter of the TG is to provide the
specifications that will allow time-synchronized low
latency streaming services through 802 networks.", 2016,
<http://www.ieee802.org/1/pages/tsn.html>.
[IETFDetNet]
IETF, "Charter for IETF DetNet Working Group", 2015,
<https://datatracker.ietf.org/wg/detnet/charter/>.
[ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation",
<https://www.isa.org/isa100/>. <https://www.isa.org/isa100/>.
[ISA100.11a] [ISA100.11a]
ISA/ANSI, "Wireless Systems for Industrial Automation: ISA/ANSI, "Wireless Systems for Industrial Automation:
Process Control and Related Applications - ISA100.11a-2011 Process Control and Related Applications - ISA100.11a-2011
- IEC 62734", 2011, <http://www.isa.org/Community/ - IEC 62734", 2011, <http://www.isa.org/Community/
SP100WirelessSystemsforAutomation>. SP100WirelessSystemsforAutomation>.
[ISO7240-16] [ISO7240-16]
skipping to change at line 3642 skipping to change at page 84, line 39
Applied Communication Sciences Applied Communication Sciences
150 Mount Airy Road, Basking Ridge 150 Mount Airy Road, Basking Ridge
New Jersey, 07920, USA New Jersey, 07920, USA
Email: sdas@appcomsci.com Email: sdas@appcomsci.com
Yiyong Zha Yiyong Zha
Huawei Technologies Huawei Technologies
Email: zhayiyong@huawei.com Email: zhayiyong@huawei.com
Balazs Varga
Ericsson
Konyves Kalman krt. 11/B
Budapest 1097
Hungary
Email: balazs.a.varga@ericsson.com
Janos Farkas
Ericsson
Konyves Kalman krt. 11/B
Budapest 1097
Hungary
Email: janos.farkas@ericsson.com
Franz-Josef Goetz
Siemens
Gleiwitzerstr. 555
Nurnberg 90475
Germany
Email: franz-josef.goetz@siemens.com
Juergen Schmitt
Siemens
Gleiwitzerstr. 555
Nurnberg 90475
Germany
Email: juergen.jues.schmitt@siemens.com
 End of changes. 43 change blocks. 
58 lines changed or deleted 237 lines changed or added

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