rfc9030.original.xml   rfc9030.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
ensus="true" docName="draft-ietf-6tisch-architecture-30" indexInclude="true" ipr
<?rfc toc="yes"?> ="trust200902" number="9030" prepTime="2021-05-29T09:04:29" scripts="Common,Lati
<?rfc tocompact="yes"?> n" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude=
<?rfc tocdepth="3"?> "true" xml:lang="en">
<?rfc tocindent="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture-30
<?rfc symrefs="yes"?> " rel="prev"/>
<?rfc sortrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc9030" rel="alternate"/>
<?rfc comments="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc inline="yes"?> <front>
<?rfc compact="no"?> <title abbrev="6TiSCH Architecture">An Architecture for IPv6 over the Time-S
<?rfc subcompact="no"?> lotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)</title>
<?rfc authorship="yes"?> <seriesInfo name="RFC" value="9030" stream="IETF"/>
<?rfc tocappendix="yes"?> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edito
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr='trust20090 r">
2' tocInclude="true" obsoletes="" updates="" consensus="true" submissionType="I <organization abbrev="Cisco Systems" showOnFrontPage="true">Cisco Systems,
ETF" xml:lang="en" version="3" docName="draft-ietf-6tisch-architecture-30" > Inc</organization>
<front>
<title abbrev='6tisch-architecture'>An Architecture for IPv6 over the TSCH mo
de of IEEE 802.15.4</title>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor
'>
<organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization>
<address> <address>
<postal> <postal>
<street>Building D</street> <extaddr>Building D</extaddr>
<street>45 Allee des Ormes - BP1200 </street> <street>45 Allee des Ormes - BP1200</street>
<city>Mougins - Sophia Antipolis</city> <city>Mougins - Sophia Antipolis</city>
<code>06254</code> <code>06254</code>
<country>France</country> <country>France</country>
</postal> </postal>
<phone>+33 497 23 26 34</phone> <phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email> <email>pthubert@cisco.com</email>
</address> </address>
</author> </author>
<date month="05" year="2021"/>
<date/> <area>Internet Area</area>
<workgroup>6TiSCH</workgroup>
<area>Internet Area</area> <keyword>deterministic wireless</keyword>
<workgroup>6TiSCH</workgroup> <keyword>radio</keyword>
<keyword>Draft</keyword> <keyword>mesh</keyword>
<abstract> <abstract pn="section-abstract">
<t> This document describes a network architecture that provides <t indent="0" pn="section-abstract-1"> This document describes a network
low-latency, low-jitter and high-reliability packet delivery. It architecture that provides
low-latency, low-jitter, and high-reliability packet delivery. It
combines a high-speed powered backbone and subnetworks using IEEE combines a high-speed powered backbone and subnetworks using IEEE
802.15.4 time-slotted channel hopping (TSCH) to meet the 802.15.4 time-slotted channel hopping (TSCH) to meet the
requirements of LowPower wireless deterministic applications. requirements of low-power wireless deterministic applications.
<!--
This document presents the 6TiSCH architecture of an IPv6
Multi-Link subnet that is composed of a high-speed powered backbone and
a number of IEEE Std. 802.15.4 TSCH low-power wireless networks attache
d and
synchronized by Backbone Routers. The architecture defines mechanisms
to establish and maintain routing and scheduling in a centralized,
distributed, or mixed fashion.
Backbone Routers perform proxy Neighbor Discovery operations over
the backbone on behalf of the wireless devices, so they can share a sam
e
subnet and appear to be connected to the same backbone as classical dev
ices.
-->
</t>
</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> </t>
</note--> </abstract>
</front> <boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<middle> "exclude" pn="section-boilerplate.1">
<section><name>Introduction</name> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<t> >
Wireless Networks enable a wide variety of devices of any size <t indent="0" pn="section-boilerplate.1-1">
This document is not an Internet Standards Track specification; it i
s
published for informational purposes.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9030" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-terminology">Terminology</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ne
w-terms">New Terms</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><
xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ab
breviations">Abbreviations</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-related-documents">Rel
ated Documents</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-high-level-architecture">High-Leve
l Architecture</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-a-non-broadcast-multi-
acces">A Non-broadcast Multi-access Radio Mesh Network</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-a-multi-link-subnet-mo
del">A Multi-Link Subnet Model</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tsch-a-deterministic-m
ac-la">TSCH: a Deterministic MAC Layer</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
"3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-scheduling-tsch">Sched
uling TSCH</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5">
<t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent=
"3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-distributed-vs-central
ized-">Distributed vs. Centralized Routing</xref></t>
</li>
<li pn="section-toc.1-1.3.2.6">
<t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent=
"3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-forwarding-over-tsch">
Forwarding over TSCH</xref></t>
</li>
<li pn="section-toc.1-1.3.2.7">
<t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent=
"3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-6tisch-stack">6TiSCH S
tack</xref></t>
</li>
<li pn="section-toc.1-1.3.2.8">
<t indent="0" pn="section-toc.1-1.3.2.8.1"><xref derivedContent=
"3.8" format="counter" sectionFormat="of" target="section-3.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-communication-paradigm
s-and">Communication Paradigms and Interaction Models</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-architecture-components">Architect
ure Components</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-6lowpan-and-rpl">6LoWP
AN (and RPL)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.1.2">
<li pn="section-toc.1-1.4.2.1.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derived
Content="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-rpl-unawar
e-leaves-and-6low">RPL-Unaware Leaves and 6LoWPAN ND</xref></t>
</li>
<li pn="section-toc.1-1.4.2.1.2.2">
<t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derived
Content="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-6lbr-and-r
pl-root">6LBR and RPL Root</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-network-access-and-add
ressi">Network Access and Addressing</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.2.2">
<li pn="section-toc.1-1.4.2.2.2.1">
<t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derived
Content="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-join-proce
ss">Join Process</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derived
Content="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-registrati
on">Registration</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tsch-and-6top">TSCH an
d 6top</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.3.2">
<li pn="section-toc.1-1.4.2.3.2.1">
<t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derived
Content="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-6top">6top
</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.2">
<t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derived
Content="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-scheduling
-functions-and-th">Scheduling Functions and the 6top Protocol</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derived
Content="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-6top-and-r
pl-objective-func">6top and RPL Objective Function Operations</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.4">
<t indent="0" pn="section-toc.1-1.4.2.3.2.4.1"><xref derived
Content="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-network-sy
nchronization">Network Synchronization</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.5">
<t indent="0" pn="section-toc.1-1.4.2.3.2.5.1"><xref derived
Content="4.3.5" format="counter" sectionFormat="of" target="section-4.3.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-slotframes
-and-cdu-matrix">Slotframes and CDU Matrix</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.6">
<t indent="0" pn="section-toc.1-1.4.2.3.2.6.1"><xref derived
Content="4.3.6" format="counter" sectionFormat="of" target="section-4.3.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-distributi
ng-the-reservatio">Distributing the Reservation of Cells</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-schedule-management-me
chani">Schedule Management Mechanisms</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.4.2">
<li pn="section-toc.1-1.4.2.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derived
Content="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-static-sch
eduling">Static Scheduling</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.4.2.2.1"><xref derived
Content="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-neighbor-t
o-neighbor-schedu">Neighbor-to-Neighbor Scheduling</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.4.2.3.1"><xref derived
Content="4.4.3" format="counter" sectionFormat="of" target="section-4.4.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-remote-mon
itoring-and-sched">Remote Monitoring and Schedule Management</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.2.4.1"><xref derived
Content="4.4.4" format="counter" sectionFormat="of" target="section-4.4.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-hop-by-hop
-scheduling">Hop-by-Hop Scheduling</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.5">
<t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent=
"4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-on-tracks">On Tracks</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.5.2">
<li pn="section-toc.1-1.4.2.5.2.1">
<t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derived
Content="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-general-be
havior-of-tracks">General Behavior of Tracks</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5.2.2">
<t indent="0" pn="section-toc.1-1.4.2.5.2.2.1"><xref derived
Content="4.5.2" format="counter" sectionFormat="of" target="section-4.5.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-serial-tra
ck">Serial Track</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5.2.3">
<t indent="0" pn="section-toc.1-1.4.2.5.2.3.1"><xref derived
Content="4.5.3" format="counter" sectionFormat="of" target="section-4.5.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-complex-tr
ack-with-replicat">Complex Track with Replication and Elimination</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5.2.4">
<t indent="0" pn="section-toc.1-1.4.2.5.2.4.1"><xref derived
Content="4.5.4" format="counter" sectionFormat="of" target="section-4.5.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-detnet-end
-to-end-path">DetNet End-to-End Path</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5.2.5">
<t indent="0" pn="section-toc.1-1.4.2.5.2.5.1"><xref derived
Content="4.5.5" format="counter" sectionFormat="of" target="section-4.5.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-cell-reuse
">Cell Reuse</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.6">
<t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent=
"4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-forwarding-models">For
warding Models</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.6.2">
<li pn="section-toc.1-1.4.2.6.2.1">
<t indent="0" pn="section-toc.1-1.4.2.6.2.1.1"><xref derived
Content="4.6.1" format="counter" sectionFormat="of" target="section-4.6.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-track-forw
arding">Track Forwarding</xref></t>
</li>
<li pn="section-toc.1-1.4.2.6.2.2">
<t indent="0" pn="section-toc.1-1.4.2.6.2.2.1"><xref derived
Content="4.6.2" format="counter" sectionFormat="of" target="section-4.6.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-ipv6-forwa
rding">IPv6 Forwarding</xref></t>
</li>
<li pn="section-toc.1-1.4.2.6.2.3">
<t indent="0" pn="section-toc.1-1.4.2.6.2.3.1"><xref derived
Content="4.6.3" format="counter" sectionFormat="of" target="section-4.6.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-fragment-f
orwarding">Fragment Forwarding</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.7">
<t indent="0" pn="section-toc.1-1.4.2.7.1"><xref derivedContent=
"4.7" format="counter" sectionFormat="of" target="section-4.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-advanced-6tisch-routin
g">Advanced 6TiSCH Routing</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.7.2">
<li pn="section-toc.1-1.4.2.7.2.1">
<t indent="0" pn="section-toc.1-1.4.2.7.2.1.1"><xref derived
Content="4.7.1" format="counter" sectionFormat="of" target="section-4.7.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-packet-mar
king-and-handling">Packet Marking and Handling</xref></t>
</li>
<li pn="section-toc.1-1.4.2.7.2.2">
<t indent="0" pn="section-toc.1-1.4.2.7.2.2.1"><xref derived
Content="4.7.2" format="counter" sectionFormat="of" target="section-4.7.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-replicatio
n-retries-and-eli">Replication, Retries, and Elimination</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-availability-of-remote
-serv">Availability of Remote Services</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-selective-jamming">Sel
ective Jamming</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-mac-layer-security">MA
C-Layer Security</xref></t>
</li>
<li pn="section-toc.1-1.6.2.4">
<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
"6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-time-synchronization">
Time Synchronization</xref></t>
</li>
<li pn="section-toc.1-1.6.2.5">
<t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent=
"6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-validating-asn">Valida
ting ASN</xref></t>
</li>
<li pn="section-toc.1-1.6.2.6">
<t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent=
"6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-network-keying-and-rek
eying">Network Keying and Rekeying</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendi
x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d
erivedContent="" format="title" sectionFormat="of" target="name-related-work-in-
progress">Related Work in Progress</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-unchartered-ietf-work-
items">Unchartered IETF Work Items</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.1.2">
<li pn="section-toc.1-1.8.2.1.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.2.1.1"><xref derived
Content="A.1.1" format="counter" sectionFormat="of" target="section-a.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-6tisch-zer
o-touch-security">6TiSCH Zero-Touch Security</xref></t>
</li>
<li pn="section-toc.1-1.8.2.1.2.2">
<t indent="0" pn="section-toc.1-1.8.2.1.2.2.1"><xref derived
Content="A.1.2" format="counter" sectionFormat="of" target="section-a.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-6tisch-tra
ck-setup">6TiSCH Track Setup</xref></t>
</li>
<li pn="section-toc.1-1.8.2.1.2.3">
<t indent="0" pn="section-toc.1-1.8.2.1.2.3.1"><xref derived
Content="A.1.3" format="counter" sectionFormat="of" target="section-a.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-using-bier
-in-a-6tisch-netw">Using BIER in a 6TiSCH Network</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-external-non-ietf-work
-item">External (Non-IETF) Work Items</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments
</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
ss</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section numbered="true" removeInRFC="false" toc="include" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">
Wireless networks enable a wide variety of devices of any size
to get interconnected, often at a very low marginal cost per device, to get interconnected, often at a very low marginal cost per device,
at any range, and in circumstances where wiring may be impractical, at any range, and in circumstances where wiring may be impractical,
for instance on fast-moving or rotating devices. for instance, on fast-moving or rotating devices.
</t> </t>
<t> <t indent="0" pn="section-1-2">
On the other hand, Deterministic Networking maximizes the packet On the other hand, Deterministic Networking maximizes the packet
delivery ratio within a bounded latency so as to enable delivery ratio within a bounded latency so as to enable
mission-critical machine-to-machine (M2M) operations. mission-critical machine-to-machine (M2M) operations.
<!-- At IEEE Std. 802.1, the
<xref target="IEEE Std. 802.1TSNTG">Time Sensitive Networking</xref>(TS
N)
task group was formed to provide deterministic properties at Layer-2
across multiple hops. -->
Applications that need such networks are presented in Applications that need such networks are presented in
<xref target='RFC8578'/>. <xref target="RFC8578" format="default" sectionFormat="of" derivedConte
<!--and nt="RFC8578"/>
<xref target="I-D.bernardos-raw-use-cases"/>, which presents a number and
of additional use cases for Reliable and Available Wireless networks. <xref target="I-D.ietf-raw-use-cases" format="default" sectionFormat="o
--> f" derivedContent="RAW-USE-CASES"/>, which presents a number
The considered applications include Professional Media, Industrial of additional use cases for Reliable and Available Wireless networks (R
Automation Control Systems (IACS), building AW).
The considered applications include professional media, Industrial
Automation and Control Systems (IACS), building
automation, in-vehicle command and control, commercial automation and automation, in-vehicle command and control, commercial automation and
asset tracking with mobile scenarios, as well as gaming, drones and edg asset tracking with mobile scenarios, as well as gaming, drones and
e robotic control, and home automation applications. edge robotic control, and home automation applications.
</t> </t>
<t> <t indent="0" pn="section-1-3">
The Timeslotted Channel Hopping (TSCH) <xref target='RFC7554'/> mode The Time-Slotted Channel Hopping (TSCH) <xref target="RFC7554" format="
of the IEEE Std. 802.15.4 <xref target='IEEE802154'/> Medium Access default" sectionFormat="of" derivedContent="RFC7554"/> mode
Control (MAC) was introduced with the IEEE Std. 802.15.4e of the IEEE Std 802.15.4 <xref target="IEEE802154" format="default" sec
<xref target='IEEE802154e'/> amendment and is now retrofitted in the tionFormat="of" derivedContent="IEEE802154"/> Medium Access
Control (MAC) was introduced with the IEEE Std 802.15.4e
<xref target="IEEE802154e" format="default" sectionFormat="of" derivedC
ontent="IEEE802154e"/> amendment and is now retrofitted in the
main standard. For all practical purposes, this document main standard. For all practical purposes, this document
is expected to be insensitive to the revisions of that standard, is expected to be insensitive to the revisions of that standard,
which is thus referenced without a date. which is thus referenced without a date.
TSCH is both a Time-Division Multiplexing and a Frequency-Division TSCH is both a Time-Division Multiplexing (TDM) and a Frequency-Divisio
Multiplexing technique whereby a different channel can be used for n
each transmission, and that allows to schedule transmissions for Multiplexing (FDM) technique, whereby a different channel can be used f
deterministic operations, and applies to the slower and most energy or
constrained wireless use cases. each transmission. TSCH allows the scheduling of transmissions for
deterministic operations and applies to the slower and most
energy-constrained wireless use cases.
</t> </t>
<t> <t indent="0" pn="section-1-4">
The scheduled operation provides for a more reliable experience which The scheduled operation provides for a more reliable experience, which
can be used to monitor and manage resources, e.g., energy and water, in can be used to monitor and manage resources, e.g., energy and water, in
a more efficient fashion. a more efficient fashion.
</t> </t>
<t> <t indent="0" pn="section-1-5">
Proven Deterministic Networking standards for use in Process Control, Proven deterministic networking standards for use in process control,
including ISA100.11a <xref target='ISA100.11a'/> and WirelessHART including ISA100.11a <xref target="ISA100.11a" format="default" section
<xref target='WirelessHART'/>, have demonstrated the capabilities Format="of" derivedContent="ISA100.11a"/> and WirelessHART
of the IEEE Std. 802.15.4 TSCH MAC for high reliability against interfe <xref target="WirelessHART" format="default" sectionFormat="of" derived
rence, Content="WirelessHART"/>, have demonstrated the capabilities
of the IEEE Std 802.15.4 TSCH MAC for high reliability against interfer
ence,
low-power consumption on well-known flows, and its applicability for low-power consumption on well-known flows, and its applicability for
Traffic Engineering (TE) from a central controller. Traffic Engineering (TE) from a central controller.
</t> </t>
<t>To enable the convergence of Information Technology (IT) and <t indent="0" pn="section-1-6">To enable the convergence of information te
Operational Technology (OT) in Low-Power Lossy chnology (IT) and
Networks (LLNs), the 6TiSCH Architecture supports an IETF suite of operational technology (OT) in Low-Power and Lossy
protocols over the IEEE Std. 802.15.4 TSCH MAC to provide Networks (LLNs), the 6TiSCH architecture supports an IETF suite of
protocols over the IEEE Std 802.15.4 TSCH MAC to provide
IP connectivity for energy and otherwise constrained wireless devices. IP connectivity for energy and otherwise constrained wireless devices.
</t> </t>
<t> <t indent="0" pn="section-1-7">
The 6TiSCH Architecture relies on IPv6 <xref target='RFC8200'/> and the The 6TiSCH architecture relies on IPv6 <xref target="RFC8200" format="d
efault" sectionFormat="of" derivedContent="RFC8200"/> and the
use of routing to provide large scaling capabilities. The addition of a use of routing to provide large scaling capabilities. The addition of a
high-speed federating backbone adds yet another degree of scalability high-speed federating backbone adds yet another degree of scalability
to the design. The backbone is typically a Layer-2 transit Link such as to the design. The backbone is typically a Layer 2 transit link such as
an Ethernet bridged network, but it can also be a more complex routed an Ethernet bridged network, but it can also be a more complex routed
structure. structure.
</t> </t>
<t> <t indent="0" pn="section-1-8">
The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model that The 6TiSCH architecture introduces an IPv6 multi-link subnet model that
is composed of a federating backbone and a number of IEEE Std. 802.15.4 is composed of a federating backbone and a number of IEEE Std 802.15.4
TSCH low-power wireless networks federated and synchronized by Backbone TSCH low-power wireless networks federated and synchronized by Backbone
Routers. If the backbone is a Layer-2 transit Link then the Backbone Routers. If the backbone is a Layer 2 transit link, then the Backbone
Routers can operate as an IPv6 Neighbor Discovery (IPv6 ND) Routers can operate as an IPv6 Neighbor Discovery (IPv6 ND) proxy
<xref target='RFC4861'/> proxy. <xref target="RFC4861" format="default" sectionFormat="of" derivedConte
</t> nt="RFC4861"/>.
<t> </t>
<t indent="0" pn="section-1-9">
The 6TiSCH The 6TiSCH architecture leverages 6LoWPAN <xref target="RFC4944" format
Architecture leverages 6LoWPAN <xref target='RFC4944'/> to adapt IPv6 ="default" sectionFormat="of" derivedContent="RFC4944"/> to adapt IPv6
to the constrained media and RPL <xref target='RFC6550'/> for the to the constrained media and the
Routing Protocol for Low-Power and Lossy Networks (RPL) <xref target="
RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> for the
distributed routing operations. distributed routing operations.
</t> </t>
<t> <t indent="0" pn="section-1-10">
Centralized routing refers to a model where routes are computed Centralized routing refers to a model where routes are computed
and resources are allocated from a central controller. This is and resources are allocated from a central controller. This is
particularly helpful to schedule deterministic multihop transmissions. particularly helpful to schedule deterministic multihop transmissions.
In contrast, Distributed Routing refers to a model that relies on In contrast, distributed routing refers to a model that relies on
concurrent peer to peer protocol exchanges for TSCH resource allocation concurrent peer-to-peer protocol exchanges for TSCH resource allocation
and routing operations. and routing operations.
</t> </t>
<t> <t indent="0" pn="section-1-11">
The architecture defines mechanisms to establish and maintain routing The architecture defines mechanisms to establish and maintain routing
and scheduling in a centralized, distributed, or mixed fashion, for use and scheduling in a centralized, distributed, or mixed fashion, for use
in multiple OT environments. It is applicable in particular to highly in multiple OT environments. It is applicable in particular to highly
scalable solutions such as used in Advanced Metering Infrastructure scalable solutions such as those used in Advanced Metering Infrastructu
<xref target='AMI'/> solutions that leverage distributed routing to re
<xref target="AMI" format="default" sectionFormat="of" derivedContent="
AMI"/> solutions that leverage distributed routing to
enable multipath forwarding over large LLN meshes. enable multipath forwarding over large LLN meshes.
</t> </t>
</section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<section><name>Terminology</name> <section anchor="sixTTerminology" numbered="true" removeInRFC="false" toc=
<!-- "include" pn="section-2.1">
<section anchor='bcp' title="BCP 14"> <name slugifiedName="name-new-terms">New Terms</name>
<t>- <t indent="0" pn="section-2.1-1">
The document does not reuse terms from the <xref target="IEEE802154"
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", format="default" sectionFormat="of" derivedContent="IEEE802154">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IEEE Std 802.15.4</xref> standard such as "path" or "link", which be
"OPTIONAL" in this document are to be interpreted as described in BCP 14 ar
<xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
</t>
</section> end section "BCP 14" -->
<section anchor='sixTTerminology'><name>New Terms</name>
<t>
The draft does not reuse terms from the <xref target='IEEE802154'>
IEEE Std. 802.15.4</xref> standard such as "path" or "link" which be
ar
a meaning that is quite different from classical IETF parlance. a meaning that is quite different from classical IETF parlance.
</t> </t>
<t> <t indent="0" pn="section-2.1-2">This document adds the following terms:
This document adds the following terms: </t>
</t><dl spacing='normal'> <dl spacing="normal" indent="3" newline="false" pn="section-2.1-3">
<dt>6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4):</dt><dd> <dt pn="section-2.1-3.1">6TiSCH (IPv6 over the TSCH mode of IEEE 802.1
5.4):</dt>
<dd pn="section-2.1-3.2">
6TiSCH defines an adaptation sublayer for IPv6 over TSCH calle d 6top, 6TiSCH defines an adaptation sublayer for IPv6 over TSCH calle d 6top,
a set of protocols for setting up a TSCH schedule in distribute d a set of protocols for setting up a TSCH schedule in distribute d
approach, and a security solution. 6TiSCH may be extended in th e future for other approach, and a security solution. 6TiSCH may be extended in th e future for other
MAC/PHY pairs providing a service similar to TSCH. MAC/Physical Layer (PHY) pairs providing a service similar to T SCH.
</dd> </dd>
<dt>6top (6TiSCH Operation Sublayer):</dt><dd> <dt pn="section-2.1-3.3">6top (6TiSCH Operation Sublayer):</dt>
The next higher layer of the IEEE Std. 802.15.4 TSCH MAC layer. <dd pn="section-2.1-3.4">
The next higher layer of the IEEE Std 802.15.4 TSCH MAC layer.
6top provides the abstraction of an IP link over a TSCH MAC, 6top provides the abstraction of an IP link over a TSCH MAC,
schedules packets over TSCH cells, and exposes a management schedules packets over TSCH cells, and exposes a management
interface to schedule TSCH cells. interface to schedule TSCH cells.
</dd> </dd>
<dt>6P (6top Protocol):</dt><dd> <dt pn="section-2.1-3.5">6P (6top Protocol):</dt>
The protocol defined in <xref target='RFC8480'/>. <dd pn="section-2.1-3.6">
6P enables Layer-2 peers to allocate, move or deallocate The protocol defined in <xref target="RFC8480" format="defau
lt" sectionFormat="of" derivedContent="RFC8480"/>.
6P enables Layer 2 peers to allocate, move, or de-allocate
cells in their respective schedules to communicate. cells in their respective schedules to communicate.
6P operates at the 6top layer. 6P operates at the 6top sublayer.
</dd> </dd>
<dt>6P Transaction:</dt><dd> <dt pn="section-2.1-3.7">6P transaction:</dt>
A 2-way or 3-way sequence of 6P messages used by Layer-2 <dd pn="section-2.1-3.8">
A 2-way or 3-way sequence of 6P messages used by Layer 2
peers to modify their communication schedule. peers to modify their communication schedule.
</dd> </dd>
<dt>ASN (Absolute Slot Number):</dt><dd> <dt pn="section-2.1-3.9">ASN (Absolute Slot Number):</dt>
Defined in <xref target='IEEE802154'/>, the ASN is the total <dd pn="section-2.1-3.10">
number of timeslots that have elapsed since the Epoch Time Defined in <xref target="IEEE802154" format="default" sectio
nFormat="of" derivedContent="IEEE802154"/>, the ASN is the total
number of timeslots that have elapsed since the Epoch time
when the TSCH network started. when the TSCH network started.
Incremented by one at each timeslot. Incremented by one at each timeslot.
It is wide enough to not roll over in practice. It is wide enough to not roll over in practice.
</dd> </dd>
<!-- <dt pn="section-2.1-3.11">bundle:</dt>
<t hangText="blacklist of frequencies:"> <dd pn="section-2.1-3.12">
A set of frequencies which should not be used for
communication.
</t>
<t hangText="broadcast cell:">
A scheduled cell used for broadcast transmission.
</t> -->
<dt>bundle:</dt><dd>
A group of equivalent scheduled cells, i.e., cells A group of equivalent scheduled cells, i.e., cells
identified by different [slotOffset, channelOffset], identified by different slotOffset/channelOffset,
which are scheduled for a same purpose, with the same which are scheduled for a same purpose, with the same
neighbor, with the same flags, and the same slotframe. neighbor, with the same flags, and the same slotframe.
The size of the bundle refers to the number of cells it The size of the bundle refers to the number of cells it
contains. contains.
For a given slotframe length, the size of the bundle For a given slotframe length, the size of the bundle
translates directly into bandwidth. translates directly into bandwidth.
A bundle is a local abstraction that represents a A bundle is a local abstraction that represents a
half-duplex link for either sending or receiving, half-duplex link for either sending or receiving,
with bandwidth that amounts to the sum of the cells in the with bandwidth that amounts to the sum of the cells in the
bundle. bundle.
</dd> </dd>
<dt>Layer-2 vs. Layer-3 bundle:</dt><dd> <dt pn="section-2.1-3.13">Layer 2 vs. Layer 3 bundle:</dt>
Bundles are associated for either Layer-2 (switching) or <dd pn="section-2.1-3.14">
Layer-3 (routing) forwarding operations. A pair of Layer-3 Bundles are associated with either Layer 2 (switching) or
bundles (one for each direction) maps to an IP Link with a Layer 3 (routing) forwarding operations. A pair of Layer 3
neighbor, whereas a set of Layer-2 bundles (of an bundles (one for each direction) maps to an IP link with a
"arbitrary" cardinality and direction) corresponds to the re neighbor, whereas a set of Layer 2 bundles (of an
lation of one or more incoming bundle(s) from the "arbitrary" cardinality and direction) corresponds to the re
lation
of one or more incoming bundle(s) from the
previous-hop neighbor(s) with one or more outgoing bundle(s) previous-hop neighbor(s) with one or more outgoing bundle(s)
to the next-hop neighbor(s) along a Track as part of the to the next-hop neighbor(s) along a Track as part of the
switching role, which may include replication and eliminatio n. switching role, which may include replication and eliminatio n.
</dd> </dd>
<dt>CCA (Clear Channel Assessment):</dt><dd> <dt pn="section-2.1-3.15">CCA (Clear Channel Assessment):</dt>
A mechanism defined in <xref target='IEEE802154'/> whereby <dd pn="section-2.1-3.16">
A mechanism defined in <xref target="IEEE802154" format="def
ault" sectionFormat="of" derivedContent="IEEE802154"/> whereby
nodes listen to the channel before sending to nodes listen to the channel before sending to
detect ongoing transmissions from other parties. detect ongoing transmissions from other parties.
Because the network is synchronized, CCA cannot be used to Because the network is synchronized, CCA cannot be used to
detect colliding transmissions within the same network, but detect colliding transmissions within the same network, but
it can be used to detect other radio networks in vicinity. it can be used to detect other radio networks in the vicinit y.
</dd> </dd>
<dt>cell:</dt><dd> <dt pn="section-2.1-3.17">cell:</dt>
<dd pn="section-2.1-3.18">
A unit of transmission resource in the CDU matrix, a cell is A unit of transmission resource in the CDU matrix, a cell is
identified by a slotOffset and a channelOffset. identified by a slotOffset and a channelOffset.
A cell can be scheduled or unscheduled. A cell can be scheduled or unscheduled.
</dd> </dd>
<dt>Channel Distribution/Usage (CDU) matrix:</dt><dd>: <dt pn="section-2.1-3.19">Channel Distribution/Usage (CDU) matrix:</dt
>
<dd pn="section-2.1-3.20">:
A matrix of cells (i,j) representing the spectrum (channel) A matrix of cells (i,j) representing the spectrum (channel)
distribution among the different nodes in the 6TiSCH network . distribution among the different nodes in the 6TiSCH network .
The CDU matrix has width in timeslots, equal to the period The CDU matrix has width in timeslots equal to the period
of the network scheduling operation, and height equal to of the network scheduling operation, and height equal to
the number of available channels. the number of available channels.
Every cell (i,j) in the CDU, identified by (slotOffset, Every cell (i,j) in the CDU, identified by slotOffset/channe
channelOffset), belongs to a specific chunk. lOffset,
belongs to a specific chunk.
</dd> </dd>
<dt>channelOffset:</dt><dd> <dt pn="section-2.1-3.21">channelOffset:</dt>
<dd pn="section-2.1-3.22">
Identifies a row in the TSCH schedule. The number of Identifies a row in the TSCH schedule. The number of
channelOffset values is bounded by the number of available channelOffset values is bounded by the number of available
frequencies. The channelOffset translates into a frequency frequencies. The channelOffset translates into a frequency
with a function that depends on the absolute time when the with a function that depends on the absolute time when the
communication takes place, resulting in a channel hopping communication takes place, resulting in a channel-hopping
operation. operation.
</dd> </dd>
<dt>chunk:</dt><dd> <dt pn="section-2.1-3.23">chunk:</dt>
<dd pn="section-2.1-3.24">
A well-known list of cells, distributed in time and frequenc y, within a CDU matrix. A well-known list of cells, distributed in time and frequenc y, within a CDU matrix.
A chunk represents a portion of a CDU matrix. A chunk represents a portion of a CDU matrix.
The partition of the CDU matrix in chunks is globally known by all the nodes in the network to support the appropriation process, which is a negotiation between nodes within an interference domain. The partition of the CDU matrix in chunks is globally known by all the nodes in the network to support the appropriation process, which is a negotiation between nodes within an interference domain.
A node that manages to appropriate a chunk gets to decide wh ich transmissions will occur over the cells in the chunk within its interference domain, i.e., a parent node will decide when the cells within the appropriated chunk are used and by which node, among its children. A node that manages to appropriate a chunk gets to decide wh ich transmissions will occur over the cells in the chunk within its interference domain, i.e., a parent node will decide when the cells within the appropriated chunk are used and by which node among its children.
</dd> </dd>
<dt>CoJP (Constrained Join Protocol):</dt><dd> <dt pn="section-2.1-3.25">CoJP (Constrained Join Protocol):</dt>
<dd pn="section-2.1-3.26">
<!--
CoJP is a one-touch join protocol defined in the
<xref target="I-D.ietf-6tisch-minimal-security">
Minimal Security Framework for 6TiSCH</xref>.
CoJP requires the distribution of preshared keys (PSK), and
enables a node to join with a single round trip
to the JRC via the JP.
-->
The Constrained Join Protocol (CoJP) enables a pledge to The Constrained Join Protocol (CoJP) enables a pledge to
securely join a 6TiSCH network and obtain network parameters securely join a 6TiSCH network and obtain network parameters
over a secure channel. over a secure channel.
<!-- "<xref target="RFC9031" format="title" sectionFormat="of" de
CoJP is defined in the rivedContent="Constrained Join Protocol (CoJP) for 6TiSCH"/>" <xref target="RFC9
<xref target="I-D.ietf-6tisch-minimal-security"> 031" format="default" sectionFormat="of" derivedContent="RFC9031"/> defines
Minimal Security Framework for 6TiSCH </xref>.
-->
<xref target='I-D.ietf-6tisch-minimal-security'>
Minimal Security Framework for 6TiSCH </xref> defines
the minimal CoJP setup with pre-shared keys defined. In that the minimal CoJP setup with pre-shared keys defined. In that
mode, CoJP can operate with a single round trip exchange. mode, CoJP can operate with a single round-trip exchange.
</dd> </dd>
<dt>dedicated cell:</dt><dd> <dt pn="section-2.1-3.27">dedicated cell:</dt>
<dd pn="section-2.1-3.28">
A cell that is reserved for a given node to transmit to a sp ecific neighbor. A cell that is reserved for a given node to transmit to a sp ecific neighbor.
</dd> </dd>
<dt>deterministic network:</dt><dd> <dt pn="section-2.1-3.29">deterministic network:</dt>
The generic concept of deterministic network is defined in t <dd pn="section-2.1-3.30">
he <xref target='RFC8655'>"DetNet Architecture"</xref> document. The generic concept of a deterministic network is defined
When applied to 6TiSCH, it refers to the reservation of Trac in the <xref target="RFC8655" format="default" sectionFormat
ks which guarantees an end-to-end latency and optimizes the Packet Delivery Rati ="of" derivedContent="RFC8655">"Deterministic Networking Architecture"</xref> do
o (PDR) for well-characterized flows. cument.
When applied to 6TiSCH, it refers to the reservation of Trac
ks,
which guarantees an end-to-end latency and optimizes the
Packet Delivery Ratio (PDR) for well-characterized flows.
</dd> </dd>
<dt>distributed cell reservation:</dt><dd> <dt pn="section-2.1-3.31">distributed cell reservation:</dt>
<dd pn="section-2.1-3.32">
A reservation of a cell done by one or more in-network enti ties. A reservation of a cell done by one or more in-network enti ties.
</dd> </dd>
<dt>distributed Track reservation:</dt><dd> <dt pn="section-2.1-3.33">distributed Track reservation:</dt>
<dd pn="section-2.1-3.34">
A reservation of a Track done by one or more in-network enti ties. A reservation of a Track done by one or more in-network enti ties.
</dd> </dd>
<dt>EB (Enhanced Beacon):</dt><dd> <dt pn="section-2.1-3.35">EB (Enhanced Beacon):</dt>
A special frame defined in <xref target='IEEE802154'/> <dd pn="section-2.1-3.36">
used by a node, including the JP, to announce the presence A special frame defined in <xref target="IEEE802154" format=
"default" sectionFormat="of" derivedContent="IEEE802154"/>
used by a node, including the Join Proxy (JP), to announce t
he presence
of the network. of the network.
It contains enough information for a pledge to synchronize t o the network. It contains enough information for a pledge to synchronize t o the network.
</dd> </dd>
<dt>hard cell:</dt><dd> <dt pn="section-2.1-3.37">hard cell:</dt>
A scheduled cell which the 6top sublayer may not relocate. <dd pn="section-2.1-3.38">
A scheduled cell that the 6top sublayer may not relocate.
</dd> </dd>
<dt>hopping sequence:</dt><dd> <dt pn="section-2.1-3.39">hopping sequence:</dt>
<dd pn="section-2.1-3.40">
Ordered sequence of frequencies, identified by a Hopping_Seq uence_ID, used for channel hopping when translating the channelOffset value into a frequency. Ordered sequence of frequencies, identified by a Hopping_Seq uence_ID, used for channel hopping when translating the channelOffset value into a frequency.
</dd> </dd>
<dt>IE (Information Element):</dt><dd> <dt pn="section-2.1-3.41">IE (Information Element):</dt>
Type-Length-Value containers placed at the end of the MAC he <dd pn="section-2.1-3.42">
ader, used to pass data between layers or devices. Type-Length-Value containers placed at the end of the MAC he
Some IE identifiers are managed by the IEEE <xref target='IE ader and used to pass data between layers or devices.
EE802154'/>. Some IE identifiers are managed by the IEEE <xref target="IE
Some IE identifiers are managed by the IETF <xref target='RF EE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"/>.
C8137'/>, and <xref target='I-D.ietf-6tisch-enrollment-enhanced-beacon'/> uses o Some IE identifiers are managed by the IETF <xref target="RF
ne subtype to support the selection of the Join Proxy. C8137" format="default" sectionFormat="of" derivedContent="RFC8137"/>. <xref tar
get="RFC9032" format="default" sectionFormat="of" derivedContent="RFC9032"/>
uses one subtype to support the selection of the Join Proxy.
</dd> </dd>
<dt>join process:</dt><dd> <dt pn="section-2.1-3.43">join process:</dt>
<dd pn="section-2.1-3.44">
The overall process that includes the discovery of the netwo rk by pledge(s) and the execution of the join protocol. The overall process that includes the discovery of the netwo rk by pledge(s) and the execution of the join protocol.
</dd> </dd>
<dt>join protocol:</dt><dd> <dt pn="section-2.1-3.45">join protocol:</dt>
<dd pn="section-2.1-3.46">
The protocol that allows the pledge to join the network. The protocol that allows the pledge to join the network.
The join protocol encompasses authentication, authorization and parameter distribution. The join protocol encompasses authentication, authorization, and parameter distribution.
The join protocol is executed between the pledge and the JRC . The join protocol is executed between the pledge and the JRC .
</dd> </dd>
<dt>joined node:</dt><dd> <dt pn="section-2.1-3.47">joined node:</dt>
The new device, after having completed the join process, oft <dd pn="section-2.1-3.48">
en just called a node. The new device after having completed the join process, ofte
n just called a node.
</dd> </dd>
<dt>JP (Join Proxy):</dt><dd> <dt pn="section-2.1-3.49">JP (Join Proxy):</dt>
Node already part of the 6TiSCH network that serves as a rel <dd pn="section-2.1-3.50">
ay to provide connectivity between the pledge and the JRC. A node already part of the 6TiSCH network that serves as a r
elay to provide connectivity between the pledge and the JRC.
The JP announces the presence of the network by regularly se nding EB frames. The JP announces the presence of the network by regularly se nding EB frames.
</dd> </dd>
<dt>JRC (Join Registrar/Coordinator):</dt><dd> <dt pn="section-2.1-3.51">JRC (Join Registrar/Coordinator):</dt>
Central entity responsible for the authentication, authoriza <dd pn="section-2.1-3.52">
tion and configuration of the pledge. Central entity responsible for the authentication, authoriza
tion, and configuration of the pledge.
</dd> </dd>
<dt pn="section-2.1-3.53">link:</dt>
<dt>link:</dt><dd> <dd pn="section-2.1-3.54">
A communication facility or medium over which nodes can comm A communication facility or medium over which nodes can comm
unicate at the Link-Layer, the layer immediately below IP. In 6TiSCH, the concep unicate
t is implemented as a collection at the link layer, which is the layer immediately below IP.
of Layer-3 bundles. Note: In 6TiSCH, the concept is implemented as a collection
the IETF parlance for the term "Link" is adopted, as opposed of Layer 3 bundles. Note:
to the IEEE Std. 802.15.4 terminology. the IETF parlance for the term "link" is adopted, as opposed
to the IEEE Std 802.15.4 terminology.
</dd> </dd>
<dt>Operational Technology:</dt><dd> <dt pn="section-2.1-3.55">operational technology:</dt>
<dd pn="section-2.1-3.56">
OT refers to technology used in automation, for instance in OT refers to technology used in automation, for instance in
industrial control networks. The convergence of IT and OT is industrial control networks. The convergence of IT and OT is
the main object of the Industrial Internet of Things (IIOT). the main object of the Industrial Internet of Things (IIOT).
</dd> </dd>
<dt>pledge:</dt><dd> <dt pn="section-2.1-3.57">pledge:</dt>
<dd pn="section-2.1-3.58">
A new device that attempts to join a 6TiSCH network. A new device that attempts to join a 6TiSCH network.
</dd> </dd>
<dt>(to) relocate a cell:</dt><dd> <dt pn="section-2.1-3.59">(to) relocate a cell:</dt>
<dd pn="section-2.1-3.60">
The action operated by the 6top sublayer of changing the slo tOffset and/or channelOffset of a soft cell. The action operated by the 6top sublayer of changing the slo tOffset and/or channelOffset of a soft cell.
</dd> </dd>
<dt>(to) schedule a cell:</dt><dd> <dt pn="section-2.1-3.61">(to) schedule a cell:</dt>
<dd pn="section-2.1-3.62">
The action of turning an unscheduled cell into a scheduled c ell. The action of turning an unscheduled cell into a scheduled c ell.
</dd> </dd>
<dt>scheduled cell:</dt><dd> <dt pn="section-2.1-3.63">scheduled cell:</dt>
A cell which is assigned a neighbor MAC address (broadcast a <dd pn="section-2.1-3.64">
ddress is also possible), and one or more of the following flags: TX, RX, Shared A cell that is assigned a neighbor MAC address
and Timekeeping. (broadcast address is also possible) and one or
A scheduled cell can be used by the IEEE Std. 802.15.4 TSCH more of the following flags: TX, RX, Shared, and Timekeeping
implementation to communicate. .
A scheduled cell can be used by the IEEE Std 802.15.4 TSCH i
mplementation to communicate.
A scheduled cell can either be a hard or a soft cell. A scheduled cell can either be a hard or a soft cell.
</dd> </dd>
<dt>SF (6top Scheduling Function):</dt><dd> <dt pn="section-2.1-3.65">SF (6top Scheduling Function):</dt>
<dd pn="section-2.1-3.66">
The cell management entity that adds or deletes cells dynami cally based on application networking requirements. The cell management entity that adds or deletes cells dynami cally based on application networking requirements.
The cell negotiation with a neighbor is done using 6P. The cell negotiation with a neighbor is done using 6P.
</dd> </dd>
<dt>SFID (6top Scheduling Function Identifier):</dt><dd> <dt pn="section-2.1-3.67">SFID (6top Scheduling Function Identifier):<
/dt>
<dd pn="section-2.1-3.68">
A 4-bit field identifying an SF. A 4-bit field identifying an SF.
</dd> </dd>
<dt>shared cell:</dt><dd> <dt pn="section-2.1-3.69">shared cell:</dt>
A cell marked with both the "TX" and "shared" flags. <dd pn="section-2.1-3.70">
A cell marked with both the TX and Shared flags.
This cell can be used by more than one transmitter node. This cell can be used by more than one transmitter node.
A back-off algorithm is used to resolve contention. A back-off algorithm is used to resolve contention.
</dd> </dd>
<dt>slotframe:</dt><dd> <dt pn="section-2.1-3.71">slotframe:</dt>
<dd pn="section-2.1-3.72">
A collection of timeslots repeating in time, analogous to a superframe in that it defines periods of communication opportunities. A collection of timeslots repeating in time, analogous to a superframe in that it defines periods of communication opportunities.
It is characterized by a slotframe_ID, and a slotframe_size. It is characterized by a slotframe_ID and a slotframe_size.
Multiple slotframes can coexist in a node's schedule, i.e., Multiple slotframes can coexist in a node's schedule,
a node can have multiple activities scheduled in different slotframes, based on i.e., a node can have multiple activities scheduled in
the priority of its packets/traffic flows. different slotframes based on the priority of its packets/tr
The timeslots in the Slotframe are indexed by the SlotOffset affic flows.
; the first timeslot is at SlotOffset 0. The timeslots in the slotframe are indexed by the slotOffset
; the first timeslot is at slotOffset 0.
</dd> </dd>
<dt>slotOffset:</dt><dd> <dt pn="section-2.1-3.73">slotOffset:</dt>
<dd pn="section-2.1-3.74">
A column in the TSCH schedule, i.e., the number of timeslots since the beginning of the current iteration of the slotframe. A column in the TSCH schedule, i.e., the number of timeslots since the beginning of the current iteration of the slotframe.
</dd> </dd>
<dt>soft cell:</dt><dd> <dt pn="section-2.1-3.75">soft cell:</dt>
A scheduled cell which the 6top sublayer can relocate. <dd pn="section-2.1-3.76">
A scheduled cell that the 6top sublayer can relocate.
</dd> </dd>
<dt>time source neighbor:</dt><dd> <dt pn="section-2.1-3.77">time source neighbor:</dt>
<dd pn="section-2.1-3.78">
A neighbor that a node uses as its time reference, and to wh ich it needs to keep its clock synchronized. A neighbor that a node uses as its time reference, and to wh ich it needs to keep its clock synchronized.
</dd> </dd>
<dt>timeslot:</dt><dd> <dt pn="section-2.1-3.79">timeslot:</dt>
A basic communication unit in TSCH which allows <dd pn="section-2.1-3.80">
a transmitter node to send a frame to a receiver neighbo A basic communication unit in TSCH that allows
r, and a transmitter node to send a frame to a receiver neighbo
that receiver neighbor to optionally send back an acknow r and
ledgment. that allows the receiver neighbor to optionally send bac
k an acknowledgment.
</dd> </dd>
<dt>Track:</dt><dd> <dt pn="section-2.1-3.81">Track:</dt>
<dd pn="section-2.1-3.82">
A Track is a Directed Acyclic Graph (DAG) that is used as a A Track is a Directed Acyclic Graph (DAG) that is used as a
complex multi-hop path to the destination(s) of the path. complex multihop path to the destination(s) of the path.
In the case of unicast traffic, the Track is a Destination In the case of unicast traffic, the Track is a Destination-O
Oriented DAG (DODAG) where the Root of the DODAG is the riented DAG (DODAG) where the Root of the DODAG is the
destination of the unicast traffic. destination of the unicast traffic.
A Track enables replication, elimination and reordering func A Track enables replication, elimination, and reordering fun
tions on the way (more on those functions in ctions on the way (more on those functions in
<xref target='RFC8655'/>. <xref target="RFC8655" format="default" sectionFormat="of" d
erivedContent="RFC8655"/>).
A Track reservation locks physical resources such as cells a nd buffers in every node along the DODAG. A Track reservation locks physical resources such as cells a nd buffers in every node along the DODAG.
A Track is associated with a owner that can be for instance the destination of the Track. A Track is associated with an owner, which can be for instan ce the destination of the Track.
</dd> </dd>
<dt>TrackID:</dt><dd> <dt pn="section-2.1-3.83">TrackID:</dt>
A TrackID is either globally unique, or locally unique to th <dd pn="section-2.1-3.84">
e Track owner, A TrackID is either globally unique or locally unique to the
Track owner,
in which case the identification of the owner must be provid ed together with the TrackID in which case the identification of the owner must be provid ed together with the TrackID
to provide a full reference to the Track. typically, the Tra to provide a full reference to the Track. Typically, the Tra
ck owner is the ingress of the Track then the IPv6 source address of packets alo ck owner is the ingress of the
ng the Track can be used as Track, the IPv6 source address of packets along the Track ca
identification of the owner and a local InstanceID <xref tar n be used as
get='RFC6550'/> identification of the owner, and a local InstanceID <xref ta
in the namespace of that owner can be used as TrackID. If th rget="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/>
e Track is reversible, then in the namespace of that owner can be used as TrackID.
the owner is found in the IPv6 destination address of a pack If the Track is reversible, then the owner is found in
et coming back along the Track. the IPv6 destination address of a packet coming back along t
In that case, a RPL Packet Information <xref target='RFC6550 he Track.
'/> in an IPv6 packet In that case, a RPL Packet Information <xref target="RFC6550
" format="default" sectionFormat="of" derivedContent="RFC6550"/> in an IPv6 pack
et
can unambiguously identify the Track and can be expressed in a compressed form using can unambiguously identify the Track and can be expressed in a compressed form using
<xref target='RFC8138'/>. <xref target="RFC8138" format="default" sectionFormat="of" d erivedContent="RFC8138"/>.
</dd> </dd>
<dt>TSCH:</dt><dd> <dt pn="section-2.1-3.85">TSCH:</dt>
A medium access mode of the <xref target='IEEE802154'> <dd pn="section-2.1-3.86">
IEEE Std. 802.15.4</xref> standard which uses A medium access mode of the <xref target="IEEE802154" format
time synchronization to achieve ultra-low-power operation, a ="default" sectionFormat="of" derivedContent="IEEE802154">
nd IEEE Std 802.15.4</xref> standard that uses
time synchronization to achieve ultra-low-power operation an
d
channel hopping to enable high reliability. channel hopping to enable high reliability.
</dd> </dd>
<dt>TSCH Schedule:</dt><dd> <dt pn="section-2.1-3.87">TSCH Schedule:</dt>
A matrix of cells, each cell indexed by a slotOffset and a c <dd pn="section-2.1-3.88">
hannelOffset. A matrix of cells, with each cell indexed by a slotOffset an
The TSCH schedule contains all the scheduled cells from all d a channelOffset.
slotframes and is sufficient to qualify the communication in the TSCH network. 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 matr ix) is equal to the number of available frequencies. The number of channelOffset values (the "height" of the matr ix) is equal to the number of available frequencies.
</dd> </dd>
<dt>Unscheduled Cell:</dt><dd> <dt pn="section-2.1-3.89">Unscheduled Cell:</dt>
A cell which is not used by the IEEE Std. 802.15.4 TSCH impl <dd pn="section-2.1-3.90">
ementation. A cell that is not used by the IEEE Std 802.15.4 TSCH implem
entation.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor='acronyms'><name>Abbreviations</name> <section anchor="acronyms" numbered="true" removeInRFC="false" toc="includ
<t> This document uses the following abbreviations: e" pn="section-2.2">
</t><dl spacing='normal'> <name slugifiedName="name-abbreviations">Abbreviations</name>
<dt>6BBR:</dt><dd> 6LoWPAN Backbone Router (router with a proxy ND functi <t indent="0" pn="section-2.2-1"> This document uses the following abbre
on) </dd> viations:
<dt>6LBR:</dt><dd> 6LoWPAN Border Router (authoritative on DAD) </dd> </t>
<dt>6LN:</dt><dd> 6LoWPAN Node </dd> <dl spacing="normal" indent="3" newline="false" pn="section-2.2-2">
<dt>6LR:</dt><dd> 6LoWPAN Router (relay to the registration process) </dd <dt pn="section-2.2-2.1">6BBR:</dt>
> <dd pn="section-2.2-2.2"> 6LoWPAN Backbone Router (router with a proxy
<dt>6CIO:</dt><dd> Capability Indication Option </dd> ND function) </dd>
<dt pn="section-2.2-2.3">6LBR:</dt>
<dt>(E)ARO:</dt><dd> (Extended) Address Registration Option </dd> <dd pn="section-2.2-2.4"> 6LoWPAN Border Router (authoritative on Dupl
<dt>(E)DAR:</dt><dd> (Extended) Duplicate Address Request </dd> icate Address Detection (DAD)) </dd>
<dt>(E)DAC:</dt><dd> (Extended) Duplicate Address Confirmation </dd> <dt pn="section-2.2-2.5">6LN:</dt>
<dd pn="section-2.2-2.6"> 6LoWPAN Node </dd>
<dt>DAD:</dt><dd> Duplicate Address Detection </dd> <dt pn="section-2.2-2.7">6LR:</dt>
<dt>DODAG:</dt><dd> Destination-Oriented Directed Acyclic Graph <dd pn="section-2.2-2.8"> 6LoWPAN Router (relay to the registration pr
</dd> ocess) </dd>
<dt pn="section-2.2-2.9">6CIO:</dt>
<dt>LLN:</dt><dd> Low-Power and Lossy Network (a typical IoT network) </ <dd pn="section-2.2-2.10"> Capability Indication Option </dd>
dd> <dt pn="section-2.2-2.11">(E)ARO:</dt>
<dt>NA:</dt><dd> Neighbor Advertisement </dd> <dd pn="section-2.2-2.12"> (Extended) Address Registration Option </d
<dt>NCE:</dt><dd> Neighbor Cache Entry </dd> d>
<dt>ND:</dt><dd> Neighbor Discovery </dd> <dt pn="section-2.2-2.13">(E)DAR:</dt>
<dt>NDP:</dt><dd> Neighbor Discovery Protocol </dd> <dd pn="section-2.2-2.14"> (Extended) Duplicate Address Request </dd>
<dt>PCE:</dt><dd> Path Computation Element </dd> <dt pn="section-2.2-2.15">(E)DAC:</dt>
<dt>NME:</dt><dd> Network Management Entity </dd> <dd pn="section-2.2-2.16"> (Extended) Duplicate Address Confirmation <
<dt>ROVR:</dt><dd> Registration Ownership Verifier (pronounced rover) </d /dd>
d> <dt pn="section-2.2-2.17">DAD:</dt>
<dt>RPL:</dt><dd> IPv6 Routing Protocol for LLNs (pronounced ripple) </dd <dd pn="section-2.2-2.18"> Duplicate Address Detection </dd>
> <dt pn="section-2.2-2.19">DODAG:</dt>
<dt>RA:</dt><dd> Router Advertisement </dd> <dd pn="section-2.2-2.20"> Destination-Oriented Directed Acyclic Graph
<dt>RS:</dt><dd> Router Solicitation </dd> </dd>
<dt>TSCH:</dt><dd> timeslotted Channel Hopping </dd> <dt pn="section-2.2-2.21">LLN:</dt>
<dt>TID:</dt><dd> Transaction ID (a sequence counter in the EARO) </dd> <dd pn="section-2.2-2.22"> Low-Power and Lossy Network (a typical IoT
network) </dd>
</dl> <dt pn="section-2.2-2.23">NA:</dt>
</section> <!-- end section "Abbreviations" --> <dd pn="section-2.2-2.24"> Neighbor Advertisement </dd>
<dt pn="section-2.2-2.25">NCE:</dt>
<section anchor='lo'><name>Related Documents</name> <dd pn="section-2.2-2.26"> Neighbor Cache Entry </dd>
<dt pn="section-2.2-2.27">ND:</dt>
<t> <dd pn="section-2.2-2.28"> Neighbor Discovery </dd>
The draft also conforms to the terms and models described in <dt pn="section-2.2-2.29">NDP:</dt>
<xref target='RFC3444'/> and <xref target='RFC5889'/> and uses the <dd pn="section-2.2-2.30"> Neighbor Discovery Protocol </dd>
vocabulary and the concepts defined in <xref target='RFC4291'/> for the <dt pn="section-2.2-2.31">PCE:</dt>
IPv6 Architecture and refers <xref target='RFC4080'/> for reservation <dd pn="section-2.2-2.32"> Path Computation Element </dd>
<!-- signaling and <xref target="RFC5191"/> for authentication. --> <dt pn="section-2.2-2.33">NME:</dt>
<dd pn="section-2.2-2.34"> Network Management Entity </dd>
<dt pn="section-2.2-2.35">ROVR:</dt>
<dd pn="section-2.2-2.36"> Registration Ownership Verifier (pronounced
rover) </dd>
<dt pn="section-2.2-2.37">RPL:</dt>
<dd pn="section-2.2-2.38"> IPv6 Routing Protocol for LLNs (pronounced
ripple) </dd>
<dt pn="section-2.2-2.39">RA:</dt>
<dd pn="section-2.2-2.40"> Router Advertisement </dd>
<dt pn="section-2.2-2.41">RS:</dt>
<dd pn="section-2.2-2.42"> Router Solicitation </dd>
<dt pn="section-2.2-2.43">TSCH:</dt>
<dd pn="section-2.2-2.44"> Time-Slotted Channel Hopping </dd>
<dt pn="section-2.2-2.45">TID:</dt>
<dd pn="section-2.2-2.46"> Transaction ID (a sequence counter in the E
ARO) </dd>
</dl>
</section>
<section anchor="lo" numbered="true" removeInRFC="false" toc="include" pn=
"section-2.3">
<name slugifiedName="name-related-documents">Related Documents</name>
<t indent="0" pn="section-2.3-1">
The document conforms to the terms and models described in
<xref target="RFC3444" format="default" sectionFormat="of" derivedConte
nt="RFC3444"/> and <xref target="RFC5889" format="default" sectionFormat="of" de
rivedContent="RFC5889"/>, uses the
vocabulary and the concepts defined in <xref target="RFC4291" format="d
efault" sectionFormat="of" derivedContent="RFC4291"/> for the
IPv6 architecture, and refers to <xref target="RFC4080" format="default
" sectionFormat="of" derivedContent="RFC4080"/> for reservation.
</t> </t>
<t> <t indent="0" pn="section-2.3-2">
The draft uses domain-specific terminology defined or referenced in: The document uses domain-specific terminology defined or referenced
</t><ul empty='true' spacing='normal'> in the following:
<li> 6LoWPAN ND <xref target='RFC6775'>"Neighbor Discovery Optimization </t>
for Low-power and Lossy Networks"</xref> and <xref target='RFC8505'> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
"Registration Extensions for 6LoWPAN Neighbor Discovery"</xref>, .3-3">
<li pn="section-2.3-3.1">6LoWPAN ND:
<xref target="RFC6775" format="default" sectionFormat="of" derivedCont
ent="RFC6775">"Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)"</xref> and
<xref target="RFC8505" format="default" sectionFormat="of" derivedCont
ent="RFC8505">"Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Discovery"</xref>,
</li> </li>
<li><xref target='RFC7102'>"Terms Used in Routing for Low-Power <li pn="section-2.3-3.2">
and Lossy Networks (LLNs)"</xref>,</li> <xref target="RFC7102" format="default" sectionFormat="of" derivedCo
<li> and RPL ntent="RFC7102">"Terms Used in Routing for Low-Power and Lossy Networks"</xref>,
<xref target='RFC6552'>"Objective Function Zero for the and
Routing Protocol for Low-Power and Lossy Networks (RPL)" </li>
</xref>, and <li pn="section-2.3-3.3">RPL:
<xref target='RFC6550'>"RPL: IPv6 Routing Protocol for <xref target="RFC6552" format="default" sectionFormat="of" derivedCont
Low-Power and Lossy Networks"</xref>.</li> ent="RFC6552">"Objective Function Zero for the
</ul><t> Routing Protocol for Low-Power and Lossy Networks (RPL)"</xref> and
Other terms in use in LLNs are found in <xref target='RFC7228'> <xref target="RFC6550" format="default" sectionFormat="of" derivedCont
ent="RFC6550">"RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks"</xref>.
</li>
</ul>
<t indent="0" pn="section-2.3-4">
Other terms in use in LLNs are found in <xref target="RFC7228" format="defaul
t" sectionFormat="of" derivedContent="RFC7228">
"Terminology for Constrained-Node Networks"</xref>. "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 Discovery for IP version 6"
</xref>, and
<xref target='RFC4862'>"IPv6 Stateless Address Autoconfiguration"
</xref>.</li>
</ul><t>
</t> </t>
<t indent="0" pn="section-2.3-5">
<t>In addition, readers would benefit from reading: Readers are expected to be familiar with all the terms and concepts
</t><ul spacing='normal'> that are discussed in the following:
<li><xref target='RFC6606'>"Problem Statement and Requirements for </t>
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
</xref>,</li> .3-6">
<li> <xref target='RFC4903'>"Multi-Link Subnet Issues"</xref>, and </li> <li pn="section-2.3-6.1">
<li> <xref target='RFC4919'>"IPv6 over Low-Power <xref target="RFC4861" format="default" sectionFormat="of" derivedCo
ntent="RFC4861">"Neighbor Discovery for IP version 6 (IPv6)"</xref> and
</li>
<li pn="section-2.3-6.2">
<xref target="RFC4862" format="default" sectionFormat="of" derivedCo
ntent="RFC4862">"IPv6 Stateless Address Autoconfiguration"</xref>.
</li>
</ul>
<t indent="0" pn="section-2.3-7">In addition, readers would benefit from
reading the following
prior to this specification for a clear understanding of the art
in ND-proxying and binding:
</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
.3-8">
<li pn="section-2.3-8.1">
<xref target="RFC6606" format="default" sectionFormat="of" derivedCo
ntent="RFC6606">"Problem Statement and Requirements for
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing"</xref>
,
</li>
<li pn="section-2.3-8.2">
<xref target="RFC4903" format="default" sectionFormat="of" derivedCo
ntent="RFC4903">"Multi-Link Subnet Issues"</xref>, and
</li>
<li pn="section-2.3-8.3">
<xref target="RFC4919" format="default" sectionFormat="of" derivedCo
ntent="RFC4919">"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref></li> Problem Statement, and Goals"</xref>.
</ul><t> prior to this specification for a clear </li>
understanding of the art in ND-proxying and binding. </ul>
</t> </section>
</section> <!-- end section "References" --> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3">
</section> <!-- end section "Terminology" --> <name slugifiedName="name-high-level-architecture">High-Level Architecture
</name>
<section><name>High Level Architecture</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-3.1
">
<section><name>A Non-Broadcast Multi-Access Radio Mesh Network</name> <name slugifiedName="name-a-non-broadcast-multi-acces">A Non-broadcast M
ulti-access Radio Mesh Network</name>
<t> <t indent="0" pn="section-3.1-1">
A 6TiSCH network is an IPv6 <xref target='RFC8200'/> subnet which, in A 6TiSCH network is an IPv6 <xref target="RFC8200" format="default" sec
its basic configuration illustrated in <xref target='fig1'/>, is a tionFormat="of" derivedContent="RFC8200"/> subnet that, in
single Low-Power Lossy Network (LLN) operating over a synchronized its basic configuration illustrated in <xref target="fig1" format="defa
ult" sectionFormat="of" derivedContent="Figure 1"/>, is a
single Low-Power and Lossy Network (LLN) operating over a synchronized
TSCH-based mesh. TSCH-based mesh.
</t> </t>
<figure anchor="fig1" align="left" suppress-title="false" pn="figure-1">
<figure anchor='fig1'><name>Basic Configuration of a 6TiSCH Network</na <name slugifiedName="name-basic-configuration-of-a-6t">Basic Configura
me> tion of a 6TiSCH Network</name>
<artwork><![CDATA[ <artwork align="left" pn="section-3.1-2.1">
---+-------- ............ ------------ ---+-------- ............ ------------
| External Network | | External Network |
| +-----+ | +-----+
+-----+ | NME | +-----+ | NME |
| | LLN Border | PCE | | | LLN Border | PCE |
| | router (6LBR) +-----+ | | router (6LBR) +-----+
+-----+ +-----+
o o o o o o
o o o o o o o o o o
o o 6LoWPAN + RPL o o o o 6LoWPAN + RPL o o
o o o o o o o o
]]></artwork> </artwork>
</figure> </figure>
<t> <t indent="0" pn="section-3.1-3">
Inside a 6TiSCH LLN, nodes rely on <xref target='RFC6282'>6LoWPAN Inside a 6TiSCH LLN, nodes rely on <xref target="RFC6282" format="defau
Header Compression (6LoWPAN HC)</xref> to encode IPv6 packets. lt" sectionFormat="of" derivedContent="RFC6282">6LoWPAN
header compression (6LoWPAN HC)</xref> to encode IPv6 packets.
From the perspective of the network layer, a single LLN interface From the perspective of the network layer, a single LLN interface
(typically an IEEE Std. 802.15.4-compliant radio) may be seen as a coll (typically an IEEE Std 802.15.4-compliant radio) may be seen as a colle
ection ction
of Links with different capabilities for unicast or multicast services. of links with different capabilities for unicast or multicast services.
</t><t> </t>
<t indent="0" pn="section-3.1-4">
6TiSCH nodes join a mesh network by attaching to nodes that are already 6TiSCH nodes join a mesh network by attaching to nodes that are already
members of the mesh (see <xref target='rflo'/>). The security aspects members of the mesh (see <xref target="rflo" format="default" sectionFo
of the join process are further detailed in <xref target='sec'/>. rmat="of" derivedContent="Section 4.2.1"/>). The security aspects
of the join process are further detailed in <xref target="sec" format="
default" sectionFormat="of" derivedContent="Section 6"/>.
In a mesh network, 6TiSCH nodes are not necessarily reachable from one In a mesh network, 6TiSCH nodes are not necessarily reachable from one
another at Layer-2 and an LLN may span over multiple links. another at Layer 2, and an LLN may span over multiple links.
</t><t> </t>
<t indent="0" pn="section-3.1-5">
This forms a homogeneous non-broadcast multi-access (NBMA) subnet, This forms a homogeneous non-broadcast multi-access (NBMA) subnet,
which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND)
<xref target='RFC4861'/><xref target='RFC4862'/>. 6LoWPAN Neighbor <xref target="RFC4861" format="default" sectionFormat="of" derivedConte
Discovery (6LoWPAN ND) <xref target='RFC6775'/><xref target='RFC8505'/> nt="RFC4861"/> <xref target="RFC4862" format="default" sectionFormat="of" derive
dContent="RFC4862"/>. 6LoWPAN Neighbor
Discovery (6LoWPAN ND) <xref target="RFC6775" format="default" sectionF
ormat="of" derivedContent="RFC6775"/> <xref target="RFC8505" format="default" se
ctionFormat="of" derivedContent="RFC8505"/>
specifies extensions to IPv6 ND that enable ND operations in this type specifies extensions to IPv6 ND that enable ND operations in this type
of subnet that can be protected against address theft and impersonation of subnet that can be protected against address theft and impersonation
with <xref target='I-D.ietf-6lo-ap-nd'/>. with <xref target="RFC8928" format="default" sectionFormat="of" derived
</t> Content="RFC8928"/>.
<t> </t>
Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses <t indent="0" pn="section-3.1-6">
and register them using 6LoWPAN ND. This guarantees that the addresses Once it has joined the 6TiSCH network, a node acquires IPv6 addresses
and registers them using 6LoWPAN ND. This guarantees that the addresses
are unique and protects the address ownership over the subnet, more in are unique and protects the address ownership over the subnet, more in
<xref target='rreg'/>. <xref target="rreg" format="default" sectionFormat="of" derivedContent=
</t> "Section 4.2.2"/>.
<t> </t>
Within the NBMA subnet, <xref target='RFC6550'>RPL</xref> enables <t indent="0" pn="section-3.1-7">
routing in the so-called Route Over fashion, either in storing Within the NBMA subnet, <xref target="RFC6550" format="default" section
Format="of" derivedContent="RFC6550">RPL</xref> enables
routing in the so-called "route-over" fashion, either in storing
(stateful) or non-storing (stateless, with routing headers) mode. (stateful) or non-storing (stateless, with routing headers) mode.
From there, some nodes can act as routers for 6LoWPAN ND and RPL From there, some nodes can act as routers for 6LoWPAN ND and RPL
operations, as detailed in <xref target='RPLvs6lo'/>. operations, as detailed in <xref target="RPLvs6lo" format="default" sec
</t><t> tionFormat="of" derivedContent="Section 4.1"/>.
With TSCH, devices are time-synchronized at the MAC level. The use of </t>
<t indent="0" pn="section-3.1-8">
With TSCH, devices are time synchronized at the MAC level. The use of
a particular RPL Instance for time synchronization is discussed in a particular RPL Instance for time synchronization is discussed in
<xref target='sync'/>. With this mechanism, the time synchronization <xref target="sync" format="default" sectionFormat="of" derivedContent= "Section 4.3.4"/>. With this mechanism, the time synchronization
starts at the RPL Root and follows the RPL loopless routing topology. starts at the RPL Root and follows the RPL loopless routing topology.
</t><t> </t>
RPL forms Destination Oriented <t indent="0" pn="section-3.1-9">
RPL forms Destination-Oriented
Directed Acyclic Graphs (DODAGs) within Instances of the protocol, Directed Acyclic Graphs (DODAGs) within Instances of the protocol,
each Instance being associated with an Objective Function (OF) to each Instance being associated with an Objective Function (OF) to
form a routing topology. A particular 6TiSCH node, the LLN Border Route r form a routing topology. A particular 6TiSCH node, the LLN Border Route r
(6LBR), acts as RPL Root, 6LoWPAN HC terminator, and Border Router (6LBR), acts as RPL Root, 6LoWPAN HC terminator, and Border Router
for the LLN to the outside. The 6LBR is usually powered. for the LLN to the outside. The 6LBR is usually powered.
More on RPL Instances can be found in section 3.1 of More on RPL Instances can be found in Section
<xref target='RFC6550'>RPL</xref>, in particular <xref target="RFC6550" section="3.1" sectionFormat="bare" format="defau
"3.1.2. RPL Identifiers" and lt" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1" derivedContent=
"3.1.3. Instances, DODAGs, and DODAG Versions". RPL adds artifacts in "RFC6550"/> of
the data packets that are compressed with a 6LoWPAN addition <xref target="RFC6550" format="default" sectionFormat="of" derivedConte
<xref target='RFC8138'>6LoRH</xref>. nt="RFC6550">RPL</xref>, in particular
</t><t> "<xref target="RFC6550" section="3.1.2" sectionFormat="bare" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1.2" derivedCon
tent="RFC6550"/> RPL Identifiers" and
"<xref target="RFC6550" section="3.1.3" sectionFormat="bare" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1.3" derivedCon
tent="RFC6550"/> Instances, DODAGs, and DODAG Versions".
RPL adds artifacts in
the data packets that are compressed with a
<xref target="RFC8138" format="default" sectionFormat="of" derivedConte
nt="RFC8138">6LoWPAN Routing Header (6LoRH)</xref>.
In a preexisting network, the compression can be globally turned on in
a
DODAG once all nodes are migrated to support <xref target="RFC8138" for
mat="default" sectionFormat="of" derivedContent="RFC8138"/>
using <xref target="RFC9035" format="default" sectionFormat="of" derive
dContent="RFC9035"/>.
</t>
<t indent="0" pn="section-3.1-10">
Additional routing and scheduling protocols may be deployed to Additional routing and scheduling protocols may be deployed to
establish on-demand Peer-to-Peer routes with particular characteristics establish on-demand, peer-to-peer routes with particular characteristic s
inside the 6TiSCH network. inside the 6TiSCH network.
This may be achieved in a centralized fashion by a Path Computation This may be achieved in a centralized fashion by a Path Computation
Element (PCE) <xref target='PCE'/> that programs both the routes and Element (PCE) <xref target="PCE" format="default" sectionFormat="of" de
the schedules inside the 6TiSCH nodes, or by in a distributed fashion rivedContent="PCE"/> that programs both the routes and
using a reactive routing protocol and a Hop-by-Hop scheduling protocol. the schedules inside the 6TiSCH nodes or in a distributed fashion by
</t> using a reactive routing protocol and a hop-by-hop scheduling protocol.
</t>
<t> <t indent="0" pn="section-3.1-11">
This architecture expects that a 6LoWPAN node can connect as a This architecture expects that a 6LoWPAN node can connect as a
leaf to a RPL network, where the leaf support is the minimal leaf to a RPL network, where the leaf support is the minimal
functionality to connect as a host to a RPL network without the need to functionality to connect as a host to a RPL network without the need to
participate to the full routing protocol. participate in the full routing protocol.
The architecture also expects that a 6LoWPAN node that is not aware The architecture also expects that a 6LoWPAN node that is unaware
at all of the RPL protocol may also connect as described in of RPL may also connect as described in <xref target="RFC9010" format="d
<xref target='I-D.ietf-roll-unaware-leaves'/>. efault" sectionFormat="of" derivedContent="RFC9010"/>.
</t> </t>
</section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-3.2
<section><name>A Multi-Link Subnet Model</name> ">
<t> <name slugifiedName="name-a-multi-link-subnet-model">A Multi-Link Subnet
An extended configuration of the subnet comprises multiple LLNs as Model</name>
illustrated in <xref target='fig2'/>. <t indent="0" pn="section-3.2-1">
In the extended configuration, a Routing Registrar <xref target='RFC8505'/> An extended configuration of the subnet comprises multiple LLNs as
may be connected to the node that acts as RPL Root and / or 6LoWPAN 6LBR illustrated in <xref target="fig2" format="default" sectionFormat="of" deriv
and provides connectivity to the larger campus / factory plant network edContent="Figure 2"/>.
over a high-speed backbone or a back-haul link. The Routing registrar In the extended configuration, a Routing Registrar <xref target="RFC8505" fo
may perform IPv6 ND proxy operations, or redistribute the registration in rmat="default" sectionFormat="of" derivedContent="RFC8505"/>
a routing protocol such as <xref target='RFC5340'>OSPF</xref> or may be connected to the node that acts as the RPL Root and/or 6LoWPAN 6LBR
<xref target='RFC2545'>BGP</xref>, or inject a route in a mobility protocol and provides connectivity to the larger campus or factory plant network
such as <xref target='RFC6275'>MIPv6</xref>, <xref target='RFC3963'>NEMO over a high-speed backbone or a back-haul link. The Routing Registrar
</xref>, or <xref target='RFC6830'>LISP</xref>. may perform IPv6 ND proxy operations; redistribute the registration in
a routing protocol such as <xref target="RFC5340" format="default" sectionFo
</t> rmat="of" derivedContent="RFC5340">OSPF</xref> or
<t> <xref target="RFC2545" format="default" sectionFormat="of" derivedContent="R
FC2545">BGP</xref>; or inject a route in a mobility protocol
such as <xref target="RFC6275" format="default" sectionFormat="of" derivedCo
ntent="RFC6275">Mobile IPv6 (MIPv6)</xref>,
<xref target="RFC3963" format="default" sectionFormat="of" derivedContent="R
FC3963">Network Mobility (NEMO)</xref>, or
<xref target="RFC6830" format="default" sectionFormat="of" derivedContent="R
FC6830">Locator/ID Separation Protocol (LISP)</xref>.
</t>
<t indent="0" pn="section-3.2-2">
Multiple LLNs can be interconnected and possibly synchronized over a Multiple LLNs can be interconnected and possibly synchronized over a
backbone, which can be wired or wireless. The backbone can operate with backbone, which can be wired or wireless. The backbone can operate with
IPv6 ND <xref target='RFC4861'/><xref target='RFC4862'/> procedures or an IPv6 ND procedures <xref target="RFC4861" format="default" sectionFormat="of " derivedContent="RFC4861"/> <xref target="RFC4862" format="default" sectionForm at="of" derivedContent="RFC4862"/> or a
hybrid of IPv6 ND and 6LoWPAN ND hybrid of IPv6 ND and 6LoWPAN ND
<xref target='RFC6775'/><xref target='RFC8505'/><xref target='I-D.ietf-6lo-a <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="R
p-nd'/>. FC6775"/> <xref target="RFC8505" format="default" sectionFormat="of" derivedCont
</t> ent="RFC8505"/> <xref target="RFC8928" format="default" sectionFormat="of" deriv
<figure anchor='fig2'><name>Extended Configuration of a 6TiSCH Network< edContent="RFC8928"/>.
/name> </t>
<artwork><![CDATA[ <figure anchor="fig2" align="left" suppress-title="false" pn="figure-2">
<name slugifiedName="name-extended-configuration-of-a">Extended Config
uration of a 6TiSCH Network</name>
<artwork align="left" pn="section-3.2-3.1">
| |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
(default) | | (Optional) | | | | IPv6 (default) | | (Optional) | | | | IPv6
Router | | 6LBR | | | | Node Router | | 6LBR | | | | Node
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| Backbone side | | | Backbone side | |
--------+---+--------------------+-+---------------+------+--- --------+---+--------------------+-+---------------+------+---
| | | | | |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Routing | | Routing | | Routing | | Routing | | Routing | | Routing |
| Registrar | | Registrar | | Registrar | | Registrar | | Registrar | | Registrar |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
o Wireless side o o o o o Wireless side o o o o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o 6TiSCH o 6TiSCH o o o o 6TiSCH o o 6TiSCH o 6TiSCH o o o o 6TiSCH o
o o LLN o o o o LLN o o LLN o o o LLN o o o o LLN o o LLN o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
</artwork>
]]></artwork></figure> </figure>
<t indent="0" pn="section-3.2-4">
<t>
A Routing Registrar that performs proxy IPv6 ND operations over the A Routing Registrar that performs proxy IPv6 ND operations over the
backbone on behalf of the 6TiSCH nodes is called a Backbone Router (6BBR) backbone on behalf of the 6TiSCH nodes is called a Backbone Router (6BBR)
<xref target='I-D.ietf-6lo-backbone-router'/>. The 6BBRs are <xref target="RFC8929" format="default" sectionFormat="of" derivedContent="R
placed along the wireless edge of a Backbone, and federate multiple FC8929"/>. The 6BBRs are
wireless links to form a single MultiLink Subnet. The 6BBRs synchronize placed along the wireless edge of a backbone and federate multiple
wireless links to form a single multi-link subnet. The 6BBRs synchronize
with one another over the backbone, so as to ensure that the multiple LLNs with one another over the backbone, so as to ensure that the multiple LLNs
that form the IPv6 subnet stay tightly synchronized. that form the IPv6 subnet stay tightly synchronized.
</t> </t>
<t> <t indent="0" pn="section-3.2-5">
The use of multicast can also be reduced on the backbone with a registrar The use of multicast can also be reduced on the backbone with a registrar
that would contribute to Duplicate Address Detection as well as Address that would contribute to Duplicate Address Detection as well as address
Lookup using only unicast request/response exchanges. lookup using only unicast request/response exchanges.
<xref target='I-D.thubert-6man-unicast-lookup'/> is a proposed method that <xref target="I-D.thubert-6man-unicast-lookup" format="default" sectionForma
presents an example of how to this could be achieved with an extension of t="of" derivedContent="ND-UNICAST-LOOKUP"/> is a proposed method that
<xref target='RFC8505'/>, using an optional 6LBR as a SubNet-level registrar presents an example of how this could be achieved with an extension of
, <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="R
as illustrated in <xref target='fig2'/>. FC8505"/>, using an optional 6LBR as a subnet-level registrar,
</t> as illustrated in <xref target="fig2" format="default" sectionFormat="of" de
<t> rivedContent="Figure 2"/>.
As detailed in <xref target='RPLvs6lo'/> the 6LBR that serves the LLN and </t>
<t indent="0" pn="section-3.2-6">
As detailed in <xref target="RPLvs6lo" format="default" sectionFormat="of" d
erivedContent="Section 4.1"/>, the 6LBR that serves the LLN and
the Root of the RPL network need to share information about the devices the Root of the RPL network need to share information about the devices
that are learned through either 6LoWPAN ND or RPL but not both. that are learned through either 6LoWPAN ND or RPL, but not both.
The preferred way of achieving this is to collocate/combine them. The preferred way of achieving this is to co-locate or combine them.
The combined RPL Root and 6LBR may be collocated with the 6BBR, or The combined RPL Root and 6LBR may be co-located with the 6BBR, or
directly attached to the 6BBR. In the latter case, it leverages the directly attached to the 6BBR. In the latter case, it leverages the
extended registration process defined in <xref target='RFC8505'/> to proxy extended registration process defined in <xref target="RFC8505" format="defa ult" sectionFormat="of" derivedContent="RFC8505"/> to proxy
the 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so the 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so
that the 6BBR may in turn perform proxy classical ND operations over the that the 6BBR may in turn perform classical ND operations over the
backbone. backbone as a proxy.
</t> </t>
<t> The <xref target='RFC8655'>DetNet <t indent="0" pn="section-3.2-7"> The <xref target="RFC8655" format="def
Architecture</xref> studies Layer-3 aspects of Deterministic Networks, and ault" sectionFormat="of" derivedContent="RFC8655">"Deterministic Networking Arch
covers networks that span multiple Layer-2 domains. itecture"</xref>
If the Backbone is Deterministic (such as defined by the Time Sensitive studies Layer 3 aspects of Deterministic Networks and
Networking WG at IEEE), then the Backbone Router ensures that the covers networks that span multiple Layer 2 domains.
If the backbone is deterministic (such as defined by the Time-Sensitive
Networking (TSN) Task Group at IEEE), then the Backbone Router ensures that
the
end-to-end deterministic behavior is maintained between the LLN and the end-to-end deterministic behavior is maintained between the LLN and the
backbone. backbone.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3.3
<section><name>TSCH: A Deterministic MAC Layer</name> ">
<t> <name slugifiedName="name-tsch-a-deterministic-mac-la">TSCH: a Determini
stic MAC Layer</name>
<t indent="0" pn="section-3.3-1">
Though at a different time scale (several orders of magnitude), Though at a different time scale (several orders of magnitude),
both IEEE Std. 802.1TSN and IEEE Std. 802.15.4 TSCH both IEEE Std 802.1 TSN and IEEE Std 802.15.4 TSCH
standards provide Deterministic capabilities to the point that a packet standards provide deterministic capabilities to the point that a packet
that pertains to a certain flow may traverse a network from node to nod pertaining to a certain flow may traverse a network from node to node f
e following ollowing
a precise schedule, as a train that enters and then leaves intermediate stations a precise schedule, as a train that enters and then leaves intermediate stations
at precise times along its path. at precise times along its path.
</t>
</t> <t indent="0" pn="section-3.3-2">
<t>
With TSCH, time is formatted into With TSCH, time is formatted into
timeslots, and individual communication cells are allocated to unicast or timeslots, and individual communication cells are allocated to unicast or
broadcast communication at the MAC level. The time-slotted operation broadcast communication at the MAC level. The time-slotted operation
reduces collisions, saves energy, and enables to more closely engineer reduces collisions, saves energy, and enables more closely engineering
the network for deterministic properties. the network for deterministic properties.
The channel hopping aspect is a simple and efficient technique to comba t The channel-hopping aspect is a simple and efficient technique to comba t
multipath fading and co-channel interference. multipath fading and co-channel interference.
</t> </t>
<t> <t indent="0" pn="section-3.3-3">
6TiSCH builds on the IEEE Std. 802.15.4 TSCH MAC and inherits its advan 6TiSCH builds on the IEEE Std 802.15.4 TSCH MAC and inherits its advanc
ced ed
capabilities to enable them in multiple environments where they can capabilities to enable them in multiple environments where they can
be leveraged to improve automated operations. be leveraged to improve automated operations.
The 6TiSCH Architecture also inherits the capability to perform a The 6TiSCH architecture also inherits the capability to perform a
centralized route computation to achieve deterministic properties, centralized route computation to achieve deterministic properties,
though it relies on the IETF though it relies on the IETF
<xref target='RFC8655'>DetNet Architecture</xref>, <xref target="RFC8655" format="default" sectionFormat="of" derivedConte nt="RFC8655">DetNet architecture</xref>
and IETF components such as the PCE and IETF components such as the PCE
<xref target='PCE'/>, for the protocol aspects. <xref target="PCE" format="default" sectionFormat="of" derivedContent="
PCE"/> for the protocol aspects.
</t> </t>
<t>On top of this inheritance, 6TiSCH adds capabilities for distributed <t indent="0" pn="section-3.3-4">On top of this inheritance, 6TiSCH adds
routing and scheduling operations based on the RPL routing protocol capabilities for distributed
and capabilities to negotiate schedule adjustments between peers. routing and scheduling operations based on RPL
and capabilities for negotiating schedule adjustments between peers.
These distributed routing and scheduling operations simplify the These distributed routing and scheduling operations simplify the
deployment of TSCH networks and enable wireless solutions in a larger deployment of TSCH networks and enable wireless solutions in a larger
variety of use cases from operational technology in general. Examples variety of use cases from operational technology in general. Examples
of such use-cases in industrial environments include plant setup and of such use cases in industrial environments include plant setup and
decommissioning, as well as monitoring of lots of lesser importance decommissioning, as well as monitoring a multiplicity of minor
measurements such as corrosion and events and mobile workers accessing notifications such as corrosion measurements, events, and access of
local devices. local devices by mobile workers.
</t> </t>
</section> </section>
<section><name>Scheduling TSCH</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-3.4
<t>A scheduling operation attributes cells in a Time-Division-Multiplexing ">
(TDM) / Frequency-Division Multiplexing (FDM) matrix called the Channel <name slugifiedName="name-scheduling-tsch">Scheduling TSCH</name>
distribution/usage (CDU) to either individual transmissions <t indent="0" pn="section-3.4-1">A scheduling operation allocates cells
or as multi-access shared resources. The CDU matrix can be formatted in in a TDM/FDM matrix
called a CDU either to individual transmissions or as multi-access shar
ed resources.
The CDU matrix can be formatted in
chunks that can be allocated exclusively to particular nodes to enable chunks that can be allocated exclusively to particular nodes to enable
distributed scheduling without collision. distributed scheduling without collision.
More in <xref target='slotframes'/>. More in <xref target="slotframes" format="default" sectionFormat="of" d
</t> erivedContent="Section 4.3.5"/>.
<t> </t>
From the standpoint of a 6TiSCH node (at the MAC layer), its schedule <t indent="0" pn="section-3.4-2">
At the MAC layer, the schedule of a 6TiSCH node
is the collection of the timeslots at which it must wake up for is the collection of the timeslots at which it must wake up for
transmission, and the channels to which it should either send or listen transmission, and the channels to which it should either send or listen
at those times. The schedule is expressed as one or more slotframes tha at those times. The schedule is expressed as one or more repeating slot
t frames.
repeat over and over. Slotframes may collide and require a device to Slotframes may collide and require a device to
wake up at a same time, in which case the slotframe with the highest wake up at a same time, in which case the slotframe with the highest
priority is actionable. priority is actionable.
</t> </t>
<t> <t indent="0" pn="section-3.4-3">
The 6top sublayer (see <xref target='s6Pprot'/> for more) hides the The 6top sublayer (see <xref target="s6Pprot" format="default" sectionF
complexity of the schedule from the upper layers. The Link abstraction ormat="of" derivedContent="Section 4.3"/> for more) hides the
that IP traffic utilizes is composed of a pair of Layer-3 cell bundles, complexity of the schedule from the upper layers. The link abstraction
that IP traffic utilizes is composed of a pair of Layer 3 cell bundles,
one to receive and one to transmit. Some of the cells may be shared, in one to receive and one to transmit. Some of the cells may be shared, in
which case the 6top sublayer must perform some arbitration. which case the 6top sublayer must perform some arbitration.
</t> </t>
<t> <t indent="0" pn="section-3.4-4">
Scheduling enables multiple communications at a same time in a same Scheduling enables multiple simultaneous communications in a same
interference domain using different channels; but a node equipped with interference domain using different channels; but a node equipped with
a single radio can only either transmit or receive on one channel at a single radio can only either transmit or receive on one channel at
any point of time. any point of time.
Scheduled cells that fulfil the same role, e.g., receive IP packets fro m Scheduled cells that fulfill the same role, e.g., receive IP packets fr om
a peer, are grouped in bundles. a peer, are grouped in bundles.
</t> </t>
<t indent="0" pn="section-3.4-5">The 6TiSCH architecture identifies four
<t>The 6TiSCH architecture identifies four ways a schedule can be managed ways a schedule can be managed
and CDU cells can be allocated: Static Scheduling, Neighbor-to-Neighbor and CDU cells can be allocated: Static Scheduling, Neighbor-to-Neighbor
Scheduling, Centralized (or Remote) Monitoring and Schedule Management, Scheduling, Centralized (or Remote) Monitoring and Schedule Management,
and Hop-by-hop Scheduling. and Hop-by-Hop Scheduling.
</t><dl spacing='normal'> </t>
<dt>Static Scheduling:</dt><dd>This refers to the minimal <dl spacing="normal" indent="3" newline="false" pn="section-3.4-6">
<dt pn="section-3.4-6.1">Static Scheduling:</dt>
<dd pn="section-3.4-6.2">This refers to the minimal
6TiSCH operation whereby a static schedule is configured for the whole 6TiSCH operation whereby a static schedule is configured for the whole
network for use in a Slotted ALOHA <xref target='S-ALOHA'/> fashion. network for use in a Slotted ALOHA <xref target="S-ALOHA" format="defau lt" sectionFormat="of" derivedContent="S-ALOHA"/> fashion.
The static schedule is The static schedule is
distributed through the native methods in the TSCH MAC layer distributed through the native methods in the TSCH MAC layer
and does not preclude other scheduling operations to co-exist on a same and does not preclude other scheduling operations coexisting on a same
6TiSCH network. A static schedule is 6TiSCH network. A static schedule is
necessary for basic operations such as the join process and necessary for basic operations such as the join process and
for interoperability during the network formation, which is specified for interoperability during the network formation, which is specified
as part of the <xref target='RFC8180'>Minimal 6TiSCH Configuration as part of the <xref target="RFC8180" format="default" sectionFormat="o
</xref>. f" derivedContent="RFC8180">Minimal 6TiSCH Configuration
</xref>.
</dd> </dd>
<dt>Neighbor-to-Neighbor Scheduling:</dt><dd>This refers to the <dt pn="section-3.4-6.3">Neighbor-to-Neighbor Scheduling:</dt>
dynamic adaptation of the bandwidth of the Links that are used for IPv6 <dd pn="section-3.4-6.4">This refers to the
dynamic adaptation of the bandwidth of the links that are used for IPv6
traffic between adjacent peers. Scheduling Functions such as the traffic between adjacent peers. Scheduling Functions such as the
<xref target='I-D.ietf-6tisch-msf'>"6TiSCH Minimal Scheduling Function <xref target="RFC9033" format="default" sectionFormat="of" derivedConte
(MSF)"</xref> influence the operation of the MAC layer to add, update nt="RFC9033">"6TiSCH Minimal Scheduling Function
and remove cells in its own, and its peer's schedules using 6P (MSF)"</xref> influence the operation of the MAC layer to add, update,
<xref target='RFC8480'/>, and remove cells in its own and its peer's schedules using 6P
<xref target="RFC8480" format="default" sectionFormat="of" derivedConte
nt="RFC8480"/>
for the negotiation of the MAC resources.</dd> for the negotiation of the MAC resources.</dd>
<dt>Centralized (or Remote) Monitoring and Schedule Management:</dt><dd <dt pn="section-3.4-6.5">Centralized (or Remote) Monitoring and Schedu
> le Management:</dt>
<dd pn="section-3.4-6.6">
This refers to the central computation of a schedule and the capability This refers to the central computation of a schedule and the capability
to forward a frame based on the cell of arrival. In that case, to forward a frame based on the cell of arrival. In that case,
the related portion of the device schedule as well as other device the related portion of the device schedule as well as other device
resources are managed by an abstract Network Management Entity (NME), resources are managed by an abstract Network Management Entity (NME),
which may cooperate with the PCE to minimize the interaction which may cooperate with the PCE to minimize the interaction
with and the load on the constrained device. with, and the load on, the constrained device.
This model is the TSCH adaption of the This model is the TSCH adaption of the
<xref target='RFC8655'>DetNet Architecture</xref>, <xref target="RFC8655" format="default" sectionFormat="of" derivedConte nt="RFC8655">DetNet architecture</xref>,
and it enables Traffic Engineering with deterministic properties. and it enables Traffic Engineering with deterministic properties.
</dd> </dd>
<dt>Hop-by-hop Scheduling:</dt><dd>This refers to the possibility to <dt pn="section-3.4-6.7">Hop-by-Hop Scheduling:</dt>
reserves cells along a path for a particular flow using a distributed <dd pn="section-3.4-6.8">This refers to the possibility of
reserving cells along a path for a particular flow using a distributed
mechanism.</dd> mechanism.</dd>
</dl><t> </dl>
</t> <t> <t indent="0" pn="section-3.4-7">
It is not expected that all use cases will require all those mechanisms . It is not expected that all use cases will require all those mechanisms .
Static Scheduling with minimal configuration one is the only one that Static Scheduling with minimal configuration is the only one that
is expected in all implementations, since it provides a simple and is expected in all implementations, since it provides a simple and
solid basis for convergecast routing and time distribution. solid basis for convergecast routing and time distribution.
</t><t> </t>
A deeper dive in those mechanisms can be found in <xref target='schd'/> <t indent="0" pn="section-3.4-8">
. A deeper dive into those mechanisms can be found in <xref target="schd"
</t> format="default" sectionFormat="of" derivedContent="Section 4.4"/>.
</t>
</section> </section>
<section anchor='rtg3'><name>Distributed vs. Centralized Routing</name> <section anchor="rtg3" numbered="true" removeInRFC="false" toc="include" p
n="section-3.5">
<t> <name slugifiedName="name-distributed-vs-centralized-">Distributed vs. C
entralized Routing</name>
<t indent="0" pn="section-3.5-1">
6TiSCH enables a mixed model of centralized routes and distributed routes. 6TiSCH enables a mixed model of centralized routes and distributed routes.
Centralized routes can for example be computed by an entity such as a PCE. Centralized routes can, for example, be computed by an entity such as a PC
6TiSCH leverages the <xref target='RFC6550'>RPL</xref> routing protocol E.
for interoperable distributed routing operations. 6TiSCH leverages <xref target="RFC6550" format="default" sectionFormat="of
</t> " derivedContent="RFC6550">RPL</xref>
<t> for interoperable, distributed routing operations.
Both methods may inject routes in the Routing Tables of the 6TiSCH routers </t>
. <t indent="0" pn="section-3.5-2">
Both methods may inject routes into the routing tables of the 6TiSCH route
rs.
In either case, each route is associated with a 6TiSCH topology that can In either case, each route is associated with a 6TiSCH topology that can
be a RPL Instance topology or a Track. The 6TiSCH topology is be a RPL Instance topology or a Track. The 6TiSCH topology is
indexed by a RPLInstanceID, in a format that reuses the RPLInstanceID as indexed by a RPLInstanceID, in a format that reuses the RPLInstanceID as
defined in RPL. defined in RPL.
</t> </t>
<t> <t indent="0" pn="section-3.5-3">
<xref target='RFC6550'>RPL</xref> is applicable to Static Scheduling and <xref target="RFC6550" format="default" sectionFormat="of" derivedConten
t="RFC6550">RPL</xref> is applicable to Static Scheduling and
Neighbor-to-Neighbor Scheduling. The architecture also supports a Neighbor-to-Neighbor Scheduling. The architecture also supports a
centralized routing model for Remote Monitoring and Schedule Management. centralized routing model for Remote Monitoring and Schedule Management.
It is expected that a routing protocol that is more optimized for It is expected that a routing protocol that is more optimized for
point-to-point routing than <xref target='RFC6550'>RPL</xref>, such as point-to-point routing than <xref target="RFC6550" format="default" sect
the <xref target='I-D.ietf-roll-aodv-rpl'> ionFormat="of" derivedContent="RFC6550">RPL</xref>, such as
Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks"</xref> the <xref target="I-D.ietf-roll-aodv-rpl" format="default" sectionFormat
AODV-RPL), which derives from the <xref target='I-D.ietf-manet-aodvv2'> ="of" derivedContent="AODV-RPL">
Ad Hoc On-demand Distance Vector Routing (AODV)</xref> will be "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks" (AODV-RPL)</xr
selected for Hop-by-hop Scheduling. ef>,
</t> which derives from the <xref target="I-D.ietf-manet-aodvv2" format="defa
<t> ult" sectionFormat="of" derivedContent="AODVv2">
Both RPL and PCE rely on shared sources such as policies to define Global "Ad Hoc On-demand Distance Vector (AODVv2) Routing"</xref>, will be
and Local RPLInstanceIDs that can be used by either method. It is possible selected for Hop-by-Hop Scheduling.
for centralized and distributed routing to share a same topology. </t>
<t indent="0" pn="section-3.5-4">
Both RPL and PCE rely on shared sources such as policies to define global
and local RPLInstanceIDs that can be used by either method. It is possible
for centralized and distributed routing to share the same topology.
Generally they will operate in different slotframes, and centralized Generally they will operate in different slotframes, and centralized
routes will be used for scheduled traffic and will have precedence over routes will be used for scheduled traffic and will have precedence over
distributed routes in case of conflict between the slotframes. distributed routes in case of conflict between the slotframes.
</t> </t>
</section> <!-- Distributed vs. Centralized Routing --> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3.6
<section><name>Forwarding Over TSCH</name> ">
<t> <name slugifiedName="name-forwarding-over-tsch">Forwarding over TSCH</na
me>
<t indent="0" pn="section-3.6-1">
The 6TiSCH architecture supports three different forwarding models. The 6TiSCH architecture supports three different forwarding models.
One is the classical IPv6 Forwarding, where the node selects a feasible One is the classical IPv6 Forwarding, where the node selects a feasible
successor at Layer-3 on a per packet basis and based on its routing successor at Layer 3 on a per-packet basis and based on its routing
table. The second derives from Generic MPLS (G-MPLS) for so-called table. The second derives from Generalized MPLS (GMPLS) for so-called
Track Forwarding, whereby a frame received at a particular timeslot Track Forwarding, whereby a frame received at a particular timeslot
can be switched into another timeslot at Layer-2 without regard to the can be switched into another timeslot at Layer 2 without regard to the
upper layer protocol. The third model is the upper-layer protocol. The third model is the
6LoWPAN Fragment Forwarding, which allows to forward individual 6loWPAN 6LoWPAN Fragment Forwarding, which allows the forwarding individual 6Lo
fragments along a route that is setup by the first fragment. WPAN
</t> fragments along a route that is set up by the first fragment.
<t>In more details: </t>
</t><dl spacing='normal'> <t indent="0" pn="section-3.6-2">In more detail:
<dt>IPv6 Forwarding:</dt><dd>This is the classical IP forwarding </t>
model, with a Routing Information Based (RIB) that is installed by the <dl spacing="normal" indent="3" newline="false" pn="section-3.6-3">
RPL routing protocol and used to select a feasible successor per packet <dt pn="section-3.6-3.1">IPv6 Forwarding:</dt>
. <dd pn="section-3.6-3.2">This is the classical IP forwarding
The packet is placed on an outgoing Link, that the 6top layer maps into model, with a Routing Information Base (RIB) that is installed by
a (Layer-3) bundle of cells, and scheduled for transmission based on Qo RPL and used to select a feasible successor per packet.
S The packet is placed on an outgoing link, which the 6top sublayer maps
into
a (Layer 3) bundle of cells, and scheduled for transmission based on Qo
S
parameters. Besides RPL, this model also applies to any routing parameters. Besides RPL, this model also applies to any routing
protocol which may be operated in the 6TiSCH network, and corresponds protocol that may be operated in the 6TiSCH network and corresponds
to all the distributed scheduling models, Static, Neighbor-to-Neighbor to all the distributed scheduling models: Static, Neighbor-to-Neighbor,
and Hop-by-Hop Scheduling.</dd> and Hop-by-Hop Scheduling.</dd>
<dt>G-MPLS Track Forwarding:</dt><dd>This model corresponds to the <dt pn="section-3.6-3.3">GMPLS Track Forwarding:</dt>
<dd pn="section-3.6-3.4">This model corresponds to the
Remote Monitoring and Schedule Management. In this model, a central Remote Monitoring and Schedule Management. In this model, a central
controller (hosting a PCE) computes and installs the schedules in the controller (hosting a PCE) computes and installs the schedules in the
devices per flow. The incoming (Layer-2) bundle of cells from the devices per flow. The incoming (Layer 2) bundle of cells from the
previous node along the path determines the outgoing (Layer-2) bundle previous node along the path determines the outgoing (Layer 2) bundle
towards the next hop for that flow as determined by the PCE. The towards the next hop for that flow as determined by the PCE. The
programmed sequence for bundles is called a Track and can assume DAG programmed sequence for bundles is called a Track and can assume DAG
shapes that are more complex than a simple direct sequence of nodes.</d d> shapes that are more complex than a simple direct sequence of nodes.</d d>
<dt>6LoWPAN Fragment Forwarding:</dt><dd>This is a hybrid model <dt pn="section-3.6-3.5">6LoWPAN Fragment Forwarding:</dt>
<dd pn="section-3.6-3.6">This is a hybrid model
that derives from IPv6 forwarding for the case where packets must that derives from IPv6 forwarding for the case where packets must
be fragmented at the 6LoWPAN sublayer. The first fragment is forwarded be fragmented at the 6LoWPAN sublayer. The first fragment is forwarded
like any IPv6 packet and leaves a state in the intermediate hops to like any IPv6 packet and leaves a state in the intermediate hops to
enable forwarding of the next fragments that do not have a IP header enable forwarding of the next fragments that do not have an IP header
without the need to recompose the packet at every hop.</dd> without the need to recompose the packet at every hop.</dd>
</dl><t> </dl>
</t> <t indent="0" pn="section-3.6-4">A deeper dive into these operations can
<t>A deeper dive on these operations can be found in be found in
<xref target='fwd'/>. <xref target="fwd" format="default" sectionFormat="of" derivedContent="Secti
</t> on 4.6"/>.
<t> The following table summarizes how the forwarding models </t>
<t indent="0" pn="section-3.6-5"> <xref target="RaF" format="default" se
ctionFormat="of" derivedContent="Table 1"/> summarizes how the forwarding models
apply to the various routing and scheduling possibilities: apply to the various routing and scheduling possibilities:
</t> </t>
<figure anchor='RaF' suppress-title='true'> <table anchor="RaF" align="center" pn="table-1">
<artwork> <thead>
<![CDATA[ <tr>
+-------------------+------------+----------------------------------+ <th align="left" colspan="1" rowspan="1">Forwarding Model</th>
| Forwarding Model | Routing | Scheduling | <th align="left" colspan="1" rowspan="1">Routing</th>
+===================+============+==================================+ <th align="left" colspan="1" rowspan="1">Scheduling</th>
| | | Static (Minimal Configuration) | </tr>
+ classical IPv6 + RPL +----------------------------------+ </thead>
| / | | Neighbor-to-Neighbor (SF+6P) | <tbody>
+ 6LoWPAN Fragment +------------+----------------------------------+ <tr>
| | Reactive | Hop-by-Hop (AODV-RPL) | <td rowspan="3" align="left" colspan="1">classical IPv6 / 6LoWPAN
+-------------------+------------+----------------------------------+ Fragment</td>
|G-MPLS Track Fwding| PCE |Remote Monitoring and Schedule Mgt| <td rowspan="2" align="left" colspan="1">RPL</td>
+-------------------+------------+----------------------------------+ <td align="left" colspan="1" rowspan="1">Static (Minimal Configura
]]> tion)</td>
</artwork> </tr>
</figure> <tr>
<td align="left" colspan="1" rowspan="1">Neighbor-to-Neighbor (SF+
</section> 6P)</td>
<section anchor='fsixstac'><name>6TiSCH Stack</name> </tr>
<t> <tr>
<td align="left" colspan="1" rowspan="1">Reactive</td>
<td align="left" colspan="1" rowspan="1">Hop-by-Hop (AODV-RPL)</td
>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">GMPLS Track Forwarding</t
d>
<td align="left" colspan="1" rowspan="1">PCE</td>
<td align="left" colspan="1" rowspan="1">Remote Monitoring and Sch
edule Mgt</td>
</tr>
</tbody>
</table>
</section>
<section anchor="fsixstac" numbered="true" removeInRFC="false" toc="includ
e" pn="section-3.7">
<name slugifiedName="name-6tisch-stack">6TiSCH Stack</name>
<t indent="0" pn="section-3.7-1">
The IETF proposes multiple techniques for implementing functions related The IETF proposes multiple techniques for implementing functions related
to routing, transport or security. to routing, transport, or security.
</t>
</t> <t indent="0" pn="section-3.7-2">
<t>
The 6TiSCH architecture limits the possible The 6TiSCH architecture limits the possible
variations of the stack and recommends a number of base elements for LLN variations of the stack and recommends a number of base elements for LLN
applications to control the complexity of applications to control the complexity of
possible deployments and device interactions, and to limit the size of possible deployments and device interactions and to limit the size of
the resulting object code. In particular, UDP <xref target='RFC0768'/>, the resulting object code. In particular, UDP <xref target="RFC0768" forma
IPv6 <xref target='RFC8200'/> and the <xref target='RFC7252'>Constrained t="default" sectionFormat="of" derivedContent="RFC0768"/>,
Application Protocol</xref> (CoAP) are used as the transport / binding of IPv6 <xref target="RFC8200" format="default" sectionFormat="of" derivedCon
tent="RFC8200"/>, and the <xref target="RFC7252" format="default" sectionFormat=
"of" derivedContent="RFC7252">Constrained
Application Protocol (CoAP)</xref> are used as the transport/binding of
choice for applications and management as opposed to TCP and HTTP. choice for applications and management as opposed to TCP and HTTP.
</t> </t>
<t> <t indent="0" pn="section-3.7-3">
The resulting protocol stack is represented in <xref target='fig4'/>: The resulting protocol stack is represented in <xref target="fig4" format=
</t> "default" sectionFormat="of" derivedContent="Figure 3"/>:
<figure anchor='fig4'><name>6TiSCH Protocol Stack</name> </t>
<artwork><![CDATA[ <figure anchor="fig4" align="left" suppress-title="false" pn="figure-3">
<name slugifiedName="name-6tisch-protocol-stack">6TiSCH Protocol Stack
</name>
<artwork align="left" pn="section-3.7-4.1">
+--------+--------+ +--------+--------+
| Applis | CoJP | | Applis | CoJP |
+--------+--------+--------------+-----+ +--------+--------+--------------+-----+
| CoAP / OSCORE | 6LoWPAN ND | RPL | | CoAP / OSCORE | 6LoWPAN ND | RPL |
+-----------------+--------------+-----+ +-----------------+--------------+-----+
| UDP | ICMPv6 | | UDP | ICMPv6 |
+-----------------+--------------------+ +-----------------+--------------------+
| IPv6 | | IPv6 |
+--------------------------------------+----------------------+ +--------------------------------------+----------------------+
| 6LoWPAN HC / 6LoRH HC | Scheduling Functions | | 6LoWPAN HC / 6LoRH HC | Scheduling Functions |
+--------------------------------------+----------------------+ +--------------------------------------+----------------------+
| 6top inc. 6top protocol | | 6top inc. 6top Protocol |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| IEEE Std. 802.15.4 TSCH | | IEEE Std 802.15.4 TSCH |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
</artwork>
]]></artwork> </figure>
</figure> <t indent="0" pn="section-3.7-5">
<t> RPL is the routing protocol of choice for LLNs. So far, there is no
RPL is the routing protocol of choice for LLNs. So far, there was no identified need to define a 6TiSCH-specific Objective Function.
identified need to define a 6TiSCH specific Objective Function. The <xref target="RFC8180" format="default" sectionFormat="of" derivedC
The <xref target='RFC8180'>Minimal 6TiSCH Configuration ontent="RFC8180">Minimal 6TiSCH Configuration
</xref> describes the operation of RPL over a static schedule used in </xref> describes the operation of RPL over a static schedule used in
a Slotted ALOHA fashion <xref target='S-ALOHA'/>, whereby all active sl a Slotted ALOHA fashion <xref target="S-ALOHA" format="default" section
ots Format="of" derivedContent="S-ALOHA"/>, whereby all active slots
may be used for emission or reception of both unicast and multicast may be used for emission or reception of both unicast and multicast
frames. frames.
</t> </t>
<t> <t indent="0" pn="section-3.7-6">
The <xref target='RFC6282'>6LoWPAN Header Compression</xref> is used <xref target="RFC6282" format="default" sectionFormat="of" derivedConte
nt="RFC6282">6LoWPAN header compression</xref> is used
to compress the IPv6 and UDP headers, whereas the to compress the IPv6 and UDP headers, whereas the
<xref target='RFC8138'> 6LoWPAN Routing Header (6LoRH)</xref> is used <xref target="RFC8138" format="default" sectionFormat="of" derivedConte nt="RFC8138"> 6LoWPAN Routing Header (6LoRH)</xref> is used
to compress the RPL artifacts in to compress the RPL artifacts in
the IPv6 data packets, including the RPL Packet Information (RPI), the IPv6 data packets, including the RPL Packet Information (RPI),
the IP-in-IP encapsulation to/from the RPL Root, and the Source Route the IP-in-IP encapsulation to/from the RPL Root, and the Source Routing
Header (SRH) in non-storing mode. Header (SRH) in non-storing mode.
<xref target='I-D.ietf-roll-useofrplinfo'>"When to use RFC 6553, 6554 "<xref target="RFC9008" format="title" sectionFormat="of" derivedConten
and IPv6-in-IPv6"</xref> provides the details on when headers or encaps t="Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Enc
ulation are needed. apsulation in the RPL Data Plane"/>" <xref target="RFC9008" format="default" sec
</t> tionFormat="of" derivedContent="RFC9008"/>
<t> provides the details on when headers or encapsulation are needed.
<!--The COMAN list is working on network Management for LLN. </t>
They are considering the Open Mobile Alliance (OMA) Lightweight M2M (LW <t indent="0" pn="section-3.7-7">
M2M) Object system. The <xref target="RFC8613" format="default" sectionFormat="of" derivedC
This standard includes DTLS, CoAP (core plus Block and Observe patterns ontent="RFC8613">
), Object Security for Constrained RESTful Environments (OSCORE) </xref>
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'>
Object Security for Constrained RESTful Environments (OSCORE) </xref>,
is leveraged by the Constrained Join Protocol (CoJP) and is expected to is leveraged by the Constrained Join Protocol (CoJP) and is expected to
be the primary protocol for the protection of the application payload be the primary protocol for the protection of the application payload
as well. The application payload may also be protected by as well. The application payload may also be protected by
the <xref target='RFC6347'>Datagram Transport Layer Security (DTLS) the <xref target="RFC6347" format="default" sectionFormat="of" derivedC
</xref> sitting either under CoAP or over CoAP so it can traverse ontent="RFC6347">Datagram Transport Layer Security (DTLS)
</xref> sitting either under CoAP or over CoAP so it can traverse
proxies. proxies.
</t>
</t> <t indent="0" pn="section-3.7-8">
<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 The 6TiSCH Operation
sublayer (6top) is a sublayer of a Logical Link Control (LLC) Sublayer (6top) is a sublayer of a Logical Link Control (LLC)
that provides the abstraction of an IP link over a TSCH MAC and that provides the abstraction of an IP link over a TSCH MAC and
schedules packets over TSCH cells, as further discussed in the next schedules packets over TSCH cells, as further discussed in the next
sections, providing in particular dynamic cell allocation with the sections, providing in particular dynamic cell allocation with the
6top Protocol (6P) <xref target='RFC8480'/>. 6top Protocol (6P) <xref target="RFC8480" format="default" sectionForma
</t> t="of" derivedContent="RFC8480"/>.
<t> </t>
<t indent="0" pn="section-3.7-9">
The reference stack presented in this document was implemented The reference stack presented in this document was implemented
and interop-tested by a conjunction of opensource, IETF and ETSI efforts. and interoperability-tested by a combination of open source, IETF, and ETS I efforts.
One goal is to help other bodies to adopt the stack as a whole, making the One goal is to help other bodies to adopt the stack as a whole, making the
effort to move to an IPv6-based IoT stack easier. effort to move to an IPv6-based IoT stack easier.
</t> </t>
<t> <t indent="0" pn="section-3.7-10">
For a particular For a particular
environment, some of the choices that are made in this architecture may no t environment, some of the choices that are available in this architecture m ay not
be relevant. For instance, RPL is not required for star topologies and be relevant. For instance, RPL is not required for star topologies and
mesh-under Layer-2 routed networks, and the 6LoWPAN compression may not be mesh-under Layer 2 routed networks, and the 6LoWPAN compression may not be
sufficient for ultra-constrained cases such as some Low-Power Wide Area sufficient for ultra-constrained cases such as some Low-Power Wide Area
(LPWA) networks. In such cases, it is perfectly doable to adopt a subset (LPWA) networks. In such cases, it is perfectly doable to adopt a subset
of the selection that is presented hereafter and then select alternate of the selection that is presented hereafter and then select alternate
components to complete the solution wherever needed. components to complete the solution wherever needed.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3.8
<section><name>Communication Paradigms and Interaction Models</name> ">
<t> <name slugifiedName="name-communication-paradigms-and">Communication Par
<xref target='sixTTerminology'/> provides the terms adigms and Interaction Models</name>
of Communication Paradigms and Interaction Models, in relation with <t indent="0" pn="section-3.8-1">
<xref target='RFC3444'>"On the Difference between Information Models <xref target="sixTTerminology" format="default" sectionFormat="of" deri
vedContent="Section 2.1"/> provides the terms
of Communication Paradigms and Interaction Models in combination with
<xref target="RFC3444" format="default" sectionFormat="of" derivedConte
nt="RFC3444">"On the Difference between Information Models
and Data Models"</xref>. and Data Models"</xref>.
A Communication Paradigm would be an abstract view of a protocol exchan A Communication Paradigm is an abstract view of a protocol exchange
ge, and has an Information Model for the information that is being exchange
and would come with an Information Model for the information that is be d.
ing exchanged. In contrast, an Interaction Model is more refined and points to standar
In contrast, an Interaction Model would be more refined and could point d operation
to standard operation such as a Representational State Transfer (REST) "GET" operation and ma
such as a Representational state transfer (REST) "GET" operation and wo tches
uld match
a Data Model for the data that is provided over the protocol exchange. a Data Model for the data that is provided over the protocol exchange.
</t> </t>
<t> <t indent="0" pn="section-3.8-2">
Section 2.1.3 of <xref target="I-D.ietf-roll-rpl-industrial-applicability" section="2.1.
<xref target='I-D.ietf-roll-rpl-industrial-applicability'/> and next 3" sectionFormat="of" format="default" derivedLink="https://tools.ietf.org/html/
sections discuss application-layer paradigms, such as Source-sink (SS) draft-ietf-roll-rpl-industrial-applicability-02#section-2.1.3" derivedContent="R
that is a Multipeer to Multipeer (MP2MP) model primarily used for PL-APPLICABILITY"/>
alarms and alerts, Publish-subscribe (PS, or pub/sub) that is typically and its following
used for sensor data, as well as Peer-to-peer (P2P) and sections discuss application-layer paradigms such as source-sink,
Peer-to-multipeer (P2MP) communications. which is a multipeer-to-multipeer model primarily used for
alarms and alerts, publish-subscribe, which is typically
</t> used for sensor data, as well as peer-to-peer and
<t> peer-to-multipeer communications.
Additional considerations on Duocast - one sender, two receivers for re </t>
dundancy - <t indent="0" pn="section-3.8-3">
Additional considerations on duocast -- one sender, two receivers for r
edundancy --
and its N-cast generalization are also provided. and its N-cast generalization are also provided.
Those paradigms are frequently used in industrial automation, which is Those paradigms are frequently used in industrial automation, which is
a major use case for IEEE Std. 802.15.4 TSCH wireless networks with a major use case for IEEE Std 802.15.4 TSCH wireless networks with
<xref target='ISA100.11a'/> and <xref target='WirelessHART'/>, that <xref target="ISA100.11a" format="default" sectionFormat="of" derivedCo
provides a wireless access to <xref target='HART'/> applications and ntent="ISA100.11a"/> and <xref target="WirelessHART" format="default" sectionFor
mat="of" derivedContent="WirelessHART"/>, which
provides a wireless access to <xref target="HART" format="default" sect
ionFormat="of" derivedContent="HART"/> applications and
devices. devices.
</t> </t>
<t> <t indent="0" pn="section-3.8-4">
This document focuses on Communication Paradigms and Interaction This document focuses on Communication Paradigms and Interaction
Models for packet forwarding and TSCH resources (cells) management. Models for packet forwarding and TSCH resources (cells) management.
Management mechanisms for the TSCH schedule at Link-Layer (one-hop), Management mechanisms for the TSCH schedule at the link layer (one hop)
Network-layer (multihop along a Track), and Application-layer ,
(remote control) are discussed in <xref target='schd'/>. network layer (multihop along a Track), and application layer
Link-Layer frame forwarding interactions are discussed in <xref target= (remote control) are discussed in <xref target="schd" format="default"
'fwd'/>, and sectionFormat="of" derivedContent="Section 4.4"/>.
Network-layer Packet routing is addressed in <xref target='rtg'/>. Link-layer frame forwarding interactions are discussed in <xref target=
</t> "fwd" format="default" sectionFormat="of" derivedContent="Section 4.6"/>, and
</section> network-layer packet routing is addressed in <xref target="rtg" format=
</section> "default" sectionFormat="of" derivedContent="Section 4.7"/>.
</t>
<section anchor='dd'><name>Architecture Components</name> </section>
</section>
<section anchor='RPLvs6lo'><name>6LoWPAN (and RPL)</name> <section anchor="dd" numbered="true" removeInRFC="false" toc="include" pn="s
<t>A RPL DODAG is formed of a Root, a collection of routers, and leaves that ection-4">
are hosts. Hosts are nodes which do not forward packets that they did not ge <name slugifiedName="name-architecture-components">Architecture Components
nerate. </name>
RPL-aware leaves will participate to RPL to advertise their own <section anchor="RPLvs6lo" numbered="true" removeInRFC="false" toc="includ
e" pn="section-4.1">
<name slugifiedName="name-6lowpan-and-rpl">6LoWPAN (and RPL)</name>
<t indent="0" pn="section-4.1-1">A RPL DODAG is formed of a Root, a coll
ection of routers, and leaves that
are hosts. Hosts are nodes that do not forward packets that they did not gen
erate.
RPL-aware leaves will participate in RPL to advertise their own
addresses, whereas RPL-unaware leaves depend on a connected RPL router to do addresses, whereas RPL-unaware leaves depend on a connected RPL router to do
so. RPL interacts with 6LoWPAN ND at multiple levels, in particular at the so. RPL interacts with 6LoWPAN ND at multiple levels, in particular at the
Root and in the RPL-unaware leaves. Root and in the RPL-unaware leaves.
</t> </t>
<section anchor="leaf" numbered="true" removeInRFC="false" toc="include"
<section anchor='leaf'><name>RPL-Unaware Leaves and 6LoWPAN ND</name> pn="section-4.1.1">
<t>RPL needs a set of information to advertise <name slugifiedName="name-rpl-unaware-leaves-and-6low">RPL-Unaware Lea
ves and 6LoWPAN ND</name>
<t indent="0" pn="section-4.1.1-1">RPL needs a set of information to a
dvertise
a leaf node through a Destination Advertisement Object (DAO) message and esta blish reachability. a leaf node through a Destination Advertisement Object (DAO) message and esta blish reachability.
</t> </t>
<t> <t indent="0" pn="section-4.1.1-2"><xref target="RFC9010" format="defa
<xref target='I-D.ietf-roll-unaware-leaves'>"Routing for RPL Leaves"</xref> ult" sectionFormat="of" derivedContent="RFC9010">"Routing for RPL Leaves"</xref>
details the basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN details the basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN
that supports <xref target='RFC8505'/> to obtain return that supports <xref target="RFC8505" format="default" sectionFormat="of" deri
connectivity via the RPL network as an RPL-unaware leaf. vedContent="RFC8505"/> to obtain return
connectivity via the RPL network as a RPL-unaware leaf.
The leaf indicates that it requires reachability services for the The leaf indicates that it requires reachability services for the
Registered Address from a Routing Registrar by setting a 'R' flag in the Registered Address from a Routing Registrar by setting an 'R' flag in the
Extended Address Registration Option <xref target='RFC8505'/>, and it Extended Address Registration Option <xref target="RFC8505" format="default"
provides a TID that maps to a sequence number in section 7 of RPL <xref targe sectionFormat="of" derivedContent="RFC8505"/>, and it
t='RFC6550'/>. provides a TID that maps to the "Path Sequence" defined in <xref target="RFC6
</t> 550" section="6.7.8" sectionFormat="of" format="default" derivedLink="https://rf
<t> c-editor.org/rfc/rfc6550#section-6.7.8" derivedContent="RFC6550"/>, and its oper
<xref target='I-D.ietf-roll-unaware-leaves'/> also enables the leaf to signal ation is defined in <xref target="RFC6550" section="7.2" sectionFormat="of" form
the RPL InstanceID that it wants to participate to using the at="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-7.2" derive
Opaque field of the EARO. On the backbone, the InstanceID is dContent="RFC6550"/>.
</t>
<t indent="0" pn="section-4.1.1-3"><xref target="RFC9010" format="defa
ult" sectionFormat="of" derivedContent="RFC9010"/> also enables the leaf to sign
al
with the RPLInstanceID that it wants to participate by using the
Opaque field of the EARO. On the backbone, the RPLInstanceID is
expected to be mapped to an overlay that matches the RPL Instance, e.g., expected to be mapped to an overlay that matches the RPL Instance, e.g.,
a Virtual LAN (VLAN) or a virtual routing and forwarding (VRF) instance. a Virtual LAN (VLAN) or a virtual routing and forwarding (VRF) instance.
</t> </t>
<t> <t indent="0" pn="section-4.1.1-4">
Though at the time of this writing the above specification enables a model Though, at the time of this writing, the above specification enables a model
where the separation is possible, this architecture recommends to where the separation is possible, this architecture recommends
collocate the functions of 6LBR and RPL Root. co-locating the functions of 6LBR and RPL Root.
</t> </t>
</section> <!-- RPL-Unaware Leaves and 6LoWPAN ND --> </section>
<section anchor="rpllbr" numbered="true" removeInRFC="false" toc="includ
<section anchor='rpllbr'><name>6LBR and RPL Root</name> e" pn="section-4.1.2">
<name slugifiedName="name-6lbr-and-rpl-root">6LBR and RPL Root</name>
<t> <t indent="0" pn="section-4.1.2-1">
With the 6LowPAN ND <xref target='RFC6775'/>, information on the 6LBR is With the 6LoWPAN ND <xref target="RFC6775" format="default" sectionFormat="o
f" derivedContent="RFC6775"/>, information on the 6LBR is
disseminated via an Authoritative Border Router Option (ABRO) in RA messages . disseminated via an Authoritative Border Router Option (ABRO) in RA messages .
<xref target='RFC8505'/> extends <xref target='RFC6775'/> to enable a <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="R FC8505"/> extends <xref target="RFC6775" format="default" sectionFormat="of" der ivedContent="RFC6775"/> to enable a
registration for routing and proxy ND. registration for routing and proxy ND.
The capability to support <xref target='RFC8505'/> The capability to support <xref target="RFC8505" format="default" sectionFor mat="of" derivedContent="RFC8505"/>
is indicated in the 6LoWPAN Capability Indication Option (6CIO). is indicated in the 6LoWPAN Capability Indication Option (6CIO).
The discovery and liveliness of the RPL Root are obtained through RPL The discovery and liveliness of the RPL Root are obtained through RPL
<xref target='RFC6550'/> itself. <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="R
</t> FC6550"/> itself.
<t> </t>
<t indent="0" pn="section-4.1.2-2">
When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities
are co-located in order that the address of the 6LBR be indicated by RPL are co-located in order that the address of the 6LBR is indicated by RPL
DIO messages and to associate the unique ID from the EDAR/EDAC DODAG Information Object (DIO) messages and to associate the ROVR from
<xref target='RFC8505'/> exchange with the state that is maintained by RPL. the Extended Duplicate Address Request/Confirmation (EDAR/EDAC)
</t> exchange <xref target="RFC8505" format="default" sectionFormat="of" derivedCo
<t> ntent="RFC8505"/> with the state that is maintained by RPL.
Section 7 of <xref target='I-D.ietf-roll-unaware-leaves'/> specifies how </t>
<t indent="0" pn="section-4.1.2-3">
<xref target="RFC9010" section="7" sectionFormat="of" format="default" derive
dLink="https://rfc-editor.org/rfc/rfc9010#section-7" derivedContent="RFC9010"/>
specifies how
the DAO messages are used to reconfirm the registration, thus eliminating a the DAO messages are used to reconfirm the registration, thus eliminating a
duplication of functionality between DAO and EDAR/EDAC messages, as duplication of functionality between DAO and EDAR/EDAC messages, as
illustrated in <xref target='figReg2'/>. illustrated in <xref target="figReg2" format="default" sectionFormat="of" de
<xref target='I-D.ietf-roll-unaware-leaves'/> also provides the protocol rivedContent="Figure 6"/>.
<xref target="RFC9010" format="default" sectionFormat="of" derivedContent="RF
C9010"/> also provides the protocol
elements that are needed when the 6LBR and RPL Root functionalities are not elements that are needed when the 6LBR and RPL Root functionalities are not
co-located. co-located.
</t> </t>
<t> <t indent="0" pn="section-4.1.2-4">
Even though the Root of the RPL network is integrated with the 6LBR, Even though the Root of the RPL network is integrated with the 6LBR,
it is logically separated from the Backbone Router (6BBR) that it is logically separated from the Backbone Router (6BBR) that
is used to connect the 6TiSCH LLN to the backbone. This way, is used to connect the 6TiSCH LLN to the backbone. This way,
the Root has all information from 6LoWPAN ND and RPL about the LLN the Root has all information from 6LoWPAN ND and RPL about the LLN
devices attached to it. devices attached to it.
</t><t> </t>
<t indent="0" pn="section-4.1.2-5">
This architecture also expects that the Root of the RPL network This architecture also expects that the Root of the RPL network
(proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR,
for whatever operation the 6BBR performs on the backbone, such for whatever operation the 6BBR performs on the backbone, such
as ND proxy, or redistribution in a routing protocol. as ND proxy or redistribution in a routing protocol.
This relies on an extension of the 6LoWPAN ND registration described in This relies on an extension of the 6LoWPAN ND registration described in
<xref target='I-D.ietf-6lo-backbone-router'/>. <xref target="RFC8929" format="default" sectionFormat="of" derivedContent="RF
</t><t> C8929"/>.
This model supports the movement of a 6TiSCH device across the Multi-Link </t>
Subnet, and allows the proxy registration of 6TiSCH nodes deep into the <t indent="0" pn="section-4.1.2-6">
This model supports the movement of a 6TiSCH device across the multi-link
subnet and allows the proxy registration of 6TiSCH nodes deep into the
6TiSCH LLN by the 6LBR / RPL Root. 6TiSCH LLN by the 6LBR / RPL Root.
This is why in <xref target='RFC8505'/> the Registered Address is signaled This is why in <xref target="RFC8505" format="default" sectionFormat="of" der
in the Target Address field of the NS message as opposed to the IPv6 Source ivedContent="RFC8505"/> the Registered Address is signaled
in the Target Address field of the Neighbor Solicitation (NS) message as oppo
sed to the IPv6 Source
Address, which, in the case of a proxy registration, is that of the 6LBR / Address, which, in the case of a proxy registration, is that of the 6LBR /
RPL Root itself. RPL Root itself.
</t> </t>
</section>
<!--
<section anchor='gone' title="registration Failures Due to Movement">
<t>Registration to the 6LBR through DAR/DAC messages <xref target="RFC6775"/>
may percolate slowly through an LLN mesh, and it might happen that in
the meantime, the 6LoWPAN node moves and registers somewhere else. Both RPL
and 6LoWPAN ND lack the capability to indicate that the same node is
registered elsewhere, so as to invalidate states down the deprecated path.
</t><t> In its current expression and functionality,
6LoWPAN ND considers that the registration is used for the purpose of DAD
only as opposed to that of achieving reachability, and as long as the same
node registers the IPv6 address, the protocol is functional. to
act as a RPL leaf registration protocol and achieve reachability, the
device must use the same TID for all its concurrent registrations, and
registrations with a past TID should be declined. The state for an obsolete
registration in the 6LR, as well as the RPL routers on the way, should be
invalidated. This can only be achieved with the addition of a new Status in
the DAC message, and a new error/clean-up flow in RPL.
</t>
</section>
<section anchor='prox' title="Proxy registration">
<t>The 6BBR provides the capability to defend an address that is owned by
a 6LoWPAN Node, and attract packets to that address, whether it is done by
proxying ND over a Multi-Link Subnet, redistributing the address in a routing
protocol or advertising it through an alternate proxy registration such as
<xref target="RFC6830">the Locator/ID Separation Protocol</xref> (LISP) or
<xref target="RFC6275">Mobility Support in IPv6</xref> (MIPv6). In a LLN,
it makes sense to piggyback the request to proxy/defend an address with its
registration.
</t>
</section>
<section anchor='source' title="Target Registration">
<t>
In their current incarnations, both 6LoWPAN ND and Efficient ND expect
that the address being registered is the source of the NS(ARO) message and
thus impose that a Source Link-Layer Address (SLLA) option be present in the
message.
In a mesh scenario where the 6LBR is physically separated from the 6LoWPAN
Node, the 6LBR does not own the address being registered. This is why
<xref target="I-D.ietf-6lo-backbone-router"/>
registers the Target of the NS message as opposed to the Source Address.
From another perspective, it may happen, in the use case of a Star topology,
that the 6LR, 6LBR and 6BBR are effectively collapsed and should support
6LoWPAN ND clients. The convergence of efficient ND and 6LoWPAN ND into a
single protocol is thus highly desirable.
</t><t>
In any case, as long as the DAD process is not complete for the address
used as source of the packet, it is against the current practice to advertise
the SLLA, since this may corrupt the ND cache of the destination node, as
discussed in the <xref target="RFC4429">Optimistic DAD specification</xref>
with regards to the TENTATIVE state.
</t><t>
This may look like a chicken and an egg problem, but in fact 6LoWPAN ND
acknowledges that the Link-Local Address that is based on an EUI-64 address
of a LLN node may be autoconfigured without the need for DAD.
It results that a node could use that Address as source, with an SLLA
option in the message if required, to register any other addresses, either
Global or Unique-Local Addresses, which would be indicated in the Target.
</t>
<t>
The suggested change is to register the target of the NS message, and use
Target Link-Layer Address (TLLA) in the NS as opposed to the SLLA to
install a Neighbor Cache Entry. This would apply to both Efficient ND
and 6LoWPAN ND in a very same manner, with the caveat that depending on the
nature of the link between the 6LBR and the 6BBR, the 6LBR may resort to
classical ND or DHCPv6 to obtain the address that it uses to source the NS
registration messages, whether for itself or on behalf of LLN nodes.
</t>
</section> </section>
<section anchor='Rroot' title="RPL Root vs. 6LBR">
<t>6LoWPAN ND is unclear on how the 6LBR is discovered, and how the liveliness
of the 6LBR is asserted over time. On the other hand, the discovery
and liveliness of the RPL Root are obtained through the RPL protocol.
</t><t>
When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities
are co-located in order that the address of the 6LBR be indicated by RPL
DIO messages and to associate the unique ID from the DAR/DAC exchange with
the state that is maintained by RPL. The DAR/DAC exchange becomes a
preamble to the DAO messages that are used from then on to reconfirm the
registration, thus eliminating a duplication of functionality between DAO
and DAR messages.
</t>
</section> </section>
<section anchor="join" numbered="true" removeInRFC="false" toc="include" p
<section anchor='Sec' title="Securing the Registration"> n="section-4.2">
<t> <name slugifiedName="name-network-access-and-addressi">Network Access an
A typical attack against IPv6 ND is address spoofing, whereby a rogue node d Addressing</name>
claims the IPv6 Address of another node in and hijacks its traffic. The <section anchor="rflo" numbered="true" removeInRFC="false" toc="include"
threats against IPv6 ND as described in pn="section-4.2.1">
<xref target="RFC3971">SEcure Neighbor Discovery (SEND)</xref> <name slugifiedName="name-join-process">Join Process</name>
are applicable to 6LoPWAN ND as well, but the solution can not work as the <t indent="0" pn="section-4.2.1-1">
route over network does not permit direct peer to peer communication.
</t><t>
Additionally SEND requires considerably enlarged ND messages to carry
cryptographic material, and requires that each protected address is generated
cryptographically, which implies the computation of a different key for
each Cryptographically Generated Address (CGA). SEND as defined in
<xref target="RFC3971"/> is thus largely unsuitable for application in a LLN.
</t><t>
With 6LoWPAN ND, as illustrated in <xref target='figReg'/>, it is
possible to leverage the registration state in the 6LBR, which may store
additional security information for later proof of ownership. If this
information proves the ownership independently of the address itself,
then a single proof may be used to protect multiple addresses.
</t><t>
Once an Address is registered,
the 6LBR maintains a state for that Address and is in position to bind
securely the first registration with the Node that placed it, whether the
Address is CGA or not. It should thus be possible to protect the ownership of
all the addresses of a 6LoWPAN Node with a single key, and there should not
be a need to carry the cryptographic material more than once to the 6LBR.
</t><t>
The energy constraint is usually a foremost factor, and attention should be
paid to minimize the burden on the CPU. Hardware-assisted support of variants
of the <xref target="RFC3610">Counter with CBC-MAC</xref> (CCM) authenticated
encryption block cipher mode such as CCM* are common in LowPower ship-set
implementations, and 6LoWPAN ND security mechanism should be capable to
reuse them when applicable.
</t><t>
Finally, the code footprint in the device being also an issue, the capability
to reuse not only hardware-assist mechanisms but also software across layers
has to be considered. For instance, if code has to be present for upper-layer
operations, e.g <xref target="RFC6655">AES-CCM Cipher Suites for Transport
Layer Security (TLS)</xref>, then the capability to reuse that code should be
considered.
</t>
-->
</section>
<section anchor='join'><name>Network Access and Addressing</name>
<section anchor='rflo'><name>Join Process</name>
<t>
A new device, called the pledge, undergoes the join protocol to become a node A new device, called the pledge, undergoes the join protocol to become a node
in a 6TiSCH network. This usually occurs only once when the device is in a 6TiSCH network. This usually occurs only once when the device is
first powered on. The pledge communicates with the Join Registrar/Coordi nator first powered on. The pledge communicates with the Join Registrar/Coordi nator
(JRC) of the network through a Join Proxy (JP), a radio neighbor of the p ledge. (JRC) of the network through a Join Proxy (JP), a radio neighbor of the p ledge.
</t><t> </t>
The JP is discovered though MAC layer beacons. When multiple JPs from pos <t indent="0" pn="section-4.2.1-2">
sibly multiple networks are visible, trial and error till an acceptable position The JP is discovered though MAC-layer beacons. When multiple JPs from pos
in the right network is obtained becomes ineffficient. sibly
<xref target='I-D.ietf-6tisch-enrollment-enhanced-beacon'/> adds a new su multiple networks are visible, using trial and error until an acceptable
btype in the Information Element that was delegated to the IETF <xref target='RF position
C8137'/> and provides visibility on the network that can be joined and the willi in the right network is obtained becomes inefficient.
ngness by the JP and the Root to be used by the pledge. <xref target="RFC9032" format="default" sectionFormat="of" derivedContent
</t><t> ="RFC9032"/> adds a new subtype in the Information Element that
was delegated to the IETF <xref target="RFC8137" format="default" section
Format="of" derivedContent="RFC8137"/> and provides visibility
into the network that can be joined and the willingness of the JP and the
Root to be used by the pledge.
</t>
<t indent="0" pn="section-4.2.1-3">
The join protocol provides the following functionality: The join protocol provides the following functionality:
</t><ul spacing='normal'> </t>
<li> Mutual authentication</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li> Authorization</li> -4.2.1-4">
<li> Parameter distribution to the pledge over a secure channel</li> <li pn="section-4.2.1-4.1"> Mutual authentication</li>
</ul><t> <li pn="section-4.2.1-4.2"> Authorization</li>
</t> <li pn="section-4.2.1-4.3"> Parameter distribution to the pledge ove
r a secure channel</li>
<t> </ul>
Minimal Security Framework for 6TiSCH <xref target='I-D.ietf-6tisch-mini <t indent="0" pn="section-4.2.1-5">
mal-security'/> The Minimal Security Framework for 6TiSCH <xref target="RFC9031" format=
"default" sectionFormat="of" derivedContent="RFC9031"/>
defines the minimal mechanisms required for this join process to occur i n a secure defines the minimal mechanisms required for this join process to occur i n a secure
manner. The specification defines the Constrained Join Protocol (CoJP) t hat is used manner. The specification defines the Constrained Join Protocol (CoJP), which is used
to distribute the parameters to the pledge over a secure session establi shed through to distribute the parameters to the pledge over a secure session establi shed through
OSCORE <xref target='I-D.ietf-core-object-security'/>, and a secure conf iguration of the network OSCORE <xref target="RFC8613" format="default" sectionFormat="of" derive dContent="RFC8613"/> and which describes the secure configuration of the network
stack. In the minimal setting with pre-shared keys (PSKs), CoJP allows t he pledge to stack. In the minimal setting with pre-shared keys (PSKs), CoJP allows t he pledge to
join after a single round-trip exchange with the JRC. The provisioning o f the PSK to join after a single round-trip exchange with the JRC. The provisioning o f the PSK to
the pledge and the JRC needs to be done out of band, through a 'one-touc h' the pledge and the JRC needs to be done out of band, through a 'one-touc h'
bootstrapping process, which effectively enrolls the pledge into the dom ain managed by bootstrapping process, which effectively enrolls the pledge into the dom ain managed by
the JRC. the JRC.
</t> </t>
<t indent="0" pn="section-4.2.1-6">
<t> In certain use cases, the 'one-touch' bootstrapping is not feasible due
In certain use cases, the 'one touch' bootstrapping is not feasible due to the
to the operational constraints, and the enrollment of the pledge into the domai
operational constraints and the enrollment of the pledge into the domain n needs to occur
needs to occur
in-band. This is handled through a 'zero-touch' extension of the Minimal Security Framework in-band. This is handled through a 'zero-touch' extension of the Minimal Security Framework
for 6TiSCH. Zero touch <xref target='I-D.ietf-6tisch-dtsecurity-zerotouc for 6TiSCH. The zero-touch extension <xref target="I-D.ietf-6tisch-dtsec
h-join'/> extension leverages urity-zerotouch-join" format="default" sectionFormat="of" derivedContent="ZEROTO
the 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' [<xref tar UCH-JOIN"/> leverages
get='I-D.ietf-anima-bootstrapping-keyinfra'/> the "<xref target="RFC8995" format="title" sectionFormat="of" derivedCon
tent="Bootstrapping Remote Secure Key Infrastructure (BRSKI)"/>" <xref target="R
FC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>
work to establish a shared secret between a pledge and the JRC without n ecessarily having work to establish a shared secret between a pledge and the JRC without n ecessarily having
them belong to a common (security) domain at join time. This happens thr ough inter-domain them belong to a common (security) domain at join time. This happens thr ough inter-domain
communication occurring between the JRC of the network and the domain of the pledge, communication occurring between the JRC of the network and the domain of the pledge,
represented by a fourth entity, Manufacturer Authorized Signing Authorit y (MASA). Once represented by a fourth entity, Manufacturer Authorized Signing Authorit y (MASA). Once
the zero-touch exchange completes, the CoJP exchange defined in <xref ta rget='I-D.ietf-6tisch-minimal-security'/> the zero-touch exchange completes, the CoJP exchange defined in <xref ta rget="RFC9031" format="default" sectionFormat="of" derivedContent="RFC9031"/>
is carried over the secure session established between the pledge and th e JRC. is carried over the secure session established between the pledge and th e JRC.
</t> </t>
<t indent="0" pn="section-4.2.1-7">
<t> <xref target="figJoin" format="default" sectionFormat="of" derivedConten
<xref target='figJoin'/> depicts the join process and where a Link-Local t="Figure 4"/> depicts the join process and where a Link-Local
Address (LLA) is used, versus a Global Unicast Address (GUA). Address (LLA) is used, versus a Global Unicast Address (GUA).
</t> </t>
<figure anchor="figJoin" suppress-title="false" align="left" pn="figur
<figure anchor='figJoin' suppress-title='false'><name>Join process in a Multi-Li e-4">
nk Subnet. Parentheses () denote optional exchanges.</name> <name slugifiedName="name-join-process-in-a-multi-lin">Join Process
<artwork><![CDATA[ in a Multi-Link Subnet. Parentheses () denote optional exchanges.</name>
<artwork align="left" pn="section-4.2.1-8.1">
6LoWPAN Node 6LR 6LBR Join Registrar MASA 6LoWPAN Node 6LR 6LBR Join Registrar MASA
(pledge) (Join Proxy) (Root) /Coordinator (JRC) (pledge) (Join Proxy) (Root) /Coordinator (JRC)
| | | | | | | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network | | 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network |
| LLN link |Route-Over mesh|(the Internet)|(the Internet)| | LLN link |Route-Over mesh|(the Internet)|(the Internet)|
| | | | | | | | | |
| Layer-2 | | | | | Layer 2 | | | |
|enhanced beacon| | | | |Enhanced Beacon| | | |
|<--------------| | | | |&lt;--------------| | | |
| | | | | | | | | |
| NS (EARO) | | | | | NS (EARO) | | | |
| (for the LLA) | | | | | (for the LLA) | | | |
|-------------->| | | | |--------------&gt;| | | |
| NA (EARO) | | | | | NA (EARO) | | | |
|<--------------| | | | |&lt;--------------| | | |
| | | | | | | | | |
| (Zero-touch | | | | | (Zero-touch | | | |
| handshake) | (Zero-touch handshake) | (Zero-touch | | handshake) | (Zero-touch handshake) | (Zero-touch |
| using LLA | using GUA | handshake) | | using LLA | using GUA | handshake) |
|<------------->|<---------------------------->|<------------>| |<-------------&gt;|&lt;----------------------------&gt;|&lt;------------&g t;|
| | | | | | | | | |
| CoJP Join Req | | | | \ | CoJP Join Req | | | | \
| using LLA | | | | | | using LLA | | | | |
|-------------->| | | | | |--------------&gt;| | | | |
| | CoJP Join Request | | | | | CoJP Join Request | | |
| | using GUA | | | | | using GUA | | |
| |----------------------------->| | | C | |-----------------------------&gt;| | | C
| | | | | | o | | | | | | o
| | CoJP Join Response | | | J | | CoJP Join Response | | | J
| | using GUA | | | P | | using GUA | | | P
| |<-----------------------------| | | | |&lt;-----------------------------| | |
|CoJP Join Resp | | | | | |CoJP Join Resp | | | | |
| using LLA | | | | | | using LLA | | | | |
|<--------------| | | | / |&lt;--------------| | | | /
| | | | | | | | | |
]]></artwork> </artwork>
</figure> </figure>
</section>
</section> <section anchor="rreg" numbered="true" removeInRFC="false" toc="include"
pn="section-4.2.2">
<section anchor='rreg'><name>Registration</name> <name slugifiedName="name-registration">Registration</name>
<t indent="0" pn="section-4.2.2-1">
<t> Once the pledge successfully completes the CoJP exchange and becomes
Once the pledge successfully completes the CoJP protocol and becomes
a network node, it obtains the network prefix from neighboring routers a network node, it obtains the network prefix from neighboring routers
and registers its IPv6 addresses. and registers its IPv6 addresses.
As detailed in <xref target='RPLvs6lo'/>, the combined 6LoWPAN ND 6LBR As detailed in <xref target="RPLvs6lo" format="default" sectionFormat="
and Root of the RPL network learn information such as the device Unique of" derivedContent="Section 4.1"/>, the combined 6LoWPAN ND 6LBR
ID (from 6LoWPAN ND) and the updated Sequence Number (from RPL), and and Root of the RPL network learn information such as an identifier (de
perform 6LoWPAN ND proxy registration to the 6BBR of behalf of the LLN vice EUI-64 <xref target="RFC6775" format="default" sectionFormat="of" derivedCo
ntent="RFC6775"/> or a ROVR <xref target="RFC8505" format="default" sectionForma
t="of" derivedContent="RFC8505"/>
(from 6LoWPAN ND)) and the updated Sequence Number (from RPL), and
perform 6LoWPAN ND proxy registration to the 6BBR on behalf of the LLN
nodes. nodes.
</t> </t>
<t indent="0" pn="section-4.2.2-2">
<t> <xref target="figReg" format="default" sectionFormat="of" derivedConten
<xref target='figReg'/> illustrates the initial IPv6 signaling that t="Figure 5"/> illustrates the initial IPv6 signaling that
enables a 6LN to form a global address and register it to a 6LBR enables a 6LN to form a global address and register it to a 6LBR
using 6LoWPAN ND <xref target='RFC8505'/>, is then carried using 6LoWPAN ND <xref target="RFC8505" format="default" sectionFormat=
over RPL to the RPL Root, and then to the 6BBR. This flow happens "of" derivedContent="RFC8505"/>. It is then carried
over RPL to the RPL Root and then to the 6BBR. This flow happens
just once when the address is created and first registered. just once when the address is created and first registered.
</t> </t>
<figure anchor="figReg" suppress-title="false" align="left" pn="figure
<figure anchor='figReg' suppress-title='false'><name>Initial Registration Flow o -5">
ver Multi-Link Subnet</name> <name slugifiedName="name-initial-registration-flow-o">Initial Regis
<artwork><![CDATA[ tration Flow over Multi-Link Subnet</name>
<artwork align="left" pn="section-4.2.2-3.1">
6LoWPAN Node 6LR 6LBR 6BBR 6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (Root) (RPL leaf) (router) (Root)
| | | | | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh|Ethernet/serial| Backbone | LLN link |Route-Over mesh|Ethernet/serial| Backbone
| | | | | | | |
| RS (mcast) | | | | RS (mcast) | | |
|-------------->| | | |--------------&gt;| | |
|-----------> | | | |-----------&gt; | | |
|------------------> | | |------------------&gt; | |
| RA (unicast) | | | | RA (unicast) | | |
|<--------------| | | |&lt;--------------| | |
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|-------------->| | | |--------------&gt;| | |
| 6LoWPAN ND | Extended DAR | | | 6LoWPAN ND | Extended DAR | |
| |-------------->| | | |--------------&gt;| |
| | | NS(EARO) | | | | NS(EARO) |
| | |-------------->| | | |--------------&gt;|
| | | | NS-DAD | | | | NS-DAD
| | | |------> | | | |------&gt;
| | | | (EARO) | | | | (EARO)
| | | | | | | |
| | | NA(EARO) |<timeout> | | | NA(EARO) |&lt;timeout&gt;
| | |<--------------| | | |&lt;--------------|
| | Extended DAC | | | | Extended DAC | |
| |<--------------| | | |&lt;--------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<--------------| | | |&lt;--------------| | |
| | | | | | | |
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-4.2.2-4">
<t> <xref target="figReg2" format="default" sectionFormat="of" derivedConte
<xref target='figReg2'/> illustrates the repeating IPv6 signaling that nt="Figure 6"/> illustrates the repeating IPv6 signaling that
enables a 6LN to keep a global address alive and registered to its 6LBR enables a 6LN to keep a global address alive and registered with its 6L
BR
using 6LoWPAN ND to the 6LR, RPL to the RPL Root, and then 6LoWPAN ND using 6LoWPAN ND to the 6LR, RPL to the RPL Root, and then 6LoWPAN ND
again again
to the 6BBR, which avoids repeating the Extended DAR/DAC flow across to the 6BBR, which avoids repeating the Extended DAR/DAC flow across
the network when RPL can suffice as a keep-alive mechanism. the network when RPL can suffice as a keep-alive mechanism.
</t> </t>
<figure anchor='figReg2' suppress-title='false'><name>Next Registration Flow ove <figure anchor="figReg2" suppress-title="false" align="left" pn="figur
r Multi-Link Subnet</name> e-6">
<artwork><![CDATA[ <name slugifiedName="name-next-registration-flow-over">Next Registra
tion Flow over Multi-Link Subnet</name>
<artwork align="left" pn="section-4.2.2-5.1">
6LoWPAN Node 6LR 6LBR 6BBR 6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (Root) (RPL leaf) (router) (Root)
| | | | | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh| ant IPv6 link | Backbone | LLN link |Route-Over mesh| ant IPv6 link | Backbone
| | | | | |
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|-------------->| | | |--------------&gt;| | |
| NA(EARO) | | | | NA(EARO) | | |
|<--------------| | | |&lt;--------------| | |
| | DAO | | | | DAO | |
| |-------------->| | | |--------------&gt;| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |&lt;--------------| |
| | | NS(EARO) | | | | NS(EARO) |
| | |-------------->| | | |--------------&gt;|
| | | NA(EARO) | | | | NA(EARO) |
| | |<--------------| | | |&lt;--------------|
| | | | | | | |
| | | | | | | |
</artwork>
]]></artwork> </figure>
</figure> <t indent="0" pn="section-4.2.2-6">As the network builds up, a node sh
ould start as a
<t>As the network builds up, a node should start as a leaf to join the RPL network and may later turn into both a RPL-capable
leaf to join the RPL network, and may later turn into both a RPL-capable router and a 6LR, so as to accept leaf nodes recursively joining the network.
router and a 6LR, so as to accept leaf nodes </t>
to recursively join the network. </section>
</t> </section>
<section anchor="s6Pprot" numbered="true" removeInRFC="false" toc="include
</section> " pn="section-4.3">
<name slugifiedName="name-tsch-and-6top">TSCH and 6top</name>
</section> <!--"Network Access and Addressing" --> <section numbered="true" removeInRFC="false" toc="include" pn="section-4
.3.1">
<section anchor='s6Pprot'><name>TSCH and 6top</name> <name slugifiedName="name-6top">6top</name>
<section><name>6top</name> <t indent="0" pn="section-4.3.1-1">
<t>
6TiSCH expects a high degree of scalability together with a 6TiSCH expects a high degree of scalability together with a
distributed routing functionality based on RPL. To achieve this distributed routing functionality based on RPL. To achieve this
goal, the spectrum must be allocated in a way that allows for goal, the spectrum must be allocated in a way that allows for
spatial reuse between zones that will not interfere with one spatial reuse between zones that will not interfere with one
another. another.
In a large and spatially distributed network, a 6TiSCH node is In a large and spatially distributed network, a 6TiSCH node is
often in a good position to determine usage of the spectrum in its often in a good position to determine usage of the spectrum in its
vicinity. vicinity.
</t> </t>
<t> <t indent="0" pn="section-4.3.1-2">
With 6TiSCH, the abstraction of an IPv6 link is implemented as a With 6TiSCH, the abstraction of an IPv6 link is implemented as a
pair of bundles of cells, one in each direction. IP Links are only pair of bundles of cells, one in each direction. IP links are only
enabled between RPL parents and children. The 6TiSCH enabled between RPL parents and children. The 6TiSCH
operation is optimal when the size of a bundle is such that both operation is optimal when the size of a bundle minimizes both
the energy wasted in idle listening and the packet drops due to the energy wasted in idle listening and the packet drops due to
congestion loss are minimized, while packets are forwarded within congestion loss, while packets are forwarded within
an acceptable latency. an acceptable latency.
</t> </t>
<t indent="0" pn="section-4.3.1-3">
<t>
Use cases for distributed routing are often associated with a Use cases for distributed routing are often associated with a
statistical distribution of best-effort traffic with variable needs statistical distribution of best-effort traffic with variable needs
for bandwidth on each individual link. The 6TiSCH operation can for bandwidth on each individual link. The 6TiSCH operation can
remain optimal if RPL parents can adjust dynamically, and with enoug remain optimal if RPL parents can adjust, dynamically and with enoug
h reactivity to match the variations of best-effort traffic, h
the amount of bandwidth that is used to communicate between themselv reactivity to match the variations of best-effort traffic,
es and their children, in both directions. the amount of bandwidth that is used to communicate between themselv
es
and their children, in both directions.
In turn, the agility to fulfill the needs for additional cells In turn, the agility to fulfill the needs for additional cells
improves when the number of interactions with other devices and improves when the number of interactions with other devices and
the protocol latencies are minimized. the protocol latencies are minimized.
</t> </t>
<t indent="0" pn="section-4.3.1-4">
<t>
6top is a logical link control sitting between the IP layer and the 6top is a logical link control sitting between the IP layer and the
TSCH MAC layer, which provides the link abstraction that is required TSCH MAC layer, which provides the link abstraction that is required
for IP operations. The 6top protocol, 6P, which is specified in for IP operations. The 6top Protocol, 6P, which is specified in
<xref target='RFC8480'/>, is one of the services provided by 6top. <xref target="RFC8480" format="default" sectionFormat="of" derivedCo
ntent="RFC8480"/>, is one of the services provided by 6top.
In particular, the 6top services are available over a management In particular, the 6top services are available over a management
API that enables an external management entity to schedule cells API that enables an external management entity to schedule cells
and slotframes, and allows the addition of complementary and slotframes, and allows the addition of complementary
functionality, for instance a Scheduling Function functionality, for instance, a Scheduling Function
that manages a dynamic schedule management based on that manages a dynamic schedule based on
observed resource usage as discussed in <xref target='dynsched'/>. observed resource usage as discussed in <xref target="dynsched" form
at="default" sectionFormat="of" derivedContent="Section 4.4.2"/>.
For this purpose, the 6TiSCH architecture differentiates "soft" For this purpose, the 6TiSCH architecture differentiates "soft"
cells and "hard" cells. cells and "hard" cells.
</t> </t>
<section><name>Hard Cells</name> <section numbered="true" removeInRFC="false" toc="exclude" pn="section
<t> -4.3.1.1">
<name slugifiedName="name-hard-cells">Hard Cells</name>
<t indent="0" pn="section-4.3.1.1-1">
"Hard" cells are cells that "Hard" cells are cells that
are owned and managed by a separate scheduling entity (e.g., a PCE) are owned and managed by a separate scheduling entity (e.g., a PCE)
that specifies the slotOffset/channelOffset of the cells to be that specifies the slotOffset/channelOffset of the cells to be
added/moved/deleted, in which case 6top can only act as instructed, added/moved/deleted, in which case 6top can only act as instructed
and may not move hard cells in the TSCH schedule on its own. and may not move hard cells in the TSCH schedule on its own.
</t> </t>
</section> </section>
<section><name>Soft Cells</name> <section numbered="true" removeInRFC="false" toc="exclude" pn="section
<t> -4.3.1.2">
<name slugifiedName="name-soft-cells">Soft Cells</name>
<t indent="0" pn="section-4.3.1.2-1">
In contrast, "soft" cells are cells that 6top can manage locally. In contrast, "soft" cells are cells that 6top can manage locally.
6top contains a monitoring process which monitors the performance of 6top contains a monitoring process that monitors the performance of
cells, and can add, remove soft cells in the TSCH schedule to adapt cells and that can add and remove soft cells in the TSCH schedule to
adapt
to the traffic needs, or move one when it performs poorly. to the traffic needs, or move one when it performs poorly.
To reserve a soft cell, the higher layer does not indicate the exact To reserve a soft cell, the higher layer does not indicate the exact
slotOffset/channelOffset of the cell to add, but rather the resultin g slotOffset/channelOffset of the cell to add, but rather the resultin g
bandwidth and QoS requirements. When the monitoring process triggers bandwidth and QoS requirements. When the monitoring process triggers
a cell reallocation, the two neighbor devices communicating over thi s a cell reallocation, the two neighbor devices communicating over thi s
cell negotiate its new position in the TSCH schedule. cell negotiate its new position in the TSCH schedule.
</t> </t>
</section> </section>
</section> </section>
<section anchor="missf" numbered="true" removeInRFC="false" toc="include
<section anchor='missf'><name>Scheduling Functions and the 6top protocol</nam " pn="section-4.3.2">
e> <name slugifiedName="name-scheduling-functions-and-th">Scheduling Func
<t>In the case of soft cells, the cell management entity that controls the tions and the 6top Protocol</name>
<t indent="0" pn="section-4.3.2-1">In the case of soft cells, the cell
management entity that controls the
dynamic attribution of cells to adapt to the dynamics of variable rate flows dynamic attribution of cells to adapt to the dynamics of variable rate flows
is called a Scheduling Function (SF). is called a Scheduling Function (SF).
</t> </t>
<t> <t indent="0" pn="section-4.3.2-2">
There may be multiple SFs with more or less aggressive reaction to the There may be multiple SFs that react more or less aggressively to the
dynamics of the network. dynamics of the network.
</t> </t>
<t> <t indent="0" pn="section-4.3.2-3">
An SF may be seen as divided between an upper bandwidth adaptation logic An SF may be seen as divided between an upper bandwidth-adaptation logic
that is not aware of the particular technology that is used to obtain and that is unaware of the particular technology used to obtain and
release bandwidth, and an underlying service that maps those needs in the release bandwidth and an underlying service that maps those needs in the
actual technology, which means mapping the bandwidth onto cells in the case actual technology. In the case
of TSCH using the 6top protocol as illustrated in <xref target='fig6P'/>. of TSCH using the 6top Protocol as illustrated in <xref target="fig6P" format
</t> ="default" sectionFormat="of" derivedContent="Figure 7"/>,
this means mapping the bandwidth onto cells.
<figure anchor='fig6P' suppress-title='false'><name>SF/6P stack in 6top </t>
</name> <figure anchor="fig6P" suppress-title="false" align="left" pn="figure-
<artwork><![CDATA[ 7">
<name slugifiedName="name-sf-6p-stack-in-6top">SF/6P Stack in 6top</
name>
<artwork align="left" pn="section-4.3.2-4.1">
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function | | Scheduling Function | | Scheduling Function |
| Bandwidth adaptation | | Bandwidth adaptation | | Bandwidth adaptation | | Bandwidth adaptation |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function | | Scheduling Function | | Scheduling Function |
| TSCH mapping to cells | | TSCH mapping to cells | | TSCH mapping to cells | | TSCH mapping to cells |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| 6top cells negotiation | <- 6P -&gt; | 6top cells negotiation | | 6top cells negotiation | <- 6P -&gt; | 6top cells negotiation |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
Device A Device B Device A Device B
</artwork>
]]></artwork> </figure>
</figure> <t indent="0" pn="section-4.3.2-5">
<t>
The SF relies on 6top services that implement the The SF relies on 6top services that implement the
<xref target='RFC8480'> 6top Protocol (6P) </xref> <xref target="RFC8480" format="default" sectionFormat="of" derivedContent="R FC8480"> 6top Protocol (6P) </xref>
to negotiate the precise cells that will be allocated or freed based on the to negotiate the precise cells that will be allocated or freed based on the
schedule of the peer. It may be for instance that a peer wants to use a schedule of the peer. For instance, it may be that a peer wants to use a
particular time slot that is free in its schedule, but that timeslot is particular timeslot that is free in its schedule, but that timeslot is
already in use by the other peer for a communication with a third party on a already in use by the other peer to communicate with a third party on a
different cell. 6P enables the peers to find an agreement in a different cell. 6P enables the peers to find an agreement in a
transactional manner that ensures the final consistency of the nodes state. transactional manner that ensures the final consistency of the nodes' state.
</t> </t>
<t> <t indent="0" pn="section-4.3.2-6">
<xref target='I-D.ietf-6tisch-msf'>MSF</xref> is one of the possible <xref target="RFC9033" format="default" sectionFormat="of" derivedContent="R
scheduling functions. MSF uses the rendez-vous slot from FC9033">MSF</xref> is one of the possible
<xref target='RFC8180'/> for network discovery, neighbor discovery, and any Scheduling Functions. MSF uses the rendezvous slot from
<xref target="RFC8180" format="default" sectionFormat="of" derivedContent="R
FC8180"/> for network discovery, neighbor discovery, and any
other broadcast. other broadcast.
</t> </t>
<t> <t indent="0" pn="section-4.3.2-7">
For basic unicast communication with any neighbor, each node uses a receive For basic unicast communication with any neighbor, each node uses a receive
cell at a well-known slotOffset/channelOffset, derived from a hash of their cell at a well-known slotOffset/channelOffset, which is derived from a hash of their
own MAC address. own MAC address.
Nodes can reach any neighbor by installing a transmit (shared) cell with Nodes can reach any neighbor by installing a transmit (shared) cell with
slotOffset/channelOffset derived from the neighbor's MAC address. slotOffset/channelOffset derived from the neighbor's MAC address.
</t> </t>
<t> <t indent="0" pn="section-4.3.2-8">
For child-parent links, MSF continuously monitors the load to/from parents For child-parent links, MSF continuously monitors the load between parents
and children. It then uses 6P to install/remove unicast cells whenever the and children. It then uses 6P to install or remove unicast cells whenever th
current schedule appears to be under-/over- provisioned. e
current schedule appears to be under-provisioned or over-provisioned.
</t>
</section>
<section><name>6top and RPL Objective Function operations</name> </t>
<!-- 8.1.1. Support to RPL Neighbor Discovery and Parent Selection --> </section>
<t> <section numbered="true" removeInRFC="false" toc="include" pn="section-4
An implementation of a <xref target='RFC6550'>RPL</xref> Objective F .3.3">
unction <name slugifiedName="name-6top-and-rpl-objective-func">6top and RPL Ob
(OF), such as the <xref target='RFC6552'> RPL Objective Function Zer jective Function Operations</name>
o (OF0) <t indent="0" pn="section-4.3.3-1">
</xref> that is used in the <xref target='RFC8180'> Minimal An implementation of a <xref target="RFC6550" format="default" secti
6TiSCH Configuration </xref> to support RPL over a static schedule, onFormat="of" derivedContent="RFC6550">RPL</xref> Objective Function
may (OF), such as the <xref target="RFC6552" format="default" sectionFor
leverage, for its internal computation, the information maintained b mat="of" derivedContent="RFC6552">RPL Objective Function Zero (OF0)
y 6top. </xref> that is used in the <xref target="RFC8180" format="default"
</t> sectionFormat="of" derivedContent="RFC8180">Minimal
<t>An OF may require metrics about reachability, such as the Expected 6TiSCH Configuration</xref> to support RPL over a static schedule, m
Transmission Count (ETX) metric <xref target='RFC6551'/>. ay
leverage for its internal computation the information maintained by
6top.
</t>
<t indent="0" pn="section-4.3.3-2">An OF may require metrics about rea
chability, such as the Expected
Transmission Count (ETX) metric <xref target="RFC6551" format="defau
lt" sectionFormat="of" derivedContent="RFC6551"/>.
6top creates and maintains an abstract neighbor table, 6top creates and maintains an abstract neighbor table,
and this state may be leveraged to feed an OF and/or store OF inform ation and this state may be leveraged to feed an OF and/or store OF inform ation
as well. A neighbor table entry may contain a set of statistics with as well. A neighbor table entry may contain a set of statistics with
respect to that specific neighbor. respect to that specific neighbor.
</t> </t>
<t> <t indent="0" pn="section-4.3.3-3">
The neighbor information may include the time when the last The neighbor information may include the time when the last
packet has been received from that neighbor, a set of cell quality packet has been received from that neighbor, a set of cell quality
metrics, e.g., received signal strength indication (RSSI) or link metrics, e.g., received signal strength indication (RSSI) or link
quality indicator (LQI), the number of packets sent to the quality indicator (LQI), the number of packets sent to the
neighbor or the number of packets received from it. This neighbor, or the number of packets received from it. This
information can be made available through 6top management APIs information can be made available through 6top management APIs
and used for instance to compute a Rank Increment that will and used, for instance, to compute a Rank Increment that will
determine the selection of the preferred parent. determine the selection of the preferred parent.
</t> </t>
<t> <t indent="0" pn="section-4.3.3-4">
6top provides statistics about the underlying layer so the OF can be tuned 6top provides statistics about the underlying layer so the OF can be tuned
to the nature of the TSCH MAC layer. 6top also enables the RPL OF to to the nature of the TSCH MAC layer. 6top also enables the RPL OF to
influence the MAC behavior, for instance by configuring the periodic influence the MAC behavior, for instance, by configuring the periodi
ity of city of
IEEE Std. 802.15.4 Extended Beacons (EBs). By augmenting the EB peri IEEE Std 802.15.4 Extended Beacons (EBs). By augmenting the EB perio
odicity, it is dicity, it is
possible to change the network dynamics so as to improve the support of possible to change the network dynamics so as to improve the support of
devices that may change their point of attachment in the 6TiSCH netw ork. devices that may change their point of attachment in the 6TiSCH netw ork.
</t> </t>
<!-- PT: I took of the text about time source; the way we do it is a bi <t indent="0" pn="section-4.3.3-5">
t reverse: Some RPL control messages, such as the DODAG Information Object (DIO
we have an Instance that is used for time sourcing, and the preferred p ), are
arent
becomes the time source. If we change preferred parent we use the new o
ne 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. ICMPv6 messages that are broadcast to all neighbor nodes.
With 6TiSCH, the broadcast channel requirement is addressed by 6top With 6TiSCH, the broadcast channel requirement is addressed by 6top
by configuring TSCH to provide a broadcast channel, by configuring TSCH to provide a broadcast channel,
as opposed to, for instance, piggybacking the DIO messages in as opposed to, for instance, piggybacking the DIO messages in
Layer-2 Enhanced Beacons (EBs), which would produce undue timer Layer 2 Enhanced Beacons (EBs), which would produce undue timer
coupling among layers, packet size issues and could conflict with coupling among layers and packet size issues, and could conflict wit
h
the policy of production networks where EBs are mostly eliminated the policy of production networks where EBs are mostly eliminated
to conserve energy. to conserve energy.
</t> </t>
<!--t> </section>
In the TSCH schedule, each cell has the IEEE Std. 802.15.4e LinkType <section anchor="sync" numbered="true" removeInRFC="false" toc="include"
attribute. pn="section-4.3.4">
Setting the LinkType to ADVERTISING indicates that the cell MAY be u <name slugifiedName="name-network-synchronization">Network Synchroniza
sed to send an tion</name>
Enhanced Beacon. When a node forms its Enhanced Beacon, the cell, <t indent="0" pn="section-4.3.4-1">
with LinkType=ADVERTISING, SHOULD be included in the FrameAndLinkIE,
and its LinkOption field SHOULD be set to the combination of
"Receive" and "Timekeeping". The receiver of the Enhanced Beacon MAY
be listening at the cell to get the Enhanced Beacon ([IEEE Std. 8021
54e]).
6top takes this way to establish broadcast channel, which not only
allows TSCH to broadcast Enhanced Beacons, but also allows protocol
exchanges by an upper layer such as RPL.
</t>
<t>
To broadcast ICMPv6 control messages used by RPL such as DIO or DAO,
6top uses the payload of a Data frames. The message is inserted into
the
queue associated with the cells which LinkType is set to ADVERTISING
.
Then, taking advantage of the broadcast cell feature established wit
h
FrameAndLinkIE (as described above), the RPL control message can be
received by neighbors, which enables the maintenance of RPL DODAGs.
</t>
<t>
A LinkOption combining "Receive" and "Timekeeping" bits indicates to
the receivers of the Enhanced Beacon that the cell MUST be used as a
broadcast cell. The frequency of sending Enhanced Beacons or other
broadcast messages by the upper layer is determined by the timers
associated with the messages. For example, the transmission of
Enhance Beacons is triggered by a timer in 6top; transmission of a
DIO message is triggered by the trickle timer of RPL.
</t-->
</section>
<section anchor='sync'><name>Network Synchronization</name>
<t>
Nodes in a TSCH network must be time synchronized. Nodes in a TSCH network must be time synchronized.
A node keeps synchronized to its time source neighbor A node keeps synchronized to its time source neighbor
through a combination of frame-based and acknowledgment-based synchr onization. through a combination of frame-based and acknowledgment-based synchr onization.
To maximize battery life and network throughput, it is advisable tha t RPL ICMP discovery To maximize battery life and network throughput, it is advisable tha t RPL ICMP discovery
and maintenance traffic (governed by the trickle timer) be somehow c and maintenance traffic (governed by the Trickle timer) be somehow c
oordinated with the oordinated with the
transmission of time synchronization packets (especially with enhanc transmission of time synchronization packets (especially with Enhanc
ed beacons). ed Beacons).
</t> </t>
<t> <t indent="0" pn="section-4.3.4-2">
This could be achieved through an interaction of the 6top sublayer a This could be achieved through an interaction of the 6top sublayer a
nd the RPL objective Function, nd the RPL Objective Function,
or could be controlled by a management entity. or could be controlled by a management entity.
</t> </t>
<!-- TW: Concept of TSGI developed in separate standards-Track draft? - <t indent="0" pn="section-4.3.4-3">
-> Time distribution requires a loop-free structure. Nodes caught in a
<t> synchronization loop will rapidly
Time distribution requires a loop-free structure. Nodes taken in a s
ynchronization loop will rapidly
desynchronize from the network and become isolated. 6TiSCH uses a RP L DAG with a dedicated global Instance for the purpose of time synchronization. desynchronize from the network and become isolated. 6TiSCH uses a RP L DAG with a dedicated global Instance for the purpose of time synchronization.
That Instance is referred to as the Time Synchronization Global Inst ance (TSGI). That Instance is referred to as the Time Synchronization Global Inst ance (TSGI).
The TSGI can be operated in either of the 3 modes that are detailed The TSGI can be operated in either of the three modes that are detai
in section 3.1.3 of <xref target='RFC6550'>RPL</xref>, led
"Instances, DODAGs, and DODAG Versions". in Section <xref target="RFC6550" section="3.1.3" sectionFormat="bar
e" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1.
3" derivedContent="RFC6550"/>
of <xref target="RFC6550" format="default" sectionFormat="of" deri
vedContent="RFC6550">RPL</xref>, "Instances, DODAGs, and DODAG Versions".
Multiple uncoordinated DODAGs with independent Roots may be used if all the Roots Multiple uncoordinated DODAGs with independent Roots may be used if all the Roots
share a common time source such as the Global Positioning System (GP S). share a common time source such as the Global Positioning System (GP S).
</t> </t>
<t> <t indent="0" pn="section-4.3.4-4">
In the absence In the absence
of a common time source, the TSGI should form a single DODAG with a virtual Root. of a common time source, the TSGI should form a single DODAG with a virtual Root.
A backbone network is then used to synchronize and coordinate RPL op erations between A backbone network is then used to synchronize and coordinate RPL op erations between
the backbone routers that act as sinks for the LLN. the Backbone Routers that act as sinks for the LLN.
Optionally, RPL's periodic operations may be used to Optionally, RPL's periodic operations may be used to
transport the network synchronization. This may transport the network synchronization. This may
mean that 6top would need to trigger (override) the trickle timer if mean that 6top would need to trigger (override) the Trickle timer if
no other traffic has occurred for such a time that nodes may get out no other traffic has occurred for such a time that nodes may get out
of synchronization. of synchronization.
</t> </t>
<t> <t indent="0" pn="section-4.3.4-5">
A node that has not joined the TSGI advertises a MAC level Join Prio A node that has not joined the TSGI advertises a MAC-level Join Prio
rity rity
of 0xFF to notify its neighbors that is not capable of serving as ti me parent. of 0xFF to notify its neighbors that is not capable of serving as ti me parent.
A node that has joined the TSGI advertises a MAC level Join Priority set to A node that has joined the TSGI advertises a MAC-level Join Priority set to
its DAGRank() in that Instance, where DAGRank() is the operation spe cified in its DAGRank() in that Instance, where DAGRank() is the operation spe cified in
section 3.5.1 of <xref target='RFC6550'/>, "Rank Comparison". Section <xref target="RFC6550" section="3.5.1" sectionFormat="bare"
</t> format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.5.1"
<!-- TW: Official request made to move alter IEEE Std. 802.15.4e text. derivedContent="RFC6550"/>
Maybe remove last sentence? --> of <xref target="RFC6550" format="default" sectionFormat="of" derive
<t> dContent="RFC6550"/>, "Rank Comparison".
</t>
<t indent="0" pn="section-4.3.4-6">
The provisioning of a RPL Root is out of scope for both RPL and this The provisioning of a RPL Root is out of scope for both RPL and this
Architecture, whereas RPL enables to propagate configuration information down t architecture, whereas RPL enables the propagation of configuration i
he DODAG. This applies to the TSGI as well; a nformation
Root is configured or obtains by unspecified means the knowledge down the DODAG. This applies to the TSGI as well; a
Root is configured, or obtains by unspecified means, the knowledge
of the RPLInstanceID for the TSGI. The Root advertises its DagRank of the RPLInstanceID for the TSGI. The Root advertises its DagRank
in the TSGI, that must be less than 0xFF, as its Join Priority in in the TSGI, which must be less than 0xFF, as its Join Priority in
its IEEE Std. 802.15.4 Extended Beacons (EB). its IEEE Std 802.15.4 EBs.
</t> </t>
<t> <t indent="0" pn="section-4.3.4-7">
A node that reads a Join Priority of less than 0xFF should join the A node that reads a Join Priority of less than 0xFF should join the
neighbor with the lesser Join Priority and use it as time parent. If neighbor with the lesser Join Priority and use it as time parent. If
the node is configured to serve as time parent, then the node should the node is configured to serve as time parent, then the node should
join the TSGI, obtain a Rank in that Instance and start advertising join the TSGI, obtain a Rank in that Instance, and start advertising
its own DagRank in the TSGI as its Join Priority in its EBs. its own DagRank in the TSGI as its Join Priority in its EBs.
</t> </t>
</section> </section>
<section anchor="slotframes" numbered="true" removeInRFC="false" toc="in
<section anchor='slotframes'><name>Slotframes and CDU matrix</name> clude" pn="section-4.3.5">
<name slugifiedName="name-slotframes-and-cdu-matrix">Slotframes and CD
<t> U Matrix</name>
6TiSCH enables IPv6 best effort (stochastic) transmissions over a MAC <t indent="0" pn="section-4.3.5-1">
6TiSCH enables IPv6 best-effort (stochastic) transmissions over a MAC
layer that is also capable of scheduled (deterministic) transmissions. layer that is also capable of scheduled (deterministic) transmissions.
A window of time is defined A window of time is defined
around the scheduled transmission where the medium must, as much as around the scheduled transmission where the medium must, as much as
practically feasible, be free of contending energy to ensure that the practically feasible, be free of contending energy to ensure that the
medium is free of contending packets when time comes for a scheduled medium is free of contending packets when the time comes for a schedule d
transmission. transmission.
One simple way to obtain such a window is to format time and One simple way to obtain such a window is to format time and
frequencies in cells of transmission of equal duration. This is the frequencies in cells of transmission of equal duration. This is the
method that is adopted in IEEE Std. 802.15.4 TSCH as well as the Long method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long
Term Evolution (LTE) of cellular networks. Term Evolution (LTE) of cellular networks.
</t> </t>
<t> <t indent="0" pn="section-4.3.5-2">
The 6TiSCH architecture defines a global concept that is called a The 6TiSCH architecture defines a global concept that is called a
Channel Distribution and Usage (CDU) matrix to describe that formatting Channel Distribution and Usage (CDU) matrix to describe that formatting
of time and frequencies, of time and frequencies.
</t> </t>
<t> <t indent="0" pn="section-4.3.5-3">
A CDU matrix is defined centrally A CDU matrix is defined centrally
as part of the network definition. It is a matrix of cells with a as part of the network definition. It is a matrix of cells with a
height equal to the number of available channels (indexed by height equal to the number of available channels (indexed by
ChannelOffsets) and a width (in timeslots) that is the period of the channelOffsets) and a width (in timeslots) that is the period of the
network scheduling operation (indexed by slotOffsets) for that CDU network scheduling operation (indexed by slotOffsets) for that CDU
matrix. There are different models for scheduling the usage of the matrix. There are different models for scheduling the usage of the
cells, which place the responsibility of avoiding collisions either on cells, which place the responsibility of avoiding collisions either on
a central controller or on the devices themselves, at an extra cost in a central controller or on the devices themselves, at an extra cost in
terms of energy to scan for free cells (more in <xref target='schd'/>). terms of energy to scan for free cells (more in <xref target="schd" for
</t> mat="default" sectionFormat="of" derivedContent="Section 4.4"/>).
<t> </t>
<t indent="0" pn="section-4.3.5-4">
The size of a cell is a timeslot duration, and The size of a cell is a timeslot duration, and
values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to
accommodate for the transmission of a frame and an ack, including the accommodate for the transmission of a frame and an ack, including the
security validation on the receive side which may take up to a few security validation on the receive side, which may take up to a few
milliseconds on some device architecture. milliseconds on some device architecture.
</t> </t>
<t> <t indent="0" pn="section-4.3.5-5">
A CDU matrix iterates over and over with a well-known channel rotation A CDU matrix iterates over a well-known channel rotation
called the hopping sequence. called the hopping sequence.
In a given network, there might be multiple CDU matrices that operate In a given network, there might be multiple CDU matrices that operate
with different width, so they have different durations and represent with different widths, so they have different durations and represent
different periodic operations. different periodic operations.
It is recommended that all CDU matrices in a 6TiSCH domain operate with It is recommended that all CDU matrices in a 6TiSCH domain operate with
the same cell duration and are aligned, so as to reduce the the same cell duration and are aligned so as to reduce the
chances of interferences from the Slotted ALOHA operations. chances of interferences from the Slotted ALOHA operations.
The knowledge of the CDU matrices is shared The knowledge of the CDU matrices is shared
between all the nodes and used in particular to define slotframes. between all the nodes and used in particular to define slotframes.
</t> </t>
<t> <t indent="0" pn="section-4.3.5-6">
A slotframe is a MAC-level abstraction that is common to all nodes and A slotframe is a MAC-level abstraction that is common to all nodes and
contains a series of timeslots of equal length and precedence. contains a series of timeslots of equal length and precedence.
It is characterized by a slotframe_ID, and a slotframe_size. It is characterized by a slotframe_ID and a slotframe_size.
A slotframe aligns to a CDU matrix for its parameters, such as number A slotframe aligns to a CDU matrix for its parameters, such as number
and duration of timeslots. and duration of timeslots.
</t> </t>
<t> <t indent="0" pn="section-4.3.5-7">
Multiple slotframes can coexist in a node schedule, i.e., a node can Multiple slotframes can coexist in a node schedule, i.e., a node can
have multiple activities scheduled in different slotframes. have multiple activities scheduled in different slotframes.
A slotframe is associated with a priority that may be related to A slotframe is associated with a priority that may be related to
the precedence of different 6TiSCH topologies. The slotframes may be the precedence of different 6TiSCH topologies. The slotframes may be
aligned to different CDU matrices and thus have different width. aligned to different CDU matrices and thus have different widths.
There is typically one slotframe for scheduled traffic that has the There is typically one slotframe for scheduled traffic that has the
highest precedence and one or more slotframe(s) for RPL traffic. highest precedence and one or more slotframe(s) for RPL traffic.
The timeslots in the slotframe are indexed by the SlotOffset; The timeslots in the slotframe are indexed by the slotOffset;
the first cell is at SlotOffset 0. the first cell is at slotOffset 0.
</t> </t>
<t> <t indent="0" pn="section-4.3.5-8">
When a packet is received from a higher layer for transmission, When a packet is received from a higher layer for transmission,
6top inserts that packet in the outgoing queue 6top inserts that packet in the outgoing queue
which matches the packet best (Differentiated Services that matches the packet best (Differentiated Services
<xref target='RFC2474'/> can therefore be used). <xref target="RFC2474" format="default" sectionFormat="of" derivedCont
ent="RFC2474"/> can therefore be used).
At each scheduled transmit slot, 6top looks for the frame At each scheduled transmit slot, 6top looks for the frame
in all the outgoing queues that best matches the cells. in all the outgoing queues that best matches the cells.
If a frame is found, it is given to the TSCH MAC for transmission. If a frame is found, it is given to the TSCH MAC for transmission.
</t> </t>
</section> </section>
<section anchor="DistRsvTS" numbered="true" removeInRFC="false" toc="inc
<section anchor='DistRsvTS'><name>Distributing the reservation of cells</n lude" pn="section-4.3.6">
ame> <name slugifiedName="name-distributing-the-reservatio">Distributing th
e Reservation of Cells</name>
<t> <t indent="0" pn="section-4.3.6-1">
The 6TiSCH architecture introduces the concept of chunks The 6TiSCH architecture introduces the concept of chunks
(<xref target='sixTTerminology'/>) to distribute the allocation of (<xref target="sixTTerminology" format="default" sectionFormat="of" derivedContent="Section 2.1"/>) to distribute the allocation of
the spectrum for a whole group of cells at a time. the spectrum for a whole group of cells at a time.
The CDU matrix is formatted into a set of chunks, possibly as The CDU matrix is formatted into a set of chunks, possibly as
illustrated in <xref target='fig10'/>, each of the chunks illustrated in <xref target="fig10" format="default" sectionFormat=" of" derivedContent="Figure 8"/>, each of the chunks
identified uniquely by a chunk-ID. The knowledge of this identified uniquely by a chunk-ID. The knowledge of this
formatting is shared between all the nodes in a 6TiSCH network. formatting is shared between all the nodes in a 6TiSCH network.
It could be conveyed during the join process, or codified into a pro It could be conveyed during the join process, codified into a profil
file document, or obtained using some other mechanism. This is as opposed e document,
to static scheduling that refers to the pre-programmed mechanism tha or obtained using some other mechanism. This is as opposed
t to Static Scheduling, which refers to the preprogrammed mechanism
is specified in <xref target='RFC8180'/> and pre-exists to the specified in <xref target="RFC8180" format="default" sectionFormat="
of" derivedContent="RFC8180"/> and which existed before the
distribution of the chunk formatting. distribution of the chunk formatting.
</t> </t>
<figure anchor='fig10'><name>CDU matrix Partitioning in Chunks</name <figure anchor="fig10" align="left" suppress-title="false" pn="figure-
> 8">
<artwork align='center'> <name slugifiedName="name-cdu-matrix-partitioning-in-">CDU Matrix Pa
<![CDATA[ rtitioning in Chunks</name>
<artwork align="center" pn="section-4.3.6-2.1">
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
... ...
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
+-----+-----+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+-----+-----+ +-----+
0 1 2 3 4 5 6 M 0 1 2 3 4 5 6 M
]]>
</artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-4.3.6-3">
<t> The 6TiSCH architecture envisions a protocol that enables chunk
The 6TiSCH Architecture envisions a protocol that enables chunk
ownership appropriation whereby a RPL parent ownership appropriation whereby a RPL parent
discovers a chunk that is not used in its interference domain, discovers a chunk that is not used in its interference domain,
claims the chunk, and then defends it in case another RPL claims the chunk, and then defends it in case another RPL
parent would attempt to appropriate it while it is in use. parent would attempt to appropriate it while it is in use.
The chunk is the basic unit of ownership that is used in that proces s. The chunk is the basic unit of ownership that is used in that proces s.
</t> </t>
<t> <t indent="0" pn="section-4.3.6-4">
As a result of the process of chunk ownership appropriation, the RPL As a result of the process of chunk ownership appropriation, the RPL
parent has exclusive authority to decide which cell in the parent has exclusive authority to decide which cell in the
appropriated chunk can be used by which node in its interference appropriated chunk can be used by which node in its interference
domain. In other words, it is implicitly delegated the right to domain. In other words, it is implicitly delegated the right to
manage the portion of the CDU matrix that is represented by the manage the portion of the CDU matrix that is represented by the
chunk. chunk.
<!-- Eliot's review: drop this sentence </t>
The RPL parent may thus orchestrate <t indent="0" pn="section-4.3.6-5">
which transmissions occur in any of the cells in the chunk, by
allocating cells from the chunk to any form of communication (unicas
t,
multicast) in any direction between itself and its children.
-->
</t>
<t>
Initially, those cells are added to the heap of free cells, then Initially, those cells are added to the heap of free cells, then
dynamically placed into existing bundles, in new bundles, or dynamically placed into existing bundles, into new bundles, or
allocated opportunistically for one transmission. allocated opportunistically for one transmission.
</t> </t>
<t indent="0" pn="section-4.3.6-6">
<t>
Note that a PCE is expected to have precedence in the Note that a PCE is expected to have precedence in the
allocation, so that a RPL parent would only be able to obtain allocation, so that a RPL parent would only be able to obtain
portions that are not in-use by the PCE. portions that are not in use by the PCE.
</t> </t>
</section>
</section> </section>
</section> <section anchor="schd" numbered="true" removeInRFC="false" toc="include" p
<!-- n="section-4.4">
<section title="Functional Flows"> <name slugifiedName="name-schedule-management-mechani">Schedule Manageme
<t> nt Mechanisms</name>
<list hangIndent="6" style="hanging"> <t indent="0" pn="section-4.4-1">
<t hangText="Join:"></t> 6TiSCH uses four paradigms to manage the TSCH schedule of the LLN nodes
<t hangText="Time Synchronization:"></t> : Static Scheduling,
<t hangText="Setup for routing:"></t> Neighbor-to-Neighbor Scheduling, Remote Monitoring and Scheduling Manag
<t hangText="PCE reservation:"></t> ement, and Hop-by-Hop Scheduling.
<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 to manage the TSCH schedule of the LLN nodes: S
tatic Scheduling,
neighbor-to-neighbor Scheduling, remote monitoring and scheduling manag
ement, and Hop-by-hop scheduling.
Multiple mechanisms are defined that implement the associated Interacti on Models, Multiple mechanisms are defined that implement the associated Interacti on Models,
and can be combined and used in the same LLN. and they can be combined and used in the same LLN.
Which mechanism(s) to use depends on application requirements. Which mechanism(s) to use depends on application requirements.
</t> </t>
<section anchor='mini'><name>Static Scheduling</name> <section anchor="mini" numbered="true" removeInRFC="false" toc="include"
<t> pn="section-4.4.1">
<name slugifiedName="name-static-scheduling">Static Scheduling</name>
<t indent="0" pn="section-4.4.1-1">
In the simplest instantiation of a 6TiSCH network, a common fixed In the simplest instantiation of a 6TiSCH network, a common fixed
schedule may be shared by all nodes in the network. Cells are shared , schedule may be shared by all nodes in the network. Cells are shared ,
and nodes contend for slot access in a slotted ALOHA manner. and nodes contend for slot access in a Slotted ALOHA manner.
</t> </t>
<t> <t indent="0" pn="section-4.4.1-2">
A static TSCH schedule can be used to bootstrap a network, as an A static TSCH schedule can be used to bootstrap a network, as an
initial phase during implementation, or as a fall-back mechanism in initial phase during implementation or as a fall-back mechanism in
case of network malfunction. case of network malfunction.
This schedule is pre-established, for instance decided by a network This schedule is preestablished, for instance, decided by a network
administrator based on operational needs. It can be pre-configured administrator based on operational needs. It can be preconfigured
into the nodes, or, more commonly, learned by a node when joining into the nodes, or, more commonly, learned by a node when joining
the network using standard IEEE Std. 802.15.4 Information Elements ( IE). the network using standard IEEE Std 802.15.4 Information Elements (I E).
Regardless, the schedule remains unchanged Regardless, the schedule remains unchanged
after the node has joined a network. after the node has joined a network.
RPL is used on the resulting network. This "minimal" scheduling RPL is used on the resulting network. This "minimal" scheduling
mechanism that implements this paradigm is detailed in mechanism that implements this paradigm is detailed in
<xref target='RFC8180'/>. <xref target="RFC8180" format="default" sectionFormat="of" derivedCo
</t> ntent="RFC8180"/>.
</section> </t>
<section anchor='dynsched'><name>Neighbor-to-neighbor Scheduling</name> </section>
<t> <section anchor="dynsched" numbered="true" removeInRFC="false" toc="incl
ude" pn="section-4.4.2">
<name slugifiedName="name-neighbor-to-neighbor-schedu">Neighbor-to-Nei
ghbor Scheduling</name>
<t indent="0" pn="section-4.4.2-1">
In the simplest instantiation of a 6TiSCH network described in In the simplest instantiation of a 6TiSCH network described in
<xref target='mini'/>, nodes may expect a packet at any cell in <xref target="mini" format="default" sectionFormat="of" derivedConte nt="Section 4.4.1"/>, nodes may expect a packet at any cell in
the schedule and will waste energy idle listening. In a more the schedule and will waste energy idle listening. In a more
complex instantiation of a 6TiSCH network, a matching portion of the complex instantiation of a 6TiSCH network, a matching portion of the
schedule is established between peers to reflect the observed amount schedule is established between peers to reflect the observed amount
of transmissions between those nodes. The aggregation of the cells of transmissions between those nodes. The aggregation of the cells
between a node and a peer forms a bundle that the 6top layer uses to between a node and a peer forms a bundle that the 6top sublayer uses to
implement the abstraction of a link for IP. The bandwidth on that implement the abstraction of a link for IP. The bandwidth on that
link is proportional to the number of cells in the bundle. link is proportional to the number of cells in the bundle.
</t><t> </t>
<t indent="0" pn="section-4.4.2-2">
If the size of a bundle is configured to fit an average amount of If the size of a bundle is configured to fit an average amount of
bandwidth, peak traffic is dropped. If the size is bandwidth, peak traffic is dropped. If the size is
configured to allow for peak emissions, energy is be wasted configured to allow for peak emissions, energy is wasted
idle listening. idle listening.
</t><t> </t>
As discussed in more details in <xref target='s6Pprot'/>, the <t indent="0" pn="section-4.4.2-3">
<xref target='RFC8480'>6top Protocol</xref> As discussed in more detail in <xref target="s6Pprot" format="defaul
t" sectionFormat="of" derivedContent="Section 4.3"/>, the
<xref target="RFC8480" format="default" sectionFormat="of" derivedCo
ntent="RFC8480">6top Protocol</xref>
specifies the exchanges between neighbor nodes to reserve soft cells specifies the exchanges between neighbor nodes to reserve soft cells
to transmit to one another, possibly under the control of a to transmit to one another, possibly under the control of a
Scheduling Function (SF). Because this reservation is done without Scheduling Function (SF). Because this reservation is done without
global knowledge of the schedule of other nodes in the LLN, scheduli ng global knowledge of the schedule of the other nodes in the LLN, sche duling
collisions are possible. collisions are possible.
<!-- 6top defines a monitoring process which </t>
continuously Tracks the packet delivery ratio of soft cells. <t indent="0" pn="section-4.4.2-4">
It uses these statistics to trigger the reallocation of a soft cell And as discussed in <xref target="missf" format="default" sectionFor
in the schedule, using a negotiation protocol between the neighbors mat="of" derivedContent="Section 4.3.2"/>,
nodes communicating over that cell. an optional SF is used to
In the most efficient instantiations of a 6TiSCH network, the size o monitor bandwidth usage and to perform requests for dynamic allocati
f on
the bundles that implement the links may be changed dynamically
in order to adapt to the need of end-to-end flows routed by RPL. -->
</t><t>
And as discussed in <xref target='missf'/>,
an optional Scheduling Function (SF) is used to
monitor bandwidth usage and perform requests for dynamic allocation
by the 6top sublayer. by the 6top sublayer.
The SF component is not part of the 6top sublayer. It may be The SF component is not part of the 6top sublayer. It may be
collocated on the same device or may be partially or fully offloaded co-located on the same device or may be partially or fully offloaded
to an external system. The <xref target='I-D.ietf-6tisch-msf'> to an external system. The <xref target="RFC9033" format="default" s
ectionFormat="of" derivedContent="RFC9033">
"6TiSCH Minimal Scheduling Function (MSF)"</xref> provides a simple "6TiSCH Minimal Scheduling Function (MSF)"</xref> provides a simple
scheduling function that can be used by default by devices that SF that can be used by default by devices that
support dynamic scheduling of soft cells. support dynamic scheduling of soft cells.
</t> </t>
<t> <t indent="0" pn="section-4.4.2-5">
Monitoring and relocation is done in the 6top layer. For the upper Monitoring and relocation is done in the 6top sublayer. For the uppe
r
layer, the connection between two neighbor nodes appears as a number layer, the connection between two neighbor nodes appears as a number
of cells. of cells.
Depending on traffic requirements, the upper layer can request 6top Depending on traffic requirements, the upper layer can request 6top
to add or delete a number of cells scheduled to a particular to add or delete a number of cells scheduled to a particular
neighbor, without being responsible for choosing the exact neighbor, without being responsible for choosing the exact
slotOffset/channelOffset of those cells. slotOffset/channelOffset of those cells.
</t> </t>
</section> </section>
<section anchor='topint'><name>Remote Monitoring and Schedule Management</ <section anchor="topint" numbered="true" removeInRFC="false" toc="includ
name> e" pn="section-4.4.3">
<!-- <name slugifiedName="name-remote-monitoring-and-sched">Remote Monitori
<t> ng and Schedule Management</name>
The 6top interface document <t indent="0" pn="section-4.4.3-1">
<xref target="I-D.ietf-6tisch-6top-interface"/> Remote Monitoring and Schedule Management refers to a DetNet/SDN model
specifies the generic data model that can be used to monitor and man
age
resources of the 6top sublayer. Abstract methods are suggested for u
se
by a management entity in the device. The data model also enables
remote control operations on the 6top sublayer.
</t>
<t>
The capability to interact with the node 6top sublayer from multiple
hops away
can be leveraged for monitoring, scheduling, or a combination of the
reof.
The architecture supports variations on the deployment model, and
focuses on the flows rather than
whether there is a proxy or a translation operation en-route.
</t>
<t>
<xref target="I-D.ietf-6tisch-coap"/> defines an mapping of
the 6top set of commands, which is described in
<xref target="I-D.ietf-6tisch-6top-interface"/>, to CoAP resources.
This allows an entity to interact with the 6top layer of a node that
is multiple hops away in a RESTful fashion.
</t>
<!--t>
The work at the 6TiSCH WG is focused on non-deterministic traffic and
does not provide the generic data model that would be necessary to
monitor and manage resources of the 6top sublayer. It is recognized
that CoAP can be appropriate to interact with the 6top layer of a
node that is multiple hops away across a 6TiSCH mesh.
</t>
<t>
The entity issuing the CoAP requests can be a central scheduling ent
ity
(e.g., a PCE), a node multiple hops away with the authority to modif
y the TSCH
schedule (e.g., the head of a local cluster), or a external device m
onitoring the
overall state of the network (e.g., NME). It is also possible that a
mapping entity on the backbone transforms a non-CoAP protocol such
as PCEP into the RESTful interfaces that the 6TiSCH devices support.
</t-->
<t>
Remote monitoring and Schedule Management refers to a DetNet/SDN model
whereby an NME and a scheduling entity, associated with a PCE, reside whereby an NME and a scheduling entity, associated with a PCE, reside
in a central controller and interact with the 6top layer to control in a central controller and interact with the 6top sublayer to control
IPv6 Links and Tracks (<xref target='ontrk'/>) in a 6TiSCH network. IPv6 links and Tracks (<xref target="ontrk" format="default" sectionFo
rmat="of" derivedContent="Section 4.5"/>) in a 6TiSCH network.
The composite centralized controller can assign physical resources The composite centralized controller can assign physical resources
(e.g., buffers and hard cells) to a particular Track to optimize the (e.g., buffers and hard cells) to a particular Track to optimize the
reliability within a bounded latency for a well-specified flow. reliability within a bounded latency for a well-specified flow.
</t> </t>
<t> <t indent="0" pn="section-4.4.3-2">
The work at the 6TiSCH WG focused on non-deterministic traffic and The work in the 6TiSCH Working Group focused on nondeterministic traffi
did not provide the generic data model that is necessary for the c and
did not provide the generic data model necessary for the
controller to monitor and manage resources of the 6top sublayer. controller to monitor and manage resources of the 6top sublayer.
This is deferred to future work, see <xref target='unchartered-tracks'/ This is deferred to future work, see <xref target="unchartered-tracks"
>. format="default" sectionFormat="of" derivedContent="Appendix A.1.2"/>.
</t>
<!-- for later -->
<t> </t>
With respect to Centralized routing and scheduling, it is envisioned <t indent="0" pn="section-4.4.3-3">
that the related component of the 6TiSCH Architecture would be an With respect to centralized routing and scheduling, it is envisioned
extension of the that the related component of the 6TiSCH architecture would be an
<xref target='RFC8655'>DetNet Architecture</xref>, extension of the <xref target="RFC8655" format="default" sectionFormat=
which studies Layer-3 aspects of Deterministic Networks, and covers "of" derivedContent="RFC8655">DetNet architecture</xref>,
networks that span multiple Layer-2 domains. which studies Layer 3 aspects of Deterministic Networks and covers
</t> networks that span multiple Layer 2 domains.
<t> </t>
The DetNet architecture is a form of Software Defined Networking (SDN) <t indent="0" pn="section-4.4.3-4">
Architecture and is composed of three planes, a (User) Application The DetNet architecture is a form of Software-Defined Networking (SDN)
Plane, a Controller Plane (where the PCE operates), and a Network Plane architecture and is composed of three planes: a (User) Application
Plane, a Controller Plane (where the PCE operates), and a Network Plane
,
which can represent a 6TiSCH LLN. which can represent a 6TiSCH LLN.
</t> </t>
<t> <t indent="0" pn="section-4.4.3-5">
<xref target='RFC7426'>Software-Defined Networking (SDN): <xref target="RFC7426" format="default" sectionFormat="of" derivedConte
Layers and Architecture Terminology</xref> proposes a generic nt="RFC7426">"Software-Defined Networking (SDN):
Layers and Architecture Terminology"</xref> proposes a generic
representation of the SDN architecture that is reproduced in representation of the SDN architecture that is reproduced in
<xref target='RFC7426archi'/>. <xref target="RFC7426archi" format="default" sectionFormat="of" derived
</t> Content="Figure 9"/>.
<figure align='center' anchor='RFC7426archi'><name>SDN Layers and Architecture </t>
Terminology per RFC 7426</name> <figure align="center" anchor="RFC7426archi" suppress-title="false" pn
<artwork align='left'> ="figure-9">
<![CDATA[ <name slugifiedName="name-sdn-layers-and-architecture">SDN Layers an
d Architecture Terminology per RFC 7426</name>
<artwork align="left" pn="section-4.4.3-6.1">
o--------------------------------o o--------------------------------o
| | | |
| +-------------+ +----------+ | | +-------------+ +----------+ |
| | Application | | Service | | | | Application | | Service | |
| +-------------+ +----------+ | | +-------------+ +----------+ |
| Application Plane | | Application Plane |
o---------------Y----------------o o---------------Y----------------o
| |
*-----------------------------Y---------------------------------* *-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) | | Network Services Abstraction Layer (NSAL) |
skipping to change at line 2199 skipping to change at line 2229
| | | |
*------------Y---------------------------------Y----------------* *------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) | | Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------* *------------Y---------------------------------Y----------------*
| | | | | | | |
| o-------Y----------o +-----+ o--------Y----------o | | o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | | | | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o | | o------------------o +-----+ o-------------------o |
| Network Device | | Network Device |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t>The PCE establishes end-to-end Tracks of hard cells, which are describe <t indent="0" pn="section-4.4.3-7">The PCE establishes end-to-end Trac
d ks of hard cells, which are described
in more details in <xref target='trkfwd'/>. in more detail in <xref target="trkfwd" format="default" sectionFormat="of
</t> " derivedContent="Section 4.6.1"/>.
<t> </t>
The DetNet work is expected to enable end to end Deterministic Path <t indent="0" pn="section-4.4.3-8">
across heterogeneous network. This can be for instance a 6TiSCH LLN The DetNet work is expected to enable end-to-end deterministic paths
and an Ethernet Backbone. across heterogeneous networks. This can be, for instance, a 6TiSCH LLN
and an Ethernet backbone.
</t> </t>
<t>This model fits the 6TiSCH extended configuration, whereby a <t indent="0" pn="section-4.4.3-9">This model fits the 6TiSCH extended
configuration, whereby a
6BBR federates 6BBR federates
multiple 6TiSCH LLN in a single subnet over a backbone that can be, multiple 6TiSCH LLNs in a single subnet over a backbone that can be,
for instance, Ethernet or Wi-Fi. In that model, for instance, Ethernet or Wi-Fi. In that model,
6TiSCH 6BBRs synchronize with one another over the backbone, so as 6TiSCH 6BBRs synchronize with one another over the backbone, so as
to ensure that the multiple LLNs that form the IPv6 subnet stay to ensure that the multiple LLNs that form the IPv6 subnet stay
tightly synchronized. tightly synchronized.
</t> </t>
<t> <t indent="0" pn="section-4.4.3-10">
If the Backbone is Deterministic, then the If the backbone is deterministic, then the
Backbone Router ensures that the end-to-end deterministic Backbone Router ensures that the end-to-end deterministic
behavior is maintained between the LLN and the backbone. behavior is maintained between the LLN and the backbone.
It is the responsibility of the PCE to compute a It is the responsibility of the PCE to compute a
deterministic path and to end across the TSCH network and an IEEE Std. deterministic path end to end across the TSCH network and an IEEE Std 8
802.1 02.1
TSN Ethernet backbone, and that of DetNet to enable end-to-end determin TSN Ethernet backbone, and it is the responsibility of DetNet to enable
istic end-to-end deterministic
forwarding. forwarding.
</t> </t>
</section> </section>
<section><name>Hop-by-hop Scheduling</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-4
<t> .4.4">
A node can reserve a <xref target='ontrk'>Track</xref> to one or more <name slugifiedName="name-hop-by-hop-scheduling">Hop-by-Hop Scheduling
</name>
<t indent="0" pn="section-4.4.4-1">
A node can reserve a <xref target="ontrk" format="default" sectionFormat="of
" derivedContent="Section 4.5">Track</xref> to one or more
destination(s) that are multiple hops away by installing soft cells at each destination(s) that are multiple hops away by installing soft cells at each
intermediate node. intermediate node.
This forms a Track of soft cells. A Track Scheduling Function above the 6top This forms a Track of soft cells. A Track SF above the 6top
sublayer of each node on the Track is needed to monitor these soft cells and sublayer of each node on the Track is needed to monitor these soft cells and
trigger relocation when needed. trigger relocation when needed.
</t> </t>
<t> <t indent="0" pn="section-4.4.4-2">
This hop-by-hop reservation mechanism is expected to be similar in essence This hop-by-hop reservation mechanism is expected to be similar in essence
to <xref target='RFC3209'/> and/or <xref target='RFC4080'/>/<xref target='RF C5974'/>. to <xref target="RFC3209" format="default" sectionFormat="of" derivedContent ="RFC3209"/> and/or <xref target="RFC4080" format="default" sectionFormat="of" d erivedContent="RFC4080"/> and <xref target="RFC5974" format="default" sectionFor mat="of" derivedContent="RFC5974"/>.
The protocol for a node to trigger hop-by-hop scheduling is not yet defined. The protocol for a node to trigger hop-by-hop scheduling is not yet defined.
</t> </t>
</section>
</section> </section>
</section> <section anchor="ontrk" numbered="true" removeInRFC="false" toc="include"
<!-- pn="section-4.5">
<section anchor="topo" title="6TiSCH Device Capabilities"> <name slugifiedName="name-on-tracks">On Tracks</name>
<t indent="0" pn="section-4.5-1">
<t>6TiSCH nodes are usually IoT devices, characterized by very limited amount
of memory, just enough buffers to store one or a few IPv6 packets, and
limited bandwidth between peers. It results that a node will maintain only a
small number of peering information, and will not be able to store many
packets waiting to be forwarded. Peers can be identified through MAC or IPv6
addresses, but a Cryptographically Generated Address <xref target="RFC3972"/>
(CGA) may also be used.
</t>
<t>
Neighbors can be discovered over the radio using mechanism such as beacons,
but, though the neighbor information is available in the 6TiSCH interface
data model, 6TiSCH does not describe a protocol to pro-actively push the
neighborhood information to a PCE.
This protocol should be described and should operate over CoAP. The protocol
should be able to carry multiple metrics, in particular the same metrics as
used for RPL operations <xref target="RFC6551"/>.
</t>
<t>
The energy that the device consumes in sleep, transmit and receive modes can
be evaluated and reported. So can the amount of energy that is stored in the
device and the power that it can be scavenged from the environment. The PCE
SHOULD be able to compute Tracks that will implement policies on how the
energy is consumed, for instance balance between nodes, ensure that the spent
energy does not exceeded the scavenged energy over a period of time, etc...
</t>
</section>
</section>
-->
<section anchor='ontrk'><name>On Tracks</name>
<t>
The architecture introduces the concept of a Track, which is a directed path The architecture introduces the concept of a Track, which is a directed path
from a source 6TiSCH node to one or more destination 6TiSCH node(s) from a source 6TiSCH node to one or more destination 6TiSCH node(s)
across a 6TiSCH LLN. across a 6TiSCH LLN.
</t> </t>
<t> <t indent="0" pn="section-4.5-2">
A Track is the 6TiSCH instantiation of the concept of a Deterministic Path A Track is the 6TiSCH instantiation of the concept of a deterministic path
as described in <xref target='RFC8655'/>. as described in <xref target="RFC8655" format="default" sectionFormat="of" d
erivedContent="RFC8655"/>.
Constrained resources such as memory buffers are reserved for that Track in Constrained resources such as memory buffers are reserved for that Track in
intermediate 6TiSCH nodes to avoid loss related to limited capacity. intermediate 6TiSCH nodes to avoid loss related to limited capacity.
A 6TiSCH node along a Track not only knows which bundles of cells it should A 6TiSCH node along a Track not only knows which bundles of cells it should
use to receive packets from a previous hop, but also knows which bundle(s) use to receive packets from a previous hop but also knows which bundle(s)
it should use to send packets to its next hop along the Track. it should use to send packets to its next hop along the Track.
</t> </t>
<section numbered="true" removeInRFC="false" toc="include" pn="section-4
<section><name>General Behavior of Tracks</name> .5.1">
<t> <name slugifiedName="name-general-behavior-of-tracks">General Behavior
A Track is associated with Layer-2 bundles of cells with related schedules of Tracks</name>
and logical relationships and that ensure that a packet that is injected in <t indent="0" pn="section-4.5.1-1">
A Track is associated with Layer 2 bundles of cells with related schedules
and logical relationships that ensure that a packet that is injected in
a Track will progress in due time all the way to destination. a Track will progress in due time all the way to destination.
</t> </t>
<t> <t indent="0" pn="section-4.5.1-2">
Multiple cells may be scheduled in a Track for the transmission of a single Multiple cells may be scheduled in a Track for the transmission of a single
packet, in which case the normal operation of IEEE Std. 802.15.4 Automatic packet, in which case the normal operation of IEEE Std 802.15.4 Automatic
Repeat-reQuest (ARQ) can take place; the acknowledgment may be omitted in Repeat-reQuest (ARQ) can take place; the acknowledgment may be omitted in
some cases, for instance if there is no scheduled cell for a possible retry. some cases, for instance, if there is no scheduled cell for a possible retry
</t> .
<t> </t>
<t indent="0" pn="section-4.5.1-3">
There are several benefits for using a Track to forward a packet from a There are several benefits for using a Track to forward a packet from a
source node to the destination node. source node to the destination node:
</t> </t>
<ol spacing='normal'> <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-
<li> 4.5.1-4">
Track forwarding, as further described in <xref target='trkfwd'/>, is a <li pn="section-4.5.1-4.1" derivedCounter="1.">
Layer-2 forwarding scheme, which introduces less process delay and Track Forwarding, as further described in <xref target="trkfwd" format="
overhead than Layer-3 forwarding scheme. Therefore, LLN Devices can save default" sectionFormat="of" derivedContent="Section 4.6.1"/>, is a
more energy and resource, which is critical for resource constrained devi Layer 2 forwarding scheme, which introduces less process delay and
ces. overhead than a Layer 3 forwarding scheme. Therefore, LLN devices can sa
ve
more energy and resources, which is critical for resource-constrained dev
ices.
</li> </li>
<li> <li pn="section-4.5.1-4.2" derivedCounter="2.">
Since channel resources, i.e., bundles of cells, have been reserved for Since channel resources, i.e., bundles of cells, have been reserved for
communications between 6TiSCH nodes of each hop on the Track, the communications between 6TiSCH nodes of each hop on the Track, the
throughput and the maximum latency of the traffic along a Track are throughput and the maximum latency of the traffic along a Track are
guaranteed and the jitter is maintained small. guaranteed, and the jitter is minimized.
</li> </li>
<li> <li pn="section-4.5.1-4.3" derivedCounter="3.">
By knowing the scheduled time slots of incoming bundle(s) and outgoing By knowing the scheduled timeslots of incoming bundle(s) and outgoing
bundle(s), 6TiSCH nodes on a Track could save more energy by staying in bundle(s), 6TiSCH nodes on a Track could save more energy by staying in
sleep state during in-active slots. sleep state during inactive slots.
</li> </li>
<li> <li pn="section-4.5.1-4.4" derivedCounter="4.">
Tracks are protected from interfering with one another if a cell is sched Tracks are protected from interfering with one another if a cell is
uled to belong to at most one Track, and congestion loss is avoided if at most o scheduled to belong to at most one Track, and congestion loss is avoided
ne if at most one
packet can be presented to the MAC to use that cell. packet can be presented to the MAC to use that cell.
Tracks enhance the reliability of transmissions and thus further improve Tracks enhance the reliability of transmissions and thus further improve
the energy consumption in LLN Devices by reducing the chances of the energy consumption in LLN devices by reducing the chances of
retransmission. retransmission.
</li> </li>
</ol><t> </ol>
</t> </section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4
.5.2">
<section><name>Serial Track</name> <name slugifiedName="name-serial-track">Serial Track</name>
<t indent="0" pn="section-4.5.2-1">
<t> A Serial (or simple) Track is the 6TiSCH version of a circuit: a bundle of
A Serial (or simple) Track is the 6TiSCH version of a circuit; a bundle of cells that are programmed to receive (RX-cells) is uniquely paired with a
cells that are programmed to receive (RX-cells) is uniquely paired to a bundle of cells that are set to transmit (TX-cells), representing a Layer 2
bundle of cells that are set to transmit (TX-cells), representing a Layer-2 forwarding state that can be used regardless of the network-layer protocol.
forwarding state which can be used regardless of the network layer protocol.
A Serial Track is thus formed end-to-end as a succession of A Serial Track is thus formed end-to-end as a succession of
paired bundles, a receive bundle from the previous hop and a transmit bundle paired bundles: a receive bundle from the previous hop and a transmit bundle
to the next hop along the Track. to the next hop along the Track.
</t> </t>
<t> <t indent="0" pn="section-4.5.2-2">
For a given iteration of the device schedule, the effective channel of the For a given iteration of the device schedule, the effective channel of the
cell is obtained by following in a loop a well-known hopping sequence that cell is obtained by looping through a well-known hopping sequence
started at Epoch time at the channelOffset of the cell, which results beginning at Epoch time and starting at the cell's channelOffset, which resu
in a rotation of the frequency that used for transmission. lts
in a rotation of the frequency that is used for transmission.
The bundles may be computed so as to accommodate both variable rates and The bundles may be computed so as to accommodate both variable rates and
retransmissions, so they might not be fully used in the iteration of the retransmissions, so they might not be fully used in the iteration of the
schedule. schedule.
</t> </t>
</section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4
.5.3">
<section><name>Complex Track with Replication and Elimination</name> <name slugifiedName="name-complex-track-with-replicat">Complex Track w
ith Replication and Elimination</name>
<t> <t indent="0" pn="section-4.5.3-1">
The art of Deterministic Networks already include Packet Replication and The art of Deterministic Networks already includes packet replication and
Elimination techniques. Example elimination techniques. Example
standards include the Parallel Redundancy Protocol (PRP) and the standards include the Parallel Redundancy Protocol (PRP) and the
High-availability Seamless Redundancy (HSR) <xref target='IEC62439'/>. High-availability Seamless Redundancy (HSR) <xref target="IEC62439" format=" default" sectionFormat="of" derivedContent="IEC62439"/>.
Similarly, and as opposed to a Serial Track that is a sequence of nodes Similarly, and as opposed to a Serial Track that is a sequence of nodes
and links, a Complex Track is shaped as a directed acyclic graph towards one and links, a Complex Track is shaped as a directed acyclic graph towards one
or more destination(s) to support multi-path forwarding and route around or more destination(s) to support multipath forwarding and route around
failures. failures.
</t> </t>
<t> <t indent="0" pn="section-4.5.3-2">
A Complex Track may branch off over non congruent branches for the purpose A Complex Track may branch off over noncongruent branches for the purpose
of multicasting, and/or redundancy, in which case it reconverges later down of multicasting and/or redundancy, in which case, it reconverges later down
the path. the path.
This enables the Packet Replication, Elimination and Ordering Functions (PRE This enables the Packet Replication, Elimination, and Ordering Functions (PR
OF) EOF)
defined by Detnet. Packet ARQ, Replication, Elimination and Overhearing (PAR defined by DetNet. Packet ARQ, Replication, Elimination, and Overhearing (PA
EO) REO)
adds radio-specific capabilities of Layer-2 ARQ and promiscuous listening to adds radio-specific capabilities of Layer 2 ARQ and promiscuous listening to
redundant transmissions to compensate for the lossiness of the medium and me et redundant transmissions to compensate for the lossiness of the medium and me et
industrial expectations of a Reliable and Available Wireless network. industrial expectations of a RAW network.
Combining PAREO and PREOF, a Track may extend beyond the 6TiSCH network in a Combining PAREO and PREOF, a Track may extend beyond the 6TiSCH network into
larger DetNet network. a larger DetNet network.
</t> </t>
<t> <t indent="0" pn="section-4.5.3-3">
In the art of TSCH, a path does not necessarily support PRE but it is almost In the art of TSCH, a path does not necessarily support PRE, but it is almos
systematically multi-path. This means that a Track is scheduled so as to t
systematically multipath. This means that a Track is scheduled so as to
ensure that each hop has at least two forwarding solutions, and the ensure that each hop has at least two forwarding solutions, and the
forwarding decision is to try the preferred one and use the other in forwarding decision is to try the preferred one and use the other in
case of Layer-2 transmission failure as detected by ARQ. Similarly, case of Layer 2 transmission failure as detected by ARQ. Similarly,
at each 6TiSCH hop along the Track, the PCE may schedule more than one at each 6TiSCH hop along the Track, the PCE may schedule more than one
timeslot for a packet, so as to support Layer-2 retries (ARQ). It is also timeslot for a packet, so as to support Layer 2 retries (ARQ). It is also
possible that the field device only uses the second branch if sending over possible that the field device only uses the second branch if sending over
the first branch fails. the first branch fails.
</t> </t>
</section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4
.5.4">
<section><name>DetNet End-to-end Path</name> <name slugifiedName="name-detnet-end-to-end-path">DetNet End-to-End Pa
th</name>
<t> <t indent="0" pn="section-4.5.4-1">
Ultimately, DetNet should Ultimately, DetNet should
enable to extend a Track beyond the 6TiSCH LLN as illustrated in enable extending a Track beyond the 6TiSCH LLN as illustrated in
<xref target='elifig'/>. In that example, a Track that is laid out from a <xref target="elifig" format="default" sectionFormat="of" derivedContent="Fi
gure 10"/>. In that example, a Track is laid out from a
field device in a 6TiSCH network to an IoT gateway that is located on an field device in a 6TiSCH network to an IoT gateway that is located on an
802.1 Time-Sensitive Networking (TSN) backbone. 802.1 Time-Sensitive Networking (TSN) backbone.
A 6TiSCH-Aware DetNet Service Layer handles the Packet Replication, A 6TiSCH-aware DetNet service layer handles the Packet Replication,
Elimination, and Ordering Functions over the DODAG that forms a Track. Elimination, and Ordering Functions over the DODAG that forms a Track.
</t> </t>
<t> <t indent="0" pn="section-4.5.4-2">
The Replication function in the 6TiSCH Node sends a copy of each packet over The Replication function in the 6TiSCH Node sends a copy of each packet over
two different branches, and the PCE schedules each hop of both branches so two different branches, and the PCE schedules each hop of both branches so
that the two copies arrive in due time at the gateway. In case of a loss on that the two copies arrive in due time at the gateway. In case of a loss on
one branch, hopefully the other copy of the packet still makes it in due one branch, hopefully the other copy of the packet still makes it in due
time. If two copies make it to the IoT gateway, the Elimination function time. If two copies make it to the IoT gateway, the Elimination function
in the gateway ignores the extra packet and presents only one copy to upper in the gateway ignores the extra packet and presents only one copy to upper
layers. layers.
</t> </t>
<figure align="center" anchor="elifig" suppress-title="false" pn="figu
<figure align='center' anchor='elifig'><name>Example End-to-End DetNet re-10">
Track</name> <name slugifiedName="name-example-end-to-end-detnet-t">Example End-t
<artwork><![CDATA[ o-End DetNet Track</name>
<artwork align="left" pn="section-4.5.4-3.1">
+-=-=-+ +-=-=-+
| IoT | | IoT |
| G/W | | G/W |
+-=-=-+ +-=-=-+
^ <=== Elimination ^ &lt;=== Elimination
Track branch | | Track branch | |
+-=-=-=-+ +-=-=-=-=+ Subnet Backbone +-=-=-=-+ +-=-=-=-=+ Subnet backbone
| | | |
+-=|-=+ +-=|-=+ +-=|-=+ +-=|-=+
| | | Backbone | | | Backbone | | | Backbone | | | Backbone
o | | | router | | | router o | | | Router | | | Router
+-=/-=+ +-=|-=+ +-=/-=+ +-=|-=+
o / o o-=-o-=-=/ o o / o o-=-o-=-=/ o
o o-=-o-=/ o o o o o o o-=-o-=/ o o o o o
o \ / o o LLN o o \ / o o LLN o
o v <=== Replication o v &lt;=== Replication
o o
]]></artwork> </artwork>
</figure> </figure>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-4
<section><name>Cell Reuse</name> .5.5">
<name slugifiedName="name-cell-reuse">Cell Reuse</name>
<t> <t indent="0" pn="section-4.5.5-1">
The 6TiSCH architecture provides means to avoid waste of cells as The 6TiSCH architecture provides the means to avoid waste of cells as
well as overflows in the transmit bundle of a Track, as follows: well as overflows in the transmit bundle of a Track, as follows:
</t> </t>
<t> <t indent="0" pn="section-4.5.5-2">
A TX-cell that is not needed for the current iteration may A TX-cell that is not needed for the current iteration may
be reused opportunistically on a per-hop basis for routed packets. be reused opportunistically on a per-hop basis for routed packets.
When all of the frame that were received for a given Track are When all of the frames that were received for a given Track are
effectively transmitted, any available TX-cell for that Track can be effectively transmitted, any available TX-cell for that Track can be
reused for upper layer traffic for which the next-hop router matches the reused for upper-layer traffic for which the next-hop router matches the
next hop along the Track. next hop along the Track.
In that case, the cell that is being used is effectively a TX-cell from In that case, the cell that is being used is effectively a TX-cell from
the Track, but the short address for the destination is that of the the Track, but the short address for the destination is that of the
next-hop router. next-hop router.
</t> </t>
<t> <t indent="0" pn="section-4.5.5-3">
It results in a frame that is received in a RX-cell of a Track with a It results in a frame that is received in an RX-cell of a Track with a
destination MAC address set to this node as opposed to the broadcast MAC destination MAC address set to this node, as opposed to the broadcast MA
address must be extracted from the Track and delivered to the upper laye C
r. address that must be extracted from the Track and delivered to the upper
layer.
Note that a frame with an unrecognized destination MAC address is droppe d Note that a frame with an unrecognized destination MAC address is droppe d
at the lower MAC layer and thus is not received at the 6top sublayer. at the lower MAC layer and thus is not received at the 6top sublayer.
</t> </t>
<t> <t indent="0" pn="section-4.5.5-4">
On the other hand, it might happen that there are not enough TX-cells On the other hand, it might happen that there are not enough TX-cells
in the transmit bundle to accommodate the Track traffic, for instance if in the transmit bundle to accommodate the Track traffic, for instance, i f
more retransmissions are needed than provisioned. more retransmissions are needed than provisioned.
In that case, and if the frame transports an IPv6 packet, then it can be In that case, and if the frame transports an IPv6 packet, then it can be
placed for transmission in the bundle that is used for Layer-3 traffic placed for transmission in the bundle that is used for Layer 3 traffic
towards the next hop along the Track. towards the next hop along the Track.
The MAC address should be set to the next-hop MAC address to avoid The MAC address should be set to the next-hop MAC address to avoid
confusion. confusion.
</t> </t>
<t> <t indent="0" pn="section-4.5.5-5">
It results in a frame that is received over a Layer-3 bundle may be in It results in a frame that is received over a Layer 3 bundle that may be
fact associated to a Track. In a classical IP link such as an Ethernet, in
fact associated with a Track. In a classical IP link such as an Ethernet
,
off-Track traffic is typically in excess over reservation to be routed off-Track traffic is typically in excess over reservation to be routed
along the non-reserved path based on its QoS setting. along the non-reserved path based on its QoS setting.
But with 6TiSCH, since the use of the Layer-3 bundle may be due to But with 6TiSCH, since the use of the Layer 3 bundle may be due to
transmission failures, it makes sense for the receiver to recognize a transmission failures, it makes sense for the receiver to recognize a
frame that should be re-Tracked, and to place it back on the appropriate frame that should be re-Tracked and to place it back on the appropriate
bundle if possible. bundle if possible.
<!--
A frame should be re-Tracked if the Per-Hop-Behavior group indicated in
the Differentiated Services Field of the IPv6 header is set to
Deterministic Forwarding, as discussed in <xref target="pmh"/ -->.
A frame is re-Tracked by scheduling it for transmission over the A frame is re-Tracked by scheduling it for transmission over the
transmit bundle associated to the Track, with the destination MAC transmit bundle associated with the Track, with the destination MAC
address set to broadcast. address set to broadcast.
</t> </t>
</section>
</section> </section>
</section> <section anchor="fwd" numbered="true" removeInRFC="false" toc="include" pn
="section-4.6">
<section anchor='fwd'><name>Forwarding Models</name> <name slugifiedName="name-forwarding-models">Forwarding Models</name>
<!-- TW: Forwarding models should be formalized in a standards-Track draft <t indent="0" pn="section-4.6-1">
? One should be MUST (IPv6?), the others SHOULD? -->
<t>
By forwarding, this document means the per-packet operation that By forwarding, this document means the per-packet operation that
allows to deliver a packet to a next hop or an upper layer in this node allows delivery of a packet to a next hop or an upper layer in this nod
. e.
Forwarding is based on pre-existing state that was installed as a Forwarding is based on preexisting state that was installed as a
result of a routing computation <xref target='rtg'/>. result of a routing computation, see <xref target="rtg" format="default
6TiSCH supports three different forwarding model:(G-MPLS) Track " sectionFormat="of" derivedContent="Section 4.7"/>.
Forwarding, (classical) IPv6 Forwarding and (6LoWPAN) Fragment Forwardi 6TiSCH supports three different forwarding models: (GMPLS) Track
ng. Forwarding, (classical) IPv6 Forwarding, and (6LoWPAN) Fragment Forward
</t> ing.
</t>
<section anchor='trkfwd'><name>Track Forwarding</name> <section anchor="trkfwd" numbered="true" removeInRFC="false" toc="includ
e" pn="section-4.6.1">
<t> <name slugifiedName="name-track-forwarding">Track Forwarding</name>
Forwarding along a Track can be seen as a Generalized Multi-protocol <t indent="0" pn="section-4.6.1-1">
Label Switching (G-MPLS) operation in that the information used to Forwarding along a Track can be seen as a Generalized Multiprotocol
switch a frame is not an explicit label, but rather related to other Label Switching (GMPLS) operation in that the information used to
switch a frame is not an explicit label but is rather related to oth
er
properties of the way the packet was received, a particular cell in properties of the way the packet was received, a particular cell in
the case of 6TiSCH. the case of 6TiSCH.
As a result, as long as the TSCH MAC (and Layer-2 security) accepts As a result, as long as the TSCH MAC (and Layer 2 security) accepts
a frame, that frame can be switched regardless of the protocol, a frame, that frame can be switched regardless of the protocol,
whether this is an IPv6 packet, a 6LoWPAN fragment, or a frame from whether this is an IPv6 packet, a 6LoWPAN fragment, or a frame from
an alternate protocol such as WirelessHART or ISA100.11a. an alternate protocol such as WirelessHART or ISA100.11a.
</t> </t>
<t> <t indent="0" pn="section-4.6.1-2">
A data frame that is forwarded along a Track normally has a A data frame that is forwarded along a Track normally has a
destination MAC address that is set to broadcast - or a multicast destination MAC address that is set to broadcast or a multicast
address depending on MAC support. address depending on MAC support.
This way, the MAC layer in the intermediate nodes accepts the This way, the MAC layer in the intermediate nodes accepts the
incoming frame and 6top switches it without incurring a change in incoming frame and 6top switches it without incurring a change in
the MAC header. the MAC header.
In the case of IEEE Std. 802.15.4, this means effectively In the case of IEEE Std 802.15.4, this means effectively to
broadcast, so that along the Track the short address for the broadcast, so that along the Track the short address for the
destination of the frame is set to 0xFFFF. destination of the frame is set to 0xFFFF.
</t> </t>
<t> <t indent="0" pn="section-4.6.1-3">
There are 2 modes for a Track, an IPv6 native mode and There are two modes for a Track: an IPv6 native mode and a
a protocol-independant tunnel mode. protocol-independent tunnel mode.
</t> </t>
<section><name>Native Mode</name> <section numbered="true" removeInRFC="false" toc="exclude" pn="section
<t> -4.6.1.1">
<name slugifiedName="name-native-mode">Native Mode</name>
<t indent="0" pn="section-4.6.1.1-1">
In native mode, the Protocol Data Unit (PDU) is associated In native mode, the Protocol Data Unit (PDU) is associated
with flow-dependent meta-data that refers uniquely to the Track, with flow-dependent metadata that refers uniquely to the Track,
so the 6top sublayer can place the frame in the appropriate cell so the 6top sublayer can place the frame in the appropriate cell
without ambiguity. In the case of IPv6 traffic, this flow without ambiguity. In the case of IPv6 traffic, this flow
identification may be done using a 6-tuple as discussed in may be identified using a 6-tuple as discussed in
<xref target='I-D.ietf-detnet-ip'/>. In particular, <xref target="RFC8939" format="default" sectionFormat="of" derive
dContent="RFC8939"/>. In particular,
implementations of this document should support identification of implementations of this document should support identification of
DetNet flows based on the IPv6 Flow Label field. DetNet flows based on the IPv6 Flow Label field.</t>
<t indent="0" pn="section-4.6.1.1-2">
</t> The flow follows a Track that is identified using a RPL
<t> Instance (see <xref target="RFC6550" section="3.1.3" sectionFormat="of" forma
The flow follows a Track which identification is done using t="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1.3" deriv
a RPL Instance (see section 3.1.3 of <xref target='RFC6550'/>), edContent="RFC6550"/>),
signaled in a RPL Packet Information (more in section 11.2.2.1 of signaled in a RPL Packet Information (more in
<xref target='RFC6550'/>) and the destination address in the case <xref target="RFC6550" section="11.2.2.1" sectionFormat="of" format="default"
of a local instance. One or more flows may be placed in a same derivedLink="https://rfc-editor.org/rfc/rfc6550#section-11.2.2.1" derivedConten
Track and the Track identification (TrackID + owner) may be place t="RFC6550"/>)
d and the source address of a packet going down the DODAG formed by a local ins
in an tance. One or more
IP-in-IP encapsulation. The forwarding operation is based on the flows may be placed in a same Track and the Track identification
Track and does not depend on the flow therein. (TrackID plus owner) may be placed in an IP-in-IP encapsulation. The forward
ing
</t> operation is based on the Track and does not depend on the flow
<t> therein.
The Track identification is validated at egress before restoring </t>
the destination MAC address (DMAC) and punting to the upper layer <t indent="0" pn="section-4.6.1.1-3">
. The Track identification is validated at egress before restoring the
</t> destination MAC address (DMAC) and punting to the upper layer.
<t><xref target='fig6t'/> illustrates the Track Forwarding operation </t>
which happens at the 6top sublayer, below IP. <t indent="0" pn="section-4.6.1.1-4"><xref target="fig6t" format="de
fault" sectionFormat="of" derivedContent="Figure 11"/> illustrates the Track For
warding operation
that happens at the 6top sublayer, below IP.
</t> </t>
<figure anchor='fig6t'><name>Track Forwarding, Native Mode</name> <figure anchor="fig6t" align="left" suppress-title="false" pn="figur
<artwork><![CDATA[ e-11">
<name slugifiedName="name-track-forwarding-native-mod">Track Forwa
rding, Native Mode</name>
<artwork align="left" pn="section-4.6.1.1-5.1">
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | | | IPv6 | | |
+--------------+ | | +--------------+ | |
| 6LoWPAN HC | | | | 6LoWPAN HC | | |
+--------------+ ingress egress +--------------+ ingress egress
| 6top | sets +----+ +----+ restores | 6top | sets +----+ +----+ restores
+--------------+ DMAC to | | | | DMAC to +--------------+ DMAC to | | | | DMAC to
| TSCH MAC | brdcst | | | | dest | TSCH MAC | brdcst | | | | dest
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Ingress Relay Relay Egress Ingress Relay Relay Egress
Stack Layer Node Node Node Node Stack Layer Node Node Node Node
</artwork>
]]></artwork> </figure>
</figure> </section>
</section> <section numbered="true" removeInRFC="false" toc="exclude" pn="section
<section><name>Tunnel Mode</name> -4.6.1.2">
<t> <name slugifiedName="name-tunnel-mode">Tunnel Mode</name>
<t indent="0" pn="section-4.6.1.2-1">
In tunnel mode, the frames originate from an arbitrary protocol o ver a compatible MAC In tunnel mode, the frames originate from an arbitrary protocol o ver a compatible MAC
that may or may not be synchronized with the 6TiSCH network. An e xample of that may or may not be synchronized with the 6TiSCH network. An e xample of
this would be a router with a dual radio that is capable of recei ving and sending WirelessHART this would be a router with a dual radio that is capable of recei ving and sending WirelessHART
or ISA100.11a frames with the second radio, by presenting itself or ISA100.11a frames with the second radio by presenting itself a
as an access s an access
Point or a Backbone Router, respectively. point or a Backbone Router, respectively.
In that mode, some entity (e.g., PCE) can coordinate with a In that mode, some entity (e.g., PCE) can coordinate with a
WirelessHART Network Manager or an ISA100.11a System Manager to WirelessHART Network Manager or an ISA100.11a System Manager to
specify the flows that are transported. specify the flows that are transported.
</t> </t>
<figure anchor='fig6'><name>Track Forwarding, Tunnel Mode</name> <figure anchor="fig6" align="left" suppress-title="false" pn="figure
<artwork><![CDATA[ -12">
<name slugifiedName="name-track-forwarding-tunnel-mod">Track Forwa
rding, Tunnel Mode</name>
<artwork align="left" pn="section-4.6.1.2-2.1">
+--------------+ +--------------+
| IPv6 | | IPv6 |
+--------------+ +--------------+
| 6LoWPAN HC | | 6LoWPAN HC |
+--------------+ set restore +--------------+ set restore
| 6top | +DMAC+ +DMAC+ | 6top | +DMAC+ +DMAC+
+--------------+ to|brdcst to|nexthop +--------------+ to|brdcst to|nexthop
| TSCH MAC | | | | | | TSCH MAC | | | | |
+--------------+ | | | | +--------------+ | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
skipping to change at line 2627 skipping to change at line 2610
| | | |
+--------------+ | | +--------------+ | |
| LLN PHY | | | | LLN PHY | | |
+--------------+ | Packet flowing across the network | +--------------+ | Packet flowing across the network |
| TSCH MAC | | | | TSCH MAC | | |
+--------------+ | DMAC = | DMAC = +--------------+ | DMAC = | DMAC =
|ISA100/WiHART | | nexthop v nexthop |ISA100/WiHART | | nexthop v nexthop
+--------------+ +--------------+
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Node Node Node Stack Layer Node Node Node Node
</artwork>
]]></artwork> </figure>
</figure> <t indent="0" pn="section-4.6.1.2-3">
<t>
In that case, the TrackID that identifies the Track at In that case, the TrackID that identifies the Track at
the ingress 6TiSCH router is derived from the RX-cell. The DMAC the ingress 6TiSCH router is derived from the RX-cell.
is set to this node but the TrackID indicates that the The DMAC
frame must be tunneled over a particular Track so the frame is is set to this node, but the TrackID indicates that the
frame must be tunneled over a particular Track, so the frame is
not passed to the upper layer. Instead, the DMAC is forced to not passed to the upper layer. Instead, the DMAC is forced to
broadcast and the frame is passed to the 6top sublayer for broadcast, and the frame is passed to the 6top sublayer for
switching. switching.
</t> </t>
<t> <t indent="0" pn="section-4.6.1.2-4">
At the egress 6TiSCH router, the reverse operation occurs. Based At the egress 6TiSCH router, the reverse operation occurs. Based
on tunneling information of the Track, which may for instance on tunneling information of the Track, which may for instance
indicate that the tunneled datagram is an IP packet, indicate that the tunneled datagram is an IP packet,
the datagram is passed to the appropriate Link-Layer with the the datagram is passed to the appropriate link-layer with the
destination MAC restored. destination MAC restored.
</t> </t>
</section> </section>
<section><name>Tunneling Information</name> <section numbered="true" removeInRFC="false" toc="exclude" pn="section
<t> -4.6.1.3">
<name slugifiedName="name-tunneling-information">Tunneling Informati
on</name>
<t indent="0" pn="section-4.6.1.3-1">
Tunneling information coming with the Track configuration Tunneling information coming with the Track configuration
provides the destination MAC address provides the destination MAC address
of the egress endpoint as well as the tunnel mode and specific of the egress endpoint as well as the tunnel mode and specific
data depending on the mode, data depending on the mode,
for instance a service access point for frame delivery at egress. for instance, a service access point for frame delivery at egress .
</t> </t>
<t> <t indent="0" pn="section-4.6.1.3-2">
If the tunnel egress point does not have a MAC address that If the tunnel egress point does not have a MAC address that
matches the configuration, the Track installation fails. matches the configuration, the Track installation fails.
</t> </t>
<t> <t indent="0" pn="section-4.6.1.3-3">
If the Layer-3 destination address belongs to If the Layer 3 destination address belongs to
the tunnel termination, then it is possible that the IPv6 address the tunnel termination, then it is possible that the IPv6 address
of the destination is compressed at the 6LoWPAN sublayer based on of the destination is compressed at the 6LoWPAN sublayer based on
the MAC address. Restoring the wrong MAC address at the egress the MAC address. Restoring the wrong MAC address at the egress
would then also result in the wrong IP address in the packet would then also result in the wrong IP address in the packet
after decompression. after decompression.
For that reason, a packet can be injected in a Track only if For that reason, a packet can be injected in a Track only if
the destination MAC address is effectively that of the tunnel the destination MAC address is effectively that of the tunnel
egress point. egress point.
It is thus mandatory for the ingress router to validate that the It is thus mandatory for the ingress router to validate that the
MAC address that was used at the 6LoWPAN MAC address used at the 6LoWPAN
sublayer for compression matches that of the tunnel egress point sublayer for compression matches that of the tunnel egress point
before it overwrites it to broadcast. before it overwrites it to broadcast.
The 6top sublayer at the tunnel egress point reverts that The 6top sublayer at the tunnel egress point reverts that
operation to the MAC address obtained from the tunnel operation to the MAC address obtained from the tunnel
information. information.
</t> </t>
</section> </section>
</section> <section><name>IPv6 Forwarding</name> </section>
<t> <section numbered="true" removeInRFC="false" toc="include" pn="section-4
As the packets are routed at Layer-3, traditional QoS and Active .6.2">
<name slugifiedName="name-ipv6-forwarding">IPv6 Forwarding</name>
<t indent="0" pn="section-4.6.2-1">
As the packets are routed at Layer 3, traditional QoS and Active
Queue Management (AQM) operations are expected to prioritize flows. Queue Management (AQM) operations are expected to prioritize flows.
</t>
<!-- the application of Differentiated Services is further discussed <figure anchor="fig9" align="left" suppress-title="false" pn="figure-1
in --> 3">
<!-- <xref target="I-D.svshah-tsvwg-lln-diffserv-recommendations"/>. <name slugifiedName="name-ip-forwarding">IP Forwarding</name>
--> <artwork align="left" pn="section-4.6.2-2.1">
</t>
<figure anchor='fig9'><name>IP Forwarding</name>
<artwork><![CDATA[
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | +-QoS+ +-QoS+ | | IPv6 | | +-QoS+ +-QoS+ |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6LoWPAN HC | | | | | | | | 6LoWPAN HC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Router Router Node Stack Layer Node Router Router Node
</artwork>
]]></artwork> </figure>
</figure> </section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4
<section><name>Fragment Forwarding</name> .6.3">
<t> <name slugifiedName="name-fragment-forwarding">Fragment Forwarding</na
Considering that per section 4 of <xref target='RFC4944'/> 6LoWPAN me>
packets can be as large as 1280 bytes (the IPv6 minimum MTU), <t indent="0" pn="section-4.6.3-1">
and that the non-storing mode of RPL implies Source Routing that req Considering that, per <xref target="RFC4944" section="4" sectionForm
uires space for routing at="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4944#section
headers, and that a IEEE Std. 802.15.4 frame with security may carry -4" derivedContent="RFC4944"/>, 6LoWPAN
in the order of 80 bytes of packets can be as large as 1280 bytes (the IPv6 minimum MTU)
and that the non-storing mode of RPL implies source routing, which r
equires space for routing
headers, and that an IEEE Std 802.15.4 frame with security may carry
in the order of 80 bytes of
effective payload, an IPv6 packet might be fragmented into more than 16 fragments at the effective payload, an IPv6 packet might be fragmented into more than 16 fragments at the
6LoWPAN sublayer. 6LoWPAN sublayer.
</t> </t>
<t> <t indent="0" pn="section-4.6.3-2">
This level of fragmentation is much higher than that traditionally e xperienced over the Internet This level of fragmentation is much higher than that traditionally e xperienced over the Internet
with IPv4 fragments, where fragmentation is already known as harmful . with IPv4 fragments, where fragmentation is already known as harmful .
</t> </t>
<t> <t indent="0" pn="section-4.6.3-3">
In the case to a multihop route within a 6TiSCH network, Hop-by-Hop In the case of a multihop route within a 6TiSCH network, hop-by-hop
recomposition occurs at each recomposition occurs at each
hop to reform the packet and route it. This creates additional laten cy and forces intermediate hop to reform the packet and route it. This creates additional laten cy and forces intermediate
nodes to store a portion of a packet for an undetermined time, thus impacting critical resources such nodes to store a portion of a packet for an undetermined time, thus impacting critical resources such
as memory and battery. as memory and battery.
</t> </t>
<t> <t indent="0" pn="section-4.6.3-4">
<xref target='I-D.ietf-6lo-minimal-fragment'/> describes a framework <xref target="RFC8930" format="default" sectionFormat="of" derivedCo
for forwarding fragments end-to-end across a 6TiSCH route-over mesh. ntent="RFC8930"/> describes a framework for forwarding fragments end-to-end
Within that framework, <xref target='I-D.ietf-lwig-6lowpan-virtual-r across a 6TiSCH route-over mesh. Within that framework,
eassembly'/> details a virtual reassembly buffer mechanism whereby the datagram <xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly" format="defa
tag in the 6LoWPAN Fragment is used as a label for switching at the 6LoWPAN subl ult" sectionFormat="of" derivedContent="VIRTUAL-REASSEMBLY"/> details a virtual
ayer. reassembly
</t> buffer mechanism whereby the datagram tag in the 6LoWPAN fragment is
<t> used as a label
Building on this technique, <xref target='I-D.ietf-6lo-fragment-reco for switching at the 6LoWPAN sublayer.
very'/> introduces a new format for 6LoWPAN fragments that enables the selective </t>
recovery of individual fragments, and allows for a degree of flow control based <t indent="0" pn="section-4.6.3-5">
on an Explicit Congestion Notification. Building on this technique, <xref target="RFC8931" format="default"
</t> sectionFormat="of" derivedContent="RFC8931"/> introduces a new format for
<figure anchor='fig7'><name>Forwarding First Fragment</name> 6LoWPAN fragments that enables the selective recovery of individual
<artwork><![CDATA[ fragments
and allows for a degree of flow control based on an Explicit Congest
ion Notification (ECN).
</t>
<figure anchor="fig7" align="left" suppress-title="false" pn="figure-1
4">
<name slugifiedName="name-forwarding-first-fragment">Forwarding Firs
t Fragment</name>
<artwork align="left" pn="section-4.6.3-6.1">
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | +----+ +----+ | | IPv6 | | +----+ +----+ |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6LoWPAN HC | | learn learn | | 6LoWPAN HC | | learn learn |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Router Router Node Stack Layer Node Router Router Node
</artwork>
]]></artwork> </figure>
</figure> <t indent="0" pn="section-4.6.3-7">
<t>
In that model, the first fragment is routed based on the IPv6 header that is present in that fragment. In that model, the first fragment is routed based on the IPv6 header that is present in that fragment.
The 6LoWPAN sublayer learns the next hop selection, generates a new datagram tag for transmission to The 6LoWPAN sublayer learns the next-hop selection, generates a new datagram tag for transmission to
the next hop, and stores that information indexed by the incoming MA C address and datagram tag. The next the next hop, and stores that information indexed by the incoming MA C address and datagram tag. The next
fragments are then switched based on that stored state. fragments are then switched based on that stored state.
</t> </t>
<figure anchor='fig8'><name>Forwarding Next Fragment</name> <figure anchor="fig8" align="left" suppress-title="false" pn="figure-1
<artwork><![CDATA[ 5">
<name slugifiedName="name-forwarding-next-fragment">Forwarding Next
Fragment</name>
<artwork align="left" pn="section-4.6.3-8.1">
| Packet flowing across the network ^ | Packet flowing across the network ^
+--------------+ | | +--------------+ | |
| IPv6 | | | | IPv6 | | |
+--------------+ | | +--------------+ | |
| 6LoWPAN HC | | replay replay | | 6LoWPAN HC | | replay replay |
+--------------+ | | | | | | +--------------+ | | | | | |
| 6top | | | | | | | | 6top | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| TSCH MAC | | | | | | | | TSCH MAC | | | | | | |
+--------------+ | | | | | | +--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+ | LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ +--------------+
Source Ingress Egress Destination Source Ingress Egress Destination
Stack Layer Node Router Router Node Stack Layer Node Router Router Node
</artwork>
]]></artwork> </figure>
</figure> <t indent="0" pn="section-4.6.3-9">
<t>
A bitmap and an ECN echo in the end-to-end acknowledgment enable the source to resend the missing A bitmap and an ECN echo in the end-to-end acknowledgment enable the source to resend the missing
fragments selectively. The first fragment may be resent to carve a n ew path in case of a path failure. fragments selectively. The first fragment may be resent to carve a n ew path in case of a path failure.
The ECN echo set indicates that the number of outstanding fragments should be reduced. The ECN echo set indicates that the number of outstanding fragments should be reduced.
</t> </t>
</section>
</section> </section>
<section anchor="rtg" numbered="true" removeInRFC="false" toc="include" pn
</section> ="section-4.7">
<name slugifiedName="name-advanced-6tisch-routing">Advanced 6TiSCH Routi
<section anchor='rtg'><name>Advanced 6TiSCH Routing</name> ng</name>
<section anchor='pmh'><name>Packet Marking and Handling</name> <section anchor="pmh" numbered="true" removeInRFC="false" toc="include"
<t> pn="section-4.7.1">
<name slugifiedName="name-packet-marking-and-handling">Packet Marking
and Handling</name>
<t indent="0" pn="section-4.7.1-1">
All packets inside a 6TiSCH domain must carry the RPLInstanceID that All packets inside a 6TiSCH domain must carry the RPLInstanceID that
identifies the 6TiSCH topology (e.g., a Track) that is to be used for identifies the 6TiSCH topology (e.g., a Track) that is to be used for
routing and forwarding that packet. The location of that information routing and forwarding that packet. The location of that information
must be the same for all packets forwarded inside the domain. must be the same for all packets forwarded inside the domain.
</t> </t>
<t> <t indent="0" pn="section-4.7.1-2">
For packets that are routed by a PCE along a Track, the tuple formed by 1) For packets that are routed by a PCE along a Track, the tuple formed
(typically) the IPv6 source or (possibly) destination address in the IPv6 by 1) (typically) the IPv6 source or (possibly) destination address
Header and 2) a local RPLInstanceID in the RPI that serves as TrackID, in the IPv6 header and 2) a local RPLInstanceID in the RPI that
identify uniquely the Track and associated transmit bundle. serves as TrackID, identify uniquely the Track and
</t> associated transmit bundle.
<t> </t>
<t indent="0" pn="section-4.7.1-3">
For packets that are routed by RPL, that information is the RPLInstanceID For packets that are routed by RPL, that information is the RPLInstanceID
which is carried in the RPL Packet Information (RPI), as discussed in that is carried in the RPL Packet Information (RPI), as discussed in
section 11.2 of <xref target='RFC6550'/>, "Loop Avoidance and Detection". <xref target="RFC6550" section="11.2" sectionFormat="of" format="default" der
The RPI is transported by a RPL option in the IPv6 Hop-By-Hop Header ivedLink="https://rfc-editor.org/rfc/rfc6550#section-11.2" derivedContent="RFC65
<xref target='RFC6553'/>. 50"/>, "Loop Avoidance and Detection".
</t> The RPI is transported by a RPL Option in the IPv6 Hop-By-Hop Options header
<t> <xref target="RFC6553" format="default" sectionFormat="of" derivedContent="RF
C6553"/>.
</t>
<t indent="0" pn="section-4.7.1-4">
A compression mechanism for the RPL packet artifacts that integrates the A compression mechanism for the RPL packet artifacts that integrates the
compression of IP-in-IP encapsulation and the Routing Header type 3 compression of IP-in-IP encapsulation and the Routing Header type 3
<xref target='RFC6554'/> <xref target="RFC6554" format="default" sectionFormat="of" derivedContent="RF C6554"/>
with that of the RPI in a 6LoWPAN dispatch/header type is specified in with that of the RPI in a 6LoWPAN dispatch/header type is specified in
<xref target='RFC8025'/> and <xref target='RFC8138'/>. <xref target="RFC8025" format="default" sectionFormat="of" derivedContent="RF
</t> C8025"/> and <xref target="RFC8138" format="default" sectionFormat="of" derivedC
<t> ontent="RFC8138"/>.
<!--In a 6TiSCH network, the routing dispatch is the recommended encoding the </t>
RPL Packet Information.--> <t indent="0" pn="section-4.7.1-5">
</t>
<t>
Either way, the method and format used for encoding the RPLInstanceID Either way, the method and format used for encoding the RPLInstanceID
is generalized to all 6TiSCH topological Instances, which include is generalized to all 6TiSCH topological Instances, which include
both RPL Instances and Tracks. both RPL Instances and Tracks.
</t> </t>
</section>
</section> <section anchor="pmhrre" numbered="true" removeInRFC="false" toc="includ
<section anchor='pmhrre'><name>Replication, Retries and Elimination</name> e" pn="section-4.7.2">
<name slugifiedName="name-replication-retries-and-eli">Replication, Re
<t> tries, and Elimination</name>
<t indent="0" pn="section-4.7.2-1">
6TiSCH supports the PREOF operations of elimination and reordering of packets 6TiSCH supports the PREOF operations of elimination and reordering of packets
along a complex Track, but has no requirement about whether a sequence number along a complex Track, but has no requirement about tagging a sequence number
is tagged in the packet for that purpose. in the packet for that purpose.
With 6TiSCH, the schedule can tell when multiple receive timeslots correspond With 6TiSCH, the schedule can tell when multiple receive timeslots correspond
to copies of a same packet, in which case the receiver may avoid listening to to copies of a same packet, in which case the receiver may avoid listening to
the extra copies once it had received one instance of the packet. the extra copies once it has received one instance of the packet.
</t> </t>
<t> <t indent="0" pn="section-4.7.2-2">
The semantics of the configuration will enable correlated timeslots to be The semantics of the configuration enable correlated timeslots to be
grouped for transmit (and respectively receive) with a 'OR' relations, grouped for transmit (and receive, respectively) with 'OR' relations,
and then a 'AND' relation would be configurable between groups. and then an 'AND' relation can be configurable between groups.
The semantics is that if the transmit (and respectively receive) operation The semantics are such that if the transmit (and receive, respectively) opera
succeeded in one timeslot in a 'OR' group, then all the other timeslots in tion
succeeded in one timeslot in an 'OR' group, then all the other timeslots in
the group are ignored. the group are ignored.
Now, if there are at least two groups, the 'AND' relation between the groups Now, if there are at least two groups, the 'AND' relation between the groups
indicates that one operation must succeed in each of the groups. indicates that one operation must succeed in each of the groups.
</t> </t>
<t> <t indent="0" pn="section-4.7.2-3">
On the transmit side, timeslots provisioned for retries along a same branch On the transmit side, timeslots provisioned for retries along a same branch
of a Track are placed a same 'OR' group. The 'OR' relation indicates that if of a Track are placed in the same 'OR' group. The 'OR' relation indicates tha t if
a transmission is acknowledged, then retransmissions of that packet should a transmission is acknowledged, then retransmissions of that packet should
not be attempted for remaining timeslots in that group. There are as many not be attempted for the remaining timeslots in that group. There are as many
'OR' groups as there are branches of the Track departing from this node. 'OR' groups as there are branches of the Track departing from this node.
Different 'OR' groups are programmed for the purpose of replication, each Different 'OR' groups are programmed for the purpose of replication, each
group corresponding to one branch of the Track. The 'AND' relation between th e group corresponding to one branch of the Track. The 'AND' relation between th e
groups indicates that transmission over any of branches must be attempted groups indicates that transmission over any of branches must be attempted
regardless of whether a transmission succeeded in another branch. It is also regardless of whether a transmission succeeded in another branch. It is also
possible to place cells to different next-hop routers in a same 'OR' group. possible to place cells to different next-hop routers in the same 'OR' group.
This allows to route along multi-path Tracks, trying one next-hop and then This allows routing along multipath Tracks, trying one next hop and then
another only if sending to the first fails. another only if sending to the first fails.
</t> </t>
<t> <t indent="0" pn="section-4.7.2-4">
On the receive side, all timeslots are programmed in a same 'OR' group. On the receive side, all timeslots are programmed in the same 'OR' group.
Retries of a same copy as well as converging branches for elimination Retries of the same copy as well as converging branches for elimination
are converged, meaning that the first successful reception is enough and that are converged, meaning that the first successful reception is enough and that
all the other timeslots can be ignored. A 'AND' group denotes different all the other timeslots can be ignored. An 'AND' group denotes different
packets that must all be received and transmitted over the associated packets that must all be received and transmitted over the associated
transmit groups within their respected 'AND' or 'OR' rules. transmit groups within their respected 'AND' or 'OR' rules.
</t> </t>
<t> <t indent="0" pn="section-4.7.2-5">
As an example say that we have a simple network as represented in As an example, say that we have a simple network as represented in
<xref target='figANDORref'/>, and we want to enable PREOF between an ingress <xref target="figANDORref" format="default" sectionFormat="of" derivedContent
="Figure 16"/>, and we want to enable PREOF between an ingress
node I and an egress node E. node I and an egress node E.
</t> </t>
<figure align='center' anchor='figANDORref'><name>Scheduling PREOF on a Simpl <figure align="center" anchor="figANDORref" suppress-title="false" pn=
e Network</name> "figure-16">
<artwork align='center'><![CDATA[ <name slugifiedName="name-scheduling-preof-on-a-simpl">Scheduling PR
EOF on a Simple Network</name>
<artwork align="center" pn="section-4.7.2-6.1">
+-+ +-+ +-+ +-+
-- |A| ------ |C| -- -- |A| ------ |C| --
/ +-+ +-+ \ / +-+ +-+ \
/ \ / \
+-+ +-+ +-+ +-+
|I| |E| |I| |E|
+-+ +-+ +-+ +-+
\ / \ /
\ +-+ +-+ / \ +-+ +-+ /
-- |B| ------- |D| -- -- |B| ------- |D| --
+-+ +-+ +-+ +-+
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-4.7.2-7">
<t>
The assumption for this particular problem is The assumption for this particular problem is
that a 6TiSCH node has a single radio, so it cannot perform 2 receive and/or that a 6TiSCH node has a single radio, so it cannot perform two receive and/o
transmit operations at the same time, even on 2 different channels. r
transmit operations at the same time, even on two different channels.
</t> </t>
<t> <t indent="0" pn="section-4.7.2-8">
Say we have 6 possible channels, and at least 10 timeslots per slotframe. Say we have six possible channels, and at least ten timeslots per slotframe.
<xref target='figsc'/> shows a possible schedule whereby each transmission <xref target="figsc" format="default" sectionFormat="of" derivedContent="Figu
is retried 2 or 3 times, and redundant copies are forwarded in parallel via re 17"/> shows a possible schedule whereby each transmission
is retried two or three times, and redundant copies are forwarded in parallel
via
A and C on the one hand, and B and D on the other, providing time diversity, A and C on the one hand, and B and D on the other, providing time diversity,
spatial diversity though different physical paths, and frequency diversity. spatial diversity though different physical paths, and frequency diversity.
</t> </t>
<figure anchor='figsc'><name>Example Global Schedule</name> <figure anchor="figsc" align="left" suppress-title="false" pn="figure-
<artwork align='center'> 17">
<![CDATA[ <name slugifiedName="name-example-global-schedule">Example Global Sc
hedule</name>
<artwork align="center" pn="section-4.7.2-9.1">
slotOffset 0 1 2 3 4 5 6 7 9 slotOffset 0 1 2 3 4 5 6 7 9
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 0 | | | | | | |B->D| | | ... channelOffset 0 | | | | | | |B-&gt;D| | | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 1 | |I->A| |A->C|B-&gt;D| | | | | ... channelOffset 1 | |I->A| |A-&gt;C|B-&gt;D| | | | | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 2 |I->A| | |I->B| |C->E| |D-&gt;E| | ... channelOffset 2 |I->A| | |I-&gt;B| |C-&gt;E| |D-&gt;E| | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 3 | | | | |A->C| | | | | ... channelOffset 3 | | | | |A-&gt;C| | | | | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 4 | | |I->B| | |B->D| | |D-&gt;E| ... channelOffset 4 | | |I->B| | |B-&gt;D| | |D-&gt;E| ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset 5 | | |A->C| | | |C-&gt;E| | | ... channelOffset 5 | | |A->C| | | |C-&gt;E| | | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
]]>
</artwork> </artwork>
</figure> </figure>
<t> <t indent="0" pn="section-4.7.2-10">
This translates in a different slotframe for every node that provides the This translates into a different slotframe that provides the
waking and sleeping times, and the channelOffset to be used when awake. waking and sleeping times for every node, and the channelOffset to be used wh
<xref target='figsfA'/> shows the corresponding slotframe for node A. en awake.
<xref target="figsfA" format="default" sectionFormat="of" derivedContent="Fig
ure 18"/> shows the corresponding slotframe for node A.
</t> </t>
<figure anchor="figsfA" align="left" suppress-title="false" pn="figure
<figure anchor='figsfA'><name>Example Slotframe for Node A</name> -18">
<artwork align='center'> <name slugifiedName="name-example-slotframe-for-node-">Example Slotf
<![CDATA[ rame for Node A</name>
<artwork align="center" pn="section-4.7.2-11.1">
slotOffset 0 1 2 3 4 5 6 7 9 slotOffset 0 1 2 3 4 5 6 7 9
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ... operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ... channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ...
+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+
]]>
</artwork> </artwork>
</figure> </figure>
<t> <t indent="0" pn="section-4.7.2-12">
<!-- If, say, node A successfully transmits at slotOffset 2 then it may sleep
at
slotOffsets 3 and 4. -->
The logical relationship between the timeslots is given The logical relationship between the timeslots is given
by the following table: by <xref target="figslog" format="default" sectionFormat="of" derivedContent=
</t> "Table 2"/>:
</t>
<figure anchor='figslog' suppress-title='true'> <table anchor="figslog" align="center" pn="table-2">
<artwork align='center'> <thead>
<![CDATA[ <tr>
+------+---------------------+------------------------+ <th align="center" colspan="1" rowspan="1">Node</th>
| Node | rcv slotOffset | xmit slotOffset | <th align="center" colspan="1" rowspan="1">rcv slotOffset</th>
+------+---------------------+------------------------+ <th align="center" colspan="1" rowspan="1">xmit slotOffset</th>
| I | N/A | (0 OR 1) AND (2 OR 3) | </tr>
| A | (0 OR 1) | (2 OR 3 OR 4) | </thead>
| B | (2 OR 3) | (4 OR 5 OR 6) | <tbody>
| C | (2 OR 3 OR 4) | (5 OR 6) | <tr>
| D | (4 OR 5 OR 6) | (7 OR 8) | <td align="center" colspan="1" rowspan="1">I</td>
| E | (5 OR 6 OR 7 OR 8) | N/A | <td align="center" colspan="1" rowspan="1">N/A</td>
+------+---------------------+------------------------+ <td align="center" colspan="1" rowspan="1">(0 OR 1) AND (2 OR 3)
]]> </td>
</artwork> </tr>
</figure> <tr>
<td align="center" colspan="1" rowspan="1">A</td>
<!-- <td align="center" colspan="1" rowspan="1">(0 OR 1)</td>
<texttable title="schedule" anchor="schedtable"> <td align="center" colspan="1" rowspan="1">(2 OR 3 OR 4)</td>
<ttcol>Node</ttcol> </tr>
<ttcol align="center"> rcv slotOffset</ttcol> <tr>
<ttcol align="center"> xmit slotOffset</ttcol> <td align="center" colspan="1" rowspan="1">B</td>
<c>I</c> <td align="center" colspan="1" rowspan="1">(2 OR 3)</td>
<c> N/A </c> <td align="center" colspan="1" rowspan="1">(4 OR 5 OR 6)</td>
<c> (0 OR 1) AND (2 OR 3) </c> </tr>
<c>A</c> <tr>
<c> (0 OR 1)</c> <td align="center" colspan="1" rowspan="1">C</td>
<c> (2 OR 3 OR 4) </c> <td align="center" colspan="1" rowspan="1">(2 OR 3 OR 4)</td>
<c>B</c> <td align="center" colspan="1" rowspan="1">(5 OR 6)</td>
<c> (2 OR 3) </c> </tr>
<c> (4 OR 5 OR 6) </c> <tr>
<c>C</c> <td align="center" colspan="1" rowspan="1">D</td>
<c> (2 OR 3 OR 4)</c> <td align="center" colspan="1" rowspan="1">(4 OR 5 OR 6)</td>
<c> (5 OR 6) </c> <td align="center" colspan="1" rowspan="1">(7 OR 8)</td>
<c>D</c> </tr>
<c> (4 OR 5 OR 6) </c> <tr>
<c> (7 OR 8) </c> <td align="center" colspan="1" rowspan="1">E</td>
<c>E</c> <td align="center" colspan="1" rowspan="1">(5 OR 6 OR 7 OR 8)</t
<c> (5 OR 6 OR 7 OR 8) </c> d>
<c> N/A </c> <td align="center" colspan="1" rowspan="1">N/A</td>
</texttable> </tr>
--> </tbody>
</section> </table>
<!-- <section anchor="pmhds" title="Differentiated Services Per-Hop-Behavior" </section>
> --> </section>
<!-- <t> --> </section>
<!-- A future document could define a PHB for Deterministic Flows, to be indi <section numbered="true" removeInRFC="false" toc="include" pn="section-5">
cated --> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<!-- in the IANA registry where IETF-defined PHBs are listed. --> <t indent="0" pn="section-5-1">
<!-- </t> --> This document has no IANA actions.
<!-- </section> -->
</section>
</section>
<section><name>IANA Considerations</name>
<t>
This document does not require IANA action.
</t> </t>
</section> </section>
<section anchor="sec" numbered="true" removeInRFC="false" toc="include" pn="
<section anchor='sec'><name>Security Considerations</name> section-6">
<name slugifiedName="name-security-considerations">Security Considerations
<t> </name>
The <xref target='I-D.ietf-6tisch-minimal-security'>"Minimal Security <t indent="0" pn="section-6-1">
The <xref target="RFC9031" format="default" sectionFormat="of" derivedContent
="RFC9031">"Minimal Security
Framework for 6TiSCH"</xref> was optimized for Low-Power and TSCH operations. Framework for 6TiSCH"</xref> was optimized for Low-Power and TSCH operations.
The reader is encouraged to review the Security Considerations section of The reader is encouraged to review the Security Considerations section of
that document, which discusses 6TiSCH security issues in more details. that document (Section <xref target="RFC9031" sectionFormat="bare" section="9
</t> " format="default" derivedLink="https://rfc-editor.org/rfc/rfc9031#section-9" de
rivedContent="RFC9031"/>),
<section anchor='det'><name>Availability of Remote Services</name> which discusses 6TiSCH security issues in more details.
</t>
<t> <section anchor="det" numbered="true" removeInRFC="false" toc="include" pn
The operation of 6TiSCH Tracks inherits its high level operation from DetNet ="section-6.1">
and is subject to the observations in section 5 of <name slugifiedName="name-availability-of-remote-serv">Availability of R
<xref target='RFC8655'/>. The installation and the emote Services</name>
maintenance of the 6TiSCH Tracks depends on the availability of a controller <t indent="0" pn="section-6.1-1">
The operation of 6TiSCH Tracks inherits its high-level operation from DetNet
and is subject to the observations in
<xref target="RFC8655" section="5" sectionFormat="of" format="default" deriv
edLink="https://rfc-editor.org/rfc/rfc8655#section-5" derivedContent="RFC8655"/>
. The installation and the
maintenance of the 6TiSCH Tracks depend on the availability of a controller
with a PCE to compute and push them in the network. When that connectivity with a PCE to compute and push them in the network. When that connectivity
is lost, existing Tracks may continue to operate until the end of their is lost, existing Tracks may continue to operate until the end of their
lifetime, but cannot be removed or updated, and new Tracks cannot be lifetime, but cannot be removed or updated, and new Tracks cannot be
installed. installed.
</t> </t>
<t> <t indent="0" pn="section-6.1-2">
In a LLN, the communication with a remote PCE may be slow and unreactive to In an LLN, the communication with a remote PCE may be slow and unreactive to
rapid changes in the condition of the wireless communication. An attacker rapid changes in the condition of the wireless communication. An attacker
may introduce extra delay by selectively jamming some packets or some flows. may introduce extra delay by selectively jamming some packets or some flows.
The expectation is that the 6TiSCH Tracks enable enough redundancy to The expectation is that the 6TiSCH Tracks enable enough redundancy to
maintain the critical traffic in operation while new routes are calculated maintain the critical traffic in operation while new routes are calculated
and programmed into the network. and programmed into the network.
</t> </t>
<t> <t indent="0" pn="section-6.1-3">
As with DetNet in general, the communication with the PCE must be secured As with DetNet in general, the communication with the PCE must be secured
and should be protected against DoS attacks, including delay injection and and should be protected against DoS attacks, including delay injection and
blackholing attacks, and secured as discussed in the security considerations blackholing attacks, and secured as discussed in the security considerations
defined for Abstraction and Control of Traffic Engineered Networks (ACTN) in defined for Abstraction and Control of Traffic Engineered Networks (ACTN) in
Section 9 of <xref target='RFC8453'/>, which applies equally to DetNet and <xref target="RFC8453" section="9" sectionFormat="of" format="default" deriv edLink="https://rfc-editor.org/rfc/rfc8453#section-9" derivedContent="RFC8453"/> , which applies equally to DetNet and
6TiSCH. In a similar manner, the communication with the JRC must 6TiSCH. In a similar manner, the communication with the JRC must
be secured and should be protected against DoS attacks when possible. be secured and should be protected against DoS attacks when possible.
</t> </t>
</section>
</section> <section anchor="phy" numbered="true" removeInRFC="false" toc="include" pn
="section-6.2">
<section anchor='phy'><name>Selective Jamming</name> <name slugifiedName="name-selective-jamming">Selective Jamming</name>
<t> <t indent="0" pn="section-6.2-1">
The Hopping Sequence of a TSCH network is well-known, meaning that if a The hopping sequence of a TSCH network is well known, meaning that if a
rogue manages to identify a cell of a particular flow, then it may rogue manages to identify a cell of a particular flow, then it may
to selectively jam that cell, without impacting any other traffic. selectively jam that cell without impacting any other traffic.
This attack can be performed at the PHY layer without any knowledge of the This attack can be performed at the PHY layer without any knowledge of the
Layer-2 keys, and is very hard to detect and diagnose because only one flow Layer 2 keys, and it is very hard to detect and diagnose because only one fl ow
is impacted. is impacted.
</t> </t>
<t> <t indent="0" pn="section-6.2-2">
<xref target='I-D.tiloca-6tisch-robust-scheduling'/> proposes <xref target="I-D.tiloca-6tisch-robust-scheduling" format="default" sectionF
ormat="of" derivedContent="ROBUST-SCHEDULING"/> proposes
a method to obfuscate the hopping sequence and make it harder to perpetrate a method to obfuscate the hopping sequence and make it harder to perpetrate
that particular attack. that particular attack.
</t> </t>
</section>
</section> <section anchor="iee" numbered="true" removeInRFC="false" toc="include" pn
<section anchor='iee'><name>MAC-Layer Security</name> ="section-6.3">
<t> <name slugifiedName="name-mac-layer-security">MAC-Layer Security</name>
This architecture operates on IEEE Std. 802.15.4 and expects the Link-Layer <t indent="0" pn="section-6.3-1">
This architecture operates on IEEE Std 802.15.4 and expects the link-layer
security to be enabled at all times between connected devices, except for security to be enabled at all times between connected devices, except for
the very first step of the device join process, where a joining device may the very first step of the device join process, where a joining device may
need some initial, unsecured exchanges so as to obtain its initial key need some initial, unsecured exchanges so as to obtain its initial key
material. In a typical deployment, all joined nodes use the same keys and material. In a typical deployment, all joined nodes use the same keys, and
rekeying needs to be global. rekeying needs to be global.
</t> </t>
<t> <t indent="0" pn="section-6.3-2">
The 6TISCH Architecture relies on the join process to deny authorization of The 6TISCH architecture relies on the join process to deny authorization of
invalid nodes and preserve the integrity of the network keys. A rogue that invalid nodes and to preserve the integrity of the network keys. A rogue tha
t
managed to access the network can perform a large variety of attacks from managed to access the network can perform a large variety of attacks from
DoS to injecting forged packets and routing information. DoS to injecting forged packets and routing information.
"Zero-trust" properties would be highly desirable but are mostly not "Zero-trust" properties would be highly desirable but are mostly not
available at the time of this writing. <xref target='I-D.ietf-6lo-ap-nd'/> available at the time of this writing. <xref target="RFC8928" format="defaul t" sectionFormat="of" derivedContent="RFC8928"/>
is a notable exception that protects the ownership of IPv6 addresses and is a notable exception that protects the ownership of IPv6 addresses and
prevents a rogue node with L2 access from stealing and injecting traffic prevents a rogue node with L2 access from stealing and injecting traffic
on behalf of a legitimate node. on behalf of a legitimate node.
</t> </t>
</section>
<!-- <section anchor="ts" numbered="true" removeInRFC="false" toc="include" pn=
<t> "section-6.4">
The join protocol can be zero-touch and leverage ANIMA procedures, as <name slugifiedName="name-time-synchronization">Time Synchronization</na
detailed in the <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"> me>
6tisch Zero-Touch Secure Join protocol</xref>. <t indent="0" pn="section-6.4-1">
</t> Time synchronization in TSCH induces another event horizon whereby a node
<t>
Alternatively, the join protocol can be one-touch, in which case the pledge
is provisioned with a preshared key (PSK), and uses CoJP as specified in
<xref target="I-D.ietf-6tisch-minimal-security"/>.
</t>
-->
</section>
<section anchor='ts'><name>Time Synchronization</name>
<t>
Time Synchronization in TSCH induces another event horizon whereby a node
will only communicate with another node if they are synchronized within a will only communicate with another node if they are synchronized within a
guard time. The pledge discovers the synchronization of the network based guard time. The pledge discovers the synchronization of the network based
on the time of reception of the beacon. If an attacker synchronizes a pledge on the time of reception of the beacon. If an attacker synchronizes a pledge
outside of the guard time of the legitimate nodes then the pledge will never outside of the guard time of the legitimate nodes, then the pledge will neve r
see a legitimate beacon and may not discover the attack. see a legitimate beacon and may not discover the attack.
</t> </t>
<t>As discussed in <xref target='RFC8655'/>, measures <t indent="0" pn="section-6.4-2">As discussed in <xref target="RFC8655"
format="default" sectionFormat="of" derivedContent="RFC8655"/>, measures
must be taken to protect the time synchronization, and for 6TiSCH this must be taken to protect the time synchronization, and for 6TiSCH this
includes ensuring that the Absolute Slot Number (ASN), which is the node's includes ensuring that the Absolute Slot Number (ASN), which is the node's
sense of time, is not compromised. Once installed and as long as the node is sense of time, is not compromised. Once installed and as long as the node is
synchronized to the network, ASN is implicit in the transmissions. synchronized to the network, ASN is implicit in the transmissions.
</t> </t>
<t> <t indent="0" pn="section-6.4-3">
<xref target='IEEE802154'>IEEE Std. 802.15.4</xref> specifies that in a TSCH <xref target="IEEE802154" format="default" sectionFormat="of" derivedContent
="IEEE802154">IEEE Std 802.15.4</xref> specifies that in a TSCH
network, the nonce that is used for the computation of the Message Integrity network, the nonce that is used for the computation of the Message Integrity
Code (MIC) to secure Link-Layer frames is composed of the address Code (MIC) to secure link-layer frames is composed of the address
of the source of the frame and of the ASN. The standard assumes that the ASN of the source of the frame and of the ASN. The standard assumes that the ASN
is distributed securely by other means. The ASN is not passed explicitly in is distributed securely by other means. The ASN is not passed explicitly in
the data frames and does not constitute a complete anti-replay protection. the data frames and does not constitute a complete anti-replay protection.
It results that upper layer protocols must provide a way to detect As a result, upper-layer protocols must provide a way to detect
duplicates and cope with them. duplicates and cope with them.
</t> </t>
<t indent="0" pn="section-6.4-4">
<t>
If the receiver and the sender have a different sense of ASN, the MIC will If the receiver and the sender have a different sense of ASN, the MIC will
not validate and the frame will be dropped. In that sense, TSCH induces an not validate and the frame will be dropped. In that sense, TSCH induces an
event horizon whereby only nodes that have a common sense of ASN can talk to event horizon whereby only nodes that have a common sense of ASN can talk to
one another in an authenticated manner. With 6TiSCH, the pledge discovers a one another in an authenticated manner. With 6TiSCH, the pledge discovers a
tentative ASN in beacons from nodes that have already joined the network. tentative ASN in beacons from nodes that have already joined the network.
But even if the beacon can be authenticated, the ASN cannot be trusted as it But even if the beacon can be authenticated, the ASN cannot be trusted as it
could be a replay by an attacker and thus could announce an ASN that could be a replay by an attacker, announcing an ASN that
represents a time in the past. If the pledge uses an ASN that is learned represents a time in the past. If the pledge uses an ASN that is learned
from a replayed beacon for an encrypted transmission, a nonce-reuse attack from a replayed beacon for an encrypted transmission, a nonce-reuse attack
becomes possible and the network keys may be compromised. becomes possible, and the network keys may be compromised.
</t> </t>
</section> </section>
<section anchor="asv" numbered="true" removeInRFC="false" toc="include" pn
<section anchor='asv'><name>Validating ASN</name> ="section-6.5">
<name slugifiedName="name-validating-asn">Validating ASN</name>
<t> <t indent="0" pn="section-6.5-1">
After obtaining the tentative ASN, a pledge that wishes to join the After obtaining the tentative ASN, a pledge that wishes to join the
6TiSCH network must use a join protocol to obtain its security keys. 6TiSCH network must use a join protocol to obtain its security keys.
The join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP). The join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP).
In the minimal setting defined in In the minimal setting defined in
<xref target='I-D.ietf-6tisch-minimal-security'/>, the authentication <xref target="RFC9031" format="default" sectionFormat="of" derivedContent="R FC9031"/>, the authentication
requires a pre-shared key, based on which a secure session is derived. requires a pre-shared key, based on which a secure session is derived.
The CoJP exchange may also be preceded with a zero-touch handshake The CoJP exchange may also be preceded by a zero-touch handshake
<xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> in order <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" format="default" se
ctionFormat="of" derivedContent="ZEROTOUCH-JOIN"/> in order
to enable pledge joining based on certificates and/or inter-domain to enable pledge joining based on certificates and/or inter-domain
communication. communication.
</t> </t>
<t> <t indent="0" pn="section-6.5-2">
As detailed in <xref target='rflo'/>, As detailed in <xref target="rflo" format="default" sectionFormat="of" deriv
a Join Proxy (JP) helps the pledge for the join procedure by relaying the edContent="Section 4.2.1"/>,
a Join Proxy (JP) helps the pledge with the join procedure by relaying the
link-scope Join Request over the IP network to a Join Registrar/Coordinator link-scope Join Request over the IP network to a Join Registrar/Coordinator
(JRC) that can authenticate the pledge and validate that it is attached to (JRC) that can authenticate the pledge and validate that it is attached to
the appropriate network. As a result of the CoJP exchange, the pledge is in the appropriate network. As a result of the CoJP exchange, the pledge is in
possession of a Link-Layer material including keys and a short address, and possession of link-layer material including keys and a short address, and
if the ASN is known to be correct, all traffic can now be secured using CCM* if the ASN is known to be correct, all traffic can now be secured using CCM*
<xref target='CCMstar'/> at the Link-Layer. <xref target="CCMstar" format="default" sectionFormat="of" derivedContent="C
</t> CMstar"/> at the link layer.
<t> </t>
<t indent="0" pn="section-6.5-3">
The authentication steps must be such that they cannot be replayed by an The authentication steps must be such that they cannot be replayed by an
attacker, and they must not depend on the tentative ASN being valid. attacker, and they must not depend on the tentative ASN being valid.
During the authentication, the keying material that the pledge obtains from During the authentication, the keying material that the pledge obtains from
the JRC does not provide protection against spoofed ASN. Once the pledge has the JRC does not provide protection against spoofed ASN. Once the pledge has
obtained the keys to use in the network, it may still need to verify the ASN . obtained the keys to use in the network, it may still need to verify the ASN .
If the nonce used in the Layer-2 security derives from the extended (MAC-64) If the nonce used in the Layer 2 security derives from the extended (MAC-64)
address, then replaying the ASN alone cannot enable a nonce-reuse attack address, then replaying the ASN alone cannot enable a nonce-reuse attack
unless the same node is lost its state with a previous ASN. But unless the same node has lost its state with a previous ASN. But
if the nonce derives from the short address (e.g., assigned by the JRC) then if the nonce derives from the short address (e.g., assigned by the JRC), the
n
the JRC must ensure that it never assigns short addresses that were already the JRC must ensure that it never assigns short addresses that were already
given to this or other nodes with the same keys. In other words, the network given to this or other nodes with the same keys. In other words, the network
must be rekeyed before the JRC runs out of short addresses. must be rekeyed before the JRC runs out of short addresses.
</t> </t>
<!--t> </section>
Once the node obtains the keys from the JRC, an additional step may be <section anchor="keying" numbered="true" removeInRFC="false" toc="include"
required to ensure that the ASN is correct before encrypting any message. pn="section-6.6">
If the ASN is not guaranteed to be correct by other means, the pledge should <name slugifiedName="name-network-keying-and-rekeying">Network Keying an
perform a non-replayable exchange (e.g., using a nonce in the payload that d Rekeying</name>
does not derive from ASN) with a peer node that is trusted and has already <t indent="0" pn="section-6.6-1">
joined (e.g., the JP or a RPL time parent). The request by the pledge should <xref target="rflo" format="default" sectionFormat="of" derivedContent="Se
not be encrypted at the Link-Layer but only authenticated to avoid ction 4.2.1"/> provides an overview of the CoJP process described in
nonce-replay attacks. A successful authenticated exchange proves a common <xref target="RFC9031" format="default" sectionFormat="of" derivedContent=
sense of ASN and encrypted traffic can now happen. "RFC9031"/> by which an LLN
</t-->
</section>
<section anchor='keying'><name>Network Keying and Rekeying</name>
<t>
<xref target='rflo'/> provides an overview of the CoJP process described i
n
<xref target='I-D.ietf-6tisch-minimal-security'/> by which an LLN
can be assembled in the field, having been provisioned in a lab. can be assembled in the field, having been provisioned in a lab.
<xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> is future <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" format="default"
work that preceeds and then leverages the CoJP protocol using the sectionFormat="of" derivedContent="ZEROTOUCH-JOIN"/> is future
<xref target='I-D.ietf-anima-constrained-voucher'/> constrained profile work that precedes and then leverages CoJP using the
of <xref target='I-D.ietf-anima-bootstrapping-keyinfra'/> (BRSKI). <xref target="I-D.ietf-anima-constrained-voucher" format="default" section
This later work requires a yet-to-be standardized Lighweight Authenticated Format="of" derivedContent="CONSTRAINED-VOUCHER"/> constrained profile
of <xref target="RFC8995" format="default" sectionFormat="of" derivedConte
nt="RFC8995"/>.
This later work requires a yet-to-be standardized Lightweight Authenticate
d
Key Exchange protocol. Key Exchange protocol.
</t> </t>
<t> <t indent="0" pn="section-6.6-2">
The CoJP protocol results in distribution of a network-wide key that CoJP results in distribution of a network-wide key that
is to be used with <xref target='IEEE802154'/> security. The details of us is to be used with <xref target="IEEE802154" format="default" sectionForma
e are t="of" derivedContent="IEEE802154"/> security. The details of use are
described in <xref target='I-D.ietf-6tisch-minimal-security'/> sections described in <xref target="RFC9031" format="default" sectionFormat="of" de
9.2 and 9.3.2. rivedContent="RFC9031"/>, Sections <xref target="RFC9031" section="9.2" sectionF
</t> ormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9031#se
<t> ction-9.2" derivedContent="RFC9031"/>
The BRSKI mechanism may lead to the use of the CoJP protocol, in which cas and <xref target="RFC9031" section="9.3.2" sectionFormat="bare" format="de
e fault" derivedLink="https://rfc-editor.org/rfc/rfc9031#section-9.3.2" derivedCon
tent="RFC9031"/>.
</t>
<t indent="0" pn="section-6.6-3">
The BRSKI mechanism may lead to the use of CoJP, in which case
it also results in distribution of a network-wide key. Alternatively it also results in distribution of a network-wide key. Alternatively
the BRSKI mechanism may be followed by use of <xref target='I-D.ietf-ace-c oap-est'/> the BRSKI mechanism may be followed by use of <xref target="I-D.ietf-ace-c oap-est" format="default" sectionFormat="of" derivedContent="EST-COAPS"/>
to enroll certificates for each device. In that case, the certificates to enroll certificates for each device. In that case, the certificates
may be used with an <xref target='IEEE802154'/> key agreement protocol. T may be used with an <xref target="IEEE802154" format="default" sectionForm
he at="of" derivedContent="IEEE802154"/> key agreement protocol. The
description of this mechanism, while conceptually straight forward still description of this mechanism, while conceptually straightforward, still
has significant standardization hurdles to pass. has significant standardization hurdles to pass.
</t> </t>
<t> <t indent="0" pn="section-6.6-4">
<xref target='I-D.ietf-6tisch-minimal-security'/> section 9.2 describes <xref target="RFC9031" section="8.2" sectionFormat="of" format="default" d erivedLink="https://rfc-editor.org/rfc/rfc9031#section-8.2" derivedContent="RFC9 031"/> describes
a mechanism to change (rekey) the network. a mechanism to change (rekey) the network.
There are a number of reasons to initiate a network rekey: to remove There are a number of reasons to initiate a network rekey: to remove
unwanted (corrupt/malicious) nodes, to recover unused 2-byte short unwanted (corrupt/malicious) nodes, to recover unused 2-byte short
addresses, or due to limits in encryption algorithms. addresses, or due to limits in encryption algorithms.
For all of the mechanisms that distribute a network-wide key, rekeying For all of the mechanisms that distribute a network-wide key, rekeying
is also needed on a periodic basis. In more details: is also needed on a periodic basis. In more detail:
</t> </t>
<t></t><ul spacing='normal'> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6
<li> .6-5">
<li pn="section-6.6-5.1">
The mechanism described in The mechanism described in
<xref target='I-D.ietf-6tisch-minimal-security'/> section 9.2 requires <xref target="RFC9031" section="8.2" sectionFormat="of" format="default" d erivedLink="https://rfc-editor.org/rfc/rfc9031#section-8.2" derivedContent="RFC9 031"/> requires
advance communication between the JRC and every one of the nodes before advance communication between the JRC and every one of the nodes before
the key change. Given that many nodes may be sleepy, this operation the key change. Given that many nodes may be sleepy, this operation
may take a significant amount of time, and may consume a significant may take a significant amount of time and may consume a significant
portion of the available bandwidth. As such, network-wide rekeys in portion of the available bandwidth. As such, network-wide rekeys
order to exclude nodes that have become malicious will not be to exclude nodes that have become malicious will not be
particularly quick. If a rekey is already in progress, but the particularly quick. If a rekey is already in progress, but the
unwanted node has not yet been updated, then it is possible to to just unwanted node has not yet been updated, then it is possible to just
continue the operation. If the unwanted node has already received the continue the operation. If the unwanted node has already received the
update, then the rekey operation will need to be restarted. update, then the rekey operation will need to be restarted.
</li> </li>
<li> <li pn="section-6.6-5.2">
The cryptographic mechanisms used by IEEE Std. 802.15.4 include the 2-byte The cryptographic mechanisms used by IEEE Std 802.15.4 include the 2-byte
short address in the calculation of the context. short address in the calculation of the context.
A nonce-reuse attack may become feasible if a short address is reassigned A nonce-reuse attack may become feasible if a short address is reassigned
to another node while the same network-wide keys are in operation. to another node while the same network-wide keys are in operation.
A network that gains and loses nodes on a regular A network that gains and loses nodes on a regular
basis is likely to reach the 65536 limit of the 2-byte (16-bit) short basis is likely to reach the 65536 limit of the 2-byte (16-bit) short
addresses, even if the network has only a few thousand nodes. Network addresses, even if the network has only a few thousand nodes. Network
planners should consider the need to rekey the network on a periodic planners should consider the need to rekey the network on a periodic
basis in order to recover 2-byte addresses. The rekey can update the basis in order to recover 2-byte addresses. The rekey can update the
short addresses for active nodes if desired, but there is actually no short addresses for active nodes if desired, but there is actually no
need to do this as long as the key has been changed. need to do this as long as the key has been changed.
</li> </li>
<li> <li pn="section-6.6-5.3">
With TSCH as it stands at the time of this writing, the ASN will wrap With TSCH as it stands at the time of this writing, the ASN will wrap
after 2^40 timeslot durations, which means with the default values around after 2^40 timeslot durations, meaning around 350 years with the default v
350 years. Wrapping ASN is not expected to happen within the lifetime of alues.
Wrapping ASN is not expected to happen within the lifetime of
most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid
a nonce-reuse attack. a nonce-reuse attack.
</li> </li>
<li> <li pn="section-6.6-5.4">
Many cipher algorithms have some suggested limits on how many bytes Many cipher algorithms have some suggested limits on how many bytes
should be encrypted with that algorithm before a new key is used. should be encrypted with that algorithm before a new key is used.
These numbers are typically in the many to hundreds of gigabytes of These numbers are typically in the many to hundreds of gigabytes of
data. On very fast backbone networks this becomes an important data. On very fast backbone networks, this becomes an important
concern. On LLNs with typical data rates in the kilobits/second, concern. On LLNs with typical data rates in the kilobits/second,
this concern is significantly less. With IEEE Std. 802.15.4 as it stands this concern is significantly less. With IEEE Std 802.15.4 as it stands
at the time of this writing, the ASN will wrap before the limits of the at the time of this writing, the ASN will wrap before the limits of the
current L2 crypto (AES-CCM-128) are reached, so the problem should never current L2 crypto (AES-CCM-128) are reached, so the problem should never
occur. occur.
</li> </li>
<li> <li pn="section-6.6-5.5">
In any fashion, if the LLN is expected to operate continuously for decades In any fashion, if the LLN is expected to operate continuously for decades
,
then the operators are advised to plan for the need to rekey. then the operators are advised to plan for the need to rekey.
</li> </li>
</ul><t> </ul>
</t> <t indent="0" pn="section-6.6-6">
<t>
Except for urgent rekeys caused by malicious nodes, the rekey operation Except for urgent rekeys caused by malicious nodes, the rekey operation
described in <xref target='I-D.ietf-6tisch-minimal-security'/> described in <xref target="RFC9031" format="default" sectionFormat="of" de rivedContent="RFC9031"/>
can be done as a background task and can be done incrementally. It can be done as a background task and can be done incrementally. It
is a make-before-break mechanism. The switch over to the new key is is a make-before-break mechanism. The switch over to the new key is
not signaled by time, but rather by observation that the new key is in not signaled by time, but rather by observation that the new key is in
use. As such, the update can take as long as needed, or occur in as use. As such, the update can take as long as needed, or occur in as
short a time as practical. short a time as practical.
</t> </t>
</section>
</section> </section>
</section> </middle>
<section><name>Acknowledgments</name> <back>
<section><name>Contributors</name> <displayreference target="I-D.ietf-roll-rpl-industrial-applicability" to="RP
<t>The co-authors of this document are listed below: L-APPLICABILITY"/>
</t><dl spacing='normal'> <displayreference target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" to="ZER
<dt>Thomas Watteyne</dt><dd> OTOUCH-JOIN"/>
for his contribution to the whole design, in particular on TSCH and se <displayreference target="I-D.ietf-manet-aodvv2" to="AODVv2"/>
curity, <displayreference target="I-D.ietf-roll-aodv-rpl" to="AODV-RPL"/>
and to the open source community with openWSN that he created. <displayreference target="I-D.ietf-lwig-6lowpan-virtual-reassembly" to="VIRT
</dd> UAL-REASSEMBLY"/>
<dt>Xavier Vilajosana</dt><dd> <displayreference target="I-D.ietf-roll-dao-projection" to="DAO-PROJECTION"/
who lead the design of the minimal support with RPL and contributed >
deeply to the 6top design and the G-MPLS operation of Track switching; <displayreference target="I-D.ietf-roll-capabilities" to="RPL-MOP"/>
</dd> <displayreference target="I-D.selander-ace-cose-ecdhe" to="EDHOC"/>
<dt>Kris Pister</dt><dd> <displayreference target="I-D.thubert-roll-bier" to="RPL-BIER"/>
for creating TSCH and his continuing guidance through the elaboration <displayreference target="I-D.thubert-bier-replication-elimination" to="TE-P
of this design; REF"/>
</dd> <displayreference target="I-D.thubert-6lo-bier-dispatch" to="BITSTRINGS-6LOR
<dt>Malisa Vucinic</dt><dd> H"/>
for the work on the one-touch join process and his contribution to the <displayreference target="I-D.thubert-6man-unicast-lookup" to="ND-UNICAST-LO
Security Design Team; OKUP"/>
</dd> <displayreference target="I-D.pthubert-raw-architecture" to="RAW-ARCHITECTUR
<dt>Michael Richardson</dt><dd> E"/>
for his leadership role in the Security Design Team and his <displayreference target="I-D.tiloca-6tisch-robust-scheduling" to="ROBUST-SC
contribution throughout this document; HEDULING"/>
</dd> <displayreference target="I-D.ietf-ace-coap-est" to="EST-COAPS"/>
<dt>Tero Kivinen</dt><dd> <displayreference target="I-D.ietf-anima-constrained-voucher" to="CONSTRAINE
for his contribution to the security work in general and the security D-VOUCHER"/>
section in particular. <displayreference target="I-D.ietf-raw-use-cases" to="RAW-USE-CASES"/>
</dd> <references pn="section-7">
<dt>Maria Rita Palattella</dt><dd> <name slugifiedName="name-references">References</name>
for managing the Terminology document merged into this through the work <references pn="section-7.1">
of 6TiSCH; <name slugifiedName="name-normative-references">Normative References</na
</dd> me>
<dt>Simon Duquennoy</dt><dd> <reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc7
for his contribution to the open source community with the 6TiSCH 68" quoteTitle="true" derivedAnchor="RFC0768">
implementaton of contiki, and for his contribution to MSF and <front>
autonomous unicast cells. <title>User Datagram Protocol</title>
</dd> <author initials="J." surname="Postel" fullname="J. Postel">
<dt>Qin Wang</dt><dd> <organization showOnFrontPage="true"/>
who lead the design of the 6top sublayer and contributed related text </author>
that was moved and/or adapted in this document; <date year="1980" month="August"/>
</dd> </front>
<dt>Rene Struik</dt><dd> <seriesInfo name="STD" value="6"/>
for the security section and his contribution to the Security Design <seriesInfo name="RFC" value="768"/>
Team; <seriesInfo name="DOI" value="10.17487/RFC0768"/>
</dd> </reference>
<dt>Robert Assimiti</dt><dd> <reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4
for his breakthrough work on RPL over TSCH and initial text and 861" quoteTitle="true" derivedAnchor="RFC4861">
guidance; <front>
</dd> <title>Neighbor Discovery for IP version 6 (IPv6)</title>
</dl><t> <author initials="T." surname="Narten" fullname="T. Narten">
</t> <organization showOnFrontPage="true"/>
</section> </author>
<section><name>Special Thanks</name><t> <author initials="E." surname="Nordmark" fullname="E. Nordmark">
Special thanks to Jonathan Simon, Giuseppe Piro, Subir Das <organization showOnFrontPage="true"/>
and Yoshihiro Ohba for their deep contribution to the initial security </author>
work, to Yasuyuki Tanaka for his work on implementation and simulation <author initials="W." surname="Simpson" fullname="W. Simpson">
that tremendously helped build a robust system, to Diego Dujovne for <organization showOnFrontPage="true"/>
starting and leading the SF0 effort and to Tengfei Chang for evolving it </author>
in the MSF. <author initials="H." surname="Soliman" fullname="H. Soliman">
</t><t> <organization showOnFrontPage="true"/>
Special thanks also to Pat Kinney, Charlie Perkins and Bob Heile for their </author>
support in maintaining the connection active and the design in line with <date year="2007" month="September"/>
work happening at IEEE 802.15. <abstract>
</t> <t> <t indent="0">This document specifies the Neighbor Discovery proto
Special thanks to Ted Lemon who was the INT Area A-D while this col for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to dis
document was initiated for his great support and help throughout, cover each other's presence, to determine each other's link-layer addresses, to
and to Suresh Krishnan who took over with that kind efficiency of his till find routers, and to maintain reachability information about the paths to active
publication. neighbors. [STANDARDS-TRACK]</t>
</t><t> </abstract>
Also special thanks to Ralph Droms who performed the first INT Area </front>
Directorate review, that was very deep and thorough and radically changed <seriesInfo name="RFC" value="4861"/>
the orientations of this document, and then to Eliot Lear and Carlos <seriesInfo name="DOI" value="10.17487/RFC4861"/>
Pignataro who help finalize this document in preparation to the IESG </reference>
reviews, and to Gorry Fairhurst, David Mandelberg, Qin Wu, Francis Dupont, <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4
Eric Vyncke, Mirja Kuhlewind, Roman Danyliw, Benjamin Kaduk 862" quoteTitle="true" derivedAnchor="RFC4862">
and Andrew Malis, who contributed to the final shaping of this document <front>
through the IESG review procedure. <title>IPv6 Stateless Address Autoconfiguration</title>
</t> <author initials="S." surname="Thomson" fullname="S. Thomson">
</section> <organization showOnFrontPage="true"/>
<section><name>And Do not Forget</name> </author>
<t>This document is the result of multiple interactions, in <author initials="T." surname="Narten" fullname="T. Narten">
particular during the 6TiSCH (bi)Weekly Interim call, relayed through <organization showOnFrontPage="true"/>
the 6TiSCH mailing list at the IETF, over the course of more than 5 years. </author>
</t><t> <author initials="T." surname="Jinmei" fullname="T. Jinmei">
The authors wish to thank in arbitrary order: <organization showOnFrontPage="true"/>
Alaeddine Weslati, Chonggang Wang, Georgios Exarchakos, Zhuo Chen, </author>
Georgios Papadopoulos, Eric Levy-Abegnoli, <date year="2007" month="September"/>
Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Deji Chen, Martin Turon, <abstract>
Dominique Barthel, Elvis Vogli, Geraldine Texier, <t indent="0">This document specifies the steps a host takes in de
Guillaume Gaillard, Herman Storey, Kazushi Muraoka, Ken Bannister, ciding how to autoconfigure its interfaces in IP version 6. The autoconfigurati
Kuor Hsin Chang, Laurent Toutain, Maik Seewald, on process includes generating a link-local address, generating global addresses
Michael Behringer, Nancy Cam Winget, Nicola Accettura, Nicolas Montavont, via stateless address autoconfiguration, and the Duplicate Address Detection pr
Oleg Hahm, Patrick Wetterwald, Paul Duffy, Peter van der Stock, Rahul Sen, ocedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]<
Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin-Lopez, /t>
Raghuram Sudhaakar, Sedat Gormus, Shitanshu Shah, Steve Simlo, </abstract>
Tina Tsou, Tom Phinney, Xavier Lagrange, Ines Robles and </front>
Samita Chakrabarti for their participation and various contributions. <seriesInfo name="RFC" value="4862"/>
</t> <seriesInfo name="DOI" value="10.17487/RFC4862"/>
</section> </reference>
</section> <reference anchor="RFC4944" target="https://www.rfc-editor.org/info/rfc4
</middle> 944" quoteTitle="true" derivedAnchor="RFC4944">
<front>
<back> <title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</tit
<displayreference target="I-D.ietf-6tisch-minimal-security" to le>
="MIN-SECURITY"/> <author initials="G." surname="Montenegro" fullname="G. Montenegro">
<displayreference target="I-D.ietf-6lo-backbone-router" to="6B <organization showOnFrontPage="true"/>
BR-DRAFT"/> </author>
<displayreference target="I-D.ietf-6lo-fragment-recovery" to=" <author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar
RECOV-FRAG"/> ">
<displayreference target="I-D.ietf-6lo-minimal-fragment" to="M <organization showOnFrontPage="true"/>
IN-FRAG"/> </author>
<displayreference target="I-D.ietf-6lo-ap-nd" to="AP-ND"/> <author initials="J." surname="Hui" fullname="J. Hui">
<displayreference target="I-D.ietf-roll-useofrplinfo" to="USEo <organization showOnFrontPage="true"/>
fRPLinfo"/> </author>
<displayreference target="I-D.ietf-roll-unaware-leaves" to="RU <author initials="D." surname="Culler" fullname="D. Culler">
L-DRAFT"/> <organization showOnFrontPage="true"/>
<displayreference target="I-D.ietf-6tisch-enrollment-enhanced-beacon" </author>
to="ENH-BEACON"/> <date year="2007" month="September"/>
<displayreference target="I-D.ietf-6tisch-msf" to="MSF"/> <abstract>
<references><name>Normative References</name> <t indent="0">This document describes the frame format for transmi
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ssion of IPv6 packets and the method of forming IPv6 link-local addresses and st
ce.RFC.0768.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification --> atelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifi
<!-- <?rfc include="reference.RFC.2119"?> Key words for use in RFCs to Ind cations include a simple header compression scheme using shared context and prov
icate Requirement Levels --> isions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </abstract>
ce.RFC.4861.xml'/> <!-- neighbor Discovery for IP version 6 (IPv6) --> </front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <seriesInfo name="RFC" value="4944"/>
ce.RFC.4862.xml'/> <!-- IPv6 Stateless Address Autoconfiguration --> <seriesInfo name="DOI" value="10.17487/RFC4944"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </reference>
ce.RFC.4944.xml'/> <!-- 6LoWPAN --> <reference anchor="RFC5889" target="https://www.rfc-editor.org/info/rfc5
889" quoteTitle="true" derivedAnchor="RFC5889">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <front>
ce.RFC.6282.xml'/> <!-- Compression Format for IPv6 Datagrams over IEEE 802.15.4 <title>IP Addressing Model in Ad Hoc Networks</title>
-Based Networks --> <author initials="E." surname="Baccelli" fullname="E. Baccelli" role
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ="editor">
ce.RFC.6550.xml'/> <!-- RPL: IPv6 Routing Protocol for Low-Power and Lossy Netwo <organization showOnFrontPage="true"/>
rks --> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <author initials="M." surname="Townsley" fullname="M. Townsley" role
ce.RFC.6551.xml'/> <!-- Routing Metrics Used for Path Calculation in LLNs --> ="editor">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <organization showOnFrontPage="true"/>
ce.RFC.6552.xml'/> <!-- RPL OF0: Objective Function Zero for RPL--> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <date year="2010" month="September"/>
ce.RFC.6553.xml'/> <!-- RPL Option for Carrying RPL Information in Data-Plane Da <abstract>
tagrams --> <t indent="0">This document describes a model for configuring IP a
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ddresses and subnet prefixes on the interfaces of routers which connect to links
ce.RFC.6554.xml'/> <!-- An IPv6 Routing Header for Source Routes with RPL --> with undetermined connectivity properties. This document is not an Internet S
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen tandards Track specification; it is published for informational purposes.</t>
ce.RFC.6775.xml'/> <!-- neighbor Discovery Optimization for IPv6 over Low-Power </abstract>
Wireless Personal Area Networks (6LoWPANs) --> </front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <seriesInfo name="RFC" value="5889"/>
ce.RFC.7252.xml'/> <!-- CoAP --> <seriesInfo name="DOI" value="10.17487/RFC5889"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </reference>
ce.RFC.8025.xml'/> <!-- 6LoRH coding dispatch--> <reference anchor="RFC6282" target="https://www.rfc-editor.org/info/rfc6
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen 282" quoteTitle="true" derivedAnchor="RFC6282">
ce.RFC.8137.xml'/> <front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Base
ce.RFC.8138.xml'/> <!-- 6LoRH routing dispatch--> d Networks</title>
<!-- <?rfc include='reference.RFC.8174'?> Ambiguity of Uppercase vs Lower <author initials="J." surname="Hui" fullname="J. Hui" role="editor">
case in RFC 2119 Key Words--> <organization showOnFrontPage="true"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </author>
ce.RFC.8180.xml'/> <!-- 6TiSCH minimal --> <author initials="P." surname="Thubert" fullname="P. Thubert">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <organization showOnFrontPage="true"/>
ce.RFC.8200.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification --> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <date year="2011" month="September"/>
ce.RFC.8480.xml'/> <!-- 6top protocol --> <abstract>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <t indent="0">This document updates RFC 4944, "Transmission of IPv
ce.RFC.8453.xml'/> <!-- ACTN --> 6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen compression format for IPv6 packet delivery in Low Power Wireless Personal Area
ce.RFC.8505.xml'/> <!-- RFC6775 update --> Networks (6LoWPANs). The compression format relies on shared context to allow c
ompression of arbitrary prefixes. How the information is maintained in that sha
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen red context is out of scope. This document specifies compression of multicast ad
ce.RFC.7102.xml'/> <!-- Terms Used in Routing for Low-Power and Lossy Networks - dresses and a framework for compressing next headers. UDP header compression is
-> specified within this framework. [STANDARDS-TRACK]</t>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </abstract>
ce.RFC.7554.xml'/> <!-- 6TiSCH TSCH --> </front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <seriesInfo name="RFC" value="6282"/>
ce.RFC.7228.xml'/> <!-- Terminology for Constrained-Node Networks --> <seriesInfo name="DOI" value="10.17487/RFC6282"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </reference>
ce.RFC.5889.xml'/> <!-- IP Addressing Model in Ad Hoc Networks --> <reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen 550" quoteTitle="true" derivedAnchor="RFC6550">
ce.RFC.8655.xml'/> <!-- DetNet Architecture --> <front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere title>
nce.I-D.ietf-6tisch-minimal-security.xml'/> <author initials="T." surname="Winter" fullname="T. Winter" role="ed
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere itor">
nce.I-D.ietf-6lo-backbone-router.xml'/> <organization showOnFrontPage="true"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere </author>
nce.I-D.ietf-6lo-fragment-recovery.xml'/> <author initials="P." surname="Thubert" fullname="P. Thubert" role="
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere editor">
nce.I-D.ietf-6lo-minimal-fragment.xml'/> <organization showOnFrontPage="true"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere </author>
nce.I-D.ietf-6lo-ap-nd.xml'/> <author initials="A." surname="Brandt" fullname="A. Brandt">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <organization showOnFrontPage="true"/>
nce.I-D.ietf-roll-useofrplinfo.xml'/> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <author initials="J." surname="Hui" fullname="J. Hui">
nce.I-D.ietf-roll-unaware-leaves.xml'/> <organization showOnFrontPage="true"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere </author>
nce.I-D.ietf-6tisch-enrollment-enhanced-beacon.xml'/> <author initials="R." surname="Kelsey" fullname="R. Kelsey">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <organization showOnFrontPage="true"/>
nce.I-D.ietf-6tisch-msf.xml'/> </author>
<author initials="P." surname="Levis" fullname="P. Levis">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Struik" fullname="R. Struik">
<organization showOnFrontPage="true"/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Alexander" fullname="R. Alexander">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">Low-Power and Lossy Networks (LLNs) are a class of n
etwork in which both the routers and their interconnect are constrained. LLN ro
uters typically operate with constraints on processing power, memory, and energy
(battery power). Their interconnects are characterized by high loss rates, low
data rates, and instability. LLNs are comprised of anything from a few dozen t
o thousands of routers. Supported traffic flows include point-to-point (between
devices inside the LLN), point-to-multipoint (from a central control point to a
subset of devices inside the LLN), and multipoint-to-point (from devices inside
the LLN towards a central control point). This document specifies the IPv6 Rou
ting Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism
whereby multipoint-to-point traffic from devices inside the LLN towards a centr
al control point as well as point-to-multipoint traffic from the central control
point to the devices inside the LLN are supported. Support for point-to-point
traffic is also available. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6550"/>
<seriesInfo name="DOI" value="10.17487/RFC6550"/>
</reference>
<reference anchor="RFC6551" target="https://www.rfc-editor.org/info/rfc6
551" quoteTitle="true" derivedAnchor="RFC6551">
<front>
<title>Routing Metrics Used for Path Calculation in Low-Power and Lo
ssy Networks</title>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Kim" fullname="M. Kim" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Dejean" fullname="N. Dejean">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Barthel" fullname="D. Barthel">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">Low-Power and Lossy Networks (LLNs) have unique char
acteristics compared with traditional wired and ad hoc networks that require the
specification of new routing metrics and constraints. By contrast, with typica
l Interior Gateway Protocol (IGP) routing metrics using hop counts or link metri
cs, this document specifies a set of link and node routing metrics and constrain
ts suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy N
etworks (RPL). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6551"/>
<seriesInfo name="DOI" value="10.17487/RFC6551"/>
</reference>
<reference anchor="RFC6552" target="https://www.rfc-editor.org/info/rfc6
552" quoteTitle="true" derivedAnchor="RFC6552">
<front>
<title>Objective Function Zero for the Routing Protocol for Low-Powe
r and Lossy Networks (RPL)</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">The Routing Protocol for Low-Power and Lossy Network
s (RPL) specification defines a generic Distance Vector protocol that is adapted
to a variety of network types by the application of specific Objective Function
s (OFs). An OF states the outcome of the process used by a RPL node to select a
nd optimize routes within a RPL Instance based on the Information Objects availa
ble; an OF is not an algorithm.</t>
<t indent="0">This document specifies a basic Objective Function t
hat relies only on the objects that are defined in the RPL and does not use any
protocol extensions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6552"/>
<seriesInfo name="DOI" value="10.17487/RFC6552"/>
</reference>
<reference anchor="RFC6553" target="https://www.rfc-editor.org/info/rfc6
553" quoteTitle="true" derivedAnchor="RFC6553">
<front>
<title>The Routing Protocol for Low-Power and Lossy Networks (RPL) O
ption for Carrying RPL Information in Data-Plane Datagrams</title>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization showOnFrontPage="true"/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">The Routing Protocol for Low-Power and Lossy Network
s (RPL) includes routing information in data-plane datagrams to quickly identify
inconsistencies in the routing topology. This document describes the RPL Optio
n for use among RPL routers to include such routing information. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6553"/>
<seriesInfo name="DOI" value="10.17487/RFC6553"/>
</reference>
<reference anchor="RFC6554" target="https://www.rfc-editor.org/info/rfc6
554" quoteTitle="true" derivedAnchor="RFC6554">
<front>
<title>An IPv6 Routing Header for Source Routes with the Routing Pro
tocol for Low-Power and Lossy Networks (RPL)</title>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization showOnFrontPage="true"/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Culler" fullname="D. Culler">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Manral" fullname="V. Manral">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">In Low-Power and Lossy Networks (LLNs), memory const
raints on routers may limit them to maintaining, at most, a few routes. In some
configurations, it is necessary to use these memory-constrained routers to deli
ver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and L
ossy Networks (RPL) can be used in some deployments to store most, if not all, r
outes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and
forward the IPv6 datagram using a source routing technique to avoid large routin
g tables on memory-constrained routers. This document specifies a new IPv6 Rout
ing header type for delivering datagrams within a RPL routing domain. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6554"/>
<seriesInfo name="DOI" value="10.17487/RFC6554"/>
</reference>
<reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6
775" quoteTitle="true" derivedAnchor="RFC6775">
<front>
<title>Neighbor Discovery Optimization for IPv6 over Low-Power Wirel
ess Personal Area Networks (6LoWPANs)</title>
<author initials="Z." surname="Shelby" fullname="Z. Shelby" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti
">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="November"/>
<abstract>
<t indent="0">The IETF work in IPv6 over Low-power Wireless Person
al Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and othe
r similar link technologies have limited or no usage of multicast signaling due
to energy conservation. In addition, the wireless network may not strictly foll
ow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery
was not designed for non- transitive wireless links, as its reliance on the trad
itional IPv6 link concept and its heavy use of multicast make it inefficient and
sometimes impractical in a low-power and lossy network. This document describe
s simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, an
d duplicate address detection for Low- power Wireless Personal Area Networks and
similar networks. The document thus updates RFC 4944 to specify the use of the
optimizations defined here. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6775"/>
<seriesInfo name="DOI" value="10.17487/RFC6775"/>
</reference>
<reference anchor="RFC7102" target="https://www.rfc-editor.org/info/rfc7
102" quoteTitle="true" derivedAnchor="RFC7102">
<front>
<title>Terms Used in Routing for Low-Power and Lossy Networks</title
>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="January"/>
<abstract>
<t indent="0">This document provides a glossary of terminology use
d in routing requirements and solutions for networks referred to as Low-Power an
d Lossy Networks (LLNs). An LLN is typically composed of many embedded devices
with limited power, memory, and processing resources interconnected by a variety
of links. There is a wide scope of application areas for LLNs, including indus
trial monitoring, building automation (e.g., heating, ventilation, air condition
ing, lighting, access control, fire), connected home, health care, environmental
monitoring, urban sensor networks, energy management, assets tracking, and refr
igeration.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7102"/>
<seriesInfo name="DOI" value="10.17487/RFC7102"/>
</reference>
<reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7
228" quoteTitle="true" derivedAnchor="RFC7228">
<front>
<title>Terminology for Constrained-Node Networks</title>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Ersue" fullname="M. Ersue">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Keranen" fullname="A. Keranen">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="May"/>
<abstract>
<t indent="0">The Internet Protocol Suite is increasingly used on
small devices with severe constraints on power, memory, and processing resources
, creating constrained-node networks. This document provides a number of basic
terms that have been useful in the standardization work for constrained-node net
works.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7228"/>
<seriesInfo name="DOI" value="10.17487/RFC7228"/>
</reference>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
252" quoteTitle="true" derivedAnchor="RFC7252">
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials="Z." surname="Shelby" fullname="Z. Shelby">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Hartke" fullname="K. Hartke">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="June"/>
<abstract>
<t indent="0">The Constrained Application Protocol (CoAP) is a spe
cialized web transfer protocol for use with constrained nodes and constrained (e
.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers wi
th small amounts of ROM and RAM, while constrained networks such as IPv6 over Lo
w-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error
rates and a typical throughput of 10s of kbit/s. The protocol is designed for m
achine- to-machine (M2M) applications such as smart energy and building automati
on.</t>
<t indent="0">CoAP provides a request/response interaction model b
etween application endpoints, supports built-in discovery of services and resour
ces, and includes key concepts of the Web such as URIs and Internet media types.
CoAP is designed to easily interface with HTTP for integration with the Web wh
ile meeting specialized requirements such as multicast support, very low overhea
d, and simplicity for constrained environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>
<reference anchor="RFC7554" target="https://www.rfc-editor.org/info/rfc7
554" quoteTitle="true" derivedAnchor="RFC7554">
<front>
<title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in t
he Internet of Things (IoT): Problem Statement</title>
<author initials="T." surname="Watteyne" fullname="T. Watteyne" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Palattella" fullname="M. Palattella">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Grieco" fullname="L. Grieco">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="May"/>
<abstract>
<t indent="0">This document describes the environment, problem sta
tement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Acces
s Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy
Networks (LLNs). The set of goals enumerated in this document form an initial
set only.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7554"/>
<seriesInfo name="DOI" value="10.17487/RFC7554"/>
</reference>
<reference anchor="RFC8025" target="https://www.rfc-editor.org/info/rfc8
025" quoteTitle="true" derivedAnchor="RFC8025">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
Paging Dispatch</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Cragie" fullname="R. Cragie">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="November"/>
<abstract>
<t indent="0">This specification updates RFC 4944 to introduce a n
ew context switch mechanism for IPv6 over Low-Power Wireless Personal Area Netwo
rk (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Pagi
ng Dispatch.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8025"/>
<seriesInfo name="DOI" value="10.17487/RFC8025"/>
</reference>
<reference anchor="RFC8137" target="https://www.rfc-editor.org/info/rfc8
137" quoteTitle="true" derivedAnchor="RFC8137">
<front>
<title>IEEE 802.15.4 Information Element for the IETF</title>
<author initials="T." surname="Kivinen" fullname="T. Kivinen">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Kinney" fullname="P. Kinney">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">IEEE Std 802.15.4 defines Information Elements (IEs)
that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.1
5 Assigned Numbers Authority (ANA) manages the registry of the Information Eleme
nts. This document formulates a request for ANA to allocate a number from that
registry for the IETF and describes how the IE is formatted to provide subtypes.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8137"/>
<seriesInfo name="DOI" value="10.17487/RFC8137"/>
</reference>
<reference anchor="RFC8138" target="https://www.rfc-editor.org/info/rfc8
138" quoteTitle="true" derivedAnchor="RFC8138">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
Routing Header</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Toutain" fullname="L. Toutain">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Cragie" fullname="R. Cragie">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="April"/>
<abstract>
<t indent="0">This specification introduces a new IPv6 over Low-Po
wer Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN ro
ute-over topologies, which initially covers the needs of Routing Protocol for Lo
w-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this
dispatch type, this specification defines a method to compress the RPL Option (
RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-I
P technique, and is extensible for more applications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8138"/>
<seriesInfo name="DOI" value="10.17487/RFC8138"/>
</reference>
<reference anchor="RFC8180" target="https://www.rfc-editor.org/info/rfc8
180" quoteTitle="true" derivedAnchor="RFC8180">
<front>
<title>Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Co
nfiguration</title>
<author initials="X." surname="Vilajosana" fullname="X. Vilajosana"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Watteyne" fullname="T. Watteyne">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">This document describes a minimal mode of operation
for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal
mode of operation specifies the baseline set of protocols that need to be suppo
rted and the recommended configurations and modes of operation sufficient to ena
ble a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time-
Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. T
his minimal mode uses a collection of protocols with the respective configuratio
ns, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framew
ork, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This
minimal configuration provides the necessary bandwidth for network and security
bootstrapping and defines the proper link between the IETF protocols that inter
face to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implem
ented by all 6TiSCH-compliant devices.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="210"/>
<seriesInfo name="RFC" value="8180"/>
<seriesInfo name="DOI" value="10.17487/RFC8180"/>
</reference>
<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8
200" quoteTitle="true" derivedAnchor="RFC8200">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="July"/>
<abstract>
<t indent="0">This document specifies version 6 of the Internet Pr
otocol (IPv6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC8453" target="https://www.rfc-editor.org/info/rfc8
453" quoteTitle="true" derivedAnchor="RFC8453">
<front>
<title>Framework for Abstraction and Control of TE Networks (ACTN)</
title>
<author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">Traffic Engineered (TE) networks have a variety of m
echanisms to facilitate the separation of the data plane and control plane. The
y also have a range of management and provisioning protocols to configure and ac
tivate network resources. These mechanisms represent key technologies for enabl
ing flexible and dynamic networking. The term "Traffic Engineered network" refe
rs to a network that uses any connection-oriented technology under the control o
f a distributed or centralized control plane to support dynamic provisioning of
end-to- end connectivity.</t>
<t indent="0">Abstraction of network resources is a technique that
can be applied to a single network domain or across multiple domains to create
a single virtualized network that is under the control of a network operator or
the customer of the operator that actually owns the network resources.</t>
<t indent="0">This document provides a framework for Abstraction a
nd Control of TE Networks (ACTN) to support virtual network services and connect
ivity services.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8453"/>
<seriesInfo name="DOI" value="10.17487/RFC8453"/>
</reference>
<reference anchor="RFC8480" target="https://www.rfc-editor.org/info/rfc8
480" quoteTitle="true" derivedAnchor="RFC8480">
<front>
<title>6TiSCH Operation Sublayer (6top) Protocol (6P)</title>
<author initials="Q." surname="Wang" fullname="Q. Wang" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="X." surname="Vilajosana" fullname="X. Vilajosana">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Watteyne" fullname="T. Watteyne">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="November"/>
<abstract>
<t indent="0">This document defines the "IPv6 over the TSCH mode o
f IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enable
s distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/de
lete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of
the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.
4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling
Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decid
es when to add/delete cells, and it triggers 6P Transactions. The definition of
SFs is out of scope for this document; however, this document provides the requ
irements for an SF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8480"/>
<seriesInfo name="DOI" value="10.17487/RFC8480"/>
</reference>
<reference anchor="RFC8505" target="https://www.rfc-editor.org/info/rfc8
505" quoteTitle="true" derivedAnchor="RFC8505">
<front>
<title>Registration Extensions for IPv6 over Low-Power Wireless Pers
onal Area Network (6LoWPAN) Neighbor Discovery</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti
">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="November"/>
<abstract>
<t indent="0">This specification updates RFC 6775 -- the Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to
clarify the role of the protocol as a registration technique and simplify the r
egistration operation in 6LoWPAN routers, as well as to provide enhancements to
the registration capabilities and mobility detection for different network topol
ogies, including the Routing Registrars performing routing for host routes and/o
r proxy Neighbor Discovery in a low-power network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8505"/>
<seriesInfo name="DOI" value="10.17487/RFC8505"/>
</reference>
<reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc8
655" quoteTitle="true" derivedAnchor="RFC8655">
<front>
<title>Deterministic Networking Architecture</title>
<author initials="N." surname="Finn" fullname="N. Finn">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Varga" fullname="B. Varga">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Farkas" fullname="J. Farkas">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="October"/>
<abstract>
<t indent="0">This document provides the overall architecture for
Deterministic Networking (DetNet), which provides a capability to carry specifie
d unicast or multicast data flows for real-time applications with extremely low
data loss rates and bounded latency within a network domain. Techniques used in
clude 1) reserving data-plane resources for individual (or aggregated) DetNet fl
ows in some or all of the intermediate nodes along the path of the flow, 2) prov
iding explicit routes for DetNet flows that do not immediately change with the n
etwork topology, and 3) distributing data from DetNet flow packets over time and
/or space to ensure delivery of each packet's data in spite of the loss of a pat
h. DetNet operates at the IP layer and delivers service over lower-layer techno
logies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.
1.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8655"/>
<seriesInfo name="DOI" value="10.17487/RFC8655"/>
</reference>
<reference anchor="RFC8928" target="https://www.rfc-editor.org/info/rfc8
928" quoteTitle="true" derivedAnchor="RFC8928">
<front>
<title>Address-Protected Neighbor Discovery for Low-Power and Lossy
Networks</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Sarikaya" fullname="B. Sarikaya">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Sethi" fullname="M. Sethi">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Struik" fullname="R. Struik">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="November"/>
<abstract>
<t indent="0">This document updates the IPv6 over Low-Power Wirele
ss Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in R
FCs 6775 and 8505. The new extension is called Address-Protected Neighbor Disco
very (AP-ND), and it protects the owner of an address against address theft and
impersonation attacks in a Low-Power and Lossy Network (LLN). Nodes supporting
this extension compute a cryptographic identifier (Crypto-ID), and use it with o
ne or more of their Registered Addresses. The Crypto-ID identifies the owner of
the Registered Address and can be used to provide proof of ownership of the Regi
stered Addresses. Once an address is registered with the Crypto-ID and a proof o
f ownership is provided, only the owner of that address can modify the registrat
ion information, thereby enforcing Source Address Validation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8928"/>
<seriesInfo name="DOI" value="10.17487/RFC8928"/>
</reference>
<reference anchor="RFC8929" target="https://www.rfc-editor.org/info/rfc8
929" quoteTitle="true" derivedAnchor="RFC8929">
<front>
<title>IPv6 Backbone Router</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C.E." surname="Perkins" fullname="C.E. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Levy-Abegnoli" fullname="E. Levy-Abeg
noli">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="November"/>
<abstract>
<t indent="0">This document updates RFCs 6775 and 8505 in order to
enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called
"Backbone Routers". Backbone Routers are placed along the wireless edge of a bac
kbone and federate multiple wireless links to form a single Multi-Link Subnet (M
LSN).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8929"/>
<seriesInfo name="DOI" value="10.17487/RFC8929"/>
</reference>
<reference anchor="RFC8930" target="https://www.rfc-editor.org/info/rfc8
930" quoteTitle="true" derivedAnchor="RFC8930">
<front>
<title>On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network
</title>
<author initials="T." surname="Watteyne" fullname="T. Watteyne" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="November"/>
<abstract>
<t indent="0">This document provides generic rules to enable the f
orwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fra
gment over a route-over network. Forwarding fragments can improve both end-to-en
d latency and reliability as well as reduce the buffer requirements in intermedi
ate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (
VRBs).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8930"/>
<seriesInfo name="DOI" value="10.17487/RFC8930"/>
</reference>
<reference anchor="RFC8931" target="https://www.rfc-editor.org/info/rfc8
931" quoteTitle="true" derivedAnchor="RFC8931">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
Selective Fragment Recovery</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="November"/>
<abstract>
<t indent="0">This document updates RFC 4944 with a protocol that
forwards individual fragments across a route-over mesh and recovers them end to
end, with congestion control capabilities to protect the network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8931"/>
<seriesInfo name="DOI" value="10.17487/RFC8931"/>
</reference>
<reference anchor="RFC9008" target="https://www.rfc-editor.org/info/rfc9
008" quoteTitle="true" derivedAnchor="RFC9008">
<front>
<title>Using RPI Option Type, Routing Header for Source Routes, and
IPv6-in-IPv6 Encapsulation in the RPL Data Plane</title>
<author initials="M.I." surname="Robles" fullname="M.I. Robles">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Richardson" fullname="M. Richardson">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="April"/>
<abstract>
<t indent="0">This document looks at different data flows through
Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Powe
r and Lossy Networks) is used to establish routing. The document enumerates the
cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Rout
e Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data pla
ne. This analysis provides the basis upon which to design efficient compression
of these headers. This document updates RFC 6553 by adding a change to the RPI O
ption Type. Additionally, this document updates RFC 6550 by defining a flag in t
he DODAG Information Object (DIO) Configuration option to indicate this change a
nd updates RFC 8138 as well to consider the new Option Type when the RPL Option
is decompressed.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9008"/>
<seriesInfo name="DOI" value="10.17487/RFC9008"/>
</reference>
<reference anchor="RFC9010" target="https://www.rfc-editor.org/info/rfc9
010" quoteTitle="true" derivedAnchor="RFC9010">
<front>
<title>Routing for RPL (Routing Protocol for Low-Power and Lossy Net
works) Leaves</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Richardson" fullname="M. Richardson">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="April"/>
<abstract>
<t indent="0">This specification provides a mechanism for a host t
hat implements a routing-agnostic interface based on IPv6 over Low-Power Wireles
s Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability serv
ices across a network that leverages RFC 6550 for its routing operations. It upd
ates RFCs 6550, 6775, and 8505.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9010"/>
<seriesInfo name="DOI" value="10.17487/RFC9010"/>
</reference>
<reference anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9
031" quoteTitle="true" derivedAnchor="RFC9031">
<front>
<title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
<author initials="M" surname="Vučinić" fullname="Mališa Vučinić" rol
e="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Simon" fullname="Jonathan Simon">
<organization showOnFrontPage="true"/>
</author>
<author initials="K" surname="Pister" fullname="Kris Pister">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization showOnFrontPage="true"/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="9031"/>
<seriesInfo name="DOI" value="10.17487/RFC9031"/>
</reference>
<reference anchor="RFC9032" target="https://www.rfc-editor.org/info/rfc9
032" quoteTitle="true" derivedAnchor="RFC9032">
<front>
<title>Encapsulation of 6TiSCH Join and Enrollment Information Eleme
nts</title>
<author initials="D" surname="Dujovne" fullname="Diego Dujovne" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization showOnFrontPage="true"/>
</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/rfc9
033" quoteTitle="true" derivedAnchor="RFC9033">
<front>
<title>6TiSCH Minimal Scheduling Function (MSF)</title>
<author initials="T" surname="Chang" fullname="Tengfei Chang" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Vučinić" fullname="Mališa Vučinić">
<organization showOnFrontPage="true"/>
</author>
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosan
a">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Duquennoy" fullname="Simon Duquennoy">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Dujovne" fullname="Diego Dujovne">
<organization showOnFrontPage="true"/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="9033"/>
<seriesInfo name="DOI" value="10.17487/RFC9033"/>
</reference>
</references>
<references pn="section-7.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="AMI" target="https://www.energy.gov/sites/prod/files/
2016/12/f34/AMI%20Summary%20Report_09-26-16.pdf" quoteTitle="true" derivedAnchor
="AMI">
<front>
<title>Advanced Metering Infrastructure and Customer Systems</title>
<author>
<organization showOnFrontPage="true">U.S. Department of Energy</or
ganization>
</author>
<date year="2006"/>
</front>
</reference>
<reference anchor="ANIMA" target="https://datatracker.ietf.org/doc/chart
er-ietf-anima/" quoteTitle="true" derivedAnchor="ANIMA">
<front>
<title>Autonomic Networking Integrated Model and Approach (anima)</t
itle>
<author>
<organization showOnFrontPage="true">IETF</organization>
</author>
</front>
</reference>
<reference anchor="I-D.ietf-roll-aodv-rpl" quoteTitle="true" target="htt
ps://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-10" derivedAnchor="AODV-RPL">
<front>
<title>Supporting Asymmetric Links in Low Power Networks: AODV-RPL</
title>
<author fullname="Satish Anamalamudi">
<organization showOnFrontPage="true">SRM University-AP</organizati
on>
</author>
<author fullname="Mingui Zhang">
<organization showOnFrontPage="true">Huawei Technologies</organiza
tion>
</author>
<author fullname="Charles E. Perkins">
<organization showOnFrontPage="true">Lupin Lodge</organization>
</author>
<author fullname="S.V.R Anand">
<organization showOnFrontPage="true">Indian Institute of Science</
organization>
</author>
<author fullname="Bing Liu">
<organization showOnFrontPage="true">Huawei Technologies</organiza
tion>
</author>
<date month="April" day="4" year="2021"/>
<abstract>
<t indent="0"> Route discovery for symmetric and asymmetric Poin
t-to-Point (P2P)
traffic flows is a desirable feature in Low power and Lossy Networks
(LLNs). For that purpose, this document specifies a reactive P2P
route discovery mechanism for both hop-by-hop routing and source
routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
protocol (AODV-RPL). Paired Instances are used to construct
directional paths, in case some of the links between source and
target node are asymmetric.
</references> </t>
<references><name>Informative References</name> </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-aodv-rpl-10"/
>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
roll-aodv-rpl-10.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-manet-aodvv2" quoteTitle="true" target="http
s://tools.ietf.org/html/draft-ietf-manet-aodvv2-16" derivedAnchor="AODVv2">
<front>
<title>Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing</
title>
<author fullname="Charles E. Perkins">
</author>
<author fullname="Stan Ratliff">
</author>
<author fullname="John Dowdell">
</author>
<author fullname="Lotte Steenbrink">
</author>
<author fullname="Victoria Mercieca">
</author>
<date month="May" day="4" year="2016"/>
<abstract>
<t indent="0"> The Ad Hoc On-demand Distance Vector Version 2 (A
ODVv2) routing
protocol is intended for use by mobile routers in wireless, multihop
networks. AODVv2 determines unicast routes among AODVv2 routers
within the network in an on-demand fashion.
<!-- <?rfc include="reference.RFC.6620"?> FCFS SAVI: First-Come, First-Se </t>
rved Source Address Validation --> </abstract>
<!--?rfc include="reference.RFC.6655"?--> <!-- AES-CCM Cipher Suites for </front>
Transport Layer Security (TLS) --> <seriesInfo name="Internet-Draft" value="draft-ietf-manet-aodvv2-16"/>
<!--?rfc include="reference.RFC.5191"?--> <!-- Protocol for Carrying Authe <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
ntication for Network Access (PANA) --> manet-aodvv2-16.txt"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <refcontent>Work in Progress</refcontent>
ce.RFC.5340.xml'/> <!-- OSPF for IPv6 --> </reference>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <reference anchor="I-D.thubert-6lo-bier-dispatch" quoteTitle="true" targ
ce.RFC.6275.xml'/> <!-- Mobility Support in IPv6 --> et="https://tools.ietf.org/html/draft-thubert-6lo-bier-dispatch-06" derivedAncho
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen r="BITSTRINGS-6LORH">
ce.RFC.2474.xml'/> <!-- Differentiated Services Field --> <front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <title>A 6loRH for BitStrings</title>
ce.RFC.2545.xml'/> <!-- BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Rou <author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
ting --> e="editor">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <organization showOnFrontPage="true"/>
ce.RFC.3963.xml'/> <!-- Network Mobility (NEMO) --> </author>
<!-- <?rfc include="reference.RFC.3972"?> CGA --> <author initials="Z" surname="Brodard" fullname="Zacharie Brodard">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <organization showOnFrontPage="true"/>
ce.RFC.3209.xml'/> <!-- RSVP TE --> </author>
<!-- <?rfc include="reference.RFC.3971"?> SEcure Neighbor Discovery (SEND) <author initials="H" surname="Jiang" fullname="Hao Jiang">
--> <organization showOnFrontPage="true"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </author>
ce.RFC.4291.xml'/> <!-- IP Version 6 Addressing Architecture --> <author initials="G" surname="Texier" fullname="Geraldine Texier">
<!-- <?rfc include="reference.RFC.4429"?> IP Version 6 Optimistic DAD --> <organization showOnFrontPage="true"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </author>
ce.RFC.3444.xml'/> <!-- On the Difference between Information Models and Data Mo <date month="January" day="28" year="2019"/>
dels --> </front>
<!-- <?rfc include="reference.RFC.3610"?> Counter with CBC-MAC (CCM) --> <seriesInfo name="Internet-Draft" value="draft-thubert-6lo-bier-dispat
<!-- 6TiSCH --> ch-06"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <refcontent>Work in Progress</refcontent>
ce.RFC.4080.xml'/> <!-- Next Steps in Signaling (NSIS): Framework --> </reference>
<!-- <?rfc include="reference.RFC.4389"?> IP Version 6 ND Proxy --> <reference anchor="CCAMP" target="https://datatracker.ietf.org/doc/chart
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen er-ietf-ccamp/" quoteTitle="true" derivedAnchor="CCAMP">
ce.RFC.4919.xml'/> <!-- IPv6 over Low-Power Wireless Personal Area Networks --> <front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <title>Common Control and Measurement Plane (ccamp)</title>
ce.RFC.4903.xml'/> <!-- IPv6 Multi-Link Subnet Issues -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5974.xml'/> <!-- NSIS Signaling Layer Protocol (NSLP) for Quality-of-Serv
ice Signaling -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6347.xml'/> <!-- Datagram Transport Layer Security Version 1.2 -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6830.xml'/> <!-- The Locator/ID Separation Protocol (LISP) -->
<!--?rfc include="reference.RFC.6997"?--> <!-- Reactive Discovery of Poin
t-to-Point Routes in Low-Power and Lossy Networks -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7426.xml'/> <!-- Software-Defined Networking (SDN): Layers and Architectu
re Terminology -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6606.xml'/> <!-- Problem Statement and Requirements for 6LoWPAN Routing -
->
<!-- others -->
<!--?rfc include='reference.I-D.ietf-ipv6-Multi-Link-subnets'?-->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-roll-rpl-industrial-applicability.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-6tisch-dtsecurity-zerotouch-join.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-core-object-security.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-manet-aodvv2.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8578.xml'/> <!-- Deterministic Networking Use Cases -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-detnet-ip.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-anima-bootstrapping-keyinfra.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-roll-aodv-rpl.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-lwig-6lowpan-virtual-reassembly.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-roll-dao-projection.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.rahul-roll-mop-ext.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.selander-ace-cose-ecdhe.xml'/>
<!-- <?rfc include='reference.I-D.svshah-tsvwg-lln-diffserv-recommendation
s'?> -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.thubert-roll-bier.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.thubert-bier-replication-elimination.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.thubert-6lo-bier-dispatch.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.thubert-6man-unicast-lookup.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.pthubert-raw-problem-statement.xml'/>
<!--?rfc include='reference.I-D.bernardos-raw-use-cases'?-->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.tiloca-6tisch-robust-scheduling.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-ace-coap-est.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-anima-constrained-voucher.xml'/>
<reference anchor='IEEE802154'>
<front>
<title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access
Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks
</title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization showOnFrontPage="true">IETF</organization>
</author> </author>
<date/> </front>
</front> </reference>
</reference> <reference anchor="CCMstar" target="http://www.ieee802.org/15/pub/2004/1
5-04-0537-00-004b-formal-specification-ccm-star-mode-operation.doc" quoteTitle="
true" derivedAnchor="CCMstar">
<front>
<title>Formal Specification of the CCM* Mode of Operation</title>
<author fullname="Rene Struik">
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date month="September" year="2004"/>
</front>
</reference>
<reference anchor="I-D.ietf-anima-constrained-voucher" target="https://t
ools.ietf.org/html/draft-ietf-anima-constrained-voucher-10" quoteTitle="true" de
rivedAnchor="CONSTRAINED-VOUCHER">
<front>
<title>Constrained Voucher Artifacts for Bootstrapping Protocols</ti
tle>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="van der Stok" fullname="Peter van der
Stok">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Kampanakis" fullname="Panos Kampanakis
">
<organization showOnFrontPage="true"/>
</author>
<date month="February" day="21" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-
voucher-10"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-roll-dao-projection" quoteTitle="true" targe
t="https://tools.ietf.org/html/draft-ietf-roll-dao-projection-16" derivedAnchor=
"DAO-PROJECTION">
<front>
<title>Root initiated routing state in RPL</title>
<author fullname="Pascal Thubert">
<organization showOnFrontPage="true">Cisco Systems, Inc</organizat
ion>
</author>
<author fullname="Rahul Arvind Jadhav">
<organization showOnFrontPage="true">Huawei Tech</organization>
</author>
<author fullname="Matthew Gillmore">
<organization showOnFrontPage="true">Itron, Inc</organization>
</author>
<date month="January" day="15" year="2021"/>
<abstract>
<t indent="0"> This document extends RFC 6550 and RFC 6553 to en
able a RPL Root to
install and maintain Projected Routes within its DODAG, along a
selected set of nodes that may or may not include self, for a chosen
duration. This potentially enables routes that are more optimized or
resilient than those obtained with the classical distributed
operation of RPL, either in terms of the size of a Routing Header or
in terms of path length, which impacts both the latency and the
packet delivery ratio.
<reference anchor='CCMstar' target='www.ieee802.org/15/pub/2004/15-04-0537 </t>
-00-004b-formal-specification-ccm-star-mode-operation.doc'> </abstract>
<front> </front>
<title> <seriesInfo name="Internet-Draft" value="draft-ietf-roll-dao-projectio
Formal Specification of the CCM* Mode of Operation n-16"/>
</title> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
<author fullname='Rene Struik'> roll-dao-projection-16.txt"/>
<organization>IEEE standard for Information Technology</organizat <refcontent>Work in Progress</refcontent>
ion> </reference>
<reference anchor="I-D.selander-ace-cose-ecdhe" quoteTitle="true" target
="https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-14" derivedAnchor="E
DHOC">
<front>
<title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
<author fullname="Göran Selander">
<organization showOnFrontPage="true">Ericsson AB</organization>
</author> </author>
<date month='September' year='2004'/> <author fullname="John Mattsson">
</front> <organization showOnFrontPage="true">Ericsson AB</organization>
</reference>
<reference anchor='IEEE802154e'>
<front>
<title>IEEE standard for Information Technology, IEEE Std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks, June 2011 as amended by IEEE Std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer
</title>
<author>
<organization>IEEE standard for Information Technology</organizat
ion>
</author> </author>
<date month='April' year='2012'/> <author fullname="Francesca Palombini">
</front> <organization showOnFrontPage="true">Ericsson AB</organization>
</reference> </author>
<!--reference anchor="IEEE802.1TSNTG" target="http://www.ieee802.org/1/pag <date month="September" day="11" year="2019"/>
es/avbridges.html"> <abstract>
<front> <t indent="0"> This document specifies Ephemeral Diffie-Hellman
<title>IEEE 802.1 Time-Sensitive Networks Task Group</title> Over COSE (EDHOC), a
very compact, and lightweight authenticated Diffie-Hellman key
exchange with ephemeral keys. EDHOC provides mutual authentication,
perfect forward secrecy, and identity protection. EDHOC is intended
for usage in constrained scenarios and a main use case is to
establish an OSCORE security context. By reusing COSE for
cryptography, CBOR for encoding, and CoAP for transport, the
additional code footprint can be kept very low.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-selander-ace-cose-ecdhe
-14"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-selan
der-ace-cose-ecdhe-14.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-ace-coap-est" quoteTitle="true" target="http
s://tools.ietf.org/html/draft-ietf-ace-coap-est-18" derivedAnchor="EST-COAPS">
<front>
<title>EST over secure CoAP (EST-coaps)</title>
<author initials="P" surname="van der Stok" fullname="Peter van der
Stok">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Kampanakis" fullname="Panos Kampanakis
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Raza" fullname="Shahid Raza">
<organization showOnFrontPage="true"/>
</author>
<date month="January" day="6" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-coap-est-18"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="HART" target="https://fieldcommgroup.org/technologies
/hart" quoteTitle="true" derivedAnchor="HART">
<front>
<title>HART</title>
<author> <author>
<organization>IEEE Standards Association</organization> <organization showOnFrontPage="true">FieldComm Group</organization >
</author> </author>
<date day="08" month="March" year="2013" /> </front>
</front> </reference>
</reference--> <reference anchor="IEC62439" target="https://webstore.iec.ch/publication
<reference anchor='WirelessHART'> /24438" quoteTitle="true" derivedAnchor="IEC62439">
<front> <front>
<title>Industrial Communication Networks - Wireless Communication Ne <title>Industrial communication networks - High availability automat
twork and Communication Profiles - WirelessHART - IEC 62591</title> ion networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability
Seamless Redundancy (HSR)</title>
<author> <author>
<organization>www.hartcomm.org</organization> <organization showOnFrontPage="true">IEC</organization>
</author> </author>
<date year='2010'/> <date year="2016"/>
</front> </front>
</reference> <seriesInfo name="IEC" value="62439-3:2016"/>
<reference anchor='HART'> </reference>
<front> <reference anchor="IEEE802154" target="https://ieeexplore.ieee.org/docum
<title>Highway Addressable remote Transducer, a group of specificati ent/7460875" quoteTitle="true" derivedAnchor="IEEE802154">
ons for industrial process and control devices administered by the HART Foundati <front>
on</title> <title>IEEE Standard for Low-Rate Wireless Networks</title>
<author> <author>
<organization>www.hartcomm.org</organization> <organization showOnFrontPage="true">IEEE</organization>
</author> </author>
<date/> <date month="April" year="2016"/>
</front> </front>
</reference> <seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
<reference anchor='ISA100.11a' target='http://www.isa.org/Community/SP100W <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
irelessSystemsforAutomation'> </reference>
<front> <reference anchor="IEEE802154e" target="https://ieeexplore.ieee.org/docu
<title>Wireless Systems for Industrial Automation: Process Control a ment/6185525" quoteTitle="true" derivedAnchor="IEEE802154e">
nd Related Applications - ISA100.11a-2011 - IEC 62734</title> <front>
<title>IEEE Standard for Local and metropolitan area networks -- Par
t. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC su
blayer</title>
<author> <author>
<organization>ISA/ANSI</organization> <organization showOnFrontPage="true">IEEE</organization>
</author> </author>
<date year='2011'/> <date month="April" year="2012"/>
</front> </front>
</reference> <seriesInfo name="IEEE Standard" value="802.15.4e-2012"/>
<reference anchor='ISA100' target='https://www.isa.org/isa100/'> <seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6185525"/>
<front> </reference>
<reference anchor="ISA100" target="https://www.isa.org/isa100/" quoteTit
le="true" derivedAnchor="ISA100">
<front>
<title>ISA100, Wireless Systems for Automation</title> <title>ISA100, Wireless Systems for Automation</title>
<author> <author>
<organization>ISA/ANSI</organization> <organization showOnFrontPage="true">ISA/ANSI</organization>
</author> </author>
<date/> </front>
</front> </reference>
</reference> <reference anchor="ISA100.11a" target="https://webstore.iec.ch/publicati
<reference anchor='TEAS' target='https://dataTracker.ietf.org/doc/charter- on/65581" quoteTitle="true" derivedAnchor="ISA100.11a">
ietf-teas/'> <front>
<front> <title>Wireless Systems for Industrial Automation: Process Control a
<title>Traffic Engineering Architecture and Signaling</title> nd Related Applications - ISA100.11a-2011</title>
<author> <author>
<organization>IETF</organization> <organization showOnFrontPage="true">ISA/ANSI</organization>
</author> </author>
<date/> <date year="2011"/>
</front> </front>
</reference> <seriesInfo name="IEC" value="62734:2014"/>
<reference anchor='ANIMA' target='https://dataTracker.ietf.org/doc/charter </reference>
-ietf-anima/'> <reference anchor="I-D.thubert-6man-unicast-lookup" quoteTitle="true" ta
<front> rget="https://tools.ietf.org/html/draft-thubert-6man-unicast-lookup-00" derivedA
<title>Autonomic Networking Integrated Model and Approach</title> nchor="ND-UNICAST-LOOKUP">
<author> <front>
<organization>IETF</organization> <title>IPv6 Neighbor Discovery Unicast Lookup</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
e="editor">
<organization showOnFrontPage="true"/>
</author> </author>
<date/> <author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abe
</front> gnoli">
</reference> <organization showOnFrontPage="true"/>
<reference anchor='PCE' target='https://dataTracker.ietf.org/doc/charter-i
etf-pce/'>
<front>
<title>Path Computation Element</title>
<author>
<organization>IETF</organization>
</author> </author>
<date/> <date month="July" day="29" year="2019"/>
</front> </front>
</reference> <seriesInfo name="Internet-Draft" value="draft-thubert-6man-unicast-lo
<reference anchor='CCAMP' target='https://dataTracker.ietf.org/doc/charter okup-00"/>
-ietf-ccamp/'> <refcontent>Work in Progress</refcontent>
<front> </reference>
<title>Common Control and Measurement Plane</title> <reference anchor="PCE" target="https://datatracker.ietf.org/doc/charter
-ietf-pce/" quoteTitle="true" derivedAnchor="PCE">
<front>
<title>Path Computation Element (pce)</title>
<author> <author>
<organization>IETF</organization> <organization showOnFrontPage="true">IETF</organization>
</author> </author>
<date/> </front>
</front> </reference>
</reference> <reference anchor="I-D.pthubert-raw-architecture" quoteTitle="true" targ
et="https://tools.ietf.org/html/draft-pthubert-raw-architecture-05" derivedAncho
<reference anchor='AMI' target='https://www.energy.gov/sites/prod/files/20 r="RAW-ARCHITECTURE">
16/12/f34/AMI%20Summary%20Report_09-26-16.pdf'> <front>
<front> <title>Reliable and Available Wireless Problem Statement</title>
<title>Advanced Metering Infrastructure and Customer Systems </title <author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
> e="editor">
<author> <organization showOnFrontPage="true"/>
<organization>US Department of Energy</organization>
</author> </author>
<date year='2006'/> <author initials="G. Z." surname="Papadopoulos" fullname="Georgios P
</front> apadopoulos">
</reference> <organization showOnFrontPage="true"/>
</author>
<date month="November" day="15" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-pthubert-raw-architectu
re-05"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-raw-use-cases" quoteTitle="true" target="htt
ps://tools.ietf.org/html/draft-ietf-raw-use-cases-01" derivedAnchor="RAW-USE-CAS
ES">
<front>
<title>RAW use cases</title>
<author fullname="Georgios Z. Papadopoulos">
<organization showOnFrontPage="true">IMT Atlantique</organization>
</author>
<author fullname="Pascal Thubert">
<organization showOnFrontPage="true">Cisco</organization>
</author>
<author fullname="Fabrice Theoleyre">
<organization showOnFrontPage="true">CNRS</organization>
</author>
<author fullname="Carlos J. Bernardos">
<organization showOnFrontPage="true">UC3M</organization>
</author>
<date month="February" day="21" year="2021"/>
<abstract>
<t indent="0"> The wireless medium presents significant specific
challenges to
achieve properties similar to those of wired deterministic networks.
At the same time, a number of use cases cannot be solved with wires
and justify the extra effort of going wireless. This document
presents wireless use cases demanding reliable and available
behavior.
<reference anchor='S-ALOHA' target='https://dl.acm.org/citation.cfm?id=102 </t>
4920'> </abstract>
<front> </front>
<title>ALOHA Packet System With and Without Slots and Capture</title <seriesInfo name="Internet-Draft" value="draft-ietf-raw-use-cases-01"/
> >
<author surname='Roberts' fullname='Lawrence G. Roberts'> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
raw-use-cases-01.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2
474" quoteTitle="true" derivedAnchor="RFC2474">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers</title>
<author initials="K." surname="Nichols" fullname="K. Nichols">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Blake" fullname="S. Blake">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization showOnFrontPage="true"/>
</author>
<date year="1998" month="December"/>
<abstract>
<t indent="0">This document defines the IP header field, called th
e DS (for differentiated services) field. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2474"/>
<seriesInfo name="DOI" value="10.17487/RFC2474"/>
</reference>
<reference anchor="RFC2545" target="https://www.rfc-editor.org/info/rfc2
545" quoteTitle="true" derivedAnchor="RFC2545">
<front>
<title>Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain R
outing</title>
<author initials="P." surname="Marques" fullname="P. Marques">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Dupont" fullname="F. Dupont">
<organization showOnFrontPage="true"/>
</author>
<date year="1999" month="March"/>
<abstract>
<t indent="0">BGP-4 Multiprotocol Extensions (BGP-MP) defines the
format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be use
d to announce and withdraw the announcement of reachability information. This do
cument defines how compliant systems should make use of those attributes for the
purpose of conveying IPv6 routing information. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2545"/>
<seriesInfo name="DOI" value="10.17487/RFC2545"/>
</reference>
<reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3
209" quoteTitle="true" derivedAnchor="RFC3209">
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author initials="D." surname="Awduche" fullname="D. Awduche">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Gan" fullname="D. Gan">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="December"/>
<abstract>
<t indent="0">This document describes the use of RSVP (Resource Re
servation Protocol), including all the necessary extensions, to establish label-
switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow
along an LSP is completely identified by the label applied at the ingress node o
f the path, these paths may be treated as tunnels. A key application of LSP tun
nels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3209"/>
<seriesInfo name="DOI" value="10.17487/RFC3209"/>
</reference>
<reference anchor="RFC3444" target="https://www.rfc-editor.org/info/rfc3
444" quoteTitle="true" derivedAnchor="RFC3444">
<front>
<title>On the Difference between Information Models and Data Models<
/title>
<author initials="A." surname="Pras" fullname="A. Pras">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="January"/>
<abstract>
<t indent="0">There has been ongoing confusion about the differenc
es between Information Models and Data Models for defining managed objects in ne
twork management. This document explains the differences between these terms by
analyzing how existing network management model specifications (from the IETF a
nd other bodies such as the International Telecommunication Union (ITU) or the D
istributed Management Task Force (DMTF)) fit into the universe of Information Mo
dels and Data Models. This memo documents the main results of the 8th workshop o
f the Network Management Research Group (NMRG) of the Internet Research Task For
ce (IRTF) hosted by the University of Texas at Austin. This memo provides infor
mation for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3444"/>
<seriesInfo name="DOI" value="10.17487/RFC3444"/>
</reference>
<reference anchor="RFC3963" target="https://www.rfc-editor.org/info/rfc3
963" quoteTitle="true" derivedAnchor="RFC3963">
<front>
<title>Network Mobility (NEMO) Basic Support Protocol</title>
<author initials="V." surname="Devarapalli" fullname="V. Devarapalli
">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Wakikawa" fullname="R. Wakikawa">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Petrescu" fullname="A. Petrescu">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="January"/>
<abstract>
<t indent="0">This document describes the Network Mobility (NEMO)
Basic Support protocol that enables Mobile Networks to attach to different point
s in the Internet. The protocol is an extension of Mobile IPv6 and allows sessi
on continuity for every node in the Mobile Network as the network moves. It als
o allows every node in the Mobile Network to be reachable while moving around.
The Mobile Router, which connects the network to the Internet, runs the NEMO Bas
ic Support protocol with its Home Agent. The protocol is designed so that netwo
rk mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-T
RACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3963"/>
<seriesInfo name="DOI" value="10.17487/RFC3963"/>
</reference>
<reference anchor="RFC4080" target="https://www.rfc-editor.org/info/rfc4
080" quoteTitle="true" derivedAnchor="RFC4080">
<front>
<title>Next Steps in Signaling (NSIS): Framework</title>
<author initials="R." surname="Hancock" fullname="R. Hancock">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Karagiannis" fullname="G. Karagiannis
">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Loughney" fullname="J. Loughney">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Van den Bosch" fullname="S. Van den B
osch">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="June"/>
<abstract>
<t indent="0">The Next Steps in Signaling (NSIS) working group is
considering protocols for signaling information about a data flow along its path
in the network. The NSIS suite of protocols is envisioned to support various s
ignaling applications that need to install and/or manipulate such state in the n
etwork. Based on existing work on signaling requirements, this document propose
s an architectural framework for these signaling protocols.</t>
<t indent="0">This document provides a model for the network entit
ies that take part in such signaling, and for the relationship between signaling
and the rest of network operation. We decompose the overall signaling protocol
suite into a generic (lower) layer, with separate upper layers for each specifi
c signaling application. This memo provides information for the Internet commun
ity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4080"/>
<seriesInfo name="DOI" value="10.17487/RFC4080"/>
</reference>
<reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4
291" quoteTitle="true" derivedAnchor="RFC4291">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="February"/>
<abstract>
<t indent="0">This specification defines the addressing architectu
re of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressi
ng model, text representations of IPv6 addresses, definition of IPv6 unicast add
resses, anycast addresses, and multicast addresses, and an IPv6 node's required
addresses.</t>
<t indent="0">This document obsoletes RFC 3513, "IP Version 6 Addr
essing Architecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
<reference anchor="RFC4903" target="https://www.rfc-editor.org/info/rfc4
903" quoteTitle="true" derivedAnchor="RFC4903">
<front>
<title>Multi-Link Subnet Issues</title>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="June"/>
<abstract>
<t indent="0">There have been several proposals around the notion
that a subnet may span multiple links connected by routers. This memo documents
the issues and potential problems that have been raised with such an approach.
This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4903"/>
<seriesInfo name="DOI" value="10.17487/RFC4903"/>
</reference>
<reference anchor="RFC4919" target="https://www.rfc-editor.org/info/rfc4
919" quoteTitle="true" derivedAnchor="RFC4919">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs
): Overview, Assumptions, Problem Statement, and Goals</title>
<author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar
">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Montenegro" fullname="G. Montenegro">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Schumacher" fullname="C. Schumacher">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="August"/>
<abstract>
<t indent="0">This document describes the assumptions, problem sta
tement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of g
oals enumerated in this document form an initial set only. This memo provides i
nformation for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4919"/>
<seriesInfo name="DOI" value="10.17487/RFC4919"/>
</reference>
<reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5
340" quoteTitle="true" derivedAnchor="RFC5340">
<front>
<title>OSPF for IPv6</title>
<author initials="R." surname="Coltun" fullname="R. Coltun">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Ferguson" fullname="D. Ferguson">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Moy" fullname="J. Moy">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="July"/>
<abstract>
<t indent="0">This document describes the modifications to OSPF to
support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms
of OSPF (flooding, Designated Router (DR) election, area support, Short Path Fir
st (SPF) calculations, etc.) remain unchanged. However, some changes have been
necessary, either due to changes in protocol semantics between IPv4 and IPv6, or
simply to handle the increased address size of IPv6. These modifications will
necessitate incrementing the protocol version from version 2 to version 3. OSPF
for IPv6 is also referred to as OSPF version 3 (OSPFv3).</t>
<t indent="0">Changes between OSPF for IPv4, OSPF Version 2, and O
SPF for IPv6 as described herein include the following. Addressing semantics ha
ve been removed from OSPF packets and the basic Link State Advertisements (LSAs)
. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now ru
ns on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for
LSAs has been generalized. Authentication has been removed from the OSPF proto
col and instead relies on IPv6's Authentication Header and Encapsulating Securit
y Payload (ESP).</t>
<t indent="0">Even with larger IPv6 addresses, most packets in OSP
F for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and pac
ket- size limitations present in OSPF for IPv4 have been relaxed. In addition,
option handling has been made more flexible.</t>
<t indent="0">All of OSPF for IPv4's optional capabilities, includ
ing demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported i
n OSPF for IPv6. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5340"/>
<seriesInfo name="DOI" value="10.17487/RFC5340"/>
</reference>
<reference anchor="RFC5974" target="https://www.rfc-editor.org/info/rfc5
974" quoteTitle="true" derivedAnchor="RFC5974">
<front>
<title>NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service S
ignaling</title>
<author initials="J." surname="Manner" fullname="J. Manner">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Karagiannis" fullname="G. Karagiannis
">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="McDonald" fullname="A. McDonald">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="October"/>
<abstract>
<t indent="0">This specification describes the NSIS Signaling Laye
r Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Int
ernet. It is in accordance with the framework and requirements developed in NSIS
. Together with General Internet Signaling Transport (GIST), it provides functi
onality similar to RSVP and extends it. The QoS NSLP is independent of the unde
rlying QoS specification or architecture and provides support for different rese
rvation models. It is simplified by the elimination of support for multicast fl
ows. This specification explains the overall protocol approach, describes the d
esign decisions made, and provides examples. It specifies object, message forma
ts, and processing rules. This document defines an Experimental Protocol for t
he Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5974"/>
<seriesInfo name="DOI" value="10.17487/RFC5974"/>
</reference>
<reference anchor="RFC6275" target="https://www.rfc-editor.org/info/rfc6
275" quoteTitle="true" derivedAnchor="RFC6275">
<front>
<title>Mobility Support in IPv6</title>
<author initials="C." surname="Perkins" fullname="C. Perkins" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Johnson" fullname="D. Johnson">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Arkko" fullname="J. Arkko">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="July"/>
<abstract>
<t indent="0">This document specifies Mobile IPv6, a protocol that
allows nodes to remain reachable while moving around in the IPv6 Internet. Eac
h mobile node is always identified by its home address, regardless of its curren
t point of attachment to the Internet. While situated away from its home, a mob
ile node is also associated with a care-of address, which provides information a
bout the mobile node's current location. IPv6 packets addressed to a mobile nod
e's home address are transparently routed to its care-of address. The protocol
enables IPv6 nodes to cache the binding of a mobile node's home address with its
care-of address, and to then send any packets destined for the mobile node dire
ctly to it at this care-of address. To support this operation, Mobile IPv6 defi
nes a new IPv6 protocol and a new destination option. All IPv6 nodes, whether m
obile or stationary, can communicate with mobile nodes. This document obsoletes
RFC 3775. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6275"/>
<seriesInfo name="DOI" value="10.17487/RFC6275"/>
</reference>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
347" quoteTitle="true" derivedAnchor="RFC6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="January"/>
<abstract>
<t indent="0">This document specifies version 1.2 of the Datagram
Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
ions privacy for datagram protocols. The protocol allows client/server applicat
ions to communicate in a way that is designed to prevent eavesdropping, tamperin
g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
cs of the underlying transport are preserved by the DTLS protocol. This documen
t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
<reference anchor="RFC6606" target="https://www.rfc-editor.org/info/rfc6
606" quoteTitle="true" derivedAnchor="RFC6606">
<front>
<title>Problem Statement and Requirements for IPv6 over Low-Power Wi
reless Personal Area Network (6LoWPAN) Routing</title>
<author initials="E." surname="Kim" fullname="E. Kim">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Kaspar" fullname="D. Kaspar">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Gomez" fullname="C. Gomez">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="May"/>
<abstract>
<t indent="0">IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 stan
dard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specif
ication defines how mesh topologies could be obtained and maintained. Thus, it
should be considered how 6LoWPAN formation and multi-hop routing could be suppor
ted.</t>
<t indent="0">This document provides the problem statement and des
ign space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs
, considering the low-power and other particular characteristics of the devices
and links. The purpose of this document is not to recommend specific solutions
but to provide general, layer-agnostic guidelines about the design of 6LoWPAN ro
uting that can lead to further analysis and protocol design. This document is i
ntended as input to groups working on routing protocols relevant to 6LoWPANs, su
ch as the IETF ROLL WG. This document is not an Internet Standards Track specif
ication; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6606"/>
<seriesInfo name="DOI" value="10.17487/RFC6606"/>
</reference>
<reference anchor="RFC6830" target="https://www.rfc-editor.org/info/rfc6
830" quoteTitle="true" derivedAnchor="RFC6830">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<author initials="D." surname="Farinacci" fullname="D. Farinacci">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Fuller" fullname="V. Fuller">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Lewis" fullname="D. Lewis">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="January"/>
<abstract>
<t indent="0">This document describes a network-layer-based protoc
ol that enables separation of IP addresses into two new numbering spaces: Endpoi
nt Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to
either host protocol stacks or to the "core" of the Internet infrastructure. Th
e Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a
"flag day", and offers Traffic Engineering, multihoming, and mobility benefits
to early adopters, even when there are relatively few LISP-capable sites.</t>
<t indent="0">Design and development of LISP was largely motivated
by the problem statement produced by the October 2006 IAB Routing and Addressin
g Workshop. This document defines an Experimental Protocol for the Internet com
munity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6830"/>
<seriesInfo name="DOI" value="10.17487/RFC6830"/>
</reference>
<reference anchor="RFC7426" target="https://www.rfc-editor.org/info/rfc7
426" quoteTitle="true" derivedAnchor="RFC7426">
<front>
<title>Software-Defined Networking (SDN): Layers and Architecture Te
rminology</title>
<author initials="E." surname="Haleplidis" fullname="E. Haleplidis"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pentikousis" fullname="K. Pentikousis
" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Denazis" fullname="S. Denazis">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hadi Salim" fullname="J. Hadi Salim">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Koufopavlou" fullname="O. Koufopavlou
">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="January"/>
<abstract>
<t indent="0">Software-Defined Networking (SDN) refers to a new ap
proach for network programmability, that is, the capacity to initialize, control
, change, and manage network behavior dynamically via open interfaces. SDN emph
asizes the role of software in running networks through the introduction of an a
bstraction for the data forwarding plane and, by doing so, separates it from the
control plane. This separation allows faster innovation cycles at both planes
as experience has already shown. However, there is increasing confusion as to w
hat exactly SDN is, what the layer structure is in an SDN architecture, and how
layers interface with each other. This document, a product of the IRTF Software
-Defined Networking Research Group (SDNRG), addresses these questions and provid
es a concise reference for the SDN research community based on relevant peer-rev
iewed literature, the RFC series, and relevant documents by other standards orga
nizations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7426"/>
<seriesInfo name="DOI" value="10.17487/RFC7426"/>
</reference>
<reference anchor="RFC8578" target="https://www.rfc-editor.org/info/rfc8
578" quoteTitle="true" derivedAnchor="RFC8578">
<front>
<title>Deterministic Networking Use Cases</title>
<author initials="E." surname="Grossman" fullname="E. Grossman" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="May"/>
<abstract>
<t indent="0">This document presents use cases for diverse industr
ies that have in common a need for "deterministic flows". "Deterministic" in th
is context means that such flows provide guaranteed bandwidth, bounded latency,
and other properties germane to the transport of time-sensitive data. These use
cases differ notably in their network topologies and specific desired behavior,
providing as a group broad industry context for Deterministic Networking (DetNe
t). For each use case, this document will identify the use case, identify repre
sentative solutions used today, and describe potential improvements that DetNet
can enable.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8578"/>
<seriesInfo name="DOI" value="10.17487/RFC8578"/>
</reference>
<reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8
613" quoteTitle="true" derivedAnchor="RFC8613">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)
</title>
<author initials="G." surname="Selander" fullname="G. Selander">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Mattsson" fullname="J. Mattsson">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Palombini" fullname="F. Palombini">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Seitz" fullname="L. Seitz">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="July"/>
<abstract>
<t indent="0">This document defines Object Security for Constraine
d RESTful Environments (OSCORE), a method for application-layer protection of th
e Constrained Application Protocol (CoAP), using CBOR Object Signing and Encrypt
ion (COSE). OSCORE provides end-to-end protection between endpoints communicati
ng using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes an
d networks supporting a range of proxy operations, including translation between
different transport protocols.</t>
<t indent="0">Although an optional functionality of CoAP, OSCORE a
lters CoAP options processing and IANA registration. Therefore, this document u
pdates RFC 7252.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8613"/>
<seriesInfo name="DOI" value="10.17487/RFC8613"/>
</reference>
<reference anchor="RFC8939" target="https://www.rfc-editor.org/info/rfc8
939" quoteTitle="true" derivedAnchor="RFC8939">
<front>
<title>Deterministic Networking (DetNet) Data Plane: IP</title>
<author initials="B." surname="Varga" fullname="B. Varga" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Farkas" fullname="J. Farkas">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Fedyk" fullname="D. Fedyk">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Bryant" fullname="S. Bryant">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="November"/>
<abstract>
<t indent="0">This document specifies the Deterministic Networking
(DetNet) data plane operation for IP hosts and routers that provide DetNet serv
ice to IP-encapsulated data. No DetNet-specific encapsulation is defined to supp
ort IP flows; instead, the existing IP-layer and higher-layer protocol header in
formation is used to support flow identification and DetNet service delivery. T
his document builds on the DetNet architecture (RFC 8655) and data plane framewo
rk (RFC 8938).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8939"/>
<seriesInfo name="DOI" value="10.17487/RFC8939"/>
</reference>
<reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8
995" quoteTitle="true" derivedAnchor="RFC8995">
<front>
<title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title
>
<author initials="M." surname="Pritikin" fullname="M. Pritikin">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Richardson" fullname="M. Richardson">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Eckert" fullname="T. Eckert">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Behringer" fullname="M. Behringer">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="May"/>
<abstract>
<t indent="0">This document specifies automated bootstrapping of a
n Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrap
ped. This is done using manufacturer-installed X.509 certificates, in combinati
on with a manufacturer's authorizing service, both online and offline. We call
this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
. Bootstrapping a new device can occur when using a routable address and a cloud
service, only link-local connectivity, or limited/disconnected networks. Suppor
t for deployment models with less stringent security requirements is included. B
ootstrapping is complete when the cryptographic identity of the new key infrastr
ucture is successfully deployed to the device. The established secure connectio
n can be used to deploy a locally issued certificate to the device as well.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8995"/>
<seriesInfo name="DOI" value="10.17487/RFC8995"/>
</reference>
<reference anchor="RFC9035" target="https://www.rfc-editor.org/info/rfc9
035" quoteTitle="true" derivedAnchor="RFC9035">
<front>
<title>A Routing Protocol for Low-Power and Lossy Networks (RPL) Des
tination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6L
oWPAN Routing Header</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Zhao" fullname="L. Zhao">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="April"/>
<abstract>
<t indent="0">This document updates RFC 8138 by defining a bit in
the Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration option to indicate whether compres
sion is used within the RPL Instance and to specify the behavior of nodes compli
ant with RFC 8138 when the bit is set and unset.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9035"/>
<seriesInfo name="DOI" value="10.17487/RFC9035"/>
</reference>
<reference anchor="I-D.tiloca-6tisch-robust-scheduling" quoteTitle="true
" target="https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling-02"
derivedAnchor="ROBUST-SCHEDULING">
<front>
<title>Robust Scheduling against Selective Jamming in 6TiSCH Network
s</title>
<author fullname="Marco Tiloca">
<organization showOnFrontPage="true">RISE AB</organization>
</author>
<author fullname="Simon Duquennoy">
<organization showOnFrontPage="true">Yanzi Networks AB</organizati
on>
</author>
<author fullname="Gianluca Dini">
<organization showOnFrontPage="true">University of Pisa</organizat
ion>
</author>
<date month="June" day="10" year="2019"/>
<abstract>
<t indent="0"> This document defines a method to generate robust
TSCH schedules in a
6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4-2015) network, so as
to protect network nodes against selective jamming attack. Network
nodes independently compute the new schedule at each slotframe, by
altering the one originally available from 6top or alternative
protocols, while preserving a consistent and collision-free
communication pattern. This method can be added on top of the
minimal security framework for 6TiSCH.
<organization>ACM SIGCOMM Computer Communication Review</organiza </t>
tion> </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-tiloca-6tisch-robust-sc
heduling-02"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-tiloc
a-6tisch-robust-scheduling-02.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-roll-rpl-industrial-applicability" quoteTitl
e="true" target="https://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-appl
icability-02" derivedAnchor="RPL-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-industria
l-applicability-02"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.thubert-roll-bier" quoteTitle="true" target="http
s://tools.ietf.org/html/draft-thubert-roll-bier-02" derivedAnchor="RPL-BIER">
<front>
<title>RPL-BIER</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
e="editor">
<organization showOnFrontPage="true"/>
</author> </author>
<date month='April' year='1975'/> <date month="July" day="24" year="2018"/>
</front> </front>
<seriesInfo name='doi' value='10.1145/1024916.1024920'/> <seriesInfo name="Internet-Draft" value="draft-thubert-roll-bier-02"/>
</reference> <refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-roll-capabilities" quoteTitle="true" target=
"https://tools.ietf.org/html/draft-ietf-roll-capabilities-08" derivedAnchor="RPL
-MOP">
<front>
<title>RPL Capabilities</title>
<author initials="R" surname="Jadhav" fullname="Rahul Arvind Jadhav"
role="editor"> </author>
<author fullname="Pascal Thubert">
<organization showOnFrontPage="true">Cisco Systems, Inc</organizat
ion>
</author>
<author fullname="Michael Richardson">
<organization showOnFrontPage="true">Sandelman Software Works</org
anization>
</author>
<author initials="R" surname="Sahoo" fullname="Rabi Narayan Sahoo">
<organization showOnFrontPage="true">Juniper</organization>
</author>
<date month="March" day="17" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-capabilities-
08"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="S-ALOHA" target="https://dl.acm.org/citation.cfm?id=1
024920" quoteTitle="true" derivedAnchor="S-ALOHA">
<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="I-D.thubert-bier-replication-elimination" quoteTitle=
"true" target="https://tools.ietf.org/html/draft-thubert-bier-replication-elimin
ation-03" derivedAnchor="TE-PREF">
<front>
<title>BIER-TE extensions for Packet Replication and Elimination Fun
ction (PREF) and OAM</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
e="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z" surname="Brodard" fullname="Zacharie Brodard">
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Jiang" fullname="Hao Jiang">
<organization showOnFrontPage="true"/>
</author>
<date month="March" day="3" year="2018"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-thubert-bier-replicatio
n-elimination-03"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="TEAS" target="https://datatracker.ietf.org/doc/charte
r-ietf-teas/" quoteTitle="true" derivedAnchor="TEAS">
<front>
<title>Traffic Engineering Architecture and Signaling (teas)</title>
<author>
<organization showOnFrontPage="true">IETF</organization>
</author>
</front>
</reference>
<reference anchor="I-D.ietf-lwig-6lowpan-virtual-reassembly" quoteTitle=
"true" target="https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reass
embly-02" derivedAnchor="VIRTUAL-REASSEMBLY">
<front>
<title>Virtual reassembly buffers in 6LoWPAN</title>
<author fullname="Carsten Bormann">
<organization showOnFrontPage="true">Universitaet Bremen TZI</orga
nization>
</author>
<author fullname="Thomas Watteyne">
<organization showOnFrontPage="true">Analog Devices</organization>
</author>
<date month="March" day="9" year="2020"/>
<abstract>
<t indent="0"> When employing adaptation layer fragmentation in
6LoWPAN, it may be
beneficial for a forwarder not to have to reassemble each packet in
its entirety before forwarding it.
<reference anchor='IEC62439' target='https://webstore.iec.ch/publication/7 This has been always possible with the original fragmentation design
018'> of RFC 4944. Apart from a brief mention of the way to do this in
<front> Section 2.5.2 of the 6LoWPAN book, this has not been extensively
<title>Industrial communication networks - High availability automat described in the literature. The present document attempts to fill
ion networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability that gap.
Seamless Redundancy (HSR) - IEC62439-3</title>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lwig-6lowpan-virtu
al-reassembly-02"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
lwig-6lowpan-virtual-reassembly-02.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="WirelessHART" target="https://webstore.iec.ch/publica
tion/24433" quoteTitle="true" derivedAnchor="WirelessHART">
<front>
<title>Industrial networks - Wireless communication network and comm
unication profiles - WirelessHART(TM)</title>
<author> <author>
<organization>IEC</organization> <organization showOnFrontPage="true">International Electrotechnica l Commission</organization>
</author> </author>
<date year='2012'/> <date month="March" year="2016"/>
</front> </front>
</reference> <seriesInfo name="IEC" value="62591:2016"/>
</references> </reference>
<reference anchor="I-D.ietf-6tisch-dtsecurity-zerotouch-join" quoteTitle
="true" target="https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotou
ch-join-04" derivedAnchor="ZEROTOUCH-JOIN">
<front>
<title>6tisch Zero-Touch Secure Join protocol</title>
<author fullname="Michael Richardson">
<organization showOnFrontPage="true">Sandelman Software Works</org
anization>
</author>
<date month="July" day="8" year="2019"/>
<abstract>
<t indent="0"> This document describes a Zero-touch Secure Join
(ZSJ) mechanism to
enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network
using the 6tisch signaling mechanisms. The resulting device will
obtain a domain specific credential that can be used with either
802.15.9 per-host pair keying protocols, or to obtain the network-
wide key from a coordinator. The mechanism describe here is an
augmentation to the one-touch mechanism described in
[I-D.ietf-6tisch-minimal-security], and is a profile of the
constrained voucher mechanism [I-D.ietf-anima-constrained-voucher].
<section><name>Related Work In Progress</name> </t>
<t>This document has been incremented as the work progressed following the </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-dtsecurity-
zerotouch-join-04"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
6tisch-dtsecurity-zerotouch-join-04.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
</references>
</references>
<section numbered="true" removeInRFC="false" toc="include" pn="section-appen
dix.a">
<name slugifiedName="name-related-work-in-progress">Related Work in Progre
ss</name>
<t indent="0" pn="section-appendix.a-1">This document has been incremented
as the work progressed following the
evolution of the WG charter and the availability of dependent work. evolution of the WG charter and the availability of dependent work.
The intent was to publish when the WG concludes on the covered items. The intent was to publish when the WG concluded on the covered items.
At the time of publishing the following specification are still in progres At the time of publishing, the following specifications are still in progr
s ess
and may affect the evolution of the stack in a 6TiSCH-aware node. and may affect the evolution of the stack in a 6TiSCH-aware node.
</t> </t>
<section anchor="unchartered" numbered="true" removeInRFC="false" toc="inc
<!-- lude" pn="section-a.1">
<section anchor="chartered" title="Chartered IETF work items"> <name slugifiedName="name-unchartered-ietf-work-items">Unchartered IETF
Work Items</name>
<t> <section anchor="unchartered-sec" numbered="true" removeInRFC="false" to
The operation of the Backbone Router c="include" pn="section-a.1.1">
<xref target="I-D.ietf-6lo-backbone-router"/> is stable but the RFC <name slugifiedName="name-6tisch-zero-touch-security">6TiSCH Zero-Touc
is not published yet. The protection of registered addresses against h Security</name>
impersonation and take over will be guaranteed by <t indent="0" pn="section-a.1.1-1">
<xref target="I-D.ietf-6lo-ap-nd">Address The security model and in particular the zero-touch join process
Protected Neighbor Discovery for Low-power and Lossy Networks</xref>, <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" format="default"
which is not yet published either. sectionFormat="of" derivedContent="ZEROTOUCH-JOIN"/> depend on
the ANIMA (Autonomic Networking Integrated Model and Approach) <xref targe
</t> t="ANIMA" format="default" sectionFormat="of" derivedContent="ANIMA"/>
<t> "<xref target="RFC8995" format="title" sectionFormat="of" derivedContent="
New procedures have been defined at ROLL that extend RPL and may be of Bootstrapping Remote Secure Key Infrastructure (BRSKI)"/>" <xref target="RFC8995
interest for a 6TiSCH stack. " format="default" sectionFormat="of" derivedContent="RFC8995"/>
In particular <xref target="I-D.ietf-roll-unaware-leaves"/> enables a 6LN to enable zero-touch security provisioning; for highly
that implements only <xref target='RFC8505'/> and avoid the support of RPL
.
</t>
</section> Chartered IETF work items -->
<section anchor='unchartered'><name>Unchartered IETF work items</name>
<section anchor='unchartered-sec'><name>6TiSCH Zerotouch security</name>
<t>
The security model and 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>
to enable zero-touch security provisionning; for highly
constrained nodes, a minimal model based on pre-shared keys (PSK) constrained nodes, a minimal model based on pre-shared keys (PSK)
is also available. As written to this day, it also depends on is also available. As currently written, it also depends on
a number of documents in progress as CORE, and on a number of documents in progress in the CORE (Constrained RESTful Environ
<xref target='I-D.selander-ace-cose-ecdhe'>"Ephemeral Diffie-Hellman Over ments) WG and on
COSE (EDHOC)"</xref>, which is being considered for adoption at the LAKE <xref target="I-D.selander-ace-cose-ecdhe" format="default" sectionFormat=
WG. "of" derivedContent="EDHOC">"Ephemeral Diffie-Hellman Over
</t> COSE (EDHOC)"</xref>, which is being considered for adoption by the LAKE
(Lightweight Authenticated Key Exchange) WG.
</section> <!-- "6TiSCH Zerotouch security" --> </t>
</section>
<section anchor='unchartered-tracks'><name>6TiSCH Track Setup</name> <section anchor="unchartered-tracks" numbered="true" removeInRFC="false"
<t> toc="include" pn="section-a.1.2">
ROLL is now standardizing a reactive routing protocol based on RPL <name slugifiedName="name-6tisch-track-setup">6TiSCH Track Setup</name
<xref target='I-D.ietf-roll-aodv-rpl'/> >
The need of a reactive routing protocol to establish on-demand <t indent="0" pn="section-a.1.2-1">
ROLL (Routing Over Low power and Lossy networks) is now standardizing a re
active routing protocol based on RPL
<xref target="I-D.ietf-roll-aodv-rpl" format="default" sectionFormat="of"
derivedContent="AODV-RPL"/>.
The need of a reactive routing protocol to establish on-demand,
constraint-optimized routes and a reservation protocol to establish constraint-optimized routes and a reservation protocol to establish
Layer-3 Tracks is being discussed at 6TiSCH but not chartered for. Layer 3 Tracks is being discussed in 6TiSCH but not yet chartered.
</t><t>
<!-- </t>
At the time of this writing, the formation of a new working group called <t indent="0" pn="section-a.1.2-2">
RAW for Reliable and Available Wireless networking is being considered.
The work on centralized Track computation is deferred to a subsequent
work, not necessarily at 6TiSCH. A Predictable and Available Wireless
(PAW) bar-BoF took place.
RAW may form as a WG and develop a generic specification for Track
operations that would cover 6TiSCH requirements as expressed in this
architecture, more in <xref target='I-D.thubert-raw-technologies'/>
and <xref target='I-D.pthubert-raw-problem-statement'/>.
In a large LLN, it is not
feasible to update the routes from a central controller that resides far
over the constrained network at the speed at which the quality of the
wireless links varies.
RAW would focus on forwarding behaviors to react quickly and locally to
the changes in the wireless links.
-->
At the time of this writing, there is new work planned in the IETF to prov ide At the time of this writing, there is new work planned in the IETF to prov ide
limited deterministic networking capabilities for wireless networks with a limited deterministic networking capabilities for wireless networks with a
focus on forwarding behaviors to react quickly and locally to the changes focus on forwarding behaviors to react quickly and locally to the changes
as described in <xref target='I-D.pthubert-raw-problem-statement'/>. as described in <xref target="I-D.pthubert-raw-architecture" format="defau lt" sectionFormat="of" derivedContent="RAW-ARCHITECTURE"/>.
</t><t> </t>
ROLL is also standardizing an extension to RPL to setup centrally-computed <t indent="0" pn="section-a.1.2-3">
routes <xref target='I-D.ietf-roll-dao-projection'/> ROLL is also standardizing an extension to RPL to set up centrally compute
d
routes <xref target="I-D.ietf-roll-dao-projection" format="default" sectio
nFormat="of" derivedContent="DAO-PROJECTION"/>.
</t><t> </t>
The 6TiSCH Architecture should thus inherit from the <t indent="0" pn="section-a.1.2-4">
<xref target='RFC8655'>DetNet</xref> architecture and The 6TiSCH architecture should thus inherit from the
thus depends on it. The Path Computation Element (PCE) should be a <xref target="RFC8655" format="default" sectionFormat="of" derivedContent=
"RFC8655">DetNet architecture</xref> and
thus depends on it. The PCE should be a
core component of that architecture. core component of that architecture.
An extension to RPL or to TEAS <xref target='TEAS'/> will be required to An extension to RPL or to TEAS (Traffic Engineering Architecture and Signa ling) <xref target="TEAS" format="default" sectionFormat="of" derivedContent="TE AS"/> will be required to
expose the 6TiSCH node capabilities and the network peers to the PCE, expose the 6TiSCH node capabilities and the network peers to the PCE,
possibly in combination with <xref target='I-D.rahul-roll-mop-ext'/>. possibly in combination with <xref target="I-D.ietf-roll-capabilities" for
A protocol such as a lightweight PCEP or an adaptation of CCAMP mat="default" sectionFormat="of" derivedContent="RPL-MOP"/>.
<xref target='CCAMP'/> G-MPLS formats and procedures could be used in A protocol such as a lightweight Path Computation Element Communication Pr
combination to <xref target='I-D.ietf-roll-dao-projection'/> to install otocol (PCEP) or an adaptation of
Common Control and Measurement Plane (CCAMP)
<xref target="CCAMP" format="default" sectionFormat="of" derivedContent="C
CAMP"/> GMPLS formats and procedures could be used in
combination to <xref target="I-D.ietf-roll-dao-projection" format="default
" sectionFormat="of" derivedContent="DAO-PROJECTION"/> to install
the Tracks, as computed by the PCE, to the 6TiSCH nodes. the Tracks, as computed by the PCE, to the 6TiSCH nodes.
</t> </t>
</section>
</section><!-- 6TiSCH Track Setup --> <section anchor="unchartered-bier" numbered="true" removeInRFC="false" t
oc="include" pn="section-a.1.3">
<section anchor='unchartered-bier'><name>Using BIER in a 6TiSCH Network</n <name slugifiedName="name-using-bier-in-a-6tisch-netw">Using BIER in a
ame> 6TiSCH Network</name>
<t indent="0" pn="section-a.1.3-1"> ROLL is actively working on Bit In
<t> ROLL is actively working on Bit Index dex
Explicit Replication (BIER) as a method to compress both the Explicit Replication (BIER) as a method to compress both the
dataplane packets and the routing tables in storing mode data-plane packets and the routing tables in storing mode
<xref target='I-D.thubert-roll-bier'/>. <xref target="I-D.thubert-roll-bier" format="default" sectionFormat="of" der
</t> ivedContent="RPL-BIER"/>.
<t> </t>
<t indent="0" pn="section-a.1.3-2">
BIER could also be used in the context of the DetNet service layer. BIER could also be used in the context of the DetNet service layer.
<xref target='I-D.thubert-bier-replication-elimination'> <xref target="I-D.thubert-bier-replication-elimination" format="default" sec
BIER-TE-based OAM, Replication and Elimination </xref> leverages BIER tionFormat="of" derivedContent="TE-PREF">
Traffic Engineering (TE) to control in the data plane the "BIER-TE extensions for Packet Replication and Elimination Function
DetNet Replication and Elimination activities, and to provide traceability (PREF) and OAM"</xref> leverages BIER
Traffic Engineering (TE) to control the
DetNet Replication and Elimination activities in the data plane, and to prov
ide traceability
on links where replication and loss happen, in a manner that is abstract to on links where replication and loss happen, in a manner that is abstract to
the forwarding information. the forwarding information.
</t> </t>
<t> <t indent="0" pn="section-a.1.3-3">
<xref target='I-D.thubert-6lo-bier-dispatch'>a 6loRH for BitStrings</xref> <xref target="I-D.thubert-6lo-bier-dispatch" format="default" sectionFormat=
proposes a 6LoWPAN compression for the BIER Bitstring based on "of" derivedContent="BITSTRINGS-6LORH">"A 6loRH for BitStrings"</xref>
<xref target='RFC8138'>6LoWPAN Routing Header</xref>. proposes a 6LoWPAN compression for the BIER BitString based on
</t> <xref target="RFC8138" format="default" sectionFormat="of" derivedContent="R
FC8138">6LoWPAN Routing Header</xref>.
</section> <!-- 6TiSCH Track Setup --> </t>
</section>
</section><!-- Unchartered IETF work items --> </section>
<section anchor="external" numbered="true" removeInRFC="false" toc="includ
<section anchor='external'><name>External (non-IETF) work items</name> e" pn="section-a.2">
<name slugifiedName="name-external-non-ietf-work-item">External (Non-IET
<t> F) Work Items</name>
The current charter positions 6TiSCH on IEEE Std. 802.15.4 only. <t indent="0" pn="section-a.2-1">
Though most of the design should be portable on other link types, The current charter positions 6TiSCH on IEEE Std 802.15.4 only.
6TiSCH has a strong dependency on IEEE Std. 802.15.4 and its evolution. Though most of the design should be portable to other link types,
The impact of changes to TSCH on this Architecture should be minimal to 6TiSCH has a strong dependency on IEEE Std 802.15.4 and its evolution.
non-existent, but deeper work such as 6top and security may be impacted. The impact of changes to TSCH on this architecture should be minimal to
nonexistent, but deeper work such as 6top and security may be impacted.
A 6TiSCH Interest Group at the IEEE maintains the synchronization A 6TiSCH Interest Group at the IEEE maintains the synchronization
and helps foster work at the IEEE should 6TiSCH demand it. and helps foster work at the IEEE should 6TiSCH demand it.
</t> </t>
<t> <t indent="0" pn="section-a.2-2">
Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would
logically include the 6top sublayer. The interaction with the 6top sublaye r logically include the 6top sublayer. The interaction with the 6top sublaye r
and the Scheduling Functions described in this document are yet to be and the Scheduling Functions described in this document are yet to be
defined. defined.
</t> </t>
<t> <t indent="0" pn="section-a.2-3">
ISA100 <xref target='ISA100'/> Common Network Management (CNM) is another ISA100 <xref target="ISA100" format="default" sectionFormat="of" derivedCo
ntent="ISA100"/> Common Network Management (CNM) is another
external work of interest for 6TiSCH. The group, referred to as ISA100.20, external work of interest for 6TiSCH. The group, referred to as ISA100.20,
defines a Common Network Management framework that should enable the defines a Common Network Management framework that should enable the
management of resources that are controlled by heterogeneous protocols management of resources that are controlled by heterogeneous protocols
such as ISA100.11a <xref target='ISA100.11a'/>, WirelessHART such as ISA100.11a <xref target="ISA100.11a" format="default" sectionForma
<xref target='WirelessHART'/>, and 6TiSCH. Interestingly, the t="of" derivedContent="ISA100.11a"/>, WirelessHART
establishment of 6TiSCH Deterministic paths, called Tracks, <xref target="WirelessHART" format="default" sectionFormat="of" derivedCon
tent="WirelessHART"/>, and 6TiSCH. Interestingly, the
establishment of 6TiSCH deterministic paths, called Tracks,
are also in scope, and ISA100.20 is working on requirements for DetNet. are also in scope, and ISA100.20 is working on requirements for DetNet.
</t>
</section>
</section>
<section numbered="false" removeInRFC="false" toc="include" pn="section-appe
ndix.b">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<section numbered="false" toc="exclude" removeInRFC="false" pn="section-b.
1">
<name slugifiedName="name-special-thanks">Special Thanks</name>
<t indent="0" pn="section-b.1-1">
Special thanks to <contact fullname="Jonathan Simon"/>,
<contact fullname="Giuseppe Piro"/>, <contact fullname="Subir Das"/>, and
<contact fullname="Yoshihiro Ohba"/> for their deep contributions to the i
nitial security
work, to <contact fullname="Yasuyuki Tanaka"/> for his work on implementat
ion and simulation
that tremendously helped build a robust system, to <contact fullname="Dieg
o Dujovne"/> for
starting and leading the SF0 effort, and to <contact fullname="Tengfei Cha
ng"/> for evolving it
in the MSF.
</t>
<t indent="0" pn="section-b.1-2">
Special thanks also to <contact fullname="Pat Kinney"/>,
<contact fullname="Charlie Perkins"/>, and <contact fullname="Bob Heile"/>
for their
support in maintaining the connection active and the design in line with
work happening at IEEE 802.15.
</t>
<t indent="0" pn="section-b.1-3">
Special thanks to <contact fullname="Ted Lemon"/>, who was the INT Area Di
rector while this
document was initiated, for his great support and help throughout,
and to <contact fullname="Suresh Krishnan"/>, who took over with that kind
efficiency of his till
publication.
</t>
<t indent="0" pn="section-b.1-4">
Also special thanks to <contact fullname="Ralph Droms"/>, who performed th
e first INT Area
Directorate review, which was very deep and thorough and radically changed
the orientations of this document, and then to <contact fullname="Eliot Le
ar"/>
and <contact fullname="Carlos Pignataro"/>, who helped finalize this
document in preparation for the IESG reviews,
and to <contact fullname="Gorry Fairhurst"/>,
<contact fullname="David Mandelberg"/>, <contact fullname="Qin Wu"/>,
<contact fullname="Francis Dupont"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Mirja Kühlewind"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Benjamin Kaduk"/>, and <contact fullname="Andrew Malis"/>,
who contributed to the final shaping of this document
through the IESG review procedure.
</t>
</section>
<section numbered="false" toc="exclude" removeInRFC="false" pn="section-b.
2">
<name slugifiedName="name-and-do-not-forget">And Do Not Forget</name>
<t indent="0" pn="section-b.2-1">This document is the result of multiple
interactions, in
particular during the 6TiSCH (bi)Weekly Interim call, relayed through
the 6TiSCH mailing list at the IETF, over the course of more than 5 years.
</t>
<t indent="0" pn="section-b.2-2">
The authors wish to thank in arbitrary order:
<contact fullname="Alaeddine Weslati"/>, <contact fullname="Chonggang Wang"/>,
<contact fullname="Georgios Exarchakos"/>, <contact fullname="Zhuo Chen"/>,
<contact fullname="Georgios Papadopoulos"/>, <contact fullname="Eric Levy-Abegno
li"/>,
<contact fullname="Alfredo Grieco"/>, <contact fullname="Bert Greevenbosch"/>,
<contact fullname="Cedric Adjih"/>, <contact fullname="Deji Chen"/>,
<contact fullname="Martin Turon"/>, <contact fullname="Dominique Barthel"/>,
<contact fullname="Elvis Vogli"/>, <contact fullname="Geraldine Texier"/>,
<contact fullname="Guillaume Gaillard"/>, <contact fullname="Herman Storey"/>,
<contact fullname="Kazushi Muraoka"/>, <contact fullname="Ken Bannister"/>,
<contact fullname="Kuor Hsin Chang"/>, <contact fullname="Laurent Toutain"/>,
<contact fullname="Maik Seewald"/>, <contact fullname="Michael Behringer"/>,
<contact fullname="Nancy Cam Winget"/>, <contact fullname="Nicola Accettura"/>,
<contact fullname="Nicolas Montavont"/>, <contact fullname="Oleg Hahm"/>,
<contact fullname="Patrick Wetterwald"/>, <contact fullname="Paul Duffy"/>,
<contact fullname="Peter van der Stok"/>, <contact fullname="Rahul Sen"/>,
<contact fullname="Pieter de Mil"/>, <contact fullname="Pouria Zand"/>,
<contact fullname="Rouhollah Nabati"/>, <contact fullname="Rafa Marin-Lopez"/>,
<contact fullname="Raghuram Sudhaakar"/>, <contact fullname="Sedat Gormus"/>,
<contact fullname="Shitanshu Shah"/>, <contact fullname="Steve Simlo"/>,
<contact fullname="Tina Tsou"/>, <contact fullname="Tom Phinney"/>,
<contact fullname="Xavier Lagrange"/>, <contact fullname="Ines Robles"/>, and
<contact fullname="Samita Chakrabarti"/> for their participation and various con
tributions.
</t>
</section>
</section>
<section numbered="false" removeInRFC="false" toc="include" pn="section-appe
ndix.c">
<name slugifiedName="name-contributors">Contributors</name>
<t indent="0" pn="section-appendix.c-1">The co-authors of this document ar
e listed below:
</t> </t>
<ul empty="true" spacing="normal" bare="false" indent="3" pn="section-appe
</section><!-- External IETF work items --> ndix.c-2">
<li pn="section-appendix.c-2.1">
</section><!--title="Dependencies on Work In Progress"--> <t indent="0" pn="section-appendix.c-2.1.1"><contact fullname="Thomas
Watteyne"/>
</back> for his contributions to the whole design, in particular on TSCH and s
ecurity,
and to the open source community that he created with openWSN;</t>
</li>
<li pn="section-appendix.c-2.2">
<t indent="0" pn="section-appendix.c-2.2.1"><contact fullname="Xavier
Vilajosana"/>,
who led the design of the minimal support with RPL and contributed
deeply to the 6top design and the GMPLS operation of Track switching;<
/t>
</li>
<li pn="section-appendix.c-2.3">
<t indent="0" pn="section-appendix.c-2.3.1"><contact fullname="Kris Pi
ster"/>
for creating TSCH and his continuing guidance through the elaboration
of this design;</t>
</li>
<li pn="section-appendix.c-2.4">
<t indent="0" pn="section-appendix.c-2.4.1"><contact fullname="Mališa
Vučinić"/>
for the work on the one-touch join process and his contribution to the
Security Design Team;</t>
</li>
<li pn="section-appendix.c-2.5">
<t indent="0" pn="section-appendix.c-2.5.1"><contact fullname="Michael
Richardson"/>
for his leadership role in the Security Design Team and his
contribution throughout this document;</t>
</li>
<li pn="section-appendix.c-2.6">
<t indent="0" pn="section-appendix.c-2.6.1"><contact fullname="Tero Ki
vinen"/>
for his contribution to the security work in general and the security
section in particular;</t>
</li>
<li pn="section-appendix.c-2.7">
<t indent="0" pn="section-appendix.c-2.7.1"><contact fullname="Maria R
ita Palattella"/>
for managing the Terminology document that was merged into this documen
t through the work of 6TiSCH;</t>
</li>
<li pn="section-appendix.c-2.8">
<t indent="0" pn="section-appendix.c-2.8.1"><contact fullname="Simon D
uquennoy"/>
for his contribution to the open source community with the 6TiSCH
implementation of contiki, and for his contribution to MSF and
autonomous unicast cells;</t>
</li>
<li pn="section-appendix.c-2.9">
<t indent="0" pn="section-appendix.c-2.9.1"><contact fullname="Qin Wan
g"/>,
who led the design of the 6top sublayer and contributed related text
that was moved and/or adapted into this document;</t>
</li>
<li pn="section-appendix.c-2.10">
<t indent="0" pn="section-appendix.c-2.10.1"><contact fullname="Rene S
truik"/>
for the security section and his contribution to the Security Design
Team;</t>
</li>
<li pn="section-appendix.c-2.11">
<t indent="0" pn="section-appendix.c-2.11.1"><contact fullname="Robert
Assimiti"/>
for his breakthrough work on RPL over TSCH and initial text and
guidance.</t>
</li>
</ul>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.d">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edi
tor">
<organization abbrev="Cisco Systems" showOnFrontPage="true">Cisco System
s, Inc</organization>
<address>
<postal>
<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>
</section>
</back>
</rfc> </rfc>
 End of changes. 573 change blocks. 
2848 lines changed or deleted 5361 lines changed or added

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