<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="info" ipr='trust200902'
ipr="trust200902"
tocInclude="true"
sortRefs="true"
symRefs="true"
obsoletes=""
updates=""
consensus="true"
submissionType="IETF"
xml:lang="en"
version="3"
docName="draft-ietf-6tisch-architecture-30" >
number="9030">

<front>

   <title abbrev='6tisch-architecture'>An abbrev="6TiSCH Architecture">An Architecture for IPv6 over
the TSCH mode Time-Slotted Channel Hopping Mode of IEEE 802.15.4</title> 802.15.4 (6TiSCH)</title>
   <seriesInfo name="RFC" value="9030"/>

   <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'> initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization abbrev='Cisco Systems'>Cisco abbrev="Cisco Systems">Cisco Systems, Inc</organization>
      <address>
         <postal>
            <street>Building D</street>
            <extaddr>Building D</extaddr>
            <street>45 Allee des Ormes - BP1200 </street>
            <city>Mougins - Sophia Antipolis</city>
            <code>06254</code>
          <country>France</country>
         </postal>
         <phone>+33 497 23 26 34</phone>
         <email>pthubert@cisco.com</email>
      </address>
   </author>

   <date/>

   <date month="May" year="2021"/>

   <area>Internet Area</area>
   <workgroup>6TiSCH</workgroup>
   <keyword>Draft</keyword>
   <keyword>deterministic wireless</keyword>
   <keyword>radio</keyword>
   <keyword>mesh</keyword>
   <abstract>
      <t>   This document describes a network architecture that provides
   low-latency, low-jitter 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 LowPower low-power wireless deterministic applications.
    <!--
         This document presents the 6TiSCH architecture of an IPv6
         Multi-Link subnet that is composed of a high-speed powered backbone and
         a number of IEEE Std. 802.15.4 TSCH low-power wireless networks attached and
         synchronized by Backbone Routers. The architecture defines mechanisms
         to establish and maintain routing and scheduling in a centralized,
         distributed, or mixed fashion.

         Backbone Routers perform proxy Neighbor Discovery operations over
         the backbone on behalf of the wireless devices, so they can share a same
         subnet and appear to be connected to the same backbone as classical devices.
         -->
      </t>
   </abstract>
   <!--note title="Requirements Language">
      <t>
         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
         and "OPTIONAL" in this document are to be interpreted as described
         in <xref target="RFC2119">RFC 2119</xref>.
      </t>
   </note-->
</front>

<middle>
   <section><name>Introduction</name>
      <t>
         Wireless Networks 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 instance, on fast-moving or rotating devices.
      </t>
      <t>
         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.
<!--         At IEEE Std. 802.1, the
         <xref target="IEEE Std. 802.1TSNTG">Time Sensitive Networking</xref>(TSN)
         task group was formed to provide deterministic properties at Layer-2
         across multiple hops. -->
         Applications that need such networks are presented in
         <xref target='RFC8578'/>.
         <!--and target="RFC8578"/>
         and
         <xref target="I-D.bernardos-raw-use-cases"/>, target="I-D.ietf-raw-use-cases"/>, which presents a number
         of additional use cases for Reliable and Available Wireless networks.
         --> networks (RAW).
         The considered applications include Professional Media, 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.
      </t>
      <t>
         The Timeslotted Time-Slotted Channel Hopping (TSCH) <xref target='RFC7554'/> target="RFC7554"/> mode
         of the IEEE Std. Std 802.15.4 <xref target='IEEE802154'/> target="IEEE802154"/> Medium Access
         Control (MAC) was introduced with the IEEE Std. Std 802.15.4e
         <xref target='IEEE802154e'/> target="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 technique (FDM) technique, whereby a different channel can be used for
         each transmission, and that transmission. TSCH allows to schedule the scheduling of transmissions for
         deterministic operations, operations and applies to the slower and most energy
         constrained
         energy-constrained wireless use cases.
      </t>
      <t>
         The scheduled operation provides for a more reliable experience experience, which
         can be used to monitor and manage resources, e.g., energy and water, in
         a more efficient fashion.
      </t>
      <t>
         Proven Deterministic Networking deterministic networking standards for use in Process Control, process control,
         including ISA100.11a <xref target='ISA100.11a'/> target="ISA100.11a"/> and WirelessHART
         <xref target='WirelessHART'/>, target="WirelessHART"/>, have demonstrated the capabilities
         of the IEEE Std. 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.
      </t>
      <t>To enable the convergence of Information Technology information technology (IT) and
         Operational Technology
         operational technology (OT) in Low-Power and Lossy
         Networks (LLNs), the 6TiSCH Architecture architecture supports an IETF suite of
         protocols over the IEEE Std. Std 802.15.4 TSCH MAC to provide
         IP connectivity for energy and otherwise constrained wireless devices.
      </t>
      <t>
         The 6TiSCH Architecture architecture relies on IPv6 <xref target='RFC8200'/> target="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 Layer 2 transit Link link such as
         an Ethernet bridged network, but it can also be a more complex routed
         structure.
      </t>
      <t>
         The 6TiSCH Architecture architecture introduces an IPv6 Multi-Link multi-link subnet model that
         is composed of a federating backbone and a number of IEEE Std. Std 802.15.4
         TSCH low-power wireless networks federated and synchronized by Backbone
         Routers. If the backbone is a Layer-2 Layer 2 transit Link link, then the Backbone
         Routers can operate as an IPv6 Neighbor Discovery (IPv6 ND) proxy
         <xref target='RFC4861'/> proxy. target="RFC4861"/>.
         </t>
      <t>

         The 6TiSCH
         Architecture architecture leverages 6LoWPAN <xref target='RFC4944'/> target="RFC4944"/> to adapt IPv6
         to the constrained media and RPL the
          Routing Protocol for Low-Power and Lossy Networks (RPL) <xref target='RFC6550'/> target="RFC6550"/> for the
         distributed routing operations.
         </t>
      <t>
         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 distributed routing refers to a model that relies on
         concurrent peer to peer peer-to-peer protocol exchanges for TSCH resource allocation
         and routing operations.
         </t>
      <t>
          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
         <xref target='AMI'/> target="AMI"/> solutions that leverage distributed routing to
         enable multipath forwarding over large LLN meshes.
         </t>

   </section>

<section><name>Terminology</name>
<!--
<section anchor='bcp' title="BCP 14">
<t>-

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP 14
    <xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they
    appear in all capitals, as shown here.

</t>
</section>    end section "BCP 14" -->

    <section anchor='sixTTerminology'><name>New anchor="sixTTerminology"><name>New Terms</name>

        <t>
            The draft document does not reuse terms from the <xref target='IEEE802154'> target="IEEE802154">
            IEEE Std. Std 802.15.4</xref> standard such as "path" or "link" "link", which bear
            a meaning that is quite different from classical IETF parlance.
        </t>
        <t>
            This
        <t>This document adds the following terms:
            </t><dl  spacing='normal'> terms:</t>
            <dl spacing="normal">
                <dt>6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4):</dt><dd>
                  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/PHY
                 MAC/Physical Layer (PHY) pairs providing a service similar to TSCH.
                </dd>
                <dt>6top (6TiSCH Operation Sublayer):</dt><dd>
                 The next higher layer of the IEEE Std. 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.
                </dd>
                <dt>6P (6top Protocol):</dt><dd>
                    The protocol defined in <xref target='RFC8480'/>. target="RFC8480"/>.
                    6P enables Layer-2 Layer 2 peers to allocate, move move, or deallocate  de-allocate
                    cells in their respective schedules to communicate.
                    6P operates at the 6top layer. sublayer.
                </dd>
                <dt>6P Transaction:</dt><dd> transaction:</dt><dd>
                    A 2-way or 3-way sequence of 6P messages used by Layer-2 Layer 2
                    peers to modify their communication schedule.
                </dd>
                <dt>ASN (Absolute Slot Number):</dt><dd>
                    Defined in <xref target='IEEE802154'/>, target="IEEE802154"/>, the ASN is the total
                    number of timeslots that have elapsed since the Epoch Time time
                    when the TSCH network started.
                    Incremented by one at each timeslot.
                    It is wide enough to not roll over in practice.
                </dd>
                <!--
                <t hangText="blacklist of frequencies:">
                <dt>bundle:</dt><dd>
                    A set group of frequencies which should not be used for
                    communication.
                </t>
                <t hangText="broadcast cell:">
                    A scheduled cell used for broadcast transmission.
                </t> -->
                <dt>bundle:</dt><dd>
                    A group of equivalent equivalent scheduled cells, i.e., cells
                    identified by different [slotOffset, channelOffset], 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.
                </dd>
                <dt>Layer-2
                <dt>Layer 2 vs. Layer-3 Layer 3 bundle:</dt><dd>
                    Bundles are associated for with either Layer-2 Layer 2 (switching) or
                    Layer-3
                    Layer 3 (routing) forwarding operations. A pair of Layer-3 Layer 3
                    bundles (one for each direction) maps to an IP Link link with a
                    neighbor, whereas a set of Layer-2 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.
                 </dd>
                <dt>CCA (Clear Channel Assessment):</dt><dd>
                    A mechanism defined in <xref target='IEEE802154'/> target="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.
                </dd>
                <dt>cell:</dt><dd>
                    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.
                </dd>
                <dt>Channel Distribution/Usage (CDU) matrix:</dt><dd>:
                    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, 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), slotOffset/channelOffset,
                    belongs to a specific chunk.
                </dd>
                <dt>channelOffset:</dt><dd>
                    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 channel-hopping
                    operation.
                </dd>
                <dt>chunk:</dt><dd>
                    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, node among its children.
                </dd>
                <dt>CoJP (Constrained Join Protocol):</dt><dd>

                    <!--
                    CoJP is a one-touch join protocol defined in the
                    <xref target="I-D.ietf-6tisch-minimal-security">
                    Minimal Security Framework for 6TiSCH</xref>.
                    CoJP requires the distribution of preshared keys (PSK),  and enables a node to join with a single round trip
                    to the JRC via the JP.
                    -->
                    The Constrained Join Protocol (CoJP) enables a pledge to
                    securely join a 6TiSCH network and obtain network parameters
                    over a secure channel.
                    <!--
                    CoJP is defined in the
                    <xref target="I-D.ietf-6tisch-minimal-security">
                    Minimal Security Framework for 6TiSCH </xref>.
                    -->
                    "<xref target="RFC9031" format="title"/>" <xref target='I-D.ietf-6tisch-minimal-security'>
                    Minimal Security Framework for 6TiSCH </xref> target="RFC9031"/> defines
                    the minimal CoJP setup with pre-shared keys defined. In that
                    mode, CoJP can operate with a single round trip round-trip exchange.
                </dd>
                <dt>dedicated cell:</dt><dd>
                    A cell that is reserved for a given node to transmit to a specific neighbor.
                </dd>
                <dt>deterministic network:</dt><dd>
                    The generic concept of a deterministic network is defined
                    in the <xref target='RFC8655'>"DetNet target="RFC8655">"Deterministic Networking Architecture"</xref> document.
                    When applied to 6TiSCH, it refers to the reservation of Tracks Tracks,
                    which guarantees an end-to-end latency and optimizes the
                    Packet Delivery Ratio (PDR) for well-characterized flows.
                </dd>
                <dt>distributed cell reservation:</dt><dd>
                    A reservation of a cell  done by one or more in-network entities.
                </dd>
                <dt>distributed Track reservation:</dt><dd>
                    A reservation of a Track done by one or more in-network entities.
                </dd>
                <dt>EB (Enhanced Beacon):</dt><dd>
                    A special frame defined in <xref target='IEEE802154'/> target="IEEE802154"/>
                    used by a node, including the JP, Join Proxy (JP), to announce the presence
                    of the network.
                    It contains enough information for a pledge to synchronize to the network.
                </dd>
                <dt>hard cell:</dt><dd>
                    A scheduled cell which that the 6top sublayer may not relocate.
                </dd>
                <dt>hopping sequence:</dt><dd>
                    Ordered sequence of frequencies, identified by a Hopping_Sequence_ID, used for channel hopping when translating the channelOffset value into a frequency.
                </dd>
                <dt>IE (Information Element):</dt><dd>
                    Type-Length-Value containers placed at the end of the MAC header, header and used to pass data between layers or devices.
                    Some IE identifiers are managed by the IEEE <xref target='IEEE802154'/>. target="IEEE802154"/>.
                    Some IE identifiers are managed by the IETF <xref target='RFC8137'/>, and target="RFC8137"/>. <xref target='I-D.ietf-6tisch-enrollment-enhanced-beacon'/> target="RFC9032"/>
                    uses one subtype to support the selection of the Join Proxy.
                </dd>
                <dt>join process:</dt><dd>
                    The overall process that includes the discovery of the network by pledge(s) and the execution of the join protocol.
                </dd>
                <dt>join protocol:</dt><dd>
                    The protocol that allows the pledge to join the network.
                    The join protocol encompasses authentication, authorization authorization, and parameter distribution.
                    The join protocol is executed between the pledge and the JRC.
                </dd>
                <dt>joined node:</dt><dd>
                    The new device, device after having completed the join process, often just called a node.
                </dd>
                <dt>JP (Join Proxy):</dt><dd>
                    Node
                    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.
                </dd>
                 <dt>JRC (Join Registrar/Coordinator):</dt><dd>
                    Central entity responsible for the authentication, authorization authorization, and configuration of the pledge.
                </dd>

                <dt>link:</dt><dd>
                    A communication facility or medium over which nodes can communicate
                    at the Link-Layer, link layer, which is the layer immediately below IP. In 6TiSCH, the concept is implemented as a collection
                    of Layer-3 Layer 3 bundles. Note:
                    the IETF parlance for the term "Link" "link" is adopted, as opposed to the IEEE Std. Std 802.15.4 terminology.
                </dd>
                <dt>Operational Technology:</dt><dd>
                <dt>operational technology:</dt><dd>
                    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).
                </dd>
                <dt>pledge:</dt><dd>
                    A new device that attempts to join a 6TiSCH network.
                </dd>
                <dt>(to) relocate a cell:</dt><dd>
                    The action operated by the 6top sublayer of changing the slotOffset and/or channelOffset of a soft cell.
                </dd>
                <dt>(to) schedule a cell:</dt><dd>
                    The action of turning an unscheduled cell into a scheduled cell.
                </dd>
                <dt>scheduled cell:</dt><dd>
                    A cell which that is assigned a neighbor MAC address
                    (broadcast address is also possible), possible) and one or
                    more of the following flags: TX, RX, Shared Shared, and Timekeeping.
                    A scheduled cell can be used by the IEEE Std. Std 802.15.4 TSCH implementation to communicate.
                    A scheduled cell can either be a hard or a soft cell.
                </dd>
                <dt>SF (6top Scheduling Function):</dt><dd>
                    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.
                </dd>
                <dt>SFID (6top Scheduling Function Identifier):</dt><dd>
                    A 4-bit field identifying an SF.
                </dd>
                <dt>shared cell:</dt><dd>
                    A cell marked with both the "TX" TX and "shared" Shared flags.
                    This cell can be used by more than one transmitter node.
                    A back-off algorithm is used to resolve contention.
                </dd>
                <dt>slotframe:</dt><dd>
                    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, 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, slotframes based on the priority of its packets/traffic flows.
                    The timeslots in the Slotframe slotframe are indexed by the SlotOffset; slotOffset; the first timeslot is at SlotOffset slotOffset 0.
                </dd>
                <dt>slotOffset:</dt><dd>
                    A column in the TSCH schedule, i.e., the number of timeslots since the beginning of the current iteration of the slotframe.
                </dd>
                <dt>soft cell:</dt><dd>
                    A scheduled cell which that the 6top sublayer can relocate.
                </dd>
                <dt>time source neighbor:</dt><dd>
                    A neighbor that a node uses as its time reference, and to which it needs to keep its clock synchronized.
                </dd>
                <dt>timeslot:</dt><dd>
                    A basic communication unit in TSCH which that allows
                        a transmitter node to send a frame to a receiver neighbor, neighbor and
                        that allows the receiver neighbor to optionally send back an acknowledgment.
                </dd>
                <dt>Track:</dt><dd>
                    A Track is a Directed Acyclic Graph (DAG) that is used as a
                    complex multi-hop multihop path to the destination(s) of the path.
                    In the case of unicast traffic, the Track is a Destination
                    Oriented Destination-Oriented DAG (DODAG) where the Root of the DODAG is the
                    destination of the unicast traffic.
                    A Track enables replication, elimination elimination, and reordering functions on the way (more on those functions in
                    <xref target='RFC8655'/>. target="RFC8655"/>).
                    A Track reservation locks physical resources such as cells and buffers in every node along the DODAG.
                    A Track is associated with a owner that an owner, which can be for instance the destination of the Track.

                </dd>
                <dt>TrackID:</dt><dd>
                    A TrackID is either globally unique, 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, Typically, the Track owner is the ingress of the Track then
                    Track, the IPv6 source address of packets along the Track can be used as
                    identification of the owner owner, and a local InstanceID <xref target='RFC6550'/> target="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 <xref target='RFC6550'/> target="RFC6550"/> in an IPv6 packet
                    can unambiguously identify the Track and can be expressed in a compressed form using
                    <xref target='RFC8138'/>. target="RFC8138"/>.
                </dd>
                <dt>TSCH:</dt><dd>
                    A medium access mode of the <xref target='IEEE802154'> target="IEEE802154">
                    IEEE Std. Std 802.15.4</xref> standard which that uses
                    time synchronization to achieve ultra-low-power operation, operation and
                    channel hopping to enable high reliability.
                </dd>
                <dt>TSCH Schedule:</dt><dd>
                    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.
                </dd>
                <dt>Unscheduled Cell:</dt><dd>
                    A cell which that is not used by the IEEE Std. Std 802.15.4 TSCH implementation.
                </dd>
            </dl>
    </section>
      <section anchor='acronyms'><name>Abbreviations</name> anchor="acronyms"><name>Abbreviations</name>
    <t> This document uses the following abbreviations:
       </t><dl  spacing='normal'>
       </t>
    <dl spacing="normal">
       <dt>6BBR:</dt><dd> 6LoWPAN Backbone Router (router with a proxy ND function) </dd>
       <dt>6LBR:</dt><dd> 6LoWPAN Border Router (authoritative on DAD) Duplicate Address Detection (DAD)) </dd>
       <dt>6LN:</dt><dd> 6LoWPAN Node  </dd>
       <dt>6LR:</dt><dd> 6LoWPAN Router (relay to the registration process) </dd>
       <dt>6CIO:</dt><dd> Capability Indication Option </dd>
       <dt>(E)ARO:</dt><dd> (Extended) Address Registration Option  </dd>
       <dt>(E)DAR:</dt><dd> (Extended) Duplicate Address Request  </dd>
       <dt>(E)DAC:</dt><dd> (Extended) Duplicate Address Confirmation </dd>
       <dt>DAD:</dt><dd> Duplicate Address Detection </dd>
       <dt>DODAG:</dt><dd> Destination-Oriented Directed Acyclic Graph </dd>
       <dt>LLN:</dt><dd> Low-Power and Lossy Network (a typical IoT network)  </dd>
       <dt>NA:</dt><dd> Neighbor Advertisement </dd>
       <dt>NCE:</dt><dd> Neighbor Cache Entry  </dd>
       <dt>ND:</dt><dd> Neighbor Discovery  </dd>
       <dt>NDP:</dt><dd> Neighbor Discovery Protocol </dd>
       <dt>PCE:</dt><dd> Path Computation Element </dd>
       <dt>NME:</dt><dd> Network Management Entity  </dd>
       <dt>ROVR:</dt><dd> Registration Ownership Verifier (pronounced rover) </dd>
       <dt>RPL:</dt><dd> IPv6 Routing Protocol for LLNs (pronounced ripple) </dd>
       <dt>RA:</dt><dd> Router Advertisement  </dd>
       <dt>RS:</dt><dd> Router Solicitation  </dd>
       <dt>TSCH:</dt><dd> timeslotted Time-Slotted Channel Hopping </dd>
       <dt>TID:</dt><dd> Transaction ID (a sequence counter in the EARO) </dd>
       </dl>
</section>   <!-- end section "Abbreviations" -->

<section anchor='lo'><name>Related anchor="lo"><name>Related Documents</name>

      <t>
         The draft also document conforms to the terms and models described in
         <xref target='RFC3444'/> target="RFC3444"/> and <xref target='RFC5889'/> and target="RFC5889"/>, uses the
         vocabulary and the concepts defined in <xref target='RFC4291'/> target="RFC4291"/> for the
         IPv6 Architecture architecture, and refers to <xref target='RFC4080'/> for reservation
         <!-- signaling and <xref target="RFC5191"/> target="RFC4080"/> for authentication. --> reservation.
</t>
      <t>
         The draft document uses domain-specific terminology defined or referenced in:
         </t><ul empty='true' spacing='normal'>
        <li> 6LoWPAN ND
         in the following:
         </t>
<ul spacing="normal">
        <li>6LoWPAN ND:
          <xref target='RFC6775'>"Neighbor target="RFC6775">"Neighbor Discovery Optimization for Low-power and Lossy Networks"</xref> IPv6 over
          Low-Power Wireless Personal Area Networks (6LoWPANs)"</xref> and
          <xref target='RFC8505'>
          "Registration target="RFC8505">"Registration Extensions for 6LoWPAN IPv6 over Low-Power
          Wireless Personal Area Network (6LoWPAN) Neighbor Discovery"</xref>,
        </li>
        <li><xref target='RFC7102'>"Terms target="RFC7102">"Terms Used in Routing for Low-Power and Lossy Networks (LLNs)"</xref>,</li>
          <li> Networks"</xref>, and RPL
        </li>
        <li>RPL:
          <xref target='RFC6552'>"Objective target="RFC6552">"Objective Function Zero for the
          Routing Protocol for Low-Power and Lossy Networks (RPL)"
        </xref>, (RPL)"</xref> and
          <xref target='RFC6550'>"RPL: target="RFC6550">"RPL: IPv6 Routing Protocol for
          Low-Power and Lossy Networks"</xref>.</li> Networks"</xref>.
        </li>
   </ul><t>
   Other terms in use in LLNs are found in <xref target='RFC7228'> target="RFC7228">
   "Terminology for Constrained-Node Networks"</xref>.
</t><t>
    Readers are expected to be familiar with all the terms and concepts
    that are discussed in
    </t><ul spacing='normal'>
    <li> <xref target='RFC4861'>"Neighbor the following:
    </t>
<ul spacing="normal">
    <li><xref target="RFC4861">"Neighbor Discovery for IP version 6"
   </xref>, 6 (IPv6)"</xref> and
   <xref target='RFC4862'>"IPv6
    </li>
    <li><xref target="RFC4862">"IPv6 Stateless Address Autoconfiguration"
   </xref>.</li>
</ul><t>
</t> Autoconfiguration"</xref>.
    </li>
</ul>
    <t>In addition, readers would benefit from reading:
    </t><ul spacing='normal'> reading the following
    prior to this specification for a clear understanding of the art
    in ND-proxying and binding:
    </t>
<ul spacing="normal">
    <li><xref target='RFC6606'>"Problem target="RFC6606">"Problem Statement and Requirements for
    IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing"
    </xref>,</li> Routing"</xref>,
    </li>
    <li> <xref target='RFC4903'>"Multi-Link target="RFC4903">"Multi-Link Subnet Issues"</xref>, and
    </li>
    <li> <xref target='RFC4919'>"IPv6 target="RFC4919">"IPv6 over Low-Power
       Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
       Problem Statement, and Goals"</xref></li>
    </ul><t> prior to this specification for a clear
       understanding of the art in ND-proxying and binding.
    </t> Goals"</xref>.
    </li>
    </ul>
</section>   <!-- end section "References" -->

</section>   <!-- end section "Terminology" -->

   <section><name>High Level

   <section><name>High-Level Architecture</name>

   <section><name>A Non-Broadcast Multi-Access Non-broadcast Multi-access Radio Mesh Network</name>

      <t>
         A 6TiSCH network is an IPv6 <xref target='RFC8200'/> target="RFC8200"/> subnet which, that, in
         its basic configuration illustrated in <xref target='fig1'/>, target="fig1"/>, is a
         single Low-Power and Lossy Network (LLN) operating over a synchronized
         TSCH-based mesh.
      </t>

         <figure anchor='fig1'><name>Basic anchor="fig1"><name>Basic Configuration of a 6TiSCH Network</name>
<artwork><![CDATA[
            ---+-------- ............ ------------
               |      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
]]></artwork>
         </figure>
         <t>
         Inside a 6TiSCH LLN, nodes rely on <xref target='RFC6282'>6LoWPAN
         Header Compression target="RFC6282">6LoWPAN
         header compression (6LoWPAN HC)</xref> to encode IPv6 packets.
         From the perspective of the network layer, a single LLN interface
         (typically an IEEE Std. Std 802.15.4-compliant radio) may be seen as a collection
         of Links links with different capabilities for unicast or multicast services.
           </t><t>
         6TiSCH nodes join a mesh network by attaching to nodes that are already
         members of the mesh (see <xref target='rflo'/>). target="rflo"/>). The security aspects
         of the join process are further detailed in <xref target='sec'/>. target="sec"/>.
         In a mesh network, 6TiSCH nodes are not necessarily reachable from one
         another at Layer-2 Layer 2, and an LLN may span over multiple links.
           </t><t>
         This forms a homogeneous non-broadcast multi-access (NBMA) subnet,
         which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND)
         <xref target='RFC4861'/><xref target='RFC4862'/>. target="RFC4861"/> <xref target="RFC4862"/>. 6LoWPAN Neighbor
         Discovery (6LoWPAN ND) <xref target='RFC6775'/><xref target='RFC8505'/> target="RFC6775"/> <xref target="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 <xref target='I-D.ietf-6lo-ap-nd'/>. target="RFC8928"/>.
      </t>
      <t>
         Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses addresses
         and register registers them using 6LoWPAN ND. This guarantees that the addresses
         are unique and protects the address ownership over the subnet, more in
         <xref target='rreg'/>. target="rreg"/>.
      </t>
      <t>
         Within the NBMA subnet, <xref target='RFC6550'>RPL</xref> target="RFC6550">RPL</xref> enables
         routing  in the so-called Route Over "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 <xref target='RPLvs6lo'/>.
      </t><t> target="RPLvs6lo"/>.
      </t>
       <t>
         With TSCH, devices are time-synchronized time synchronized at the MAC level. The use of
         a particular RPL Instance for time synchronization is discussed in
         <xref target='sync'/>. target="sync"/>. With this mechanism, the time synchronization
         starts at the RPL Root and follows the RPL loopless routing topology.
      </t><t>
         RPL forms Destination Oriented 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 Section
         <xref target="RFC6550" section="3.1" sectionFormat="bare" format="default"/> of
         <xref target='RFC6550'>RPL</xref>, target="RFC6550">RPL</xref>, in particular
         "3.1.2.
         "<xref target="RFC6550" section="3.1.2" sectionFormat="bare" format="default"/> RPL Identifiers" and
         "3.1.3.
         "<xref target="RFC6550" section="3.1.3" sectionFormat="bare" format="default"/> Instances, DODAGs, and DODAG Versions".
         RPL adds artifacts in
         the data packets that are compressed with a 6LoWPAN addition
         <xref target='RFC8138'>6LoRH</xref>. target="RFC8138">6LoWPAN Routing Header (6LoRH)</xref>.
         In a preexisting network, the compression can be globally turned on in a
         DODAG once all nodes are migrated to support <xref target="RFC8138" format="default"/>
         using <xref target="RFC9035" format="default"/>.
      </t><t>
         Additional routing and scheduling protocols may be deployed to
         establish on-demand Peer-to-Peer 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) <xref target='PCE'/> target="PCE"/> that programs both the routes and
         the schedules inside the 6TiSCH nodes, nodes or by in a distributed fashion by
         using a reactive routing protocol and a Hop-by-Hop hop-by-hop scheduling protocol.
      </t>

      <t>
        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 to in the full routing protocol.
        The architecture also expects that a 6LoWPAN node that is not aware
        at all unaware
        of the RPL protocol may also connect as described in <xref target='I-D.ietf-roll-unaware-leaves'/>. target="RFC9010"/>.
        </t>

   </section>
   <section><name>A Multi-Link Subnet Model</name>
   <t>
    An extended configuration of the subnet comprises multiple LLNs as
    illustrated in <xref target='fig2'/>. target="fig2"/>.
    In the extended configuration, a Routing Registrar <xref target='RFC8505'/> target="RFC8505"/>
    may be connected to the node that acts as the RPL Root and / or 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 Registrar
    may perform IPv6 ND proxy operations, or operations; redistribute the registration in
    a routing protocol such as <xref target='RFC5340'>OSPF</xref> target="RFC5340">OSPF</xref> or
    <xref target='RFC2545'>BGP</xref>, target="RFC2545">BGP</xref>; or inject a route in a mobility protocol
    such as <xref target='RFC6275'>MIPv6</xref>, target="RFC6275">Mobile IPv6 (MIPv6)</xref>,
    <xref target='RFC3963'>NEMO
    </xref>, target="RFC3963">Network Mobility (NEMO)</xref>, or
    <xref target='RFC6830'>LISP</xref>. target="RFC6830">Locator/ID Separation Protocol (LISP)</xref>.
  </t>
 <t>
    Multiple LLNs can be interconnected and possibly synchronized over a
    backbone, which can be wired or wireless. The backbone can operate with
    IPv6 ND <xref target='RFC4861'/><xref target='RFC4862'/> procedures <xref target="RFC4861"/> <xref target="RFC4862"/> or an a
    hybrid of IPv6 ND and 6LoWPAN ND
    <xref target='RFC6775'/><xref target='RFC8505'/><xref target='I-D.ietf-6lo-ap-nd'/>. target="RFC6775"/> <xref target="RFC8505"/> <xref target="RFC8928"/>.
    </t>
         <figure anchor='fig2'><name>Extended anchor="fig2"><name>Extended Configuration of a 6TiSCH Network</name>
         <artwork><![CDATA[
                |
             +-----+                +-----+         +-----+
   (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
]]></artwork></figure>

    <t>
    A Routing Registrar that performs proxy IPv6 ND operations over the
    backbone on behalf of the 6TiSCH nodes is called a Backbone Router (6BBR)
    <xref target='I-D.ietf-6lo-backbone-router'/>. target="RFC8929"/>. The 6BBRs are
    placed along the wireless edge of a Backbone, backbone and federate multiple
    wireless links to form a single MultiLink Subnet. 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.
    </t>
    <t>
    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 address
    lookup using only unicast request/response exchanges.
    <xref target='I-D.thubert-6man-unicast-lookup'/> target="I-D.thubert-6man-unicast-lookup"/> is a proposed method that
    presents an example of how to this could be achieved with an extension of
    <xref target='RFC8505'/>, target="RFC8505"/>, using an optional 6LBR as a SubNet-level subnet-level registrar,
    as illustrated in <xref target='fig2'/>. target="fig2"/>.
    </t>
    <t>
    As detailed in <xref target='RPLvs6lo'/> target="RPLvs6lo"/>, 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 RPL, but not both.
    The preferred way of achieving this is to collocate/combine co-locate or combine them.
    The combined RPL Root and 6LBR may be collocated co-located with the 6BBR, or
    directly attached to the 6BBR. In the latter case, it leverages the
    extended registration process defined in <xref target='RFC8505'/> target="RFC8505"/> to proxy
    the 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so
    that the 6BBR may in turn perform proxy classical ND operations over the
    backbone.
    backbone as a proxy.
      </t>
      <t> The <xref target='RFC8655'>DetNet
    Architecture</xref> target="RFC8655">"Deterministic Networking Architecture"</xref>
    studies Layer-3 Layer 3 aspects of Deterministic Networks, Networks and
    covers networks that span multiple Layer-2 Layer 2 domains.
    If the Backbone backbone is Deterministic deterministic (such as defined by the Time Sensitive Time-Sensitive
    Networking WG (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.
      </t>
   </section>

   <section><name>TSCH: A a Deterministic MAC Layer</name>
      <t>
         Though at a different time scale (several orders of magnitude),
         both IEEE Std. 802.1TSN Std 802.1 TSN and IEEE Std. Std 802.15.4 TSCH
         standards provide Deterministic deterministic capabilities to the point that a packet
         that pertains
         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.
      </t>
      <t>
         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 to more closely engineer engineering
         the network for deterministic properties.
         The channel hopping channel-hopping aspect is a simple and efficient technique to combat
         multipath fading and co-channel interference.
      </t>
      <t>
         6TiSCH builds on the IEEE Std. 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 architecture also inherits the capability to perform a
         centralized route computation to achieve deterministic properties,
         though it relies on the IETF
         <xref target='RFC8655'>DetNet Architecture</xref>, target="RFC8655">DetNet architecture</xref>
         and IETF components such as the PCE
         <xref target='PCE'/>, target="PCE"/> for the protocol aspects.
      </t>
      <t>On top of this inheritance, 6TiSCH adds capabilities for distributed
         routing and scheduling operations based on the RPL routing protocol
         and capabilities to negotiate 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 use cases in industrial environments include plant setup and
         decommissioning, as well as monitoring a multiplicity of lots of lesser importance
         measurements minor
         notifications such as corrosion measurements, events, and events and mobile workers accessing access of
         local devices. devices by mobile workers.
      </t>
   </section>
   <section><name>Scheduling TSCH</name>

      <t>A scheduling operation attributes allocates cells in a Time-Division-Multiplexing
         (TDM) / Frequency-Division Multiplexing (FDM) TDM/FDM matrix
         called the Channel
         distribution/usage (CDU) to 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 <xref target='slotframes'/>. target="slotframes"/>.
         </t>
      <t>
         From
         At the MAC layer, the standpoint schedule of a 6TiSCH node (at the MAC layer), its schedule
         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 slotframes that
         repeat over and over. 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.
      </t>
        <t>
         The 6top sublayer (see <xref target='s6Pprot'/> target="s6Pprot"/> for more) hides the
         complexity of the schedule from the upper layers. The Link link abstraction
         that IP traffic utilizes is composed of a pair of Layer-3 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.
      </t>
        <t>
         Scheduling enables multiple simultaneous communications at a same time 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 fulfil fulfill the same role, e.g., receive IP packets from
         a peer, are grouped in bundles.

         </t>

      <t>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 Hop-by-Hop Scheduling.
         </t><dl  spacing='normal'> spacing="normal">
         <dt>Static Scheduling:</dt><dd>This refers to the minimal
         6TiSCH operation whereby a static schedule is configured for the whole
         network for use in a Slotted ALOHA <xref target='S-ALOHA'/> target="S-ALOHA"/> fashion.
         The static schedule is
         distributed through the native methods in the TSCH MAC layer
         and does not preclude other scheduling operations to co-exist 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 <xref target='RFC8180'>Minimal target="RFC8180">Minimal 6TiSCH Configuration
         </xref>.
         </dd>
         <dt>Neighbor-to-Neighbor Scheduling:</dt><dd>This refers to the
         dynamic adaptation of the bandwidth of the Links links that are used for IPv6
         traffic between adjacent peers. Scheduling Functions such as the
         <xref target='I-D.ietf-6tisch-msf'>"6TiSCH target="RFC9033">"6TiSCH Minimal Scheduling Function
         (MSF)"</xref> influence the operation of the MAC layer to add, update update,
         and remove cells in its own, own and its peer's schedules using 6P
         <xref target='RFC8480'/>, target="RFC8480"/>
         for the negotiation of the MAC resources.</dd>
         <dt>Centralized (or Remote) Monitoring and Schedule Management:</dt><dd>
         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
         with, and the load on on, the constrained device.
         This model is the TSCH adaption of the
         <xref target='RFC8655'>DetNet Architecture</xref>, target="RFC8655">DetNet architecture</xref>,
         and it enables Traffic Engineering with deterministic properties.
         </dd>
         <dt>Hop-by-hop
         <dt>Hop-by-Hop Scheduling:</dt><dd>This refers to the possibility to
         reserves of
         reserving cells along a path for a particular flow using a distributed
         mechanism.</dd>
         </dl><t>
         </t>
         </dl>
         <t>
         It is not expected that all use cases will require all those mechanisms.
         Static Scheduling with minimal configuration one is the only one that
         is expected in all implementations, since it provides a simple and
         solid basis for convergecast routing and time distribution.
         </t><t>
         A deeper dive in into those mechanisms can be found in <xref target='schd'/>. target="schd"/>.
      </t>

   </section>
      <section anchor='rtg3'><name>Distributed anchor="rtg3"><name>Distributed vs. Centralized Routing</name>

      <t>
      6TiSCH enables a mixed model of centralized routes and distributed routes.
      Centralized routes can can, for example example, be computed by an entity such as a PCE.
      6TiSCH leverages the <xref target='RFC6550'>RPL</xref> routing protocol target="RFC6550">RPL</xref>
      for interoperable interoperable, distributed routing operations.
      </t>
      <t>
      Both methods may inject routes in into the Routing Tables 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.
      </t>
      <t>
        <xref target='RFC6550'>RPL</xref> target="RFC6550">RPL</xref> 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 <xref target='RFC6550'>RPL</xref>, target="RFC6550">RPL</xref>, such as
        the <xref target='I-D.ietf-roll-aodv-rpl'>
        Asymmetric target="I-D.ietf-roll-aodv-rpl">
        "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks"</xref>
        AODV-RPL), Networks" (AODV-RPL)</xref>,
        which derives from the <xref target='I-D.ietf-manet-aodvv2'>
        Ad target="I-D.ietf-manet-aodvv2">
        "Ad Hoc On-demand Distance Vector Routing (AODV)</xref> (AODVv2) Routing"</xref>, will be
        selected for Hop-by-hop Hop-by-Hop Scheduling.
       </t>
      <t>
      Both RPL and PCE rely on shared sources such as policies to define Global global
      and Local local RPLInstanceIDs that can be used by either method. It is possible
      for centralized and distributed routing to share a 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.
      </t>
    </section>   <!-- Distributed vs. Centralized Routing -->

    <section><name>Forwarding Over over TSCH</name>
       <t>
         The 6TiSCH architecture supports three different forwarding models.
         One is the classical IPv6 Forwarding, where the node selects a feasible
         successor at Layer-3 Layer 3 on a per packet per-packet basis and based on its routing
         table. The second derives from Generic Generalized MPLS (G-MPLS) (GMPLS) for so-called
         Track Forwarding, whereby a frame received at a particular timeslot
         can be switched into another timeslot at Layer-2 Layer 2 without regard to the
         upper layer
         upper-layer protocol. The third model is the
         6LoWPAN Fragment Forwarding, which allows to forward the forwarding individual 6loWPAN 6LoWPAN
         fragments along a route that is setup set up by the first fragment.
         </t>
         <t>In more details:
         </t><dl  spacing='normal'> detail:
         </t>
         <dl spacing="normal">
         <dt>IPv6 Forwarding:</dt><dd>This is the classical IP forwarding
         model, with a Routing Information Based Base (RIB) that is installed by the
         RPL routing protocol and used to select a feasible successor per packet.
         The packet is placed on an outgoing Link, that link, which the 6top layer sublayer maps into
         a (Layer-3) (Layer 3) bundle of cells, and scheduled for transmission based on QoS
         parameters. Besides RPL, this model also applies to any routing
         protocol which that may be operated in the 6TiSCH network, network and corresponds
         to all the distributed scheduling models, models: Static, Neighbor-to-Neighbor Neighbor-to-Neighbor,
         and Hop-by-Hop Scheduling.</dd>
         <dt>G-MPLS
         <dt>GMPLS Track Forwarding:</dt><dd>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) (Layer 2) bundle of cells from the
         previous node along the path determines the outgoing (Layer-2) (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.</dd>
         <dt>6LoWPAN Fragment Forwarding:</dt><dd>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 a an IP header
         without the need to recompose the packet at every hop.</dd>
         </dl><t>
      </t>
         </dl>
     <t>A deeper dive on into these operations can be found in
    <xref target='fwd'/>. target="fwd"/>.
    </t>
   <t> The following table <xref target="RaF"/> summarizes how the forwarding models
       apply to the various routing and scheduling possibilities:
 </t>
    <figure anchor='RaF' suppress-title='true'>
            <artwork>
<![CDATA[
+-------------------+------------+----------------------------------+
|  Forwarding Model |  Routing   |          Scheduling              |
+===================+============+==================================+
|                   |            |   Static (Minimal Configuration) |
+  classical
<table anchor="RaF">
	<thead>
	<tr>
		<th>Forwarding Model</th>
		<th>Routing</th>
		<th>Scheduling</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td rowspan="3">classical IPv6   +     RPL    +----------------------------------+
| /         |            |   Neighbor-to-Neighbor (SF+6P)   |
+ 6LoWPAN Fragment  +------------+----------------------------------+
|                   |  Reactive  |     Hop-by-Hop (AODV-RPL)        |
+-------------------+------------+----------------------------------+
|G-MPLS Fragment</td>
		<td rowspan="2">RPL</td>
		<td>Static (Minimal Configuration)</td>
        </tr>
        <tr>
                <td>Neighbor-to-Neighbor (SF+6P)</td>
	</tr>
        <tr>
                <td>Reactive</td>
                <td>Hop-by-Hop (AODV-RPL)</td>
        </tr>
	<tr>
		<td>GMPLS Track Fwding|     PCE    |Remote Forwarding</td>
		<td>PCE</td>
		<td>Remote Monitoring and Schedule Mgt|
+-------------------+------------+----------------------------------+
]]>
   </artwork>
     </figure> Mgt</td>
	</tr>
	</tbody>
</table>
   </section>
   <section anchor='fsixstac'><name>6TiSCH anchor="fsixstac"><name>6TiSCH Stack</name>
   <t>
      The IETF proposes multiple techniques for implementing functions related
      to routing, transport transport, or security.
      </t>
      <t>
      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, interactions and to limit the size of
      the resulting object code. In particular, UDP <xref target='RFC0768'/>, target="RFC0768"/>,
      IPv6 <xref target='RFC8200'/> target="RFC8200"/>, and the <xref target='RFC7252'>Constrained target="RFC7252">Constrained
      Application Protocol</xref> (CoAP) Protocol (CoAP)</xref> are used as the transport / binding transport/binding of
      choice for applications and management as opposed to TCP and HTTP.
      </t>
      <t>
      The resulting protocol stack is represented in <xref target='fig4'/>: target="fig4"/>:
      </t>
         <figure anchor='fig4'><name>6TiSCH anchor="fig4"><name>6TiSCH Protocol Stack</name>
<artwork><![CDATA[
   +--------+--------+
   | Applis |  CoJP  |
   +--------+--------+--------------+-----+
   | CoAP / OSCORE   |  6LoWPAN ND  | RPL |
   +-----------------+--------------+-----+
   |       UDP       |      ICMPv6        |
   +-----------------+--------------------+
   |                 IPv6                 |
   +--------------------------------------+----------------------+
   |     6LoWPAN HC   /   6LoRH HC        | Scheduling Functions |
   +--------------------------------------+----------------------+
   |               6top inc. 6top protocol Protocol                       |
   +-------------------------------------------------------------+
   |                 IEEE Std. Std 802.15.4 TSCH                      |
   +-------------------------------------------------------------+
]]></artwork>
         </figure>
      <t>
         RPL is the routing protocol of choice for LLNs. So far, there was is no
         identified need to define a 6TiSCH specific 6TiSCH-specific Objective Function.
         The <xref target='RFC8180'>Minimal target="RFC8180">Minimal 6TiSCH Configuration
         </xref> describes the operation of RPL over a static schedule used in
         a Slotted ALOHA fashion <xref target='S-ALOHA'/>, target="S-ALOHA"/>, whereby all active slots
         may be used for emission or reception of both unicast and multicast
         frames.
      </t>
      <t>
         The
         <xref target='RFC6282'>6LoWPAN Header Compression</xref> target="RFC6282">6LoWPAN header compression</xref> is used
         to compress the IPv6 and UDP headers, whereas the
         <xref target='RFC8138'> target="RFC8138"> 6LoWPAN Routing Header (6LoRH)</xref> 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 Route Routing
         Header (SRH) in non-storing mode.
         "<xref target="RFC9008" format="title"/>" <xref target='I-D.ietf-roll-useofrplinfo'>"When to use RFC 6553, 6554
         and IPv6-in-IPv6"</xref> target="RFC9008"/>
         provides the details on when headers or encapsulation are needed.
      </t>
     <t>
         <!--The COMAN list is working on network Management for LLN.
         They are considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) Object system.
         This standard includes DTLS, CoAP (core plus Block and Observe patterns),
         SenML and CoAP Resource Directory.
         6TiSCH has adopted the general direction of
         <xref target="I-D.ietf-core-comi">
         CoAP Management Interface (COMI)</xref> for the management of devices.
         This is leveraged for instance for the implementation of the generic
         data model for the 6top sublayer management interface
         <xref target="I-D.ietf-6tisch-6top-interface"/>.
         The proposed implementation is based on CoAP and CBOR,
         and specified in <xref target="I-D.ietf-6tisch-coap">
         6TiSCH Resource Management and Interaction using CoAP</xref>.-->

      </t>

     <t>
         The <xref target='I-D.ietf-core-object-security'> target="RFC8613">
         Object Security for Constrained RESTful Environments (OSCORE) </xref>, </xref>
         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 <xref target='RFC6347'>Datagram target="RFC6347">Datagram Transport Layer Security (DTLS)
         </xref> sitting either under CoAP or over CoAP so it can traverse
         proxies.
      </t>
      <t>
       <!--  Similarly, the <xref target="RFC5191">
         Protocol for Carrying Authentication for Network access (PANA)</xref>
         is represented as an example of a protocol that could be leveraged to
         secure the join process, as a Layer-3 alternate to IEEE Std. 802.1x/EAP.
         Regardless, the security model ensures that, prior to a join process,
         packets from a untrusted device are controlled in volume and in
         reachability. In particular, a PANA stack should be separated from
         the main protocol stack to avoid attacks during the join process
         that is introduced in <xref target='rflo'/>.
         -->

      </t>
      <t>
         The 6TiSCH Operation
         sublayer
         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) <xref target='RFC8480'/>. target="RFC8480"/>.
      </t>
      <t>
      The reference stack presented in this document was implemented
      and interop-tested interoperability-tested by a conjunction combination of opensource, IETF 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.
      </t>
      <t>
      For a particular
      environment, some of the choices that are made available in this architecture may not
      be relevant. For instance, RPL is not required for star topologies and
      mesh-under Layer-2 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.
      </t>
   </section>

   <section><name>Communication Paradigms and Interaction Models</name>
      <t>
         <xref target='sixTTerminology'/> target="sixTTerminology"/> provides the terms
         of Communication Paradigms and Interaction Models, Models in relation combination with
         <xref target='RFC3444'>"On target="RFC3444">"On the Difference between Information Models
         and Data Models"</xref>.
         A Communication Paradigm would be is an abstract view of a protocol exchange, exchange
         and would come with has an Information Model for the information that is being exchanged.
         In contrast, an Interaction Model would be is more refined and could point points to standard operation
         such as a Representational state transfer State Transfer (REST) "GET" operation and would match matches
         a Data Model for the data that is provided over the protocol exchange.
      </t>

      <t>
         Section 2.1.3 of
         <xref target='I-D.ietf-roll-rpl-industrial-applicability'/> target="I-D.ietf-roll-rpl-industrial-applicability" section="2.1.3" sectionFormat="of" format="default"/>
         and next its following
         sections discuss application-layer paradigms, paradigms such as Source-sink (SS)
         that source-sink,
         which is a Multipeer to Multipeer (MP2MP) multipeer-to-multipeer model primarily used for
         alarms and alerts, Publish-subscribe (PS, or pub/sub) that publish-subscribe, which is typically
         used for sensor data, as well as Peer-to-peer (P2P) peer-to-peer and
         Peer-to-multipeer (P2MP)
         peer-to-multipeer communications.
      </t>
      <t>
         Additional considerations on Duocast - 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. Std 802.15.4 TSCH wireless networks with
         <xref target='ISA100.11a'/> target="ISA100.11a"/> and <xref target='WirelessHART'/>, that target="WirelessHART"/>, which
         provides a wireless access to <xref target='HART'/> target="HART"/> applications and
         devices.
      </t>
      <t>
         This document focuses on Communication Paradigms and Interaction
         Models for packet forwarding and TSCH resources (cells) management.
         Management mechanisms for the TSCH schedule at Link-Layer (one-hop),
         Network-layer the link layer (one hop),
         network layer (multihop along a Track), and Application-layer application layer
         (remote control) are discussed in <xref target='schd'/>.
         Link-Layer target="schd"/>.
         Link-layer frame forwarding interactions are discussed in <xref target='fwd'/>, target="fwd"/>, and
         Network-layer Packet
         network-layer packet routing is addressed in <xref target='rtg'/>. target="rtg"/>.
      </t>
   </section>
   </section>

      <section anchor='dd'><name>Architecture anchor="dd"><name>Architecture Components</name>

      <section anchor='RPLvs6lo'><name>6LoWPAN anchor="RPLvs6lo"><name>6LoWPAN (and RPL)</name>
    <t>A RPL DODAG is formed of a Root, a collection of routers, and leaves that
    are hosts. Hosts are nodes which that do not forward packets that they did not generate.
    RPL-aware leaves will participate to 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.
   </t>

   <section anchor='leaf'><name>RPL-Unaware anchor="leaf"><name>RPL-Unaware Leaves and 6LoWPAN ND</name>
   <t>RPL needs a set of information to advertise
   a leaf node through a Destination Advertisement Object (DAO) message and establish reachability.
   </t>
   <t>
    <xref target='I-D.ietf-roll-unaware-leaves'>"Routing
   <t><xref target="RFC9010">"Routing for RPL Leaves"</xref>
   details the basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN
   that supports <xref target='RFC8505'/> target="RFC8505"/> to obtain return
   connectivity via the RPL network as an a RPL-unaware leaf.
   The leaf indicates that it requires reachability services for the
   Registered Address from a Routing Registrar by setting a an 'R' flag in the
   Extended Address Registration Option <xref target='RFC8505'/>, target="RFC8505"/>, and it
   provides a TID that maps to a sequence number the "Path Sequence" defined in section 7 of RPL <xref target='RFC6550'/>.
   </t>
   <t> target="RFC6550" section="6.7.8" sectionFormat="of" format="default"/>, and its operation is defined in <xref target='I-D.ietf-roll-unaware-leaves'/> target="RFC6550" section="7.2" sectionFormat="of" format="default"/>.
   </t>
   <t><xref target="RFC9010"/> also enables the leaf to signal
   with the RPL InstanceID RPLInstanceID that it wants to participate to by using the
   Opaque field of the EARO. On the backbone, the InstanceID 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.
   </t>
   <t>
    Though
    Though, at the time of this writing writing, the above specification enables a model
    where the separation is possible, this architecture recommends to
    collocate
    co-locating the functions of 6LBR and RPL Root.
   </t>
   </section> <!--  RPL-Unaware Leaves and 6LoWPAN ND -->

   <section anchor='rpllbr'><name>6LBR anchor="rpllbr"><name>6LBR and RPL Root</name>

    <t>
    With the 6LowPAN 6LoWPAN ND <xref target='RFC6775'/>, target="RFC6775"/>, information on the 6LBR is
    disseminated via an Authoritative Border Router Option (ABRO) in RA messages.
    <xref target='RFC8505'/> target="RFC8505"/> extends <xref target='RFC6775'/> target="RFC6775"/> to enable a
    registration for routing and proxy ND.
    The capability to support <xref target='RFC8505'/> target="RFC8505"/>
    is indicated in the 6LoWPAN Capability Indication Option (6CIO).
    The discovery and liveliness of the RPL Root are obtained through RPL
    <xref target='RFC6550'/> target="RFC6550"/> itself.
    </t>
   <t>
   When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities
   are co-located in order that the address of the 6LBR be is indicated by RPL
   DIO
   DODAG Information Object (DIO) messages and to associate the unique ID ROVR from
   the EDAR/EDAC
   <xref target='RFC8505'/> Extended Duplicate Address Request/Confirmation (EDAR/EDAC)
   exchange <xref target="RFC8505"/> with the state that is maintained by RPL.
    </t>
    <t>
   Section 7 of
   <xref target='I-D.ietf-roll-unaware-leaves'/> target="RFC9010" section="7" sectionFormat="of" format="default"/> 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  <xref target='figReg2'/>. target="figReg2"/>.
   <xref target='I-D.ietf-roll-unaware-leaves'/> target="RFC9010"/> also provides the protocol
   elements that are needed when the 6LBR and RPL Root functionalities are not
   co-located.
   </t>
   <t>
   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.
            </t><t>
   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, proxy or redistribution in a routing protocol.
   This relies on an extension of the 6LoWPAN ND registration described in
   <xref target='I-D.ietf-6lo-backbone-router'/>. target="RFC8929"/>.
            </t><t>
   This model supports the movement of a 6TiSCH device across the Multi-Link
   Subnet, 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 <xref target='RFC8505'/> target="RFC8505"/> the Registered Address is signaled
   in the Target Address field of the NS 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.
            </t>
   </section>
   <!--
      </section>

 <section anchor='gone' title="registration Failures Due to Movement">

   <t>Registration to the 6LBR through DAR/DAC messages <xref target="RFC6775"/>
   may percolate slowly through an LLN mesh, anchor="join"><name>Network Access and it might happen that in
   the meantime, Addressing</name>
   <section anchor="rflo"><name>Join Process</name>

       <t>
       A new device, called the 6LoWPAN node moves and registers somewhere else. Both RPL
   and 6LoWPAN ND lack pledge, undergoes the capability join protocol to indicate that the same become a node is
   registered elsewhere, so as to invalidate states down the deprecated path.
   </t><t>  In its current expression and functionality,
   6LoWPAN ND considers that
       in a 6TiSCH network. This usually occurs only once when the registration device is used for
       first powered on.  The pledge communicates with the purpose of DAD
   only as opposed to that Join Registrar/Coordinator
       (JRC) of achieving reachability, and as long as the same
   node registers the IPv6 address, network through a Join Proxy (JP), a radio neighbor of the protocol pledge.
       </t><t>
       The JP is functional. to
   act as a RPL leaf registration protocol discovered though MAC-layer beacons. When multiple JPs from possibly
       multiple networks are visible, using trial and achieve reachability, error until an acceptable position
       in the
   device must use the same TID for all its concurrent registrations, and
   registrations with right network is obtained becomes inefficient.
       <xref target="RFC9032"/> adds a past TID should be declined. The state for an obsolete
   registration new subtype in the 6LR, as well as Information Element that
       was delegated to the RPL routers on IETF <xref target="RFC8137"/> and provides visibility
       into the way, should be
   invalidated. This network that can only be achieved with joined and the addition willingness of a new Status in the DAC message, JP and a new error/clean-up flow in RPL.
   </t>
        </section>

   <section anchor='prox' title="Proxy registration">
   <t>The 6BBR provides the capability Root to defend an address that is owned be used by
   a 6LoWPAN Node, and attract packets the pledge.
       </t><t>
       The join protocol provides the following functionality:
       </t>
       <ul spacing="normal">
           <li> Mutual authentication</li>
           <li> Authorization</li>
           <li> Parameter distribution to that address, whether it is done by
   proxying ND over a Multi-Link Subnet, redistributing the address in pledge over a routing
   protocol or advertising it through an alternate proxy registration such as
   <xref target="RFC6830">the Locator/ID Separation Protocol</xref> (LISP) or secure channel</li>
     </ul>
    <t>
        The Minimal Security Framework for 6TiSCH <xref target="RFC6275">Mobility Support target="RFC9031"/>
        defines the minimal mechanisms required for this join process to occur in IPv6</xref> (MIPv6). In a LLN,
   it makes sense secure
        manner. The specification defines the Constrained Join Protocol (CoJP), which is used
        to piggyback distribute the request parameters to proxy/defend an address with its
   registration.
   </t>
        </section>

   <section anchor='source' title="Target Registration">
   <t>
   In their current incarnations, both 6LoWPAN ND and Efficient ND expect
   that the address being registered is pledge over a secure session established through
        OSCORE <xref target="RFC8613"/> and which describes the source secure configuration of the NS(ARO) message and
   thus impose that a Source Link-Layer Address (SLLA) option be present in the
   message. network
        stack. In a mesh scenario where the 6LBR is physically separated from minimal setting with pre-shared keys (PSKs), CoJP allows the 6LoWPAN
   Node, pledge to
        join after a single round-trip exchange with the 6LBR does not own the address being registered. This is why
   <xref target="I-D.ietf-6lo-backbone-router"/>
   registers the Target JRC. The provisioning of the NS message as opposed PSK to
        the Source Address.
   From another perspective, it may happen, in pledge and the use case JRC needs to be done out of band, through a Star topology,
   that the 6LR, 6LBR and 6BBR are 'one-touch'
        bootstrapping process, which effectively collapsed and should support
   6LoWPAN ND clients. The convergence of efficient ND and 6LoWPAN ND enrolls the pledge into a
   single protocol is thus highly desirable.
   </t><t>
   In any case, as long as the DAD process is not complete for domain managed by
        the address
   used as source of JRC.
    </t>

    <t>
        In certain use cases, the packet, it 'one-touch' bootstrapping is against the current practice not feasible due to advertise the SLLA, since this may corrupt
        operational constraints, and the ND cache enrollment of the destination node, as
   discussed in pledge into the <xref target="RFC4429">Optimistic DAD specification</xref>
   with regards domain needs to the TENTATIVE state.
   </t><t> occur
        in-band. This may look like a chicken and an egg problem, but in fact 6LoWPAN ND
   acknowledges that the Link-Local Address that is based on an EUI-64 address
   of handled through a LLN node may be autoconfigured without 'zero-touch' extension of the need Minimal Security Framework
        for DAD.
   It results that a node could use that Address as source, with an SLLA
   option in 6TiSCH. The zero-touch extension <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> leverages
        the message if required, "<xref target="RFC8995" format="title"/>" <xref target="RFC8995"/>
        work to register any other addresses, either
   Global or Unique-Local Addresses, which would be indicated in establish a shared secret between a pledge and the Target.
   </t>

  <t>
   The suggested change is JRC without necessarily having
        them belong to register a common (security) domain at join time. This happens through inter-domain
        communication occurring between the target JRC of the NS message, network and use
   Target Link-Layer Address (TLLA) in the NS as opposed to domain of the SLLA to
   install a Neighbor Cache Entry. This would apply to both Efficient ND
   and 6LoWPAN ND in pledge,
        represented by a very same manner, with the caveat that depending on the
   nature of the link between the 6LBR and the 6BBR, the 6LBR may resort to
   classical ND or DHCPv6 to obtain the address that it uses to source the NS
   registration messages, whether for itself or on behalf of LLN nodes.
   </t>
        </section>

   <section anchor='Rroot' title="RPL Root vs. 6LBR">

  <t>6LoWPAN ND is unclear on how the 6LBR is discovered, and how fourth entity, Manufacturer Authorized Signing Authority (MASA). Once
        the liveliness
    of zero-touch exchange completes, the 6LBR CoJP exchange defined in <xref target="RFC9031"/>
        is asserted carried over time. On the other hand, the discovery
    and liveliness of the RPL Root are obtained through the RPL protocol.
   </t><t>
   When 6LoWPAN ND is coupled with RPL, secure session established between the 6LBR pledge and RPL Root functionalities
   are co-located in order that the address of JRC.
    </t>

    <t>
        <xref target="figJoin"/> depicts the 6LBR be indicated by RPL
   DIO messages join process and to associate the unique ID from the DAR/DAC exchange with
   the state that is maintained by RPL. The DAR/DAC exchange becomes a
   preamble to the DAO messages that are used from then on to reconfirm the
   registration, thus eliminating where a duplication of functionality between DAO
   and DAR messages.
   </t>
      </section>

   <section anchor='Sec' title="Securing the Registration">
   <t>
   A typical attack against IPv6 ND Link-Local
        Address (LLA) is address spoofing, whereby used, versus a rogue node
   claims the IPv6 Global Unicast Address of another node in and hijacks its traffic. The
   threats against IPv6 ND as described (GUA).
    </t>

