RFC 9030
An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)
Heyyy bestie ๐ Part 1 of RFC 9030 is here, and it's a whole vibe. This one is an Informational RFC from May 2021, written by P. Thubert, Ed. at Cisco Systems, and it's the architecture for running IPv6 over the 6TiSCH mode of IEEE 802.15.4 ๐ฆ. The title block has no Obsoletes or Updates entry, so this doc doesn't replace or change any earlier RFC โจ. It's ISSN 2070-1721, and you can find its status page at https://www.rfc-editor.org/info/rfc9030 ๐
.
Abstract
okay so the abstract is giving elevator pitch ๐. It describes a network architecture that gives you low latency, low jitter, and high reliability packet delivery ๐ญ. The trick is combining a high-speed powered backbone with subnetworks that use IEEE 802.15.4 time-slotted channel hopping (TSCH), so it can meet the needs of low-power wireless deterministic apps ๐ฅ.
Status of This Memo
bestie, this section is basically the fine print ๐. This document is not an Internet Standards Track specification. It's published for informational purposes only ๐ธ.
This document is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community โจ. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 if you want the deets ๐ง.
Information about the current status of this document, any errata, and how to give feedback on it is at https://www.rfc-editor.org/info/rfc9030 ๐.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved ๐.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document ๐. Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ๐
.
Table of Contents
1. Introduction
2. Terminology
2.1. New Terms
2.2. Abbreviations
2.3. Related Documents
3. High-Level Architecture
3.1. A Non-broadcast Multi-access Radio Mesh Network
3.2. A Multi-Link Subnet Model
3.3. TSCH: a Deterministic MAC Layer
3.4. Scheduling TSCH
3.5. Distributed vs. Centralized Routing
3.6. Forwarding over TSCH
3.7. 6TiSCH Stack
3.8. Communication Paradigms and Interaction Models
4. Architecture Components
4.1. 6LoWPAN (and RPL)
4.1.1. RPL-Unaware Leaves and 6LoWPAN ND
4.1.2. 6LBR and RPL Root
4.2. Network Access and Addressing
4.2.1. Join Process
4.2.2. Registration
4.3. TSCH and 6top
4.3.1. 6top
4.3.2. Scheduling Functions and the 6top Protocol
4.3.3. 6top and RPL Objective Function Operations
4.3.4. Network Synchronization
4.3.5. Slotframes and CDU Matrix
4.3.6. Distributing the Reservation of Cells
4.4. Schedule Management Mechanisms
4.4.1. Static Scheduling
4.4.2. Neighbor-to-Neighbor Scheduling
4.4.3. Remote Monitoring and Schedule Management
4.4.4. Hop-by-Hop Scheduling
4.5. On Tracks
4.5.1. General Behavior of Tracks
4.5.2. Serial Track
4.5.3. Complex Track with Replication and Elimination
4.5.4. DetNet End-to-End Path
4.5.5. Cell Reuse
4.6. Forwarding Models
4.6.1. Track Forwarding
4.6.2. IPv6 Forwarding
4.6.3. Fragment Forwarding
4.7. Advanced 6TiSCH Routing
4.7.1. Packet Marking and Handling
4.7.2. Replication, Retries, and Elimination
5. IANA Considerations
6. Security Considerations
6.1. Availability of Remote Services
6.2. Selective Jamming
6.3. MAC-Layer Security
6.4. Time Synchronization
6.5. Validating ASN
6.6. Network Keying and Rekeying
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Related Work in Progress
A.1. Unchartered IETF Work Items
A.1.1. 6TiSCH Zero-Touch Security
A.1.2. 6TiSCH Track Setup
A.1.3. Using BIER in a 6TiSCH Network
A.2. External (Non-IETF) Work Items
Acknowledgments
Contributors
Author's Address1. Introduction
Wireless networks are everything ๐ฆ. They let all kinds of devices, of any size, get interconnected, usually at a super low cost per device and at any range. They're especially useful where wiring is impractical, like on fast-moving or rotating devices ๐.
On the other hand, Deterministic Networking maximizes the packet delivery ratio within a bounded latency, so mission-critical machine-to-machine (M2M) operations can actually work ๐. The applications that need these networks are covered in [RFC8578], and [RAW-USE-CASES] has a bunch more use cases for Reliable and Available Wireless networks (RAW) โจ. The use cases include professional media, Industrial Automation and Control Systems (IACS), building automation, in-vehicle command and control, commercial automation and asset tracking with mobile scenarios, gaming, drones and edge robotic control, and home automation ๐.
The Time-Slotted Channel Hopping (TSCH) [RFC7554] mode of the IEEE Std 802.15.4 [IEEE802154] Medium Access Control (MAC) layer was introduced with the IEEE Std 802.15.4e [IEEE802154e] amendment, and it's now retrofitted into the main standard ๐ง. For all practical purposes, this document is expected to be insensitive to revisions of that standard, which is why it's referenced without a date ๐ซถ. TSCH is both a Time-Division Multiplexing (TDM) and a Frequency-Division Multiplexing (FDM) technique, so a different channel can be used for each transmission ๐ฅ. It lets you schedule transmissions for deterministic operations, and it's aimed at the slower and most energy-constrained wireless use cases ๐ธ.
The scheduled operation gives you a more reliable experience, which can be used to monitor and manage resources (energy and water, for example) in a more efficient way ๐.
Proven deterministic networking standards for process control, including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART], have shown what the IEEE Std 802.15.4 TSCH MAC can do: high reliability against interference, low power consumption on well-known flows, and applicability for Traffic Engineering (TE) from a central controller ๐.
To get information technology (IT) and operational technology (OT) converging in Low-Power and Lossy Networks (LLNs), the 6TiSCH architecture supports an IETF suite of protocols over the IEEE Std 802.15.4 TSCH MAC. That gives IP connectivity to energy and otherwise constrained wireless devices ๐.
The 6TiSCH architecture relies on IPv6 [RFC8200] and on routing to provide large scaling capabilities. Adding a high-speed federating backbone adds yet another degree of scalability to the design ๐ญ. The backbone is typically a Layer 2 transit link, such as an Ethernet bridged network, but it can also be a more complex routed structure ๐ .
The 6TiSCH architecture introduces an IPv6 multi-link subnet model. It's made of a federating backbone plus a number of IEEE Std 802.15.4 TSCH low-power wireless networks, which are federated and synchronized by Backbone Routers ๐ฆ. If the backbone is a Layer 2 transit link, the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6 ND) proxy [RFC4861] โจ.
The 6TiSCH architecture uses 6LoWPAN [RFC4944] to adapt IPv6 to the constrained media, and it uses the Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] for distributed routing operations ๐.
Centralized routing is a model where routes are computed and resources are allocated from a central controller. This is especially helpful for scheduling deterministic multihop transmissions ๐. Distributed routing, on the other hand, is a model that relies on concurrent peer-to-peer protocol exchanges for TSCH resource allocation and routing operations ๐ซถ.
The architecture defines mechanisms to establish and maintain routing and scheduling in a centralized, distributed, or mixed fashion, for use in multiple OT environments ๐. It's especially applicable to highly scalable solutions, like those in Advanced Metering Infrastructure [AMI] solutions that use distributed routing to enable multipath forwarding over large LLN meshes ๐.
2. Terminology
2.1. New Terms
Okay, so terminology is where people get confused ๐. The document doesn't reuse terms from the IEEE Std 802.15.4 [IEEE802154] standard, such as "path" or "link", because those mean something quite different from classical IETF parlance ๐ .
This document adds the following terms ๐ง:
6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4): 6TiSCH defines an adaptation sublayer for IPv6 over TSCH called 6top. It also defines a set of protocols for setting up a TSCH schedule in a distributed approach, plus a security solution. 6TiSCH may be extended in the future for other MAC/Physical Layer (PHY) pairs that provide a service similar to TSCH ๐ฆ.
6top (6TiSCH Operation Sublayer): The next higher layer above the IEEE Std 802.15.4 TSCH MAC layer. 6top provides the abstraction of an IP link over a TSCH MAC, schedules packets over TSCH cells, and exposes a management interface for scheduling TSCH cells ๐ธ.
6P (6top Protocol): The protocol defined in [RFC8480]. 6P lets Layer 2 peers allocate, move, or de-allocate cells in their respective schedules so they can communicate. 6P operates at the 6top sublayer ๐.
6P transaction: A 2-way or 3-way sequence of 6P messages that Layer 2 peers use to modify their communication schedule โจ.
ASN (Absolute Slot Number): Defined in [IEEE802154]. The ASN is the total number of timeslots that have elapsed since the Epoch time when the TSCH network started. It's incremented by one at each timeslot, and it's wide enough to not roll over in practice ๐.
bundle: A group of equivalent scheduled cells, meaning cells identified by different slotOffset/channelOffset values, which are scheduled for the same purpose, with the same neighbor, with the same flags, and in the same slotframe ๐ซถ. The size of the bundle is the number of cells it contains. For a given slotframe length, the size of the bundle translates directly into bandwidth ๐. A bundle is a local abstraction that represents a half-duplex link for either sending or receiving, and its bandwidth amounts to the sum of the cells in the bundle ๐.
Layer 2 vs. Layer 3 bundle: Bundles are associated with either Layer 2 (switching) or Layer 3 (routing) forwarding operations. A pair of Layer 3 bundles (one for each direction) maps to an IP link with a neighbor. A set of Layer 2 bundles (of an "arbitrary" cardinality and direction) corresponds to the relation of one or more incoming bundles from the previous-hop neighbor(s) with one or more outgoing bundles to the next-hop neighbor(s) along a Track, as part of the switching role. That relation may include replication and elimination ๐.
CCA (Clear Channel Assessment): A mechanism defined in [IEEE802154] where nodes listen to the channel before sending, to detect ongoing transmissions from other parties. Because the network is synchronized, CCA can't be used to detect colliding transmissions within the same network, but it can be used to detect other radio networks in the vicinity ๐ฆ.
cell ๐ง: A unit of transmission resource in the CDU matrix. A cell is identified by a slotOffset and a channelOffset, and it can be scheduled or unscheduled. Cute, right? ๐
Channel Distribution/Usage (CDU) matrix: : A matrix of cells (i,j) that shows how the spectrum (channels) gets split up between the different nodes in the 6TiSCH network. Its width in timeslots equals the period of the network scheduling operation, and its height equals the number of available channels. Every cell (i,j) in the CDU, found by its slotOffset/channelOffset, belongs to one specific chunk. ๐โจ
channelOffset ๐ฆ: Identifies a row in the TSCH schedule. The number of channelOffset values is capped by the number of available frequencies. A function turns the channelOffset into an actual frequency, and that function depends on the absolute time when the communication happens. That's how you get channel hopping! ๐
chunk ๐ฐ: A well-known list of cells, spread out across time and frequency inside a CDU matrix. Each chunk is a slice of the CDU matrix. Every node in the network knows how the CDU matrix is partitioned into chunks, which is what makes the appropriation process work. Appropriation is basically a negotiation between nodes inside an interference domain. A node that successfully appropriates a chunk gets to decide which transmissions use the cells in that chunk within its interference domain. So a parent node decides when the cells in its appropriated chunk get used and which of its children gets to use them. Main character decisions only ๐๐
CoJP (Constrained Join Protocol) ๐: The Constrained Join Protocol (CoJP) lets a pledge securely join a 6TiSCH network and grab the network parameters over a secure channel. "Constrained Join Protocol (CoJP) for 6TiSCH" [RFC9031] defines the minimal CoJP setup, where pre-shared keys are defined. In that mode, CoJP can work with a single round-trip exchange. Efficient and iconic ๐ซถ
dedicated cell ๐: A cell reserved for a given node so it can transmit to one specific neighbor. Its very own lane, no sharing ๐
deterministic network โฐ: The generic idea of a deterministic network is defined in the "Deterministic Networking Architecture" [RFC8655] document. When it's applied to 6TiSCH, it means reserving Tracks. That reservation guarantees an end-to-end latency and optimizes the Packet Delivery Ratio (PDR) for well-characterized flows. Predictable and reliable, which is honestly the goal ๐
distributed cell reservation ๐งฉ: A reservation of a cell that's done by one or more in-network entities. ๐ธ๏ธ
distributed Track reservation ๐ค๏ธ: A reservation of a Track that's done by one or more in-network entities. ๐ธ๏ธ
EB (Enhanced Beacon) ๐ฃ: A special frame defined in [IEEE802154]. A node uses it to announce that the network exists, and that includes the Join Proxy (JP). It carries enough information for a pledge to synchronize to the network. Little announcement, big job ๐บ
hard cell ๐ชจ: A scheduled cell that the 6top sublayer may not relocate. It's stuck in its spot, bestie ๐ค
hopping sequence ๐ถ: An ordered sequence of frequencies, identified by a Hopping_Sequence_ID. It's used for channel hopping when the channelOffset value gets translated into a frequency. The rhythm of the whole thing ๐
IE (Information Element) ๐ฆ: Type-Length-Value containers placed at the end of the MAC header. They're used to pass data between layers or devices. Some IE identifiers are managed by the IEEE [IEEE802154], and some are managed by the IETF [RFC8137]. [RFC9032] uses one subtype to support the selection of the Join Proxy. Tiny boxes, huge energy ๐ฌ
join process ๐ช: The whole overall process. It includes the pledge(s) discovering the network and then running the join protocol. Start to finish, the full glow-up ๐ฆ
join protocol ๐ค: The protocol that lets the pledge join the network. It covers authentication, authorization, and parameter distribution, and it's executed between the pledge and the JRC. The official handshake ๐
joined node ๐: The new device once it's finished the join process. People often just call it a node. Congrats, you made it in! ๐ฅณ
JP (Join Proxy) ๐: A node that's already part of the 6TiSCH network and acts as a relay, giving the pledge connectivity to the JRC. The JP announces that the network exists by regularly sending EB frames. Literally the bridge of the whole operation ๐โจ
JRC (Join Registrar/Coordinator) ๐: The central entity responsible for the authentication, authorization, and configuration of the pledge. The queen who runs the whole join scene ๐ธ
link ๐: A communication facility or medium that nodes can use to talk at the link layer, which is the layer right below IP. In 6TiSCH, this concept is implemented as a collection of Layer 3 bundles. Note: the IETF parlance for "link" is the one adopted here, as opposed to the IEEE Std 802.15.4 terminology. Terminology drama, but make it consistent ๐
operational technology ๐ญ: OT refers to technology used in automation, for example in industrial control networks. The convergence of IT and OT is the main focus of the Industrial Internet of Things (IIOT). Factories getting that internet glow-up ๐ค
pledge ๐ฅบ: A new device that's trying to join a 6TiSCH network. Hoping to get in, no cap ๐
(to) relocate a cell ๐: The action the 6top sublayer takes when it changes the slotOffset and/or channelOffset of a soft cell. Moving day for the cell ๐ฆ
(to) schedule a cell ๐ : The action of turning an unscheduled cell into a scheduled cell. Basically putting it on the calendar โจ
scheduled cell ๐๏ธ: A cell that's assigned a neighbor MAC address (a broadcast address is also possible) and one or more of these flags: TX, RX, Shared, and Timekeeping. The IEEE Std 802.15.4 TSCH implementation can use a scheduled cell to communicate. A scheduled cell can be either a hard or a soft cell. Booked and busy ๐
SF (6top Scheduling Function) ๐ง : The cell management entity that adds or deletes cells dynamically, based on application networking requirements. Cell negotiation with a neighbor is done using 6P. The brain of the cell situation ๐ง ๐
SFID (6top Scheduling Function Identifier) ๐ชช: A 4-bit field that identifies an SF. Tiny ID card, big identity ๐ชช
shared cell ๐ซฑ๐ซฒ: A cell marked with both the TX and Shared flags. More than one transmitter node can use this cell. A back-off algorithm is used to resolve contention. Sharing is caring, but also there's a referee ๐ฅ
slotframe ๐: A collection of timeslots that repeats over time. It's analogous to a superframe, since both define periods of communication opportunities. A slotframe is characterized by a slotframe_ID and a slotframe_size. Multiple slotframes can coexist in a node's schedule, so a node can have several activities scheduled in different slotframes based on the priority of its packets/traffic flows. The timeslots in the slotframe are indexed by the slotOffset, and the first timeslot is at slotOffset 0. Multitasking queen ๐
slotOffset ๐: A column in the TSCH schedule. It's the number of timeslots since the beginning of the current iteration of the slotframe. Counting those timeslots like a pro ๐ข
soft cell ๐ง: A scheduled cell that the 6top sublayer can relocate. Flexible, soft, and easily moved ๐ท
time source neighbor โฑ๏ธ: A neighbor that a node uses as its time reference, and whose clock it needs to keep itself synchronized to. Main time-keeping bestie โฐ๐
timeslot ๐๏ธ: The basic communication unit in TSCH. It lets a transmitter node send a frame to a receiver neighbor, and it lets the receiver neighbor optionally send back an acknowledgment. One tiny slot, one whole conversation ๐ฌ
Track ๐ฃ๏ธ: A Track is a Directed Acyclic Graph (DAG) that's used as a complex multihop path to the destination(s) of the path. For unicast traffic, the Track is a Destination-Oriented DAG (DODAG), where the Root of the DODAG is the destination of the unicast traffic. A Track enables replication, elimination, and reordering functions along the way (you can find more on those in [RFC8655]). A Track reservation locks physical resources such as cells and buffers in every node along the DODAG. Each Track is associated with an owner, which can be, for instance, the destination of the Track. Main character road, very dramatic ๐
TrackID ๐ช: A TrackID is either globally unique or locally unique to the Track owner. If it's only locally unique, the identification of the owner must be provided together with the TrackID to give a full reference to the Track. Typically the Track owner is the ingress of the Track. The IPv6 source address of packets along the Track can be used to identify the owner, and a local InstanceID [RFC6550] in that owner's namespace can be used as the TrackID. If the Track is reversible, the owner is found in the IPv6 destination address of a packet coming back along the Track. In that case, a RPL Packet Information [RFC6550] in an IPv6 packet can identify the Track unambiguously, and it can be expressed in a compressed form using [RFC8138]. Identity crisis solved ๐ซถ
TSCH ๐ขโก: A medium access mode of the IEEE Std 802.15.4 [IEEE802154] standard. It uses time synchronization to achieve ultra-low-power operation and channel hopping to enable high reliability. Low power, high reliability, iconic combo ๐๐
TSCH Schedule ๐: A matrix of cells, with each cell indexed by a slotOffset and a channelOffset. The TSCH schedule contains all the scheduled cells from all slotframes, and that's enough to describe the communication in the TSCH network. The number of channelOffset values (the "height" of the matrix) equals the number of available frequencies. The master plan ๐บ๏ธ
Unscheduled Cell ๐: A cell that the IEEE Std 802.15.4 TSCH implementation doesn't use. Still waiting for its moment ๐ซ
2.2. Abbreviations
This document uses the following abbreviations, so let's get them straight ๐๐
6BBR: 6LoWPAN Backbone Router (router with a proxy ND function) ๐6LBR: 6LoWPAN Border Router (authoritative on Duplicate Address Detection (DAD)) ๐ง6LN: 6LoWPAN Node ๐ฑ6LR: 6LoWPAN Router (relay to the registration process) ๐6CIO: Capability Indication Option ๐ท๏ธ(E)ARO: (Extended) Address Registration Option ๐(E)DAR: (Extended) Duplicate Address Request ๐(E)DAC: (Extended) Duplicate Address Confirmation โDAD: Duplicate Address Detection ๐DODAG: Destination-Oriented Directed Acyclic Graph ๐ณLLN: Low-Power and Lossy Network (a typical IoT network) ๐ธNA: Neighbor Advertisement ๐ฃNCE: Neighbor Cache Entry ๐๏ธND: Neighbor Discovery ๐NDP: Neighbor Discovery Protocol ๐ซPCE: Path Computation Element ๐งฎNME: Network Management Entity ๐๏ธROVR: Registration Ownership Verifier (pronounced rover) ๐ถRPL: IPv6 Routing Protocol for LLNs (pronounced ripple) ๐RA: Router Advertisement ๐ขRS: Router Solicitation ๐TSCH: Time-Slotted Channel Hopping ๐ขTID: Transaction ID (a sequence counter in the EARO) ๐ข
2.3. Related Documents ๐
okay bestie, so this doc totally conforms to the terms and models in [RFC3444] and [RFC5889] ๐ง it also uses the vocab and concepts from [RFC4291] for the IPv6 architecture, and it refers to [RFC4080] for reservation ๐
the doc uses some domain-specific terminology that's defined or referenced in these:
- 6LoWPAN ND: "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] and "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505],
- "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102], and
- RPL: "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)" [RFC6552] and "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550].
other terms used in LLNs live in "Terminology for Constrained-Node Networks" [RFC7228] ๐ธ
readers are expected to already know all the terms and concepts in:
- "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and
- "IPv6 Stateless Address Autoconfiguration" [RFC4862].
and ngl, it'd be super helpful to read these before this spec so the ND-proxying and binding stuff makes sense ๐ฆ
- "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606],
- "Multi-Link Subnet Issues" [RFC4903], and
- "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919].
3. High-Level Architecture โจ
3.1. A Non-broadcast Multi-access Radio Mesh Network ๐
okay so a 6TiSCH network is an IPv6 [RFC8200] subnet. in its basic configuration (see Figure 1 ๐ฆ), it's a single Low-Power and Lossy Network (LLN) running on a synchronized TSCH-based mesh ๐
---+-------- ............ ------------
| External Network |
| +-----+
+-----+ | NME |
| | LLN Border | PCE |
| | router (6LBR) +-----+
+-----+
o o o
o o o o o
o o 6LoWPAN + RPL o o
o o o o
Figure 1: Basic Configuration of a 6TiSCH Networkinside a 6TiSCH LLN, nodes use 6LoWPAN header compression (6LoWPAN HC) [RFC6282] to encode IPv6 packets ๐ง from the network layer's point of view, a single LLN interface (typically an IEEE Std 802.15.4-compliant radio) can look like a bunch of links with different capabilities for unicast or multicast services ๐
6TiSCH nodes join a mesh by attaching to nodes that are already members of the mesh (see Section 4.2.1). the security side of the join process is detailed further in Section 6. in a mesh, 6TiSCH nodes aren't necessarily reachable from one another at Layer 2, and an LLN may span multiple links ๐
this forms a homogeneous non-broadcast multi-access (NBMA) subnet, which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) [RFC4861] [RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775] [RFC8505] specifies extensions to IPv6 ND that enable ND operations in this type of subnet, and those can be protected against address theft and impersonation with [RFC8928] ๐ฅ
once a node has joined the 6TiSCH network, it acquires IPv6 addresses and registers them using 6LoWPAN ND. this guarantees the addresses are unique and protects address ownership over the subnet, more in Section 4.2.2 ๐
within the NBMA subnet, RPL [RFC6550] enables routing in the so-called "route-over" fashion, in either storing (stateful) or non-storing (stateless, with routing headers) mode. from there, some nodes can act as routers for 6LoWPAN ND and RPL operations, as detailed in Section 4.1 โจ
with TSCH, devices are time synchronized at the MAC level. the use of a particular RPL Instance for time synchronization is discussed in Section 4.3.4. with this mechanism, time synchronization starts at the RPL Root and follows the RPL loopless routing topology ๐
RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) within Instances of the protocol, and each Instance is associated with an Objective Function (OF) to form a routing topology ๐ a particular 6TiSCH node, the LLN Border Router (6LBR), acts as RPL Root, 6LoWPAN HC terminator, and Border Router for the LLN to the outside. the 6LBR is usually powered. more on RPL Instances is in Section 3.1 of RPL [RFC6550], in particular "3.1.2 RPL Identifiers" and "3.1.3 Instances, DODAGs, and DODAG Versions" ๐ธ RPL adds artifacts to the data packets, which are compressed with a 6LoWPAN Routing Header (6LoRH) [RFC8138]. in a preexisting network, compression can be globally turned on in a DODAG once all nodes are migrated to support [RFC8138] using [RFC9035] ๐
additional routing and scheduling protocols may be deployed to set up on-demand, peer-to-peer routes with particular characteristics inside the 6TiSCH network. this can be done in a centralized way by a Path Computation Element (PCE) [PCE] that programs both the routes and the schedules inside the 6TiSCH nodes, or in a distributed way by using a reactive routing protocol and a hop-by-hop scheduling protocol ๐ฆ
this architecture expects that a 6LoWPAN node can connect as a leaf to an RPL network. leaf support is the minimal functionality needed to connect as a host to an RPL network without having to take part in the full routing protocol ๐ง the architecture also expects that a 6LoWPAN node that is unaware of RPL may still connect, as described in [RFC9010] ๐ซถ
3.2. A Multi-Link Subnet Model ๐
an extended configuration of the subnet has multiple LLNs, as shown in Figure 2 ๐ in this extended configuration, a Routing Registrar [RFC8505] may be connected to the node that acts as the RPL Root and/or 6LoWPAN 6LBR. it provides connectivity to the larger campus or factory plant network over a high-speed backbone or a back-haul link ๐ the Routing Registrar may perform IPv6 ND proxy operations, redistribute the registration in a routing protocol such as OSPF [RFC5340] or BGP [RFC2545], or inject a route in a mobility protocol such as Mobile IPv6 (MIPv6) [RFC6275], Network Mobility (NEMO) [RFC3963], or Locator/ID Separation Protocol (LISP) [RFC6830] ๐ญ
multiple LLNs can be interconnected and possibly synchronized over a backbone, which can be wired or wireless. the backbone can run IPv6 ND procedures [RFC4861] [RFC4862] or a hybrid of IPv6 ND and 6LoWPAN ND [RFC6775] [RFC8505] [RFC8928] ๐
|
+-----+ +-----+ +-----+
(default) | | (Optional) | | | | IPv6
Router | | 6LBR | | | | Node
+-----+ +-----+ +-----+
| Backbone side | |
--------+---+--------------------+-+---------------+------+---
| | |
+-----------+ +-----------+ +-----------+
| Routing | | Routing | | Routing |
| Registrar | | Registrar | | Registrar |
+-----------+ +-----------+ +-----------+
o Wireless side 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 LLN o o o o LLN o o LLN o
o o o o o o o o o o o o o o
Figure 2: Extended Configuration of a 6TiSCH Networka Routing Registrar that does proxy IPv6 ND operations over the backbone on behalf of the 6TiSCH nodes is called a Backbone Router (6BBR) [RFC8929] ๐ง 6BBRs sit along the wireless edge of a backbone and federate multiple wireless links to form a single multi-link subnet. the 6BBRs sync with one another over the backbone, so the multiple LLNs that form the IPv6 subnet stay tightly synchronized ๐
multicast use can also be reduced on the backbone with a registrar that contributes to Duplicate Address Detection, as well as address lookup, using only unicast request/response exchanges. [ND-UNICAST-LOOKUP] is a proposed method showing an example of how this could be done with an extension of [RFC8505], using an optional 6LBR as a subnet-level registrar, as illustrated in Figure 2 โจ
as detailed in Section 4.1, the 6LBR that serves the LLN and the Root of the RPL network need to share information about devices learned through either 6LoWPAN ND or RPL, but not both. the preferred way to do this is to co-locate or combine them ๐ธ the combined RPL Root and 6LBR may be co-located with the 6BBR, or directly attached to the 6BBR. in the latter case, it uses the extended registration process defined in [RFC8505] to proxy the 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so the 6BBR can in turn perform classical ND operations over the backbone as a proxy ๐ฆ
the "Deterministic Networking Architecture" [RFC8655] studies Layer 3 aspects of Deterministic Networks and covers networks that span multiple Layer 2 domains ๐ฅ if the backbone is deterministic (such as defined by the Time-Sensitive Networking (TSN) Task Group at IEEE), then the Backbone Router makes sure the end-to-end deterministic behavior is maintained between the LLN and the backbone ๐ฅน๐
3.3. TSCH: a Deterministic MAC Layer ๐ฆ
okay so bestie, this one is about TSCH, which is the MAC layer doing the most ๐ . Two standards, IEEE Std 802.1 TSN and IEEE Std 802.15.4 TSCH, both work at a different time scale (several orders of magnitude, so like, a LOT of difference ๐ญ) but they both give you deterministic vibes. A packet on a certain flow can cross a network from node to node on a precise schedule, kind of like a train that pulls into each station and leaves at exact times along the route ๐โจ
With TSCH, time gets chopped up into timeslots, and each communication cell gets assigned to either unicast or broadcast traffic at the MAC level ๐ The time-slotted thing cuts down on collisions, saves energy, and lets you engineer the network around deterministic properties, which is so iconic ๐ The channel-hopping part is a simple and efficient way to deal with multipath fading and co-channel interference. Honestly it's giving clever ๐ง
6TiSCH builds on the IEEE Std 802.15.4 TSCH MAC and inherits its advanced capabilities, so it can bring them into lots of different environments where they can help automate operations ๐ค๐ The 6TiSCH architecture also inherits the ability to do centralized route computation for deterministic properties. For the protocol side, though, it leans on the IETF DetNet architecture [RFC8655] and IETF components like the PCE [PCE] ๐ซถ
On top of all that inheritance, 6TiSCH adds distributed routing and scheduling based on RPL, plus ways for peers to negotiate schedule adjustments with each other ๐ธ These distributed operations make TSCH networks way easier to deploy and open up wireless solutions for a bigger variety of use cases in operational technology. In industrial settings, examples include plant setup and decommissioning, and keeping an eye on a whole bunch of minor notifications like corrosion measurements, events, and local devices being accessed by mobile workers ๐ฅ
3.4. Scheduling TSCH ๐
Scheduling is where cells get allocated in a TDM/FDM matrix called a CDU, either to individual transmissions or as multi-access shared resources. The CDU matrix can be split into chunks that get allocated exclusively to particular nodes, which lets distributed scheduling happen without collisions ๐ More on this in Section 4.3.5.
At the MAC layer, a 6TiSCH node's schedule is the set of timeslots where it has to wake up for transmission, plus the channels it should send or listen on at those times. The schedule is expressed as one or more repeating slotframes. Slotframes can collide and make a device wake up at the same time, and when that happens, the slotframe with the highest priority is the one that's actionable ๐
The 6top sublayer (see Section 4.3 for more) hides the schedule's complexity from the upper layers, so the upper layers don't have to deal with it ๐ง The link abstraction that IP traffic uses is made of a pair of Layer 3 cell bundles, one to receive and one to transmit. Some of the cells may be shared, and in that case the 6top sublayer MUST perform some arbitration. Not optional, bestie ๐
Scheduling lets multiple simultaneous communications happen in the same interference domain using different channels. But a node with a single radio can only transmit or receive on one channel at any given time ๐ฆ Scheduled cells that do the same job, like receiving IP packets from a peer, get grouped into bundles ๐
The 6TiSCH architecture identifies four ways a schedule can be managed and CDU cells can be allocated: Static Scheduling, Neighbor-to-Neighbor Scheduling, Centralized (or Remote) Monitoring and Schedule Management, and Hop-by-Hop Scheduling ๐
Static Scheduling: This is the minimal 6TiSCH operation, where a static schedule is configured for the whole network and used in a Slotted ALOHA [S-ALOHA] fashion. The static schedule gets distributed through the native methods in the TSCH MAC layer, and it doesn't rule out other scheduling operations coexisting on the same 6TiSCH network. A static schedule is necessary for basic stuff like the join process and for interoperability during network formation, which is specified as part of the Minimal 6TiSCH Configuration [RFC8180] ๐ซถ
Neighbor-to-Neighbor Scheduling: This is dynamic adaptation of the bandwidth of links used for IPv6 traffic between adjacent peers. Scheduling Functions like the "6TiSCH Minimal Scheduling Function (MSF)" [RFC9033] influence how the MAC layer operates, so they can add, update, and remove cells in its own schedule and its peer's schedule, using 6P [RFC8480] to negotiate the MAC resources ๐
Centralized (or Remote) Monitoring and Schedule Management: This is about computing a schedule centrally and being able to forward a frame based on the cell it arrived in. Here, the related part of the device schedule, along with other device resources, is managed by an abstract Network Management Entity (NME), which may work with the PCE to minimize interaction with, and load on, the constrained device. This model is the TSCH adaptation of the DetNet architecture [RFC8655], and it enables Traffic Engineering with deterministic properties โจ
Hop-by-Hop Scheduling: This means cells can be reserved along a path for a particular flow, using a distributed mechanism ๐ฆ
It's not expected that every use case will need all of these mechanisms. Static Scheduling with minimal configuration is the only one expected in all implementations, because it gives a simple, solid basis for convergecast routing and time distribution ๐
A deeper dive into these mechanisms is in Section 4.4 ๐
3.5. Distributed vs. Centralized Routing ๐ธ
6TiSCH supports a mixed model of centralized and distributed routes. Centralized routes can be computed by an entity like a PCE. For interoperable, distributed routing, 6TiSCH uses RPL [RFC6550] ๐ง
Both methods can inject routes into the routing tables of 6TiSCH routers. Either way, each route is associated with a 6TiSCH topology, which can be a RPL Instance topology or a Track. The 6TiSCH topology is indexed by a RPLInstanceID, in a format that reuses the RPLInstanceID as defined in RPL ๐
RPL [RFC6550] applies to Static Scheduling and Neighbor-to-Neighbor Scheduling. The architecture also supports a centralized routing model for Remote Monitoring and Schedule Management. For Hop-by-Hop Scheduling, a routing protocol that's more optimized for point-to-point routing than RPL [RFC6550] is expected to be selected, such as the "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks" (AODV-RPL) [AODV-RPL], which derives from the "Ad Hoc On-demand Distance Vector (AODVv2) Routing" [AODVv2] ๐
Both RPL and PCE rely on shared sources, like policies, to define global and local RPLInstanceIDs that either method can use. It's possible for centralized and distributed routing to share the same topology. Generally they operate in different slotframes, and centralized routes are used for scheduled traffic and take precedence over distributed routes if the slotframes conflict ๐ฅ
3.6. Forwarding over TSCH ๐
The 6TiSCH architecture supports three forwarding models. The first is classical IPv6 Forwarding, where the node picks a feasible successor at Layer 3 on a per-packet basis, based on its routing table. The second comes from Generalized MPLS (GMPLS) for so-called Track Forwarding, where a frame received in one timeslot can be switched into another timeslot at Layer 2 without caring about the upper-layer protocol ๐ The third is 6LoWPAN Fragment Forwarding, which forwards individual 6LoWPAN fragments along a route set up by the first fragment ๐ฆ
In more detail:
IPv6 Forwarding: This is the classical IP forwarding model, with a Routing Information Base (RIB) installed by RPL and used to pick a feasible successor per packet. The packet goes onto an outgoing link, which the 6top sublayer maps into a (Layer 3) bundle of cells, and it gets scheduled for transmission based on QoS parameters. Besides RPL, this model also applies to any routing protocol that might run in the 6TiSCH network, and it lines up with all the distributed scheduling models: Static, Neighbor-to-Neighbor, and Hop-by-Hop Scheduling ๐
GMPLS Track Forwarding: This model corresponds to Remote Monitoring and Schedule Management. A central controller (hosting a PCE) computes and installs the schedules in the devices on a per-flow basis. The incoming (Layer 2) bundle of cells from the previous node along the path determines the outgoing (Layer 2) bundle toward the next hop for that flow, as decided by the PCE. The programmed sequence of bundles is called a Track, and it can take DAG shapes that are way more complex than a simple direct sequence of nodes ๐ธ
6LoWPAN Fragment Forwarding: This is a hybrid model that derives from IPv6 forwarding for cases where packets have to be fragmented at the 6LoWPAN sublayer. The first fragment gets forwarded like any IPv6 packet and leaves state in the intermediate hops, so the next fragments (which don't have an IP header) can be forwarded without recomposing the packet at every hop ๐ง
A deeper dive into these operations is in Section 4.6 ๐
Table 1 summarizes how the forwarding models apply to the various routing and scheduling possibilities ๐
+==================+==========+======================+
| Forwarding Model | Routing | Scheduling |
+==================+==========+======================+
| classical IPv6 / | RPL | Static (Minimal |
| 6LoWPAN Fragment | | Configuration) |
| | +----------------------+
| | | Neighbor-to-Neighbor |
| | | (SF+6P) |
| +----------+----------------------+
| | Reactive | Hop-by-Hop (AODV- |
| | | RPL) |
+------------------+----------+----------------------+
| GMPLS Track | PCE | Remote Monitoring |
| Forwarding | | and Schedule Mgt |
+------------------+----------+----------------------+
Table 13.7. 6TiSCH Stack
okay so the IETF has, like, a whole buffet of techniques for routing, transport, and security ๐ The 6TiSCH architecture is way more intentional than that. It limits how many variations of the stack are possible and recommends a set of base elements for LLN applications ๐ That keeps deployments and device interactions from getting out of hand, and it keeps the resulting object code small ๐ง Specifically, UDP [RFC0768], IPv6 [RFC8200], and the Constrained Application Protocol (CoAP) [RFC7252] are the transport/binding of choice for applications and management, as opposed to TCP and HTTP ๐
the resulting protocol stack is shown in Figure 3:
+--------+--------+
| Applis | CoJP |
+--------+--------+--------------+-----+
| CoAP / OSCORE | 6LoWPAN ND | RPL |
+-----------------+--------------+-----+
| UDP | ICMPv6 |
+-----------------+--------------------+
| IPv6 |
+--------------------------------------+----------------------+
| 6LoWPAN HC / 6LoRH HC | Scheduling Functions |
+--------------------------------------+----------------------+
| 6top inc. 6top Protocol |
+-------------------------------------------------------------+
| IEEE Std 802.15.4 TSCH |
+-------------------------------------------------------------+Figure 3: 6TiSCH Protocol Stack
RPL is the routing protocol of choice for LLNs ๐ธ So far, there is no identified need to define a 6TiSCH-specific Objective Function. The Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL over a static schedule used in a Slotted ALOHA fashion [S-ALOHA], where all active slots may be used for emission or reception of both unicast and multicast frames. โจ
6LoWPAN header compression [RFC6282] is used to compress the IPv6 and UDP headers ๐ฆ Meanwhile, the 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to compress the RPL artifacts in the IPv6 data packets. That includes the RPL Packet Information (RPI), the IP-in-IP encapsulation to/from the RPL Root, and the Source Routing Header (SRH) in non-storing mode. "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008] gives the details on when headers or encapsulation are needed ๐
the Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] is leveraged by the Constrained Join Protocol (CoJP), and it's expected to be the primary protocol for protecting the application payload too ๐ฅ The application payload may also be protected by the Datagram Transport Layer Security (DTLS) [RFC6347], sitting either under CoAP or over CoAP so it can traverse proxies. ๐ซถ
the 6TiSCH Operation Sublayer (6top) is a sublayer of a Logical Link Control (LLC). It provides the abstraction of an IP link over a TSCH MAC, and it schedules packets over TSCH cells, as discussed further in the next sections ๐ In particular, it provides dynamic cell allocation with the 6top Protocol (6P) [RFC8480] โจ
the reference stack in this document was implemented and interoperability-tested through a combination of open source, IETF, and ETSI efforts ๐ One goal is to help other bodies adopt the stack as a whole, which makes the move to an IPv6-based IoT stack easier. ๐
for a particular environment, some of the choices in this architecture may not be relevant ๐ For instance, RPL is not required for star topologies and mesh-under Layer 2 routed networks. The 6LoWPAN compression may also not be sufficient for ultra-constrained cases, such as some Low-Power Wide Area (LPWA) networks ๐ In such cases, it's perfectly doable to adopt a subset of the selection presented hereafter and then select alternate components to complete the solution wherever needed. ๐ง
3.8. Communication Paradigms and Interaction Models
Section 2.1 provides the terms of Communication Paradigms and Interaction Models, in combination with "On the Difference between Information Models and Data Models" [RFC3444]. okay so a Communication Paradigm is an abstract view of a protocol exchange, and it has an Information Model for the information being exchanged ๐ฆ An Interaction Model is more refined. It points to a standard operation, like a Representational State Transfer (REST) "GET" operation, and it matches a Data Model for the data that's provided over the protocol exchange ๐
Section 2.1.3 of [RPL-APPLICABILITY] and its following sections discuss application-layer paradigms. There's source-sink, which is a multipeer-to-multipeer model primarily used for alarms and alerts ๐จ There's publish-subscribe, which is typically used for sensor data ๐ก And there are peer-to-peer and peer-to-multipeer communications too ๐ธ
Additional considerations on duocast (one sender, two receivers, for redundancy) and its N-cast generalization are also provided โจ Those paradigms are frequently used in industrial automation, which is a major use case for IEEE Std 802.15.4 TSCH wireless networks with [ISA100.11a] and [WirelessHART]. WirelessHART provides a wireless access to [HART] applications and devices ๐ญ
This document focuses on Communication Paradigms and Interaction Models for packet forwarding and TSCH resources (cells) management ๐ Management mechanisms for the TSCH schedule at the link layer (one hop), the network layer (multihop along a Track), and the application layer (remote control) are discussed in Section 4.4. Link-layer frame forwarding interactions are discussed in Section 4.6, and network-layer packet routing is addressed in Section 4.7. ๐
4. Architecture Components
4.1. 6LoWPAN (and RPL)
A RPL DODAG is formed of a Root, a collection of routers, and leaves that are hosts ๐ณ Hosts are nodes that do not forward packets they did not generate. RPL-aware leaves will participate in RPL to advertise their own addresses, whereas RPL-unaware leaves depend on a connected RPL router to do so ๐ RPL interacts with 6LoWPAN ND at multiple levels, in particular at the Root and in the RPL-unaware leaves. it's giving layers, bestie ๐ง
4.1.1. RPL-Unaware Leaves and 6LoWPAN ND
RPL needs a set of information to advertise a leaf node through a Destination Advertisement Object (DAO) message and establish reachability ๐ฌ
"Routing for RPL Leaves" [RFC9010] details the basic interaction of 6LoWPAN ND and RPL. It enables a plain 6LN that supports [RFC8505] to obtain return connectivity via the RPL network as a RPL-unaware leaf ๐ The leaf indicates that it requires reachability services for the Registered Address from a Routing Registrar by setting an 'R' flag in the Extended Address Registration Option [RFC8505]. It provides a TID that maps to the "Path Sequence" defined in Section 6.7.8 of [RFC6550], and its operation is defined in Section 7.2 of [RFC6550] ๐งฉ
[RFC9010] also enables the leaf to signal with the RPLInstanceID that it wants to participate, by using the Opaque field of the EARO. On the backbone, the RPLInstanceID is expected to be mapped to an overlay that matches the RPL Instance, e.g., a Virtual LAN (VLAN) or a virtual routing and forwarding (VRF) instance ๐ฆ
Though, at the time of this writing, the above specification enables a model where the separation is possible, this architecture recommends co-locating the functions of 6LBR and RPL Root ๐ท
4.1.2. 6LBR and RPL Root
With the 6LoWPAN ND [RFC6775], information on the 6LBR is disseminated via an Authoritative Border Router Option (ABRO) in RA messages ๐ฃ [RFC8505] extends [RFC6775] to enable a registration for routing and proxy ND. The capability to support [RFC8505] is indicated in the 6LoWPAN Capability Indication Option (6CIO). The discovery and liveliness of the RPL Root are obtained through RPL [RFC6550] itself ๐ซ
When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities are co-located. This way, the address of the 6LBR is indicated by RPL DODAG Information Object (DIO) messages, and the ROVR from the Extended Duplicate Address Request/Confirmation (EDAR/EDAC) exchange [RFC8505] is associated with the state that's maintained by RPL ๐ฅฐ
Section 7 of [RFC9010] specifies how the DAO messages are used to reconfirm the registration, which eliminates a duplication of functionality between DAO and EDAR/EDAC messages, as illustrated in Figure 6. [RFC9010] also provides the protocol elements that are needed when the 6LBR and RPL Root functionalities are not co-located ๐ง
Even though the Root of the RPL network is integrated with the 6LBR, it's logically separated from the Backbone Router (6BBR) that is used to connect the 6TiSCH LLN to the backbone. Ngl, this is the part that makes it iconic: the Root has all the information from 6LoWPAN ND and RPL about the LLN devices attached to it ๐
This architecture also expects that the Root of the RPL network (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, for whatever operation the 6BBR performs on the backbone, such as ND proxy or redistribution in a routing protocol. This relies on an extension of the 6LoWPAN ND registration described in [RFC8929] ๐
This model supports the movement of a 6TiSCH device across the multi-link subnet, and it allows the proxy registration of 6TiSCH nodes deep into the 6TiSCH LLN by the 6LBR / RPL Root ๐ฆ This is why in [RFC8505] the Registered Address is signaled in the Target Address field of the Neighbor Solicitation (NS) message, as opposed to the IPv6 Source Address. In a proxy registration, the IPv6 Source Address is that of the 6LBR / RPL Root itself. ๐
4.2. Network Access and Addressing
4.2.1. Join Process ๐ฆ
okay so, a brand new device, called the pledge, goes through the join protocol to become a node in a 6TiSCH network โจ. this usually happens only once, right when the device is first powered on ๐. the pledge talks to the Join Registrar/Coordinator (JRC) of the network through a Join Proxy (JP), which is a radio neighbor of the pledge ๐ .
the JP gets discovered through MAC-layer beacons ๐ก. when there are multiple JPs visible, maybe from multiple networks, doing trial and error until you land in an acceptable position in the right network is super inefficient ๐. [RFC9032] adds a new subtype in the Information Element that was delegated to the IETF [RFC8137], and it gives visibility into which network can be joined and whether the JP and the Root are willing to be used by the pledge ๐.
the join protocol gives you:
- Mutual authentication
- Authorization
- Parameter distribution to the pledge over a secure channel
the Minimal Security Framework for 6TiSCH [RFC9031] defines the minimal mechanisms required for this join process to happen securely ๐. the spec defines the Constrained Join Protocol (CoJP), which distributes the parameters to the pledge over a secure session set up through OSCORE [RFC8613], and it describes the secure configuration of the network stack ๐ง. in the minimal setting with pre-shared keys (PSKs), CoJP lets the pledge join after a single round-trip exchange with the JRC ๐โโ๏ธ. the PSK has to be provisioned to both the pledge and the JRC out of band, through a 'one-touch' bootstrapping process, which basically enrolls the pledge into the domain managed by the JRC ๐.
sometimes 'one-touch' bootstrapping isn't doable because of operational constraints, so the enrollment of the pledge into the domain has to happen in-band ๐. that's where the 'zero-touch' extension of the Minimal Security Framework for 6TiSCH comes in ๐ฆ. the zero-touch extension [ZEROTOUCH-JOIN] builds on the "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" [RFC8995] work to establish a shared secret between a pledge and the JRC, without them necessarily belonging to a common (security) domain at join time ๐ธ. this happens through inter-domain communication between the JRC of the network and the domain of the pledge, which is represented by a fourth entity, the Manufacturer Authorized Signing Authority (MASA) ๐ต๏ธโโ๏ธ. once the zero-touch exchange completes, the CoJP exchange defined in [RFC9031] runs over the secure session between the pledge and the JRC ๐.
Figure 4 shows the join process and where a Link-Local Address (LLA) is used, versus a Global Unicast Address (GUA) ๐บ๏ธ.
6LoWPAN Node 6LR 6LBR Join Registrar MASA
(pledge) (Join Proxy) (Root) /Coordinator (JRC)
| | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network |
| LLN link |Route-Over mesh|(the Internet)|(the Internet)|
| | | | |
| Layer 2 | | | |
|Enhanced Beacon| | | |
|<--------------| | | |
| | | | |
| NS (EARO) | | | |
| (for the LLA) | | | |
|-------------->| | | |
| NA (EARO) | | | |
|<--------------| | | |
| | | | |
| (Zero-touch | | | |
| handshake) | (Zero-touch handshake) | (Zero-touch |
| using LLA | using GUA | handshake) |
|<------------->|<---------------------------->|<------------>|
| | | | |
| CoJP Join Req | | | | \
| using LLA | | | | |
|-------------->| | | | |
| | CoJP Join Request | | |
| | using GUA | | |
| |----------------------------->| | | C
| | | | | | o
| | CoJP Join Response | | | J
| | using GUA | | | P
| |<-----------------------------| | |
|CoJP Join Resp | | | | |
| using LLA | | | | |
|<--------------| | | | /
| | | | | Figure 4: Join Process in a Multi-Link Subnet. Parentheses ()
denote optional exchanges.4.2.2. Registration ๐ท
okay, once the pledge finishes the CoJP exchange and becomes a network node, it grabs the network prefix from neighboring routers and registers its IPv6 addresses ๐ฎ. as detailed in Section 4.1, the combined 6LoWPAN ND 6LBR and Root of the RPL network learns stuff like an identifier (device EUI-64 [RFC6775] or a ROVR [RFC8505] (from 6LoWPAN ND)) and the updated Sequence Number (from RPL). then it does 6LoWPAN ND proxy registration to the 6BBR on behalf of the LLN nodes ๐ซถ.
Figure 5 shows the initial IPv6 signaling that lets a 6LN form a global address and register it to a 6LBR using 6LoWPAN ND [RFC8505]. it then gets carried over RPL to the RPL Root and then on to the 6BBR ๐ง. this flow happens just once, when the address is created and first registered โญ.
6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (Root)
| | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh|Ethernet/serial| Backbone
| | | |
| RS (mcast) | | |
|-------------->| | |
|-----------> | | |
|------------------> | |
| RA (unicast) | | |
|<--------------| | |
| | | |
| NS(EARO) | | |
|-------------->| | |
| 6LoWPAN ND | Extended DAR | |
| |-------------->| |
| | | NS(EARO) |
| | |-------------->|
| | | | NS-DAD
| | | |------>
| | | | (EARO)
| | | |
| | | NA(EARO) |<timeout>
| | |<--------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<--------------| | |
| | | | Figure 5: Initial Registration Flow over Multi-Link SubnetFigure 6 shows the repeating IPv6 signaling that keeps a 6LN's global address alive and registered with its 6LBR ๐. it goes 6LoWPAN ND to the 6LR, RPL to the RPL Root, and then 6LoWPAN ND again to the 6BBR. this avoids repeating the Extended DAR/DAC flow across the network when RPL can suffice as a keep-alive mechanism ๐. so smart, honestly ๐.
6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (Root)
| | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh| ant IPv6 link | Backbone
| | |
| | | |
| NS(EARO) | | |
|-------------->| | |
| NA(EARO) | | |
|<--------------| | |
| | DAO | |
| |-------------->| |
| | DAO-ACK | |
| |<--------------| |
| | | NS(EARO) |
| | |-------------->|
| | | NA(EARO) |
| | |<--------------|
| | | |
| | | | Figure 6: Next Registration Flow over Multi-Link Subnetas the network builds up, a node should start as a leaf to join the RPL network, and it may later turn into both an RPL-capable router and a 6LR, so it can accept leaf nodes recursively joining the network ๐โจ.
4.3. TSCH and 6top ๐
4.3.1. 6top โจ
okay bestie, 6TiSCH needs to be super scalable AND do distributed routing based on RPL ๐ฆ to pull that off, the spectrum has to be split up so zones that won't interfere with each other can reuse the same frequencies across space ๐ and honestly? In a big, spread-out network, a 6TiSCH node is usually in a great spot to figure out how the spectrum is being used around it ๐
so with 6TiSCH, the IPv6 link is basically faked as a pair of cell bundles, one for each direction ๐ IP links only get switched on between RPL parents and their children (no drama outside that circle ๐ โโ๏ธ). 6TiSCH runs best when the bundle is sized so it wastes the least energy on idle listening AND drops the fewest packets to congestion, while still getting packets forwarded fast enough ๐
distributed routing usually shows up with best-effort traffic that comes in bursts, and each link needs a different amount of bandwidth ๐ธ the vibe stays optimal if RPL parents can adjust their bandwidth with each child, in both directions, quickly enough to keep up with those bursts โญ and the faster they can grab more cells, the less they have to chat with other devices and the less protocol latency gets involved ๐
6top is the logical link control sitting between the IP layer and the TSCH MAC layer ๐ its whole job is providing the link abstraction IP needs. The 6top Protocol, 6P, specified in [RFC8480], is just one of the services 6top offers โจ the 6top services are also available through a management API, so an external management entity can schedule cells and slotframes, and you can plug in extra features too ๐ง like a Scheduling Function that manages a dynamic schedule based on observed resource usage (more on that in Section 4.4.2 ๐ซถ). That's why 6TiSCH splits cells into "soft" cells and "hard" cells ๐ฅ
4.3.1.1. Hard Cells ๐งฑ
"Hard" cells are owned and managed by a separate scheduling entity (for example, a PCE) ๐ that tells 6top exactly which slotOffset/channelOffset to add, move, or delete. So 6top can only do what it's told and it may not move hard cells around in the TSCH schedule on its own ๐
4.3.1.2. Soft Cells ๐ท
"Soft" cells are the ones 6top can handle locally ๐ 6top has a monitoring process that keeps an eye on how cells are performing, and it can add or remove soft cells in the TSCH schedule to match the traffic, or move one if it's performing badly ๐ญ To reserve a soft cell, the higher layer doesn't pick the exact slotOffset/channelOffset. It just says what bandwidth and QoS it needs ๐ And when the monitoring process triggers a cell reallocation, the two neighbors using that cell negotiate its new spot in the TSCH schedule together ๐ค
4.3.2. Scheduling Functions and the 6top Protocol ๐ง
for soft cells, the cell management entity that handles dynamically assigning cells to match variable-rate flows is called a Scheduling Function (SF) โจ
there can be multiple SFs, and they can react more or less aggressively to what's happening in the network ๐
an SF can be split into two parts ๐ there's an upper bandwidth-adaptation logic that doesn't care what technology is used to get and release bandwidth, and an underlying service that maps those needs onto the actual technology ๐ For TSCH using the 6top Protocol, as shown in Figure 7, that means mapping the bandwidth onto cells ๐ง
+------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function |
| Bandwidth adaptation | | Bandwidth adaptation |
+------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function |
| TSCH mapping to cells | | TSCH mapping to cells |
+------------------------+ +------------------------+
| 6top cells negotiation | <- 6P -> | 6top cells negotiation |
+------------------------+ +------------------------+
Device A Device B
Figure 7: SF/6P Stack in 6topthe SF leans on 6top services that implement the 6top Protocol (6P) [RFC8480] to negotiate exactly which cells get allocated or freed, based on the peer's schedule ๐ซถ For example, a peer might want a timeslot that's free in its own schedule, but that timeslot is already being used by the other peer to talk to a third party on a different cell ๐ฌ 6P lets the peers reach an agreement in a transactional way, which keeps the nodes' states consistent in the end ๐
MSF [RFC9033] is one of the possible Scheduling Functions ๐ MSF uses the rendezvous slot from [RFC8180] for network discovery, neighbor discovery, and any other broadcast ๐ก
for basic unicast with any neighbor, each node listens on a receive cell at a well-known slotOffset/channelOffset, which is derived from a hash of its own MAC address ๐ Nodes can reach any neighbor by installing a transmit (shared) cell with a slotOffset/channelOffset derived from that neighbor's MAC address ๐ฆ
for child-parent links, MSF keeps monitoring the load between parents and children ๐ then it uses 6P to install or remove unicast cells whenever the schedule looks under-provisioned or over-provisioned ๐ธ
4.3.3. 6top and RPL Objective Function Operations ๐งฉ
an implementation of a RPL [RFC6550] Objective Function (OF) can use the info 6top keeps around for its own calculations ๐ For example, the RPL Objective Function Zero (OF0) [RFC6552] is used in the Minimal 6TiSCH Configuration [RFC8180] to support RPL over a static schedule, and it can totally lean on 6top data โจ
an OF may need reachability metrics, like the Expected Transmission Count (ETX) metric [RFC6551] ๐ 6top creates and maintains an abstract neighbor table, and that state can feed an OF and/or store OF information too ๐ each neighbor table entry can hold a set of statistics about that specific neighbor ๐
that info can include the time the last packet came in from that neighbor, cell quality metrics like received signal strength indication (RSSI) or link quality indicator (LQI), how many packets were sent to the neighbor, and how many were received from it ๐ It's all available through 6top management APIs, and it can be used to compute a Rank Increment, which decides which preferred parent gets picked ๐
6top also provides stats about the underlying layer, so the OF can be tuned to the nature of the TSCH MAC layer ๐ง and the RPL OF can influence MAC behaviour too, like by setting how often IEEE Std 802.15.4 Extended Beacons (EBs) go out ๐ก By making the EB periodicity longer, the network dynamics can change so devices that switch their point of attachment in the 6TiSCH network get better support ๐ฆ
some RPL control messages, like the DODAG Information Object (DIO), are ICMPv6 messages that get broadcast to all neighbor nodes ๐ฃ In 6TiSCH, 6top handles that broadcast need by configuring TSCH to provide a broadcast channel ๐ The other option would be piggybacking DIO messages in Layer 2 Enhanced Beacons (EBs), but that would cause undue timer coupling among layers and packet size issues ๐ตโ๐ซ and it could clash with production networks, where EBs are mostly eliminated to save energy ๐
4.3.4. Network Synchronization โฐ
nodes in a TSCH network must be time synchronized โฑ๏ธ A node stays synchronized with its time source neighbor through a mix of frame-based and acknowledgment-based synchronization ๐ซถ To max out battery life and network throughput, it's advisable to coordinate RPL ICMP discovery and maintenance traffic (governed by the Trickle timer) with the transmission of time synchronization packets, especially Enhanced Beacons ๐ธ
this could happen through an interaction between the 6top sublayer and the RPL Objective Function, or a management entity could control it ๐ง
time distribution needs a loop-free structure ๐ nodes caught in a synchronization loop will quickly desync from the network and get isolated ๐ฑ 6TiSCH uses an RPL DAG with a dedicated global Instance just for time sync, called the Time Synchronization Global Instance (TSGI) ๐ The TSGI can operate in any of the three modes detailed in Section 3.1.3 of RPL [RFC6550], "Instances, DODAGs, and DODAG Versions" ๐ Multiple uncoordinated DODAGs with independent Roots can be used if all the Roots share a common time source, like the Global Positioning System (GPS) ๐ฐ๏ธ
without a common time source, the TSGI should form a single DODAG with a virtual Root ๐ A backbone network is then used to synchronize and coordinate RPL operations between the Backbone Routers that act as sinks for the LLN ๐ฆ Optionally, RPL's periodic operations can transport the network synchronization ๐ This might mean 6top has to trigger (override) the Trickle timer if no other traffic has happened for so long that nodes could fall out of sync โ ๏ธ
a node that hasn't joined the TSGI advertises a MAC-level Join Priority of 0xFF to tell its neighbors that it is not capable of serving as a time parent ๐
โโ๏ธ A node that has joined the TSGI advertises a MAC-level Join Priority set to its DAGRank() in that Instance, where DAGRank() is the operation specified in Section 3.5.1 of [RFC6550], "Rank Comparison" ๐
provisioning a RPL Root is out of scope for both RPL and this architecture, even though RPL can propagate configuration info down the DODAG ๐คทโโ๏ธ This applies to the TSGI too: a Root is configured (or gets the knowledge by unspecified means) of the RPLInstanceID for the TSGI ๐ The Root advertises its DagRank in the TSGI as its Join Priority in its IEEE Std 802.15.4 EBs, and that DagRank must be less than 0xFF ๐
a node that reads a Join Priority of less than 0xFF should join the neighbor with the lesser Join Priority and use it as its time parent ๐งญ If the node is configured to serve as a time parent, then it should 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 ๐
4.3.5. Slotframes and CDU Matrix โจ
okay so 6TiSCH lets IPv6 do best-effort (stochastic) transmissions over a MAC layer that can also do scheduled (deterministic) transmissions ๐ฆ. The trick is a window of time around each scheduled transmission where the medium must, as much as practically feasible, be free of contending energy. That way no contending packets are on the medium when the scheduled one comes up ๐ซถ. The simplest way to get that window is to format time and frequencies into cells of transmission that all have the same duration. That's the method used in IEEE Std 802.15.4 TSCH and also in the Long Term Evolution (LTE) of cellular networks ๐ถ.
The 6TiSCH architecture has a global concept called a Channel Distribution and Usage (CDU) matrix, which is how it describes that formatting of time and frequencies ๐ .
A CDU matrix is defined centrally as part of the network definition. It's a matrix of cells. The height is the number of available channels (indexed by channelOffsets), and the width (in timeslots) is the period of the network scheduling operation for that CDU matrix (indexed by slotOffsets). There are different models for scheduling the usage of those cells, and they put the job of avoiding collisions either on a central controller or on the devices themselves. The devices-do-it-themselves option costs extra energy because they have to scan for free cells (more in Section 4.4) ๐.
A cell is one timeslot long. Values of 10 to 15 milliseconds are typical in 802.15.4 TSCH, because that's enough room for a frame and an ack, plus the security validation on the receive side, which may take up to a few milliseconds on some device architectures ๐ง .
A CDU matrix iterates over a well-known channel rotation called the hopping sequence ๐. A network might have several CDU matrices with different widths, so they have different durations and represent different periodic operations. It is recommended that all CDU matrices in a 6TiSCH domain use the same cell duration and are aligned, so there are fewer chances of interference from Slotted ALOHA operations ๐. Every node knows about the CDU matrices, and they're used in particular to define slotframes ๐.
A slotframe is a MAC-level abstraction that's common to all nodes. It holds a series of timeslots of equal length and precedence, and it's characterized by a slotframe_ID and a slotframe_size. A slotframe lines up with a CDU matrix for its parameters, like the number and duration of its timeslots ๐.
A node can have multiple slotframes in its schedule, so it can have activities scheduled in different slotframes at once ๐ง. Each slotframe has a priority that may be related to the precedence of different 6TiSCH topologies. Slotframes can be aligned to different CDU matrices, which means they can have different widths. There's typically one slotframe for scheduled traffic with the highest precedence, plus one or more slotframes for RPL traffic ๐. The timeslots in a slotframe are indexed by the slotOffset, and the first cell is at slotOffset 0 ๐ธ.
When a packet comes down from a higher layer for transmission, 6top puts it in the outgoing queue that matches it best. (That means Differentiated Services [RFC2474] can be used here ๐.) At each scheduled transmit slot, 6top looks through all the outgoing queues for the frame that best matches the cells. If it finds one, it hands it to the TSCH MAC for transmission ๐.
4.3.6. Distributing the Reservation of Cells ๐ฐ
The 6TiSCH architecture introduces the concept of chunks (Section 2.1) so the allocation of spectrum can be handed out for a whole group of cells at a time ๐ง. The CDU matrix gets formatted into a set of chunks, possibly like the one in Figure 8, and each chunk is uniquely identified by a chunk-ID ๐ท๏ธ. Every node in a 6TiSCH network knows this formatting. It could be conveyed during the join process, codified into a profile document, or obtained some other way ๐. This is the opposite of Static Scheduling, which is the preprogrammed mechanism specified in [RFC8180] and which already existed before chunk formatting was distributed ๐ฐ๏ธ.
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
...
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
0 1 2 3 4 5 6 MFigure 8: CDU Matrix Partitioning in Chunks ๐งฉ
The 6TiSCH architecture imagines a protocol for chunk ownership appropriation ๐ดโโ ๏ธ. Here's how it goes: a RPL parent discovers a chunk that isn't used in its interference domain, claims it, and then defends it in case another RPL parent tries to appropriate it while it's in use ๐ก๏ธ. The chunk is the basic unit of ownership in that process.
Because of chunk ownership appropriation, the RPL parent has exclusive authority to decide which cell in the appropriated chunk can be used by which node in its interference domain. In other words, it's implicitly delegated the right to manage the part of the CDU matrix that the chunk represents ๐ธ.
At first, those cells go into the heap of free cells. Then they get dynamically placed into existing bundles, into new bundles, or allocated opportunistically for one transmission โญ.
Note that a PCE is expected to have precedence in the allocation, so a RPL parent would only be able to get portions that aren't in use by the PCE. Main character energy for the PCE, honestly ๐ โจ.
4.4. Schedule Management Mechanisms ๐๏ธ
6TiSCH uses four paradigms to manage the TSCH schedule of the LLN nodes: Static Scheduling, Neighbor-to-Neighbor Scheduling, Remote Monitoring and Scheduling Management, and Hop-by-Hop Scheduling ๐. Multiple mechanisms are defined that implement the associated Interaction Models, and they can be combined and used in the same LLN ๐ซถ. Which mechanism(s) to use depends on the application requirements ๐.
4.4.1. Static Scheduling ๐งธ
In the simplest version of a 6TiSCH network, one common fixed schedule can be shared by all the nodes. The cells are shared, and nodes contend for slot access in a Slotted ALOHA manner ๐ฒ.
A static TSCH schedule can be used to bootstrap a network, either as an initial phase during implementation or as a fall-back mechanism if the network malfunctions ๐. This schedule is preestablished. For instance, a network administrator might decide it based on operational needs ๐. It can be preconfigured into the nodes or, more commonly, learned by a node when it joins the network, using the standard IEEE Std 802.15.4 Information Elements (IE) ๐ก. Either way, the schedule stays unchanged after the node has joined a network ๐. RPL is used on the resulting network. This "minimal" scheduling mechanism that implements this paradigm is detailed in [RFC8180] ๐.
4.4.2. Neighbor-to-Neighbor Scheduling ๐ค
In the simplest version of a 6TiSCH network, as described in Section 4.4.1, nodes may expect a packet at any cell in the schedule, and they'll waste energy idle listening ๐ญ. In a more complex version, a matching portion of the schedule is established between peers to reflect the observed amount of transmissions between those nodes ๐. The aggregation of cells between a node and a peer forms a bundle, which the 6top sublayer uses to implement the abstraction of a link for IP ๐. The bandwidth on that link is proportional to the number of cells in the bundle ๐ซ.
If the bundle is sized to fit an average amount of bandwidth, peak traffic gets dropped ๐. If it's sized to allow for peak emissions, energy is wasted on idle listening ๐ฅฒ.
As discussed in more detail in Section 4.3, the 6top Protocol [RFC8480] specifies the exchanges between neighbor nodes that reserve soft cells to transmit to one another. This can happen under the control of a Scheduling Function (SF). Because this reservation is done without global knowledge of the other nodes' schedules in the LLN, scheduling collisions are possible ๐ฅ.
And as discussed in Section 4.3.2, an optional SF monitors bandwidth usage and makes requests for dynamic allocation by the 6top sublayer ๐. The SF component is not part of the 6top sublayer. It may be co-located on the same device, or it may be partially or fully offloaded to an external system โ๏ธ. The "6TiSCH Minimal Scheduling Function (MSF)" [RFC9033] provides a simple SF that devices supporting dynamic scheduling of soft cells can use by default ๐ฏ.
Monitoring and relocation happen in the 6top sublayer. For the upper layer, the connection between two neighbor nodes just looks like a number of cells ๐ง. Depending on traffic requirements, the upper layer can ask 6top to add or delete a number of cells scheduled to a particular neighbor. It doesn't have to pick the exact slotOffset/channelOffset of those cells itself ๐.
4.4.3. Remote Monitoring and Schedule Management โจ
okay so bestie, this one is about a DetNet/SDN setup where a network management entity (NME) and a scheduling entity, both tied to a PCE, chill together in a central controller ๐ง . From there they talk to the 6top sublayer to control IPv6 links and Tracks (Section 4.5) in a 6TiSCH network. The controller can hand out physical resources, like buffers and hard cells, to a particular Track. The goal is to optimize reliability within a bounded latency for a well-specified flow ๐ .
The 6TiSCH Working Group focused on nondeterministic traffic, so it didn't write the generic data model the controller would need to monitor and manage the resources of the 6top sublayer. That's been pushed to future work, see Appendix A.1.2 ๐ซ .
For centralized routing and scheduling, the plan is for the related 6TiSCH component to be an extension of the DetNet architecture [RFC8655]. DetNet studies the Layer 3 side of Deterministic Networks, and it covers networks that span multiple Layer 2 domains ๐.
The DetNet architecture is a form of Software-Defined Networking (SDN) architecture with three planes: a (User) Application Plane, a Controller Plane (where the PCE lives), and a Network Plane, which can be a 6TiSCH LLN ๐.
"Software-Defined Networking (SDN): Layers and Architecture Terminology" [RFC7426] gives a generic picture of SDN architecture, and here it is, reproduced as Figure 9 ๐ฆ:
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+Figure 9: SDN Layers and Architecture Terminology per RFC 7426
The PCE sets up end-to-end Tracks of hard cells, which Section 4.6.1 digs into more ๐ง.
The DetNet work is expected to enable end-to-end deterministic paths across heterogeneous networks. Think a 6TiSCH LLN plus an Ethernet backbone, for example ๐ธ.
This model fits the 6TiSCH extended configuration, where a 6BBR federates multiple 6TiSCH LLNs into one subnet over a backbone that can be Ethernet or Wi-Fi, for instance. In that setup, 6TiSCH 6BBRs sync up with one another over the backbone, so the multiple LLNs that make up the IPv6 subnet stay tightly synchronized โฐโจ.
If the backbone is deterministic, the Backbone Router makes sure the end-to-end deterministic behavior survives between the LLN and the backbone. The PCE is responsible for computing a deterministic path end to end across the TSCH network and an IEEE Std 802.1 TSN Ethernet backbone. DetNet is responsible for enabling end-to-end deterministic forwarding. Teamwork makes the dream work ๐ซถ.
4.4.4. Hop-by-Hop Scheduling
okay, so a node can reserve a Track (Section 4.5) to one or more destinations that are multiple hops away ๐ฆ. How? It installs soft cells at each intermediate node. Those soft cells add up to a Track of soft cells. Each node on the Track needs a Track SF sitting above its 6top sublayer, because that's what keeps an eye on these soft cells and kicks off relocation when needed ๐.
This hop-by-hop reservation mechanism is expected to be similar in essence to [RFC3209] and/or [RFC4080] and [RFC5974]. As for the protocol a node would use to trigger hop-by-hop scheduling, that's not defined yet ๐.
4.5. On Tracks
the architecture brings in the concept of a Track ๐ค๏ธ. It's a directed path from a source 6TiSCH node to one or more destination 6TiSCH nodes across a 6TiSCH LLN.
A Track is the 6TiSCH version of the deterministic path idea from [RFC8655]. Constrained resources, like memory buffers, get reserved for that Track in the intermediate 6TiSCH nodes, so the Track can avoid loss from limited capacity ๐. A 6TiSCH node along a Track doesn't just know which bundles of cells to use to receive packets from the previous hop. It also knows which bundle(s) to use to send packets to its next hop along the Track. Main character energy ๐.
4.5.1. General Behavior of Tracks
A Track is tied to Layer 2 bundles of cells, which come with related schedules and logical relationships. Together they make sure a packet injected into a Track keeps moving and gets all the way to the destination in due time โณ.
Several cells can be scheduled in a Track for transmitting one packet. When that happens, the normal operation of IEEE Std 802.15.4 Automatic Repeat-reQuest (ARQ) can take place. The acknowledgment can be left out in some cases, for example if there's no scheduled cell for a possible retry ๐.
Using a Track to forward a packet from a source node to the destination node has a few perks, ngl ๐:
- Track Forwarding, as further described in Section 4.6.1, is a Layer 2 forwarding scheme. It adds less process delay and overhead than a Layer 3 forwarding scheme. So LLN devices can save more energy and resources, which is huge for resource-constrained devices ๐.
- Channel resources, i.e., bundles of cells, get reserved for communication between 6TiSCH nodes at each hop on the Track. That means the throughput and maximum latency of the traffic along a Track are guaranteed, and the jitter is minimized ๐ฏ.
- Knowing the scheduled timeslots of incoming bundle(s) and outgoing bundle(s) lets 6TiSCH nodes on a Track save even more energy by sleeping during inactive slots ๐ด.
- Tracks are protected from interfering with one another if a cell belongs to at most one Track. Congestion loss is avoided if at most one packet can be presented to the MAC to use that cell. Tracks also boost transmission reliability, which cuts retransmissions and improves energy consumption in LLN devices ๐.
4.5.2. Serial Track
A Serial (or simple) Track is the 6TiSCH version of a circuit ๐. A bundle of cells programmed to receive (RX-cells) is uniquely paired with a bundle of cells set to transmit (TX-cells). That pairing is a Layer 2 forwarding state, and it works regardless of the network-layer protocol. A Serial Track is formed end-to-end as a chain of paired bundles: a receive bundle from the previous hop and a transmit bundle to the next hop along the Track ๐.
For a given iteration of the device schedule, the cell's effective channel comes from looping through a well-known hopping sequence, starting at Epoch time and beginning at the cell's channelOffset. That rotates the frequency used for transmission ๐. The bundles may be computed to accommodate both variable rates and retransmissions, so they might not be fully used in a given iteration of the schedule. Not every slot has to be busy, and that's totally fine ๐ฅฐ.
4.5.3. Complex Track with Replication and Elimination
The Deterministic Networks world already has packet replication and elimination techniques ๐งฉ. Example standards include the Parallel Redundancy Protocol (PRP) and the High-availability Seamless Redundancy (HSR) [IEC62439]. Unlike a Serial Track, which is a sequence of nodes and links, a Complex Track is shaped as a directed acyclic graph toward one or more destination(s). That lets it do multipath forwarding and route around failures ๐บ๏ธ.
A Complex Track can branch off over noncongruent branches for multicasting and/or redundancy, and then reconverge later down the path. This enables the Packet Replication, Elimination, and Ordering Functions (PREOF) defined by DetNet. Packet ARQ, Replication, Elimination, and Overhearing (PAREO) adds radio-specific stuff: Layer 2 ARQ, plus promiscuous listening to redundant transmissions. That compensates for the lossiness of the medium and helps meet industrial expectations of a RAW network ๐ญ. Put PAREO and PREOF together, and a Track can stretch beyond the 6TiSCH network into a larger DetNet network ๐.
In the art of TSCH, a path doesn't necessarily support PRE, but it's almost always multipath ๐. So a Track gets scheduled so each hop has at least two forwarding solutions. The forwarding decision is to try the preferred one and use the other if Layer 2 transmission fails, as detected by ARQ. Similarly, at each 6TiSCH hop along the Track, the PCE may schedule more than one timeslot for a packet, to support Layer 2 retries (ARQ). It's also possible that the field device only uses the second branch if sending over the first one fails ๐ซถโจ.
4.5.4. DetNet End-to-End Path ๐
Okay so DetNet is supposed to let a Track stretch way past the 6TiSCH LLN, see Figure 10 ๐. In that picture, a Track runs from a field device in a 6TiSCH network all the way to an IoT gateway sitting on an 802.1 Time-Sensitive Networking (TSN) backbone ๐ฆ. A 6TiSCH-aware DetNet service layer handles the Packet Replication, Elimination, and Ordering Functions over the DODAG that forms the Track, and it's giving main character energy ๐ .
The Replication function in the 6TiSCH Node sends a copy of each packet over two different branches. The PCE then schedules every hop of both branches so the two copies reach the gateway in due time ๐ฐ๏ธ. If one branch loses a packet, the other copy hopefully still makes it on time ๐ค. When two copies do arrive, the Elimination function in the gateway throws away the extra one and only hands one copy up to the upper layers โจ.
+-=-=-+
| IoT |
| G/W |
+-=-=-+
^ <=== Elimination
Track branch | |
+-=-=-=-+ +-=-=-=-=+ Subnet backbone
| |
+-=|-=+ +-=|-=+
| | | Backbone | | | Backbone
o | | | Router | | | Router
+-=/-=+ +-=|-=+
o / o o-=-o-=-=/ o
o o-=-o-=/ o o o o o
o \ / o o LLN o
o v <=== Replication
o
Figure 10: Example End-to-End DetNet Track4.5.5. Cell Reuse ๐
Okay bestie, 6TiSCH has a way to stop cells from going to waste and to stop the transmit bundle of a Track from overflowing ๐ซถ. Here's how it works:
A TX-cell that isn't needed for the current iteration may be reused opportunistically on a per-hop basis for routed packets ๐ธ. Once every frame received for a given Track has effectively been transmitted, any available TX-cell for that Track can be reused for upper-layer traffic whose next-hop router matches the next hop along the Track. In that case the cell is effectively still a TX-cell from the Track, but the short address for the destination is the one of the next-hop router ๐.
This results in a frame that lands in an RX-cell of a Track with a destination MAC address set to this node, instead of the broadcast MAC address. The broadcast one is the kind that must be pulled out of the Track and delivered to the upper layer. Also, a frame with an unrecognized destination MAC address gets dropped at the lower MAC layer, so it never reaches the 6top sublayer ๐.
Now the other side of things: sometimes there just aren't enough TX-cells in the transmit bundle for the Track traffic, for example when more retransmissions are needed than were provisioned ๐ญ. In that case, and if the frame carries an IPv6 packet, it can be placed for transmission in the bundle used for Layer 3 traffic toward the next hop along the Track. The MAC address should be set to the next-hop MAC address to avoid confusion ๐ง.
This results in a frame received over a Layer 3 bundle that may actually be associated with a Track. On a classical IP link like Ethernet, off-Track traffic is usually just excess over the reservation, routed along the non-reserved path based on its QoS setting. But with 6TiSCH, the Layer 3 bundle might be getting used because transmissions failed, so it makes sense for the receiver to recognize a frame that should be re-Tracked and put it back on the appropriate bundle if possible ๐ โจ. A frame is re-Tracked by scheduling it for transmission over the transmit bundle associated with the Track, with the destination MAC address set to broadcast ๐ฆ.
4.6. Forwarding Models ๐งญ
Okay so by forwarding, this document means the per-packet operation that lets a packet get delivered to a next hop or to an upper layer in this node ๐ฆ. Forwarding is based on preexisting state that was installed as a result of a routing computation, see Section 4.7 ๐บ๏ธ. 6TiSCH supports three different forwarding models: (GMPLS) Track Forwarding, (classical) IPv6 Forwarding, and (6LoWPAN) Fragment Forwarding ๐.
4.6.1. Track Forwarding ๐
Forwarding along a Track can be seen as a Generalized Multiprotocol Label Switching (GMPLS) operation ๐. The thing used to switch a frame isn't an explicit label. It's related to other properties of how the packet was received, which in 6TiSCH means a particular cell ๐. So as long as the TSCH MAC (and Layer 2 security) accepts a frame, that frame can be switched no matter the protocol. That includes an IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate protocol such as WirelessHART or ISA100.11a ๐ซถ.
A data frame forwarded along a Track normally has its destination MAC address set to broadcast or to a multicast address, depending on what the MAC supports ๐. This way the MAC layer in the intermediate nodes accepts the incoming frame, and 6top switches it without changing the MAC header โจ. With IEEE Std 802.15.4, that effectively means broadcast, so along the Track the short address for the destination of the frame is set to 0xFFFF ๐.
There are two modes for a Track: an IPv6 native mode and a protocol-independent tunnel mode ๐ฆ.
4.6.1.1. Native Mode ๐
In native mode, the Protocol Data Unit (PDU) is associated with flow-dependent metadata that refers uniquely to the Track. That means the 6top sublayer can put the frame in the right cell with no confusion ๐ฏ. For IPv6 traffic, this flow may be identified using a 6-tuple, as discussed in [RFC8939]. Also, implementations of this document should support identification of DetNet flows based on the IPv6 Flow Label field ๐ท๏ธ.
The flow follows a Track that is identified using a RPL Instance (see Section 3.1.3 of [RFC6550]). That instance is signaled in a RPL Packet Information (more in Section 11.2.2.1 of [RFC6550]), along with the source address of a packet going down the DODAG formed by a local instance ๐ณ. One or more flows may be placed in the same Track, and the Track identification (TrackID plus owner) may be placed in an IP-in-IP encapsulation ๐ฎ. The forwarding operation is based on the Track and does not depend on the flow inside it ๐.
The Track identification is validated at egress before the destination MAC address (DMAC) gets restored and the packet is punted to the upper layer ๐ฌ.
Figure 11 shows the Track Forwarding operation that happens at the 6top sublayer, below IP ๐.
| Packet flowing across the network ^
+--------------+ | |
| IPv6 | | |
+--------------+ | |
| 6LoWPAN HC | | |
+--------------+ ingress egress
| 6top | sets +----+ +----+ restores
+--------------+ DMAC to | | | | DMAC to
| TSCH MAC | brdcst | | | | dest
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Ingress Relay Relay Egress
Stack Layer Node Node Node Node
Figure 11: Track Forwarding, Native Mode4.6.1.2. Tunnel Mode ๐
In tunnel mode, the frames come from an arbitrary protocol over a compatible MAC, and that MAC may or may not be synchronized with the 6TiSCH network ๐. For example, picture a router with a dual radio that can receive and send WirelessHART or ISA100.11a frames. The second radio presents itself as an access point or a Backbone Router, respectively ๐ก. In that mode, some entity (e.g., PCE) can coordinate with a WirelessHART Network Manager or an ISA100.11a System Manager to specify which flows get transported ๐ค.
+--------------+
| IPv6 |
+--------------+
| 6LoWPAN HC |
+--------------+ set restore
| 6top | +DMAC+ +DMAC+
+--------------+ to|brdcst to|nexthop
| TSCH MAC | | | | |
+--------------+ | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ | ingress egress |
| |
+--------------+ | |
| LLN PHY | | |
+--------------+ | Packet flowing across the network |
| TSCH MAC | | |
+--------------+ | DMAC = | DMAC =
|ISA100/WiHART | | nexthop v nexthop
+--------------+
Source Ingress Egress Destination
Stack Layer Node Node Node Node
Figure 12: Track Forwarding, Tunnel ModeIn that case, the TrackID that identifies the Track at the ingress 6TiSCH router is derived from the RX-cell ๐. The DMAC is set to this node, but the TrackID says the frame must be tunneled over a particular Track. So the frame isn't passed to the upper layer โ. Instead, the DMAC is forced to broadcast, and the frame goes to the 6top sublayer for switching ๐.
At the egress 6TiSCH router, the reverse operation happens ๐. Based on the tunneling information of the Track, which may indicate for instance that the tunneled datagram is an IP packet, the datagram is passed to the appropriate link-layer with the destination MAC restored ๐.
4.6.1.3. Tunneling Information ๐
Tunneling information that comes with the Track configuration gives you the destination MAC address of the egress endpoint, plus the tunnel mode and whatever specific data that mode needs. For instance, that could be a service access point for frame delivery at egress ๐งพ.
If the tunnel egress point doesn't have a MAC address that matches the configuration, the Track installation fails ๐.
If the Layer 3 destination address belongs to the tunnel termination, the IPv6 address of the destination might get compressed at the 6LoWPAN sublayer based on the MAC address ๐งฉ. Restoring the wrong MAC address at egress would then also produce the wrong IP address in the packet after decompression ๐ฑ. That's why a packet can only be injected in a Track if the destination MAC address is effectively that of the tunnel egress point. So it is mandatory for the ingress router to validate that the MAC address used at the 6LoWPAN sublayer for compression matches the one of the tunnel egress point before it overwrites it to broadcast ๐ก๏ธ. The 6top sublayer at the tunnel egress point then reverts that operation back to the MAC address obtained from the tunnel information ๐ฅณ.
4.6.2. IPv6 Forwarding ๐ฆ
okay so once packets are routed at Layer 3, the traditional QoS and Active Queue Management (AQM) stuff is expected to prioritize flows ๐ it's giving traffic cop energy, and the diagram below shows where it all happens โจ
| Packet flowing across the network ^
+--------------+ | |
| IPv6 | | +-QoS+ +-QoS+ |
+--------------+ | | | | | |
| 6LoWPAN HC | | | | | | |
+--------------+ | | | | | |
| 6top | | | | | | |
+--------------+ | | | | | |
| TSCH MAC | | | | | | |
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Source Ingress Egress Destination
Stack Layer Node Router Router Node
Figure 13: IP Forwarding4.6.3. Fragment Forwarding ๐งฉ
okay this one is a whole saga, bestie ๐ญ per Section 4 of [RFC4944], 6LoWPAN packets can be as large as 1280 bytes (the IPv6 minimum MTU). and since the non-storing mode of RPL implies source routing, which needs room for routing headers, plus an IEEE Std 802.15.4 frame with security may only carry in the order of 80 bytes of effective payload, an IPv6 packet might get fragmented into more than 16 fragments at the 6LoWPAN sublayer. that is a LOT of pieces ๐
this level of fragmentation is way higher than what we usually see on the Internet with IPv4 fragments, where fragmentation is already known as harmful ๐
in a multihop route within a 6TiSCH network, hop-by-hop recomposition happens at each hop so the packet can be reformed and routed. this adds latency and forces intermediate nodes to store a portion of a packet for an undetermined time, which hits critical resources like memory and battery ๐ not it being so messy ngl
[RFC8930] describes a framework for forwarding fragments end-to-end across a 6TiSCH route-over mesh ๐ inside that framework, [VIRTUAL-REASSEMBLY] details a virtual reassembly buffer mechanism where the datagram tag in the 6LoWPAN fragment is used as a label for switching at the 6LoWPAN sublayer. the main character move here is the label doing all the work โจ
building on this technique, [RFC8931] introduces a new format for 6LoWPAN fragments that enables selective recovery of individual fragments and allows a degree of flow control based on an Explicit Congestion Notification (ECN) ๐
| Packet flowing across the network ^
+--------------+ | |
| IPv6 | | +----+ +----+ |
+--------------+ | | | | | |
| 6LoWPAN HC | | learn learn |
+--------------+ | | | | | |
| 6top | | | | | | |
+--------------+ | | | | | |
| TSCH MAC | | | | | | |
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Source Ingress Egress Destination
Stack Layer Node Router Router Node
Figure 14: Forwarding First Fragmentin that model, the first fragment gets routed based on the IPv6 header that is present in that fragment. the 6LoWPAN sublayer learns the next-hop selection, generates a new datagram tag for transmission to the next hop, and stores that info indexed by the incoming MAC address and datagram tag. then the next fragments get switched based on that stored state, so the lookup is basically pre-cooked ๐ง
| Packet flowing across the network ^
+--------------+ | |
| IPv6 | | |
+--------------+ | |
| 6LoWPAN HC | | replay replay |
+--------------+ | | | | | |
| 6top | | | | | | |
+--------------+ | | | | | |
| TSCH MAC | | | | | | |
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Source Ingress Egress Destination
Stack Layer Node Router Router Node
Figure 15: Forwarding Next Fragmenta bitmap and an ECN echo in the end-to-end acknowledgment let the source resend the missing fragments selectively, which is so efficient it's iconic ๐ซถ the first fragment may be resent to carve a new path if there's a path failure. and if the ECN echo is set, it means the number of outstanding fragments should be reduced ๐ธ
4.7. Advanced 6TiSCH Routing ๐
4.7.1. Packet Marking and Handling ๐ท๏ธ
all packets inside a 6TiSCH domain must carry the RPLInstanceID that identifies the 6TiSCH topology (e.g., a Track) that is to be used for routing and forwarding that packet ๐ the location of that info must be the same for all packets forwarded inside the domain, so everyone is on the same page.
for packets that are routed by a PCE along a Track, the tuple formed by 1) (typically) the IPv6 source or (possibly) destination address in the IPv6 header and 2) a local RPLInstanceID in the RPI that serves as TrackID, identifies the Track and its associated transmit bundle uniquely. that is a very specific combo, and I'm obsessed ๐ญ
for packets that are routed by RPL, that info is the RPLInstanceID carried in the RPL Packet Information (RPI), as discussed in Section 11.2 of [RFC6550], "Loop Avoidance and Detection". the RPI rides along in a RPL Option in the IPv6 Hop-By-Hop Options header [RFC6553] ๐ฆ
there's also a compression mechanism for the RPL packet artifacts ๐๏ธ it squishes together the compression of IP-in-IP encapsulation and the Routing Header type 3 [RFC6554] with that of the RPI, in a 6LoWPAN dispatch/header type. that's specified in [RFC8025] and [RFC8138], so go check those out, they're literally the blueprint ๐
either way, the method and format used for encoding the RPLInstanceID is generalized to all 6TiSCH topological Instances, which include both RPL Instances and Tracks. one encoding to rule them all, periodt ๐ โจ
4.7.2. Replication, Retries, and Elimination โจ
okay bestie, 6TiSCH totally supports PREOF ๐ (that's elimination and reordering of packets along a complex Track), but it does not need a sequence number tagged onto the packet for that. ๐ The schedule does the work instead. It can tell when several receive timeslots are copies of the same packet, so the receiver may skip listening to the extra copies once it has gotten one instance of the packet. ๐ง
the config lets you group correlated timeslots for transmit (and for receive, same energy) with 'OR' relations ๐ฏ, and then you can set an 'AND' relation between the groups ๐. if an operation succeeds in one timeslot inside an 'OR' group, every other timeslot in that group gets ignored โจ. and if there are at least two groups, the 'AND' relation means one operation must succeed in each of the groups. ๐
on the transmit side, timeslots provisioned for retries along the same branch of a Track go into the same 'OR' group. the vibe is that if a transmission gets acknowledged, you should not attempt retransmissions of that packet for the remaining timeslots in that group. ๐ โโ๏ธ there are as many 'OR' groups as there are branches of the Track leaving this node, and each group matches one branch. different 'OR' groups are set up for replication. the 'AND' relation between the groups says transmission over any of the branches must be attempted, no matter whether it succeeded on another branch. ๐ฅ you can also put cells to different next-hop routers in the same 'OR' group. that lets you route along multipath Tracks, trying one next hop and then the next one only if sending to the first one fails. ๐ฆ
on the receive side, all timeslots go in the same 'OR' group. retries of the same copy and converging branches for elimination all get merged, so the first successful reception is enough and you can ignore everything else. ๐ an 'AND' group stands for different packets that must all be received and transmitted over the associated transmit groups, following their respective 'AND' or 'OR' rules. ๐
okay so, picture a simple network like Figure 16, and we want PREOF between an ingress node I and an egress node E. ๐
+-+ +-+
-- |A| ------ |C| --
/ +-+ +-+ \
/ \
+-+ +-+
|I| |E|
+-+ +-+
\ /
\ +-+ +-+ /
-- |B| ------- |D| --
+-+ +-+
Figure 16: Scheduling PREOF on a Simple Networkthe assumption here is that a 6TiSCH node has a single radio, so it cannot do two receive and/or transmit operations at the same time, even on two different channels. ๐ป (no multitasking, sorry, it's a whole vibe ๐ญ)
say we have six possible channels and at least ten timeslots per slotframe. Figure 17 shows a possible schedule where each transmission gets retried two or three times, and redundant copies get forwarded in parallel via A and C on one side, and B and D on the other. that gives you time diversity, spatial diversity through different physical paths, and frequency diversity. ๐ธ
slotOffset 0 1 2 3 4 5 6 7 9
+----+----+----+----+----+----+----+----+----+
channelOffset 0 | | | | | | |B->D| | | ...
+----+----+----+----+----+----+----+----+----+
channelOffset 1 | |I->A| |A->C|B->D| | | | | ...
+----+----+----+----+----+----+----+----+----+
channelOffset 2 |I->A| | |I->B| |C->E| |D->E| | ...
+----+----+----+----+----+----+----+----+----+
channelOffset 3 | | | | |A->C| | | | | ...
+----+----+----+----+----+----+----+----+----+
channelOffset 4 | | |I->B| | |B->D| | |D->E| ...
+----+----+----+----+----+----+----+----+----+
channelOffset 5 | | |A->C| | | |C->E| | | ...
+----+----+----+----+----+----+----+----+----+
Figure 17: Example Global Schedulethis then turns into a separate slotframe for every node, which tells it when to wake up and sleep, plus the channelOffset to use while awake. โฐ Figure 18 is the slotframe for node A. ๐ฆข
slotOffset 0 1 2 3 4 5 6 7 9
+----+----+----+----+----+----+----+----+----+
operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ...
+----+----+----+----+----+----+----+----+----+
channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ...
+----+----+----+----+----+----+----+----+----+
Figure 18: Example Slotframe for Node Athe logical relationship between the timeslots is laid out in Table 2 ๐:
+======+====================+=======================+
| Node | rcv slotOffset | xmit slotOffset |
+======+====================+=======================+
| I | N/A | (0 OR 1) AND (2 OR 3) |
+------+--------------------+-----------------------+
| A | (0 OR 1) | (2 OR 3 OR 4) |
+------+--------------------+-----------------------+
| B | (2 OR 3) | (4 OR 5 OR 6) |
+------+--------------------+-----------------------+
| C | (2 OR 3 OR 4) | (5 OR 6) |
+------+--------------------+-----------------------+
| D | (4 OR 5 OR 6) | (7 OR 8) |
+------+--------------------+-----------------------+
| E | (5 OR 6 OR 7 OR 8) | N/A |
+------+--------------------+-----------------------+
Table 25. IANA Considerations ๐
good news: this document has no IANA actions. ๐ธ
6. Security Considerations ๐
the "Minimal Security Framework for 6TiSCH" [RFC9031] was built for Low-Power and TSCH operations ๐. go read the Security Considerations section of that doc (Section 9), which gets into 6TiSCH security issues in more detail. ๐ซถ
6.1. Availability of Remote Services
6TiSCH Tracks inherit their high-level operation from DetNet ๐ง , so they're subject to the observations in Section 5 of [RFC8655]. installing and maintaining 6TiSCH Tracks depends on having a controller with a PCE to compute them and push them into the network. when that connectivity is lost, existing Tracks may keep running until the end of their lifetime, but they cannot be removed or updated, and new Tracks cannot be installed. ๐ญ
in an LLN ๐ก, talking to a remote PCE can be slow and not very reactive when wireless conditions change fast. an attacker can add extra delay by selectively jamming some packets or some flows ๐. the expectation is that 6TiSCH Tracks have enough redundancy to keep critical traffic running while new routes get calculated and programmed into the network. ๐ช
just like DetNet in general, the communication with the PCE must be secured and should be protected against DoS attacks, including delay injection and blackholing attacks, and secured as discussed in the security considerations for Abstraction and Control of Traffic Engineered Networks (ACTN) in Section 9 of [RFC8453], which applies equally to DetNet and 6TiSCH. in a similar way, the communication with the JRC must be secured and should be protected against DoS attacks when possible. ๐
6.2. Selective Jamming
the hopping sequence of a TSCH network is well known. that means if a rogue manages to identify a cell of a particular flow, it may selectively jam that cell without touching any other traffic. ๐ this attack can be done at the PHY layer without any knowledge of the Layer 2 keys, and it is super hard to detect and diagnose because only one flow gets hit. ๐จ
[ROBUST-SCHEDULING] proposes a method to obfuscate the hopping sequence and make it harder to pull off that particular attack. ๐ต๏ธโโ๏ธ
6.3. MAC-Layer Security
this architecture operates on IEEE Std 802.15.4 and expects link-layer security to be enabled at all times between connected devices. the one exception is the very first step of the device join process, where a joining device may need some initial, unsecured exchanges to obtain its initial key material. ๐๏ธ in a typical deployment, all joined nodes use the same keys, and rekeying needs to be global. ๐
the 6TISCH architecture relies on the join process to deny authorization to invalid nodes and to preserve the integrity of the network keys. a rogue that gets into the network can do a huge variety of attacks, from DoS to injecting forged packets and routing information. โ ๏ธ "Zero-trust" properties would be highly desirable, but they are mostly not available at the time of this writing. [RFC8928] is a notable exception. it protects the ownership of IPv6 addresses and stops a rogue node with L2 access from stealing and injecting traffic on behalf of a legitimate node. ๐ก๏ธโจ
6.4. Time Synchronization โฐ
Okay so time sync in TSCH creates another event horizon ๐. A node will only talk to another node if they're synchronized within a guard time. The pledge figures out how the network's sync is doing from when it receives a beacon ๐ก. If an attacker pushes a pledge outside the guard time of the legit nodes, the pledge will never catch a legitimate beacon, and it may not even spot the attack ๐ญ.
As discussed in [RFC8655], measures must be taken to protect the time synchronization ๐ก๏ธ. For 6TiSCH, that includes making sure the Absolute Slot Number (ASN), which is the node's sense of time, isn't compromised ๐ฐ๏ธ. Once it's installed and the node is synced to the network, the ASN is implicit in the transmissions โจ.
IEEE Std 802.15.4 [IEEE802154] says that in a TSCH network, the nonce used to compute the Message Integrity Code (MIC) that secures link-layer frames is made from the source address of the frame and the ASN ๐. The standard assumes the ASN is distributed securely by other means ๐ค. The ASN isn't passed explicitly in the data frames, and it doesn't count as complete anti-replay protection ๐.
As a result, upper-layer protocols must provide a way to detect duplicates and cope with them ๐งฉ.
If the receiver and the sender have a different sense of ASN, the MIC won't validate and the frame gets dropped ๐๏ธ. So TSCH is giving event horizon energy again: only nodes with a common sense of ASN can talk to one another in an authenticated manner ๐ซถ. With 6TiSCH, the pledge discovers a tentative ASN in beacons from nodes that have already joined the network ๐ถ. But even if the beacon can be authenticated, the ASN can't be trusted, because it could be a replay by an attacker announcing an ASN that represents a time in the past โช. If the pledge uses an ASN learned from a replayed beacon for an encrypted transmission, a nonce-reuse attack becomes possible, and the network keys may be compromised ๐.
6.5. Validating ASN ๐
After getting the tentative ASN, a pledge that wants to join the 6TiSCH network must use a join protocol to obtain its security keys ๐. The join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP). In the minimal setting defined in [RFC9031], authentication requires a pre-shared key, and a secure session is derived from it ๐ง. The CoJP exchange may also be preceded by a zero-touch handshake [ZEROTOUCH-JOIN], so pledges can join based on certificates and/or inter-domain communication ๐.
As detailed in Section 4.2.1, a Join Proxy (JP) helps the pledge with the join procedure. It relays the link-scope Join Request over the IP network to a Join Registrar/Coordinator (JRC), which can authenticate the pledge and validate that it's attached to the appropriate network ๐งโ๐คโ๐ง. As a result of the CoJP exchange, the pledge has link-layer material including keys and a short address ๐๏ธ. If the ASN is known to be correct, all traffic can now be secured using CCM* [CCMstar] at the link layer ๐.
The authentication steps must be such that they cannot be replayed by an attacker, and they must not depend on the tentative ASN being valid ๐ซ. During the authentication, the keying material that the pledge obtains from the JRC does not provide protection against spoofed ASN ๐ฌ. Once the pledge has obtained the keys to use in the network, it may still need to verify the ASN ๐.
If the nonce used in the Layer 2 security derives from the extended (MAC-64) address, then replaying the ASN alone can't enable a nonce-reuse attack, unless the same node has lost its state with a previous ASN ๐ง . But if the nonce derives from the short address (e.g., assigned by the JRC), then the JRC must ensure that it never assigns short addresses that were already given to this or other nodes with the same keys ๐. In other words, the network must be rekeyed before the JRC runs out of short addresses โป๏ธ.
6.6. Network Keying and Rekeying ๐
Section 4.2.1 gives an overview of the CoJP process described in [RFC9031], which is how an LLN gets assembled in the field after being provisioned in a lab ๐งช. [ZEROTOUCH-JOIN] is future work that comes before CoJP and then builds on it, using the [CONSTRAINED-VOUCHER] constrained profile of [RFC8995]. This later work requires a yet-to-be standardized Lightweight Authenticated Key Exchange protocol ๐ง.
CoJP results in distribution of a network-wide key that is to be used with [IEEE802154] security ๐. The details of use are described in [RFC9031], Sections 9.2 and 9.3.2 ๐.
The BRSKI mechanism may lead to the use of CoJP, in which case it also results in distribution of a network-wide key ๐. Alternatively, the BRSKI mechanism may be followed by use of [EST-COAPS] to enroll certificates for each device ๐. In that case, the certificates may be used with an [IEEE802154] key agreement protocol. The description of this mechanism, while conceptually straightforward, still has significant standardization hurdles to pass ๐.
Section 8.2 of [RFC9031] describes a mechanism to change (rekey) the network ๐. There are a number of reasons to initiate a network rekey: to remove unwanted (corrupt/malicious) nodes, to recover unused 2-byte short addresses, or due to limits in encryption algorithms. For all of the mechanisms that distribute a network-wide key, rekeying is also needed on a periodic basis. In more detail:
- The mechanism described in Section 8.2 of [RFC9031] requires advance communication between the JRC and every one of the nodes before the key change ๐ก. Given that many nodes may be sleepy ๐ด, this operation may take a significant amount of time and may eat up a significant portion of the available bandwidth. So network-wide rekeys to exclude nodes that have turned malicious won't be particularly quick ๐ข. If a rekey is already in progress but the unwanted node has not yet been updated, then it's possible to just continue the operation. If the unwanted node has already received the update, then the rekey operation will need to be restarted ๐.
- The cryptographic mechanisms used by IEEE Std 802.15.4 include the 2-byte short address in the calculation of the context. A nonce-reuse attack may become feasible if a short address is reassigned to another node while the same network-wide keys are in operation ๐. A network that gains and loses nodes on a regular basis is likely to reach the 65536 limit of the 2-byte (16-bit) short addresses, even if the network has only a few thousand nodes ๐คฏ. Network planners should consider the need to rekey the network on a periodic basis in order to recover 2-byte addresses ๐๏ธ. The rekey can update the short addresses for active nodes if desired, but there is actually no need to do this as long as the key has been changed ๐ซ.
- With TSCH as it stands at the time of this writing, the ASN will wrap after 2^40 timeslot durations, meaning around 350 years with the default values โณ. Wrapping ASN is not expected to happen within the lifetime of most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid a nonce-reuse attack ๐.
- Many cipher algorithms have some suggested limits on how many bytes should be encrypted with that algorithm before a new key is used ๐งฎ. These numbers are typically in the many to hundreds of gigabytes of data. On very fast backbone networks, this becomes an important concern ๐๏ธ. On LLNs with typical data rates in the kilobits/second, this concern is significantly less. With IEEE Std 802.15.4 as it stands at the time of this writing, the ASN will wrap before the limits of the current L2 crypto (AES-CCM-128) are reached, so the problem should never occur ๐.
- In any fashion, if the LLN is expected to operate continuously for decades, then the operators are advised to plan for the need to rekey ๐ธ.
Except for urgent rekeys caused by malicious nodes, the rekey operation described in [RFC9031] can be done as a background task and can be done incrementally ๐. It is a make-before-break mechanism. The switch over to the new key is not signaled by time, but rather by observation that the new key is in use ๐. As such, the update can take as long as needed, or occur in as short a time as practical ๐.
7. References ๐
7.1. Normative References
okay bestie, these are the normative references ๐โจ the docs you need to read alongside this one to get the full picture ๐
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<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>.
[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012,
<https://www.rfc-editor.org/info/rfc6552>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>.
[RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information
Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May
2017, <https://www.rfc-editor.org/info/rfc8137>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Protocol (6P)", RFC 8480,
DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
November 2020, <https://www.rfc-editor.org/info/rfc8929>.
[RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On
Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6
Network", RFC 8930, DOI 10.17487/RFC8930, November 2020,
<https://www.rfc-editor.org/info/rfc8930>.
[RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Selective Fragment Recovery",
RFC 8931, DOI 10.17487/RFC8931, November 2020,
<https://www.rfc-editor.org/info/rfc8931>.
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes, and IPv6-
in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>.
[RFC9031] Vuฤiniฤ, M., Ed., Simon, J., Pister, K., and M.
Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
RFC 9031, DOI 10.17487/RFC9031, May 2021,
<https://www.rfc-editor.org/info/rfc9031>.
[RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of
6TiSCH Join and Enrollment Information Elements",
RFC 9032, DOI 10.17487/RFC9032, May 2021,
<https://www.rfc-editor.org/info/rfc9032>.
[RFC9033] Chang, T., Ed., Vuฤiniฤ, M., Vilajosana, X., Duquennoy,
S., and D. Dujovne, "6TiSCH Minimal Scheduling Function
(MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021,
<https://www.rfc-editor.org/info/rfc9033>.7.2. Informative References
these ones are the extra-credit reading ๐ง๐ background stuff, more context, and a few drafts that were still works in progress when this was written ๐ธ
[AMI] U.S. 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 Approach
(anima)",
<https://datatracker.ietf.org/doc/charter-ietf-anima/>.
[AODV-RPL] Anamalamudi, S., Zhang, M., Perkins, C. E., Anand, S., and
B. Liu, "Supporting Asymmetric Links in Low Power
Networks: AODV-RPL", Work in Progress, Internet-Draft,
draft-ietf-roll-aodv-rpl-10, 4 April 2021,
<https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-10>.
[AODVv2] Perkins, C. E., Ratliff, S., Dowdell, J., Steenbrink, L.,
and V. Mercieca, "Ad Hoc On-demand Distance Vector Version
2 (AODVv2) Routing", Work in Progress, Internet-Draft,
draft-ietf-manet-aodvv2-16, 4 May 2016,
<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-16>.
[BITSTRINGS-6LORH]
Thubert, P., Ed., Brodard, Z., Jiang, H., and G. Texier,
"A 6loRH for BitStrings", Work in Progress, Internet-
Draft, draft-thubert-6lo-bier-dispatch-06, 28 January
2019, <https://tools.ietf.org/html/draft-thubert-6lo-bier-
dispatch-06>.
[CCAMP] IETF, "Common Control and Measurement Plane (ccamp)",
<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[CCMstar] Struik, R., "Formal Specification of the CCM* Mode of
Operation", September 2004, <http://www.ieee802.org/15/
pub/2004/15-04-0537-00-004b-formal-specification-ccm-star-
mode-operation.doc>.
[CONSTRAINED-VOUCHER]
Richardson, M., van der Stok, P., and P. Kampanakis,
"Constrained Voucher Artifacts for Bootstrapping
Protocols", Work in Progress, Internet-Draft, draft-ietf-
anima-constrained-voucher-10, 21 February 2021,
<https://tools.ietf.org/html/draft-ietf-anima-constrained-
voucher-10>.
[DAO-PROJECTION]
Thubert, P., Jadhav, R. A., and M. Gillmore, "Root
initiated routing state in RPL", Work in Progress,
Internet-Draft, draft-ietf-roll-dao-projection-16, 15
January 2021, <https://tools.ietf.org/html/draft-ietf-
roll-dao-projection-16>.
[EDHOC] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", Work in Progress,
Internet-Draft, draft-selander-ace-cose-ecdhe-14, 11
September 2019, <https://tools.ietf.org/html/draft-
selander-ace-cose-ecdhe-14>.Okay bestie, here's the rest of the informative squad ๐ Every entry is copied word for word, so you can go hunt them down yourself ๐๐ธ
[EST-COAPS]
van der Stok, P., Kampanakis, P., Richardson, M., and S.
Raza, "EST over secure CoAP (EST-coaps)", Work in
Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6
January 2020,
<https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>.
[HART] FieldComm Group, "HART",
<https://fieldcommgroup.org/technologies/hart>.
[IEC62439] IEC, "Industrial communication networks - High
availability automation networks - Part 3: Parallel
Redundancy Protocol (PRP) and High-availability Seamless
Redundancy (HSR)", IEC 62439-3:2016, 2016,
<https://webstore.iec.ch/publication/24438>.
[IEEE802154]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
Standard 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
April 2016,
<https://ieeexplore.ieee.org/document/7460875>.
[IEEE802154e]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE
Standard 802.15.4e-2012, DOI 10.1109/IEEESTD.2012.6185525,
April 2012,
<https://ieeexplore.ieee.org/document/6185525>.
[ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation",
<https://www.isa.org/isa100/>.
[ISA100.11a]
ISA/ANSI, "Wireless Systems for Industrial Automation:
Process Control and Related Applications - ISA100.11a-
2011", IEC 62734:2014, 2011,
<https://webstore.iec.ch/publication/65581>.
[ND-UNICAST-LOOKUP]
Thubert, P., Ed. and E. Levy-Abegnoli, "IPv6 Neighbor
Discovery Unicast Lookup", Work in Progress, Internet-
Draft, draft-thubert-6man-unicast-lookup-00, 29 July 2019,
<https://tools.ietf.org/html/draft-thubert-6man-unicast-
lookup-00>.
[PCE] IETF, "Path Computation Element (pce)",
<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[RAW-ARCHITECTURE]
Thubert, P., Ed. and G. Z. Papadopoulos, "Reliable and
Available Wireless Problem Statement", Work in Progress,
Internet-Draft, draft-pthubert-raw-architecture-05, 15
November 2020, <https://tools.ietf.org/html/draft-
pthubert-raw-architecture-05>.
[RAW-USE-CASES]
Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
Bernardos, "RAW use cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-01, 21 February 2021,
<https://tools.ietf.org/html/draft-ietf-raw-use-cases-01>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999,
<https://www.rfc-editor.org/info/rfc2545>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, DOI 10.17487/RFC4080, June 2005,
<https://www.rfc-editor.org/info/rfc4080>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010,
<https://www.rfc-editor.org/info/rfc5974>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration Option for
the 6LoWPAN Routing Header", RFC 9035,
DOI 10.17487/RFC9035, April 2021,
<https://www.rfc-editor.org/info/rfc9035>.
[ROBUST-SCHEDULING]
Tiloca, M., Duquennoy, S., and G. Dini, "Robust Scheduling
against Selective Jamming in 6TiSCH Networks", Work in
Progress, Internet-Draft, draft-tiloca-6tisch-robust-
scheduling-02, 10 June 2019, <https://tools.ietf.org/html/
draft-tiloca-6tisch-robust-scheduling-02>.
[RPL-APPLICABILITY]
Phinney, T., Ed., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", Work in Progress,
Internet-Draft, draft-ietf-roll-rpl-industrial-
applicability-02, 21 October 2013,
<https://tools.ietf.org/html/draft-ietf-roll-rpl-
industrial-applicability-02>.
[RPL-BIER] Thubert, P., Ed., "RPL-BIER", Work in Progress, Internet-
Draft, draft-thubert-roll-bier-02, 24 July 2018,
<https://tools.ietf.org/html/draft-thubert-roll-bier-02>.
[RPL-MOP] Jadhav, R., Ed., Thubert, P., Richardson, M., and R.
Sahoo, "RPL Capabilities", Work in Progress, Internet-
Draft, draft-ietf-roll-capabilities-08, 17 March 2021,
<https://tools.ietf.org/html/draft-ietf-roll-capabilities-
08>.
[S-ALOHA] Roberts, L. G., "ALOHA packet system with and without
slots and capture", ACM SIGCOMM Computer Communication
Review, DOI 10.1145/1024916.1024920, April 1975,
<https://dl.acm.org/citation.cfm?id=1024920>.
[TE-PREF] Thubert, P., Ed., Eckert, T., Brodard, Z., and H. Jiang,
"BIER-TE extensions for Packet Replication and Elimination
Function (PREF) and OAM", Work in Progress, Internet-
Draft, draft-thubert-bier-replication-elimination-03, 3
March 2018, <https://tools.ietf.org/html/draft-thubert-
bier-replication-elimination-03>.
[TEAS] IETF, "Traffic Engineering Architecture and Signaling
(teas)",
<https://datatracker.ietf.org/doc/charter-ietf-teas/>.
[VIRTUAL-REASSEMBLY]
Bormann, C. and T. Watteyne, "Virtual reassembly buffers
in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-
lwig-6lowpan-virtual-reassembly-02, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-
virtual-reassembly-02>.
[WirelessHART]
International Electrotechnical Commission, "Industrial
networks - Wireless communication network and
communication profiles - WirelessHART(TM)",
IEC 62591:2016, March 2016,
<https://webstore.iec.ch/publication/24433>.
[ZEROTOUCH-JOIN]
Richardson, M., "6tisch Zero-Touch Secure Join protocol",
Work in Progress, Internet-Draft, draft-ietf-6tisch-
dtsecurity-zerotouch-join-04, 8 July 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-
zerotouch-join-04>.Appendix A. Related Work in Progress ๐ฆ
Okay so this bit is basically a sneak peek at the stuff that's still cooking ๐ณ This document got bumped along as the working group (WG) charter kept evolving and as the work it depends on became available. The plan was to publish once the WG wrapped up the covered items, but at publish time these specs are still in progress and could change how the stack looks on a 6TiSCH-aware node ๐โจ
A.1. Unchartered IETF Work Items
A.1.1. 6TiSCH Zero-Touch Security โจ
okay so the security model, and especially the zero-touch join process [ZEROTOUCH-JOIN], leans on the ANIMA (Autonomic Networking Integrated Model and Approach) [ANIMA] "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" [RFC8995] to get zero-touch security provisioning going ๐. for super constrained nodes there's also a minimal model based on pre-shared keys (PSK), so nobody gets left out ๐ซถ. bestie, it's also giving dependency drama: as it's written right now, it relies on a bunch of docs still in progress in the CORE (Constrained RESTful Environments) WG, plus "Ephemeral Diffie-Hellman Over COSE (EDHOC)" [EDHOC], which the LAKE (Lightweight Authenticated Key Exchange) WG might adopt ๐
A.1.2. 6TiSCH Track Setup ๐ฆ
ROLL (Routing Over Low power and Lossy networks) is now standardizing a reactive routing protocol based on RPL [AODV-RPL] ๐ธ. the whole point is that a reactive routing protocol can set up on-demand, constraint-optimized routes, and there's a reservation protocol to set up Layer 3 Tracks too. this is being discussed in 6TiSCH but it's not chartered yet, so it's still in the "maybe soon" zone โณ
as of writing, there's new work planned in the IETF for limited deterministic networking on wireless networks ๐ฅ. the focus is on forwarding behaviors that react quickly and locally to changes, as described in [RAW-ARCHITECTURE] ๐
ROLL is also standardizing an RPL extension for setting up centrally computed routes [DAO-PROJECTION] ๐ง
the 6TiSCH architecture should inherit from the DetNet architecture [RFC8655], so it depends on it ๐. the PCE should be a core component of that architecture ๐. an extension to RPL or to TEAS (Traffic Engineering Architecture and Signaling) [TEAS] will be required so the 6TiSCH node capabilities and network peers can be exposed to the PCE, possibly combined with [RPL-MOP] ๐. then a lightweight Path Computation Element Communication Protocol (PCEP), or an adaptation of Common Control and Measurement Plane (CCAMP) [CCAMP] GMPLS formats and procedures, could be used together with [DAO-PROJECTION] to install the Tracks, as computed by the PCE, onto the 6TiSCH nodes ๐
A.1.3. Using BIER in a 6TiSCH Network ๐
ROLL is actively working on Bit Index Explicit Replication (BIER) ๐ซง. it's a way to compress both the data-plane packets and the routing tables in storing mode [RPL-BIER]. iconic compression behavior โจ
BIER could also show up in the DetNet service layer ๐ง . "BIER-TE extensions for Packet Replication and Elimination Function (PREF) and OAM" [TE-PREF] uses BIER Traffic Engineering (TE) to control the DetNet Replication and Elimination activities in the data plane. it also gives you traceability on links where replication and loss happen, and it does all this in a way that's abstract to the forwarding information ๐ฆ
"A 6loRH for BitStrings" [BITSTRINGS-6LORH] proposes a 6LoWPAN compression for the BIER BitString, based on the 6LoWPAN Routing Header [RFC8138] ๐
A.2. External (Non-IETF) Work Items ๐
the current charter positions 6TiSCH on IEEE Std 802.15.4 only ๐. most of the design should be portable to other link types, but 6TiSCH has a strong dependency on IEEE Std 802.15.4 and how it evolves ๐ค. changes to TSCH should have minimal to zero impact on this architecture, but deeper stuff like 6top and security may be affected ๐ฌ. a 6TiSCH Interest Group at the IEEE keeps the synchronization going and helps push work at the IEEE if 6TiSCH needs it ๐
work is being proposed at IEEE (802.15.12 PAR) for an LLC that would logically include the 6top sublayer ๐ซถ. how it interacts with the 6top sublayer, and with the Scheduling Functions described in this document, is still TBD ๐
ISA100 [ISA100] Common Network Management (CNM) is another external work worth watching for 6TiSCH ๐. the group, called ISA100.20, defines a Common Network Management framework meant to manage resources controlled by heterogeneous protocols like ISA100.11a [ISA100.11a], WirelessHART [WirelessHART], and 6TiSCH ๐ฅ. the establishment of 6TiSCH deterministic paths, called Tracks, is also in scope, and ISA100.20 is working on DetNet requirements too ๐
Acknowledgments โจ
Special Thanks ๐
big thank-yous to Jonathan Simon, Giuseppe Piro, Subir Das, and Yoshihiro Ohba for their deep contributions to the initial security work ๐ซถ. to Yasuyuki Tanaka for the implementation and simulation work that helped build a robust system ๐ฅ. to Diego Dujovne for starting and leading the SF0 effort ๐, and to Tengfei Chang for evolving it in the MSF ๐
thanks also to Pat Kinney, Charlie Perkins, and Bob Heile for keeping the connection active and the design in line with the work happening at IEEE 802.15 ๐ธ
special thanks to Ted Lemon, who was the INT Area Director when this document was initiated, for his great support and help throughout ๐ง. and to Suresh Krishnan, who took over with that kind efficiency of his until publication ๐ฆ
also a huge thank-you to Ralph Droms, who did the first INT Area Directorate review. it was deep and thorough and totally changed the direction of this document ๐ญ. then Eliot Lear and Carlos Pignataro helped finalize it for the IESG reviews ๐. and Gorry Fairhurst, David Mandelberg, Qin Wu, Francis Dupont, รric Vyncke, Mirja Kรผhlewind, Roman Danyliw, Benjamin Kaduk, and Andrew Malis contributed to the final shaping of this document through the IESG review procedure ๐
And Do Not Forget ๐
this document is the result of lots of back-and-forth, especially on the 6TiSCH (bi)Weekly Interim call, relayed through the 6TiSCH mailing list at the IETF, over more than 5 years ๐ซง
the authors wish to thank, in arbitrary order: Alaeddine Weslati, Chonggang Wang, Georgios Exarchakos, Zhuo Chen, Georgios Papadopoulos, Eric Levy-Abegnoli, Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Deji Chen, Martin Turon, Dominique Barthel, Elvis Vogli, Geraldine Texier, Guillaume Gaillard, Herman Storey, Kazushi Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Toutain, Maik Seewald, Michael Behringer, Nancy Cam Winget, Nicola Accettura, Nicolas Montavont, Oleg Hahm, Patrick Wetterwald, Paul Duffy, Peter van der Stok, Rahul Sen, Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin-Lopez, Raghuram Sudhaakar, Sedat Gormus, Shitanshu Shah, Steve Simlo, Tina Tsou, Tom Phinney, Xavier Lagrange, Ines Robles, and Samita Chakrabarti for their participation and various contributions ๐ธ
Contributors ๐
the co-authors of this document are listed below ๐
Thomas Watteyne for his contributions to the whole design, in particular on TSCH and security, and to the open source community he created with openWSN ๐ฅ
Xavier Vilajosana, who led the design of the minimal support with RPL and contributed deeply to the 6top design and the GMPLS operation of Track switching ๐
Kris Pister for creating TSCH and his continuing guidance through the elaboration of this design ๐ง
Maliลกa Vuฤiniฤ for the work on the one-touch join process and his contribution to the Security Design Team ๐ซถ
Michael Richardson for his leadership role in the Security Design Team and his contribution throughout this document ๐
Tero Kivinen for his contribution to the security work in general and the security section in particular ๐ฆ
Maria Rita Palattella for managing the Terminology document that was merged into this document through the work of 6TiSCH ๐
Simon Duquennoy for his contribution to the open source community with the 6TiSCH implementation of contiki, and for his contribution to MSF and autonomous unicast cells ๐
Qin Wang, who led the design of the 6top sublayer and contributed related text that was moved and/or adapted into this document ๐
Rene Struik for the security section and his contribution to the Security Design Team ๐
Robert Assimiti for his breakthrough work on RPL over TSCH and initial text and guidance ๐ธ
Author's Address ๐ฎ
Pascal Thubert (editor)
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis
France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com๐ฆ where this page comes from
- ietf: rfc9030 2021-05
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms