< draft-ietf-6tisch-architecture-20.txt   draft-ietf-6tisch-architecture-21.txt >
6TiSCH P. Thubert, Ed. 6TiSCH P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track March 1, 2019 Intended status: Informational June 19, 2019
Expires: September 2, 2019 Expires: December 21, 2019
An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
draft-ietf-6tisch-architecture-20 draft-ietf-6tisch-architecture-21
Abstract Abstract
This document describes a network architecture that provides low- This document describes a network architecture that provides low-
latency, low-jitter and high-reliability packet delivery. It latency, low-jitter and high-reliability packet delivery. It
combines a high-speed powered backbone and subnetworks using IEEE combines a high-speed powered backbone and subnetworks using IEEE
802.15.4 time-slotted channel hopping (TSCH) to meet the requirements 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements
of LowPower wireless deterministic applications. of LowPower wireless deterministic applications.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 September 2, 2019. This Internet-Draft will expire on December 21, 2019.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms and References . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10
2.3. References . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Related Documents . . . . . . . . . . . . . . . . . . . . 11
3. High Level Architecture . . . . . . . . . . . . . . . . . . . 12 3. High Level Architecture . . . . . . . . . . . . . . . . . . . 12
3.1. A Non-Broadcast Multi-Access Radio Mesh Network . . . . . 12 3.1. A Non-Broadcast Multi-Access Radio Mesh Network . . . . . 12
3.2. A Multi-Link Subnet Model . . . . . . . . . . . . . . . . 13 3.2. A Multi-Link Subnet Model . . . . . . . . . . . . . . . . 13
3.3. TSCH: A Deterministic MAC Layer . . . . . . . . . . . . . 15 3.3. TSCH: A Deterministic MAC Layer . . . . . . . . . . . . . 15
3.4. Scheduling TSCH . . . . . . . . . . . . . . . . . . . . . 15 3.4. Scheduling TSCH . . . . . . . . . . . . . . . . . . . . . 16
3.5. Distributed vs. Centralized Routing . . . . . . . . . . . 17 3.5. Distributed vs. Centralized Routing . . . . . . . . . . . 17
3.6. Forwarding Over TSCH . . . . . . . . . . . . . . . . . . 18 3.6. Forwarding Over TSCH . . . . . . . . . . . . . . . . . . 18
3.7. 6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . 19 3.7. 6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . 19
4. Architecture Components . . . . . . . . . . . . . . . . . . . 21 4. Architecture Components . . . . . . . . . . . . . . . . . . . 21
4.1. 6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . . 21 4.1. 6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . . 21
4.1.1. RPL-Unaware Leaves and 6LoWPAN ND . . . . . . . . . . 21 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND . . . . . . . . . . 21
4.1.2. RPL Root And 6LBR . . . . . . . . . . . . . . . . . . 21 4.1.2. RPL Root And 6LBR . . . . . . . . . . . . . . . . . . 22
4.2. Network Access and Addressing . . . . . . . . . . . . . . 22 4.2. Network Access and Addressing . . . . . . . . . . . . . . 23
4.2.1. Join Process . . . . . . . . . . . . . . . . . . . . 22 4.2.1. Join Process . . . . . . . . . . . . . . . . . . . . 23
4.2.2. Registration . . . . . . . . . . . . . . . . . . . . 24 4.2.2. Registration . . . . . . . . . . . . . . . . . . . . 25
4.3. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . 26 4.3. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . 26
4.3.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.2. Scheduling Functions and the 6top protocol . . . . . 27 4.3.2. Scheduling Functions and the 6top protocol . . . . . 28
4.3.3. 6top and RPL Objective Function operations . . . . . 29 4.3.3. 6top and RPL Objective Function operations . . . . . 29
4.3.4. Network Synchronization . . . . . . . . . . . . . . . 29 4.3.4. Network Synchronization . . . . . . . . . . . . . . . 30
4.3.5. SlotFrames and CDU matrix . . . . . . . . . . . . . . 31 4.3.5. SlotFrames and CDU matrix . . . . . . . . . . . . . . 31
4.3.6. Distributing the reservation of cells . . . . . . . . 32 4.3.6. Distributing the reservation of cells . . . . . . . . 32
4.4. Communication Paradigms and Interaction Models . . . . . 33 4.4. Communication Paradigms and Interaction Models . . . . . 33
4.5. Schedule Management Mechanisms . . . . . . . . . . . . . 34 4.5. Schedule Management Mechanisms . . . . . . . . . . . . . 34
4.5.1. Static Scheduling . . . . . . . . . . . . . . . . . . 34 4.5.1. Static Scheduling . . . . . . . . . . . . . . . . . . 34
4.5.2. Neighbor-to-neighbor Scheduling . . . . . . . . . . . 34 4.5.2. Neighbor-to-neighbor Scheduling . . . . . . . . . . . 35
4.5.3. Remote Monitoring and Schedule Management . . . . . . 35 4.5.3. Remote Monitoring and Schedule Management . . . . . . 35
4.5.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . 37 4.5.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . 38
4.6. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 37 4.6. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6.1. General Behavior of Tracks . . . . . . . . . . . . . 38 4.6.1. General Behavior of Tracks . . . . . . . . . . . . . 39
4.6.2. Serial Track . . . . . . . . . . . . . . . . . . . . 38 4.6.2. Serial Track . . . . . . . . . . . . . . . . . . . . 39
4.6.3. Complex Track with Replication and Elimination . . . 39 4.6.3. Complex Track with Replication and Elimination . . . 40
4.6.4. DetNet End-to-end Path . . . . . . . . . . . . . . . 39 4.6.4. DetNet End-to-end Path . . . . . . . . . . . . . . . 40
4.6.5. Cell Reuse . . . . . . . . . . . . . . . . . . . . . 40 4.6.5. Cell Reuse . . . . . . . . . . . . . . . . . . . . . 41
4.7. Forwarding Models . . . . . . . . . . . . . . . . . . . . 41 4.7. Forwarding Models . . . . . . . . . . . . . . . . . . . . 42
4.7.1. Track Forwarding . . . . . . . . . . . . . . . . . . 41 4.7.1. Track Forwarding . . . . . . . . . . . . . . . . . . 42
4.7.2. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . 44 4.7.2. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . 45
4.7.3. Fragment Forwarding . . . . . . . . . . . . . . . . . 44 4.7.3. Fragment Forwarding . . . . . . . . . . . . . . . . . 45
4.8. Advanced 6TiSCH Routing . . . . . . . . . . . . . . . . . 46 4.8. Advanced 6TiSCH Routing . . . . . . . . . . . . . . . . . 47
4.8.1. Packet Marking and Handling . . . . . . . . . . . . . 46 4.8.1. Packet Marking and Handling . . . . . . . . . . . . . 47
4.8.2. Replication, Retries and Elimination . . . . . . . . 47 4.8.2. Replication, Retries and Elimination . . . . . . . . 48
4.8.3. Differentiated Services Per-Hop-Behavior . . . . . . 49 4.8.3. Differentiated Services Per-Hop-Behavior . . . . . . 50
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 50 7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 51
7.2. Special Thanks . . . . . . . . . . . . . . . . . . . . . 51 7.2. Special Thanks . . . . . . . . . . . . . . . . . . . . . 52
7.3. And Do not Forget . . . . . . . . . . . . . . . . . . . . 51 7.3. And Do not Forget . . . . . . . . . . . . . . . . . . . . 52
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1. Normative References . . . . . . . . . . . . . . . . . . 52 8.1. Normative References . . . . . . . . . . . . . . . . . . 53
8.2. Informative References . . . . . . . . . . . . . . . . . 54 8.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Dependencies on Work In Progress . . . . . . . . . . 60 Appendix A. Related Work In Progress . . . . . . . . . . . . . . 61
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 61 A.1. Chartered IETF work items . . . . . . . . . . . . . . . . 61
A.2. Unchartered IETF work items . . . . . . . . . . . . . . . 62
A.2.1. 6TiSCH Zerotouch security . . . . . . . . . . . . . . 62
A.2.2. 6TiSCH Track Setup . . . . . . . . . . . . . . . . . 62
A.2.3. Using BIER in a 6TiSCH Network . . . . . . . . . . . 63
A.3. External (non-IETF) work items . . . . . . . . . . . . . 63
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
Wireless Networks enable a wide variety of devices of any size to get Wireless Networks enable a wide variety of devices of any size to get
interconnected, often at a very low marginal cost per device, at any interconnected, often at a very low marginal cost per device, at any
range, and in circumstances where wiring may be impractical, for range, and in circumstances where wiring may be impractical, for
instance on fast-moving or rotating devices. instance on fast-moving or rotating devices.
On the other hand, Deterministic Networking maximizes the packet On the other hand, Deterministic Networking maximizes the packet
delivery ratio within a bounded latency so as to enable mission- delivery ratio within a bounded latency so as to enable mission-
skipping to change at page 3, line 48 skipping to change at page 4, line 7
a different channel can be used for each transmission, and that a different channel can be used for each transmission, and that
allows to schedule transmissions for deterministic operations. allows to schedule transmissions for deterministic operations.
Proven Deterministic Networking standards for use in Process Control, Proven Deterministic Networking standards for use in Process Control,
including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART], including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART],
have demonstrated the capabilities of the IEEE Std 802.15.4 TSCH MAC have demonstrated the capabilities of the IEEE Std 802.15.4 TSCH MAC
for high reliability against interference, low-power consumption on for high reliability against interference, low-power consumption on
well-known flows, and its applicability for Traffic Engineering (TE) well-known flows, and its applicability for Traffic Engineering (TE)
from a central controller. from a central controller.
In order to enable the convergence of IT and OT in Low-Power Lossy To enable the convergence of IT and OT in Low-Power Lossy Networks
Networks (LLNs), the 6TiSCH Architecture supports an IETF suite of (LLNs), the 6TiSCH Architecture supports an IETF suite of protocols
protocols over the TSCH MAC to provide IP connectivity for energy and over the IEEE Std 802.15.4TSCH MAC to provide IP connectivity for
otherwise constrained wireless devices. energy and otherwise constrained wireless devices.
6TiSCH provides large scaling capabilities, which, in a number of 6TiSCH provides large scaling capabilities, which, in a number of
scenarios, require the addition of a high-speed and reliable backbone scenarios, require the addition of a high-speed and reliable backbone
and the use of IP version 6 (IPv6). and the use of IP version 6 (IPv6) [RFC8200]. The 6TiSCH
Architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to the
constrained media and RPL [RFC6550] for the distributed routing
operations.
The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model
that is composed of a federating backbone, e.g., an Ethernet bridged that is composed of a federating backbone, e.g., an Ethernet bridged
network, and a number of IEEE Std 802.15.4 TSCH low-power wireless network, and a number of IEEE Std 802.15.4 TSCH low-power wireless
networks federated and synchronized by Backbone Routers. networks federated and synchronized by Backbone Routers.
Centralized routing refers to a model where routes are computed and Centralized routing refers to a model where routes are computed and
resources are allocated from a central controller. This is resources are allocated from a central controller. This is
particularly helpful to schedule deterministic multihop particularly helpful to schedule deterministic multihop
transmissions. Distributed is a concurrent model that relies in more transmissions. In contrast, Distributed Routing refers to a model
classical peer to peer protocols for TSCH resource allocation and that relies on concurrent peer to peer protocol exchanges for TSCH
routing operations. resource allocation and routing operations.
The architecture defines mechanisms to establish and maintain routing The architecture defines mechanisms to establish and maintain routing
and scheduling in a centralized, distributed, or mixed fashion, for and scheduling in a centralized, distributed, or mixed fashion, for
use in multiple OT environments. It is applicable in particular to use in multiple OT environments. It is applicable in particular to
highly scalable solutions such a Advance metering that leverage highly scalable solutions such as used in Advanced Metering
distributed routing to address multipath over a large number of hops Infrastructure [AMI] solutions that leverage distributed routing to
and nodes. enable multipath forwarding over large LLN meshes.
Other use cases includes industrial control systems, building Other use cases includes industrial control systems, building
automation, in-vehicle command and control, commercial automation and automation, in-vehicle command and control, commercial automation and
asset tracking with mobile scenarios, and home automation asset tracking with mobile scenarios, and home automation
applications. The determinism provides for a more reliable applications. The determinism provides for a more reliable
experience which can be used to monitor and manage resources, e.g., experience which can be used to monitor and manage resources, e.g.,
energy and water, in a more efficient fashion. energy and water, in a more efficient fashion.
2. Terms and References 2. Terminology
2.1. Terminology 2.1. New Terms
The draft does not reuse terms from the IEEE Std 802.15.4 The draft does not reuse terms from the IEEE Std 802.15.4
[IEEE802154] standard such as "path" or "link" which bear a meaning [IEEE802154] standard such as "path" or "link" which bear a meaning
that is quite different from classical IETF parlance. that is quite different from classical IETF parlance.
This document adds the following terms: This document adds the following terms:
6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e): 6TiSCH defines 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e): 6TiSCH defines
an adaptation sublayer for IPv6 over TSCH called 6top, a an adaptation sublayer for IPv6 over TSCH called 6top, a
set of protocols for setting up a TSCH schedule in set of protocols for setting up a TSCH schedule in
skipping to change at page 5, line 13 skipping to change at page 5, line 22
providing a service similar to TSCH. providing a service similar to TSCH.
6top (6TiSCH Operation Sublayer): The next higher layer of the IEEE 6top (6TiSCH Operation Sublayer): The next higher layer of the IEEE
Std 802.15.4 TSCH MAC layer. 6top provides the Std 802.15.4 TSCH MAC layer. 6top provides the
abstraction of an IP link over a TSCH MAC, schedules abstraction of an IP link over a TSCH MAC, schedules
packets over TSCH cells, and exposes a management packets over TSCH cells, and exposes a management
interface to schedule TSCH cells. interface to schedule TSCH cells.
6P (6top Protocol): The protocol defined in [RFC8480]. 6P enables 6P (6top Protocol): The protocol defined in [RFC8480]. 6P enables
Layer-2 peers to allocate, move or deallocate cells in Layer-2 peers to allocate, move or deallocate cells in
their respective schedules in order to communicate. 6P their respective schedules to communicate. 6P operates
operates at the 6top layer. at the 6top layer.
6P Transaction: A 2-way or 3-way sequence of 6P messages used by 6P Transaction: A 2-way or 3-way sequence of 6P messages used by
Layer-2 peers to modify their communication schedule. Layer-2 peers to modify their communication schedule.
ASN (Absolute Slot Number): The total number of timeslots that have ASN (Absolute Slot Number): The total number of timeslots that have
elapsed since the PAN coordinator has started the TSCH elapsed since the PAN coordinator has started the TSCH
network. Incremented by one at each timeslot. It is network. Incremented by one at each timeslot. It is
wide enough to not roll over in practice. wide enough to not roll over in practice.
bundle: A group of equivalent scheduled cells, i.e. cells bundle: A group of equivalent scheduled cells, i.e. cells
skipping to change at page 5, line 46 skipping to change at page 6, line 6
Layer-2 (switching) or Layer-3 (routing) forwarding Layer-2 (switching) or Layer-3 (routing) forwarding
operations. A pair of Layer-3 bundles (one for each operations. A pair of Layer-3 bundles (one for each
direction) maps to an IP Link with a neighbor, whereas a direction) maps to an IP Link with a neighbor, whereas a
set of Layer-2 bundles (a number per neighbor, either set of Layer-2 bundles (a number per neighbor, either
from or to the neighbor) corresponds to the relation of from or to the neighbor) corresponds to the relation of
one or more incoming bundle(s) from the previous-hop one or more incoming bundle(s) from the previous-hop
neighbor(s) with one or more outgoing bundle(s) to the neighbor(s) with one or more outgoing bundle(s) to the
next-hop neighbor(s) along a Track. next-hop neighbor(s) along a Track.
CCA (Clear Channel Assessment): A mechanism defined in [IEEE802154] CCA (Clear Channel Assessment): A mechanism defined in [IEEE802154]
whereby nodes listen to the channel before sending, in whereby nodes listen to the channel before sending to
order to detect ongoing transmissions from other parties. detect ongoing transmissions from other parties. Because
Because the network is synchronized, CCA cannot be used the network is synchronized, CCA cannot be used to detect
to detect colliding transmissions within the same colliding transmissions within the same network, but it
network, but it can be used to detect other radio can be used to detect other radio networks in vicinity.
networks in vicinity.
cell: A unit of transmission resource in the CDU matrix, a cell cell: A unit of transmission resource in the CDU matrix, a cell
is identified by a slotOffset and a channelOffset. A is identified by a slotOffset and a channelOffset. A
cell can be scheduled or unscheduled. cell can be scheduled or unscheduled.
Channel Distribution/Usage (CDU) matrix: : A matrix of cells (i,j) Channel Distribution/Usage (CDU) matrix: : A matrix of cells (i,j)
representing the spectrum (channel) distribution among representing the spectrum (channel) distribution among
the different nodes in the 6TiSCH network. The CDU the different nodes in the 6TiSCH network. The CDU
matrix has width in timeslots, equal to the period of the matrix has width in timeslots, equal to the period of the
network scheduling operation, and height equal to the network scheduling operation, and height equal to the
skipping to change at page 6, line 39 skipping to change at page 6, line 46
network to support the appropriation process, which is a network to support the appropriation process, which is a
negotiation between nodes within an interference domain. negotiation between nodes within an interference domain.
A node that manages to appropriate a chunk gets to decide A node that manages to appropriate a chunk gets to decide
which transmissions will occur over the cells in the which transmissions will occur over the cells in the
chunk within its interference domain (i.e., a parent node chunk within its interference domain (i.e., a parent node
will decide when the cells within the appropriated chunk will decide when the cells within the appropriated chunk
are used and by which node, among its children. are used and by which node, among its children.
CoJP (Constrained Join Protocol): The Constrained Join Protocol CoJP (Constrained Join Protocol): The Constrained Join Protocol
(CoJP) enables a pledge to securely join a 6TiSCH network (CoJP) enables a pledge to securely join a 6TiSCH network
and obtain network parameters over a secure channel. In and obtain network parameters over a secure channel.
the minimal setup with pre-shared keys defined in Minimal Security Framework for 6TiSCH
[I-D.ietf-6tisch-minimal-security], CoJP can operate with [I-D.ietf-6tisch-minimal-security] defines the minimal
a single round trip exchange. CoJP setup with pre-shared keys defined. In that mode,
CoJP can operate with a single round trip exchange.
dedicated cell: A cell that is reserved for a given node to transmit dedicated cell: A cell that is reserved for a given node to transmit
to a specific neighbor. to a specific neighbor.
deterministic network: The generic concept of deterministic network deterministic network: The generic concept of deterministic network
is defined in [I-D.ietf-detnet-architecture]. When is defined in [I-D.ietf-detnet-architecture]. When
applied to 6TiSCH, it refers to the reservation of Tracks applied to 6TiSCH, it refers to the reservation of Tracks
which guarantee an end-to-end latency and optimize the which guarantee an end-to-end latency and optimize the
PDR for well-characterized flows. PDR for well-characterized flows.
skipping to change at page 11, line 5 skipping to change at page 11, line 14
RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) RPL: IPv6 Routing Protocol for LLNs (pronounced ripple)
RA: Router Advertisement RA: Router Advertisement
RS: Router Solicitation RS: Router Solicitation
TSCH: timeslotted Channel Hopping TSCH: timeslotted Channel Hopping
TID: Transaction ID (a sequence counter in the EARO) TID: Transaction ID (a sequence counter in the EARO)
2.3. References 2.3. Related Documents
The draft also conforms to the terms and models described in The draft also conforms to the terms and models described in
[RFC3444] and [RFC5889] and uses the vocabulary and the concepts [RFC3444] and [RFC5889] and uses the vocabulary and the concepts
defined in [RFC4291] for the IPv6 Architecture and refers [RFC4080] defined in [RFC4291] for the IPv6 Architecture and refers [RFC4080]
for reservation for reservation
The draft uses domain-specific terminology defined or referenced in: The draft uses domain-specific terminology defined or referenced in:
"Neighbor Discovery Optimization for Low-power and Lossy Networks" "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775], [RFC6775],
skipping to change at page 13, line 34 skipping to change at page 13, line 42
centralized fashion by a PCE [PCE] that programs both the routes and centralized fashion by a PCE [PCE] that programs both the routes and
the schedules inside the 6TiSCH nodes, or by in a distributed fashion the schedules inside the 6TiSCH nodes, or by in a distributed fashion
using a reactive routing protocol and a Hop-by-Hop scheduling using a reactive routing protocol and a Hop-by-Hop scheduling
protocol. protocol.
This architecture expects that a 6LoWPAN node can connect as a leaf This architecture expects that a 6LoWPAN node can connect as a leaf
to a RPL network, where the leaf support is the minimal functionality to a RPL network, where the leaf support is the minimal functionality
to connect as a host to a RPL network without the need to participate to connect as a host to a RPL network without the need to participate
to the full routing protocol. The architecture also expects that a to the full routing protocol. The architecture also expects that a
6LoWPAN node that is not aware at all of the RPL protocol may also 6LoWPAN node that is not aware at all of the RPL protocol may also
connect as described in [I-D.thubert-roll-unaware-leaves]. connect as described in [I-D.ietf-roll-unaware-leaves].
3.2. A Multi-Link Subnet Model 3.2. A Multi-Link Subnet Model
An extended configuration of the subnet comprises multiple LLNs as An extended configuration of the subnet comprises multiple LLNs as
illustrated in Figure 2. In the extended configuration, a Routing illustrated in Figure 2. In the extended configuration, a Routing
Registrar [RFC8505] may be connected to the node that acts as RPL Registrar [RFC8505] may be connected to the node that acts as RPL
root and / or 6LoWPAN 6LBR and provides connectivity to the larger root and / or 6LoWPAN 6LBR and provides connectivity to the larger
campus / factory plant network over a high-speed backbone or a back- campus / factory plant network over a high-speed backbone or a back-
haul link. The Routing registrar may perform IPv6 ND proxy haul link. The Routing registrar may perform IPv6 ND proxy
operations, or redistribute the registration in a routing protocol operations, or redistribute the registration in a routing protocol
such as OSPF [RFC5340] or BGP [RFC2545], or inject a route in a such as OSPF [RFC5340] or BGP [RFC2545], or inject a route in a
mobility protocol such as MIPv6 [RFC6275], NEMO [RFC3963], or LISP mobility protocol such as MIPv6 [RFC6275], NEMO [RFC3963], or LISP
[RFC6830]. [RFC6830].
Multiple LLNs can be interconnected and possibly synchronized over a Multiple LLNs can be interconnected and possibly synchronized over a
backbone, which can be wired or wireless. The backbone can operate backbone, which can be wired or wireless. The backbone can operate
with IPv6 ND [RFC4861][RFC4862] procedures or an hybrid of IPv6 ND with IPv6 ND [RFC4861][RFC4862] procedures or an hybrid of IPv6 ND
and 6LoWPAN ND [RFC6775] [RFC8505]. and 6LoWPAN ND [RFC6775] [RFC8505].
| |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
(default) | | (Optional) | | | | IPv6 (default) | | (Optional) | | | | IPv6
Router | | 6LBR | | | | Node Router | | 6LBR | | | | Node
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| Backbone side | | | Backbone side | |
--------+---+--------------------+-+---------------+------+--- --------+---+--------------------+-+---------------+------+---
| | | | | |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Routing | | Routing | | Routing | | Routing | | Routing | | Routing |
| Registrar | | Registrar | | Registrar | | Registrar | | Registrar | | Registrar |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
o Wireless side o o o o o Wireless side 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 o o o
o 6TiSCH o 6TiSCH o o o o 6TiSCH o o o 6TiSCH o 6TiSCH o o o o 6TiSCH o
o o LLN o o o o LLN o o LLN o o o LLN o o o o LLN o o LLN 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
Figure 2: Extended Configuration of a 6TiSCH Network Figure 2: Extended Configuration of a 6TiSCH Network
A Routing Registrar that performs proxy IPv6 ND operations over the A Routing Registrar that performs proxy IPv6 ND operations over the
backbone on behalf of the 6TiSCH nodes is called a Backbone Router backbone on behalf of the 6TiSCH nodes is called a Backbone Router
(6BBR) [I-D.ietf-6lo-backbone-router]. The 6BBRs are placed along (6BBR) [I-D.ietf-6lo-backbone-router]. The 6BBRs are placed along
the wireless edge of a Backbone, and federate multiple wireless links the wireless edge of a Backbone, and federate multiple wireless links
to form a single MultiLink Subnet. The 6BBRs synchronize with one to form a single MultiLink Subnet. The 6BBRs synchronize with one
another over the backbone, so as to ensure that the multiple LLNs another over the backbone, so as to ensure that the multiple LLNs
that form the IPv6 subnet stay tightly synchronized. that form the IPv6 subnet stay tightly synchronized.
A 6LBR located on the backbone may contribute to Duplicate Address The use of multicast can also be reduced on the backbone with a
Detection as well as Address Lookup and save multicast operations registrar that would contribute to Duplicate Address Detection as
[I-D.thubert-6lo-unicast-lookup]. well as Address Lookup using only unicast request/response exchanges.
[I-D.thubert-6lo-unicast-lookup] is a proposed method that presents
an example of how to this could be achieved with an extension of
[RFC8505], using a 6LBR as a SubNet-level registrar.
As detailed in Section 4.1 the 6LBR that serves the LLN and the root As detailed in Section 4.1 the 6LBR that serves the LLN and the root
of the RPL network need to share information about the devices that of the RPL network need to share information about the devices that
are learned through either protocol but not both. The preferred way are learned through either protocol but not both. The preferred way
of achieving this is to collocate/combine them. The combined RPL of achieving this is to collocate/combine them. The combined RPL
root and 6LBR may be collocated with the 6BBR, or directly attached root and 6LBR may be collocated with the 6BBR, or directly attached
to the 6BBR. In the latter case, it leverages the extended to the 6BBR. In the latter case, it leverages the extended
registration process defined in [RFC8505] to proxy the 6LoWPAN ND registration process defined in [RFC8505] to proxy the 6LoWPAN ND
registration to the 6BBR on behalf of the LLN nodes, so that the 6BBR registration to the 6BBR on behalf of the LLN nodes, so that the 6BBR
may in turn perform proxy classical ND operations over the backbone. may in turn perform proxy classical ND operations over the backbone.
skipping to change at page 17, line 4 skipping to change at page 17, line 18
the "6TiSCH Minimal Scheduling Function (MSF)" the "6TiSCH Minimal Scheduling Function (MSF)"
[I-D.ietf-6tisch-msf] influence the operation of the MAC layer to [I-D.ietf-6tisch-msf] influence the operation of the MAC layer to
add, update and remove cells in its own, and its peer's schedules add, update and remove cells in its own, and its peer's schedules
using 6P [RFC8480], for the negotiation of the MAC resources. using 6P [RFC8480], for the negotiation of the MAC resources.
Centralized (or Remote) Monitoring and Schedule Management: This Centralized (or Remote) Monitoring and Schedule Management: This
refers to the central computation of a schedule and the capability refers to the central computation of a schedule and the capability
to forward a frame based on the cell of arrival. In that case, to forward a frame based on the cell of arrival. In that case,
the related portion of the device schedule as well as other device the related portion of the device schedule as well as other device
resources are managed by an abstract Network Management Entity resources are managed by an abstract Network Management Entity
(NME), which may cooperate with the PCE in order to minimize the (NME), which may cooperate with the PCE to minimize the
interaction with and the load on the constrained device. This interaction with and the load on the constrained device. This
model is the TSCH adaption of the "DetNet Architecture" model is the TSCH adaption of the "DetNet Architecture"
[I-D.ietf-detnet-architecture], and it enables Traffic Engineering [I-D.ietf-detnet-architecture], and it enables Traffic Engineering
with deterministic properties. with deterministic properties.
Hop-by-hop Scheduling: This refers to the possibility to reserves Hop-by-hop Scheduling: This refers to the possibility to reserves
cells along a path for a particular flow using a distributed cells along a path for a particular flow using a distributed
mechanism. mechanism.
It is not expected that all use cases will require all those It is not expected that all use cases will require all those
skipping to change at page 19, line 5 skipping to change at page 19, line 17
at the 6LoWPAN sublayer. The first fragment is forwarded like any at the 6LoWPAN sublayer. The first fragment is forwarded like any
IPv6 packet and leaves a state in the intermediate hops to enable IPv6 packet and leaves a state in the intermediate hops to enable
forwarding of the next fragments that do not have a IP header forwarding of the next fragments that do not have a IP header
without the need to recompose the packet at every hop. without the need to recompose the packet at every hop.
A deeper dive on these operations can be found in Section 4.7. A deeper dive on these operations can be found in Section 4.7.
The following table summarizes how the forwarding models apply to the The following table summarizes how the forwarding models apply to the
various routing and scheduling possibilities: various routing and scheduling possibilities:
+--------------------+------------+-----------------------------------+ +-------------------+------------+----------------------------------+
| Forwarding Model | Routing | Scheduling | | Forwarding Model | Routing | Scheduling |
+====================+============+===================================+ +===================+============+==================================+
| | | Static (Minimal Configuration) | | | | Static (Minimal Configuration) |
+ classical IPv6 + RPL +-----------------------------------+ + classical IPv6 + RPL +----------------------------------+
| / | | Neighbor-to-Neighbor (SF+6P) | | / | | Neighbor-to-Neighbor (SF+6P) |
+ 6LoWPAN Fragment +------------+-----------------------------------+ + 6LoWPAN Fragment +------------+----------------------------------+
| |Reactive P2P| Hop-by-Hop (TBD) | | |Reactive P2P| Hop-by-Hop (TBD) |
+--------------------+------------+-----------------------------------+ +-------------------+------------+----------------------------------+
|G-MPLS Track Fwrding| PCE |Remote Monitoring and Schedule Mgt | |G-MPLS Track Fwding| PCE |Remote Monitoring and Schedule Mgt|
+--------------------+------------+-----------------------------------+ +-------------------+------------+----------------------------------+
3.7. 6TiSCH Stack 3.7. 6TiSCH Stack
The IETF proposes multiple techniques for implementing functions The IETF proposes multiple techniques for implementing functions
related to routing, transport or security. related to routing, transport or security.
In order to control the complexity of possible deployments and device The 6TiSCH architecture limits the possible variations of the stack
interactions, and to limit the size of the resulting object code, the and recommends a number of base elements for LLN applications to
6TiSCH architecture limits the possible variations of the stack and control the complexity of possible deployments and device
recommends a number of base elements for LLN applications. In interactions, and to limit the size of the resulting object code. In
particular, UDP [RFC0768], IPv6 [RFC8200] and the Constrained particular, UDP [RFC0768], IPv6 [RFC8200] and the Constrained
Application Protocol [RFC7252] (CoAP) are used as the transport / Application Protocol [RFC7252] (CoAP) are used as the transport /
binding of choice for applications and management as opposed to TCP binding of choice for applications and management as opposed to TCP
and HTTP. and HTTP.
The resulting protocol stack is represented in Figure 4: The resulting protocol stack is represented in Figure 4:
+--------+--------+ +--------+--------+
| Applis | CoJP | | Applis | CoJP |
+--------+--------+--------------+-----+ +--------+--------+--------------+-----+
skipping to change at page 21, line 11 skipping to change at page 21, line 32
In such cases, it is perfectly doable to adopt a subset of the In such cases, it is perfectly doable to adopt a subset of the
selection that is presented hereafter and then select alternate selection that is presented hereafter and then select alternate
components to complete the solution wherever needed. components to complete the solution wherever needed.
4. Architecture Components 4. Architecture Components
4.1. 6LoWPAN (and RPL) 4.1. 6LoWPAN (and RPL)
A RPL DODAG is formed of a root, a collection of routers, and leaves A RPL DODAG is formed of a root, a collection of routers, and leaves
that are hosts. Hosts are nodes which do not forward packets that that are hosts. Hosts are nodes which do not forward packets that
they did not generate. RPL-aware leaves will participate to RPL in they did not generate. RPL-aware leaves will participate to RPL to
order to advertise their own addresses, whereas RPL-unaware leaves advertise their own addresses, whereas RPL-unaware leaves depend on a
depend on a connected RPL router to do so. RPL interacts with connected RPL router to do so. RPL interacts with 6LoWPAN ND at
6LoWPAN ND at multiple levels, in particular at the root and in the multiple levels, in particular at the root and in the RPL-unaware
RPL-unaware leaves. leaves.
4.1.1. RPL-Unaware Leaves and 6LoWPAN ND 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND
RPL needs a set of information in order to advertise a leaf node RPL needs a set of information to advertise a leaf node through a DAO
through a DAO message and establish reachability. message and establish reachability.
"Routing for RPL Leaves" [I-D.thubert-roll-unaware-leaves] details "Routing for RPL Leaves" [I-D.ietf-roll-unaware-leaves] details the
the basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN that
that supports [RFC8505] to obtain return connectivity via the RPL supports [RFC8505] to obtain return connectivity via the RPL network
network as an RPL-unaware leaf. The leaf indicates that it requires as an RPL-unaware leaf. The leaf indicates that it requires
reachability services for the Registered Address from a Routing reachability services for the Registered Address from a Routing
Registrar by settig a 'R' flag in the Extended Address Registration Registrar by settig a 'R' flag in the Extended Address Registration
Option [RFC8505], and it provides a TID that maps to a sequence Option [RFC8505], and it provides a TID that maps to a sequence
number in section 7 of RPL [RFC6550]. number in section 7 of RPL [RFC6550].
The RPL InstanceID that the leaf wants to participate to may be The RPL InstanceID that the leaf wants to participate to may be
signaled in the Opaque field of the EARO. On the backbone, the signaled in the Opaque field of the EARO. On the backbone, the
InstanceID is expected to be mapped to an overlay that matches the InstanceID is expected to be mapped to an overlay that matches the
RPL Instance, e.g., a Virtual LAN (VLAN) or a virtual routing and RPL Instance, e.g., a Virtual LAN (VLAN) or a virtual routing and
forwarding (VRF) instance. forwarding (VRF) instance.
skipping to change at page 22, line 8 skipping to change at page 22, line 31
indicated in the 6LoWPAN Capability Indication Option (6CIO). The indicated in the 6LoWPAN Capability Indication Option (6CIO). The
discovery and liveliness of the RPL root are obtained through RPL discovery and liveliness of the RPL root are obtained through RPL
[RFC6550] itself. [RFC6550] itself.
When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL root When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL root
functionalities are co-located in order that the address of the 6LBR functionalities are co-located in order that the address of the 6LBR
be indicated by RPL DIO messages and to associate the unique ID from be indicated by RPL DIO messages and to associate the unique ID from
the EDAR/EDAC [RFC8505] exchange with the state that is maintained by the EDAR/EDAC [RFC8505] exchange with the state that is maintained by
RPL. RPL.
Section 5 of [I-D.thubert-roll-unaware-leaves] details how the DAO Section 5 of [I-D.ietf-roll-unaware-leaves] details how the DAO
messages are used to reconfirm the registration, thus eliminating a messages are used to reconfirm the registration, thus eliminating a
duplication of functionality between DAO and EDAR/EDAC messages. duplication of functionality between DAO and EDAR/EDAC messages.
Even though the root of the RPL network is integrated with the 6LBR, Even though the root of the RPL network is integrated with the 6LBR,
it is logically separated from the Backbone Router (6BBR) that is it is logically separated from the Backbone Router (6BBR) that is
used to connect the 6TiSCH LLN to the backbone. This way, the root used to connect the 6TiSCH LLN to the backbone. This way, the root
has all information from 6LoWPAN ND and RPL about the LLN devices has all information from 6LoWPAN ND and RPL about the LLN devices
attached to it. attached to it.
This architecture also expects that the root of the RPL network This architecture also expects that the root of the RPL network
skipping to change at page 23, line 28 skipping to change at page 24, line 4
'zero-touch' extension of the Minimal Security Framework for 6TiSCH. 'zero-touch' extension of the Minimal Security Framework for 6TiSCH.
Zero touch [I-D.ietf-6tisch-dtsecurity-zerotouch-join] extension Zero touch [I-D.ietf-6tisch-dtsecurity-zerotouch-join] extension
leverages the 'Bootstrapping Remote Secure Key Infrastructures leverages the 'Bootstrapping Remote Secure Key Infrastructures
(BRSKI)' [[I-D.ietf-anima-bootstrapping-keyinfra] work to establish a (BRSKI)' [[I-D.ietf-anima-bootstrapping-keyinfra] work to establish a
shared secret between a pledge and the JRC without necessarily having shared secret between a pledge and the JRC without necessarily having
them belong to a common (security) domain at join time. This happens them belong to a common (security) domain at join time. This happens
through inter-domain communication occurring between the JRC of the through inter-domain communication occurring between the JRC of the
network and the domain of the pledge, represented by a fourth entity, network and the domain of the pledge, represented by a fourth entity,
Manufacturer Authorized Signing Authority (MASA). Once the zero- Manufacturer Authorized Signing Authority (MASA). Once the zero-
touch exchange completes, the CoJP exchange defined in touch exchange completes, the CoJP exchange defined in
[I-D.ietf-6tisch-minimal-security] is carried over the secure session [I-D.ietf-6tisch-minimal-security] is carried over the secure session
established between the pledge and the JRC. established between the pledge and the JRC.
Figure 5 depicts the join process. Figure 5 depicts the join process.
6LoWPAN Node 6LR 6LBR Join Registrar MASA 6LoWPAN Node 6LR 6LBR Join Registrar MASA
(pledge) (Join Proxy) (root) /Coordinator (JRC) (pledge) (Join Proxy) (root) /Coordinator (JRC)
| | | | | | | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network | | 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network |
| LLN link |Route-Over mesh|(the Internet)|(the Internet)| | LLN link |Route-Over mesh|(the Internet)|(the Internet)|
| | | | | | | | | |
| Layer-2 | | | | | Layer-2 | | | |
|enhanced beacon| | | | |enhanced beacon| | | |
|<--------------| | | | |<--------------| | | |
| | | | | | | | | |
| NS (EARO) | | | | | NS (EARO) | | | |
| (for the LL @)| | | | | (for the LL @)| | | |
skipping to change at page 29, line 19 skipping to change at page 29, line 26
Minimal 6TiSCH Configuration [RFC8180] to support RPL over a static Minimal 6TiSCH Configuration [RFC8180] to support RPL over a static
schedule, may leverage, for its internal computation, the information schedule, may leverage, for its internal computation, the information
maintained by 6top. maintained by 6top.
An OF may require metrics about reachability, such as the ETX. 6top An OF may require metrics about reachability, such as the ETX. 6top
creates and maintains an abstract neighbor table, and this state may creates and maintains an abstract neighbor table, and this state may
be leveraged to feed an OF and/or store OF information as well. A be leveraged to feed an OF and/or store OF information as well. A
neighbor table entry may contain a set of statistics with respect to neighbor table entry may contain a set of statistics with respect to
that specific neighbor. that specific neighbor.
The neighbor infoirmation may include the time when the last packet The neighbor information may include the time when the last packet
has been received from that neighbor, a set of cell quality metrics has been received from that neighbor, a set of cell quality metrics
(e.g. RSSI or LQI), the number of packets sent to the neighbor or (e.g. RSSI or LQI), the number of packets sent to the neighbor or
the number of packets received from it. This information can be made the number of packets received from it. This information can be made
available through 6top management APIs and used for instance to available through 6top management APIs and used for instance to
compute a Rank Increment that will determine the selection of the compute a Rank Increment that will determine the selection of the
preferred parent. preferred parent.
6top provides statistics about the underlying layer so the OF can be 6top provides statistics about the underlying layer so the OF can be
tuned to the nature of the TSCH MAC layer. 6top also enables the RPL tuned to the nature of the TSCH MAC layer. 6top also enables the RPL
OF to influence the MAC behaviour, for instance by configuring the OF to influence the MAC behaviour, for instance by configuring the
skipping to change at page 29, line 48 skipping to change at page 30, line 9
configuring TSCH to provide a broadcast channel, as opposed to, for configuring TSCH to provide a broadcast channel, as opposed to, for
instance, piggybacking the DIO messages in Layer-2 Enhanced Beacons instance, piggybacking the DIO messages in Layer-2 Enhanced Beacons
(EBs), which would produce undue timer coupling among layers, packet (EBs), which would produce undue timer coupling among layers, packet
size issues and could conflict with the policy of production networks size issues and could conflict with the policy of production networks
where EBs are mostly eliminated to conserve energy. where EBs are mostly eliminated to conserve energy.
4.3.4. Network Synchronization 4.3.4. Network Synchronization
Nodes in a TSCH network must be time synchronized. A node keeps Nodes in a TSCH network must be time synchronized. A node keeps
synchronized to its time source neighbor through a combination of synchronized to its time source neighbor through a combination of
frame-based and acknowledgment-based synchronization. In order to frame-based and acknowledgment-based synchronization. To maximize
maximize battery life and network throughput, it is advisable that battery life and network throughput, it is advisable that RPL ICMP
RPL ICMP discovery and maintenance traffic (governed by the trickle discovery and maintenance traffic (governed by the trickle timer) be
timer) be somehow coordinated with the transmission of time somehow coordinated with the transmission of time synchronization
synchronization packets (especially with enhanced beacons). packets (especially with enhanced beacons).
This could be achieved through an interaction of the 6top sublayer This could be achieved through an interaction of the 6top sublayer
and the RPL objective Function, or could be controlled by a and the RPL objective Function, or could be controlled by a
management entity. management entity.
Time distribution requires a loop-free structure. Nodes taken in a Time distribution requires a loop-free structure. Nodes taken in a
synchronization loop will rapidly desynchronize from the network and synchronization loop will rapidly desynchronize from the network and
become isolated. It is expected that a RPL DAG with a dedicated become isolated. It is expected that a RPL DAG with a dedicated
global Instance is deployed for the purpose of time synchronization. global Instance is deployed for the purpose of time synchronization.
That Instance is referred to as the Time Synchronization Global That Instance is referred to as the Time Synchronization Global
skipping to change at page 31, line 9 skipping to change at page 31, line 17
A node that reads a Join Priority of less than 0xFF should join the A node that reads a Join Priority of less than 0xFF should join the
neighbor with the lesser Join Priority and use it as time parent. If neighbor with the lesser Join Priority and use it as time parent. If
the node is configured to serve as time parent, then the node should the node is configured to serve as time parent, then the node should
join the TSGI, obtain a Rank in that Instance and start advertising join the TSGI, obtain a Rank in that Instance and start advertising
its own DagRank in the TSGI as its Join Priority in its EBs. its own DagRank in the TSGI as its Join Priority in its EBs.
4.3.5. SlotFrames and CDU matrix 4.3.5. SlotFrames and CDU matrix
6TiSCH enables IPv6 best effort (stochastic) transmissions over a MAC 6TiSCH enables IPv6 best effort (stochastic) transmissions over a MAC
layer that is also capable of scheduled (deterministic) layer that is also capable of scheduled (deterministic)
transmissions. In order to ensure that the medium is free of transmissions. A window of time is defined around the scheduled
contending packets when time comes for a scheduled transmission, a transmission where the medium must, as much as practically feasible,
window of time is defined around the scheduled transmission where the be free of contending energy to ensure that the medium is free of
medium must, as much as practically feasible, be free of contending contending packets when time comes for a scheduled transmission. One
energy. One simple way to obtain such a window is to format time and simple way to obtain such a window is to format time and frequencies
frequencies in cells of transmission of equal duration. This is the in cells of transmission of equal duration. This is the method that
method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long is adopted in IEEE Std 802.15.4 TSCH as well as the Long Term
Term Evolution (LTE) of cellular networks. Evolution (LTE) of cellular networks.
In order to describe that formatting of time and frequencies, the The 6TiSCH architecture defines a global concept that is called a
6TiSCH architecture defines a global concept that is called a Channel Channel Distribution and Usage (CDU) matrix to describe that
Distribution and Usage (CDU) matrix. formatting of time and frequencies,
A CDU matrix is defined centrally as part of the network definition. A CDU matrix is defined centrally as part of the network definition.
It is a matrix of cells with an height equal to the number of It is a matrix of cells with an height equal to the number of
available channels (indexed by ChannelOffsets) and a width (in available channels (indexed by ChannelOffsets) and a width (in
timeslots) that is the period of the network scheduling operation timeslots) that is the period of the network scheduling operation
(indexed by slotOffsets) for that CDU matrix. There are different (indexed by slotOffsets) for that CDU matrix. There are different
models for scheduling the usage of the cells, which place the models for scheduling the usage of the cells, which place the
responsibility of avoiding collisions either on a central controller responsibility of avoiding collisions either on a central controller
or on the devices themselves, at an extra cost in terms of energy to or on the devices themselves, at an extra cost in terms of energy to
scan for free cells (more in Section 4.5). scan for free cells (more in Section 4.5).
skipping to change at page 42, line 5 skipping to change at page 43, line 5
A data frame that is forwarded along a Track normally has a A data frame that is forwarded along a Track normally has a
destination MAC address that is set to broadcast - or a multicast destination MAC address that is set to broadcast - or a multicast
address depending on MAC support. This way, the MAC layer in the address depending on MAC support. This way, the MAC layer in the
intermediate nodes accepts the incoming frame and 6top switches it intermediate nodes accepts the incoming frame and 6top switches it
without incurring a change in the MAC header. In the case of IEEE without incurring a change in the MAC header. In the case of IEEE
Std 802.15.4, this means effectively broadcast, so that along the Std 802.15.4, this means effectively broadcast, so that along the
Track the short address for the destination of the frame is set to Track the short address for the destination of the frame is set to
0xFFFF. 0xFFFF.
There are 2 modes for a Track, transport mode and tunnel mode. There are 2 modes for a Track, native mode and tunnel mode.
4.7.1.1. Transport Mode 4.7.1.1. Native Mode
In transport mode, the Protocol Data Unit (PDU) is associated with In native mode, the Protocol Data Unit (PDU) is associated with flow-
flow-dependant meta-data that refers uniquely to the Track, so the dependent meta-data that refers uniquely to the Track, so the 6top
6top sublayer can place the frame in the appropriate cell without 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 may
transported in the Flow Label of the IPv6 header. Associated with be done using a 6-tuple as discussed in [I-D.ietf-detnet-ip]. In
the source IPv6 address, the Flow Label forms a globally unique particular, implementations of this document should support
identifier for that particular Track that is validated at egress identification of DetNet flows based on the IPv6 Flow Label field.
before restoring the destination MAC address (DMAC) and punting to The flow identification may also be done using a dedicated RPL
the upper layer. Instance (see section 3.1.3 of [RFC6550]), signaled in a RPL Packet
Information (more in section 11.2.2.1 of [RFC6550]). The flow
identification is validated at egress before restoring the
destination MAC address (DMAC) and punting to the upper layer.
Figure 12 illustrates the Track Forwarding operation which happens at Figure 12 illustrates the Track Forwarding operation which happens at
the 6top sublayer, below IP. the 6top sublayer, below IP.
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | | | IPv6 | | |
+--------------+ | | +--------------+ | |
| 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 | | | | dest | TSCH MAC | brdcst | | | | dest
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Ingress Relay Relay Egress Ingress Relay Relay Egress
Stack Layer Node Node Node Node Stack Layer Node Node Node Node
Figure 12: Track Forwarding, Transport Mode Figure 12: Track Forwarding, Native Mode
4.7.1.2. Tunnel Mode 4.7.1.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. In that mode, some entity (e.g. PCE) Backbone Router, respectively. In that mode, some entity (e.g. PCE)
can coordinate with a WirelessHART Network Manager or an ISA100.11a can coordinate with a WirelessHART Network Manager or an ISA100.11a
System Manager to specify the flows that are to be transported System Manager to specify the flows that are transported.
transparently over the Track.
+--------------+ +--------------+
| IPv6 | | IPv6 |
+--------------+ +--------------+
| 6LoWPAN HC | | 6LoWPAN HC |
+--------------+ set restore +--------------+ set restore
| 6top | +DMAC+ +DMAC+ | 6top | +DMAC+ +DMAC+
+--------------+ to|brdcst to|nexthop +--------------+ to|brdcst to|nexthop
| TSCH MAC | | | | | | TSCH MAC | | | | |
+--------------+ | | | | +--------------+ | | | |
skipping to change at page 44, line 5 skipping to change at page 45, line 5
4.7.1.3. Tunneling Information 4.7.1.3. Tunneling Information
Tunneling information coming with the Track configuration provides Tunneling information coming with the Track configuration provides
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. service access point for frame delivery at egress.
If the tunnel egress point does not have a MAC address that matches If the tunnel egress point does not have a MAC address that matches
the configuration, the Track installation fails. the configuration, the Track installation fails.
In transport mode, if the final Layer-3 destination is the tunnel If the final Layer-3 destination address is the same address as the
termination, then it is possible that the IPv6 address of the tunnel 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 that operation to the MAC address obtained from the tunnel
information. information.
skipping to change at page 44, line 43 skipping to change at page 45, line 43
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Router Router Node Stack Layer Node Router Router Node
Figure 14: IP Forwarding Figure 14: IP Forwarding
4.7.3. Fragment Forwarding 4.7.3. Fragment Forwarding
Considering that 6LoWPAN packets can be as large as 1280 bytes (the Considering that per section 4 of [RFC4944] 6LoWPAN packets can be as
IPv6 MTU), and that the non-storing mode of RPL implies Source large as 1280 bytes (the IPv6 minimum MTU), and that the non-storing
Routing that requires space for routing headers, and that a IEEE Std mode of RPL implies Source Routing that requires space for routing
802.15.4 frame with security may carry in the order of 80 bytes of headers, and that a IEEE Std 802.15.4 frame with security may carry
effective payload, an IPv6 packet might be fragmented into more than in the order of 80 bytes of effective payload, an IPv6 packet might
16 fragments at the 6LoWPAN sublayer. be fragmented into more than 16 fragments at the 6LoWPAN sublayer.
This level of fragmentation is much higher than that traditionally This level of fragmentation is much higher than that traditionally
experienced over the Internet with IPv4 fragments, where experienced over the Internet with IPv4 fragments, where
fragmentation is already known as harmful. fragmentation is already known as harmful.
In the case to a multihop route within a 6TiSCH network, Hop-by-Hop In the case to a multihop route within a 6TiSCH network, Hop-by-Hop
recomposition occurs at each hop in order to reform the packet and recomposition occurs at each hop to reform the packet and route it.
route it. This creates additional latency and forces intermediate This creates additional latency and forces intermediate nodes to
nodes to store a portion of a packet for an undetermined time, thus store a portion of a packet for an undetermined time, thus impacting
impacting critical resources such as memory and battery. critical resources such as memory and battery.
[I-D.ietf-6lo-minimal-fragment] describes a framework for forwarding [I-D.ietf-6lo-minimal-fragment] describes a framework for forwarding
fragments end-to-end across a 6TiSCH route-over mesh. Within that fragments end-to-end across a 6TiSCH route-over mesh. Within that
framework, [I-D.ietf-lwig-6lowpan-virtual-reassembly] details a framework, [I-D.ietf-lwig-6lowpan-virtual-reassembly] details a
virtual reassembly buffer mechanism whereby the datagram tag in the virtual reassembly buffer mechanism whereby the datagram tag in the
6LoWPAN Fragment is used as a label for switching at the 6LoWPAN 6LoWPAN Fragment is used as a label for switching at the 6LoWPAN
sublayer. Building on this technique, sublayer.
[I-D.ietf-6lo-fragment-recovery] introduces a new format for 6LoWPAN
fragments that enables the selective recovery of individual Building on this technique, [I-D.ietf-6lo-fragment-recovery]
fragments, and allows for a degree of flow control based on an introduces a new format for 6LoWPAN fragments that enables the
Explicit Congestion Notification. selective recovery of individual fragments, and allows for a degree
of flow control based on an Explicit Congestion Notification.
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | +----+ +----+ | | IPv6 | | +----+ +----+ |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6LoWPAN HC | | learn learn | | 6LoWPAN HC | | learn learn |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
skipping to change at page 49, line 34 skipping to change at page 50, line 34
| I | N/A | (0 OR 1) AND (2 OR 3) | | I | N/A | (0 OR 1) AND (2 OR 3) |
| A | (0 OR 1) | (2 OR 3 OR 4) | | A | (0 OR 1) | (2 OR 3 OR 4) |
| B | (2 OR 3) | (4 OR 5 OR 6) | | B | (2 OR 3) | (4 OR 5 OR 6) |
| C | (2 OR 3 OR 4) | (5 OR 6) | | C | (2 OR 3 OR 4) | (5 OR 6) |
| D | (4 OR 5 OR 6) | (7 OR 8) | | D | (4 OR 5 OR 6) | (7 OR 8) |
| E | (5 OR 6 OR 7 OR 8) | N/A | | E | (5 OR 6 OR 7 OR 8) | N/A |
+------+---------------------+------------------------+ +------+---------------------+------------------------+
4.8.3. Differentiated Services Per-Hop-Behavior 4.8.3. Differentiated Services Per-Hop-Behavior
Additionally, an IP packet that is sent along a Track uses the A future document could define a PHB for Deterministic Flows, to be
Differentiated Services Per-Hop-Behavior Group called Deterministic indicated in the IANA registry where IETF-defined PHBs are listed.
Forwarding, as described in
[I-D.svshah-tsvwg-deterministic-forwarding].
5. IANA Considerations 5. IANA Considerations
This specification does not require IANA action. This specification does not require IANA action.
6. Security Considerations 6. Security Considerations
This architecture operates on IEEE Std 802.15.4 and expects Link- This architecture operates on IEEE Std 802.15.4 and expects Link-
Layer security to be enabled at all times between connected devices, Layer security to be enabled at all times between connected devices,
except for the very first step of the device join process, where a except for the very first step of the device join process, where a
skipping to change at page 50, line 17 skipping to change at page 51, line 15
As detailed in Section 4.2.1, a pledge that wishes to join the 6TiSCH As detailed in Section 4.2.1, a pledge that wishes to join the 6TiSCH
network must use a join protocol to obtain its security keys. The network must use a join protocol to obtain its security keys. The
join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP). join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP).
In the minimal setting defined in [I-D.ietf-6tisch-minimal-security], In the minimal setting defined in [I-D.ietf-6tisch-minimal-security],
the authentication requires a pre-shared key, based on which a secure the authentication requires a pre-shared key, based on which a secure
session is derived. The CoJP exchange may also be preceded with a session is derived. The CoJP exchange may also be preceded with a
zero-touch handshake [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in zero-touch handshake [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in
order to enable pledge joining based on certificates and/or inter- order to enable pledge joining based on certificates and/or inter-
domain communication. domain communication.
In order to join, the pledge is helped by a Join Proxy (JP) that For the join procedure, the pledge is helped by a Join Proxy (JP)
relays the link-scope Join Request over the IP network to the Join that relays the link-scope Join Request over the IP network to the
Registrar/Coordinator (JRC) that can authenticate the pledge and Join Registrar/Coordinator (JRC) that can authenticate the pledge and
validate that it is attached to the appropriate network. As a result validate that it is attached to the appropriate network. As a result
of this exchange the pledge is in possession of a Link-Layer material of this exchange the pledge is in possession of a Link-Layer material
including a key and a short address, and all traffic is secured at including a key and a short address, and all traffic is secured at
the Link-Layer. the Link-Layer.
7. Acknowledgments 7. Acknowledgments
7.1. Contributors 7.1. Contributors
The co-authors of this document are listed below: The co-authors of this document are listed below:
skipping to change at page 51, line 30 skipping to change at page 52, line 27
security work, to Yasuyuki Tanaka for his work on implementation and security work, to Yasuyuki Tanaka for his work on implementation and
simulation that tremendously helped build a robust system, to Diego simulation that tremendously helped build a robust system, to Diego
Dujovne for starting and leading the SF0 effort and to Tengfei Chang Dujovne for starting and leading the SF0 effort and to Tengfei Chang
for evolving it in the MSF. for evolving it in the MSF.
Special thanks also to Pat Kinney for his support in maintaining the Special thanks also to Pat Kinney for his support in maintaining the
connection active and the design in line with work happening at IEEE connection active and the design in line with work happening at IEEE
Std 802.15.4. Std 802.15.4.
Special thanks to Ted Lemon who was the INT Area A-D while this Special thanks to Ted Lemon who was the INT Area A-D while this
specification was developed for his great support and help specification was initiated for his great support and help
throughout. throughout, and to Suresh Krishnan who took over with that kind
efficiency of his till publication.
Also special thanks to Ralph Droms who performed the first INT Area Also special thanks to Ralph Droms who performed the first INT Area
Directorate review, that was very deep and through and radically Directorate review, that was very deep and through and radically
changed the orientations of this document. changed the orientations of this document, and then to Eliot Lear and
Carlos Pignataro who help finalize this document in preparation to
the IESG reviews, and to Gorry Fairhurst who contributed to the final
shaping of this document through the IESG review procedure.
7.3. And Do not Forget 7.3. And Do not Forget
This specification is the result of multiple interactions, in This specification is the result of multiple interactions, in
particular during the 6TiSCH (bi)Weekly Interim call, relayed through particular during the 6TiSCH (bi)Weekly Interim call, relayed through
the 6TiSCH mailing list at the IETF. the 6TiSCH mailing list at the IETF.
The authors wish to thank: Alaeddine Weslati, Chonggang Wang, The authors wish to thank in arbitrary order: Alaeddine Weslati,
Georgios Exarchakos, Zhuo Chen, Alfredo Grieco, Bert Greevenbosch, Chonggang Wang, Georgios Exarchakos, Zhuo Chen, Georgios
Cedric Adjih, Deji Chen, Martin Turon, Dominique Barthel, Elvis Papadopoulos, Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Deji
Vogli, Geraldine Texier, Malisa Vucinic, Guillaume Gaillard, Herman Chen, Martin Turon, Dominique Barthel, Elvis Vogli, Geraldine Texier,
Storey, Kazushi Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Malisa Vucinic, Guillaume Gaillard, Herman Storey, Kazushi Muraoka,
Toutain, Maik Seewald, Maria Rita Palattella, Michael Behringer, Ken Bannister, Kuor Hsin Chang, Laurent Toutain, Maik Seewald, Maria
Nancy Cam Winget, Nicola Accettura, Nicolas Montavont, Oleg Hahm, Rita Palattella, Michael Behringer, Nancy Cam Winget, Nicola
Patrick Wetterwald, Paul Duffy, Peter van der Stock, Rahul Sen, Accettura, Nicolas Montavont, Oleg Hahm, Patrick Wetterwald, Paul
Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin-Lopez, Duffy, Peter van der Stock, Rahul Sen, Pieter de Mil, Pouria Zand,
Raghuram Sudhaakar, Sedat Gormus, Shitanshu Shah, Steve Simlo, Rouhollah Nabati, Rafa Marin-Lopez, Raghuram Sudhaakar, Sedat Gormus,
Tengfei Chang, Tina Tsou, Tom Phinney, Xavier Lagrange, Ines Robles Shitanshu Shah, Steve Simlo, Tengfei Chang, Tina Tsou, Tom Phinney,
and Samita Chakrabarti for their participation and various Xavier Lagrange, Ines Robles and Samita Chakrabarti for their
contributions. participation and various contributions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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-11 (work in progress), February 2019. detnet-architecture-13 (work in progress), May 2019.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
skipping to change at page 54, line 13 skipping to change at page 55, line 18
<https://www.rfc-editor.org/info/rfc8480>. <https://www.rfc-editor.org/info/rfc8480>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
8.2. Informative References 8.2. Informative References
[AMI] US Department of Energy, "Advanced Metering Infrastructure
and Customer Systems", 2006,
<https://www.energy.gov/sites/prod/files/2016/12/f34/
AMI%20Summary%20Report_09-26-16.pdf>.
[ANIMA] IETF, "Autonomic Networking Integrated Model and [ANIMA] IETF, "Autonomic Networking Integrated Model and
Approach", Approach",
<https://dataTracker.ietf.org/doc/charter-ietf-anima/>. <https://dataTracker.ietf.org/doc/charter-ietf-anima/>.
[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/>.
[HART] www.hartcomm.org, "Highway Addressable remote Transducer, [HART] www.hartcomm.org, "Highway Addressable remote Transducer,
a group of specifications for industrial process and a group of specifications for industrial process and
control devices administered by the HART Foundation". control devices administered by the HART Foundation".
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", draft-ietf-6lo-ap-nd-11 (work in Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in
progress), February 2019. progress), April 2019.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
Backbone Router", draft-ietf-6lo-backbone-router-11 (work Backbone Router", draft-ietf-6lo-backbone-router-11 (work
in progress), February 2019. in progress), February 2019.
[I-D.ietf-6lo-fragment-recovery] [I-D.ietf-6lo-fragment-recovery]
Thubert, P., "6LoWPAN Selective Fragment Recovery", draft- Thubert, P., "6LoWPAN Selective Fragment Recovery", draft-
ietf-6lo-fragment-recovery-02 (work in progress), January ietf-6lo-fragment-recovery-04 (work in progress), June
2019. 2019.
[I-D.ietf-6lo-minimal-fragment] [I-D.ietf-6lo-minimal-fragment]
Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal
Fragment Forwarding", draft-ietf-6lo-minimal-fragment-00 Fragment Forwarding", draft-ietf-6lo-minimal-fragment-01
(work in progress), October 2018. (work in progress), March 2019.
[I-D.ietf-6tisch-dtsecurity-zerotouch-join] [I-D.ietf-6tisch-dtsecurity-zerotouch-join]
Richardson, M., "6tisch Zero-Touch Secure Join protocol", Richardson, M., "6tisch Zero-Touch Secure Join protocol",
draft-ietf-6tisch-dtsecurity-zerotouch-join-03 (work in draft-ietf-6tisch-dtsecurity-zerotouch-join-03 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Minimal Security Framework for 6TiSCH", draft-ietf- "Minimal Security Framework for 6TiSCH", draft-ietf-
6tisch-minimal-security-09 (work in progress), November 6tisch-minimal-security-11 (work in progress), June 2019.
2018.
[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-01 (work in progress), October 2018. draft-ietf-6tisch-msf-03 (work in progress), April 2019.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-18 (work in progress), January 2019. keyinfra-22 (work in progress), June 2019.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), August 2018. progress), March 2019.
[I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
draft-ietf-detnet-ip-00 (work in progress), May 2019.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-20 (work in progress), December ietf-detnet-use-cases-20 (work in progress), December
2018. 2018.
[I-D.ietf-lwig-6lowpan-virtual-reassembly] [I-D.ietf-lwig-6lowpan-virtual-reassembly]
Bormann, C. and T. Watteyne, "Virtual reassembly buffers Bormann, C. and T. Watteyne, "Virtual reassembly buffers
in 6LoWPAN", draft-ietf-lwig-6lowpan-virtual-reassembly-00 in 6LoWPAN", draft-ietf-lwig-6lowpan-virtual-reassembly-01
(work in progress), July 2018. (work in progress), March 2019.
[I-D.ietf-manet-aodvv2] [I-D.ietf-manet-aodvv2]
Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and
V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2
(AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-roll-aodv-rpl] [I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B.
Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (LLNs)", draft-ietf-roll-aodv-rpl-05 (work in Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in
progress), October 2018. progress), April 2019.
[I-D.ietf-roll-dao-projection]
Thubert, P., Jadhav, R., Gillmore, M., and J. Pylakutty,
"Root initiated routing state in RPL", draft-ietf-roll-
dao-projection-06 (work in progress), May 2019.
[I-D.ietf-roll-rpl-industrial-applicability] [I-D.ietf-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-ietf-roll- applicability in industrial networks", draft-ietf-roll-
rpl-industrial-applicability-02 (work in progress), rpl-industrial-applicability-02 (work in progress),
October 2013. October 2013.
[I-D.ietf-roll-unaware-leaves]
Thubert, P., "Routing for RPL Leaves", draft-ietf-roll-
unaware-leaves-00 (work in progress), May 2019.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPL Robles, I., Richardson, M., and P. Thubert, "Using RPL
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", draft-ietf- IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-24 (work in progress), January 2019. roll-useofrplinfo-29 (work in progress), May 2019.
[I-D.svshah-tsvwg-deterministic-forwarding] [I-D.rahul-roll-mop-ext]
Shah, S. and P. Thubert, "Deterministic Forwarding PHB", Jadhav, R. and P. Thubert, "RPL Mode of Operation
draft-svshah-tsvwg-deterministic-forwarding-04 (work in extension", draft-rahul-roll-mop-ext-01 (work in
progress), August 2015. progress), June 2019.
[I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-13 (work in progress), March 2019.
[I-D.svshah-tsvwg-lln-diffserv-recommendations] [I-D.svshah-tsvwg-lln-diffserv-recommendations]
Shah, S. and P. Thubert, "Differentiated Service Class Shah, S. and P. Thubert, "Differentiated Service Class
Recommendations for LLN Traffic", draft-svshah-tsvwg-lln- Recommendations for LLN Traffic", draft-svshah-tsvwg-lln-
diffserv-recommendations-04 (work in progress), February diffserv-recommendations-04 (work in progress), February
2015. 2015.
[I-D.thubert-6lo-bier-dispatch] [I-D.thubert-6lo-bier-dispatch]
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
skipping to change at page 56, line 44 skipping to change at page 58, line 21
Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery
Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work
in progress), January 2019. 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.
[I-D.thubert-roll-unaware-leaves] [I-D.thubert-raw-technologies]
Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- Thubert, P., Cavalcanti, D., and X. Vilajosana, "Reliable
unaware-leaves-06 (work in progress), November 2018. and Available Wireless Technologies", draft-thubert-raw-
technologies-01 (work in progress), June 2019.
[I-D.thubert-roll-bier]
Thubert, P., "RPL-BIER", draft-thubert-roll-bier-02 (work
in progress), July 2018.
[IEC62439] [IEC62439]
IEC, "Industrial communication networks - High IEC, "Industrial communication networks - High
availability automation networks - Part 3: Parallel availability automation networks - Part 3: Parallel
Redundancy Protocol (PRP) and High-availability Seamless Redundancy Protocol (PRP) and High-availability Seamless
Redundancy (HSR) - IEC62439-3", 2012, Redundancy (HSR) - IEC62439-3", 2012,
<https://webstore.iec.ch/publication/7018>. <https://webstore.iec.ch/publication/7018>.
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE Std. IEEE standard for Information Technology, "IEEE Std.
skipping to change at page 60, line 10 skipping to change at page 61, line 34
2017, <https://www.rfc-editor.org/info/rfc8137>. 2017, <https://www.rfc-editor.org/info/rfc8137>.
[TEAS] IETF, "Traffic Engineering Architecture and Signaling", [TEAS] IETF, "Traffic Engineering Architecture and Signaling",
<https://dataTracker.ietf.org/doc/charter-ietf-teas/>. <https://dataTracker.ietf.org/doc/charter-ietf-teas/>.
[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
- WirelessHART - IEC 62591", 2010. - WirelessHART - IEC 62591", 2010.
Appendix A. Dependencies on Work In Progress Appendix A. Related Work In Progress
In order to control the complexity and the size of the 6TiSCH work, To control the complexity and the size of the 6TiSCH work, the
the architecture and the associated IETF work are staged and the WG architecture and the associated IETF work are staged and the WG is
is expected to recharter multiple times. This document is been expected to recharter multiple times. This document is been
incremented as the work progressed following the evolution of the WG incremented as the work progressed following the evolution of the WG
charter and the availability of dependent work. The intent was to charter and the availability of dependent work. The intent was to
publish when the WG concludes on the covered items. publish when the WG concludes on the covered items.
At the time of publishing: At the time of publishing the following specification are still in
progress and may affect the stack in a 6TiSCH-aware node.
o The need of a reactive routing protocol to establish on-demand A.1. Chartered IETF work items
constraint-optimized routes and a reservation protocol to
establish Layer-3 Tracks is being discussed at 6TiSCH but not
chartered for.
o The operation of the Backbone Router The operation of the Backbone Router [I-D.ietf-6lo-backbone-router]
[I-D.ietf-6lo-backbone-router] is stable but the RFC is not is stable but the RFC is not published yet. The protection of
published yet. The protection of registered addresses against registered addresses against impersonation and take over will be
impersonation and take over will be guaranteed by Address guaranteed by Address Protected Neighbor Discovery for Low-power and
Protected Neighbor Discovery for Low-power and Lossy Networks Lossy Networks [I-D.ietf-6lo-ap-nd], which is not yet published
[I-D.ietf-6lo-ap-nd], which is not yet published either. either.
o The work on centralized Track computation is deferred to a New procedures have been defined at ROLL that extend RPL and may be
subsequent work, not necessarily at 6TiSCH. A Predicatable and of interest for a 6TiSCH stack. In particular
Available Wireless (PAW) bar-BoF took place; PAW may form as a WG [I-D.ietf-roll-unaware-leaves] enables a 6LN that implements only
and take over that work. The 6TiSCH Architecture should thus [RFC8505] and avoid the support of RPL.
inherit from the DetNet [I-D.ietf-detnet-architecture]
architecture and thus depends on it. The Path Computation Element
(PCE) should be a core component of that architecture. Around the
PCE, a protocol such as an extension to a TEAS [TEAS] protocol
will be required to expose the 6TiSCH node capabilities and the
network peers to the PCE, and a protocol such as a lightweight
PCEP or an adaptation of CCAMP [CCAMP] G-MPLS formats and
procedures will be used to publish the Tracks, as computed by the
PCE, to the 6TiSCH nodes.
o BIER-TE-based OAM, Replication and Elimination A.2. Unchartered IETF work items
[I-D.thubert-bier-replication-elimination] leverages Bit Index
Explicit Replication - Traffic Engineering to control in the data
plane the DetNet Replication and Elimination activities, and to
provide traceability on links where replication and loss happen,
in a manner that is abstract to the forwarding information,
whereas a 6loRH for BitStrings [I-D.thubert-6lo-bier-dispatch]
proposes a 6LoWPAN compression for the BIER Bitstring based on
6LoWPAN Routing Header [RFC8138].
o The security model and in particular the join process depends on A.2.1. 6TiSCH Zerotouch security
the ANIMA [ANIMA] Bootstrapping Remote Secure Key Infrastructures
(BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra] in order to enable
zero-touch security provisionning; for highly constrained nodes, a
minimal model based on pre-shared keys (PSK) is also available.
o The current charter positions 6TiSCH on IEEE Std 802.15.4 only. The security model and in particular the zerotouch join process
Though most of the design should be portable on other link types, [I-D.ietf-6tisch-dtsecurity-zerotouch-join] depends on the ANIMA
6TiSCH has a strong dependency on IEEE Std 802.15.4 and its [ANIMA] Bootstrapping Remote Secure Key Infrastructures (BRSKI)
evolution. The impact of changes to TSCH on this Architecture [I-D.ietf-anima-bootstrapping-keyinfra] to enable zero-touch security
should be minimal to non-existent, but deeper work such as 6top provisionning; for highly constrained nodes, a minimal model based on
and security may be impacted. A 6TiSCH Interest Group at the IEEE pre-shared keys (PSK) is also available. As written to this day, it
maintains the synchronization and helps foster work at the IEEE also depends on a nmuber of documents in progress as CORE, and on
should 6TiSCH demand it. "Ephemeral Diffie-Hellman Over COSE (EDHOC)"
[I-D.selander-ace-cose-ecdhe], which is facing significant opposition
at ACE.
o Work is being proposed at IEEE (802.15.12 PAR) for an LLC that A.2.2. 6TiSCH Track Setup
would logically include the 6top sublayer. The interaction with
the 6top sublayer and the Scheduling Functions described in this
document are yet to be defined.
o ISA100 [ISA100] Common Network Management (CNM) is another ROLL is now standardizing a reactive routing protocol based on RPL
external work of interest for 6TiSCH. The group, referred to as [I-D.ietf-roll-aodv-rpl] The need of a reactive routing protocol to
ISA100.20, defines a Common Network Management framework that establish on-demand constraint-optimized routes and a reservation
should enable the management of resources that are controlled by protocol to establish Layer-3 Tracks is being discussed at 6TiSCH but
heterogeneous protocols such as ISA100.11a [ISA100.11a], not chartered for.
WirelessHART [WirelessHART], and 6TiSCH. Interestingly, the
establishment of 6TiSCH Deterministic paths, called Tracks, are At the time of this writing, the formation of a new working group
also in scope, and ISA100.20 is working on requirements for called RAW for Reliable and Available Wireless networking is being
DetNet. considered. During the PAW BoF that took place on that matter, one
of the considered work items was to develop a generic specification
for Tracks that would cover 6TiSCH requirements as expressed in this
architecture.
ROLL is also standardizing an extension to RPL to setup centrally-
computed routes [I-D.ietf-roll-dao-projection] The work on
centralized Track computation is deferred to a subsequent work, not
necessarily at 6TiSCH. A Predicatable and Available Wireless (PAW)
bar-BoF took place; the formation of a new working group called RAW
for Reliable and Available Wireless networking is being considered.
RAW may form as a WG and develop a generic specification for Tracks
that would cover 6TiSCH requirements as expressed in this
architecture, more in [I-D.thubert-raw-technologies]
The 6TiSCH Architecture should thus inherit from the DetNet
[I-D.ietf-detnet-architecture] architecture and thus depends on it.
The Path Computation Element (PCE) should be a core component of that
architecture. An extension to RPL or to TEAS [TEAS] will be required
to expose the 6TiSCH node capabilities and the network peers to the
PCE, possibly in combination with [I-D.rahul-roll-mop-ext]. A
protocol such as a lightweight PCEP or an adaptation of CCAMP [CCAMP]
G-MPLS formats and procedures could be used in combination to
[I-D.ietf-roll-dao-projection] to install the Tracks, as computed by
the PCE, to the 6TiSCH nodes.
A.2.3. Using BIER in a 6TiSCH Network
ROLL is actively working on Bit Index Explicit Replication (BIER) as
a method to compress both the dataplane packets and the routing
tables in storing mode [I-D.thubert-roll-bier].
BIER could also be used in the context of the DetNet service layer.
BIER-TE-based OAM, Replication and Elimination
[I-D.thubert-bier-replication-elimination] leverages BIER Traffic
Engineering (TE) to control in the data plane the DetNet Replication
and Elimination activities, and to provide traceability on links
where replication and loss happen, in a manner that is abstract to
the forwarding information.
a 6loRH for BitStrings [I-D.thubert-6lo-bier-dispatch] proposes a
6LoWPAN compression for the BIER Bitstring based on 6LoWPAN Routing
Header [RFC8138].
A.3. External (non-IETF) work items
The current charter positions 6TiSCH on IEEE Std 802.15.4 only.
Though most of the design should be portable on other link types,
6TiSCH has a strong dependency on IEEE Std 802.15.4 and its
evolution. The impact of changes to TSCH on this Architecture should
be minimal to non-existent, but deeper work such as 6top and security
may be impacted. A 6TiSCH Interest Group at the IEEE maintains the
synchronization and helps foster work at the IEEE should 6TiSCH
demand it.
Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would
logically include the 6top sublayer. The interaction with the 6top
sublayer and the Scheduling Functions described in this document are
yet to be defined.
ISA100 [ISA100] Common Network Management (CNM) is another external
work of interest for 6TiSCH. The group, referred to as ISA100.20,
defines a Common Network Management framework that should enable the
management of resources that are controlled by heterogeneous
protocols such as ISA100.11a [ISA100.11a], WirelessHART
[WirelessHART], and 6TiSCH. Interestingly, the establishment of
6TiSCH Deterministic paths, called Tracks, are also in scope, and
ISA100.20 is working on requirements for DetNet.
Author's Address Author's Address
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
 End of changes. 78 change blocks. 
276 lines changed or deleted 369 lines changed or added

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