<figure anchor="figJoin" suppress-title="false">
<name>Join Process in
   <xref target="RFC3971">SEcure Neighbor Discovery (SEND)</xref>
   are applicable to 6LoPWAN ND as well, but the solution can not work as the
   route over network does not permit direct peer to peer communication.
   </t><t>
   Additionally SEND requires considerably enlarged ND messages to carry
   cryptographic material, and requires that each protected address is generated
   cryptographically, which implies the computation of a different key for
   each Cryptographically Generated Address (CGA). SEND as defined in
   <xref target="RFC3971"/> is thus largely unsuitable for application in a LLN.
   </t><t>
   With 6LoWPAN ND, as illustrated in <xref target='figReg'/>, it is
   possible to leverage the registration state in the 6LBR, which may store
   additional security information for later proof of ownership. If this
   information proves the ownership independently of the address itself,
   then a single proof may be used to protect multiple addresses.
   </t><t>
   Once an Address is registered,
   the 6LBR maintains a state for that Address and is in position to bind
   securely the first registration with the Node that placed it, whether the
   Address is CGA or not. It should thus be possible to protect the ownership of
   all the addresses of a Multi-Link Subnet. Parentheses () denote optional exchanges.</name>
 <artwork><![CDATA[
6LoWPAN Node with a single key, and there should not
   be a need to carry the cryptographic material more than once to the 6LBR.
   </t><t>
   The energy constraint is usually a foremost factor, and attention should be
   paid to minimize the burden on the CPU. Hardware-assisted support of variants
   of the <xref target="RFC3610">Counter with CBC-MAC</xref> (CCM) authenticated
   encryption block cipher mode such as CCM* are common in LowPower ship-set
   implementations, and       6LR           6LBR      Join Registrar     MASA
 (pledge)       (Join Proxy)     (Root)    /Coordinator (JRC)
  |               |               |              |              |
  |  6LoWPAN ND security mechanism should be capable to
   reuse them when applicable.
   </t><t>
   Finally, the code footprint in the device being also an issue, the capability
   to reuse not only hardware-assist mechanisms but also software across layers
   has to be considered. For instance, if code has to be present for upper-layer
   operations, e.g <xref target="RFC6655">AES-CCM Cipher Suites for Transport   |6LoWPAN ND+RPL | IPv6 network |IPv6 network  |
  |   LLN link    |Route-Over mesh|(the Internet)|(the Internet)|
  |               |               |              |              |
  |   Layer Security (TLS)</xref>, then the capability to reuse that code should be
   considered.
   </t>
   -->
      </section>

 <section anchor='join'><name>Network Access and Addressing</name>
   <section anchor='rflo'><name>Join Process</name>

       <t>
       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 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 Registrar/Coordinator
       (JRC) of the network through a Req |               |              |              | \
  |  using LLA    |               |              |              | |
  |-------------->|               |              |              | |
  |               |       CoJP Join Proxy (JP), a radio neighbor of the pledge.
       </t><t>
       The JP is discovered though MAC layer beacons. When multiple JPs from possibly multiple networks are visible, trial and error till an acceptable position in the right network is obtained becomes ineffficient.
       <xref target='I-D.ietf-6tisch-enrollment-enhanced-beacon'/> adds a new subtype in the Information Element that was delegated to the IETF <xref target='RFC8137'/> and provides visibility on the network that can be joined and the willingness by the JP and the Root to be used by the pledge.
       </t><t>
       The join protocol provides the following functionality:
       </t><ul spacing='normal'>
           <li> Mutual authentication</li>
           <li> Authorization</li>
           <li> Parameter distribution to the pledge over a secure channel</li>
     </ul><t>
 </t>

    <t>
        Minimal Security Framework for 6TiSCH <xref target='I-D.ietf-6tisch-minimal-security'/>
        defines the minimal mechanisms required for this join process to occur in a secure
        manner. The specification defines the Constrained Join Protocol (CoJP) that is used
        to distribute the parameters to the pledge over a secure session established through
        OSCORE <xref target='I-D.ietf-core-object-security'/>, and a 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.
    </t>

    <t>
        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. Zero touch <xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> extension leverages
        the 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' [<xref target='I-D.ietf-anima-bootstrapping-keyinfra'/>
        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 <xref target='I-D.ietf-6tisch-minimal-security'/>
        is carried over the secure session established between the pledge and the JRC.
    </t>

    <t>
        <xref target='figJoin'/> depicts the join process and where a Link-Local
        Address (LLA) is used, versus a Global Unicast Address (GUA).
    </t>

<figure anchor='figJoin' suppress-title='false'><name>Join process in a Multi-Link Subnet. Parentheses () denote optional exchanges.</name>
 <artwork><![CDATA[

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
  |               | Request      |              | |
  |               |           using GUA          |              | |
  |               |----------------------------->|              | | C
  |               |               |              |              | | o
  |               |       CoJP Join Response     |              | | J
  |               |           using GUA          |              | | P
  |               |<-----------------------------|              | |
  |CoJP Join Resp |               |              |              | |
  |  using LLA    |               |              |              | |
  |<--------------|               |              |              | /
  |               |               |              |              |
]]></artwork>
</figure>

</section>

   <section anchor='rreg'><name>Registration</name>

       <t>
         Once the pledge successfully completes the CoJP protocol and becomes
         a network node, it obtains the network prefix from neighboring routers
         and registers its IPv6 addresses.
         As detailed in <xref target='RPLvs6lo'/>, the combined 6LoWPAN ND 6LBR
         and Root of the RPL network learn information such as the device Unique
         ID (from 6LoWPAN ND) and the updated Sequence Number (from RPL), and
         perform 6LoWPAN ND proxy registration to the 6BBR of behalf of the LLN
         nodes.
     </t>

    <t>
         <xref target='figReg'/> illustrates the initial IPv6 signaling that
         enables a 6LN to form a global address and register it to a 6LBR
         using 6LoWPAN ND <xref target='RFC8505'/>, 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.
    </t>

<figure anchor='figReg' suppress-title='false'><name>Initial Registration Flow over Multi-Link Subnet</name>
<artwork><![CDATA[

    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)     |               |               |
         |<--------------|               |               |
         |               |               |               |
]]></artwork>
</figure>

    <t>
         <xref target='figReg2'/> illustrates the repeating IPv6 signaling that
         enables a 6LN to keep a global address alive and registered to 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.
</t>
<figure anchor='figReg2' suppress-title='false'><name>Next Registration Flow over Multi-Link Subnet</name>
<artwork><![CDATA[

 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)     |
      |               |               |<--------------|
      |               |               |               |
      |               |               |               |

]]></artwork>
</figure>

   <t>As the network builds up, a node should start as a
   leaf to join the RPL network, and may later turn into both a RPL-capable
   router and a 6LR, so as to accept leaf nodes
   to recursively join the network.
    </t>

   </section>

</section> <!--"Network Access and Addressing" -->

   <section anchor='s6Pprot'><name>TSCH and 6top</name>
      <section><name>6top</name>

         <t>
            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.
         </t>
         <t>
            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 is such that both
            the energy wasted in idle listening and the packet drops due to
            congestion loss are minimized, while packets are forwarded within
            an acceptable latency.
         </t>

         <t>
            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.
         </t>

         <t>
            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
            <xref target='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 management based on
            observed resource usage as discussed in <xref target='dynsched'/>.
            For this purpose, the 6TiSCH architecture differentiates "soft"
            cells and "hard" cells.
         </t>
      <section><name>Hard Cells</name>
         <t>
            "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.
            </t>
   </section>
      <section><name>Soft Cells</name>
         <t>
            In contrast, "soft" cells are cells that 6top can manage locally.
            6top contains a monitoring process which monitors the performance of
            cells, and can add, 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.
         </t>
   </section>
   </section>

   <section anchor='missf'><name>Scheduling Functions and the 6top protocol</name>
   <t>In the case of soft cells, the cell management entity that controls the
   dynamic attribution of cells to adapt to the dynamics of variable rate flows
   is called a Scheduling Function (SF).
   </t>
   <t>
   There may be multiple SFs with more or less aggressive reaction to the
   dynamics of the network.
   </t>
   <t>
   An SF may be seen as divided between an upper bandwidth adaptation logic
   that is not aware of the particular technology that is used to obtain and
   release bandwidth, and an underlying service that maps those needs in the
   actual technology, which means mapping the bandwidth onto cells in the case
   of TSCH using the 6top protocol as illustrated in <xref target='fig6P'/>.
   </t>

         <figure anchor='fig6P' suppress-title='false'><name>SF/6P stack in 6top</name>
<artwork><![CDATA[

 +------------------------+          +------------------------+
 |  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

]]></artwork>
</figure>
      <t>
    The SF relies on 6top services that implement the
    <xref target='RFC8480'> 6top Protocol (6P) </xref>
    to negotiate the precise cells that will be allocated or freed based on the
    schedule of the peer. It may be for instance that a peer wants to use a
    particular time slot that is free in its schedule, but that timeslot is
    already in use by the other peer for a communication with a third party on a
    different cell. 6P enables the peers to find an agreement in a
    transactional manner that ensures the final consistency of the nodes state.
    </t>
    <t>
    <xref target='I-D.ietf-6tisch-msf'>MSF</xref> is one of the possible
    scheduling functions. MSF uses the rendez-vous slot from
    <xref target='RFC8180'/> for network discovery, neighbor discovery, and any
    other broadcast.
    </t>
    <t>
    For basic unicast communication with any neighbor, each node uses a receive
    cell at a well-known slotOffset/channelOffset, derived from a hash of their
    own MAC address.
    Nodes can reach any neighbor by installing a transmit (shared) cell with
    slotOffset/channelOffset derived from the neighbor's MAC address.
    </t>
    <t>
    For child-parent links, MSF continuously monitors the load to/from parents
    and children. It then uses 6P to install/remove unicast cells whenever the
    current schedule appears to be under-/over- provisioned.

         </t>
      </section>

      <section><name>6top and RPL Objective Function operations</name>
         <!-- 8.1.1.  Support to RPL Neighbor Discovery and Parent Selection -->
         <t>
            An implementation of a <xref target='RFC6550'>RPL</xref> Objective Function
            (OF), such as the <xref target='RFC6552'> RPL Objective Function Zero (OF0)
            </xref> that is used in the <xref target='RFC8180'> Minimal
            6TiSCH Configuration </xref> to support RPL over a static schedule, may
            leverage, for its internal computation, the information maintained by 6top.
         </t>
         <t>An OF may require metrics about reachability, such as the Expected
            Transmission Count (ETX) metric <xref target='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.

         </t>
         <t>
            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.
         </t>
         <t>
            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.
         </t>
         <!-- PT: I took of the text about time source; the way we do it is a bit reverse:
         we have an Instance that is used for time sourcing, and the preferred parent
         becomes the time source. If we change preferred parent we use the new one as
         time source -->
         <t>
            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, packet size issues and could conflict with
            the policy of production networks where EBs are mostly eliminated
            to conserve energy.
         </t>
         <!--t>
            In the TSCH schedule, each cell has the IEEE Std. 802.15.4e LinkType attribute.
            Setting the LinkType to ADVERTISING indicates that the cell MAY be used to send an
            Enhanced Beacon. When a node forms its Enhanced Beacon, the cell,
            with LinkType=ADVERTISING, SHOULD be included in the FrameAndLinkIE,
            and its LinkOption field SHOULD be set to the combination of
            "Receive" and "Timekeeping". The receiver of the Enhanced Beacon MAY
            be listening at the cell to get the Enhanced Beacon ([IEEE Std. 802154e]).
            6top takes this way to establish broadcast channel, which not only
            allows TSCH to broadcast Enhanced Beacons, but also allows protocol
            exchanges by an upper layer such as RPL.
         </t>
         <t>
            To broadcast ICMPv6 control messages used by RPL such as DIO or DAO,
            6top uses the payload of a Data frames. The message is inserted into the
            queue associated with the cells which LinkType is set to ADVERTISING.
            Then, taking advantage of the broadcast cell feature established with
            FrameAndLinkIE (as described above), the RPL control message can be
            received by neighbors, which enables the maintenance of RPL DODAGs.
         </t>
         <t>
            A LinkOption combining "Receive" and "Timekeeping" bits indicates to
            the receivers of the Enhanced Beacon that the cell MUST be used as a
            broadcast cell. The frequency of sending Enhanced Beacons or other
            broadcast messages by the upper layer is determined by the timers
            associated with the messages. For example, the transmission of
            Enhance Beacons is triggered by a timer in 6top; transmission of a
            DIO message is triggered by the trickle timer of RPL.
         </t-->
      </section>
      <section anchor='sync'><name>Network Synchronization</name>
         <t>
            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).
         </t>
         <t>
            This could be achieved through an interaction of the 6top sublayer and the RPL objective Function,
            or could be controlled by a management entity.
         </t>
         <!-- TW: Concept of TSGI developed in separate standards-Track draft? -->
         <t>
            Time distribution requires a loop-free structure. Nodes taken 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 3 modes that are detailed
            in section 3.1.3 of  <xref target='RFC6550'>RPL</xref>,
            "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).
         </t>
         <t>
            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.
         </t>
         <t>
            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 <xref target='RFC6550'/>, "Rank Comparison".
         </t>
         <!-- TW: Official request made to move alter IEEE Std. 802.15.4e text. Maybe remove last sentence? -->
         <t>

            The provisioning of a RPL Root is out of scope for both RPL and this Architecture, whereas RPL enables to propagate 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, that must be less than 0xFF, as its Join Priority in
            its IEEE Std. 802.15.4 Extended Beacons (EB).
         </t>
         <t>
            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.
         </t>
      </section>

      <section anchor='slotframes'><name>Slotframes and CDU matrix</name>

         <t>
         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 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.
         </t>
         <t>
         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,
         </t>
         <t>
         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 <xref target='schd'/>).
         </t>
         <t>
         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.
         </t>
         <t>
         A CDU matrix iterates over and over with a well-known channel rotation
         called the hopping sequence.
         In a given network, there might be multiple CDU matrices that operate
         with different width, 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.
          </t>
          <t>
          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.
          </t>
          <t>
          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 width.
          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.
          </t>
          <t>
          When a packet is received from a higher layer for transmission,
          6top inserts that packet in the outgoing queue
          which matches the packet best (Differentiated Services
          <xref target='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.
         </t> J
  |               |           using GUA          |              | | P
  |               |<-----------------------------|              | |
  |CoJP Join Resp |               |              |              | |
  |  using LLA    |               |              |              | |
  |<--------------|               |              |              | /
  |               |               |              |              |
]]></artwork>
</figure>

</section>

   <section anchor='DistRsvTS'><name>Distributing the reservation of cells</name> anchor="rreg"><name>Registration</name>
       <t>
            The 6TiSCH architecture introduces the concept of chunks
            (<xref target='sixTTerminology'/>) to distribute
         Once the allocation of pledge successfully completes the spectrum for a whole group of cells at a time.
            The CDU matrix is formatted into CoJP exchange and becomes
         a set of chunks, possibly as
            illustrated network node, it obtains the network prefix from neighboring routers
         and registers its IPv6 addresses.
         As detailed in <xref target='fig10'/>, each of target="RPLvs6lo"/>, the chunks
            identified uniquely by a chunk-ID. The knowledge combined 6LoWPAN ND 6LBR
         and Root of this
            formatting is shared between all the nodes in a 6TiSCH network.
            It could be conveyed during the join process, RPL network learn information such as an identifier (device EUI-64 <xref target="RFC6775" format="default"/> or codified into a profile document, or obtained using some other mechanism. This is as opposed
            to static scheduling that refers to the pre-programmed mechanism that
            is specified in ROVR <xref target='RFC8180'/> target="RFC8505" format="default"/>
         (from 6LoWPAN ND)) and pre-exists to the
            distribution of the chunk formatting.

          </t>
            <figure anchor='fig10'><name>CDU matrix Partitioning in Chunks</name>
<artwork align='center'>
<![CDATA[
             +-----+-----+-----+-----+-----+-----+-----+     +-----+
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
]]>
</artwork>
            </figure>

          <t>
            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, updated Sequence Number (from RPL), and then defends it in case another RPL
            parent would attempt
         perform 6LoWPAN ND proxy registration to appropriate it while it is in use.
            The chunk is the basic unit 6BBR on behalf of ownership that is used in that process. the LLN
         nodes.
     </t>

    <t>
            As a result of the process of chunk ownership appropriation,
         <xref target="figReg"/> illustrates the RPL
            parent has exclusive authority initial IPv6 signaling that
         enables a 6LN to decide which cell in the
            appropriated chunk can be used by which node in its interference
            domain. In other words, form a global address and register it to a 6LBR
         using 6LoWPAN ND <xref target="RFC8505"/>. It is implicitly delegated then carried
         over RPL to the right RPL Root and then to
            manage the portion of 6BBR. This flow happens
         just once when the address is created and first registered.
    </t>

<figure anchor="figReg" suppress-title="false"><name>Initial Registration Flow over Multi-Link Subnet</name>
<artwork><![CDATA[
    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)     |               |               |
         |<--------------|               |               |
         |               |               |               |
]]></artwork>
</figure>

    <t>
         <xref target="figReg2"/> illustrates the CDU matrix repeating IPv6 signaling that is represented by the
            chunk.
            <!-- Eliot's review: drop this sentence
            The RPL parent may thus orchestrate
            which transmissions occur in any of the cells in the chunk, by
            allocating cells from the chunk
         enables a 6LN to any form of communication (unicast,
            multicast) in any direction between itself keep a global address alive and registered with its children.
            -->
         </t>
         <t>
            Initially, those cells are added to the heap of free cells, then
            dynamically placed into existing bundles, in new bundles, or
            allocated opportunistically for one transmission.
         </t>

         <t>
            Note that a PCE is expected 6LBR
         using 6LoWPAN ND to have precedence in the
            allocation, so that a 6LR, RPL parent would only be able to obtain
            portions that are not in-use by the PCE.
         </t>
      </section>
   </section>
   <!--
   <section title="Functional Flows">
      <t>
         <list hangIndent="6" style="hanging">
            <t hangText="Join:"></t>
            <t hangText="Time Synchronization:"></t>
            <t hangText="Setup for routing:"></t>
            <t hangText="PCE reservation:"></t>
            <t hangText="Distributed reservation:"></t>
            <t hangText="Dynamic slot (de)allocation:"></t>
            <t hangText="DSCP mapping:"></t>
         </list>
      </t>
   </section>
   -->

   <section anchor='schd'><name>Schedule Management Mechanisms</name>
      <t>
         6TiSCH uses 4 paradigms RPL Root, and then 6LoWPAN ND
         again
         to manage the TSCH schedule of 6BBR, which avoids repeating 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 Extended DAR/DAC flow across
         the associated Interaction Models,
         and network when RPL can be combined and used in the same LLN.
         Which mechanism(s) to use depends on application requirements. suffice as a keep-alive mechanism.
</t>
      <section anchor='mini'><name>Static Scheduling</name>
         <t>
            In
<figure anchor="figReg2" suppress-title="false"><name>Next Registration Flow over Multi-Link Subnet</name>
<artwork><![CDATA[
 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)     |
      |               |               |<--------------|
      |               |               |               |
      |               |               |               |
]]></artwork>
</figure>

   <t>As the simplest instantiation of network builds up, a 6TiSCH network, node should start as a common fixed
            schedule may be shared by all nodes in
   leaf to join the network. Cells are shared, RPL network and nodes contend for slot access in may later turn into both a slotted ALOHA manner.
         </t>
         <t>
            A static TSCH schedule can be used to bootstrap RPL-capable
   router and a network, as an
            initial phase during implementation, or 6LR, so as a fall-back mechanism in
            case of network malfunction.
            This schedule is pre-established, for instance decided by a network
            administrator based on operational needs. It can be pre-configured
            into the nodes, or, more commonly, learned by a node when to accept leaf nodes recursively 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
            <xref target='RFC8180'/>.
    </t>

   </section>

