rfc9030v5.txt   rfc9030.txt 
Internet Engineering Task Force (IETF) P. Thubert, Ed. Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9030 Cisco Systems Request for Comments: 9030 Cisco Systems
Category: Informational May 2021 Category: Informational May 2021
ISSN: 2070-1721 ISSN: 2070-1721
An Architecture for IPv6 over the Time-Slotted Channel Hopping (TSCH) An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of
Mode of IEEE 802.15.4 IEEE 802.15.4 (6TiSCH)
Abstract Abstract
This document describes a network architecture that provides low- This document describes a network architecture that provides low-
latency, low-jitter, and high-reliability packet delivery. It latency, low-jitter, and high-reliability packet delivery. It
combines a high-speed powered backbone and subnetworks using IEEE combines a high-speed powered backbone and subnetworks using IEEE
802.15.4 time-slotted channel hopping (TSCH) to meet the requirements 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements
of low-power wireless deterministic applications. of low-power wireless deterministic applications.
Status of This Memo Status of This Memo
skipping to change at line 138 skipping to change at line 138
such networks are presented in [RFC8578] and [RAW-USE-CASES], which such networks are presented in [RFC8578] and [RAW-USE-CASES], which
presents a number of additional use cases for Reliable and Available presents a number of additional use cases for Reliable and Available
Wireless networks (RAW). The considered applications include Wireless networks (RAW). The considered applications include
professional media, Industrial Automation and Control Systems (IACS), professional media, Industrial Automation and Control Systems (IACS),
building automation, in-vehicle command and control, commercial building automation, in-vehicle command and control, commercial
automation and asset tracking with mobile scenarios, as well as automation and asset tracking with mobile scenarios, as well as
gaming, drones and edge robotic control, and home automation gaming, drones and edge robotic control, and home automation
applications. applications.
The Time-Slotted Channel Hopping (TSCH) [RFC7554] mode of the IEEE The Time-Slotted Channel Hopping (TSCH) [RFC7554] mode of the IEEE
Std. 802.15.4 [IEEE802154] Medium Access Control (MAC) was introduced Std 802.15.4 [IEEE802154] Medium Access Control (MAC) was introduced
with the IEEE Std. 802.15.4e [IEEE802154e] amendment and is now with the IEEE Std 802.15.4e [IEEE802154e] amendment and is now
retrofitted in the main standard. For all practical purposes, this retrofitted in the main standard. For all practical purposes, this
document is expected to be insensitive to the revisions of that document is expected to be insensitive to the revisions of that
standard, which is thus referenced without a date. TSCH is both a standard, which is thus referenced without a date. TSCH is both a
Time-Division Multiplexing (TDM) and a Frequency-Division Time-Division Multiplexing (TDM) and a Frequency-Division
Multiplexing (FDM) technique, whereby a different channel can be used Multiplexing (FDM) technique, whereby a different channel can be used
for each transmission. TSCH allows the scheduling of transmissions for each transmission. TSCH allows the scheduling of transmissions
for deterministic operations and applies to the slower and most for deterministic operations and applies to the slower and most
energy-constrained wireless use cases. energy-constrained wireless use cases.
The scheduled operation provides for a more reliable experience, The scheduled operation provides for a more reliable experience,
which can be used to monitor and manage resources, e.g., energy and which can be used to monitor and manage resources, e.g., energy and
water, in a more efficient fashion. water, in a more efficient fashion.
Proven deterministic networking standards for use in process control, Proven deterministic networking standards for use in process control,
including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART], including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART],
have demonstrated the capabilities of the IEEE Std. 802.15.4 TSCH MAC have demonstrated the capabilities of the IEEE Std 802.15.4 TSCH MAC
for high reliability against interference, low-power consumption on for high reliability against interference, low-power consumption on
well-known flows, and its applicability for Traffic Engineering (TE) well-known flows, and its applicability for Traffic Engineering (TE)
from a central controller. from a central controller.
To enable the convergence of information technology (IT) and To enable the convergence of information technology (IT) and
operational technology (OT) in Low-Power and Lossy Networks (LLNs), operational technology (OT) in Low-Power and Lossy Networks (LLNs),
the 6TiSCH architecture supports an IETF suite of protocols over the the 6TiSCH architecture supports an IETF suite of protocols over the
IEEE Std. 802.15.4 TSCH MAC to provide IP connectivity for energy and IEEE Std 802.15.4 TSCH MAC to provide IP connectivity for energy and
otherwise constrained wireless devices. otherwise constrained wireless devices.
The 6TiSCH architecture relies on IPv6 [RFC8200] and the use of The 6TiSCH architecture relies on IPv6 [RFC8200] and the use of
routing to provide large scaling capabilities. The addition of a routing to provide large scaling capabilities. The addition of a
high-speed federating backbone adds yet another degree of scalability high-speed federating backbone adds yet another degree of scalability
to the design. The backbone is typically a Layer 2 transit link such 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 as an Ethernet bridged network, but it can also be a more complex
routed structure. routed structure.
The 6TiSCH architecture introduces an IPv6 multi-link subnet model The 6TiSCH architecture introduces an IPv6 multi-link subnet model
that is composed of a federating backbone and a number of IEEE Std. that is composed of a federating backbone and a number of IEEE Std
802.15.4 TSCH low-power wireless networks federated and synchronized 802.15.4 TSCH low-power wireless networks federated and synchronized
by Backbone Routers. If the backbone is a Layer 2 transit link, then by Backbone Routers. If the backbone is a Layer 2 transit link, then
the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6 the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6
ND) proxy [RFC4861]. ND) proxy [RFC4861].
The 6TiSCH architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to The 6TiSCH architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to
the constrained media and the Routing Protocol for Low-Power and the constrained media and the Routing Protocol for Low-Power and
Lossy Networks (RPL) [RFC6550] for the distributed routing Lossy Networks (RPL) [RFC6550] for the distributed routing
operations. operations.
skipping to change at line 203 skipping to change at line 203
and scheduling in a centralized, distributed, or mixed fashion, for and scheduling in a centralized, distributed, or mixed fashion, for
use in multiple OT environments. It is applicable in particular to use in multiple OT environments. It is applicable in particular to
highly scalable solutions such as those used in Advanced Metering highly scalable solutions such as those used in Advanced Metering
Infrastructure [AMI] solutions that leverage distributed routing to Infrastructure [AMI] solutions that leverage distributed routing to
enable multipath forwarding over large LLN meshes. enable multipath forwarding over large LLN meshes.
2. Terminology 2. Terminology
2.1. New Terms 2.1. New Terms
The document does not reuse terms from the IEEE Std. 802.15.4 The document does not reuse terms from the IEEE Std 802.15.4
[IEEE802154] standard such as "path" or "link", which bear a meaning [IEEE802154] standard such as "path" or "link", which bear a meaning
that is quite different from classical IETF parlance. that is quite different from classical IETF parlance.
This document adds the following terms: This document adds the following terms:
6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4): 6TiSCH defines an 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4): 6TiSCH defines an
adaptation sublayer for IPv6 over TSCH called 6top, a set of adaptation sublayer for IPv6 over TSCH called 6top, a set of
protocols for setting up a TSCH schedule in distributed approach, protocols for setting up a TSCH schedule in distributed approach,
and a security solution. 6TiSCH may be extended in the future for and a security solution. 6TiSCH may be extended in the future for
other MAC/Physical Layer (PHY) pairs providing a service similar other MAC/Physical Layer (PHY) pairs providing a service similar
to TSCH. to TSCH.
6top (6TiSCH Operation Sublayer): The next higher layer of the IEEE 6top (6TiSCH Operation Sublayer): The next higher layer of the IEEE
Std. 802.15.4 TSCH MAC layer. 6top provides the abstraction of an 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 IP link over a TSCH MAC, schedules packets over TSCH cells, and
exposes a management interface to schedule TSCH cells. exposes a management interface to schedule TSCH cells.
6P (6top Protocol): The protocol defined in [RFC8480]. 6P enables 6P (6top Protocol): The protocol defined in [RFC8480]. 6P enables
Layer 2 peers to allocate, move, or de-allocate cells in their Layer 2 peers to allocate, move, or de-allocate cells in their
respective schedules to communicate. 6P operates at the 6top respective schedules to communicate. 6P operates at the 6top
sublayer. sublayer.
6P transaction: A 2-way or 3-way sequence of 6P messages used by 6P transaction: A 2-way or 3-way sequence of 6P messages used by
Layer 2 peers to modify their communication schedule. Layer 2 peers to modify their communication schedule.
skipping to change at line 354 skipping to change at line 354
the JRC. The JP announces the presence of the network by the JRC. The JP announces the presence of the network by
regularly sending EB frames. regularly sending EB frames.
JRC (Join Registrar/Coordinator): Central entity responsible for the JRC (Join Registrar/Coordinator): Central entity responsible for the
authentication, authorization, and configuration of the pledge. authentication, authorization, and configuration of the pledge.
link: A communication facility or medium over which nodes can link: A communication facility or medium over which nodes can
communicate at the link layer, which is the layer immediately communicate at the link layer, which is the layer immediately
below IP. In 6TiSCH, the concept is implemented as a collection below IP. In 6TiSCH, the concept is implemented as a collection
of Layer 3 bundles. Note: the IETF parlance for the term "link" of Layer 3 bundles. Note: the IETF parlance for the term "link"
is adopted, as opposed to the IEEE Std. 802.15.4 terminology. is adopted, as opposed to the IEEE Std 802.15.4 terminology.
operational technology: OT refers to technology used in automation, operational technology: OT refers to technology used in automation,
for instance in industrial control networks. The convergence of for instance in industrial control networks. The convergence of
IT and OT is the main object of the Industrial Internet of Things IT and OT is the main object of the Industrial Internet of Things
(IIOT). (IIOT).
pledge: A new device that attempts to join a 6TiSCH network. pledge: A new device that attempts to join a 6TiSCH network.
(to) relocate a cell: The action operated by the 6top sublayer of (to) relocate a cell: The action operated by the 6top sublayer of
changing the slotOffset and/or channelOffset of a soft cell. changing the slotOffset and/or channelOffset of a soft cell.
(to) schedule a cell: The action of turning an unscheduled cell into (to) schedule a cell: The action of turning an unscheduled cell into
a scheduled cell. a scheduled cell.
scheduled cell: A cell that is assigned a neighbor MAC address scheduled cell: A cell that is assigned a neighbor MAC address
(broadcast address is also possible) and one or more of the (broadcast address is also possible) and one or more of the
following flags: TX, RX, Shared, and Timekeeping. A scheduled following flags: TX, RX, Shared, and Timekeeping. A scheduled
cell can be used by the IEEE Std. 802.15.4 TSCH implementation to cell can be used by the IEEE Std 802.15.4 TSCH implementation to
communicate. A scheduled cell can either be a hard or a soft communicate. A scheduled cell can either be a hard or a soft
cell. cell.
SF (6top Scheduling Function): The cell management entity that adds SF (6top Scheduling Function): The cell management entity that adds
or deletes cells dynamically based on application networking or deletes cells dynamically based on application networking
requirements. The cell negotiation with a neighbor is done using requirements. The cell negotiation with a neighbor is done using
6P. 6P.
SFID (6top Scheduling Function Identifier): A 4-bit field SFID (6top Scheduling Function Identifier): A 4-bit field
identifying an SF. identifying an SF.
skipping to change at line 412 skipping to change at line 412
time source neighbor: A neighbor that a node uses as its time time source neighbor: A neighbor that a node uses as its time
reference, and to which it needs to keep its clock synchronized. reference, and to which it needs to keep its clock synchronized.
timeslot: A basic communication unit in TSCH that allows a timeslot: A basic communication unit in TSCH that allows a
transmitter node to send a frame to a receiver neighbor and that transmitter node to send a frame to a receiver neighbor and that
allows the receiver neighbor to optionally send back an allows the receiver neighbor to optionally send back an
acknowledgment. acknowledgment.
Track: A Track is a Directed Acyclic Graph (DAG) that is used as a Track: A Track is a Directed Acyclic Graph (DAG) that is used as a
complex multi-hop path to the destination(s) of the path. In the complex multihop path to the destination(s) of the path. In the
case of unicast traffic, the Track is a Destination-Oriented DAG case of unicast traffic, the Track is a Destination-Oriented DAG
(DODAG) where the Root of the DODAG is the destination of the (DODAG) where the Root of the DODAG is the destination of the
unicast traffic. A Track enables replication, elimination, and unicast traffic. A Track enables replication, elimination, and
reordering functions on the way (more on those functions in reordering functions on the way (more on those functions in
[RFC8655]). A Track reservation locks physical resources such as [RFC8655]). A Track reservation locks physical resources such as
cells and buffers in every node along the DODAG. A Track is cells and buffers in every node along the DODAG. A Track is
associated with an owner, which can be for instance the associated with an owner, which can be for instance the
destination of the Track. destination of the Track.
TrackID: A TrackID is either globally unique or locally unique to TrackID: A TrackID is either globally unique or locally unique to
skipping to change at line 435 skipping to change at line 435
reference to the Track. Typically, the Track owner is the ingress reference to the Track. Typically, the Track owner is the ingress
of the Track, the IPv6 source address of packets along the Track of the Track, the IPv6 source address of packets along the Track
can be used as identification of the owner, and a local InstanceID can be used as identification of the owner, and a local InstanceID
[RFC6550] in the namespace of that owner can be used as TrackID. [RFC6550] in the namespace of that owner can be used as TrackID.
If the Track is reversible, then the owner is found in the IPv6 If the Track is reversible, then the owner is found in the IPv6
destination address of a packet coming back along the Track. In destination address of a packet coming back along the Track. In
that case, a RPL Packet Information [RFC6550] in an IPv6 packet that case, a RPL Packet Information [RFC6550] in an IPv6 packet
can unambiguously identify the Track and can be expressed in a can unambiguously identify the Track and can be expressed in a
compressed form using [RFC8138]. compressed form using [RFC8138].
TSCH: A medium access mode of the IEEE Std. 802.15.4 [IEEE802154] TSCH: A medium access mode of the IEEE Std 802.15.4 [IEEE802154]
standard that uses time synchronization to achieve ultra-low-power standard that uses time synchronization to achieve ultra-low-power
operation and channel hopping to enable high reliability. operation and channel hopping to enable high reliability.
TSCH Schedule: A matrix of cells, with each cell indexed by a TSCH Schedule: A matrix of cells, with each cell indexed by a
slotOffset and a channelOffset. The TSCH schedule contains all slotOffset and a channelOffset. The TSCH schedule contains all
the scheduled cells from all slotframes and is sufficient to the scheduled cells from all slotframes and is sufficient to
qualify the communication in the TSCH network. The number of qualify the communication in the TSCH network. The number of
channelOffset values (the "height" of the matrix) is equal to the channelOffset values (the "height" of the matrix) is equal to the
number of available frequencies. number of available frequencies.
Unscheduled Cell: A cell that is not used by the IEEE Std. 802.15.4 Unscheduled Cell: A cell that is not used by the IEEE Std 802.15.4
TSCH implementation. TSCH implementation.
2.2. Abbreviations 2.2. Abbreviations
This document uses the following abbreviations: This document uses the following abbreviations:
6BBR: 6LoWPAN Backbone Router (router with a proxy ND function) 6BBR: 6LoWPAN Backbone Router (router with a proxy ND function)
6LBR: 6LoWPAN Border Router (authoritative on Duplicate Address 6LBR: 6LoWPAN Border Router (authoritative on Duplicate Address
Detection (DAD)) Detection (DAD))
skipping to change at line 568 skipping to change at line 568
+-----+ +-----+
o o o o o o
o o o o o o o o o o
o o 6LoWPAN + RPL o o o o 6LoWPAN + RPL o o
o o o o o o o o
Figure 1: Basic Configuration of a 6TiSCH Network Figure 1: Basic Configuration of a 6TiSCH Network
Inside a 6TiSCH LLN, nodes rely on 6LoWPAN header compression Inside a 6TiSCH LLN, nodes rely on 6LoWPAN header compression
(6LoWPAN HC) [RFC6282] to encode IPv6 packets. From the perspective (6LoWPAN HC) [RFC6282] to encode IPv6 packets. From the perspective
of the network layer, a single LLN interface (typically an IEEE Std. of the network layer, a single LLN interface (typically an IEEE Std
802.15.4-compliant radio) may be seen as a collection of links with 802.15.4-compliant radio) may be seen as a collection of links with
different capabilities for unicast or multicast services. different capabilities for unicast or multicast services.
6TiSCH nodes join a mesh network by attaching to nodes that are 6TiSCH nodes join a mesh network by attaching to nodes that are
already members of the mesh (see Section 4.2.1). The security already members of the mesh (see Section 4.2.1). The security
aspects of the join process are further detailed in Section 6. In a aspects of the join process are further detailed in Section 6. In a
mesh network, 6TiSCH nodes are not necessarily reachable from one mesh network, 6TiSCH nodes are not necessarily reachable from one
another at Layer 2, and an LLN may span over multiple links. another at Layer 2, and an LLN may span over multiple links.
This forms a homogeneous non-broadcast multi-access (NBMA) subnet, This forms a homogeneous non-broadcast multi-access (NBMA) subnet,
skipping to change at line 610 skipping to change at line 610
RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs)
within Instances of the protocol, each Instance being associated with within Instances of the protocol, each Instance being associated with
an Objective Function (OF) to form a routing topology. A particular an Objective Function (OF) to form a routing topology. A particular
6TiSCH node, the LLN Border Router (6LBR), acts as RPL Root, 6LoWPAN 6TiSCH node, the LLN Border Router (6LBR), acts as RPL Root, 6LoWPAN
HC terminator, and Border Router for the LLN to the outside. The HC terminator, and Border Router for the LLN to the outside. The
6LBR is usually powered. More on RPL Instances can be found in 6LBR is usually powered. More on RPL Instances can be found in
Section 3.1 of RPL [RFC6550], in particular "3.1.2 RPL Identifiers" Section 3.1 of RPL [RFC6550], in particular "3.1.2 RPL Identifiers"
and "3.1.3 Instances, DODAGs, and DODAG Versions". RPL adds and "3.1.3 Instances, DODAGs, and DODAG Versions". RPL adds
artifacts in the data packets that are compressed with a 6LoWPAN artifacts in the data packets that are compressed with a 6LoWPAN
Routing Header (6LoRH) [RFC8138]. In an preexisting network, the Routing Header (6LoRH) [RFC8138]. In a preexisting network, the
compression can be globally turned on in a DODAG once all nodes are compression can be globally turned on in a DODAG once all nodes are
migrated to support [RFC8138] using [RFC9035]. migrated to support [RFC8138] using [RFC9035].
Additional routing and scheduling protocols may be deployed to Additional routing and scheduling protocols may be deployed to
establish on-demand, peer-to-peer routes with particular establish on-demand, peer-to-peer routes with particular
characteristics inside the 6TiSCH network. This may be achieved in a characteristics inside the 6TiSCH network. This may be achieved in a
centralized fashion by a Path Computation Element (PCE) [PCE] that centralized fashion by a Path Computation Element (PCE) [PCE] that
programs both the routes and the schedules inside the 6TiSCH nodes or programs both the routes and the schedules inside the 6TiSCH nodes or
in a distributed fashion by using a reactive routing protocol and a in a distributed fashion by using a reactive routing protocol and a
hop-by-hop scheduling protocol. hop-by-hop scheduling protocol.
skipping to change at line 704 skipping to change at line 704
The "Deterministic Networking Architecture" [RFC8655] studies Layer 3 The "Deterministic Networking Architecture" [RFC8655] studies Layer 3
aspects of Deterministic Networks and covers networks that span aspects of Deterministic Networks and covers networks that span
multiple Layer 2 domains. If the backbone is deterministic (such as multiple Layer 2 domains. If the backbone is deterministic (such as
defined by the Time-Sensitive Networking (TSN) Task Group at IEEE), defined by the Time-Sensitive Networking (TSN) Task Group at IEEE),
then the Backbone Router ensures that the end-to-end deterministic then the Backbone Router ensures that the end-to-end deterministic
behavior is maintained between the LLN and the backbone. behavior is maintained between the LLN and the backbone.
3.3. TSCH: a Deterministic MAC Layer 3.3. TSCH: a Deterministic MAC Layer
Though at a different time scale (several orders of magnitude), both Though at a different time scale (several orders of magnitude), both
IEEE Std. 802.1 TSN and IEEE Std. 802.15.4 TSCH standards provide IEEE Std 802.1 TSN and IEEE Std 802.15.4 TSCH standards provide
deterministic capabilities to the point that a packet pertaining to a deterministic capabilities to the point that a packet pertaining to a
certain flow may traverse a network from node to node following a certain flow may traverse a network from node to node following a
precise schedule, as a train that enters and then leaves intermediate precise schedule, as a train that enters and then leaves intermediate
stations at precise times along its path. stations at precise times along its path.
With TSCH, time is formatted into timeslots, and individual With TSCH, time is formatted into timeslots, and individual
communication cells are allocated to unicast or broadcast communication cells are allocated to unicast or broadcast
communication at the MAC level. The time-slotted operation reduces communication at the MAC level. The time-slotted operation reduces
collisions, saves energy, and enables more closely engineering the collisions, saves energy, and enables more closely engineering the
network for deterministic properties. The channel-hopping aspect is network for deterministic properties. The channel-hopping aspect is
a simple and efficient technique to combat multipath fading and co- a simple and efficient technique to combat multipath fading and co-
channel interference. channel interference.
6TiSCH builds on the IEEE Std. 802.15.4 TSCH MAC and inherits its 6TiSCH builds on the IEEE Std 802.15.4 TSCH MAC and inherits its
advanced capabilities to enable them in multiple environments where advanced capabilities to enable them in multiple environments where
they can be leveraged to improve automated operations. The 6TiSCH they can be leveraged to improve automated operations. The 6TiSCH
architecture also inherits the capability to perform a centralized architecture also inherits the capability to perform a centralized
route computation to achieve deterministic properties, though it route computation to achieve deterministic properties, though it
relies on the IETF DetNet architecture [RFC8655] and IETF components relies on the IETF DetNet architecture [RFC8655] and IETF components
such as the PCE [PCE] for the protocol aspects. such as the PCE [PCE] for the protocol aspects.
On top of this inheritance, 6TiSCH adds capabilities for distributed On top of this inheritance, 6TiSCH adds capabilities for distributed
routing and scheduling operations based on RPL and capabilities for routing and scheduling operations based on RPL and capabilities for
negotiating schedule adjustments between peers. These distributed negotiating schedule adjustments between peers. These distributed
skipping to change at line 849 skipping to change at line 849
3.6. Forwarding over TSCH 3.6. Forwarding over TSCH
The 6TiSCH architecture supports three different forwarding models. The 6TiSCH architecture supports three different forwarding models.
One is the classical IPv6 Forwarding, where the node selects a One is the classical IPv6 Forwarding, where the node selects a
feasible successor at Layer 3 on a per-packet basis and based on its feasible successor at Layer 3 on a per-packet basis and based on its
routing table. The second derives from Generalized MPLS (GMPLS) for routing table. The second derives from Generalized MPLS (GMPLS) for
so-called Track Forwarding, whereby a frame received at a particular so-called Track Forwarding, whereby a frame received at a particular
timeslot can be switched into another timeslot at Layer 2 without timeslot can be switched into another timeslot at Layer 2 without
regard to the upper-layer protocol. The third model is the 6LoWPAN regard to the upper-layer protocol. The third model is the 6LoWPAN
Fragment Forwarding, which allows the forwarding individual 6loWPAN Fragment Forwarding, which allows the forwarding individual 6LoWPAN
fragments along a route that is set up by the first fragment. fragments along a route that is set up by the first fragment.
In more detail: In more detail:
IPv6 Forwarding: This is the classical IP forwarding model, with a IPv6 Forwarding: This is the classical IP forwarding model, with a
Routing Information Base (RIB) that is installed by RPL and used Routing Information Base (RIB) that is installed by RPL and used
to select a feasible successor per packet. The packet is placed to select a feasible successor per packet. The packet is placed
on an outgoing link, which the 6top sublayer maps into a (Layer 3) on an outgoing link, which the 6top sublayer maps into a (Layer 3)
bundle of cells, and scheduled for transmission based on QoS bundle of cells, and scheduled for transmission based on QoS
parameters. Besides RPL, this model also applies to any routing parameters. Besides RPL, this model also applies to any routing
skipping to change at line 933 skipping to change at line 933
| CoAP / OSCORE | 6LoWPAN ND | RPL | | CoAP / OSCORE | 6LoWPAN ND | RPL |
+-----------------+--------------+-----+ +-----------------+--------------+-----+
| UDP | ICMPv6 | | UDP | ICMPv6 |
+-----------------+--------------------+ +-----------------+--------------------+
| IPv6 | | IPv6 |
+--------------------------------------+----------------------+ +--------------------------------------+----------------------+
| 6LoWPAN HC / 6LoRH HC | Scheduling Functions | | 6LoWPAN HC / 6LoRH HC | Scheduling Functions |
+--------------------------------------+----------------------+ +--------------------------------------+----------------------+
| 6top inc. 6top Protocol | | 6top inc. 6top Protocol |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| IEEE Std. 802.15.4 TSCH | | IEEE Std 802.15.4 TSCH |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
Figure 3: 6TiSCH Protocol Stack Figure 3: 6TiSCH Protocol Stack
RPL is the routing protocol of choice for LLNs. So far, there is no RPL is the routing protocol of choice for LLNs. So far, there is no
identified need to define a 6TiSCH-specific Objective Function. The identified need to define a 6TiSCH-specific Objective Function. The
Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL
over a static schedule used in a Slotted ALOHA fashion [S-ALOHA], over a static schedule used in a Slotted ALOHA fashion [S-ALOHA],
whereby all active slots may be used for emission or reception of whereby all active slots may be used for emission or reception of
both unicast and multicast frames. both unicast and multicast frames.
skipping to change at line 969 skipping to change at line 969
protected by the Datagram Transport Layer Security (DTLS) [RFC6347] protected by the Datagram Transport Layer Security (DTLS) [RFC6347]
sitting either under CoAP or over CoAP so it can traverse proxies. sitting either under CoAP or over CoAP so it can traverse proxies.
The 6TiSCH Operation Sublayer (6top) is a sublayer of a Logical Link The 6TiSCH Operation Sublayer (6top) is a sublayer of a Logical Link
Control (LLC) that provides the abstraction of an IP link over a TSCH Control (LLC) that provides the abstraction of an IP link over a TSCH
MAC and schedules packets over TSCH cells, as further discussed in MAC and schedules packets over TSCH cells, as further discussed in
the next sections, providing in particular dynamic cell allocation the next sections, providing in particular dynamic cell allocation
with the 6top Protocol (6P) [RFC8480]. with the 6top Protocol (6P) [RFC8480].
The reference stack presented in this document was implemented and The reference stack presented in this document was implemented and
interop-tested by a combination of open source, IETF, and ETSI interoperability-tested by a combination of open source, IETF, and
efforts. One goal is to help other bodies to adopt the stack as a ETSI efforts. One goal is to help other bodies to adopt the stack as
whole, making the effort to move to an IPv6-based IoT stack easier. a whole, making the effort to move to an IPv6-based IoT stack easier.
For a particular environment, some of the choices that are available For a particular environment, some of the choices that are available
in this architecture may not be relevant. For instance, RPL is not in this architecture may not be relevant. For instance, RPL is not
required for star topologies and mesh-under Layer 2 routed networks, required for star topologies and mesh-under Layer 2 routed networks,
and the 6LoWPAN compression may not be sufficient for ultra- and the 6LoWPAN compression may not be sufficient for ultra-
constrained cases such as some Low-Power Wide Area (LPWA) networks. constrained cases such as some Low-Power Wide Area (LPWA) networks.
In such cases, it is perfectly doable to adopt a subset of the In such cases, it is perfectly doable to adopt a subset of the
selection that is presented hereafter and then select alternate selection that is presented hereafter and then select alternate
components to complete the solution wherever needed. components to complete the solution wherever needed.
skipping to change at line 1003 skipping to change at line 1003
Section 2.1.3 of [RPL-APPLICABILITY] and its following sections Section 2.1.3 of [RPL-APPLICABILITY] and its following sections
discuss application-layer paradigms such as source-sink, which is a discuss application-layer paradigms such as source-sink, which is a
multipeer-to-multipeer model primarily used for alarms and alerts, multipeer-to-multipeer model primarily used for alarms and alerts,
publish-subscribe, which is typically used for sensor data, as well publish-subscribe, which is typically used for sensor data, as well
as peer-to-peer and peer-to-multipeer communications. as peer-to-peer and peer-to-multipeer communications.
Additional considerations on duocast -- one sender, two receivers for Additional considerations on duocast -- one sender, two receivers for
redundancy -- and its N-cast generalization are also provided. Those redundancy -- and its N-cast generalization are also provided. Those
paradigms are frequently used in industrial automation, which is a paradigms are frequently used in industrial automation, which is a
major use case for IEEE Std. 802.15.4 TSCH wireless networks with major use case for IEEE Std 802.15.4 TSCH wireless networks with
[ISA100.11a] and [WirelessHART], which provides a wireless access to [ISA100.11a] and [WirelessHART], which provides a wireless access to
[HART] applications and devices. [HART] applications and devices.
This document focuses on Communication Paradigms and Interaction This document focuses on Communication Paradigms and Interaction
Models for packet forwarding and TSCH resources (cells) management. Models for packet forwarding and TSCH resources (cells) management.
Management mechanisms for the TSCH schedule at the link layer (one Management mechanisms for the TSCH schedule at the link layer (one
hop), network layer (multihop along a Track), and application layer hop), network layer (multihop along a Track), and application layer
(remote control) are discussed in Section 4.4. Link-layer frame (remote control) are discussed in Section 4.4. Link-layer frame
forwarding interactions are discussed in Section 4.6, and network- forwarding interactions are discussed in Section 4.6, and network-
layer packet routing is addressed in Section 4.7. layer packet routing is addressed in Section 4.7.
skipping to change at line 1035 skipping to change at line 1035
leaves. leaves.
4.1.1. RPL-Unaware Leaves and 6LoWPAN ND 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND
RPL needs a set of information to advertise a leaf node through a RPL needs a set of information to advertise a leaf node through a
Destination Advertisement Object (DAO) message and establish Destination Advertisement Object (DAO) message and establish
reachability. reachability.
"Routing for RPL Leaves" [RFC9010] details the basic interaction of "Routing for RPL Leaves" [RFC9010] details the basic interaction of
6LoWPAN ND and RPL and enables a plain 6LN that supports [RFC8505] to 6LoWPAN ND and RPL and enables a plain 6LN that supports [RFC8505] to
obtain return connectivity via the RPL network as an RPL-unaware obtain return connectivity via the RPL network as a RPL-unaware leaf.
leaf. The leaf indicates that it requires reachability services for The leaf indicates that it requires reachability services for the
the Registered Address from a Routing Registrar by setting an 'R' Registered Address from a Routing Registrar by setting an 'R' flag in
flag in the Extended Address Registration Option [RFC8505], and it the Extended Address Registration Option [RFC8505], and it provides a
provides a TID that maps to the "Path Sequence" defined in TID that maps to the "Path Sequence" defined in Section 6.7.8 of
Section 6.7.8 of [RFC6550], and its operation is defined in [RFC6550], and its operation is defined in Section 7.2 of [RFC6550].
Section 7.2 of [RFC6550].
[RFC9010] also enables the leaf to signal with the RPLInstanceID that [RFC9010] also enables the leaf to signal with the RPLInstanceID that
it wants to participate by using the Opaque field of the EARO. On it wants to participate by using the Opaque field of the EARO. On
the backbone, the RPLInstanceID is expected to be mapped to an the backbone, the RPLInstanceID is expected to be mapped to an
overlay that matches the RPL Instance, e.g., a Virtual LAN (VLAN) or overlay that matches the RPL Instance, e.g., a Virtual LAN (VLAN) or
a virtual routing and forwarding (VRF) instance. a virtual routing and forwarding (VRF) instance.
Though, at the time of this writing, the above specification enables Though, at the time of this writing, the above specification enables
a model where the separation is possible, this architecture a model where the separation is possible, this architecture
recommends co-locating the functions of 6LBR and RPL Root. recommends co-locating the functions of 6LBR and RPL Root.
4.1.2. 6LBR and RPL Root 4.1.2. 6LBR and RPL Root
With the 6LowPAN ND [RFC6775], information on the 6LBR is With the 6LoWPAN ND [RFC6775], information on the 6LBR is
disseminated via an Authoritative Border Router Option (ABRO) in RA disseminated via an Authoritative Border Router Option (ABRO) in RA
messages. [RFC8505] extends [RFC6775] to enable a registration for messages. [RFC8505] extends [RFC6775] to enable a registration for
routing and proxy ND. The capability to support [RFC8505] is routing and proxy ND. The capability to support [RFC8505] is
indicated in the 6LoWPAN Capability Indication Option (6CIO). The indicated in the 6LoWPAN Capability Indication Option (6CIO). The
discovery and liveliness of the RPL Root are obtained through RPL discovery and liveliness of the RPL Root are obtained through RPL
[RFC6550] itself. [RFC6550] itself.
When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root
functionalities are co-located in order that the address of the 6LBR functionalities are co-located in order that the address of the 6LBR
is indicated by RPL DODAG Information Object (DIO) messages and to is indicated by RPL DODAG Information Object (DIO) messages and to
skipping to change at line 1139 skipping to change at line 1138
pledge to join after a single round-trip exchange with the JRC. The pledge to join after a single round-trip exchange with the JRC. The
provisioning of the PSK to the pledge and the JRC needs to be done provisioning of the PSK to the pledge and the JRC needs to be done
out of band, through a 'one-touch' bootstrapping process, which out of band, through a 'one-touch' bootstrapping process, which
effectively enrolls the pledge into the domain managed by the JRC. effectively enrolls the pledge into the domain managed by the JRC.
In certain use cases, the 'one-touch' bootstrapping is not feasible In certain use cases, the 'one-touch' bootstrapping is not feasible
due to the operational constraints, and the enrollment of the pledge due to the operational constraints, and the enrollment of the pledge
into the domain needs to occur in-band. This is handled through a into the domain needs to occur in-band. This is handled through a
'zero-touch' extension of the Minimal Security Framework for 6TiSCH. 'zero-touch' extension of the Minimal Security Framework for 6TiSCH.
The zero-touch extension [ZEROTOUCH-JOIN] leverages the The zero-touch extension [ZEROTOUCH-JOIN] leverages the
"Bootstrapping Remote Secure Key Infrastructures (BRSKI)" [BRSKI] "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" [RFC8995]
work to establish a shared secret between a pledge and the JRC work to establish a shared secret between a pledge and the JRC
without necessarily having them belong to a common (security) domain without necessarily having them belong to a common (security) domain
at join time. This happens through inter-domain communication at join time. This happens through inter-domain communication
occurring between the JRC of the network and the domain of the occurring between the JRC of the network and the domain of the
pledge, represented by a fourth entity, Manufacturer Authorized pledge, represented by a fourth entity, Manufacturer Authorized
Signing Authority (MASA). Once the zero-touch exchange completes, Signing Authority (MASA). Once the zero-touch exchange completes,
the CoJP exchange defined in [RFC9031] is carried over the secure the CoJP exchange defined in [RFC9031] is carried over the secure
session established between the pledge and the JRC. session established between the pledge and the JRC.
Figure 4 depicts the join process and where a Link-Local Address Figure 4 depicts the join process and where a Link-Local Address
skipping to change at line 1373 skipping to change at line 1372
The SF relies on 6top services that implement the 6top Protocol (6P) The SF relies on 6top services that implement the 6top Protocol (6P)
[RFC8480] to negotiate the precise cells that will be allocated or [RFC8480] to negotiate the precise cells that will be allocated or
freed based on the schedule of the peer. For instance, it may be freed based on the schedule of the peer. For instance, it may be
that a peer wants to use a particular timeslot that is free in its that a peer wants to use a particular timeslot that is free in its
schedule, but that timeslot is already in use by the other peer to schedule, but that timeslot is already in use by the other peer to
communicate with a third party on a different cell. 6P enables the communicate with a third party on a different cell. 6P enables the
peers to find an agreement in a transactional manner that ensures the peers to find an agreement in a transactional manner that ensures the
final consistency of the nodes' state. final consistency of the nodes' state.
MSF [RFC9033] is one of the possible Scheduling Functions. MSF uses MSF [RFC9033] is one of the possible Scheduling Functions. MSF uses
the rendez-vous slot from [RFC8180] for network discovery, neighbor the rendezvous slot from [RFC8180] for network discovery, neighbor
discovery, and any other broadcast. discovery, and any other broadcast.
For basic unicast communication with any neighbor, each node uses a For basic unicast communication with any neighbor, each node uses a
receive cell at a well-known slotOffset/channelOffset, which is receive cell at a well-known slotOffset/channelOffset, which is
derived from a hash of their own MAC address. Nodes can reach any derived from a hash of their own MAC address. Nodes can reach any
neighbor by installing a transmit (shared) cell with slotOffset/ neighbor by installing a transmit (shared) cell with slotOffset/
channelOffset derived from the neighbor's MAC address. channelOffset derived from the neighbor's MAC address.
For child-parent links, MSF continuously monitors the load between For child-parent links, MSF continuously monitors the load between
parents and children. It then uses 6P to install or remove unicast parents and children. It then uses 6P to install or remove unicast
skipping to change at line 1414 skipping to change at line 1413
e.g., received signal strength indication (RSSI) or link quality e.g., received signal strength indication (RSSI) or link quality
indicator (LQI), the number of packets sent to the neighbor, or the indicator (LQI), the number of packets sent to the neighbor, or the
number of packets received from it. This information can be made number of packets received from it. This information can be made
available through 6top management APIs and used, for instance, to available through 6top management APIs and used, for instance, to
compute a Rank Increment that will determine the selection of the compute a Rank Increment that will determine the selection of the
preferred parent. preferred parent.
6top provides statistics about the underlying layer so the OF can be 6top provides statistics about the underlying layer so the OF can be
tuned to the nature of the TSCH MAC layer. 6top also enables the RPL tuned to the nature of the TSCH MAC layer. 6top also enables the RPL
OF to influence the MAC behavior, for instance, by configuring the OF to influence the MAC behavior, for instance, by configuring the
periodicity of IEEE Std. 802.15.4 Extended Beacons (EBs). By periodicity of IEEE Std 802.15.4 Extended Beacons (EBs). By
augmenting the EB periodicity, it is possible to change the network augmenting the EB periodicity, it is possible to change the network
dynamics so as to improve the support of devices that may change dynamics so as to improve the support of devices that may change
their point of attachment in the 6TiSCH network. their point of attachment in the 6TiSCH network.
Some RPL control messages, such as the DODAG Information Object Some RPL control messages, such as the DODAG Information Object
(DIO), are ICMPv6 messages that are broadcast to all neighbor nodes. (DIO), are ICMPv6 messages that are broadcast to all neighbor nodes.
With 6TiSCH, the broadcast channel requirement is addressed by 6top With 6TiSCH, the broadcast channel requirement is addressed by 6top
by configuring TSCH to provide a broadcast channel, as opposed to, by configuring TSCH to provide a broadcast channel, as opposed to,
for instance, piggybacking the DIO messages in Layer 2 Enhanced for instance, piggybacking the DIO messages in Layer 2 Enhanced
Beacons (EBs), which would produce undue timer coupling among layers Beacons (EBs), which would produce undue timer coupling among layers
skipping to change at line 1476 skipping to change at line 1475
MAC-level Join Priority set to its DAGRank() in that Instance, where MAC-level Join Priority set to its DAGRank() in that Instance, where
DAGRank() is the operation specified in Section 3.5.1 of [RFC6550], DAGRank() is the operation specified in Section 3.5.1 of [RFC6550],
"Rank Comparison". "Rank Comparison".
The provisioning of a RPL Root is out of scope for both RPL and this The provisioning of a RPL Root is out of scope for both RPL and this
architecture, whereas RPL enables the propagation of configuration architecture, whereas RPL enables the propagation of configuration
information down the DODAG. This applies to the TSGI as well; a Root information down the DODAG. This applies to the TSGI as well; a Root
is configured, or obtains by unspecified means, the knowledge of the is configured, or obtains by unspecified means, the knowledge of the
RPLInstanceID for the TSGI. The Root advertises its DagRank in the RPLInstanceID for the TSGI. The Root advertises its DagRank in the
TSGI, which must be less than 0xFF, as its Join Priority in its IEEE TSGI, which must be less than 0xFF, as its Join Priority in its IEEE
Std. 802.15.4 EBs. Std 802.15.4 EBs.
A node that reads a Join Priority of less than 0xFF should join the A node that reads a Join Priority of less than 0xFF should join the
neighbor with the lesser Join Priority and use it as time parent. If neighbor with the lesser Join Priority and use it as time parent. If
the node is configured to serve as time parent, then the node should the node is configured to serve as time parent, then the node should
join the TSGI, obtain a Rank in that Instance, and start advertising join the TSGI, obtain a Rank in that Instance, and start advertising
its own DagRank in the TSGI as its Join Priority in its EBs. its own DagRank in the TSGI as its Join Priority in its EBs.
4.3.5. Slotframes and CDU Matrix 4.3.5. Slotframes and CDU Matrix
6TiSCH enables IPv6 best-effort (stochastic) transmissions over a MAC 6TiSCH enables IPv6 best-effort (stochastic) transmissions over a MAC
layer that is also capable of scheduled (deterministic) layer that is also capable of scheduled (deterministic)
transmissions. A window of time is defined around the scheduled transmissions. A window of time is defined around the scheduled
transmission where the medium must, as much as practically feasible, transmission where the medium must, as much as practically feasible,
be free of contending energy to ensure that the medium is free of be free of contending energy to ensure that the medium is free of
contending packets when the time comes for a scheduled transmission. contending packets when the time comes for a scheduled transmission.
One simple way to obtain such a window is to format time and One simple way to obtain such a window is to format time and
frequencies in cells of transmission of equal duration. This is the frequencies in cells of transmission of equal duration. This is the
method that is adopted in IEEE Std. 802.15.4 TSCH as well as the Long method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long
Term Evolution (LTE) of cellular networks. Term Evolution (LTE) of cellular networks.
The 6TiSCH architecture defines a global concept that is called a The 6TiSCH architecture defines a global concept that is called a
Channel Distribution and Usage (CDU) matrix to describe that Channel Distribution and Usage (CDU) matrix to describe that
formatting of time and frequencies. formatting of time and frequencies.
A CDU matrix is defined centrally as part of the network definition. A CDU matrix is defined centrally as part of the network definition.
It is a matrix of cells with a height equal to the number of It is a matrix of cells with a height equal to the number of
available channels (indexed by channelOffsets) and a width (in available channels (indexed by channelOffsets) and a width (in
timeslots) that is the period of the network scheduling operation timeslots) that is the period of the network scheduling operation
skipping to change at line 1619 skipping to change at line 1618
In the simplest instantiation of a 6TiSCH network, a common fixed In the simplest instantiation of a 6TiSCH network, a common fixed
schedule may be shared by all nodes in the network. Cells are schedule may be shared by all nodes in the network. Cells are
shared, and nodes contend for slot access in a Slotted ALOHA manner. shared, and nodes contend for slot access in a Slotted ALOHA manner.
A static TSCH schedule can be used to bootstrap a network, as an A static TSCH schedule can be used to bootstrap a network, as an
initial phase during implementation or as a fall-back mechanism in initial phase during implementation or as a fall-back mechanism in
case of network malfunction. This schedule is preestablished, for case of network malfunction. This schedule is preestablished, for
instance, decided by a network administrator based on operational instance, decided by a network administrator based on operational
needs. It can be preconfigured into the nodes, or, more commonly, needs. It can be preconfigured into the nodes, or, more commonly,
learned by a node when joining the network using standard IEEE Std. learned by a node when joining the network using standard IEEE Std
802.15.4 Information Elements (IE). Regardless, the schedule remains 802.15.4 Information Elements (IE). Regardless, the schedule remains
unchanged after the node has joined a network. RPL is used on the unchanged after the node has joined a network. RPL is used on the
resulting network. This "minimal" scheduling mechanism that resulting network. This "minimal" scheduling mechanism that
implements this paradigm is detailed in [RFC8180]. implements this paradigm is detailed in [RFC8180].
4.4.2. Neighbor-to-Neighbor Scheduling 4.4.2. Neighbor-to-Neighbor Scheduling
In the simplest instantiation of a 6TiSCH network described in In the simplest instantiation of a 6TiSCH network described in
Section 4.4.1, nodes may expect a packet at any cell in the schedule Section 4.4.1, nodes may expect a packet at any cell in the schedule
and will waste energy idle listening. In a more complex and will waste energy idle listening. In a more complex
skipping to change at line 1754 skipping to change at line 1753
federates multiple 6TiSCH LLNs in a single subnet over a backbone federates multiple 6TiSCH LLNs in a single subnet over a backbone
that can be, for instance, Ethernet or Wi-Fi. In that model, 6TiSCH that can be, for instance, Ethernet or Wi-Fi. In that model, 6TiSCH
6BBRs synchronize with one another over the backbone, so as to ensure 6BBRs synchronize with one another over the backbone, so as to ensure
that the multiple LLNs that form the IPv6 subnet stay tightly that the multiple LLNs that form the IPv6 subnet stay tightly
synchronized. synchronized.
If the backbone is deterministic, then the Backbone Router ensures If the backbone is deterministic, then the Backbone Router ensures
that the end-to-end deterministic behavior is maintained between the that the end-to-end deterministic behavior is maintained between the
LLN and the backbone. It is the responsibility of the PCE to compute LLN and the backbone. It is the responsibility of the PCE to compute
a deterministic path end to end across the TSCH network and an IEEE a deterministic path end to end across the TSCH network and an IEEE
Std. 802.1 TSN Ethernet backbone, and it is the responsibility of Std 802.1 TSN Ethernet backbone, and it is the responsibility of
DetNet to enable end-to-end deterministic forwarding. DetNet to enable end-to-end deterministic forwarding.
4.4.4. Hop-by-Hop Scheduling 4.4.4. Hop-by-Hop Scheduling
A node can reserve a Track (Section 4.5) to one or more A node can reserve a Track (Section 4.5) to one or more
destination(s) that are multiple hops away by installing soft cells destination(s) that are multiple hops away by installing soft cells
at each intermediate node. This forms a Track of soft cells. A at each intermediate node. This forms a Track of soft cells. A
Track SF above the 6top sublayer of each node on the Track is needed Track SF above the 6top sublayer of each node on the Track is needed
to monitor these soft cells and trigger relocation when needed. to monitor these soft cells and trigger relocation when needed.
skipping to change at line 1791 skipping to change at line 1790
use to send packets to its next hop along the Track. use to send packets to its next hop along the Track.
4.5.1. General Behavior of Tracks 4.5.1. General Behavior of Tracks
A Track is associated with Layer 2 bundles of cells with related A Track is associated with Layer 2 bundles of cells with related
schedules and logical relationships that ensure that a packet that is schedules and logical relationships that ensure that a packet that is
injected in a Track will progress in due time all the way to injected in a Track will progress in due time all the way to
destination. destination.
Multiple cells may be scheduled in a Track for the transmission of a Multiple cells may be scheduled in a Track for the transmission of a
single packet, in which case the normal operation of IEEE Std. single packet, in which case the normal operation of IEEE Std
802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the 802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the
acknowledgment may be omitted in some cases, for instance, if there acknowledgment may be omitted in some cases, for instance, if there
is no scheduled cell for a possible retry. is no scheduled cell for a possible retry.
There are several benefits for using a Track to forward a packet from There are several benefits for using a Track to forward a packet from
a source node to the destination node: a source node to the destination node:
1. Track Forwarding, as further described in Section 4.6.1, is a 1. Track Forwarding, as further described in Section 4.6.1, is a
Layer 2 forwarding scheme, which introduces less process delay Layer 2 forwarding scheme, which introduces less process delay
and overhead than a Layer 3 forwarding scheme. Therefore, LLN and overhead than a Layer 3 forwarding scheme. Therefore, LLN
skipping to change at line 1922 skipping to change at line 1921
A TX-cell that is not needed for the current iteration may be reused A TX-cell that is not needed for the current iteration may be reused
opportunistically on a per-hop basis for routed packets. When all of opportunistically on a per-hop basis for routed packets. When all of
the frames that were received for a given Track are effectively the frames that were received for a given Track are effectively
transmitted, any available TX-cell for that Track can be reused for transmitted, any available TX-cell for that Track can be reused for
upper-layer traffic for which the next-hop router matches the next upper-layer traffic for which the next-hop router matches the next
hop along the Track. In that case, the cell that is being used is hop along the Track. In that case, the cell that is being used is
effectively a TX-cell from the Track, but the short address for the effectively a TX-cell from the Track, but the short address for the
destination is that of the next-hop router. destination is that of the next-hop router.
It results in a frame that is received in a RX-cell of a Track with a It results in a frame that is received in an RX-cell of a Track with
destination MAC address set to this node, as opposed to the broadcast a destination MAC address set to this node, as opposed to the
MAC address that must be extracted from the Track and delivered to broadcast MAC address that must be extracted from the Track and
the upper layer. Note that a frame with an unrecognized destination delivered to the upper layer. Note that a frame with an unrecognized
MAC address is dropped at the lower MAC layer and thus is not destination MAC address is dropped at the lower MAC layer and thus is
received at the 6top sublayer. not received at the 6top sublayer.
On the other hand, it might happen that there are not enough TX-cells On the other hand, it might happen that there are not enough TX-cells
in the transmit bundle to accommodate the Track traffic, for in the transmit bundle to accommodate the Track traffic, for
instance, if more retransmissions are needed than provisioned. In instance, if more retransmissions are needed than provisioned. In
that case, and if the frame transports an IPv6 packet, then it can be that case, and if the frame transports an IPv6 packet, then it can be
placed for transmission in the bundle that is used for Layer 3 placed for transmission in the bundle that is used for Layer 3
traffic towards the next hop along the Track. The MAC address should traffic towards the next hop along the Track. The MAC address should
be set to the next-hop MAC address to avoid confusion. be set to the next-hop MAC address to avoid confusion.
It results in a frame that is received over a Layer 3 bundle that may It results in a frame that is received over a Layer 3 bundle that may
skipping to change at line 1974 skipping to change at line 1973
(and Layer 2 security) accepts a frame, that frame can be switched (and Layer 2 security) accepts a frame, that frame can be switched
regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN
fragment, or a frame from an alternate protocol such as WirelessHART fragment, or a frame from an alternate protocol such as WirelessHART
or ISA100.11a. or ISA100.11a.
A data frame that is forwarded along a Track normally has a A data frame that is forwarded along a Track normally has a
destination MAC address that is set to broadcast or a multicast destination MAC address that is set to broadcast or a multicast
address depending on MAC support. This way, the MAC layer in the address depending on MAC support. This way, the MAC layer in the
intermediate nodes accepts the incoming frame and 6top switches it intermediate nodes accepts the incoming frame and 6top switches it
without incurring a change in the MAC header. In the case of IEEE without incurring a change in the MAC header. In the case of IEEE
Std. 802.15.4, this means effectively to broadcast, so that along the Std 802.15.4, this means effectively to broadcast, so that along the
Track the short address for the destination of the frame is set to Track the short address for the destination of the frame is set to
0xFFFF. 0xFFFF.
There are two modes for a Track: an IPv6 native mode and a protocol- There are two modes for a Track: an IPv6 native mode and a protocol-
independent tunnel mode. independent tunnel mode.
4.6.1.1. Native Mode 4.6.1.1. Native Mode
In native mode, the Protocol Data Unit (PDU) is associated with flow- In native mode, the Protocol Data Unit (PDU) is associated with flow-
dependent metadata that refers uniquely to the Track, so the 6top dependent metadata that refers uniquely to the Track, so the 6top
sublayer can place the frame in the appropriate cell without sublayer can place the frame in the appropriate cell without
ambiguity. In the case of IPv6 traffic, this flow may be identified ambiguity. In the case of IPv6 traffic, this flow may be identified
using a 6-tuple as discussed in [DETNET-IP]. In particular, using a 6-tuple as discussed in [RFC8939]. In particular,
implementations of this document should support identification of implementations of this document should support identification of
DetNet flows based on the IPv6 Flow Label field. DetNet flows based on the IPv6 Flow Label field.
The flow follows a Track that is identified using a RPL Instance (see The flow follows a Track that is identified using a RPL Instance (see
Section 3.1.3 of [RFC6550]), signaled in a RPL Packet Information Section 3.1.3 of [RFC6550]), signaled in a RPL Packet Information
(more in Section 11.2.2.1 of [RFC6550]) and the source address of a (more in Section 11.2.2.1 of [RFC6550]) and the source address of a
packet going down the DODAG formed by a local instance. One or more packet going down the DODAG formed by a local instance. One or more
flows may be placed in a same Track and the Track identification flows may be placed in a same Track and the Track identification
(TrackID plus owner) may be placed in an IP-in-IP encapsulation. The (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 forwarding operation is based on the Track and does not depend on the
skipping to change at line 2120 skipping to change at line 2119
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Router Router Node Stack Layer Node Router Router Node
Figure 13: IP Forwarding Figure 13: IP Forwarding
4.6.3. Fragment Forwarding 4.6.3. Fragment Forwarding
Considering that, per Section 4 of [RFC4944], 6LoWPAN packets can be Considering that, per Section 4 of [RFC4944], 6LoWPAN packets can be
as large as 1280 bytes (the IPv6 minimum MTU) and that the non- as large as 1280 bytes (the IPv6 minimum MTU) and that the non-
storing mode of RPL implies source routing, which requires space for storing mode of RPL implies source routing, which requires space for
routing headers, and that an IEEE Std. 802.15.4 frame with security routing headers, and that an IEEE Std 802.15.4 frame with security
may carry in the order of 80 bytes of effective payload, an IPv6 may carry in the order of 80 bytes of effective payload, an IPv6
packet might be fragmented into more than 16 fragments at the 6LoWPAN packet might be fragmented into more than 16 fragments at the 6LoWPAN
sublayer. sublayer.
This level of fragmentation is much higher than that traditionally This level of fragmentation is much higher than that traditionally
experienced over the Internet with IPv4 fragments, where experienced over the Internet with IPv4 fragments, where
fragmentation is already known as harmful. fragmentation is already known as harmful.
In the case of a multihop route within a 6TiSCH network, hop-by-hop In the case of a multihop route within a 6TiSCH network, hop-by-hop
recomposition occurs at each hop to reform the packet and route it. recomposition occurs at each hop to reform the packet and route it.
skipping to change at line 2396 skipping to change at line 2395
selectively jam that cell without impacting any other traffic. This selectively jam that cell without impacting any other traffic. This
attack can be performed at the PHY layer without any knowledge of the attack can be performed at the PHY layer without any knowledge of the
Layer 2 keys, and it is very hard to detect and diagnose because only Layer 2 keys, and it is very hard to detect and diagnose because only
one flow is impacted. one flow is impacted.
[ROBUST-SCHEDULING] proposes a method to obfuscate the hopping [ROBUST-SCHEDULING] proposes a method to obfuscate the hopping
sequence and make it harder to perpetrate that particular attack. sequence and make it harder to perpetrate that particular attack.
6.3. MAC-Layer Security 6.3. MAC-Layer Security
This architecture operates on IEEE Std. 802.15.4 and expects the This architecture operates on IEEE Std 802.15.4 and expects the link-
link-layer security to be enabled at all times between connected layer security to be enabled at all times between connected devices,
devices, except for the very first step of the device join process, except for the very first step of the device join process, where a
where a joining device may need some initial, unsecured exchanges so joining device may need some initial, unsecured exchanges so as to
as to obtain its initial key material. In a typical deployment, all obtain its initial key material. In a typical deployment, all joined
joined nodes use the same keys, and rekeying needs to be global. nodes use the same keys, and rekeying needs to be global.
The 6TISCH architecture relies on the join process to deny The 6TISCH architecture relies on the join process to deny
authorization of invalid nodes and to preserve the integrity of the authorization of invalid nodes and to preserve the integrity of the
network keys. A rogue that managed to access the network can perform network keys. A rogue that managed to access the network can perform
a large variety of attacks from DoS to injecting forged packets and a large variety of attacks from DoS to injecting forged packets and
routing information. "Zero-trust" properties would be highly routing information. "Zero-trust" properties would be highly
desirable but are mostly not available at the time of this writing. desirable but are mostly not available at the time of this writing.
[RFC8928] is a notable exception that protects the ownership of IPv6 [RFC8928] is a notable exception that protects the ownership of IPv6
addresses and prevents a rogue node with L2 access from stealing and addresses and prevents a rogue node with L2 access from stealing and
injecting traffic on behalf of a legitimate node. injecting traffic on behalf of a legitimate node.
skipping to change at line 2429 skipping to change at line 2428
synchronizes a pledge outside of the guard time of the legitimate synchronizes a pledge outside of the guard time of the legitimate
nodes, then the pledge will never see a legitimate beacon and may not nodes, then the pledge will never see a legitimate beacon and may not
discover the attack. discover the attack.
As discussed in [RFC8655], measures must be taken to protect the time As discussed in [RFC8655], measures must be taken to protect the time
synchronization, and for 6TiSCH this includes ensuring that the synchronization, and for 6TiSCH this includes ensuring that the
Absolute Slot Number (ASN), which is the node's sense of time, is not Absolute Slot Number (ASN), which is the node's sense of time, is not
compromised. Once installed and as long as the node is synchronized compromised. Once installed and as long as the node is synchronized
to the network, ASN is implicit in the transmissions. to the network, ASN is implicit in the transmissions.
IEEE Std. 802.15.4 [IEEE802154] specifies that in a TSCH network, the IEEE Std 802.15.4 [IEEE802154] specifies that in a TSCH network, the
nonce that is used for the computation of the Message Integrity Code nonce that is used for the computation of the Message Integrity Code
(MIC) to secure link-layer frames is composed of the address of the (MIC) to secure link-layer frames is composed of the address of the
source of the frame and of the ASN. The standard assumes that the source of the frame and of the ASN. The standard assumes that the
ASN is distributed securely by other means. The ASN is not passed ASN is distributed securely by other means. The ASN is not passed
explicitly in the data frames and does not constitute a complete explicitly in the data frames and does not constitute a complete
anti-replay protection. As a result, upper-layer protocols must anti-replay protection. As a result, upper-layer protocols must
provide a way to detect duplicates and cope with them. provide a way to detect duplicates and cope with them.
If the receiver and the sender have a different sense of ASN, the MIC If the receiver and the sender have a different sense of ASN, the MIC
will not validate and the frame will be dropped. In that sense, TSCH will not validate and the frame will be dropped. In that sense, TSCH
skipping to change at line 2491 skipping to change at line 2490
already given to this or other nodes with the same keys. In other 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 words, the network must be rekeyed before the JRC runs out of short
addresses. addresses.
6.6. Network Keying and Rekeying 6.6. Network Keying and Rekeying
Section 4.2.1 provides an overview of the CoJP process described in Section 4.2.1 provides an overview of the CoJP process described in
[RFC9031] by which an LLN can be assembled in the field, having been [RFC9031] by which an LLN can be assembled in the field, having been
provisioned in a lab. [ZEROTOUCH-JOIN] is future work that precedes provisioned in a lab. [ZEROTOUCH-JOIN] is future work that precedes
and then leverages CoJP using the [CONSTRAINED-VOUCHER] constrained and then leverages CoJP using the [CONSTRAINED-VOUCHER] constrained
profile of [BRSKI]. This later work requires a yet-to-be profile of [RFC8995]. This later work requires a yet-to-be
standardized Lighweight Authenticated Key Exchange protocol. standardized Lightweight Authenticated Key Exchange protocol.
CoJP results in distribution of a network-wide key that is to be used CoJP results in distribution of a network-wide key that is to be used
with [IEEE802154] security. The details of use are described in with [IEEE802154] security. The details of use are described in
[RFC9031], Sections 9.2 and 9.3.2. [RFC9031], Sections 9.2 and 9.3.2.
The BRSKI mechanism may lead to the use of CoJP, in which case it The BRSKI mechanism may lead to the use of CoJP, in which case it
also results in distribution of a network-wide key. Alternatively also results in distribution of a network-wide key. Alternatively
the BRSKI mechanism may be followed by use of [EST-COAPS] to enroll the BRSKI mechanism may be followed by use of [EST-COAPS] to enroll
certificates for each device. In that case, the certificates may be certificates for each device. In that case, the certificates may be
used with an [IEEE802154] key agreement protocol. The description of used with an [IEEE802154] key agreement protocol. The description of
skipping to change at line 2525 skipping to change at line 2524
before the key change. Given that many nodes may be sleepy, this before the key change. Given that many nodes may be sleepy, this
operation may take a significant amount of time and may consume a operation may take a significant amount of time and may consume a
significant portion of the available bandwidth. As such, network- significant portion of the available bandwidth. As such, network-
wide rekeys to exclude nodes that have become malicious will not wide rekeys to exclude nodes that have become malicious will not
be particularly quick. If a rekey is already in progress, but the be particularly quick. If a rekey is already in progress, but the
unwanted node has not yet been updated, then it is possible to unwanted node has not yet been updated, then it is possible to
just continue the operation. If the unwanted node has already just continue the operation. If the unwanted node has already
received the update, then the rekey operation will need to be received the update, then the rekey operation will need to be
restarted. restarted.
* The cryptographic mechanisms used by IEEE Std. 802.15.4 include * The cryptographic mechanisms used by IEEE Std 802.15.4 include the
the 2-byte short address in the calculation of the context. A 2-byte short address in the calculation of the context. A nonce-
nonce-reuse attack may become feasible if a short address is reuse attack may become feasible if a short address is reassigned
reassigned to another node while the same network-wide keys are in to another node while the same network-wide keys are in operation.
operation. A network that gains and loses nodes on a regular A network that gains and loses nodes on a regular basis is likely
basis is likely to reach the 65536 limit of the 2-byte (16-bit) to reach the 65536 limit of the 2-byte (16-bit) short addresses,
short addresses, even if the network has only a few thousand even if the network has only a few thousand nodes. Network
nodes. Network planners should consider the need to rekey the planners should consider the need to rekey the network on a
network on a periodic basis in order to recover 2-byte addresses. periodic basis in order to recover 2-byte addresses. The rekey
The rekey can update the short addresses for active nodes if can update the short addresses for active nodes if desired, but
desired, but there is actually no need to do this as long as the there is actually no need to do this as long as the key has been
key has been changed. changed.
* With TSCH as it stands at the time of this writing, the ASN will * 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 wrap after 2^40 timeslot durations, meaning around 350 years with
the default values. Wrapping ASN is not expected to happen within the default values. Wrapping ASN is not expected to happen within
the lifetime of most LLNs. Yet, should the ASN wrap, the network the lifetime of most LLNs. Yet, should the ASN wrap, the network
must be rekeyed to avoid a nonce-reuse attack. must be rekeyed to avoid a nonce-reuse attack.
* Many cipher algorithms have some suggested limits on how many * Many cipher algorithms have some suggested limits on how many
bytes should be encrypted with that algorithm before a new key is bytes should be encrypted with that algorithm before a new key is
used. These numbers are typically in the many to hundreds of used. These numbers are typically in the many to hundreds of
gigabytes of data. On very fast backbone networks, this becomes gigabytes of data. On very fast backbone networks, this becomes
an important concern. On LLNs with typical data rates in the an important concern. On LLNs with typical data rates in the
kilobits/second, this concern is significantly less. With IEEE kilobits/second, this concern is significantly less. With IEEE
Std. 802.15.4 as it stands at the time of this writing, the ASN 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) will wrap before the limits of the current L2 crypto (AES-CCM-128)
are reached, so the problem should never occur. are reached, so the problem should never occur.
* In any fashion, if the LLN is expected to operate continuously for * In any fashion, if the LLN is expected to operate continuously for
decades, then the operators are advised to plan for the need to decades, then the operators are advised to plan for the need to
rekey. rekey.
Except for urgent rekeys caused by malicious nodes, the rekey Except for urgent rekeys caused by malicious nodes, the rekey
operation described in [RFC9031] can be done as a background task and operation described in [RFC9031] can be done as a background task and
can be done incrementally. It is a make-before-break mechanism. The can be done incrementally. It is a make-before-break mechanism. The
skipping to change at line 2733 skipping to change at line 2732
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks) (Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>. <https://www.rfc-editor.org/info/rfc9010>.
[RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M.
Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
RFC 9031, DOI 10.17487/RFC9031, May 2021, RFC 9031, DOI 10.17487/RFC9031, May 2021,
<https://www.rfc-editor.org/info/rfc9031>. <https://www.rfc-editor.org/info/rfc9031>.
[RFC9032] Dujovne, D. and M. Richardson, "IEEE 802.15.4 Information [RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of
Element Encapsulation of 6TiSCH Join and Enrollment 6TiSCH Join and Enrollment Information Elements",
Information", RFC 9032, DOI 10.17487/RFC9032, May 2021, RFC 9032, DOI 10.17487/RFC9032, May 2021,
<https://www.rfc-editor.org/info/rfc9032>. <https://www.rfc-editor.org/info/rfc9032>.
[RFC9033] Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy, [RFC9033] Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy,
S., and D. Dujovne, "6TiSCH Minimal Scheduling Function S., and D. Dujovne, "6TiSCH Minimal Scheduling Function
(MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021, (MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021,
<https://www.rfc-editor.org/info/rfc9033>. <https://www.rfc-editor.org/info/rfc9033>.
7.2. Informative References 7.2. Informative References
[AMI] U.S. Department of Energy, "Advanced Metering [AMI] U.S. Department of Energy, "Advanced Metering
skipping to change at line 2773 skipping to change at line 2772
draft-ietf-manet-aodvv2-16, 4 May 2016, draft-ietf-manet-aodvv2-16, 4 May 2016,
<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-16>. <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-16>.
[BITSTRINGS-6LORH] [BITSTRINGS-6LORH]
Thubert, P., Ed., Brodard, Z., Jiang, H., and G. Texier, Thubert, P., Ed., Brodard, Z., Jiang, H., and G. Texier,
"A 6loRH for BitStrings", Work in Progress, Internet- "A 6loRH for BitStrings", Work in Progress, Internet-
Draft, draft-thubert-6lo-bier-dispatch-06, 28 January Draft, draft-thubert-6lo-bier-dispatch-06, 28 January
2019, <https://tools.ietf.org/html/draft-thubert-6lo-bier- 2019, <https://tools.ietf.org/html/draft-thubert-6lo-bier-
dispatch-06>. dispatch-06>.
[BRSKI] Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M.
H., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", Work in Progress, Internet-
Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11
November 2020, <https://tools.ietf.org/html/draft-ietf-
anima-bootstrapping-keyinfra-45>.
[CCAMP] IETF, "Common Control and Measurement Plane (ccamp)", [CCAMP] IETF, "Common Control and Measurement Plane (ccamp)",
<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>. <https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[CCMstar] Struik, R., "Formal Specification of the CCM* Mode of [CCMstar] Struik, R., "Formal Specification of the CCM* Mode of
Operation", September 2004, <http://www.ieee802.org/15/ Operation", September 2004, <http://www.ieee802.org/15/
pub/2004/15-04-0537-00-004b-formal-specification-ccm-star- pub/2004/15-04-0537-00-004b-formal-specification-ccm-star-
mode-operation.doc>. mode-operation.doc>.
[CONSTRAINED-VOUCHER] [CONSTRAINED-VOUCHER]
Richardson, M., van der Stok, P., and P. Kampanakis, Richardson, M., van der Stok, P., and P. Kampanakis,
skipping to change at line 2803 skipping to change at line 2795
<https://tools.ietf.org/html/draft-ietf-anima-constrained- <https://tools.ietf.org/html/draft-ietf-anima-constrained-
voucher-10>. voucher-10>.
[DAO-PROJECTION] [DAO-PROJECTION]
Thubert, P., Jadhav, R. A., and M. Gillmore, "Root Thubert, P., Jadhav, R. A., and M. Gillmore, "Root
initiated routing state in RPL", Work in Progress, initiated routing state in RPL", Work in Progress,
Internet-Draft, draft-ietf-roll-dao-projection-16, 15 Internet-Draft, draft-ietf-roll-dao-projection-16, 15
January 2021, <https://tools.ietf.org/html/draft-ietf- January 2021, <https://tools.ietf.org/html/draft-ietf-
roll-dao-projection-16>. roll-dao-projection-16>.
[DETNET-IP]
Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", Work in Progress, Internet-Draft, draft-ietf-detnet-
ip-07, 3 July 2020,
<https://tools.ietf.org/html/draft-ietf-detnet-ip-07>.
[EDHOC] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral [EDHOC] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Diffie-Hellman Over COSE (EDHOC)", Work in Progress,
Internet-Draft, draft-selander-ace-cose-ecdhe-14, 11 Internet-Draft, draft-selander-ace-cose-ecdhe-14, 11
September 2019, <https://tools.ietf.org/html/draft- September 2019, <https://tools.ietf.org/html/draft-
selander-ace-cose-ecdhe-14>. selander-ace-cose-ecdhe-14>.
[EST-COAPS] [EST-COAPS]
van der Stok, P., Kampanakis, P., Richardson, M., and S. van der Stok, P., Kampanakis, P., Richardson, M., and S.
Raza, "EST over secure CoAP (EST-coaps)", Work in Raza, "EST over secure CoAP (EST-coaps)", Work in
Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6
skipping to change at line 2966 skipping to change at line 2951
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019, RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>. <https://www.rfc-editor.org/info/rfc8578>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <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- [RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
Power and Lossy Networks (RPL) Destination-Oriented Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration Option for Directed Acyclic Graph (DODAG) Configuration Option for
the 6LoWPAN Routing Header", RFC 9035, the 6LoWPAN Routing Header", RFC 9035,
DOI 10.17487/RFC9035, April 2021, DOI 10.17487/RFC9035, April 2021,
<https://www.rfc-editor.org/info/rfc9035>. <https://www.rfc-editor.org/info/rfc9035>.
[ROBUST-SCHEDULING] [ROBUST-SCHEDULING]
Tiloca, M., Duquennoy, S., and G. Dini, "Robust Scheduling Tiloca, M., Duquennoy, S., and G. Dini, "Robust Scheduling
against Selective Jamming in 6TiSCH Networks", Work in against Selective Jamming in 6TiSCH Networks", Work in
skipping to change at line 3050 skipping to change at line 3045
items. At the time of publishing, the following specifications are items. At the time of publishing, the following specifications are
still in progress and may affect the evolution of the stack in a still in progress and may affect the evolution of the stack in a
6TiSCH-aware node. 6TiSCH-aware node.
A.1. Unchartered IETF Work Items A.1. Unchartered IETF Work Items
A.1.1. 6TiSCH Zero-Touch Security A.1.1. 6TiSCH Zero-Touch Security
The security model and in particular the zero-touch join process The security model and in particular the zero-touch join process
[ZEROTOUCH-JOIN] depend on the ANIMA (Autonomic Networking Integrated [ZEROTOUCH-JOIN] depend on the ANIMA (Autonomic Networking Integrated
Model and Approach) [ANIMA] Bootstrapping Remote Secure Key Model and Approach) [ANIMA] "Bootstrapping Remote Secure Key
Infrastructures (BRSKI) [BRSKI] to enable zero-touch security Infrastructure (BRSKI)" [RFC8995] to enable zero-touch security
provisioning; for highly constrained nodes, a minimal model based on provisioning; for highly constrained nodes, a minimal model based on
pre-shared keys (PSK) is also available. As currently written, it pre-shared keys (PSK) is also available. As currently written, it
also depends on a number of documents in progress in the CORE also depends on a number of documents in progress in the CORE
(Constrained RESTful Environments) WG and on "Ephemeral (Constrained RESTful Environments) WG and on "Ephemeral
Diffie-Hellman Over COSE (EDHOC)" [EDHOC], which is being considered Diffie-Hellman Over COSE (EDHOC)" [EDHOC], which is being considered
for adoption by the LAKE (Lightweight Authenticated Key Exchange) WG. for adoption by the LAKE (Lightweight Authenticated Key Exchange) WG.
A.1.2. 6TiSCH Track Setup A.1.2. 6TiSCH Track Setup
ROLL (Routing Over Low power and Lossy networks) is now standardizing ROLL (Routing Over Low power and Lossy networks) is now standardizing
skipping to change at line 3107 skipping to change at line 3102
plane, and to provide traceability on links where replication and plane, and to provide traceability on links where replication and
loss happen, in a manner that is abstract to the forwarding loss happen, in a manner that is abstract to the forwarding
information. information.
"A 6loRH for BitStrings" [BITSTRINGS-6LORH] proposes a 6LoWPAN "A 6loRH for BitStrings" [BITSTRINGS-6LORH] proposes a 6LoWPAN
compression for the BIER BitString based on 6LoWPAN Routing Header compression for the BIER BitString based on 6LoWPAN Routing Header
[RFC8138]. [RFC8138].
A.2. External (Non-IETF) Work Items A.2. External (Non-IETF) Work Items
The current charter positions 6TiSCH on IEEE Std. 802.15.4 only. The current charter positions 6TiSCH on IEEE Std 802.15.4 only.
Though most of the design should be portable to other link types, Though most of the design should be portable to other link types,
6TiSCH has a strong dependency on IEEE Std. 802.15.4 and its 6TiSCH has a strong dependency on IEEE Std 802.15.4 and its
evolution. The impact of changes to TSCH on this architecture should evolution. The impact of changes to TSCH on this architecture should
be minimal to nonexistent, but deeper work such as 6top and security be minimal to nonexistent, but deeper work such as 6top and security
may be impacted. A 6TiSCH Interest Group at the IEEE maintains the may be impacted. A 6TiSCH Interest Group at the IEEE maintains the
synchronization and helps foster work at the IEEE should 6TiSCH synchronization and helps foster work at the IEEE should 6TiSCH
demand it. demand it.
Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would
logically include the 6top sublayer. The interaction with the 6top logically include the 6top sublayer. The interaction with the 6top
sublayer and the Scheduling Functions described in this document are sublayer and the Scheduling Functions described in this document are
yet to be defined. yet to be defined.
 End of changes. 46 change blocks. 
92 lines changed or deleted 87 lines changed or added

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