doc: Add RFC documents

1 files changed, 3228 insertions, 0 deletions

diff --git a/doc/rfc/rfc9030.txt b/doc/rfc/rfc9030.txt
new file mode 100644
index 0000000..bfed0b1
--- /dev/null
+++ b/doc/rfc/rfc9030.txt
@@ -0,0 +1,3228 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
+Request for Comments: 9030                                 Cisco Systems
+Category: Informational                                         May 2021
+ISSN: 2070-1721
+
+
+ An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of
+                         IEEE 802.15.4 (6TiSCH)
+
+Abstract
+
+   This document describes a network architecture that provides low-
+   latency, low-jitter, and high-reliability packet delivery.  It
+   combines a high-speed powered backbone and subnetworks using IEEE
+   802.15.4 time-slotted channel hopping (TSCH) to meet the requirements
+   of low-power wireless deterministic applications.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9030.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+     2.1.  New Terms
+     2.2.  Abbreviations
+     2.3.  Related Documents
+   3.  High-Level Architecture
+     3.1.  A Non-broadcast Multi-access Radio Mesh Network
+     3.2.  A Multi-Link Subnet Model
+     3.3.  TSCH: a Deterministic MAC Layer
+     3.4.  Scheduling TSCH
+     3.5.  Distributed vs. Centralized Routing
+     3.6.  Forwarding over TSCH
+     3.7.  6TiSCH Stack
+     3.8.  Communication Paradigms and Interaction Models
+   4.  Architecture Components
+     4.1.  6LoWPAN (and RPL)
+       4.1.1.  RPL-Unaware Leaves and 6LoWPAN ND
+       4.1.2.  6LBR and RPL Root
+     4.2.  Network Access and Addressing
+       4.2.1.  Join Process
+       4.2.2.  Registration
+     4.3.  TSCH and 6top
+       4.3.1.  6top
+       4.3.2.  Scheduling Functions and the 6top Protocol
+       4.3.3.  6top and RPL Objective Function Operations
+       4.3.4.  Network Synchronization
+       4.3.5.  Slotframes and CDU Matrix
+       4.3.6.  Distributing the Reservation of Cells
+     4.4.  Schedule Management Mechanisms
+       4.4.1.  Static Scheduling
+       4.4.2.  Neighbor-to-Neighbor Scheduling
+       4.4.3.  Remote Monitoring and Schedule Management
+       4.4.4.  Hop-by-Hop Scheduling
+     4.5.  On Tracks
+       4.5.1.  General Behavior of Tracks
+       4.5.2.  Serial Track
+       4.5.3.  Complex Track with Replication and Elimination
+       4.5.4.  DetNet End-to-End Path
+       4.5.5.  Cell Reuse
+     4.6.  Forwarding Models
+       4.6.1.  Track Forwarding
+       4.6.2.  IPv6 Forwarding
+       4.6.3.  Fragment Forwarding
+     4.7.  Advanced 6TiSCH Routing
+       4.7.1.  Packet Marking and Handling
+       4.7.2.  Replication, Retries, and Elimination
+   5.  IANA Considerations
+   6.  Security Considerations
+     6.1.  Availability of Remote Services
+     6.2.  Selective Jamming
+     6.3.  MAC-Layer Security
+     6.4.  Time Synchronization
+     6.5.  Validating ASN
+     6.6.  Network Keying and Rekeying
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  Related Work in Progress
+     A.1.  Unchartered IETF Work Items
+       A.1.1.  6TiSCH Zero-Touch Security
+       A.1.2.  6TiSCH Track Setup
+       A.1.3.  Using BIER in a 6TiSCH Network
+     A.2.  External (Non-IETF) Work Items
+   Acknowledgments
+   Contributors
+   Author's Address
+
+1.  Introduction
+
+   Wireless networks enable a wide variety of devices of any size to get
+   interconnected, often at a very low marginal cost per device, at any
+   range, and in circumstances where wiring may be impractical, for
+   instance, on fast-moving or rotating devices.
+
+   On the other hand, Deterministic Networking maximizes the packet
+   delivery ratio within a bounded latency so as to enable mission-
+   critical machine-to-machine (M2M) operations.  Applications that need
+   such networks are presented in [RFC8578] and [RAW-USE-CASES], which
+   presents a number of additional use cases for Reliable and Available
+   Wireless networks (RAW).  The considered applications include
+   professional media, Industrial Automation and Control Systems (IACS),
+   building automation, in-vehicle command and control, commercial
+   automation and asset tracking with mobile scenarios, as well as
+   gaming, drones and edge robotic control, and home automation
+   applications.
+
+   The Time-Slotted Channel Hopping (TSCH) [RFC7554] mode of the IEEE
+   Std 802.15.4 [IEEE802154] Medium Access Control (MAC) was introduced
+   with the IEEE Std 802.15.4e [IEEE802154e] amendment and is now
+   retrofitted in the main standard.  For all practical purposes, this
+   document is expected to be insensitive to the revisions of that
+   standard, which is thus referenced without a date.  TSCH is both a
+   Time-Division Multiplexing (TDM) and a Frequency-Division
+   Multiplexing (FDM) technique, whereby a different channel can be used
+   for each transmission.  TSCH allows the scheduling of transmissions
+   for deterministic operations and applies to the slower and most
+   energy-constrained wireless use cases.
+
+   The scheduled operation provides for a more reliable experience,
+   which can be used to monitor and manage resources, e.g., energy and
+   water, in a more efficient fashion.
+
+   Proven deterministic networking standards for use in process control,
+   including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART],
+   have demonstrated the capabilities of the IEEE Std 802.15.4 TSCH MAC
+   for high reliability against interference, low-power consumption on
+   well-known flows, and its applicability for Traffic Engineering (TE)
+   from a central controller.
+
+   To enable the convergence of information technology (IT) and
+   operational technology (OT) in Low-Power and Lossy Networks (LLNs),
+   the 6TiSCH architecture supports an IETF suite of protocols over the
+   IEEE Std 802.15.4 TSCH MAC to provide IP connectivity for energy and
+   otherwise constrained wireless devices.
+
+   The 6TiSCH architecture relies on IPv6 [RFC8200] and the use of
+   routing to provide large scaling capabilities.  The addition of a
+   high-speed federating backbone adds yet another degree of scalability
+   to the design.  The backbone is typically a Layer 2 transit link such
+   as an Ethernet bridged network, but it can also be a more complex
+   routed structure.
+
+   The 6TiSCH architecture introduces an IPv6 multi-link subnet model
+   that 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 Routers.  If the backbone is a Layer 2 transit link, then
+   the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6
+   ND) proxy [RFC4861].
+
+   The 6TiSCH architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to
+   the constrained media and the Routing Protocol for Low-Power and
+   Lossy Networks (RPL) [RFC6550] for the distributed routing
+   operations.
+
+   Centralized routing refers to a model where routes are computed and
+   resources are allocated from a central controller.  This is
+   particularly helpful to schedule deterministic multihop
+   transmissions.  In contrast, distributed routing refers to a model
+   that relies on concurrent peer-to-peer protocol exchanges for TSCH
+   resource allocation and routing operations.
+
+   The architecture defines mechanisms to establish and maintain routing
+   and scheduling in a centralized, distributed, or mixed fashion, for
+   use in multiple OT environments.  It is applicable in particular to
+   highly scalable solutions such as those used in Advanced Metering
+   Infrastructure [AMI] solutions that leverage distributed routing to
+   enable multipath forwarding over large LLN meshes.
+
+2.  Terminology
+
+2.1.  New Terms
+
+   The document does not reuse terms from the IEEE Std 802.15.4
+   [IEEE802154] standard such as "path" or "link", which bear a meaning
+   that is quite different from classical IETF parlance.
+
+   This document adds the following terms:
+
+   6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4):  6TiSCH defines an
+      adaptation sublayer for IPv6 over TSCH called 6top, a set of
+      protocols for setting up a TSCH schedule in distributed approach,
+      and a security solution. 6TiSCH may be extended in the future for
+      other MAC/Physical Layer (PHY) pairs providing a service similar
+      to TSCH.
+
+   6top (6TiSCH Operation Sublayer):  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, schedules packets over TSCH cells, and
+      exposes a management interface to schedule TSCH cells.
+
+   6P (6top Protocol):  The protocol defined in [RFC8480].  6P enables
+      Layer 2 peers to allocate, move, or de-allocate cells in their
+      respective schedules to communicate.  6P operates at the 6top
+      sublayer.
+
+   6P transaction:  A 2-way or 3-way sequence of 6P messages used by
+      Layer 2 peers to modify their communication schedule.
+
+   ASN (Absolute Slot Number):  Defined in [IEEE802154], the ASN is the
+      total number of timeslots that have elapsed since the Epoch time
+      when the TSCH network started.  Incremented by one at each
+      timeslot.  It is wide enough to not roll over in practice.
+
+   bundle:  A group of equivalent scheduled cells, i.e., cells
+      identified by different slotOffset/channelOffset, which are
+      scheduled for a same purpose, with the same neighbor, with the
+      same flags, and the same slotframe.  The size of the bundle refers
+      to the number of cells it contains.  For a given slotframe length,
+      the size of the bundle translates directly into bandwidth.  A
+      bundle is a local abstraction that represents a half-duplex link
+      for either sending or receiving, with bandwidth that amounts to
+      the sum of the cells in the bundle.
+
+   Layer 2 vs. Layer 3 bundle:  Bundles are associated with either Layer
+      2 (switching) or Layer 3 (routing) forwarding operations.  A pair
+      of Layer 3 bundles (one for each direction) maps to an IP link
+      with a neighbor, whereas a set of Layer 2 bundles (of an
+      "arbitrary" cardinality and direction) corresponds to the relation
+      of one or more incoming bundle(s) from the previous-hop
+      neighbor(s) with one or more outgoing bundle(s) to the next-hop
+      neighbor(s) along a Track as part of the switching role, which may
+      include replication and elimination.
+
+   CCA (Clear Channel Assessment):  A mechanism defined in [IEEE802154]
+      whereby nodes listen to the channel before sending to detect
+      ongoing transmissions from other parties.  Because the network is
+      synchronized, CCA cannot be used to detect colliding transmissions
+      within the same network, but it can be used to detect other radio
+      networks in the vicinity.
+
+   cell:  A unit of transmission resource in the CDU matrix, a cell is
+      identified by a slotOffset and a channelOffset.  A cell can be
+      scheduled or unscheduled.
+
+   Channel Distribution/Usage (CDU) matrix:  : A matrix of cells (i,j)
+      representing the spectrum (channel) distribution among the
+      different nodes in the 6TiSCH network.  The CDU matrix has width
+      in timeslots equal to the period of the network scheduling
+      operation, and height equal to the number of available channels.
+      Every cell (i,j) in the CDU, identified by slotOffset/
+      channelOffset, belongs to a specific chunk.
+
+   channelOffset:  Identifies a row in the TSCH schedule.  The number of
+      channelOffset values is bounded by the number of available
+      frequencies.  The channelOffset translates into a frequency with a
+      function that depends on the absolute time when the communication
+      takes place, resulting in a channel-hopping operation.
+
+   chunk:  A well-known list of cells, distributed in time and
+      frequency, within 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.  A node that manages to appropriate a chunk
+      gets to decide which 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.
+
+   CoJP (Constrained Join Protocol):  The Constrained Join Protocol
+      (CoJP) enables a pledge to securely join a 6TiSCH network and
+      obtain network parameters over a secure channel.  "Constrained
+      Join Protocol (CoJP) for 6TiSCH" [RFC9031] defines the minimal
+      CoJP setup with pre-shared keys defined.  In that mode, CoJP can
+      operate with a single round-trip exchange.
+
+   dedicated cell:  A cell that is reserved for a given node to transmit
+      to a specific neighbor.
+
+   deterministic network:  The generic concept of a deterministic
+      network is defined in the "Deterministic Networking Architecture"
+      [RFC8655] document.  When applied to 6TiSCH, it refers to the
+      reservation of Tracks, which guarantees an end-to-end latency and
+      optimizes the Packet Delivery Ratio (PDR) for well-characterized
+      flows.
+
+   distributed cell reservation:  A reservation of a cell done by one or
+      more in-network entities.
+
+   distributed Track reservation:  A reservation of a Track done by one
+      or more in-network entities.
+
+   EB (Enhanced Beacon):  A special frame defined in [IEEE802154] used
+      by a node, including the Join Proxy (JP), to announce the presence
+      of the network.  It contains enough information for a pledge to
+      synchronize to the network.
+
+   hard cell:  A scheduled cell that the 6top sublayer may not relocate.
+
+   hopping sequence:  Ordered sequence of frequencies, identified by a
+      Hopping_Sequence_ID, used for channel hopping when translating the
+      channelOffset value into a frequency.
+
+   IE (Information Element):  Type-Length-Value containers placed at the
+      end of the MAC header and used to pass data between layers or
+      devices.  Some IE identifiers are managed by the IEEE
+      [IEEE802154].  Some IE identifiers are managed by the IETF
+      [RFC8137].  [RFC9032] uses one subtype to support the selection of
+      the Join Proxy.
+
+   join process:  The overall process that includes the discovery of the
+      network by pledge(s) and the execution of the join protocol.
+
+   join protocol:  The protocol that allows the pledge to join the
+      network.  The join protocol encompasses authentication,
+      authorization, and parameter distribution.  The join protocol is
+      executed between the pledge and the JRC.
+
+   joined node:  The new device after having completed the join process,
+      often just called a node.
+
+   JP (Join Proxy):  A node already part of the 6TiSCH network that
+      serves as a relay to provide connectivity between the pledge and
+      the JRC.  The JP announces the presence of the network by
+      regularly sending EB frames.
+
+   JRC (Join Registrar/Coordinator):  Central entity responsible for the
+      authentication, authorization, and configuration of the pledge.
+
+   link:  A communication facility or medium over which nodes can
+      communicate at the link layer, which is the layer immediately
+      below IP.  In 6TiSCH, the concept is implemented as a collection
+      of Layer 3 bundles.  Note: the IETF parlance for the term "link"
+      is adopted, as opposed to the IEEE Std 802.15.4 terminology.
+
+   operational technology:  OT refers to technology used in automation,
+      for instance in industrial control networks.  The convergence of
+      IT and OT is the main object of the Industrial Internet of Things
+      (IIOT).
+
+   pledge:  A new device that attempts to join a 6TiSCH network.
+
+   (to) relocate a cell:  The action operated by the 6top sublayer of
+      changing the slotOffset and/or channelOffset of a soft cell.
+
+   (to) schedule a cell:  The action of turning an unscheduled cell into
+      a scheduled cell.
+
+   scheduled cell:  A cell that is assigned a neighbor MAC address
+      (broadcast address is also possible) and one or 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 either be a hard or a soft
+      cell.
+
+   SF (6top Scheduling Function):  The cell management entity that adds
+      or deletes cells dynamically based on application networking
+      requirements.  The cell negotiation with a neighbor is done using
+      6P.
+
+   SFID (6top Scheduling Function Identifier):  A 4-bit field
+      identifying an SF.
+
+   shared cell:  A cell marked with both the TX and Shared flags.  This
+      cell can be used by more than one transmitter node.  A back-off
+      algorithm is used to resolve contention.
+
+   slotframe:  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.  Multiple slotframes can coexist in a node's
+      schedule, i.e., a node can have multiple activities scheduled in
+      different slotframes based on the priority of its packets/traffic
+      flows.  The timeslots in the slotframe are indexed by the
+      slotOffset; the first timeslot is at slotOffset 0.
+
+   slotOffset:  A column in the TSCH schedule, i.e., the number of
+      timeslots since the beginning of the current iteration of the
+      slotframe.
+
+   soft cell:  A scheduled cell that the 6top sublayer can relocate.
+
+   time source neighbor:  A neighbor that a node uses as its time
+      reference, and to which it needs to keep its clock synchronized.
+
+   timeslot:  A basic communication unit in TSCH that allows a
+      transmitter node to send a frame to a receiver neighbor and that
+      allows the receiver neighbor to optionally send back an
+      acknowledgment.
+
+   Track:  A Track is a Directed Acyclic Graph (DAG) that is used as a
+      complex multihop path to the destination(s) of the path.  In the
+      case of unicast traffic, the Track is a Destination-Oriented DAG
+      (DODAG) where the Root of the DODAG is the destination of the
+      unicast traffic.  A Track enables replication, elimination, and
+      reordering functions on the way (more on those functions in
+      [RFC8655]).  A Track reservation locks physical resources such as
+      cells and buffers in every node along the DODAG.  A Track is
+      associated with an owner, which can be for instance the
+      destination of the Track.
+
+   TrackID:  A TrackID is either globally unique or locally unique to
+      the Track owner, in which case the identification of the owner
+      must be provided together with the TrackID to provide a full
+      reference to the Track.  Typically, the Track owner is the ingress
+      of the Track, the IPv6 source address of packets along the Track
+      can be used as identification of the owner, and a local InstanceID
+      [RFC6550] in the namespace of that owner can be used as TrackID.
+      If the Track is reversible, then the owner is found in the IPv6
+      destination address of a packet coming back along the Track.  In
+      that case, a RPL Packet Information [RFC6550] in an IPv6 packet
+      can unambiguously identify the Track and can be expressed in a
+      compressed form using [RFC8138].
+
+   TSCH:  A medium access mode of the IEEE Std 802.15.4 [IEEE802154]
+      standard that uses time synchronization to achieve ultra-low-power
+      operation and channel hopping to enable high reliability.
+
+   TSCH Schedule:  A matrix of cells, with each cell indexed by a
+      slotOffset and a channelOffset.  The TSCH schedule contains all
+      the scheduled cells from all slotframes and is sufficient to
+      qualify the communication in the TSCH network.  The number of
+      channelOffset values (the "height" of the matrix) is equal to the
+      number of available frequencies.
+
+   Unscheduled Cell:  A cell that is not used by the IEEE Std 802.15.4
+      TSCH implementation.
+
+2.2.  Abbreviations
+
+   This document uses the following abbreviations:
+
+   6BBR:  6LoWPAN Backbone Router (router with a proxy ND function)
+
+   6LBR:  6LoWPAN Border Router (authoritative on Duplicate Address
+      Detection (DAD))
+
+   6LN:  6LoWPAN Node
+
+   6LR:  6LoWPAN Router (relay to the registration process)
+
+   6CIO:  Capability Indication Option
+
+   (E)ARO:  (Extended) Address Registration Option
+
+   (E)DAR:  (Extended) Duplicate Address Request
+
+   (E)DAC:  (Extended) Duplicate Address Confirmation
+
+   DAD:  Duplicate Address Detection
+
+   DODAG:  Destination-Oriented Directed Acyclic Graph
+
+   LLN:  Low-Power and Lossy Network (a typical IoT network)
+
+   NA:  Neighbor Advertisement
+
+   NCE:  Neighbor Cache Entry
+
+   ND:  Neighbor Discovery
+
+   NDP:  Neighbor Discovery Protocol
+
+   PCE:  Path Computation Element
+
+   NME:  Network Management Entity
+
+   ROVR:  Registration Ownership Verifier (pronounced rover)
+
+   RPL:  IPv6 Routing Protocol for LLNs (pronounced ripple)
+
+   RA:  Router Advertisement
+
+   RS:  Router Solicitation
+
+   TSCH:  Time-Slotted Channel Hopping
+
+   TID:  Transaction ID (a sequence counter in the EARO)
+
+2.3.  Related Documents
+
+   The document conforms to the terms and models described in [RFC3444]
+   and [RFC5889], uses the vocabulary and the concepts defined in
+   [RFC4291] for the IPv6 architecture, and refers to [RFC4080] for
+   reservation.
+
+   The document uses domain-specific terminology defined or referenced
+   in the following:
+
+   *  6LoWPAN ND: "Neighbor Discovery Optimization for IPv6 over
+      Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]
+      and "Registration Extensions for IPv6 over Low-Power Wireless
+      Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505],
+
+   *  "Terms Used in Routing for Low-Power and Lossy Networks"
+      [RFC7102], and
+
+   *  RPL: "Objective Function Zero for the Routing Protocol for
+      Low-Power and Lossy Networks (RPL)" [RFC6552] and "RPL: IPv6
+      Routing Protocol for Low-Power and Lossy Networks" [RFC6550].
+
+   Other terms in use in LLNs are found in "Terminology for
+   Constrained-Node Networks" [RFC7228].
+
+   Readers are expected to be familiar with all the terms and concepts
+   that are discussed in the following:
+
+   *  "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and
+
+   *  "IPv6 Stateless Address Autoconfiguration" [RFC4862].
+
+   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:
+
+   *  "Problem Statement and Requirements for IPv6 over Low-Power
+      Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606],
+
+   *  "Multi-Link Subnet Issues" [RFC4903], and
+
+   *  "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
+      Overview, Assumptions, Problem Statement, and Goals" [RFC4919].
+
+3.  High-Level Architecture
+
+3.1.  A Non-broadcast Multi-access Radio Mesh Network
+
+   A 6TiSCH network is an IPv6 [RFC8200] subnet that, in its basic
+   configuration illustrated in Figure 1, is a single Low-Power and
+   Lossy Network (LLN) operating over a synchronized TSCH-based mesh.
+
+               ---+-------- ............ ------------
+                  |      External Network       |
+                  |                          +-----+
+               +-----+                       | NME |
+               |     | LLN Border            | PCE |
+               |     | router (6LBR)         +-----+
+               +-----+
+             o    o   o
+         o     o   o     o    o
+        o   o 6LoWPAN + RPL o    o
+            o   o   o       o
+
+             Figure 1: Basic Configuration of a 6TiSCH Network
+
+   Inside a 6TiSCH LLN, nodes rely on 6LoWPAN header compression
+   (6LoWPAN HC) [RFC6282] to encode IPv6 packets.  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 collection of links with
+   different capabilities for unicast or multicast services.
+
+   6TiSCH nodes join a mesh network by attaching to nodes that are
+   already members of the mesh (see Section 4.2.1).  The security
+   aspects of the join process are further detailed in Section 6.  In a
+   mesh network, 6TiSCH nodes are not necessarily reachable from one
+   another at Layer 2, and an LLN may span over multiple links.
+
+   This forms a homogeneous non-broadcast multi-access (NBMA) subnet,
+   which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND)
+   [RFC4861] [RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND)
+   [RFC6775] [RFC8505] specifies extensions to IPv6 ND that enable ND
+   operations in this type of subnet that can be protected against
+   address theft and impersonation with [RFC8928].
+
+   Once it has joined the 6TiSCH network, a node acquires IPv6 addresses
+   and registers them using 6LoWPAN ND.  This guarantees that the
+   addresses are unique and protects the address ownership over the
+   subnet, more in Section 4.2.2.
+
+   Within the NBMA subnet, RPL [RFC6550] enables routing in the so-
+   called "route-over" fashion, either in storing (stateful) or non-
+   storing (stateless, with routing headers) mode.  From there, some
+   nodes can act as routers for 6LoWPAN ND and RPL operations, as
+   detailed in Section 4.1.
+
+   With TSCH, devices are time synchronized at the MAC level.  The use
+   of a particular RPL Instance for time synchronization is discussed in
+   Section 4.3.4.  With this mechanism, the time synchronization starts
+   at the RPL Root and follows the RPL loopless routing topology.
+
+   RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs)
+   within Instances of the protocol, each Instance being associated with
+   an Objective Function (OF) to form a routing topology.  A particular
+   6TiSCH node, the LLN Border Router (6LBR), acts as RPL Root, 6LoWPAN
+   HC terminator, and Border Router for the LLN to the outside.  The
+   6LBR is usually powered.  More on RPL Instances can be found in
+   Section 3.1 of RPL [RFC6550], in particular "3.1.2 RPL Identifiers"
+   and "3.1.3 Instances, DODAGs, and DODAG Versions".  RPL adds
+   artifacts in the data packets that are compressed with a 6LoWPAN
+   Routing Header (6LoRH) [RFC8138].  In a preexisting network, the
+   compression can be globally turned on in a DODAG once all nodes are
+   migrated to support [RFC8138] using [RFC9035].
+
+   Additional routing and scheduling protocols may be deployed to
+   establish on-demand, peer-to-peer routes with particular
+   characteristics inside the 6TiSCH network.  This may be achieved in a
+   centralized fashion by a Path Computation Element (PCE) [PCE] that
+   programs both the routes and the schedules inside the 6TiSCH nodes or
+   in a distributed fashion by using a reactive routing protocol and a
+   hop-by-hop scheduling protocol.
+
+   This architecture expects that a 6LoWPAN node can connect as a leaf
+   to a RPL network, where the leaf support is the minimal functionality
+   to connect as a host to a RPL network without the need to participate
+   in the full routing protocol.  The architecture also expects that a
+   6LoWPAN node that is unaware of RPL may also connect as described in
+   [RFC9010].
+
+3.2.  A Multi-Link Subnet Model
+
+   An extended configuration of the subnet comprises multiple LLNs as
+   illustrated in Figure 2.  In the extended configuration, a Routing
+   Registrar [RFC8505] may be connected to the node that acts as the RPL
+   Root and/or 6LoWPAN 6LBR and provides connectivity to the larger
+   campus or factory plant network over a high-speed backbone or a back-
+   haul link.  The Routing Registrar may perform IPv6 ND proxy
+   operations; redistribute the registration in a routing protocol such
+   as OSPF [RFC5340] or BGP [RFC2545]; or inject a route in a mobility
+   protocol such as Mobile IPv6 (MIPv6) [RFC6275], Network Mobility
+   (NEMO) [RFC3963], or Locator/ID Separation Protocol (LISP) [RFC6830].
+
+   Multiple LLNs can be interconnected and possibly synchronized over a
+   backbone, which can be wired or wireless.  The backbone can operate
+   with IPv6 ND procedures [RFC4861] [RFC4862] or a hybrid of IPv6 ND
+   and 6LoWPAN ND [RFC6775] [RFC8505] [RFC8928].
+
+                   |
+                +-----+                +-----+         +-----+
+      (default) |     |     (Optional) |     |         |     | IPv6
+         Router |     |           6LBR |     |         |     | Node
+                +-----+                +-----+         +-----+
+                   |  Backbone side       |               |
+       --------+---+--------------------+-+---------------+------+---
+               |                        |                        |
+         +-----------+            +-----------+            +-----------+
+         | Routing   |            | Routing   |            | Routing   |
+         | Registrar |            | Registrar |            | Registrar |
+         +-----------+            +-----------+            +-----------+
+           o     Wireless side       o  o                     o o
+       o o   o  o                o o   o  o  o          o  o  o  o o
+     o   6TiSCH                o   6TiSCH   o  o          o o  6TiSCH o
+     o   o LLN     o o           o o LLN   o               o     LLN   o
+     o   o  o  o  o            o  o  o o o            o  o    o        o
+
+            Figure 2: Extended Configuration of a 6TiSCH Network
+
+   A Routing Registrar that performs proxy IPv6 ND operations over the
+   backbone on behalf of the 6TiSCH nodes is called a Backbone Router
+   (6BBR) [RFC8929].  The 6BBRs are placed along the wireless edge of a
+   backbone and federate multiple 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 that form the IPv6
+   subnet stay tightly synchronized.
+
+   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 lookup using only unicast request/response exchanges.
+   [ND-UNICAST-LOOKUP] is a proposed method that presents an example of
+   how this could be achieved with an extension of [RFC8505], using an
+   optional 6LBR as a subnet-level registrar, as illustrated in
+   Figure 2.
+
+   As detailed in Section 4.1, the 6LBR that serves the LLN and the Root
+   of the RPL network need to share information about the devices that
+   are learned through either 6LoWPAN ND or RPL, but not both.  The
+   preferred way of achieving this is to co-locate or combine them.  The
+   combined RPL Root and 6LBR may be co-located with the 6BBR, or
+   directly attached to the 6BBR.  In the latter case, it leverages the
+   extended registration process defined in [RFC8505] to proxy the
+   6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so
+   that the 6BBR may in turn perform classical ND operations over the
+   backbone as a proxy.
+
+   The "Deterministic Networking Architecture" [RFC8655] studies Layer 3
+   aspects of Deterministic Networks and covers networks that span
+   multiple Layer 2 domains.  If the backbone is deterministic (such as
+   defined by the Time-Sensitive Networking (TSN) Task Group at IEEE),
+   then the Backbone Router ensures that the end-to-end deterministic
+   behavior is maintained between the LLN and the backbone.
+
+3.3.  TSCH: a Deterministic MAC Layer
+
+   Though at a different time scale (several orders of magnitude), both
+   IEEE Std 802.1 TSN and IEEE Std 802.15.4 TSCH standards provide
+   deterministic capabilities to the point that a packet pertaining to a
+   certain flow may traverse a network from node to node following a
+   precise schedule, as a train that enters and then leaves intermediate
+   stations at precise times along its path.
+
+   With TSCH, time is formatted into timeslots, and individual
+   communication cells are allocated to unicast or broadcast
+   communication at the MAC level.  The time-slotted operation reduces
+   collisions, saves energy, and enables more closely engineering the
+   network for deterministic properties.  The channel-hopping aspect is
+   a simple and efficient technique to combat multipath fading and co-
+   channel interference.
+
+   6TiSCH builds on the IEEE Std 802.15.4 TSCH MAC and inherits its
+   advanced capabilities to enable them in multiple environments where
+   they can be leveraged to improve automated operations.  The 6TiSCH
+   architecture also inherits the capability to perform a centralized
+   route computation to achieve deterministic properties, though it
+   relies on the IETF DetNet architecture [RFC8655] and IETF components
+   such as the PCE [PCE] for the protocol aspects.
+
+   On top of this inheritance, 6TiSCH adds capabilities for distributed
+   routing and scheduling operations based on RPL and capabilities for
+   negotiating schedule adjustments between peers.  These distributed
+   routing and scheduling operations simplify the deployment of TSCH
+   networks and enable wireless solutions in a larger variety of use
+   cases from operational technology in general.  Examples of such use
+   cases in industrial environments include plant setup and
+   decommissioning, as well as monitoring a multiplicity of minor
+   notifications such as corrosion measurements, events, and access of
+   local devices by mobile workers.
+
+3.4.  Scheduling TSCH
+
+   A scheduling operation allocates cells in a TDM/FDM matrix called a
+   CDU either to individual transmissions or as multi-access shared
+   resources.  The CDU matrix can be formatted in chunks that can be
+   allocated exclusively to particular nodes to enable distributed
+   scheduling without collision.  More in Section 4.3.5.
+
+   At the MAC layer, the schedule of a 6TiSCH node 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 at those times.
+   The schedule is expressed as one or more repeating slotframes.
+   Slotframes may collide and require a device to wake up at a same
+   time, in which case the slotframe with the highest priority is
+   actionable.
+
+   The 6top sublayer (see Section 4.3 for more) hides the 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, one
+   to receive and one to transmit.  Some of the cells may be shared, in
+   which case the 6top sublayer must perform some arbitration.
+
+   Scheduling enables multiple simultaneous communications in a same
+   interference domain using different channels; but a node equipped
+   with a single radio can only either transmit or receive on one
+   channel at any point of time.  Scheduled cells that fulfill the same
+   role, e.g., receive IP packets from a peer, are grouped in bundles.
+
+   The 6TiSCH architecture identifies four ways a schedule can be
+   managed and CDU cells can be allocated: Static Scheduling, Neighbor-
+   to-Neighbor Scheduling, Centralized (or Remote) Monitoring and
+   Schedule Management, and Hop-by-Hop Scheduling.
+
+   Static Scheduling:  This refers to the minimal 6TiSCH operation
+      whereby a static schedule is configured for the whole network for
+      use in a Slotted ALOHA [S-ALOHA] fashion.  The static schedule is
+      distributed through the native methods in the TSCH MAC layer and
+      does not preclude other scheduling operations coexisting on a same
+      6TiSCH network.  A static schedule is necessary for basic
+      operations such as the join process and for interoperability
+      during the network formation, which is specified as part of the
+      Minimal 6TiSCH Configuration [RFC8180].
+
+   Neighbor-to-Neighbor Scheduling:  This refers to the dynamic
+      adaptation of the bandwidth of the links that are used for IPv6
+      traffic between adjacent peers.  Scheduling Functions such as the
+      "6TiSCH Minimal Scheduling Function (MSF)" [RFC9033] influence the
+      operation of the MAC layer to add, update, and remove cells in its
+      own and its peer's schedules using 6P [RFC8480] for the
+      negotiation of the MAC resources.
+
+   Centralized (or Remote) Monitoring and Schedule Management:  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,
+      the related portion of the device schedule as well as other device
+      resources are managed by an abstract Network Management Entity
+      (NME), which may cooperate with the PCE to minimize the
+      interaction with, and the load on, the constrained device.  This
+      model is the TSCH adaption of the DetNet architecture [RFC8655],
+      and it enables Traffic Engineering with deterministic properties.
+
+   Hop-by-Hop Scheduling:  This refers to the possibility of reserving
+      cells along a path for a particular flow using a distributed
+      mechanism.
+
+   It is not expected that all use cases will require all those
+   mechanisms.  Static Scheduling with minimal configuration is the only
+   one that is expected in all implementations, since it provides a
+   simple and solid basis for convergecast routing and time
+   distribution.
+
+   A deeper dive into those mechanisms can be found in Section 4.4.
+
+3.5.  Distributed vs. Centralized Routing
+
+   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.  6TiSCH leverages RPL [RFC6550] for
+   interoperable, distributed routing operations.
+
+   Both methods may inject routes into the routing tables of the 6TiSCH
+   routers.  In either case, each route is associated with a 6TiSCH
+   topology that can be a RPL Instance topology or a Track.  The 6TiSCH
+   topology is indexed by a RPLInstanceID, in a format that reuses the
+   RPLInstanceID as defined in RPL.
+
+   RPL [RFC6550] is applicable to Static Scheduling and Neighbor-to-
+   Neighbor Scheduling.  The architecture also supports a centralized
+   routing model for Remote Monitoring and Schedule Management.  It is
+   expected that a routing protocol that is more optimized for point-to-
+   point routing than RPL [RFC6550], such as the "Asymmetric
+   AODV-P2P-RPL in Low-Power and Lossy Networks" (AODV-RPL) [AODV-RPL],
+   which derives from the "Ad Hoc On-demand Distance Vector (AODVv2)
+   Routing" [AODVv2], will be selected for Hop-by-Hop Scheduling.
+
+   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 for centralized and distributed routing to share the
+   same topology.  Generally they will operate in different slotframes,
+   and centralized routes will be used for scheduled traffic and will
+   have precedence over distributed routes in case of conflict between
+   the slotframes.
+
+3.6.  Forwarding over TSCH
+
+   The 6TiSCH architecture supports three different forwarding models.
+   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 table.  The second derives from Generalized MPLS (GMPLS) for
+   so-called Track Forwarding, whereby a frame received at a particular
+   timeslot can be switched into another timeslot at Layer 2 without
+   regard to the upper-layer protocol.  The third model is the 6LoWPAN
+   Fragment Forwarding, which allows the forwarding individual 6LoWPAN
+   fragments along a route that is set up by the first fragment.
+
+   In more detail:
+
+   IPv6 Forwarding:  This is the classical IP forwarding model, with a
+      Routing Information Base (RIB) that is installed by RPL and used
+      to select a feasible successor per packet.  The packet is placed
+      on an outgoing link, which the 6top sublayer maps into a (Layer 3)
+      bundle of cells, and scheduled for transmission based on QoS
+      parameters.  Besides RPL, this model also applies to any routing
+      protocol that may be operated in the 6TiSCH network and
+      corresponds to all the distributed scheduling models: Static,
+      Neighbor-to-Neighbor, and Hop-by-Hop Scheduling.
+
+   GMPLS Track Forwarding:  This model corresponds to the Remote
+      Monitoring and Schedule Management.  In this model, a central
+      controller (hosting a PCE) computes and installs the schedules in
+      the devices per flow.  The incoming (Layer 2) bundle of cells from
+      the previous node along the path determines the outgoing (Layer 2)
+      bundle 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 shapes that are more complex than a simple direct
+      sequence of nodes.
+
+   6LoWPAN Fragment Forwarding:  This is a hybrid model that derives
+      from IPv6 forwarding for the case where packets must be fragmented
+      at the 6LoWPAN sublayer.  The first fragment is forwarded like any
+      IPv6 packet and leaves a state in the intermediate hops to enable
+      forwarding of the next fragments that do not have an IP header
+      without the need to recompose the packet at every hop.
+
+   A deeper dive into these operations can be found in Section 4.6.
+
+   Table 1 summarizes how the forwarding models apply to the various
+   routing and scheduling possibilities:
+
+          +==================+==========+======================+
+          | Forwarding Model | Routing  | Scheduling           |
+          +==================+==========+======================+
+          | classical IPv6 / | RPL      | Static (Minimal      |
+          | 6LoWPAN Fragment |          | Configuration)       |
+          |                  |          +----------------------+
+          |                  |          | Neighbor-to-Neighbor |
+          |                  |          | (SF+6P)              |
+          |                  +----------+----------------------+
+          |                  | Reactive | Hop-by-Hop (AODV-    |
+          |                  |          | RPL)                 |
+          +------------------+----------+----------------------+
+          | GMPLS Track      | PCE      | Remote Monitoring    |
+          | Forwarding       |          | and Schedule Mgt     |
+          +------------------+----------+----------------------+
+
+                                 Table 1
+
+3.7.  6TiSCH Stack
+
+   The IETF proposes multiple techniques for implementing functions
+   related to routing, transport, or security.
+
+   The 6TiSCH architecture limits the possible variations of the stack
+   and recommends a number of base elements for LLN applications to
+   control the complexity of possible deployments and device
+   interactions and to limit the size of the resulting object code.  In
+   particular, UDP [RFC0768], IPv6 [RFC8200], and the Constrained
+   Application Protocol (CoAP) [RFC7252] are used as the transport/
+   binding of choice for applications and management as opposed to TCP
+   and HTTP.
+
+   The resulting protocol stack is represented in Figure 3:
+
+      +--------+--------+
+      | Applis |  CoJP  |
+      +--------+--------+--------------+-----+
+      | CoAP / OSCORE   |  6LoWPAN ND  | RPL |
+      +-----------------+--------------+-----+
+      |       UDP       |      ICMPv6        |
+      +-----------------+--------------------+
+      |                 IPv6                 |
+      +--------------------------------------+----------------------+
+      |     6LoWPAN HC   /   6LoRH HC        | Scheduling Functions |
+      +--------------------------------------+----------------------+
+      |               6top inc. 6top Protocol                       |
+      +-------------------------------------------------------------+
+      |                 IEEE Std 802.15.4 TSCH                      |
+      +-------------------------------------------------------------+
+
+                      Figure 3: 6TiSCH Protocol Stack
+
+   RPL is the routing protocol of choice for LLNs.  So far, there is no
+   identified need to define a 6TiSCH-specific Objective Function.  The
+   Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL
+   over a static schedule used in a Slotted ALOHA fashion [S-ALOHA],
+   whereby all active slots may be used for emission or reception of
+   both unicast and multicast frames.
+
+   6LoWPAN header compression [RFC6282] is used to compress the IPv6 and
+   UDP headers, whereas the 6LoWPAN Routing Header (6LoRH) [RFC8138] is
+   used to compress the RPL artifacts in the IPv6 data packets,
+   including the RPL Packet Information (RPI), the IP-in-IP
+   encapsulation to/from the RPL Root, and the Source Routing Header
+   (SRH) in non-storing mode.  "Using RPI Option Type, Routing Header
+   for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data
+   Plane" [RFC9008] provides the details on when headers or
+   encapsulation are needed.
+
+   The Object Security for Constrained RESTful Environments (OSCORE)
+   [RFC8613] is leveraged by the Constrained Join Protocol (CoJP) and is
+   expected to be the primary protocol for the protection of the
+   application payload as well.  The application payload may also be
+   protected by the Datagram Transport Layer Security (DTLS) [RFC6347]
+   sitting either under CoAP or over CoAP so it can traverse proxies.
+
+   The 6TiSCH Operation Sublayer (6top) is a sublayer of a Logical Link
+   Control (LLC) that provides the abstraction of an IP link over a TSCH
+   MAC and schedules packets over TSCH cells, as further discussed in
+   the next sections, providing in particular dynamic cell allocation
+   with the 6top Protocol (6P) [RFC8480].
+
+   The reference stack presented in this document was implemented and
+   interoperability-tested by a combination of open source, IETF, and
+   ETSI efforts.  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.
+
+   For a particular environment, some of the choices that are available
+   in this architecture may not 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 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 of the
+   selection that is presented hereafter and then select alternate
+   components to complete the solution wherever needed.
+
+3.8.  Communication Paradigms and Interaction Models
+
+   Section 2.1 provides the terms of Communication Paradigms and
+   Interaction Models in combination with "On the Difference between
+   Information Models and Data Models" [RFC3444].  A Communication
+   Paradigm is an abstract view of a protocol exchange and has an
+   Information Model for the information that is being exchanged.  In
+   contrast, an Interaction Model is more refined and points to standard
+   operation such as a Representational State Transfer (REST) "GET"
+   operation and matches a Data Model for the data that is provided over
+   the protocol exchange.
+
+   Section 2.1.3 of [RPL-APPLICABILITY] 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.
+
+   Additional considerations on duocast -- one sender, two receivers for
+   redundancy -- and its N-cast generalization are also provided.  Those
+   paradigms are frequently used in industrial automation, which is a
+   major use case for IEEE Std 802.15.4 TSCH wireless networks with
+   [ISA100.11a] and [WirelessHART], which provides a wireless access to
+   [HART] applications and devices.
+
+   This document focuses on Communication Paradigms and Interaction
+   Models for packet forwarding and TSCH resources (cells) management.
+   Management mechanisms for the TSCH schedule at the link layer (one
+   hop), network layer (multihop along a Track), and application layer
+   (remote control) are discussed in Section 4.4.  Link-layer frame
+   forwarding interactions are discussed in Section 4.6, and network-
+   layer packet routing is addressed in Section 4.7.
+
+4.  Architecture Components
+
+4.1.  6LoWPAN (and RPL)
+
+   A RPL DODAG is formed of a Root, a collection of routers, and leaves
+   that are hosts.  Hosts are nodes that do not forward packets that
+   they did not generate.  RPL-aware leaves will participate in RPL to
+   advertise their own addresses, whereas RPL-unaware leaves depend on a
+   connected RPL router to do so.  RPL interacts with 6LoWPAN ND at
+   multiple levels, in particular at the Root and in the RPL-unaware
+   leaves.
+
+4.1.1.  RPL-Unaware Leaves and 6LoWPAN ND
+
+   RPL needs a set of information to advertise a leaf node through a
+   Destination Advertisement Object (DAO) message and establish
+   reachability.
+
+   "Routing for RPL Leaves" [RFC9010] details the basic interaction of
+   6LoWPAN ND and RPL and enables a plain 6LN that supports [RFC8505] to
+   obtain return connectivity via the RPL network as a RPL-unaware leaf.
+   The leaf indicates that it requires reachability services for the
+   Registered Address from a Routing Registrar by setting an 'R' flag in
+   the Extended Address Registration Option [RFC8505], and it provides a
+   TID that maps to the "Path Sequence" defined in Section 6.7.8 of
+   [RFC6550], and its operation is defined in Section 7.2 of [RFC6550].
+
+   [RFC9010] also enables the leaf to signal with the RPLInstanceID that
+   it wants to participate by using the Opaque field of the EARO.  On
+   the backbone, the RPLInstanceID is expected to be mapped to an
+   overlay that matches the RPL Instance, e.g., a Virtual LAN (VLAN) or
+   a virtual routing and forwarding (VRF) instance.
+
+   Though, at the time of this writing, the above specification enables
+   a model where the separation is possible, this architecture
+   recommends co-locating the functions of 6LBR and RPL Root.
+
+4.1.2.  6LBR and RPL Root
+
+   With the 6LoWPAN ND [RFC6775], information on the 6LBR is
+   disseminated via an Authoritative Border Router Option (ABRO) in RA
+   messages.  [RFC8505] extends [RFC6775] to enable a registration for
+   routing and proxy ND.  The capability to support [RFC8505] is
+   indicated in the 6LoWPAN Capability Indication Option (6CIO).  The
+   discovery and liveliness of the RPL Root are obtained through RPL
+   [RFC6550] itself.
+
+   When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root
+   functionalities are co-located in order that the address of the 6LBR
+   is indicated by RPL DODAG Information Object (DIO) messages and to
+   associate the ROVR from the Extended Duplicate Address Request/
+   Confirmation (EDAR/EDAC) exchange [RFC8505] with the state that is
+   maintained by RPL.
+
+   Section 7 of [RFC9010] specifies how the DAO messages are used to
+   reconfirm the registration, thus eliminating a duplication of
+   functionality between DAO and EDAR/EDAC messages, as illustrated in
+   Figure 6.  [RFC9010] also provides the protocol elements that are
+   needed when the 6LBR and RPL Root functionalities are not co-located.
+
+   Even though the Root of the RPL network is integrated with the 6LBR,
+   it is logically separated from the Backbone Router (6BBR) that 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 devices
+   attached to it.
+
+   This architecture also expects that the Root of the RPL network
+   (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, for
+   whatever operation the 6BBR performs on the backbone, such as ND
+   proxy or redistribution in a routing protocol.  This relies on an
+   extension of the 6LoWPAN ND registration described in [RFC8929].
+
+   This model supports the movement of a 6TiSCH device across the multi-
+   link subnet and allows the proxy registration of 6TiSCH nodes deep
+   into the 6TiSCH LLN by the 6LBR / RPL Root.  This is why in [RFC8505]
+   the Registered Address is signaled in the Target Address field of the
+   Neighbor Solicitation (NS) message as opposed to the IPv6 Source
+   Address, which, in the case of a proxy registration, is that of the
+   6LBR / RPL Root itself.
+
+4.2.  Network Access and Addressing
+
+4.2.1.  Join Process
+
+   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 first powered on.  The pledge communicates with
+   the Join Registrar/Coordinator (JRC) of the network through a Join
+   Proxy (JP), a radio neighbor of the pledge.
+
+   The JP is discovered though MAC-layer beacons.  When multiple JPs
+   from possibly multiple networks are visible, using trial and error
+   until an acceptable position in the right network is obtained becomes
+   inefficient.  [RFC9032] adds a new subtype in the Information Element
+   that was delegated to the IETF [RFC8137] and provides visibility into
+   the network that can be joined and the willingness of the JP and the
+   Root to be used by the pledge.
+
+   The join protocol provides the following functionality:
+
+   *  Mutual authentication
+
+   *  Authorization
+
+   *  Parameter distribution to the pledge over a secure channel
+
+   The Minimal Security Framework for 6TiSCH [RFC9031] defines the
+   minimal mechanisms required for this join process to occur in a
+   secure manner.  The specification defines the Constrained Join
+   Protocol (CoJP), which is used to distribute the parameters to the
+   pledge over a secure session established through OSCORE [RFC8613] and
+   which describes the secure configuration of the network stack.  In
+   the minimal setting with pre-shared keys (PSKs), CoJP allows the
+   pledge to join after a single round-trip exchange with the JRC.  The
+   provisioning of the PSK to the pledge and the JRC needs to be done
+   out of band, through a 'one-touch' bootstrapping process, which
+   effectively enrolls the pledge into the domain managed by the JRC.
+
+   In certain use cases, the 'one-touch' bootstrapping is not feasible
+   due to the operational constraints, and the enrollment of the pledge
+   into the domain needs to occur in-band.  This is handled through a
+   'zero-touch' extension of the Minimal Security Framework for 6TiSCH.
+   The zero-touch extension [ZEROTOUCH-JOIN] leverages the
+   "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" [RFC8995]
+   work to establish a shared secret between a pledge and the JRC
+   without necessarily having them belong to a common (security) domain
+   at join time.  This happens through inter-domain communication
+   occurring between the JRC of the network and the domain of the
+   pledge, represented by a fourth entity, Manufacturer Authorized
+   Signing Authority (MASA).  Once the zero-touch exchange completes,
+   the CoJP exchange defined in [RFC9031] is carried over the secure
+   session established between the pledge and the JRC.
+
+   Figure 4 depicts the join process and where a Link-Local Address
+   (LLA) is used, versus a Global Unicast Address (GUA).
+
+   6LoWPAN Node       6LR           6LBR      Join Registrar     MASA
+    (pledge)       (Join Proxy)     (Root)    /Coordinator (JRC)
+     |               |               |              |              |
+     |  6LoWPAN ND   |6LoWPAN ND+RPL | IPv6 network |IPv6 network  |
+     |   LLN link    |Route-Over mesh|(the Internet)|(the Internet)|
+     |               |               |              |              |
+     |   Layer 2     |               |              |              |
+     |Enhanced Beacon|               |              |              |
+     |<--------------|               |              |              |
+     |               |               |              |              |
+     |    NS (EARO)  |               |              |              |
+     | (for the LLA) |               |              |              |
+     |-------------->|               |              |              |
+     |    NA (EARO)  |               |              |              |
+     |<--------------|               |              |              |
+     |               |               |              |              |
+     |  (Zero-touch  |               |              |              |
+     |   handshake)  |     (Zero-touch handshake)   | (Zero-touch  |
+     |   using LLA   |           using GUA          |  handshake)  |
+     |<------------->|<---------------------------->|<------------>|
+     |               |               |              |              |
+     | CoJP Join Req |               |              |              | \
+     |  using LLA    |               |              |              | |
+     |-------------->|               |              |              | |
+     |               |       CoJP Join Request      |              | |
+     |               |           using GUA          |              | |
+     |               |----------------------------->|              | | C
+     |               |               |              |              | | o
+     |               |       CoJP Join Response     |              | | J
+     |               |           using GUA          |              | | P
+     |               |<-----------------------------|              | |
+     |CoJP Join Resp |               |              |              | |
+     |  using LLA    |               |              |              | |
+     |<--------------|               |              |              | /
+     |               |               |              |              |
+
+       Figure 4: Join Process in a Multi-Link Subnet.  Parentheses ()
+                         denote optional exchanges.
+
+4.2.2.  Registration
+
+   Once the pledge successfully completes the CoJP exchange and becomes
+   a network node, it obtains the network prefix from neighboring
+   routers and registers its IPv6 addresses.  As detailed in
+   Section 4.1, the combined 6LoWPAN ND 6LBR and Root of the RPL network
+   learn information such as an identifier (device EUI-64 [RFC6775] or a
+   ROVR [RFC8505] (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.
+
+   Figure 5 illustrates the initial IPv6 signaling that enables a 6LN to
+   form a global address and register it to a 6LBR using 6LoWPAN ND
+   [RFC8505].  It is then carried over RPL to the RPL Root and then to
+   the 6BBR.  This flow happens just once when the address is created
+   and first registered.
+
+       6LoWPAN Node        6LR             6LBR            6BBR
+        (RPL leaf)       (router)         (Root)
+            |               |               |               |
+            |  6LoWPAN ND   |6LoWPAN ND+RPL | 6LoWPAN ND    | IPv6 ND
+            |   LLN link    |Route-Over mesh|Ethernet/serial| Backbone
+            |               |               |               |
+            |  RS (mcast)   |               |               |
+            |-------------->|               |               |
+            |----------->   |               |               |
+            |------------------>            |               |
+            |  RA (unicast) |               |               |
+            |<--------------|               |               |
+            |               |               |               |
+            |  NS(EARO)     |               |               |
+            |-------------->|               |               |
+            | 6LoWPAN ND    | Extended DAR  |               |
+            |               |-------------->|               |
+            |               |               |  NS(EARO)     |
+            |               |               |-------------->|
+            |               |               |               | NS-DAD
+            |               |               |               |------>
+            |               |               |               | (EARO)
+            |               |               |               |
+            |               |               |  NA(EARO)     |<timeout>
+            |               |               |<--------------|
+            |               | Extended DAC  |               |
+            |               |<--------------|               |
+            |  NA(EARO)     |               |               |
+            |<--------------|               |               |
+            |               |               |               |
+
+         Figure 5: Initial Registration Flow over Multi-Link Subnet
+
+   Figure 6 illustrates the repeating IPv6 signaling that enables a 6LN
+   to keep a global address alive and registered with its 6LBR using
+   6LoWPAN ND to the 6LR, RPL to the RPL Root, and then 6LoWPAN ND again
+   to the 6BBR, which avoids repeating the Extended DAR/DAC flow across
+   the network when RPL can suffice as a keep-alive mechanism.
+
+    6LoWPAN Node        6LR             6LBR            6BBR
+     (RPL leaf)       (router)         (Root)
+         |               |               |               |
+         |  6LoWPAN ND   |6LoWPAN ND+RPL | 6LoWPAN ND    | IPv6 ND
+         |   LLN link    |Route-Over mesh| ant IPv6 link | Backbone
+         |               |               |
+         |               |               |               |
+         |  NS(EARO)     |               |               |
+         |-------------->|               |               |
+         |  NA(EARO)     |               |               |
+         |<--------------|               |               |
+         |               | DAO           |               |
+         |               |-------------->|               |
+         |               | DAO-ACK       |               |
+         |               |<--------------|               |
+         |               |               |  NS(EARO)     |
+         |               |               |-------------->|
+         |               |               |  NA(EARO)     |
+         |               |               |<--------------|
+         |               |               |               |
+         |               |               |               |
+
+          Figure 6: Next Registration Flow over Multi-Link Subnet
+
+   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 router and a
+   6LR, so as to accept leaf nodes recursively joining the network.
+
+4.3.  TSCH and 6top
+
+4.3.1.  6top
+
+   6TiSCH expects a high degree of scalability together with a
+   distributed routing functionality based on RPL.  To achieve this
+   goal, the spectrum must be allocated in a way that allows for spatial
+   reuse between zones that will not interfere with one another.  In a
+   large and spatially distributed network, a 6TiSCH node is often in a
+   good position to determine usage of the spectrum in its vicinity.
+
+   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
+   enabled between RPL parents and children.  The 6TiSCH operation is
+   optimal when the size of a bundle minimizes both the energy wasted in
+   idle listening and the packet drops due to congestion loss, while
+   packets are forwarded within an acceptable latency.
+
+   Use cases for distributed routing are often associated with a
+   statistical distribution of best-effort traffic with variable needs
+   for bandwidth on each individual link.  The 6TiSCH operation can
+   remain optimal if RPL parents can adjust, dynamically and with enough
+   reactivity to match the variations of best-effort traffic, the amount
+   of bandwidth that is used to communicate between themselves and their
+   children, in both directions.  In turn, the agility to fulfill the
+   needs for additional cells improves when the number of interactions
+   with other devices and the protocol latencies are minimized.
+
+   6top is a logical link control sitting between the IP layer and the
+   TSCH MAC layer, which provides the link abstraction that is required
+   for IP operations.  The 6top Protocol, 6P, which is specified in
+   [RFC8480], is one of the services provided by 6top.  In particular,
+   the 6top services are available over a management API that enables an
+   external management entity to schedule cells and slotframes, and
+   allows the addition of complementary functionality, for instance, a
+   Scheduling Function that manages a dynamic schedule based on observed
+   resource usage as discussed in Section 4.4.2.  For this purpose, the
+   6TiSCH architecture differentiates "soft" cells and "hard" cells.
+
+4.3.1.1.  Hard Cells
+
+   "Hard" cells are cells that are owned and managed by a separate
+   scheduling entity (e.g., a PCE) that specifies the slotOffset/
+   channelOffset of the cells to be 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.
+
+4.3.1.2.  Soft Cells
+
+   In contrast, "soft" cells are cells that 6top can manage locally.
+   6top contains a monitoring process that monitors the performance of
+   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
+   reserve a soft cell, the higher layer does not indicate the exact
+   slotOffset/channelOffset of the cell to add, but rather the resulting
+   bandwidth and QoS requirements.  When the monitoring process triggers
+   a cell reallocation, the two neighbor devices communicating over this
+   cell negotiate its new position in the TSCH schedule.
+
+4.3.2.  Scheduling Functions and the 6top Protocol
+
+   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 is called a Scheduling Function (SF).
+
+   There may be multiple SFs that react more or less aggressively to the
+   dynamics of the network.
+
+   An SF may be seen as divided between an upper bandwidth-adaptation
+   logic that is unaware of the particular technology used to obtain and
+   release bandwidth and an underlying service that maps those needs in
+   the actual technology.  In the case of TSCH using the 6top Protocol
+   as illustrated in Figure 7, this means mapping the bandwidth onto
+   cells.
+
+    +------------------------+          +------------------------+
+    |  Scheduling Function   |          |  Scheduling Function   |
+    |  Bandwidth adaptation  |          |  Bandwidth adaptation  |
+    +------------------------+          +------------------------+
+    |  Scheduling Function   |          |  Scheduling Function   |
+    | TSCH mapping to cells  |          | TSCH mapping to cells  |
+    +------------------------+          +------------------------+
+    | 6top cells negotiation | <- 6P -> | 6top cells negotiation |
+    +------------------------+          +------------------------+
+            Device A                             Device B
+
+                       Figure 7: SF/6P Stack in 6top
+
+   The SF relies on 6top services that implement the 6top Protocol (6P)
+   [RFC8480] to negotiate the precise cells that will be allocated or
+   freed based on the schedule of the peer.  For instance, it may be
+   that a peer wants to use a particular timeslot that is free in its
+   schedule, but that timeslot is already in use by the other peer to
+   communicate with a third party on a different cell. 6P enables the
+   peers to find an agreement in a transactional manner that ensures the
+   final consistency of the nodes' state.
+
+   MSF [RFC9033] is one of the possible Scheduling Functions.  MSF uses
+   the rendezvous slot from [RFC8180] for network discovery, neighbor
+   discovery, and any other broadcast.
+
+   For basic unicast communication with any neighbor, each node uses a
+   receive cell at a well-known slotOffset/channelOffset, which is
+   derived from a hash of their own MAC address.  Nodes can reach any
+   neighbor by installing a transmit (shared) cell with slotOffset/
+   channelOffset derived from the neighbor's MAC address.
+
+   For child-parent links, MSF continuously monitors the load between
+   parents and children.  It then uses 6P to install or remove unicast
+   cells whenever the current schedule appears to be under-provisioned
+   or over-provisioned.
+
+4.3.3.  6top and RPL Objective Function Operations
+
+   An implementation of a RPL [RFC6550] Objective Function (OF), such as
+   the RPL Objective Function Zero (OF0) [RFC6552] that is used in the
+   Minimal 6TiSCH Configuration [RFC8180] to support RPL over a static
+   schedule, may leverage for its internal computation the information
+   maintained by 6top.
+
+   An OF may require metrics about reachability, such as the Expected
+   Transmission Count (ETX) metric [RFC6551].  6top creates and
+   maintains an abstract neighbor table, and this state may be leveraged
+   to feed an OF and/or store OF information as well.  A neighbor table
+   entry may contain a set of statistics with respect to that specific
+   neighbor.
+
+   The neighbor information may include the time when the last packet
+   has been received from that neighbor, a set of cell quality metrics,
+   e.g., received signal strength indication (RSSI) or link quality
+   indicator (LQI), the number of packets sent to the neighbor, or the
+   number of packets received from it.  This information can be made
+   available through 6top management APIs and used, for instance, to
+   compute a Rank Increment that will determine the selection of the
+   preferred parent.
+
+   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 influence the MAC behavior, for instance, by configuring the
+   periodicity of IEEE Std 802.15.4 Extended Beacons (EBs).  By
+   augmenting the EB periodicity, it is possible to change the network
+   dynamics so as to improve the support of devices that may change
+   their point of attachment in the 6TiSCH network.
+
+   Some RPL control messages, such as the DODAG Information Object
+   (DIO), are ICMPv6 messages that are broadcast to all neighbor nodes.
+   With 6TiSCH, the broadcast channel requirement is addressed by 6top
+   by configuring TSCH to provide a broadcast channel, as opposed to,
+   for instance, piggybacking the DIO messages in Layer 2 Enhanced
+   Beacons (EBs), which would produce undue timer coupling among layers
+   and packet size issues, and could conflict with the policy of
+   production networks where EBs are mostly eliminated to conserve
+   energy.
+
+4.3.4.  Network Synchronization
+
+   Nodes in a TSCH network must be time synchronized.  A node keeps
+   synchronized to its time source neighbor through a combination of
+   frame-based and acknowledgment-based synchronization.  To maximize
+   battery life and network throughput, it is advisable that RPL ICMP
+   discovery and maintenance traffic (governed by the Trickle timer) be
+   somehow coordinated with the transmission of time synchronization
+   packets (especially with Enhanced Beacons).
+
+   This could be achieved through an interaction of the 6top sublayer
+   and the RPL Objective Function, or could be controlled by a
+   management entity.
+
+   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 RPL DAG with a dedicated global
+   Instance for the purpose of time synchronization.  That Instance is
+   referred to as the Time Synchronization Global Instance (TSGI).  The
+   TSGI can be operated in either of the three modes that are detailed
+   in Section 3.1.3 of RPL [RFC6550], "Instances, DODAGs, and DODAG
+   Versions".  Multiple uncoordinated DODAGs with independent Roots may
+   be used if all the Roots share a common time source such as the
+   Global Positioning System (GPS).
+
+   In the absence 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 operations between the Backbone
+   Routers that act as sinks for the LLN.  Optionally, RPL's periodic
+   operations may be used to transport the network synchronization.
+   This may 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 of synchronization.
+
+   A node that has not joined the TSGI advertises a MAC-level Join
+   Priority of 0xFF to notify its neighbors that is not capable of
+   serving as time parent.  A node that has joined the TSGI advertises a
+   MAC-level Join Priority set to its DAGRank() in that Instance, where
+   DAGRank() is the operation specified in Section 3.5.1 of [RFC6550],
+   "Rank Comparison".
+
+   The provisioning of a RPL Root is out of scope for both RPL and this
+   architecture, whereas RPL enables the propagation of configuration
+   information 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 in the
+   TSGI, which must be less than 0xFF, as its Join Priority in its IEEE
+   Std 802.15.4 EBs.
+
+   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
+   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
+   its own DagRank in the TSGI as its Join Priority in its EBs.
+
+4.3.5.  Slotframes and CDU Matrix
+
+   6TiSCH enables IPv6 best-effort (stochastic) transmissions over a MAC
+   layer that is also capable of scheduled (deterministic)
+   transmissions.  A window of time is defined around the scheduled
+   transmission where the medium must, as much as practically feasible,
+   be free of contending energy to ensure that the medium is free of
+   contending packets when the time comes for a scheduled transmission.
+   One simple way to obtain such a window is to format time and
+   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
+   Term Evolution (LTE) of cellular networks.
+
+   The 6TiSCH architecture defines a global concept that is called a
+   Channel Distribution and Usage (CDU) matrix to describe that
+   formatting of time and frequencies.
+
+   A CDU matrix is defined centrally as part of the network definition.
+   It is a matrix of cells with a height equal to the number of
+   available channels (indexed by channelOffsets) and a width (in
+   timeslots) that is the period of the network scheduling operation
+   (indexed by slotOffsets) for that CDU matrix.  There are different
+   models for scheduling the usage of the cells, which place the
+   responsibility of avoiding collisions either on a central controller
+   or on the devices themselves, at an extra cost in terms of energy to
+   scan for free cells (more in Section 4.4).
+
+   The size of a cell is a timeslot duration, and 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 security validation
+   on the receive side, which may take up to a few milliseconds on some
+   device architecture.
+
+   A CDU matrix iterates over a well-known channel rotation called the
+   hopping sequence.  In a given network, there might be multiple CDU
+   matrices that operate with different widths, so they have different
+   durations and represent different periodic operations.  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 chances of
+   interferences from the Slotted ALOHA operations.  The knowledge of
+   the CDU matrices is shared between all the nodes and used in
+   particular to define slotframes.
+
+   A slotframe is a MAC-level abstraction that is common to all nodes
+   and contains a series of timeslots of equal length and precedence.
+   It is characterized by a slotframe_ID and a slotframe_size.  A
+   slotframe aligns to a CDU matrix for its parameters, such as number
+   and duration of timeslots.
+
+   Multiple slotframes can coexist in a node schedule, i.e., a node can
+   have multiple activities scheduled in different slotframes.  A
+   slotframe is associated with a priority that may be related to the
+   precedence of different 6TiSCH topologies.  The slotframes may be
+   aligned to different CDU matrices and thus have different widths.
+   There is typically one slotframe for scheduled traffic that has the
+   highest precedence and one or more slotframe(s) for RPL traffic.  The
+   timeslots in the slotframe are indexed by the slotOffset; the first
+   cell is at slotOffset 0.
+
+   When a packet is received from a higher layer for transmission, 6top
+   inserts that packet in the outgoing queue that matches the packet
+   best (Differentiated Services [RFC2474] can therefore be used).  At
+   each scheduled transmit slot, 6top looks for the frame in all the
+   outgoing queues that best matches the cells.  If a frame is found, it
+   is given to the TSCH MAC for transmission.
+
+4.3.6.  Distributing the Reservation of Cells
+
+   The 6TiSCH architecture introduces the concept of chunks
+   (Section 2.1) to distribute the allocation of the spectrum for a
+   whole group of cells at a time.  The CDU matrix is formatted into a
+   set of chunks, possibly as illustrated in Figure 8, each of the
+   chunks identified uniquely by a chunk-ID.  The knowledge of this
+   formatting is shared between all the nodes in a 6TiSCH network.  It
+   could be conveyed during the join process, codified into a profile
+   document, or obtained using some other mechanism.  This is as opposed
+   to Static Scheduling, which refers to the preprogrammed mechanism
+   specified in [RFC8180] and which existed before the distribution of
+   the chunk formatting.
+
+                +-----+-----+-----+-----+-----+-----+-----+     +-----+
+   chan.Off. 0  |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
+                +-----+-----+-----+-----+-----+-----+-----+     +-----+
+   chan.Off. 1  |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
+                +-----+-----+-----+-----+-----+-----+-----+     +-----+
+                  ...
+                +-----+-----+-----+-----+-----+-----+-----+     +-----+
+   chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
+                +-----+-----+-----+-----+-----+-----+-----+     +-----+
+                   0     1     2     3     4     5     6          M
+
+                Figure 8: CDU Matrix Partitioning in Chunks
+
+   The 6TiSCH architecture envisions a protocol that enables chunk
+   ownership appropriation whereby a RPL parent discovers a chunk that
+   is not used in its interference domain, claims the chunk, and then
+   defends it in case another RPL parent would attempt to appropriate it
+   while it is in use.  The chunk is the basic unit of ownership that is
+   used in that process.
+
+   As a result of the process of chunk ownership appropriation, the RPL
+   parent has exclusive authority to decide which cell in the
+   appropriated chunk can be used by which node in its interference
+   domain.  In other words, it is implicitly delegated the right to
+   manage the portion of the CDU matrix that is represented by the
+   chunk.
+
+   Initially, those cells are added to the heap of free cells, then
+   dynamically placed into existing bundles, into new bundles, or
+   allocated opportunistically for one transmission.
+
+   Note that a PCE is expected to have precedence in the allocation, so
+   that a RPL parent would only be able to obtain portions that are not
+   in use by the PCE.
+
+4.4.  Schedule Management Mechanisms
+
+   6TiSCH uses four paradigms to manage the TSCH schedule of the LLN
+   nodes: Static Scheduling, Neighbor-to-Neighbor Scheduling, Remote
+   Monitoring and Scheduling Management, and Hop-by-Hop Scheduling.
+   Multiple mechanisms are defined that implement the associated
+   Interaction Models, and they can be combined and used in the same
+   LLN.  Which mechanism(s) to use depends on application requirements.
+
+4.4.1.  Static Scheduling
+
+   In the simplest instantiation of a 6TiSCH network, a common fixed
+   schedule may be shared by all nodes in the network.  Cells are
+   shared, and nodes contend for slot access in a Slotted ALOHA manner.
+
+   A static TSCH schedule can be used to bootstrap a network, as an
+   initial phase during implementation or as a fall-back mechanism in
+   case of network malfunction.  This schedule is preestablished, for
+   instance, decided by a network administrator based on operational
+   needs.  It can be preconfigured into the nodes, or, more commonly,
+   learned by a node when joining the network using standard IEEE Std
+   802.15.4 Information Elements (IE).  Regardless, the schedule remains
+   unchanged after the node has joined a network.  RPL is used on the
+   resulting network.  This "minimal" scheduling mechanism that
+   implements this paradigm is detailed in [RFC8180].
+
+4.4.2.  Neighbor-to-Neighbor Scheduling
+
+   In the simplest instantiation of a 6TiSCH network described in
+   Section 4.4.1, nodes may expect a packet at any cell in the schedule
+   and will waste energy idle listening.  In a more complex
+   instantiation of a 6TiSCH network, a matching portion of the schedule
+   is established between peers to reflect the observed amount of
+   transmissions between those nodes.  The aggregation of the cells
+   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
+   link is proportional to the number of cells in the bundle.
+
+   If the size of a bundle is configured to fit an average amount of
+   bandwidth, peak traffic is dropped.  If the size is configured to
+   allow for peak emissions, energy is wasted idle listening.
+
+   As discussed in more detail in Section 4.3, the 6top Protocol
+   [RFC8480] specifies the exchanges between neighbor nodes to reserve
+   soft cells to transmit to one another, possibly under the control of
+   a Scheduling Function (SF).  Because this reservation is done without
+   global knowledge of the schedule of the other nodes in the LLN,
+   scheduling collisions are possible.
+
+   And as discussed in Section 4.3.2, an optional SF is used to monitor
+   bandwidth usage and to perform requests for dynamic allocation by the
+   6top sublayer.  The SF component is not part of the 6top sublayer.
+   It may be co-located on the same device or may be partially or fully
+   offloaded to an external system.  The "6TiSCH Minimal Scheduling
+   Function (MSF)" [RFC9033] provides a simple SF that can be used by
+   default by devices that support dynamic scheduling of soft cells.
+
+   Monitoring and relocation is done in the 6top sublayer.  For the
+   upper layer, the connection between two neighbor nodes appears as a
+   number of cells.  Depending on traffic requirements, the upper layer
+   can request 6top to add or delete a number of cells scheduled to a
+   particular neighbor, without being responsible for choosing the exact
+   slotOffset/channelOffset of those cells.
+
+4.4.3.  Remote Monitoring and Schedule Management
+
+   Remote Monitoring and Schedule Management refers to a DetNet/SDN
+   model whereby an NME and a scheduling entity, associated with a PCE,
+   reside in a central controller and interact with the 6top sublayer to
+   control IPv6 links and Tracks (Section 4.5) in a 6TiSCH network.  The
+   composite centralized controller can assign physical resources (e.g.,
+   buffers and hard cells) to a particular Track to optimize the
+   reliability within a bounded latency for a well-specified flow.
+
+   The work in the 6TiSCH Working Group focused on nondeterministic
+   traffic and did not provide the generic data model necessary for the
+   controller to monitor and manage resources of the 6top sublayer.
+   This is deferred to future work, see Appendix A.1.2.
+
+   With respect to centralized routing and scheduling, it is envisioned
+   that the related component of the 6TiSCH architecture would be an
+   extension of the DetNet architecture [RFC8655], which studies Layer 3
+   aspects of Deterministic Networks and covers networks that span
+   multiple Layer 2 domains.
+
+   The DetNet architecture is a form of Software-Defined Networking
+   (SDN) architecture and is composed of three planes: a (User)
+   Application Plane, a Controller Plane (where the PCE operates), and a
+   Network Plane, which can represent a 6TiSCH LLN.
+
+   "Software-Defined Networking (SDN): Layers and Architecture
+   Terminology" [RFC7426] proposes a generic representation of the SDN
+   architecture that is reproduced in Figure 9.
+
+                     o--------------------------------o
+                     |                                |
+                     | +-------------+   +----------+ |
+                     | | Application |   |  Service | |
+                     | +-------------+   +----------+ |
+                     |       Application Plane        |
+                     o---------------Y----------------o
+                                     |
+       *-----------------------------Y---------------------------------*
+       |           Network Services Abstraction Layer (NSAL)           |
+       *------Y------------------------------------------------Y-------*
+              |                                                |
+              |               Service Interface                |
+              |                                                |
+       o------Y------------------o       o---------------------Y------o
+       |      |    Control Plane |       | Management Plane    |      |
+       | +----Y----+   +-----+   |       |  +-----+       +----Y----+ |
+       | | Service |   | App |   |       |  | App |       | Service | |
+       | +----Y----+   +--Y--+   |       |  +--Y--+       +----Y----+ |
+       |      |           |      |       |     |               |      |
+       | *----Y-----------Y----* |       | *---Y---------------Y----* |
+       | | Control Abstraction | |       | | Management Abstraction | |
+       | |     Layer (CAL)     | |       | |      Layer (MAL)       | |
+       | *----------Y----------* |       | *----------Y-------------* |
+       |            |            |       |            |               |
+       o------------|------------o       o------------|---------------o
+                    |                                 |
+                    | CP                              | MP
+                    | Southbound                      | Southbound
+                    | Interface                       | Interface
+                    |                                 |
+       *------------Y---------------------------------Y----------------*
+       |         Device and resource Abstraction Layer (DAL)           |
+       *------------Y---------------------------------Y----------------*
+       |            |                                 |                |
+       |    o-------Y----------o   +-----+   o--------Y----------o     |
+       |    | Forwarding Plane |   | App |   | Operational Plane |     |
+       |    o------------------o   +-----+   o-------------------o     |
+       |                       Network Device                          |
+       +---------------------------------------------------------------+
+
+       Figure 9: SDN Layers and Architecture Terminology per RFC 7426
+
+   The PCE establishes end-to-end Tracks of hard cells, which are
+   described in more detail in Section 4.6.1.
+
+   The DetNet work is expected to enable end-to-end deterministic paths
+   across heterogeneous networks.  This can be, for instance, a 6TiSCH
+   LLN and an Ethernet backbone.
+
+   This model fits the 6TiSCH extended configuration, whereby a 6BBR
+   federates multiple 6TiSCH LLNs in a single subnet over a backbone
+   that can be, for instance, Ethernet or Wi-Fi.  In that model, 6TiSCH
+   6BBRs synchronize with one another over the backbone, so as to ensure
+   that the multiple LLNs that form the IPv6 subnet stay tightly
+   synchronized.
+
+   If the backbone is deterministic, then the Backbone Router ensures
+   that the end-to-end deterministic behavior is maintained between the
+   LLN and the backbone.  It is the responsibility of the PCE to compute
+   a deterministic path end to end across the TSCH network and an IEEE
+   Std 802.1 TSN Ethernet backbone, and it is the responsibility of
+   DetNet to enable end-to-end deterministic forwarding.
+
+4.4.4.  Hop-by-Hop Scheduling
+
+   A node can reserve a Track (Section 4.5) to one or more
+   destination(s) that are multiple hops away by installing soft cells
+   at each intermediate node.  This forms a Track of soft cells.  A
+   Track SF above the 6top sublayer of each node on the Track is needed
+   to monitor these soft cells and trigger relocation when needed.
+
+   This hop-by-hop reservation mechanism is expected to be similar in
+   essence to [RFC3209] and/or [RFC4080] and [RFC5974].  The protocol
+   for a node to trigger hop-by-hop scheduling is not yet defined.
+
+4.5.  On Tracks
+
+   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) across a 6TiSCH LLN.
+
+   A Track is the 6TiSCH instantiation of the concept of a deterministic
+   path as described in [RFC8655].  Constrained resources such as memory
+   buffers are reserved for that Track in 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 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.
+
+4.5.1.  General Behavior of Tracks
+
+   A Track is associated with Layer 2 bundles of cells with related
+   schedules and logical relationships that ensure that a packet that is
+   injected in a Track will progress in due time all the way to
+   destination.
+
+   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 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.
+
+   There are several benefits for using a Track to forward a packet from
+   a source node to the destination node:
+
+   1.  Track Forwarding, as further described in Section 4.6.1, is a
+       Layer 2 forwarding scheme, which introduces less process delay
+       and overhead than a Layer 3 forwarding scheme.  Therefore, LLN
+       devices can save more energy and resources, which is critical for
+       resource-constrained devices.
+
+   2.  Since channel resources, i.e., bundles of cells, have been
+       reserved for communications between 6TiSCH nodes of each hop on
+       the Track, the throughput and the maximum latency of the traffic
+       along a Track are guaranteed, and the jitter is minimized.
+
+   3.  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 sleep state during inactive slots.
+
+   4.  Tracks are protected from interfering with one another if a cell
+       is scheduled to belong to at most one Track, and congestion loss
+       is avoided if at most one packet can be presented to the MAC to
+       use that cell.  Tracks enhance the reliability of transmissions
+       and thus further improve the energy consumption in LLN devices by
+       reducing the chances of retransmission.
+
+4.5.2.  Serial Track
+
+   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 with a bundle of cells that are set to transmit (TX-cells),
+   representing a Layer 2 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 paired bundles: a receive bundle from the
+   previous hop and a transmit bundle to the next hop along the Track.
+
+   For a given iteration of the device schedule, the effective channel
+   of the cell is obtained by looping through a well-known hopping
+   sequence beginning at Epoch time and starting at the cell's
+   channelOffset, which results in a rotation of the frequency that is
+   used for transmission.  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 schedule.
+
+4.5.3.  Complex Track with Replication and Elimination
+
+   The art of Deterministic Networks already includes packet replication
+   and elimination techniques.  Example standards include the Parallel
+   Redundancy Protocol (PRP) and the High-availability Seamless
+   Redundancy (HSR) [IEC62439].  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 or more destination(s)
+   to support multipath forwarding and route around failures.
+
+   A Complex Track may branch off over noncongruent branches for the
+   purpose of multicasting and/or redundancy, in which case, it
+   reconverges later down the path.  This enables the Packet
+   Replication, Elimination, and Ordering Functions (PREOF) defined by
+   DetNet.  Packet ARQ, Replication, Elimination, and Overhearing
+   (PAREO) adds radio-specific capabilities of Layer 2 ARQ and
+   promiscuous listening to redundant transmissions to compensate for
+   the lossiness of the medium and meet industrial expectations of a RAW
+   network.  Combining PAREO and PREOF, a Track may extend beyond the
+   6TiSCH network into a larger DetNet network.
+
+   In the art of TSCH, a path does not necessarily support PRE, but it
+   is almost systematically multipath.  This means that a Track is
+   scheduled so as to 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 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 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 the first branch fails.
+
+4.5.4.  DetNet End-to-End Path
+
+   Ultimately, DetNet should enable extending a Track beyond the 6TiSCH
+   LLN as illustrated in Figure 10.  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 802.1 Time-Sensitive Networking (TSN) backbone.  A
+   6TiSCH-aware DetNet service layer handles the Packet Replication,
+   Elimination, and Ordering Functions over the DODAG that forms a
+   Track.
+
+   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 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 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 layers.
+
+                     +-=-=-+
+                     | IoT |
+                     | G/W |
+                     +-=-=-+
+                        ^  <=== Elimination
+        Track branch   | |
+               +-=-=-=-+ +-=-=-=-=+ Subnet backbone
+               |                  |
+            +-=|-=+            +-=|-=+
+            |  |  | Backbone   |  |  | Backbone
+       o    |  |  | Router     |  |  | Router
+            +-=/-=+            +-=|-=+
+       o     /    o     o-=-o-=-=/       o
+           o    o-=-o-=/   o      o   o  o   o
+      o     \  /     o               o   LLN    o
+         o   v  <=== Replication
+             o
+
+                 Figure 10: Example End-to-End DetNet Track
+
+4.5.5.  Cell Reuse
+
+   The 6TiSCH architecture provides the means to avoid waste of cells as
+   well as overflows in the transmit bundle of a Track, as follows:
+
+   A TX-cell that is not needed for the current iteration may be reused
+   opportunistically on a per-hop basis for routed packets.  When all of
+   the frames that were received for a given Track are effectively
+   transmitted, any available TX-cell for that Track can be reused for
+   upper-layer traffic for which the next-hop router matches the next
+   hop along the Track.  In that case, the cell that is being used is
+   effectively a TX-cell from the Track, but the short address for the
+   destination is that of the next-hop router.
+
+   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 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 dropped at the lower MAC layer and thus is
+   not received at the 6top sublayer.
+
+   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 more retransmissions are needed than provisioned.  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 towards the next hop along the Track.  The MAC address should
+   be set to the next-hop MAC address to avoid confusion.
+
+   It results in a frame that is received over a Layer 3 bundle that may
+   be 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 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 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 bundle if possible.  A frame is re-Tracked by
+   scheduling it for transmission over the transmit bundle associated
+   with the Track, with the destination MAC address set to broadcast.
+
+4.6.  Forwarding Models
+
+   By forwarding, this document means the per-packet operation that
+   allows delivery of a packet to a next hop or an upper layer in this
+   node.  Forwarding is based on preexisting state that was installed as
+   a result of a routing computation, see Section 4.7.  6TiSCH supports
+   three different forwarding models: (GMPLS) Track Forwarding,
+   (classical) IPv6 Forwarding, and (6LoWPAN) Fragment Forwarding.
+
+4.6.1.  Track Forwarding
+
+   Forwarding along a Track can be seen as a Generalized Multiprotocol
+   Label Switching (GMPLS) operation in that the information used to
+   switch a frame is not an explicit label but is rather related to
+   other properties of the way the packet was received, a particular
+   cell in the case of 6TiSCH.  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, whether this is an IPv6 packet, a 6LoWPAN
+   fragment, or a frame from an alternate protocol such as WirelessHART
+   or ISA100.11a.
+
+   A data frame that is forwarded along a Track normally has a
+   destination MAC address that is set to broadcast or a multicast
+   address depending on MAC support.  This way, the MAC layer in the
+   intermediate nodes accepts the incoming frame and 6top switches it
+   without incurring a change in the MAC header.  In the case of IEEE
+   Std 802.15.4, this means effectively to broadcast, so that along the
+   Track the short address for the destination of the frame is set to
+   0xFFFF.
+
+   There are two modes for a Track: an IPv6 native mode and a protocol-
+   independent tunnel mode.
+
+4.6.1.1.  Native Mode
+
+   In native mode, the Protocol Data Unit (PDU) is associated with flow-
+   dependent metadata that refers uniquely to the Track, so the 6top
+   sublayer can place the frame in the appropriate cell without
+   ambiguity.  In the case of IPv6 traffic, this flow may be identified
+   using a 6-tuple as discussed in [RFC8939].  In particular,
+   implementations of this document should support identification of
+   DetNet flows based on the IPv6 Flow Label field.
+
+   The flow follows a Track that is identified using a RPL Instance (see
+   Section 3.1.3 of [RFC6550]), signaled in a RPL Packet Information
+   (more in Section 11.2.2.1 of [RFC6550]) and the source address of a
+   packet going down the DODAG formed by a local instance.  One or more
+   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
+   forwarding operation is based on the Track and does not depend on the
+   flow therein.
+
+   The Track identification is validated at egress before restoring the
+   destination MAC address (DMAC) and punting to the upper layer.
+
+   Figure 11 illustrates the Track Forwarding operation that happens at
+   the 6top sublayer, below IP.
+
+                          | Packet flowing across the network  ^
+      +--------------+    |                                    |
+      |     IPv6     |    |                                    |
+      +--------------+    |                                    |
+      |  6LoWPAN HC  |    |                                    |
+      +--------------+  ingress                              egress
+      |     6top     |   sets     +----+          +----+    restores
+      +--------------+  DMAC to   |    |          |    |    DMAC to
+      |   TSCH MAC   |   brdcst   |    |          |    |     dest
+      +--------------+    |       |    |          |    |       |
+      |   LLN PHY    |    +-------+    +--...-----+    +-------+
+      +--------------+
+                        Ingress   Relay            Relay     Egress
+         Stack Layer     Node     Node             Node       Node
+
+                  Figure 11: Track Forwarding, Native Mode
+
+4.6.1.2.  Tunnel Mode
+
+   In tunnel mode, the frames originate from an arbitrary protocol over
+   a compatible MAC that may or may not be synchronized with the 6TiSCH
+   network.  An example of this would be a router with a dual radio that
+   is capable of receiving and sending WirelessHART or ISA100.11a frames
+   with the second radio by presenting itself as an access point or a
+   Backbone Router, respectively.  In that mode, some entity (e.g., PCE)
+   can coordinate with a WirelessHART Network Manager or an ISA100.11a
+   System Manager to specify the flows that are transported.
+
+      +--------------+
+      |     IPv6     |
+      +--------------+
+      |  6LoWPAN HC  |
+      +--------------+             set            restore
+      |     6top     |            +DMAC+          +DMAC+
+      +--------------+          to|brdcst       to|nexthop
+      |   TSCH MAC   |            |    |          |    |
+      +--------------+            |    |          |    |
+      |   LLN PHY    |    +-------+    +--...-----+    +-------+
+      +--------------+    |   ingress                 egress   |
+                          |                                    |
+      +--------------+    |                                    |
+      |   LLN PHY    |    |                                    |
+      +--------------+    |  Packet flowing across the network |
+      |   TSCH MAC   |    |                                    |
+      +--------------+    | DMAC =                             | DMAC =
+      |ISA100/WiHART |    | nexthop                            v nexthop
+      +--------------+
+                        Source   Ingress          Egress   Destination
+         Stack Layer     Node     Node             Node       Node
+
+                  Figure 12: Track Forwarding, Tunnel Mode
+
+   In that case, the TrackID that identifies the Track at the ingress
+   6TiSCH router is derived from the RX-cell.  The DMAC is set to this
+   node, but the TrackID 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 broadcast, and the frame is passed to
+   the 6top sublayer for switching.
+
+   At the egress 6TiSCH router, the reverse operation occurs.  Based on
+   tunneling information of the Track, which may for instance indicate
+   that the tunneled datagram is an IP packet, the datagram is passed to
+   the appropriate link-layer with the destination MAC restored.
+
+4.6.1.3.  Tunneling Information
+
+   Tunneling information coming with the Track configuration provides
+   the destination MAC address of the egress endpoint as well as the
+   tunnel mode and specific data depending on the mode, for instance, a
+   service access point for frame delivery at egress.
+
+   If the tunnel egress point does not have a MAC address that matches
+   the configuration, the Track installation fails.
+
+   If the Layer 3 destination address belongs to the tunnel termination,
+   then it is possible that the IPv6 address of the destination is
+   compressed at the 6LoWPAN sublayer based on the MAC address.
+   Restoring the wrong MAC address at the egress would then also result
+   in the wrong IP address in the packet after decompression.  For that
+   reason, a packet can be injected in a Track only if the destination
+   MAC address is effectively that of the tunnel egress point.  It is
+   thus mandatory for the ingress router to validate that the MAC
+   address used at the 6LoWPAN sublayer for compression matches that of
+   the tunnel egress point before it overwrites it to broadcast.  The
+   6top sublayer at the tunnel egress point reverts that operation to
+   the MAC address obtained from the tunnel information.
+
+4.6.2.  IPv6 Forwarding
+
+   As the packets are routed at Layer 3, traditional QoS and Active
+   Queue Management (AQM) operations are expected to prioritize flows.
+
+                          | Packet flowing across the network  ^
+      +--------------+    |                                    |
+      |     IPv6     |    |       +-QoS+          +-QoS+       |
+      +--------------+    |       |    |          |    |       |
+      |  6LoWPAN HC  |    |       |    |          |    |       |
+      +--------------+    |       |    |          |    |       |
+      |     6top     |    |       |    |          |    |       |
+      +--------------+    |       |    |          |    |       |
+      |   TSCH MAC   |    |       |    |          |    |       |
+      +--------------+    |       |    |          |    |       |
+      |   LLN PHY    |    +-------+    +--...-----+    +-------+
+      +--------------+
+                        Source   Ingress          Egress   Destination
+         Stack Layer     Node    Router           Router      Node
+
+                          Figure 13: IP Forwarding
+
+4.6.3.  Fragment Forwarding
+
+   Considering that, per Section 4 of [RFC4944], 6LoWPAN packets can be
+   as large as 1280 bytes (the IPv6 minimum MTU) and that the non-
+   storing mode of RPL implies source routing, which requires space for
+   routing headers, and that an IEEE Std 802.15.4 frame with security
+   may carry in the order of 80 bytes of effective payload, an IPv6
+   packet might be fragmented into more than 16 fragments at the 6LoWPAN
+   sublayer.
+
+   This level of fragmentation is much higher than that traditionally
+   experienced over the Internet with IPv4 fragments, where
+   fragmentation is already known as harmful.
+
+   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 latency and forces intermediate nodes to
+   store a portion of a packet for an undetermined time, thus impacting
+   critical resources such as memory and battery.
+
+   [RFC8930] describes a framework for forwarding fragments end-to-end
+   across a 6TiSCH route-over mesh.  Within that framework,
+   [VIRTUAL-REASSEMBLY] details a virtual reassembly buffer mechanism
+   whereby the datagram tag in the 6LoWPAN fragment is used as a label
+   for switching at the 6LoWPAN sublayer.
+
+   Building on this technique, [RFC8931] introduces a new format for
+   6LoWPAN fragments that enables the selective recovery of individual
+   fragments and allows for a degree of flow control based on an
+   Explicit Congestion Notification (ECN).
+
+                          | Packet flowing across the network  ^
+      +--------------+    |                                    |
+      |     IPv6     |    |       +----+          +----+       |
+      +--------------+    |       |    |          |    |       |
+      |  6LoWPAN HC  |    |       learn           learn        |
+      +--------------+    |       |    |          |    |       |
+      |     6top     |    |       |    |          |    |       |
+      +--------------+    |       |    |          |    |       |
+      |   TSCH MAC   |    |       |    |          |    |       |
+      +--------------+    |       |    |          |    |       |
+      |   LLN PHY    |    +-------+    +--...-----+    +-------+
+      +--------------+
+                        Source   Ingress          Egress   Destination
+         Stack Layer     Node    Router           Router      Node
+
+                    Figure 14: Forwarding First 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 next hop, and stores that information indexed by the incoming MAC
+   address and datagram tag.  The next fragments are then switched based
+   on that stored state.
+
+                          | Packet flowing across the network  ^
+      +--------------+    |                                    |
+      |     IPv6     |    |                                    |
+      +--------------+    |                                    |
+      |  6LoWPAN HC  |    |       replay          replay       |
+      +--------------+    |       |    |          |    |       |
+      |     6top     |    |       |    |          |    |       |
+      +--------------+    |       |    |          |    |       |
+      |   TSCH MAC   |    |       |    |          |    |       |
+      +--------------+    |       |    |          |    |       |
+      |   LLN PHY    |    +-------+    +--...-----+    +-------+
+      +--------------+
+                        Source   Ingress          Egress   Destination
+         Stack Layer     Node    Router           Router      Node
+
+                    Figure 15: Forwarding Next Fragment
+
+   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 new path in case of a path failure.
+   The ECN echo set indicates that the number of outstanding fragments
+   should be reduced.
+
+4.7.  Advanced 6TiSCH Routing
+
+4.7.1.  Packet Marking and Handling
+
+   All packets inside a 6TiSCH domain must carry the RPLInstanceID that
+   identifies the 6TiSCH topology (e.g., a Track) that is to be used for
+   routing and forwarding that packet.  The location of that information
+   must be the same for all packets forwarded inside the domain.
+
+   For packets that are routed by a PCE along a Track, the tuple formed
+   by 1) (typically) the IPv6 source or (possibly) destination address
+   in the IPv6 header and 2) a local RPLInstanceID in the RPI that
+   serves as TrackID, identify uniquely the Track and associated
+   transmit bundle.
+
+   For packets that are routed by RPL, that information is the
+   RPLInstanceID that is carried in the RPL Packet Information (RPI), as
+   discussed in Section 11.2 of [RFC6550], "Loop Avoidance and
+   Detection".  The RPI is transported by a RPL Option in the IPv6 Hop-
+   By-Hop Options header [RFC6553].
+
+   A compression mechanism for the RPL packet artifacts that integrates
+   the compression of IP-in-IP encapsulation and the Routing Header type
+   3 [RFC6554] with that of the RPI in a 6LoWPAN dispatch/header type is
+   specified in [RFC8025] and [RFC8138].
+
+   Either way, the method and format used for encoding the RPLInstanceID
+   is generalized to all 6TiSCH topological Instances, which include
+   both RPL Instances and Tracks.
+
+4.7.2.  Replication, Retries, and Elimination
+
+   6TiSCH supports the PREOF operations of elimination and reordering of
+   packets along a complex Track, but has no requirement about tagging a
+   sequence number in the packet for that purpose.  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 the extra copies once it has received one instance of
+   the packet.
+
+   The semantics of the configuration enable correlated timeslots to be
+   grouped for transmit (and receive, respectively) with 'OR' relations,
+   and then an 'AND' relation can be configurable between groups.  The
+   semantics are such that if the transmit (and receive, respectively)
+   operation succeeded in one timeslot in an 'OR' group, then all the
+   other timeslots in the group are ignored.  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.
+
+   On the transmit side, timeslots provisioned for retries along a same
+   branch of a Track are placed in the same 'OR' group.  The 'OR'
+   relation indicates that if a transmission is acknowledged, then
+   retransmissions of that packet should 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.  Different
+   'OR' groups are programmed for the purpose of replication, each group
+   corresponding to one branch of the Track.  The 'AND' relation between
+   the groups indicates that transmission over any of branches must be
+   attempted regardless of whether a transmission succeeded in another
+   branch.  It is also possible to place cells to different next-hop
+   routers in the same 'OR' group.  This allows routing along multipath
+   Tracks, trying one next hop and then another only if sending to the
+   first fails.
+
+   On the receive side, all timeslots are programmed in the same 'OR'
+   group.  Retries of the same copy as well as converging branches for
+   elimination are converged, meaning that the first successful
+   reception is enough and that all the other timeslots can be ignored.
+   An 'AND' group denotes different packets that must all be received
+   and transmitted over the associated transmit groups within their
+   respected 'AND' or 'OR' rules.
+
+   As an example, say that we have a simple network as represented in
+   Figure 16, and we want to enable PREOF between an ingress node I and
+   an egress node E.
+
+                              +-+         +-+
+                           -- |A|  ------ |C| --
+                         /    +-+         +-+    \
+                       /                           \
+                  +-+                                +-+
+                  |I|                                |E|
+                  +-+                                +-+
+                       \                           /
+                         \    +-+         +-+    /
+                           -- |B| ------- |D| --
+                              +-+         +-+
+
+              Figure 16: Scheduling PREOF on a Simple Network
+
+   The assumption for this particular problem is that a 6TiSCH node has
+   a single radio, so it cannot perform two receive and/or transmit
+   operations at the same time, even on two different channels.
+
+   Say we have six possible channels, and at least ten timeslots per
+   slotframe.  Figure 17 shows a possible schedule whereby each
+   transmission 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, spatial diversity though different
+   physical paths, and frequency diversity.
+
+       slotOffset      0    1    2    3    4    5    6    7    9
+                    +----+----+----+----+----+----+----+----+----+
+    channelOffset 0 |    |    |    |    |    |    |B->D|    |    | ...
+                    +----+----+----+----+----+----+----+----+----+
+    channelOffset 1 |    |I->A|    |A->C|B->D|    |    |    |    | ...
+                    +----+----+----+----+----+----+----+----+----+
+    channelOffset 2 |I->A|    |    |I->B|    |C->E|    |D->E|    | ...
+                    +----+----+----+----+----+----+----+----+----+
+    channelOffset 3 |    |    |    |    |A->C|    |    |    |    | ...
+                    +----+----+----+----+----+----+----+----+----+
+    channelOffset 4 |    |    |I->B|    |    |B->D|    |    |D->E| ...
+                    +----+----+----+----+----+----+----+----+----+
+    channelOffset 5 |    |    |A->C|    |    |    |C->E|    |    | ...
+                    +----+----+----+----+----+----+----+----+----+
+
+                     Figure 17: Example Global Schedule
+
+   This translates into a different slotframe that provides the waking
+   and sleeping times for every node, and the channelOffset to be used
+   when awake.  Figure 18 shows the corresponding slotframe for node A.
+
+       slotOffset      0    1    2    3    4    5    6    7    9
+                    +----+----+----+----+----+----+----+----+----+
+    operation       |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ...
+                    +----+----+----+----+----+----+----+----+----+
+    channelOffset   |  2 |  1 |  5 |  1 |  3 |N/A |N/A |N/A |N/A | ...
+                    +----+----+----+----+----+----+----+----+----+
+
+                  Figure 18: Example Slotframe for Node A
+
+   The logical relationship between the timeslots is given by Table 2:
+
+           +======+====================+=======================+
+           | Node |   rcv slotOffset   |    xmit slotOffset    |
+           +======+====================+=======================+
+           |  I   |        N/A         | (0 OR 1) AND (2 OR 3) |
+           +------+--------------------+-----------------------+
+           |  A   |      (0 OR 1)      |     (2 OR 3 OR 4)     |
+           +------+--------------------+-----------------------+
+           |  B   |      (2 OR 3)      |     (4 OR 5 OR 6)     |
+           +------+--------------------+-----------------------+
+           |  C   |   (2 OR 3 OR 4)    |        (5 OR 6)       |
+           +------+--------------------+-----------------------+
+           |  D   |   (4 OR 5 OR 6)    |        (7 OR 8)       |
+           +------+--------------------+-----------------------+
+           |  E   | (5 OR 6 OR 7 OR 8) |          N/A          |
+           +------+--------------------+-----------------------+
+
+                                  Table 2
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  Security Considerations
+
+   The "Minimal Security Framework for 6TiSCH" [RFC9031] was optimized
+   for Low-Power and TSCH operations.  The reader is encouraged to
+   review the Security Considerations section of that document
+   (Section 9), which discusses 6TiSCH security issues in more details.
+
+6.1.  Availability of Remote Services
+
+   The operation of 6TiSCH Tracks inherits its high-level operation from
+   DetNet and is subject to the observations in Section 5 of [RFC8655].
+   The 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 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 installed.
+
+   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 may introduce extra delay by selectively
+   jamming some packets or some flows.  The expectation is that the
+   6TiSCH Tracks enable enough redundancy to maintain the critical
+   traffic in operation while new routes are calculated and programmed
+   into the network.
+
+   As with DetNet in general, the communication with the PCE must be
+   secured and should be protected against DoS attacks, including delay
+   injection and blackholing attacks, and secured as discussed in the
+   security considerations defined for Abstraction and Control of
+   Traffic Engineered Networks (ACTN) in Section 9 of [RFC8453], which
+   applies equally to DetNet and 6TiSCH.  In a similar manner, the
+   communication with the JRC must be secured and should be protected
+   against DoS attacks when possible.
+
+6.2.  Selective Jamming
+
+   The hopping sequence of a TSCH network is well known, meaning that if
+   a rogue manages to identify a cell of a particular flow, then it may
+   selectively jam that cell without impacting any other traffic.  This
+   attack can be performed at the PHY layer without any knowledge of the
+   Layer 2 keys, and it is very hard to detect and diagnose because only
+   one flow is impacted.
+
+   [ROBUST-SCHEDULING] proposes a method to obfuscate the hopping
+   sequence and make it harder to perpetrate that particular attack.
+
+6.3.  MAC-Layer Security
+
+   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 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 material.  In a typical deployment, all joined
+   nodes use the same keys, and rekeying needs to be global.
+
+   The 6TISCH architecture relies on the join process to deny
+   authorization of invalid nodes and to preserve the integrity of the
+   network keys.  A rogue that managed to access the network can perform
+   a large variety of attacks from DoS to injecting forged packets and
+   routing information.  "Zero-trust" properties would be highly
+   desirable but are mostly not available at the time of this writing.
+   [RFC8928] is a notable exception that protects the ownership of IPv6
+   addresses and prevents a rogue node with L2 access from stealing and
+   injecting traffic on behalf of a legitimate node.
+
+6.4.  Time Synchronization
+
+   Time synchronization in TSCH induces another event horizon whereby a
+   node will only communicate with another node if they are synchronized
+   within a 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 outside of the guard time of the legitimate
+   nodes, then the pledge will never see a legitimate beacon and may not
+   discover the attack.
+
+   As discussed in [RFC8655], measures 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 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.
+
+   IEEE Std 802.15.4 [IEEE802154] specifies that in a TSCH network, the
+   nonce that is used for the computation of the Message Integrity Code
+   (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 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.  As a result, upper-layer protocols must
+   provide a way to detect duplicates and cope with them.
+
+   If the receiver and the sender have a different sense of ASN, the MIC
+   will 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 one another in an authenticated manner.  With
+   6TiSCH, the pledge discovers a tentative ASN in beacons from nodes
+   that have already joined the network.  But even if the beacon can be
+   authenticated, the ASN cannot be trusted as it 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 from a replayed beacon for
+   an encrypted transmission, a nonce-reuse attack becomes possible, and
+   the network keys may be compromised.
+
+6.5.  Validating ASN
+
+   After obtaining the tentative ASN, a pledge that wishes to join the
+   6TiSCH network must use a join protocol to obtain its security keys.
+   The join protocol used in 6TiSCH is the Constrained Join Protocol
+   (CoJP).  In the minimal setting defined in [RFC9031], the
+   authentication requires a pre-shared key, based on which a secure
+   session is derived.  The CoJP exchange may also be preceded by a
+   zero-touch handshake [ZEROTOUCH-JOIN] in order to enable pledge
+   joining based on certificates and/or inter-domain communication.
+
+   As detailed in Section 4.2.1, a Join Proxy (JP) helps the pledge with
+   the join procedure by relaying the 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 the
+   appropriate network.  As a result of the CoJP exchange, the pledge is
+   in 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* [CCMstar] at the link layer.
+
+   The authentication steps must be such that they cannot be replayed by
+   an attacker, and they must not depend on the tentative ASN being
+   valid.  During the authentication, the keying material that the
+   pledge obtains from the JRC does not provide protection against
+   spoofed ASN.  Once the pledge has obtained the keys to use in the
+   network, it may still need to verify the ASN.  If the nonce used in
+   the Layer 2 security derives from the extended (MAC-64) address, then
+   replaying the ASN alone cannot enable a nonce-reuse attack unless the
+   same node has lost its state with a previous ASN.  But if the nonce
+   derives from the short address (e.g., assigned by the JRC), then the
+   JRC must ensure that it never assigns short addresses that were
+   already given to this or other nodes with the same keys.  In other
+   words, the network must be rekeyed before the JRC runs out of short
+   addresses.
+
+6.6.  Network Keying and Rekeying
+
+   Section 4.2.1 provides an overview of the CoJP process described in
+   [RFC9031] by which an LLN can be assembled in the field, having been
+   provisioned in a lab.  [ZEROTOUCH-JOIN] is future work that precedes
+   and then leverages CoJP using the [CONSTRAINED-VOUCHER] constrained
+   profile of [RFC8995].  This later work requires a yet-to-be
+   standardized Lightweight Authenticated Key Exchange protocol.
+
+   CoJP results in distribution of a network-wide key that is to be used
+   with [IEEE802154] security.  The details of use are described in
+   [RFC9031], Sections 9.2 and 9.3.2.
+
+   The BRSKI mechanism may lead to the use of CoJP, in which case it
+   also results in distribution of a network-wide key.  Alternatively
+   the BRSKI mechanism may be followed by use of [EST-COAPS] to enroll
+   certificates for each device.  In that case, the certificates may be
+   used with an [IEEE802154] key agreement protocol.  The description of
+   this mechanism, while conceptually straightforward, still has
+   significant standardization hurdles to pass.
+
+   Section 8.2 of [RFC9031] describes a mechanism to change (rekey) the
+   network.  There are a number of reasons to initiate a network rekey:
+   to remove unwanted (corrupt/malicious) nodes, to recover unused
+   2-byte short addresses, or due to limits in encryption algorithms.
+   For all of the mechanisms that distribute a network-wide key,
+   rekeying is also needed on a periodic basis.  In more detail:
+
+   *  The mechanism described in Section 8.2 of [RFC9031] requires
+      advance communication between the JRC and every one of the nodes
+      before the key change.  Given that many nodes may be sleepy, this
+      operation may take a significant amount of time and may consume a
+      significant portion of the available bandwidth.  As such, network-
+      wide rekeys to exclude nodes that have become malicious will not
+      be particularly quick.  If a rekey is already in progress, but the
+      unwanted node has not yet been updated, then it is possible to
+      just continue the operation.  If the unwanted node has already
+      received the update, then the rekey operation will need to be
+      restarted.
+
+   *  The cryptographic mechanisms used by IEEE Std 802.15.4 include the
+      2-byte short address in the calculation of the context.  A nonce-
+      reuse attack may become feasible if a short address is reassigned
+      to another node while the same network-wide keys are in operation.
+      A network that gains and loses nodes on a regular basis is likely
+      to reach the 65536 limit of the 2-byte (16-bit) short addresses,
+      even if the network has only a few thousand nodes.  Network
+      planners should consider the need to rekey the network on a
+      periodic basis in order to recover 2-byte addresses.  The rekey
+      can update the short addresses for active nodes if desired, but
+      there is actually no need to do this as long as the key has been
+      changed.
+
+   *  With TSCH as it stands at the time of this writing, the ASN will
+      wrap after 2^40 timeslot durations, meaning around 350 years with
+      the default values.  Wrapping ASN is not expected to happen within
+      the lifetime of most LLNs.  Yet, should the ASN wrap, the network
+      must be rekeyed to avoid a nonce-reuse attack.
+
+   *  Many cipher algorithms have some suggested limits on how many
+      bytes should be encrypted with that algorithm before a new key is
+      used.  These numbers are typically in the many to hundreds of
+      gigabytes of data.  On very fast backbone networks, this becomes
+      an important concern.  On LLNs with typical data rates in the
+      kilobits/second, this concern is significantly less.  With IEEE
+      Std 802.15.4 as it stands at the time of this writing, the ASN
+      will wrap before the limits of the current L2 crypto (AES-CCM-128)
+      are reached, so the problem should never occur.
+
+   *  In any fashion, if the LLN is expected to operate continuously for
+      decades, then the operators are advised to plan for the need to
+      rekey.
+
+   Except for urgent rekeys caused by malicious nodes, the rekey
+   operation described in [RFC9031] can be done as a background task and
+   can be done incrementally.  It is a make-before-break mechanism.  The
+   switch over to the new key is not signaled by time, but rather by
+   observation that the new key is in use.  As such, the update can take
+   as long as needed, or occur in as short a time as practical.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <https://www.rfc-editor.org/info/rfc768>.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <https://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862,
+              DOI 10.17487/RFC4862, September 2007,
+              <https://www.rfc-editor.org/info/rfc4862>.
+
+   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
+              "Transmission of IPv6 Packets over IEEE 802.15.4
+              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
+              <https://www.rfc-editor.org/info/rfc4944>.
+
+   [RFC5889]  Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
+              Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
+              September 2010, <https://www.rfc-editor.org/info/rfc5889>.
+
+   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
+              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
+              DOI 10.17487/RFC6282, September 2011,
+              <https://www.rfc-editor.org/info/rfc6282>.
+
+   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
+              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
+              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
+              Low-Power and Lossy Networks", RFC 6550,
+              DOI 10.17487/RFC6550, March 2012,
+              <https://www.rfc-editor.org/info/rfc6550>.
+
+   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
+              and D. Barthel, "Routing Metrics Used for Path Calculation
+              in Low-Power and Lossy Networks", RFC 6551,
+              DOI 10.17487/RFC6551, March 2012,
+              <https://www.rfc-editor.org/info/rfc6551>.
+
+   [RFC6552]  Thubert, P., Ed., "Objective Function Zero for the Routing
+              Protocol for Low-Power and Lossy Networks (RPL)",
+              RFC 6552, DOI 10.17487/RFC6552, March 2012,
+              <https://www.rfc-editor.org/info/rfc6552>.
+
+   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
+              Power and Lossy Networks (RPL) Option for Carrying RPL
+              Information in Data-Plane Datagrams", RFC 6553,
+              DOI 10.17487/RFC6553, March 2012,
+              <https://www.rfc-editor.org/info/rfc6553>.
+
+   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
+              Routing Header for Source Routes with the Routing Protocol
+              for Low-Power and Lossy Networks (RPL)", RFC 6554,
+              DOI 10.17487/RFC6554, March 2012,
+              <https://www.rfc-editor.org/info/rfc6554>.
+
+   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
+              Bormann, "Neighbor Discovery Optimization for IPv6 over
+              Low-Power Wireless Personal Area Networks (6LoWPANs)",
+              RFC 6775, DOI 10.17487/RFC6775, November 2012,
+              <https://www.rfc-editor.org/info/rfc6775>.
+
+   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
+              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
+              2014, <https://www.rfc-editor.org/info/rfc7102>.
+
+   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
+              Constrained-Node Networks", RFC 7228,
+              DOI 10.17487/RFC7228, May 2014,
+              <https://www.rfc-editor.org/info/rfc7228>.
+
+   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
+              Application Protocol (CoAP)", RFC 7252,
+              DOI 10.17487/RFC7252, June 2014,
+              <https://www.rfc-editor.org/info/rfc7252>.
+
+   [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
+              IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
+              Internet of Things (IoT): Problem Statement", RFC 7554,
+              DOI 10.17487/RFC7554, May 2015,
+              <https://www.rfc-editor.org/info/rfc7554>.
+
+   [RFC8025]  Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
+              Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
+              RFC 8025, DOI 10.17487/RFC8025, November 2016,
+              <https://www.rfc-editor.org/info/rfc8025>.
+
+   [RFC8137]  Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information
+              Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May
+              2017, <https://www.rfc-editor.org/info/rfc8137>.
+
+   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
+              "IPv6 over Low-Power Wireless Personal Area Network
+              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
+              April 2017, <https://www.rfc-editor.org/info/rfc8138>.
+
+   [RFC8180]  Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
+              IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
+              Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
+              May 2017, <https://www.rfc-editor.org/info/rfc8180>.
+
+   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
+              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
+              DOI 10.17487/RFC8453, August 2018,
+              <https://www.rfc-editor.org/info/rfc8453>.
+
+   [RFC8480]  Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
+              Operation Sublayer (6top) Protocol (6P)", RFC 8480,
+              DOI 10.17487/RFC8480, November 2018,
+              <https://www.rfc-editor.org/info/rfc8480>.
+
+   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
+              Perkins, "Registration Extensions for IPv6 over Low-Power
+              Wireless Personal Area Network (6LoWPAN) Neighbor
+              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
+              <https://www.rfc-editor.org/info/rfc8505>.
+
+   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
+              "Deterministic Networking Architecture", RFC 8655,
+              DOI 10.17487/RFC8655, October 2019,
+              <https://www.rfc-editor.org/info/rfc8655>.
+
+   [RFC8928]  Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
+              "Address-Protected Neighbor Discovery for Low-Power and
+              Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
+              2020, <https://www.rfc-editor.org/info/rfc8928>.
+
+   [RFC8929]  Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
+              "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
+              November 2020, <https://www.rfc-editor.org/info/rfc8929>.
+
+   [RFC8930]  Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On
+              Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6
+              Network", RFC 8930, DOI 10.17487/RFC8930, November 2020,
+              <https://www.rfc-editor.org/info/rfc8930>.
+
+   [RFC8931]  Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal
+              Area Network (6LoWPAN) Selective Fragment Recovery",
+              RFC 8931, DOI 10.17487/RFC8931, November 2020,
+              <https://www.rfc-editor.org/info/rfc8931>.
+
+   [RFC9008]  Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
+              Option Type, Routing Header for Source Routes, and IPv6-
+              in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
+              DOI 10.17487/RFC9008, April 2021,
+              <https://www.rfc-editor.org/info/rfc9008>.
+
+   [RFC9010]  Thubert, P., Ed. and M. Richardson, "Routing for RPL
+              (Routing Protocol for Low-Power and Lossy Networks)
+              Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
+              <https://www.rfc-editor.org/info/rfc9010>.
+
+   [RFC9031]  Vučinić, M., Ed., Simon, J., Pister, K., and M.
+              Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
+              RFC 9031, DOI 10.17487/RFC9031, May 2021,
+              <https://www.rfc-editor.org/info/rfc9031>.
+
+   [RFC9032]  Dujovne, D., Ed. and M. Richardson, "Encapsulation of
+              6TiSCH Join and Enrollment Information Elements",
+              RFC 9032, DOI 10.17487/RFC9032, May 2021,
+              <https://www.rfc-editor.org/info/rfc9032>.
+
+   [RFC9033]  Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy,
+              S., and D. Dujovne, "6TiSCH Minimal Scheduling Function
+              (MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021,
+              <https://www.rfc-editor.org/info/rfc9033>.
+
+7.2.  Informative References
+
+   [AMI]      U.S. Department of Energy, "Advanced Metering
+              Infrastructure and Customer Systems", 2006,
+              <https://www.energy.gov/sites/prod/files/2016/12/f34/
+              AMI%20Summary%20Report_09-26-16.pdf>.
+
+   [ANIMA]    IETF, "Autonomic Networking Integrated Model and Approach
+              (anima)",
+              <https://datatracker.ietf.org/doc/charter-ietf-anima/>.
+
+   [AODV-RPL] Anamalamudi, S., Zhang, M., Perkins, C. E., Anand, S., and
+              B. Liu, "Supporting Asymmetric Links in Low Power
+              Networks: AODV-RPL", Work in Progress, Internet-Draft,
+              draft-ietf-roll-aodv-rpl-10, 4 April 2021,
+              <https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-10>.
+
+   [AODVv2]   Perkins, C. E., Ratliff, S., Dowdell, J., Steenbrink, L.,
+              and V. Mercieca, "Ad Hoc On-demand Distance Vector Version
+              2 (AODVv2) Routing", Work in Progress, Internet-Draft,
+              draft-ietf-manet-aodvv2-16, 4 May 2016,
+              <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-16>.
+
+   [BITSTRINGS-6LORH]
+              Thubert, P., Ed., Brodard, Z., Jiang, H., and G. Texier,
+              "A 6loRH for BitStrings", Work in Progress, Internet-
+              Draft, draft-thubert-6lo-bier-dispatch-06, 28 January
+              2019, <https://tools.ietf.org/html/draft-thubert-6lo-bier-
+              dispatch-06>.
+
+   [CCAMP]    IETF, "Common Control and Measurement Plane (ccamp)",
+              <https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
+
+   [CCMstar]  Struik, R., "Formal Specification of the CCM* Mode of
+              Operation", September 2004, <http://www.ieee802.org/15/
+              pub/2004/15-04-0537-00-004b-formal-specification-ccm-star-
+              mode-operation.doc>.
+
+   [CONSTRAINED-VOUCHER]
+              Richardson, M., van der Stok, P., and P. Kampanakis,
+              "Constrained Voucher Artifacts for Bootstrapping
+              Protocols", Work in Progress, Internet-Draft, draft-ietf-
+              anima-constrained-voucher-10, 21 February 2021,
+              <https://tools.ietf.org/html/draft-ietf-anima-constrained-
+              voucher-10>.
+
+   [DAO-PROJECTION]
+              Thubert, P., Jadhav, R. A., and M. Gillmore, "Root
+              initiated routing state in RPL", Work in Progress,
+              Internet-Draft, draft-ietf-roll-dao-projection-16, 15
+              January 2021, <https://tools.ietf.org/html/draft-ietf-
+              roll-dao-projection-16>.
+
+   [EDHOC]    Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
+              Diffie-Hellman Over COSE (EDHOC)", Work in Progress,
+              Internet-Draft, draft-selander-ace-cose-ecdhe-14, 11
+              September 2019, <https://tools.ietf.org/html/draft-
+              selander-ace-cose-ecdhe-14>.
+
+   [EST-COAPS]
+              van der Stok, P., Kampanakis, P., Richardson, M., and S.
+              Raza, "EST over secure CoAP (EST-coaps)", Work in
+              Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6
+              January 2020,
+              <https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>.
+
+   [HART]     FieldComm Group, "HART",
+              <https://fieldcommgroup.org/technologies/hart>.
+
+   [IEC62439] IEC, "Industrial communication networks - High
+              availability automation networks - Part 3: Parallel
+              Redundancy Protocol (PRP) and High-availability Seamless
+              Redundancy (HSR)", IEC 62439-3:2016, 2016,
+              <https://webstore.iec.ch/publication/24438>.
+
+   [IEEE802154]
+              IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
+              Standard 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
+              April 2016,
+              <https://ieeexplore.ieee.org/document/7460875>.
+
+   [IEEE802154e]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks -- Part. 15.4: Low-Rate Wireless Personal Area
+              Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE
+              Standard 802.15.4e-2012, DOI 10.1109/IEEESTD.2012.6185525,
+              April 2012,
+              <https://ieeexplore.ieee.org/document/6185525>.
+
+   [ISA100]   ISA/ANSI, "ISA100, Wireless Systems for Automation",
+              <https://www.isa.org/isa100/>.
+
+   [ISA100.11a]
+              ISA/ANSI, "Wireless Systems for Industrial Automation:
+              Process Control and Related Applications - ISA100.11a-
+              2011", IEC 62734:2014, 2011,
+              <https://webstore.iec.ch/publication/65581>.
+
+   [ND-UNICAST-LOOKUP]
+              Thubert, P., Ed. and E. Levy-Abegnoli, "IPv6 Neighbor
+              Discovery Unicast Lookup", Work in Progress, Internet-
+              Draft, draft-thubert-6man-unicast-lookup-00, 29 July 2019,
+              <https://tools.ietf.org/html/draft-thubert-6man-unicast-
+              lookup-00>.
+
+   [PCE]      IETF, "Path Computation Element (pce)",
+              <https://datatracker.ietf.org/doc/charter-ietf-pce/>.
+
+   [RAW-ARCHITECTURE]
+              Thubert, P., Ed. and G. Z. Papadopoulos, "Reliable and
+              Available Wireless Problem Statement", Work in Progress,
+              Internet-Draft, draft-pthubert-raw-architecture-05, 15
+              November 2020, <https://tools.ietf.org/html/draft-
+              pthubert-raw-architecture-05>.
+
+   [RAW-USE-CASES]
+              Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
+              Bernardos, "RAW use cases", Work in Progress, Internet-
+              Draft, draft-ietf-raw-use-cases-01, 21 February 2021,
+              <https://tools.ietf.org/html/draft-ietf-raw-use-cases-01>.
+
+   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
+              "Definition of the Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474,
+              DOI 10.17487/RFC2474, December 1998,
+              <https://www.rfc-editor.org/info/rfc2474>.
+
+   [RFC2545]  Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
+              Extensions for IPv6 Inter-Domain Routing", RFC 2545,
+              DOI 10.17487/RFC2545, March 1999,
+              <https://www.rfc-editor.org/info/rfc2545>.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <https://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
+              Information Models and Data Models", RFC 3444,
+              DOI 10.17487/RFC3444, January 2003,
+              <https://www.rfc-editor.org/info/rfc3444>.
+
+   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
+              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
+              RFC 3963, DOI 10.17487/RFC3963, January 2005,
+              <https://www.rfc-editor.org/info/rfc3963>.
+
+   [RFC4080]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
+              Bosch, "Next Steps in Signaling (NSIS): Framework",
+              RFC 4080, DOI 10.17487/RFC4080, June 2005,
+              <https://www.rfc-editor.org/info/rfc4080>.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
+              2006, <https://www.rfc-editor.org/info/rfc4291>.
+
+   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
+              DOI 10.17487/RFC4903, June 2007,
+              <https://www.rfc-editor.org/info/rfc4903>.
+
+   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
+              over Low-Power Wireless Personal Area Networks (6LoWPANs):
+              Overview, Assumptions, Problem Statement, and Goals",
+              RFC 4919, DOI 10.17487/RFC4919, August 2007,
+              <https://www.rfc-editor.org/info/rfc4919>.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+              <https://www.rfc-editor.org/info/rfc5340>.
+
+   [RFC5974]  Manner, J., Karagiannis, G., and A. McDonald, "NSIS
+              Signaling Layer Protocol (NSLP) for Quality-of-Service
+              Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010,
+              <https://www.rfc-editor.org/info/rfc5974>.
+
+   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
+              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
+              2011, <https://www.rfc-editor.org/info/rfc6275>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+              January 2012, <https://www.rfc-editor.org/info/rfc6347>.
+
+   [RFC6606]  Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
+              Statement and Requirements for IPv6 over Low-Power
+              Wireless Personal Area Network (6LoWPAN) Routing",
+              RFC 6606, DOI 10.17487/RFC6606, May 2012,
+              <https://www.rfc-editor.org/info/rfc6606>.
+
+   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
+              Locator/ID Separation Protocol (LISP)", RFC 6830,
+              DOI 10.17487/RFC6830, January 2013,
+              <https://www.rfc-editor.org/info/rfc6830>.
+
+   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
+              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
+              Defined Networking (SDN): Layers and Architecture
+              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
+              2015, <https://www.rfc-editor.org/info/rfc7426>.
+
+   [RFC8578]  Grossman, E., Ed., "Deterministic Networking Use Cases",
+              RFC 8578, DOI 10.17487/RFC8578, May 2019,
+              <https://www.rfc-editor.org/info/rfc8578>.
+
+   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
+              "Object Security for Constrained RESTful Environments
+              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
+              <https://www.rfc-editor.org/info/rfc8613>.
+
+   [RFC8939]  Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
+              Bryant, "Deterministic Networking (DetNet) Data Plane:
+              IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
+              <https://www.rfc-editor.org/info/rfc8939>.
+
+   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
+              and K. Watsen, "Bootstrapping Remote Secure Key
+              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
+              May 2021, <https://www.rfc-editor.org/info/rfc8995>.
+
+   [RFC9035]  Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
+              Power and Lossy Networks (RPL) Destination-Oriented
+              Directed Acyclic Graph (DODAG) Configuration Option for
+              the 6LoWPAN Routing Header", RFC 9035,
+              DOI 10.17487/RFC9035, April 2021,
+              <https://www.rfc-editor.org/info/rfc9035>.
+
+   [ROBUST-SCHEDULING]
+              Tiloca, M., Duquennoy, S., and G. Dini, "Robust Scheduling
+              against Selective Jamming in 6TiSCH Networks", Work in
+              Progress, Internet-Draft, draft-tiloca-6tisch-robust-
+              scheduling-02, 10 June 2019, <https://tools.ietf.org/html/
+              draft-tiloca-6tisch-robust-scheduling-02>.
+
+   [RPL-APPLICABILITY]
+              Phinney, T., Ed., Thubert, P., and R. Assimiti, "RPL
+              applicability in industrial networks", Work in Progress,
+              Internet-Draft, draft-ietf-roll-rpl-industrial-
+              applicability-02, 21 October 2013,
+              <https://tools.ietf.org/html/draft-ietf-roll-rpl-
+              industrial-applicability-02>.
+
+   [RPL-BIER] Thubert, P., Ed., "RPL-BIER", Work in Progress, Internet-
+              Draft, draft-thubert-roll-bier-02, 24 July 2018,
+              <https://tools.ietf.org/html/draft-thubert-roll-bier-02>.
+
+   [RPL-MOP]  Jadhav, R., Ed., Thubert, P., Richardson, M., and R.
+              Sahoo, "RPL Capabilities", Work in Progress, Internet-
+              Draft, draft-ietf-roll-capabilities-08, 17 March 2021,
+              <https://tools.ietf.org/html/draft-ietf-roll-capabilities-
+              08>.
+
+   [S-ALOHA]  Roberts, L. G., "ALOHA packet system with and without
+              slots and capture", ACM SIGCOMM Computer Communication
+              Review, DOI 10.1145/1024916.1024920, April 1975,
+              <https://dl.acm.org/citation.cfm?id=1024920>.
+
+   [TE-PREF]  Thubert, P., Ed., Eckert, T., Brodard, Z., and H. Jiang,
+              "BIER-TE extensions for Packet Replication and Elimination
+              Function (PREF) and OAM", Work in Progress, Internet-
+              Draft, draft-thubert-bier-replication-elimination-03, 3
+              March 2018, <https://tools.ietf.org/html/draft-thubert-
+              bier-replication-elimination-03>.
+
+   [TEAS]     IETF, "Traffic Engineering Architecture and Signaling
+              (teas)",
+              <https://datatracker.ietf.org/doc/charter-ietf-teas/>.
+
+   [VIRTUAL-REASSEMBLY]
+              Bormann, C. and T. Watteyne, "Virtual reassembly buffers
+              in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-
+              lwig-6lowpan-virtual-reassembly-02, 9 March 2020,
+              <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-
+              virtual-reassembly-02>.
+
+   [WirelessHART]
+              International Electrotechnical Commission, "Industrial
+              networks - Wireless communication network and
+              communication profiles - WirelessHART(TM)",
+              IEC 62591:2016, March 2016,
+              <https://webstore.iec.ch/publication/24433>.
+
+   [ZEROTOUCH-JOIN]
+              Richardson, M., "6tisch Zero-Touch Secure Join protocol",
+              Work in Progress, Internet-Draft, draft-ietf-6tisch-
+              dtsecurity-zerotouch-join-04, 8 July 2019,
+              <https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-
+              zerotouch-join-04>.
+
+Appendix A.  Related Work in Progress
+
+   This document has been incremented as the work progressed following
+   the evolution of the WG charter and the availability of dependent
+   work.  The intent was to publish when the WG concluded on the covered
+   items.  At the time of publishing, the following specifications are
+   still in progress and may affect the evolution of the stack in a
+   6TiSCH-aware node.
+
+A.1.  Unchartered IETF Work Items
+
+A.1.1.  6TiSCH Zero-Touch Security
+
+   The security model and in particular the zero-touch join process
+   [ZEROTOUCH-JOIN] depend on the ANIMA (Autonomic Networking Integrated
+   Model and Approach) [ANIMA] "Bootstrapping Remote Secure Key
+   Infrastructure (BRSKI)" [RFC8995] to enable zero-touch security
+   provisioning; for highly constrained nodes, a minimal model based on
+   pre-shared keys (PSK) is also available.  As currently written, it
+   also depends on a number of documents in progress in the CORE
+   (Constrained RESTful Environments) WG and on "Ephemeral
+   Diffie-Hellman Over COSE (EDHOC)" [EDHOC], which is being considered
+   for adoption by the LAKE (Lightweight Authenticated Key Exchange) WG.
+
+A.1.2.  6TiSCH Track Setup
+
+   ROLL (Routing Over Low power and Lossy networks) is now standardizing
+   a reactive routing protocol based on RPL [AODV-RPL].  The need of a
+   reactive routing protocol to establish on-demand, constraint-
+   optimized routes and a reservation protocol to establish Layer 3
+   Tracks is being discussed in 6TiSCH but not yet chartered.
+
+   At the time of this writing, there is new work planned in the IETF to
+   provide limited deterministic networking capabilities for wireless
+   networks with a focus on forwarding behaviors to react quickly and
+   locally to the changes as described in [RAW-ARCHITECTURE].
+
+   ROLL is also standardizing an extension to RPL to set up centrally
+   computed routes [DAO-PROJECTION].
+
+   The 6TiSCH architecture should thus inherit from the DetNet
+   architecture [RFC8655] and thus depends on it.  The PCE should be a
+   core component of that architecture.  An extension to RPL or to TEAS
+   (Traffic Engineering Architecture and Signaling) [TEAS] will be
+   required to expose the 6TiSCH node capabilities and the network peers
+   to the PCE, possibly in combination with [RPL-MOP].  A protocol such
+   as a lightweight Path Computation Element Communication Protocol
+   (PCEP) or an adaptation of Common Control and Measurement Plane
+   (CCAMP) [CCAMP] GMPLS formats and procedures could be used in
+   combination to [DAO-PROJECTION] to install the Tracks, as computed by
+   the PCE, to the 6TiSCH nodes.
+
+A.1.3.  Using BIER in a 6TiSCH Network
+
+   ROLL is actively working on Bit Index Explicit Replication (BIER) as
+   a method to compress both the data-plane packets and the routing
+   tables in storing mode [RPL-BIER].
+
+   BIER could also be used in the context of the DetNet service layer.
+   "BIER-TE extensions for Packet Replication and Elimination Function
+   (PREF) and OAM" [TE-PREF] leverages BIER Traffic Engineering (TE) to
+   control the DetNet Replication and Elimination activities in the data
+   plane, and to provide traceability on links where replication and
+   loss happen, in a manner that is abstract to the forwarding
+   information.
+
+   "A 6loRH for BitStrings" [BITSTRINGS-6LORH] proposes a 6LoWPAN
+   compression for the BIER BitString based on 6LoWPAN Routing Header
+   [RFC8138].
+
+A.2.  External (Non-IETF) Work Items
+
+   The current charter positions 6TiSCH on IEEE Std 802.15.4 only.
+   Though most of the design should be portable to other link types,
+   6TiSCH has a strong dependency on IEEE Std 802.15.4 and its
+   evolution.  The impact of changes to TSCH on this architecture should
+   be minimal to nonexistent, but deeper work such as 6top and security
+   may be impacted.  A 6TiSCH Interest Group at the IEEE maintains the
+   synchronization and helps foster work at the IEEE should 6TiSCH
+   demand it.
+
+   Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would
+   logically include the 6top sublayer.  The interaction with the 6top
+   sublayer and the Scheduling Functions described in this document are
+   yet to be defined.
+
+   ISA100 [ISA100] Common Network Management (CNM) is another external
+   work of interest for 6TiSCH.  The group, referred to as ISA100.20,
+   defines a Common Network Management framework that should enable the
+   management of resources that are controlled by heterogeneous
+   protocols such as ISA100.11a [ISA100.11a], WirelessHART
+   [WirelessHART], and 6TiSCH.  Interestingly, the establishment of
+   6TiSCH deterministic paths, called Tracks, are also in scope, and
+   ISA100.20 is working on requirements for DetNet.
+
+Acknowledgments
+
+Special Thanks
+
+   Special thanks to Jonathan Simon, Giuseppe Piro, Subir Das, and
+   Yoshihiro Ohba for their deep contributions 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.
+
+   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.
+
+   Special thanks to Ted Lemon, who was the INT Area Director 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.
+
+   Also special thanks to Ralph Droms, who performed the first INT Area
+   Directorate review, which was very deep and thorough and radically
+   changed the orientations of this document, and then to Eliot Lear and
+   Carlos Pignataro, who helped finalize this document in preparation
+   for the IESG reviews, and to Gorry Fairhurst, David Mandelberg, Qin
+   Wu, Francis Dupont, Éric Vyncke, Mirja Kühlewind, Roman Danyliw,
+   Benjamin Kaduk, and Andrew Malis, who contributed to the final
+   shaping of this document through the IESG review procedure.
+
+And Do Not Forget
+
+   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.
+
+   The authors wish to thank in arbitrary order: Alaeddine Weslati,
+   Chonggang Wang, Georgios Exarchakos, Zhuo Chen, Georgios
+   Papadopoulos, Eric Levy-Abegnoli, Alfredo Grieco, Bert Greevenbosch,
+   Cedric Adjih, Deji Chen, Martin Turon, Dominique Barthel, Elvis
+   Vogli, Geraldine Texier, Guillaume Gaillard, Herman Storey, Kazushi
+   Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Toutain, Maik
+   Seewald, Michael Behringer, Nancy Cam Winget, Nicola Accettura,
+   Nicolas Montavont, Oleg Hahm, Patrick Wetterwald, Paul Duffy, Peter
+   van der Stok, Rahul Sen, Pieter de Mil, Pouria Zand, Rouhollah
+   Nabati, Rafa Marin-Lopez, Raghuram Sudhaakar, Sedat Gormus, Shitanshu
+   Shah, Steve Simlo, Tina Tsou, Tom Phinney, Xavier Lagrange, Ines
+   Robles, and Samita Chakrabarti for their participation and various
+   contributions.
+
+Contributors
+
+   The co-authors of this document are listed below:
+
+      Thomas Watteyne for his contributions to the whole design, in
+      particular on TSCH and security, and to the open source community
+      that he created with openWSN;
+
+      Xavier Vilajosana, who led the design of the minimal support with
+      RPL and contributed deeply to the 6top design and the GMPLS
+      operation of Track switching;
+
+      Kris Pister for creating TSCH and his continuing guidance through
+      the elaboration of this design;
+
+      Mališa Vučinić for the work on the one-touch join process and his
+      contribution to the Security Design Team;
+
+      Michael Richardson for his leadership role in the Security Design
+      Team and his contribution throughout this document;
+
+      Tero Kivinen for his contribution to the security work in general
+      and the security section in particular;
+
+      Maria Rita Palattella for managing the Terminology document that
+      was merged into this document through the work of 6TiSCH;
+
+      Simon Duquennoy for his contribution to the open source community
+      with the 6TiSCH implementation of contiki, and for his
+      contribution to MSF and autonomous unicast cells;
+
+      Qin Wang, who led the design of the 6top sublayer and contributed
+      related text that was moved and/or adapted into this document;
+
+      Rene Struik for the security section and his contribution to the
+      Security Design Team;
+
+      Robert Assimiti for his breakthrough work on RPL over TSCH and
+      initial text and guidance.
+
+Author's Address
+
+   Pascal Thubert (editor)
+   Cisco Systems, Inc
+   Building D
+   45 Allee des Ormes - BP1200
+   06254 Mougins - Sophia Antipolis
+   France
+
+   Phone: +33 497 23 26 34
+   Email: pthubert@cisco.com