</section>

   <section anchor='dynsched'><name>Neighbor-to-neighbor Scheduling</name> anchor="s6Pprot"><name>TSCH and 6top</name>
      <section><name>6top</name>

         <t>
            In the simplest instantiation of a
            6TiSCH network described in
            <xref target='mini'/>, nodes may expect expects a packet at any cell in high degree of scalability together with a
            distributed routing functionality based on RPL. To achieve this
            goal, the schedule and spectrum must be allocated in a way that allows for
            spatial reuse between zones that will waste energy idle listening. not interfere with one
            another.
            In a more
            complex instantiation of large and spatially distributed network, a 6TiSCH network, node is
            often in a matching portion good position to determine usage of the
            schedule is established between peers to reflect spectrum in its
            vicinity.
         </t>
         <t>
            With 6TiSCH, the observed amount abstraction of transmissions between those nodes. The aggregation an IPv6 link is implemented as a
            pair of the cells bundles of cells, one in each direction. IP links are only
            enabled between a node RPL parents and a peer forms children. The 6TiSCH
            operation is optimal when the size of a bundle that minimizes both
            the 6top layer uses to
            implement energy wasted in idle listening and the abstraction of packet drops due to
            congestion loss, while packets are forwarded within
            an acceptable latency.
         </t>

         <t>
            Use cases for distributed routing are often associated with a link
            statistical distribution of best-effort traffic with variable needs
            for IP. The bandwidth on that
            link is proportional each individual link. The 6TiSCH operation can
            remain optimal if RPL parents can adjust, dynamically and with enough
            reactivity to match the number variations of cells in the bundle.
         </t><t>
            If best-effort traffic,
            the size amount of a bundle bandwidth that is configured used to fit an average amount 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
            bandwidth, peak traffic interactions with other devices and
            the protocol latencies are minimized.
         </t>

         <t>
            6top is dropped. If a logical link control sitting between the IP layer and the size
            TSCH MAC layer, which provides the link abstraction that is
            configured to allow required
            for peak emissions, energy IP operations. The 6top Protocol, 6P, which is be wasted
            idle listening.
         </t><t>
            As discussed in more details specified in
            <xref target='s6Pprot'/>, target="RFC8480"/>, is one of the
            <xref target='RFC8480'>6top Protocol</xref>
            specifies services provided by 6top.
            In particular, the exchanges between neighbor nodes 6top services are available over a management
            API that enables an external management entity to reserve soft schedule cells
            to transmit to one another, possibly under
            and slotframes, and allows the control addition of complementary
            functionality, for instance, a Scheduling Function (SF). Because
            that manages a dynamic schedule based on
            observed resource usage as discussed in <xref target="dynsched"/>.
            For this reservation is done without
            global knowledge of purpose, the schedule 6TiSCH architecture differentiates "soft"
            cells and "hard" cells.
         </t>
      <section><name>Hard Cells</name>
         <t>
            "Hard" cells are cells that
            are owned and managed by a separate scheduling entity (e.g., a PCE)
            that specifies the slotOffset/channelOffset of other nodes the cells to be
            added/moved/deleted, in which case 6top can only act as instructed
            and may not move hard cells in the LLN, scheduling
            collisions TSCH schedule on its own.
            </t>
   </section>
      <section><name>Soft Cells</name>
         <t>
            In contrast, "soft" cells are possible.
            <!-- cells that 6top defines can manage locally.
            6top contains a monitoring process which
            continuously Tracks that monitors the packet delivery ratio performance of
            cells and that can add and remove soft cells.
            It uses these statistics cells in the TSCH schedule to trigger 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 reallocation of monitoring process triggers
            a soft cell
            in the schedule, using a negotiation protocol between reallocation, the neighbors
            nodes two neighbor devices communicating over that cell.
            In this
            cell negotiate its new position in the most efficient instantiations of a 6TiSCH network, TSCH schedule.
         </t>
   </section>
   </section>

   <section anchor="missf"><name>Scheduling Functions and the size 6top Protocol</name>
   <t>In the case of soft cells, the bundles cell management entity that implement controls the links may be changed dynamically
            in order
   dynamic attribution of cells to adapt to the need dynamics of end-to-end variable rate flows routed by RPL. -->
         </t><t>
            And as discussed in <xref target='missf'/>,
            an optional
   is called a Scheduling Function (SF) (SF).
   </t>
   <t>
   There may be multiple SFs that react more or less aggressively to the
   dynamics of the network.
   </t>
   <t>
   An SF may be seen as divided between an upper bandwidth-adaptation logic
   that is unaware of the particular technology used to
            monitor obtain and
   release bandwidth usage and perform requests for dynamic allocation
            by an underlying service that maps those needs in the
   actual technology. In the case
   of TSCH using the 6top sublayer. Protocol as illustrated in <xref target="fig6P"/>,
   this means mapping the bandwidth onto cells.
   </t>

         <figure anchor="fig6P" suppress-title="false"><name>SF/6P Stack in 6top</name>
<artwork><![CDATA[
 +------------------------+          +------------------------+
 |  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
]]></artwork>
</figure>
      <t>
    The SF component is not part of relies on 6top services that implement the
    <xref target="RFC8480"> 6top sublayer. It may Protocol (6P) </xref>
    to negotiate the precise cells that will be
            collocated allocated or freed based on the same device or
    schedule of the peer. For instance, it may be partially or fully offloaded that a peer wants to an external system. The <xref target='I-D.ietf-6tisch-msf'>
            "6TiSCH Minimal Scheduling Function (MSF)"</xref> provides use a simple
            scheduling function
    particular timeslot that can be used by default by devices is free in its schedule, but that
            support dynamic scheduling of soft cells.
   </t>
         <t>
            Monitoring and relocation timeslot is done
    already in use by the 6top layer. For the upper
            layer, the connection between two neighbor nodes appears as other peer to communicate with a number
            of cells.
            Depending third party on traffic requirements, the upper layer can request 6top
            to add or delete a number of cells scheduled
    different cell. 6P enables the peers to find an agreement in a particular
            neighbor, without being responsible for choosing
    transactional manner that ensures the exact
            slotOffset/channelOffset final consistency of those cells. the nodes' state.
    </t>
      </section>
      <section anchor='topint'><name>Remote Monitoring and Schedule Management</name>
      <!--
    <t>
            The 6top interface document
    <xref target="I-D.ietf-6tisch-6top-interface"/>
            specifies the generic data model that can be used to monitor and manage
            resources target="RFC9033">MSF</xref> is one of the 6top sublayer. Abstract methods are suggested for use
            by a management entity in the device. The data model also enables
            remote control operations on possible
    Scheduling Functions. MSF uses the 6top sublayer. rendezvous slot from
    <xref target="RFC8180"/> for network discovery, neighbor discovery, and any
    other broadcast.
    </t>
    <t>
            The capability to interact
    For basic unicast communication with the any neighbor, each node 6top sublayer uses a receive
    cell at a well-known slotOffset/channelOffset, which is derived from multiple hops away a hash of their
    own MAC address.
    Nodes can be leveraged for monitoring, scheduling, or reach any neighbor by installing a combination of thereof.
            The architecture supports variations on transmit (shared) cell with
    slotOffset/channelOffset derived from the deployment model, neighbor's MAC address.
    </t>
    <t>
    For child-parent links, MSF continuously monitors the load between parents
    and
            focuses on children. It then uses 6P to install or remove unicast cells whenever the flows rather than
            whether there is a proxy
    current schedule appears to be under-provisioned or a translation operation en-route. over-provisioned.

         </t>
      </section>

      <section><name>6top and RPL Objective Function Operations</name>
         <t>
            <xref target="I-D.ietf-6tisch-coap"/> defines an mapping
            An implementation of a <xref target="RFC6550">RPL</xref> Objective Function
            (OF), such as the 6top set of commands, which <xref target="RFC6552">RPL Objective Function Zero (OF0)
            </xref> that is described used in the <xref target="I-D.ietf-6tisch-6top-interface"/>, to CoAP resources.
            This allows an entity target="RFC8180">Minimal
            6TiSCH Configuration</xref> to interact with support RPL over a static schedule, may
            leverage for its internal computation the information maintained by 6top.
         </t>
         <t>An OF may require metrics about reachability, such as the Expected
            Transmission Count (ETX) metric <xref target="RFC6551"/>.
            6top layer of 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 node set of statistics with
            respect to that
            is multiple hops away in a RESTful fashion. specific neighbor.

         </t>
-->
         <!--t>
         <t>
            The work at neighbor information may include the 6TiSCH WG is focused on non-deterministic traffic and
         does not provide time when the generic data model last
            packet has been received from that would be necessary to
         monitor and manage resources neighbor, a set of cell quality
            metrics, e.g., received signal strength indication (RSSI) or link
            quality indicator (LQI), the 6top sublayer. It is recognized
         that CoAP number of packets sent to the
            neighbor, or the number of packets received from it. This
            information can be appropriate to interact with the made available through 6top layer of management APIs
            and used, for instance, to compute a
         node Rank Increment that is multiple hops away across a 6TiSCH mesh. will
            determine the selection of the preferred parent.
         </t>
         <t>
            The entity issuing
            6top provides statistics about the CoAP requests underlying layer so the OF can be a central scheduling entity
            (e.g., a PCE), a node multiple hops away with the authority tuned
            to modify the nature of the TSCH
            schedule (e.g., MAC layer. 6top also enables the head of a local cluster), or a external device monitoring RPL OF to
            influence the
            overall state MAC behavior, for instance, by configuring the periodicity of
            IEEE Std 802.15.4 Extended Beacons (EBs). By augmenting the network (e.g., NME). It EB periodicity, it is also
            possible that a
            mapping entity on to change the backbone transforms a non-CoAP protocol such network dynamics so as PCEP into the RESTful interfaces that to improve the 6TiSCH support of
            devices support.

         </t-->
         <t>
          Remote monitoring and Schedule Management refers to a DetNet/SDN model
          whereby an NME and a scheduling entity, associated with a PCE, reside that may change their point of attachment in a central controller and interact with the 6top layer to control
          IPv6 Links and Tracks (<xref target='ontrk'/>) 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.
         </t>
         <t>
         The work at the 6TiSCH WG focused on non-deterministic traffic and
         did not provide
            Some RPL control messages, such as the generic data model DODAG Information Object (DIO), are
            ICMPv6 messages that are broadcast to all neighbor nodes.
            With 6TiSCH, the broadcast channel requirement is necessary addressed by 6top
            by configuring TSCH to provide a broadcast channel,
            as opposed to, for instance, piggybacking the
         controller to  monitor DIO messages in
            Layer 2 Enhanced Beacons (EBs), which would produce undue timer
            coupling among layers and manage resources of packet size issues, and could conflict with
            the 6top sublayer.
         This is deferred policy of production networks where EBs are mostly eliminated
            to future work, see <xref target='unchartered-tracks'/>. conserve energy.
         </t>
         <!-- for later -->
      </section>
      <section anchor="sync"><name>Network Synchronization</name>
         <t>
         With respect
            Nodes in a TSCH network must be time synchronized.
            A node keeps synchronized to Centralized routing its time source neighbor
            through a combination of frame-based and scheduling, acknowledgment-based synchronization.
            To maximize battery life and network throughput, it is envisioned advisable that RPL ICMP discovery
            and maintenance traffic (governed by the related component of Trickle timer) be somehow coordinated with the 6TiSCH Architecture would
            transmission of time synchronization packets (especially with Enhanced Beacons).
         </t>
         <t>
            This could be achieved through an
         extension interaction of the
         <xref target='RFC8655'>DetNet Architecture</xref>,
         which studies Layer-3 aspects of Deterministic Networks, 6top sublayer and covers
         networks that span multiple Layer-2 domains. the RPL Objective Function,
            or could be controlled by a management entity.
         </t>
         <t>
         The DetNet architecture is a form of Software Defined Networking (SDN)
         Architecture and is composed of three planes,
            Time distribution requires a (User) Application
         Plane, loop-free structure. Nodes caught in a Controller Plane (where synchronization loop will rapidly
            desynchronize from the PCE operates), network and a Network Plane
         which can represent a become isolated. 6TiSCH LLN.
         </t>
         <t>
         <xref target='RFC7426'>Software-Defined Networking (SDN):
         Layers and Architecture Terminology</xref> proposes uses a generic
         representation 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 SDN architecture three modes that is reproduced are detailed
            in Section <xref target='RFC7426archi'/>.
  </t>
  <figure align='center' anchor='RFC7426archi'><name>SDN Layers and Architecture Terminology per RFC 7426</name>
   <artwork align='left'>
   <![CDATA[
                  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 target="RFC6550" section="3.1.3" sectionFormat="bare" format="default"/>
             of  <xref target="RFC6550">RPL</xref>, "Instances, DODAGs, and resource Abstraction Layer (DAL)           |
    *------------Y---------------------------------Y----------------*
    |            |                                 |                |
    |    o-------Y----------o   +-----+   o--------Y----------o     |
    |    | Forwarding Plane |   | App |   | Operational Plane |     |
    |    o------------------o   +-----+   o-------------------o     |
    |                       Network Device                          |
    +---------------------------------------------------------------+
  ]]></artwork>
 </figure>
      <t>The PCE establishes end-to-end Tracks 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).
         </t>
         <t>
            In the absence
            of hard cells, which are described 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.
         </t>
         <t>
            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 more details that Instance, where DAGRank() is the operation specified in
            Section <xref target='trkfwd'/>. target="RFC6550" section="3.5.1" sectionFormat="bare" format="default"/>
            of <xref target="RFC6550"/>, "Rank Comparison".
         </t>
         <t>

            The DetNet work 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.
         </t>
         <t>
            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 expected to enable end configured to end Deterministic Path
         across heterogeneous network. This can be for instance serve as time parent, then the node should
            join the TSGI, obtain a 6TiSCH LLN Rank in that Instance, and an Ethernet Backbone.

      </t>
      <t>This model fits start advertising
            its own DagRank in the 6TiSCH extended configuration, whereby a
         6BBR federates
         multiple 6TiSCH LLN TSGI as its Join Priority in a single subnet its EBs.
         </t>
      </section>

      <section anchor="slotframes"><name>Slotframes and CDU Matrix</name>

         <t>
         6TiSCH enables IPv6 best-effort (stochastic) transmissions over a backbone that can be,
         for instance, Ethernet or Wi-Fi. In MAC
         layer that model,
         6TiSCH 6BBRs synchronize with one another over is also capable of scheduled (deterministic) transmissions.
         A window of time is defined
         around the backbone, so scheduled transmission where the medium must, as much as
         practically feasible, be free of contending energy to ensure that the multiple LLNs
         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 form is adopted in IEEE Std 802.15.4 TSCH as well as the IPv6 subnet stay
         tightly synchronized. Long
         Term Evolution (LTE) of cellular networks.
         </t>
         <t>
         If
         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.
         </t>
         <t>
         A CDU matrix is defined centrally
         as part of the Backbone network definition. It is Deterministic, then a matrix of cells with a
         height equal to the
         Backbone Router ensures number of available channels (indexed by
         channelOffsets) and a width (in timeslots) that the end-to-end deterministic
         behavior is maintained between the LLN and period of the backbone.
         It is
         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 PCE devices themselves, at an extra cost in
         terms of energy to compute scan for free cells (more in <xref target="schd"/>).
         </t>
         <t>
         The size of a
         deterministic path cell is a timeslot duration, and
         values  of 10 to end across the 15 milliseconds are typical in 802.15.4 TSCH network to
         accommodate for the transmission of a frame and an IEEE Std. 802.1
         TSN Ethernet backbone, and that of DetNet ack, including the
         security validation on the receive side, which may take up to enable end-to-end deterministic
         forwarding. a few
         milliseconds on some device architecture.
         </t>
      </section>
    <section><name>Hop-by-hop Scheduling</name>
         <t>
         A node can reserve CDU matrix iterates over a <xref target='ontrk'>Track</xref> to one or more
    destination(s) that are well-known channel rotation
         called the hopping sequence.
         In a given network, there might be multiple hops away by installing soft cells at each
    intermediate node.
    This forms 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 Track 6TiSCH domain operate with
         the same cell duration and are aligned so as to reduce the
         chances of soft cells. A Track Scheduling Function above interferences from the 6top
    sublayer Slotted ALOHA operations.
         The knowledge of each node on the Track is needed to monitor these soft cells and
    trigger relocation when needed.
    </t>
    <t>
    This hop-by-hop reservation mechanism CDU matrices is expected to be similar shared
         between all the nodes and used in essence particular to <xref target='RFC3209'/> and/or <xref target='RFC4080'/>/<xref target='RFC5974'/>.
    The protocol for define slotframes.
          </t>
          <t>
          A slotframe is a node to trigger hop-by-hop scheduling MAC-level abstraction that is not yet defined.
         </t>
      </section>
   </section>
   <!--
   <section anchor="topo" title="6TiSCH Device Capabilities">

   <t>6TiSCH common to all nodes are usually IoT devices, and
          contains a series of timeslots of equal length and precedence.
          It is characterized by very limited amount
   of memory, just enough buffers to store one or a few IPv6 packets, slotframe_ID and
   limited bandwidth between peers. It results that a node will maintain only slotframe_size.
          A slotframe aligns to a
   small CDU matrix for its parameters, such as number of peering information,
          and will not be able to store many
   packets waiting to be forwarded. Peers duration of timeslots.
          </t>
          <t>
          Multiple slotframes can be identified through MAC or IPv6
   addresses, but coexist in a Cryptographically Generated Address <xref target="RFC3972"/>
   (CGA) node schedule, i.e., a node can
          have multiple activities scheduled in different slotframes.
          A slotframe is associated with a priority that may also be used. 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.
          </t>
          <t>
   Neighbors
          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
          <xref target="RFC2474"/> can therefore be discovered over the radio using mechanism such as beacons,
   but, though used).
          At each scheduled transmit slot, 6top looks for the neighbor information is available frame
          in all the 6TiSCH interface
   data model, 6TiSCH does not describe a protocol to pro-actively push outgoing queues that best matches the
   neighborhood information to cells.
          If a PCE.
   This protocol should be described and should operate over CoAP. The protocol
   should be able frame is found, it is given to carry multiple metrics, in particular the same metrics as
   used TSCH MAC for RPL operations <xref target="RFC6551"/>. transmission.
         </t>
      </section>

      <section anchor="DistRsvTS"><name>Distributing the Reservation of Cells</name>

         <t>
            The energy that 6TiSCH architecture introduces the device consumes in sleep, transmit and receive modes can
   be evaluated and reported. So can concept of chunks
            (<xref target="sixTTerminology"/>) to distribute the amount allocation of energy that
            the spectrum for a whole group of cells at a time.
            The CDU matrix is stored formatted into a set of chunks, possibly as
            illustrated in <xref target="fig10"/>, each of the
   device and the power that it can be scavenged from the environment. chunks
            identified uniquely by a chunk-ID. The PCE
   SHOULD be able to compute Tracks that will implement policies on how the
   energy knowledge of this
            formatting is consumed, for instance balance shared between nodes, ensure that all the spent
   energy does not exceeded nodes in a 6TiSCH network.
            It could be conveyed during the scavenged energy over join process, codified into a period profile document,
            or obtained using some other mechanism. This is as opposed
            to Static Scheduling, which refers to the preprogrammed mechanism
            specified in <xref target="RFC8180"/> and which existed before the
            distribution of time, etc... the chunk formatting.
          </t>

   </section>
   </section>

   -->

 <section anchor='ontrk'><name>On Tracks</name>
            <figure anchor="fig10"><name>CDU Matrix Partitioning in Chunks</name>
<artwork align="center"><![CDATA[
             +-----+-----+-----+-----+-----+-----+-----+     +-----+
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
]]></artwork>
            </figure>

          <t>
            The 6TiSCH architecture introduces the concept of a Track, which is envisions a directed path
    from protocol that enables chunk
            ownership appropriation whereby a source 6TiSCH node to one or more destination 6TiSCH node(s)
    across RPL parent
            discovers a 6TiSCH LLN.
    </t>
    <t>
    A Track chunk that is the 6TiSCH instantiation of the concept of a Deterministic Path
    as described not used in <xref target='RFC8655'/>.
    Constrained resources such as memory buffers are reserved for that Track its interference domain,
            claims the chunk, and then defends it in
    intermediate 6TiSCH nodes to avoid loss related case another RPL
            parent would attempt to limited capacity.
    A 6TiSCH node along a Track not only knows which bundles of cells appropriate it should
    use to receive packets from a previous hop, but also knows which bundle(s) while it should use to send packets to its next hop along the Track.
    </t>

   <section><name>General Behavior of Tracks</name>
    <t>
    A Track is associated with Layer-2 bundles in use.
            The chunk is the basic unit of cells with related schedules
    and logical relationships and that ensure that a packet ownership that is injected in
    a Track will progress used in due time all the way to destination. that process.
         </t>
         <t>
    Multiple cells may be scheduled in
            As a Track for result of the transmission process of a single
    packet, in chunk ownership appropriation, the RPL
            parent has exclusive authority to decide which case cell in the normal operation of IEEE Std. 802.15.4 Automatic
    Repeat-reQuest (ARQ)
            appropriated chunk can take place; the acknowledgment may be omitted used by which node in
    some cases, for instance if there its interference
            domain. In other words, it is implicitly delegated the right to
            manage the portion of the CDU matrix that is no scheduled cell for a possible retry. represented by the
            chunk.
         </t>
         <t>
    There
            Initially, those cells are several benefits for using a Track to forward a packet from a
    source node added to the destination node. heap of free cells, then
            dynamically placed into existing bundles, into new bundles, or
            allocated opportunistically for one transmission.
         </t>
    <ol  spacing='normal'>
       <li>
       Track forwarding, as further described in  <xref target='trkfwd'/>, is

         <t>
            Note that a
       Layer-2 forwarding scheme, which introduces less process delay and
       overhead than Layer-3 forwarding scheme.  Therefore, LLN Devices can save
       more energy and resource, which PCE is critical for resource constrained devices.
       </li>
       <li>
       Since channel resources, i.e., bundles of cells, expected to have been reserved for
       communications between 6TiSCH nodes of each hop on the Track, the
       throughput and the maximum latency of precedence in the traffic along
            allocation, so that a Track RPL parent would only be able to obtain
            portions that are
       guaranteed and not in use by the jitter is maintained small.
       </li>
       <li>
       By knowing PCE.
         </t>
      </section>
   </section>
   <section anchor="schd"><name>Schedule Management Mechanisms</name>
      <t>
         6TiSCH uses four paradigms to manage the scheduled time slots TSCH schedule of incoming bundle(s) the LLN nodes: Static Scheduling,
         Neighbor-to-Neighbor Scheduling, Remote Monitoring and outgoing
       bundle(s), 6TiSCH nodes on a Track could save more energy by staying in
       sleep state during in-active slots.

       </li>
       <li>
       Tracks Scheduling Management, and Hop-by-Hop Scheduling.
         Multiple mechanisms are protected from interfering with one another if a cell is scheduled to belong to at most one Track, defined that implement the associated Interaction Models,
         and congestion loss is avoided if at most one
       packet they can be presented to combined and used in the MAC same LLN.
         Which mechanism(s) to use that cell.
       Tracks enhance depends on application requirements.
      </t>
      <section anchor="mini"><name>Static Scheduling</name>
         <t>
            In the reliability simplest instantiation of transmissions and thus further improve
       the energy consumption in LLN Devices a 6TiSCH network, a common fixed
            schedule may be shared by reducing all nodes in the chances of
       retransmission.

       </li>
    </ol><t> network. Cells are shared,
            and nodes contend for slot access in a Slotted ALOHA manner.
         </t>
   </section>

   <section><name>Serial Track</name>
         <t>
            A Serial (or simple) Track is the 6TiSCH version of static TSCH schedule can be used to bootstrap a circuit; network, as an
            initial phase during implementation or as a bundle fall-back mechanism in
            case of
    cells that are programmed to receive (RX-cells) network malfunction.
            This schedule is uniquely paired to a
    bundle of cells that are set to transmit (TX-cells), representing preestablished, for instance, decided by a Layer-2
    forwarding state which network
            administrator based on operational needs. It can be used regardless of preconfigured
            into the nodes, or, more commonly, learned by a node when joining
            the network layer protocol.
    A Serial Track is thus formed end-to-end as using standard IEEE Std 802.15.4 Information Elements (IE).
            Regardless, the schedule remains unchanged
            after the node has joined a succession network.
            RPL is used on the resulting network. This "minimal" scheduling
            mechanism that implements this paradigm is detailed in
            <xref target="RFC8180"/>.
         </t>
      </section>
      <section anchor="dynsched"><name>Neighbor-to-Neighbor Scheduling</name>
         <t>
            In the simplest instantiation of
    paired bundles, a receive bundle from 6TiSCH network described in
            <xref target="mini"/>, nodes may expect a packet at any cell in
            the previous hop schedule and will waste energy idle listening. In a transmit bundle
    to the next hop along the Track.
    </t>
    <t>
    For more
            complex instantiation of a given iteration 6TiSCH network, a matching portion of the device schedule,
            schedule is established between peers to reflect the effective channel observed amount
            of transmissions between those nodes. The aggregation of the
    cell is obtained by following in cells
            between a loop node and a well-known hopping sequence peer forms a bundle that
    started at Epoch time at the channelOffset of 6top sublayer uses to
            implement the cell, which results
    in a rotation abstraction of the frequency that used a link for transmission. IP. The bundles may be computed so as bandwidth on that
            link is proportional to accommodate both variable rates and
    retransmissions, so they might not be fully used in the iteration of the
    schedule.
    </t>

     </section>

     <section><name>Complex Track with Replication and Elimination</name>

    <t>
    The art number of Deterministic Networks already include Packet Replication and
    Elimination techniques. Example
    standards include cells in the Parallel Redundancy Protocol (PRP) and bundle.
         </t><t>
            If the
    High-availability Seamless Redundancy (HSR) <xref target='IEC62439'/>.
    Similarly, and as opposed to size of a Serial Track that bundle is a sequence configured to fit an average amount of nodes
    and links, a Complex Track
            bandwidth, peak traffic is shaped as a directed acyclic graph towards one
    or more destination(s) dropped. If the size is
            configured to support multi-path forwarding and route around
    failures.
    </t>
    <t>
    A Complex Track may branch off over non congruent branches allow for the purpose
    of multicasting, and/or redundancy, peak emissions, energy is wasted
            idle listening.
         </t><t>
            As discussed in which case it reconverges later down more detail in <xref target="s6Pprot"/>, the path.
    This enables
            <xref target="RFC8480">6top Protocol</xref>
            specifies 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 exchanges between neighbor nodes to
    redundant transmissions reserve soft cells
            to compensate for transmit to one another, possibly under the lossiness control of a
            Scheduling Function (SF). Because this reservation is done without
            global knowledge of the medium and meet
    industrial expectations schedule of a Reliable and Available Wireless network.
    Combining PAREO and PREOF, a Track may extend beyond the 6TiSCH network other nodes in a larger DetNet network.
    </t>
    <t>
    In the art of TSCH, a path does not necessarily support PRE but it is almost
    systematically multi-path. This means that a Track is scheduled so LLN, scheduling
            collisions are possible.
         </t><t>
            And as to
    ensure that each hop has at least two forwarding solutions, and the
    forwarding decision discussed in <xref target="missf"/>,
            an optional SF is used to try the preferred one
            monitor bandwidth usage and use to perform requests for dynamic allocation
            by the other in
    case 6top sublayer.
            The SF component is not part of Layer-2 transmission failure as detected by ARQ. Similarly,
    at each 6TiSCH hop along the Track, 6top sublayer. It may be
            co-located on the PCE same device or may schedule more than one
    timeslot for a packet, so as be partially or fully offloaded
            to an external system. The <xref target="RFC9033">
            "6TiSCH Minimal Scheduling Function (MSF)"</xref> provides a simple
            SF that can be used by default by devices that
            support Layer-2 retries (ARQ). It dynamic scheduling of soft cells.
   </t>
         <t>
            Monitoring and relocation is also
    possible that done in the field device only uses 6top sublayer. For the second branch if sending over 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 first branch fails. exact
            slotOffset/channelOffset of those cells.
         </t>
      </section>

     <section><name>DetNet End-to-end Path</name>
      <section anchor="topint"><name>Remote Monitoring and Schedule Management</name>
         <t>
    Ultimately, DetNet should
    enable
          Remote Monitoring and Schedule Management refers to extend a Track beyond the 6TiSCH LLN as illustrated in
    <xref target='elifig'/>. In that example, DetNet/SDN model
          whereby an NME and a Track that is laid out from scheduling entity, associated with a
    field device PCE, reside
          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 central controller and interact with the Packet Replication,
    Elimination, 6top sublayer to control
          IPv6 links and Ordering Functions over Tracks (<xref target="ontrk"/>) 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 DODAG that forms
          reliability within a Track. bounded latency for a well-specified flow.
         </t>
         <t>
         The Replication function work in the 6TiSCH Node sends a copy of each packet over
    two different branches, Working Group focused on nondeterministic traffic and
         did not provide the PCE schedules each hop generic data model necessary for the
         controller to  monitor and manage resources of both branches so the 6top sublayer.
         This is deferred to future work, see <xref target="unchartered-tracks"/>.

         </t>
         <t>
         With respect to centralized routing and scheduling, it is envisioned
         that the two copies arrive in due time at related component of the gateway. In case 6TiSCH architecture would be an
         extension of the <xref target="RFC8655">DetNet architecture</xref>,
         which studies Layer 3 aspects of Deterministic Networks and covers
         networks that span multiple Layer 2 domains.
         </t>
         <t>
         The DetNet architecture is a form of Software-Defined Networking (SDN)
         architecture and is composed of three planes: a loss on
    one branch, hopefully (User) Application
         Plane, a Controller Plane (where the other copy PCE operates), and a Network Plane,
         which can represent a 6TiSCH LLN.
         </t>
         <t>
         <xref target="RFC7426">"Software-Defined Networking (SDN):
         Layers and Architecture Terminology"</xref> proposes a generic
         representation of the packet still makes it in due
    time. If two copies make it to the IoT gateway, the Elimination function SDN architecture that is reproduced in the gateway ignores the extra packet and presents only one copy to upper
    layers.
         <xref target="RFC7426archi"/>.
  </t>
  <figure align='center' anchor='elifig'><name>Example End-to-End DetNet Track</name>
