rfc9030.original.xml   rfc9030.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc toc="yes"?> category="info"
<?rfc tocompact="yes"?> ipr="trust200902"
<?rfc tocdepth="3"?> tocInclude="true"
<?rfc tocindent="yes"?> sortRefs="true"
<?rfc symrefs="yes"?> symRefs="true"
<?rfc sortrefs="yes"?> obsoletes=""
<?rfc comments="yes"?> updates=""
<?rfc inline="yes"?> consensus="true"
<?rfc compact="no"?> submissionType="IETF"
<?rfc subcompact="no"?> xml:lang="en"
<?rfc authorship="yes"?> version="3"
<?rfc tocappendix="yes"?> docName="draft-ietf-6tisch-architecture-30"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr='trust20090 number="9030">
2' tocInclude="true" obsoletes="" updates="" consensus="true" submissionType="I
ETF" xml:lang="en" version="3" docName="draft-ietf-6tisch-architecture-30" >
<front> <front>
<title abbrev='6tisch-architecture'>An Architecture for IPv6 over the TSCH mo <title abbrev="6TiSCH Architecture">An Architecture for IPv6 over
de of IEEE 802.15.4</title> the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)</title>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor <seriesInfo name="RFC" value="9030"/>
'>
<organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor
">
<organization abbrev="Cisco Systems">Cisco Systems, Inc</organization>
<address> <address>
<postal> <postal>
<street>Building D</street> <extaddr>Building D</extaddr>
<street>45 Allee des Ormes - BP1200 </street> <street>45 Allee des Ormes - BP1200 </street>
<city>Mougins - Sophia Antipolis</city> <city>Mougins - Sophia Antipolis</city>
<code>06254</code> <code>06254</code>
<country>France</country> <country>France</country>
</postal> </postal>
<phone>+33 497 23 26 34</phone> <phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email> <email>pthubert@cisco.com</email>
</address> </address>
</author> </author>
<date/> <date month="May" year="2021"/>
<area>Internet Area</area> <area>Internet Area</area>
<workgroup>6TiSCH</workgroup> <workgroup>6TiSCH</workgroup>
<keyword>Draft</keyword> <keyword>deterministic wireless</keyword>
<keyword>radio</keyword>
<keyword>mesh</keyword>
<abstract> <abstract>
<t> This document describes a network architecture that provides <t> This document describes a network architecture that provides
low-latency, low-jitter and high-reliability packet delivery. It low-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 802.15.4 time-slotted channel hopping (TSCH) to meet the
requirements of LowPower wireless deterministic applications. requirements of low-power wireless deterministic applications.
<!--
This document presents the 6TiSCH architecture of an IPv6
Multi-Link subnet that is composed of a high-speed powered backbone and
a number of IEEE Std. 802.15.4 TSCH low-power wireless networks attache
d and
synchronized by Backbone Routers. The architecture defines mechanisms
to establish and maintain routing and scheduling in a centralized,
distributed, or mixed fashion.
Backbone Routers perform proxy Neighbor Discovery operations over
the backbone on behalf of the wireless devices, so they can share a sam
e
subnet and appear to be connected to the same backbone as classical dev
ices.
-->
</t> </t>
</abstract> </abstract>
<!--note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.
</t>
</note-->
</front> </front>
<middle> <middle>
<section><name>Introduction</name> <section><name>Introduction</name>
<t> <t>
Wireless Networks enable a wide variety of devices of any size Wireless networks enable a wide variety of devices of any size
to get interconnected, often at a very low marginal cost per device, to get interconnected, often at a very low marginal cost per device,
at any range, and in circumstances where wiring may be impractical, at any range, and in circumstances where wiring may be impractical,
for instance on fast-moving or rotating devices. for instance, on fast-moving or rotating devices.
</t> </t>
<t> <t>
On the other hand, Deterministic Networking maximizes the packet On the other hand, Deterministic Networking maximizes the packet
delivery ratio within a bounded latency so as to enable delivery ratio within a bounded latency so as to enable
mission-critical machine-to-machine (M2M) operations. mission-critical machine-to-machine (M2M) operations.
<!-- At IEEE Std. 802.1, the
<xref target="IEEE Std. 802.1TSNTG">Time Sensitive Networking</xref>(TS
N)
task group was formed to provide deterministic properties at Layer-2
across multiple hops. -->
Applications that need such networks are presented in Applications that need such networks are presented in
<xref target='RFC8578'/>. <xref target="RFC8578"/>
<!--and and
<xref target="I-D.bernardos-raw-use-cases"/>, which presents a number <xref target="I-D.ietf-raw-use-cases"/>, which presents a number
of additional use cases for Reliable and Available Wireless networks. of additional use cases for Reliable and Available Wireless networks (R
--> AW).
The considered applications include Professional Media, Industrial The considered applications include professional media, Industrial
Automation Control Systems (IACS), building Automation and Control Systems (IACS), building
automation, in-vehicle command and control, commercial automation and automation, in-vehicle command and control, commercial automation and
asset tracking with mobile scenarios, as well as gaming, drones and edg asset tracking with mobile scenarios, as well as gaming, drones and
e robotic control, and home automation applications. edge robotic control, and home automation applications.
</t> </t>
<t> <t>
The Timeslotted Channel Hopping (TSCH) <xref target='RFC7554'/> mode The Time-Slotted Channel Hopping (TSCH) <xref target="RFC7554"/> mode
of the IEEE Std. 802.15.4 <xref target='IEEE802154'/> Medium Access of the IEEE Std 802.15.4 <xref target="IEEE802154"/> Medium Access
Control (MAC) was introduced with the IEEE Std. 802.15.4e Control (MAC) was introduced with the IEEE Std 802.15.4e
<xref target='IEEE802154e'/> amendment and is now retrofitted in the <xref target="IEEE802154e"/> amendment and is now retrofitted in the
main standard. For all practical purposes, this document main standard. For all practical purposes, this document
is expected to be insensitive to the revisions of that standard, is expected to be insensitive to the revisions of that standard,
which is thus referenced without a date. which is thus referenced without a date.
TSCH is both a Time-Division Multiplexing and a Frequency-Division TSCH is both a Time-Division Multiplexing (TDM) and a Frequency-Divisio
Multiplexing technique whereby a different channel can be used for n
each transmission, and that allows to schedule transmissions for Multiplexing (FDM) technique, whereby a different channel can be used f
deterministic operations, and applies to the slower and most energy or
constrained wireless use cases. each transmission. TSCH allows the scheduling of transmissions for
deterministic operations and applies to the slower and most
energy-constrained wireless use cases.
</t> </t>
<t> <t>
The scheduled operation provides for a more reliable experience which The scheduled operation provides for a more reliable experience, which
can be used to monitor and manage resources, e.g., energy and water, in can be used to monitor and manage resources, e.g., energy and water, in
a more efficient fashion. a more efficient fashion.
</t> </t>
<t> <t>
Proven Deterministic Networking standards for use in Process Control, Proven deterministic networking standards for use in process control,
including ISA100.11a <xref target='ISA100.11a'/> and WirelessHART including ISA100.11a <xref target="ISA100.11a"/> and WirelessHART
<xref target='WirelessHART'/>, have demonstrated the capabilities <xref target="WirelessHART"/>, have demonstrated the capabilities
of the IEEE Std. 802.15.4 TSCH MAC for high reliability against interfe of the IEEE Std 802.15.4 TSCH MAC for high reliability against interfer
rence, ence,
low-power consumption on well-known flows, and its applicability for low-power consumption on well-known flows, and its applicability for
Traffic Engineering (TE) from a central controller. Traffic Engineering (TE) from a central controller.
</t> </t>
<t>To enable the convergence of Information Technology (IT) and <t>To enable the convergence of information technology (IT) and
Operational Technology (OT) in Low-Power Lossy operational technology (OT) in Low-Power and Lossy
Networks (LLNs), the 6TiSCH Architecture supports an IETF suite of Networks (LLNs), the 6TiSCH architecture supports an IETF suite of
protocols over the IEEE Std. 802.15.4 TSCH MAC to provide protocols over the IEEE Std 802.15.4 TSCH MAC to provide
IP connectivity for energy and otherwise constrained wireless devices. IP connectivity for energy and otherwise constrained wireless devices.
</t> </t>
<t> <t>
The 6TiSCH Architecture relies on IPv6 <xref target='RFC8200'/> and the The 6TiSCH architecture relies on IPv6 <xref target="RFC8200"/> and the
use of routing to provide large scaling capabilities. The addition of a use of 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 as 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 an Ethernet bridged network, but it can also be a more complex routed
structure. structure.
</t> </t>
<t> <t>
The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model that The 6TiSCH architecture introduces an IPv6 multi-link subnet model that
is composed of a federating backbone and a number of IEEE Std. 802.15.4 is composed of a federating backbone and a number of IEEE Std 802.15.4
TSCH low-power wireless networks federated and synchronized by Backbone TSCH low-power wireless networks federated and synchronized by Backbone
Routers. If the backbone is a Layer-2 transit Link then the Backbone Routers. If the backbone is a Layer 2 transit link, then the Backbone
Routers can operate as an IPv6 Neighbor Discovery (IPv6 ND) Routers can operate as an IPv6 Neighbor Discovery (IPv6 ND) proxy
<xref target='RFC4861'/> proxy. <xref target="RFC4861"/>.
</t> </t>
<t> <t>
The 6TiSCH The 6TiSCH architecture leverages 6LoWPAN <xref target="RFC4944"/> to a
Architecture leverages 6LoWPAN <xref target='RFC4944'/> to adapt IPv6 dapt IPv6
to the constrained media and RPL <xref target='RFC6550'/> for the to the constrained media and the
Routing Protocol for Low-Power and Lossy Networks (RPL) <xref target="
RFC6550"/> for the
distributed routing operations. distributed routing operations.
</t> </t>
<t> <t>
Centralized routing refers to a model where routes are computed Centralized routing refers to a model where routes are computed
and resources are allocated from a central controller. This is and resources are allocated from a central controller. This is
particularly helpful to schedule deterministic multihop transmissions. particularly helpful to schedule deterministic multihop transmissions.
In contrast, Distributed Routing refers to a model that relies on In contrast, distributed routing refers to a model that relies on
concurrent peer to peer protocol exchanges for TSCH resource allocation concurrent peer-to-peer protocol exchanges for TSCH resource allocation
and routing operations. and routing operations.
</t> </t>
<t> <t>
The architecture defines mechanisms to establish and maintain routing The architecture defines mechanisms to establish and maintain routing
and scheduling in a centralized, distributed, or mixed fashion, for use and scheduling in a centralized, distributed, or mixed fashion, for use
in multiple OT environments. It is applicable in particular to highly in multiple OT environments. It is applicable in particular to highly
scalable solutions such as used in Advanced Metering Infrastructure scalable solutions such as those used in Advanced Metering Infrastructu
<xref target='AMI'/> solutions that leverage distributed routing to re
<xref target="AMI"/> solutions that leverage distributed routing to
enable multipath forwarding over large LLN meshes. enable multipath forwarding over large LLN meshes.
</t> </t>
</section> </section>
<section><name>Terminology</name> <section><name>Terminology</name>
<!--
<section anchor='bcp' title="BCP 14">
<t>-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
</t>
</section> end section "BCP 14" -->
<section anchor='sixTTerminology'><name>New Terms</name> <section anchor="sixTTerminology"><name>New Terms</name>
<t> <t>
The draft does not reuse terms from the <xref target='IEEE802154'> The document does not reuse terms from the <xref target="IEEE802154"
IEEE Std. 802.15.4</xref> standard such as "path" or "link" which be >
ar IEEE Std 802.15.4</xref> standard such as "path" or "link", which be
ar
a meaning that is quite different from classical IETF parlance. a meaning that is quite different from classical IETF parlance.
</t> </t>
<t> <t>This document adds the following terms:</t>
This document adds the following terms: <dl spacing="normal">
</t><dl spacing='normal'>
<dt>6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4):</dt><dd> <dt>6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4):</dt><dd>
6TiSCH defines an adaptation sublayer for IPv6 over TSCH calle d 6top, 6TiSCH defines an adaptation sublayer for IPv6 over TSCH calle d 6top,
a set of protocols for setting up a TSCH schedule in distribute d a set of protocols for setting up a TSCH schedule in distribute d
approach, and a security solution. 6TiSCH may be extended in th e future for other approach, and a security solution. 6TiSCH may be extended in th e future for other
MAC/PHY pairs providing a service similar to TSCH. MAC/Physical Layer (PHY) pairs providing a service similar to T SCH.
</dd> </dd>
<dt>6top (6TiSCH Operation Sublayer):</dt><dd> <dt>6top (6TiSCH Operation Sublayer):</dt><dd>
The next higher layer of the IEEE Std. 802.15.4 TSCH MAC layer. The next higher layer of the IEEE Std 802.15.4 TSCH MAC layer.
6top provides the abstraction of an IP link over a TSCH MAC, 6top provides the abstraction of an IP link over a TSCH MAC,
schedules packets over TSCH cells, and exposes a management schedules packets over TSCH cells, and exposes a management
interface to schedule TSCH cells. interface to schedule TSCH cells.
</dd> </dd>
<dt>6P (6top Protocol):</dt><dd> <dt>6P (6top Protocol):</dt><dd>
The protocol defined in <xref target='RFC8480'/>. The protocol defined in <xref target="RFC8480"/>.
6P enables Layer-2 peers to allocate, move or deallocate 6P enables Layer 2 peers to allocate, move, or de-allocate
cells in their respective schedules to communicate. cells in their respective schedules to communicate.
6P operates at the 6top layer. 6P operates at the 6top sublayer.
</dd> </dd>
<dt>6P Transaction:</dt><dd> <dt>6P transaction:</dt><dd>
A 2-way or 3-way sequence of 6P messages used by Layer-2 A 2-way or 3-way sequence of 6P messages used by Layer 2
peers to modify their communication schedule. peers to modify their communication schedule.
</dd> </dd>
<dt>ASN (Absolute Slot Number):</dt><dd> <dt>ASN (Absolute Slot Number):</dt><dd>
Defined in <xref target='IEEE802154'/>, the ASN is the total Defined in <xref target="IEEE802154"/>, the ASN is the total
number of timeslots that have elapsed since the Epoch Time number of timeslots that have elapsed since the Epoch time
when the TSCH network started. when the TSCH network started.
Incremented by one at each timeslot. Incremented by one at each timeslot.
It is wide enough to not roll over in practice. It is wide enough to not roll over in practice.
</dd> </dd>
<!--
<t hangText="blacklist of frequencies:">
A set of frequencies which should not be used for
communication.
</t>
<t hangText="broadcast cell:">
A scheduled cell used for broadcast transmission.
</t> -->
<dt>bundle:</dt><dd> <dt>bundle:</dt><dd>
A group of equivalent scheduled cells, i.e., cells A group of equivalent scheduled cells, i.e., cells
identified by different [slotOffset, channelOffset], identified by different slotOffset/channelOffset,
which are scheduled for a same purpose, with the same which are scheduled for a same purpose, with the same
neighbor, with the same flags, and the same slotframe. neighbor, with the same flags, and the same slotframe.
The size of the bundle refers to the number of cells it The size of the bundle refers to the number of cells it
contains. contains.
For a given slotframe length, the size of the bundle For a given slotframe length, the size of the bundle
translates directly into bandwidth. translates directly into bandwidth.
A bundle is a local abstraction that represents a A bundle is a local abstraction that represents a
half-duplex link for either sending or receiving, half-duplex link for either sending or receiving,
with bandwidth that amounts to the sum of the cells in the with bandwidth that amounts to the sum of the cells in the
bundle. bundle.
</dd> </dd>
<dt>Layer-2 vs. Layer-3 bundle:</dt><dd> <dt>Layer 2 vs. Layer 3 bundle:</dt><dd>
Bundles are associated for either Layer-2 (switching) or Bundles are associated with either Layer 2 (switching) or
Layer-3 (routing) forwarding operations. A pair of Layer-3 Layer 3 (routing) forwarding operations. A pair of Layer 3
bundles (one for each direction) maps to an IP Link with a bundles (one for each direction) maps to an IP link with a
neighbor, whereas a set of Layer-2 bundles (of an neighbor, whereas a set of Layer 2 bundles (of an
"arbitrary" cardinality and direction) corresponds to the re "arbitrary" cardinality and direction) corresponds to the re
lation of one or more incoming bundle(s) from the lation
of one or more incoming bundle(s) from the
previous-hop neighbor(s) with one or more outgoing bundle(s) previous-hop neighbor(s) with one or more outgoing bundle(s)
to the next-hop neighbor(s) along a Track as part of the to the next-hop neighbor(s) along a Track as part of the
switching role, which may include replication and eliminatio n. switching role, which may include replication and eliminatio n.
</dd> </dd>
<dt>CCA (Clear Channel Assessment):</dt><dd> <dt>CCA (Clear Channel Assessment):</dt><dd>
A mechanism defined in <xref target='IEEE802154'/> whereby A mechanism defined in <xref target="IEEE802154"/> whereby
nodes listen to the channel before sending to nodes listen to the channel before sending to
detect ongoing transmissions from other parties. detect ongoing transmissions from other parties.
Because the network is synchronized, CCA cannot be used to Because the network is synchronized, CCA cannot be used to
detect colliding transmissions within the same network, but detect colliding transmissions within the same network, but
it can be used to detect other radio networks in vicinity. it can be used to detect other radio networks in the vicinit y.
</dd> </dd>
<dt>cell:</dt><dd> <dt>cell:</dt><dd>
A unit of transmission resource in the CDU matrix, a cell is A unit of transmission resource in the CDU matrix, a cell is
identified by a slotOffset and a channelOffset. identified by a slotOffset and a channelOffset.
A cell can be scheduled or unscheduled. A cell can be scheduled or unscheduled.
</dd> </dd>
<dt>Channel Distribution/Usage (CDU) matrix:</dt><dd>: <dt>Channel Distribution/Usage (CDU) matrix:</dt><dd>:
A matrix of cells (i,j) representing the spectrum (channel) A matrix of cells (i,j) representing the spectrum (channel)
distribution among the different nodes in the 6TiSCH network . distribution among the different nodes in the 6TiSCH network .
The CDU matrix has width in timeslots, equal to the period The CDU matrix has width in timeslots equal to the period
of the network scheduling operation, and height equal to of the network scheduling operation, and height equal to
the number of available channels. the number of available channels.
Every cell (i,j) in the CDU, identified by (slotOffset, Every cell (i,j) in the CDU, identified by slotOffset/channe
channelOffset), belongs to a specific chunk. lOffset,
belongs to a specific chunk.
</dd> </dd>
<dt>channelOffset:</dt><dd> <dt>channelOffset:</dt><dd>
Identifies a row in the TSCH schedule. The number of Identifies a row in the TSCH schedule. The number of
channelOffset values is bounded by the number of available channelOffset values is bounded by the number of available
frequencies. The channelOffset translates into a frequency frequencies. The channelOffset translates into a frequency
with a function that depends on the absolute time when the with a function that depends on the absolute time when the
communication takes place, resulting in a channel hopping communication takes place, resulting in a channel-hopping
operation. operation.
</dd> </dd>
<dt>chunk:</dt><dd> <dt>chunk:</dt><dd>
A well-known list of cells, distributed in time and frequenc y, within a CDU matrix. A well-known list of cells, distributed in time and frequenc y, within a CDU matrix.
A chunk represents a portion of a CDU matrix. A chunk represents a portion of a CDU matrix.
The partition of the CDU matrix in chunks is globally known by all the nodes in the network to support the appropriation process, which is a negotiation between nodes within an interference domain. The partition of the CDU matrix in chunks is globally known by all the nodes in the network to support the appropriation process, which is a negotiation between nodes within an interference domain.
A node that manages to appropriate a chunk gets to decide wh ich transmissions will occur over the cells in the chunk within its interference domain, i.e., a parent node will decide when the cells within the appropriated chunk are used and by which node, among its children. A node that manages to appropriate a chunk gets to decide wh ich transmissions will occur over the cells in the chunk within its interference domain, i.e., a parent node will decide when the cells within the appropriated chunk are used and by which node among its children.
</dd> </dd>
<dt>CoJP (Constrained Join Protocol):</dt><dd> <dt>CoJP (Constrained Join Protocol):</dt><dd>
<!--
CoJP is a one-touch join protocol defined in the
<xref target="I-D.ietf-6tisch-minimal-security">
Minimal Security Framework for 6TiSCH</xref>.
CoJP requires the distribution of preshared keys (PSK), and
enables a node to join with a single round trip
to the JRC via the JP.
-->
The Constrained Join Protocol (CoJP) enables a pledge to The Constrained Join Protocol (CoJP) enables a pledge to
securely join a 6TiSCH network and obtain network parameters securely join a 6TiSCH network and obtain network parameters
over a secure channel. over a secure channel.
<!-- "<xref target="RFC9031" format="title"/>" <xref target="RFC9
CoJP is defined in the 031"/> defines
<xref target="I-D.ietf-6tisch-minimal-security">
Minimal Security Framework for 6TiSCH </xref>.
-->
<xref target='I-D.ietf-6tisch-minimal-security'>
Minimal Security Framework for 6TiSCH </xref> defines
the minimal CoJP setup with pre-shared keys defined. In that the minimal CoJP setup with pre-shared keys defined. In that
mode, CoJP can operate with a single round trip exchange. mode, CoJP can operate with a single round-trip exchange.
</dd> </dd>
<dt>dedicated cell:</dt><dd> <dt>dedicated cell:</dt><dd>
A cell that is reserved for a given node to transmit to a sp ecific neighbor. A cell that is reserved for a given node to transmit to a sp ecific neighbor.
</dd> </dd>
<dt>deterministic network:</dt><dd> <dt>deterministic network:</dt><dd>
The generic concept of deterministic network is defined in t The generic concept of a deterministic network is defined
he <xref target='RFC8655'>"DetNet Architecture"</xref> document. in the <xref target="RFC8655">"Deterministic Networking Arch
When applied to 6TiSCH, it refers to the reservation of Trac itecture"</xref> document.
ks which guarantees an end-to-end latency and optimizes the Packet Delivery Rati When applied to 6TiSCH, it refers to the reservation of Trac
o (PDR) for well-characterized flows. ks,
which guarantees an end-to-end latency and optimizes the
Packet Delivery Ratio (PDR) for well-characterized flows.
</dd> </dd>
<dt>distributed cell reservation:</dt><dd> <dt>distributed cell reservation:</dt><dd>
A reservation of a cell done by one or more in-network enti ties. A reservation of a cell done by one or more in-network enti ties.
</dd> </dd>
<dt>distributed Track reservation:</dt><dd> <dt>distributed Track reservation:</dt><dd>
A reservation of a Track done by one or more in-network enti ties. A reservation of a Track done by one or more in-network enti ties.
</dd> </dd>
<dt>EB (Enhanced Beacon):</dt><dd> <dt>EB (Enhanced Beacon):</dt><dd>
A special frame defined in <xref target='IEEE802154'/> A special frame defined in <xref target="IEEE802154"/>
used by a node, including the JP, to announce the presence used by a node, including the Join Proxy (JP), to announce t
he presence
of the network. of the network.
It contains enough information for a pledge to synchronize t o the network. It contains enough information for a pledge to synchronize t o the network.
</dd> </dd>
<dt>hard cell:</dt><dd> <dt>hard cell:</dt><dd>
A scheduled cell which the 6top sublayer may not relocate. A scheduled cell that the 6top sublayer may not relocate.
</dd> </dd>
<dt>hopping sequence:</dt><dd> <dt>hopping sequence:</dt><dd>
Ordered sequence of frequencies, identified by a Hopping_Seq uence_ID, used for channel hopping when translating the channelOffset value into a frequency. Ordered sequence of frequencies, identified by a Hopping_Seq uence_ID, used for channel hopping when translating the channelOffset value into a frequency.
</dd> </dd>
<dt>IE (Information Element):</dt><dd> <dt>IE (Information Element):</dt><dd>
Type-Length-Value containers placed at the end of the MAC he Type-Length-Value containers placed at the end of the MAC he
ader, used to pass data between layers or devices. ader and used to pass data between layers or devices.
Some IE identifiers are managed by the IEEE <xref target='IE Some IE identifiers are managed by the IEEE <xref target="IE
EE802154'/>. EE802154"/>.
Some IE identifiers are managed by the IETF <xref target='RF Some IE identifiers are managed by the IETF <xref target="RF
C8137'/>, and <xref target='I-D.ietf-6tisch-enrollment-enhanced-beacon'/> uses o C8137"/>. <xref target="RFC9032"/>
ne subtype to support the selection of the Join Proxy. uses one subtype to support the selection of the Join Proxy.
</dd> </dd>
<dt>join process:</dt><dd> <dt>join process:</dt><dd>
The overall process that includes the discovery of the netwo rk by pledge(s) and the execution of the join protocol. The overall process that includes the discovery of the netwo rk by pledge(s) and the execution of the join protocol.
</dd> </dd>
<dt>join protocol:</dt><dd> <dt>join protocol:</dt><dd>
The protocol that allows the pledge to join the network. The protocol that allows the pledge to join the network.
The join protocol encompasses authentication, authorization and parameter distribution. The join protocol encompasses authentication, authorization, and parameter distribution.
The join protocol is executed between the pledge and the JRC . The join protocol is executed between the pledge and the JRC .
</dd> </dd>
<dt>joined node:</dt><dd> <dt>joined node:</dt><dd>
The new device, after having completed the join process, oft en just called a node. The new device after having completed the join process, ofte n just called a node.
</dd> </dd>
<dt>JP (Join Proxy):</dt><dd> <dt>JP (Join Proxy):</dt><dd>
Node already part of the 6TiSCH network that serves as a rel ay to provide connectivity between the pledge and the JRC. A node already part of the 6TiSCH network that serves as a r elay to provide connectivity between the pledge and the JRC.
The JP announces the presence of the network by regularly se nding EB frames. The JP announces the presence of the network by regularly se nding EB frames.
</dd> </dd>
<dt>JRC (Join Registrar/Coordinator):</dt><dd> <dt>JRC (Join Registrar/Coordinator):</dt><dd>
Central entity responsible for the authentication, authoriza tion and configuration of the pledge. Central entity responsible for the authentication, authoriza tion, and configuration of the pledge.
</dd> </dd>
<dt>link:</dt><dd> <dt>link:</dt><dd>
A communication facility or medium over which nodes can comm A communication facility or medium over which nodes can comm
unicate at the Link-Layer, the layer immediately below IP. In 6TiSCH, the concep unicate
t is implemented as a collection at the link layer, which is the layer immediately below IP.
of Layer-3 bundles. Note: In 6TiSCH, the concept is implemented as a collection
the IETF parlance for the term "Link" is adopted, as opposed of Layer 3 bundles. Note:
to the IEEE Std. 802.15.4 terminology. the IETF parlance for the term "link" is adopted, as opposed
to the IEEE Std 802.15.4 terminology.
</dd> </dd>
<dt>Operational Technology:</dt><dd> <dt>operational technology:</dt><dd>
OT refers to technology used in automation, for instance in OT refers to technology used in automation, for instance in
industrial control networks. The convergence of IT and OT is industrial control networks. The convergence of IT and OT is
the main object of the Industrial Internet of Things (IIOT). the main object of the Industrial Internet of Things (IIOT).
</dd> </dd>
<dt>pledge:</dt><dd> <dt>pledge:</dt><dd>
A new device that attempts to join a 6TiSCH network. A new device that attempts to join a 6TiSCH network.
</dd> </dd>
<dt>(to) relocate a cell:</dt><dd> <dt>(to) relocate a cell:</dt><dd>
The action operated by the 6top sublayer of changing the slo tOffset and/or channelOffset of a soft cell. The action operated by the 6top sublayer of changing the slo tOffset and/or channelOffset of a soft cell.
</dd> </dd>
<dt>(to) schedule a cell:</dt><dd> <dt>(to) schedule a cell:</dt><dd>
The action of turning an unscheduled cell into a scheduled c ell. The action of turning an unscheduled cell into a scheduled c ell.
</dd> </dd>
<dt>scheduled cell:</dt><dd> <dt>scheduled cell:</dt><dd>
A cell which is assigned a neighbor MAC address (broadcast a A cell that is assigned a neighbor MAC address
ddress is also possible), and one or more of the following flags: TX, RX, Shared (broadcast address is also possible) and one or
and Timekeeping. more of the following flags: TX, RX, Shared, and Timekeeping
A scheduled cell can be used by the IEEE Std. 802.15.4 TSCH .
implementation to communicate. A scheduled cell can be used by the IEEE Std 802.15.4 TSCH i
mplementation to communicate.
A scheduled cell can either be a hard or a soft cell. A scheduled cell can either be a hard or a soft cell.
</dd> </dd>
<dt>SF (6top Scheduling Function):</dt><dd> <dt>SF (6top Scheduling Function):</dt><dd>
The cell management entity that adds or deletes cells dynami cally based on application networking requirements. The cell management entity that adds or deletes cells dynami cally based on application networking requirements.
The cell negotiation with a neighbor is done using 6P. The cell negotiation with a neighbor is done using 6P.
</dd> </dd>
<dt>SFID (6top Scheduling Function Identifier):</dt><dd> <dt>SFID (6top Scheduling Function Identifier):</dt><dd>
A 4-bit field identifying an SF. A 4-bit field identifying an SF.
</dd> </dd>
<dt>shared cell:</dt><dd> <dt>shared cell:</dt><dd>
A cell marked with both the "TX" and "shared" flags. A cell marked with both the TX and Shared flags.
This cell can be used by more than one transmitter node. This cell can be used by more than one transmitter node.
A back-off algorithm is used to resolve contention. A back-off algorithm is used to resolve contention.
</dd> </dd>
<dt>slotframe:</dt><dd> <dt>slotframe:</dt><dd>
A collection of timeslots repeating in time, analogous to a superframe in that it defines periods of communication opportunities. A collection of timeslots repeating in time, analogous to a superframe in that it defines periods of communication opportunities.
It is characterized by a slotframe_ID, and a slotframe_size. It is characterized by a slotframe_ID and a slotframe_size.
Multiple slotframes can coexist in a node's schedule, i.e., Multiple slotframes can coexist in a node's schedule,
a node can have multiple activities scheduled in different slotframes, based on i.e., a node can have multiple activities scheduled in
the priority of its packets/traffic flows. different slotframes based on the priority of its packets/tr
The timeslots in the Slotframe are indexed by the SlotOffset affic flows.
; the first timeslot is at SlotOffset 0. The timeslots in the slotframe are indexed by the slotOffset
; the first timeslot is at slotOffset 0.
</dd> </dd>
<dt>slotOffset:</dt><dd> <dt>slotOffset:</dt><dd>
A column in the TSCH schedule, i.e., the number of timeslots since the beginning of the current iteration of the slotframe. A column in the TSCH schedule, i.e., the number of timeslots since the beginning of the current iteration of the slotframe.
</dd> </dd>
<dt>soft cell:</dt><dd> <dt>soft cell:</dt><dd>
A scheduled cell which the 6top sublayer can relocate. A scheduled cell that the 6top sublayer can relocate.
</dd> </dd>
<dt>time source neighbor:</dt><dd> <dt>time source neighbor:</dt><dd>
A neighbor that a node uses as its time reference, and to wh ich it needs to keep its clock synchronized. A neighbor that a node uses as its time reference, and to wh ich it needs to keep its clock synchronized.
</dd> </dd>
<dt>timeslot:</dt><dd> <dt>timeslot:</dt><dd>
A basic communication unit in TSCH which allows A basic communication unit in TSCH that allows
a transmitter node to send a frame to a receiver neighbo a transmitter node to send a frame to a receiver neighbo
r, and r and
that receiver neighbor to optionally send back an acknow that allows the receiver neighbor to optionally send bac
ledgment. k an acknowledgment.
</dd> </dd>
<dt>Track:</dt><dd> <dt>Track:</dt><dd>
A Track is a Directed Acyclic Graph (DAG) that is used as a A Track is a Directed Acyclic Graph (DAG) that is used as a
complex multi-hop path to the destination(s) of the path. complex multihop path to the destination(s) of the path.
In the case of unicast traffic, the Track is a Destination In the case of unicast traffic, the Track is a Destination-O
Oriented DAG (DODAG) where the Root of the DODAG is the riented DAG (DODAG) where the Root of the DODAG is the
destination of the unicast traffic. destination of the unicast traffic.
A Track enables replication, elimination and reordering func A Track enables replication, elimination, and reordering fun
tions on the way (more on those functions in ctions on the way (more on those functions in
<xref target='RFC8655'/>. <xref target="RFC8655"/>).
A Track reservation locks physical resources such as cells a nd buffers in every node along the DODAG. A Track reservation locks physical resources such as cells a nd buffers in every node along the DODAG.
A Track is associated with a owner that can be for instance the destination of the Track. A Track is associated with an owner, which can be for instan ce the destination of the Track.
</dd> </dd>
<dt>TrackID:</dt><dd> <dt>TrackID:</dt><dd>
A TrackID is either globally unique, or locally unique to th e Track owner, A TrackID is either globally unique or locally unique to the Track owner,
in which case the identification of the owner must be provid ed together with the TrackID in which case the identification of the owner must be provid ed together with the TrackID
to provide a full reference to the Track. typically, the Tra to provide a full reference to the Track. Typically, the Tra
ck owner is the ingress of the Track then the IPv6 source address of packets alo ck owner is the ingress of the
ng the Track can be used as Track, the IPv6 source address of packets along the Track ca
identification of the owner and a local InstanceID <xref tar n be used as
get='RFC6550'/> identification of the owner, and a local InstanceID <xref ta
in the namespace of that owner can be used as TrackID. If th rget="RFC6550"/>
e Track is reversible, then in the namespace of that owner can be used as TrackID.
the owner is found in the IPv6 destination address of a pack If the Track is reversible, then the owner is found in
et coming back along the Track. the IPv6 destination address of a packet coming back along t
In that case, a RPL Packet Information <xref target='RFC6550 he Track.
'/> in an IPv6 packet In that case, a RPL Packet Information <xref target="RFC6550
"/> in an IPv6 packet
can unambiguously identify the Track and can be expressed in a compressed form using can unambiguously identify the Track and can be expressed in a compressed form using
<xref target='RFC8138'/>. <xref target="RFC8138"/>.
</dd> </dd>
<dt>TSCH:</dt><dd> <dt>TSCH:</dt><dd>
A medium access mode of the <xref target='IEEE802154'> A medium access mode of the <xref target="IEEE802154">
IEEE Std. 802.15.4</xref> standard which uses IEEE Std 802.15.4</xref> standard that uses
time synchronization to achieve ultra-low-power operation, a time synchronization to achieve ultra-low-power operation an
nd d
channel hopping to enable high reliability. channel hopping to enable high reliability.
</dd> </dd>
<dt>TSCH Schedule:</dt><dd> <dt>TSCH Schedule:</dt><dd>
A matrix of cells, each cell indexed by a slotOffset and a c A matrix of cells, with each cell indexed by a slotOffset an
hannelOffset. d a channelOffset.
The TSCH schedule contains all the scheduled cells from all The TSCH schedule contains all the scheduled cells from all
slotframes and is sufficient to qualify the communication in the TSCH network. slotframes and is sufficient to qualify the communication in
the TSCH network.
The number of channelOffset values (the "height" of the matr ix) is equal to the number of available frequencies. The number of channelOffset values (the "height" of the matr ix) is equal to the number of available frequencies.
</dd> </dd>
<dt>Unscheduled Cell:</dt><dd> <dt>Unscheduled Cell:</dt><dd>
A cell which is not used by the IEEE Std. 802.15.4 TSCH impl ementation. A cell that is not used by the IEEE Std 802.15.4 TSCH implem entation.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor='acronyms'><name>Abbreviations</name> <section anchor="acronyms"><name>Abbreviations</name>
<t> This document uses the following abbreviations: <t> This document uses the following abbreviations:
</t><dl spacing='normal'> </t>
<dl spacing="normal">
<dt>6BBR:</dt><dd> 6LoWPAN Backbone Router (router with a proxy ND functi on) </dd> <dt>6BBR:</dt><dd> 6LoWPAN Backbone Router (router with a proxy ND functi on) </dd>
<dt>6LBR:</dt><dd> 6LoWPAN Border Router (authoritative on DAD) </dd> <dt>6LBR:</dt><dd> 6LoWPAN Border Router (authoritative on Duplicate Addr ess Detection (DAD)) </dd>
<dt>6LN:</dt><dd> 6LoWPAN Node </dd> <dt>6LN:</dt><dd> 6LoWPAN Node </dd>
<dt>6LR:</dt><dd> 6LoWPAN Router (relay to the registration process) </dd > <dt>6LR:</dt><dd> 6LoWPAN Router (relay to the registration process) </dd >
<dt>6CIO:</dt><dd> Capability Indication Option </dd> <dt>6CIO:</dt><dd> Capability Indication Option </dd>
<dt>(E)ARO:</dt><dd> (Extended) Address Registration Option </dd> <dt>(E)ARO:</dt><dd> (Extended) Address Registration Option </dd>
<dt>(E)DAR:</dt><dd> (Extended) Duplicate Address Request </dd> <dt>(E)DAR:</dt><dd> (Extended) Duplicate Address Request </dd>
<dt>(E)DAC:</dt><dd> (Extended) Duplicate Address Confirmation </dd> <dt>(E)DAC:</dt><dd> (Extended) Duplicate Address Confirmation </dd>
<dt>DAD:</dt><dd> Duplicate Address Detection </dd> <dt>DAD:</dt><dd> Duplicate Address Detection </dd>
<dt>DODAG:</dt><dd> Destination-Oriented Directed Acyclic Graph <dt>DODAG:</dt><dd> Destination-Oriented Directed Acyclic Graph </dd>
</dd>
<dt>LLN:</dt><dd> Low-Power and Lossy Network (a typical IoT network) </ dd> <dt>LLN:</dt><dd> Low-Power and Lossy Network (a typical IoT network) </ dd>
<dt>NA:</dt><dd> Neighbor Advertisement </dd> <dt>NA:</dt><dd> Neighbor Advertisement </dd>
<dt>NCE:</dt><dd> Neighbor Cache Entry </dd> <dt>NCE:</dt><dd> Neighbor Cache Entry </dd>
<dt>ND:</dt><dd> Neighbor Discovery </dd> <dt>ND:</dt><dd> Neighbor Discovery </dd>
<dt>NDP:</dt><dd> Neighbor Discovery Protocol </dd> <dt>NDP:</dt><dd> Neighbor Discovery Protocol </dd>
<dt>PCE:</dt><dd> Path Computation Element </dd> <dt>PCE:</dt><dd> Path Computation Element </dd>
<dt>NME:</dt><dd> Network Management Entity </dd> <dt>NME:</dt><dd> Network Management Entity </dd>
<dt>ROVR:</dt><dd> Registration Ownership Verifier (pronounced rover) </d d> <dt>ROVR:</dt><dd> Registration Ownership Verifier (pronounced rover) </d d>
<dt>RPL:</dt><dd> IPv6 Routing Protocol for LLNs (pronounced ripple) </dd > <dt>RPL:</dt><dd> IPv6 Routing Protocol for LLNs (pronounced ripple) </dd >
<dt>RA:</dt><dd> Router Advertisement </dd> <dt>RA:</dt><dd> Router Advertisement </dd>
<dt>RS:</dt><dd> Router Solicitation </dd> <dt>RS:</dt><dd> Router Solicitation </dd>
<dt>TSCH:</dt><dd> timeslotted Channel Hopping </dd> <dt>TSCH:</dt><dd> Time-Slotted Channel Hopping </dd>
<dt>TID:</dt><dd> Transaction ID (a sequence counter in the EARO) </dd> <dt>TID:</dt><dd> Transaction ID (a sequence counter in the EARO) </dd>
</dl> </dl>
</section> <!-- end section "Abbreviations" --> </section>
<section anchor='lo'><name>Related Documents</name> <section anchor="lo"><name>Related Documents</name>
<t> <t>
The draft also conforms to the terms and models described in The document conforms to the terms and models described in
<xref target='RFC3444'/> and <xref target='RFC5889'/> and uses the <xref target="RFC3444"/> and <xref target="RFC5889"/>, uses the
vocabulary and the concepts defined in <xref target='RFC4291'/> for the vocabulary and the concepts defined in <xref target="RFC4291"/> for the
IPv6 Architecture and refers <xref target='RFC4080'/> for reservation IPv6 architecture, and refers to <xref target="RFC4080"/> for reservati
<!-- signaling and <xref target="RFC5191"/> for authentication. --> on.
</t> </t>
<t> <t>
The draft uses domain-specific terminology defined or referenced in: The document uses domain-specific terminology defined or referenced
</t><ul empty='true' spacing='normal'> in the following:
<li> 6LoWPAN ND <xref target='RFC6775'>"Neighbor Discovery Optimization </t>
for Low-power and Lossy Networks"</xref> and <xref target='RFC8505'> <ul spacing="normal">
"Registration Extensions for 6LoWPAN Neighbor Discovery"</xref>, <li>6LoWPAN ND:
<xref target="RFC6775">"Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)"</xref> and
<xref target="RFC8505">"Registration Extensions for IPv6 over Low-Powe
r
Wireless Personal Area Network (6LoWPAN) Neighbor Discovery"</xref>,
</li>
<li><xref target="RFC7102">"Terms Used in Routing for Low-Power and Loss
y Networks"</xref>, and
</li>
<li>RPL:
<xref target="RFC6552">"Objective Function Zero for the
Routing Protocol for Low-Power and Lossy Networks (RPL)"</xref> and
<xref target="RFC6550">"RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks"</xref>.
</li> </li>
<li><xref target='RFC7102'>"Terms Used in Routing for Low-Power
and Lossy Networks (LLNs)"</xref>,</li>
<li> and RPL
<xref target='RFC6552'>"Objective Function Zero for the
Routing Protocol for Low-Power and Lossy Networks (RPL)"
</xref>, and
<xref target='RFC6550'>"RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks"</xref>.</li>
</ul><t> </ul><t>
Other terms in use in LLNs are found in <xref target='RFC7228'> Other terms in use in LLNs are found in <xref target="RFC7228">
"Terminology for Constrained-Node Networks"</xref>. "Terminology for Constrained-Node Networks"</xref>.
</t><t> </t><t>
Readers are expected to be familiar with all the terms and concepts Readers are expected to be familiar with all the terms and concepts
that are discussed in that are discussed in the following:
</t><ul spacing='normal'>
<li> <xref target='RFC4861'>"Neighbor Discovery for IP version 6"
</xref>, and
<xref target='RFC4862'>"IPv6 Stateless Address Autoconfiguration"
</xref>.</li>
</ul><t>
</t>
<t>In addition, readers would benefit from reading:
</t><ul spacing='normal'>
<li><xref target='RFC6606'>"Problem Statement and Requirements for
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing"
</xref>,</li>
<li> <xref target='RFC4903'>"Multi-Link Subnet Issues"</xref>, and </li>
<li> <xref target='RFC4919'>"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref></li>
</ul><t> prior to this specification for a clear
understanding of the art in ND-proxying and binding.
</t> </t>
</section> <!-- end section "References" --> <ul spacing="normal">
<li><xref target="RFC4861">"Neighbor Discovery for IP version 6 (IPv6)"</xre
f> and
</li>
<li><xref target="RFC4862">"IPv6 Stateless Address Autoconfiguration"</xref>
.
</li>
</ul>
<t>In addition, readers would benefit from reading the following
prior to this specification for a clear understanding of the art
in ND-proxying and binding:
</t>
<ul spacing="normal">
<li><xref target="RFC6606">"Problem Statement and Requirements for
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing"</xref>
,
</li>
<li> <xref target="RFC4903">"Multi-Link Subnet Issues"</xref>, and
</li>
<li> <xref target="RFC4919">"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref>.
</li>
</ul>
</section>
</section> <!-- end section "Terminology" --> </section>
<section><name>High Level Architecture</name> <section><name>High-Level Architecture</name>
<section><name>A Non-Broadcast Multi-Access Radio Mesh Network</name> <section><name>A Non-broadcast Multi-access Radio Mesh Network</name>
<t> <t>
A 6TiSCH network is an IPv6 <xref target='RFC8200'/> subnet which, in A 6TiSCH network is an IPv6 <xref target="RFC8200"/> subnet that, in
its basic configuration illustrated in <xref target='fig1'/>, is a its basic configuration illustrated in <xref target="fig1"/>, is a
single Low-Power Lossy Network (LLN) operating over a synchronized single Low-Power and Lossy Network (LLN) operating over a synchronized
TSCH-based mesh. TSCH-based mesh.
</t> </t>
<figure anchor='fig1'><name>Basic Configuration of a 6TiSCH Network</na me> <figure anchor="fig1"><name>Basic Configuration of a 6TiSCH Network</na me>
<artwork><![CDATA[ <artwork><![CDATA[
---+-------- ............ ------------ ---+-------- ............ ------------
| External Network | | External Network |
| +-----+ | +-----+
+-----+ | NME | +-----+ | NME |
| | LLN Border | PCE | | | LLN Border | PCE |
| | router (6LBR) +-----+ | | router (6LBR) +-----+
+-----+ +-----+
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
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Inside a 6TiSCH LLN, nodes rely on <xref target='RFC6282'>6LoWPAN Inside a 6TiSCH LLN, nodes rely on <xref target="RFC6282">6LoWPAN
Header Compression (6LoWPAN HC)</xref> to encode IPv6 packets. header compression (6LoWPAN HC)</xref> to encode IPv6 packets.
From the perspective of the network layer, a single LLN interface From the perspective of the network layer, a single LLN interface
(typically an IEEE Std. 802.15.4-compliant radio) may be seen as a coll (typically an IEEE Std 802.15.4-compliant radio) may be seen as a colle
ection ction
of Links with different capabilities for unicast or multicast services. of links with different capabilities for unicast or multicast services.
</t><t> </t><t>
6TiSCH nodes join a mesh network by attaching to nodes that are already 6TiSCH nodes join a mesh network by attaching to nodes that are already
members of the mesh (see <xref target='rflo'/>). The security aspects members of the mesh (see <xref target="rflo"/>). The security aspects
of the join process are further detailed in <xref target='sec'/>. of the join process are further detailed in <xref target="sec"/>.
In a mesh network, 6TiSCH nodes are not necessarily reachable from one In a 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.
</t><t> </t><t>
This forms a homogeneous non-broadcast multi-access (NBMA) subnet, This forms a homogeneous non-broadcast multi-access (NBMA) subnet,
which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND)
<xref target='RFC4861'/><xref target='RFC4862'/>. 6LoWPAN Neighbor <xref target="RFC4861"/> <xref target="RFC4862"/>. 6LoWPAN Neighbor
Discovery (6LoWPAN ND) <xref target='RFC6775'/><xref target='RFC8505'/> Discovery (6LoWPAN ND) <xref target="RFC6775"/> <xref target="RFC8505"/
>
specifies extensions to IPv6 ND that enable ND operations in this type specifies extensions to IPv6 ND that enable ND operations in this type
of subnet that can be protected against address theft and impersonation of subnet that can be protected against address theft and impersonation
with <xref target='I-D.ietf-6lo-ap-nd'/>. with <xref target="RFC8928"/>.
</t> </t>
<t> <t>
Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses Once it has joined the 6TiSCH network, a node acquires IPv6 addresses
and register them using 6LoWPAN ND. This guarantees that the addresses and registers them using 6LoWPAN ND. This guarantees that the addresses
are unique and protects the address ownership over the subnet, more in are unique and protects the address ownership over the subnet, more in
<xref target='rreg'/>. <xref target="rreg"/>.
</t> </t>
<t> <t>
Within the NBMA subnet, <xref target='RFC6550'>RPL</xref> enables Within the NBMA subnet, <xref target="RFC6550">RPL</xref> enables
routing in the so-called Route Over fashion, either in storing routing in the so-called "route-over" fashion, either in storing
(stateful) or non-storing (stateless, with routing headers) mode. (stateful) or non-storing (stateless, with routing headers) mode.
From there, some nodes can act as routers for 6LoWPAN ND and RPL From there, some nodes can act as routers for 6LoWPAN ND and RPL
operations, as detailed in <xref target='RPLvs6lo'/>. operations, as detailed in <xref target="RPLvs6lo"/>.
</t><t> </t>
With TSCH, devices are time-synchronized at the MAC level. The use of <t>
With TSCH, devices are time synchronized at the MAC level. The use of
a particular RPL Instance for time synchronization is discussed in a particular RPL Instance for time synchronization is discussed in
<xref target='sync'/>. With this mechanism, the time synchronization <xref target="sync"/>. With this mechanism, the time synchronization
starts at the RPL Root and follows the RPL loopless routing topology. starts at the RPL Root and follows the RPL loopless routing topology.
</t><t> </t><t>
RPL forms Destination Oriented RPL forms Destination-Oriented
Directed Acyclic Graphs (DODAGs) within Instances of the protocol, Directed Acyclic Graphs (DODAGs) within Instances of the protocol,
each Instance being associated with an Objective Function (OF) to each Instance being associated with an Objective Function (OF) to
form a routing topology. A particular 6TiSCH node, the LLN Border Route r form a routing topology. A particular 6TiSCH node, the LLN Border Route r
(6LBR), acts as RPL Root, 6LoWPAN HC terminator, and Border Router (6LBR), acts as RPL Root, 6LoWPAN HC terminator, and Border Router
for the LLN to the outside. The 6LBR is usually powered. for the LLN to the outside. The 6LBR is usually powered.
More on RPL Instances can be found in section 3.1 of More on RPL Instances can be found in Section
<xref target='RFC6550'>RPL</xref>, in particular <xref target="RFC6550" section="3.1" sectionFormat="bare" format="defau
"3.1.2. RPL Identifiers" and lt"/> of
"3.1.3. Instances, DODAGs, and DODAG Versions". RPL adds artifacts in <xref target="RFC6550">RPL</xref>, in particular
the data packets that are compressed with a 6LoWPAN addition "<xref target="RFC6550" section="3.1.2" sectionFormat="bare" format="de
<xref target='RFC8138'>6LoRH</xref>. fault"/> RPL Identifiers" and
"<xref target="RFC6550" section="3.1.3" sectionFormat="bare" format="de
fault"/> Instances, DODAGs, and DODAG Versions".
RPL adds artifacts in
the data packets that are compressed with a
<xref target="RFC8138">6LoWPAN Routing Header (6LoRH)</xref>.
In a preexisting network, the compression can be globally turned on in
a
DODAG once all nodes are migrated to support <xref target="RFC8138" for
mat="default"/>
using <xref target="RFC9035" format="default"/>.
</t><t> </t><t>
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 characteristics establish on-demand, peer-to-peer routes with particular characteristic s
inside the 6TiSCH network. inside the 6TiSCH network.
This may be achieved in a centralized fashion by a Path Computation This may be achieved in a centralized fashion by a Path Computation
Element (PCE) <xref target='PCE'/> that programs both the routes and Element (PCE) <xref target="PCE"/> that programs both the routes and
the schedules inside the 6TiSCH nodes, or by in a distributed fashion the schedules inside the 6TiSCH nodes or in a distributed fashion by
using a reactive routing protocol and a Hop-by-Hop scheduling protocol. using a reactive routing protocol and a hop-by-hop scheduling protocol.
</t> </t>
<t> <t>
This architecture expects that a 6LoWPAN node can connect as a This architecture expects that a 6LoWPAN node can connect as a
leaf to a RPL network, where the leaf support is the minimal leaf to a RPL network, where the leaf support is the minimal
functionality to connect as a host to a RPL network without the need to functionality to connect as a host to a RPL network without the need to
participate to the full routing protocol. participate in the full routing protocol.
The architecture also expects that a 6LoWPAN node that is not aware The architecture also expects that a 6LoWPAN node that is unaware
at all of the RPL protocol may also connect as described in of RPL may also connect as described in <xref target="RFC9010"/>.
<xref target='I-D.ietf-roll-unaware-leaves'/>.
</t> </t>
</section> </section>
<section><name>A Multi-Link Subnet Model</name> <section><name>A Multi-Link Subnet Model</name>
<t> <t>
An extended configuration of the subnet comprises multiple LLNs as An extended configuration of the subnet comprises multiple LLNs as
illustrated in <xref target='fig2'/>. illustrated in <xref target="fig2"/>.
In the extended configuration, a Routing Registrar <xref target='RFC8505'/> In the extended configuration, a Routing Registrar <xref target="RFC8505"/>
may be connected to the node that acts as RPL Root and / or 6LoWPAN 6LBR may be connected to the node that acts as the RPL Root and/or 6LoWPAN 6LBR
and provides connectivity to the larger campus / factory plant network and provides connectivity to the larger campus or factory plant network
over a high-speed backbone or a back-haul link. The Routing registrar over a high-speed backbone or a back-haul link. The Routing Registrar
may perform IPv6 ND proxy operations, or redistribute the registration in may perform IPv6 ND proxy operations; redistribute the registration in
a routing protocol such as <xref target='RFC5340'>OSPF</xref> or a routing protocol such as <xref target="RFC5340">OSPF</xref> or
<xref target='RFC2545'>BGP</xref>, or inject a route in a mobility protocol <xref target="RFC2545">BGP</xref>; or inject a route in a mobility protocol
such as <xref target='RFC6275'>MIPv6</xref>, <xref target='RFC3963'>NEMO such as <xref target="RFC6275">Mobile IPv6 (MIPv6)</xref>,
</xref>, or <xref target='RFC6830'>LISP</xref>. <xref target="RFC3963">Network Mobility (NEMO)</xref>, or
<xref target="RFC6830">Locator/ID Separation Protocol (LISP)</xref>.
</t> </t>
<t> <t>
Multiple LLNs can be interconnected and possibly synchronized over a Multiple LLNs can be interconnected and possibly synchronized over a
backbone, which can be wired or wireless. The backbone can operate with backbone, which can be wired or wireless. The backbone can operate with
IPv6 ND <xref target='RFC4861'/><xref target='RFC4862'/> procedures or an IPv6 ND procedures <xref target="RFC4861"/> <xref target="RFC4862"/> or a
hybrid of IPv6 ND and 6LoWPAN ND hybrid of IPv6 ND and 6LoWPAN ND
<xref target='RFC6775'/><xref target='RFC8505'/><xref target='I-D.ietf-6lo-a p-nd'/>. <xref target="RFC6775"/> <xref target="RFC8505"/> <xref target="RFC8928"/>.
</t> </t>
<figure anchor='fig2'><name>Extended Configuration of a 6TiSCH Network< /name> <figure anchor="fig2"><name>Extended Configuration of a 6TiSCH Network< /name>
<artwork><![CDATA[ <artwork><![CDATA[
| |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
(default) | | (Optional) | | | | IPv6 (default) | | (Optional) | | | | IPv6
Router | | 6LBR | | | | Node Router | | 6LBR | | | | Node
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| Backbone side | | | Backbone side | |
--------+---+--------------------+-+---------------+------+--- --------+---+--------------------+-+---------------+------+---
| | | | | |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Routing | | Routing | | Routing | | Routing | | Routing | | Routing |
skipping to change at line 691 skipping to change at line 651
| | | | | |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Routing | | Routing | | Routing | | Routing | | Routing | | Routing |
| Registrar | | Registrar | | Registrar | | Registrar | | Registrar | | Registrar |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
o Wireless side o o o o o Wireless side o o o o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o 6TiSCH o 6TiSCH o o o o 6TiSCH o o 6TiSCH o 6TiSCH o o o o 6TiSCH o
o o LLN o o o o LLN o o LLN o o o LLN o o o o LLN o o LLN o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
]]></artwork></figure>
]]></artwork></figure>
<t> <t>
A Routing Registrar that performs proxy IPv6 ND operations over the A Routing Registrar that performs proxy IPv6 ND operations over the
backbone on behalf of the 6TiSCH nodes is called a Backbone Router (6BBR) backbone on behalf of the 6TiSCH nodes is called a Backbone Router (6BBR)
<xref target='I-D.ietf-6lo-backbone-router'/>. The 6BBRs are <xref target="RFC8929"/>. The 6BBRs are
placed along the wireless edge of a Backbone, and federate multiple placed along the wireless edge of a backbone and federate multiple
wireless links to form a single MultiLink Subnet. The 6BBRs synchronize wireless links to form a single multi-link subnet. The 6BBRs synchronize
with one another over the backbone, so as to ensure that the multiple LLNs with one another over the backbone, so as to ensure that the multiple LLNs
that form the IPv6 subnet stay tightly synchronized. that form the IPv6 subnet stay tightly synchronized.
</t> </t>
<t> <t>
The use of multicast can also be reduced on the backbone with a registrar The use of multicast can also be reduced on the backbone with a registrar
that would contribute to Duplicate Address Detection as well as Address that would contribute to Duplicate Address Detection as well as address
Lookup using only unicast request/response exchanges. lookup using only unicast request/response exchanges.
<xref target='I-D.thubert-6man-unicast-lookup'/> is a proposed method that <xref target="I-D.thubert-6man-unicast-lookup"/> is a proposed method that
presents an example of how to this could be achieved with an extension of presents an example of how this could be achieved with an extension of
<xref target='RFC8505'/>, using an optional 6LBR as a SubNet-level registrar <xref target="RFC8505"/>, using an optional 6LBR as a subnet-level registrar
, ,
as illustrated in <xref target='fig2'/>. as illustrated in <xref target="fig2"/>.
</t> </t>
<t> <t>
As detailed in <xref target='RPLvs6lo'/> the 6LBR that serves the LLN and As detailed in <xref target="RPLvs6lo"/>, the 6LBR that serves the LLN and
the Root of the RPL network need to share information about the devices the Root of the RPL network need to share information about the devices
that are learned through either 6LoWPAN ND or RPL but not both. that are learned through either 6LoWPAN ND or RPL, but not both.
The preferred way of achieving this is to collocate/combine them. The preferred way of achieving this is to co-locate or combine them.
The combined RPL Root and 6LBR may be collocated with the 6BBR, or The combined RPL Root and 6LBR may be co-located with the 6BBR, or
directly attached to the 6BBR. In the latter case, it leverages the directly attached to the 6BBR. In the latter case, it leverages the
extended registration process defined in <xref target='RFC8505'/> to proxy extended registration process defined in <xref target="RFC8505"/> to proxy
the 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so the 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so
that the 6BBR may in turn perform proxy classical ND operations over the that the 6BBR may in turn perform classical ND operations over the
backbone. backbone as a proxy.
</t> </t>
<t> The <xref target='RFC8655'>DetNet <t> The <xref target="RFC8655">"Deterministic Networking Architecture"</xr
Architecture</xref> studies Layer-3 aspects of Deterministic Networks, and ef>
covers networks that span multiple Layer-2 domains. studies Layer 3 aspects of Deterministic Networks and
If the Backbone is Deterministic (such as defined by the Time Sensitive covers networks that span multiple Layer 2 domains.
Networking WG at IEEE), then the Backbone Router ensures that the If the backbone is deterministic (such as defined by the Time-Sensitive
Networking (TSN) Task Group at IEEE), then the Backbone Router ensures that
the
end-to-end deterministic behavior is maintained between the LLN and the end-to-end deterministic behavior is maintained between the LLN and the
backbone. backbone.
</t> </t>
</section> </section>
<section><name>TSCH: A Deterministic MAC Layer</name> <section><name>TSCH: a Deterministic MAC Layer</name>
<t> <t>
Though at a different time scale (several orders of magnitude), Though at a different time scale (several orders of magnitude),
both IEEE Std. 802.1TSN and IEEE Std. 802.15.4 TSCH both IEEE Std 802.1 TSN and IEEE Std 802.15.4 TSCH
standards provide Deterministic capabilities to the point that a packet standards provide deterministic capabilities to the point that a packet
that pertains to a certain flow may traverse a network from node to nod pertaining to a certain flow may traverse a network from node to node f
e following ollowing
a precise schedule, as a train that enters and then leaves intermediate stations a precise schedule, as a train that enters and then leaves intermediate stations
at precise times along its path. at precise times along its path.
</t> </t>
<t> <t>
With TSCH, time is formatted into With TSCH, time is formatted into
timeslots, and individual communication cells are allocated to unicast or timeslots, and individual communication cells are allocated to unicast or
broadcast communication at the MAC level. The time-slotted operation broadcast communication at the MAC level. The time-slotted operation
reduces collisions, saves energy, and enables to more closely engineer reduces collisions, saves energy, and enables more closely engineering
the network for deterministic properties. the network for deterministic properties.
The channel hopping aspect is a simple and efficient technique to comba t The channel-hopping aspect is a simple and efficient technique to comba t
multipath fading and co-channel interference. multipath fading and co-channel interference.
</t> </t>
<t> <t>
6TiSCH builds on the IEEE Std. 802.15.4 TSCH MAC and inherits its advan ced 6TiSCH builds on the IEEE Std 802.15.4 TSCH MAC and inherits its advanc ed
capabilities to enable them in multiple environments where they can capabilities to enable them in multiple environments where they can
be leveraged to improve automated operations. be leveraged to improve automated operations.
The 6TiSCH Architecture also inherits the capability to perform a The 6TiSCH architecture also inherits the capability to perform a
centralized route computation to achieve deterministic properties, centralized route computation to achieve deterministic properties,
though it relies on the IETF though it relies on the IETF
<xref target='RFC8655'>DetNet Architecture</xref>, <xref target="RFC8655">DetNet architecture</xref>
and IETF components such as the PCE and IETF components such as the PCE
<xref target='PCE'/>, for the protocol aspects. <xref target="PCE"/> for the protocol aspects.
</t> </t>
<t>On top of this inheritance, 6TiSCH adds capabilities for distributed <t>On top of this inheritance, 6TiSCH adds capabilities for distributed
routing and scheduling operations based on the RPL routing protocol routing and scheduling operations based on RPL
and capabilities to negotiate schedule adjustments between peers. and capabilities for negotiating schedule adjustments between peers.
These distributed routing and scheduling operations simplify the These distributed routing and scheduling operations simplify the
deployment of TSCH networks and enable wireless solutions in a larger deployment of TSCH networks and enable wireless solutions in a larger
variety of use cases from operational technology in general. Examples variety of use cases from operational technology in general. Examples
of such use-cases in industrial environments include plant setup and of such use cases in industrial environments include plant setup and
decommissioning, as well as monitoring of lots of lesser importance decommissioning, as well as monitoring a multiplicity of minor
measurements such as corrosion and events and mobile workers accessing notifications such as corrosion measurements, events, and access of
local devices. local devices by mobile workers.
</t> </t>
</section> </section>
<section><name>Scheduling TSCH</name> <section><name>Scheduling TSCH</name>
<t>A scheduling operation attributes cells in a Time-Division-Multiplexing
(TDM) / Frequency-Division Multiplexing (FDM) matrix called the Channel <t>A scheduling operation allocates cells in a TDM/FDM matrix
distribution/usage (CDU) to either individual transmissions called a CDU either to individual transmissions or as multi-access shar
or as multi-access shared resources. The CDU matrix can be formatted in ed resources.
The CDU matrix can be formatted in
chunks that can be allocated exclusively to particular nodes to enable chunks that can be allocated exclusively to particular nodes to enable
distributed scheduling without collision. distributed scheduling without collision.
More in <xref target='slotframes'/>. More in <xref target="slotframes"/>.
</t> </t>
<t> <t>
From the standpoint of a 6TiSCH node (at the MAC layer), its schedule At the MAC layer, the schedule of a 6TiSCH node
is the collection of the timeslots at which it must wake up for is the collection of the timeslots at which it must wake up for
transmission, and the channels to which it should either send or listen transmission, and the channels to which it should either send or listen
at those times. The schedule is expressed as one or more slotframes tha at those times. The schedule is expressed as one or more repeating slot
t frames.
repeat over and over. Slotframes may collide and require a device to Slotframes may collide and require a device to
wake up at a same time, in which case the slotframe with the highest wake up at a same time, in which case the slotframe with the highest
priority is actionable. priority is actionable.
</t> </t>
<t> <t>
The 6top sublayer (see <xref target='s6Pprot'/> for more) hides the The 6top sublayer (see <xref target="s6Pprot"/> for more) hides the
complexity of the schedule from the upper layers. The Link abstraction complexity of the schedule from the upper layers. The link abstraction
that IP traffic utilizes is composed of a pair of Layer-3 cell bundles, that IP traffic utilizes is composed of a pair of Layer 3 cell bundles,
one to receive and one to transmit. Some of the cells may be shared, in one to receive and one to transmit. Some of the cells may be shared, in
which case the 6top sublayer must perform some arbitration. which case the 6top sublayer must perform some arbitration.
</t> </t>
<t> <t>
Scheduling enables multiple communications at a same time in a same Scheduling enables multiple simultaneous communications in a same
interference domain using different channels; but a node equipped with interference domain using different channels; but a node equipped with
a single radio can only either transmit or receive on one channel at a single radio can only either transmit or receive on one channel at
any point of time. any point of time.
Scheduled cells that fulfil the same role, e.g., receive IP packets fro m Scheduled cells that fulfill the same role, e.g., receive IP packets fr om
a peer, are grouped in bundles. a peer, are grouped in bundles.
</t> </t>
<t>The 6TiSCH architecture identifies four ways a schedule can be managed <t>The 6TiSCH architecture identifies four ways a schedule can be managed
and CDU cells can be allocated: Static Scheduling, Neighbor-to-Neighbor and CDU cells can be allocated: Static Scheduling, Neighbor-to-Neighbor
Scheduling, Centralized (or Remote) Monitoring and Schedule Management, Scheduling, Centralized (or Remote) Monitoring and Schedule Management,
and Hop-by-hop Scheduling. and Hop-by-Hop Scheduling.
</t><dl spacing='normal'> </t><dl spacing="normal">
<dt>Static Scheduling:</dt><dd>This refers to the minimal <dt>Static Scheduling:</dt><dd>This refers to the minimal
6TiSCH operation whereby a static schedule is configured for the whole 6TiSCH operation whereby a static schedule is configured for the whole
network for use in a Slotted ALOHA <xref target='S-ALOHA'/> fashion. network for use in a Slotted ALOHA <xref target="S-ALOHA"/> fashion.
The static schedule is The static schedule is
distributed through the native methods in the TSCH MAC layer distributed through the native methods in the TSCH MAC layer
and does not preclude other scheduling operations to co-exist on a same and does not preclude other scheduling operations coexisting on a same
6TiSCH network. A static schedule is 6TiSCH network. A static schedule is
necessary for basic operations such as the join process and necessary for basic operations such as the join process and
for interoperability during the network formation, which is specified for interoperability during the network formation, which is specified
as part of the <xref target='RFC8180'>Minimal 6TiSCH Configuration as part of the <xref target="RFC8180">Minimal 6TiSCH Configuration
</xref>. </xref>.
</dd> </dd>
<dt>Neighbor-to-Neighbor Scheduling:</dt><dd>This refers to the <dt>Neighbor-to-Neighbor Scheduling:</dt><dd>This refers to the
dynamic adaptation of the bandwidth of the Links that are used for IPv6 dynamic adaptation of the bandwidth of the links that are used for IPv6
traffic between adjacent peers. Scheduling Functions such as the traffic between adjacent peers. Scheduling Functions such as the
<xref target='I-D.ietf-6tisch-msf'>"6TiSCH Minimal Scheduling Function <xref target="RFC9033">"6TiSCH Minimal Scheduling Function
(MSF)"</xref> influence the operation of the MAC layer to add, update (MSF)"</xref> influence the operation of the MAC layer to add, update,
and remove cells in its own, and its peer's schedules using 6P and remove cells in its own and its peer's schedules using 6P
<xref target='RFC8480'/>, <xref target="RFC8480"/>
for the negotiation of the MAC resources.</dd> for the negotiation of the MAC resources.</dd>
<dt>Centralized (or Remote) Monitoring and Schedule Management:</dt><dd > <dt>Centralized (or Remote) Monitoring and Schedule Management:</dt><dd >
This refers to the central computation of a schedule and the capability This refers to the central computation of a schedule and the capability
to forward a frame based on the cell of arrival. In that case, to forward a frame based on the cell of arrival. In that case,
the related portion of the device schedule as well as other device the related portion of the device schedule as well as other device
resources are managed by an abstract Network Management Entity (NME), resources are managed by an abstract Network Management Entity (NME),
which may cooperate with the PCE to minimize the interaction which may cooperate with the PCE to minimize the interaction
with and the load on the constrained device. with, and the load on, the constrained device.
This model is the TSCH adaption of the This model is the TSCH adaption of the
<xref target='RFC8655'>DetNet Architecture</xref>, <xref target="RFC8655">DetNet architecture</xref>,
and it enables Traffic Engineering with deterministic properties. and it enables Traffic Engineering with deterministic properties.
</dd> </dd>
<dt>Hop-by-hop Scheduling:</dt><dd>This refers to the possibility to <dt>Hop-by-Hop Scheduling:</dt><dd>This refers to the possibility of
reserves cells along a path for a particular flow using a distributed reserving cells along a path for a particular flow using a distributed
mechanism.</dd> mechanism.</dd>
</dl><t> </dl>
</t> <t> <t>
It is not expected that all use cases will require all those mechanisms . It is not expected that all use cases will require all those mechanisms .
Static Scheduling with minimal configuration one is the only one that Static Scheduling with minimal configuration is the only one that
is expected in all implementations, since it provides a simple and is expected in all implementations, since it provides a simple and
solid basis for convergecast routing and time distribution. solid basis for convergecast routing and time distribution.
</t><t> </t><t>
A deeper dive in those mechanisms can be found in <xref target='schd'/> . A deeper dive into those mechanisms can be found in <xref target="schd" />.
</t> </t>
</section> </section>
<section anchor='rtg3'><name>Distributed vs. Centralized Routing</name> <section anchor="rtg3"><name>Distributed vs. Centralized Routing</name>
<t> <t>
6TiSCH enables a mixed model of centralized routes and distributed routes. 6TiSCH enables a mixed model of centralized routes and distributed routes.
Centralized routes can for example be computed by an entity such as a PCE. Centralized routes can, for example, be computed by an entity such as a PC
6TiSCH leverages the <xref target='RFC6550'>RPL</xref> routing protocol E.
for interoperable distributed routing operations. 6TiSCH leverages <xref target="RFC6550">RPL</xref>
for interoperable, distributed routing operations.
</t> </t>
<t> <t>
Both methods may inject routes in the Routing Tables of the 6TiSCH routers . Both methods may inject routes into the routing tables of the 6TiSCH route rs.
In either case, each route is associated with a 6TiSCH topology that can In either case, each route is associated with a 6TiSCH topology that can
be a RPL Instance topology or a Track. The 6TiSCH topology is be a RPL Instance topology or a Track. The 6TiSCH topology is
indexed by a RPLInstanceID, in a format that reuses the RPLInstanceID as indexed by a RPLInstanceID, in a format that reuses the RPLInstanceID as
defined in RPL. defined in RPL.
</t> </t>
<t> <t>
<xref target='RFC6550'>RPL</xref> is applicable to Static Scheduling and <xref target="RFC6550">RPL</xref> is applicable to Static Scheduling and
Neighbor-to-Neighbor Scheduling. The architecture also supports a Neighbor-to-Neighbor Scheduling. The architecture also supports a
centralized routing model for Remote Monitoring and Schedule Management. centralized routing model for Remote Monitoring and Schedule Management.
It is expected that a routing protocol that is more optimized for It is expected that a routing protocol that is more optimized for
point-to-point routing than <xref target='RFC6550'>RPL</xref>, such as point-to-point routing than <xref target="RFC6550">RPL</xref>, such as
the <xref target='I-D.ietf-roll-aodv-rpl'> the <xref target="I-D.ietf-roll-aodv-rpl">
Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks"</xref> "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks" (AODV-RPL)</xr
AODV-RPL), which derives from the <xref target='I-D.ietf-manet-aodvv2'> ef>,
Ad Hoc On-demand Distance Vector Routing (AODV)</xref> will be which derives from the <xref target="I-D.ietf-manet-aodvv2">
selected for Hop-by-hop Scheduling. "Ad Hoc On-demand Distance Vector (AODVv2) Routing"</xref>, will be
selected for Hop-by-Hop Scheduling.
</t> </t>
<t> <t>
Both RPL and PCE rely on shared sources such as policies to define Global Both RPL and PCE rely on shared sources such as policies to define global
and Local RPLInstanceIDs that can be used by either method. It is possible and local RPLInstanceIDs that can be used by either method. It is possible
for centralized and distributed routing to share a same topology. for centralized and distributed routing to share the same topology.
Generally they will operate in different slotframes, and centralized Generally they will operate in different slotframes, and centralized
routes will be used for scheduled traffic and will have precedence over routes will be used for scheduled traffic and will have precedence over
distributed routes in case of conflict between the slotframes. distributed routes in case of conflict between the slotframes.
</t> </t>
</section> <!-- Distributed vs. Centralized Routing --> </section>
<section><name>Forwarding Over TSCH</name> <section><name>Forwarding over TSCH</name>
<t> <t>
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 feasible 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 routing successor at Layer 3 on a per-packet basis and based on its routing
table. The second derives from Generic MPLS (G-MPLS) for so-called table. The second derives from Generalized MPLS (GMPLS) for so-called
Track Forwarding, whereby a frame received at a particular timeslot Track Forwarding, whereby a frame received at a particular timeslot
can be switched into another timeslot at Layer-2 without regard to the can be switched into another timeslot at Layer 2 without regard to the
upper layer protocol. The third model is the upper-layer protocol. The third model is the
6LoWPAN Fragment Forwarding, which allows to forward individual 6loWPAN 6LoWPAN Fragment Forwarding, which allows the forwarding individual 6Lo
fragments along a route that is setup by the first fragment. WPAN
fragments along a route that is set up by the first fragment.
</t> </t>
<t>In more details: <t>In more detail:
</t><dl spacing='normal'> </t>
<dl spacing="normal">
<dt>IPv6 Forwarding:</dt><dd>This is the classical IP forwarding <dt>IPv6 Forwarding:</dt><dd>This is the classical IP forwarding
model, with a Routing Information Based (RIB) that is installed by the model, with a Routing Information Base (RIB) that is installed by
RPL routing protocol and used to select a feasible successor per packet RPL and used to select a feasible successor per packet.
. The packet is placed on an outgoing link, which the 6top sublayer maps
The packet is placed on an outgoing Link, that the 6top layer maps into into
a (Layer-3) bundle of cells, and scheduled for transmission based on Qo a (Layer 3) bundle of cells, and scheduled for transmission based on Qo
S S
parameters. Besides RPL, this model also applies to any routing parameters. Besides RPL, this model also applies to any routing
protocol which may be operated in the 6TiSCH network, and corresponds protocol that may be operated in the 6TiSCH network and corresponds
to all the distributed scheduling models, Static, Neighbor-to-Neighbor to all the distributed scheduling models: Static, Neighbor-to-Neighbor,
and Hop-by-Hop Scheduling.</dd> and Hop-by-Hop Scheduling.</dd>
<dt>G-MPLS Track Forwarding:</dt><dd>This model corresponds to the <dt>GMPLS Track Forwarding:</dt><dd>This model corresponds to the
Remote Monitoring and Schedule Management. In this model, a central Remote Monitoring and Schedule Management. In this model, a central
controller (hosting a PCE) computes and installs the schedules in the controller (hosting a PCE) computes and installs the schedules in the
devices per flow. The incoming (Layer-2) bundle of cells from the devices per flow. The incoming (Layer 2) bundle of cells from the
previous node along the path determines the outgoing (Layer-2) bundle previous node along the path determines the outgoing (Layer 2) bundle
towards the next hop for that flow as determined by the PCE. The towards the next hop for that flow as determined by the PCE. The
programmed sequence for bundles is called a Track and can assume DAG programmed sequence for bundles is called a Track and can assume DAG
shapes that are more complex than a simple direct sequence of nodes.</d d> shapes that are more complex than a simple direct sequence of nodes.</d d>
<dt>6LoWPAN Fragment Forwarding:</dt><dd>This is a hybrid model <dt>6LoWPAN Fragment Forwarding:</dt><dd>This is a hybrid model
that derives from IPv6 forwarding for the case where packets must that derives from IPv6 forwarding for the case where packets must
be fragmented at the 6LoWPAN sublayer. The first fragment is forwarded be fragmented at the 6LoWPAN sublayer. The first fragment is forwarded
like any IPv6 packet and leaves a state in the intermediate hops to like any IPv6 packet and leaves a state in the intermediate hops to
enable forwarding of the next fragments that do not have a IP header enable forwarding of the next fragments that do not have an IP header
without the need to recompose the packet at every hop.</dd> without the need to recompose the packet at every hop.</dd>
</dl><t> </dl>
</t> <t>A deeper dive into these operations can be found in
<t>A deeper dive on these operations can be found in <xref target="fwd"/>.
<xref target='fwd'/>.
</t> </t>
<t> The following table summarizes how the forwarding models <t> <xref target="RaF"/> summarizes how the forwarding models
apply to the various routing and scheduling possibilities: apply to the various routing and scheduling possibilities:
</t> </t>
<figure anchor='RaF' suppress-title='true'> <table anchor="RaF">
<artwork> <thead>
<![CDATA[ <tr>
+-------------------+------------+----------------------------------+ <th>Forwarding Model</th>
| Forwarding Model | Routing | Scheduling | <th>Routing</th>
+===================+============+==================================+ <th>Scheduling</th>
| | | Static (Minimal Configuration) | </tr>
+ classical IPv6 + RPL +----------------------------------+ </thead>
| / | | Neighbor-to-Neighbor (SF+6P) | <tbody>
+ 6LoWPAN Fragment +------------+----------------------------------+ <tr>
| | Reactive | Hop-by-Hop (AODV-RPL) | <td rowspan="3">classical IPv6 / 6LoWPAN Fragment</td>
+-------------------+------------+----------------------------------+ <td rowspan="2">RPL</td>
|G-MPLS Track Fwding| PCE |Remote Monitoring and Schedule Mgt| <td>Static (Minimal Configuration)</td>
+-------------------+------------+----------------------------------+ </tr>
]]> <tr>
</artwork> <td>Neighbor-to-Neighbor (SF+6P)</td>
</figure> </tr>
<tr>
<td>Reactive</td>
<td>Hop-by-Hop (AODV-RPL)</td>
</tr>
<tr>
<td>GMPLS Track Forwarding</td>
<td>PCE</td>
<td>Remote Monitoring and Schedule Mgt</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor='fsixstac'><name>6TiSCH Stack</name> <section anchor="fsixstac"><name>6TiSCH Stack</name>
<t> <t>
The IETF proposes multiple techniques for implementing functions related The IETF proposes multiple techniques for implementing functions related
to routing, transport or security. to routing, transport, or security.
</t> </t>
<t> <t>
The 6TiSCH architecture limits the possible The 6TiSCH architecture limits the possible
variations of the stack and recommends a number of base elements for LLN variations of the stack and recommends a number of base elements for LLN
applications to control the complexity of applications to control the complexity of
possible deployments and device interactions, and to limit the size of possible deployments and device interactions and to limit the size of
the resulting object code. In particular, UDP <xref target='RFC0768'/>, the resulting object code. In particular, UDP <xref target="RFC0768"/>,
IPv6 <xref target='RFC8200'/> and the <xref target='RFC7252'>Constrained IPv6 <xref target="RFC8200"/>, and the <xref target="RFC7252">Constrained
Application Protocol</xref> (CoAP) are used as the transport / binding of Application Protocol (CoAP)</xref> are used as the transport/binding of
choice for applications and management as opposed to TCP and HTTP. choice for applications and management as opposed to TCP and HTTP.
</t> </t>
<t> <t>
The resulting protocol stack is represented in <xref target='fig4'/>: The resulting protocol stack is represented in <xref target="fig4"/>:
</t> </t>
<figure anchor='fig4'><name>6TiSCH Protocol Stack</name> <figure anchor="fig4"><name>6TiSCH Protocol Stack</name>
<artwork><![CDATA[ <artwork><![CDATA[
+--------+--------+ +--------+--------+
| Applis | CoJP | | Applis | CoJP |
+--------+--------+--------------+-----+ +--------+--------+--------------+-----+
| 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 |
skipping to change at line 997 skipping to change at line 962
| Applis | CoJP | | Applis | CoJP |
+--------+--------+--------------+-----+ +--------+--------+--------------+-----+
| 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 |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
RPL is the routing protocol of choice for LLNs. So far, there was no RPL is the routing protocol of choice for LLNs. So far, there is no
identified need to define a 6TiSCH specific Objective Function. identified need to define a 6TiSCH-specific Objective Function.
The <xref target='RFC8180'>Minimal 6TiSCH Configuration The <xref target="RFC8180">Minimal 6TiSCH Configuration
</xref> describes the operation of RPL over a static schedule used in </xref> describes the operation of RPL over a static schedule used in
a Slotted ALOHA fashion <xref target='S-ALOHA'/>, whereby all active sl ots a Slotted ALOHA fashion <xref target="S-ALOHA"/>, whereby all active sl ots
may be used for emission or reception of both unicast and multicast may be used for emission or reception of both unicast and multicast
frames. frames.
</t> </t>
<t> <t>
The <xref target='RFC6282'>6LoWPAN Header Compression</xref> is used <xref target="RFC6282">6LoWPAN header compression</xref> is used
to compress the IPv6 and UDP headers, whereas the to compress the IPv6 and UDP headers, whereas the
<xref target='RFC8138'> 6LoWPAN Routing Header (6LoRH)</xref> is used <xref target="RFC8138"> 6LoWPAN Routing Header (6LoRH)</xref> is used
to compress the RPL artifacts in to compress the RPL artifacts in
the IPv6 data packets, including the RPL Packet Information (RPI), the IPv6 data packets, including the RPL Packet Information (RPI),
the IP-in-IP encapsulation to/from the RPL Root, and the Source Route the IP-in-IP encapsulation to/from the RPL Root, and the Source Routing
Header (SRH) in non-storing mode. Header (SRH) in non-storing mode.
<xref target='I-D.ietf-roll-useofrplinfo'>"When to use RFC 6553, 6554 "<xref target="RFC9008" format="title"/>" <xref target="RFC9008"/>
and IPv6-in-IPv6"</xref> provides the details on when headers or encaps provides the details on when headers or encapsulation are needed.
ulation are needed.
</t>
<t>
<!--The COMAN list is working on network Management for LLN.
They are considering the Open Mobile Alliance (OMA) Lightweight M2M (LW
M2M) Object system.
This standard includes DTLS, CoAP (core plus Block and Observe patterns
),
SenML and CoAP Resource Directory.
6TiSCH has adopted the general direction of
<xref target="I-D.ietf-core-comi">
CoAP Management Interface (COMI)</xref> for the management of devices.
This is leveraged for instance for the implementation of the generic
data model for the 6top sublayer management interface
<xref target="I-D.ietf-6tisch-6top-interface"/>.
The proposed implementation is based on CoAP and CBOR,
and specified in <xref target="I-D.ietf-6tisch-coap">
6TiSCH Resource Management and Interaction using CoAP</xref>.-->
</t> </t>
<t> <t>
The <xref target='I-D.ietf-core-object-security'> The <xref target="RFC8613">
Object Security for Constrained RESTful Environments (OSCORE) </xref>, Object Security for Constrained RESTful Environments (OSCORE) </xref>
is leveraged by the Constrained Join Protocol (CoJP) and is expected to is leveraged by the Constrained Join Protocol (CoJP) and is expected to
be the primary protocol for the protection of the application payload be the primary protocol for the protection of the application payload
as well. The application payload may also be protected by as well. The application payload may also be protected by
the <xref target='RFC6347'>Datagram Transport Layer Security (DTLS) the <xref target="RFC6347">Datagram Transport Layer Security (DTLS)
</xref> sitting either under CoAP or over CoAP so it can traverse </xref> sitting either under CoAP or over CoAP so it can traverse
proxies. proxies.
</t>
<t>
<!-- Similarly, the <xref target="RFC5191">
Protocol for Carrying Authentication for Network access (PANA)</xref>
is represented as an example of a protocol that could be leveraged to
secure the join process, as a Layer-3 alternate to IEEE Std. 802.1x/EAP
.
Regardless, the security model ensures that, prior to a join process,
packets from a untrusted device are controlled in volume and in
reachability. In particular, a PANA stack should be separated from
the main protocol stack to avoid attacks during the join process
that is introduced in <xref target='rflo'/>.
-->
</t> </t>
<t> <t>
The 6TiSCH Operation The 6TiSCH Operation
sublayer (6top) is a sublayer of a Logical Link Control (LLC) Sublayer (6top) is a sublayer of a Logical Link Control (LLC)
that provides the abstraction of an IP link over a TSCH MAC and that provides the abstraction of an IP link over a TSCH MAC and
schedules packets over TSCH cells, as further discussed in the next schedules packets over TSCH cells, as further discussed in the next
sections, providing in particular dynamic cell allocation with the sections, providing in particular dynamic cell allocation with the
6top Protocol (6P) <xref target='RFC8480'/>. 6top Protocol (6P) <xref target="RFC8480"/>.
</t> </t>
<t> <t>
The reference stack presented in this document was implemented The reference stack presented in this document was implemented
and interop-tested by a conjunction of opensource, IETF and ETSI efforts. and interoperability-tested by a combination of open source, IETF, and ETS I efforts.
One goal is to help other bodies to adopt the stack as a whole, making the One goal is to help other bodies to adopt the stack as a whole, making the
effort to move to an IPv6-based IoT stack easier. effort to move to an IPv6-based IoT stack easier.
</t> </t>
<t> <t>
For a particular For a particular
environment, some of the choices that are made in this architecture may no t environment, some of the choices that are available in this architecture m ay not
be relevant. For instance, RPL is not required for star topologies and be relevant. For instance, RPL is not required for star topologies and
mesh-under Layer-2 routed networks, and the 6LoWPAN compression may not be mesh-under Layer 2 routed networks, and the 6LoWPAN compression may not be
sufficient for ultra-constrained cases such as some Low-Power Wide Area sufficient for ultra-constrained cases such as some Low-Power Wide Area
(LPWA) networks. In such cases, it is perfectly doable to adopt a subset (LPWA) networks. In such cases, it is perfectly doable to adopt a subset
of the selection that is presented hereafter and then select alternate of the selection that is presented hereafter and then select alternate
components to complete the solution wherever needed. components to complete the solution wherever needed.
</t> </t>
</section> </section>
<section><name>Communication Paradigms and Interaction Models</name> <section><name>Communication Paradigms and Interaction Models</name>
<t> <t>
<xref target='sixTTerminology'/> provides the terms <xref target="sixTTerminology"/> provides the terms
of Communication Paradigms and Interaction Models, in relation with of Communication Paradigms and Interaction Models in combination with
<xref target='RFC3444'>"On the Difference between Information Models <xref target="RFC3444">"On the Difference between Information Models
and Data Models"</xref>. and Data Models"</xref>.
A Communication Paradigm would be an abstract view of a protocol exchan A Communication Paradigm is an abstract view of a protocol exchange
ge, and has an Information Model for the information that is being exchange
and would come with an Information Model for the information that is be d.
ing exchanged. In contrast, an Interaction Model is more refined and points to standar
In contrast, an Interaction Model would be more refined and could point d operation
to standard operation such as a Representational State Transfer (REST) "GET" operation and ma
such as a Representational state transfer (REST) "GET" operation and wo tches
uld match
a Data Model for the data that is provided over the protocol exchange. a Data Model for the data that is provided over the protocol exchange.
</t> </t>
<t>
Section 2.1.3 of
<xref target='I-D.ietf-roll-rpl-industrial-applicability'/> and next
sections discuss application-layer paradigms, such as Source-sink (SS)
that is a Multipeer to Multipeer (MP2MP) model primarily used for
alarms and alerts, Publish-subscribe (PS, or pub/sub) that is typically
used for sensor data, as well as Peer-to-peer (P2P) and
Peer-to-multipeer (P2MP) communications.
<t>
<xref target="I-D.ietf-roll-rpl-industrial-applicability" section="2.1.
3" sectionFormat="of" format="default"/>
and its following
sections discuss application-layer paradigms such as source-sink,
which is a multipeer-to-multipeer model primarily used for
alarms and alerts, publish-subscribe, which is typically
used for sensor data, as well as peer-to-peer and
peer-to-multipeer communications.
</t> </t>
<t> <t>
Additional considerations on Duocast - one sender, two receivers for re dundancy - Additional considerations on duocast -- one sender, two receivers for r edundancy --
and its N-cast generalization are also provided. and its N-cast generalization are also provided.
Those paradigms are frequently used in industrial automation, which is Those paradigms are frequently used in industrial automation, which is
a major use case for IEEE Std. 802.15.4 TSCH wireless networks with a major use case for IEEE Std 802.15.4 TSCH wireless networks with
<xref target='ISA100.11a'/> and <xref target='WirelessHART'/>, that <xref target="ISA100.11a"/> and <xref target="WirelessHART"/>, which
provides a wireless access to <xref target='HART'/> applications and provides a wireless access to <xref target="HART"/> applications and
devices. devices.
</t> </t>
<t> <t>
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 Link-Layer (one-hop), Management mechanisms for the TSCH schedule at the link layer (one hop)
Network-layer (multihop along a Track), and Application-layer ,
(remote control) are discussed in <xref target='schd'/>. network layer (multihop along a Track), and application layer
Link-Layer frame forwarding interactions are discussed in <xref target= (remote control) are discussed in <xref target="schd"/>.
'fwd'/>, and Link-layer frame forwarding interactions are discussed in <xref target=
Network-layer Packet routing is addressed in <xref target='rtg'/>. "fwd"/>, and
network-layer packet routing is addressed in <xref target="rtg"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor='dd'><name>Architecture Components</name> <section anchor="dd"><name>Architecture Components</name>
<section anchor='RPLvs6lo'><name>6LoWPAN (and RPL)</name> <section anchor="RPLvs6lo"><name>6LoWPAN (and RPL)</name>
<t>A RPL DODAG is formed of a Root, a collection of routers, and leaves that <t>A RPL DODAG is formed of a Root, a collection of routers, and leaves that
are hosts. Hosts are nodes which do not forward packets that they did not ge are hosts. Hosts are nodes that do not forward packets that they did not gen
nerate. erate.
RPL-aware leaves will participate to RPL to advertise their own RPL-aware leaves will participate in RPL to advertise their own
addresses, whereas RPL-unaware leaves depend on a connected RPL router to do 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 so. RPL interacts with 6LoWPAN ND at multiple levels, in particular at the
Root and in the RPL-unaware leaves. Root and in the RPL-unaware leaves.
</t> </t>
<section anchor='leaf'><name>RPL-Unaware Leaves and 6LoWPAN ND</name> <section anchor="leaf"><name>RPL-Unaware Leaves and 6LoWPAN ND</name>
<t>RPL needs a set of information to advertise <t>RPL needs a set of information to advertise
a leaf node through a Destination Advertisement Object (DAO) message and esta blish reachability. a leaf node through a Destination Advertisement Object (DAO) message and esta blish reachability.
</t> </t>
<t> <t><xref target="RFC9010">"Routing for RPL Leaves"</xref>
<xref target='I-D.ietf-roll-unaware-leaves'>"Routing for RPL Leaves"</xref>
details the basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN details the basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN
that supports <xref target='RFC8505'/> to obtain return that supports <xref target="RFC8505"/> to obtain return
connectivity via the RPL network as an RPL-unaware leaf. connectivity via the RPL network as a RPL-unaware leaf.
The leaf indicates that it requires reachability services for the The leaf indicates that it requires reachability services for the
Registered Address from a Routing Registrar by setting a 'R' flag in the Registered Address from a Routing Registrar by setting an 'R' flag in the
Extended Address Registration Option <xref target='RFC8505'/>, and it Extended Address Registration Option <xref target="RFC8505"/>, and it
provides a TID that maps to a sequence number in section 7 of RPL <xref targe provides a TID that maps to the "Path Sequence" defined in <xref target="RFC6
t='RFC6550'/>. 550" section="6.7.8" sectionFormat="of" format="default"/>, and its operation is
defined in <xref target="RFC6550" section="7.2" sectionFormat="of" format="defa
ult"/>.
</t> </t>
<t> <t><xref target="RFC9010"/> also enables the leaf to signal
<xref target='I-D.ietf-roll-unaware-leaves'/> also enables the leaf to signal with the RPLInstanceID that it wants to participate by using the
the RPL InstanceID that it wants to participate to using the Opaque field of the EARO. On the backbone, the RPLInstanceID is
Opaque field of the EARO. On the backbone, the InstanceID is
expected to be mapped to an overlay that matches the RPL Instance, e.g., 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. a Virtual LAN (VLAN) or a virtual routing and forwarding (VRF) instance.
</t> </t>
<t> <t>
Though at the time of this writing the above specification enables a model Though, at the time of this writing, the above specification enables a model
where the separation is possible, this architecture recommends to where the separation is possible, this architecture recommends
collocate the functions of 6LBR and RPL Root. co-locating the functions of 6LBR and RPL Root.
</t> </t>
</section> <!-- RPL-Unaware Leaves and 6LoWPAN ND --> </section>
<section anchor='rpllbr'><name>6LBR and RPL Root</name> <section anchor="rpllbr"><name>6LBR and RPL Root</name>
<t> <t>
With the 6LowPAN ND <xref target='RFC6775'/>, information on the 6LBR is With the 6LoWPAN ND <xref target="RFC6775"/>, information on the 6LBR is
disseminated via an Authoritative Border Router Option (ABRO) in RA messages . disseminated via an Authoritative Border Router Option (ABRO) in RA messages .
<xref target='RFC8505'/> extends <xref target='RFC6775'/> to enable a <xref target="RFC8505"/> extends <xref target="RFC6775"/> to enable a
registration for routing and proxy ND. registration for routing and proxy ND.
The capability to support <xref target='RFC8505'/> The capability to support <xref target="RFC8505"/>
is indicated in the 6LoWPAN Capability Indication Option (6CIO). is indicated in the 6LoWPAN Capability Indication Option (6CIO).
The discovery and liveliness of the RPL Root are obtained through RPL The discovery and liveliness of the RPL Root are obtained through RPL
<xref target='RFC6550'/> itself. <xref target="RFC6550"/> itself.
</t> </t>
<t> <t>
When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities
are co-located in order that the address of the 6LBR be indicated by RPL are co-located in order that the address of the 6LBR is indicated by RPL
DIO messages and to associate the unique ID from the EDAR/EDAC DODAG Information Object (DIO) messages and to associate the ROVR from
<xref target='RFC8505'/> exchange with the state that is maintained by RPL. the Extended Duplicate Address Request/Confirmation (EDAR/EDAC)
exchange <xref target="RFC8505"/> with the state that is maintained by RPL.
</t> </t>
<t> <t>
Section 7 of <xref target='I-D.ietf-roll-unaware-leaves'/> specifies how <xref target="RFC9010" section="7" sectionFormat="of" format="default"/> spec ifies how
the DAO messages are used to reconfirm the registration, thus eliminating a the DAO messages are used to reconfirm the registration, thus eliminating a
duplication of functionality between DAO and EDAR/EDAC messages, as duplication of functionality between DAO and EDAR/EDAC messages, as
illustrated in <xref target='figReg2'/>. illustrated in <xref target="figReg2"/>.
<xref target='I-D.ietf-roll-unaware-leaves'/> also provides the protocol <xref target="RFC9010"/> also provides the protocol
elements that are needed when the 6LBR and RPL Root functionalities are not elements that are needed when the 6LBR and RPL Root functionalities are not
co-located. co-located.
</t> </t>
<t> <t>
Even though the Root of the RPL network is integrated with the 6LBR, Even though the Root of the RPL network is integrated with the 6LBR,
it is logically separated from the Backbone Router (6BBR) that it is logically separated from the Backbone Router (6BBR) that
is used to connect the 6TiSCH LLN to the backbone. This way, is used to connect the 6TiSCH LLN to the backbone. This way,
the Root has all information from 6LoWPAN ND and RPL about the LLN the Root has all information from 6LoWPAN ND and RPL about the LLN
devices attached to it. devices attached to it.
</t><t> </t><t>
This architecture also expects that the Root of the RPL network This architecture also expects that the Root of the RPL network
(proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR,
for whatever operation the 6BBR performs on the backbone, such for whatever operation the 6BBR performs on the backbone, such
as ND proxy, or redistribution in a routing protocol. as ND proxy or redistribution in a routing protocol.
This relies on an extension of the 6LoWPAN ND registration described in This relies on an extension of the 6LoWPAN ND registration described in
<xref target='I-D.ietf-6lo-backbone-router'/>. <xref target="RFC8929"/>.
</t><t> </t><t>
This model supports the movement of a 6TiSCH device across the Multi-Link This model supports the movement of a 6TiSCH device across the multi-link
Subnet, and allows the proxy registration of 6TiSCH nodes deep into the subnet and allows the proxy registration of 6TiSCH nodes deep into the
6TiSCH LLN by the 6LBR / RPL Root. 6TiSCH LLN by the 6LBR / RPL Root.
This is why in <xref target='RFC8505'/> the Registered Address is signaled This is why in <xref target="RFC8505"/> the Registered Address is signaled
in the Target Address field of the NS message as opposed to the IPv6 Source in the Target Address field of the Neighbor Solicitation (NS) message as oppo
sed to the IPv6 Source
Address, which, in the case of a proxy registration, is that of the 6LBR / Address, which, in the case of a proxy registration, is that of the 6LBR /
RPL Root itself. RPL Root itself.
</t> </t>
</section> </section>
<!--
<section anchor='gone' title="registration Failures Due to Movement">
<t>Registration to the 6LBR through DAR/DAC messages <xref target="RFC6775"/>
may percolate slowly through an LLN mesh, and it might happen that in
the meantime, the 6LoWPAN node moves and registers somewhere else. Both RPL
and 6LoWPAN ND lack the capability to indicate that the same node is
registered elsewhere, so as to invalidate states down the deprecated path.
</t><t> In its current expression and functionality,
6LoWPAN ND considers that the registration is used for the purpose of DAD
only as opposed to that of achieving reachability, and as long as the same
node registers the IPv6 address, the protocol is functional. to
act as a RPL leaf registration protocol and achieve reachability, the
device must use the same TID for all its concurrent registrations, and
registrations with a past TID should be declined. The state for an obsolete
registration in the 6LR, as well as the RPL routers on the way, should be
invalidated. This can only be achieved with the addition of a new Status in
the DAC message, and a new error/clean-up flow in RPL.
</t>
</section>
<section anchor='prox' title="Proxy registration">
<t>The 6BBR provides the capability to defend an address that is owned by
a 6LoWPAN Node, and attract packets to that address, whether it is done by
proxying ND over a Multi-Link Subnet, redistributing the address in a routing
protocol or advertising it through an alternate proxy registration such as
<xref target="RFC6830">the Locator/ID Separation Protocol</xref> (LISP) or
<xref target="RFC6275">Mobility Support in IPv6</xref> (MIPv6). In a LLN,
it makes sense to piggyback the request to proxy/defend an address with its
registration.
</t>
</section>
<section anchor='source' title="Target Registration">
<t>
In their current incarnations, both 6LoWPAN ND and Efficient ND expect
that the address being registered is the source of the NS(ARO) message and
thus impose that a Source Link-Layer Address (SLLA) option be present in the
message.
In a mesh scenario where the 6LBR is physically separated from the 6LoWPAN
Node, the 6LBR does not own the address being registered. This is why
<xref target="I-D.ietf-6lo-backbone-router"/>
registers the Target of the NS message as opposed to the Source Address.
From another perspective, it may happen, in the use case of a Star topology,
that the 6LR, 6LBR and 6BBR are effectively collapsed and should support
6LoWPAN ND clients. The convergence of efficient ND and 6LoWPAN ND into a
single protocol is thus highly desirable.
</t><t>
In any case, as long as the DAD process is not complete for the address
used as source of the packet, it is against the current practice to advertise
the SLLA, since this may corrupt the ND cache of the destination node, as
discussed in the <xref target="RFC4429">Optimistic DAD specification</xref>
with regards to the TENTATIVE state.
</t><t>
This may look like a chicken and an egg problem, but in fact 6LoWPAN ND
acknowledges that the Link-Local Address that is based on an EUI-64 address
of a LLN node may be autoconfigured without the need for DAD.
It results that a node could use that Address as source, with an SLLA
option in the message if required, to register any other addresses, either
Global or Unique-Local Addresses, which would be indicated in the Target.
</t>
<t>
The suggested change is to register the target of the NS message, and use
Target Link-Layer Address (TLLA) in the NS as opposed to the SLLA to
install a Neighbor Cache Entry. This would apply to both Efficient ND
and 6LoWPAN ND in a very same manner, with the caveat that depending on the
nature of the link between the 6LBR and the 6BBR, the 6LBR may resort to
classical ND or DHCPv6 to obtain the address that it uses to source the NS
registration messages, whether for itself or on behalf of LLN nodes.
</t>
</section>
<section anchor='Rroot' title="RPL Root vs. 6LBR">
<t>6LoWPAN ND is unclear on how the 6LBR is discovered, and how the liveliness
of the 6LBR is asserted over time. On the other hand, the discovery
and liveliness of the RPL Root are obtained through the RPL protocol.
</t><t>
When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities
are co-located in order that the address of the 6LBR be indicated by RPL
DIO messages and to associate the unique ID from the DAR/DAC exchange with
the state that is maintained by RPL. The DAR/DAC exchange becomes a
preamble to the DAO messages that are used from then on to reconfirm the
registration, thus eliminating a duplication of functionality between DAO
and DAR messages.
</t>
</section> </section>
<section anchor='Sec' title="Securing the Registration"> <section anchor="join"><name>Network Access and Addressing</name>
<t> <section anchor="rflo"><name>Join Process</name>
A typical attack against IPv6 ND is address spoofing, whereby a rogue node
claims the IPv6 Address of another node in and hijacks its traffic. The
threats against IPv6 ND as described in
<xref target="RFC3971">SEcure Neighbor Discovery (SEND)</xref>
are applicable to 6LoPWAN ND as well, but the solution can not work as the
route over network does not permit direct peer to peer communication.
</t><t>
Additionally SEND requires considerably enlarged ND messages to carry
cryptographic material, and requires that each protected address is generated
cryptographically, which implies the computation of a different key for
each Cryptographically Generated Address (CGA). SEND as defined in
<xref target="RFC3971"/> is thus largely unsuitable for application in a LLN.
</t><t>
With 6LoWPAN ND, as illustrated in <xref target='figReg'/>, it is
possible to leverage the registration state in the 6LBR, which may store
additional security information for later proof of ownership. If this
information proves the ownership independently of the address itself,
then a single proof may be used to protect multiple addresses.
</t><t>
Once an Address is registered,
the 6LBR maintains a state for that Address and is in position to bind
securely the first registration with the Node that placed it, whether the
Address is CGA or not. It should thus be possible to protect the ownership of
all the addresses of a 6LoWPAN Node with a single key, and there should not
be a need to carry the cryptographic material more than once to the 6LBR.
</t><t>
The energy constraint is usually a foremost factor, and attention should be
paid to minimize the burden on the CPU. Hardware-assisted support of variants
of the <xref target="RFC3610">Counter with CBC-MAC</xref> (CCM) authenticated
encryption block cipher mode such as CCM* are common in LowPower ship-set
implementations, and 6LoWPAN ND security mechanism should be capable to
reuse them when applicable.
</t><t>
Finally, the code footprint in the device being also an issue, the capability
to reuse not only hardware-assist mechanisms but also software across layers
has to be considered. For instance, if code has to be present for upper-layer
operations, e.g <xref target="RFC6655">AES-CCM Cipher Suites for Transport
Layer Security (TLS)</xref>, then the capability to reuse that code should be
considered.
</t>
-->
</section>
<section anchor='join'><name>Network Access and Addressing</name>
<section anchor='rflo'><name>Join Process</name>
<t> <t>
A new device, called the pledge, undergoes the join protocol to become a node A new device, called the pledge, undergoes the join protocol to become a node
in a 6TiSCH network. This usually occurs only once when the device is in a 6TiSCH network. This usually occurs only once when the device is
first powered on. The pledge communicates with the Join Registrar/Coordi nator first powered on. The pledge communicates with the Join Registrar/Coordi nator
(JRC) of the network through a Join Proxy (JP), a radio neighbor of the p ledge. (JRC) of the network through a Join Proxy (JP), a radio neighbor of the p ledge.
</t><t> </t><t>
The JP is discovered though MAC layer beacons. When multiple JPs from pos The JP is discovered though MAC-layer beacons. When multiple JPs from pos
sibly multiple networks are visible, trial and error till an acceptable position sibly
in the right network is obtained becomes ineffficient. multiple networks are visible, using trial and error until an acceptable
<xref target='I-D.ietf-6tisch-enrollment-enhanced-beacon'/> adds a new su position
btype in the Information Element that was delegated to the IETF <xref target='RF in the right network is obtained becomes inefficient.
C8137'/> and provides visibility on the network that can be joined and the willi <xref target="RFC9032"/> adds a new subtype in the Information Element th
ngness by the JP and the Root to be used by the pledge. at
was delegated to the IETF <xref target="RFC8137"/> and provides visibilit
y
into the network that can be joined and the willingness of the JP and the
Root to be used by the pledge.
</t><t> </t><t>
The join protocol provides the following functionality: The join protocol provides the following functionality:
</t><ul spacing='normal'> </t>
<ul spacing="normal">
<li> Mutual authentication</li> <li> Mutual authentication</li>
<li> Authorization</li> <li> Authorization</li>
<li> Parameter distribution to the pledge over a secure channel</li> <li> Parameter distribution to the pledge over a secure channel</li>
</ul><t> </ul>
</t>
<t> <t>
Minimal Security Framework for 6TiSCH <xref target='I-D.ietf-6tisch-mini mal-security'/> The Minimal Security Framework for 6TiSCH <xref target="RFC9031"/>
defines the minimal mechanisms required for this join process to occur i n a secure defines the minimal mechanisms required for this join process to occur i n a secure
manner. The specification defines the Constrained Join Protocol (CoJP) t hat is used manner. The specification defines the Constrained Join Protocol (CoJP), which is used
to distribute the parameters to the pledge over a secure session establi shed through to distribute the parameters to the pledge over a secure session establi shed through
OSCORE <xref target='I-D.ietf-core-object-security'/>, and a secure conf iguration of the network OSCORE <xref target="RFC8613"/> and which describes the secure configura tion of the network
stack. In the minimal setting with pre-shared keys (PSKs), CoJP allows t he pledge to stack. In the minimal setting with pre-shared keys (PSKs), CoJP allows t he pledge to
join after a single round-trip exchange with the JRC. The provisioning o f the PSK to join after a single round-trip exchange with the JRC. The provisioning o f the PSK to
the pledge and the JRC needs to be done out of band, through a 'one-touc h' the pledge and the JRC needs to be done out of band, through a 'one-touc h'
bootstrapping process, which effectively enrolls the pledge into the dom ain managed by bootstrapping process, which effectively enrolls the pledge into the dom ain managed by
the JRC. the JRC.
</t> </t>
<t> <t>
In certain use cases, the 'one touch' bootstrapping is not feasible due In certain use cases, the 'one-touch' bootstrapping is not feasible due
to the to the
operational constraints and the enrollment of the pledge into the domain operational constraints, and the enrollment of the pledge into the domai
needs to occur n needs to occur
in-band. This is handled through a 'zero-touch' extension of the Minimal Security Framework in-band. This is handled through a 'zero-touch' extension of the Minimal Security Framework
for 6TiSCH. Zero touch <xref target='I-D.ietf-6tisch-dtsecurity-zerotouc for 6TiSCH. The zero-touch extension <xref target="I-D.ietf-6tisch-dtsec
h-join'/> extension leverages urity-zerotouch-join"/> leverages
the 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' [<xref tar the "<xref target="RFC8995" format="title"/>" <xref target="RFC8995"/>
get='I-D.ietf-anima-bootstrapping-keyinfra'/>
work to establish a shared secret between a pledge and the JRC without n ecessarily having work to establish a shared secret between a pledge and the JRC without n ecessarily having
them belong to a common (security) domain at join time. This happens thr ough inter-domain them belong to a common (security) domain at join time. This happens thr ough inter-domain
communication occurring between the JRC of the network and the domain of the pledge, communication occurring between the JRC of the network and the domain of the pledge,
represented by a fourth entity, Manufacturer Authorized Signing Authorit y (MASA). Once represented by a fourth entity, Manufacturer Authorized Signing Authorit y (MASA). Once
the zero-touch exchange completes, the CoJP exchange defined in <xref ta rget='I-D.ietf-6tisch-minimal-security'/> the zero-touch exchange completes, the CoJP exchange defined in <xref ta rget="RFC9031"/>
is carried over the secure session established between the pledge and th e JRC. is carried over the secure session established between the pledge and th e JRC.
</t> </t>
<t> <t>
<xref target='figJoin'/> depicts the join process and where a Link-Local <xref target="figJoin"/> depicts the join process and where a Link-Local
Address (LLA) is used, versus a Global Unicast Address (GUA). Address (LLA) is used, versus a Global Unicast Address (GUA).
</t> </t>
<figure anchor='figJoin' suppress-title='false'><name>Join process in a Multi-Li <figure anchor="figJoin" suppress-title="false">
nk Subnet. Parentheses () denote optional exchanges.</name> <name>Join Process in a Multi-Link Subnet. Parentheses () denote optional exchan
ges.</name>
<artwork><![CDATA[ <artwork><![CDATA[
6LoWPAN Node 6LR 6LBR Join Registrar MASA 6LoWPAN Node 6LR 6LBR Join Registrar MASA
(pledge) (Join Proxy) (Root) /Coordinator (JRC) (pledge) (Join Proxy) (Root) /Coordinator (JRC)
| | | | | | | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network | | 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network |
| LLN link |Route-Over mesh|(the Internet)|(the Internet)| | LLN link |Route-Over mesh|(the Internet)|(the Internet)|
| | | | | | | | | |
| Layer-2 | | | | | Layer 2 | | | |
|enhanced beacon| | | | |Enhanced Beacon| | | |
|<--------------| | | | |<--------------| | | |
| | | | | | | | | |
| NS (EARO) | | | | | NS (EARO) | | | |
| (for the LLA) | | | | | (for the LLA) | | | |
|-------------->| | | | |-------------->| | | |
| NA (EARO) | | | | | NA (EARO) | | | |
|<--------------| | | | |<--------------| | | |
| | | | | | | | | |
| (Zero-touch | | | | | (Zero-touch | | | |
| handshake) | (Zero-touch handshake) | (Zero-touch | | handshake) | (Zero-touch handshake) | (Zero-touch |
skipping to change at line 1452 skipping to change at line 1255
| |<-----------------------------| | | | |<-----------------------------| | |
|CoJP Join Resp | | | | | |CoJP Join Resp | | | | |
| using LLA | | | | | | using LLA | | | | |
|<--------------| | | | / |<--------------| | | | /
| | | | | | | | | |
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor='rreg'><name>Registration</name> <section anchor="rreg"><name>Registration</name>
<t> <t>
Once the pledge successfully completes the CoJP protocol and becomes Once the pledge successfully completes the CoJP exchange and becomes
a network node, it obtains the network prefix from neighboring routers a network node, it obtains the network prefix from neighboring routers
and registers its IPv6 addresses. and registers its IPv6 addresses.
As detailed in <xref target='RPLvs6lo'/>, the combined 6LoWPAN ND 6LBR As detailed in <xref target="RPLvs6lo"/>, the combined 6LoWPAN ND 6LBR
and Root of the RPL network learn information such as the device Unique and Root of the RPL network learn information such as an identifier (de
ID (from 6LoWPAN ND) and the updated Sequence Number (from RPL), and vice EUI-64 <xref target="RFC6775" format="default"/> or a ROVR <xref target="RF
perform 6LoWPAN ND proxy registration to the 6BBR of behalf of the LLN C8505" format="default"/>
(from 6LoWPAN ND)) and the updated Sequence Number (from RPL), and
perform 6LoWPAN ND proxy registration to the 6BBR on behalf of the LLN
nodes. nodes.
</t> </t>
<t> <t>
<xref target='figReg'/> illustrates the initial IPv6 signaling that <xref target="figReg"/> illustrates the initial IPv6 signaling that
enables a 6LN to form a global address and register it to a 6LBR enables a 6LN to form a global address and register it to a 6LBR
using 6LoWPAN ND <xref target='RFC8505'/>, is then carried using 6LoWPAN ND <xref target="RFC8505"/>. It is then carried
over RPL to the RPL Root, and then to the 6BBR. This flow happens over RPL to the RPL Root and then to the 6BBR. This flow happens
just once when the address is created and first registered. just once when the address is created and first registered.
</t> </t>
<figure anchor='figReg' suppress-title='false'><name>Initial Registration Flow o ver Multi-Link Subnet</name> <figure anchor="figReg" suppress-title="false"><name>Initial Registration Flow o ver Multi-Link Subnet</name>
<artwork><![CDATA[ <artwork><![CDATA[
6LoWPAN Node 6LR 6LBR 6BBR 6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (Root) (RPL leaf) (router) (Root)
| | | | | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh|Ethernet/serial| Backbone | LLN link |Route-Over mesh|Ethernet/serial| Backbone
| | | | | | | |
| RS (mcast) | | | | RS (mcast) | | |
|-------------->| | | |-------------->| | |
|-----------> | | | |-----------> | | |
|------------------> | | |------------------> | |
skipping to change at line 1510 skipping to change at line 1311
| | |<--------------| | | |<--------------|
| | Extended DAC | | | | Extended DAC | |
| |<--------------| | | |<--------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
<xref target='figReg2'/> illustrates the repeating IPv6 signaling that <xref target="figReg2"/> illustrates the repeating IPv6 signaling that
enables a 6LN to keep a global address alive and registered to its 6LBR enables a 6LN to keep a global address alive and registered with its 6L
BR
using 6LoWPAN ND to the 6LR, RPL to the RPL Root, and then 6LoWPAN ND using 6LoWPAN ND to the 6LR, RPL to the RPL Root, and then 6LoWPAN ND
again again
to the 6BBR, which avoids repeating the Extended DAR/DAC flow across to the 6BBR, which avoids repeating the Extended DAR/DAC flow across
the network when RPL can suffice as a keep-alive mechanism. the network when RPL can suffice as a keep-alive mechanism.
</t> </t>
<figure anchor='figReg2' suppress-title='false'><name>Next Registration Flow ove r Multi-Link Subnet</name> <figure anchor="figReg2" suppress-title="false"><name>Next Registration Flow ove r Multi-Link Subnet</name>
<artwork><![CDATA[ <artwork><![CDATA[
6LoWPAN Node 6LR 6LBR 6BBR 6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (Root) (RPL leaf) (router) (Root)
| | | | | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh| ant IPv6 link | Backbone | LLN link |Route-Over mesh| ant IPv6 link | Backbone
| | | | | |
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|-------------->| | | |-------------->| | |
| NA(EARO) | | | | NA(EARO) | | |
skipping to change at line 1541 skipping to change at line 1341
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | NS(EARO) | | | | NS(EARO) |
| | |-------------->| | | |-------------->|
| | | NA(EARO) | | | | NA(EARO) |
| | |<--------------| | | |<--------------|
| | | | | | | |
| | | | | | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t>As the network builds up, a node should start as a <t>As the network builds up, a node should start as a
leaf to join the RPL network, and may later turn into both a RPL-capable leaf to join the RPL network and may later turn into both a RPL-capable
router and a 6LR, so as to accept leaf nodes router and a 6LR, so as to accept leaf nodes recursively joining the network.
to recursively join the network.
</t> </t>
</section> </section>
</section> <!--"Network Access and Addressing" --> </section>
<section anchor='s6Pprot'><name>TSCH and 6top</name> <section anchor="s6Pprot"><name>TSCH and 6top</name>
<section><name>6top</name> <section><name>6top</name>
<t> <t>
6TiSCH expects a high degree of scalability together with a 6TiSCH expects a high degree of scalability together with a
distributed routing functionality based on RPL. To achieve this distributed routing functionality based on RPL. To achieve this
goal, the spectrum must be allocated in a way that allows for goal, the spectrum must be allocated in a way that allows for
spatial reuse between zones that will not interfere with one spatial reuse between zones that will not interfere with one
another. another.
In a large and spatially distributed network, a 6TiSCH node is In a large and spatially distributed network, a 6TiSCH node is
often in a good position to determine usage of the spectrum in its often in a good position to determine usage of the spectrum in its
vicinity. vicinity.
</t> </t>
<t> <t>
With 6TiSCH, the abstraction of an IPv6 link is implemented as a With 6TiSCH, the abstraction of an IPv6 link is implemented as a
pair of bundles of cells, one in each direction. IP Links are only pair of bundles of cells, one in each direction. IP links are only
enabled between RPL parents and children. The 6TiSCH enabled between RPL parents and children. The 6TiSCH
operation is optimal when the size of a bundle is such that both operation is optimal when the size of a bundle minimizes both
the energy wasted in idle listening and the packet drops due to the energy wasted in idle listening and the packet drops due to
congestion loss are minimized, while packets are forwarded within congestion loss, while packets are forwarded within
an acceptable latency. an acceptable latency.
</t> </t>
<t> <t>
Use cases for distributed routing are often associated with a Use cases for distributed routing are often associated with a
statistical distribution of best-effort traffic with variable needs statistical distribution of best-effort traffic with variable needs
for bandwidth on each individual link. The 6TiSCH operation can for bandwidth on each individual link. The 6TiSCH operation can
remain optimal if RPL parents can adjust dynamically, and with enoug remain optimal if RPL parents can adjust, dynamically and with enoug
h reactivity to match the variations of best-effort traffic, h
the amount of bandwidth that is used to communicate between themselv reactivity to match the variations of best-effort traffic,
es and their children, in both directions. the amount of bandwidth that is used to communicate between themselv
es
and their children, in both directions.
In turn, the agility to fulfill the needs for additional cells In turn, the agility to fulfill the needs for additional cells
improves when the number of interactions with other devices and improves when the number of interactions with other devices and
the protocol latencies are minimized. the protocol latencies are minimized.
</t> </t>
<t> <t>
6top is a logical link control sitting between the IP layer and the 6top is a logical link control sitting between the IP layer and the
TSCH MAC layer, which provides the link abstraction that is required TSCH MAC layer, which provides the link abstraction that is required
for IP operations. The 6top protocol, 6P, which is specified in for IP operations. The 6top Protocol, 6P, which is specified in
<xref target='RFC8480'/>, is one of the services provided by 6top. <xref target="RFC8480"/>, is one of the services provided by 6top.
In particular, the 6top services are available over a management In particular, the 6top services are available over a management
API that enables an external management entity to schedule cells API that enables an external management entity to schedule cells
and slotframes, and allows the addition of complementary and slotframes, and allows the addition of complementary
functionality, for instance a Scheduling Function functionality, for instance, a Scheduling Function
that manages a dynamic schedule management based on that manages a dynamic schedule based on
observed resource usage as discussed in <xref target='dynsched'/>. observed resource usage as discussed in <xref target="dynsched"/>.
For this purpose, the 6TiSCH architecture differentiates "soft" For this purpose, the 6TiSCH architecture differentiates "soft"
cells and "hard" cells. cells and "hard" cells.
</t> </t>
<section><name>Hard Cells</name> <section><name>Hard Cells</name>
<t> <t>
"Hard" cells are cells that "Hard" cells are cells that
are owned and managed by a separate scheduling entity (e.g., a PCE) are owned and managed by a separate scheduling entity (e.g., a PCE)
that specifies the slotOffset/channelOffset of the cells to be that specifies the slotOffset/channelOffset of the cells to be
added/moved/deleted, in which case 6top can only act as instructed, added/moved/deleted, in which case 6top can only act as instructed
and may not move hard cells in the TSCH schedule on its own. and may not move hard cells in the TSCH schedule on its own.
</t> </t>
</section> </section>
<section><name>Soft Cells</name> <section><name>Soft Cells</name>
<t> <t>
In contrast, "soft" cells are cells that 6top can manage locally. In contrast, "soft" cells are cells that 6top can manage locally.
6top contains a monitoring process which monitors the performance of 6top contains a monitoring process that monitors the performance of
cells, and can add, remove soft cells in the TSCH schedule to adapt cells and that can add and remove soft cells in the TSCH schedule to
adapt
to the traffic needs, or move one when it performs poorly. to the traffic needs, or move one when it performs poorly.
To reserve a soft cell, the higher layer does not indicate the exact To reserve a soft cell, the higher layer does not indicate the exact
slotOffset/channelOffset of the cell to add, but rather the resultin g slotOffset/channelOffset of the cell to add, but rather the resultin g
bandwidth and QoS requirements. When the monitoring process triggers bandwidth and QoS requirements. When the monitoring process triggers
a cell reallocation, the two neighbor devices communicating over thi s a cell reallocation, the two neighbor devices communicating over thi s
cell negotiate its new position in the TSCH schedule. cell negotiate its new position in the TSCH schedule.
</t> </t>
</section> </section>
</section> </section>
<section anchor='missf'><name>Scheduling Functions and the 6top protocol</nam e> <section anchor="missf"><name>Scheduling Functions and the 6top Protocol</nam e>
<t>In the case of soft cells, the cell management entity that controls the <t>In the case of soft cells, the cell management entity that controls the
dynamic attribution of cells to adapt to the dynamics of variable rate flows dynamic attribution of cells to adapt to the dynamics of variable rate flows
is called a Scheduling Function (SF). is called a Scheduling Function (SF).
</t> </t>
<t> <t>
There may be multiple SFs with more or less aggressive reaction to the There may be multiple SFs that react more or less aggressively to the
dynamics of the network. dynamics of the network.
</t> </t>
<t> <t>
An SF may be seen as divided between an upper bandwidth adaptation logic An SF may be seen as divided between an upper bandwidth-adaptation logic
that is not aware of the particular technology that is used to obtain and that is unaware of the particular technology used to obtain and
release bandwidth, and an underlying service that maps those needs in the release bandwidth and an underlying service that maps those needs in the
actual technology, which means mapping the bandwidth onto cells in the case actual technology. In the case
of TSCH using the 6top protocol as illustrated in <xref target='fig6P'/>. of TSCH using the 6top Protocol as illustrated in <xref target="fig6P"/>,
this means mapping the bandwidth onto cells.
</t> </t>
<figure anchor='fig6P' suppress-title='false'><name>SF/6P stack in 6top </name> <figure anchor="fig6P" suppress-title="false"><name>SF/6P Stack in 6top </name>
<artwork><![CDATA[ <artwork><![CDATA[
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function | | Scheduling Function | | Scheduling Function |
| Bandwidth adaptation | | Bandwidth adaptation | | Bandwidth adaptation | | Bandwidth adaptation |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function | | Scheduling Function | | Scheduling Function |
| TSCH mapping to cells | | TSCH mapping to cells | | TSCH mapping to cells | | TSCH mapping to cells |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| 6top cells negotiation | <- 6P -> | 6top cells negotiation | | 6top cells negotiation | <- 6P -> | 6top cells negotiation |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
Device A Device B Device A Device B
skipping to change at line 1657 skipping to change at line 1457
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function | | Scheduling Function | | Scheduling Function |
| Bandwidth adaptation | | Bandwidth adaptation | | Bandwidth adaptation | | Bandwidth adaptation |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function | | Scheduling Function | | Scheduling Function |
| TSCH mapping to cells | | TSCH mapping to cells | | TSCH mapping to cells | | TSCH mapping to cells |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| 6top cells negotiation | <- 6P -> | 6top cells negotiation | | 6top cells negotiation | <- 6P -> | 6top cells negotiation |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
Device A Device B Device A Device B
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The SF relies on 6top services that implement the The SF relies on 6top services that implement the
<xref target='RFC8480'> 6top Protocol (6P) </xref> <xref target="RFC8480"> 6top Protocol (6P) </xref>
to negotiate the precise cells that will be allocated or freed based on the to negotiate the precise cells that will be allocated or freed based on the
schedule of the peer. It may be for instance that a peer wants to use a schedule of the peer. For instance, it may be that a peer wants to use a
particular time slot that is free in its schedule, but that timeslot is particular timeslot that is free in its schedule, but that timeslot is
already in use by the other peer for a communication with a third party on a already in use by the other peer to communicate with a third party on a
different cell. 6P enables the peers to find an agreement in a different cell. 6P enables the peers to find an agreement in a
transactional manner that ensures the final consistency of the nodes state. transactional manner that ensures the final consistency of the nodes' state.
</t> </t>
<t> <t>
<xref target='I-D.ietf-6tisch-msf'>MSF</xref> is one of the possible <xref target="RFC9033">MSF</xref> is one of the possible
scheduling functions. MSF uses the rendez-vous slot from Scheduling Functions. MSF uses the rendezvous slot from
<xref target='RFC8180'/> for network discovery, neighbor discovery, and any <xref target="RFC8180"/> for network discovery, neighbor discovery, and any
other broadcast. other broadcast.
</t> </t>
<t> <t>
For basic unicast communication with any neighbor, each node uses a receive For basic unicast communication with any neighbor, each node uses a receive
cell at a well-known slotOffset/channelOffset, derived from a hash of their cell at a well-known slotOffset/channelOffset, which is derived from a hash of their
own MAC address. own MAC address.
Nodes can reach any neighbor by installing a transmit (shared) cell with Nodes can reach any neighbor by installing a transmit (shared) cell with
slotOffset/channelOffset derived from the neighbor's MAC address. slotOffset/channelOffset derived from the neighbor's MAC address.
</t> </t>
<t> <t>
For child-parent links, MSF continuously monitors the load to/from parents For child-parent links, MSF continuously monitors the load between parents
and children. It then uses 6P to install/remove unicast cells whenever the and children. It then uses 6P to install or remove unicast cells whenever th
current schedule appears to be under-/over- provisioned. e
current schedule appears to be under-provisioned or over-provisioned.
</t> </t>
</section> </section>
<section><name>6top and RPL Objective Function operations</name> <section><name>6top and RPL Objective Function Operations</name>
<!-- 8.1.1. Support to RPL Neighbor Discovery and Parent Selection -->
<t> <t>
An implementation of a <xref target='RFC6550'>RPL</xref> Objective F An implementation of a <xref target="RFC6550">RPL</xref> Objective F
unction unction
(OF), such as the <xref target='RFC6552'> RPL Objective Function Zer (OF), such as the <xref target="RFC6552">RPL Objective Function Zero
o (OF0) (OF0)
</xref> that is used in the <xref target='RFC8180'> Minimal </xref> that is used in the <xref target="RFC8180">Minimal
6TiSCH Configuration </xref> to support RPL over a static schedule, 6TiSCH Configuration</xref> to support RPL over a static schedule, m
may ay
leverage, for its internal computation, the information maintained b leverage for its internal computation the information maintained by
y 6top. 6top.
</t> </t>
<t>An OF may require metrics about reachability, such as the Expected <t>An OF may require metrics about reachability, such as the Expected
Transmission Count (ETX) metric <xref target='RFC6551'/>. Transmission Count (ETX) metric <xref target="RFC6551"/>.
6top creates and maintains an abstract neighbor table, 6top creates and maintains an abstract neighbor table,
and this state may be leveraged to feed an OF and/or store OF inform ation and this state may be leveraged to feed an OF and/or store OF inform ation
as well. A neighbor table entry may contain a set of statistics with as well. A neighbor table entry may contain a set of statistics with
respect to that specific neighbor. respect to that specific neighbor.
</t> </t>
<t> <t>
The neighbor information may include the time when the last The neighbor information may include the time when the last
packet has been received from that neighbor, a set of cell quality packet has been received from that neighbor, a set of cell quality
metrics, e.g., received signal strength indication (RSSI) or link metrics, e.g., received signal strength indication (RSSI) or link
quality indicator (LQI), the number of packets sent to the quality indicator (LQI), the number of packets sent to the
neighbor or the number of packets received from it. This neighbor, or the number of packets received from it. This
information can be made available through 6top management APIs information can be made available through 6top management APIs
and used for instance to compute a Rank Increment that will and used, for instance, to compute a Rank Increment that will
determine the selection of the preferred parent. determine the selection of the preferred parent.
</t> </t>
<t> <t>
6top provides statistics about the underlying layer so the OF can be tuned 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 OF to to the nature of the TSCH MAC layer. 6top also enables the RPL OF to
influence the MAC behavior, for instance by configuring the periodic influence the MAC behavior, for instance, by configuring the periodi
ity of city of
IEEE Std. 802.15.4 Extended Beacons (EBs). By augmenting the EB peri IEEE Std 802.15.4 Extended Beacons (EBs). By augmenting the EB perio
odicity, it is dicity, it is
possible to change the network dynamics so as to improve the support of possible to change the network dynamics so as to improve the support of
devices that may change their point of attachment in the 6TiSCH netw ork. devices that may change their point of attachment in the 6TiSCH netw ork.
</t> </t>
<!-- PT: I took of the text about time source; the way we do it is a bi
t reverse:
we have an Instance that is used for time sourcing, and the preferred p
arent
becomes the time source. If we change preferred parent we use the new o
ne as
time source -->
<t> <t>
Some RPL control messages, such as the DODAG Information Object (DIO ) are Some RPL control messages, such as the DODAG Information Object (DIO ), are
ICMPv6 messages that are broadcast to all neighbor nodes. 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, by configuring TSCH to provide a broadcast channel,
as opposed to, for instance, piggybacking the DIO messages in as opposed to, for instance, piggybacking the DIO messages in
Layer-2 Enhanced Beacons (EBs), which would produce undue timer Layer 2 Enhanced Beacons (EBs), which would produce undue timer
coupling among layers, packet size issues and could conflict with coupling among layers and packet size issues, and could conflict wit
h
the policy of production networks where EBs are mostly eliminated the policy of production networks where EBs are mostly eliminated
to conserve energy. to conserve energy.
</t> </t>
<!--t>
In the TSCH schedule, each cell has the IEEE Std. 802.15.4e LinkType
attribute.
Setting the LinkType to ADVERTISING indicates that the cell MAY be u
sed to send an
Enhanced Beacon. When a node forms its Enhanced Beacon, the cell,
with LinkType=ADVERTISING, SHOULD be included in the FrameAndLinkIE,
and its LinkOption field SHOULD be set to the combination of
"Receive" and "Timekeeping". The receiver of the Enhanced Beacon MAY
be listening at the cell to get the Enhanced Beacon ([IEEE Std. 8021
54e]).
6top takes this way to establish broadcast channel, which not only
allows TSCH to broadcast Enhanced Beacons, but also allows protocol
exchanges by an upper layer such as RPL.
</t>
<t>
To broadcast ICMPv6 control messages used by RPL such as DIO or DAO,
6top uses the payload of a Data frames. The message is inserted into
the
queue associated with the cells which LinkType is set to ADVERTISING
.
Then, taking advantage of the broadcast cell feature established wit
h
FrameAndLinkIE (as described above), the RPL control message can be
received by neighbors, which enables the maintenance of RPL DODAGs.
</t>
<t>
A LinkOption combining "Receive" and "Timekeeping" bits indicates to
the receivers of the Enhanced Beacon that the cell MUST be used as a
broadcast cell. The frequency of sending Enhanced Beacons or other
broadcast messages by the upper layer is determined by the timers
associated with the messages. For example, the transmission of
Enhance Beacons is triggered by a timer in 6top; transmission of a
DIO message is triggered by the trickle timer of RPL.
</t-->
</section> </section>
<section anchor='sync'><name>Network Synchronization</name> <section anchor="sync"><name>Network Synchronization</name>
<t> <t>
Nodes in a TSCH network must be time synchronized. Nodes in a TSCH network must be time synchronized.
A node keeps synchronized to its time source neighbor A node keeps synchronized to its time source neighbor
through a combination of frame-based and acknowledgment-based synchr onization. through a combination of frame-based and acknowledgment-based synchr onization.
To maximize battery life and network throughput, it is advisable tha t RPL ICMP discovery To maximize battery life and network throughput, it is advisable tha t RPL ICMP discovery
and maintenance traffic (governed by the trickle timer) be somehow c and maintenance traffic (governed by the Trickle timer) be somehow c
oordinated with the oordinated with the
transmission of time synchronization packets (especially with enhanc transmission of time synchronization packets (especially with Enhanc
ed beacons). ed Beacons).
</t> </t>
<t> <t>
This could be achieved through an interaction of the 6top sublayer a nd the RPL objective Function, This could be achieved through an interaction of the 6top sublayer a nd the RPL Objective Function,
or could be controlled by a management entity. or could be controlled by a management entity.
</t> </t>
<!-- TW: Concept of TSGI developed in separate standards-Track draft? - ->
<t> <t>
Time distribution requires a loop-free structure. Nodes taken in a s ynchronization loop will rapidly Time distribution requires a loop-free structure. Nodes caught in a synchronization loop will rapidly
desynchronize from the network and become isolated. 6TiSCH uses a RP L DAG with a dedicated global Instance for the purpose of time synchronization. desynchronize from the network and become isolated. 6TiSCH uses a RP L DAG with a dedicated global Instance for the purpose of time synchronization.
That Instance is referred to as the Time Synchronization Global Inst ance (TSGI). That Instance is referred to as the Time Synchronization Global Inst ance (TSGI).
The TSGI can be operated in either of the 3 modes that are detailed The TSGI can be operated in either of the three modes that are detai
in section 3.1.3 of <xref target='RFC6550'>RPL</xref>, led
"Instances, DODAGs, and DODAG Versions". in Section <xref target="RFC6550" section="3.1.3" sectionFormat="bar
e" format="default"/>
of <xref target="RFC6550">RPL</xref>, "Instances, DODAGs, and DODA
G Versions".
Multiple uncoordinated DODAGs with independent Roots may be used if all the Roots Multiple uncoordinated DODAGs with independent Roots may be used if all the Roots
share a common time source such as the Global Positioning System (GP S). share a common time source such as the Global Positioning System (GP S).
</t> </t>
<t> <t>
In the absence In the absence
of a common time source, the TSGI should form a single DODAG with a virtual Root. of 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 op erations between A backbone network is then used to synchronize and coordinate RPL op erations between
the backbone routers that act as sinks for the LLN. the Backbone Routers that act as sinks for the LLN.
Optionally, RPL's periodic operations may be used to Optionally, RPL's periodic operations may be used to
transport the network synchronization. This may transport the network synchronization. This may
mean that 6top would need to trigger (override) the trickle timer if mean that 6top would need to trigger (override) the Trickle timer if
no other traffic has occurred for such a time that nodes may get out no other traffic has occurred for such a time that nodes may get out
of synchronization. of synchronization.
</t> </t>
<t> <t>
A node that has not joined the TSGI advertises a MAC level Join Prio rity A node that has not joined the TSGI advertises a MAC-level Join Prio rity
of 0xFF to notify its neighbors that is not capable of serving as ti me parent. of 0xFF to notify its neighbors that is not capable of serving as ti me parent.
A node that has joined the TSGI advertises a MAC level Join Priority set to 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 spe cified in its DAGRank() in that Instance, where DAGRank() is the operation spe cified in
section 3.5.1 of <xref target='RFC6550'/>, "Rank Comparison". Section <xref target="RFC6550" section="3.5.1" sectionFormat="bare"
format="default"/>
of <xref target="RFC6550"/>, "Rank Comparison".
</t> </t>
<!-- TW: Official request made to move alter IEEE Std. 802.15.4e text. Maybe remove last sentence? -->
<t> <t>
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 to propagate configuration information down t architecture, whereas RPL enables the propagation of configuration i
he DODAG. This applies to the TSGI as well; a nformation
Root is configured or obtains by unspecified means the knowledge down the DODAG. This applies to the TSGI as well; a
Root is configured, or obtains by unspecified means, the knowledge
of the RPLInstanceID for the TSGI. The Root advertises its DagRank of the RPLInstanceID for the TSGI. The Root advertises its DagRank
in the TSGI, that must be less than 0xFF, as its Join Priority in in the TSGI, which must be less than 0xFF, as its Join Priority in
its IEEE Std. 802.15.4 Extended Beacons (EB). its IEEE Std 802.15.4 EBs.
</t> </t>
<t> <t>
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.
</t> </t>
</section> </section>
<section anchor='slotframes'><name>Slotframes and CDU matrix</name> <section anchor="slotframes"><name>Slotframes and CDU Matrix</name>
<t> <t>
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) transmissions. layer that is also capable of scheduled (deterministic) transmissions.
A window of time is defined A window of time is defined
around the scheduled transmission where the medium must, as much as around the scheduled transmission where the medium must, as much as
practically feasible, be free of contending energy to ensure that the practically feasible, be free of contending energy to ensure that the
medium is free of contending packets when time comes for a scheduled medium is free of contending packets when the time comes for a schedule d
transmission. 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.
</t> </t>
<t> <t>
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 formatting Channel Distribution and Usage (CDU) matrix to describe that formatting
of time and frequencies, of time and frequencies.
</t> </t>
<t> <t>
A CDU matrix is defined centrally A CDU matrix is defined centrally
as part of the network definition. It is a matrix of cells with a as part of the network definition. It is a matrix of cells with a
height equal to the number of available channels (indexed by height equal to the number of available channels (indexed by
ChannelOffsets) and a width (in timeslots) that is the period of the channelOffsets) and a width (in timeslots) that is the period of the
network scheduling operation (indexed by slotOffsets) for that CDU network scheduling operation (indexed by slotOffsets) for that CDU
matrix. There are different models for scheduling the usage of the matrix. There are different models for scheduling the usage of the
cells, which place the responsibility of avoiding collisions either on cells, which place the responsibility of avoiding collisions either on
a central controller or on the devices themselves, at an extra cost in a central controller or on the devices themselves, at an extra cost in
terms of energy to scan for free cells (more in <xref target='schd'/>). terms of energy to scan for free cells (more in <xref target="schd"/>).
</t> </t>
<t> <t>
The size of a cell is a timeslot duration, and The size of a cell is a timeslot duration, and
values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to
accommodate for the transmission of a frame and an ack, including the accommodate for the transmission of a frame and an ack, including the
security validation on the receive side which may take up to a few security validation on the receive side, which may take up to a few
milliseconds on some device architecture. milliseconds on some device architecture.
</t> </t>
<t> <t>
A CDU matrix iterates over and over with a well-known channel rotation A CDU matrix iterates over a well-known channel rotation
called the hopping sequence. called the hopping sequence.
In a given network, there might be multiple CDU matrices that operate In a given network, there might be multiple CDU matrices that operate
with different width, so they have different durations and represent with different widths, so they have different durations and represent
different periodic operations. different periodic operations.
It is recommended that all CDU matrices in a 6TiSCH domain operate with It is recommended that all CDU matrices in a 6TiSCH domain operate with
the same cell duration and are aligned, so as to reduce the the same cell duration and are aligned so as to reduce the
chances of interferences from the Slotted ALOHA operations. chances of interferences from the Slotted ALOHA operations.
The knowledge of the CDU matrices is shared The knowledge of the CDU matrices is shared
between all the nodes and used in particular to define slotframes. between all the nodes and used in particular to define slotframes.
</t> </t>
<t> <t>
A slotframe is a MAC-level abstraction that is common to all nodes and A slotframe is a MAC-level abstraction that is common to all nodes and
contains a series of timeslots of equal length and precedence. contains a series of timeslots of equal length and precedence.
It is characterized by a slotframe_ID, and a slotframe_size. It is characterized by a slotframe_ID and a slotframe_size.
A slotframe aligns to a CDU matrix for its parameters, such as number A slotframe aligns to a CDU matrix for its parameters, such as number
and duration of timeslots. and duration of timeslots.
</t> </t>
<t> <t>
Multiple slotframes can coexist in a node schedule, i.e., a node can Multiple slotframes can coexist in a node schedule, i.e., a node can
have multiple activities scheduled in different slotframes. have multiple activities scheduled in different slotframes.
A slotframe is associated with a priority that may be related to A slotframe is associated with a priority that may be related to
the precedence of different 6TiSCH topologies. The slotframes may be the precedence of different 6TiSCH topologies. The slotframes may be
aligned to different CDU matrices and thus have different width. aligned to different CDU matrices and thus have different widths.
There is typically one slotframe for scheduled traffic that has the There is typically one slotframe for scheduled traffic that has the
highest precedence and one or more slotframe(s) for RPL traffic. highest precedence and one or more slotframe(s) for RPL traffic.
The timeslots in the slotframe are indexed by the SlotOffset; The timeslots in the slotframe are indexed by the slotOffset;
the first cell is at SlotOffset 0. the first cell is at slotOffset 0.
</t> </t>
<t> <t>
When a packet is received from a higher layer for transmission, When a packet is received from a higher layer for transmission,
6top inserts that packet in the outgoing queue 6top inserts that packet in the outgoing queue
which matches the packet best (Differentiated Services that matches the packet best (Differentiated Services
<xref target='RFC2474'/> can therefore be used). <xref target="RFC2474"/> can therefore be used).
At each scheduled transmit slot, 6top looks for the frame At each scheduled transmit slot, 6top looks for the frame
in all the outgoing queues that best matches the cells. in all the outgoing queues that best matches the cells.
If a frame is found, it is given to the TSCH MAC for transmission. If a frame is found, it is given to the TSCH MAC for transmission.
</t> </t>
</section> </section>
<section anchor='DistRsvTS'><name>Distributing the reservation of cells</n ame> <section anchor="DistRsvTS"><name>Distributing the Reservation of Cells</n ame>
<t> <t>
The 6TiSCH architecture introduces the concept of chunks The 6TiSCH architecture introduces the concept of chunks
(<xref target='sixTTerminology'/>) to distribute the allocation of (<xref target="sixTTerminology"/>) to distribute the allocation of
the spectrum for a whole group of cells at a time. the spectrum for a whole group of cells at a time.
The CDU matrix is formatted into a set of chunks, possibly as The CDU matrix is formatted into a set of chunks, possibly as
illustrated in <xref target='fig10'/>, each of the chunks illustrated in <xref target="fig10"/>, each of the chunks
identified uniquely by a chunk-ID. The knowledge of this identified uniquely by a chunk-ID. The knowledge of this
formatting is shared between all the nodes in a 6TiSCH network. formatting is shared between all the nodes in a 6TiSCH network.
It could be conveyed during the join process, or codified into a pro It could be conveyed during the join process, codified into a profil
file document, or obtained using some other mechanism. This is as opposed e document,
to static scheduling that refers to the pre-programmed mechanism tha or obtained using some other mechanism. This is as opposed
t to Static Scheduling, which refers to the preprogrammed mechanism
is specified in <xref target='RFC8180'/> and pre-exists to the specified in <xref target="RFC8180"/> and which existed before the
distribution of the chunk formatting. distribution of the chunk formatting.
</t> </t>
<figure anchor='fig10'><name>CDU matrix Partitioning in Chunks</name <figure anchor="fig10"><name>CDU Matrix Partitioning in Chunks</name
> >
<artwork align='center'> <artwork align="center"><![CDATA[
<![CDATA[
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
... ...
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
0 1 2 3 4 5 6 M 0 1 2 3 4 5 6 M
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
The 6TiSCH Architecture envisions a protocol that enables chunk The 6TiSCH architecture envisions a protocol that enables chunk
ownership appropriation whereby a RPL parent ownership appropriation whereby a RPL parent
discovers a chunk that is not used in its interference domain, discovers a chunk that is not used in its interference domain,
claims the chunk, and then defends it in case another RPL claims the chunk, and then defends it in case another RPL
parent would attempt to appropriate it while it is in use. parent would attempt to appropriate it while it is in use.
The chunk is the basic unit of ownership that is used in that proces s. The chunk is the basic unit of ownership that is used in that proces s.
</t> </t>
<t> <t>
As a result of the process of chunk ownership appropriation, the RPL As a result of the process of chunk ownership appropriation, the RPL
parent has exclusive authority to decide which cell in the parent has exclusive authority to decide which cell in the
appropriated chunk can be used by which node in its interference appropriated chunk can be used by which node in its interference
domain. In other words, it is implicitly delegated the right to domain. In other words, it is implicitly delegated the right to
manage the portion of the CDU matrix that is represented by the manage the portion of the CDU matrix that is represented by the
chunk. chunk.
<!-- Eliot's review: drop this sentence
The RPL parent may thus orchestrate
which transmissions occur in any of the cells in the chunk, by
allocating cells from the chunk to any form of communication (unicas
t,
multicast) in any direction between itself and its children.
-->
</t> </t>
<t> <t>
Initially, those cells are added to the heap of free cells, then Initially, those cells are added to the heap of free cells, then
dynamically placed into existing bundles, in new bundles, or dynamically placed into existing bundles, into new bundles, or
allocated opportunistically for one transmission. allocated opportunistically for one transmission.
</t> </t>
<t> <t>
Note that a PCE is expected to have precedence in the Note that a PCE is expected to have precedence in the
allocation, so that a RPL parent would only be able to obtain allocation, so that a RPL parent would only be able to obtain
portions that are not in-use by the PCE. portions that are not in use by the PCE.
</t> </t>
</section> </section>
</section> </section>
<!-- <section anchor="schd"><name>Schedule Management Mechanisms</name>
<section title="Functional Flows">
<t>
<list hangIndent="6" style="hanging">
<t hangText="Join:"></t>
<t hangText="Time Synchronization:"></t>
<t hangText="Setup for routing:"></t>
<t hangText="PCE reservation:"></t>
<t hangText="Distributed reservation:"></t>
<t hangText="Dynamic slot (de)allocation:"></t>
<t hangText="DSCP mapping:"></t>
</list>
</t>
</section>
-->
<section anchor='schd'><name>Schedule Management Mechanisms</name>
<t> <t>
6TiSCH uses 4 paradigms to manage the TSCH schedule of the LLN nodes: S 6TiSCH uses four paradigms to manage the TSCH schedule of the LLN nodes
tatic Scheduling, : Static Scheduling,
neighbor-to-neighbor Scheduling, remote monitoring and scheduling manag Neighbor-to-Neighbor Scheduling, Remote Monitoring and Scheduling Manag
ement, and Hop-by-hop scheduling. ement, and Hop-by-Hop Scheduling.
Multiple mechanisms are defined that implement the associated Interacti on Models, Multiple mechanisms are defined that implement the associated Interacti on Models,
and can be combined and used in the same LLN. and they can be combined and used in the same LLN.
Which mechanism(s) to use depends on application requirements. Which mechanism(s) to use depends on application requirements.
</t> </t>
<section anchor='mini'><name>Static Scheduling</name> <section anchor="mini"><name>Static Scheduling</name>
<t> <t>
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 shared , schedule may be shared by all nodes in the network. Cells are shared ,
and nodes contend for slot access in a slotted ALOHA manner. and nodes contend for slot access in a Slotted ALOHA manner.
</t> </t>
<t> <t>
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. case of network malfunction.
This schedule is pre-established, for instance decided by a network This schedule is preestablished, for instance, decided by a network
administrator based on operational needs. It can be pre-configured administrator based on operational needs. It can be preconfigured
into the nodes, or, more commonly, learned by a node when joining into the nodes, or, more commonly, learned by a node when joining
the network using standard IEEE Std. 802.15.4 Information Elements ( IE). the network using standard IEEE Std 802.15.4 Information Elements (I E).
Regardless, the schedule remains unchanged Regardless, the schedule remains unchanged
after the node has joined a network. after the node has joined a network.
RPL is used on the resulting network. This "minimal" scheduling RPL is used on the resulting network. This "minimal" scheduling
mechanism that implements this paradigm is detailed in mechanism that implements this paradigm is detailed in
<xref target='RFC8180'/>. <xref target="RFC8180"/>.
</t> </t>
</section> </section>
<section anchor='dynsched'><name>Neighbor-to-neighbor Scheduling</name> <section anchor="dynsched"><name>Neighbor-to-Neighbor Scheduling</name>
<t> <t>
In the simplest instantiation of a 6TiSCH network described in In the simplest instantiation of a 6TiSCH network described in
<xref target='mini'/>, nodes may expect a packet at any cell in <xref target="mini"/>, nodes may expect a packet at any cell in
the schedule and will waste energy idle listening. In a more the schedule and will waste energy idle listening. In a more
complex instantiation of a 6TiSCH network, a matching portion of the complex instantiation of a 6TiSCH network, a matching portion of the
schedule is established between peers to reflect the observed amount schedule is established between peers to reflect the observed amount
of transmissions between those nodes. The aggregation of the cells of transmissions between those nodes. The aggregation of the cells
between a node and a peer forms a bundle that the 6top layer uses to between a node and a peer forms a bundle that the 6top sublayer uses to
implement the abstraction of a link for IP. The bandwidth on that implement the abstraction of a link for IP. The bandwidth on that
link is proportional to the number of cells in the bundle. link is proportional to the number of cells in the bundle.
</t><t> </t><t>
If the size of a bundle is configured to fit an average amount of If the size of a bundle is configured to fit an average amount of
bandwidth, peak traffic is dropped. If the size is bandwidth, peak traffic is dropped. If the size is
configured to allow for peak emissions, energy is be wasted configured to allow for peak emissions, energy is wasted
idle listening. idle listening.
</t><t> </t><t>
As discussed in more details in <xref target='s6Pprot'/>, the As discussed in more detail in <xref target="s6Pprot"/>, the
<xref target='RFC8480'>6top Protocol</xref> <xref target="RFC8480">6top Protocol</xref>
specifies the exchanges between neighbor nodes to reserve soft cells specifies the exchanges between neighbor nodes to reserve soft cells
to transmit to one another, possibly under the control of a to transmit to one another, possibly under the control of a
Scheduling Function (SF). Because this reservation is done without Scheduling Function (SF). Because this reservation is done without
global knowledge of the schedule of other nodes in the LLN, scheduli ng global knowledge of the schedule of the other nodes in the LLN, sche duling
collisions are possible. collisions are possible.
<!-- 6top defines a monitoring process which
continuously Tracks the packet delivery ratio of soft cells.
It uses these statistics to trigger the reallocation of a soft cell
in the schedule, using a negotiation protocol between the neighbors
nodes communicating over that cell.
In the most efficient instantiations of a 6TiSCH network, the size o
f
the bundles that implement the links may be changed dynamically
in order to adapt to the need of end-to-end flows routed by RPL. -->
</t><t> </t><t>
And as discussed in <xref target='missf'/>, And as discussed in <xref target="missf"/>,
an optional Scheduling Function (SF) is used to an optional SF is used to
monitor bandwidth usage and perform requests for dynamic allocation monitor bandwidth usage and to perform requests for dynamic allocati
on
by the 6top sublayer. by the 6top sublayer.
The SF component is not part of the 6top sublayer. It may be The SF component is not part of the 6top sublayer. It may be
collocated on the same device or may be partially or fully offloaded co-located on the same device or may be partially or fully offloaded
to an external system. The <xref target='I-D.ietf-6tisch-msf'> to an external system. The <xref target="RFC9033">
"6TiSCH Minimal Scheduling Function (MSF)"</xref> provides a simple "6TiSCH Minimal Scheduling Function (MSF)"</xref> provides a simple
scheduling function that can be used by default by devices that SF that can be used by default by devices that
support dynamic scheduling of soft cells. support dynamic scheduling of soft cells.
</t> </t>
<t> <t>
Monitoring and relocation is done in the 6top layer. For the upper Monitoring and relocation is done in the 6top sublayer. For the uppe r
layer, the connection between two neighbor nodes appears as a number layer, the connection between two neighbor nodes appears as a number
of cells. of cells.
Depending on traffic requirements, the upper layer can request 6top Depending on traffic requirements, the upper layer can request 6top
to add or delete a number of cells scheduled to a particular to add or delete a number of cells scheduled to a particular
neighbor, without being responsible for choosing the exact neighbor, without being responsible for choosing the exact
slotOffset/channelOffset of those cells. slotOffset/channelOffset of those cells.
</t> </t>
</section> </section>
<section anchor='topint'><name>Remote Monitoring and Schedule Management</ <section anchor="topint"><name>Remote Monitoring and Schedule Management</
name> name>
<!--
<t>
The 6top interface document
<xref target="I-D.ietf-6tisch-6top-interface"/>
specifies the generic data model that can be used to monitor and man
age
resources of the 6top sublayer. Abstract methods are suggested for u
se
by a management entity in the device. The data model also enables
remote control operations on the 6top sublayer.
</t>
<t>
The capability to interact with the node 6top sublayer from multiple
hops away
can be leveraged for monitoring, scheduling, or a combination of the
reof.
The architecture supports variations on the deployment model, and
focuses on the flows rather than
whether there is a proxy or a translation operation en-route.
</t>
<t>
<xref target="I-D.ietf-6tisch-coap"/> defines an mapping of
the 6top set of commands, which is described in
<xref target="I-D.ietf-6tisch-6top-interface"/>, to CoAP resources.
This allows an entity to interact with the 6top layer of a node that
is multiple hops away in a RESTful fashion.
</t>
<!--t>
The work at the 6TiSCH WG is focused on non-deterministic traffic and
does not provide the generic data model that would be necessary to
monitor and manage resources of the 6top sublayer. It is recognized
that CoAP can be appropriate to interact with the 6top layer of a
node that is multiple hops away across a 6TiSCH mesh.
</t>
<t>
The entity issuing the CoAP requests can be a central scheduling ent
ity
(e.g., a PCE), a node multiple hops away with the authority to modif
y the TSCH
schedule (e.g., the head of a local cluster), or a external device m
onitoring the
overall state of the network (e.g., NME). It is also possible that a
mapping entity on the backbone transforms a non-CoAP protocol such
as PCEP into the RESTful interfaces that the 6TiSCH devices support.
</t-->
<t> <t>
Remote monitoring and Schedule Management refers to a DetNet/SDN model Remote Monitoring and Schedule Management refers to a DetNet/SDN model
whereby an NME and a scheduling entity, associated with a PCE, reside whereby an NME and a scheduling entity, associated with a PCE, reside
in a central controller and interact with the 6top layer to control in a central controller and interact with the 6top sublayer to control
IPv6 Links and Tracks (<xref target='ontrk'/>) in a 6TiSCH network. IPv6 links and Tracks (<xref target="ontrk"/>) in a 6TiSCH network.
The composite centralized controller can assign physical resources The composite centralized controller can assign physical resources
(e.g., buffers and hard cells) to a particular Track to optimize the (e.g., buffers and hard cells) to a particular Track to optimize the
reliability within a bounded latency for a well-specified flow. reliability within a bounded latency for a well-specified flow.
</t> </t>
<t> <t>
The work at the 6TiSCH WG focused on non-deterministic traffic and The work in the 6TiSCH Working Group focused on nondeterministic traffi
did not provide the generic data model that is necessary for the c and
did not provide the generic data model necessary for the
controller to monitor and manage resources of the 6top sublayer. controller to monitor and manage resources of the 6top sublayer.
This is deferred to future work, see <xref target='unchartered-tracks'/ >. This is deferred to future work, see <xref target="unchartered-tracks"/ >.
</t> </t>
<!-- for later -->
<t> <t>
With respect to Centralized routing and scheduling, it is envisioned With respect to centralized routing and scheduling, it is envisioned
that the related component of the 6TiSCH Architecture would be an that the related component of the 6TiSCH architecture would be an
extension of the extension of the <xref target="RFC8655">DetNet architecture</xref>,
<xref target='RFC8655'>DetNet Architecture</xref>, which studies Layer 3 aspects of Deterministic Networks and covers
which studies Layer-3 aspects of Deterministic Networks, and covers networks that span multiple Layer 2 domains.
networks that span multiple Layer-2 domains.
</t> </t>
<t> <t>
The DetNet architecture is a form of Software Defined Networking (SDN) The DetNet architecture is a form of Software-Defined Networking (SDN)
Architecture and is composed of three planes, a (User) Application architecture and is composed of three planes: a (User) Application
Plane, a Controller Plane (where the PCE operates), and a Network Plane Plane, a Controller Plane (where the PCE operates), and a Network Plane
,
which can represent a 6TiSCH LLN. which can represent a 6TiSCH LLN.
</t> </t>
<t> <t>
<xref target='RFC7426'>Software-Defined Networking (SDN): <xref target="RFC7426">"Software-Defined Networking (SDN):
Layers and Architecture Terminology</xref> proposes a generic Layers and Architecture Terminology"</xref> proposes a generic
representation of the SDN architecture that is reproduced in representation of the SDN architecture that is reproduced in
<xref target='RFC7426archi'/>. <xref target="RFC7426archi"/>.
</t> </t>
<figure align='center' anchor='RFC7426archi'><name>SDN Layers and Architecture <figure align="center" anchor="RFC7426archi"><name>SDN Layers and Architecture
Terminology per RFC 7426</name> Terminology per RFC 7426</name>
<artwork align='left'> <artwork align="left"><![CDATA[
<![CDATA[
o--------------------------------o o--------------------------------o
| | | |
| +-------------+ +----------+ | | +-------------+ +----------+ |
| | Application | | Service | | | | Application | | Service | |
| +-------------+ +----------+ | | +-------------+ +----------+ |
| Application Plane | | Application Plane |
o---------------Y----------------o o---------------Y----------------o
| |
*-----------------------------Y---------------------------------* *-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) | | Network Services Abstraction Layer (NSAL) |
skipping to change at line 2199 skipping to change at line 1889
| | | |
*------------Y---------------------------------Y----------------* *------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) | | Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------* *------------Y---------------------------------Y----------------*
| | | | | | | |
| o-------Y----------o +-----+ o--------Y----------o | | o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | | | | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o | | o------------------o +-----+ o-------------------o |
| Network Device | | Network Device |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The PCE establishes end-to-end Tracks of hard cells, which are describe d <t>The PCE establishes end-to-end Tracks of hard cells, which are describe d
in more details in <xref target='trkfwd'/>. in more detail in <xref target="trkfwd"/>.
</t> </t>
<t> <t>
The DetNet work is expected to enable end to end Deterministic Path The DetNet work is expected to enable end-to-end deterministic paths
across heterogeneous network. This can be for instance a 6TiSCH LLN across heterogeneous networks. This can be, for instance, a 6TiSCH LLN
and an Ethernet Backbone. and an Ethernet backbone.
</t> </t>
<t>This model fits the 6TiSCH extended configuration, whereby a <t>This model fits the 6TiSCH extended configuration, whereby a
6BBR federates 6BBR federates
multiple 6TiSCH LLN in a single subnet over a backbone that can be, multiple 6TiSCH LLNs in a single subnet over a backbone that can be,
for instance, Ethernet or Wi-Fi. In that model, for instance, Ethernet or Wi-Fi. In that model,
6TiSCH 6BBRs synchronize with one another over the backbone, so as 6TiSCH 6BBRs synchronize with one another over the backbone, so as
to ensure that the multiple LLNs that form the IPv6 subnet stay to ensure that the multiple LLNs that form the IPv6 subnet stay
tightly synchronized. tightly synchronized.
</t> </t>
<t> <t>
If the Backbone is Deterministic, then the If the backbone is deterministic, then the
Backbone Router ensures that the end-to-end deterministic 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.
It is the responsibility of the PCE to compute a It is the responsibility of the PCE to compute a
deterministic path and to end across the TSCH network and an IEEE Std. deterministic path end to end across the TSCH network and an IEEE Std 8
802.1 02.1
TSN Ethernet backbone, and that of DetNet to enable end-to-end determin TSN Ethernet backbone, and it is the responsibility of DetNet to enable
istic end-to-end deterministic
forwarding. forwarding.
</t> </t>
</section> </section>
<section><name>Hop-by-hop Scheduling</name> <section><name>Hop-by-Hop Scheduling</name>
<t> <t>
A node can reserve a <xref target='ontrk'>Track</xref> to one or more A node can reserve a <xref target="ontrk">Track</xref> to one or more
destination(s) that are multiple hops away by installing soft cells at each destination(s) that are multiple hops away by installing soft cells at each
intermediate node. intermediate node.
This forms a Track of soft cells. A Track Scheduling Function above the 6top This forms a Track of soft cells. A Track SF above the 6top
sublayer of each node on the Track is needed to monitor these soft cells and sublayer of each node on the Track is needed to monitor these soft cells and
trigger relocation when needed. trigger relocation when needed.
</t> </t>
<t> <t>
This hop-by-hop reservation mechanism is expected to be similar in essence This hop-by-hop reservation mechanism is expected to be similar in essence
to <xref target='RFC3209'/> and/or <xref target='RFC4080'/>/<xref target='RF C5974'/>. to <xref target="RFC3209"/> and/or <xref target="RFC4080"/> and <xref target ="RFC5974"/>.
The protocol for a node to trigger hop-by-hop scheduling is not yet defined. The protocol for a node to trigger hop-by-hop scheduling is not yet defined.
</t> </t>
</section> </section>
</section> </section>
<!--
<section anchor="topo" title="6TiSCH Device Capabilities">
<t>6TiSCH nodes are usually IoT devices, characterized by very limited amount <section anchor="ontrk"><name>On Tracks</name>
of memory, just enough buffers to store one or a few IPv6 packets, and
limited bandwidth between peers. It results that a node will maintain only a
small number of peering information, and will not be able to store many
packets waiting to be forwarded. Peers can be identified through MAC or IPv6
addresses, but a Cryptographically Generated Address <xref target="RFC3972"/>
(CGA) may also be used.
</t>
<t>
Neighbors can be discovered over the radio using mechanism such as beacons,
but, though the neighbor information is available in the 6TiSCH interface
data model, 6TiSCH does not describe a protocol to pro-actively push the
neighborhood information to a PCE.
This protocol should be described and should operate over CoAP. The protocol
should be able to carry multiple metrics, in particular the same metrics as
used for RPL operations <xref target="RFC6551"/>.
</t>
<t>
The energy that the device consumes in sleep, transmit and receive modes can
be evaluated and reported. So can the amount of energy that is stored in the
device and the power that it can be scavenged from the environment. The PCE
SHOULD be able to compute Tracks that will implement policies on how the
energy is consumed, for instance balance between nodes, ensure that the spent
energy does not exceeded the scavenged energy over a period of time, etc...
</t>
</section>
</section>
-->
<section anchor='ontrk'><name>On Tracks</name>
<t> <t>
The architecture introduces the concept of a Track, which is a directed path The architecture introduces the concept of a Track, which is a directed path
from a source 6TiSCH node to one or more destination 6TiSCH node(s) from a source 6TiSCH node to one or more destination 6TiSCH node(s)
across a 6TiSCH LLN. across a 6TiSCH LLN.
</t> </t>
<t> <t>
A Track is the 6TiSCH instantiation of the concept of a Deterministic Path A Track is the 6TiSCH instantiation of the concept of a deterministic path
as described in <xref target='RFC8655'/>. as described in <xref target="RFC8655"/>.
Constrained resources such as memory buffers are reserved for that Track in Constrained resources such as memory buffers are reserved for that Track in
intermediate 6TiSCH nodes to avoid loss related to limited capacity. intermediate 6TiSCH nodes to avoid loss related to limited capacity.
A 6TiSCH node along a Track not only knows which bundles of cells it should A 6TiSCH node along a Track not only knows which bundles of cells it should
use to receive packets from a previous hop, but also knows which bundle(s) use to receive packets from a previous hop but also knows which bundle(s)
it should use to send packets to its next hop along the Track. it should use to send packets to its next hop along the Track.
</t> </t>
<section><name>General Behavior of Tracks</name> <section><name>General Behavior of Tracks</name>
<t> <t>
A Track is associated with Layer-2 bundles of cells with related schedules A Track is associated with Layer 2 bundles of cells with related schedules
and logical relationships and that ensure that a packet that is injected in and logical relationships that ensure that a packet that is injected in
a Track will progress in due time all the way to destination. a Track will progress in due time all the way to destination.
</t> </t>
<t> <t>
Multiple cells may be scheduled in a Track for the transmission of a single Multiple cells may be scheduled in a Track for the transmission of a single
packet, in which case the normal operation of IEEE Std. 802.15.4 Automatic packet, in which case the normal operation of IEEE Std 802.15.4 Automatic
Repeat-reQuest (ARQ) can take place; the acknowledgment may be omitted in Repeat-reQuest (ARQ) can take place; the acknowledgment may be omitted in
some cases, for instance if there is no scheduled cell for a possible retry. some cases, for instance, if there is no scheduled cell for a possible retry .
</t> </t>
<t> <t>
There are several benefits for using a Track to forward a packet from a There are several benefits for using a Track to forward a packet from a
source node to the destination node. source node to the destination node:
</t> </t>
<ol spacing='normal'> <ol spacing="normal">
<li> <li>
Track forwarding, as further described in <xref target='trkfwd'/>, is a Track Forwarding, as further described in <xref target="trkfwd"/>, is a
Layer-2 forwarding scheme, which introduces less process delay and Layer 2 forwarding scheme, which introduces less process delay and
overhead than Layer-3 forwarding scheme. Therefore, LLN Devices can save overhead than a Layer 3 forwarding scheme. Therefore, LLN devices can sa
more energy and resource, which is critical for resource constrained devi ve
ces. more energy and resources, which is critical for resource-constrained dev
ices.
</li> </li>
<li> <li>
Since channel resources, i.e., bundles of cells, have been reserved for Since channel resources, i.e., bundles of cells, have been reserved for
communications between 6TiSCH nodes of each hop on the Track, the communications between 6TiSCH nodes of each hop on the Track, the
throughput and the maximum latency of the traffic along a Track are throughput and the maximum latency of the traffic along a Track are
guaranteed and the jitter is maintained small. guaranteed, and the jitter is minimized.
</li> </li>
<li> <li>
By knowing the scheduled time slots of incoming bundle(s) and outgoing By knowing the scheduled timeslots of incoming bundle(s) and outgoing
bundle(s), 6TiSCH nodes on a Track could save more energy by staying in bundle(s), 6TiSCH nodes on a Track could save more energy by staying in
sleep state during in-active slots. sleep state during inactive slots.
</li> </li>
<li> <li>
Tracks are protected from interfering with one another if a cell is sched Tracks are protected from interfering with one another if a cell is
uled to belong to at most one Track, and congestion loss is avoided if at most o scheduled to belong to at most one Track, and congestion loss is avoided
ne if at most one
packet can be presented to the MAC to use that cell. packet can be presented to the MAC to use that cell.
Tracks enhance the reliability of transmissions and thus further improve Tracks enhance the reliability of transmissions and thus further improve
the energy consumption in LLN Devices by reducing the chances of the energy consumption in LLN devices by reducing the chances of
retransmission. retransmission.
</li> </li>
</ol><t> </ol>
</t>
</section> </section>
<section><name>Serial Track</name> <section><name>Serial Track</name>
<t> <t>
A Serial (or simple) Track is the 6TiSCH version of a circuit; a bundle of A Serial (or simple) Track is the 6TiSCH version of a circuit: a bundle of
cells that are programmed to receive (RX-cells) is uniquely paired to a cells that are programmed to receive (RX-cells) is uniquely paired with a
bundle of cells that are set to transmit (TX-cells), representing a Layer-2 bundle of cells that are set to transmit (TX-cells), representing a Layer 2
forwarding state which can be used regardless of the network layer protocol. forwarding state that can be used regardless of the network-layer protocol.
A Serial Track is thus formed end-to-end as a succession of A Serial Track is thus formed end-to-end as a succession of
paired bundles, a receive bundle from the previous hop and a transmit bundle paired bundles: a receive bundle from the previous hop and a transmit bundle
to the next hop along the Track. to the next hop along the Track.
</t> </t>
<t> <t>
For a given iteration of the device schedule, the effective channel of the For a given iteration of the device schedule, the effective channel of the
cell is obtained by following in a loop a well-known hopping sequence that cell is obtained by looping through a well-known hopping sequence
started at Epoch time at the channelOffset of the cell, which results beginning at Epoch time and starting at the cell's channelOffset, which resu
in a rotation of the frequency that used for transmission. lts
in a rotation of the frequency that is used for transmission.
The bundles may be computed so as to accommodate both variable rates and The bundles may be computed so as to accommodate both variable rates and
retransmissions, so they might not be fully used in the iteration of the retransmissions, so they might not be fully used in the iteration of the
schedule. schedule.
</t> </t>
</section> </section>
<section><name>Complex Track with Replication and Elimination</name> <section><name>Complex Track with Replication and Elimination</name>
<t> <t>
The art of Deterministic Networks already include Packet Replication and The art of Deterministic Networks already includes packet replication and
Elimination techniques. Example elimination techniques. Example
standards include the Parallel Redundancy Protocol (PRP) and the standards include the Parallel Redundancy Protocol (PRP) and the
High-availability Seamless Redundancy (HSR) <xref target='IEC62439'/>. High-availability Seamless Redundancy (HSR) <xref target="IEC62439"/>.
Similarly, and as opposed to a Serial Track that is a sequence of nodes Similarly, and as opposed to a Serial Track that is a sequence of nodes
and links, a Complex Track is shaped as a directed acyclic graph towards one and links, a Complex Track is shaped as a directed acyclic graph towards one
or more destination(s) to support multi-path forwarding and route around or more destination(s) to support multipath forwarding and route around
failures. failures.
</t> </t>
<t> <t>
A Complex Track may branch off over non congruent branches for the purpose A Complex Track may branch off over noncongruent branches for the purpose
of multicasting, and/or redundancy, in which case it reconverges later down of multicasting and/or redundancy, in which case, it reconverges later down
the path. the path.
This enables the Packet Replication, Elimination and Ordering Functions (PRE This enables the Packet Replication, Elimination, and Ordering Functions (PR
OF) EOF)
defined by Detnet. Packet ARQ, Replication, Elimination and Overhearing (PAR defined by DetNet. Packet ARQ, Replication, Elimination, and Overhearing (PA
EO) REO)
adds radio-specific capabilities of Layer-2 ARQ and promiscuous listening to adds radio-specific capabilities of Layer 2 ARQ and promiscuous listening to
redundant transmissions to compensate for the lossiness of the medium and me et redundant transmissions to compensate for the lossiness of the medium and me et
industrial expectations of a Reliable and Available Wireless network. industrial expectations of a RAW network.
Combining PAREO and PREOF, a Track may extend beyond the 6TiSCH network in a Combining PAREO and PREOF, a Track may extend beyond the 6TiSCH network into
larger DetNet network. a larger DetNet network.
</t> </t>
<t> <t>
In the art of TSCH, a path does not necessarily support PRE but it is almost In the art of TSCH, a path does not necessarily support PRE, but it is almos
systematically multi-path. This means that a Track is scheduled so as to t
systematically multipath. This means that a Track is scheduled so as to
ensure that each hop has at least two forwarding solutions, and the ensure that each hop has at least two forwarding solutions, and the
forwarding decision is to try the preferred one and use the other in forwarding decision is to try the preferred one and use the other in
case of Layer-2 transmission failure as detected by ARQ. Similarly, case of Layer 2 transmission failure as detected by ARQ. Similarly,
at each 6TiSCH hop along the Track, the PCE may schedule more than one at each 6TiSCH hop along the Track, the PCE may schedule more than one
timeslot for a packet, so as to support Layer-2 retries (ARQ). It is also timeslot for a packet, so as to support Layer 2 retries (ARQ). It is also
possible that the field device only uses the second branch if sending over possible that the field device only uses the second branch if sending over
the first branch fails. the first branch fails.
</t> </t>
</section> </section>
<section><name>DetNet End-to-end Path</name> <section><name>DetNet End-to-End Path</name>
<t> <t>
Ultimately, DetNet should Ultimately, DetNet should
enable to extend a Track beyond the 6TiSCH LLN as illustrated in enable extending a Track beyond the 6TiSCH LLN as illustrated in
<xref target='elifig'/>. In that example, a Track that is laid out from a <xref target="elifig"/>. In that example, a Track is laid out from a
field device in a 6TiSCH network to an IoT gateway that is located on an field device in a 6TiSCH network to an IoT gateway that is located on an
802.1 Time-Sensitive Networking (TSN) backbone. 802.1 Time-Sensitive Networking (TSN) backbone.
A 6TiSCH-Aware DetNet Service Layer handles the Packet Replication, A 6TiSCH-aware DetNet service layer handles the Packet Replication,
Elimination, and Ordering Functions over the DODAG that forms a Track. Elimination, and Ordering Functions over the DODAG that forms a Track.
</t> </t>
<t> <t>
The Replication function in the 6TiSCH Node sends a copy of each packet over The Replication function in the 6TiSCH Node sends a copy of each packet over
two different branches, and the PCE schedules each hop of both branches so two different branches, and the PCE schedules each hop of both branches so
that the two copies arrive in due time at the gateway. In case of a loss on that the two copies arrive in due time at the gateway. In case of a loss on
one branch, hopefully the other copy of the packet still makes it in due one branch, hopefully the other copy of the packet still makes it in due
time. If two copies make it to the IoT gateway, the Elimination function time. If two copies make it to the IoT gateway, the Elimination function
in the gateway ignores the extra packet and presents only one copy to upper in the gateway ignores the extra packet and presents only one copy to upper
layers. layers.
</t> </t>
<figure align='center' anchor='elifig'><name>Example End-to-End DetNet Track</name> <figure align="center" anchor="elifig"><name>Example End-to-End DetNet Track</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-=-=-+ +-=-=-+
| IoT | | IoT |
| G/W | | G/W |
+-=-=-+ +-=-=-+
^ <=== Elimination ^ <=== Elimination
Track branch | | Track branch | |
+-=-=-=-+ +-=-=-=-=+ Subnet Backbone +-=-=-=-+ +-=-=-=-=+ Subnet backbone
| | | |
+-=|-=+ +-=|-=+ +-=|-=+ +-=|-=+
| | | Backbone | | | Backbone | | | Backbone | | | Backbone
o | | | router | | | router o | | | Router | | | Router
+-=/-=+ +-=|-=+ +-=/-=+ +-=|-=+
o / o o-=-o-=-=/ o o / o o-=-o-=-=/ o
o o-=-o-=/ o o o o o o o-=-o-=/ o o o o o
o \ / o o LLN o o \ / o o LLN o
o v <=== Replication o v <=== Replication
o o
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section><name>Cell Reuse</name> <section><name>Cell Reuse</name>
<t> <t>
The 6TiSCH architecture provides means to avoid waste of cells as The 6TiSCH architecture provides the means to avoid waste of cells as
well as overflows in the transmit bundle of a Track, as follows: well as overflows in the transmit bundle of a Track, as follows:
</t> </t>
<t> <t>
A TX-cell that is not needed for the current iteration may A TX-cell that is not needed for the current iteration may
be reused opportunistically on a per-hop basis for routed packets. be reused opportunistically on a per-hop basis for routed packets.
When all of the frame that were received for a given Track are When all of the frames that were received for a given Track are
effectively transmitted, any available TX-cell for that Track can be effectively transmitted, any available TX-cell for that Track can be
reused for upper layer traffic for which the next-hop router matches the reused for upper-layer traffic for which the next-hop router matches the
next hop along the Track. next hop along the Track.
In that case, the cell that is being used is effectively a TX-cell from In that case, the cell that is being used is effectively a TX-cell from
the Track, but the short address for the destination is that of the the Track, but the short address for the destination is that of the
next-hop router. next-hop router.
</t> </t>
<t> <t>
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 a
destination MAC address set to this node as opposed to the broadcast MAC destination MAC address set to this node, as opposed to the broadcast MA
address must be extracted from the Track and delivered to the upper laye C
r. address that must be extracted from the Track and delivered to the upper
layer.
Note that a frame with an unrecognized destination MAC address is droppe d Note that a frame with an unrecognized destination MAC address is droppe d
at the lower MAC layer and thus is not received at the 6top sublayer. at the lower MAC layer and thus is not received at the 6top sublayer.
</t> </t>
<t> <t>
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 instance if in the transmit bundle to accommodate the Track traffic, for instance, i f
more retransmissions are needed than provisioned. more retransmissions are needed than provisioned.
In that case, and if the frame transports an IPv6 packet, then it can be In 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 traffic placed for transmission in the bundle that is used for Layer 3 traffic
towards the next hop along the Track. towards the next hop along the Track.
The MAC address should be set to the next-hop MAC address to avoid The MAC address should be set to the next-hop MAC address to avoid
confusion. confusion.
</t> </t>
<t> <t>
It results in a frame that is received over a Layer-3 bundle may be in It results in a frame that is received over a Layer 3 bundle that may be
fact associated to a Track. In a classical IP link such as an Ethernet, in
fact associated with a Track. In a classical IP link such as an Ethernet
,
off-Track traffic is typically in excess over reservation to be routed off-Track traffic is typically in excess over reservation to be routed
along the non-reserved path based on its QoS setting. along the non-reserved path based on its QoS setting.
But with 6TiSCH, since the use of the Layer-3 bundle may be due to But with 6TiSCH, since the use of the Layer 3 bundle may be due to
transmission failures, it makes sense for the receiver to recognize a transmission failures, it makes sense for the receiver to recognize a
frame that should be re-Tracked, and to place it back on the appropriate frame that should be re-Tracked and to place it back on the appropriate
bundle if possible. bundle if possible.
<!--
A frame should be re-Tracked if the Per-Hop-Behavior group indicated in
the Differentiated Services Field of the IPv6 header is set to
Deterministic Forwarding, as discussed in <xref target="pmh"/ -->.
A frame is re-Tracked by scheduling it for transmission over the A frame is re-Tracked by scheduling it for transmission over the
transmit bundle associated to the Track, with the destination MAC transmit bundle associated with the Track, with the destination MAC
address set to broadcast. address set to broadcast.
</t> </t>
</section> </section>
</section> </section>
<section anchor='fwd'><name>Forwarding Models</name> <section anchor="fwd"><name>Forwarding Models</name>
<!-- TW: Forwarding models should be formalized in a standards-Track draft
? One should be MUST (IPv6?), the others SHOULD? -->
<t> <t>
By forwarding, this document means the per-packet operation that By forwarding, this document means the per-packet operation that
allows to deliver a packet to a next hop or an upper layer in this node allows delivery of a packet to a next hop or an upper layer in this nod
. e.
Forwarding is based on pre-existing state that was installed as a Forwarding is based on preexisting state that was installed as a
result of a routing computation <xref target='rtg'/>. result of a routing computation, see <xref target="rtg"/>.
6TiSCH supports three different forwarding model:(G-MPLS) Track 6TiSCH supports three different forwarding models: (GMPLS) Track
Forwarding, (classical) IPv6 Forwarding and (6LoWPAN) Fragment Forwardi Forwarding, (classical) IPv6 Forwarding, and (6LoWPAN) Fragment Forward
ng. ing.
</t> </t>
<section anchor='trkfwd'><name>Track Forwarding</name> <section anchor="trkfwd"><name>Track Forwarding</name>
<t> <t>
Forwarding along a Track can be seen as a Generalized Multi-protocol Forwarding along a Track can be seen as a Generalized Multiprotocol
Label Switching (G-MPLS) operation in that the information used to Label Switching (GMPLS) operation in that the information used to
switch a frame is not an explicit label, but rather related to other switch a frame is not an explicit label but is rather related to oth
er
properties of the way the packet was received, a particular cell in properties of the way the packet was received, a particular cell in
the case of 6TiSCH. the case of 6TiSCH.
As a result, as long as the TSCH MAC (and Layer-2 security) accepts As a result, as long as the TSCH MAC (and Layer 2 security) accepts
a frame, that frame can be switched regardless of the protocol, a frame, that frame can be switched regardless of the protocol,
whether this is an IPv6 packet, a 6LoWPAN fragment, or a frame from whether this is an IPv6 packet, a 6LoWPAN fragment, or a frame from
an alternate protocol such as WirelessHART or ISA100.11a. an alternate protocol such as WirelessHART or ISA100.11a.
</t> </t>
<t> <t>
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. address depending on MAC support.
This way, the MAC layer in the intermediate nodes accepts the This way, the MAC layer in the intermediate nodes accepts the
incoming frame and 6top switches it without incurring a change in incoming frame and 6top switches it without incurring a change in
the MAC header. the MAC header.
In the case of IEEE Std. 802.15.4, this means effectively In the case of IEEE Std 802.15.4, this means effectively to
broadcast, so that along the Track the short address for the broadcast, so that along the Track the short address for the
destination of the frame is set to 0xFFFF. destination of the frame is set to 0xFFFF.
</t> </t>
<t> <t>
There are 2 modes for a Track, an IPv6 native mode and There are two modes for a Track: an IPv6 native mode and a
a protocol-independant tunnel mode. protocol-independent tunnel mode.
</t> </t>
<section><name>Native Mode</name> <section><name>Native Mode</name>
<t> <t>
In native mode, the Protocol Data Unit (PDU) is associated In native mode, the Protocol Data Unit (PDU) is associated
with flow-dependent meta-data that refers uniquely to the Track, with flow-dependent metadata that refers uniquely to the Track,
so the 6top sublayer can place the frame in the appropriate cell so the 6top sublayer can place the frame in the appropriate cell
without ambiguity. In the case of IPv6 traffic, this flow without ambiguity. In the case of IPv6 traffic, this flow
identification may be done using a 6-tuple as discussed in may be identified using a 6-tuple as discussed in
<xref target='I-D.ietf-detnet-ip'/>. In particular, <xref target="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.</t>
</t>
<t>
The flow follows a Track which identification is done using
a RPL Instance (see section 3.1.3 of <xref target='RFC6550'/>),
signaled in a RPL Packet Information (more in section 11.2.2.1 of
<xref target='RFC6550'/>) and the destination address in the case
of a local instance. One or more flows may be placed in a same
Track and the Track identification (TrackID + owner) may be place
d
in an
IP-in-IP encapsulation. The forwarding operation is based on the
Track and does not depend on the flow therein.
</t> <t>
<t> The flow follows a Track that is identified using a RPL
The Track identification is validated at egress before restoring Instance (see <xref target="RFC6550" section="3.1.3" sectionFormat="of" forma
the destination MAC address (DMAC) and punting to the upper layer t="default"/>),
. signaled in a RPL Packet Information (more in
</t> <xref target="RFC6550" section="11.2.2.1" sectionFormat="of" format="default"
<t><xref target='fig6t'/> illustrates the Track Forwarding operation />)
which happens at the 6top sublayer, below IP. and the source address of a packet going down the DODAG formed by a local ins
tance. One or more
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 forward
ing
operation is based on the Track and does not depend on the flow
therein.
</t>
<t>
The Track identification is validated at egress before restoring the
destination MAC address (DMAC) and punting to the upper layer.
</t>
<t><xref target="fig6t"/> illustrates the Track Forwarding operation
that happens at the 6top sublayer, below IP.
</t> </t>
<figure anchor='fig6t'><name>Track Forwarding, Native Mode</name> <figure anchor="fig6t"><name>Track Forwarding, Native Mode</name>
<artwork><![CDATA[ <artwork><![CDATA[
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | | | IPv6 | | |
+--------------+ | | +--------------+ | |
| 6LoWPAN HC | | | | 6LoWPAN HC | | |
+--------------+ ingress egress +--------------+ ingress egress
| 6top | sets +----+ +----+ restores | 6top | sets +----+ +----+ restores
+--------------+ DMAC to | | | | DMAC to +--------------+ DMAC to | | | | DMAC to
| TSCH MAC | brdcst | | | | dest | TSCH MAC | brdcst | | | | dest
skipping to change at line 2588 skipping to change at line 2241
| 6LoWPAN HC | | | | 6LoWPAN HC | | |
+--------------+ ingress egress +--------------+ ingress egress
| 6top | sets +----+ +----+ restores | 6top | sets +----+ +----+ restores
+--------------+ DMAC to | | | | DMAC to +--------------+ DMAC to | | | | DMAC to
| TSCH MAC | brdcst | | | | dest | TSCH MAC | brdcst | | | | dest
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Ingress Relay Relay Egress Ingress Relay Relay Egress
Stack Layer Node Node Node Node Stack Layer Node Node Node Node
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section><name>Tunnel Mode</name> <section><name>Tunnel Mode</name>
<t> <t>
In tunnel mode, the frames originate from an arbitrary protocol o ver a compatible MAC In tunnel mode, the frames originate from an arbitrary protocol o ver a compatible MAC
that may or may not be synchronized with the 6TiSCH network. An e xample of that may or may not be synchronized with the 6TiSCH network. An e xample of
this would be a router with a dual radio that is capable of recei ving and sending WirelessHART this would be a router with a dual radio that is capable of recei ving and sending WirelessHART
or ISA100.11a frames with the second radio, by presenting itself or ISA100.11a frames with the second radio by presenting itself a
as an access s an access
Point or a Backbone Router, respectively. point or a Backbone Router, respectively.
In that mode, some entity (e.g., PCE) can coordinate with a In that mode, some entity (e.g., PCE) can coordinate with a
WirelessHART Network Manager or an ISA100.11a System Manager to WirelessHART Network Manager or an ISA100.11a System Manager to
specify the flows that are transported. specify the flows that are transported.
</t> </t>
<figure anchor='fig6'><name>Track Forwarding, Tunnel Mode</name> <figure anchor="fig6"><name>Track Forwarding, Tunnel Mode</name>
<artwork><![CDATA[ <artwork><![CDATA[
+--------------+ +--------------+
| IPv6 | | IPv6 |
+--------------+ +--------------+
| 6LoWPAN HC | | 6LoWPAN HC |
+--------------+ set restore +--------------+ set restore
| 6top | +DMAC+ +DMAC+ | 6top | +DMAC+ +DMAC+
+--------------+ to|brdcst to|nexthop +--------------+ to|brdcst to|nexthop
| TSCH MAC | | | | | | TSCH MAC | | | | |
+--------------+ | | | | +--------------+ | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
skipping to change at line 2627 skipping to change at line 2278
| | | |
+--------------+ | | +--------------+ | |
| LLN PHY | | | | LLN PHY | | |
+--------------+ | Packet flowing across the network | +--------------+ | Packet flowing across the network |
| TSCH MAC | | | | TSCH MAC | | |
+--------------+ | DMAC = | DMAC = +--------------+ | DMAC = | DMAC =
|ISA100/WiHART | | nexthop v nexthop |ISA100/WiHART | | nexthop v nexthop
+--------------+ +--------------+
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Node Node Node Stack Layer Node Node Node Node
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In that case, the TrackID that identifies the Track at In that case, the TrackID that identifies the Track at
the ingress 6TiSCH router is derived from the RX-cell. The DMAC the ingress 6TiSCH router is derived from the RX-cell.
is set to this node but the TrackID indicates that the The DMAC
frame must be tunneled over a particular Track so the frame is is set to this node, but the TrackID indicates that the
frame must be tunneled over a particular Track, so the frame is
not passed to the upper layer. Instead, the DMAC is forced to not passed to the upper layer. Instead, the DMAC is forced to
broadcast and the frame is passed to the 6top sublayer for broadcast, and the frame is passed to the 6top sublayer for
switching. switching.
</t> </t>
<t> <t>
At the egress 6TiSCH router, the reverse operation occurs. Based At the egress 6TiSCH router, the reverse operation occurs. Based
on tunneling information of the Track, which may for instance on tunneling information of the Track, which may for instance
indicate that the tunneled datagram is an IP packet, indicate that the tunneled datagram is an IP packet,
the datagram is passed to the appropriate Link-Layer with the the datagram is passed to the appropriate link-layer with the
destination MAC restored. destination MAC restored.
</t> </t>
</section> </section>
<section><name>Tunneling Information</name> <section><name>Tunneling Information</name>
<t> <t>
Tunneling information coming with the Track configuration Tunneling information coming with the Track configuration
provides the destination MAC address provides the destination MAC address
of the egress endpoint as well as the tunnel mode and specific of the egress endpoint as well as the tunnel mode and specific
data depending on the mode, data depending on the mode,
for instance a service access point for frame delivery at egress. for instance, a service access point for frame delivery at egress .
</t> </t>
<t> <t>
If the tunnel egress point does not have a MAC address that If the tunnel egress point does not have a MAC address that
matches the configuration, the Track installation fails. matches the configuration, the Track installation fails.
</t> </t>
<t> <t>
If the Layer-3 destination address belongs to If the Layer 3 destination address belongs to
the tunnel termination, then it is possible that the IPv6 address the tunnel termination, then it is possible that the IPv6 address
of the destination is compressed at the 6LoWPAN sublayer based on of the destination is compressed at the 6LoWPAN sublayer based on
the MAC address. Restoring the wrong MAC address at the egress the MAC address. Restoring the wrong MAC address at the egress
would then also result in the wrong IP address in the packet would then also result in the wrong IP address in the packet
after decompression. after decompression.
For that reason, a packet can be injected in a Track only if For that reason, a packet can be injected in a Track only if
the destination MAC address is effectively that of the tunnel the destination MAC address is effectively that of the tunnel
egress point. egress point.
It is thus mandatory for the ingress router to validate that the It is thus mandatory for the ingress router to validate that the
MAC address that was used at the 6LoWPAN MAC address used at the 6LoWPAN
sublayer for compression matches that of the tunnel egress point sublayer for compression matches that of the tunnel egress point
before it overwrites it to broadcast. before it overwrites it to broadcast.
The 6top sublayer at the tunnel egress point reverts that The 6top sublayer at the tunnel egress point reverts that
operation to the MAC address obtained from the tunnel operation to the MAC address obtained from the tunnel
information. information.
</t> </t>
</section> </section>
</section> <section><name>IPv6 Forwarding</name> </section> <section><name>IPv6 Forwarding</name>
<t> <t>
As the packets are routed at Layer-3, traditional QoS and Active As the packets are routed at Layer 3, traditional QoS and Active
Queue Management (AQM) operations are expected to prioritize flows. Queue Management (AQM) operations are expected to prioritize flows.
<!-- the application of Differentiated Services is further discussed
in -->
<!-- <xref target="I-D.svshah-tsvwg-lln-diffserv-recommendations"/>.
-->
</t> </t>
<figure anchor='fig9'><name>IP Forwarding</name> <figure anchor="fig9"><name>IP Forwarding</name>
<artwork><![CDATA[ <artwork><![CDATA[
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | +-QoS+ +-QoS+ | | IPv6 | | +-QoS+ +-QoS+ |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6LoWPAN HC | | | | | | | | 6LoWPAN HC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
skipping to change at line 2704 skipping to change at line 2352
| 6LoWPAN HC | | | | | | | | 6LoWPAN HC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Router Router Node Stack Layer Node Router Router Node
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section><name>Fragment Forwarding</name> <section><name>Fragment Forwarding</name>
<t> <t>
Considering that per section 4 of <xref target='RFC4944'/> 6LoWPAN Considering that, per <xref target="RFC4944" section="4" sectionForm
packets can be as large as 1280 bytes (the IPv6 minimum MTU), at="of" format="default"/>, 6LoWPAN
and that the non-storing mode of RPL implies Source Routing that req packets can be as large as 1280 bytes (the IPv6 minimum MTU)
uires space for routing and that the non-storing mode of RPL implies source routing, which r
headers, and that a IEEE Std. 802.15.4 frame with security may carry equires space for routing
in the order of 80 bytes of 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 packet might be fragmented into more than 16 fragments at the effective payload, an IPv6 packet might be fragmented into more than 16 fragments at the
6LoWPAN sublayer. 6LoWPAN sublayer.
</t> </t>
<t> <t>
This level of fragmentation is much higher than that traditionally e xperienced over the Internet This level of fragmentation is much higher than that traditionally e xperienced over the Internet
with IPv4 fragments, where fragmentation is already known as harmful . with IPv4 fragments, where fragmentation is already known as harmful .
</t> </t>
<t> <t>
In the case to a multihop route within a 6TiSCH network, Hop-by-Hop recomposition occurs at each 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. This creates additional laten cy and forces intermediate hop to reform the packet and route it. This creates additional laten cy and forces intermediate
nodes to store a portion of a packet for an undetermined time, thus impacting critical resources such nodes to store a portion of a packet for an undetermined time, thus impacting critical resources such
as memory and battery. as memory and battery.
</t> </t>
<t> <t>
<xref target='I-D.ietf-6lo-minimal-fragment'/> describes a framework <xref target="RFC8930"/> describes a framework for forwarding fragme
for forwarding fragments end-to-end across a 6TiSCH route-over mesh. nts end-to-end
Within that framework, <xref target='I-D.ietf-lwig-6lowpan-virtual-r across a 6TiSCH route-over mesh. Within that framework,
eassembly'/> details a virtual reassembly buffer mechanism whereby the datagram <xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly"/> details a
tag in the 6LoWPAN Fragment is used as a label for switching at the 6LoWPAN subl virtual reassembly
ayer. buffer mechanism whereby the datagram tag in the 6LoWPAN fragment is
used as a label
for switching at the 6LoWPAN sublayer.
</t> </t>
<t> <t>
Building on this technique, <xref target='I-D.ietf-6lo-fragment-reco Building on this technique, <xref target="RFC8931"/> introduces a ne
very'/> introduces a new format for 6LoWPAN fragments that enables the selective w format for
recovery of individual fragments, and allows for a degree of flow control based 6LoWPAN fragments that enables the selective recovery of individual
on an Explicit Congestion Notification. fragments
and allows for a degree of flow control based on an Explicit Congest
ion Notification (ECN).
</t> </t>
<figure anchor='fig7'><name>Forwarding First Fragment</name> <figure anchor="fig7"><name>Forwarding First Fragment</name>
<artwork><![CDATA[ <artwork><![CDATA[
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | +----+ +----+ | | IPv6 | | +----+ +----+ |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6LoWPAN HC | | learn learn | | 6LoWPAN HC | | learn learn |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
skipping to change at line 2750 skipping to change at line 2402
| 6LoWPAN HC | | learn learn | | 6LoWPAN HC | | learn learn |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Router Router Node Stack Layer Node Router Router Node
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In that model, the first fragment is routed based on the IPv6 header that is present in that fragment. In that model, the first fragment is 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 6LoWPAN sublayer learns the next-hop selection, generates a new datagram tag for transmission to
the next hop, and stores that information indexed by the incoming MA C address and datagram tag. The next the next hop, and stores that information indexed by the incoming MA C address and datagram tag. The next
fragments are then switched based on that stored state. fragments are then switched based on that stored state.
</t> </t>
<figure anchor='fig8'><name>Forwarding Next Fragment</name> <figure anchor="fig8"><name>Forwarding Next Fragment</name>
<artwork><![CDATA[ <artwork><![CDATA[
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | | | IPv6 | | |
+--------------+ | | +--------------+ | |
| 6LoWPAN HC | | replay replay | | 6LoWPAN HC | | replay replay |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
skipping to change at line 2787 skipping to change at line 2437
</figure> </figure>
<t> <t>
A bitmap and an ECN echo in the end-to-end acknowledgment enable the source to resend the missing A bitmap and an ECN echo in the end-to-end acknowledgment enable the source to resend the missing
fragments selectively. The first fragment may be resent to carve a n ew path in case of a path failure. fragments selectively. The first fragment may be resent to carve a n ew path in case of a path failure.
The ECN echo set indicates that the number of outstanding fragments should be reduced. The ECN echo set indicates that the number of outstanding fragments should be reduced.
</t> </t>
</section> </section>
</section> </section>
<section anchor='rtg'><name>Advanced 6TiSCH Routing</name> <section anchor="rtg"><name>Advanced 6TiSCH Routing</name>
<section anchor='pmh'><name>Packet Marking and Handling</name> <section anchor="pmh"><name>Packet Marking and Handling</name>
<t> <t>
All packets inside a 6TiSCH domain must carry the RPLInstanceID that 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 identifies the 6TiSCH topology (e.g., a Track) that is to be used for
routing and forwarding that packet. The location of that information routing and forwarding that packet. The location of that information
must be the same for all packets forwarded inside the domain. must be the same for all packets forwarded inside the domain.
</t> </t>
<t> <t>
For packets that are routed by a PCE along a Track, the tuple formed by 1) For packets that are routed by a PCE along a Track, the tuple formed
(typically) the IPv6 source or (possibly) destination address in the IPv6 by 1) (typically) the IPv6 source or (possibly) destination address
Header and 2) a local RPLInstanceID in the RPI that serves as TrackID, in the IPv6 header and 2) a local RPLInstanceID in the RPI that
identify uniquely the Track and associated transmit bundle. serves as TrackID, identify uniquely the Track and
associated transmit bundle.
</t> </t>
<t> <t>
For packets that are routed by RPL, that information is the RPLInstanceID For packets that are routed by RPL, that information is the RPLInstanceID
which is carried in the RPL Packet Information (RPI), as discussed in that is carried in the RPL Packet Information (RPI), as discussed in
section 11.2 of <xref target='RFC6550'/>, "Loop Avoidance and Detection". <xref target="RFC6550" section="11.2" sectionFormat="of" format="default"/>,
The RPI is transported by a RPL option in the IPv6 Hop-By-Hop Header "Loop Avoidance and Detection".
<xref target='RFC6553'/>. The RPI is transported by a RPL Option in the IPv6 Hop-By-Hop Options header
<xref target="RFC6553"/>.
</t> </t>
<t> <t>
A compression mechanism for the RPL packet artifacts that integrates the A compression mechanism for the RPL packet artifacts that integrates the
compression of IP-in-IP encapsulation and the Routing Header type 3 compression of IP-in-IP encapsulation and the Routing Header type 3
<xref target='RFC6554'/> <xref target="RFC6554"/>
with that of the RPI in a 6LoWPAN dispatch/header type is specified in with that of the RPI in a 6LoWPAN dispatch/header type is specified in
<xref target='RFC8025'/> and <xref target='RFC8138'/>. <xref target="RFC8025"/> and <xref target="RFC8138"/>.
</t>
<t>
<!--In a 6TiSCH network, the routing dispatch is the recommended encoding the
RPL Packet Information.-->
</t> </t>
<t> <t>
Either way, the method and format used for encoding the RPLInstanceID Either way, the method and format used for encoding the RPLInstanceID
is generalized to all 6TiSCH topological Instances, which include is generalized to all 6TiSCH topological Instances, which include
both RPL Instances and Tracks. both RPL Instances and Tracks.
</t> </t>
</section> </section>
<section anchor='pmhrre'><name>Replication, Retries and Elimination</name> <section anchor="pmhrre"><name>Replication, Retries, and Elimination</name>
<t> <t>
6TiSCH supports the PREOF operations of elimination and reordering of packets 6TiSCH supports the PREOF operations of elimination and reordering of packets
along a complex Track, but has no requirement about whether a sequence number along a complex Track, but has no requirement about tagging a sequence number
is tagged in the packet for that purpose. in the packet for that purpose.
With 6TiSCH, the schedule can tell when multiple receive timeslots correspond With 6TiSCH, the schedule can tell when multiple receive timeslots correspond
to copies of a same packet, in which case the receiver may avoid listening to to copies of a same packet, in which case the receiver may avoid listening to
the extra copies once it had received one instance of the packet. the extra copies once it has received one instance of the packet.
</t> </t>
<t> <t>
The semantics of the configuration will enable correlated timeslots to be The semantics of the configuration enable correlated timeslots to be
grouped for transmit (and respectively receive) with a 'OR' relations, grouped for transmit (and receive, respectively) with 'OR' relations,
and then a 'AND' relation would be configurable between groups. and then an 'AND' relation can be configurable between groups.
The semantics is that if the transmit (and respectively receive) operation The semantics are such that if the transmit (and receive, respectively) opera
succeeded in one timeslot in a 'OR' group, then all the other timeslots in tion
succeeded in one timeslot in an 'OR' group, then all the other timeslots in
the group are ignored. the group are ignored.
Now, if there are at least two groups, the 'AND' relation between the groups Now, if there are at least two groups, the 'AND' relation between the groups
indicates that one operation must succeed in each of the groups. indicates that one operation must succeed in each of the groups.
</t> </t>
<t> <t>
On the transmit side, timeslots provisioned for retries along a same branch On the transmit side, timeslots provisioned for retries along a same branch
of a Track are placed a same 'OR' group. The 'OR' relation indicates that if of a Track are placed in the same 'OR' group. The 'OR' relation indicates tha t if
a transmission is acknowledged, then retransmissions of that packet should a transmission is acknowledged, then retransmissions of that packet should
not be attempted for remaining timeslots in that group. There are as many not be attempted for the remaining timeslots in that group. There are as many
'OR' groups as there are branches of the Track departing from this node. 'OR' groups as there are branches of the Track departing from this node.
Different 'OR' groups are programmed for the purpose of replication, each Different 'OR' groups are programmed for the purpose of replication, each
group corresponding to one branch of the Track. The 'AND' relation between th e group corresponding to one branch of the Track. The 'AND' relation between th e
groups indicates that transmission over any of branches must be attempted groups indicates that transmission over any of branches must be attempted
regardless of whether a transmission succeeded in another branch. It is also regardless of whether a transmission succeeded in another branch. It is also
possible to place cells to different next-hop routers in a same 'OR' group. possible to place cells to different next-hop routers in the same 'OR' group.
This allows to route along multi-path Tracks, trying one next-hop and then This allows routing along multipath Tracks, trying one next hop and then
another only if sending to the first fails. another only if sending to the first fails.
</t> </t>
<t> <t>
On the receive side, all timeslots are programmed in a same 'OR' group. On the receive side, all timeslots are programmed in the same 'OR' group.
Retries of a same copy as well as converging branches for elimination Retries of the same copy as well as converging branches for elimination
are converged, meaning that the first successful reception is enough and that are converged, meaning that the first successful reception is enough and that
all the other timeslots can be ignored. A 'AND' group denotes different all the other timeslots can be ignored. An 'AND' group denotes different
packets that must all be received and transmitted over the associated packets that must all be received and transmitted over the associated
transmit groups within their respected 'AND' or 'OR' rules. transmit groups within their respected 'AND' or 'OR' rules.
</t> </t>
<t> <t>
As an example say that we have a simple network as represented in As an example, say that we have a simple network as represented in
<xref target='figANDORref'/>, and we want to enable PREOF between an ingress <xref target="figANDORref"/>, and we want to enable PREOF between an ingress
node I and an egress node E. node I and an egress node E.
</t> </t>
<figure align='center' anchor='figANDORref'><name>Scheduling PREOF on a Simpl <figure align="center" anchor="figANDORref"><name>Scheduling PREOF on a Simpl
e Network</name> e Network</name>
<artwork align='center'><![CDATA[ <artwork align="center"><![CDATA[
+-+ +-+ +-+ +-+
-- |A| ------ |C| -- -- |A| ------ |C| --
/ +-+ +-+ \ / +-+ +-+ \
/ \ / \
+-+ +-+ +-+ +-+
|I| |E| |I| |E|
+-+ +-+ +-+ +-+
\ / \ /
\ +-+ +-+ / \ +-+ +-+ /
-- |B| ------- |D| -- -- |B| ------- |D| --
+-+ +-+ +-+ +-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The assumption for this particular problem is The assumption for this particular problem is
that a 6TiSCH node has a single radio, so it cannot perform 2 receive and/or that a 6TiSCH node has a single radio, so it cannot perform two receive and/o
transmit operations at the same time, even on 2 different channels. r
transmit operations at the same time, even on two different channels.
</t> </t>
<t> <t>
Say we have 6 possible channels, and at least 10 timeslots per slotframe. Say we have six possible channels, and at least ten timeslots per slotframe.
<xref target='figsc'/> shows a possible schedule whereby each transmission <xref target="figsc"/> shows a possible schedule whereby each transmission
is retried 2 or 3 times, and redundant copies are forwarded in parallel via is retried two or three times, and redundant copies are forwarded in parallel
via
A and C on the one hand, and B and D on the other, providing time diversity, A and C on the one hand, and B and D on the other, providing time diversity,
spatial diversity though different physical paths, and frequency diversity. spatial diversity though different physical paths, and frequency diversity.
</t> </t>
<figure anchor='figsc'><name>Example Global Schedule</name> <figure anchor="figsc"><name>Example Global Schedule</name>
<artwork align='center'> <artwork align="center"><![CDATA[
<![CDATA[
slotOffset 0 1 2 3 4 5 6 7 9 slotOffset 0 1 2 3 4 5 6 7 9
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 0 | | | | | | |B->D| | | ... channelOffset 0 | | | | | | |B->D| | | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 1 | |I->A| |A->C|B->D| | | | | ... channelOffset 1 | |I->A| |A->C|B->D| | | | | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 2 |I->A| | |I->B| |C->E| |D->E| | ... channelOffset 2 |I->A| | |I->B| |C->E| |D->E| | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 3 | | | | |A->C| | | | | ... channelOffset 3 | | | | |A->C| | | | | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 4 | | |I->B| | |B->D| | |D->E| ... channelOffset 4 | | |I->B| | |B->D| | |D->E| ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 5 | | |A->C| | | |C->E| | | ... channelOffset 5 | | |A->C| | | |C->E| | | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
This translates in a different slotframe for every node that provides the This translates into a different slotframe that provides the
waking and sleeping times, and the channelOffset to be used when awake. waking and sleeping times for every node, and the channelOffset to be used wh
<xref target='figsfA'/> shows the corresponding slotframe for node A. en awake.
<xref target="figsfA"/> shows the corresponding slotframe for node A.
</t> </t>
<figure anchor='figsfA'><name>Example Slotframe for Node A</name> <figure anchor="figsfA"><name>Example Slotframe for Node A</name>
<artwork align='center'> <artwork align="center"><![CDATA[
<![CDATA[
slotOffset 0 1 2 3 4 5 6 7 9 slotOffset 0 1 2 3 4 5 6 7 9
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ... operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ... channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
<!-- If, say, node A successfully transmits at slotOffset 2 then it may sleep
at
slotOffsets 3 and 4. -->
The logical relationship between the timeslots is given The logical relationship between the timeslots is given
by the following table: by <xref target="figslog"/>:
</t> </t>
<table anchor="figslog">
<figure anchor='figslog' suppress-title='true'> <thead>
<artwork align='center'> <tr>
<![CDATA[ <th align="center">Node</th>
+------+---------------------+------------------------+ <th align="center">rcv slotOffset</th>
| Node | rcv slotOffset | xmit slotOffset | <th align="center">xmit slotOffset</th>
+------+---------------------+------------------------+ </tr>
| I | N/A | (0 OR 1) AND (2 OR 3) | </thead>
| A | (0 OR 1) | (2 OR 3 OR 4) | <tbody>
| B | (2 OR 3) | (4 OR 5 OR 6) | <tr>
| C | (2 OR 3 OR 4) | (5 OR 6) | <td align="center">I</td>
| D | (4 OR 5 OR 6) | (7 OR 8) | <td align="center">N/A</td>
| E | (5 OR 6 OR 7 OR 8) | N/A | <td align="center">(0 OR 1) AND (2 OR 3)</td>
+------+---------------------+------------------------+ </tr>
]]> <tr>
</artwork> <td align="center">A</td>
</figure> <td align="center">(0 OR 1)</td>
<td align="center">(2 OR 3 OR 4)</td>
<!-- </tr>
<texttable title="schedule" anchor="schedtable"> <tr>
<ttcol>Node</ttcol> <td align="center">B</td>
<ttcol align="center"> rcv slotOffset</ttcol> <td align="center">(2 OR 3)</td>
<ttcol align="center"> xmit slotOffset</ttcol> <td align="center">(4 OR 5 OR 6)</td>
<c>I</c> </tr>
<c> N/A </c> <tr>
<c> (0 OR 1) AND (2 OR 3) </c> <td align="center">C</td>
<c>A</c> <td align="center">(2 OR 3 OR 4)</td>
<c> (0 OR 1)</c> <td align="center">(5 OR 6)</td>
<c> (2 OR 3 OR 4) </c> </tr>
<c>B</c> <tr>
<c> (2 OR 3) </c> <td align="center">D</td>
<c> (4 OR 5 OR 6) </c> <td align="center">(4 OR 5 OR 6)</td>
<c>C</c> <td align="center">(7 OR 8)</td>
<c> (2 OR 3 OR 4)</c> </tr>
<c> (5 OR 6) </c> <tr>
<c>D</c> <td align="center">E</td>
<c> (4 OR 5 OR 6) </c> <td align="center">(5 OR 6 OR 7 OR 8)</td>
<c> (7 OR 8) </c> <td align="center">N/A</td>
<c>E</c> </tr>
<c> (5 OR 6 OR 7 OR 8) </c> </tbody>
<c> N/A </c> </table>
</texttable> </section>
-->
</section>
<!-- <section anchor="pmhds" title="Differentiated Services Per-Hop-Behavior"
> -->
<!-- <t> -->
<!-- A future document could define a PHB for Deterministic Flows, to be indi
cated -->
<!-- in the IANA registry where IETF-defined PHBs are listed. -->
<!-- </t> -->
<!-- </section> -->
</section> </section>
</section> </section>
<section><name>IANA Considerations</name> <section><name>IANA Considerations</name>
<t> <t>
This document does not require IANA action. This document has no IANA actions.
</t> </t>
</section> </section>
<section anchor='sec'><name>Security Considerations</name> <section anchor="sec"><name>Security Considerations</name>
<t> <t>
The <xref target='I-D.ietf-6tisch-minimal-security'>"Minimal Security The <xref target="RFC9031">"Minimal Security
Framework for 6TiSCH"</xref> was optimized for Low-Power and TSCH operations. Framework for 6TiSCH"</xref> was optimized for Low-Power and TSCH operations.
The reader is encouraged to review the Security Considerations section of The reader is encouraged to review the Security Considerations section of
that document, which discusses 6TiSCH security issues in more details. that document (Section <xref target="RFC9031" sectionFormat="bare" section="9
"/>),
which discusses 6TiSCH security issues in more details.
</t> </t>
<section anchor='det'><name>Availability of Remote Services</name> <section anchor="det"><name>Availability of Remote Services</name>
<t> <t>
The operation of 6TiSCH Tracks inherits its high level operation from DetNet The operation of 6TiSCH Tracks inherits its high-level operation from DetNet
and is subject to the observations in section 5 of and is subject to the observations in
<xref target='RFC8655'/>. The installation and the <xref target="RFC8655" section="5" sectionFormat="of" format="default"/>. T
maintenance of the 6TiSCH Tracks depends on the availability of a controller he installation and the
maintenance of the 6TiSCH Tracks depend on the availability of a controller
with a PCE to compute and push them in the network. When that connectivity with a PCE to compute and push them in the network. When that connectivity
is lost, existing Tracks may continue to operate until the end of their is lost, existing Tracks may continue to operate until the end of their
lifetime, but cannot be removed or updated, and new Tracks cannot be lifetime, but cannot be removed or updated, and new Tracks cannot be
installed. installed.
</t> </t>
<t> <t>
In a LLN, the communication with a remote PCE may be slow and unreactive to In an LLN, the communication with a remote PCE may be slow and unreactive to
rapid changes in the condition of the wireless communication. An attacker rapid changes in the condition of the wireless communication. An attacker
may introduce extra delay by selectively jamming some packets or some flows. may introduce extra delay by selectively jamming some packets or some flows.
The expectation is that the 6TiSCH Tracks enable enough redundancy to The expectation is that the 6TiSCH Tracks enable enough redundancy to
maintain the critical traffic in operation while new routes are calculated maintain the critical traffic in operation while new routes are calculated
and programmed into the network. and programmed into the network.
</t> </t>
<t> <t>
As with DetNet in general, the communication with the PCE must be secured As with DetNet in general, the communication with the PCE must be secured
and should be protected against DoS attacks, including delay injection and and should be protected against DoS attacks, including delay injection and
blackholing attacks, and secured as discussed in the security considerations blackholing attacks, and secured as discussed in the security considerations
defined for Abstraction and Control of Traffic Engineered Networks (ACTN) in defined for Abstraction and Control of Traffic Engineered Networks (ACTN) in
Section 9 of <xref target='RFC8453'/>, which applies equally to DetNet and <xref target="RFC8453" section="9" sectionFormat="of" format="default"/>, wh ich applies equally to DetNet and
6TiSCH. In a similar manner, the communication with the JRC must 6TiSCH. In a similar manner, the communication with the JRC must
be secured and should be protected against DoS attacks when possible. be secured and should be protected against DoS attacks when possible.
</t> </t>
</section> </section>
<section anchor='phy'><name>Selective Jamming</name> <section anchor="phy"><name>Selective Jamming</name>
<t> <t>
The Hopping Sequence of a TSCH network is well-known, meaning that if a The hopping sequence of a TSCH network is well known, meaning that if a
rogue manages to identify a cell of a particular flow, then it may rogue manages to identify a cell of a particular flow, then it may
to selectively jam that cell, without impacting any other traffic. selectively jam that cell without impacting any other traffic.
This attack can be performed at the PHY layer without any knowledge of the This attack can be performed at the PHY layer without any knowledge of the
Layer-2 keys, and is very hard to detect and diagnose because only one flow Layer 2 keys, and it is very hard to detect and diagnose because only one fl ow
is impacted. is impacted.
</t> </t>
<t> <t>
<xref target='I-D.tiloca-6tisch-robust-scheduling'/> proposes <xref target="I-D.tiloca-6tisch-robust-scheduling"/> proposes
a method to obfuscate the hopping sequence and make it harder to perpetrate a method to obfuscate the hopping sequence and make it harder to perpetrate
that particular attack. that particular attack.
</t> </t>
</section> </section>
<section anchor='iee'><name>MAC-Layer Security</name> <section anchor="iee"><name>MAC-Layer Security</name>
<t> <t>
This architecture operates on IEEE Std. 802.15.4 and expects the Link-Layer This architecture operates on IEEE Std 802.15.4 and expects the link-layer
security to be enabled at all times between connected devices, except for security to be enabled at all times between connected devices, except for
the very first step of the device join process, where a joining device may the very first step of the device join process, where a joining device may
need some initial, unsecured exchanges so as to obtain its initial key need some initial, unsecured exchanges so as to obtain its initial key
material. In a typical deployment, all joined nodes use the same keys and material. In a typical deployment, all joined nodes use the same keys, and
rekeying needs to be global. rekeying needs to be global.
</t> </t>
<t> <t>
The 6TISCH Architecture relies on the join process to deny authorization of The 6TISCH architecture relies on the join process to deny authorization of
invalid nodes and preserve the integrity of the network keys. A rogue that invalid nodes and to preserve the integrity of the network keys. A rogue tha
t
managed to access the network can perform a large variety of attacks from managed to access the network can perform a large variety of attacks from
DoS to injecting forged packets and routing information. DoS to injecting forged packets and routing information.
"Zero-trust" properties would be highly desirable but are mostly not "Zero-trust" properties would be highly desirable but are mostly not
available at the time of this writing. <xref target='I-D.ietf-6lo-ap-nd'/> available at the time of this writing. <xref target="RFC8928"/>
is a notable exception that protects the ownership of IPv6 addresses and is a notable exception that protects the ownership of IPv6 addresses and
prevents a rogue node with L2 access from stealing and injecting traffic prevents a rogue node with L2 access from stealing and injecting traffic
on behalf of a legitimate node. on behalf of a legitimate node.
</t> </t>
<!--
<t>
The join protocol can be zero-touch and leverage ANIMA procedures, as
detailed in the <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join">
6tisch Zero-Touch Secure Join protocol</xref>.
</t>
<t>
Alternatively, the join protocol can be one-touch, in which case the pledge
is provisioned with a preshared key (PSK), and uses CoJP as specified in
<xref target="I-D.ietf-6tisch-minimal-security"/>.
</t>
-->
</section> </section>
<section anchor='ts'><name>Time Synchronization</name> <section anchor="ts"><name>Time Synchronization</name>
<t> <t>
Time Synchronization in TSCH induces another event horizon whereby a node Time synchronization in TSCH induces another event horizon whereby a node
will only communicate with another node if they are synchronized within a will only communicate with another node if they are synchronized within a
guard time. The pledge discovers the synchronization of the network based guard time. The pledge discovers the synchronization of the network based
on the time of reception of the beacon. If an attacker synchronizes a pledge on the time of reception of the beacon. If an attacker synchronizes a pledge
outside of the guard time of the legitimate nodes then the pledge will never outside of the guard time of the legitimate nodes, then the pledge will neve r
see a legitimate beacon and may not discover the attack. see a legitimate beacon and may not discover the attack.
</t> </t>
<t>As discussed in <xref target='RFC8655'/>, measures <t>As discussed in <xref target="RFC8655"/>, measures
must be taken to protect the time synchronization, and for 6TiSCH this must be taken to protect the time synchronization, and for 6TiSCH this
includes ensuring that the Absolute Slot Number (ASN), which is the node's includes ensuring that the Absolute Slot Number (ASN), which is the node's
sense of time, is not compromised. Once installed and as long as the node is sense of time, is not compromised. Once installed and as long as the node is
synchronized to the network, ASN is implicit in the transmissions. synchronized to the network, ASN is implicit in the transmissions.
</t> </t>
<t> <t>
<xref target='IEEE802154'>IEEE Std. 802.15.4</xref> specifies that in a TSCH <xref target="IEEE802154">IEEE Std 802.15.4</xref> specifies that in a TSCH
network, the nonce that is used for the computation of the Message Integrity network, the nonce that is used for the computation of the Message Integrity
Code (MIC) to secure Link-Layer frames is composed of the address Code (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 ASN of 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 explicitly in is distributed securely by other means. The ASN is not passed explicitly in
the data frames and does not constitute a complete anti-replay protection. the data frames and does not constitute a complete anti-replay protection.
It results that upper layer protocols must provide a way to detect As a result, upper-layer protocols must provide a way to detect
duplicates and cope with them. duplicates and cope with them.
</t> </t>
<t> <t>
If the receiver and the sender have a different sense of ASN, the MIC will 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 induces an not validate and the frame will be dropped. In that sense, TSCH induces an
event horizon whereby only nodes that have a common sense of ASN can talk to event horizon whereby only nodes that have a common sense of ASN can talk to
one another in an authenticated manner. With 6TiSCH, the pledge discovers a one another in an authenticated manner. With 6TiSCH, the pledge discovers a
tentative ASN in beacons from nodes that have already joined the network. tentative ASN in beacons from nodes that have already joined the network.
But even if the beacon can be authenticated, the ASN cannot be trusted as it But even if the beacon can be authenticated, the ASN cannot be trusted as it
could be a replay by an attacker and thus could announce an ASN that could be a replay by an attacker, announcing an ASN that
represents a time in the past. If the pledge uses an ASN that is learned represents a time in the past. If the pledge uses an ASN that is learned
from a replayed beacon for an encrypted transmission, a nonce-reuse attack from a replayed beacon for an encrypted transmission, a nonce-reuse attack
becomes possible and the network keys may be compromised. becomes possible, and the network keys may be compromised.
</t> </t>
</section> </section>
<section anchor='asv'><name>Validating ASN</name> <section anchor="asv"><name>Validating ASN</name>
<t> <t>
After obtaining the tentative ASN, a pledge that wishes to join the After obtaining the tentative ASN, a pledge that wishes to join the
6TiSCH network must use a join protocol to obtain its security keys. 6TiSCH network must use a join protocol to obtain its security keys.
The join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP). The join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP).
In the minimal setting defined in In the minimal setting defined in
<xref target='I-D.ietf-6tisch-minimal-security'/>, the authentication <xref target="RFC9031"/>, the authentication
requires a pre-shared key, based on which a secure session is derived. requires a pre-shared key, based on which a secure session is derived.
The CoJP exchange may also be preceded with a zero-touch handshake The CoJP exchange may also be preceded by a zero-touch handshake
<xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> in order <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> in order
to enable pledge joining based on certificates and/or inter-domain to enable pledge joining based on certificates and/or inter-domain
communication. communication.
</t> </t>
<t> <t>
As detailed in <xref target='rflo'/>, As detailed in <xref target="rflo"/>,
a Join Proxy (JP) helps the pledge for the join procedure by relaying the a Join Proxy (JP) helps the pledge with the join procedure by relaying the
link-scope Join Request over the IP network to a Join Registrar/Coordinator link-scope Join Request over the IP network to a Join Registrar/Coordinator
(JRC) that can authenticate the pledge and validate that it is attached to (JRC) that can authenticate the pledge and validate that it is attached to
the appropriate network. As a result of the CoJP exchange, the pledge is in the appropriate network. As a result of the CoJP exchange, the pledge is in
possession of a Link-Layer material including keys and a short address, and possession of link-layer material including keys and a short address, and
if the ASN is known to be correct, all traffic can now be secured using CCM* if the ASN is known to be correct, all traffic can now be secured using CCM*
<xref target='CCMstar'/> at the Link-Layer. <xref target="CCMstar"/> at the link layer.
</t> </t>
<t> <t>
The authentication steps must be such that they cannot be replayed by an 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. attacker, and they must not depend on the tentative ASN being valid.
During the authentication, the keying material that the pledge obtains from During the authentication, the keying material that the pledge obtains from
the JRC does not provide protection against spoofed ASN. Once the pledge has 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 . 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) If the nonce used in the Layer 2 security derives from the extended (MAC-64)
address, then replaying the ASN alone cannot enable a nonce-reuse attack address, then replaying the ASN alone cannot enable a nonce-reuse attack
unless the same node is lost its state with a previous ASN. But 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 if the nonce derives from the short address (e.g., assigned by the JRC), the
n
the JRC must ensure that it never assigns short addresses that were already 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 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. must be rekeyed before the JRC runs out of short addresses.
</t> </t>
<!--t>
Once the node obtains the keys from the JRC, an additional step may be
required to ensure that the ASN is correct before encrypting any message.
If the ASN is not guaranteed to be correct by other means, the pledge should
perform a non-replayable exchange (e.g., using a nonce in the payload that
does not derive from ASN) with a peer node that is trusted and has already
joined (e.g., the JP or a RPL time parent). The request by the pledge should
not be encrypted at the Link-Layer but only authenticated to avoid
nonce-replay attacks. A successful authenticated exchange proves a common
sense of ASN and encrypted traffic can now happen.
</t-->
</section> </section>
<section anchor='keying'><name>Network Keying and Rekeying</name> <section anchor="keying"><name>Network Keying and Rekeying</name>
<t> <t>
<xref target='rflo'/> provides an overview of the CoJP process described i <xref target="rflo"/> provides an overview of the CoJP process described i
n n
<xref target='I-D.ietf-6tisch-minimal-security'/> by which an LLN <xref target="RFC9031"/> by which an LLN
can be assembled in the field, having been provisioned in a lab. can be assembled in the field, having been provisioned in a lab.
<xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> is future <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> is future
work that preceeds and then leverages the CoJP protocol using the work that precedes and then leverages CoJP using the
<xref target='I-D.ietf-anima-constrained-voucher'/> constrained profile <xref target="I-D.ietf-anima-constrained-voucher"/> constrained profile
of <xref target='I-D.ietf-anima-bootstrapping-keyinfra'/> (BRSKI). of <xref target="RFC8995"/>.
This later work requires a yet-to-be standardized Lighweight Authenticated This later work requires a yet-to-be standardized Lightweight Authenticate
d
Key Exchange protocol. Key Exchange protocol.
</t> </t>
<t> <t>
The CoJP protocol results in distribution of a network-wide key that CoJP results in distribution of a network-wide key that
is to be used with <xref target='IEEE802154'/> security. The details of us is to be used with <xref target="IEEE802154"/> security. The details of us
e are e are
described in <xref target='I-D.ietf-6tisch-minimal-security'/> sections described in <xref target="RFC9031"/>, Sections <xref target="RFC9031" sec
9.2 and 9.3.2. tion="9.2" sectionFormat="bare" format="default"/>
and <xref target="RFC9031" section="9.3.2" sectionFormat="bare" format="de
fault"/>.
</t> </t>
<t> <t>
The BRSKI mechanism may lead to the use of the CoJP protocol, in which cas e The BRSKI mechanism may lead to the use of CoJP, in which case
it also results in distribution of a network-wide key. Alternatively it also results in distribution of a network-wide key. Alternatively
the BRSKI mechanism may be followed by use of <xref target='I-D.ietf-ace-c oap-est'/> the BRSKI mechanism may be followed by use of <xref target="I-D.ietf-ace-c oap-est"/>
to enroll certificates for each device. In that case, the certificates to enroll certificates for each device. In that case, the certificates
may be used with an <xref target='IEEE802154'/> key agreement protocol. T may be used with an <xref target="IEEE802154"/> key agreement protocol. T
he he
description of this mechanism, while conceptually straight forward still description of this mechanism, while conceptually straightforward, still
has significant standardization hurdles to pass. has significant standardization hurdles to pass.
</t> </t>
<t> <t>
<xref target='I-D.ietf-6tisch-minimal-security'/> section 9.2 describes <xref target="RFC9031" section="8.2" sectionFormat="of" format="default"/> describes
a mechanism to change (rekey) the network. a mechanism to change (rekey) the network.
There are a number of reasons to initiate a network rekey: to remove There are a number of reasons to initiate a network rekey: to remove
unwanted (corrupt/malicious) nodes, to recover unused 2-byte short unwanted (corrupt/malicious) nodes, to recover unused 2-byte short
addresses, or due to limits in encryption algorithms. addresses, or due to limits in encryption algorithms.
For all of the mechanisms that distribute a network-wide key, rekeying For all of the mechanisms that distribute a network-wide key, rekeying
is also needed on a periodic basis. In more details: is also needed on a periodic basis. In more detail:
</t> </t>
<t></t><ul spacing='normal'> <ul spacing="normal">
<li> <li>
The mechanism described in The mechanism described in
<xref target='I-D.ietf-6tisch-minimal-security'/> section 9.2 requires <xref target="RFC9031" section="8.2" sectionFormat="of" format="default"/> requires
advance communication between the JRC and every one of the nodes before advance communication between the JRC and every one of the nodes before
the key change. Given that many nodes may be sleepy, this operation the key change. Given that many nodes may be sleepy, this operation
may take a significant amount of time, and may consume a significant may take a significant amount of time and may consume a significant
portion of the available bandwidth. As such, network-wide rekeys in portion of the available bandwidth. As such, network-wide rekeys
order to exclude nodes that have become malicious will not be to exclude nodes that have become malicious will not be
particularly quick. If a rekey is already in progress, but the particularly quick. If a rekey is already in progress, but the
unwanted node has not yet been updated, then it is possible to to just unwanted node has not yet been updated, then it is possible to just
continue the operation. If the unwanted node has already received the continue the operation. If the unwanted node has already received the
update, then the rekey operation will need to be restarted. update, then the rekey operation will need to be restarted.
</li> </li>
<li> <li>
The cryptographic mechanisms used by IEEE Std. 802.15.4 include the 2-byte The cryptographic mechanisms used by IEEE Std 802.15.4 include the 2-byte
short address in the calculation of the context. short address in the calculation of the context.
A nonce-reuse attack may become feasible if a short address is reassigned 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. to another node while the same network-wide keys are in operation.
A network that gains and loses nodes on a regular 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 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 addresses, even if the network has only a few thousand nodes. Network
planners should consider the need to rekey the network on a periodic 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 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 short addresses for active nodes if desired, but there is actually no
need to do this as long as the key has been changed. need to do this as long as the key has been changed.
</li> </li>
<li> <li>
With TSCH as it stands at the time of this writing, the ASN will wrap With TSCH as it stands at the time of this writing, the ASN will wrap
after 2^40 timeslot durations, which means with the default values around after 2^40 timeslot durations, meaning around 350 years with the default v
350 years. Wrapping ASN is not expected to happen within the lifetime of alues.
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 most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid
a nonce-reuse attack. a nonce-reuse attack.
</li> </li>
<li> <li>
Many cipher algorithms have some suggested limits on how many bytes Many cipher algorithms have some suggested limits on how many bytes
should be encrypted with that algorithm before a new key is used. should be encrypted with that algorithm before a new key is used.
These numbers are typically in the many to hundreds of gigabytes of These numbers are typically in the many to hundreds of gigabytes of
data. On very fast backbone networks this becomes an important data. On very fast backbone networks, this becomes an important
concern. On LLNs with typical data rates in the kilobits/second, 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 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 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 current L2 crypto (AES-CCM-128) are reached, so the problem should never
occur. occur.
</li> </li>
<li> <li>
In any fashion, if the LLN is expected to operate continuously for decades 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. then the operators are advised to plan for the need to rekey.
</li> </li>
</ul><t> </ul>
</t>
<t> <t>
Except for urgent rekeys caused by malicious nodes, the rekey operation Except for urgent rekeys caused by malicious nodes, the rekey operation
described in <xref target='I-D.ietf-6tisch-minimal-security'/> described in <xref target="RFC9031"/>
can be done as a background task and can be done incrementally. It 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 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 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 use. As such, the update can take as long as needed, or occur in as
short a time as practical. short a time as practical.
</t> </t>
</section> </section>
</section> </section>
<section><name>Acknowledgments</name>
<section><name>Contributors</name>
<t>The co-authors of this document are listed below:
</t><dl spacing='normal'>
<dt>Thomas Watteyne</dt><dd>
for his contribution to the whole design, in particular on TSCH and se
curity,
and to the open source community with openWSN that he created.
</dd>
<dt>Xavier Vilajosana</dt><dd>
who lead the design of the minimal support with RPL and contributed
deeply to the 6top design and the G-MPLS operation of Track switching;
</dd>
<dt>Kris Pister</dt><dd>
for creating TSCH and his continuing guidance through the elaboration
of this design;
</dd>
<dt>Malisa Vucinic</dt><dd>
for the work on the one-touch join process and his contribution to the
Security Design Team;
</dd>
<dt>Michael Richardson</dt><dd>
for his leadership role in the Security Design Team and his
contribution throughout this document;
</dd>
<dt>Tero Kivinen</dt><dd>
for his contribution to the security work in general and the security
section in particular.
</dd>
<dt>Maria Rita Palattella</dt><dd>
for managing the Terminology document merged into this through the work
of 6TiSCH;
</dd>
<dt>Simon Duquennoy</dt><dd>
for his contribution to the open source community with the 6TiSCH
implementaton of contiki, and for his contribution to MSF and
autonomous unicast cells.
</dd>
<dt>Qin Wang</dt><dd>
who lead the design of the 6top sublayer and contributed related text
that was moved and/or adapted in this document;
</dd>
<dt>Rene Struik</dt><dd>
for the security section and his contribution to the Security Design
Team;
</dd>
<dt>Robert Assimiti</dt><dd>
for his breakthrough work on RPL over TSCH and initial text and
guidance;
</dd>
</dl><t>
</t>
</section>
<section><name>Special Thanks</name><t>
Special thanks to Jonathan Simon, Giuseppe Piro, Subir Das
and Yoshihiro Ohba for their deep contribution to the initial security
work, to Yasuyuki Tanaka for his work on implementation and simulation
that tremendously 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.
</t><t>
Special thanks also to Pat Kinney, Charlie Perkins and Bob Heile for their
support in maintaining the connection active and the design in line with
work happening at IEEE 802.15.
</t> <t>
Special thanks to Ted Lemon who was the INT Area A-D while this
document was initiated for his great support and help throughout,
and to Suresh Krishnan who took over with that kind efficiency of his till
publication.
</t><t>
Also special thanks to Ralph Droms who performed the first INT Area
Directorate review, that was very deep and thorough and radically changed
the orientations of this document, and then to Eliot Lear and Carlos
Pignataro who help finalize this document in preparation to the IESG
reviews, and to Gorry Fairhurst, David Mandelberg, Qin Wu, Francis Dupont,
Eric Vyncke, Mirja Kuhlewind, Roman Danyliw, Benjamin Kaduk
and Andrew Malis, who contributed to the final shaping of this document
through the IESG review procedure.
</t>
</section>
<section><name>And Do not Forget</name>
<t>This document is the result of multiple interactions, in
particular during the 6TiSCH (bi)Weekly Interim call, relayed through
the 6TiSCH mailing list at the IETF, over the course of more than 5 years.
</t><t>
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 Stock, 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.
</t>
</section>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-6tisch-minimal-security" to <displayreference target="I-D.ietf-roll-rpl-industrial-applicability" to="RPL-AP
="MIN-SECURITY"/> PLICABILITY"/>
<displayreference target="I-D.ietf-6lo-backbone-router" to="6B <displayreference target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" to="ZEROTOU
BR-DRAFT"/> CH-JOIN"/>
<displayreference target="I-D.ietf-6lo-fragment-recovery" to=" <displayreference target="I-D.ietf-manet-aodvv2" to="AODVv2"/>
RECOV-FRAG"/> <displayreference target="I-D.ietf-roll-aodv-rpl" to="AODV-RPL"/>
<displayreference target="I-D.ietf-6lo-minimal-fragment" to="M <displayreference target="I-D.ietf-lwig-6lowpan-virtual-reassembly" to="VIRTUAL-
IN-FRAG"/> REASSEMBLY"/>
<displayreference target="I-D.ietf-6lo-ap-nd" to="AP-ND"/> <displayreference target="I-D.ietf-roll-dao-projection" to="DAO-PROJECTION"/>
<displayreference target="I-D.ietf-roll-useofrplinfo" to="USEo <displayreference target="I-D.ietf-roll-capabilities" to="RPL-MOP"/>
fRPLinfo"/> <displayreference target="I-D.selander-ace-cose-ecdhe" to="EDHOC"/>
<displayreference target="I-D.ietf-roll-unaware-leaves" to="RU <displayreference target="I-D.thubert-roll-bier" to="RPL-BIER"/>
L-DRAFT"/> <displayreference target="I-D.thubert-bier-replication-elimination" to="TE-PREF"
<displayreference target="I-D.ietf-6tisch-enrollment-enhanced-beacon" />
to="ENH-BEACON"/> <displayreference target="I-D.thubert-6lo-bier-dispatch" to="BITSTRINGS-6LORH"/>
<displayreference target="I-D.ietf-6tisch-msf" to="MSF"/> <displayreference target="I-D.thubert-6man-unicast-lookup" to="ND-UNICAST-LOOKUP
<references><name>Normative References</name> "/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <displayreference target="I-D.pthubert-raw-architecture" to="RAW-ARCHITECTURE"/>
ce.RFC.0768.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification --> <displayreference target="I-D.tiloca-6tisch-robust-scheduling" to="ROBUST-SCHEDU
<!-- <?rfc include="reference.RFC.2119"?> Key words for use in RFCs to Ind LING"/>
icate Requirement Levels --> <displayreference target="I-D.ietf-ace-coap-est" to="EST-COAPS"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <displayreference target="I-D.ietf-anima-constrained-voucher" to="CONSTRAINED-VO
ce.RFC.4861.xml'/> <!-- neighbor Discovery for IP version 6 (IPv6) --> UCHER"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <displayreference target="I-D.ietf-raw-use-cases" to="RAW-USE-CASES"/>
ce.RFC.4862.xml'/> <!-- IPv6 Stateless Address Autoconfiguration --> <references>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <name>References</name>
ce.RFC.4944.xml'/> <!-- 6LoWPAN --> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0768.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4861.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4862.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4944.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6282.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6550.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6551.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6552.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6553.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6554.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6775.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8025.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8137.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8138.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8180.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8200.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8480.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8453.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8505.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7102.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7554.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7228.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5889.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8655.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <reference anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9031">
ce.RFC.6282.xml'/> <!-- Compression Format for IPv6 Datagrams over IEEE 802.15.4 <front>
-Based Networks --> <title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <author initials="M" surname="Vučinić" fullname=" Mališa Vučinić" role="edit
ce.RFC.6550.xml'/> <!-- RPL: IPv6 Routing Protocol for Low-Power and Lossy Netwo or">
rks --> <organization/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </author>
ce.RFC.6551.xml'/> <!-- Routing Metrics Used for Path Calculation in LLNs --> <author initials="J" surname="Simon" fullname="Jonathan Simon">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <organization/>
ce.RFC.6552.xml'/> <!-- RPL OF0: Objective Function Zero for RPL--> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <author initials="K" surname="Pister" fullname="Kris Pister">
ce.RFC.6553.xml'/> <!-- RPL Option for Carrying RPL Information in Data-Plane Da <organization/>
tagrams --> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <author initials="M" surname="Richardson" fullname="Michael Richardson">
ce.RFC.6554.xml'/> <!-- An IPv6 Routing Header for Source Routes with RPL --> <organization/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </author>
ce.RFC.6775.xml'/> <!-- neighbor Discovery Optimization for IPv6 over Low-Power <date month="May" year="2021"/>
Wireless Personal Area Networks (6LoWPANs) --> </front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <seriesInfo name="RFC" value="9031"/>
ce.RFC.7252.xml'/> <!-- CoAP --> <seriesInfo name="DOI" value="10.17487/RFC9031"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </reference>
ce.RFC.8025.xml'/> <!-- 6LoRH coding dispatch-->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8137.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8138.xml'/> <!-- 6LoRH routing dispatch-->
<!-- <?rfc include='reference.RFC.8174'?> Ambiguity of Uppercase vs Lower
case in RFC 2119 Key Words-->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8180.xml'/> <!-- 6TiSCH minimal -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8200.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8480.xml'/> <!-- 6top protocol -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8453.xml'/> <!-- ACTN -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8505.xml'/> <!-- RFC6775 update -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.7102.xml'/> <!-- Terms Used in Routing for Low-Power and Lossy Networks - .8929.xml"/>
->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7554.xml'/> <!-- 6TiSCH TSCH -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7228.xml'/> <!-- Terminology for Constrained-Node Networks -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5889.xml'/> <!-- IP Addressing Model in Ad Hoc Networks -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8655.xml'/> <!-- DetNet Architecture -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
nce.I-D.ietf-6tisch-minimal-security.xml'/> .8931.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-6lo-backbone-router.xml'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere .8930.xml"/>
nce.I-D.ietf-6lo-fragment-recovery.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
nce.I-D.ietf-6lo-minimal-fragment.xml'/> .8928.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-6lo-ap-nd.xml'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere .9008.xml"/>
nce.I-D.ietf-roll-useofrplinfo.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
nce.I-D.ietf-roll-unaware-leaves.xml'/> .9010.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-6tisch-enrollment-enhanced-beacon.xml'/> <reference anchor="RFC9032" target="https://www.rfc-editor.org/info/rfc9032">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <front>
nce.I-D.ietf-6tisch-msf.xml'/> <title>Encapsulation of 6TiSCH Join and Enrollment Information Elements</tit
le>
<author initials="D" surname="Dujovne" fullname="Diego Dujovne" role="editor
">
<organization/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richardson">
<organization/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="9032"/>
<seriesInfo name="DOI" value="10.17487/RFC9032"/>
</reference>
<reference anchor="RFC9033" target="https://www.rfc-editor.org/info/rfc9033">
<front>
<title>6TiSCH Minimal Scheduling Function (MSF)</title>
<author initials="T" surname="Chang" fullname="Tengfei Chang" role="editor">
<organization/>
</author>
<author initials="M" surname="Vučinić" fullname="Mališa Vučinić">
<organization/>
</author>
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana">
<organization/>
</author>
<author initials="S" surname="Duquennoy" fullname="Simon Duquennoy">
<organization/>
</author>
<author initials="D" surname="Dujovne" fullname="Diego Dujovne">
<organization/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="9033"/>
<seriesInfo name="DOI" value="10.17487/RFC9033"/>
</reference>
</references>
</references>
<references><name>Informative References</name> <references><name>Informative References</name>
<!-- <?rfc include="reference.RFC.6620"?> FCFS SAVI: First-Come, First-Se <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
rved Source Address Validation --> .5340.xml"/>
<!--?rfc include="reference.RFC.6655"?--> <!-- AES-CCM Cipher Suites for <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
Transport Layer Security (TLS) --> .6275.xml"/>
<!--?rfc include="reference.RFC.5191"?--> <!-- Protocol for Carrying Authe <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ntication for Network Access (PANA) --> .2474.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.5340.xml'/> <!-- OSPF for IPv6 --> .2545.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.6275.xml'/> <!-- Mobility Support in IPv6 --> .3963.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.2474.xml'/> <!-- Differentiated Services Field --> .3209.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.2545.xml'/> <!-- BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Rou .4291.xml"/>
ting --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen .3444.xml"/>
ce.RFC.3963.xml'/> <!-- Network Mobility (NEMO) --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<!-- <?rfc include="reference.RFC.3972"?> CGA --> .4080.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.3209.xml'/> <!-- RSVP TE --> .4919.xml"/>
<!-- <?rfc include="reference.RFC.3971"?> SEcure Neighbor Discovery (SEND) <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
--> .4903.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.4291.xml'/> <!-- IP Version 6 Addressing Architecture --> .5974.xml"/>
<!-- <?rfc include="reference.RFC.4429"?> IP Version 6 Optimistic DAD --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen .6347.xml"/>
ce.RFC.3444.xml'/> <!-- On the Difference between Information Models and Data Mo <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
dels --> .6830.xml"/>
<!-- <?rfc include="reference.RFC.3610"?> Counter with CBC-MAC (CCM) --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<!-- 6TiSCH --> .7426.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.4080.xml'/> <!-- Next Steps in Signaling (NSIS): Framework --> .6606.xml"/>
<!-- <?rfc include="reference.RFC.4389"?> IP Version 6 ND Proxy -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <reference anchor="I-D.ietf-roll-rpl-industrial-applicability">
ce.RFC.4919.xml'/> <!-- IPv6 over Low-Power Wireless Personal Area Networks --> <front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <title>RPL applicability in industrial networks</title>
ce.RFC.4903.xml'/> <!-- IPv6 Multi-Link Subnet Issues --> <author fullname="Tom Phinney" role="editor"> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <author fullname="Pascal Thubert"> </author>
ce.RFC.5974.xml'/> <!-- NSIS Signaling Layer Protocol (NSLP) for Quality-of-Serv <author fullname="Robert Assimiti"> </author>
ice Signaling --> <date month="October" day="21" year="2013"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </front>
ce.RFC.6347.xml'/> <!-- Datagram Transport Layer Security Version 1.2 --> <seriesInfo name="Internet-Draft" value="draft-ietf-roll-rpl-industrial-applicab
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere ility-02"/>
nce.RFC.6830.xml'/> <!-- The Locator/ID Separation Protocol (LISP) --> </reference>
<!--?rfc include="reference.RFC.6997"?--> <!-- Reactive Discovery of Poin
t-to-Point Routes in Low-Power and Lossy Networks --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen etf-6tisch-dtsecurity-zerotouch-join.xml"/>
ce.RFC.7426.xml'/> <!-- Software-Defined Networking (SDN): Layers and Architectu
re Terminology --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8613.xml"/>
ce.RFC.6606.xml'/> <!-- Problem Statement and Requirements for 6LoWPAN Routing -
-> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
<!-- others --> etf-manet-aodvv2.xml"/>
<!--?rfc include='reference.I-D.ietf-ipv6-Multi-Link-subnets'?-->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
nce.I-D.ietf-roll-rpl-industrial-applicability.xml'/> ce.RFC.8578.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-6tisch-dtsecurity-zerotouch-join.xml'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere ce.RFC.8939.xml"/>
nce.I-D.ietf-core-object-security.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
nce.I-D.ietf-manet-aodvv2.xml'/> ce.RFC.8995.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8578.xml'/> <!-- Deterministic Networking Use Cases --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere etf-roll-aodv-rpl.xml"/>
nce.I-D.ietf-detnet-ip.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
nce.I-D.ietf-anima-bootstrapping-keyinfra.xml'/> etf-lwig-6lowpan-virtual-reassembly.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-roll-aodv-rpl.xml'/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere etf-roll-dao-projection.xml"/>
nce.I-D.ietf-lwig-6lowpan-virtual-reassembly.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <reference anchor="I-D.ietf-roll-capabilities">
nce.I-D.ietf-roll-dao-projection.xml'/> <front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <title>RPL Capabilities</title>
nce.I-D.rahul-roll-mop-ext.xml'/> <author initials="R" surname="Jadhav" fullname="Rahul Arvind Jadhav" role=
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere "editor"> </author>
nce.I-D.selander-ace-cose-ecdhe.xml'/> <author fullname="Pascal Thubert">
<!-- <?rfc include='reference.I-D.svshah-tsvwg-lln-diffserv-recommendation <organization>Cisco Systems, Inc</organization>
s'?> --> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <author fullname="Michael Richardson">
nce.I-D.thubert-roll-bier.xml'/> <organization>Sandelman Software Works</organization>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere </author>
nce.I-D.thubert-bier-replication-elimination.xml'/> <author initials="R" surname="Sahoo" fullname="Rabi Narayan Sahoo">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <organization>Juniper</organization>
nce.I-D.thubert-6lo-bier-dispatch.xml'/> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <date month="March" day="17" year="2021"/>
nce.I-D.thubert-6man-unicast-lookup.xml'/> </front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <seriesInfo name="Internet-Draft" value="draft-ietf-roll-capabilities-08"/>
nce.I-D.pthubert-raw-problem-statement.xml'/> </reference>
<!--?rfc include='reference.I-D.bernardos-raw-use-cases'?-->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.s
nce.I-D.tiloca-6tisch-robust-scheduling.xml'/> elander-ace-cose-ecdhe.xml"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-ace-coap-est.xml'/> <reference anchor="I-D.thubert-roll-bier">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <front>
nce.I-D.ietf-anima-constrained-voucher.xml'/> <title>RPL-BIER</title>
<reference anchor='IEEE802154'> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edito
<front> r">
<title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access <organization/>
Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate </author>
Wireless Personal Area Networks <date month="July" day="24" year="2018"/>
</title> </front>
<seriesInfo name="Internet-Draft" value="draft-thubert-roll-bier-02"/>
</reference>
<reference anchor="I-D.thubert-bier-replication-elimination">
<front>
<title>BIER-TE extensions for Packet Replication and Elimination Function (P
REF) and OAM</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edito
r">
<organization/>
</author>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/>
</author>
<author initials="Z" surname="Brodard" fullname="Zacharie Brodard">
<organization/>
</author>
<author initials="H" surname="Jiang" fullname="Hao Jiang">
<organization/>
</author>
<date month="March" day="3" year="2018"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-thubert-bier-replication-elimin
ation-03"/>
</reference>
<reference anchor="I-D.thubert-6lo-bier-dispatch">
<front>
<title>A 6loRH for BitStrings</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edito
r">
<organization/>
</author>
<author initials="Z" surname="Brodard" fullname="Zacharie Brodard">
<organization/>
</author>
<author initials="H" surname="Jiang" fullname="Hao Jiang">
<organization/>
</author>
<author initials="G" surname="Texier" fullname="Geraldine Texier">
<organization/>
</author>
<date month="January" day="28" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-thubert-6lo-bier-dispatch-06"/>
</reference>
<reference anchor="I-D.thubert-6man-unicast-lookup">
<front>
<title>IPv6 Neighbor Discovery Unicast Lookup</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edito
r">
<organization/>
</author>
<author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abegnoli">
<organization/>
</author>
<date month="July" day="29" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-thubert-6man-unicast-lookup-00"
/>
</reference>
<reference anchor="I-D.pthubert-raw-architecture">
<front>
<title>Reliable and Available Wireless Problem Statement</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edito
r">
<organization/>
</author>
<author initials="G. Z." surname="Papadopoulos" fullname="Georgios Papadopou
los">
<organization/>
</author>
<date month="November" day="15" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-pthubert-raw-architecture-05"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.t
iloca-6tisch-robust-scheduling.xml"/>
<reference anchor="I-D.ietf-ace-coap-est">
<front>
<title>EST over secure CoAP (EST-coaps)</title>
<author initials="P" surname="van der Stok" fullname="Peter van der Stok">
<organization/>
</author>
<author initials="P" surname="Kampanakis" fullname="Panos Kampanakis">
<organization/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richardson">
<organization/>
</author>
<author initials="S" surname="Raza" fullname="Shahid Raza">
<organization/>
</author>
<date month="January" day="6" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-coap-est-18"/>
</reference>
<reference anchor="I-D.ietf-anima-constrained-voucher" target="https://tools.iet
f.org/html/draft-ietf-anima-constrained-voucher-10">
<front>
<title>Constrained Voucher Artifacts for Bootstrapping Protocols</title>
<author initials="M" surname="Richardson" fullname="Michael Richardson">
<organization/>
</author>
<author initials="P" surname="van der Stok" fullname="Peter van der Stok">
<organization/>
</author>
<author initials="P" surname="Kampanakis" fullname="Panos Kampanakis">
<organization/>
</author>
<date month="February" day="21" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-
10"/>
</reference>
<reference anchor="IEEE802154"
target="https://ieeexplore.ieee.org/document/7460875">
<front>
<title>IEEE Standard for Low-Rate Wireless Networks</title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date/> <date month="April" year="2016"/>
</front> </front>
<seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
</reference> </reference>
<reference anchor='CCMstar' target='www.ieee802.org/15/pub/2004/15-04-0537 -00-004b-formal-specification-ccm-star-mode-operation.doc'> <reference anchor="CCMstar" target="http://www.ieee802.org/15/pub/2004/15- 04-0537-00-004b-formal-specification-ccm-star-mode-operation.doc">
<front> <front>
<title> <title>Formal Specification of the CCM* Mode of Operation</title>
Formal Specification of the CCM* Mode of Operation <author fullname="Rene Struik">
</title> <organization>IEEE</organization>
<author fullname='Rene Struik'>
<organization>IEEE standard for Information Technology</organizat
ion>
</author> </author>
<date month='September' year='2004'/> <date month="September" year="2004"/>
</front> </front>
</reference> </reference>
<reference anchor='IEEE802154e'>
<reference anchor="IEEE802154e"
target="https://ieeexplore.ieee.org/document/6185525">
<front> <front>
<title>IEEE standard for Information Technology, IEEE Std. <title>IEEE Standard for Local and metropolitan area networks -- Par
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) t. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC su
and Physical Layer (PHY) Specifications for Low-Rate blayer
Wireless Personal Area Networks, June 2011 as amended by IEEE Std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date month='April' year='2012'/> <date month="April" year="2012"/>
</front> </front>
<seriesInfo name="IEEE Standard" value="802.15.4e-2012"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6185525"/>
</reference> </reference>
<!--reference anchor="IEEE802.1TSNTG" target="http://www.ieee802.org/1/pag
es/avbridges.html"> <reference anchor="WirelessHART" target="https://webstore.iec.ch/publicati
<front> on/24433">
<title>IEEE 802.1 Time-Sensitive Networks Task Group</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date day="08" month="March" year="2013" />
</front>
</reference-->
<reference anchor='WirelessHART'>
<front> <front>
<title>Industrial Communication Networks - Wireless Communication Ne twork and Communication Profiles - WirelessHART - IEC 62591</title> <title>Industrial networks - Wireless communication network and comm unication profiles - WirelessHART(TM)</title>
<author> <author>
<organization>www.hartcomm.org</organization> <organization>International Electrotechnical Commission</organiza tion>
</author> </author>
<date year='2010'/> <date month="March" year="2016"/>
</front> </front>
<seriesInfo name="IEC" value="62591:2016"/>
</reference> </reference>
<reference anchor='HART'>
<reference anchor="HART" target="https://fieldcommgroup.org/technologies/h
art">
<front> <front>
<title>Highway Addressable remote Transducer, a group of specificati ons for industrial process and control devices administered by the HART Foundati on</title> <title>HART</title>
<author> <author>
<organization>www.hartcomm.org</organization> <organization>FieldComm Group</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor='ISA100.11a' target='http://www.isa.org/Community/SP100W
irelessSystemsforAutomation'> <reference anchor="ISA100.11a" target="https://webstore.iec.ch/publication
/65581">
<front> <front>
<title>Wireless Systems for Industrial Automation: Process Control a nd Related Applications - ISA100.11a-2011 - IEC 62734</title> <title>Wireless Systems for Industrial Automation: Process Control a nd Related Applications - ISA100.11a-2011</title>
<author> <author>
<organization>ISA/ANSI</organization> <organization>ISA/ANSI</organization>
</author> </author>
<date year='2011'/> <date year="2011"/>
</front> </front>
<seriesInfo name="IEC" value="62734:2014"/>
</reference> </reference>
<reference anchor='ISA100' target='https://www.isa.org/isa100/'>
<reference anchor="ISA100" target="https://www.isa.org/isa100/">
<front> <front>
<title>ISA100, Wireless Systems for Automation</title> <title>ISA100, Wireless Systems for Automation</title>
<author> <author>
<organization>ISA/ANSI</organization> <organization>ISA/ANSI</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor='TEAS' target='https://dataTracker.ietf.org/doc/charter-
ietf-teas/'> <reference anchor="TEAS" target="https://datatracker.ietf.org/doc/charter-
ietf-teas/">
<front> <front>
<title>Traffic Engineering Architecture and Signaling</title> <title>Traffic Engineering Architecture and Signaling (teas)</title>
<author> <author>
<organization>IETF</organization> <organization>IETF</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor='ANIMA' target='https://dataTracker.ietf.org/doc/charter
-ietf-anima/'> <reference anchor="ANIMA" target="https://datatracker.ietf.org/doc/charter
-ietf-anima/">
<front> <front>
<title>Autonomic Networking Integrated Model and Approach</title> <title>Autonomic Networking Integrated Model and Approach (anima)</t itle>
<author> <author>
<organization>IETF</organization> <organization>IETF</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor='PCE' target='https://dataTracker.ietf.org/doc/charter-i
etf-pce/'> <reference anchor="PCE" target="https://datatracker.ietf.org/doc/charter-i
etf-pce/">
<front> <front>
<title>Path Computation Element</title> <title>Path Computation Element (pce)</title>
<author> <author>
<organization>IETF</organization> <organization>IETF</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor='CCAMP' target='https://dataTracker.ietf.org/doc/charter
-ietf-ccamp/'> <reference anchor="CCAMP" target="https://datatracker.ietf.org/doc/charter
-ietf-ccamp/">
<front> <front>
<title>Common Control and Measurement Plane</title> <title>Common Control and Measurement Plane (ccamp)</title>
<author> <author>
<organization>IETF</organization> <organization>IETF</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor='AMI' target='https://www.energy.gov/sites/prod/files/20 16/12/f34/AMI%20Summary%20Report_09-26-16.pdf'> <reference anchor="AMI" target="https://www.energy.gov/sites/prod/files/20 16/12/f34/AMI%20Summary%20Report_09-26-16.pdf">
<front> <front>
<title>Advanced Metering Infrastructure and Customer Systems </title > <title>Advanced Metering Infrastructure and Customer Systems </title >
<author> <author>
<organization>US Department of Energy</organization> <organization>U.S. Department of Energy</organization>
</author> </author>
<date year='2006'/> <date year="2006"/>
</front> </front>
</reference> </reference>
<reference anchor='S-ALOHA' target='https://dl.acm.org/citation.cfm?id=102 4920'> <reference anchor="S-ALOHA" target="https://dl.acm.org/citation.cfm?id=102 4920">
<front> <front>
<title>ALOHA Packet System With and Without Slots and Capture</title <title>ALOHA packet system with and without slots and capture</title
> >
<author surname='Roberts' fullname='Lawrence G. Roberts'> <author surname="Roberts" fullname="Lawrence G. Roberts">
<organization>ACM SIGCOMM Computer Communication Review</organiza
tion>
</author> </author>
<date month='April' year='1975'/> <date month="April" year="1975"/>
</front> </front>
<seriesInfo name='doi' value='10.1145/1024916.1024920'/> <refcontent>ACM SIGCOMM Computer Communication Review</refcontent>
<seriesInfo name="DOI" value="10.1145/1024916.1024920"/>
</reference> </reference>
<reference anchor='IEC62439' target='https://webstore.iec.ch/publication/7 018'> <reference anchor="IEC62439" target="https://webstore.iec.ch/publication/2 4438">
<front> <front>
<title>Industrial communication networks - High availability automat ion networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR) - IEC62439-3</title> <title>Industrial communication networks - High availability automat ion networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR)</title>
<author> <author>
<organization>IEC</organization> <organization>IEC</organization>
</author> </author>
<date year='2012'/> <date year="2016"/>
</front> </front>
<seriesInfo name="IEC" value="62439-3:2016"/>
</reference> </reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
etf-raw-use-cases.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.9035.xml"/>
</references> </references>
</references>
<section><name>Related Work In Progress</name> <section><name>Related Work in Progress</name>
<t>This document has been incremented as the work progressed following the <t>This document has been incremented as the work progressed following the
evolution of the WG charter and the availability of dependent work. evolution of the WG charter and the availability of dependent work.
The intent was to publish when the WG concludes on the covered items. The intent was to publish when the WG concluded on the covered items.
At the time of publishing the following specification are still in progres At the time of publishing, the following specifications are still in progr
s ess
and may affect the evolution of the stack in a 6TiSCH-aware node. and may affect the evolution of the stack in a 6TiSCH-aware node.
</t> </t>
<!-- <section anchor="unchartered"><name>Unchartered IETF Work Items</name>
<section anchor="chartered" title="Chartered IETF work items">
<t>
The operation of the Backbone Router
<xref target="I-D.ietf-6lo-backbone-router"/> is stable but the RFC
is not published yet. The protection of registered addresses against
impersonation and take over will be guaranteed by
<xref target="I-D.ietf-6lo-ap-nd">Address
Protected Neighbor Discovery for Low-power and Lossy Networks</xref>,
which is not yet published either.
</t>
<t>
New procedures have been defined at ROLL that extend RPL and may be of
interest for a 6TiSCH stack.
In particular <xref target="I-D.ietf-roll-unaware-leaves"/> enables a 6LN
that implements only <xref target='RFC8505'/> and avoid the support of RPL
.
</t>
</section> Chartered IETF work items -->
<section anchor='unchartered'><name>Unchartered IETF work items</name>
<section anchor='unchartered-sec'><name>6TiSCH Zerotouch security</name> <section anchor="unchartered-sec"><name>6TiSCH Zero-Touch Security</name>
<t> <t>
The security model and in particular the zerotouch join process The security model and in particular the zero-touch join process
<xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> depends on <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> depend on
the ANIMA <xref target='ANIMA'/> the ANIMA (Autonomic Networking Integrated Model and Approach) <xref targe
<xref target='I-D.ietf-anima-bootstrapping-keyinfra'>Bootstrapping Remote t="ANIMA"/>
Secure Key Infrastructures (BRSKI)</xref> "<xref target="RFC8995" format="title"/>" <xref target="RFC8995"/>
to enable zero-touch security provisionning; for highly to enable zero-touch security provisioning; for highly
constrained nodes, a minimal model based on pre-shared keys (PSK) constrained nodes, a minimal model based on pre-shared keys (PSK)
is also available. As written to this day, it also depends on is also available. As currently written, it also depends on
a number of documents in progress as CORE, and on a number of documents in progress in the CORE (Constrained RESTful Environ
<xref target='I-D.selander-ace-cose-ecdhe'>"Ephemeral Diffie-Hellman Over ments) WG and on
COSE (EDHOC)"</xref>, which is being considered for adoption at the LAKE <xref target="I-D.selander-ace-cose-ecdhe">"Ephemeral Diffie-Hellman Over
WG. COSE (EDHOC)"</xref>, which is being considered for adoption by the LAKE
(Lightweight Authenticated Key Exchange) WG.
</t> </t>
</section> <!-- "6TiSCH Zerotouch security" --> </section>
<section anchor='unchartered-tracks'><name>6TiSCH Track Setup</name> <section anchor="unchartered-tracks"><name>6TiSCH Track Setup</name>
<t> <t>
ROLL is now standardizing a reactive routing protocol based on RPL ROLL (Routing Over Low power and Lossy networks) is now standardizing a re
<xref target='I-D.ietf-roll-aodv-rpl'/> active routing protocol based on RPL
The need of a reactive routing protocol to establish on-demand <xref target="I-D.ietf-roll-aodv-rpl"/>.
The need of a reactive routing protocol to establish on-demand,
constraint-optimized routes and a reservation protocol to establish constraint-optimized routes and a reservation protocol to establish
Layer-3 Tracks is being discussed at 6TiSCH but not chartered for. Layer 3 Tracks is being discussed in 6TiSCH but not yet chartered.
</t><t> </t><t>
<!--
At the time of this writing, the formation of a new working group called
RAW for Reliable and Available Wireless networking is being considered.
The work on centralized Track computation is deferred to a subsequent
work, not necessarily at 6TiSCH. A Predictable and Available Wireless
(PAW) bar-BoF took place.
RAW may form as a WG and develop a generic specification for Track
operations that would cover 6TiSCH requirements as expressed in this
architecture, more in <xref target='I-D.thubert-raw-technologies'/>
and <xref target='I-D.pthubert-raw-problem-statement'/>.
In a large LLN, it is not
feasible to update the routes from a central controller that resides far
over the constrained network at the speed at which the quality of the
wireless links varies.
RAW would focus on forwarding behaviors to react quickly and locally to
the changes in the wireless links.
-->
At the time of this writing, there is new work planned in the IETF to prov ide At the time of this writing, there is new work planned in the IETF to prov ide
limited deterministic networking capabilities for wireless networks with a limited deterministic networking capabilities for wireless networks with a
focus on forwarding behaviors to react quickly and locally to the changes focus on forwarding behaviors to react quickly and locally to the changes
as described in <xref target='I-D.pthubert-raw-problem-statement'/>. as described in <xref target="I-D.pthubert-raw-architecture"/>.
</t><t> </t><t>
ROLL is also standardizing an extension to RPL to setup centrally-computed ROLL is also standardizing an extension to RPL to set up centrally compute
routes <xref target='I-D.ietf-roll-dao-projection'/> d
routes <xref target="I-D.ietf-roll-dao-projection"/>.
</t><t> </t><t>
The 6TiSCH Architecture should thus inherit from the The 6TiSCH architecture should thus inherit from the
<xref target='RFC8655'>DetNet</xref> architecture and <xref target="RFC8655">DetNet architecture</xref> and
thus depends on it. The Path Computation Element (PCE) should be a thus depends on it. The PCE should be a
core component of that architecture. core component of that architecture.
An extension to RPL or to TEAS <xref target='TEAS'/> will be required to An extension to RPL or to TEAS (Traffic Engineering Architecture and Signa ling) <xref target="TEAS"/> will be required to
expose the 6TiSCH node capabilities and the network peers to the PCE, expose the 6TiSCH node capabilities and the network peers to the PCE,
possibly in combination with <xref target='I-D.rahul-roll-mop-ext'/>. possibly in combination with <xref target="I-D.ietf-roll-capabilities"/>.
A protocol such as a lightweight PCEP or an adaptation of CCAMP A protocol such as a lightweight Path Computation Element Communication Pr
<xref target='CCAMP'/> G-MPLS formats and procedures could be used in otocol (PCEP) or an adaptation of
combination to <xref target='I-D.ietf-roll-dao-projection'/> to install Common Control and Measurement Plane (CCAMP)
<xref target="CCAMP"/> GMPLS formats and procedures could be used in
combination to <xref target="I-D.ietf-roll-dao-projection"/> to install
the Tracks, as computed by the PCE, to the 6TiSCH nodes. the Tracks, as computed by the PCE, to the 6TiSCH nodes.
</t> </t>
</section><!-- 6TiSCH Track Setup --> </section>
<section anchor='unchartered-bier'><name>Using BIER in a 6TiSCH Network</n ame> <section anchor="unchartered-bier"><name>Using BIER in a 6TiSCH Network</n ame>
<t> ROLL is actively working on Bit Index <t> ROLL is actively working on Bit Index
Explicit Replication (BIER) as a method to compress both the Explicit Replication (BIER) as a method to compress both the
dataplane packets and the routing tables in storing mode data-plane packets and the routing tables in storing mode
<xref target='I-D.thubert-roll-bier'/>. <xref target="I-D.thubert-roll-bier"/>.
</t> </t>
<t> <t>
BIER could also be used in the context of the DetNet service layer. BIER could also be used in the context of the DetNet service layer.
<xref target='I-D.thubert-bier-replication-elimination'> <xref target="I-D.thubert-bier-replication-elimination">
BIER-TE-based OAM, Replication and Elimination </xref> leverages BIER "BIER-TE extensions for Packet Replication and Elimination Function
Traffic Engineering (TE) to control in the data plane the (PREF) and OAM"</xref> leverages BIER
DetNet Replication and Elimination activities, and to provide traceability Traffic Engineering (TE) to control the
DetNet Replication and Elimination activities in the data plane, and to prov
ide traceability
on links where replication and loss happen, in a manner that is abstract to on links where replication and loss happen, in a manner that is abstract to
the forwarding information. the forwarding information.
</t> </t>
<t> <t>
<xref target='I-D.thubert-6lo-bier-dispatch'>a 6loRH for BitStrings</xref> <xref target="I-D.thubert-6lo-bier-dispatch">"A 6loRH for BitStrings"</xref>
proposes a 6LoWPAN compression for the BIER Bitstring based on proposes a 6LoWPAN compression for the BIER BitString based on
<xref target='RFC8138'>6LoWPAN Routing Header</xref>. <xref target="RFC8138">6LoWPAN Routing Header</xref>.
</t> </t>
</section> <!-- 6TiSCH Track Setup --> </section>
</section>
</section><!-- Unchartered IETF work items -->
<section anchor='external'><name>External (non-IETF) work items</name> <section anchor="external"><name>External (Non-IETF) Work Items</name>
<t> <t>
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 on 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 evolution. 6TiSCH has a strong dependency on IEEE Std 802.15.4 and its evolution.
The impact of changes to TSCH on this Architecture should be minimal to The impact of changes to TSCH on this architecture should be minimal to
non-existent, but deeper work such as 6top and security may be impacted. nonexistent, but deeper work such as 6top and security may be impacted.
A 6TiSCH Interest Group at the IEEE maintains the synchronization A 6TiSCH Interest Group at the IEEE maintains the synchronization
and helps foster work at the IEEE should 6TiSCH demand it. and helps foster work at the IEEE should 6TiSCH demand it.
</t> </t>
<t> <t>
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 sublaye r logically include the 6top sublayer. The interaction with the 6top sublaye r
and the Scheduling Functions described in this document are yet to be and the Scheduling Functions described in this document are yet to be
defined. defined.
</t> </t>
<t> <t>
ISA100 <xref target='ISA100'/> Common Network Management (CNM) is another ISA100 <xref target="ISA100"/> Common Network Management (CNM) is another
external work of interest for 6TiSCH. The group, referred to as ISA100.20, external work of interest for 6TiSCH. The group, referred to as ISA100.20,
defines a Common Network Management framework that should enable the defines a Common Network Management framework that should enable the
management of resources that are controlled by heterogeneous protocols management of resources that are controlled by heterogeneous protocols
such as ISA100.11a <xref target='ISA100.11a'/>, WirelessHART such as ISA100.11a <xref target="ISA100.11a"/>, WirelessHART
<xref target='WirelessHART'/>, and 6TiSCH. Interestingly, the <xref target="WirelessHART"/>, and 6TiSCH. Interestingly, the
establishment of 6TiSCH Deterministic paths, called Tracks, establishment of 6TiSCH deterministic paths, called Tracks,
are also in scope, and ISA100.20 is working on requirements for DetNet. are also in scope, and ISA100.20 is working on requirements for DetNet.
</t> </t>
</section><!-- External IETF work items --> </section>
</section><!--title="Dependencies on Work In Progress"--> </section>
<section numbered="false"><name>Acknowledgments</name>
<section numbered="false" toc="exclude"><name>Special Thanks</name>
<t>
Special thanks to <contact fullname="Jonathan Simon"/>,
<contact fullname="Giuseppe Piro"/>, <contact fullname="Subir Das"/>, and
<contact fullname="Yoshihiro Ohba"/> for their deep contributions to the i
nitial security
work, to <contact fullname="Yasuyuki Tanaka"/> for his work on implementat
ion and simulation
that tremendously helped build a robust system, to <contact fullname="Dieg
o Dujovne"/> for
starting and leading the SF0 effort, and to <contact fullname="Tengfei Cha
ng"/> for evolving it
in the MSF.
</t><t>
Special thanks also to <contact fullname="Pat Kinney"/>,
<contact fullname="Charlie Perkins"/>, and <contact fullname="Bob Heile"/>
for their
support in maintaining the connection active and the design in line with
work happening at IEEE 802.15.
</t> <t>
Special thanks to <contact fullname="Ted Lemon"/>, who was the INT Area Di
rector while this
document was initiated, for his great support and help throughout,
and to <contact fullname="Suresh Krishnan"/>, who took over with that kind
efficiency of his till
publication.
</t><t>
Also special thanks to <contact fullname="Ralph Droms"/>, who performed th
e first INT Area
Directorate review, which was very deep and thorough and radically changed
the orientations of this document, and then to <contact fullname="Eliot Le
ar"/>
and <contact fullname="Carlos Pignataro"/>, who helped finalize this
document in preparation for the IESG reviews,
and to <contact fullname="Gorry Fairhurst"/>,
<contact fullname="David Mandelberg"/>, <contact fullname="Qin Wu"/>,
<contact fullname="Francis Dupont"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Mirja Kühlewind"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Benjamin Kaduk"/>, and <contact fullname="Andrew Malis"/>,
who contributed to the final shaping of this document
through the IESG review procedure.
</t>
</section>
<section numbered="false" toc="exclude"><name>And Do Not Forget</name>
<t>This document is the result of multiple interactions, in
particular during the 6TiSCH (bi)Weekly Interim call, relayed through
the 6TiSCH mailing list at the IETF, over the course of more than 5 years.
</t><t>
The authors wish to thank in arbitrary order:
<contact fullname="Alaeddine Weslati"/>, <contact fullname="Chonggang Wang"/>,
<contact fullname="Georgios Exarchakos"/>, <contact fullname="Zhuo Chen"/>,
<contact fullname="Georgios Papadopoulos"/>, <contact fullname="Eric Levy-Abegno
li"/>,
<contact fullname="Alfredo Grieco"/>, <contact fullname="Bert Greevenbosch"/>,
<contact fullname="Cedric Adjih"/>, <contact fullname="Deji Chen"/>,
<contact fullname="Martin Turon"/>, <contact fullname="Dominique Barthel"/>,
<contact fullname="Elvis Vogli"/>, <contact fullname="Geraldine Texier"/>,
<contact fullname="Guillaume Gaillard"/>, <contact fullname="Herman Storey"/>,
<contact fullname="Kazushi Muraoka"/>, <contact fullname="Ken Bannister"/>,
<contact fullname="Kuor Hsin Chang"/>, <contact fullname="Laurent Toutain"/>,
<contact fullname="Maik Seewald"/>, <contact fullname="Michael Behringer"/>,
<contact fullname="Nancy Cam Winget"/>, <contact fullname="Nicola Accettura"/>,
<contact fullname="Nicolas Montavont"/>, <contact fullname="Oleg Hahm"/>,
<contact fullname="Patrick Wetterwald"/>, <contact fullname="Paul Duffy"/>,
<contact fullname="Peter van der Stok"/>, <contact fullname="Rahul Sen"/>,
<contact fullname="Pieter de Mil"/>, <contact fullname="Pouria Zand"/>,
<contact fullname="Rouhollah Nabati"/>, <contact fullname="Rafa Marin-Lopez"/>,
<contact fullname="Raghuram Sudhaakar"/>, <contact fullname="Sedat Gormus"/>,
<contact fullname="Shitanshu Shah"/>, <contact fullname="Steve Simlo"/>,
<contact fullname="Tina Tsou"/>, <contact fullname="Tom Phinney"/>,
<contact fullname="Xavier Lagrange"/>, <contact fullname="Ines Robles"/>, and
<contact fullname="Samita Chakrabarti"/> for their participation and various con
tributions.
</t>
</section>
</section>
<section numbered="false"><name>Contributors</name>
<t>The co-authors of this document are listed below:
</t><ul empty="true" spacing="normal">
<li><t><contact fullname="Thomas Watteyne"/>
for his contributions to the whole design, in particular on TSCH and s
ecurity,
and to the open source community that he created with openWSN;</t>
</li>
<li><t><contact fullname="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;<
/t>
</li>
<li><t><contact fullname="Kris Pister"/>
for creating TSCH and his continuing guidance through the elaboration
of this design;</t>
</li>
<li><t><contact fullname="Mališa Vučinić"/>
for the work on the one-touch join process and his contribution to the
Security Design Team;</t>
</li>
<li><t><contact fullname="Michael Richardson"/>
for his leadership role in the Security Design Team and his
contribution throughout this document;</t>
</li>
<li><t><contact fullname="Tero Kivinen"/>
for his contribution to the security work in general and the security
section in particular;</t>
</li>
<li><t><contact fullname="Maria Rita Palattella"/>
for managing the Terminology document that was merged into this documen
t through the work of 6TiSCH;</t>
</li>
<li><t><contact fullname="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;</t>
</li>
<li><t><contact fullname="Qin Wang"/>,
who led the design of the 6top sublayer and contributed related text
that was moved and/or adapted into this document;</t>
</li>
<li><t><contact fullname="Rene Struik"/>
for the security section and his contribution to the Security Design
Team;</t>
</li>
<li><t><contact fullname="Robert Assimiti"/>
for his breakthrough work on RPL over TSCH and initial text and
guidance.</t>
</li>
</ul>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 623 change blocks. 
1999 lines changed or deleted 1814 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/