< draft-thubert-raw-technologies-02.txt   draft-thubert-raw-technologies-03.txt >
RAW P. Thubert, Ed. RAW P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational D. Cavalcanti Intended status: Informational D. Cavalcanti
Expires: December 21, 2019 Intel Expires: January 2, 2020 Intel
X. Vilajosana X. Vilajosana
Universitat Oberta de Catalunya Universitat Oberta de Catalunya
June 19, 2019 C. Schmitt
Universitaet der Bundeswehr Muenchen
July 1, 2019
Reliable and Available Wireless Technologies Reliable and Available Wireless Technologies
draft-thubert-raw-technologies-02 draft-thubert-raw-technologies-03
Abstract Abstract
This document presents a series of recent technologies that are This document presents a series of recent technologies that are
capable of time synchronization and scheduling of transmission, capable of time synchronization and scheduling of transmission,
making them suitable to carry time-sensitive flows with requirements making them suitable to carry time-sensitive flows with requirements
of both reliable delivery in bounded time, and availability at all of both reliable delivery in bounded time, and availability at all
times, regardless of packet transmission or individual equipement times, regardless of packet transmission or individual equipement
failures. failures.
skipping to change at page 1, line 38 skipping to change at page 1, line 40
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 21, 2019. This Internet-Draft will expire on January 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 16 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4 3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4 3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4
3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 5 3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 5
4. IEEE 802 standards . . . . . . . . . . . . . . . . . . . . . 6 4. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Provenance and Documents . . . . . . . . . . . . . . . . 6
4.1.1. Provenance and Documents . . . . . . . . . . . . . . 6 4.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . . . 8
4.1.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . 8 4.2.1. General Characteristics . . . . . . . . . . . . . . . 8
4.1.2.1. General Characteristics . . . . . . . . . . . . . 8 4.2.1.1. Multi-User OFDMA and Trigger-based Scheduled
4.1.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access . . . . . . . . . . . . . . . . . . . . . 8
Access . . . . . . . . . . . . . . . . . . . 8 4.2.1.2. Improved PHY Robustness . . . . . . . . . . . . . 8
4.1.2.1.2. Improved PHY Robustness . . . . . . . . . . . 8 4.2.1.3. Support for 6GHz band . . . . . . . . . . . . . . 9
4.1.2.1.3. Support for 6GHz band . . . . . . . . . . . . 9 4.2.2. Applicability to deterministic flows . . . . . . . . 9
4.1.2.2. Applicability to deterministic flows . . . . . . 9 4.2.2.1. 802.11 Managed network operation and admission
4.1.2.2.1. 802.11 Managed network operation and control . . . . . . . . . . . . . . . . . . . . . 9
admission control . . . . . . . . . . . . . . 9 4.2.2.2. Scheduling for bounded latency and diversity . . 10
4.1.2.2.2. Scheduling for bounded latency and diversity 10 4.3. 802.11be Extreme High Throughput (EHT) . . . . . . . . . 10
4.1.3. 802.11be Extreme High Throughput (EHT) . . . . . . . 10 4.3.1. General Characteristics . . . . . . . . . . . . . . . 10
4.1.3.1. General Characteristics . . . . . . . . . . . . . 10 4.3.2. Applicability to deterministic flows . . . . . . . . 11
4.1.3.2. Applicability to deterministic flows . . . . . . 11 4.3.2.1. Enhanced scheduled operation for bounded latency 11
4.1.3.2.1. Enhanced scheduled operation for bounded 4.3.2.2. Multi-AP coordination . . . . . . . . . . . . . . 11
latency . . . . . . . . . . . . . . . . . . . 11 4.3.2.3. Multi-band operation . . . . . . . . . . . . . . 12
4.1.3.2.2. Multi-AP coordination . . . . . . . . . . . . 11 4.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . . . 12
4.1.3.2.3. Multi-band operation . . . . . . . . . . . . 12 4.4.1. General Characteristics . . . . . . . . . . . . . . . 12
4.1.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . 12 4.4.2. Applicability to deterministic flows . . . . . . . . 12
4.1.4.1. General Characteristics . . . . . . . . . . . . . 12 5. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4.2. Applicability to deterministic flows . . . . . . 12 5.1. Provenance and Documents . . . . . . . . . . . . . . . . 13
4.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 13 5.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . . . 15
4.2.1. Provenance and Documents . . . . . . . . . . . . . . 13 5.2.1. General Characteristics . . . . . . . . . . . . . . . 15
4.2.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . 15 5.2.2. Applicability to Deterministic Flows . . . . . . . . 16
4.2.2.1. General Characteristics . . . . . . . . . . . . . 15 5.2.2.1. Centralized Path Computation . . . . . . . . . . 16
4.2.2.2. Applicability to Deterministic Flows . . . . . . 16 5.2.2.2. 6TiSCH Tracks . . . . . . . . . . . . . . . . . . 23
4.2.2.2.1. Centralized Path Computation . . . . . . . . 16 6. 3GPP Ultra-Reliable Low-Latency Communication . . . . . . . . 30
4.2.2.2.2. 6TiSCH Tracks . . . . . . . . . . . . . . . . 22 7. L-band Digital Aeronautical Communications System . . . . . . 30
5. 3GPP standards . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Provenance and Documents . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7.2. General Characteristics . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7.3. Applicability to Deterministic Flows . . . . . . . . . . 33
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 29 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 30 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
When used in math or philosophy, the term "deterministic" generally When used in math or philosophy, the term "deterministic" generally
refers to a perfection where all aspect are understood and refers to a perfection where all aspect are understood and
predictable. A perfectly Deterministic Network would ensure that predictable. A perfectly Deterministic Network would ensure that
every packet reach its destination following a predetermined path every packet reach its destination following a predetermined path
along a predefined schedule to be delivered at the exact due time. along a predefined schedule to be delivered at the exact due time.
In a real and imperfect world, a Deterministic Network must highly In a real and imperfect world, a Deterministic Network must highly
predictable, which is a combination of reliability and availability. predictable, which is a combination of reliability and availability.
skipping to change at page 6, line 5 skipping to change at page 6, line 7
limit to the ratio of isolated critical traffic. limit to the ratio of isolated critical traffic.
Finally, scheduling plays a critical role to save energy. In IOT, Finally, scheduling plays a critical role to save energy. In IOT,
energy is the foremost concern, and synchronizing sender and listener energy is the foremost concern, and synchronizing sender and listener
enables to always maintain them in deep sleep when there is no enables to always maintain them in deep sleep when there is no
scheduled transmission. This avoids idle listening and long scheduled transmission. This avoids idle listening and long
preambles and enables long sleep periods between traffic and preambles and enables long sleep periods between traffic and
resynchronization, allowing battery-operated nodes to operate in a resynchronization, allowing battery-operated nodes to operate in a
mesh topology for multiple years. mesh topology for multiple years.
4. IEEE 802 standards 4. IEEE 802.11
4.1. Provenance and Documents
With an active portfolio of nearly 1,300 standards and projects under With an active portfolio of nearly 1,300 standards and projects under
development, IEEE is a leading developer of industry standards in a development, IEEE is a leading developer of industry standards in a
broad range of technologies that drive the functionality, broad range of technologies that drive the functionality,
capabilities, and interoperability of products and services, capabilities, and interoperability of products and services,
transforming how people live, work, and communicate. transforming how people live, work, and communicate.
The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains
networking standards and recommended practices for local, networking standards and recommended practices for local,
metropolitan, and other area networks, using an open and accredited metropolitan, and other area networks, using an open and accredited
process, and advocates them on a global basis. The most widely used process, and advocates them on a global basis. The most widely used
standards are for Ethernet, Bridging and Virtual Bridged LANs standards are for Ethernet, Bridging and Virtual Bridged LANs
Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media
Independent Handover Services, and Wireless RAN. An individual Independent Handover Services, and Wireless RAN. An individual
Working Group provides the focus for each area. Standards produced Working Group provides the focus for each area. Standards produced
by the IEEE 802 SC are freely available from the IEEE GET Program by the IEEE 802 SC are freely available from the IEEE GET Program
after they have been published in PDF for six months. after they have been published in PDF for six months.
4.1. IEEE 802.11
4.1.1. Provenance and Documents
The IEEE 802.11 LAN standards define the underlying MAC and PHY The IEEE 802.11 LAN standards define the underlying MAC and PHY
layers for the Wi-Fi technology. Wi-Fi/802.11 is one of the most layers for the Wi-Fi technology. Wi-Fi/802.11 is one of the most
successful wireless technologies, supporting many application successful wireless technologies, supporting many application
domains. While previous 802.11 generations, such as 802.11n and domains. While previous 802.11 generations, such as 802.11n and
802.11ac, have focused mainly on improving peak throughput, more 802.11ac, have focused mainly on improving peak throughput, more
recent generations are also considering other performance vectors, recent generations are also considering other performance vectors,
such as efficiency enhancements for dense environments in 802.11ax, such as efficiency enhancements for dense environments in 802.11ax,
and latency and support for Time-Sensitive Networking (TSN) and latency and support for Time-Sensitive Networking (TSN)
capabilities in 802.11be. capabilities in 802.11be.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
11ax] 11ax]
IEEE 802.11be Extreme High Throughput (EHT). [IEEE80211be] IEEE 802.11be Extreme High Throughput (EHT). [IEEE80211be]
IEE 802.11ay Enhanced throughput for operation in license-exempt IEE 802.11ay Enhanced throughput for operation in license-exempt
bands above 45 GHz. [IEEE80211ay] bands above 45 GHz. [IEEE80211ay]
The main 802.11ax and 802.11be capabilities and their relevance to The main 802.11ax and 802.11be capabilities and their relevance to
RAW are discussed in the remainder of this document. RAW are discussed in the remainder of this document.
4.1.2. 802.11ax High Efficiency (HE) 4.2. 802.11ax High Efficiency (HE)
4.1.2.1. General Characteristics 4.2.1. General Characteristics
The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax
amendment [IEEE80211ax], which includes new capabilities to increase amendment [IEEE80211ax], which includes new capabilities to increase
efficiency, control and reduce latency. Some of the new features efficiency, control and reduce latency. Some of the new features
include higher order 1024-QAM modulation, support for uplink multi- include higher order 1024-QAM modulation, support for uplink multi-
user MIMO, OFDMA, trigger-based access and Target Wake time (TWT) for user MIMO, OFDMA, trigger-based access and Target Wake time (TWT) for
enhanced power savings. The OFDMA mode and trigger-based access enhanced power savings. The OFDMA mode and trigger-based access
enable scheduled operation, which is a key capability required to enable scheduled operation, which is a key capability required to
support deterministic latency and reliability for time-sensitive support deterministic latency and reliability for time-sensitive
flows. 802.11ax can operate in up to 160 MHz channels and it includes flows. 802.11ax can operate in up to 160 MHz channels and it includes
support for operation in the new 6 GHz band, which is expected to be support for operation in the new 6 GHz band, which is expected to be
open to unlicensed use by the FCC and other regulatory agencies open to unlicensed use by the FCC and other regulatory agencies
worldwide. worldwide.
4.1.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access 4.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access
802.11ax introduced a new orthogonal frequency-division multiple 802.11ax introduced a new orthogonal frequency-division multiple
access (OFDMA) mode in which multiple users can be scheduled across access (OFDMA) mode in which multiple users can be scheduled across
the frequency domain. In this mode, the Access Point (AP) can the frequency domain. In this mode, the Access Point (AP) can
initiate multi-user (MU) Uplink (UL) transmissions in the same PHY initiate multi-user (MU) Uplink (UL) transmissions in the same PHY
Protocol Data Unit (PPDU) by sending a trigger frame. This Protocol Data Unit (PPDU) by sending a trigger frame. This
centralized scheduling capability gives the AP much more control of centralized scheduling capability gives the AP much more control of
the channel, and it can remove contention between devices for uplink the channel, and it can remove contention between devices for uplink
transmissions, therefore reducing the randomness caused by CSMA-based transmissions, therefore reducing the randomness caused by CSMA-based
access between stations. The AP can also transmit simultaneously to access between stations. The AP can also transmit simultaneously to
multiple users in the downlink direction by using a Downlink (DL) MU multiple users in the downlink direction by using a Downlink (DL) MU
OFDMA PPDU. In order to initiate a contention free Transmission OFDMA PPDU. In order to initiate a contention free Transmission
Opportunity (TXOP) using the OFDMA mode, the AP still follows the Opportunity (TXOP) using the OFDMA mode, the AP still follows the
typical listen before talk procedure to acquire the medium, which typical listen before talk procedure to acquire the medium, which
ensures interoperability and compliance with unlicensed band access ensures interoperability and compliance with unlicensed band access
rules. However, 802.11ax also includes a multi-user Enhanced rules. However, 802.11ax also includes a multi-user Enhanced
Distributed Channel Access (MU-EDCA) capability, which allows the AP Distributed Channel Access (MU-EDCA) capability, which allows the AP
to get higher channel access priority. to get higher channel access priority.
4.1.2.1.2. Improved PHY Robustness 4.2.1.2. Improved PHY Robustness
The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard
interval (GI). The larger GI options provide better protection interval (GI). The larger GI options provide better protection
against multipath, which is expected to be a challenge in industrial against multipath, which is expected to be a challenge in industrial
environments. The possibility to operate with smaller resource units environments. The possibility to operate with smaller resource units
(e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and (e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and
improve SNR, leading to better packet error rate (PER) performance. improve SNR, leading to better packet error rate (PER) performance.
802.11ax supports beamforming as in 802.11ac, but introduces UL MU 802.11ax supports beamforming as in 802.11ac, but introduces UL MU
MIMO, which helps improve reliability. The UL MU MIMO capability is MIMO, which helps improve reliability. The UL MU MIMO capability is
also enabled by the trigger based access operation in 802.11ax. also enabled by the trigger based access operation in 802.11ax.
4.1.2.1.3. Support for 6GHz band 4.2.1.3. Support for 6GHz band
The 802.11ax specification [IEEE80211ax] includes support for The 802.11ax specification [IEEE80211ax] includes support for
operation in the new 6 GHz band. Given the amount of new spectrum operation in the new 6 GHz band. Given the amount of new spectrum
available as well as the fact that no legacy 802.11 device (prior available as well as the fact that no legacy 802.11 device (prior
802.11ax) will be able to operate in this new band, 802.11ax 802.11ax) will be able to operate in this new band, 802.11ax
operation in this new band can be even more efficient. operation in this new band can be even more efficient.
4.1.2.2. Applicability to deterministic flows 4.2.2. Applicability to deterministic flows
TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide
the underlying mechanism for supporting deterministic flows in a the underlying mechanism for supporting deterministic flows in a
Local Area Network (LAN). The 802.11 working group has already Local Area Network (LAN). The 802.11 working group has already
incorporated support for several TSN capabilities, so that time- incorporated support for several TSN capabilities, so that time-
sensitive flow can experience precise time synchronization and sensitive flow can experience precise time synchronization and
timeliness when operating over 802.11 links. TSN capabilities timeliness when operating over 802.11 links. TSN capabilities
supported over 802.11 (which also extends to 802.11ax), include: supported over 802.11 (which also extends to 802.11ax), include:
1. 802.1AS based Time Synchronization (other time synchronization 1. 802.1AS based Time Synchronization (other time synchronization
skipping to change at page 9, line 41 skipping to change at page 9, line 41
3. Time-sensitive Traffic Stream identification 3. Time-sensitive Traffic Stream identification
The exiting 802.11 TSN capabilities listed above, and the 802.11ax The exiting 802.11 TSN capabilities listed above, and the 802.11ax
OFDMA and scheduled access provide a new set of tools to better OFDMA and scheduled access provide a new set of tools to better
server time-sensitive flows. However, it is important to understand server time-sensitive flows. However, it is important to understand
the tradeoffs and constraints associated with such capabilities, as the tradeoffs and constraints associated with such capabilities, as
well as redundancy and diversity mechanisms that can be used to well as redundancy and diversity mechanisms that can be used to
provide more predictable and reliable performance. provide more predictable and reliable performance.
4.1.2.2.1. 802.11 Managed network operation and admission control 4.2.2.1. 802.11 Managed network operation and admission control
Time-sensitive applications and TSN standards are expected to operate Time-sensitive applications and TSN standards are expected to operate
under a managed network (e.g. industrial/enterprise network). Thus, under a managed network (e.g. industrial/enterprise network). Thus,
the Wi-Fi operation must also be carefully managed and integrated the Wi-Fi operation must also be carefully managed and integrated
with the overall TSN management framework, as defined in the IEEE with the overall TSN management framework, as defined in the IEEE
Std. 802.1Qcc specification [IEEE8021Qcc]. Std. 802.1Qcc specification [IEEE8021Qcc].
Some of the random-access latency and interference from legacy/ Some of the random-access latency and interference from legacy/
unmanaged devices can be minimized under a centralized management unmanaged devices can be minimized under a centralized management
mode as defined in IEEE Std. 802.1Qcc, in which admission control mode as defined in IEEE Std. 802.1Qcc, in which admission control
procedures are enforced. procedures are enforced.
Existing traffic stream identification, configuration and admission Existing traffic stream identification, configuration and admission
control procedures defined in IEEE Std. 802.11 QoS mechanism can be control procedures defined in IEEE Std. 802.11 QoS mechanism can be
re-used. However, given the high degree of determinism required by re-used. However, given the high degree of determinism required by
many time-sensitive applications, additional capabilities to manage many time-sensitive applications, additional capabilities to manage
interference and legacy devices within tight time-constraints need to interference and legacy devices within tight time-constraints need to
be explored. be explored.
4.1.2.2.2. Scheduling for bounded latency and diversity 4.2.2.2. Scheduling for bounded latency and diversity
As discussed earlier, the 802.11ax OFDMA mode introduces the As discussed earlier, the 802.11ax OFDMA mode introduces the
possibility of assigning different RUs (frequency resources) to users possibility of assigning different RUs (frequency resources) to users
within a PPDU. Several RU sizes are defined in the specification within a PPDU. Several RU sizes are defined in the specification
(26, 52, 106, 242, 484, 996 subcarriers). In addition, the AP can (26, 52, 106, 242, 484, 996 subcarriers). In addition, the AP can
also decide on MCS and grouping of users within a given OFMDA PPDU. also decide on MCS and grouping of users within a given OFMDA PPDU.
Such flexibility can be leveraged to support time-sensitive Such flexibility can be leveraged to support time-sensitive
applications with bounded latency, especially in a managed network applications with bounded latency, especially in a managed network
where stations can be configured to operate under the control of the where stations can be configured to operate under the control of the
AP. AP.
skipping to change at page 10, line 37 skipping to change at page 10, line 37
tradeoffs to be considered. For instance, smaller Resource Units tradeoffs to be considered. For instance, smaller Resource Units
(RU)s result in longer transmission durations, which may impact the (RU)s result in longer transmission durations, which may impact the
minimal latency that can be achieved, but the contention latency and minimal latency that can be achieved, but the contention latency and
randomness elimination due to multi-user transmission is a major randomness elimination due to multi-user transmission is a major
benefit of the OFDMA mode. benefit of the OFDMA mode.
The flexibility to dynamically assign RUs to each transmission also The flexibility to dynamically assign RUs to each transmission also
enables the AP to provide frequency diversity, which can help enables the AP to provide frequency diversity, which can help
increase reliability. increase reliability.
4.1.3. 802.11be Extreme High Throughput (EHT) 4.3. 802.11be Extreme High Throughput (EHT)
4.1.3.1. General Characteristics 4.3.1. General Characteristics
The 802.11be is the next major 802.11 amendment (after 802.11ax) for The 802.11be is the next major 802.11 amendment (after 802.11ax) for
operation in the 2.4, 5 and 6 GHz bands. 802.11be is expected to operation in the 2.4, 5 and 6 GHz bands. 802.11be is expected to
include new PHY and MAC features and it is targeting extremely high include new PHY and MAC features and it is targeting extremely high
throughput (at least 30 Gbps), as well as enhancements to worst case throughput (at least 30 Gbps), as well as enhancements to worst case
latency and jitter. It is also expected to improve the integration latency and jitter. It is also expected to improve the integration
with 802.1 TSN to support time-sensitive applications over Ethernet with 802.1 TSN to support time-sensitive applications over Ethernet
and Wireless LANs. and Wireless LANs.
The 802.11be Task Group started its operation in May 2019, therefore, The 802.11be Task Group started its operation in May 2019, therefore,
skipping to change at page 11, line 20 skipping to change at page 11, line 20
3. 16 spatial streams and related MIMO enhancements. 3. 16 spatial streams and related MIMO enhancements.
4. Multi-Access Point (AP) Coordination. 4. Multi-Access Point (AP) Coordination.
5. Enhanced link adaptation and retransmission protocol, e.g. 5. Enhanced link adaptation and retransmission protocol, e.g.
Hybrid Automatic Repeat Request (HARQ). Hybrid Automatic Repeat Request (HARQ).
6. Any required adaptations to regulatory rules for the 6 GHz 6. Any required adaptations to regulatory rules for the 6 GHz
spectrum. spectrum.
4.1.3.2. Applicability to deterministic flows 4.3.2. Applicability to deterministic flows
The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG)
provided detailed information on use cases, issues and potential provided detailed information on use cases, issues and potential
solution directions to improve support for time-sensitive solution directions to improve support for time-sensitive
applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06]
was used as input to the 802.11be project scope. was used as input to the 802.11be project scope.
Improvements for worst-case latency, jitter and reliability were the Improvements for worst-case latency, jitter and reliability were the
main topics identified in the RTA report, which were motivated by main topics identified in the RTA report, which were motivated by
applications in gaming, industrial automation, robotics, etc. The applications in gaming, industrial automation, robotics, etc. The
RTA report also highlighted the need to support additional TSN RTA report also highlighted the need to support additional TSN
capabilities, such as time-aware (802.1Qbv) shaping and packet capabilities, such as time-aware (802.1Qbv) shaping and packet
replication and elimination as defined in 802.1CB. replication and elimination as defined in 802.1CB.
802.11be is expected to build on and enhance 802.11ax capabilities to 802.11be is expected to build on and enhance 802.11ax capabilities to
improve worst case latency and jitter. Some of the enhancement areas improve worst case latency and jitter. Some of the enhancement areas
are discussed next. are discussed next.
4.1.3.2.1. Enhanced scheduled operation for bounded latency 4.3.2.1. Enhanced scheduled operation for bounded latency
In addition to the throughput enhancements, 802.11be will leverage In addition to the throughput enhancements, 802.11be will leverage
the trigger-based scheduled operation enabled by 802.11ax to provide the trigger-based scheduled operation enabled by 802.11ax to provide
efficient and more predictable medium access. 802.11be is expected to efficient and more predictable medium access. 802.11be is expected to
include enhancements to reduce overhead and enable more efficient include enhancements to reduce overhead and enable more efficient
operation in managed network deployments [IEEE_doc_11-19-0373-00]. operation in managed network deployments [IEEE_doc_11-19-0373-00].
4.1.3.2.2. Multi-AP coordination 4.3.2.2. Multi-AP coordination
Multi-AP coordination is one of the main new candidate features in Multi-AP coordination is one of the main new candidate features in
802.11be. It can provide benefits in throughput and capacity and has 802.11be. It can provide benefits in throughput and capacity and has
the potential to address some of the issues that impact worst case the potential to address some of the issues that impact worst case
latency and reliability. Multi-AP coordination is expected to latency and reliability. Multi-AP coordination is expected to
address the contention due to overlapping Basic Service Sets (OBSS), address the contention due to overlapping Basic Service Sets (OBSS),
which is one of the main sources of random latency variations. which is one of the main sources of random latency variations.
802.11be can define methods to enable better coordination between 802.11be can define methods to enable better coordination between
APs, for instance, in a managed network scenario, in order to reduce APs, for instance, in a managed network scenario, in order to reduce
latency due to unmanaged contention. latency due to unmanaged contention.
Several multi-AP coordination approaches have been discussed with Several multi-AP coordination approaches have been discussed with
different levels of complexities and benefits, but specific different levels of complexities and benefits, but specific
coordination methods have not yet been defined. coordination methods have not yet been defined.
4.1.3.2.3. Multi-band operation 4.3.2.3. Multi-band operation
802.11be will introduce new features to improve operation over 802.11be will introduce new features to improve operation over
multiple bands and channels. By leveraging multiple bands/channels, multiple bands and channels. By leveraging multiple bands/channels,
802.11be can isolate time-sensitive traffic from network congestion, 802.11be can isolate time-sensitive traffic from network congestion,
one of the main causes of large latency variations. In a managed one of the main causes of large latency variations. In a managed
802.11be network, it should be possible to steer traffic to certain 802.11be network, it should be possible to steer traffic to certain
bands/channels to isolate time-sensitive traffic from other traffic bands/channels to isolate time-sensitive traffic from other traffic
and help achieve bounded latency. and help achieve bounded latency.
4.1.4. 802.11ad and 802.11ay (mmWave operation) 4.4. 802.11ad and 802.11ay (mmWave operation)
4.1.4.1. General Characteristics 4.4.1. General Characteristics
The IEEE 802.11ad amendment defines PHY and MAC capabilities to The IEEE 802.11ad amendment defines PHY and MAC capabilities to
enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave) enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave)
band. The standard addresses the adverse mmWave signal propagation band. The standard addresses the adverse mmWave signal propagation
characteristics and provides directional communication capabilities characteristics and provides directional communication capabilities
that take advantage of beamforming to cope with increased that take advantage of beamforming to cope with increased
attenuation. An overview of the 802.11ad standard can be found in attenuation. An overview of the 802.11ad standard can be found in
[Nitsche_2015] . [Nitsche_2015] .
The IEEE 802.11ay is currently developing enhancements to the The IEEE 802.11ay is currently developing enhancements to the
802.11ad standard to enable the next generation mmWave operation 802.11ad standard to enable the next generation mmWave operation
targeting 100 Gbps throughput. Some of the main enhancements in targeting 100 Gbps throughput. Some of the main enhancements in
802.11ay include MIMO, channel bonding, improved channel access and 802.11ay include MIMO, channel bonding, improved channel access and
beamforming training. An overview of the 802.11ay capabilities can beamforming training. An overview of the 802.11ay capabilities can
be found in [Ghasempour_2017] be found in [Ghasempour_2017]
4.1.4.2. Applicability to deterministic flows 4.4.2. Applicability to deterministic flows
The high data rates achievable with 802.11ad and 802.11ay can The high data rates achievable with 802.11ad and 802.11ay can
significantly reduce latency down to microsecond levels. Limited significantly reduce latency down to microsecond levels. Limited
interference from legacy and other unlicensed devices in 60 GHz is interference from legacy and other unlicensed devices in 60 GHz is
also a benefit. However, directionality and short range typical in also a benefit. However, directionality and short range typical in
mmWave operation impose new challenges such as the overhead required mmWave operation impose new challenges such as the overhead required
for beam training and blockage issues, which impact both latency and for beam training and blockage issues, which impact both latency and
reliability. Therefore, it is important to understand the use case reliability. Therefore, it is important to understand the use case
and deployment conditions in order to properly apply and configure and deployment conditions in order to properly apply and configure
802.11ad/ay networks for time sensitive applications. 802.11ad/ay networks for time sensitive applications.
The 802.11ad standard include a scheduled access mode in which The 802.11ad standard include a scheduled access mode in which
stations can be allocated contention-free service periods by a stations can be allocated contention-free service periods by a
central controller. This scheduling capability is also available in central controller. This scheduling capability is also available in
802.11ay, and it is one of the mechanisms that can be used to provide 802.11ay, and it is one of the mechanisms that can be used to provide
bounded latency to time-sensitive data flows. An analysis of the bounded latency to time-sensitive data flows. An analysis of the
theoretical latency bounds that can be achieved with 802.11ad service theoretical latency bounds that can be achieved with 802.11ad service
periods is provided in [Cavalcanti_2019]. periods is provided in [Cavalcanti_2019].
4.2. IEEE 802.15.4 5. IEEE 802.15.4
4.2.1. Provenance and Documents 5.1. Provenance and Documents
The IEEE802.15.4 Task Group has been driving the development of low- The IEEE802.15.4 Task Group has been driving the development of low-
power low-cost radio technology. The IEEE802.15.4 physical layer has power low-cost radio technology. The IEEE802.15.4 physical layer has
been designed to support demanding low-power scenarios targeting the been designed to support demanding low-power scenarios targeting the
use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial, use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial,
Scientific and Medical (ISM) bands. This has imposed requirements in Scientific and Medical (ISM) bands. This has imposed requirements in
terms of frame size, data rate and bandwidth to achieve reduced terms of frame size, data rate and bandwidth to achieve reduced
collision probability, reduced packet error rate, and acceptable collision probability, reduced packet error rate, and acceptable
range with limited transmission power. The PHY layer supports frames range with limited transmission power. The PHY layer supports frames
of up to 127 bytes. The Medium Access Control (MAC) sublayer of up to 127 bytes. The Medium Access Control (MAC) sublayer
skipping to change at page 14, line 22 skipping to change at page 14, line 22
IPv6 capabilities with a Link-Local Address for the join process and IPv6 capabilities with a Link-Local Address for the join process and
a global unicast addres for later exchanges, but the IPv6 traffic a global unicast addres for later exchanges, but the IPv6 traffic
typically ends at a local application gateway and the full power of typically ends at a local application gateway and the full power of
IPv6 for end-to-end communication is not enabled. Compared to that IPv6 for end-to-end communication is not enabled. Compared to that
state of the art, work at the IETF and in particular at RAW could state of the art, work at the IETF and in particular at RAW could
provide additional techniques such as optimized P2P routing, PAREO provide additional techniques such as optimized P2P routing, PAREO
functions, and end-to-end secured IPv6/CoAP connectivity. functions, and end-to-end secured IPv6/CoAP connectivity.
The 6TiSCH architecture [I-D.ietf-6tisch-architecture] identifies The 6TiSCH architecture [I-D.ietf-6tisch-architecture] identifies
different models to schedule resources along so-called Tracks (see different models to schedule resources along so-called Tracks (see
Section 4.2.2.2.2) exploiting the TSCH schedule structure however the Section 5.2.2.2) exploiting the TSCH schedule structure however the
focus at 6TiSCH is on best effort traffic and the group was never focus at 6TiSCH is on best effort traffic and the group was never
chartered to produce standard work related to Tracks. chartered to produce standard work related to Tracks.
Useful References include: Useful References include:
1. IEEE Std 802.15.4: "IEEE Std. 802.15.4, Part. 15.4: Wireless 1. IEEE Std 802.15.4: "IEEE Std. 802.15.4, Part. 15.4: Wireless
Medium Access Control (MAC) and Physical Layer (PHY) Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless Personal Area Networks" Specifications for Low-Rate Wireless Personal Area Networks"
[IEEE802154]. The latest version at the time of this writing is [IEEE802154]. The latest version at the time of this writing is
dated year 2015. dated year 2015.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
T., Vilajosana, X. (2016, September). Determinism through path T., Vilajosana, X. (2016, September). Determinism through path
diversity: Why packet replication makes sense. In 2016 diversity: Why packet replication makes sense. In 2016
International Conference on Intelligent Networking and International Conference on Intelligent Networking and
Collaborative Systems (INCoS) (pp. 150-154). IEEE. [dearmas16]. Collaborative Systems (INCoS) (pp. 150-154). IEEE. [dearmas16].
4. X. Vilajosana, T. Watteyne, M. Vucinic, T. Chang and K. S. 4. X. Vilajosana, T. Watteyne, M. Vucinic, T. Chang and K. S.
J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet- J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet-
of-Things Networks," in Proceedings of the IEEE, vol. 107, no. of-Things Networks," in Proceedings of the IEEE, vol. 107, no.
6, pp. 1153-1165, June 2019. [vilajosana19]. 6, pp. 1153-1165, June 2019. [vilajosana19].
4.2.2. TimeSlotted Channel Hopping 5.2. TimeSlotted Channel Hopping
4.2.2.1. General Characteristics 5.2.1. General Characteristics
As a core technique in IEEE802.15.4, TSCH splits time in multiple As a core technique in IEEE802.15.4, TSCH splits time in multiple
time slots that repeat over time. The structure is referred as a time slots that repeat over time. A set of timeslots constructs a
Slotframe (see Section 4.2.2.2.1.4). For each timeslot, a set of Slotframe (see Section 5.2.2.1.4). For each timeslot, a set of
available frequencies can be used, resulting in a matrix-like available frequencies can be used, resulting in a matrix-like
schedule (see Fig. Figure 1). schedule (see Figure 1).
timeslot offset timeslot offset
| 0 1 2 3 4 | 0 1 2 3 4 | Nodes | 0 1 2 3 4 | 0 1 2 3 4 | Nodes
+------------------------+------------------------+ +-----+ +------------------------+------------------------+ +-----+
| | | | | | | | | | | | C | | | | | | | | | | | | | C |
CH-1 | EB | | |C->B| | EB | | |C->B| | | | CH-1 | EB | | |C->B| | EB | | |C->B| | | |
| | | | | | | | | | | +-----+ | | | | | | | | | | | +-----+
+-------------------------------------------------+ | +-------------------------------------------------+ |
| | | | | | | | | | | | | | | | | | | | | | | |
CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+ CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+
skipping to change at page 15, line 40 skipping to change at page 15, line 40
CH-15| |A->B| | | | |A->B| | | | | A | CH-15| |A->B| | | | |A->B| | | | | A |
| | | | | | | | | | | | | | | | | | | | | | | | | |
+-------------------------------------------------+ +-----+ +-------------------------------------------------+ +-----+
ch. ch.
offset offset
Figure 1: Slotframe example with scheduled cells between nodes A, B Figure 1: Slotframe example with scheduled cells between nodes A, B
and C and C
This schedule represents the possible communications of a node with This schedule represents the possible communications of a node with
its neighbors, and is managed by a Scheduling Function such as The its neighbors, and is managed by a Scheduling Function such as the
Minimal Scheduling Function (MSF) [I-D.ietf-6tisch-msf]. Each cell Minimal Scheduling Function (MSF) [I-D.ietf-6tisch-msf]. Each cell
in the schedule is identified by its slotoffset and channeloffset in the schedule is identified by its slotoffset and channeloffset
coordinates. A cell's timeslot offset indicates its position in coordinates. A cell's timeslot offset indicates its position in
time, relative to the beginning of the slotframe. A cell's channel time, relative to the beginning of the slotframe. A cell's channel
offset is an index which maps to a frequency at each iteration of the offset is an index which maps to a frequency at each iteration of the
slotframe. Each packet exchanged between neighbors happens within slotframe. Each packet exchanged between neighbors happens within
one cell. An Absolute Slot Number (ASN) indicates the number of one cell. The size of a cell is a timeslot duration, between 10 to
slots elapsed since the network started. It increments at every 15 milliseconds. An Absolute Slot Number (ASN) indicates the number
of slots elapsed since the network started. It increments at every
slot. This is a 5 byte counter that can support networks running for slot. This is a 5 byte counter that can support networks running for
more than 300 years without wrapping (assuming a 10 ms timeslot). more than 300 years without wrapping (assuming a 10 ms timeslot).
Channel hopping provides increased reliability to multi-path fading Channel hopping provides increased reliability to multi-path fading
and external interference. It is handled by TSCH through a channel and external interference. It is handled by TSCH through a channel
hopping sequence referred as macHopSeq in the IEEE802.15.4 hopping sequence referred as macHopSeq in the IEEE802.15.4
specification. specification.
The Time-Frequency Division Multiple Access provided by TSCH enables The Time-Frequency Division Multiple Access provided by TSCH enables
the orchestration of traffic flows, spreading them in time and the orchestration of traffic flows, spreading them in time and
frequency, and hence enabling an efficient management of the frequency, and hence enabling an efficient management of the
skipping to change at page 16, line 26 skipping to change at page 16, line 27
such as Class 4 defined by the RFC5673 [RFC5673]. As a low power such as Class 4 defined by the RFC5673 [RFC5673]. As a low power
technology targeting industrial scenarios radio transducers provide technology targeting industrial scenarios radio transducers provide
low data rates (typically between 50kbps to 250kbps) and robust low data rates (typically between 50kbps to 250kbps) and robust
modulations to trade-off performance to reliability. TSCH networks modulations to trade-off performance to reliability. TSCH networks
are organized in mesh topologies and connected to a backbone. are organized in mesh topologies and connected to a backbone.
Latency in the mesh network is mainly influenced by propagation Latency in the mesh network is mainly influenced by propagation
aspects such as interference. ARQ methods and redundancy techniques aspects such as interference. ARQ methods and redundancy techniques
such as replication and elimination should be studied to provide the such as replication and elimination should be studied to provide the
needed performance to address deterministic scenarios. needed performance to address deterministic scenarios.
4.2.2.2. Applicability to Deterministic Flows 5.2.2. Applicability to Deterministic Flows
Nodes in a TSCH network are tightly synchronized. This enables to Nodes in a TSCH network are tightly synchronized. This enables to
build the slotted structure and ensure efficient utilization of build the slotted structure and ensure efficient utilization of
resources thanks to proper scheduling policies. Scheduling is a key resources thanks to proper scheduling policies. Scheduling is a key
to orchestrate the resources that different nodes in a Track or a to orchestrate the resources that different nodes in a Track or a
path are using. Slotframes can be split in resource blocks reserving path are using. Slotframes can be split in resource blocks reserving
the needed capacity to certain flows. Periodic and bursty traffic the needed capacity to certain flows. Periodic and bursty traffic
can be handled independently in the schedule, using active and can be handled independently in the schedule, using active and
reactive policies and taking advantage of overprovisionned cells to reactive policies and taking advantage of overprovisionned cells to
measu reth excursion. Along a Track, resource blocks can be chained measu reth excursion. Along a Track, resource blocks can be chained
so nodes in previous hops transmit their data before the next packet so nodes in previous hops transmit their data before the next packet
comes. This provides a tight control to latency along a Track. comes. This provides a tight control to latency along a Track.
Collision loss is avoided for best effort traffic by Collision loss is avoided for best effort traffic by
overprovisionning resources, giving time to the management plane of overprovisionning resources, giving time to the management plane of
the network to dedicate more resources if needed. the network to dedicate more resources if needed.
4.2.2.2.1. Centralized Path Computation 5.2.2.1. Centralized Path Computation
In a controlled environment, a 6TiSCH device usually does not place a In a controlled environment, a 6TiSCH device usually does not place a
request for bandwidth between itself and another device in the request for bandwidth between itself and another device in the
network. Rather, an Operation Control System (OCS) invoked through network. Rather, an Operation Control System (OCS) invoked through
an Human/Machine Interface (HMI) iprovides the Traffic Specification, an Human/Machine Interface (HMI) iprovides the Traffic Specification,
in particular in terms of latency and reliability, and the end nodes, in particular in terms of latency and reliability, and the end nodes,
to a PCE. With this, the PCE computes a Track between the end nodes to a Path Computation element (PCE). With this, the PCE computes a
and provisions every hop in the Track with per-flow state that Track between the end nodes and provisions every hop in the Track
describes the per-hop operation for a given packet, the corresponding with per-flow state that describes the per-hop operation for a given
timeSlots, and the flow identification to recognize which packet is packet, the corresponding timeSlots, and the flow identification to
placed in which Track, sort out duplicates, etc... recognize which packet is placed in which Track, sort out duplicates,
etc. In Figure 2, an example of Operational Control System and HMI
is depicted.
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 Tracks. The 6TiSCH Architecture expects that behavior for multiple Tracks. The 6TiSCH Architecture expects that
the programing of the schedule is done over COAP as discussed in the programing of the schedule is done over CoAP as discussed in
"6TiSCH Resource Management and Interaction using CoAP" "6TiSCH Resource Management and Interaction using CoAP"
[I-D.ietf-6tisch-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, Packet Delivery Ratio (PDR).
expectation is that a protocol that flows along a Track (to be), in a For that case, the expectation is that a protocol that flows along a
fashion similar to classical Traffic Engineering (TE) [CCAMP], may be Track (to be), in a fashion similar to classical Traffic Engineering
used to update the state in the devices. 6TiSCH provides means for a (TE) [CCAMP], may be used to update the state in the devices. 6TiSCH
device to negotiate a timeSlot with a neighbor, but in general that provides means for a device to negotiate a timeSlot with a neighbor,
flow was not designed and no protocol was selected and it is expected but in general that flow was not designed and no protocol was
that DetNet will determine the appropriate end-to-end protocols to be selected and it is expected that DetNet will determine the
used in that case. appropriate end-to-end protocols to be used in that case.
Stream Management Entity Stream Management Entity
Operational System and HMI Operational Control 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 2 Figure 2
4.2.2.2.1.1. Packet Marking and Handling 5.2.2.1.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.
4.2.2.2.1.1.1. Tagging Packets for Flow Identification 5.2.2.1.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
by the IPv6 source address and a local RPLInstanceID is tagged in the by the IPv6 source address and a local RPLInstanceID is tagged in the
packets to identify uniquely the Track and associated transmit bundle packets to identify uniquely the Track and associated transmit bundle
of timeSlots. of timeSlots.
It results that the tagging that is used for a DetNet flow outside It results that the tagging that is used for a DetNet flow outside
the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the
packet enters and then leaves the 6TiSCH network. packet enters and then leaves the 6TiSCH network.
Note: The method and format used for encoding the RPLInstanceID at Note: The method and format used for encoding the RPLInstanceID at
6lo is generalized to all 6TiSCH topological Instances, which 6lo is generalized to all 6TiSCH topological Instances, which
includes Tracks. includes Tracks.
4.2.2.2.1.1.2. Replication, Retries and Elimination 5.2.2.1.1.2. Replication, Retries and Elimination
PRE establishes several paths in a network to provide redundancy and
parallel transmissions to bound the end-to-end delay. Considering
the scenario shown in Figure 3, many different paths are possible for
S to reach R. A simple way to benefit from this topology could be to
use the two independent paths via nodes A, C, E and via B, D, F. But
more complex paths are possible as well.
(A) (C) (E)
source (S) (R) (destination)
(B) (D) (F)
Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward the
Destination
By employing a Packet Replication function, each node forwards a copy
of each data packet over two different branches. For instance, in
Figure 4, the source node S transmits the data packet to nodes A and
B, in two different timeslots within the same TSCH slotframe.
===> (A) => (C) => (E) ===
// \\// \\// \\
source (S) //\\ //\\ (R) (destination)
\\ // \\ // \\ //
===> (B) => (D) => (F) ===
Figure 4: Packet Replication: S transmits twice the same data packet,
to its DP (A) and to its AP (B).
By employing Packet Elimination function once a node receives the
first copy of a data packet, it discards the subsequent copies.
Because the first copy that reaches a node is the one that matters,
it is the only copy that will be forwarded upward.
Considering that the wireless medium is broadcast by nature, any
neighbor of a transmitter may overhear a transmission. By employing
the Promiscuous Overhearing function, nodes will have multiple
opportunities to receive a given data packet. For instance, in
Figure 4, when the source node S transmits the data packet to node A,
node B may overhear this transmission.
6TiSCH expects elimination and replication of packets along a complex 6TiSCH expects elimination and replication of packets along a complex
Track, but has no position about how the sequence numbers would be Track, but has no position about how the sequence numbers would be
tagged in the packet. tagged in the packet.
As it goes, 6TiSCH expects that timeSlots corresponding to copies of As it goes, 6TiSCH expects that timeSlots corresponding to copies of
a same packet along a Track are correlated by configuration, and does a same packet along a Track are correlated by configuration, and does
not need to process the sequence numbers. not need to process the sequence numbers.
The semantics of the configuration MUST enable correlated timeSlots The semantics of the configuration MUST enable correlated timeSlots
skipping to change at page 19, line 10 skipping to change at page 20, line 14
whether a transmission succeeded in another branch. It is also whether a transmission succeeded in another branch. It is also
possible to place cells to different next-hop routers in a same 'OR' possible to place cells to different next-hop routers in a same 'OR'
group. This allows to route along multi-path Tracks, trying one group. This allows to route along multi-path Tracks, trying one
next-hop and then another only if sending to the first fails. next-hop and then another only if sending to the first fails.
On the receive side, all timeSlots are programmed in a same 'OR' On the receive side, all timeSlots are programmed in a same 'OR'
group. Retries of a same copy as well as converging branches for group. Retries of a same copy as well as converging branches for
elimination are converged, meaning that the first successful elimination are converged, meaning that the first successful
reception is enough and that all the other timeSlots can be ignored. reception is enough and that all the other timeSlots can be ignored.
4.2.2.2.1.1.3. Differentiated Services Per-Hop-Behavior 5.2.2.1.1.3. Differentiated Services Per-Hop-Behavior
Additionally, an IP packet that is sent along a Track uses the Additionally, an IP packet that is sent along a Track uses the
Differentiated Services Per-Hop-Behavior Group called Deterministic Differentiated Services Per-Hop-Behavior Group called Deterministic
Forwarding, as described in Forwarding, as described in
[I-D.svshah-tsvwg-deterministic-forwarding]. [I-D.svshah-tsvwg-deterministic-forwarding].
4.2.2.2.1.2. Topology and capabilities 5.2.2.1.2. Topology and capabilities
6TiSCH nodes are usually IoT devices, characterized by very limited 6TiSCH nodes are usually IoT devices, characterized by very limited
amount of memory, just enough buffers to store one or a few IPv6 amount of memory, just enough buffers to store one or a few IPv6
packets, and limited bandwidth between peers. It results that a node packets, and limited bandwidth between peers. It results that a node
will maintain only a small number of peering information, and will will maintain only a small number of peering information, and will
not be able to store many packets waiting to be forwarded. Peers can not be able to store many packets waiting to be forwarded. Peers can
be identified through MAC or IPv6 addresses. be identified through MAC or IPv6 addresses.
Neighbors can be discovered over the radio using mechanism such as Neighbors can be discovered over the radio using mechanism such as
beacons, but, though the neighbor information is available in the Enhanced Beacons, but, though the neighbor information is available
6TiSCH interface data model, 6TiSCH does not describe a protocol to in the 6TiSCH interface data model, 6TiSCH does not describe a
pro-actively push the neighborhood information to a PCE. This protocol to pro-actively push the neighborhood information to a PCE.
protocol should be described and should operate over CoAP. The This protocol should be described and should operate over CoAP. The
protocol should be able to carry multiple metrics, in particular the protocol should be able to carry multiple metrics, in particular the
same metrics as used for RPL operations [RFC6551] same metrics as used for RPL operations [RFC6551].
The energy that the device consumes in sleep, transmit and receive The energy that the device consumes in sleep, transmit and receive
modes can be evaluated and reported. So can the amount of energy modes can be evaluated and reported. So can the amount of energy
that is stored in the device and the power that it can be scavenged that is stored in the device and the power that it can be scavenged
from the environment. The PCE SHOULD be able to compute Tracks that from the environment. The PCE SHOULD be able to compute Tracks that
will implement policies on how the energy is consumed, for instance will implement policies on how the energy is consumed, for instance
balance between nodes, ensure that the spent energy does not exceeded balance between nodes, ensure that the spent energy does not exceeded
the scavenged energy over a period of time, etc... the scavenged energy over a period of time, etc...
4.2.2.2.1.3. Schedule Management by a PCE 5.2.2.1.3. Schedule Management by a PCE
6TiSCH supports a mixed model of centralized routes and distributed 6TiSCH supports a mixed model of centralized routes and distributed
routes. Centralized routes can for example be computed by a entity routes. Centralized routes can for example be computed by a entity
such as a Path Computation element (PCE) [PCE]. Distributed routes such as a PCE [PCE]. Distributed routes are computed by RPL
are computed by RPL [RFC6550]. [RFC6550].
Both methods may inject routes in the Routing Tables of the 6TiSCH Both methods may inject routes in the Routing Tables of the 6TiSCH
routers. In either case, each route is associated with a 6TiSCH routers. In either case, each route is associated with a 6TiSCH
topology that can be a RPL Instance topology or a Track. The 6TiSCH topology that can be a RPL Instance topology or a Track. The 6TiSCH
topology is indexed by a Instance ID, in a format that reuses the topology is indexed by a Instance ID, in a format that reuses the
RPLInstanceID as defined in RPL. RPLInstanceID as defined in RPL.
Both RPL and PCE rely on shared sources such as policies to define Both RPL and PCE rely on shared sources such as policies to define
Global and Local RPLInstanceIDs that can be used by either method. Global and Local RPLInstanceIDs that can be used by either method.
It is possible for centralized and distributed routing to share a It is possible for centralized and distributed routing to share a
same topology. Generally they will operate in different slotFrames, same topology. Generally they will operate in different slotFrames,
and centralized routes will be used for scheduled traffic and will and centralized routes will be used for scheduled traffic and will
have precedence over distributed routes in case of conflict between have precedence over distributed routes in case of conflict between
the slotFrames. the slotFrames.
4.2.2.2.1.4. SlotFrames and Priorities 5.2.2.1.4. SlotFrames and Priorities
A slotFrame is the base object that a PCE needs to manipulate to A slotFrame is the base object that a PCE needs to manipulate to
program a schedule into an LLN node. Elaboration on that concept can program a schedule into an LLN node. Elaboration on that concept can
be fond in section "SlotFrames and Priorities" of be fond in section "SlotFrames and Priorities" of
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
IEEE802.15.4 TSCH avoids contention on the medium by formatting time IEEE802.15.4 TSCH avoids contention on the medium by formatting time
and frequencies in cells of transmission of equal duration. In order and frequencies in cells of transmission of equal duration. In order
to describe that formatting of time and frequencies, the 6TiSCH to describe that formatting of time and frequencies, the 6TiSCH
architecture defines a global concept that is called a Channel architecture defines a global concept that is called a Channel
Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
cells with an height equal to the number of available channels cells with an height equal to the number of available channels
(indexed by ChannelOffsets) and a width (in timeSlots) that is the (indexed by ChannelOffsets) and a width (in timeSlots) that is the
period of the network scheduling operation (indexed by slotOffsets) period of the network scheduling operation (indexed by slotOffsets)
for that CDU matrix. The size of a cell is a timeSlot duration, and for that CDU matrix. The size of a cell is a timeSlot duration, and
values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to
accommodate for the transmission of a frame and an ack, including the accommodate for the transmission of a frame and an acknowledgement,
security validation on the receive side which may take up to a few including the security validation on the receive side which may take
milliseconds on some device architecture. up to a few milliseconds on some device architecture.
The frequency used by a cell in the matrix rotates in a pseudo-random The frequency used by a cell in the matrix rotates in a pseudo-random
fashion, from an initial position at an epoch time, as the matrix fashion, from an initial position at an epoch time, as the matrix
iterates over and over. iterates over and over.
A CDU matrix is computed by the PCE, but unallocated timeSlots may be A CDU matrix is computed by the PCE, but unallocated timeSlots may be
used opportunistically by the nodes for classical best effort IP used opportunistically by the nodes for classical best effort IP
traffic. The PCE has precedence in the allocation in case of a traffic. The PCE has precedence in the allocation in case of a
conflict. conflict.
skipping to change at page 21, line 26 skipping to change at page 22, line 28
aligned to different CDU matrices and thus have different width. aligned to different CDU matrices and thus have different width.
There is typically one slotFrame for scheduled traffic that has the There is typically one slotFrame for scheduled traffic that has the
highest precedence and one or more slotFrame(s) for RPL traffic. The highest precedence and one or more slotFrame(s) for RPL traffic. The
timeSlots in the slotFrame are indexed by the SlotOffset; the first timeSlots in the slotFrame are indexed by the SlotOffset; the first
cell is at SlotOffset 0. cell is at SlotOffset 0.
The 6TiSCH architecture introduces the concept of chunks The 6TiSCH architecture introduces the concept of chunks
([I-D.ietf-6tisch-architecture]) to operate such spectrum ([I-D.ietf-6tisch-architecture]) to operate such spectrum
distribution for a whole group of cells at a time. The CDU matrix is distribution for a whole group of cells at a time. The CDU matrix is
formatted into a set of chunks, each of them identified uniquely by a formatted into a set of chunks, each of them identified uniquely by a
chunk-ID. The PCE MUST compute the partitioning of CDU matrices into chunk-ID, see Figure 5. The PCE MUST compute the partitioning of CDU
chunks and shared that knowledge with all the nodes in a 6TiSCH matrices into chunks and shared that knowledge with all the nodes in
network. a 6TiSCH network.
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
... ...
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
0 1 2 3 4 5 6 M 0 1 2 3 4 5 6 M
Figure 3: CDU matrix Partitioning in Chunks Figure 5: CDU matrix Partitioning in Chunks
The appropriation of a chunk can be requested explicitly by the PCE The appropriation of a chunk can be requested explicitly by the PCE
to any node. After a successful appropriation, the PCE owns the to any node. After a successful appropriation, the PCE owns the
cells in that chunk, and may use them as hard cells to set up Tracks. cells in that chunk, and may use them as hard cells to set up Tracks.
Then again, 6TiSCH did not propose a method for chunk definition and Then again, 6TiSCH did not propose a method for chunk definition and
a protocol for appropriation. This is to be done at PAW. a protocol for appropriation. This is to be done at RAW.
4.2.2.2.2. 6TiSCH Tracks 5.2.2.2. 6TiSCH Tracks
A Track at 6TiSCH is the application to wireless of the concept of a A Track at 6TiSCH is the application to wireless of the concept of a
path in the Detnet architecture [I-D.ietf-detnet-architecture]. A path in the Detnet architecture [I-D.ietf-detnet-architecture]. A
Track can follow a simple sequence of relay nodes or can be Track can follow a simple sequence of relay nodes or can be
structured as a more complex destination oriented directed acyclic structured as a more complex Destination Oriented Directed Acyclic
graph (DODAG) to a unicast destination. Along a Track, 6TiSCH nodes Graph (DODAG) to a unicast destination. Along a Track, 6TiSCH nodes
reserve the resources to enable the efficient transmission of packets reserve the resources to enable the efficient transmission of packets
while aiming to optimize certain properties such as reliability and while aiming to optimize certain properties such as reliability and
ensure small jitter or bounded latency. The Track structure enables ensure small jitter or bounded latency. The Track structure enables
Layer-2 forwarding schemes, reducing the overhead of taking routing Layer-2 forwarding schemes, reducing the overhead of taking routing
decisions at the Layer-3. decisions at the Layer-3.
Serial Tracks can be understood as the concatenation of cells or Serial Tracks can be understood as the concatenation of cells or
bundles along a routing path from a node towards a destination. The bundles along a routing path from a source towards a destination.
serial Track concept is analogous to the circuit concept where The serial Track concept is analogous to the circuit concept where
resources are chained through the multi-hop topology. For example, A resources are chained through the multi-hop topology. For example, A
bundle of Tx Cells in a particular node is paired to a bundle of Rx bundle of Tx Cells in a particular node is paired to a bundle of Rx
Cells in the next hop node following a routing path. Cells in the next hop node following a routing path.
whereas scheduling ensures reliable delivery in bounded time along Whereas scheduling ensures reliable delivery in bounded time along
any Track, high availability requires the application of PAREO any Track, high availability requires the application of PAREO
functions along a more complex DODAG Track structure. A DODAG has functions along a more complex DODAG Track structure. A DODAG has
forking and joining nodes where the concepts such as Replication and forking and joining nodes where the concepts such as Replication and
Elimination can be exploited. Spatial redundancy increases the Elimination can be exploited. Spatial redundancy increases the
oveall energy consumption in the network but improves significantly oveall energy consumption in the network but improves significantly
the availability of the network as well as the packet delivery ratio. the availability of the network as well as the packet delivery ratio.
A Track may also branch off and rejoin, for the purpose of the so- A Track may also branch off and rejoin, for the purpose of the so-
called Packet Replication and Elimination (PRE), over non congruent called Packet Replication and Elimination (PRE), over non congruent
branches. PRE may be used to complement layer-2 Automatic Repeat branches. PRE may be used to complement layer-2 Automatic Repeat
reQuest (ARQ) and and receiver-end Ordering to form the PAREO reQuest (ARQ) and receiver-end Ordering to form the PAREO functions.
functions. PAREO functions enable to meet industrial expectations in PAREO functions enable to meet industrial expectations in PDR within
Packet Delivery Ratio (PDR) within bounded delivery time over a Track bounded delivery time over a Track that includes wireless links, even
that includes wireless links, even when the Track extends beyond the when the Track extends beyond the 6TiSCH network.
6TiSCH network.
+-----+ +-----+
| IoT | | IoT |
| G/W | | G/W |
+-----+ +-----+
^ <---- Elimination ^ <---- Elimination
| | | |
Track branch | | Track branch | |
+-------+ +--------+ Subnet Backbone +-------+ +--------+ Subnet Backbone
| | | |
+--|--+ +--|--+ +--|--+ +--|--+
| | | Backbone | | | Backbone | | | Backbone | | | Backbone
o | | | router | | | router o | | | router | | | router
+--/--+ +--|--+ +--/--+ +--|--+
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 4: End-to-End deterministic Track Figure 6: End-to-End deterministic Track
In the example above, a Track is laid out from a field device in a In the example above (see Figure 6), a Track is laid out from a field
6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN device in a 6TiSCH network to an IoT gateway that is located on a
backbone. IEEE802.1 TSN backbone.
The Replication function in the field device sends a copy of each The Replication function in the field device sends a copy of each
packet over two different branches, and a PCE schedules each hop of packet over two different branches, and a PCE schedules each hop of
both branches so that the two copies arrive in due time at the 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 makes it in due time. If two copies make it to of the packet still makes it in due time. If two copies make it to
the IoT gateway, the Elimination function in the gateway ignores the the IoT gateway, the Elimination function in the gateway ignores the
extra packet and presents only one copy to upper layers. 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
skipping to change at page 24, line 11 skipping to change at page 25, line 11
solutions, and the forwarding decision is to try the preferred one solutions, and the forwarding decision is to try the preferred one
and use the other in case of Layer-2 transmission failure as detected and use the other in case of Layer-2 transmission failure as detected
by ARQ. by ARQ.
Methods to implement complex Tracks are described in Methods to implement complex Tracks are described in
[I-D.papadopoulos-paw-pre-reqs] and complemented by extensions to the [I-D.papadopoulos-paw-pre-reqs] and complemented by extensions to the
RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort
traffic, but a centralized routing technique such as promoted in traffic, but a centralized routing technique such as promoted in
DetNet is still missing. DetNet is still missing.
4.2.2.2.2.1. Track Scheduling Protocol 5.2.2.2.1. Track Scheduling Protocol
Section "Schedule Management Mechanisms" of the 6TiSCH architecture Section "Schedule Management Mechanisms" of the 6TiSCH architecture
describes 4 paradigms to manage the TSCH schedule of the LLN nodes: describes 4 paradigms to manage the TSCH schedule of the LLN nodes:
Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring
and scheduling management, and Hop-by-hop scheduling. The Track and scheduling management, and Hop-by-hop scheduling. The Track
operation for DetNet corresponds to a remote monitoring and operation for DetNet corresponds to a remote monitoring and
scheduling management by a PCE. scheduling management by a PCE.
Early work at 6TiSCH on a data model and a protocol to program the Early work at 6TiSCH on a data model and a protocol to program the
schedule in the 6TiSCH device was never concluded as the group schedule in the 6TiSCH device was never concluded as the group
focussed on best effort traffic. This work would be revived by PAW: focussed on best effort traffic. This work would be revived by RAW:
The 6top interface document [RFC8480] (to be reopened at PAW) was The 6top interface document [RFC8480] (to be reopened at RAW) was
intended to specify the generic data model that can be used to intended to specify the generic data model that can be used to
monitor and manage resources of the 6top sublayer. Abstract monitor and manage resources of the 6top sublayer. Abstract
methods were suggested for use by a management entity in the methods were suggested for use by a management entity in the
device. The data model also enables remote control operations on device. The data model also enables remote control operations on
the 6top sublayer. the 6top sublayer.
[I-D.ietf-6tisch-coap] (to be reopened at RAW) was intended to [I-D.ietf-6tisch-coap] (to be reopened at RAW) was intended to
define a mapping of the 6top set of commands, which is described define a mapping of the 6top set of commands, which is described
in RFC 8480, to CoAP resources. This allows an entity to interact in RFC 8480, to CoAP resources. This allows an entity to interact
with the 6top layer of a node that is multiple hops away in a with the 6top layer of a node that is multiple hops away in a
skipping to change at page 24, line 47 skipping to change at page 25, line 47
[I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and [I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and
associated RESTful access methods (GET/PUT/POST/DELETE). The associated RESTful access methods (GET/PUT/POST/DELETE). The
payload (body) of the CoAP messages is encoded using the CBOR payload (body) of the CoAP messages is encoded using the CBOR
format. The PCE commands are expected to be issued directly as format. The PCE commands are expected to be issued directly as
CoAP requests or to be mapped back and forth into CoAP by a CoAP requests or to be mapped back and forth into CoAP by a
gateway function at the edge of the 6TiSCH network. For instance, gateway function at the edge of the 6TiSCH network. For instance,
it is possible that a mapping entity on the backbone transforms a it is possible that a mapping entity on the backbone transforms a
non-CoAP protocol such as PCEP into the RESTful interfaces that non-CoAP protocol such as PCEP into the RESTful interfaces that
the 6TiSCH devices support. the 6TiSCH devices support.
4.2.2.2.2.2. Track Forwarding 5.2.2.2.2. Track Forwarding
By forwarding, this specification means the per-packet operation that By forwarding, this specification means the per-packet operation that
allows to deliver a packet to a next hop or an upper layer in this allows to deliver a packet to a next hop or an upper layer in this
node. Forwarding is based on pre-existing state that was installed node. Forwarding is based on pre-existing state that was installed
as a result of the routing computation of a Track by a PCE. The as a result of the routing computation of a Track by a PCE. The
6TiSCH architecture supports three different forwarding model, G-MPLS 6TiSCH architecture supports three different forwarding model, G-MPLS
Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6
Forwarding (6F) which is the classical IP operation. The DetNet case Forwarding (6F) which is the classical IP operation
relates to the Track Forwarding operation under the control of a PCE. [I-D.ietf-6tisch-architecture]. The DetNet case relates to the Track
Forwarding operation under the control of a PCE.
A Track is a unidirectional path between a source and a destination. A Track is a unidirectional path between a source and a destination.
In a Track cell, the normal operation of IEEE802.15.4 Automatic In a Track cell, the normal operation of IEEE802.15.4 Automatic
Repeat-reQuest (ARQ) usually happens, though the acknowledgment may Repeat-reQuest (ARQ) usually happens, though the acknowledgment may
be omitted in some cases, for instance if there is no scheduled cell be omitted in some cases, for instance if there is no scheduled cell
for a retry. for a retry.
Track Forwarding is the simplest and fastest. A bundle of cells set Track Forwarding is the simplest and fastest. A bundle of cells set
to receive (RX-cells) is uniquely paired to a bundle of cells that to receive (RX-cells) is uniquely paired to a bundle of cells that
are set to transmit (TX-cells), representing a layer-2 forwarding are set to transmit (TX-cells), representing a layer-2 forwarding
skipping to change at page 26, line 36 skipping to change at page 27, line 36
next-hop MAC address to avoid confusion. It results that a frame next-hop MAC address to avoid confusion. It results that a frame
that is received over a layer-3 bundle may be in fact associated to a that is received over a layer-3 bundle may be in fact associated to a
Track. In a classical IP link such as an Ethernet, off-Track traffic Track. In a classical IP link such as an Ethernet, off-Track traffic
is typically in excess over reservation to be routed along the non- is typically in excess over reservation to be routed along the non-
reserved path based on its QoS setting. But with 6TiSCH, since the reserved path based on its QoS setting. But with 6TiSCH, since the
use of the layer-3 bundle may be due to transmission failures, it use of the layer-3 bundle may be due to transmission failures, it
makes sense for the receiver to recognize a frame that should be re- makes sense for the receiver to recognize a frame that should be re-
Tracked, and to place it back on the appropriate bundle if possible. Tracked, and to place it back on the appropriate bundle if possible.
A frame should be re-Tracked if the Per-Hop-Behavior group indicated A frame should be re-Tracked if the Per-Hop-Behavior group indicated
in the Differentiated Services Field in the IPv6 header is set to in the Differentiated Services Field in the IPv6 header is set to
Deterministic Forwarding, as discussed in Section 4.2.2.2.1.1. A Deterministic Forwarding, as discussed in Section 5.2.2.1.1. A frame
frame is re-Tracked by scheduling it for transmission over the is re-Tracked by scheduling it for transmission over the transmit
transmit bundle associated to the Track, with the destination MAC bundle associated to the Track, with the destination MAC address set
address set to broadcast. to broadcast.
There are 2 modes for a Track, transport mode and tunnel mode. There are 2 modes for a Track, transport mode and tunnel mode.
4.2.2.2.2.2.1. Transport Mode 5.2.2.2.2.1. Transport Mode
In transport mode, the Protocol Data Unit (PDU) is associated with In transport mode, the Protocol Data Unit (PDU) is associated with
flow-dependant meta-data that refers uniquely to the Track, so the flow-dependant meta-data that refers uniquely to the Track, so the
6top sublayer can place the frame in the appropriate cell without 6top sublayer can place the frame in the appropriate cell without
ambiguity. In the case of IPv6 traffic, this flow identification is ambiguity. In the case of IPv6 traffic, this flow identification is
transported in the Flow Label of the IPv6 header. Associated with transported in the Flow Label of the IPv6 header. Associated with
the source IPv6 address, the Flow Label forms a globally unique the source IPv6 address, the Flow Label forms a globally unique
identifier for that particular Track that is validated at egress identifier for that particular Track that is validated at egress
before restoring the destination MAC address (DMAC) and punting to before restoring the destination MAC address (DMAC) and punting to
the upper layer. the upper layer.
skipping to change at page 27, line 20 skipping to change at page 28, line 20
+--------------+ | | +--------------+ | |
| 6LoWPAN HC | | | | 6LoWPAN HC | | |
+--------------+ ingress egress +--------------+ ingress egress
| 6top | sets +----+ +----+ restores | 6top | sets +----+ +----+ restores
+--------------+ dmac to | | | | dmac to +--------------+ dmac to | | | | dmac to
| TSCH MAC | brdcst | | | | self | TSCH MAC | brdcst | | | | self
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Track Forwarding, Transport Mode Figure 7: Track Forwarding, Transport Mode
4.2.2.2.2.2.2. Tunnel Mode 5.2.2.2.2.2. Tunnel Mode
In tunnel mode, the frames originate from an arbitrary protocol over In tunnel mode, the frames originate from an arbitrary protocol over
a compatible MAC that may or may not be synchronized with the 6TiSCH a compatible MAC that may or may not be synchronized with the 6TiSCH
network. An example of this would be a router with a dual radio that network. An example of this would be a router with a dual radio that
is capable of receiving and sending WirelessHART or ISA100.11a frames is capable of receiving and sending WirelessHART or ISA100.11a frames
with the second radio, by presenting itself as an Access Point or a with the second radio, by presenting itself as an Access Point or a
Backbone Router, respectively. Backbone Router, respectively.
In that mode, some entity (e.g. PCE) can coordinate with a In that mode, some entity (e.g. PCE) can coordinate with a
WirelessHART Network Manager or an ISA100.11a System Manager to WirelessHART Network Manager or an ISA100.11a System Manager to
skipping to change at page 28, line 25 skipping to change at page 29, line 25
+--------------+ | ingress egress | +--------------+ | ingress egress |
| | | |
+--------------+ | | +--------------+ | |
| LLN PHY | | | | LLN PHY | | |
+--------------+ | | +--------------+ | |
| TSCH MAC | | | | TSCH MAC | | |
+--------------+ | dmac = | dmac = +--------------+ | dmac = | dmac =
|ISA100/WiHART | | nexthop v nexthop |ISA100/WiHART | | nexthop v nexthop
+--------------+ +--------------+
Figure 5: Track Forwarding, Tunnel Mode Figure 8: Track Forwarding, Tunnel Mode
In that case, the flow information that identifies the Track at the In that case, the flow information that identifies the Track at the
ingress 6TiSCH router is derived from the RX-cell. The dmac is set ingress 6TiSCH router is derived from the RX-cell. The dmac is set
to this node but the flow information indicates that the frame must to this node but the flow information indicates that the frame must
be tunneled over a particular Track so the frame is not passed to the be tunneled over a particular Track so the frame is not passed to the
upper layer. Instead, the dmac is forced to broadcast and the frame upper layer. Instead, the dmac is forced to broadcast and the frame
is passed to the 6top sublayer for switching. is passed to the 6top sublayer for switching.
At the egress 6TiSCH router, the reverse operation occurs. Based on At the egress 6TiSCH router, the reverse operation occurs. Based on
metadata associated to the Track, the frame is passed to the metadata associated to the Track, the frame is passed to the
appropriate link layer with the destination MAC restored. appropriate link layer with the destination MAC restored.
4.2.2.2.2.2.3. Tunnel Metadata 5.2.2.2.2.3. Tunnel Metadata
Metadata coming with the Track configuration is expected to provide Metadata coming with the Track configuration is expected to provide
the destination MAC address of the egress endpoint as well as the the destination MAC address of the egress endpoint as well as the
tunnel mode and specific data depending on the mode, for instance a tunnel mode and specific data depending on the mode, for instance a
service access point for frame delivery at egress. If the tunnel service access point for frame delivery at egress. If the tunnel
egress point does not have a MAC address that matches the egress point does not have a MAC address that matches the
configuration, the Track installation fails. configuration, the Track installation fails.
In transport mode, if the final layer-3 destination is the tunnel In transport mode, if the final layer-3 destination is the tunnel
termination, then it is possible that the IPv6 address of the termination, then it is possible that the IPv6 address of the
destination is compressed at the 6LoWPAN sublayer based on the MAC destination is compressed at the 6LoWPAN sublayer based on the MAC
address. It is thus mandatory at the ingress point to validate that address. It is thus mandatory at the ingress point to validate that
the MAC address that was used at the 6LoWPAN sublayer for compression the MAC address that was used at the 6LoWPAN sublayer for compression
matches that of the tunnel egress point. For that reason, the node matches that of the tunnel egress point. For that reason, the node
that injects a packet on a Track checks that the destination is that injects a packet on a Track checks that the destination is
effectively that of the tunnel egress point before it overwrites it effectively that of the tunnel egress point before it overwrites it
to broadcast. The 6top sublayer at the tunnel egress point reverts to broadcast. The 6top sublayer at the tunnel egress point reverts
that operation to the MAC address obtained from the tunnel metadata. that operation to the MAC address obtained from the tunnel metadata.
4.2.2.2.2.2.4. OAM 5.2.2.2.2.4. OAM
An Overview of Operations, Administration, and Maintenance (OAM) An Overview of Operations, Administration, and Maintenance (OAM)
Tools [RFC7276] provides an overwiew of the existing tooling for OAM Tools [RFC7276] provides an overwiew of the existing tooling for OAM
[RFC6291]. Tracks are complex paths and new tooling is necessary to [RFC6291]. Tracks are complex paths and new tooling is necessary to
manage them, with respect to load control, timing, and the Packet manage them, with respect to load control, timing, and the Packet
Replication and Elimination Functions (PREF). Replication and Elimination Functions (PREF).
An example of such tooling can be found in the context of BIER An example of such tooling can be found in the context of BIER
[RFC8279] and more specifically BIER Traffic Engineering [RFC8279] and more specifically BIER Traffic Engineering
[I-D.ietf-bier-te-arch] (BIER-TE): [I-D.ietf-bier-te-arch] (BIER-TE):
[I-D.thubert-bier-replication-elimination] leverages BIER-TE to [I-D.thubert-bier-replication-elimination] leverages BIER-TE to
control the process of PREF, and to provide traceability of these control the process of PREF, and to provide traceability of these
operations, in the deterministic dataplane, along a complex Track. operations, in the deterministic dataplane, along a complex Track.
For the 6TiSCH type of constrained environment, For the 6TiSCH type of constrained environment,
[I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the [I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the
BIER bitmap within the 6LoRH framework. BIER bitmap within the 6LoRH framework.
5. 3GPP standards 6. 3GPP Ultra-Reliable Low-Latency Communication
6. IANA Considerations coming up
7. L-band Digital Aeronautical Communications System
One of the main pillars of the modern Air Traffic Management (ATM)
system is the existence of a communication infrastructure that
enables efficient aircraft guidance and safe separation in all phases
of flight. Although current systems are technically mature, they are
suffering from the VHF band's increasing saturation in high-density
areas and the limitations posed by analogue radio. Therefore,
aviation globally and the European Union (EU) in particular, strives
for a sustainable modernization of the aeronautical communication
infrastructure.
In the long-term, ATM communication shall transition from analogue
VHF voice and VDL2 communication to more spectrum efficient digital
data communication. The European ATM Master Plan foresees this
transition to be realized for terrestrial communications by the
development and implementation of the L-band Digital Aeronautical
Communications System (LDACS). LDACS shall enable IPv6 based air-
ground communication related to the safety and regularity of the
flight. The particular challenge is that no new frequencies can be
made available for terrestrial aeronautical communication. It was
thus necessary to develop procedures to enable the operation of LDACS
in parallel with other services in the same frequency band.
7.1. Provenance and Documents
The development of LDACS has already made substantial progress in the
Single European Sky ATM Research (SESAR) framework, and is currently
being continued in the follow-up program, SESAR2020 [RIH18]. A key
objective of the SESAR activities is to develop, implement and
validate a modern aeronautical data link able to evolve with aviation
needs over long-term. To this end, an LDACS specification has been
produced [GRA19] and is continuously updated; transmitter
demonstrators were developed to test the spectrum compatibility of
LDACS with legacy systems operating in the L-band [SAJ14]; and the
overall system performance was analyzed by computer simulations,
indicating that LDACS can fulfil the identified requirements [GRA11].
LDACS standardization within the framework of the International Civil
Aviation Organization (ICAO) started in December 2016. The ICAO
standardization group has produced an initial Standards and
Recommended Practices (SARPs) document [ICAO18]. The SARPs document
defines the general characteristics of LDACS. The ICAO
standardization group plans to produce an ICAO technical manual - the
ICAO equivalent to a technical standard - within the next years.
Generally, the group is open to input from all sources and develops
LDACS in the open.
Up to now the LDACS standardization has been focused on the
development of the physical layer and the data link layer, only
recently have higher layers come into the focus of the LDACS
development activities. There is currently no "IPv6 over LDACS"
specification; however, SESAR2020 has started the testing of
IPv6-based LDACS testbeds. The IPv6 architecture for the
aeronautical telecommunication network is called the Future
Communications Infrastructure (FCI). FCI shall support quality of
service, diversity, and mobility under the umbrella of the "multi-
link concept". This work is conducted by ICAO working group WG-I.
In addition to standardization activities several industrial LDACS
prototypes have been built. One set of LDACS prototypes has been
evaluated in flight trials confirming the theoretical results
predicting the system performance [GRA18][SCH19].
7.2. General Characteristics
LDACS will become one of several wireless access networks connecting
aircraft to the Aeronautical Telecommunications Network (ATN). The
LDACS access network contains several ground stations, each of them
providing one LDACS radio cell. The LDACS air interface is a
cellular data link with a star-topology connecting aircraft to
ground-stations with a full duplex radio link. Each ground-station
is the centralized instance controlling all air-ground communications
within its radio cell. A ground-station supports up to 512 aircraft.
The LDACS air interface protocol stack defines two layers, the
physical layer and the data link layer.
The physical layer provides the means to transfer data over the radio
channel. The LDACS ground-station supports bi-directional links to
multiple aircraft under its control. The forward link direction (FL;
ground-to-air) and the reverse link direction (RL; air-to-ground) are
separated by frequency division duplex. Forward link and reverse
link use a 500 kHz channel each. The ground-station transmits a
continuous stream of OFDM symbols on the forward link. In the
reverse link different aircraft are separated in time and frequency
using a combination of Orthogonal Frequency-Division Multiple-Access
(OFDMA) and Time-Division Multiple-Access (TDMA). Aircraft thus
transmit discontinuously on the reverse link with radio bursts sent
in precisely defined transmission opportunities allocated by the
ground-station. LDACS does not support beam-forming or Multiple
Input Multiple Output (MIMO).
The data-link layer provides the necessary protocols to facilitate
concurrent and reliable data transfer for multiple users. The LDACS
data link layer is organized in two sub-layers: The medium access
sub-layer and the logical link control sub-layer. The medium access
sub-layer manages the organization of transmission opportunities in
slots of time and frequency. The logical link control sub-layer
provides acknowledged point-to-point logical channels between the
aircraft and the ground-station using an automatic repeat request
protocol. LDACS supports also unacknowledged point-to-point channels
and ground-to-air broadcast.
The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the
forward link, and 294 kbit/s to 1390 kbit/s on the reverse link,
depending on coding and modulation. Due to strong interference from
legacy systems in the L-band, the most robust coding and modulation
should be expected for initial deployment i.e. 315/294 kbit/s on the
forward/reverse link, respectively.
Since LDACS has been mainly designed for air traffic management
communication it supports mutual entity authentication, integrity and
confidentiality capabilities of user data messages and some control
channel protection capabilities [MAE19].
7.3. Applicability to Deterministic Flows
LDACS has been designed with applications related to the safety and
regularity of the flight in mind. It has therefore been designed as
a deterministic wireless data link (as far as possible).
LDACS medium access is always under the control of the ground-station
of a radio cell. Any medium access for the transmission of user data
has to be requested with a resource request message stating the
requested amount of resources and class of service. The ground-
station performs resource scheduling on the basis of these requests
and grants resources with resource allocation messages. Resource
request and allocation messages are exchanged over dedicated
contention-free control channels.
LDACS has two mechanisms to request resources from the scheduler in
the ground-station. Resources can either be requested "on demand"
with a given class of service. On the forward link, this is done
locally in the ground-station, on the reverse link a dedicated
contention-free control channel is used (Dedicated Control Channel
(DCCH); roughly 83 bit every 60 ms). A resource allocation is always
announced in the control channel of the forward link (Common Control
Channel (CCCH); variable sized). Due to the spacing of the reverse
link control channels of every 60 ms, a medium access delay in the
same order of magnitude is to be expected.
Resources can also be requested "permanently". The permanent
resource request mechanism supports requesting recurring resources in
given time intervals. A permanent resource request has to be
canceled by the user (or by the ground-station, which is always in
control). User data transmissions over LDACS are therefore always
scheduled by the ground-station, while control data uses statically
(i.e. at net entry) allocated recurring resources (DCCH and CCCH).
The current specification documents specify no scheduling algorithm.
However performance evaluations so far have used strict priority
scheduling and round robin for equal priorities for simplicity. In
the current prototype implementations LDACS classes of service are
thus realized as priorities of medium access and not as flows. Note
that this can starve out low priority flows. However, this is not
seen as a big problem since safety related message always go first in
any case. Scheduling of reverse link resources is done in physical
Protocol Data Units (PDU) of 112 bit (or larger if more aggressive
coding and modulation is used). Scheduling on the forward link is
done Byte-wise since the forward link is transmitted continuously by
the ground-station.
In order to support diversity, LDACS supports handovers to other
ground-stations on different channels. Handovers may be initiated by
the aircraft (break-before-make) or by the ground-station (make-
before-break) if it is connected to an alternative ground-station via
the same ground-station controller. Beyond this, FCI diversity shall
be implemented by the multi-link concept.
8. IANA Considerations
This specification does not require IANA action. This specification does not require IANA action.
7. Security Considerations 9. Security Considerations
Most RAW technologies integrate some authentication or encryption Most RAW technologies integrate some authentication or encryption
mechanisms that were defined outside the IETF. mechanisms that were defined outside the IETF.
8. Acknowledgments 10. Contributors
Georgios Z. Papadopoulos: Contributed to the TSCH section.
Nils Maeurer: Contributed to the LDACS section.
Thomas Graeupl: Contributed to the LDACS section.
11. Acknowledgments
Many thanks to the participants of the RAW WG where a lot of the work Many thanks to the participants of the RAW WG where a lot of the work
discussed here happened. discussed here happened.
9. References 12. References
9.1. Normative References 12.1. Normative References
[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-21 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-23 (work
in progress), June 2019. in progress), June 2019.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019. detnet-architecture-13 (work in progress), May 2019.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
skipping to change at page 30, line 25 skipping to change at page 35, line 15
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Protocol (6P)", RFC 8480, Operation Sublayer (6top) Protocol (6P)", RFC 8480,
DOI 10.17487/RFC8480, November 2018, DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>. <https://www.rfc-editor.org/info/rfc8480>.
9.2. Informative References 12.2. Informative References
[Cavalcanti_2019] [Cavalcanti_2019]
Dave Cavalcanti et al., "Extending Time Distribution and Dave Cavalcanti et al., "Extending Time Distribution and
Timeliness Capabilities over the Air to Enable Future Timeliness Capabilities over the Air to Enable Future
Wireless Industrial Automation Systems, the Proceedings of Wireless Industrial Automation Systems, the Proceedings of
IEEE", June 2019. IEEE", June 2019.
[CCAMP] IETF, "Common Control and Measurement Plane", [CCAMP] IETF, "Common Control and Measurement Plane",
<https://dataTracker.ietf.org/doc/charter-ietf-ccamp/>. <https://dataTracker.ietf.org/doc/charter-ietf-ccamp/>.
[dearmas16] [dearmas16]
Jesica de Armas et al., "Determinism through path Jesica de Armas et al., "Determinism through path
diversity: Why packet replication makes sense", September diversity: Why packet replication makes sense", September
2016. 2016.
[Ghasempour_2017] [Ghasempour_2017]
Yasaman Ghasempour et al., "802.11ay: Next-Generation 60 Yasaman Ghasempour et al., "802.11ay: Next-Generation 60
GHz Communications for 100 Gb/s Wi-Fi", December 2017. GHz Communications for 100 Gb/s Wi-Fi", December 2017.
[GRA11] Graeupl, T. and M. Ehammer, "L-DACS1 Data Link Layer
Evolution of ATN/IPS", Proceedings of the 30th IEEE/AIAA
Digital Avionics Systems Conference (DASC) Seattle, WA,
USA, October 2011.
[GRA18] al., T. G. E., "L-band Digital Aeronautical Communications
System (LDACS) flight trials in the national German
project MICONAV", Proceedings of the Integrated
Communications, Navigation, Surveillance Conference
(ICNS) Herndon, VA, USA, April 2018.
[GRA19] Graeupl, T., Rihacek, C., and B. Haindl, "LDACS A/G
Specification", SESAR2020 PJ14-02-01 D3.3.010, February
2019.
[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-msf] [I-D.ietf-6tisch-msf]
Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and
D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)",
draft-ietf-6tisch-msf-03 (work in progress), April 2019. draft-ietf-6tisch-msf-03 (work in progress), April 2019.
[I-D.ietf-bier-te-arch] [I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic
Engineering for Bit Index Explicit Replication (BIER-TE)", Engineering for Bit Index Explicit Replication (BIER-TE)",
draft-ietf-bier-te-arch-02 (work in progress), May 2019. draft-ietf-bier-te-arch-02 (work in progress), May 2019.
[I-D.ietf-roll-nsa-extension] [I-D.ietf-roll-nsa-extension]
Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P.
Thubert, "RPL DAG Metric Container Node State and Thubert, "RPL DAG Metric Container Node State and
Attribute object type extension", draft-ietf-roll-nsa- Attribute object type extension", draft-ietf-roll-nsa-
extension-01 (work in progress), March 2019. extension-03 (work in progress), June 2019.
[I-D.papadopoulos-paw-pre-reqs] [I-D.papadopoulos-paw-pre-reqs]
Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P. Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P.
Thubert, "Exploiting Packet Replication and Elimination in Thubert, "Exploiting Packet Replication and Elimination in
Complex Tracks in LLNs", draft-papadopoulos-paw-pre- Complex Tracks in LLNs", draft-papadopoulos-paw-pre-
reqs-01 (work in progress), March 2019. reqs-01 (work in progress), March 2019.
[I-D.svshah-tsvwg-deterministic-forwarding] [I-D.svshah-tsvwg-deterministic-forwarding]
Shah, S. and P. Thubert, "Deterministic Forwarding PHB", Shah, S. and P. Thubert, "Deterministic Forwarding PHB",
draft-svshah-tsvwg-deterministic-forwarding-04 (work in draft-svshah-tsvwg-deterministic-forwarding-04 (work in
skipping to change at page 31, line 43 skipping to change at page 36, line 48
Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A
6loRH for BitStrings", draft-thubert-6lo-bier-dispatch-06 6loRH for BitStrings", draft-thubert-6lo-bier-dispatch-06
(work in progress), January 2019. (work in progress), January 2019.
[I-D.thubert-bier-replication-elimination] [I-D.thubert-bier-replication-elimination]
Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER-
TE extensions for Packet Replication and Elimination TE extensions for Packet Replication and Elimination
Function (PREF) and OAM", draft-thubert-bier-replication- Function (PREF) and OAM", draft-thubert-bier-replication-
elimination-03 (work in progress), March 2018. elimination-03 (work in progress), March 2018.
[ICAO18] International Civil Aviation Organization (ICAO), "L-Band
Digital Aeronautical Communication System (LDACS)",
International Standards and Recommended Practices Annex 10
- Aeronautical Telecommunications, Vol. III -
Communication Systems, July 2018.
[IEEE80211] [IEEE80211]
"IEEE Standard 802.11 - IEEE Standard for Information "IEEE Standard 802.11 - IEEE Standard for Information
Technology - Telecommunications and information exchange Technology - Telecommunications and information exchange
between systems Local and metropolitan area networks - between systems Local and metropolitan area networks -
Specific requirements - Part 11: Wireless LAN Medium Specific requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Access Control (MAC) and Physical Layer (PHY)
Specifications.". Specifications.".
[IEEE80211ad] [IEEE80211ad]
"802.11ad: Enhancements for very high throughput in the 60 "802.11ad: Enhancements for very high throughput in the 60
skipping to change at page 33, line 5 skipping to change at page 38, line 11
[IEEE_doc_11-19-0373-00] [IEEE_doc_11-19-0373-00]
Kevin Stanton et Al., "Time-Sensitive Applications Support Kevin Stanton et Al., "Time-Sensitive Applications Support
in EHT", March 2019. in EHT", March 2019.
[ISA100.11a] [ISA100.11a]
ISA/IEC, "ISA100.11a, Wireless Systems for Automation, ISA/IEC, "ISA100.11a, Wireless Systems for Automation,
also IEC 62734", 2011, < http://www.isa100wci.org/en- also IEC 62734", 2011, < http://www.isa100wci.org/en-
US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch-
WEB-ETSI.aspx>. WEB-ETSI.aspx>.
[MAE19] Maeurer, N. and C. Schmitt, "DLR tests digital
communications technologies combined with additional
navigation functions for the first time", Proceedings of
the Integrated Communications, Navigation, Surveillance
Conference (ICNS) Washington D.C., USA, April 2019.
[morell13] [morell13]
Antoni Morell et al., "Label switching over IEEE802.15.4e Antoni Morell et al., "Label switching over IEEE802.15.4e
networks", April 2013. networks", April 2013.
[Nitsche_2015] [Nitsche_2015]
Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz
communication for multi-Gigabit-per-second Wi-Fi", communication for multi-Gigabit-per-second Wi-Fi",
December 2014. December 2014.
[PCE] IETF, "Path Computation Element", [PCE] IETF, "Path Computation Element",
skipping to change at page 33, line 48 skipping to change at page 39, line 11
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RIH18] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S.,
Graeupl, T., Schnell, M., and N. Fistas, "L-band Digital
Aeronautical Communications System (LDACS) Activities in
SESAR2020", Proceedings of the Integrated Communications
Navigation and Surveillance Conference (ICNS) Herndon, VA,
USA, April 2018.
[SAJ14] Sajatovic, M., Guenzel, H., and S. Mueller, "WA04 D22 Test
Report for Assessing LDACS1 Transmitter Impact upon DME/
TACAN Receivers", April 2014.
[SCH19] Schnell, M., "DLR tests digital communications
technologies combined with additional navigation functions
for the first time", March 2019,
<https://www.dlr.de/dlr/en/desktopdefault.aspx/
tabid-10081/151_read-32951/#/gallery/33877>.
[TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4", [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4",
<https://dataTracker.ietf.org/doc/charter-ietf-6tisch/>. <https://dataTracker.ietf.org/doc/charter-ietf-6tisch/>.
[vilajosana19] [vilajosana19]
Xavier Vilajosana et al., "6TiSCH: Industrial Performance Xavier Vilajosana et al., "6TiSCH: Industrial Performance
for IPv6 Internet-of-Things Networks", June 2019. for IPv6 Internet-of-Things Networks", June 2019.
[WirelessHART] [WirelessHART]
www.hartcomm.org, "Industrial Communication Networks - www.hartcomm.org, "Industrial Communication Networks -
Wireless Communication Network and Communication Profiles Wireless Communication Network and Communication Profiles
skipping to change at page 34, line 25 skipping to change at page 40, line 4
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis 06254
FRANCE FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Dave Cavalcanti Dave Cavalcanti
Intel Corporation Intel Corporation
2111 NE 25th Ave 2111 NE 25th Ave
Hillsboro, OR 97124 Hillsboro, OR 97124
USA USA
Phone: 503 712 5566 Phone: 503 712 5566
Email: dave.cavalcanti@intel.com Email: dave.cavalcanti@intel.com
Xavier Vilajosana Xavier Vilajosana
Universitat Oberta de Catalunya Universitat Oberta de Catalunya
156 Rambla Poblenou 156 Rambla Poblenou
Barcelona, Catalonia 08018 Barcelona, Catalonia 08018
Spain Spain
Email: xvilajosana@uoc.edu Email: xvilajosana@uoc.edu
Corinna Schmitt
Universitaet der Bundeswehr Muenchen
Werner-Heisenberg-Weg 39
Neubiberg 85577
Germany
Email: corinna.schmitt@unibw.de
 End of changes. 87 change blocks. 
155 lines changed or deleted 425 lines changed or added

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