<artwork><![CDATA[
                  +-=-=-+ align="center" anchor="RFC7426archi"><name>SDN Layers and Architecture Terminology per RFC 7426</name>
   <artwork align="left"><![CDATA[
                  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
                 | IoT                                 |
    *------------Y---------------------------------Y----------------*
    | G/W         Device and resource Abstraction Layer (DAL)           |
                  +-=-=-+
                     ^  <=== Elimination
     Track branch
    *------------Y---------------------------------Y----------------*
    |            |
            +-=-=-=-+ +-=-=-=-=+ Subnet Backbone                                 |                |
         +-=|-=+            +-=|-=+
    |    o-------Y----------o   +-----+   o--------Y----------o     |
    | Backbone    | Forwarding Plane |   | Backbone
    o App |   | Operational Plane | router     |
    |    o------------------o   +-----+   o-------------------o     | router
         +-=/-=+            +-=|-=+
    o     /    o     o-=-o-=-=/       o
        o    o-=-o-=/   o      o   o  o   o
   o     \  /     o               o   LLN    o
      o   v  <=== Replication
          o
    |                       Network Device                          |
    +---------------------------------------------------------------+
]]></artwork>
 </figure>
   </section>

<section><name>Cell Reuse</name>

    <t>
    The 6TiSCH architecture provides means to avoid waste
      <t>The PCE establishes end-to-end Tracks of cells as
    well as overflows hard cells, which are described
      in the transmit bundle of a Track, as follows: more detail in <xref target="trkfwd"/>.
      </t>
      <t>
        A TX-cell that
      The DetNet work is not needed expected to enable end-to-end deterministic paths
         across heterogeneous networks. This can be, for the current iteration may
        be reused opportunistically on instance, a per-hop basis for routed packets.
        When all of 6TiSCH LLN
         and an Ethernet backbone.

      </t>
      <t>This model fits the frame that were received for 6TiSCH extended configuration, whereby a given Track are
        effectively transmitted, any available TX-cell for
         6BBR federates
         multiple 6TiSCH LLNs in a single subnet over a backbone that Track can be
        reused for upper layer traffic be,
         for which the next-hop router matches instance, Ethernet or Wi-Fi. In that model,
         6TiSCH 6BBRs synchronize with one another over the
        next hop along backbone, so as
         to ensure that the Track.
        In multiple LLNs that case, form the cell IPv6 subnet stay
         tightly synchronized.
      </t>

      <t>
         If the backbone is deterministic, then the
         Backbone Router ensures that the end-to-end deterministic
         behavior is being used maintained between the LLN and the backbone.
         It is effectively a TX-cell from the Track, but responsibility of the short address for PCE to compute a
         deterministic path end to end across the destination TSCH network and an IEEE Std 802.1
         TSN Ethernet backbone, and it is that of the
        next-hop router. responsibility of DetNet to enable end-to-end deterministic
         forwarding.
      </t>
      </section>
    <section><name>Hop-by-Hop Scheduling</name>
    <t>
        It results in
    A node can reserve a frame <xref target="ontrk">Track</xref> to one or more
    destination(s) that is received in are multiple hops away by installing soft cells at each
    intermediate node.
    This forms a RX-cell Track of a soft cells. A Track with a
        destination MAC address set to this node as opposed to SF above the broadcast MAC
        address must be extracted from 6top
    sublayer of each node on the Track and delivered is needed to the upper layer.
        Note that a frame with an unrecognized destination MAC address monitor these soft cells and
    trigger relocation when needed.
    </t>
    <t>
    This hop-by-hop reservation mechanism is dropped
        at the lower MAC layer expected to be similar in essence
    to <xref target="RFC3209"/> and/or <xref target="RFC4080"/> and thus <xref target="RFC5974"/>.
    The protocol for a node to trigger hop-by-hop scheduling is not received at the 6top sublayer. yet defined.
         </t>
      </section>
   </section>

 <section anchor="ontrk"><name>On Tracks</name>

    <t>
        On the other hand, it might happen that there are not enough TX-cells
        in
    The architecture introduces the transmit bundle concept of a Track, which is a directed path
    from a source 6TiSCH node to accommodate the Track traffic, for instance if one or more retransmissions destination 6TiSCH node(s)
    across a 6TiSCH LLN.
    </t>
    <t>
    A Track is the 6TiSCH instantiation of the concept of a deterministic path
    as described in <xref target="RFC8655"/>.
    Constrained resources such as memory buffers are needed than provisioned.
        In that case, and if the frame transports an IPv6 packet, then it can be
        placed reserved for transmission in the bundle that is used for Layer-3 traffic
        towards the 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.
        The MAC address should be set to the next-hop MAC address to avoid
        confusion.
    </t>

   <section><name>General Behavior of Tracks</name>

    <t>
        It results in
    A Track is associated with Layer 2 bundles of cells with related schedules
    and logical relationships that ensure that a frame packet that is received over injected in
    a Layer-3 bundle Track will progress in due time all the way to destination.
    </t>
    <t>
    Multiple cells may be scheduled in
        fact associated to a Track. In Track for the transmission of a classical IP link such as an Ethernet,
        off-Track traffic is typically single
    packet, in excess over reservation to be routed
        along the non-reserved path based on its QoS setting.
        But with 6TiSCH, since which case the use normal operation of IEEE Std 802.15.4 Automatic
    Repeat-reQuest (ARQ) can take place; the Layer-3 bundle acknowledgment may be due to
        transmission failures, it makes sense omitted in
    some cases, 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 should be re-Tracked instance, if the Per-Hop-Behavior group indicated in
        the Differentiated Services Field of the IPv6 header there is set no scheduled cell for a possible retry.
    </t>
    <t>
    There are several benefits for using a Track to
        Deterministic forward a packet from a
    source node to the destination node:
    </t>
    <ol spacing="normal">
       <li>
       Track Forwarding, as discussed further described in  <xref target="pmh"/ -->.
        A frame target="trkfwd"/>, is re-Tracked by scheduling it 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 transmission over the
        transmit bundle associated to resource-constrained devices.
       </li>
       <li>
       Since channel resources, i.e., bundles of cells, have been reserved for
       communications between 6TiSCH nodes of each hop on the Track, with the destination MAC
        address set to broadcast.
            </t>

   </section>
   </section>

   <section anchor='fwd'><name>Forwarding Models</name>
      <!-- TW: Forwarding models should be formalized in
       throughput and the maximum latency of the traffic along a standards-Track draft? One should be MUST (IPv6?), Track are
       guaranteed, and the others SHOULD? -->
      <t> jitter is minimized.
       </li>
       <li>
       By forwarding, this document means knowing the per-packet operation that
         allows to deliver a packet to scheduled timeslots of incoming bundle(s) and outgoing
       bundle(s), 6TiSCH nodes on a next hop or an upper layer Track could save more energy by staying in this node.
         Forwarding is based on pre-existing
       sleep state that was installed as during inactive slots.

       </li>
       <li>
       Tracks are protected from interfering with one another if a
         result 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 a routing computation <xref target='rtg'/>.
         6TiSCH supports three different forwarding model:(G-MPLS) Track
         Forwarding, (classical) IPv6 Forwarding transmissions and (6LoWPAN) Fragment Forwarding.
      </t>

 <section anchor='trkfwd'><name>Track Forwarding</name> thus further improve
       the energy consumption in LLN devices by reducing the chances of
       retransmission.
       </li>
    </ol>
   </section>

   <section><name>Serial Track</name>

    <t>
            Forwarding along a
    A Serial (or simple) Track can be seen as is the 6TiSCH version of a Generalized Multi-protocol
            Label Switching (G-MPLS) operation in circuit: a bundle of
    cells that the information used are programmed to
            switch a frame receive (RX-cells) is not an explicit label, but rather related to other
            properties of the way the packet was received, uniquely paired with a particular cell in
            the case
    bundle of 6TiSCH.
            As a result, as long as the TSCH MAC (and Layer-2 security) accepts cells that are set to transmit (TX-cells), representing a frame, Layer 2
    forwarding state that frame can be switched used 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.
         </t>
         <t> network-layer protocol.
    A data frame that is forwarded along a Serial Track normally has a
            destination MAC address that is set to broadcast - or thus formed end-to-end as a multicast
            address depending on MAC support.
            This way, the MAC layer in the intermediate nodes accepts succession of
    paired bundles: a receive bundle from the
            incoming frame previous hop and 6top switches it without incurring a change in
            the MAC header.
            In transmit bundle
    to the case of IEEE Std. 802.15.4, this means effectively
            broadcast, so that next hop along the Track the short address for the
            destination of the frame is set to 0xFFFF. Track.
    </t>
    <t>
            There are 2 modes for a Track, an IPv6 native mode and
    For a protocol-independant tunnel mode.
         </t>
         <section><name>Native Mode</name>
            <t>
               In native mode, the Protocol Data Unit (PDU) is associated
               with flow-dependent meta-data that refers uniquely to the Track,
               so given iteration of the 6top sublayer can place device schedule, the frame in effective channel of the appropriate
    cell
               without ambiguity. In is obtained by looping through a well-known hopping sequence
    beginning at Epoch time and starting at the case cell's channelOffset, which results
    in a rotation of IPv6 traffic, this flow
               identification the frequency that is used for transmission.

    The bundles may be done using a 6-tuple computed so as discussed to accommodate both variable rates and
    retransmissions, so they might not be fully used in
               <xref target='I-D.ietf-detnet-ip'/>. In particular,
               implementations of this document should support identification the iteration of
               DetNet flows based on the IPv6 Flow Label field.
    schedule.
    </t>

     </section>

     <section><name>Complex Track with Replication and Elimination</name>

    <t>
    The flow follows 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) <xref target="IEC62439"/>.
    Similarly, and as opposed to a Serial Track which identification that is done using
               a RPL Instance (see section 3.1.3 of <xref target='RFC6550'/>),
               signaled in a RPL Packet Information (more in section 11.2.2.1 sequence of
               <xref target='RFC6550'/>) nodes
    and the destination address in the case
               of links, a local instance. One Complex Track is shaped as a directed acyclic graph towards one
    or more flows destination(s) to support multipath forwarding and route around
    failures.
    </t>
    <t>
    A Complex Track may be placed 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 same
               Track RAW network.
    Combining PAREO and the PREOF, a Track identification (TrackID + owner) may be placed
               in an
               IP-in-IP encapsulation. The forwarding operation is based on the
               Track and does not depend on extend beyond the flow therein. 6TiSCH network into
    a larger DetNet network.
    </t>
    <t>
               The
    In the art of TSCH, a path does not necessarily support PRE, but it is almost
    systematically multipath. This means that a Track identification is validated scheduled so as to
    ensure that each hop has at egress before restoring
               the destination MAC address (DMAC) least two forwarding solutions, and punting the
    forwarding decision is to try the upper layer.
            </t>
            <t><xref target='fig6t'/> illustrates preferred one and use the Track Forwarding operation
            which happens other in
    case of Layer 2 transmission failure as detected by ARQ. Similarly,
    at each 6TiSCH hop along the 6top sublayer, below IP.
            </t>
               <figure anchor='fig6t'><name>Track Forwarding, Native Mode</name>
<artwork><![CDATA[
                       | Packet flowing across Track, the network  ^
   +--------------+    |                                    |
   |     IPv6     |    |                                    |
   +--------------+    |                                    |
   |  6LoWPAN HC  |    |                                    |
   +--------------+  ingress                              egress
   |     6top     |   sets     +----+          +----+    restores
   +--------------+  DMAC to   |    |          |    |    DMAC PCE may schedule more than one
    timeslot for a packet, so as to
   |   TSCH MAC   |   brdcst   |    |          |    |     dest
   +--------------+    |       |    |          |    |       |
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+
                     Ingress   Relay            Relay     Egress
      Stack support Layer     Node     Node             Node       Node

]]></artwork>
               </figure> 2 retries (ARQ). It is also
    possible that the field device only uses the second branch if sending over
    the first branch fails.
    </t>

     </section>
         <section><name>Tunnel Mode</name>

     <section><name>DetNet End-to-End Path</name>

    <t>
               In tunnel mode,
    Ultimately, DetNet should
    enable extending a Track beyond the frames originate 6TiSCH LLN as illustrated in
    <xref target="elifig"/>. In that example, a Track is laid out from a
    field device in a 6TiSCH network to an arbitrary protocol 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 a compatible MAC the DODAG that may or may not be synchronized with forms a Track.
    </t>
    <t>
    The Replication function in the 6TiSCH network. An example of
               this would be a router with Node sends a dual radio that is capable copy of receiving each packet over
    two different branches, and sending WirelessHART
               or ISA100.11a frames with the second radio, by presenting itself as an access
               Point or a Backbone Router, respectively.
               In PCE schedules each hop of both branches so
    that mode, some entity (e.g., PCE) can coordinate with the two copies arrive in due time at the gateway. In case of a
               WirelessHART Network Manager or an ISA100.11a System Manager loss on
    one branch, hopefully the other copy of the packet still makes it in due
    time. If two copies make it to
               specify the flows that are transported.
            </t>
               <figure anchor='fig6'><name>Track Forwarding, Tunnel Mode</name>
<artwork><![CDATA[

   +--------------+
   |     IPv6     |
   +--------------+
   |  6LoWPAN HC  |
   +--------------+             set            restore
   |     6top     |            +DMAC+          +DMAC+
   +--------------+          to|brdcst       to|nexthop
   |   TSCH MAC   |            |    |          |    |
   +--------------+            |    |          |    |
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+ IoT gateway, the Elimination function
    in the gateway ignores the extra packet and presents only one copy to upper
    layers.
    </t>

         <figure align="center" anchor="elifig"><name>Example End-to-End DetNet Track</name>
<artwork><![CDATA[
                  +-=-=-+
                  |   ingress                 egress IoT |
                  | G/W |
   +--------------+
                  +-=-=-+
                     ^  <=== Elimination
     Track branch   | |
            +-=-=-=-+ +-=-=-=-=+ Subnet backbone
            |   LLN PHY                  |
         +-=|-=+            +-=|-=+
         |  |
   +--------------+  |  Packet flowing across the network Backbone   |  |   TSCH MAC  | Backbone
    o    |  |
   +--------------+  | DMAC = Router     | DMAC =
   |ISA100/WiHART  |  | nexthop Router
         +-=/-=+            +-=|-=+
    o     /    o     o-=-o-=-=/       o
        o    o-=-o-=/   o      o   o  o   o
   o     \  /     o               o   LLN    o
      o   v nexthop
   +--------------+
                     Source   Ingress          Egress   Destination
      Stack Layer     Node     Node             Node       Node  <=== Replication
          o
]]></artwork>
         </figure>
   </section>

<section><name>Cell Reuse</name>

    <t>
    The 6TiSCH architecture provides the means to avoid waste of cells as
    well as overflows in the transmit bundle of a Track, as follows:
    </t>
         <t>
        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 TrackID cell that identifies 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.
        </t>
         <t>
        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 ingress 6TiSCH router lower MAC layer and thus is derived from not received at the RX-cell. The DMAC
               is set 6top sublayer.
        </t>
        <t>
        On the other hand, it might happen that there are not enough TX-cells
        in the transmit bundle to this node but accommodate the TrackID indicates Track traffic, for instance, if
        more retransmissions are needed than provisioned.
        In that case, and if the frame must transports an IPv6 packet, then it can be tunneled over a particular Track so
        placed for transmission in the frame bundle that is
               not passed to used for Layer 3 traffic
        towards the upper layer. Instead, next hop along the DMAC is forced Track.
        The MAC address should be set to
               broadcast and the frame is passed next-hop MAC address to the 6top sublayer for
               switching. avoid
        confusion.
        </t>
         <t>
               At the egress 6TiSCH router,
        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 reverse operation occurs. Based non-reserved path based on tunneling information its QoS setting.
        But with 6TiSCH, since the use of the Track, which Layer 3 bundle may be due to
        transmission failures, it makes sense for instance
               indicate that the tunneled datagram is an IP packet, the datagram is passed receiver to recognize a
        frame that should be re-Tracked and to place it back on the appropriate Link-Layer
        bundle if possible.
        A frame is re-Tracked by scheduling it for transmission over the
        transmit bundle associated with the
               destination MAC restored.
            </t>
         </section>
         <section><name>Tunneling Information</name>
            <t>
               Tunneling information coming Track, 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. set to broadcast.
            </t>

   </section>
   </section>

   <section anchor="fwd"><name>Forwarding Models</name>
      <t>
               If
         By forwarding, this document means the tunnel egress point does not have per-packet operation that
         allows delivery of a MAC address packet to a next hop or an upper layer in this node.
         Forwarding is based on preexisting state that
               matches the configuration, the was installed as a
         result of a routing computation, see <xref target="rtg"/>.
         6TiSCH supports three different forwarding models: (GMPLS) Track installation fails.
         Forwarding, (classical) IPv6 Forwarding, and (6LoWPAN) Fragment Forwarding.
      </t>

 <section anchor="trkfwd"><name>Track Forwarding</name>

         <t>
               If
            Forwarding along a Track can be seen as a Generalized Multiprotocol
            Label Switching (GMPLS) operation in that the Layer-3 destination address belongs information used to
               the tunnel termination, then it
            switch a frame is possible that the IPv6 address
               of the destination not an explicit label but is compressed at the 6LoWPAN sublayer based on
               the MAC address. Restoring rather related to other
            properties of the wrong MAC address at way the egress
               would then also result packet was received, a particular cell in
            the wrong IP address in case of 6TiSCH.
            As a result, as long as the packet
               after decompression.
               For that reason, TSCH MAC (and Layer 2 security) accepts
            a packet frame, that frame can be injected in 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.
         </t>
         <t>
            A data frame that is forwarded along a Track only if
               the normally has a
            destination MAC address is effectively that of the tunnel
               egress point.
               It is thus mandatory for the ingress router set to validate that broadcast or a multicast
            address depending on MAC support.
            This way, the MAC address that was used at layer in the 6LoWPAN
               sublayer for compression matches that of intermediate nodes accepts the tunnel egress point
               before it overwrites it to broadcast.

               The
            incoming frame and 6top sublayer at the tunnel egress point reverts that
               operation to switches it without incurring a change in
            the MAC address obtained from the tunnel
               information.
            </t>
         </section>
      </section>      <section><name>IPv6 Forwarding</name>
         <t>
            As header.
            In the packets are routed at Layer-3, traditional QoS and Active
            Queue Management (AQM) operations are expected case of IEEE Std 802.15.4, this means effectively to prioritize flows.

            <!--
            broadcast, so that along the application Track the short address for the
            destination of Differentiated Services the frame is further discussed in -->
            <!-- <xref target="I-D.svshah-tsvwg-lln-diffserv-recommendations"/>. --> set to 0xFFFF.
         </t>
            <figure anchor='fig9'><name>IP Forwarding</name>
<artwork><![CDATA[

                       | 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

]]></artwork>
            </figure>
      </section>
      <section><name>Fragment Forwarding</name>

         <t>
            Considering that per section 4 of <xref target='RFC4944'/> 6LoWPAN
            packets can be as large as 1280 bytes (the
            There are two modes for a Track: an IPv6 minimum MTU),
            and that the non-storing native mode of RPL implies Source Routing that requires space for routing
            headers, and that a IEEE Std. 802.15.4 frame
            protocol-independent tunnel mode.
         </t>
         <section><name>Native Mode</name>
            <t>
               In native mode, the Protocol Data Unit (PDU) is associated
               with security may carry flow-dependent metadata that refers uniquely to the Track,
               so the 6top sublayer can place the frame in the order of 80 bytes appropriate cell
               without ambiguity. In the case of
            effective payload, an IPv6 packet might traffic, this flow
               may be fragmented into more than 16 fragments at identified using a 6-tuple as discussed in
               <xref target="RFC8939"/>. In particular,
               implementations of this document should support identification of
               DetNet flows based on the
            6LoWPAN sublayer.
         </t> IPv6 Flow Label field.</t>

<t>
            This level of fragmentation is much higher than
   The flow follows a Track that traditionally experienced over the Internet
            with IPv4 fragments, where fragmentation is already known as harmful.
         </t>
         <t>
            In the case to identified using a multihop route within RPL
   Instance (see <xref target="RFC6550" section="3.1.3" sectionFormat="of" format="default"/>),
   signaled in a 6TiSCH network, Hop-by-Hop recomposition occurs at each
            hop to reform the packet and route it. This creates additional latency RPL Packet Information (more in
   <xref target="RFC6550" section="11.2.2.1" sectionFormat="of" format="default"/>)
   and forces intermediate
            nodes to store a portion the source address of a packet for an undetermined time, thus impacting critical resources such
            as memory and battery.
         </t>
         <t>
            <xref target='I-D.ietf-6lo-minimal-fragment'/> describes a framework for forwarding fragments end-to-end across going down the DODAG formed by a 6TiSCH route-over mesh.
            Within that framework, <xref target='I-D.ietf-lwig-6lowpan-virtual-reassembly'/> details local instance.  One or more
   flows may be placed in a virtual reassembly buffer mechanism whereby same Track and the datagram tag Track identification
   (TrackID plus owner) may be placed in an IP-in-IP encapsulation.  The forwarding
   operation is based on the 6LoWPAN Fragment Track and does not depend on the flow
   therein.
</t>
<t>
   The Track identification is used as a label for switching validated at egress before restoring the 6LoWPAN sublayer.
   destination MAC address (DMAC) and punting to the upper layer.
</t>
         <t>
            Building on this technique, <xref target='I-D.ietf-6lo-fragment-recovery'/> introduces a new format for 6LoWPAN fragments
            <t><xref target="fig6t"/> illustrates the Track Forwarding operation
            that enables happens at the selective recovery of individual fragments, and allows for a degree of flow control based on an Explicit Congestion Notification. 6top sublayer, below IP.
            </t>
               <figure anchor='fig7'><name>Forwarding First Fragment</name> anchor="fig6t"><name>Track Forwarding, Native Mode</name>
<artwork><![CDATA[
                       | Packet flowing across the network  ^
   +--------------+    |                                    |
   |     IPv6     |    |       +----+          +----+                                    |
   +--------------+    |                                    |
   |          |    |       |
   |  6LoWPAN HC  |    |       learn           learn                                    |
   +--------------+    |       |    |          |    |       |  ingress                              egress
   |     6top     |    |       |    |          |    |       |   sets     +----+          +----+    restores
   +--------------+  DMAC to   |    |          |    |    |       |    DMAC to
   |   TSCH MAC   |   brdcst   |    |          |    |    |       |     dest
   +--------------+    |       |    |          |    |       |
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+
                     Source
                     Ingress   Relay            Relay     Egress   Destination
      Stack Layer     Node    Router           Router     Node             Node       Node
]]></artwork>
               </figure>
         </section>
         <section><name>Tunnel Mode</name>
            <t>
               In that model, tunnel mode, the first fragment is routed based on frames originate from an arbitrary protocol over a compatible MAC
               that may or may not be synchronized with the IPv6 header 6TiSCH network. An example of
               this would be a router with a dual radio that is present in that fragment.
            The 6LoWPAN sublayer learns capable of receiving and sending WirelessHART
               or ISA100.11a frames with the next hop selection, generates second radio by presenting itself as an access
               point or a new datagram tag for transmission to
            the next hop, and stores Backbone Router, respectively.
               In that information indexed by mode, some entity (e.g., PCE) can coordinate with a
               WirelessHART Network Manager or an ISA100.11a System Manager to
               specify the incoming MAC address and datagram tag. The next
            fragments are then switched based on flows that stored state. are transported.
            </t>
               <figure anchor='fig8'><name>Forwarding Next Fragment</name> anchor="fig6"><name>Track Forwarding, Tunnel Mode</name>
<artwork><![CDATA[
                       | Packet flowing across the network  ^
   +--------------+
   |                                    |
   |     IPv6     |    |                                    |
   +--------------+
   |                                    |
   |  6LoWPAN HC  |    |       replay          replay       |
   +--------------+             set            restore
   |     6top     |            +DMAC+          +DMAC+
   +--------------+          to|brdcst       to|nexthop
   |   TSCH MAC   |            |    |          |     6top    |
   +--------------+            |    |          |    |
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+    |   ingress                 egress   |
                       |                                    |
   +--------------+    |                                    |
   |   TSCH MAC   |    |   LLN PHY    |    |                                    |
   +--------------+    |  Packet flowing across the network |
   +--------------+
   |   TSCH MAC   |    |                                    |
   +--------------+    | DMAC =                             | DMAC =
   |ISA100/WiHART |   LLN PHY    |    +-------+    +--...-----+    +-------+ nexthop                            v nexthop
   +--------------+
                     Source   Ingress          Egress   Destination
      Stack Layer     Node    Router           Router     Node             Node       Node
]]></artwork>
               </figure>

            <t>
            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.
         </t>
      </section>

   </section>

      <section anchor='rtg'><name>Advanced 6TiSCH Routing</name>
   <section anchor='pmh'><name>Packet Marking and Handling</name>
   <t>
   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.
   </t>
    <t>
   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.
   </t>
   <t>
   For packets
               In that are routed by RPL, case, the TrackID that information is identifies the RPLInstanceID
   which Track at
               the ingress 6TiSCH router is carried in derived from the RPL Packet Information (RPI), as discussed in
   section 11.2 of <xref target='RFC6550'/>, "Loop Avoidance and Detection". RX-cell.
               The RPI DMAC
               is transported by a RPL option in the IPv6 Hop-By-Hop Header
   <xref target='RFC6553'/>.
   </t>
   <t>
   A compression mechanism for set to this node, but the RPL packet artifacts TrackID indicates that integrates the
   compression of IP-in-IP encapsulation and
               frame must be tunneled over a particular Track, so the Routing Header type 3
   <xref target='RFC6554'/>
   with that of frame is
               not passed to the RPI in a 6LoWPAN dispatch/header type upper layer. Instead, the DMAC is specified in
   <xref target='RFC8025'/> forced to
               broadcast, and <xref target='RFC8138'/>.
   </t>
   <t>
   <!--In a 6TiSCH network, the routing dispatch frame is passed to the recommended encoding the
   RPL Packet Information.--> 6top sublayer for
               switching.
            </t>
            <t>
   Either way,
               At the method and format used egress 6TiSCH router, the reverse operation occurs. Based
               on tunneling information of the Track, which may for encoding instance
               indicate that the RPLInstanceID tunneled datagram is generalized an IP packet,
               the datagram is passed to all 6TiSCH topological Instances, which include
   both RPL Instances and Tracks. the appropriate link-layer with the
               destination MAC restored.
            </t>
         </section>
   <section anchor='pmhrre'><name>Replication, Retries and Elimination</name>
         <section><name>Tunneling Information</name>
            <t>
   6TiSCH supports
               Tunneling information coming with the PREOF operations of elimination and reordering Track configuration
               provides the destination MAC address
               of packets
   along a complex Track, but has no requirement about whether a sequence number
   is tagged in the packet for that purpose.
   With 6TiSCH, egress endpoint as well as the schedule can tell when multiple receive timeslots correspond
   to copies of tunnel mode and specific
               data depending on the mode,
               for instance, a same packet, in which case service access point for frame delivery at egress.
            </t>
            <t>
               If the receiver may avoid listening to tunnel egress point does not have a MAC address that
               matches the extra copies once it had received one instance of configuration, the packet. Track installation fails.
            </t>
            <t>
   The semantics of
               If the configuration will enable correlated timeslots Layer 3 destination address belongs to be
   grouped for transmit (and respectively receive) with a 'OR' relations,
   and
               the tunnel termination, then a 'AND' relation would be configurable between groups.
   The semantics it is possible that if the transmit (and respectively receive) operation
   succeeded in one timeslot in a 'OR' group, then all the other timeslots in IPv6 address
               of the group are ignored.
   Now, if there are destination is compressed at least two groups, the 'AND' relation between 6LoWPAN sublayer based on
               the groups
   indicates that one operation must succeed in each of MAC address. Restoring the groups.
   </t>
   <t>
   On wrong MAC address at the transmit side, timeslots provisioned for retries along a same branch
   of a Track are placed a same 'OR' group. The 'OR' relation indicates that if
   a transmission is acknowledged, egress
               would then retransmissions of that packet should
   not be attempted for remaining timeslots also result 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 wrong IP address in the
   groups indicates packet
               after decompression.
               For that transmission over any of branches must be attempted
   regardless of whether reason, a transmission succeeded packet can be injected in another branch. a Track only if
               the destination MAC address is effectively that of the tunnel
               egress point.
               It is also
   possible to place cells thus mandatory for the ingress router to different next-hop routers in a same 'OR' group.
   This allows validate that the
               MAC address used at the 6LoWPAN
               sublayer for compression matches that of the tunnel egress point
               before it overwrites it to route along multi-path Tracks, trying one next-hop and then
   another only if sending broadcast.

               The 6top sublayer at the tunnel egress point reverts that
               operation to the first fails. MAC address obtained from the tunnel
               information.
            </t>
         </section>
      </section>      <section><name>IPv6 Forwarding</name>
         <t>
   On
            As the receive side, all timeslots packets are programmed in a same 'OR' group.
   Retries of a same copy as well as converging branches for elimination routed at Layer 3, traditional QoS and Active
            Queue Management (AQM) operations are converged, meaning expected to prioritize flows.
         </t>
            <figure anchor="fig9"><name>IP Forwarding</name>
<artwork><![CDATA[
                       | 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
]]></artwork>
            </figure>
      </section>
      <section><name>Fragment Forwarding</name>
         <t>
            Considering that, per <xref target="RFC4944" section="4" sectionFormat="of" format="default"/>, 6LoWPAN
            packets can be as large as 1280 bytes (the IPv6 minimum MTU)
            and that the first successful reception is enough non-storing mode of RPL implies source routing, which requires space for routing
            headers, and that
   all an IEEE Std 802.15.4 frame with security may carry in the other timeslots can order of 80 bytes of
            effective payload, an IPv6 packet might be ignored. A 'AND' group denotes different
   packets fragmented into more than 16 fragments at the
            6LoWPAN sublayer.
         </t>
         <t>
            This level of fragmentation is much higher than that must all be received and transmitted traditionally experienced over the associated
   transmit groups within their respected 'AND' or 'OR' rules. Internet
            with IPv4 fragments, where fragmentation is already known as harmful.
         </t>
         <t>
   As an example say that we have
            In the case of a simple network as represented in
   <xref target='figANDORref'/>, multihop route within a 6TiSCH network, hop-by-hop recomposition occurs at each
            hop to reform the packet and we want route it. This creates additional latency and forces intermediate
            nodes to enable PREOF between store a portion of a packet for an ingress
   node I undetermined time, thus impacting critical resources such
            as memory and an egress node E. battery.
         </t>
   <figure align='center' anchor='figANDORref'><name>Scheduling PREOF on a Simple Network</name>
<artwork align='center'><![CDATA[
            +-+         +-+
         -- |A|  ------ |C| --
       /    +-+         +-+    \
     /                           \
+-+                                +-+
|I|                                |E|
+-+                                +-+
     \                           /
       \    +-+         +-+    /
         -- |B| ------- |D| --
            +-+         +-+
]]></artwork>
            </figure>
         <t>
   The assumption
            <xref target="RFC8930"/> describes a framework for this particular problem is
   that forwarding fragments end-to-end
            across a 6TiSCH node has route-over mesh.  Within that framework,
            <xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly"/> details a virtual reassembly
            buffer mechanism whereby the datagram tag in the 6LoWPAN fragment is used as a single radio, so it cannot perform 2 receive and/or
   transmit operations label
            for switching at the same time, even on 2 different channels. 6LoWPAN sublayer.
         </t>
         <t>
   Say we have 6 possible channels, and at least 10 timeslots per slotframe.
            Building on this technique, <xref target='figsc'/> shows target="RFC8931"/> introduces a possible schedule whereby each transmission
   is retried 2 or 3 times, and redundant copies are forwarded in parallel via
   A and C on new format for
            6LoWPAN fragments that enables the one hand, and B selective recovery of individual fragments
            and D allows for a degree of flow control based on the other, providing time diversity,
   spatial diversity though different physical paths, and frequency diversity. an Explicit Congestion Notification (ECN).
         </t>
            <figure anchor='figsc'><name>Example Global Schedule</name>
<artwork align='center'>
<![CDATA[
   slotOffset      0    1    2    3    4    5    6    7    9
                +----+----+----+----+----+----+----+----+----+
channelOffset 0 anchor="fig7"><name>Forwarding First Fragment</name>
<artwork><![CDATA[
                       | Packet flowing across the network  ^
   +--------------+    |                                    |
   |     IPv6     |    |    |B->D|       +----+          +----+       |
   +--------------+    | ...
                +----+----+----+----+----+----+----+----+----+
channelOffset 1       |    |I->A|    |A->C|B->D|    |          |    |       | ...
                +----+----+----+----+----+----+----+----+----+
channelOffset 2 |I->A|
   |    |I->B|    |C->E|    |D->E|  6LoWPAN HC  |    |       learn           learn        |
   +--------------+    |       |    |          |    |       |
   |     6top     |    |       |    |          |    |       |
   +--------------+    |       |    |          |    |       |
   |   TSCH MAC   |    |       |    |          |    |       |
   +--------------+    |       | ...
                +----+----+----+----+----+----+----+----+----+
channelOffset 3    |          |    |       |    |A->C|
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+
                     Source   Ingress          Egress   Destination
      Stack Layer     Node    Router           Router      Node
]]></artwork>
            </figure>
         <t>
            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.
         </t>
            <figure anchor="fig8"><name>Forwarding Next Fragment</name>
<artwork><![CDATA[
                       | Packet flowing across the network  ^
   +--------------+    |                                    |
   |     IPv6     | ...
                +----+----+----+----+----+----+----+----+----+
channelOffset 4    |                                    |    |I->B|
   +--------------+    |    |B->D|                                    |    |D->E| ...
                +----+----+----+----+----+----+----+----+----+
channelOffset 5
   |  6LoWPAN HC  |    |A->C|    |       replay          replay       |    |C->E|
   +--------------+    |       | ...
                +----+----+----+----+----+----+----+----+----+
]]>
</artwork>
            </figure>
<t>
   This translates in a different slotframe for every node that provides the
   waking and sleeping times, and the channelOffset to be used when awake.
   <xref target='figsfA'/> shows the corresponding slotframe for node A.
</t>

            <figure anchor='figsfA'><name>Example Slotframe for Node A</name>
<artwork align='center'>
<![CDATA[
   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     6top     | ...
                +----+----+----+----+----+----+----+----+----+
]]>
</artwork>
            </figure>
   <t>
   <!-- If, say, node A successfully transmits at slotOffset 2 then it may sleep at
   slotOffsets 3 and 4. -->
   The logical relationship between the timeslots is given
   by the following table:
   </t>

    <figure anchor='figslog' suppress-title='true'>
<artwork align='center'>
<![CDATA[
          +------+---------------------+------------------------+    | 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   TSCH MAC   |       (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   LLN PHY    |
          +------+---------------------+------------------------+
]]>
</artwork>
 </figure>

            <!--
        <texttable title="schedule" anchor="schedtable">
          <ttcol>Node</ttcol>
           <ttcol align="center"> rcv slotOffset</ttcol>
           <ttcol align="center"> xmit slotOffset</ttcol>
            <c>I</c>
                <c> N/A </c>
                <c> (0 OR 1) AND (2 OR 3) </c>
            <c>A</c>
                <c> (0 OR 1)</c>
                <c> (2 OR 3 OR 4) </c>
            <c>B</c>
                <c> (2 OR 3)  </c>
                <c> (4 OR 5 OR 6) </c>
            <c>C</c>
                <c> (2 OR 3 OR 4)</c>
                <c>  (5 OR 6) </c>
            <c>D</c>
                <c> (4 OR 5 OR 6) </c>
                <c> (7 OR 8) </c>
            <c>E</c>
                <c> (5 OR 6 OR 7 OR 8) </c>
                <c> N/A    </c>
        </texttable>
 -->    +-------+    +--...-----+    +-------+
   +--------------+
                     Source   Ingress          Egress   Destination
      Stack Layer     Node    Router           Router      Node
]]></artwork>
            </figure>
         <t>
            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.
         </t>
      </section>

   </section>
   <!--

      <section anchor="pmhds" title="Differentiated Services Per-Hop-Behavior"> -->
   <!-- anchor="rtg"><name>Advanced 6TiSCH Routing</name>
   <section anchor="pmh"><name>Packet Marking and Handling</name>

   <t> -->
   <!-- A future document could define
   All packets inside a PHB for Deterministic Flows, 6TiSCH domain must carry the RPLInstanceID that
   identifies the 6TiSCH topology (e.g., a Track) that is to be indicated -->
   <!-- used for
   routing and forwarding that packet.  The location of that information
   must be the same for all packets forwarded inside the domain.
   </t>
    <t>
   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 IANA registry where IETF-defined PHBs IPv6 header and 2) a local RPLInstanceID in the RPI that
   serves as TrackID, identify uniquely the Track and
   associated transmit bundle.
   </t>
   <t>
   For packets that are listed. -->
   <!-- routed by RPL, that information is the RPLInstanceID
   that is carried in the RPL Packet Information (RPI), as discussed in
   <xref target="RFC6550" section="11.2" sectionFormat="of" format="default"/>, "Loop Avoidance and Detection".
   The RPI is transported by a RPL Option in the IPv6 Hop-By-Hop Options header
   <xref target="RFC6553"/>.
   </t> -->
   <!-- </section> -->
   </section>
   </section>
   <section><name>IANA Considerations</name>
   <t>
         This document does not require IANA action.
   A compression mechanism for the RPL packet artifacts that integrates the
   compression of IP-in-IP encapsulation and the Routing Header type 3
   <xref target="RFC6554"/>
   with that of the RPI in a 6LoWPAN dispatch/header type is specified in
   <xref target="RFC8025"/> and <xref target="RFC8138"/>.
   </t>
   </section>

   <section anchor='sec'><name>Security Considerations</name>
   <t>
   The <xref target='I-D.ietf-6tisch-minimal-security'>"Minimal Security
   Framework for 6TiSCH"</xref> was optimized for Low-Power
   Either way, the method and TSCH operations.
   The reader format used for encoding the RPLInstanceID
   is encouraged generalized to review the Security Considerations section of
   that document, which discusses all 6TiSCH security issues in more details. topological Instances, which include
   both RPL Instances and Tracks.
   </t>

   </section>
   <section anchor='det'><name>Availability of Remote Services</name> anchor="pmhrre"><name>Replication, Retries, and Elimination</name>

   <t>
    The operation of
   6TiSCH Tracks inherits its high level operation from DetNet
    and is subject to supports the observations in section 5 PREOF operations of
    <xref target='RFC8655'/>.  The installation elimination and the
    maintenance of the 6TiSCH Tracks depends on the availability reordering of packets
   along a controller
    with complex Track, but has no requirement about tagging a PCE to compute and push them sequence number
   in the network. When packet for that connectivity
    is lost, existing Tracks may continue to operate until purpose.
   With 6TiSCH, the end schedule can tell when multiple receive timeslots correspond
   to copies of their
    lifetime, but cannot be removed or updated, and new Tracks cannot be
    installed.
    </t>
    <t>
    In a LLN, same packet, in which case the communication with a remote PCE receiver may be slow and unreactive avoid listening to
    rapid changes in
   the condition extra copies once it has received one instance of the wireless communication. An attacker
    may introduce extra delay by selectively jamming some packets or some flows. packet.
   </t>
   <t>
   The expectation is that semantics of the 6TiSCH Tracks configuration enable enough redundancy correlated timeslots to
    maintain 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 critical traffic transmit (and receive, respectively) operation
   succeeded in one timeslot in operation while new routes are calculated
    and programmed into an 'OR' group, then all the network.
    </t>
    <t>
    As with DetNet other timeslots in general,
   the communication with group are ignored.
   Now, if there are at least two groups, the PCE must be secured
    and should be protected against DoS attacks, including delay injection and
    blackholing attacks, and secured as discussed in 'AND' relation between the security considerations
    defined for Abstraction and Control of Traffic Engineered Networks (ACTN) groups
   indicates that one operation must succeed in
    Section 9 each of <xref target='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. groups.
   </t>

    </section>

   <section anchor='phy'><name>Selective Jamming</name>
   <t>
    The Hopping Sequence
   On the transmit side, timeslots provisioned for retries along a same branch
   of a TSCH network is well-known, meaning Track are placed in the same 'OR' group. The 'OR' relation indicates that if
   a
    rogue manages to identify a cell of a particular flow, transmission is acknowledged, then it may
    to selectively jam retransmissions of that cell, without impacting any other traffic.
    This attack can packet should
   not be performed at attempted for the PHY layer without any knowledge remaining timeslots in that group. There are as many
   'OR' groups as there are branches of the
    Layer-2 keys, and is very hard to detect and diagnose because only one flow
    is impacted.
    </t>
    <t>
    <xref target='I-D.tiloca-6tisch-robust-scheduling'/> proposes
    a method to obfuscate the hopping sequence and make it harder to perpetrate
    that particular attack.

    </t>

    </section>
   <section anchor='iee'><name>MAC-Layer Security</name>
      <t>
    This architecture operates on IEEE Std. 802.15.4 and expects Track departing from this node.
   Different 'OR' groups are programmed for the Link-Layer
    security purpose of replication, each
   group corresponding to be enabled at all times one branch of the Track. The 'AND' relation between connected devices, except for the very first step
   groups indicates that transmission over any of the device join process, where branches must be attempted
   regardless of whether a joining device may
    need some initial, unsecured exchanges so as transmission succeeded in another branch. It is also
   possible to obtain its initial key
    material. In a typical deployment, all joined nodes use place cells to different next-hop routers in the same keys 'OR' group.
   This allows routing along multipath Tracks, trying one next hop and
    rekeying needs then
   another only if sending to be global. the first fails.
   </t>
   <t>
    The 6TISCH Architecture relies on
   On the join process to deny authorization of
    invalid nodes and preserve receive side, all timeslots are programmed in the integrity same 'OR' group.
   Retries of the network keys. A rogue same copy as well as converging branches for elimination
   are converged, meaning that
    managed to access the network first successful reception is enough and that
   all the other timeslots can perform a large variety of attacks from
    DoS to injecting forged be ignored. An 'AND' group denotes different
   packets and routing information.
    "Zero-trust" properties would that must all be highly desirable but are mostly not
    available at received and transmitted over the time of associated
   transmit groups within their respected 'AND' or 'OR' rules.
   </t>
   <t>
   As an example, say that we have a simple network as represented in
   <xref target="figANDORref"/>, and we want to enable PREOF between an ingress
   node I and an egress node E.
   </t>
   <figure align="center" anchor="figANDORref"><name>Scheduling PREOF on a Simple Network</name>
<artwork align="center"><![CDATA[
            +-+         +-+
         -- |A|  ------ |C| --
       /    +-+         +-+    \
     /                           \
+-+                                +-+
|I|                                |E|
+-+                                +-+
     \                           /
       \    +-+         +-+    /
         -- |B| ------- |D| --
            +-+         +-+
]]></artwork>
            </figure>

<t>
   The assumption for this writing. <xref target='I-D.ietf-6lo-ap-nd'/> particular problem is a notable exception
   that protects the ownership of IPv6 addresses and
    prevents a rogue 6TiSCH node with L2 access from stealing and injecting traffic
    on behalf of has a legitimate node. single radio, so it cannot perform two receive and/or
   transmit operations at the same time, even on two different channels.
</t>

      <!--
<t>
    The join protocol can be zero-touch
   Say we have six possible channels, and leverage ANIMA procedures, as
    detailed in the at least ten timeslots per slotframe.
   <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join">
    6tisch Zero-Touch Secure Join protocol</xref>.
      </t>
      <t>
    Alternatively, the join protocol can be one-touch, in which case the pledge
    is provisioned with target="figsc"/> shows a preshared key (PSK), possible schedule whereby each transmission
   is retried two or three times, and uses CoJP as specified redundant copies are forwarded in
    <xref target="I-D.ietf-6tisch-minimal-security"/>. 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.
</t>
      -->
    </section>
   <section anchor='ts'><name>Time Synchronization</name>
            <figure anchor="figsc"><name>Example Global Schedule</name>
<artwork align="center"><![CDATA[
   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|    |    | ...
                +----+----+----+----+----+----+----+----+----+
]]></artwork>
            </figure>
<t>
    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
   This translates into a pledge
    outside of the guard time of the legitimate nodes then different slotframe that provides the pledge will never
    see a legitimate beacon
   waking and sleeping times for every node, and may not discover the attack.
    </t>
    <t>As discussed in <xref target='RFC8655'/>, measures
    must be taken channelOffset to protect be used when awake.
   <xref target="figsfA"/> shows the time synchronization, and corresponding slotframe 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 A.
</t>

            <figure anchor="figsfA"><name>Example Slotframe for Node A</name>
<artwork align="center"><![CDATA[
   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 | ...
                +----+----+----+----+----+----+----+----+----+
]]></artwork>
            </figure>
   <t>
   The logical relationship between the network, ASN timeslots is implicit in the transmissions. given
   by <xref target="figslog"/>:
   </t>
<table anchor="figslog">
	<thead>
	<tr>
		<th align="center">Node</th>
		<th align="center">rcv slotOffset</th>
		<th align="center">xmit slotOffset</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td align="center">I</td>
		<td align="center">N/A</td>
		<td align="center">(0 OR 1) AND (2 OR 3)</td>
	</tr>
	<tr>
		<td align="center">A</td>
		<td align="center">(0 OR 1)</td>
		<td align="center">(2 OR 3 OR 4)</td>
	</tr>
	<tr>
		<td align="center">B</td>
		<td align="center">(2 OR 3)</td>
		<td align="center">(4 OR 5 OR 6)</td>
	</tr>
	<tr>
		<td align="center">C</td>
		<td align="center">(2 OR 3 OR 4)</td>
		<td align="center">(5 OR 6)</td>
	</tr>
	<tr>
		<td align="center">D</td>
		<td align="center">(4 OR 5 OR 6)</td>
		<td align="center">(7 OR 8)</td>
	</tr>
	<tr>
		<td align="center">E</td>
		<td align="center">(5 OR 6 OR 7 OR 8)</td>
		<td align="center">N/A</td>
	</tr>
	</tbody>
</table>
     </section>
   </section>
   </section>
   <section><name>IANA Considerations</name>
      <t>
      This document has no IANA actions.
      </t>
   </section>

   <section anchor="sec"><name>Security Considerations</name>

   <t>
   The <xref target='IEEE802154'>IEEE Std. 802.15.4</xref> specifies that in a target="RFC9031">"Minimal Security
   Framework for 6TiSCH"</xref> was optimized for Low-Power and TSCH
    network, the nonce that operations.
   The reader is used for the computation of the Message Integrity
    Code (MIC) encouraged to secure Link-Layer frames is composed of the address
    of the source of review the frame and Security Considerations section of the ASN. The standard assumes
   that the ASN
    is distributed securely by other means. The ASN is not passed explicitly document (Section <xref target="RFC9031" sectionFormat="bare" section="9"/>),
   which discusses 6TiSCH security issues in
    the data frames and does not constitute a complete anti-replay protection.
    It results that upper layer protocols must provide a way to detect
    duplicates and cope with them. more details.
    </t>

   <section anchor="det"><name>Availability of Remote Services</name>

    <t>
    If
    The operation of 6TiSCH Tracks inherits its high-level operation from DetNet
    and is subject to the receiver observations in
    <xref target="RFC8655" section="5" sectionFormat="of" format="default"/>.  The installation and the sender have a different sense
    maintenance of ASN, the MIC will
    not validate and 6TiSCH Tracks depend on the frame will be dropped. In that sense, TSCH induces an
    event horizon whereby only nodes that have a common sense availability of ASN can talk to
    one another in an authenticated manner. With 6TiSCH, the pledge discovers a
    tentative ASN controller
    with a PCE to compute and push them in beacons from nodes that have already joined the network.
    But even if the beacon can be authenticated, When that connectivity
    is lost, existing Tracks may continue to operate until the ASN end of their
    lifetime, but cannot be trusted as it
    could be a replay by an attacker removed or updated, and thus could announce new Tracks cannot be
    installed.
    </t>
    <t>
    In an ASN that
    represents LLN, the communication with a time remote PCE may be slow and unreactive to
    rapid changes in the  past. If condition of the pledge uses an ASN that wireless communication. An attacker
    may introduce extra delay by selectively jamming some packets or some flows.
    The expectation is learned
    from a replayed beacon for an encrypted transmission, a nonce-reuse attack
    becomes possible that the 6TiSCH Tracks enable enough redundancy to
    maintain the critical traffic in operation while new routes are calculated
    and programmed into the network keys may be compromised. network.
    </t>
    </section>

   <section anchor='asv'><name>Validating ASN</name>
    <t>
    After obtaining
    As with DetNet in general, the tentative ASN, a pledge that wishes to join communication with the
    6TiSCH network PCE must use a join protocol to obtain its security keys.
    The join protocol used be secured
    and should be protected against DoS attacks, including delay injection and
    blackholing attacks, and secured as discussed in 6TiSCH is the Constrained Join Protocol (CoJP).
    In the minimal setting security considerations
    defined for Abstraction and Control of Traffic Engineered Networks (ACTN) in
    <xref target='I-D.ietf-6tisch-minimal-security'/>, the authentication
    requires a pre-shared key, based on target="RFC8453" section="9" sectionFormat="of" format="default"/>, which applies equally to DetNet and
    6TiSCH. In a secure session is derived.
    The CoJP exchange may also be preceded similar manner, the communication with a zero-touch handshake
    <xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> in order
    to enable pledge joining based on certificates and/or inter-domain
    communication. the JRC must
    be secured and should be protected against DoS attacks when possible.
    </t>

    </section>

   <section anchor="phy"><name>Selective Jamming</name>
        <t>
    As detailed in <xref target='rflo'/>,
    The hopping sequence of a Join Proxy (JP) helps the pledge for the join procedure by relaying the
    link-scope Join Request over the IP TSCH network is well known, meaning that if a
    rogue manages to identify a Join Registrar/Coordinator
    (JRC) cell of a particular flow, then it may
    selectively jam that cell without impacting any other traffic.
    This attack can authenticate be performed at the pledge PHY layer without any knowledge of the
    Layer 2 keys, and validate that it is attached very hard to
    the appropriate network. As a result of the CoJP exchange, the pledge is in
    possession of a Link-Layer material including keys and a short address, detect and
    if the ASN diagnose because only one flow
    is known to be correct, all traffic can now be secured using CCM*
    <xref target='CCMstar'/> at the Link-Layer. impacted.
    </t>
    <t>
    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
    <xref target="I-D.tiloca-6tisch-robust-scheduling"/> proposes
    a method to use in obfuscate the network, hopping sequence and make it may still need harder to verify the ASN.
    If the nonce used in perpetrate
    that particular attack.

    </t>

    </section>
   <section anchor="iee"><name>MAC-Layer Security</name>
      <t>
    This architecture operates on IEEE Std 802.15.4 and expects the Layer-2 link-layer
    security derives from the extended (MAC-64)
    address, then replaying to be enabled at all times between connected devices, except for
    the ASN alone cannot enable a nonce-reuse attack
    unless very first step of the same node is lost its state with device join process, where 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 joining device may
    need some initial, unsecured exchanges so as to this or other obtain its initial key
    material. In a typical deployment, all joined nodes with use the same keys. In other words, the network
    must keys, and
    rekeying needs to be rekeyed before the JRC runs out of short addresses. global.
    </t>
        <!--t>
    Once the node obtains the keys from
    <t>
    The 6TISCH architecture relies on the JRC, an additional step may be
    required join process to ensure that deny authorization of
    invalid nodes and to preserve the ASN is correct before encrypting any message.
    If integrity of the ASN is not guaranteed network keys. A rogue that
    managed to be correct by other means, access the pledge should network can perform a non-replayable exchange (e.g., using a nonce in the payload that
    does not derive large variety of attacks from ASN) with a peer node that is trusted
    DoS to injecting forged packets and has already
    joined (e.g., the JP or a RPL time parent). The request by the pledge should
    not routing information.
    "Zero-trust" properties would be encrypted highly desirable but are mostly not
    available at the Link-Layer but only authenticated to avoid
    nonce-replay attacks. A successful authenticated exchange proves a common
    sense of ASN and encrypted traffic can now happen.
    </t-->
    </section>

   <section anchor='keying'><name>Network Keying and Rekeying</name>

    <t>
      <xref target='rflo'/> provides an overview time of the CoJP process described in
      <xref target='I-D.ietf-6tisch-minimal-security'/> by which an LLN
      can be assembled in the field, having been provisioned in a lab. this writing. <xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> target="RFC8928"/>
    is future
      work a notable exception that preceeds and then leverages the CoJP protocol using protects the
      <xref target='I-D.ietf-anima-constrained-voucher'/> constrained profile ownership of <xref target='I-D.ietf-anima-bootstrapping-keyinfra'/> (BRSKI).
      This later work requires IPv6 addresses and
    prevents a yet-to-be standardized Lighweight Authenticated
      Key Exchange protocol. rogue node with L2 access from stealing and injecting traffic
    on behalf of a legitimate node.
    </t>
    </section>
   <section anchor="ts"><name>Time Synchronization</name>
    <t>
      The CoJP protocol results
    Time synchronization in distribution of TSCH induces another event horizon whereby a network-wide key that
      is to be used node
    will only communicate with <xref target='IEEE802154'/> security. The details of use another node if they are
      described in <xref target='I-D.ietf-6tisch-minimal-security'/> sections
      9.2 and 9.3.2.
    </t>
    <t> synchronized within a
    guard time. The BRSKI mechanism may lead to pledge discovers the use synchronization of the CoJP protocol, in which case
      it also results in distribution network based
    on the time of reception of the beacon. If an attacker synchronizes a network-wide key.  Alternatively pledge
    outside of the BRSKI mechanism may be followed by use guard time of the legitimate nodes, then the pledge will never
    see a legitimate beacon and may not discover the attack.
    </t>
    <t>As discussed in <xref target='I-D.ietf-ace-coap-est'/> target="RFC8655"/>, measures
    must be taken to enroll certificates protect the time synchronization, and for each device.  In 6TiSCH this
    includes ensuring that case, the certificates
      may be used with an <xref target='IEEE802154'/> key agreement protocol.  The
      description Absolute Slot Number (ASN), which is the node's
    sense of this mechanism, while conceptually straight forward still
      has significant standardization hurdles time, is not compromised. Once installed and as long as the node is
    synchronized to pass. the network, ASN is implicit in the transmissions.
    </t>
     <t>
    <xref target='I-D.ietf-6tisch-minimal-security'/> section 9.2 describes target="IEEE802154">IEEE Std 802.15.4</xref> specifies that in a mechanism to change (rekey) TSCH
    network, the network.
      There are a number nonce that is used for the computation of reasons to initiate a network rekey: to remove
      unwanted (corrupt/malicious) nodes, to recover unused 2-byte short
      addresses, or due the Message Integrity
    Code (MIC) to limits in encryption algorithms.
      For all secure link-layer frames is composed of the mechanisms address
    of the source of the frame and of the ASN. The standard assumes that distribute a network-wide key, rekeying the ASN
    is also needed on a periodic basis. In more details:
    </t>
    <t></t><ul spacing='normal'>
    <li> distributed securely by other means. The mechanism described ASN is not passed explicitly in
      <xref target='I-D.ietf-6tisch-minimal-security'/> section 9.2 requires
      advance communication between
    the JRC data frames and every one of 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.
    </t>

     <t>
    If the nodes before receiver and the key change.  Given that many nodes may be sleepy, this operation
      may take sender have a significant amount different sense of time, ASN, the MIC will
    not validate and may consume the frame will be dropped. In that sense, TSCH induces an
    event horizon whereby only nodes that have a significant
      portion common sense of ASN can talk to
    one another in an authenticated manner. With 6TiSCH, the available bandwidth.  As such, network-wide rekeys pledge discovers a
    tentative ASN in
      order to exclude beacons from 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 to just
      continue the operation.  If joined the unwanted node has already received network.
    But even if the
      update, then beacon can be authenticated, the rekey operation will need to ASN cannot be restarted.
    </li>
    <li>
      The cryptographic mechanisms used trusted as it
    could be a replay by IEEE Std. 802.15.4 include the 2-byte
      short address an attacker, announcing an ASN that
    represents a time in the calculation of  past. If the context.
      A 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 become feasible if be compromised.
    </t>
    </section>

   <section anchor="asv"><name>Validating ASN</name>

    <t>
    After obtaining the tentative ASN, a short address is reassigned pledge that wishes to another node while join the  same network-wide keys are in operation.
      A
    6TiSCH network that gains and loses nodes on must use a regular
      basis is likely join protocol to reach obtain its security keys.
    The join protocol used in 6TiSCH is the 65536 limit of Constrained Join Protocol (CoJP).
    In the 2-byte (16-bit) short
      addresses, even if minimal setting defined in
    <xref target="RFC9031"/>, the network has only authentication
    requires a few thousand nodes. Network
      planners should consider the need to rekey the network pre-shared key, based on which a periodic
      basis secure session is derived.
    The CoJP exchange may also be preceded by a zero-touch handshake
    <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> in order
    to recover 2-byte addresses.  The rekey can update enable pledge joining based on certificates and/or inter-domain
    communication.
      </t>
    <t>
    As detailed in <xref target="rflo"/>,
    a Join Proxy (JP) helps the
      short addresses for active nodes if desired, but there is actually no
      need to do this as long as pledge with the key has been changed.
    </li>
    <li>
      With TSCH as it stands at join procedure by relaying the time of this writing,
    link-scope Join Request over the ASN will wrap
      after 2^40 timeslot durations, which means with IP network to a Join Registrar/Coordinator
    (JRC) that can authenticate the default values around
      350 years. Wrapping ASN pledge and validate that it is not expected attached to happen within
    the lifetime appropriate network. As a result of the CoJP exchange, the pledge is in
    possession of
      most LLNs. Yet, should link-layer material including keys and a short address, and
    if the ASN wrap, is known to be correct, all traffic can now be secured using CCM*
    <xref target="CCMstar"/> at the network link layer.
    </t>
    <t>
    The authentication steps must be rekeyed to avoid
      a nonce-reuse attack.
    </li>
    <li>
      Many cipher algorithms have some suggested limits on how many bytes
      should such that they cannot be encrypted with replayed by an
    attacker, and they must not depend on the tentative ASN being valid.
    During the authentication, the keying material that algorithm before a new key is used.
      These numbers are typically in the many pledge obtains from
    the JRC does not provide protection against spoofed ASN. Once the pledge has
    obtained the keys to hundreds of gigabytes of
      data.  On very fast backbone networks this becomes an important
      concern. On LLNs with typical data rates use in the kilobits/second,
      this concern is significantly less. With IEEE Std. 802.15.4 as network, it stands
      at may still need to verify the time of this writing, ASN.
    If the nonce used in the Layer 2 security derives from the extended (MAC-64)
    address, then replaying the ASN will wrap before alone cannot enable a nonce-reuse attack
    unless the limits of same node has lost its state with a previous ASN. But
    if the
      current L2 crypto (AES-CCM-128) are reached, so nonce derives from the problem should short address (e.g., assigned by the JRC), then
    the JRC must ensure that it never
      occur.
    </li>
    <li>
      In any fashion, if assigns short addresses that were already
    given to this or other nodes with the LLN is expected to operate continuously for decades
      then same keys. In other words, the operators are advised to plan for network
    must be rekeyed before the need to rekey.
    </li>
    </ul><t> JRC runs out of short addresses.
    </t>
    </section>

   <section anchor="keying"><name>Network Keying and Rekeying</name>

    <t>
      Except for urgent rekeys caused by malicious nodes,
      <xref target="rflo"/> provides an overview of the rekey operation CoJP process described in
      <xref target='I-D.ietf-6tisch-minimal-security'/>
      can be done as a background task and target="RFC9031"/> by which an LLN
      can be done incrementally.  It
      is a make-before-break mechanism.  The switch over to assembled in the new key field, having been provisioned in a lab.
      <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> is
      not signaled by time, but rather by observation future
      work that precedes and then leverages CoJP using the new
      <xref target="I-D.ietf-anima-constrained-voucher"/> constrained profile
      of <xref target="RFC8995"/>.
      This later work requires a yet-to-be standardized Lightweight Authenticated
      Key Exchange protocol.
    </t>
    <t>
      CoJP results in distribution of a network-wide key that
      is to be used with <xref target="IEEE802154"/> security. The details of use are
      described in
      use.  As such, <xref target="RFC9031"/>, Sections <xref target="RFC9031" section="9.2" sectionFormat="bare" format="default"/>
      and <xref target="RFC9031" section="9.3.2" sectionFormat="bare" format="default"/>.
    </t>
    <t>
      The BRSKI mechanism may lead to the update can take as long as needed, or occur use of CoJP, in as
      short which case
      it also results in distribution of a time as practical.
    </t>

  </section>
</section>
   <section><name>Acknowledgments</name>
   <section><name>Contributors</name>
   <t>The co-authors network-wide key.  Alternatively
      the BRSKI mechanism may be followed by use of <xref target="I-D.ietf-ace-coap-est"/>
      to enroll certificates for each device.  In that case, the certificates
      may be used with an <xref target="IEEE802154"/> key agreement protocol.  The
      description of this document mechanism, while conceptually straightforward, still
      has significant standardization hurdles to pass.
    </t>
    <t>

      <xref target="RFC9031" section="8.2" sectionFormat="of" format="default"/> describes
      a mechanism to change (rekey) the network.
      There are listed below:
      </t><dl  spacing='normal'>
       <dt>Thomas Watteyne</dt><dd>
          for his contribution a number of reasons to the whole design, in particular on TSCH and security,
          and 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 open source community with openWSN mechanisms that he created.
      </dd>
         <dt>Xavier Vilajosana</dt><dd>
          who lead the design of distribute a network-wide key, rekeying
      is also needed on a periodic basis. In more detail:
    </t>
    <ul spacing="normal">
    <li>
      The mechanism described in
      <xref target="RFC9031" section="8.2" sectionFormat="of" format="default"/> requires
      advance communication between the minimal support with RPL JRC and contributed
          deeply to every one of the 6top design and nodes before
      the G-MPLS key change.  Given that many nodes may be sleepy, this operation
      may take a significant amount of Track switching;
      </dd>
         <dt>Kris Pister</dt><dd>
         for creating TSCH time and his continuing guidance through the elaboration may consume a significant
      portion of this design;
      </dd>
         <dt>Malisa Vucinic</dt><dd>
         for the work on the one-touch join process and his contribution available bandwidth.  As such, network-wide rekeys
      to the
         Security Design Team;
      </dd>
         <dt>Michael Richardson</dt><dd>
         for his leadership role exclude nodes that have become malicious will not be
      particularly quick.  If a rekey is already in progress, but the Security Design Team and his
         contribution throughout this document;
      </dd>
         <dt>Tero Kivinen</dt><dd>
          for his contribution
      unwanted node has not yet been updated, then it is possible to just
      continue the security work in general and operation.  If the security
          section in particular.
      </dd>
         <dt>Maria Rita Palattella</dt><dd>
         for managing unwanted node has already received the Terminology document merged into this through
      update, then the work rekey operation will need to be restarted.
    </li>
    <li>
      The cryptographic mechanisms used by IEEE Std 802.15.4 include the 2-byte
      short address in the calculation of 6TiSCH;
      </dd>
         <dt>Simon Duquennoy</dt><dd>
          for his contribution the context.
      A nonce-reuse attack may become feasible if a short address is reassigned
      to another node while the open source community with the 6TiSCH
          implementaton of contiki,  same network-wide keys are in operation.
      A network that gains and for his contribution loses nodes on a regular
      basis is likely to MSF and
          autonomous unicast cells.
      </dd>
         <dt>Qin Wang</dt><dd>
          who lead reach the design 65536 limit of the 6top sublayer and contributed related text
          that was moved and/or adapted in this document;
      </dd>
         <dt>Rene Struik</dt><dd>
         for 2-byte (16-bit) short
      addresses, even if the security section and his contribution to network has only a few thousand nodes. Network
      planners should consider the Security Design
         Team;
      </dd>
         <dt>Robert Assimiti</dt><dd>
          for his breakthrough work on RPL over TSCH and initial text and
          guidance;
      </dd>
        </dl><t>
      </t>
   </section>
   <section><name>Special Thanks</name><t>
      Special thanks to Jonathan Simon, Giuseppe Piro, Subir Das
      and Yoshihiro Ohba for their deep contribution need to rekey the initial security
      work, to Yasuyuki Tanaka for his work network 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 periodic
      basis in the MSF.
      </t><t>
      Special thanks also order to Pat Kinney, Charlie Perkins and Bob Heile for their
      support in maintaining recover 2-byte addresses.  The rekey can update the connection
      short addresses for active and nodes if desired, but there is actually no
      need to do this as long as the design in line with
      work happening key has been changed.
    </li>
    <li>
      With TSCH as it stands at IEEE 802.15.
      </t>  <t>
      Special thanks to Ted Lemon who was the INT Area A-D while this
      document was initiated for his great support and help throughout,
      and to Suresh Krishnan who took over with that kind efficiency time of his till
      publication.
      </t><t>
      Also special thanks 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 Ralph Droms who performed happen within the first INT Area
      Directorate review, lifetime of
      most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid
      a nonce-reuse attack.
    </li>
    <li>
      Many cipher algorithms have some suggested limits on how many bytes
      should be encrypted with that was very deep and thorough and radically changed algorithm before a new key is used.
      These numbers are typically in the orientations of this document, and then many to Eliot Lear and Carlos
      Pignataro who help finalize hundreds of gigabytes of
      data.  On very fast backbone networks, this document becomes an important
      concern. On LLNs with typical data rates in preparation to the IESG
      reviews, and to Gorry Fairhurst, David Mandelberg, Qin Wu, Francis Dupont,
      Eric Vyncke, Mirja Kuhlewind, Roman Danyliw, Benjamin Kaduk
      and Andrew Malis, who contributed to kilobits/second,
      this concern is significantly less. With IEEE Std 802.15.4 as it stands
      at the final shaping time of this document
      through writing, the IESG review procedure.
      </t>
   </section>
   <section><name>And Do not Forget</name>
      <t>This document is ASN will wrap before the result limits of multiple interactions, in
      particular during the 6TiSCH (bi)Weekly Interim call, relayed through
      current L2 crypto (AES-CCM-128) are reached, so the 6TiSCH mailing list at problem should never
      occur.
    </li>
    <li>
      In any fashion, if the IETF, LLN is expected to operate continuously for decades,
      then the operators are advised to plan for the need to rekey.
    </li>
    </ul>
    <t>
      Except for urgent rekeys caused by malicious nodes, the rekey operation
      described in <xref target="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 course of more than 5 years.
      </t><t>
      The authors wish to thank update can take as long as needed, or occur in arbitrary order:
      Alaeddine Weslati, Chonggang Wang, Georgios Exarchakos, Zhuo Chen,
      Georgios Papadopoulos, Eric Levy-Abegnoli,
      Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Deji Chen, Martin Turon,
      Dominique Barthel, Elvis Vogli, Geraldine Texier,
      Guillaume Gaillard, Herman Storey, Kazushi Muraoka, Ken Bannister,
      Kuor Hsin Chang, Laurent Toutain, Maik Seewald,
      Michael Behringer, Nancy Cam Winget, Nicola Accettura, Nicolas Montavont,
      Oleg Hahm, Patrick Wetterwald, Paul Duffy, Peter van der Stock, Rahul Sen,
      Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin-Lopez,
      Raghuram Sudhaakar, Sedat Gormus, Shitanshu Shah, Steve Simlo,
      Tina Tsou, Tom Phinney, Xavier Lagrange, Ines Robles and
      Samita Chakrabarti for their participation and various contributions. as
      short a time as practical.
    </t>

  </section>
</section>
</middle>

<back>
<displayreference   target="I-D.ietf-6tisch-minimal-security"           to="MIN-SECURITY"/> target="I-D.ietf-roll-rpl-industrial-applicability" to="RPL-APPLICABILITY"/>
<displayreference target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" to="ZEROTOUCH-JOIN"/>
<displayreference target="I-D.ietf-manet-aodvv2" to="AODVv2"/>
<displayreference target="I-D.ietf-roll-aodv-rpl" to="AODV-RPL"/>
<displayreference   target="I-D.ietf-6lo-backbone-router"           to="6BBR-DRAFT"/> target="I-D.ietf-lwig-6lowpan-virtual-reassembly" to="VIRTUAL-REASSEMBLY"/>
<displayreference   target="I-D.ietf-6lo-fragment-recovery"           to="RECOV-FRAG"/> target="I-D.ietf-roll-dao-projection" to="DAO-PROJECTION"/>
<displayreference   target="I-D.ietf-6lo-minimal-fragment"           to="MIN-FRAG"/> target="I-D.ietf-roll-capabilities" to="RPL-MOP"/>
<displayreference   target="I-D.ietf-6lo-ap-nd"           to="AP-ND"/> target="I-D.selander-ace-cose-ecdhe" to="EDHOC"/>
<displayreference   target="I-D.ietf-roll-useofrplinfo"           to="USEofRPLinfo"/> target="I-D.thubert-roll-bier" to="RPL-BIER"/>
<displayreference   target="I-D.ietf-roll-unaware-leaves"           to="RUL-DRAFT"/> target="I-D.thubert-bier-replication-elimination" to="TE-PREF"/>
<displayreference   target="I-D.ietf-6tisch-enrollment-enhanced-beacon"           to="ENH-BEACON"/> target="I-D.thubert-6lo-bier-dispatch" to="BITSTRINGS-6LORH"/>
<displayreference   target="I-D.ietf-6tisch-msf"           to="MSF"/>
   <references><name>Normative target="I-D.thubert-6man-unicast-lookup" to="ND-UNICAST-LOOKUP"/>
<displayreference target="I-D.pthubert-raw-architecture" to="RAW-ARCHITECTURE"/>
<displayreference target="I-D.tiloca-6tisch-robust-scheduling" to="ROBUST-SCHEDULING"/>
<displayreference target="I-D.ietf-ace-coap-est" to="EST-COAPS"/>
<displayreference target="I-D.ietf-anima-constrained-voucher" to="CONSTRAINED-VOUCHER"/>
<displayreference target="I-D.ietf-raw-use-cases" to="RAW-USE-CASES"/>
<references>
  <name>References</name>
   <references>
    <name>Normative References</name>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification -->
      <!-- <?rfc include="reference.RFC.2119"?> Key words for use in RFCs to Indicate Requirement Levels -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml'/> <!-- neighbor Discovery for IP version 6 (IPv6) -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml'/> <!-- IPv6 Stateless Address Autoconfiguration -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml'/> <!-- 6LoWPAN -->

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml'/> <!-- Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml'/> <!-- RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml'/> <!-- Routing Metrics Used for Path Calculation in LLNs -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6552.xml'/> <!-- RPL OF0: Objective Function Zero for RPL-->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml'/> <!-- RPL Option for Carrying RPL Information in Data-Plane Datagrams -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml'/> <!-- An IPv6 Routing Header for Source Routes with RPL --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml'/> <!-- neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml'/> <!-- CoAP --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml'/> <!-- 6LoRH coding dispatch--> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8137.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8138.xml'/> <!-- 6LoRH routing dispatch-->
       <!-- <?rfc include='reference.RFC.8174'?> Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words--> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8180.xml'/> <!-- 6TiSCH minimal --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6552.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8480.xml'/> <!-- 6top protocol --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml'/> <!-- ACTN --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml'/> <!-- RFC6775 update --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml'/> <!-- Terms Used in Routing for Low-Power and Lossy Networks --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7554.xml'/> <!-- 6TiSCH TSCH --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml'/> <!-- Terminology for Constrained-Node Networks --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8137.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5889.xml'/> <!-- IP Addressing Model in Ad Hoc Networks --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8138.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml'/> <!-- DetNet Architecture --> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8180.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-minimal-security.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-backbone-router.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8480.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-fragment-recovery.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-minimal-fragment.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-ap-nd.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-useofrplinfo.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7554.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-unaware-leaves.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-enrollment-enhanced-beacon.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5889.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-msf.xml'/>

   </references>
   <references><name>Informative References</name>

       <!-- <?rfc include="reference.RFC.6620"?> FCFS SAVI: First-Come, First-Served Source Address Validation -->
      <!--?rfc include="reference.RFC.6655"?--> <!--  AES-CCM Cipher Suites for Transport Layer Security (TLS) -->
      <!--?rfc include="reference.RFC.5191"?--> <!-- href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>

<reference anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9031">
  <front>
    <title>Constrained Join Protocol (CoJP) for Carrying Authentication for Network Access (PANA) -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml'/> <!-- OSPF for IPv6 -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml'/> <!-- Mobility Support in IPv6 --> 6TiSCH</title>
    <author initials="M" surname="Vučinić" fullname=" Mališa Vučinić" role="editor">
      <organization/>
    </author>
    <author initials="J" surname="Simon" fullname="Jonathan Simon">
     <organization/>
    </author>
    <author initials="K" surname="Pister" fullname="Kris Pister">
     <organization/>
    </author>
    <author initials="M" surname="Richardson" fullname="Michael Richardson">
     <organization/>
    </author>
    <date month="May" year="2021"/>
  </front>
  <seriesInfo name="RFC" value="9031"/>
  <seriesInfo name="DOI" value="10.17487/RFC9031"/>
</reference>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml'/> <!-- Differentiated Services Field --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml'/> <!-- BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8931.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3963.xml'/> <!-- Network Mobility (NEMO) -->
      <!-- <?rfc include="reference.RFC.3972"?>  CGA --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8930.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml'/> <!-- RSVP TE -->
      <!-- <?rfc include="reference.RFC.3971"?> SEcure Neighbor Discovery (SEND) --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml'/> <!-- IP Version 6 Addressing Architecture -->
       <!-- <?rfc include="reference.RFC.4429"?> IP Version 6 Optimistic DAD --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3444.xml'/> <!-- On the Difference between Information Models and Data Models -->
      <!-- <?rfc include="reference.RFC.3610"?>  Counter with CBC-MAC (CCM)  -->
      <!-- href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"/>

<reference anchor="RFC9032" target="https://www.rfc-editor.org/info/rfc9032">
  <front>
    <title>Encapsulation of 6TiSCH -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4080.xml'/> <!-- Next Steps in Signaling (NSIS): Framework -->
      <!-- <?rfc include="reference.RFC.4389"?> IP Version 6 ND Proxy --> Join and Enrollment Information Elements</title>
    <author initials="D" surname="Dujovne" fullname="Diego Dujovne" role="editor">
      <organization/>
    </author>
    <author initials="M" surname="Richardson" fullname="Michael Richardson">
    <organization/>
    </author>
    <date month="May" year="2021"/>
  </front>
  <seriesInfo name="RFC" value="9032"/>
  <seriesInfo name="DOI" value="10.17487/RFC9032"/>
</reference>

<reference anchor="RFC9033" target="https://www.rfc-editor.org/info/rfc9033">
  <front>
  <title>6TiSCH Minimal Scheduling Function (MSF)</title>
    <author initials="T" surname="Chang" fullname="Tengfei Chang" role="editor">
      <organization/>
    </author>
    <author initials="M" surname="Vučinić" fullname="Mališa Vučinić">
      <organization/>
    </author>
    <author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana">
     <organization/>
    </author>
    <author initials="S" surname="Duquennoy" fullname="Simon Duquennoy">
     <organization/>
    </author>
    <author initials="D" surname="Dujovne" fullname="Diego Dujovne">
     <organization/>
    </author>
    <date month="May" year="2021"/>
  </front>
  <seriesInfo name="RFC" value="9033"/>
  <seriesInfo name="DOI" value="10.17487/RFC9033"/>
</reference>
</references>

   <references><name>Informative References</name>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml'/> <!-- IPv6 over Low-Power Wireless Personal Area Networks  --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4903.xml'/> <!-- IPv6  Multi-Link Subnet Issues   --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5974.xml'/> <!-- NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml'/> <!-- Datagram Transport Layer Security Version 1.2 --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml'/> <!--   The Locator/ID Separation Protocol (LISP) -->
      <!--?rfc include="reference.RFC.6997"?-->  <!-- Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3963.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml'/> <!-- Software-Defined Networking (SDN): Layers and Architecture Terminology --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6606.xml'/> <!-- Problem Statement and Requirements for 6LoWPAN Routing -->
      <!-- others -->
      <!--?rfc include='reference.I-D.ietf-ipv6-Multi-Link-subnets'?--> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-rpl-industrial-applicability.xml'/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3444.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-dtsecurity-zerotouch-join.xml'/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4080.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-object-security.xml'/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-manet-aodvv2.xml'/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4903.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml'/> <!-- Deterministic Networking Use Cases --> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5974.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-detnet-ip.xml'/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-bootstrapping-keyinfra.xml'/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-aodv-rpl.xml'/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lwig-6lowpan-virtual-reassembly.xml'/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6606.xml"/>

<reference anchor="I-D.ietf-roll-rpl-industrial-applicability">
<front>
<title>RPL applicability in industrial networks</title>
<author fullname="Tom Phinney" role="editor"> </author>
<author fullname="Pascal Thubert"> </author>
<author fullname="Robert Assimiti"> </author>
<date month="October" day="21" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-rpl-industrial-applicability-02"/>
</reference>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-dao-projection.xml'/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-6tisch-dtsecurity-zerotouch-join.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.rahul-roll-mop-ext.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.selander-ace-cose-ecdhe.xml'/>
      <!-- <?rfc include='reference.I-D.svshah-tsvwg-lln-diffserv-recommendations'?> --> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-manet-aodvv2.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-roll-bier.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-bier-replication-elimination.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-6lo-bier-dispatch.xml'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-6man-unicast-lookup.xml'/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-roll-aodv-rpl.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.pthubert-raw-problem-statement.xml'/>
      <!--?rfc include='reference.I-D.bernardos-raw-use-cases'?--> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-lwig-6lowpan-virtual-reassembly.xml"/>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.tiloca-6tisch-robust-scheduling.xml'/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-roll-dao-projection.xml"/>

<reference anchor="I-D.ietf-roll-capabilities">
   <front>
      <title>RPL Capabilities</title>
      <author initials="R" surname="Jadhav" fullname="Rahul Arvind Jadhav" role="editor"> </author>
      <author fullname="Pascal Thubert">
         <organization>Cisco Systems, Inc</organization>
      </author>
      <author fullname="Michael Richardson">
         <organization>Sandelman Software Works</organization>
      </author>
      <author initials="R" surname="Sahoo" fullname="Rabi Narayan Sahoo">
         <organization>Juniper</organization>
     </author>
     <date month="March" day="17" year="2021"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-roll-capabilities-08"/>
</reference>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ace-coap-est.xml'/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.selander-ace-cose-ecdhe.xml"/>

<reference anchor="I-D.thubert-roll-bier">
  <front>
    <title>RPL-BIER</title>
    <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization/>
    </author>
    <date month="July" day="24" year="2018"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-thubert-roll-bier-02"/>
</reference>

<reference anchor="I-D.thubert-bier-replication-elimination">
  <front>
    <title>BIER-TE extensions for Packet Replication and Elimination Function (PREF) and OAM</title>
    <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization/>
    </author>
    <author initials="T" surname="Eckert" fullname="Toerless Eckert">
      <organization/>
    </author>
    <author initials="Z" surname="Brodard" fullname="Zacharie Brodard">
      <organization/>
    </author>
    <author initials="H" surname="Jiang" fullname="Hao Jiang">
      <organization/>
    </author>
    <date month="March" day="3" year="2018"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-thubert-bier-replication-elimination-03"/>
</reference>

<reference anchor="I-D.thubert-6lo-bier-dispatch">
  <front>
    <title>A 6loRH for BitStrings</title>
    <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization/>
    </author>
    <author initials="Z" surname="Brodard" fullname="Zacharie Brodard">
      <organization/>
    </author>
    <author initials="H" surname="Jiang" fullname="Hao Jiang">
      <organization/>
    </author>
    <author initials="G" surname="Texier" fullname="Geraldine Texier">
      <organization/>
    </author>
    <date month="January" day="28" year="2019"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-thubert-6lo-bier-dispatch-06"/>
</reference>

<reference anchor="I-D.thubert-6man-unicast-lookup">
  <front>
    <title>IPv6 Neighbor Discovery Unicast Lookup</title>
    <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization/>
    </author>
    <author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abegnoli">
      <organization/>
    </author>
   <date month="July" day="29" year="2019"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-thubert-6man-unicast-lookup-00"/>
</reference>

<reference anchor="I-D.pthubert-raw-architecture">
  <front>
    <title>Reliable and Available Wireless Problem Statement</title>
    <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization/>
    </author>
    <author initials="G. Z." surname="Papadopoulos" fullname="Georgios Papadopoulos">
      <organization/>
    </author>
    <date month="November" day="15" year="2020"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-pthubert-raw-architecture-05"/>
</reference>

      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-constrained-voucher.xml'/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.tiloca-6tisch-robust-scheduling.xml"/>

<reference anchor="I-D.ietf-ace-coap-est">
  <front>
    <title>EST over secure CoAP (EST-coaps)</title>
    <author initials="P" surname="van der Stok" fullname="Peter van der Stok">
      <organization/>
    </author>
    <author initials="P" surname="Kampanakis" fullname="Panos Kampanakis">
      <organization/>
    </author>
    <author initials="M" surname="Richardson" fullname="Michael Richardson">
      <organization/>
    </author>
    <author initials="S" surname="Raza" fullname="Shahid Raza">
      <organization/>
    </author>
    <date month="January" day="6" year="2020"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-ace-coap-est-18"/>
</reference>

<reference anchor="I-D.ietf-anima-constrained-voucher" target="https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-10">
  <front>
    <title>Constrained Voucher Artifacts for Bootstrapping Protocols</title>
    <author initials="M" surname="Richardson" fullname="Michael Richardson">
      <organization/>
    </author>
    <author initials="P" surname="van der Stok" fullname="Peter van der Stok">
      <organization/>
    </author>
    <author initials="P" surname="Kampanakis" fullname="Panos Kampanakis">
      <organization/>
    </author>
    <date month="February" day="21" year="2021"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-10"/>
</reference>

      <reference anchor='IEEE802154'> anchor="IEEE802154"
target="https://ieeexplore.ieee.org/document/7460875">
        <front>
            <title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access
            Control (MAC) and Physical Layer (PHY) Specifications Standard for Low-Rate Wireless Personal Area Networks
            </title> Networks</title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
              <organization>IEEE</organization>
            </author>
            <date/>
            <date month="April" year="2016"/>
        </front>
        <seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
      </reference>

      <reference anchor='CCMstar' target='www.ieee802.org/15/pub/2004/15-04-0537-00-004b-formal-specification-ccm-star-mode-operation.doc'> anchor="CCMstar" target="http://www.ieee802.org/15/pub/2004/15-04-0537-00-004b-formal-specification-ccm-star-mode-operation.doc">
         <front>
            <title>
            Formal
            <title>Formal Specification of the CCM* Mode of Operation
         </title> Operation</title>
            <author fullname='Rene Struik'>
               <organization>IEEE standard for Information Technology</organization> fullname="Rene Struik">
               <organization>IEEE</organization>
            </author>
            <date month='September' year='2004'/> month="September" year="2004"/>
         </front>
      </reference>

      <reference anchor='IEEE802154e'> anchor="IEEE802154e"
target="https://ieeexplore.ieee.org/document/6185525">
         <front>
            <title>IEEE standard Standard for Information Technology, IEEE Std.
         802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) Local and Physical Layer (PHY) Specifications for Low-Rate
         Wireless Personal Area Networks, June 2011 as amended by IEEE Std.
         802.15.4e, metropolitan area networks -- Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer
         </title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
               <organization>IEEE</organization>
            </author>
            <date month='April' year='2012'/> month="April" year="2012"/>
         </front>
        <seriesInfo name="IEEE Standard" value="802.15.4e-2012"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6185525"/>
      </reference>
      <!--reference anchor="IEEE802.1TSNTG" target="http://www.ieee802.org/1/pages/avbridges.html">
         <front>
            <title>IEEE 802.1 Time-Sensitive Networks Task Group</title>
            <author>
               <organization>IEEE Standards Association</organization>
            </author>
            <date day="08" month="March" year="2013" />
         </front>
      </reference-->

      <reference anchor='WirelessHART'> anchor="WirelessHART" target="https://webstore.iec.ch/publication/24433">
         <front>
            <title>Industrial Communication Networks networks - Wireless Communication Network communication network and Communication Profiles - WirelessHART communication profiles - IEC 62591</title> WirelessHART(TM)</title>
            <author>
               <organization>www.hartcomm.org</organization>
               <organization>International Electrotechnical Commission</organization>
            </author>
            <date year='2010'/> month="March" year="2016"/>
         </front>
         <seriesInfo name="IEC" value="62591:2016"/>
      </reference>

      <reference anchor='HART'> anchor="HART" target="https://fieldcommgroup.org/technologies/hart">
         <front>
            <title>Highway Addressable remote Transducer, a group of specifications for industrial process and control devices administered by the HART Foundation</title>
            <title>HART</title>
            <author>
               <organization>www.hartcomm.org</organization>
               <organization>FieldComm Group</organization>
            </author>
            <date/>
         </front>
      </reference>

      <reference anchor='ISA100.11a' target='http://www.isa.org/Community/SP100WirelessSystemsforAutomation'> anchor="ISA100.11a" target="https://webstore.iec.ch/publication/65581">
         <front>
            <title>Wireless Systems for Industrial Automation: Process Control and Related Applications - ISA100.11a-2011 - IEC 62734</title> ISA100.11a-2011</title>
            <author>
               <organization>ISA/ANSI</organization>
            </author>
            <date year='2011'/> year="2011"/>
         </front>
         <seriesInfo name="IEC" value="62734:2014"/>
      </reference>

       <reference anchor='ISA100' target='https://www.isa.org/isa100/'> anchor="ISA100" target="https://www.isa.org/isa100/">
         <front>
            <title>ISA100, Wireless Systems for Automation</title>
            <author>
               <organization>ISA/ANSI</organization>
            </author>
            <date/>
         </front>
      </reference>

      <reference anchor='TEAS' target='https://dataTracker.ietf.org/doc/charter-ietf-teas/'> anchor="TEAS" target="https://datatracker.ietf.org/doc/charter-ietf-teas/">
         <front>
            <title>Traffic Engineering Architecture and Signaling</title> Signaling (teas)</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

      <reference anchor='ANIMA' target='https://dataTracker.ietf.org/doc/charter-ietf-anima/'> anchor="ANIMA" target="https://datatracker.ietf.org/doc/charter-ietf-anima/">
         <front>
            <title>Autonomic Networking Integrated Model and Approach</title> Approach (anima)</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

      <reference anchor='PCE' target='https://dataTracker.ietf.org/doc/charter-ietf-pce/'> anchor="PCE" target="https://datatracker.ietf.org/doc/charter-ietf-pce/">
         <front>
            <title>Path Computation Element</title> Element (pce)</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

      <reference anchor='CCAMP' target='https://dataTracker.ietf.org/doc/charter-ietf-ccamp/'> anchor="CCAMP" target="https://datatracker.ietf.org/doc/charter-ietf-ccamp/">
         <front>
            <title>Common Control and Measurement Plane</title> Plane (ccamp)</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

      <reference anchor='AMI' target='https://www.energy.gov/sites/prod/files/2016/12/f34/AMI%20Summary%20Report_09-26-16.pdf'> anchor="AMI" target="https://www.energy.gov/sites/prod/files/2016/12/f34/AMI%20Summary%20Report_09-26-16.pdf">
         <front>
            <title>Advanced Metering Infrastructure and Customer Systems </title>
            <author>
               <organization>US Department Customer Systems </title>
            <author>
               <organization>U.S. Department of Energy</organization>
            </author>
            <date year="2006"/>
         </front>
      </reference>

      <reference anchor="S-ALOHA" target="https://dl.acm.org/citation.cfm?id=1024920">
         <front>
            <title>ALOHA packet system with and without slots and capture</title>
            <author surname="Roberts" fullname="Lawrence G. Roberts">
            </author>
            <date month="April" year="1975"/>
         </front>
         <refcontent>ACM SIGCOMM Computer Communication Review</refcontent>
         <seriesInfo name="DOI" value="10.1145/1024916.1024920"/>
      </reference>

      <reference anchor="IEC62439" target="https://webstore.iec.ch/publication/24438">
         <front>
            <title>Industrial communication networks - High availability automation networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR)</title>
            <author>
               <organization>IEC</organization>
            </author>
            <date year="2016"/>
         </front>
         <seriesInfo name="IEC" value="62439-3:2016"/>
      </reference>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-raw-use-cases.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9035.xml"/>
   </references>
</references>

   <section><name>Related Work in Progress</name>
   <t>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.
      </t>

      <section anchor="unchartered"><name>Unchartered IETF Work Items</name>

      <section anchor="unchartered-sec"><name>6TiSCH Zero-Touch Security</name>

      <t>
      The security model and in particular the zero-touch join process
      <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> depend on
      the ANIMA (Autonomic Networking Integrated Model and Approach) <xref target="ANIMA"/>
      "<xref target="RFC8995" format="title"/>" <xref target="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
      <xref target="I-D.selander-ace-cose-ecdhe">"Ephemeral Diffie-Hellman Over
      COSE (EDHOC)"</xref>, which is being considered for adoption by the LAKE
      (Lightweight Authenticated Key Exchange) WG.
      </t>

      </section>

      <section anchor="unchartered-tracks"><name>6TiSCH Track Setup</name>
            <t>
      ROLL (Routing Over Low power and Lossy networks) is now standardizing a reactive routing protocol based on RPL
      <xref target="I-D.ietf-roll-aodv-rpl"/>.
      The need of Energy</organization>
            </author>
            <date year='2006'/>
         </front>
      </reference>

      <reference anchor='S-ALOHA' target='https://dl.acm.org/citation.cfm?id=1024920'>
         <front>
            <title>ALOHA Packet System With and Without Slots a reactive routing protocol to establish on-demand,
      constraint-optimized routes and Capture</title>
            <author surname='Roberts' fullname='Lawrence G. Roberts'>

               <organization>ACM SIGCOMM Computer Communication Review</organization>
            </author>
            <date month='April' year='1975'/>
         </front>
         <seriesInfo name='doi' value='10.1145/1024916.1024920'/>
      </reference>

      <reference anchor='IEC62439' target='https://webstore.iec.ch/publication/7018'>
         <front>
            <title>Industrial communication networks - High availability automation a reservation protocol to establish
      Layer 3 Tracks is being discussed in 6TiSCH but not yet chartered.

      </t><t>

      At the time of this writing, there is new work planned in the IETF to provide
      limited deterministic networking capabilities for wireless networks - Part 3: Parallel Redundancy Protocol (PRP) with a
      focus on forwarding behaviors to react quickly and High-availability Seamless Redundancy (HSR) - IEC62439-3</title>
            <author>
               <organization>IEC</organization>
            </author>
            <date year='2012'/>
         </front>
      </reference>
   </references>

   <section><name>Related Work In Progress</name>
   <t>This document has been incremented as locally to the work progressed following changes
      as described in <xref target="I-D.pthubert-raw-architecture"/>.

      </t><t>
      ROLL is also standardizing an extension to RPL to set up centrally computed
      routes <xref target="I-D.ietf-roll-dao-projection"/>.

      </t><t>
      The 6TiSCH architecture should thus inherit from the
      evolution
      <xref target="RFC8655">DetNet architecture</xref> 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) <xref target="TEAS"/> will be required to
      expose the WG charter 6TiSCH node capabilities and the availability network peers to the PCE,
      possibly in combination with <xref target="I-D.ietf-roll-capabilities"/>.
      A protocol such as a lightweight Path Computation Element Communication Protocol (PCEP) or an adaptation of dependent work.
      The intent was
      Common Control and Measurement Plane (CCAMP)
      <xref target="CCAMP"/> GMPLS formats and procedures could be used in
      combination to publish when the WG concludes on the covered items.
      At the time of publishing <xref target="I-D.ietf-roll-dao-projection"/> to install
      the following specification are still in progress
      and may affect Tracks, as computed by the evolution of PCE, to the stack in a 6TiSCH-aware node. 6TiSCH nodes.
      </t>

      <!--

      </section>

      <section anchor="chartered" title="Chartered IETF work items"> anchor="unchartered-bier"><name>Using BIER in a 6TiSCH Network</name>

    <t>
      The operation of the Backbone Router
      <xref target="I-D.ietf-6lo-backbone-router"/> ROLL is stable but actively working on Bit Index
    Explicit Replication (BIER) as a method to compress both the RFC
      is not published yet. The protection of registered addresses against
      impersonation
    data-plane packets and take over will be guaranteed by the routing tables in storing mode
    <xref target="I-D.ietf-6lo-ap-nd">Address
      Protected Neighbor Discovery for Low-power and Lossy Networks</xref>,
      which is not yet published either. target="I-D.thubert-roll-bier"/>.
    </t>
    <t>
      New procedures have been defined at ROLL that extend RPL and may
    BIER could also be used in the context of
      interest for a 6TiSCH stack.
      In particular <xref target="I-D.ietf-roll-unaware-leaves"/> enables a 6LN
      that implements only the DetNet service layer.
    <xref target='RFC8505'/> target="I-D.thubert-bier-replication-elimination">
    "BIER-TE extensions for Packet Replication and avoid Elimination Function
                             (PREF) and OAM"</xref> leverages BIER
    Traffic Engineering (TE) to control the support of RPL.
      </t>

      </section> Chartered IETF work items -->

      <section anchor='unchartered'><name>Unchartered IETF work items</name>

      <section anchor='unchartered-sec'><name>6TiSCH Zerotouch security</name>

      <t>
      The security model
    DetNet Replication and Elimination activities in particular the zerotouch join process
      <xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> depends on the ANIMA <xref target='ANIMA'/>
      <xref target='I-D.ietf-anima-bootstrapping-keyinfra'>Bootstrapping Remote
      Secure Key Infrastructures (BRSKI)</xref> data plane, and to enable zero-touch security provisionning; for highly
      constrained nodes, a minimal model based provide traceability
    on pre-shared keys (PSK) links where replication and loss happen, in a manner that is also available. As written abstract to this day, it also depends on
      a number of documents in progress as CORE, and on
    the forwarding information.
    </t>
    <t>
    <xref target='I-D.selander-ace-cose-ecdhe'>"Ephemeral Diffie-Hellman Over
      COSE (EDHOC)"</xref>, which is being considered target="I-D.thubert-6lo-bier-dispatch">"A 6loRH for BitStrings"</xref>
    proposes a 6LoWPAN compression for adoption at the LAKE
      WG. BIER BitString based on
    <xref target="RFC8138">6LoWPAN Routing Header</xref>.
      </t>

      </section> <!-- "6TiSCH Zerotouch security" -->
      </section>

      <section anchor='unchartered-tracks'><name>6TiSCH Track Setup</name> anchor="external"><name>External (Non-IETF) Work Items</name>

      <t>
      ROLL is now standardizing
      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 reactive routing protocol based strong dependency on RPL
      <xref target='I-D.ietf-roll-aodv-rpl'/> IEEE Std 802.15.4 and its evolution.
      The need impact of a reactive routing protocol changes to establish on-demand
      constraint-optimized routes and a reservation protocol TSCH on this architecture should be minimal to establish
      Layer-3 Tracks is being discussed at 6TiSCH
      nonexistent, but not chartered for.

      </t><t>

      <!--
      At deeper work such as 6top and security may be impacted.
      A 6TiSCH Interest Group at the time of this writing, IEEE maintains the formation of a new working group called
      RAW for Reliable synchronization
      and Available Wireless networking is being considered.
      The helps foster work on centralized Track computation at the IEEE should 6TiSCH demand it.
      </t>
      <t>
      Work is deferred to a subsequent
      work, not necessarily being proposed at 6TiSCH. A Predictable and Available Wireless
      (PAW) bar-BoF took place.
      RAW may form as a WG and develop a generic specification IEEE (802.15.12 PAR) for Track
      operations an LLC that would cover 6TiSCH requirements as expressed
      logically include the 6top sublayer. The interaction with the 6top sublayer
      and the Scheduling Functions described in this
      architecture, more in <xref target='I-D.thubert-raw-technologies'/>
      and document are yet to be
      defined.
      </t>
      <t>
      ISA100 <xref target='I-D.pthubert-raw-problem-statement'/>.
      In a large LLN, it target="ISA100"/> Common Network Management (CNM) is not
      feasible another
      external work of interest for 6TiSCH. The group, referred to update the routes from as ISA100.20,
      defines a central controller Common Network Management framework that resides far
      over the constrained network at should enable the speed at which
      management of resources that are controlled by heterogeneous protocols
      such as ISA100.11a <xref target="ISA100.11a"/>, WirelessHART
      <xref target="WirelessHART"/>, and 6TiSCH. Interestingly, the quality
      establishment of the
      wireless links varies.
      RAW would focus 6TiSCH deterministic paths, called Tracks,
      are also in scope, and ISA100.20 is working on forwarding behaviors requirements for DetNet.
      </t>

      </section>

   </section>

   <section numbered="false"><name>Acknowledgments</name>
   <section numbered="false" toc="exclude"><name>Special Thanks</name>
<t>
      Special thanks to react quickly and locally <contact fullname="Jonathan Simon"/>,
      <contact fullname="Giuseppe Piro"/>, <contact fullname="Subir Das"/>, and
      <contact fullname="Yoshihiro Ohba"/> for their deep contributions to the changes in the wireless links.

      -->
      At the time of this writing, there is new work planned in the IETF initial security
      work, to provide
      limited deterministic networking capabilities <contact fullname="Yasuyuki Tanaka"/> for wireless networks with a
      focus his work on forwarding behaviors to react quickly implementation and locally simulation
      that tremendously helped build a robust system, to <contact fullname="Diego Dujovne"/> for
      starting and leading the changes
      as described SF0 effort, and to <contact fullname="Tengfei Chang"/> for evolving it
      in <xref target='I-D.pthubert-raw-problem-statement'/>. the MSF.
      </t><t>
      ROLL is
      Special thanks also standardizing an extension to RPL to setup centrally-computed
      routes <xref target='I-D.ietf-roll-dao-projection'/>

      </t><t>
      The 6TiSCH Architecture should thus inherit from <contact fullname="Pat Kinney"/>,
      <contact fullname="Charlie Perkins"/>, and <contact fullname="Bob Heile"/> for their
      support in maintaining the
      <xref target='RFC8655'>DetNet</xref> architecture connection active and
      thus depends on it. The Path Computation Element (PCE) should be a
      core component of that architecture.
      An extension to RPL or to TEAS <xref target='TEAS'/> will be required the design in line with
      work happening at IEEE 802.15.
      </t>  <t>
      Special thanks to
      expose <contact fullname="Ted Lemon"/>, who was the 6TiSCH node capabilities INT Area Director while this
      document was initiated, for his great support and help throughout,
      and the network peers to the PCE,
      possibly in combination <contact fullname="Suresh Krishnan"/>, who took over with <xref target='I-D.rahul-roll-mop-ext'/>.
      A protocol such as a lightweight PCEP or an adaptation that kind efficiency of CCAMP
      <xref target='CCAMP'/> G-MPLS formats his till
      publication.
      </t><t>
      Also special thanks to <contact fullname="Ralph Droms"/>, who performed the first INT Area
      Directorate review, which was very deep and procedures could be used thorough and radically changed
      the orientations of this document, and then to <contact fullname="Eliot Lear"/>
      and <contact fullname="Carlos Pignataro"/>, who helped finalize this
      document in
      combination preparation for the IESG reviews,
      and to <xref target='I-D.ietf-roll-dao-projection'/> <contact fullname="Gorry Fairhurst"/>,
<contact fullname="David Mandelberg"/>, <contact fullname="Qin Wu"/>,
<contact fullname="Francis Dupont"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Mirja Kühlewind"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Benjamin Kaduk"/>, and <contact fullname="Andrew Malis"/>,
who contributed to install
      the Tracks, as computed by the PCE, to final shaping of this document
      through the 6TiSCH nodes. IESG review procedure.
      </t>

      </section><!-- 6TiSCH Track Setup -->
   </section>
   <section anchor='unchartered-bier'><name>Using BIER in a 6TiSCH Network</name>

    <t> ROLL numbered="false" toc="exclude"><name>And Do Not Forget</name>
      <t>This document is actively working on Bit Index
    Explicit Replication (BIER) as a method to compress both the
    dataplane packets and the routing tables in storing mode
    <xref target='I-D.thubert-roll-bier'/>.
    </t>
    <t>
    BIER could also be used result of multiple interactions, in
      particular during the context of 6TiSCH (bi)Weekly Interim call, relayed through
      the DetNet service layer.
    <xref target='I-D.thubert-bier-replication-elimination'>
    BIER-TE-based OAM, Replication and Elimination </xref> leverages BIER
    Traffic Engineering (TE) to control in 6TiSCH mailing list at the data plane IETF, over the
    DetNet Replication and Elimination activities, and course of more than 5 years.
      </t><t>
      The authors wish to provide traceability
    on links where replication and loss happen, thank in a manner that is abstract to
    the forwarding information.
    </t>
    <t>
    <xref target='I-D.thubert-6lo-bier-dispatch'>a 6loRH for BitStrings</xref>
    proposes a 6LoWPAN compression arbitrary order:
<contact fullname="Alaeddine Weslati"/>, <contact fullname="Chonggang Wang"/>,
<contact fullname="Georgios Exarchakos"/>, <contact fullname="Zhuo Chen"/>,
<contact fullname="Georgios Papadopoulos"/>, <contact fullname="Eric Levy-Abegnoli"/>,
<contact fullname="Alfredo Grieco"/>, <contact fullname="Bert Greevenbosch"/>,
<contact fullname="Cedric Adjih"/>, <contact fullname="Deji Chen"/>,
<contact fullname="Martin Turon"/>, <contact fullname="Dominique Barthel"/>,
<contact fullname="Elvis Vogli"/>, <contact fullname="Geraldine Texier"/>,
<contact fullname="Guillaume Gaillard"/>, <contact fullname="Herman Storey"/>,
<contact fullname="Kazushi Muraoka"/>, <contact fullname="Ken Bannister"/>,
<contact fullname="Kuor Hsin Chang"/>, <contact fullname="Laurent Toutain"/>,
<contact fullname="Maik Seewald"/>, <contact fullname="Michael Behringer"/>,
<contact fullname="Nancy Cam Winget"/>, <contact fullname="Nicola Accettura"/>,
<contact fullname="Nicolas Montavont"/>, <contact fullname="Oleg Hahm"/>,
<contact fullname="Patrick Wetterwald"/>, <contact fullname="Paul Duffy"/>,
<contact fullname="Peter van der Stok"/>, <contact fullname="Rahul Sen"/>,
<contact fullname="Pieter de Mil"/>, <contact fullname="Pouria Zand"/>,
<contact fullname="Rouhollah Nabati"/>, <contact fullname="Rafa Marin-Lopez"/>,
<contact fullname="Raghuram Sudhaakar"/>, <contact fullname="Sedat Gormus"/>,
<contact fullname="Shitanshu Shah"/>, <contact fullname="Steve Simlo"/>,
<contact fullname="Tina Tsou"/>, <contact fullname="Tom Phinney"/>,
<contact fullname="Xavier Lagrange"/>, <contact fullname="Ines Robles"/>, and
<contact fullname="Samita Chakrabarti"/> for the BIER Bitstring based on
    <xref target='RFC8138'>6LoWPAN Routing Header</xref>. their participation and various contributions.
      </t>
   </section> <!-- 6TiSCH Track Setup -->

      </section><!-- Unchartered IETF work items -->
   </section>

   <section anchor='external'><name>External (non-IETF) work items</name>

      <t>
      The current charter positions 6TiSCH on IEEE Std. 802.15.4 only.
      Though most numbered="false"><name>Contributors</name>
   <t>The co-authors of this document are listed below:
      </t><ul empty="true" spacing="normal">
       <li><t><contact fullname="Thomas Watteyne"/>
          for his contributions to the design should be portable on other link types,
      6TiSCH has a strong dependency whole design, in particular on IEEE Std. 802.15.4 TSCH and security,
          and its evolution.
      The impact of changes to TSCH on this Architecture should be the open source community that he created with openWSN;</t>
      </li>
         <li><t><contact fullname="Xavier Vilajosana"/>,
          who led the design of the minimal support with RPL and contributed
          deeply to
      non-existent, but deeper work such as the 6top design and security may be impacted.
      A 6TiSCH Interest Group at the IEEE maintains the synchronization GMPLS operation of Track switching;</t>
      </li>
         <li><t><contact fullname="Kris Pister"/>
         for creating TSCH and helps foster his continuing guidance through the elaboration
         of this design;</t>
      </li>
         <li><t><contact fullname="Mališa Vučinić"/>
         for the work at on the IEEE should 6TiSCH demand it.
      </t>
      <t>
      Work is being proposed at IEEE (802.15.12 PAR) one-touch join process and his contribution to the
         Security Design Team;</t>
      </li>
         <li><t><contact fullname="Michael Richardson"/>
         for an LLC that would
      logically include his leadership role in the 6top sublayer. The interaction with Security Design Team and his
         contribution throughout this document;</t>
      </li>
         <li><t><contact fullname="Tero Kivinen"/>
          for his contribution to the 6top sublayer security work in general and the Scheduling Functions described security
          section in particular;</t>
      </li>
         <li><t><contact fullname="Maria Rita Palattella"/>
         for managing the Terminology document that was merged into this document are yet to be
      defined.
      </t>
      <t>
      ISA100 <xref target='ISA100'/> Common Network Management (CNM) is another
      external through the work of interest 6TiSCH;</t>
      </li>
         <li><t><contact fullname="Simon Duquennoy"/>
          for 6TiSCH. The group, referred his contribution to as ISA100.20,
      defines a Common Network Management framework that should enable the
      management open source community with the 6TiSCH
          implementation of resources that are controlled by heterogeneous protocols
      such as ISA100.11a <xref target='ISA100.11a'/>, WirelessHART
      <xref target='WirelessHART'/>, contiki, and 6TiSCH. Interestingly, for his contribution to MSF and
          autonomous unicast cells;</t>
      </li>
         <li><t><contact fullname="Qin Wang"/>,
          who led the
      establishment design of 6TiSCH Deterministic paths, called Tracks,
      are also in scope, the 6top sublayer and ISA100.20 is working on requirements contributed related text
          that was moved and/or adapted into this document;</t>
      </li>
         <li><t><contact fullname="Rene Struik"/>
         for DetNet.
      </t>

      </section><!-- External IETF the security section and his contribution to the Security Design
         Team;</t>
      </li>
         <li><t><contact fullname="Robert Assimiti"/>
          for his breakthrough work items -->

   </section><!--title="Dependencies on Work In Progress"--> RPL over TSCH and initial text and
          guidance.</t>
      </li>
        </ul>
   </section>

</back>

</rfc>