<?xml version='1.0' encoding='utf-8'?><!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="no"?> <?rfc subcompact="no"?> <?rfc authorship="yes"?> <?rfc tocappendix="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info"ipr='trust200902' tocInclude="true" obsoletes="" updates=""consensus="true"submissionType="IETF" xml:lang="en" version="3"docName="draft-ietf-6tisch-architecture-30">indexInclude="true" ipr="trust200902" number="9030" prepTime="2021-05-29T09:04:29" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture-30" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc9030" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <titleabbrev='6tisch-architecture'>Anabbrev="6TiSCH Architecture">An Architecture for IPv6 over theTSCH modeTime-Slotted Channel Hopping Mode of IEEE802.15.4</title>802.15.4 (6TiSCH)</title> <seriesInfo name="RFC" value="9030" stream="IETF"/> <authorinitials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor"> <organizationabbrev='Cisco Systems'>Ciscoabbrev="Cisco Systems" showOnFrontPage="true">Cisco Systems, Inc</organization> <address> <postal><street>Building D</street><extaddr>Building D</extaddr> <street>45 Allee des Ormes -BP1200 </street>BP1200</street> <city>Mougins - Sophia Antipolis</city> <code>06254</code> <country>France</country> </postal> <phone>+33 497 23 26 34</phone> <email>pthubert@cisco.com</email> </address> </author><date/><date month="05" year="2021"/> <area>Internet Area</area> <workgroup>6TiSCH</workgroup><keyword>Draft</keyword> <abstract> <t><keyword>deterministic wireless</keyword> <keyword>radio</keyword> <keyword>mesh</keyword> <abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1"> This document describes a network architecture that provides low-latency,low-jitterlow-jitter, and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements ofLowPowerlow-power wireless deterministic applications.<!--</t> </abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This documentpresents the 6TiSCH architecture ofis not anIPv6 Multi-Link subnet thatInternet Standards Track specification; it is published for informational purposes. </t> <t indent="0" pn="section-boilerplate.1-2"> This document iscomposed of a high-speed powered backbone andanumberproduct ofIEEE Std. 802.15.4 TSCH low-power wireless networks attachedthe Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review andsynchronizedhas been approved for publication byBackbone 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 overthebackbone on behalfInternet 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 thewireless devices, so they can share a same subnetcurrent status of this document, any errata, andappearhow to provide feedback on it may beconnected toobtained at <eref target="https://www.rfc-editor.org/info/rfc9030" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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 thesame backbonepersons identified asclassical devices. -->the document authors. All rights reserved. </t></abstract> <!--note title="Requirements Language"> <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",<t indent="0" pn="section-boilerplate.2-2"> This document is subject to BCP 78 and"OPTIONAL"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 thisdocument aredocument. Please review these documents carefully, as they describe your rights and restrictions with respect tobe interpretedthis document. Code Components extracted from this document must include Simplified BSD License text as described in<xref target="RFC2119">RFC 2119</xref>. </t> </note--> </front> <middle> <section><name>Introduction</name> <t> Wireless Networks enable a wide variety of devicesSection 4.e ofany size to get interconnected, often at a very low marginal cost per device, at any range,the Trust Legal Provisions and are provided without warranty as described incircumstances where wiring may be impractical, for instance on fast-moving orthe Simplified BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="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" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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-new-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-abbreviations">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 derivedContent="" format="title" sectionFormat="of" target="name-related-documents">Related 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" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-high-level-architecture">High-Level Architecture</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-a-multi-link-subnet-model">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 derivedContent="" format="title" sectionFormat="of" target="name-tsch-a-deterministic-mac-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 derivedContent="" format="title" sectionFormat="of" target="name-scheduling-tsch">Scheduling 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 derivedContent="" format="title" sectionFormat="of" target="name-distributed-vs-centralized-">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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-6tisch-stack">6TiSCH Stack</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 derivedContent="" format="title" sectionFormat="of" target="name-communication-paradigms-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" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-architecture-components">Architecture Components</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-6lowpan-and-rpl">6LoWPAN (and RPL)</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rpl-unaware-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 derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-6lbr-and-rpl-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 derivedContent="" format="title" sectionFormat="of" target="name-network-access-and-addressi">Network Access and Addressing</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-join-process">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 derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-registration">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 derivedContent="" format="title" sectionFormat="of" target="name-tsch-and-6top">TSCH and 6top</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="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 derivedContent="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 derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-6top-and-rpl-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 derivedContent="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-network-synchronization">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 derivedContent="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 derivedContent="4.3.6" format="counter" sectionFormat="of" target="section-4.3.6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-distributing-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 derivedContent="" format="title" sectionFormat="of" target="name-schedule-management-mechani">Schedule Management Mechanisms</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-static-scheduling">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 derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-neighbor-to-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 derivedContent="4.4.3" format="counter" sectionFormat="of" target="section-4.4.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-remote-monitoring-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 derivedContent="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 derivedContent="" format="title" sectionFormat="of" target="name-on-tracks">On Tracks</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-general-behavior-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 derivedContent="4.5.2" format="counter" sectionFormat="of" target="section-4.5.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-serial-track">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 derivedContent="4.5.3" format="counter" sectionFormat="of" target="section-4.5.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-complex-track-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 derivedContent="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 derivedContent="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 derivedContent="" format="title" sectionFormat="of" target="name-forwarding-models">Forwarding Models</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="4.6.1" format="counter" sectionFormat="of" target="section-4.6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-track-forwarding">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 derivedContent="4.6.2" format="counter" sectionFormat="of" target="section-4.6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ipv6-forwarding">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 derivedContent="4.6.3" format="counter" sectionFormat="of" target="section-4.6.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-fragment-forwarding">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 derivedContent="" format="title" sectionFormat="of" target="name-advanced-6tisch-routing">Advanced 6TiSCH Routing</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="4.7.1" format="counter" sectionFormat="of" target="section-4.7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-marking-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 derivedContent="4.7.2" format="counter" sectionFormat="of" target="section-4.7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-replication-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" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.6"> <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-selective-jamming">Selective 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 derivedContent="" format="title" sectionFormat="of" target="name-mac-layer-security">MAC-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-validating-asn">Validating 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 derivedContent="" format="title" sectionFormat="of" target="name-network-keying-and-rekeying">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" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" 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="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>. <xref derivedContent="" 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="section-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 derivedContent="" 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="section-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 derivedContent="A.1.1" format="counter" sectionFormat="of" target="section-a.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-6tisch-zero-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 derivedContent="A.1.2" format="counter" sectionFormat="of" target="section-a.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-6tisch-track-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 derivedContent="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 derivedContent="" 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="" format="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="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t> </li> <li pn="section-toc.1-1.11"> <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</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, at any range, and in circumstances where wiring may be impractical, for instance, on fast-moving or rotating devices. </t><t><t indent="0" pn="section-1-2"> On the other hand, Deterministic Networking maximizes the packet delivery ratio within a bounded latency so as to enable mission-critical machine-to-machine (M2M) operations.<!-- At IEEE Std. 802.1, theApplications that need such networks are presented in <xreftarget="IEEE Std. 802.1TSNTG">Time Sensitive Networking</xref>(TSN) task group was formed to provide deterministic properties at Layer-2 across multiple hops. --> Applications that need such networks are presented in <xref target='RFC8578'/>. <!--andtarget="RFC8578" format="default" sectionFormat="of" derivedContent="RFC8578"/> and <xreftarget="I-D.bernardos-raw-use-cases"/>,target="I-D.ietf-raw-use-cases" format="default" sectionFormat="of" derivedContent="RAW-USE-CASES"/>, which presents a number of additional use cases for Reliable and Available Wirelessnetworks. -->networks (RAW). The considered applications includeProfessional Media,professional media, Industrial Automation and Control Systems (IACS), building automation, in-vehicle command and control, commercial automation and asset tracking with mobile scenarios, as well as gaming, drones and edge robotic control, and home automation applications. </t><t><t indent="0" pn="section-1-3"> TheTimeslottedTime-Slotted Channel Hopping (TSCH) <xreftarget='RFC7554'/>target="RFC7554" format="default" sectionFormat="of" derivedContent="RFC7554"/> mode of the IEEEStd.Std 802.15.4 <xreftarget='IEEE802154'/>target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"/> Medium Access Control (MAC) was introduced with the IEEEStd.Std 802.15.4e <xreftarget='IEEE802154e'/>target="IEEE802154e" format="default" sectionFormat="of" derivedContent="IEEE802154e"/> amendment and is now retrofitted in the main standard. For all practical purposes, this document is expected to be insensitive to the revisions of that standard, which is thus referenced without a date. TSCH is both a Time-Division Multiplexing (TDM) and a Frequency-Division Multiplexingtechnique(FDM) technique, whereby a different channel can be used for eachtransmission, and thattransmission. TSCH allowsto schedulethe scheduling of transmissions for deterministicoperations,operations and applies to the slower and mostenergy constrainedenergy-constrained wireless use cases. </t><t><t indent="0" pn="section-1-4"> The scheduled operation provides for a more reliableexperienceexperience, which can be used to monitor and manage resources, e.g., energy and water, in a more efficient fashion. </t><t><t indent="0" pn="section-1-5"> ProvenDeterministic Networkingdeterministic networking standards for use inProcess Control,process control, including ISA100.11a <xreftarget='ISA100.11a'/>target="ISA100.11a" format="default" sectionFormat="of" derivedContent="ISA100.11a"/> and WirelessHART <xreftarget='WirelessHART'/>,target="WirelessHART" format="default" sectionFormat="of" derivedContent="WirelessHART"/>, have demonstrated the capabilities of the IEEEStd.Std 802.15.4 TSCH MAC for high reliability against interference, low-power consumption on well-known flows, and its applicability for Traffic Engineering (TE) from a central controller. </t><t>To<t indent="0" pn="section-1-6">To enable the convergence ofInformation Technologyinformation technology (IT) andOperational Technologyoperational technology (OT) in Low-Power and Lossy Networks (LLNs), the 6TiSCHArchitecturearchitecture supports an IETF suite of protocols over the IEEEStd.Std 802.15.4 TSCH MAC to provide IP connectivity for energy and otherwise constrained wireless devices. </t><t><t indent="0" pn="section-1-7"> The 6TiSCHArchitecturearchitecture relies on IPv6 <xreftarget='RFC8200'/>target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> and the use of routing to provide large scaling capabilities. The addition of a high-speed federating backbone adds yet another degree of scalability to the design. The backbone is typically aLayer-2Layer 2 transitLinklink such as an Ethernet bridged network, but it can also be a more complex routed structure. </t><t><t indent="0" pn="section-1-8"> The 6TiSCHArchitecturearchitecture introduces an IPv6Multi-Linkmulti-link subnet model that is composed of a federating backbone and a number of IEEEStd.Std 802.15.4 TSCH low-power wireless networks federated and synchronized by Backbone Routers. If the backbone is aLayer-2Layer 2 transitLinklink, then the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6 ND) proxy <xreftarget='RFC4861'/> proxy.target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/>. </t><t><t indent="0" pn="section-1-9"> The 6TiSCHArchitecturearchitecture leverages 6LoWPAN <xreftarget='RFC4944'/>target="RFC4944" format="default" sectionFormat="of" derivedContent="RFC4944"/> to adapt IPv6 to the constrained media andRPLthe Routing Protocol for Low-Power and Lossy Networks (RPL) <xreftarget='RFC6550'/>target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> for the distributed routing operations. </t><t><t indent="0" pn="section-1-10"> Centralized routing refers to a model where routes are computed and resources are allocated from a central controller. This is particularly helpful to schedule deterministic multihop transmissions. In contrast,Distributed Routingdistributed routing refers to a model that relies on concurrentpeer to peerpeer-to-peer protocol exchanges for TSCH resource allocation and routing operations. </t><t><t indent="0" pn="section-1-11"> The architecture defines mechanisms to establish and maintain routing and scheduling in a centralized, distributed, or mixed fashion, for use in multiple OT environments. It is applicable in particular to highly scalable solutions such as those used in Advanced Metering Infrastructure <xreftarget='AMI'/>target="AMI" format="default" sectionFormat="of" derivedContent="AMI"/> solutions that leverage distributed routing to enable multipath forwarding over large LLN meshes. </t> </section><section><name>Terminology</name> <!--<sectionanchor='bcp' title="BCP 14"> <t>- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> end section "BCP 14" -->numbered="true" removeInRFC="false" toc="include" pn="section-2"> <name slugifiedName="name-terminology">Terminology</name> <sectionanchor='sixTTerminology'><name>Newanchor="sixTTerminology" numbered="true" removeInRFC="false" toc="include" pn="section-2.1"> <name slugifiedName="name-new-terms">New Terms</name><t><t indent="0" pn="section-2.1-1"> Thedraftdocument does not reuse terms from the <xreftarget='IEEE802154'>target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"> IEEEStd.Std 802.15.4</xref> standard such as "path" or"link""link", which bear a meaning that is quite different from classical IETF parlance. </t><t> This<t indent="0" pn="section-2.1-2">This document adds the followingterms: </t><dl spacing='normal'> <dt>6TiSCHterms:</t> <dl spacing="normal" indent="3" newline="false" pn="section-2.1-3"> <dt pn="section-2.1-3.1">6TiSCH (IPv6 over the TSCH mode of IEEE802.15.4):</dt><dd>802.15.4):</dt> <dd pn="section-2.1-3.2"> 6TiSCH defines an adaptation sublayer for IPv6 over TSCH called 6top, a set of protocols for setting up a TSCH schedule in distributed approach, and a security solution. 6TiSCH may be extended in the future for otherMAC/PHYMAC/Physical Layer (PHY) pairs providing a service similar to TSCH. </dd><dt>6top<dt pn="section-2.1-3.3">6top (6TiSCH OperationSublayer):</dt><dd>Sublayer):</dt> <dd pn="section-2.1-3.4"> The next higher layer of the IEEEStd.Std 802.15.4 TSCH MAC layer. 6top provides the abstraction of an IP link over a TSCH MAC, schedules packets over TSCH cells, and exposes a management interface to schedule TSCH cells. </dd><dt>6P<dt pn="section-2.1-3.5">6P (6topProtocol):</dt><dd>Protocol):</dt> <dd pn="section-2.1-3.6"> The protocol defined in <xreftarget='RFC8480'/>.target="RFC8480" format="default" sectionFormat="of" derivedContent="RFC8480"/>. 6P enablesLayer-2Layer 2 peers to allocate,movemove, ordeallocatede-allocate cells in their respective schedules to communicate. 6P operates at the 6toplayer.sublayer. </dd><dt>6P Transaction:</dt><dd><dt pn="section-2.1-3.7">6P transaction:</dt> <dd pn="section-2.1-3.8"> A 2-way or 3-way sequence of 6P messages used byLayer-2Layer 2 peers to modify their communication schedule. </dd><dt>ASN<dt pn="section-2.1-3.9">ASN (Absolute SlotNumber):</dt><dd>Number):</dt> <dd pn="section-2.1-3.10"> Defined in <xreftarget='IEEE802154'/>,target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"/>, the ASN is the total number of timeslots that have elapsed since the EpochTimetime when the TSCH network started. Incremented by one at each timeslot. It is wide enough to not roll over in practice. </dd><!-- <t hangText="blacklist of frequencies:"> A set of frequencies which should not be used for communication. </t> <t hangText="broadcast cell:"> A scheduled cell used for broadcast transmission. </t> --> <dt>bundle:</dt><dd><dt pn="section-2.1-3.11">bundle:</dt> <dd pn="section-2.1-3.12"> A group of equivalent scheduled cells, i.e., cells identified by different[slotOffset, channelOffset],slotOffset/channelOffset, which are scheduled for a same purpose, with the same neighbor, with the same flags, and the same slotframe. The size of the bundle refers to the number of cells it contains. For a given slotframe length, the size of the bundle translates directly into bandwidth. A bundle is a local abstraction that represents a half-duplex link for either sending or receiving, with bandwidth that amounts to the sum of the cells in the bundle. </dd><dt>Layer-2<dt pn="section-2.1-3.13">Layer 2 vs.Layer-3 bundle:</dt><dd>Layer 3 bundle:</dt> <dd pn="section-2.1-3.14"> Bundles are associatedforwith eitherLayer-2Layer 2 (switching) orLayer-3Layer 3 (routing) forwarding operations. A pair ofLayer-3Layer 3 bundles (one for each direction) maps to an IPLinklink with a neighbor, whereas a set ofLayer-2Layer 2 bundles (of an "arbitrary" cardinality and direction) corresponds to the relation of one or more incoming bundle(s) from the previous-hop neighbor(s) with one or more outgoing bundle(s) to the next-hop neighbor(s) along a Track as part of the switching role, which may include replication and elimination. </dd><dt>CCA<dt pn="section-2.1-3.15">CCA (Clear ChannelAssessment):</dt><dd>Assessment):</dt> <dd pn="section-2.1-3.16"> A mechanism defined in <xreftarget='IEEE802154'/>target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"/> whereby nodes listen to the channel before sending to detect ongoing transmissions from other parties. Because the network is synchronized, CCA cannot be used to detect colliding transmissions within the same network, but it can be used to detect other radio networks in the vicinity. </dd><dt>cell:</dt><dd><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 identified by a slotOffset and a channelOffset. A cell can be scheduled or unscheduled. </dd><dt>Channel<dt pn="section-2.1-3.19">Channel Distribution/Usage (CDU)matrix:</dt><dd>:matrix:</dt> <dd pn="section-2.1-3.20">: A matrix of cells (i,j) representing the spectrum (channel) distribution among the different nodes in the 6TiSCH network. The CDU matrix has width intimeslots,timeslots equal to the period of the network scheduling operation, and height equal to the number of available channels. Every cell (i,j) in the CDU, identified by(slotOffset, channelOffset),slotOffset/channelOffset, belongs to a specific chunk. </dd><dt>channelOffset:</dt><dd><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 channelOffset values is bounded by the number of available frequencies. The channelOffset translates into a frequency with a function that depends on the absolute time when the communication takes place, resulting in achannel hoppingchannel-hopping operation. </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 frequency, within a CDU matrix. A chunk represents a portion of a CDU matrix. The partition of the CDU matrix in chunks is globally known by all the nodes in the network to support the appropriation process, which is a negotiation between nodes within an interference domain. A node that manages to appropriate a chunk gets to decide which transmissions will occur over the cells in the chunk within its interference domain, i.e., a parent node will decide when the cells within the appropriated chunk are used and by whichnode,node among its children. </dd><dt>CoJP<dt pn="section-2.1-3.25">CoJP (Constrained JoinProtocol):</dt><dd> <!-- CoJP is a one-touch join protocol defined in the <xref target="I-D.ietf-6tisch-minimal-security"> Minimal Security Framework for 6TiSCH</xref>. CoJP requires the distribution of preshared keys (PSK), and enables a node to join with a single round trip to the JRC via the JP. -->Protocol):</dt> <dd pn="section-2.1-3.26"> The Constrained Join Protocol (CoJP) enables a pledge to securely join a 6TiSCH network and obtain network parameters over a secure channel.<!-- CoJP is defined in the <xref target="I-D.ietf-6tisch-minimal-security"> Minimal Security Framework"<xref target="RFC9031" format="title" sectionFormat="of" derivedContent="Constrained Join Protocol (CoJP) for6TiSCH </xref>. -->6TiSCH"/>" <xreftarget='I-D.ietf-6tisch-minimal-security'> Minimal Security Framework for 6TiSCH </xref>target="RFC9031" format="default" sectionFormat="of" derivedContent="RFC9031"/> defines the minimal CoJP setup with pre-shared keys defined. In that mode, CoJP can operate with a singleround tripround-trip exchange. </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 specific neighbor. </dd><dt>deterministic network:</dt><dd><dt pn="section-2.1-3.29">deterministic network:</dt> <dd pn="section-2.1-3.30"> The generic concept of a deterministic network is defined in the <xreftarget='RFC8655'>"DetNettarget="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655">"Deterministic Networking Architecture"</xref> document. When applied to 6TiSCH, it refers to the reservation ofTracksTracks, which guarantees an end-to-end latency and optimizes the Packet Delivery Ratio (PDR) for well-characterized flows. </dd><dt>distributed<dt pn="section-2.1-3.31">distributed cellreservation:</dt><dd>reservation:</dt> <dd pn="section-2.1-3.32"> A reservation of a cell done by one or more in-network entities. </dd><dt>distributed<dt pn="section-2.1-3.33">distributed Trackreservation:</dt><dd>reservation:</dt> <dd pn="section-2.1-3.34"> A reservation of a Track done by one or more in-network entities. </dd><dt>EB<dt pn="section-2.1-3.35">EB (EnhancedBeacon):</dt><dd>Beacon):</dt> <dd pn="section-2.1-3.36"> A special frame defined in <xreftarget='IEEE802154'/>target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"/> used by a node, including theJP,Join Proxy (JP), to announce the presence of the network. It contains enough information for a pledge to synchronize to the network. </dd><dt>hard cell:</dt><dd><dt pn="section-2.1-3.37">hard cell:</dt> <dd pn="section-2.1-3.38"> A scheduled cellwhichthat the 6top sublayer may not relocate. </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_Sequence_ID, used for channel hopping when translating the channelOffset value into a frequency. </dd><dt>IE<dt pn="section-2.1-3.41">IE (InformationElement):</dt><dd>Element):</dt> <dd pn="section-2.1-3.42"> Type-Length-Value containers placed at the end of the MACheader,header and used to pass data between layers or devices. Some IE identifiers are managed by the IEEE <xreftarget='IEEE802154'/>.target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"/>. Some IE identifiers are managed by the IETF <xreftarget='RFC8137'/>, and <xref target='I-D.ietf-6tisch-enrollment-enhanced-beacon'/>target="RFC8137" format="default" sectionFormat="of" derivedContent="RFC8137"/>. <xref target="RFC9032" format="default" sectionFormat="of" derivedContent="RFC9032"/> uses one subtype to support the selection of the Join Proxy. </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 network by pledge(s) and the execution of the join protocol. </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 join protocol encompasses authentication,authorizationauthorization, and parameter distribution. The join protocol is executed between the pledge and the JRC. </dd><dt>joined node:</dt><dd><dt pn="section-2.1-3.47">joined node:</dt> <dd pn="section-2.1-3.48"> The newdevice,device after having completed the join process, often just called a node. </dd><dt>JP<dt pn="section-2.1-3.49">JP (JoinProxy):</dt><dd> NodeProxy):</dt> <dd pn="section-2.1-3.50"> A node already part of the 6TiSCH network that serves as a relay to provide connectivity between the pledge and the JRC. The JP announces the presence of the network by regularly sending EB frames. </dd><dt>JRC<dt pn="section-2.1-3.51">JRC (JoinRegistrar/Coordinator):</dt><dd>Registrar/Coordinator):</dt> <dd pn="section-2.1-3.52"> Central entity responsible for the authentication,authorizationauthorization, and configuration of the pledge. </dd><dt>link:</dt><dd><dt pn="section-2.1-3.53">link:</dt> <dd pn="section-2.1-3.54"> A communication facility or medium over which nodes can communicate at theLink-Layer,link layer, which is the layer immediately below IP. In 6TiSCH, the concept is implemented as a collection ofLayer-3Layer 3 bundles. Note: the IETF parlance for the term"Link""link" is adopted, as opposed to the IEEEStd.Std 802.15.4 terminology. </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 industrial control networks. The convergence of IT and OT is the main object of the Industrial Internet of Things (IIOT). </dd><dt>pledge:</dt><dd><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. </dd><dt>(to)<dt pn="section-2.1-3.59">(to) relocate acell:</dt><dd>cell:</dt> <dd pn="section-2.1-3.60"> The action operated by the 6top sublayer of changing the slotOffset and/or channelOffset of a soft cell. </dd><dt>(to)<dt pn="section-2.1-3.61">(to) schedule acell:</dt><dd>cell:</dt> <dd pn="section-2.1-3.62"> The action of turning an unscheduled cell into a scheduled cell. </dd><dt>scheduled cell:</dt><dd><dt pn="section-2.1-3.63">scheduled cell:</dt> <dd pn="section-2.1-3.64"> A cellwhichthat is assigned a neighbor MAC address (broadcast address is alsopossible),possible) and one or more of the following flags: TX, RX,SharedShared, and Timekeeping. A scheduled cell can be used by the IEEEStd.Std 802.15.4 TSCH implementation to communicate. A scheduled cell can either be a hard or a soft cell. </dd><dt>SF<dt pn="section-2.1-3.65">SF (6top SchedulingFunction):</dt><dd>Function):</dt> <dd pn="section-2.1-3.66"> The cell management entity that adds or deletes cells dynamically based on application networking requirements. The cell negotiation with a neighbor is done using 6P. </dd><dt>SFID<dt pn="section-2.1-3.67">SFID (6top Scheduling FunctionIdentifier):</dt><dd>Identifier):</dt> <dd pn="section-2.1-3.68"> A 4-bit field identifying an SF. </dd><dt>shared cell:</dt><dd><dt pn="section-2.1-3.69">shared cell:</dt> <dd pn="section-2.1-3.70"> A cell marked with both the"TX"TX and"shared"Shared flags. This cell can be used by more than one transmitter node. A back-off algorithm is used to resolve contention. </dd><dt>slotframe:</dt><dd><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. It is characterized by aslotframe_ID,slotframe_ID and a slotframe_size. Multiple slotframes can coexist in a node's schedule, i.e., a node can have multiple activities scheduled in differentslotframes,slotframes based on the priority of its packets/traffic flows. The timeslots in theSlotframeslotframe are indexed by theSlotOffset;slotOffset; the first timeslot is atSlotOffsetslotOffset 0. </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. </dd><dt>soft cell:</dt><dd><dt pn="section-2.1-3.75">soft cell:</dt> <dd pn="section-2.1-3.76"> A scheduled cellwhichthat the 6top sublayer can relocate. </dd><dt>time<dt pn="section-2.1-3.77">time sourceneighbor:</dt><dd>neighbor:</dt> <dd pn="section-2.1-3.78"> A neighbor that a node uses as its time reference, and to which it needs to keep its clock synchronized. </dd><dt>timeslot:</dt><dd><dt pn="section-2.1-3.79">timeslot:</dt> <dd pn="section-2.1-3.80"> A basic communication unit in TSCHwhichthat allows a transmitter node to send a frame to a receiverneighbor,neighbor and that allows the receiver neighbor to optionally send back an acknowledgment. </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 complexmulti-hopmultihop path to the destination(s) of the path. In the case of unicast traffic, the Track is aDestination OrientedDestination-Oriented DAG (DODAG) where the Root of the DODAG is the destination of the unicast traffic. A Track enables replication,eliminationelimination, and reordering functions on the way (more on those functions in <xreftarget='RFC8655'/>.target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655"/>). A Track reservation locks physical resources such as cells and buffers in every node along the DODAG. A Track is associated witha owner thatan owner, which can be for instance the destination of the Track. </dd><dt>TrackID:</dt><dd><dt pn="section-2.1-3.83">TrackID:</dt> <dd pn="section-2.1-3.84"> A TrackID is either globallyunique,unique or locally unique to the Track owner, in which case the identification of the owner must be provided together with the TrackID to provide a full reference to the Track.typically,Typically, the Track owner is the ingress of theTrack thenTrack, the IPv6 source address of packets along the Track can be used as identification of theownerowner, and a local InstanceID <xreftarget='RFC6550'/>target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> in the namespace of that owner can be used as TrackID. If the Track is reversible, then the owner is found in the IPv6 destination address of a packet coming back along the Track. In that case, a RPL Packet Information <xreftarget='RFC6550'/>target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> in an IPv6 packet can unambiguously identify the Track and can be expressed in a compressed form using <xreftarget='RFC8138'/>. </dd> <dt>TSCH:</dt><dd>target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138"/>. </dd> <dt pn="section-2.1-3.85">TSCH:</dt> <dd pn="section-2.1-3.86"> A medium access mode of the <xreftarget='IEEE802154'>target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"> IEEEStd.Std 802.15.4</xref> standardwhichthat uses time synchronization to achieve ultra-low-poweroperation,operation and channel hopping to enable high reliability. </dd><dt>TSCH Schedule:</dt><dd><dt pn="section-2.1-3.87">TSCH Schedule:</dt> <dd pn="section-2.1-3.88"> A matrix of cells, with each cell indexed by a slotOffset and a channelOffset. The TSCH schedule contains all the scheduled cells from all slotframes and is sufficient to qualify the communication in the TSCH network. The number of channelOffset values (the "height" of the matrix) is equal to the number of available frequencies. </dd><dt>Unscheduled Cell:</dt><dd><dt pn="section-2.1-3.89">Unscheduled Cell:</dt> <dd pn="section-2.1-3.90"> A cellwhichthat is not used by the IEEEStd.Std 802.15.4 TSCH implementation. </dd> </dl> </section> <sectionanchor='acronyms'><name>Abbreviations</name> <t>anchor="acronyms" numbered="true" removeInRFC="false" toc="include" pn="section-2.2"> <name slugifiedName="name-abbreviations">Abbreviations</name> <t indent="0" pn="section-2.2-1"> This document uses the following abbreviations:</t><dl spacing='normal'> <dt>6BBR:</dt><dd></t> <dl spacing="normal" indent="3" newline="false" pn="section-2.2-2"> <dt pn="section-2.2-2.1">6BBR:</dt> <dd pn="section-2.2-2.2"> 6LoWPAN Backbone Router (router with a proxy ND function) </dd><dt>6LBR:</dt><dd><dt pn="section-2.2-2.3">6LBR:</dt> <dd pn="section-2.2-2.4"> 6LoWPAN Border Router (authoritative onDAD)Duplicate Address Detection (DAD)) </dd><dt>6LN:</dt><dd><dt pn="section-2.2-2.5">6LN:</dt> <dd pn="section-2.2-2.6"> 6LoWPAN Node </dd><dt>6LR:</dt><dd><dt pn="section-2.2-2.7">6LR:</dt> <dd pn="section-2.2-2.8"> 6LoWPAN Router (relay to the registration process) </dd><dt>6CIO:</dt><dd><dt pn="section-2.2-2.9">6CIO:</dt> <dd pn="section-2.2-2.10"> Capability Indication Option </dd><dt>(E)ARO:</dt><dd><dt pn="section-2.2-2.11">(E)ARO:</dt> <dd pn="section-2.2-2.12"> (Extended) Address Registration Option </dd><dt>(E)DAR:</dt><dd><dt pn="section-2.2-2.13">(E)DAR:</dt> <dd pn="section-2.2-2.14"> (Extended) Duplicate Address Request </dd><dt>(E)DAC:</dt><dd><dt pn="section-2.2-2.15">(E)DAC:</dt> <dd pn="section-2.2-2.16"> (Extended) Duplicate Address Confirmation </dd><dt>DAD:</dt><dd><dt pn="section-2.2-2.17">DAD:</dt> <dd pn="section-2.2-2.18"> Duplicate Address Detection </dd><dt>DODAG:</dt><dd><dt pn="section-2.2-2.19">DODAG:</dt> <dd pn="section-2.2-2.20"> Destination-Oriented Directed Acyclic Graph </dd><dt>LLN:</dt><dd><dt pn="section-2.2-2.21">LLN:</dt> <dd pn="section-2.2-2.22"> Low-Power and Lossy Network (a typical IoT network) </dd><dt>NA:</dt><dd><dt pn="section-2.2-2.23">NA:</dt> <dd pn="section-2.2-2.24"> Neighbor Advertisement </dd><dt>NCE:</dt><dd><dt pn="section-2.2-2.25">NCE:</dt> <dd pn="section-2.2-2.26"> Neighbor Cache Entry </dd><dt>ND:</dt><dd><dt pn="section-2.2-2.27">ND:</dt> <dd pn="section-2.2-2.28"> Neighbor Discovery </dd><dt>NDP:</dt><dd><dt pn="section-2.2-2.29">NDP:</dt> <dd pn="section-2.2-2.30"> Neighbor Discovery Protocol </dd><dt>PCE:</dt><dd><dt pn="section-2.2-2.31">PCE:</dt> <dd pn="section-2.2-2.32"> Path Computation Element </dd><dt>NME:</dt><dd><dt pn="section-2.2-2.33">NME:</dt> <dd pn="section-2.2-2.34"> Network Management Entity </dd><dt>ROVR:</dt><dd><dt pn="section-2.2-2.35">ROVR:</dt> <dd pn="section-2.2-2.36"> Registration Ownership Verifier (pronounced rover) </dd><dt>RPL:</dt><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>RA:</dt><dd><dt pn="section-2.2-2.39">RA:</dt> <dd pn="section-2.2-2.40"> Router Advertisement </dd><dt>RS:</dt><dd><dt pn="section-2.2-2.41">RS:</dt> <dd pn="section-2.2-2.42"> Router Solicitation </dd><dt>TSCH:</dt><dd> timeslotted<dt pn="section-2.2-2.43">TSCH:</dt> <dd pn="section-2.2-2.44"> Time-Slotted Channel Hopping </dd><dt>TID:</dt><dd><dt pn="section-2.2-2.45">TID:</dt> <dd pn="section-2.2-2.46"> Transaction ID (a sequence counter in the EARO) </dd> </dl> </section><!-- end section "Abbreviations" --><sectionanchor='lo'><name>Relatedanchor="lo" numbered="true" removeInRFC="false" toc="include" pn="section-2.3"> <name slugifiedName="name-related-documents">Related Documents</name><t><t indent="0" pn="section-2.3-1"> Thedraft alsodocument conforms to the terms and models described in <xreftarget='RFC3444'/>target="RFC3444" format="default" sectionFormat="of" derivedContent="RFC3444"/> and <xreftarget='RFC5889'/> andtarget="RFC5889" format="default" sectionFormat="of" derivedContent="RFC5889"/>, uses the vocabulary and the concepts defined in <xreftarget='RFC4291'/>target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/> for the IPv6Architecturearchitecture, and refers to <xreftarget='RFC4080'/> for reservation <!-- signaling and <xref target="RFC5191"/>target="RFC4080" format="default" sectionFormat="of" derivedContent="RFC4080"/> forauthentication. -->reservation. </t><t><t indent="0" pn="section-2.3-2"> Thedraftdocument uses domain-specific terminology defined or referencedin: </t><ul empty='true' spacing='normal'> <li> 6LoWPAN ND <xref target='RFC6775'>"Neighborin the following: </t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-3"> <li pn="section-2.3-3.1">6LoWPAN ND: <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775">"Neighbor Discovery Optimization forLow-power and Lossy Networks"</xref>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"</xref> and <xreftarget='RFC8505'> "Registrationtarget="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505">"Registration Extensions for6LoWPANIPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery"</xref>, </li><li><xref target='RFC7102'>"Terms<li pn="section-2.3-3.2"> <xref target="RFC7102" format="default" sectionFormat="of" derivedContent="RFC7102">"Terms Used in Routing for Low-Power and LossyNetworks (LLNs)"</xref>,</li> <li>Networks"</xref>, andRPL</li> <li pn="section-2.3-3.3">RPL: <xreftarget='RFC6552'>"Objectivetarget="RFC6552" format="default" sectionFormat="of" derivedContent="RFC6552">"Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks(RPL)" </xref>,(RPL)"</xref> and <xreftarget='RFC6550'>"RPL:target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550">"RPL: IPv6 Routing Protocol for Low-Power and LossyNetworks"</xref>.</li> </ul><t>Networks"</xref>. </li> </ul> <t indent="0" pn="section-2.3-4"> Other terms in use in LLNs are found in <xreftarget='RFC7228'>target="RFC7228" format="default" sectionFormat="of" derivedContent="RFC7228"> "Terminology for Constrained-Node Networks"</xref>.</t><t></t> <t indent="0" pn="section-2.3-5"> Readers are expected to be familiar with all the terms and concepts that are discussed in</t><ul spacing='normal'> <li> <xref target='RFC4861'>"Neighborthe following: </t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-6"> <li pn="section-2.3-6.1"> <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861">"Neighbor Discovery for IP version6" </xref>,6 (IPv6)"</xref> and </li> <li pn="section-2.3-6.2"> <xreftarget='RFC4862'>"IPv6target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862">"IPv6 Stateless AddressAutoconfiguration" </xref>.</li> </ul><t> </t> <t>InAutoconfiguration"</xref>. </li> </ul> <t indent="0" pn="section-2.3-7">In addition, readers would benefit fromreading: </t><ul spacing='normal'> <li><xref target='RFC6606'>"Problemreading 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" derivedContent="RFC6606">"Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)Routing" </xref>,</li> <li>Routing"</xref>, </li> <li pn="section-2.3-8.2"> <xreftarget='RFC4903'>"Multi-Linktarget="RFC4903" format="default" sectionFormat="of" derivedContent="RFC4903">"Multi-Link Subnet Issues"</xref>, and </li><li><li pn="section-2.3-8.3"> <xreftarget='RFC4919'>"IPv6target="RFC4919" format="default" sectionFormat="of" derivedContent="RFC4919">"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, andGoals"</xref></li> </ul><t> prior to this specification for a clear understanding of the art in ND-proxying and binding. </t>Goals"</xref>. </li> </ul> </section><!-- end section "References" --></section><!-- end section "Terminology" --> <section><name>High Level<section numbered="true" removeInRFC="false" toc="include" pn="section-3"> <name slugifiedName="name-high-level-architecture">High-Level Architecture</name><section><name>A Non-Broadcast Multi-Access<section numbered="true" removeInRFC="false" toc="include" pn="section-3.1"> <name slugifiedName="name-a-non-broadcast-multi-acces">A Non-broadcast Multi-access Radio Mesh Network</name><t><t indent="0" pn="section-3.1-1"> A 6TiSCH network is an IPv6 <xreftarget='RFC8200'/>target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> subnetwhich,that, in its basic configuration illustrated in <xreftarget='fig1'/>,target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/>, is a single Low-Power and Lossy Network (LLN) operating over a synchronized TSCH-based mesh. </t> <figureanchor='fig1'><name>Basicanchor="fig1" align="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-basic-configuration-of-a-6t">Basic Configuration of a 6TiSCH Network</name><artwork><![CDATA[<artwork align="left" pn="section-3.1-2.1"> ---+-------- ............ ------------ | External Network | | +-----+ +-----+ | NME | | | LLN Border | PCE | | | router (6LBR) +-----+ +-----+ o o o o o o o o o o 6LoWPAN + RPL o o o o o o]]></artwork></artwork> </figure><t><t indent="0" pn="section-3.1-3"> Inside a 6TiSCH LLN, nodes rely on <xreftarget='RFC6282'>6LoWPAN Header Compressiontarget="RFC6282" format="default" 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 (typically an IEEEStd.Std 802.15.4-compliant radio) may be seen as a collection ofLinkslinks 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 members of the mesh (see <xreftarget='rflo'/>).target="rflo" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>). The security aspects of the join process are further detailed in <xreftarget='sec'/>.target="sec" format="default" sectionFormat="of" derivedContent="Section 6"/>. In a mesh network, 6TiSCH nodes are not necessarily reachable from one another atLayer-2Layer 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, which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) <xreftarget='RFC4861'/><xref target='RFC4862'/>.target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/> <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/>. 6LoWPAN Neighbor Discovery (6LoWPAN ND) <xreftarget='RFC6775'/><xref target='RFC8505'/>target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/> <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> specifies extensions to IPv6 ND that enable ND operations in this type of subnet that can be protected against address theft and impersonation with <xreftarget='I-D.ietf-6lo-ap-nd'/>.target="RFC8928" format="default" sectionFormat="of" derivedContent="RFC8928"/>. </t><t><t indent="0" pn="section-3.1-6"> Once it has joined the 6TiSCH network, a node acquires IPv6Addressesaddresses andregisterregisters them using 6LoWPAN ND. This guarantees that the addresses are unique and protects the address ownership over the subnet, more in <xreftarget='rreg'/>.target="rreg" format="default" sectionFormat="of" derivedContent="Section 4.2.2"/>. </t><t><t indent="0" pn="section-3.1-7"> Within the NBMA subnet, <xreftarget='RFC6550'>RPL</xref>target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550">RPL</xref> enables routing in the so-calledRoute Over"route-over" fashion, either in storing (stateful) or non-storing (stateless, with routing headers) mode. From there, some nodes can act as routers for 6LoWPAN ND and RPL operations, as detailed in <xreftarget='RPLvs6lo'/>. </t><t>target="RPLvs6lo" format="default" sectionFormat="of" derivedContent="Section 4.1"/>. </t> <t indent="0" pn="section-3.1-8"> With TSCH, devices aretime-synchronizedtime synchronized at the MAC level. The use of a particular RPL Instance for time synchronization is discussed in <xreftarget='sync'/>.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.</t><t></t> <t indent="0" pn="section-3.1-9"> RPL formsDestination OrientedDestination-Oriented Directed Acyclic Graphs (DODAGs) within Instances of the protocol, each Instance being associated with an Objective Function (OF) to form a routing topology. A particular 6TiSCH node, the LLN Border Router (6LBR), acts as RPL Root, 6LoWPAN HC terminator, and Border Router for the LLN to the outside. The 6LBR is usually powered. More on RPL Instances can be found insection 3.1Section <xref target="RFC6550" section="3.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1" derivedContent="RFC6550"/> of <xreftarget='RFC6550'>RPL</xref>,target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550">RPL</xref>, in particular"3.1.2."<xref target="RFC6550" section="3.1.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1.2" derivedContent="RFC6550"/> RPL Identifiers" and"3.1.3."<xref target="RFC6550" section="3.1.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1.3" derivedContent="RFC6550"/> Instances, DODAGs, and DODAG Versions". RPL adds artifacts in the data packets that are compressed with a6LoWPAN addition<xreftarget='RFC8138'>6LoRH</xref>. </t><t>target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138">6LoWPAN Routing Header (6LoRH)</xref>. In a preexisting network, the compression can be globally turned on in a DODAG once all nodes are migrated to support <xref target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138"/> using <xref target="RFC9035" format="default" sectionFormat="of" derivedContent="RFC9035"/>. </t> <t indent="0" pn="section-3.1-10"> Additional routing and scheduling protocols may be deployed to establishon-demand Peer-to-Peeron-demand, peer-to-peer routes with particular characteristics inside the 6TiSCH network. This may be achieved in a centralized fashion by a Path Computation Element (PCE) <xreftarget='PCE'/>target="PCE" format="default" sectionFormat="of" derivedContent="PCE"/> that programs both the routes and the schedules inside the 6TiSCHnodes,nodes orbyin a distributed fashion by using a reactive routing protocol and aHop-by-Hophop-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 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 participatetoin the full routing protocol. The architecture also expects that a 6LoWPAN node that isnot aware at allunaware oftheRPLprotocolmay also connect as described in <xreftarget='I-D.ietf-roll-unaware-leaves'/>.target="RFC9010" format="default" sectionFormat="of" derivedContent="RFC9010"/>. </t> </section><section><name>A<section numbered="true" removeInRFC="false" toc="include" pn="section-3.2"> <name slugifiedName="name-a-multi-link-subnet-model">A Multi-Link Subnet Model</name><t><t indent="0" pn="section-3.2-1"> An extended configuration of the subnet comprises multiple LLNs as illustrated in <xreftarget='fig2'/>.target="fig2" format="default" sectionFormat="of" derivedContent="Figure 2"/>. In the extended configuration, a Routing Registrar <xreftarget='RFC8505'/>target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> may be connected to the node that acts as the RPL Rootand / orand/or 6LoWPAN 6LBR and provides connectivity to the larger campus/or factory plant network over a high-speed backbone or a back-haul link. The RoutingregistrarRegistrar may perform IPv6 ND proxyoperations, oroperations; redistribute the registration in a routing protocol such as <xreftarget='RFC5340'>OSPF</xref>target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340">OSPF</xref> or <xreftarget='RFC2545'>BGP</xref>,target="RFC2545" format="default" sectionFormat="of" derivedContent="RFC2545">BGP</xref>; or inject a route in a mobility protocol such as <xreftarget='RFC6275'>MIPv6</xref>, <xref target='RFC3963'>NEMO </xref>,target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275">Mobile IPv6 (MIPv6)</xref>, <xref target="RFC3963" format="default" sectionFormat="of" derivedContent="RFC3963">Network Mobility (NEMO)</xref>, or <xreftarget='RFC6830'>LISP</xref>.target="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830">Locator/ID Separation Protocol (LISP)</xref>. </t><t><t indent="0" pn="section-3.2-2"> Multiple LLNs can be interconnected and possibly synchronized over a backbone, which can be wired or wireless. The backbone can operate with IPv6 ND<xref target='RFC4861'/><xref target='RFC4862'/>procedures <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/> <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/> orana hybrid of IPv6 ND and 6LoWPAN ND <xreftarget='RFC6775'/><xref target='RFC8505'/><xref target='I-D.ietf-6lo-ap-nd'/>.target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/> <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> <xref target="RFC8928" format="default" sectionFormat="of" derivedContent="RFC8928"/>. </t> <figureanchor='fig2'><name>Extendedanchor="fig2" align="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-extended-configuration-of-a">Extended Configuration of a 6TiSCH Network</name><artwork><![CDATA[<artwork align="left" pn="section-3.2-3.1"> | +-----+ +-----+ +-----+ (default) | | (Optional) | | | | IPv6 Router | | 6LBR | | | | Node +-----+ +-----+ +-----+ | Backbone side | | --------+---+--------------------+-+---------------+------+--- | | | +-----------+ +-----------+ +-----------+ | Routing | | Routing | | Routing | | Registrar | | Registrar | | Registrar | +-----------+ +-----------+ +-----------+ o Wireless side o o o o o o o o o o o o o o o o o o o 6TiSCH o 6TiSCH o o o o 6TiSCH o o o LLN o o o o LLN o o LLN o o o o o o o o o o o o o o o]]></artwork></figure> <t></artwork> </figure> <t indent="0" pn="section-3.2-4"> A Routing Registrar that performs proxy IPv6 ND operations over the backbone on behalf of the 6TiSCH nodes is called a Backbone Router (6BBR) <xreftarget='I-D.ietf-6lo-backbone-router'/>.target="RFC8929" format="default" sectionFormat="of" derivedContent="RFC8929"/>. The 6BBRs are placed along the wireless edge of aBackbone,backbone and federate multiple wireless links to form a singleMultiLink Subnet.multi-link subnet. The 6BBRs synchronize with one another over the backbone, so as to ensure that the multiple LLNs that form the IPv6 subnet stay tightly synchronized. </t><t><t indent="0" pn="section-3.2-5"> The use of multicast can also be reduced on the backbone with a registrar that would contribute to Duplicate Address Detection as well asAddress Lookupaddress lookup using only unicast request/response exchanges. <xreftarget='I-D.thubert-6man-unicast-lookup'/>target="I-D.thubert-6man-unicast-lookup" format="default" sectionFormat="of" derivedContent="ND-UNICAST-LOOKUP"/> is a proposed method that presents an example of howtothis could be achieved with an extension of <xreftarget='RFC8505'/>,target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/>, using an optional 6LBR as aSubNet-levelsubnet-level registrar, as illustrated in <xreftarget='fig2'/>.target="fig2" format="default" sectionFormat="of" derivedContent="Figure 2"/>. </t><t><t indent="0" pn="section-3.2-6"> As detailed in <xreftarget='RPLvs6lo'/>target="RPLvs6lo" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, the 6LBR that serves the LLN and the Root of the RPL network need to share information about the devices that are learned through either 6LoWPAN ND orRPLRPL, but not both. The preferred way of achieving this is tocollocate/combineco-locate or combine them. The combined RPL Root and 6LBR may becollocatedco-located with the 6BBR, or directly attached to the 6BBR. In the latter case, it leverages the extended registration process defined in <xreftarget='RFC8505'/>target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> to proxy the 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so that the 6BBR may in turn performproxyclassical ND operations over thebackbone.backbone as a proxy. </t><t><t indent="0" pn="section-3.2-7"> The <xreftarget='RFC8655'>DetNet Architecture</xref>target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655">"Deterministic Networking Architecture"</xref> studiesLayer-3Layer 3 aspects of DeterministicNetworks,Networks and covers networks that span multipleLayer-2Layer 2 domains. If theBackbonebackbone isDeterministicdeterministic (such as defined by theTime SensitiveTime-Sensitive NetworkingWG(TSN) Task Group at IEEE), then the Backbone Router ensures that the end-to-end deterministic behavior is maintained between the LLN and the backbone. </t> </section><section><name>TSCH: A<section numbered="true" removeInRFC="false" toc="include" pn="section-3.3"> <name slugifiedName="name-tsch-a-deterministic-mac-la">TSCH: a Deterministic MAC Layer</name><t><t indent="0" pn="section-3.3-1"> Though at a different time scale (several orders of magnitude), both IEEEStd. 802.1TSNStd 802.1 TSN and IEEEStd.Std 802.15.4 TSCH standards provideDeterministicdeterministic capabilities to the point that a packetthat pertainspertaining to a certain flow may traverse a network from node to node following a precise schedule, as a train that enters and then leaves intermediate stations at precise times along its path. </t><t><t indent="0" pn="section-3.3-2"> With TSCH, time is formatted into timeslots, and individual communication cells are allocated to unicast or broadcast communication at the MAC level. The time-slotted operation reduces collisions, saves energy, and enablestomore closelyengineerengineering the network for deterministic properties. Thechannel hoppingchannel-hopping aspect is a simple and efficient technique to combat multipath fading and co-channel interference. </t><t><t indent="0" pn="section-3.3-3"> 6TiSCH builds on the IEEEStd.Std 802.15.4 TSCH MAC and inherits its advanced capabilities to enable them in multiple environments where they can be leveraged to improve automated operations. The 6TiSCHArchitecturearchitecture also inherits the capability to perform a centralized route computation to achieve deterministic properties, though it relies on the IETF <xreftarget='RFC8655'>DetNet Architecture</xref>,target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655">DetNet architecture</xref> and IETF components such as the PCE <xreftarget='PCE'/>,target="PCE" format="default" sectionFormat="of" derivedContent="PCE"/> for the protocol aspects. </t><t>On<t indent="0" pn="section-3.3-4">On top of this inheritance, 6TiSCH adds capabilities for distributed routing and scheduling operations based ontheRPLrouting protocoland capabilitiesto negotiatefor negotiating schedule adjustments between peers. These distributed routing and scheduling operations simplify the deployment of TSCH networks and enable wireless solutions in a larger variety of use cases from operational technology in general. Examples of suchuse-casesuse cases in industrial environments include plant setup and decommissioning, as well as monitoring a multiplicity oflots of lesser importance measurementsminor notifications such as corrosion measurements, events, andevents and mobile workers accessingaccess of localdevices.devices by mobile workers. </t> </section><section><name>Scheduling<section numbered="true" removeInRFC="false" toc="include" pn="section-3.4"> <name slugifiedName="name-scheduling-tsch">Scheduling TSCH</name><t>A<t indent="0" pn="section-3.4-1">A scheduling operationattributesallocates cells in aTime-Division-Multiplexing (TDM) / Frequency-Division Multiplexing (FDM)TDM/FDM matrix calledthe Channel distribution/usage (CDU) toa CDU either to individual transmissions or as multi-access shared resources. The CDU matrix can be formatted in chunks that can be allocated exclusively to particular nodes to enable distributed scheduling without collision. More in <xreftarget='slotframes'/>.target="slotframes" format="default" sectionFormat="of" derivedContent="Section 4.3.5"/>. </t><t> From<t indent="0" pn="section-3.4-2"> At thestandpointMAC layer, the schedule of a 6TiSCH node(at the MAC layer), its scheduleis the collection of the timeslots at which it must wake up for transmission, and the channels to which it should either send or listen at those times. The schedule is expressed as one or moreslotframes that repeat over and over.repeating slotframes. Slotframes may collide and require a device to wake up at a same time, in which case the slotframe with the highest priority is actionable. </t><t><t indent="0" pn="section-3.4-3"> The 6top sublayer (see <xreftarget='s6Pprot'/>target="s6Pprot" format="default" sectionFormat="of" derivedContent="Section 4.3"/> for more) hides the complexity of the schedule from the upper layers. TheLinklink abstraction that IP traffic utilizes is composed of a pair ofLayer-3Layer 3 cell bundles, one to receive and one to transmit. Some of the cells may be shared, in which case the 6top sublayer must perform some arbitration. </t><t><t indent="0" pn="section-3.4-4"> Scheduling enables multiple simultaneous communicationsat a same timein a same interference domain using different channels; but a node equipped with a single radio can only either transmit or receive on one channel at any point of time. Scheduled cells thatfulfilfulfill the same role, e.g., receive IP packets from a peer, are grouped in bundles. </t><t>The<t indent="0" pn="section-3.4-5">The 6TiSCH architecture identifies four ways a schedule can be managed and CDU cells can be allocated: Static Scheduling, Neighbor-to-Neighbor Scheduling, Centralized (or Remote) Monitoring and Schedule Management, andHop-by-hopHop-by-Hop Scheduling.</t><dl spacing='normal'> <dt>Static Scheduling:</dt><dd>This</t> <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 network for use in a Slotted ALOHA <xreftarget='S-ALOHA'/>target="S-ALOHA" format="default" sectionFormat="of" derivedContent="S-ALOHA"/> fashion. The static schedule is distributed through the native methods in the TSCH MAC layer and does not preclude other scheduling operationsto co-existcoexisting on a same 6TiSCH network. A static schedule is necessary for basic operations such as the join process and for interoperability during the network formation, which is specified as part of the <xreftarget='RFC8180'>Minimaltarget="RFC8180" format="default" sectionFormat="of" derivedContent="RFC8180">Minimal 6TiSCH Configuration </xref>. </dd><dt>Neighbor-to-Neighbor Scheduling:</dt><dd>This<dt pn="section-3.4-6.3">Neighbor-to-Neighbor Scheduling:</dt> <dd pn="section-3.4-6.4">This refers to the dynamic adaptation of the bandwidth of theLinkslinks that are used for IPv6 traffic between adjacent peers. Scheduling Functions such as the <xreftarget='I-D.ietf-6tisch-msf'>"6TiSCHtarget="RFC9033" format="default" sectionFormat="of" derivedContent="RFC9033">"6TiSCH Minimal Scheduling Function (MSF)"</xref> influence the operation of the MAC layer to add,updateupdate, and remove cells in itsown,own and its peer's schedules using 6P <xreftarget='RFC8480'/>,target="RFC8480" format="default" sectionFormat="of" derivedContent="RFC8480"/> for the negotiation of the MAC resources.</dd><dt>Centralized<dt pn="section-3.4-6.5">Centralized (or Remote) Monitoring and ScheduleManagement:</dt><dd>Management:</dt> <dd pn="section-3.4-6.6"> This refers to the central computation of a schedule and the capability to forward a frame based on the cell of arrival. In that case, the related portion of the device schedule as well as other device resources are managed by an abstract Network Management Entity (NME), which may cooperate with the PCE to minimize the interactionwithwith, and the loadonon, the constrained device. This model is the TSCH adaption of the <xreftarget='RFC8655'>DetNet Architecture</xref>,target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655">DetNet architecture</xref>, and it enables Traffic Engineering with deterministic properties. </dd><dt>Hop-by-hop Scheduling:</dt><dd>This<dt pn="section-3.4-6.7">Hop-by-Hop Scheduling:</dt> <dd pn="section-3.4-6.8">This refers to the possibilityto reservesof reserving cells along a path for a particular flow using a distributed mechanism.</dd></dl><t> </t> <t></dl> <t indent="0" pn="section-3.4-7"> It is not expected that all use cases will require all those mechanisms. Static Scheduling with minimal configurationoneis the only one that is expected in all implementations, since it provides a simple and solid basis for convergecast routing and time distribution.</t><t></t> <t indent="0" pn="section-3.4-8"> A deeper diveininto those mechanisms can be found in <xreftarget='schd'/>.target="schd" format="default" sectionFormat="of" derivedContent="Section 4.4"/>. </t> </section> <sectionanchor='rtg3'><name>Distributedanchor="rtg3" numbered="true" removeInRFC="false" toc="include" pn="section-3.5"> <name slugifiedName="name-distributed-vs-centralized-">Distributed vs. Centralized Routing</name><t><t indent="0" pn="section-3.5-1"> 6TiSCH enables a mixed model of centralized routes and distributed routes. Centralized routescancan, forexampleexample, be computed by an entity such as a PCE. 6TiSCH leveragesthe<xreftarget='RFC6550'>RPL</xref> routing protocoltarget="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550">RPL</xref> forinteroperableinteroperable, distributed routing operations. </t><t><t indent="0" pn="section-3.5-2"> Both methods may inject routesininto theRouting Tablesrouting tables of the 6TiSCH routers. In either case, each route is associated with a 6TiSCH topology that can be a RPL Instance topology or a Track. The 6TiSCH topology is indexed by a RPLInstanceID, in a format that reuses the RPLInstanceID as defined in RPL. </t><t><t indent="0" pn="section-3.5-3"> <xreftarget='RFC6550'>RPL</xref>target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550">RPL</xref> is applicable to Static Scheduling and Neighbor-to-Neighbor Scheduling. The architecture also supports a centralized routing model for Remote Monitoring and Schedule Management. It is expected that a routing protocol that is more optimized for point-to-point routing than <xreftarget='RFC6550'>RPL</xref>,target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550">RPL</xref>, such as the <xreftarget='I-D.ietf-roll-aodv-rpl'> Asymmetrictarget="I-D.ietf-roll-aodv-rpl" format="default" sectionFormat="of" derivedContent="AODV-RPL"> "Asymmetric AODV-P2P-RPL in Low-Power and LossyNetworks"</xref> AODV-RPL),Networks" (AODV-RPL)</xref>, which derives from the <xreftarget='I-D.ietf-manet-aodvv2'> Adtarget="I-D.ietf-manet-aodvv2" format="default" sectionFormat="of" derivedContent="AODVv2"> "Ad Hoc On-demand Distance VectorRouting (AODV)</xref>(AODVv2) Routing"</xref>, will be selected forHop-by-hopHop-by-Hop Scheduling. </t><t><t indent="0" pn="section-3.5-4"> Both RPL and PCE rely on shared sources such as policies to defineGlobalglobal andLocallocal RPLInstanceIDs that can be used by either method. It is possible for centralized and distributed routing to shareathe same topology. Generally they will operate in different slotframes, and centralized routes will be used for scheduled traffic and will have precedence over distributed routes in case of conflict between the slotframes. </t> </section><!-- Distributed vs. Centralized Routing --> <section><name>Forwarding Over<section numbered="true" removeInRFC="false" toc="include" pn="section-3.6"> <name slugifiedName="name-forwarding-over-tsch">Forwarding over TSCH</name><t><t indent="0" pn="section-3.6-1"> The 6TiSCH architecture supports three different forwarding models. One is the classical IPv6 Forwarding, where the node selects a feasible successor atLayer-3Layer 3 on aper packetper-packet basis and based on its routing table. The second derives fromGenericGeneralized MPLS(G-MPLS)(GMPLS) for so-called Track Forwarding, whereby a frame received at a particular timeslot can be switched into another timeslot atLayer-2Layer 2 without regard to theupper layerupper-layer protocol. The third model is the 6LoWPAN Fragment Forwarding, which allowsto forwardthe forwarding individual6loWPAN6LoWPAN fragments along a route that issetupset up by the first fragment. </t><t>In<t indent="0" pn="section-3.6-2">In moredetails: </t><dl spacing='normal'> <dt>IPv6 Forwarding:</dt><dd>Thisdetail: </t> <dl spacing="normal" indent="3" newline="false" pn="section-3.6-3"> <dt pn="section-3.6-3.1">IPv6 Forwarding:</dt> <dd pn="section-3.6-3.2">This is the classical IP forwarding model, with a Routing InformationBasedBase (RIB) that is installed bytheRPLrouting protocoland used to select a feasible successor per packet. The packet is placed on an outgoingLink, thatlink, which the 6toplayersublayer maps into a(Layer-3)(Layer 3) bundle of cells, and scheduled for transmission based on QoS parameters. Besides RPL, this model also applies to any routing protocolwhichthat may be operated in the 6TiSCHnetwork,network and corresponds to all the distributed schedulingmodels,models: Static,Neighbor-to-NeighborNeighbor-to-Neighbor, and Hop-by-Hop Scheduling.</dd><dt>G-MPLS<dt pn="section-3.6-3.3">GMPLS TrackForwarding:</dt><dd>ThisForwarding:</dt> <dd pn="section-3.6-3.4">This model corresponds to the Remote Monitoring and Schedule Management. In this model, a central controller (hosting a PCE) computes and installs the schedules in the devices per flow. The incoming(Layer-2)(Layer 2) bundle of cells from the previous node along the path determines the outgoing(Layer-2)(Layer 2) bundle towards the next hop for that flow as determined by the PCE. The programmed sequence for bundles is called a Track and can assume DAG shapes that are more complex than a simple direct sequence of nodes.</dd><dt>6LoWPAN<dt pn="section-3.6-3.5">6LoWPAN FragmentForwarding:</dt><dd>ThisForwarding:</dt> <dd pn="section-3.6-3.6">This is a hybrid model that derives from IPv6 forwarding for the case where packets must be fragmented at the 6LoWPAN sublayer. The first fragment is forwarded like any IPv6 packet and leaves a state in the intermediate hops to enable forwarding of the next fragments that do not haveaan IP header without the need to recompose the packet at every hop.</dd></dl><t> </t> <t>A</dl> <t indent="0" pn="section-3.6-4">A deeper diveoninto these operations can be found in <xreftarget='fwd'/>.target="fwd" format="default" sectionFormat="of" derivedContent="Section 4.6"/>. </t><t> The following table<t indent="0" pn="section-3.6-5"> <xref target="RaF" format="default" sectionFormat="of" derivedContent="Table 1"/> summarizes how the forwarding models apply to the various routing and scheduling possibilities: </t><figure anchor='RaF' suppress-title='true'> <artwork> <![CDATA[ +-------------------+------------+----------------------------------+ | Forwarding Model | Routing | Scheduling | +===================+============+==================================+ | | | Static (Minimal Configuration) | + classical<table anchor="RaF" align="center" pn="table-1"> <thead> <tr> <th align="left" colspan="1" rowspan="1">Forwarding Model</th> <th align="left" colspan="1" rowspan="1">Routing</th> <th align="left" colspan="1" rowspan="1">Scheduling</th> </tr> </thead> <tbody> <tr> <td rowspan="3" align="left" colspan="1">classical IPv6+ RPL +----------------------------------+ |/| | Neighbor-to-Neighbor (SF+6P) | +6LoWPANFragment +------------+----------------------------------+ | | Reactive | Hop-by-Hop (AODV-RPL) | +-------------------+------------+----------------------------------+ |G-MPLSFragment</td> <td rowspan="2" align="left" colspan="1">RPL</td> <td align="left" colspan="1" rowspan="1">Static (Minimal Configuration)</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">Neighbor-to-Neighbor (SF+6P)</td> </tr> <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 TrackFwding| PCE |RemoteForwarding</td> <td align="left" colspan="1" rowspan="1">PCE</td> <td align="left" colspan="1" rowspan="1">Remote Monitoring and ScheduleMgt| +-------------------+------------+----------------------------------+ ]]> </artwork> </figure>Mgt</td> </tr> </tbody> </table> </section> <sectionanchor='fsixstac'><name>6TiSCHanchor="fsixstac" numbered="true" removeInRFC="false" toc="include" pn="section-3.7"> <name slugifiedName="name-6tisch-stack">6TiSCH Stack</name><t><t indent="0" pn="section-3.7-1"> The IETF proposes multiple techniques for implementing functions related to routing,transporttransport, or security. </t><t><t indent="0" pn="section-3.7-2"> The 6TiSCH architecture limits the possible variations of the stack and recommends a number of base elements for LLN applications to control the complexity of possible deployments and deviceinteractions,interactions and to limit the size of the resulting object code. In particular, UDP <xreftarget='RFC0768'/>,target="RFC0768" format="default" sectionFormat="of" derivedContent="RFC0768"/>, IPv6 <xreftarget='RFC8200'/>target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>, and the <xreftarget='RFC7252'>Constrainedtarget="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252">Constrained ApplicationProtocol</xref> (CoAP)Protocol (CoAP)</xref> are used as thetransport / bindingtransport/binding of choice for applications and management as opposed to TCP and HTTP. </t><t><t indent="0" pn="section-3.7-3"> The resulting protocol stack is represented in <xreftarget='fig4'/>:target="fig4" format="default" sectionFormat="of" derivedContent="Figure 3"/>: </t> <figureanchor='fig4'><name>6TiSCHanchor="fig4" align="left" suppress-title="false" pn="figure-3"> <name slugifiedName="name-6tisch-protocol-stack">6TiSCH Protocol Stack</name><artwork><![CDATA[<artwork align="left" pn="section-3.7-4.1"> +--------+--------+ | Applis | CoJP | +--------+--------+--------------+-----+ | CoAP / OSCORE | 6LoWPAN ND | RPL | +-----------------+--------------+-----+ | UDP | ICMPv6 | +-----------------+--------------------+ | IPv6 | +--------------------------------------+----------------------+ | 6LoWPAN HC / 6LoRH HC | Scheduling Functions | +--------------------------------------+----------------------+ | 6top inc. 6topprotocolProtocol | +-------------------------------------------------------------+ | IEEEStd.Std 802.15.4 TSCH | +-------------------------------------------------------------+]]></artwork></artwork> </figure><t><t indent="0" pn="section-3.7-5"> RPL is the routing protocol of choice for LLNs. So far, therewasis no identified need to define a6TiSCH specific6TiSCH-specific Objective Function. The <xreftarget='RFC8180'>Minimaltarget="RFC8180" format="default" sectionFormat="of" derivedContent="RFC8180">Minimal 6TiSCH Configuration </xref> describes the operation of RPL over a static schedule used in a Slotted ALOHA fashion <xreftarget='S-ALOHA'/>,target="S-ALOHA" format="default" sectionFormat="of" derivedContent="S-ALOHA"/>, whereby all active slots may be used for emission or reception of both unicast and multicast frames. </t><t> The<t indent="0" pn="section-3.7-6"> <xreftarget='RFC6282'>6LoWPAN Header Compression</xref>target="RFC6282" format="default" sectionFormat="of" derivedContent="RFC6282">6LoWPAN header compression</xref> is used to compress the IPv6 and UDP headers, whereas the <xreftarget='RFC8138'>target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138"> 6LoWPAN Routing Header (6LoRH)</xref> is used to compress the RPL artifacts in the IPv6 data packets, including the RPL Packet Information (RPI), the IP-in-IP encapsulation to/from the RPL Root, and the SourceRouteRouting 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" derivedContent="Using RPI Option Type, Routing Header for Source Routes, andIPv6-in-IPv6"</xref>IPv6-in-IPv6 Encapsulation in the RPL Data Plane"/>" <xref target="RFC9008" format="default" sectionFormat="of" derivedContent="RFC9008"/> provides the details on when headers or encapsulation are needed. </t><t> <!--The COMAN list is working on network Management for LLN. They are considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) Object system. This standard includes DTLS, CoAP (core plus Block and Observe patterns), SenML and CoAP Resource Directory. 6TiSCH has adopted the general direction of <xref target="I-D.ietf-core-comi"> CoAP Management Interface (COMI)</xref> for the management of devices. This is leveraged for instance for the implementation of the generic data model for the 6top sublayer management interface <xref target="I-D.ietf-6tisch-6top-interface"/>. The proposed implementation is based on CoAP and CBOR, and specified in <xref target="I-D.ietf-6tisch-coap"> 6TiSCH Resource Management and Interaction using CoAP</xref>.--> </t> <t><t indent="0" pn="section-3.7-7"> The <xreftarget='I-D.ietf-core-object-security'>target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"> Object Security for Constrained RESTful Environments (OSCORE)</xref>,</xref> is leveraged by the Constrained Join Protocol (CoJP) and is expected to be the primary protocol for the protection of the application payload as well. The application payload may also be protected by the <xreftarget='RFC6347'>Datagramtarget="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347">Datagram Transport Layer Security (DTLS) </xref> sitting either under CoAP or over CoAP so it can traverse proxies. </t><t> <!-- Similarly, the <xref target="RFC5191"> Protocol for Carrying Authentication for Network access (PANA)</xref> is represented as an example of a protocol that could be leveraged to secure the join process, as a Layer-3 alternate to IEEE Std. 802.1x/EAP. Regardless, the security model ensures that, prior to a join process, packets from a untrusted device are controlled in volume and in reachability. In particular, a PANA stack should be separated from the main protocol stack to avoid attacks during the join process that is introduced in <xref target='rflo'/>. --> </t> <t><t indent="0" pn="section-3.7-8"> The 6TiSCH OperationsublayerSublayer (6top) is a sublayer of a Logical Link Control (LLC) that provides the abstraction of an IP link over a TSCH MAC and schedules packets over TSCH cells, as further discussed in the next sections, providing in particular dynamic cell allocation with the 6top Protocol (6P) <xreftarget='RFC8480'/>.target="RFC8480" format="default" sectionFormat="of" derivedContent="RFC8480"/>. </t><t><t indent="0" pn="section-3.7-9"> The reference stack presented in this document was implemented andinterop-testedinteroperability-tested by aconjunctioncombination ofopensource, IETFopen source, IETF, and ETSI efforts. One goal is to help other bodies to adopt the stack as a whole, making the effort to move to an IPv6-based IoT stack easier. </t><t><t indent="0" pn="section-3.7-10"> For a particular environment, some of the choices that aremadeavailable in this architecture may not be relevant. For instance, RPL is not required for star topologies and mesh-underLayer-2Layer 2 routed networks, and the 6LoWPAN compression may not be sufficient for ultra-constrained cases such as some Low-Power Wide Area (LPWA) networks. In such cases, it is perfectly doable to adopt a subset of the selection that is presented hereafter and then select alternate components to complete the solution wherever needed. </t> </section><section><name>Communication<section numbered="true" removeInRFC="false" toc="include" pn="section-3.8"> <name slugifiedName="name-communication-paradigms-and">Communication Paradigms and Interaction Models</name><t><t indent="0" pn="section-3.8-1"> <xreftarget='sixTTerminology'/>target="sixTTerminology" format="default" sectionFormat="of" derivedContent="Section 2.1"/> provides the terms of Communication Paradigms and InteractionModels,Models inrelationcombination with <xreftarget='RFC3444'>"Ontarget="RFC3444" format="default" sectionFormat="of" derivedContent="RFC3444">"On the Difference between Information Models and Data Models"</xref>. A Communication Paradigmwould beis an abstract view of a protocolexchange,exchange andwould come withhas an Information Model for the information that is being exchanged. In contrast, an Interaction Modelwould beis more refined andcould pointpoints to standard operation such as a Representationalstate transferState Transfer (REST) "GET" operation andwould matchmatches a Data Model for the data that is provided over the protocol exchange. </t><t> Section 2.1.3 of<t indent="0" pn="section-3.8-2"> <xreftarget='I-D.ietf-roll-rpl-industrial-applicability'/>target="I-D.ietf-roll-rpl-industrial-applicability" section="2.1.3" sectionFormat="of" format="default" derivedLink="https://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-02#section-2.1.3" derivedContent="RPL-APPLICABILITY"/> andnextits following sections discuss application-layerparadigms,paradigms such asSource-sink (SS) thatsource-sink, which is aMultipeer to Multipeer (MP2MP)multipeer-to-multipeer model primarily used for alarms and alerts,Publish-subscribe (PS, or pub/sub) thatpublish-subscribe, which is typically used for sensor data, as well asPeer-to-peer (P2P)peer-to-peer andPeer-to-multipeer (P2MP)peer-to-multipeer communications. </t><t><t indent="0" pn="section-3.8-3"> Additional considerations onDuocast -duocast -- one sender, two receivers for redundancy--- and its N-cast generalization are also provided. Those paradigms are frequently used in industrial automation, which is a major use case for IEEEStd.Std 802.15.4 TSCH wireless networks with <xreftarget='ISA100.11a'/>target="ISA100.11a" format="default" sectionFormat="of" derivedContent="ISA100.11a"/> and <xreftarget='WirelessHART'/>, thattarget="WirelessHART" format="default" sectionFormat="of" derivedContent="WirelessHART"/>, which provides a wireless access to <xreftarget='HART'/>target="HART" format="default" sectionFormat="of" derivedContent="HART"/> applications and devices. </t><t><t indent="0" pn="section-3.8-4"> This document focuses on Communication Paradigms and Interaction Models for packet forwarding and TSCH resources (cells) management. Management mechanisms for the TSCH schedule atLink-Layer (one-hop), Network-layerthe link layer (one hop), network layer (multihop along a Track), andApplication-layerapplication layer (remote control) are discussed in <xreftarget='schd'/>. Link-Layertarget="schd" format="default" sectionFormat="of" derivedContent="Section 4.4"/>. Link-layer frame forwarding interactions are discussed in <xreftarget='fwd'/>,target="fwd" format="default" sectionFormat="of" derivedContent="Section 4.6"/>, andNetwork-layer Packetnetwork-layer packet routing is addressed in <xreftarget='rtg'/>.target="rtg" format="default" sectionFormat="of" derivedContent="Section 4.7"/>. </t> </section> </section> <sectionanchor='dd'><name>Architectureanchor="dd" numbered="true" removeInRFC="false" toc="include" pn="section-4"> <name slugifiedName="name-architecture-components">Architecture Components</name> <sectionanchor='RPLvs6lo'><name>6LoWPANanchor="RPLvs6lo" numbered="true" removeInRFC="false" toc="include" pn="section-4.1"> <name slugifiedName="name-6lowpan-and-rpl">6LoWPAN (and RPL)</name><t>A<t indent="0" pn="section-4.1-1">A RPL DODAG is formed of a Root, a collection of routers, and leaves that are hosts. Hosts are nodeswhichthat do not forward packets that they did not generate. RPL-aware leaves will participatetoin RPL to advertise their own addresses, whereas RPL-unaware leaves depend on a connected RPL router to do so. RPL interacts with 6LoWPAN ND at multiple levels, in particular at the Root and in the RPL-unaware leaves. </t> <sectionanchor='leaf'><name>RPL-Unawareanchor="leaf" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.1"> <name slugifiedName="name-rpl-unaware-leaves-and-6low">RPL-Unaware Leaves and 6LoWPAN ND</name><t>RPL<t indent="0" pn="section-4.1.1-1">RPL needs a set of information to advertise a leaf node through a Destination Advertisement Object (DAO) message and establish reachability. </t><t> <xref target='I-D.ietf-roll-unaware-leaves'>"Routing<t indent="0" pn="section-4.1.1-2"><xref target="RFC9010" format="default" sectionFormat="of" derivedContent="RFC9010">"Routing for RPL Leaves"</xref> details the basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN that supports <xreftarget='RFC8505'/>target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> to obtain return connectivity via the RPL network asana RPL-unaware leaf. The leaf indicates that it requires reachability services for the Registered Address from a Routing Registrar by settingaan 'R' flag in the Extended Address Registration Option <xreftarget='RFC8505'/>,target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/>, and it provides a TID that maps toa sequence numberthe "Path Sequence" defined insection 7 of RPL<xreftarget='RFC6550'/>. </t> <t>target="RFC6550" section="6.7.8" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-6.7.8" derivedContent="RFC6550"/>, and its operation is defined in <xreftarget='I-D.ietf-roll-unaware-leaves'/>target="RFC6550" section="7.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-7.2" derivedContent="RFC6550"/>. </t> <t indent="0" pn="section-4.1.1-3"><xref target="RFC9010" format="default" sectionFormat="of" derivedContent="RFC9010"/> also enables the leaf to signal with theRPL InstanceIDRPLInstanceID that it wants to participatetoby using the Opaque field of the EARO. On the backbone, theInstanceIDRPLInstanceID is expected to be mapped to an overlay that matches the RPL Instance, e.g., a Virtual LAN (VLAN) or a virtual routing and forwarding (VRF) instance. </t><t> Though<t indent="0" pn="section-4.1.1-4"> Though, at the time of thiswritingwriting, the above specification enables a model where the separation is possible, this architecture recommendsto collocateco-locating the functions of 6LBR and RPL Root. </t> </section><!-- RPL-Unaware Leaves and 6LoWPAN ND --><sectionanchor='rpllbr'><name>6LBRanchor="rpllbr" numbered="true" removeInRFC="false" toc="include" 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 the6LowPAN6LoWPAN ND <xreftarget='RFC6775'/>,target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/>, information on the 6LBR is disseminated via an Authoritative Border Router Option (ABRO) in RA messages. <xreftarget='RFC8505'/>target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> extends <xreftarget='RFC6775'/>target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/> to enable a registration for routing and proxy ND. The capability to support <xreftarget='RFC8505'/>target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> is indicated in the 6LoWPAN Capability Indication Option (6CIO). The discovery and liveliness of the RPL Root are obtained through RPL <xreftarget='RFC6550'/>target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> 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 are co-located in order that the address of the 6LBRbeis indicated by RPLDIODODAG Information Object (DIO) messages and to associate theunique IDROVR from theEDAR/EDAC <xref target='RFC8505'/>Extended Duplicate Address Request/Confirmation (EDAR/EDAC) exchange <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> with the state that is maintained by RPL. </t><t> Section 7 of<t indent="0" pn="section-4.1.2-3"> <xreftarget='I-D.ietf-roll-unaware-leaves'/>target="RFC9010" section="7" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9010#section-7" derivedContent="RFC9010"/> specifies how the DAO messages are used to reconfirm the registration, thus eliminating a duplication of functionality between DAO and EDAR/EDAC messages, as illustrated in <xreftarget='figReg2'/>. <xref target='I-D.ietf-roll-unaware-leaves'/>target="figReg2" format="default" sectionFormat="of" derivedContent="Figure 6"/>. <xref target="RFC9010" format="default" sectionFormat="of" derivedContent="RFC9010"/> also provides the protocol elements that are needed when the 6LBR and RPL Root functionalities are not co-located. </t><t><t indent="0" pn="section-4.1.2-4"> Even though the Root of the RPL network is integrated with the 6LBR, it is logically separated from the Backbone Router (6BBR) that is used to connect the 6TiSCH LLN to the backbone. This way, the Root has all information from 6LoWPAN ND and RPL about the LLN devices attached to it.</t><t></t> <t indent="0" pn="section-4.1.2-5"> This architecture also expects that the Root of the RPL network (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, for whatever operation the 6BBR performs on the backbone, such as NDproxy,proxy or redistribution in a routing protocol. This relies on an extension of the 6LoWPAN ND registration described in <xreftarget='I-D.ietf-6lo-backbone-router'/>. </t><t>target="RFC8929" format="default" sectionFormat="of" derivedContent="RFC8929"/>. </t> <t indent="0" pn="section-4.1.2-6"> This model supports the movement of a 6TiSCH device across theMulti-Link Subnet,multi-link subnet and allows the proxy registration of 6TiSCH nodes deep into the 6TiSCH LLN by the 6LBR / RPL Root. This is why in <xreftarget='RFC8505'/>target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> the Registered Address is signaled in the Target Address field of theNSNeighbor Solicitation (NS) message as opposed to the IPv6 Source Address, which, in the case of a proxy registration, is that of the 6LBR / RPL Root itself. </t> </section><!--</section> <sectionanchor='gone' title="registration Failures Due to Movement"> <t>Registrationanchor="join" numbered="true" removeInRFC="false" toc="include" pn="section-4.2"> <name slugifiedName="name-network-access-and-addressi">Network Access and Addressing</name> <section anchor="rflo" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1"> <name slugifiedName="name-join-process">Join Process</name> <t indent="0" pn="section-4.2.1-1"> A new device, called the pledge, undergoes the join protocol to become a node in a 6TiSCH network. This usually occurs only once when the6LBR through DAR/DAC messages <xref target="RFC6775"/> may percolate slowlydevice is first powered on. The pledge communicates with the Join Registrar/Coordinator (JRC) of the network throughan LLN mesh,a Join Proxy (JP), a radio neighbor of the pledge. </t> <t indent="0" pn="section-4.2.1-2"> The JP is discovered though MAC-layer beacons. When multiple JPs from possibly multiple networks are visible, using trial andit might happen thaterror until an acceptable position in the right network is obtained becomes inefficient. <xref target="RFC9032" format="default" sectionFormat="of" derivedContent="RFC9032"/> adds a new subtype in themeantime,Information Element that was delegated to the6LoWPAN node moves and registers somewhere else. Both RPLIETF <xref target="RFC8137" format="default" sectionFormat="of" derivedContent="RFC8137"/> and6LoWPAN ND lackprovides visibility into thecapability to indicatenetwork that can be joined and thesame node is registered elsewhere, so as to invalidate states downwillingness of thedeprecated path. </t><t> In its current expressionJP andfunctionality, 6LoWPAN ND considers thattheregistration isRoot to be usedforby thepurpose of DAD only as opposedpledge. </t> <t indent="0" pn="section-4.2.1-3"> The join protocol provides the following functionality: </t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1-4"> <li pn="section-4.2.1-4.1"> Mutual authentication</li> <li pn="section-4.2.1-4.2"> Authorization</li> <li pn="section-4.2.1-4.3"> Parameter distribution tothat of achieving reachability, and as long asthesame node registerspledge over a secure channel</li> </ul> <t indent="0" pn="section-4.2.1-5"> The Minimal Security Framework for 6TiSCH <xref target="RFC9031" format="default" sectionFormat="of" derivedContent="RFC9031"/> defines theIPv6 address,minimal mechanisms required for this join process to occur in a secure manner. The specification defines theprotocolConstrained Join Protocol (CoJP), which isfunctional.used toact asdistribute the parameters to the pledge over aRPL leaf registration protocolsecure session established through OSCORE <xref target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/> andachieve reachability,which describes thedevice must usesecure configuration of thesame TID for all its concurrent registrations, and registrationsnetwork stack. In the minimal setting with pre-shared keys (PSKs), CoJP allows the pledge to join after apast TID should be declined.single round-trip exchange with the JRC. Thestate for an obsolete registration inprovisioning of the6LR, as well asPSK to theRPL routers onpledge and theway, should be invalidated. This can onlyJRC needs to beachieved with the additiondone out of band, through anew Status in'one-touch' bootstrapping process, which effectively enrolls theDAC message, and a new error/clean-up flow in RPL.pledge into the domain managed by the JRC. </t></section> <section anchor='prox' title="Proxy registration"> <t>The 6BBR provides<t indent="0" pn="section-4.2.1-6"> In certain use cases, thecapability to defend an address that'one-touch' bootstrapping isowned by a 6LoWPAN Node,not feasible due to the operational constraints, andattract packetsthe enrollment of the pledge into the domain needs tothat address, whether itoccur in-band. This isdone by proxying ND overhandled through aMulti-Link Subnet, redistributing'zero-touch' extension of theaddress in a routing protocol or advertising it through an alternate proxy registration such as <xref target="RFC6830">the Locator/ID Separation Protocol</xref> (LISP) orMinimal Security Framework for 6TiSCH. The zero-touch extension <xreftarget="RFC6275">Mobility Support in IPv6</xref> (MIPv6). In a LLN, it makes sense to piggybacktarget="I-D.ietf-6tisch-dtsecurity-zerotouch-join" format="default" sectionFormat="of" derivedContent="ZEROTOUCH-JOIN"/> leverages therequest"<xref target="RFC8995" format="title" sectionFormat="of" derivedContent="Bootstrapping Remote Secure Key Infrastructure (BRSKI)"/>" <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> work toproxy/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 thatestablish aSource Link-Layer Address (SLLA) option be present in the message. Inshared secret between amesh scenario where the 6LBR is physically separated from the 6LoWPAN Node, the 6LBR does not ownpledge and theaddress being registered.JRC without necessarily having them belong to a common (security) domain at join time. Thisis why <xref target="I-D.ietf-6lo-backbone-router"/> registershappens through inter-domain communication occurring between theTargetJRC of theNS message as opposed to the Source Address. From another perspective, it may happen, innetwork and theuse casedomain ofa Star topology, thatthe6LR, 6LBR and 6BBR are effectively collapsed and should support 6LoWPAN ND clients. The convergence of efficient ND and 6LoWPAN ND intopledge, represented by asingle protocol is thus highly desirable. </t><t> In any case, as long as the DAD process is not complete forfourth entity, Manufacturer Authorized Signing Authority (MASA). Once theaddress used as source ofzero-touch exchange completes, thepacket, itCoJP exchange defined in <xref target="RFC9031" format="default" sectionFormat="of" derivedContent="RFC9031"/> isagainst the current practice to advertise the SLLA, since this may corruptcarried over theND cache ofsecure session established between thedestination node, as discussed inpledge and the JRC. </t> <t indent="0" pn="section-4.2.1-7"> <xreftarget="RFC4429">Optimistic DAD specification</xref> with regards totarget="figJoin" format="default" sectionFormat="of" derivedContent="Figure 4"/> depicts theTENTATIVE state. </t><t> This may look like a chickenjoin process andan egg problem, but in fact 6LoWPAN ND acknowledges that thewhere a Link-Local Addressthat(LLA) isbased on an EUI-64 address of a LLN node may be autoconfigured without the need for DAD. It results thatused, versus anode could use that Address as source, with an SLLA option in the message if required, to register any other addresses, eitherGlobalor 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-LayerUnicast Address(TLLA)(GUA). </t> <figure anchor="figJoin" suppress-title="false" align="left" pn="figure-4"> <name slugifiedName="name-join-process-in-a-multi-lin">Join Process inthe NS as opposed to the SLLA to installaNeighbor Cache Entry. This would apply to both Efficient ND andMulti-Link Subnet. Parentheses () denote optional exchanges.</name> <artwork align="left" pn="section-4.2.1-8.1"> 6LoWPANND in a very same manner, with the caveat that depending on the nature of the link between the 6LBR and the 6BBR, the 6LBR may resort to classical ND or DHCPv6 to obtain the address that it uses to source the NS registration messages, whether for itself or on behalf of LLN nodes. </t> </section> <section anchor='Rroot' title="RPL Root vs. 6LBR"> <t>6LoWPAN ND is unclear on how the 6LBR is discovered, and how the liveliness of theNode 6LR 6LBRis asserted over time. On the other hand, the discovery and liveliness of the RPL Root are obtained through the RPL protocol. </t><t> WhenJoin Registrar MASA (pledge) (Join Proxy) (Root) /Coordinator (JRC) | | | | | | 6LoWPAN NDis coupled with RPL,|6LoWPAN ND+RPL | IPv6 network |IPv6 network | | LLN link |Route-Over mesh|(the Internet)|(the Internet)| | | | | | | Layer 2 | | | | |Enhanced Beacon| | | | |<--------------| | | | | | | | | | NS (EARO) | | | | | (for the6LBR and RPL Root functionalities are co-locatedLLA) | | | | |-------------->| | | | | NA (EARO) | | | | |<--------------| | | | | | | | | | (Zero-touch | | | | | handshake) | (Zero-touch handshake) | (Zero-touch | | using LLA | using GUA | handshake) | |<------------->|<---------------------------->|<------------>| | | | | | | CoJP Join Req | | | | \ | using LLA | | | | | |-------------->| | | | | | | CoJP Join Request | | | | | using GUA | | | | |----------------------------->| | | C | | | | | | o | | CoJP Join Response | | | J | | using GUA | | | P | |<-----------------------------| | | |CoJP Join Resp | | | | | | using LLA | | | | | |<--------------| | | | / | | | | | </artwork> </figure> </section> <section anchor="rreg" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.2"> <name slugifiedName="name-registration">Registration</name> <t indent="0" pn="section-4.2.2-1"> Once the pledge successfully completes the CoJP exchange and becomes a network node, it obtains the network prefix from neighboring routers and registers its IPv6 addresses. As detailed inorder that<xref target="RPLvs6lo" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, theaddresscombined 6LoWPAN ND 6LBR and Root of the6LBR be indicated byRPLDIO messagesnetwork learn information such as an identifier (device EUI-64 <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/> or a ROVR <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> (from 6LoWPAN ND)) and the updated Sequence Number (from RPL), and perform 6LoWPAN ND proxy registration toassociatetheunique ID from6BBR on behalf of theDAR/DAC exchange withLLN nodes. </t> <t indent="0" pn="section-4.2.2-2"> <xref target="figReg" format="default" sectionFormat="of" derivedContent="Figure 5"/> illustrates thestateinitial IPv6 signaling thatis maintained by RPL. The DAR/DAC exchange becomesenables apreamble6LN tothe DAO messages that are used from then on to reconfirm the registration, thus eliminatingform aduplication of functionality between DAO and DAR messages. </t> </section> <section anchor='Sec' title="Securing the Registration"> <t> A typical attack against IPv6 ND isglobal addressspoofing, whereby a rogue node claims the IPv6 Address of another node inandhijacks its traffic. The threats against IPv6 ND as described in <xref target="RFC3971">SEcure Neighbor Discovery (SEND)</xref> are applicable to 6LoPWAN ND as well, but the solution can not work as the route over network does not permit direct peer to peer communication. </t><t> Additionally SEND requires considerably enlarged ND messagesregister it tocarry 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 inaLLN. </t><t> With6LBR using 6LoWPANND, as illustrated inND <xreftarget='figReg'/>, ittarget="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/>. It ispossible 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,thena 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 possiblecarried over RPL toprotect the ownership of alltheaddresses of a 6LoWPAN Node with a single key,RPL Root andthere should not be a needthen tocarrythecryptographic material more than6BBR. This flow happens just oncetowhen the6LBR. </t><t> The energy constraintaddress isusually 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,created and first registered. </t> <figure anchor="figReg" suppress-title="false" align="left" pn="figure-5"> <name slugifiedName="name-initial-registration-flow-o">Initial Registration Flow over Multi-Link Subnet</name> <artwork align="left" pn="section-4.2.2-3.1"> 6LoWPAN Node 6LR 6LBR 6BBR (RPL leaf) (router) (Root) | | | | | 6LoWPAN NDsecurity 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|6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND | LLN link |Route-Over mesh|Ethernet/serial| Backbone | | | | | RS (mcast) | | | |-------------->| | | |-----------> | | | |------------------> | | | RA (unicast) | | | |<--------------| | | | | | | | NS(EARO) | | | |-------------->| | | | 6LoWPAN ND | Extended DAR | | | |-------------->| | | | | NS(EARO) | | | |-------------->| | | | | NS-DAD | | | |------> | | | | (EARO) | | | | | | | NA(EARO) |<timeout> | | |<--------------| | | Extended DAC | | | |<--------------| | | NA(EARO) | | | |<--------------| | | | | | | </artwork> </figure> <t indent="0" pn="section-4.2.2-4"> <xreftarget="RFC6655">AES-CCM Cipher Suites for Transport Layer Security (TLS)</xref>, thentarget="figReg2" format="default" sectionFormat="of" derivedContent="Figure 6"/> illustrates thecapability to reuserepeating IPv6 signaling thatcode should be considered. </t> --> </section> <section anchor='join'><name>Network Accessenables a 6LN to keep a global address alive andAddressing</name> <section anchor='rflo'><name>Join Process</name> <t> A new device, calledregistered with its 6LBR using 6LoWPAN ND to thepledge, undergoes6LR, RPL to thejoin protocolRPL Root, and then 6LoWPAN ND again tobecome a node in a 6TiSCH network. This usually occurs only once whenthedevice is first powered on. The pledge communicates with6BBR, which avoids repeating theJoin Registrar/Coordinator (JRC) ofExtended DAR/DAC flow across the networkthrough a Join Proxy (JP),when RPL can suffice as aradio neighbor of the pledge. </t><t> The JP is discovered though MAC layer beacons. When multiple JPs from possibly multiple networks are visible, trial and error till an acceptable position inkeep-alive mechanism. </t> <figure anchor="figReg2" suppress-title="false" align="left" pn="figure-6"> <name slugifiedName="name-next-registration-flow-over">Next Registration Flow over Multi-Link Subnet</name> <artwork align="left" pn="section-4.2.2-5.1"> 6LoWPAN Node 6LR 6LBR 6BBR (RPL leaf) (router) (Root) | | | | | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND | LLN link |Route-Over mesh| ant IPv6 link | Backbone | | | | | | | | NS(EARO) | | | |-------------->| | | | NA(EARO) | | | |<--------------| | | | | DAO | | | |-------------->| | | | DAO-ACK | | | |<--------------| | | | | NS(EARO) | | | |-------------->| | | | NA(EARO) | | | |<--------------| | | | | | | | | </artwork> </figure> <t indent="0" pn="section-4.2.2-6">As therightnetworkis obtained becomes ineffficient. <xref target='I-D.ietf-6tisch-enrollment-enhanced-beacon'/> addsbuilds up, anew subtype in the Information Element that was delegatednode should start as a leaf to join theIETF <xref target='RFC8137'/> and provides visibility on theRPL networkthat can be joinedandthe willingness by the JPmay later turn into both a RPL-capable router andthe Root to be used by the pledge. </t><t> The join protocol provides the following functionality: </t><ul spacing='normal'> <li> Mutual authentication</li> <li> Authorization</li> <li> Parameter distributiona 6LR, so as to accept leaf nodes recursively joining thepledge over a secure channel</li> </ul><t>network. </t><t> Minimal Security Framework for 6TiSCH <xref target='I-D.ietf-6tisch-minimal-security'/> defines the minimal mechanisms required for</section> </section> <section anchor="s6Pprot" numbered="true" removeInRFC="false" toc="include" pn="section-4.3"> <name slugifiedName="name-tsch-and-6top">TSCH and 6top</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.3.1"> <name slugifiedName="name-6top">6top</name> <t indent="0" pn="section-4.3.1-1"> 6TiSCH expects a high degree of scalability together with a distributed routing functionality based on RPL. To achieve thisjoin process to occurgoal, the spectrum must be allocated in asecure manner. The specification defines the Constrained Join Protocol (CoJP)way that allows for spatial reuse between zones that will not interfere with one another. In a large and spatially distributed network, a 6TiSCH node isusedoften in a good position todistributedetermine usage of theparameters tospectrum in its vicinity. </t> <t indent="0" pn="section-4.3.1-2"> With 6TiSCH, thepledge over a secure session established through OSCORE <xref target='I-D.ietf-core-object-security'/>, andabstraction of an IPv6 link is implemented as asecure configurationpair of bundles of cells, one in each direction. IP links are only enabled between RPL parents and children. The 6TiSCH operation is optimal when thenetwork stack. Insize of a bundle minimizes both theminimal setting with pre-shared keys (PSKs), CoJP allowsenergy wasted in idle listening and thepledgepacket drops due tojoin aftercongestion loss, while packets are forwarded within an acceptable latency. </t> <t indent="0" pn="section-4.3.1-3"> Use cases for distributed routing are often associated with asingle round-trip exchangestatistical distribution of best-effort traffic withthe JRC.variable needs for bandwidth on each individual link. Theprovisioning6TiSCH operation can remain optimal if RPL parents can adjust, dynamically and with enough reactivity to match the variations of best-effort traffic, thePSKamount of bandwidth that is used tothe pledgecommunicate between themselves and their children, in both directions. In turn, theJRC needsagility tobe done out of band, through a 'one-touch' bootstrapping process, which effectively enrollsfulfill thepledge intoneeds for additional cells improves when thedomain managed bynumber of interactions with other devices and theJRC.protocol latencies are minimized. </t><t> In certain use cases, the 'one touch' bootstrapping<t indent="0" pn="section-4.3.1-4"> 6top isnot feasible due toa logical link control sitting between theoperational constraintsIP layer and theenrollment of the pledge intoTSCH MAC layer, which provides thedomain needs to occur in-band. Thislink abstraction that ishandled through a 'zero-touch' extension of the Minimal Security Frameworkrequired for6TiSCH. Zero touchIP operations. The 6top Protocol, 6P, which is specified in <xreftarget='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> extension leveragestarget="RFC8480" format="default" sectionFormat="of" derivedContent="RFC8480"/>, is one of the'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' [<xref target='I-D.ietf-anima-bootstrapping-keyinfra'/> work to establish a shared secret between a pledge andservices provided by 6top. In particular, theJRC without necessarily having them belong to6top services are available over acommon (security) domain at join time. This happens through inter-domain communication occurring between the JRC of the networkmanagement API that enables an external management entity to schedule cells and slotframes, and allows thedomainaddition ofthe pledge, represented bycomplementary functionality, for instance, afourth entity, Manufacturer Authorized Signing Authority (MASA). Once the zero-touch exchange completes, the CoJP exchange definedScheduling Function that manages a dynamic schedule based on observed resource usage as discussed in <xreftarget='I-D.ietf-6tisch-minimal-security'/> is carried over the secure session established betweentarget="dynsched" format="default" sectionFormat="of" derivedContent="Section 4.4.2"/>. For this purpose, thepledge6TiSCH architecture differentiates "soft" cells andthe JRC."hard" cells. </t><t> <xref target='figJoin'/> depicts the join process<section numbered="true" removeInRFC="false" toc="exclude" pn="section-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 are owned andwheremanaged by aLink-Local Address (LLA) is used, versusseparate scheduling entity (e.g., aGlobal Unicast Address (GUA). </t> <figure anchor='figJoin' suppress-title='false'><name>Join processPCE) that specifies the slotOffset/channelOffset of the cells to be added/moved/deleted, in which case 6top can only act as instructed and may not move hard cells ina Multi-Link Subnet. Parentheses () denote optional exchanges.</name> <artwork><![CDATA[ 6LoWPAN Node 6LR 6LBR Join Registrar MASA (pledge) (Join Proxy) (Root) /Coordinator (JRC) | | | | | | 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network | | LLN link |Route-Over mesh|(the Internet)|(the Internet)| | | | | | | Layer-2 | | | | |enhanced beacon| | | | |<--------------| | | | | | | | | | NS (EARO) | | | | | (fortheLLA) | | | | |-------------->| | | | | NA (EARO) | | | | |<--------------| | | | | | | | | | (Zero-touch | | | | | handshake) | (Zero-touch handshake) | (Zero-touch | | using LLA | using GUA | handshake) | |<------------->|<---------------------------->|<------------>| | | | | | | CoJP Join Req | | | | \ | using LLA | | | | | |-------------->| | | | | | | CoJP Join Request | | | | | using GUA | | | | |----------------------------->| | | C | | | | | | o | | CoJP Join Response | | | J | | using GUA | | | P | |<-----------------------------| | | |CoJP Join Resp | | | | | | using LLA | | | | | |<--------------| | | | / | | | | | ]]></artwork> </figure>TSCH schedule on its own. </t> </section> <sectionanchor='rreg'><name>Registration</name> <t> Oncenumbered="true" removeInRFC="false" toc="exclude" pn="section-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. 6top contains a monitoring process that monitors the performance of cells and that can add and remove soft cells in the TSCH schedule to adapt to the traffic needs, or move one when it performs poorly. To reserve a soft cell, the higher layer does not indicate the exact slotOffset/channelOffset of the cell to add, but rather the resulting bandwidth and QoS requirements. When the monitoring process triggers a cell reallocation, the two neighbor devices communicating over this cell negotiate its new position in the TSCH schedule. </t> </section> </section> <section anchor="missf" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.2"> <name slugifiedName="name-scheduling-functions-and-th">Scheduling Functions 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 is called a Scheduling Function (SF). </t> <t indent="0" pn="section-4.3.2-2"> There may be multiple SFs that react more or less aggressively to the dynamics of the network. </t> <t indent="0" pn="section-4.3.2-3"> An SF may be seen as divided between an upper bandwidth-adaptation logic that is unaware of the particular technology used to obtain and release bandwidth and an underlying service that maps those needs in the actual technology. In the case of TSCH using the 6top Protocol as illustrated in <xref target="fig6P" format="default" sectionFormat="of" derivedContent="Figure 7"/>, this means mapping the bandwidth onto cells. </t> <figure anchor="fig6P" suppress-title="false" align="left" pn="figure-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 | | Bandwidth adaptation | | Bandwidth adaptation | +------------------------+ +------------------------+ | Scheduling Function | | Scheduling Function | | TSCH mapping to cells | | TSCH mapping to cells | +------------------------+ +------------------------+ | 6top cells negotiation | <- 6P -> | 6top cells negotiation | +------------------------+ +------------------------+ Device A Device B </artwork> </figure> <t indent="0" pn="section-4.3.2-5"> The SF relies on 6top services that implement the <xref target="RFC8480" format="default" sectionFormat="of" derivedContent="RFC8480"> 6top Protocol (6P) </xref> to negotiate the precise cells that will be allocated or freed based on the schedule of the peer. For instance, it may be that a peer wants to use a particular timeslot that is free in its schedule, but that timeslot is already in use by the other peer to communicate with a third party on a different cell. 6P enables the peers to find an agreement in a transactional manner that ensures the final consistency of the nodes' state. </t> <t indent="0" pn="section-4.3.2-6"> <xref target="RFC9033" format="default" sectionFormat="of" derivedContent="RFC9033">MSF</xref> is one of the possible Scheduling Functions. MSF uses the rendezvous slot from <xref target="RFC8180" format="default" sectionFormat="of" derivedContent="RFC8180"/> for network discovery, neighbor discovery, and any other broadcast. </t> <t indent="0" pn="section-4.3.2-7"> For basic unicast communication with any neighbor, each node uses a receive cell at a well-known slotOffset/channelOffset, which is derived from a hash of their own MAC address. Nodes can reach any neighbor by installing a transmit (shared) cell with slotOffset/channelOffset derived from the neighbor's MAC address. </t> <t indent="0" pn="section-4.3.2-8"> For child-parent links, MSF continuously monitors the load between parents and children. It then uses 6P to install or remove unicast cells whenever the current schedule appears to be under-provisioned or over-provisioned. </t> </section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.3.3"> <name slugifiedName="name-6top-and-rpl-objective-func">6top and RPL Objective Function Operations</name> <t indent="0" pn="section-4.3.3-1"> An implementation of a <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550">RPL</xref> Objective Function (OF), such as the <xref target="RFC6552" format="default" sectionFormat="of" derivedContent="RFC6552">RPL Objective Function Zero (OF0) </xref> that is used in the <xref target="RFC8180" format="default" sectionFormat="of" derivedContent="RFC8180">Minimal 6TiSCH Configuration</xref> to support RPL over a static schedule, may leverage for its internal computation the information maintained by 6top. </t> <t indent="0" pn="section-4.3.3-2">An OF may require metrics about reachability, such as the Expected Transmission Count (ETX) metric <xref target="RFC6551" format="default" sectionFormat="of" derivedContent="RFC6551"/>. 6top creates and maintains an abstract neighbor table, and this state may be leveraged to feed an OF and/or store OF information as well. A neighbor table entry may contain a set of statistics with respect to that specific neighbor. </t> <t indent="0" pn="section-4.3.3-3"> The neighbor information may include the time when the last packet has been received from that neighbor, a set of cell quality metrics, e.g., received signal strength indication (RSSI) or link quality indicator (LQI), the number of packets sent to the neighbor, or the number of packets received from it. This information can be made available through 6top management APIs and used, for instance, to compute a Rank Increment that will determine the selection of the preferred parent. </t> <t indent="0" pn="section-4.3.3-4"> 6top provides statistics about the underlying layer so the OF can be tuned to the nature of the TSCH MAC layer. 6top also enables the RPL OF to influence the MAC behavior, for instance, by configuring the periodicity of IEEE Std 802.15.4 Extended Beacons (EBs). By augmenting the EB periodicity, it is possible to change the network dynamics so as to improve the support of devices that may change their point of attachment in the 6TiSCH network. </t> <t indent="0" pn="section-4.3.3-5"> Some RPL control messages, such as the DODAG Information Object (DIO), are ICMPv6 messages that are broadcast to all neighbor nodes. With 6TiSCH, the broadcast channel requirement is addressed by 6top by configuring TSCH to provide a broadcast channel, as opposed to, for instance, piggybacking the DIO messages in Layer 2 Enhanced Beacons (EBs), which would produce undue timer coupling among layers and packet size issues, and could conflict with the policy of production networks where EBs are mostly eliminated to conserve energy. </t> </section> <section anchor="sync" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.4"> <name slugifiedName="name-network-synchronization">Network Synchronization</name> <t indent="0" pn="section-4.3.4-1"> Nodes in a TSCH network must be time synchronized. A node keeps synchronized to its time source neighbor through a combination of frame-based and acknowledgment-based synchronization. To maximize battery life and network throughput, it is advisable that RPL ICMP discovery and maintenance traffic (governed by the Trickle timer) be somehow coordinated with the transmission of time synchronization packets (especially with Enhanced Beacons). </t> <t indent="0" pn="section-4.3.4-2"> This could be achieved through an interaction of the 6top sublayer and the RPL Objective Function, or could be controlled by a management entity. </t> <t indent="0" pn="section-4.3.4-3"> Time distribution requires a loop-free structure. Nodes caught in a synchronization loop will rapidly desynchronize from the network and become isolated. 6TiSCH uses a RPL DAG with a dedicated global Instance for the purpose of time synchronization. That Instance is referred to as the Time Synchronization Global Instance (TSGI). The TSGI can be operated in either of the three modes that are detailed in Section <xref target="RFC6550" section="3.1.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1.3" derivedContent="RFC6550"/> of <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550">RPL</xref>, "Instances, DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with independent Roots may be used if all the Roots share a common time source such as the Global Positioning System (GPS). </t> <t indent="0" pn="section-4.3.4-4"> In the absence of a common time source, the TSGI should form a single DODAG with a virtual Root. A backbone network is then used to synchronize and coordinate RPL operations between the Backbone Routers that act as sinks for the LLN. Optionally, RPL's periodic operations may be used to transport the network synchronization. This may mean that 6top would need to trigger (override) the Trickle timer if no other traffic has occurred for such a time that nodes may get out of synchronization. </t> <t indent="0" pn="section-4.3.4-5"> A node that has not joined the TSGI advertises a MAC-level Join Priority of 0xFF to notify its neighbors that is not capable of serving as time parent. A node that has joined the TSGI advertises a MAC-level Join Priority set to its DAGRank() in that Instance, where DAGRank() is the operation specified in Section <xref target="RFC6550" section="3.5.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.5.1" derivedContent="RFC6550"/> of <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="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 architecture, whereas RPL enables the propagation of configuration information down the DODAG. This applies to the TSGI as well; a Root is configured, or obtains by unspecified means, the knowledge of the RPLInstanceID for the TSGI. The Root advertises its DagRank in the TSGI, which must be less than 0xFF, as its Join Priority in its IEEE Std 802.15.4 EBs. </t> <t indent="0" pn="section-4.3.4-7"> A node that reads a Join Priority of less than 0xFF should join the neighbor with the lesser Join Priority and use it as time parent. If the node is configured to serve as time parent, then the node should join the TSGI, obtain a Rank in that Instance, and start advertising its own DagRank in the TSGI as its Join Priority in its EBs. </t> </section> <section anchor="slotframes" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.5"> <name slugifiedName="name-slotframes-and-cdu-matrix">Slotframes and CDU Matrix</name> <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. A window of time is defined around the scheduled transmission where the medium must, as much as practically feasible, be free of contending energy to ensure that the medium is free of contending packets when the time comes for a scheduled transmission. One simple way to obtain such a window is to format time and frequencies in cells of transmission of equal duration. This is the method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long Term Evolution (LTE) of cellular networks. </t> <t indent="0" pn="section-4.3.5-2"> The 6TiSCH architecture defines a global concept that is called a Channel Distribution and Usage (CDU) matrix to describe that formatting of time and frequencies. </t> <t indent="0" pn="section-4.3.5-3"> A CDU matrix is defined centrally as part of the network definition. It is a matrix of cells with a height equal to the number of available channels (indexed by channelOffsets) and a width (in timeslots) that is the period of the network scheduling operation (indexed by slotOffsets) for that CDU matrix. There are different models for scheduling the usage of the cells, which place the responsibility of avoiding collisions either on a central controller or on the devices themselves, at an extra cost in terms of energy to scan for free cells (more in <xref target="schd" format="default" sectionFormat="of" derivedContent="Section 4.4"/>). </t> <t indent="0" pn="section-4.3.5-4"> The size of a cell is a timeslot duration, and values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to accommodate for the transmission of a frame and an ack, including the security validation on the receive side, which may take up to a few milliseconds on some device architecture. </t> <t indent="0" pn="section-4.3.5-5"> A CDU matrix iterates over a well-known channel rotation called the hopping sequence. In a given network, there might be multiple CDU matrices that operate with different widths, so they have different durations and represent different periodic operations. It is recommended that all CDU matrices in a 6TiSCH domain operate with the same cell duration and are aligned so as to reduce the chances of interferences from the Slotted ALOHA operations. The knowledge of the CDU matrices is shared between all the nodes and used in particular to define slotframes. </t> <t indent="0" pn="section-4.3.5-6"> A slotframe is a MAC-level abstraction that is common to all nodes and contains a series of timeslots of equal length and precedence. It is characterized by a slotframe_ID and a slotframe_size. A slotframe aligns to a CDU matrix for its parameters, such as number and duration of timeslots. </t> <t indent="0" pn="section-4.3.5-7"> Multiple slotframes can coexist in a node schedule, i.e., a node can have multiple activities scheduled in different slotframes. A slotframe is associated with a priority that may be related to the precedence of different 6TiSCH topologies. The slotframes may be aligned to different CDU matrices and thus have different widths. There is typically one slotframe for scheduled traffic that has the highest precedence and one or more slotframe(s) for RPL traffic. The timeslots in the slotframe are indexed by the slotOffset; the first cell is at slotOffset 0. </t> <t indent="0" pn="section-4.3.5-8"> When a packet is received from a higher layer for transmission, 6top inserts that packet in the outgoing queue that matches the packet best (Differentiated Services <xref target="RFC2474" format="default" sectionFormat="of" derivedContent="RFC2474"/> can therefore be used). At each scheduled transmit slot, 6top looks for the frame in all thepledge successfully completesoutgoing queues that best matches theCoJP protocol and becomescells. If anetwork node,frame is found, itobtainsis given to thenetwork prefix from neighboring routers and registers its IPv6 addresses. As detailedTSCH MAC for transmission. </t> </section> <section anchor="DistRsvTS" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.6"> <name slugifiedName="name-distributing-the-reservatio">Distributing the Reservation of Cells</name> <t indent="0" pn="section-4.3.6-1"> The 6TiSCH architecture introduces the concept of chunks (<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 CDU matrix is formatted into a set of chunks, possibly as illustrated in <xreftarget='RPLvs6lo'/>,target="fig10" format="default" sectionFormat="of" derivedContent="Figure 8"/>, each of thecombined 6LoWPAN ND 6LBR and Rootchunks identified uniquely by a chunk-ID. The knowledge of this formatting is shared between all theRPL network learn information suchnodes in a 6TiSCH network. It could be conveyed during the join process, codified into a profile document, or obtained using some other mechanism. This is as opposed to Static Scheduling, which refers to thedevice Unique ID (from 6LoWPAN ND)preprogrammed mechanism specified in <xref target="RFC8180" format="default" sectionFormat="of" derivedContent="RFC8180"/> and which existed before theupdated Sequence Number (from RPL),distribution of the chunk formatting. </t> <figure anchor="fig10" align="left" suppress-title="false" pn="figure-8"> <name slugifiedName="name-cdu-matrix-partitioning-in-">CDU Matrix Partitioning 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. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| +-----+-----+-----+-----+-----+-----+-----+ +-----+ ... +-----+-----+-----+-----+-----+-----+-----+ +-----+ chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| +-----+-----+-----+-----+-----+-----+-----+ +-----+ 0 1 2 3 4 5 6 M </artwork> </figure> <t indent="0" pn="section-4.3.6-3"> The 6TiSCH architecture envisions a protocol that enables chunk ownership appropriation whereby a RPL parent discovers a chunk that is not used in its interference domain, claims the chunk, andperform 6LoWPAN ND proxy registrationthen defends it in case another RPL parent would attempt to appropriate it while it is in use. The chunk is the6BBRbasic unit ofbehalfownership that is used in that process. </t> <t indent="0" pn="section-4.3.6-4"> As a result of theLLN nodes. </t> <t> <xref target='figReg'/> illustratesprocess of chunk ownership appropriation, theinitial IPv6 signaling that enables a 6LNRPL parent has exclusive authority toform a global address and registerdecide which cell in the appropriated chunk can be used by which node in its interference domain. In other words, itto a 6LBR using 6LoWPAN ND <xref target='RFC8505'/>,isthen carried over RPL toimplicitly delegated theRPL Root, and thenright to manage the6BBR. This flow happens just once whenportion of theaddressCDU matrix that iscreated and first registered. </t> <figure anchor='figReg' suppress-title='false'><name>Initial Registration Flow over Multi-Link Subnet</name> <artwork><![CDATA[ 6LoWPAN Node 6LR 6LBR 6BBR (RPL leaf) (router) (Root) | | | | | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND | LLN link |Route-Over mesh|Ethernet/serial| Backbone | | | | | RS (mcast) | | | |-------------->| | | |-----------> | | | |------------------> | | | RA (unicast) | | | |<--------------| | | | | | | | NS(EARO) | | | |-------------->| | | | 6LoWPAN ND | Extended DAR | | | |-------------->| | | | | NS(EARO) | | | |-------------->| | | | | NS-DAD | | | |------> | | | | (EARO) | | | | | | | NA(EARO) |<timeout> | | |<--------------| | | Extended DAC | | | |<--------------| | | NA(EARO) | | | |<--------------| | | | | | | ]]></artwork> </figure> <t> <xref target='figReg2'/> illustratesrepresented by therepeating IPv6 signaling that enables a 6LNchunk. </t> <t indent="0" pn="section-4.3.6-5"> Initially, those cells are added tokeepthe heap of free cells, then dynamically placed into existing bundles, into new bundles, or allocated opportunistically for one transmission. </t> <t indent="0" pn="section-4.3.6-6"> Note that aglobal address alive and registered to its 6LBR using 6LoWPAN NDPCE is expected to have precedence in the6LR,allocation, so that a RPL parent would only be able to obtain portions that are not in use by theRPL Root, and then 6LoWPAN ND againPCE. </t> </section> </section> <section anchor="schd" numbered="true" removeInRFC="false" toc="include" pn="section-4.4"> <name slugifiedName="name-schedule-management-mechani">Schedule Management Mechanisms</name> <t indent="0" pn="section-4.4-1"> 6TiSCH uses four paradigms to manage the6BBR, which avoids repeatingTSCH schedule of theExtended DAR/DAC flow acrossLLN nodes: Static Scheduling, Neighbor-to-Neighbor Scheduling, Remote Monitoring and Scheduling Management, and Hop-by-Hop Scheduling. Multiple mechanisms are defined that implement thenetwork when RPLassociated Interaction Models, and they cansuffice as a keep-alive mechanism. </t> <figure anchor='figReg2' suppress-title='false'><name>Next Registration Flow over Multi-Link Subnet</name> <artwork><![CDATA[ 6LoWPAN Node 6LR 6LBR 6BBR (RPL leaf) (router) (Root) | | | | | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND | LLN link |Route-Over mesh| ant IPv6 link | Backbone | | | | | | | | NS(EARO) | | | |-------------->| | | | NA(EARO) | | | |<--------------| | | | | DAO | | | |-------------->| | | | DAO-ACK | | | |<--------------| | | | | NS(EARO) | | | |-------------->| | | | NA(EARO) | | | |<--------------| | | | | | | | | ]]></artwork> </figure> <t>Asbe combined and used in thenetwork builds up, a node should start as a leafsame LLN. Which mechanism(s) tojoinuse depends on application requirements. </t> <section anchor="mini" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.1"> <name slugifiedName="name-static-scheduling">Static Scheduling</name> <t indent="0" pn="section-4.4.1-1"> In theRPL network, and may later turn into bothsimplest instantiation of aRPL-capable router and6TiSCH network, a6LR, so as to accept leafcommon fixed schedule may be shared by all nodesto recursively joinin the network.</t> </section> </section> <!--"Network Access and Addressing" --> <section anchor='s6Pprot'><name>TSCHCells are shared, and6top</name> <section><name>6top</name> <t> 6TiSCH expectsnodes contend for slot access in ahigh degreeSlotted ALOHA manner. </t> <t indent="0" pn="section-4.4.1-2"> A static TSCH schedule can be used to bootstrap a network, as an initial phase during implementation or as a fall-back mechanism in case ofscalability together withnetwork malfunction. This schedule is preestablished, for instance, decided by adistributed routing functionalitynetwork administrator based onRPL. To achieve this goal, the spectrum mustoperational needs. It can beallocated in a way that allows for spatial reuse between zones that will not interfere with one another. In a large and spatially distributed network,preconfigured into the nodes, or, more commonly, learned by a6TiSCHnodeis often inwhen joining the network using standard IEEE Std 802.15.4 Information Elements (IE). Regardless, the schedule remains unchanged after the node has joined agood position to determine usage ofnetwork. RPL is used on thespectrumresulting network. This "minimal" scheduling mechanism that implements this paradigm is detailed inits vicinity.<xref target="RFC8180" format="default" sectionFormat="of" derivedContent="RFC8180"/>. </t><t> With 6TiSCH,</section> <section anchor="dynsched" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.2"> <name slugifiedName="name-neighbor-to-neighbor-schedu">Neighbor-to-Neighbor Scheduling</name> <t indent="0" pn="section-4.4.2-1"> In theabstractionsimplest instantiation ofan IPv6 link is implemented asapair of bundles of cells, one in each direction. IP Links are only enabled between RPL parents and children. The6TiSCHoperation is optimal when the size ofnetwork described in <xref target="mini" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/>, nodes may expect abundle is such that bothpacket at any cell in the schedule and will waste energywasted inidlelistening and the packet drops due to congestion loss are minimized, while packets are forwarded within an acceptable latency. </t> <t> Use cases for distributed routing are often associated withlistening. In astatistical distributionmore complex instantiation ofbest-effort traffic with variable needs for bandwidth on each individual link. Thea 6TiSCHoperation can remain optimal if RPL parents can adjust dynamically, and with enough reactivity to match the variationsnetwork, a matching portion ofbest-effort traffic,theamount of bandwidth thatschedule isusedestablished between peers tocommunicatereflect the observed amount of transmissions betweenthemselvesthose nodes. The aggregation of the cells between a node andtheir children, in both directions. In turn,a peer forms a bundle that theagility6top sublayer uses tofulfillimplement theneedsabstraction of a link foradditional cells improves whenIP. The bandwidth on that link is proportional to the number ofinteractions with other devices andcells in theprotocol latencies are minimized.bundle. </t><t> 6top is a logical link control sitting between the IP layer and<t indent="0" pn="section-4.4.2-2"> If theTSCH MAC layer, which providessize of a bundle is configured to fit an average amount of bandwidth, peak traffic is dropped. If thelink abstraction thatsize isrequiredconfigured to allow forIP operations. The 6top protocol, 6P, whichpeak emissions, energy isspecifiedwasted idle listening. </t> <t indent="0" pn="section-4.4.2-3"> As discussed in more detail in <xreftarget='RFC8480'/>, is one oftarget="s6Pprot" format="default" sectionFormat="of" derivedContent="Section 4.3"/>, theservices provided by 6top. In particular,<xref target="RFC8480" format="default" sectionFormat="of" derivedContent="RFC8480">6top Protocol</xref> specifies the6top services are available over a management API that enables an external management entityexchanges between neighbor nodes toschedulereserve soft cellsand slotframes, and allowsto transmit to one another, possibly under theadditioncontrol ofcomplementary functionality, for instancea Scheduling Functionthat manages a dynamic(SF). Because this reservation is done without global knowledge of the schedulemanagement based on observed resource usageof the other nodes in the LLN, scheduling collisions are possible. </t> <t indent="0" pn="section-4.4.2-4"> And as discussed in <xreftarget='dynsched'/>. For this purpose, the 6TiSCH architecture differentiates "soft" cells and "hard" cells. </t> <section><name>Hard Cells</name> <t> "Hard" cells are cells that are ownedtarget="missf" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>, an optional SF is used to monitor bandwidth usage andmanagedto perform requests for dynamic allocation bya separate scheduling entity (e.g., a PCE) that specifiestheslotOffset/channelOffset6top sublayer. The SF component is not part of thecells6top sublayer. It may be co-located on the same device or may be partially or fully offloaded to an external system. The <xref target="RFC9033" format="default" sectionFormat="of" derivedContent="RFC9033"> "6TiSCH Minimal Scheduling Function (MSF)"</xref> provides a simple SF that can beadded/moved/deleted,used by default by devices that support dynamic scheduling of soft cells. </t> <t indent="0" pn="section-4.4.2-5"> Monitoring and relocation is done inwhich casethe 6topcan only actsublayer. For the upper layer, the connection between two neighbor nodes appears asinstructed, and may not move harda number of cells. Depending on traffic requirements, the upper layer can request 6top to add or delete a number of cellsinscheduled to a particular neighbor, without being responsible for choosing theTSCH schedule on its own.exact slotOffset/channelOffset of those cells. </t> </section><section><name>Soft Cells</name> <t> In contrast, "soft" cells are cells that 6top can manage locally. 6top contains<section anchor="topint" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.3"> <name slugifiedName="name-remote-monitoring-and-sched">Remote Monitoring and Schedule Management</name> <t indent="0" pn="section-4.4.3-1"> Remote Monitoring and Schedule Management refers to a DetNet/SDN model whereby an NME and amonitoring process which monitorsscheduling entity, associated with a PCE, reside in a central controller and interact with theperformance of cells,6top sublayer to control IPv6 links andcan add, remove soft cellsTracks (<xref target="ontrk" format="default" sectionFormat="of" derivedContent="Section 4.5"/>) inthe TSCH schedulea 6TiSCH network. The composite centralized controller can assign physical resources (e.g., buffers and hard cells) toadapta particular Track to optimize thetraffic needs, or move one when it performs poorly. To reservereliability within asoft cell,bounded latency for a well-specified flow. </t> <t indent="0" pn="section-4.4.3-2"> The work in thehigher layer does6TiSCH Working Group focused on nondeterministic traffic and did notindicateprovide theexact slotOffset/channelOffset ofgeneric data model necessary for thecellcontroller toadd, but rather the resulting bandwidthmonitor andQoS requirements. When the monitoring process triggers a cell reallocation, the two neighbor devices communicating over this cell negotiate its new position inmanage resources of theTSCH schedule.6top sublayer. This is deferred to future work, see <xref target="unchartered-tracks" format="default" sectionFormat="of" derivedContent="Appendix A.1.2"/>. </t></section> </section> <section anchor='missf'><name>Scheduling Functions<t indent="0" pn="section-4.4.3-3"> With respect to centralized routing and scheduling, it is envisioned that the6top protocol</name> <t>In the caserelated component ofsoft cells, the cell management entity that controlsthedynamic attribution6TiSCH architecture would be an extension ofcells to adapt tothedynamics<xref target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655">DetNet architecture</xref>, which studies Layer 3 aspects ofvariable rate flowsDeterministic Networks and covers networks that span multiple Layer 2 domains. </t> <t indent="0" pn="section-4.4.3-4"> The DetNet architecture iscalledaScheduling Function (SF). </t> <t> There may be multiple SFs with more or less aggressive reaction to the dynamicsform ofthe network. </t> <t> An SF may be seen as divided between an upper bandwidth adaptation logic thatSoftware-Defined Networking (SDN) architecture and isnot awarecomposed of three planes: a (User) Application Plane, a Controller Plane (where theparticular technology that is used to obtain and release bandwidth,PCE operates), andan underlying service that maps those needs in the actual technology,a Network Plane, whichmeans mapping the bandwidth onto cells in the casecan represent a 6TiSCH LLN. </t> <t indent="0" pn="section-4.4.3-5"> <xref target="RFC7426" format="default" sectionFormat="of" derivedContent="RFC7426">"Software-Defined Networking (SDN): Layers and Architecture Terminology"</xref> proposes a generic representation ofTSCH usingthe6top protocol as illustratedSDN architecture that is reproduced in <xreftarget='fig6P'/>.target="RFC7426archi" format="default" sectionFormat="of" derivedContent="Figure 9"/>. </t> <figureanchor='fig6P' suppress-title='false'><name>SF/6P stack in 6top</name> <artwork><![CDATA[ +------------------------+ +------------------------+align="center" anchor="RFC7426archi" suppress-title="false" pn="figure-9"> <name slugifiedName="name-sdn-layers-and-architecture">SDN Layers and Architecture Terminology per RFC 7426</name> <artwork align="left" pn="section-4.4.3-6.1"> o--------------------------------o |Scheduling Function| |Scheduling Function+-------------+ +----------+ | | | Application | | Service | | | +-------------+ +----------+ | | Application Plane | o---------------Y----------------o | *-----------------------------Y---------------------------------* | Network Services Abstraction Layer (NSAL) | *------Y------------------------------------------------Y-------* | | | Service Interface | | | o------Y------------------o o---------------------Y------o | | Control Plane | | Management Plane | | | +----Y----+ +-----+ | | +-----+ +----Y----+ | | | Service | | App | | | | App | | Service | | | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | | | | | | | | | | *----Y-----------Y----* | | *---Y---------------Y----* | | | Control Abstraction | | | | Management Abstraction | | | | Layer (CAL) | | | | Layer (MAL) | | | *----------Y----------* | | *----------Y-------------* | | | | | | | o------------|------------o o------------|---------------o | | | CP | MP | Southbound | Southbound | Interface | Interface | | *------------Y---------------------------------Y----------------* | Device and resource Abstraction Layer (DAL) | *------------Y---------------------------------Y----------------* | |Bandwidth adaptation| |Bandwidth adaptation|+------------------------+ +------------------------+o-------Y----------o +-----+ o--------Y----------o |Scheduling Function| |Scheduling FunctionForwarding Plane | |TSCH mapping to cellsApp | |TSCH mapping to cellsOperational Plane |+------------------------+ +------------------------+|6top cells negotiation|<- 6P ->o------------------o +-----+ o-------------------o |6top cells negotiation|+------------------------+ +------------------------+ Device ANetwork DeviceB ]]></artwork>| +---------------------------------------------------------------+ </artwork> </figure><t> The SF relies on 6top services that implement the <xref target='RFC8480'> 6top Protocol (6P) </xref> to negotiate the precise cells that will be allocated or freed based on the schedule<t indent="0" pn="section-4.4.3-7">The PCE establishes end-to-end Tracks ofthe peer. It may be for instance that a peer wants to use a particular time slot that is free in its schedule, but that timeslot is alreadyhard cells, which are described inuse by the other peer for a communication with a third party on a different cell. 6P enables the peers to find an agreementmore detail ina transactional manner that ensures the final consistency of the nodes state. </t> <t><xreftarget='I-D.ietf-6tisch-msf'>MSF</xref>target="trkfwd" format="default" sectionFormat="of" derivedContent="Section 4.6.1"/>. </t> <t indent="0" pn="section-4.4.3-8"> The DetNet work isone of the possible scheduling functions. MSF uses the rendez-vous slot from <xref target='RFC8180'/>expected to enable end-to-end deterministic paths across heterogeneous networks. This can be, fornetwork discovery, neighbor discovery,instance, a 6TiSCH LLN andany other broadcast.an Ethernet backbone. </t><t> For basic unicast communication with any neighbor, each node uses<t indent="0" pn="section-4.4.3-9">This model fits the 6TiSCH extended configuration, whereby areceive cell at6BBR federates multiple 6TiSCH LLNs in awell-known slotOffset/channelOffset, derived fromsingle subnet over ahash of their own MAC address. Nodesbackbone that canreach any neighbor by installing a transmit (shared) cell with slotOffset/channelOffset derived frombe, for instance, Ethernet or Wi-Fi. In that model, 6TiSCH 6BBRs synchronize with one another over theneighbor's MAC address.backbone, so as to ensure that the multiple LLNs that form the IPv6 subnet stay tightly synchronized. </t><t> For child-parent links, MSF continuously monitors<t indent="0" pn="section-4.4.3-10"> If theload to/from parents and children. Itbackbone is deterministic, thenuses 6P to install/remove unicast cells wheneverthecurrent schedule appears to be under-/over- provisioned. </t> </section> <section><name>6top and RPL Objective Function operations</name> <!-- 8.1.1. Support to RPL Neighbor DiscoveryBackbone Router ensures that the end-to-end deterministic behavior is maintained between the LLN andParent Selection --> <t> An implementationthe backbone. It is the responsibility of the PCE to compute a<xref target='RFC6550'>RPL</xref> Objective Function (OF), such asdeterministic path end to end across the<xref target='RFC6552'> RPL Objective Function Zero (OF0) </xref> thatTSCH network and an IEEE Std 802.1 TSN Ethernet backbone, and it isused inthe<xref target='RFC8180'> Minimal 6TiSCH Configuration </xref>responsibility of DetNet tosupport RPL overenable end-to-end deterministic forwarding. </t> </section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.4.4"> <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 astatic schedule, may leverage, for its internal computation, the information maintained<xref target="ontrk" format="default" sectionFormat="of" derivedContent="Section 4.5">Track</xref> to one or more destination(s) that are multiple hops away by6top. </t> <t>An OF may require metrics about reachability, such asinstalling soft cells at each intermediate node. This forms a Track of soft cells. A Track SF above theExpected Transmission Count (ETX) metric <xref target='RFC6551'/>.6topcreates and maintains an abstract neighbor table,sublayer of each node on the Track is needed to monitor these soft cells andthis state may be leveragedtrigger relocation when needed. </t> <t indent="0" pn="section-4.4.4-2"> This hop-by-hop reservation mechanism is expected tofeed an OF and/or store OF information as well. A neighbor table entry may containbe similar in essence to <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/> and/or <xref target="RFC4080" format="default" sectionFormat="of" derivedContent="RFC4080"/> and <xref target="RFC5974" format="default" sectionFormat="of" derivedContent="RFC5974"/>. The protocol for aset of statistics with respectnode tothat specific neighbor.trigger hop-by-hop scheduling is not yet defined. </t><t></section> </section> <section anchor="ontrk" numbered="true" removeInRFC="false" toc="include" pn="section-4.5"> <name slugifiedName="name-on-tracks">On Tracks</name> <t indent="0" pn="section-4.5-1"> Theneighbor information may include the time whenarchitecture introduces thelast packet has been receivedconcept of a Track, which is a directed path fromthat neighbor,aset of cell quality metrics, e.g., received signal strength indication (RSSI)source 6TiSCH node to one orlink quality indicator (LQI),more destination 6TiSCH node(s) across a 6TiSCH LLN. </t> <t indent="0" pn="section-4.5-2"> A Track is thenumber6TiSCH instantiation ofpackets sent totheneighbor or the numberconcept ofpackets received from it. This information can be made available through 6top management APIs and useda deterministic path as described in <xref target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655"/>. Constrained resources such as memory buffers are reserved forinstancethat Track in intermediate 6TiSCH nodes tocomputeavoid loss related to limited capacity. A 6TiSCH node along aRank Increment that will determine the selectionTrack not only knows which bundles ofthe preferred parent. </t> <t> 6top provides statistics about the underlying layer so the OF can be tunedcells it should use tothe nature of the TSCH MAC layer. 6topreceive packets from a previous hop but alsoenables the RPL OF to influence the MAC behavior, for instance by configuring the periodicity of IEEE Std. 802.15.4 Extended Beacons (EBs). By augmenting the EB periodicity,knows which bundle(s) itis possibleshould use tochange the network dynamics so assend packets toimprove the support of devices that may change their point of attachment inits next hop along the6TiSCH network.Track. </t><!-- PT: I took<section numbered="true" removeInRFC="false" toc="include" pn="section-4.5.1"> <name slugifiedName="name-general-behavior-of-tracks">General Behavior ofthe text about time source; the way we do itTracks</name> <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 abit reverse: we have an Instancepacket that isused for time sourcing, and the preferred parent becomes the time source. If we change preferred parent we use the new one asinjected in a Track will progress in due timesource --> <t> Some RPL control messages, such as the DODAG Information Object (DIO) are ICMPv6 messages that are broadcast toallneighbor nodes. With 6TiSCH,thebroadcast channel requirement is addressed by 6top by configuring TSCHway toprovidedestination. </t> <t indent="0" pn="section-4.5.1-2"> Multiple cells may be scheduled in abroadcast channel, as opposed to,Track forinstance, piggybackingtheDIO messagestransmission of a single packet, inLayer-2 Enhanced Beacons (EBs),whichwould produce undue timer coupling among layers, packet size issues and could conflict withcase thepolicynormal operation ofproduction networks where EBsIEEE Std 802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the acknowledgment may be omitted in some cases, for instance, if there is no scheduled cell for a possible retry. </t> <t indent="0" pn="section-4.5.1-3"> There aremostly eliminatedseveral benefits for using a Track to forward a packet from a source node toconserve energy. </t> <!--t> IntheTSCH schedule,destination node: </t> <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-4.5.1-4"> <li pn="section-4.5.1-4.1" derivedCounter="1."> Track Forwarding, as further described in <xref target="trkfwd" format="default" sectionFormat="of" derivedContent="Section 4.6.1"/>, is a Layer 2 forwarding scheme, which introduces less process delay and overhead than a Layer 3 forwarding scheme. Therefore, LLN devices can save more energy and resources, which is critical for resource-constrained devices. </li> <li pn="section-4.5.1-4.2" derivedCounter="2."> Since channel resources, i.e., bundles of cells, have been reserved for communications between 6TiSCH nodes of eachcell has the IEEE Std. 802.15.4e LinkType attribute. Setting the LinkType to ADVERTISING indicates that the cell MAY be used to send an Enhanced Beacon. When a node forms its Enhanced Beacon,hop on thecell, with LinkType=ADVERTISING, SHOULD be included inTrack, theFrameAndLinkIE,throughput andits LinkOption field SHOULD be set tothecombinationmaximum latency of"Receive"the traffic along a Track are guaranteed, and"Timekeeping". The receiver oftheEnhanced Beacon MAY be listening atjitter is minimized. </li> <li pn="section-4.5.1-4.3" derivedCounter="3."> By knowing the scheduled timeslots of incoming bundle(s) and outgoing bundle(s), 6TiSCH nodes on a Track could save more energy by staying in sleep state during inactive slots. </li> <li pn="section-4.5.1-4.4" derivedCounter="4."> Tracks are protected from interfering with one another if a cell is scheduled toget the Enhanced Beacon ([IEEE Std. 802154e]). 6top takes this way to establish broadcast channel, which not only allows TSCHbelong tobroadcast 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 messageat most one Track, and congestion loss isinserted into the queue associated withavoided if at most one packet can be presented to thecells which LinkType is setMAC toADVERTISING. Then, taking advantage ofuse that cell. Tracks enhance thebroadcast cell feature established with FrameAndLinkIE (as described above),reliability of transmissions and thus further improve theRPL control message can be receivedenergy consumption in LLN devices byneighbors, which enablesreducing themaintenancechances ofRPL DODAGs. </t> <t>retransmission. </li> </ol> </section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.5.2"> <name slugifiedName="name-serial-track">Serial Track</name> <t indent="0" pn="section-4.5.2-1"> ALinkOption combining "Receive" and "Timekeeping" bits indicates toSerial (or simple) Track is thereceivers6TiSCH version of a circuit: a bundle of cells that are programmed to receive (RX-cells) is uniquely paired with a bundle ofthe Enhanced Beaconcells thatthe cell MUSTare set to transmit (TX-cells), representing a Layer 2 forwarding state that can be used regardless of the network-layer protocol. A Serial Track is thus formed end-to-end as abroadcast cell. The frequencysuccession ofsending Enhanced Beacons or other broadcast messages bypaired bundles: a receive bundle from theupper layer is determined byprevious hop and a transmit bundle to thetimers associated withnext hop along themessages.Track. </t> <t indent="0" pn="section-4.5.2-2"> Forexample,a given iteration of thetransmissiondevice schedule, the effective channel ofEnhance Beaconsthe cell istriggeredobtained by looping through atimerwell-known hopping sequence beginning at Epoch time and starting at the cell's channelOffset, which results in6top; transmission ofaDIO messagerotation of the frequency that istriggered byused for transmission. The bundles may be computed so as to accommodate both variable rates and retransmissions, so they might not be fully used in thetrickle timeriteration ofRPL. </t-->the schedule. </t> </section> <sectionanchor='sync'><name>Network Synchronization</name> <t> Nodes in a TSCH network must be time synchronized. A node keeps synchronizednumbered="true" removeInRFC="false" toc="include" pn="section-4.5.3"> <name slugifiedName="name-complex-track-with-replicat">Complex Track with Replication and Elimination</name> <t indent="0" pn="section-4.5.3-1"> The art of Deterministic Networks already includes packet replication and elimination techniques. Example standards include the Parallel Redundancy Protocol (PRP) and the High-availability Seamless Redundancy (HSR) <xref target="IEC62439" format="default" sectionFormat="of" derivedContent="IEC62439"/>. Similarly, and as opposed toits time source neighbor throughacombinationSerial Track that is a sequence offrame-basednodes andacknowledgment-based synchronization. To maximize battery lifelinks, a Complex Track is shaped as a directed acyclic graph towards one or more destination(s) to support multipath forwarding andnetwork throughput,route around failures. </t> <t indent="0" pn="section-4.5.3-2"> A Complex Track may branch off over noncongruent branches for the purpose of multicasting and/or redundancy, in which case, itis advisable that RPL ICMP discovery and maintenance traffic (governed byreconverges later down thetrickle timer) be somehow coordinated withpath. This enables thetransmissionPacket Replication, Elimination, and Ordering Functions (PREOF) defined by DetNet. Packet ARQ, Replication, Elimination, and Overhearing (PAREO) adds radio-specific capabilities oftime synchronization packets (especially with enhanced beacons). </t> <t> This could be achieved through an interactionLayer 2 ARQ and promiscuous listening to redundant transmissions to compensate for the lossiness of the6top sublayermedium andthe RPL objective Function, or could be controlled by a management entity. </t> <!-- TW: Conceptmeet industrial expectations ofTSGI developed in separate standards-Track draft? --> <t> Time distribution requiresaloop-free structure. Nodes taken inRAW network. Combining PAREO and PREOF, asynchronization loop will rapidly desynchronize fromTrack may extend beyond thenetwork and become isolated.6TiSCHuses a RPL DAG withnetwork into adedicated global Instance forlarger DetNet network. </t> <t indent="0" pn="section-4.5.3-3"> In thepurposeart oftime synchronization. That InstanceTSCH, a path does not necessarily support PRE, but it isreferred toalmost systematically multipath. This means that a Track is scheduled so as to ensure that each hop has at least two forwarding solutions, and theTime Synchronization Global Instance (TSGI). The TSGI can be operated in either offorwarding decision is to try the3 modes that are detailedpreferred one and use the other insection 3.1.3case of<xref target='RFC6550'>RPL</xref>, "Instances, DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with independent RootsLayer 2 transmission failure as detected by ARQ. Similarly, at each 6TiSCH hop along the Track, the PCE maybe usedschedule more than one timeslot for a packet, so as to support Layer 2 retries (ARQ). It is also possible that the field device only uses the second branch ifallsending over theRoots sharefirst branch fails. </t> </section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.5.4"> <name slugifiedName="name-detnet-end-to-end-path">DetNet End-to-End Path</name> <t indent="0" pn="section-4.5.4-1"> Ultimately, DetNet should enable extending acommon time source such asTrack beyond theGlobal Positioning System (GPS). </t> <t>6TiSCH LLN as illustrated in <xref target="elifig" format="default" sectionFormat="of" derivedContent="Figure 10"/>. Inthe absence ofthat example, acommon time source, the TSGI should formTrack is laid out from asingle DODAG withfield device in avirtual Root. A backbone6TiSCH networkis then usedtosynchronize and coordinate RPL operations between the backbone routersan IoT gateway thatact as sinks foris located on an 802.1 Time-Sensitive Networking (TSN) backbone. A 6TiSCH-aware DetNet service layer handles theLLN. Optionally, RPL's periodic operations may be used to transportPacket Replication, Elimination, and Ordering Functions over thenetwork synchronization. This may meanDODAG that6top would need to trigger (override) the trickle timer if no other traffic has occurred for suchforms atime that nodes may get out of synchronization.Track. </t><t> A node that has not joined<t indent="0" pn="section-4.5.4-2"> The Replication function in theTSGI advertises6TiSCH Node sends aMAC level Join Prioritycopy of0xFF to notify its neighbors that is not capableeach packet over two different branches, and the PCE schedules each hop ofserving as time parent. A nodeboth branches so thathas joinedtheTSGI advertises a MAC level Join Priority set to its DAGRank()two copies arrive inthat Instance, where DAGRank() isdue time at theoperation specified in section 3.5.1 of <xref target='RFC6550'/>, "Rank Comparison". </t> <!-- TW: Official request made to move alter IEEE Std. 802.15.4e text. Maybe remove last sentence? --> <t> The provisioninggateway. In case of aRPL Root is outloss on one branch, hopefully the other copy ofscope for both RPL and this Architecture, whereas RPL enables to propagate configuration information downtheDODAG. This appliespacket still makes it in due time. If two copies make it to theTSGI as well; a Root is configured or obtains by unspecified meansIoT gateway, theknowledge ofElimination function in theRPLInstanceID forgateway ignores theTSGI.extra packet and presents only one copy to upper layers. </t> <figure align="center" anchor="elifig" suppress-title="false" pn="figure-10"> <name slugifiedName="name-example-end-to-end-detnet-t">Example End-to-End DetNet Track</name> <artwork align="left" pn="section-4.5.4-3.1"> +-=-=-+ | IoT | | G/W | +-=-=-+ ^ <=== Elimination Track branch | | +-=-=-=-+ +-=-=-=-=+ Subnet backbone | | +-=|-=+ +-=|-=+ | | | Backbone | | | Backbone o | | | Router | | | Router +-=/-=+ +-=|-=+ o / o o-=-o-=-=/ o o o-=-o-=/ o o o o o o \ / o o LLN o o v <=== Replication o </artwork> </figure> </section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.5.5"> <name slugifiedName="name-cell-reuse">Cell Reuse</name> <t indent="0" pn="section-4.5.5-1"> TheRoot advertises its DagRank in6TiSCH architecture provides theTSGI, that must be less than 0xFF,means to avoid waste of cells asits Join Prioritywell as overflows inits IEEE Std. 802.15.4 Extended Beacons (EB).the transmit bundle of a Track, as follows: </t><t><t indent="0" pn="section-4.5.5-2"> AnodeTX-cell thatreadsis not needed for the current iteration may be reused opportunistically on aJoin Priorityper-hop basis for routed packets. When all ofless than 0xFF should jointheneighbor withframes that were received for a given Track are effectively transmitted, any available TX-cell for that Track can be reused for upper-layer traffic for which the next-hop router matches the next hop along thelesser Join Priority and use it as time parent. IfTrack. In that case, thenodecell that isconfigured to serve as time parent, thenbeing used is effectively a TX-cell from thenode should joinTrack, but theTSGI, obtain a Rank inshort address for the destination is thatInstance and start advertising its own DagRank inof theTSGI as its Join Priority in its EBs.next-hop router. </t></section> <section anchor='slotframes'><name>Slotframes and CDU matrix</name> <t> 6TiSCH enables IPv6 best effort (stochastic) transmissions over<t indent="0" pn="section-4.5.5-3"> It results in aMAC layerframe that isalso capable of scheduled (deterministic) transmissions. A windowreceived in an RX-cell oftime is defined around the scheduled transmission where the medium must, as mucha Track with a destination MAC address set to this node, aspractically feasible, be free of contending energyopposed toensurethe broadcast MAC address that must be extracted from themedium is free of contending packets when time comes for a scheduled transmission. One simple wayTrack and delivered toobtain suchthe upper layer. Note that awindowframe with an unrecognized destination MAC address isto format timedropped at the lower MAC layer andfrequencies in cells of transmission of equal duration. Thisthus is not received at themethod6top sublayer. </t> <t indent="0" pn="section-4.5.5-4"> On the other hand, it might happen thatis adoptedthere are not enough TX-cells in the transmit bundle to accommodate the Track traffic, for instance, if more retransmissions are needed than provisioned. In that case, and if the frame transports an IPv6 packet, then it can be placed for transmission inIEEE Std. 802.15.4 TSCH as well astheLong Term Evolution (LTE) of cellular networks. </t> <t> The 6TiSCH architecture defines a global conceptbundle that iscalled a Channel Distribution and Usage (CDU) matrixused for Layer 3 traffic towards the next hop along the Track. The MAC address should be set todescribe that formatting of time and frequencies, </t> <t> A CDU matrix is defined centrally as part ofthenetwork definition.next-hop MAC address to avoid confusion. </t> <t indent="0" pn="section-4.5.5-5"> It results in a frame that is received over amatrix of cellsLayer 3 bundle that may be in fact associated with aheight equal to the number of available channels (indexed by ChannelOffsets) andTrack. In awidth (in timeslots) thatclassical IP link such as an Ethernet, off-Track traffic is typically in excess over reservation to be routed along theperiod of the network scheduling operation (indexed by slotOffsets) for that CDU matrix. There are different models for scheduling the usage of the cells, which place the responsibility of avoiding collisions either on a central controller ornon-reserved path based on its QoS setting. But with 6TiSCH, since thedevices themselves, at an extra cost in termsuse ofenergythe Layer 3 bundle may be due toscantransmission failures, it makes sense forfree cells (more in <xref target='schd'/>). </t> <t> The size of a cell isthe receiver to recognize atimeslot duration,frame that should be re-Tracked andvalues of 10to15 milliseconds are typical in 802.15.4 TSCHplace it back on the appropriate bundle if possible. A frame is re-Tracked by scheduling it for transmission over the transmit bundle associated with the Track, with the destination MAC address set toaccommodate forbroadcast. </t> </section> </section> <section anchor="fwd" numbered="true" removeInRFC="false" toc="include" pn="section-4.6"> <name slugifiedName="name-forwarding-models">Forwarding Models</name> <t indent="0" pn="section-4.6-1"> By forwarding, this document means thetransmissionper-packet operation that allows delivery of aframe and an ack, including the security validation on the receive side which may take uppacket to afew millisecondsnext hop or an upper layer in this node. Forwarding is based onsome device architecture. </t> <t> A CDU matrix iterates over and over withpreexisting state that was installed as awell-known channel rotation called the hopping sequence. Inresult of agiven network, there might be multiple CDU matrices that operate with different width, so they haverouting computation, see <xref target="rtg" format="default" sectionFormat="of" derivedContent="Section 4.7"/>. 6TiSCH supports three differentdurationsforwarding models: (GMPLS) Track Forwarding, (classical) IPv6 Forwarding, andrepresent different periodic operations. It is recommended that all CDU matrices(6LoWPAN) Fragment Forwarding. </t> <section anchor="trkfwd" numbered="true" removeInRFC="false" toc="include" pn="section-4.6.1"> <name slugifiedName="name-track-forwarding">Track Forwarding</name> <t indent="0" pn="section-4.6.1-1"> Forwarding along a Track can be seen as a Generalized Multiprotocol Label Switching (GMPLS) operation in that the information used to switch a6TiSCH domain operate withframe is not an explicit label but is rather related to other properties of thesameway the packet was received, a particular cellduration and are aligned, so as to reducein thechancescase ofinterferences from6TiSCH. As a result, as long as theSlotted ALOHA operations. The knowledgeTSCH MAC (and Layer 2 security) accepts a frame, that frame can be switched regardless of theCDU matricesprotocol, whether this isshared between all the nodes and used in particular to define slotframes.an IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate protocol such as WirelessHART or ISA100.11a. </t><t><t indent="0" pn="section-4.6.1-2"> Aslotframedata frame that is forwarded along a Track normally has aMAC-level abstractiondestination MAC address that iscommonset toallbroadcast or a multicast address depending on MAC support. This way, the MAC layer in the intermediate nodes accepts the incoming frame andcontains6top switches it without incurring aseries of timeslotschange in the MAC header. In the case ofequal length and precedence. It is characterized by a slotframe_ID, and a slotframe_size. A slotframe alignsIEEE Std 802.15.4, this means effectively toa CDU matrixbroadcast, so that along the Track the short address forits parameters, such as number and durationthe destination oftimeslots.the frame is set to 0xFFFF. </t><t> Multiple slotframes can coexist in<t indent="0" pn="section-4.6.1-3"> There are two modes for anode schedule, i.e.,Track: an IPv6 native mode and anode can have multiple activities scheduled in different slotframes. A slotframeprotocol-independent tunnel mode. </t> <section numbered="true" removeInRFC="false" toc="exclude" pn="section-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 witha priorityflow-dependent metadata thatmay be relatedrefers uniquely to theprecedenceTrack, so the 6top sublayer can place the frame in the appropriate cell without ambiguity. In the case ofdifferent 6TiSCH topologies. The slotframesIPv6 traffic, this flow may bealigned to different CDU matrices and thus have different width. There is typically one slotframe for scheduled traffic that hasidentified using a 6-tuple as discussed in <xref target="RFC8939" format="default" sectionFormat="of" derivedContent="RFC8939"/>. In particular, implementations of this document should support identification of DetNet flows based on thehighest precedenceIPv6 Flow Label field.</t> <t indent="0" pn="section-4.6.1.1-2"> The flow follows a Track that is identified using a RPL Instance (see <xref target="RFC6550" section="3.1.3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-3.1.3" derivedContent="RFC6550"/>), signaled in a RPL Packet Information (more in <xref target="RFC6550" section="11.2.2.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-11.2.2.1" derivedContent="RFC6550"/>) andonethe source address of a packet going down the DODAG formed by a local instance. One or moreslotframe(s) for RPL traffic. The timeslotsflows may be placed in a same Track and theslotframe are indexed byTrack identification (TrackID plus owner) may be placed in an IP-in-IP encapsulation. The forwarding operation is based on theSlotOffset;Track and does not depend on thefirst cell is at SlotOffset 0.flow therein. </t><t> When a packet<t indent="0" pn="section-4.6.1.1-3"> The Track identification isreceived from a higher layer for transmission, 6top inserts that packet in the outgoing queue which matchesvalidated at egress before restoring thepacket best (Differentiated Services <xref target='RFC2474'/> can therefore be used). At each scheduled transmit slot, 6top looks fordestination MAC address (DMAC) and punting to theframe in allupper layer. </t> <t indent="0" pn="section-4.6.1.1-4"><xref target="fig6t" format="default" sectionFormat="of" derivedContent="Figure 11"/> illustrates theoutgoing queuesTrack Forwarding operation thatbest matcheshappens at thecells. If a frame is found, it is given to6top sublayer, below IP. </t> <figure anchor="fig6t" align="left" suppress-title="false" pn="figure-11"> <name slugifiedName="name-track-forwarding-native-mod">Track Forwarding, Native Mode</name> <artwork align="left" pn="section-4.6.1.1-5.1"> | Packet flowing across the network ^ +--------------+ | | | IPv6 | | | +--------------+ | | | 6LoWPAN HC | | | +--------------+ ingress egress | 6top | sets +----+ +----+ restores +--------------+ DMAC to | | | | DMAC to | TSCH MACfor transmission. </t>| brdcst | | | | dest +--------------+ | | | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ Ingress Relay Relay Egress Stack Layer Node Node Node Node </artwork> </figure> </section> <sectionanchor='DistRsvTS'><name>Distributing the reservation of cells</name> <t> The 6TiSCH architecture introducesnumbered="true" removeInRFC="false" toc="exclude" pn="section-4.6.1.2"> <name slugifiedName="name-tunnel-mode">Tunnel Mode</name> <t indent="0" pn="section-4.6.1.2-1"> In tunnel mode, theconcept of chunks (<xref target='sixTTerminology'/>) to distributeframes originate from an arbitrary protocol over a compatible MAC that may or may not be synchronized with theallocation6TiSCH network. An example ofthe spectrum forthis would be awhole group of cells atrouter with atime. The CDU matrixdual radio that isformatted into a set of chunks, possibly as illustrated in <xref target='fig10'/>, eachcapable of receiving and sending WirelessHART or ISA100.11a frames with thechunks identified uniquelysecond radio bya chunk-ID. The knowledge of this formatting is shared between all the nodes in a 6TiSCH network. It could be conveyed during the join process,presenting itself as an access point orcodified intoaprofile document, or obtained using some other mechanism. This is as opposed to static schedulingBackbone Router, respectively. In thatrefersmode, some entity (e.g., PCE) can coordinate with a WirelessHART Network Manager or an ISA100.11a System Manager to specify thepre-programmed mechanismflows thatis specified in <xref target='RFC8180'/> and pre-exists to the distribution of the chunk formatting.are transported. </t> <figureanchor='fig10'><name>CDU matrix Partitioning in Chunks</name>anchor="fig6" align="left" suppress-title="false" pn="figure-12"> <name slugifiedName="name-track-forwarding-tunnel-mod">Track Forwarding, Tunnel Mode</name> <artworkalign='center'> <![CDATA[ +-----+-----+-----+-----+-----+-----+-----+ +-----+ chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| +-----+-----+-----+-----+-----+-----+-----+ +-----+ chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| +-----+-----+-----+-----+-----+-----+-----+ +-----+ ... +-----+-----+-----+-----+-----+-----+-----+ +-----+ chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| +-----+-----+-----+-----+-----+-----+-----+ +-----+ 0 1 2 3 4 5 6 M ]]>align="left" pn="section-4.6.1.2-2.1"> +--------------+ | IPv6 | +--------------+ | 6LoWPAN HC | +--------------+ set restore | 6top | +DMAC+ +DMAC+ +--------------+ to|brdcst to|nexthop | TSCH MAC | | | | | +--------------+ | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ | ingress egress | | | +--------------+ | | | LLN PHY | | | +--------------+ | Packet flowing across the network | | TSCH MAC | | | +--------------+ | DMAC = | DMAC = |ISA100/WiHART | | nexthop v nexthop +--------------+ Source Ingress Egress Destination Stack Layer Node Node Node Node </artwork> </figure><t> The 6TiSCH Architecture envisions a protocol<t indent="0" pn="section-4.6.1.2-3"> In thatenables chunk ownership appropriation whereby a RPL parent discovers a chunkcase, the TrackID thatis not used in its interference domain, claimsidentifies thechunk, and then defends it in case another RPL parent would attempt to appropriate it while itTrack at the ingress 6TiSCH router isin use.derived from the RX-cell. ThechunkDMAC is set to this node, but thebasic unit of ownership that is used inTrackID indicates thatprocess. </t> <t> As a result of the process of chunk ownership appropriation, the RPL parent has exclusive authority to decide which cell intheappropriated chunk canframe must beused by which node in its interference domain. In other words, it is implicitly delegatedtunneled over a particular Track, so therightframe is not passed tomanagetheportion ofupper layer. Instead, theCDU matrix thatDMAC isrepresented by the chunk. <!-- Eliot's review: drop this sentence The RPL parent may thus orchestrate which transmissions occur in any of the cells in the chunk, by allocating cells from the chunkforced toany form of communication (unicast, multicast) in any direction between itselfbroadcast, andits children. --> </t> <t> Initially, those cells are added totheheap of free cells, then dynamically placed into existing bundles, in new bundles, or allocated opportunistically for one transmission. </t> <t> Note that a PCEframe isexpected to have precedence in the allocation, so that a RPL parent would only be able to obtain portions that are not in-use bypassed to thePCE. </t> </section> </section> <!-- <section title="Functional Flows"> <t> <list hangIndent="6" style="hanging"> <t hangText="Join:"></t> <t hangText="Time Synchronization:"></t> <t hangText="Setup6top sublayer forrouting:"></t> <t hangText="PCE reservation:"></t> <t hangText="Distributed reservation:"></t> <t hangText="Dynamic slot (de)allocation:"></t> <t hangText="DSCP mapping:"></t> </list>switching. </t></section> --> <section anchor='schd'><name>Schedule Management Mechanisms</name> <t><t indent="0" pn="section-4.6.1.2-4"> At the egress 6TiSCHuses 4 paradigms to managerouter, theTSCH schedulereverse operation occurs. Based on tunneling information of theLLN nodes: Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring and scheduling management, and Hop-by-hop scheduling. Multiple mechanisms are definedTrack, which may for instance indicate thatimplementtheassociated Interaction Models, and can be combined and used intunneled datagram is an IP packet, thesame LLN. Which mechanism(s)datagram is passed touse depends on application requirements.the appropriate link-layer with the destination MAC restored. </t> </section> <sectionanchor='mini'><name>Static Scheduling</name> <t> Innumbered="true" removeInRFC="false" toc="exclude" pn="section-4.6.1.3"> <name slugifiedName="name-tunneling-information">Tunneling Information</name> <t indent="0" pn="section-4.6.1.3-1"> Tunneling information coming with thesimplest instantiationTrack configuration provides the destination MAC address ofa 6TiSCH network, a common fixed schedule may be shared by all nodes inthenetwork. Cells are shared,egress endpoint as well as the tunnel mode andnodes contendspecific data depending on the mode, forslotinstance, a service accessinpoint for frame delivery at egress. </t> <t indent="0" pn="section-4.6.1.3-2"> If the tunnel egress point does not have aslotted ALOHA manner.MAC address that matches the configuration, the Track installation fails. </t><t> A static TSCH schedule can be used<t indent="0" pn="section-4.6.1.3-3"> If the Layer 3 destination address belongs tobootstrap a network, as an initial phase during implementation, or asthe tunnel termination, then it is possible that the IPv6 address of the destination is compressed at the 6LoWPAN sublayer based on the MAC address. Restoring the wrong MAC address at the egress would then also result in the wrong IP address in the packet after decompression. For that reason, afall-back mechanismpacket can be injected incasea Track only if the destination MAC address is effectively that ofnetwork malfunction. This schedulethe tunnel egress point. It ispre-established,thus mandatory forinstance decided by a network administrator based on operational needs. It can be pre-configured intothenodes, or, more commonly, learned by a node when joiningingress router to validate that thenetwork using standard IEEE Std. 802.15.4 Information Elements (IE). Regardless,MAC address used at theschedule remains unchanged after6LoWPAN sublayer for compression matches that of thenode has joined a network. RPL is used ontunnel egress point before it overwrites it to broadcast. The 6top sublayer at theresulting network. This "minimal" scheduling mechanismtunnel egress point reverts thatimplements this paradigm is detailed in <xref target='RFC8180'/>.operation to the MAC address obtained from the tunnel information. </t> </section> </section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.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. </t> <figure anchor="fig9" align="left" suppress-title="false" pn="figure-13"> <name slugifiedName="name-ip-forwarding">IP Forwarding</name> <artwork align="left" pn="section-4.6.2-2.1"> | Packet flowing across the network ^ +--------------+ | | | IPv6 | | +-QoS+ +-QoS+ | +--------------+ | | | | | | | 6LoWPAN HC | | | | | | | +--------------+ | | | | | | | 6top | | | | | | | +--------------+ | | | | | | | TSCH MAC | | | | | | | +--------------+ | | | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ Source Ingress Egress Destination Stack Layer Node Router Router Node </artwork> </figure> </section> <sectionanchor='dynsched'><name>Neighbor-to-neighbor Scheduling</name> <t> In the simplest instantiation of a 6TiSCH network described innumbered="true" removeInRFC="false" toc="include" pn="section-4.6.3"> <name slugifiedName="name-fragment-forwarding">Fragment Forwarding</name> <t indent="0" pn="section-4.6.3-1"> Considering that, per <xreftarget='mini'/>, nodes may expect a packet at any cell in the schedule and will waste energy idle listening. In a more complex instantiation of a 6TiSCH network, a matching portion of the schedule is established between peers to reflect the observed amount of transmissions between those nodes. The aggregation of the cells between a nodetarget="RFC4944" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4944#section-4" derivedContent="RFC4944"/>, 6LoWPAN packets can be as large as 1280 bytes (the IPv6 minimum MTU) anda peer forms a bundlethat the6top layer uses to implement the abstractionnon-storing mode ofa linkRPL implies source routing, which requires space forIP. The bandwidth onrouting headers, and thatlink is proportional to the number of cellsan IEEE Std 802.15.4 frame with security may carry in thebundle. </t><t> If the sizeorder ofa bundle is configured to fit an average amount80 bytes ofbandwidth, peak traffic is dropped. If the size is configured to allow for peak emissions, energy iseffective payload, an IPv6 packet might bewasted idle listening. </t><t> As discussed infragmented into moredetails in <xref target='s6Pprot'/>, the <xref target='RFC8480'>6top Protocol</xref> specifies the exchanges between neighbor nodes to reserve soft cells to transmit to one another, possibly underthan 16 fragments at thecontrol6LoWPAN sublayer. </t> <t indent="0" pn="section-4.6.3-2"> This level ofa Scheduling Function (SF). Because this reservationfragmentation isdone without global knowledge of the schedule of other nodes inmuch higher than that traditionally experienced over theLLN, scheduling collisions are possible. <!-- 6top defines a monitoring process which continuously TracksInternet with IPv4 fragments, where fragmentation is already known as harmful. </t> <t indent="0" pn="section-4.6.3-3"> In thepacket delivery ratiocase ofsoft cells. It uses these statisticsa multihop route within a 6TiSCH network, hop-by-hop recomposition occurs at each hop totriggerreform thereallocationpacket and route it. This creates additional latency and forces intermediate nodes to store a portion of asoft cellpacket for an undetermined time, thus impacting critical resources such as memory and battery. </t> <t indent="0" pn="section-4.6.3-4"> <xref target="RFC8930" format="default" sectionFormat="of" derivedContent="RFC8930"/> describes a framework for forwarding fragments end-to-end across a 6TiSCH route-over mesh. Within that framework, <xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly" format="default" sectionFormat="of" derivedContent="VIRTUAL-REASSEMBLY"/> details a virtual reassembly buffer mechanism whereby the datagram tag in theschedule, using6LoWPAN fragment is used as anegotiation protocol betweenlabel for switching at theneighbors nodes communicating over6LoWPAN sublayer. </t> <t indent="0" pn="section-4.6.3-5"> Building on this technique, <xref target="RFC8931" format="default" sectionFormat="of" derivedContent="RFC8931"/> introduces a new format for 6LoWPAN fragments thatcell. Inenables themost efficient instantiationsselective recovery of individual fragments and allows for a6TiSCH network, the sizedegree of flow control based on an Explicit Congestion Notification (ECN). </t> <figure anchor="fig7" align="left" suppress-title="false" pn="figure-14"> <name slugifiedName="name-forwarding-first-fragment">Forwarding First Fragment</name> <artwork align="left" pn="section-4.6.3-6.1"> | Packet flowing across the network ^ +--------------+ | | | IPv6 | | +----+ +----+ | +--------------+ | | | | | | | 6LoWPAN HC | | learn learn | +--------------+ | | | | | | | 6top | | | | | | | +--------------+ | | | | | | | TSCH MAC | | | | | | | +--------------+ | | | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ Source Ingress Egress Destination Stack Layer Node Router Router Node </artwork> </figure> <t indent="0" pn="section-4.6.3-7"> In that model, the first fragment is routed based on thebundlesIPv6 header thatimplement the links may be changed dynamicallyis present inorder to adapt tothat fragment. The 6LoWPAN sublayer learns theneed of end-to-end flows routed by RPL. --> </t><t> And as discussed in <xref target='missf'/>, an optional Scheduling Function (SF) is usednext-hop selection, generates a new datagram tag for transmission tomonitor bandwidth usagethe next hop, andperform requests for dynamic allocationstores that information indexed by the6top sublayer.incoming MAC address and datagram tag. TheSF component is not part of the 6top sublayer. It may be collocatednext fragments are then switched based onthe same device or may be partially or fully offloaded to an external system. The <xref target='I-D.ietf-6tisch-msf'> "6TiSCH Minimal Scheduling Function (MSF)"</xref> provides a simple scheduling function that can be used by default by devicesthatsupport dynamic scheduling of soft cells.stored state. </t><t> Monitoring and relocation is done in<figure anchor="fig8" align="left" suppress-title="false" pn="figure-15"> <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 ^ +--------------+ | | | IPv6 | | | +--------------+ | | | 6LoWPAN HC | | replay replay | +--------------+ | | | | | | | 6toplayer. For the upper layer, the connection between two neighbor nodes appears as a number of cells. Depending on traffic requirements,| | | | | | | +--------------+ | | | | | | | TSCH MAC | | | | | | | +--------------+ | | | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ Source Ingress Egress Destination Stack Layer Node Router Router Node </artwork> </figure> <t indent="0" pn="section-4.6.3-9"> A bitmap and an ECN echo in theupper layer can request 6topend-to-end acknowledgment enable the source toadd or deleteresend the missing fragments selectively. The first fragment may be resent to carve anumbernew path in case ofcells scheduled toaparticular neighbor, without being responsible for choosingpath failure. The ECN echo set indicates that theexact slotOffset/channelOffsetnumber ofthose cells.outstanding fragments should be reduced. </t> </section> </section> <sectionanchor='topint'><name>Remote Monitoringanchor="rtg" numbered="true" removeInRFC="false" toc="include" pn="section-4.7"> <name slugifiedName="name-advanced-6tisch-routing">Advanced 6TiSCH Routing</name> <section anchor="pmh" numbered="true" removeInRFC="false" toc="include" pn="section-4.7.1"> <name slugifiedName="name-packet-marking-and-handling">Packet Marking andSchedule Management</name> <!-- <t> The 6top interface document <xref target="I-D.ietf-6tisch-6top-interface"/> specifiesHandling</name> <t indent="0" pn="section-4.7.1-1"> All packets inside a 6TiSCH domain must carry thegeneric data modelRPLInstanceID thatcanidentifies the 6TiSCH topology (e.g., a Track) that is to be usedto monitorfor routing andmanage resourcesforwarding that packet. The location of that information must be the6top sublayer. Abstract methods are suggestedsame foruseall packets forwarded inside the domain. </t> <t indent="0" pn="section-4.7.1-2"> For packets that are routed by amanagement entity in the device. The data model also enables remote control operations onPCE along a Track, the6top sublayer. </t> <t> The capability to interact withtuple formed by 1) (typically) thenode 6top sublayer from multiple hops away can be leveraged for monitoring, scheduling,IPv6 source or (possibly) destination address in the IPv6 header and 2) acombination of thereof. The architecture supports variations onlocal RPLInstanceID in thedeployment model,RPI that serves as TrackID, identify uniquely the Track andfocuses onassociated transmit bundle. </t> <t indent="0" pn="section-4.7.1-3"> For packets that are routed by RPL, that information is theflows rather than whether thereRPLInstanceID that is carried in the RPL Packet Information (RPI), as discussed in <xref target="RFC6550" section="11.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-11.2" derivedContent="RFC6550"/>, "Loop Avoidance and Detection". The RPI is transported by aproxy or a translation operation en-route. </t> <t>RPL Option in the IPv6 Hop-By-Hop Options header <xreftarget="I-D.ietf-6tisch-coap"/> defines an mapping oftarget="RFC6553" format="default" sectionFormat="of" derivedContent="RFC6553"/>. </t> <t indent="0" pn="section-4.7.1-4"> A compression mechanism for the6top setRPL packet artifacts that integrates the compression ofcommands, which is described inIP-in-IP encapsulation and the Routing Header type 3 <xreftarget="I-D.ietf-6tisch-6top-interface"/>, to CoAP resources. This allows an entity to interacttarget="RFC6554" format="default" sectionFormat="of" derivedContent="RFC6554"/> withthe 6top layerthat of the RPI in anode that6LoWPAN dispatch/header type ismultiple hops awayspecified ina RESTful fashion.<xref target="RFC8025" format="default" sectionFormat="of" derivedContent="RFC8025"/> and <xref target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138"/>. </t>--> <!--t> The work at<t indent="0" pn="section-4.7.1-5"> Either way, the6TiSCH WG is focused on non-deterministic trafficmethod anddoes not provideformat used for encoding thegeneric data model that would be necessaryRPLInstanceID is generalized tomonitorall 6TiSCH topological Instances, which include both RPL Instances andmanage resourcesTracks. </t> </section> <section anchor="pmhrre" numbered="true" removeInRFC="false" toc="include" pn="section-4.7.2"> <name slugifiedName="name-replication-retries-and-eli">Replication, Retries, and Elimination</name> <t indent="0" pn="section-4.7.2-1"> 6TiSCH supports the PREOF operations of elimination and reordering of packets along a complex Track, but has no requirement about tagging a sequence number in the6top sublayer. It is recognizedpacket for thatCoAPpurpose. With 6TiSCH, the schedule canbe appropriatetell when multiple receive timeslots correspond tointeract with the 6top layercopies of anode that is multiple hops away across a 6TiSCH mesh.same packet, in which case the receiver may avoid listening to the extra copies once it has received one instance of the packet. </t><t><t indent="0" pn="section-4.7.2-2"> Theentity issuingsemantics of theCoAP requests canconfiguration enable correlated timeslots to bea central scheduling entity (e.g., a PCE), a node multiple hops awaygrouped for transmit (and receive, respectively) with 'OR' relations, and then an 'AND' relation can be configurable between groups. The semantics are such that if theauthority to modifytransmit (and receive, respectively) operation succeeded in one timeslot in an 'OR' group, then all theTSCH schedule (e.g.,other timeslots in thehead of a local cluster), or a external device monitoringgroup are ignored. Now, if there are at least two groups, theoverall state of'AND' relation between thenetwork (e.g., NME). It is also possiblegroups indicates thata mapping entity on the backbone transforms a non-CoAP protocol such as PCEP intoone operation must succeed in each of theRESTful interfaces thatgroups. </t> <t indent="0" pn="section-4.7.2-3"> On the6TiSCH devices support. </t--> <t> Remote monitoring and Schedule Management refers to a DetNet/SDN model whereby an NME andtransmit side, timeslots provisioned for retries along ascheduling entity, associated withsame branch of aPCE, resideTrack are placed ina central controller and interact withthe6top layer to control IPv6 Links and Tracks (<xref target='ontrk'/>) in a 6TiSCH network.same 'OR' group. Thecomposite centralized controller can assign physical resources (e.g., buffers and hard cells) to'OR' relation indicates that if aparticulartransmission is acknowledged, then retransmissions of that packet should not be attempted for the remaining timeslots in that group. There are as many 'OR' groups as there are branches of the Track departing from this node. Different 'OR' groups are programmed for the purpose of replication, each group corresponding tooptimizeone branch of thereliability within a bounded latency for a well-specified flow. </t> <t>Track. Thework at the 6TiSCH WG focused on non-deterministic traffic and did not provide'AND' relation between thegeneric data modelgroups indicates that transmission over any of branches must be attempted regardless of whether a transmission succeeded in another branch. It isnecessary for the controlleralso possible tomonitor and manage resources ofplace cells to different next-hop routers in the6top sublayer.same 'OR' group. Thisis deferredallows routing along multipath Tracks, trying one next hop and then another only if sending tofuture work, see <xref target='unchartered-tracks'/>.the first fails. </t><!--<t indent="0" pn="section-4.7.2-4"> On the receive side, all timeslots are programmed in the same 'OR' group. Retries of the same copy as well as converging branches forlater --> <t> With respect to Centralized routing and scheduling, it is envisionedelimination are converged, meaning that therelated component offirst successful reception is enough and that all the6TiSCH Architecture wouldother timeslots can bean extension ofignored. An 'AND' group denotes different packets that must all be received and transmitted over the associated transmit groups within their respected 'AND' or 'OR' rules. </t> <t indent="0" pn="section-4.7.2-5"> As an example, say that we have a simple network as represented in <xreftarget='RFC8655'>DetNet Architecture</xref>, which studies Layer-3 aspects of Deterministic Networks,target="figANDORref" format="default" sectionFormat="of" derivedContent="Figure 16"/>, andcovers networks that span multiple Layer-2 domains.we want to enable PREOF between an ingress node I and an egress node E. </t><t><figure align="center" anchor="figANDORref" suppress-title="false" pn="figure-16"> <name slugifiedName="name-scheduling-preof-on-a-simpl">Scheduling PREOF on a Simple Network</name> <artwork align="center" pn="section-4.7.2-6.1"> +-+ +-+ -- |A| ------ |C| -- / +-+ +-+ \ / \ +-+ +-+ |I| |E| +-+ +-+ \ / \ +-+ +-+ / -- |B| ------- |D| -- +-+ +-+ </artwork> </figure> <t indent="0" pn="section-4.7.2-7"> TheDetNet architectureassumption for this particular problem is that aform of Software Defined Networking (SDN) Architecture6TiSCH node has a single radio, so it cannot perform two receive and/or transmit operations at the same time, even on two different channels. </t> <t indent="0" pn="section-4.7.2-8"> Say we have six possible channels, and at least ten timeslots per slotframe. <xref target="figsc" format="default" sectionFormat="of" derivedContent="Figure 17"/> shows a possible schedule whereby each transmission iscomposed ofretried two or threeplanes, a (User) Application Plane, a Controller Plane (wheretimes, and redundant copies are forwarded in parallel via A and C on thePCE operates),one hand, anda Network Plane which can represent a 6TiSCH LLN. </t> <t> <xref target='RFC7426'>Software-Defined Networking (SDN): LayersB andArchitecture Terminology</xref> proposes a generic representation ofD on theSDN architecture that is reproduced in <xref target='RFC7426archi'/>.other, providing time diversity, spatial diversity though different physical paths, and frequency diversity. </t> <figurealign='center' anchor='RFC7426archi'><name>SDN Layers and Architecture Terminology per RFC 7426</name>anchor="figsc" align="left" suppress-title="false" pn="figure-17"> <name slugifiedName="name-example-global-schedule">Example Global Schedule</name> <artworkalign='left'> <![CDATA[ o--------------------------------o | | | +-------------+ +----------+ | | | Application | | Service | | | +-------------+ +----------+ | | Application Plane | o---------------Y----------------o | *-----------------------------Y---------------------------------* | Network Services Abstraction Layer (NSAL) | *------Y------------------------------------------------Y-------* | | | Service Interface | | | o------Y------------------o o---------------------Y------o | | Control Plane | | Management Plane | | | +----Y----+ +-----+ | | +-----+ +----Y----+ | | | Service | | App | | | | App | | Service | | | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | | | | | | | | | | *----Y-----------Y----* | | *---Y---------------Y----* | | | Control Abstraction | | | | Management Abstraction | | | | Layer (CAL) | | | | Layer (MAL) | | | *----------Y----------* | | *----------Y-------------* | | | |align="center" pn="section-4.7.2-9.1"> slotOffset 0 1 2 3 4 5 6 7 9 +----+----+----+----+----+----+----+----+----+ channelOffset 0 | | |o------------|------------o o------------|---------------o| | |CP|B->D| |MP|Southbound... +----+----+----+----+----+----+----+----+----+ channelOffset 1 |Southbound|I->A| |A->C|B->D| |Interface|Interface| |*------------Y---------------------------------Y----------------*... +----+----+----+----+----+----+----+----+----+ channelOffset 2 |I->A| |Device and resource Abstraction Layer (DAL)|I->B| |C->E| |D->E| |*------------Y---------------------------------Y----------------*... +----+----+----+----+----+----+----+----+----+ channelOffset 3 | | | | |A->C| |o-------Y----------o +-----+ o--------Y----------o| | |Forwarding Plane... +----+----+----+----+----+----+----+----+----+ channelOffset 4 | |App|I->B| | |B->D| |Operational Plane|D->E| ... +----+----+----+----+----+----+----+----+----+ channelOffset 5 | | |A->C| |o------------------o +-----+ o-------------------o| |C->E| |Network Device|+---------------------------------------------------------------+ ]]></artwork>... +----+----+----+----+----+----+----+----+----+ </artwork> </figure><t>The PCE establishes end-to-end Tracks of hard cells, which are described in more details in <xref target='trkfwd'/>. </t> <t> The DetNet work is expected to enable end to end Deterministic Path across heterogeneous network. This can be for instance a 6TiSCH LLN and an Ethernet Backbone. </t> <t>This model fits the 6TiSCH extended configuration, whereby a 6BBR federates multiple 6TiSCH LLN in a single subnet over a backbone that can be, for instance, Ethernet or Wi-Fi. In that model, 6TiSCH 6BBRs synchronize with one another over the backbone, so as to ensure that the multiple LLNs that form the IPv6 subnet stay tightly synchronized. </t> <t> If the Backbone is Deterministic, then the Backbone Router ensures that the end-to-end deterministic behavior is maintained between the LLN and the backbone. It is the responsibility of the PCE to compute a deterministic path and to end across the TSCH network and an IEEE Std. 802.1 TSN Ethernet backbone, and that of DetNet to enable end-to-end deterministic forwarding. </t> </section> <section><name>Hop-by-hop Scheduling</name> <t> A node can reserve a <xref target='ontrk'>Track</xref> to one or more destination(s) that are multiple hops away by installing soft cells at each intermediate node. This forms a Track of soft cells. A Track Scheduling Function above the 6top sublayer of each node on the Track is needed to monitor these soft cells and trigger relocation when needed. </t> <t><t indent="0" pn="section-4.7.2-10"> Thishop-by-hop reservation mechanism is expectedtranslates into a different slotframe that provides the waking and sleeping times for every node, and the channelOffset to besimilar in essence to <xref target='RFC3209'/> and/orused when awake. <xreftarget='RFC4080'/>/<xref target='RFC5974'/>. The protocoltarget="figsfA" format="default" sectionFormat="of" derivedContent="Figure 18"/> shows the corresponding slotframe foranodeto trigger hop-by-hop scheduling is not yet defined.A. </t> <figure anchor="figsfA" align="left" suppress-title="false" pn="figure-18"> <name slugifiedName="name-example-slotframe-for-node-">Example Slotframe for Node A</name> <artwork align="center" pn="section-4.7.2-11.1"> slotOffset 0 1 2 3 4 5 6 7 9 +----+----+----+----+----+----+----+----+----+ operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ... +----+----+----+----+----+----+----+----+----+ channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ... +----+----+----+----+----+----+----+----+----+ </artwork> </figure> <t indent="0" pn="section-4.7.2-12"> The logical relationship between the timeslots is given by <xref target="figslog" format="default" sectionFormat="of" derivedContent="Table 2"/>: </t> <table anchor="figslog" align="center" pn="table-2"> <thead> <tr> <th align="center" colspan="1" rowspan="1">Node</th> <th align="center" colspan="1" rowspan="1">rcv slotOffset</th> <th align="center" colspan="1" rowspan="1">xmit slotOffset</th> </tr> </thead> <tbody> <tr> <td align="center" colspan="1" rowspan="1">I</td> <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> </tr> <tr> <td align="center" colspan="1" rowspan="1">A</td> <td align="center" colspan="1" rowspan="1">(0 OR 1)</td> <td align="center" colspan="1" rowspan="1">(2 OR 3 OR 4)</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">B</td> <td align="center" colspan="1" rowspan="1">(2 OR 3)</td> <td align="center" colspan="1" rowspan="1">(4 OR 5 OR 6)</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">C</td> <td align="center" colspan="1" rowspan="1">(2 OR 3 OR 4)</td> <td align="center" colspan="1" rowspan="1">(5 OR 6)</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">D</td> <td align="center" colspan="1" rowspan="1">(4 OR 5 OR 6)</td> <td align="center" colspan="1" rowspan="1">(7 OR 8)</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">E</td> <td align="center" colspan="1" rowspan="1">(5 OR 6 OR 7 OR 8)</td> <td align="center" colspan="1" rowspan="1">N/A</td> </tr> </tbody> </table> </section> </section> </section><!--<sectionanchor="topo" title="6TiSCH Device Capabilities"> <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,numbered="true" removeInRFC="false" toc="include" pn="section-5"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-5-1"> This document has no IANA actions. </t> </section> <section anchor="sec" numbered="true" removeInRFC="false" toc="include" pn="section-6"> <name slugifiedName="name-security-considerations">Security Considerations</name> <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 andwill not be able to store many packets waitingTSCH operations. The reader is encouraged tobe forwarded. Peers can be identified through MAC or IPv6 addresses, but a Cryptographically Generated Addressreview the Security Considerations section of that document (Section <xreftarget="RFC3972"/> (CGA) may also be used.target="RFC9031" sectionFormat="bare" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9031#section-9" derivedContent="RFC9031"/>), which discusses 6TiSCH security issues in more details. </t><t> Neighbors can be discovered over the radio using mechanism such as beacons, but, though the neighbor information<section anchor="det" numbered="true" removeInRFC="false" toc="include" pn="section-6.1"> <name slugifiedName="name-availability-of-remote-serv">Availability of Remote Services</name> <t indent="0" pn="section-6.1-1"> The operation of 6TiSCH Tracks inherits its high-level operation from DetNet and isavailablesubject to the observations in <xref target="RFC8655" section="5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8655#section-5" derivedContent="RFC8655"/>. The installation and the maintenance of the 6TiSCHinterface data model, 6TiSCH does not describeTracks depend on the availability of aprotocolcontroller with a PCE topro-activelycompute and push them in theneighborhood informationnetwork. When that connectivity is lost, existing Tracks may continue toa PCE. This protocol shouldoperate until the end of their lifetime, but cannot bedescribedremoved or updated, andshould operate over CoAP. The protocol shouldnew Tracks cannot beableinstalled. </t> <t indent="0" pn="section-6.1-2"> In an LLN, the communication with a remote PCE may be slow and unreactive tocarry multiple metrics,rapid changes inparticularthesame metrics as used for RPL operations <xref target="RFC6551"/>. </t> <t>condition of the wireless communication. An attacker may introduce extra delay by selectively jamming some packets or some flows. Theenergyexpectation is that thedevice consumes6TiSCH Tracks enable enough redundancy to maintain the critical traffic insleep, transmit and receive modes can be evaluatedoperation while new routes are calculated andreported. So canprogrammed into theamount of energy that is storednetwork. </t> <t indent="0" pn="section-6.1-3"> As with DetNet in general, thedevice and the power that it can be scavenged fromcommunication with theenvironment. ThePCESHOULDmust beable to compute Tracks that will implement policies on howsecured and should be protected against DoS attacks, including delay injection and blackholing attacks, and secured as discussed in theenergy is consumed,security considerations defined forinstance balance between nodes, ensure that the spent energy does not exceeded the scavenged energy overAbstraction and Control of Traffic Engineered Networks (ACTN) in <xref target="RFC8453" section="9" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8453#section-9" derivedContent="RFC8453"/>, which applies equally to DetNet and 6TiSCH. In aperiod of time, etc...similar manner, the communication with the JRC must be secured and should be protected against DoS attacks when possible. </t> </section></section> --><sectionanchor='ontrk'><name>On Tracks</name> <t>anchor="phy" numbered="true" removeInRFC="false" toc="include" pn="section-6.2"> <name slugifiedName="name-selective-jamming">Selective Jamming</name> <t indent="0" pn="section-6.2-1"> Thearchitecture introduces the concepthopping sequence of aTrack, whichTSCH network is well known, meaning that if adirected path from a source 6TiSCH noderogue manages toone or more destination 6TiSCH node(s) acrossidentify a6TiSCH LLN. </t> <t> A Track is the 6TiSCH instantiation of the conceptcell of aDeterministic Path as described in <xref target='RFC8655'/>. Constrained resources such as memory buffers are reserved forparticular flow, then it may selectively jam thatTrack in intermediate 6TiSCH nodes to avoid loss related to limited capacity. A 6TiSCH node along a Track not only knows which bundlescell without impacting any other traffic. This attack can be performed at the PHY layer without any knowledge ofcellsthe Layer 2 keys, and itshould useis very hard toreceive packets fromdetect and diagnose because only one flow is impacted. </t> <t indent="0" pn="section-6.2-2"> <xref target="I-D.tiloca-6tisch-robust-scheduling" format="default" sectionFormat="of" derivedContent="ROBUST-SCHEDULING"/> proposes aprevious hop, but also knows which bundle(s)method to obfuscate the hopping sequence and make itshould useharder tosend packetsperpetrate that particular attack. </t> </section> <section anchor="iee" numbered="true" removeInRFC="false" toc="include" pn="section-6.3"> <name slugifiedName="name-mac-layer-security">MAC-Layer Security</name> <t indent="0" pn="section-6.3-1"> This architecture operates on IEEE Std 802.15.4 and expects the link-layer security toits next hop alongbe enabled at all times between connected devices, except for theTrack. </t> <section><name>General Behavior of Tracks</name> <t> A Track is associated with Layer-2 bundlesvery first step ofcells with related schedules and logical relationships and that ensure thatthe device join process, where apacket that is injected injoining device may need some initial, unsecured exchanges so as to obtain its initial key material. In aTrack will progress in due timetypical deployment, all joined nodes use thewaysame keys, and rekeying needs todestination. </t> <t> Multiple cells maybescheduled in a Track forglobal. </t> <t indent="0" pn="section-6.3-2"> The 6TISCH architecture relies on thetransmissionjoin process to deny authorization ofa single packet, in which caseinvalid nodes and to preserve thenormal operationintegrity ofIEEE Std. 802.15.4 Automatic Repeat-reQuest (ARQ) can take place;theacknowledgment may be omitted in some cases, for instance if there is no scheduled cell for a possible retry. </t> <t> There are several benefits for using a Tracknetwork keys. A rogue that managed toforwardaccess the network can perform apacketlarge variety of attacks froma source nodeDoS to injecting forged packets and routing information. "Zero-trust" properties would be highly desirable but are mostly not available at thedestination node. </t> <ol spacing='normal'> <li> Track forwarding, as further described intime of this writing. <xreftarget='trkfwd'/>,target="RFC8928" format="default" sectionFormat="of" derivedContent="RFC8928"/> is aLayer-2 forwarding scheme, which introduces less process delaynotable exception that protects the ownership of IPv6 addresses andoverhead than Layer-3 forwarding scheme. Therefore, LLN Devices can save more energyprevents a rogue node with L2 access from stealing andresource, which is critical for resource constrained devices. </li> <li> Since channel resources, i.e., bundlesinjecting traffic on behalf ofcells, have been reserved for communications between 6TiSCH nodesa legitimate node. </t> </section> <section anchor="ts" numbered="true" removeInRFC="false" toc="include" pn="section-6.4"> <name slugifiedName="name-time-synchronization">Time Synchronization</name> <t indent="0" pn="section-6.4-1"> Time synchronization in TSCH induces another event horizon whereby a node will only communicate with another node if they are synchronized within a guard time. The pledge discovers the synchronization ofeach hopthe network based on theTrack,time of reception of thethroughput andbeacon. If an attacker synchronizes a pledge outside of themaximum latencyguard time of thetraffic alonglegitimate nodes, then the pledge will never see aTrack are guaranteedlegitimate beacon and may not discover thejitter is maintained small. </li> <li> By knowingattack. </t> <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 thescheduledtimeslots of incoming bundle(s)synchronization, andoutgoing bundle(s),for 6TiSCHnodes on a Track could save more energy by staying in sleep state during in-active slots. </li> <li> Tracks are protected from interfering with one another if a cellthis includes ensuring that the Absolute Slot Number (ASN), which isscheduled to belong to at most one Track,the node's sense of time, is not compromised. Once installed andcongestion lossas long as the node isavoided if at most one packet can be presentedsynchronized to theMAC to usenetwork, ASN is implicit in the transmissions. </t> <t indent="0" pn="section-6.4-3"> <xref target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154">IEEE Std 802.15.4</xref> specifies thatcell. Tracks enhancein a TSCH network, thereliabilitynonce that is used for the computation oftransmissionsthe Message Integrity Code (MIC) to secure link-layer frames is composed of the address of the source of the frame andthus further improveof theenergy consumption in LLN DevicesASN. The standard assumes that the ASN is distributed securely byreducingother means. The ASN is not passed explicitly in thechances of retransmission. </li> </ol><t>data frames and does not constitute a complete anti-replay protection. As a result, upper-layer protocols must provide a way to detect duplicates and cope with them. </t></section> <section><name>Serial Track</name> <t> A Serial (or simple) Track is<t indent="0" pn="section-6.4-4"> If the6TiSCH version of a circuit;receiver and the sender have abundledifferent sense ofcellsASN, the MIC will not validate and the frame will be dropped. In thatare programmed to receive (RX-cells) is uniquely paired tosense, TSCH induces an event horizon whereby only nodes that have abundlecommon sense ofcells that are setASN can talk totransmit (TX-cells), representingone another in an authenticated manner. With 6TiSCH, the pledge discovers aLayer-2 forwarding state whichtentative ASN in beacons from nodes that have already joined the network. But even if the beacon can beused regardless ofauthenticated, thenetwork layer protocol. A Serial Track is thus formed end-to-endASN cannot be trusted as it could be asuccession of paired bundles,replay by an attacker, announcing an ASN that represents areceive bundle fromtime in theprevious hop and a transmit bundle topast. If thenext hop alongpledge uses an ASN that is learned from a replayed beacon for an encrypted transmission, a nonce-reuse attack becomes possible, and theTrack.network keys may be compromised. </t><t> For</section> <section anchor="asv" numbered="true" removeInRFC="false" toc="include" pn="section-6.5"> <name slugifiedName="name-validating-asn">Validating ASN</name> <t indent="0" pn="section-6.5-1"> After obtaining the tentative ASN, agiven iteration ofpledge that wishes to join thedevice schedule,6TiSCH network must use a join protocol to obtain its security keys. The join protocol used in 6TiSCH is theeffective channel ofConstrained Join Protocol (CoJP). In thecell is obtained by followingminimal setting defined ina loop a well-known hopping sequence that started at Epoch time at the channelOffset of<xref target="RFC9031" format="default" sectionFormat="of" derivedContent="RFC9031"/>, thecell,authentication requires a pre-shared key, based on whichresults inarotation of the frequency that used for transmission.secure session is derived. ThebundlesCoJP exchange may also becomputed so aspreceded by a zero-touch handshake <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" format="default" sectionFormat="of" derivedContent="ZEROTOUCH-JOIN"/> in order toaccommodate both variable rates and retransmissions, so they might not be fully usedenable pledge joining based on certificates and/or inter-domain communication. </t> <t indent="0" pn="section-6.5-2"> As detailed in <xref target="rflo" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>, a Join Proxy (JP) helps theiteration of the schedule. </t> </section> <section><name>Complex Trackpledge withReplication and Elimination</name> <t> The art of Deterministic Networks already include Packet Replication and Elimination techniques. Example standards includetheParallel Redundancy Protocol (PRP) andjoin procedure by relaying theHigh-availability Seamless Redundancy (HSR) <xref target='IEC62439'/>. Similarly, and as opposedlink-scope Join Request over the IP network to aSerial TrackJoin Registrar/Coordinator (JRC) thatis a sequence of nodescan authenticate the pledge andlinks, a Complex Trackvalidate that it isshaped as a directed acyclic graph towards one or more destination(s)attached tosupport multi-path forwarding and route around failures. </t> <t> A Complex Track may branch off over non congruent branches forthepurposeappropriate network. As a result ofmulticasting, and/or redundancy, in which case it reconverges later downthepath. This enablesCoJP exchange, thePacket Replication, Elimination and Ordering Functions (PREOF) defined by Detnet. Packet ARQ, Replication, Elimination and Overhearing (PAREO) adds radio-specific capabilitiespledge is in possession ofLayer-2 ARQlink-layer material including keys andpromiscuous listening to redundant transmissionsa short address, and if the ASN is known tocompensate forbe correct, all traffic can now be secured using CCM* <xref target="CCMstar" format="default" sectionFormat="of" derivedContent="CCMstar"/> at the link layer. </t> <t indent="0" pn="section-6.5-3"> The authentication steps must be such that they cannot be replayed by an attacker, and they must not depend on the tentative ASN being valid. During thelossiness ofauthentication, themedium and meet industrial expectations of a Reliable and Available Wireless network. Combining PAREO and PREOF, a Track may extend beyondkeying material that the6TiSCH network in a larger DetNet network. </t> <t> Inpledge obtains from theart of TSCH, a pathJRC does notnecessarily support PRE but it is almost systematically multi-path. This means that a Track is scheduled so as to ensure that each hopprovide protection against spoofed ASN. Once the pledge hasat least two forwarding solutions, andobtained theforwarding decision iskeys totry the preferred one andusethe otherincase of Layer-2 transmission failure as detected by ARQ. Similarly, at each 6TiSCH hop along the Track,thePCEnetwork, it mayschedule more than one timeslot for a packet, so asstill need tosupport Layer-2 retries (ARQ). It is also possible thatverify thefield device only usesASN. If thesecond branch if sending overnonce used in thefirst branch fails. </t> </section> <section><name>DetNet End-to-end Path</name> <t> Ultimately, DetNet shouldLayer 2 security derives from the extended (MAC-64) address, then replaying the ASN alone cannot enableto extendaTrack beyondnonce-reuse attack unless the6TiSCH LLN as illustrated in <xref target='elifig'/>. In that example,same node has lost its state with aTrack that is laid outprevious ASN. But if the nonce derives froma field device in a 6TiSCH network to an IoT gatewaythe short address (e.g., assigned by the JRC), then the JRC must ensure thatis located on an 802.1 Time-Sensitive Networking (TSN) backbone. A 6TiSCH-Aware DetNet Service Layer handlesit never assigns short addresses that were already given to this or other nodes with thePacket Replication, Elimination, and Ordering Functions oversame keys. In other words, theDODAG that forms a Track. </t> <t> The Replication function innetwork must be rekeyed before the6TiSCH Node sends a copyJRC runs out ofeach packet over two different branches,short addresses. </t> </section> <section anchor="keying" numbered="true" removeInRFC="false" toc="include" pn="section-6.6"> <name slugifiedName="name-network-keying-and-rekeying">Network Keying andthe PCE schedules each hopRekeying</name> <t indent="0" pn="section-6.6-1"> <xref target="rflo" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/> provides an overview ofboth branches so thatthetwo copies arriveCoJP process described in <xref target="RFC9031" format="default" sectionFormat="of" derivedContent="RFC9031"/> by which an LLN can be assembled indue time atthegateway. In case offield, having been provisioned in aloss on one branch, hopefullylab. <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" format="default" sectionFormat="of" derivedContent="ZEROTOUCH-JOIN"/> is future work that precedes and then leverages CoJP using theother copy<xref target="I-D.ietf-anima-constrained-voucher" format="default" sectionFormat="of" derivedContent="CONSTRAINED-VOUCHER"/> constrained profile ofthe packet still makes it<xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>. This later work requires a yet-to-be standardized Lightweight Authenticated Key Exchange protocol. </t> <t indent="0" pn="section-6.6-2"> CoJP results indue time. If two copies make itdistribution of a network-wide key that is tothe IoT gateway, the Elimination functionbe used with <xref target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"/> security. The details of use are described inthe gateway ignores the extra packet and presents only one copy to upper layers.<xref target="RFC9031" format="default" sectionFormat="of" derivedContent="RFC9031"/>, Sections <xref target="RFC9031" section="9.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9031#section-9.2" derivedContent="RFC9031"/> and <xref target="RFC9031" section="9.3.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9031#section-9.3.2" derivedContent="RFC9031"/>. </t><figure align='center' anchor='elifig'><name>Example End-to-End DetNet Track</name> <artwork><![CDATA[ +-=-=-+ | IoT | | G/W | +-=-=-+ ^ <=== Elimination Track branch | | +-=-=-=-+ +-=-=-=-=+ Subnet Backbone | | +-=|-=+ +-=|-=+ | | | Backbone | | | Backbone o | | | router | | | router +-=/-=+ +-=|-=+ o / o o-=-o-=-=/ o o o-=-o-=/ o o o o o o \ / o o LLN o o v <=== Replication o ]]></artwork> </figure> </section> <section><name>Cell Reuse</name> <t><t indent="0" pn="section-6.6-3"> The6TiSCH architecture provides meansBRSKI mechanism may lead toavoid wastethe use ofcells as well as overflowsCoJP, inthe transmit bundlewhich case it also results in distribution of aTrack, as follows: </t> <t> A TX-cell that is not needed fornetwork-wide key. Alternatively thecurrent iterationBRSKI mechanism may bereused opportunistically on a per-hop basis for routed packets. When allfollowed by use ofthe frame that were received for a given Track are effectively transmitted, any available TX-cell for that Track can be reused for upper layer traffic<xref target="I-D.ietf-ace-coap-est" format="default" sectionFormat="of" derivedContent="EST-COAPS"/> to enroll certificates forwhich the next-hop router matches the next hop along the Track.each device. In that case, thecell that is beingcertificates may be usedis effectively a TX-cell from the Track, but the short address for the destination is thatwith an <xref target="IEEE802154" format="default" sectionFormat="of" derivedContent="IEEE802154"/> key agreement protocol. The description ofthe next-hop router.this mechanism, while conceptually straightforward, still has significant standardization hurdles to pass. </t><t> It results in<t indent="0" pn="section-6.6-4"> <xref target="RFC9031" section="8.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9031#section-8.2" derivedContent="RFC9031"/> describes aframe that is received inmechanism to change (rekey) the network. There are aRX-cellnumber of reasons to initiate aTrack with a destination MAC address setnetwork rekey: tothis node as opposedremove unwanted (corrupt/malicious) nodes, tothe broadcast MAC address must be extracted from the Track and deliveredrecover unused 2-byte short addresses, or due tothe upper layer. Note that a frame with an unrecognized destination MAC address is dropped at the lower MAC layer and thus is not received at the 6top sublayer. </t> <t> On the other hand, it might happen that there are not enough TX-cellslimits in encryption algorithms. For all of thetransmit bundle to accommodate the Track traffic, for instance if more retransmissions aremechanisms that distribute a network-wide key, rekeying is also neededthan provisioned.on a periodic basis. Inthat case, and if the frame transports an IPv6 packet, then it can be placed for transmissionmore detail: </t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.6-5"> <li pn="section-6.6-5.1"> The mechanism described in <xref target="RFC9031" section="8.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9031#section-8.2" derivedContent="RFC9031"/> requires advance communication between thebundle that is used for Layer-3 traffic towardsJRC and every one of thenext hop alongnodes before theTrack. The MAC address shouldkey change. Given that many nodes may beset tosleepy, this operation may take a significant amount of time and may consume a significant portion of thenext-hop MAC addressavailable bandwidth. As such, network-wide rekeys toavoid confusion. </t> <t> It results in a frameexclude nodes thatis received over a Layer-3 bundle mayhave become malicious will not bein fact associated to a Track. Inparticularly quick. If aclassical IP link such as an Ethernet, off-Track trafficrekey istypicallyalready inexcess over reservationprogress, but the unwanted node has not yet been updated, then it is possible to just continue the operation. If the unwanted node has already received the update, then the rekey operation will need to berouted alongrestarted. </li> <li pn="section-6.6-5.2"> The cryptographic mechanisms used by IEEE Std 802.15.4 include thenon-reserved path based on its QoS setting. But with 6TiSCH, since2-byte short address in theusecalculation of theLayer-3 bundlecontext. A nonce-reuse attack maybe duebecome feasible if a short address is reassigned totransmission failures, it makes sense foranother node while thereceiver to recognize a framesame network-wide keys are in operation. A network thatshould be re-Tracked,gains andto place it backloses nodes on a regular basis is likely to reach theappropriate bundle65536 limit of the 2-byte (16-bit) short addresses, even ifpossible. <!-- A framethe network has only a few thousand nodes. Network planners shouldbe re-Tracked ifconsider thePer-Hop-Behavior group indicated inneed to rekey theDifferentiated Services Field ofnetwork on a periodic basis in order to recover 2-byte addresses. The rekey can update theIPv6 headershort addresses for active nodes if desired, but there issetactually no need toDeterministic Forwarding,do this as long as the key has been changed. </li> <li pn="section-6.6-5.3"> With TSCH asdiscussed in <xref target="pmh"/ -->. A frame is re-Tracked by schedulingitfor transmission overstands at thetransmit bundle associated totime of this writing, theTrack,ASN will wrap after 2^40 timeslot durations, meaning around 350 years with thedestination MAC address setdefault values. Wrapping ASN is not expected tobroadcast. </t> </section> </section> <section anchor='fwd'><name>Forwarding Models</name> <!-- TW: Forwarding models should be formalized in a standards-Track draft? Onehappen within the lifetime of most LLNs. Yet, shouldbe MUST (IPv6?),theothers SHOULD? --> <t> By forwarding, this document meansASN wrap, theper-packet operation that allows to deliver a packetnetwork must be rekeyed to avoid anext hop or an upper layer in this node. Forwarding is basednonce-reuse attack. </li> <li pn="section-6.6-5.4"> Many cipher algorithms have some suggested limits onpre-existing state that was installed as a result of a routing computation <xref target='rtg'/>. 6TiSCH supports three different forwarding model:(G-MPLS) Track Forwarding, (classical) IPv6 Forwarding and (6LoWPAN) Fragment Forwarding. </t> <section anchor='trkfwd'><name>Track Forwarding</name> <t> Forwarding along a Track canhow many bytes should beseen as a Generalized Multi-protocol Label Switching (G-MPLS) operation inencrypted with thatthe information used to switchalgorithm before aframenew key isnot an explicit label, but rather related to other properties of the way the packet was received, a particular cellused. These numbers are typically in thecasemany to hundreds of6TiSCH. As a result, as long as the TSCH MAC (and Layer-2 security) accepts a frame, that frame can be switched regardlessgigabytes ofthe protocol, whetherdata. On very fast backbone networks, thisis an IPv6 packet, a 6LoWPAN fragment, or a frame frombecomes analternate protocol such as WirelessHART or ISA100.11a. </t> <t> Aimportant concern. On LLNs with typical dataframe that is forwarded along a Track normally has a destination MAC address that is set to broadcast - or a multicast address depending on MAC support. This way, the MAC layerrates in theintermediate nodes accepts the incoming frame and 6top switcheskilobits/second, this concern is significantly less. With IEEE Std 802.15.4 as itwithout incurring a change in the MAC header. Instands at thecasetime ofIEEE Std. 802.15.4,thismeans effectively broadcast, so that along the Trackwriting, theshort address forASN will wrap before thedestinationlimits of theframe is set to 0xFFFF. </t> <t> Therecurrent L2 crypto (AES-CCM-128) are2 modes for a Track, an IPv6 native mode and a protocol-independant tunnel mode. </t> <section><name>Native Mode</name> <t>reached, so the problem should never occur. </li> <li pn="section-6.6-5.5"> Innative mode,any fashion, if theProtocol Data Unit (PDU)LLN isassociated with flow-dependent meta-data that refers uniquelyexpected to operate continuously for decades, then theTrack, sooperators are advised to plan for the6top sublayer can placeneed to rekey. </li> </ul> <t indent="0" pn="section-6.6-6"> Except for urgent rekeys caused by malicious nodes, theframerekey operation described inthe appropriate cell without ambiguity. In the case of IPv6 traffic, this flow identification may<xref target="RFC9031" format="default" sectionFormat="of" derivedContent="RFC9031"/> can be doneusing a 6-tupleasdiscussed in <xref target='I-D.ietf-detnet-ip'/>. In particular, implementations of this document should support identification of DetNet flows based on the IPv6 Flow Label field. </t> <t> The flow followsaTrack which identification isbackground task and can be doneusingincrementally. It is aRPL Instance (see section 3.1.3 of <xref target='RFC6550'/>),make-before-break mechanism. The switch over to the new key is not signaledin a RPL Packet Information (more in section 11.2.2.1 of <xref target='RFC6550'/>) andby time, but rather by observation that thedestination addressnew key is in use. As such, thecase of a local instance. Oneupdate can take as long as needed, ormore flows may be placedoccur in as short asame Track andtime as practical. </t> </section> </section> </middle> <back> <displayreference target="I-D.ietf-roll-rpl-industrial-applicability" to="RPL-APPLICABILITY"/> <displayreference target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" to="ZEROTOUCH-JOIN"/> <displayreference target="I-D.ietf-manet-aodvv2" to="AODVv2"/> <displayreference target="I-D.ietf-roll-aodv-rpl" to="AODV-RPL"/> <displayreference target="I-D.ietf-lwig-6lowpan-virtual-reassembly" to="VIRTUAL-REASSEMBLY"/> <displayreference target="I-D.ietf-roll-dao-projection" to="DAO-PROJECTION"/> <displayreference target="I-D.ietf-roll-capabilities" to="RPL-MOP"/> <displayreference target="I-D.selander-ace-cose-ecdhe" to="EDHOC"/> <displayreference target="I-D.thubert-roll-bier" to="RPL-BIER"/> <displayreference target="I-D.thubert-bier-replication-elimination" to="TE-PREF"/> <displayreference target="I-D.thubert-6lo-bier-dispatch" to="BITSTRINGS-6LORH"/> <displayreference target="I-D.thubert-6man-unicast-lookup" to="ND-UNICAST-LOOKUP"/> <displayreference target="I-D.pthubert-raw-architecture" to="RAW-ARCHITECTURE"/> <displayreference target="I-D.tiloca-6tisch-robust-scheduling" to="ROBUST-SCHEDULING"/> <displayreference target="I-D.ietf-ace-coap-est" to="EST-COAPS"/> <displayreference target="I-D.ietf-anima-constrained-voucher" to="CONSTRAINED-VOUCHER"/> <displayreference target="I-D.ietf-raw-use-cases" to="RAW-USE-CASES"/> <references pn="section-7"> <name slugifiedName="name-references">References</name> <references pn="section-7.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc768" quoteTitle="true" derivedAnchor="RFC0768"> <front> <title>User Datagram Protocol</title> <author initials="J." surname="Postel" fullname="J. Postel"> <organization showOnFrontPage="true"/> </author> <date year="1980" month="August"/> </front> <seriesInfo name="STD" value="6"/> <seriesInfo name="RFC" value="768"/> <seriesInfo name="DOI" value="10.17487/RFC0768"/> </reference> <reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4861" quoteTitle="true" derivedAnchor="RFC4861"> <front> <title>Neighbor Discovery for IP version 6 (IPv6)</title> <author initials="T." surname="Narten" fullname="T. Narten"> <organization showOnFrontPage="true"/> </author> <author initials="E." surname="Nordmark" fullname="E. Nordmark"> <organization showOnFrontPage="true"/> </author> <author initials="W." surname="Simpson" fullname="W. Simpson"> <organization showOnFrontPage="true"/> </author> <author initials="H." surname="Soliman" fullname="H. Soliman"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="September"/> <abstract> <t indent="0">This document specifies theTrack identification (TrackID + owner) may be placed in an IP-in-IP encapsulation. The forwarding operation is basedNeighbor Discovery protocol for IP Version 6. IPv6 nodes on theTracksame link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, anddoes not depend onto maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4861"/> <seriesInfo name="DOI" value="10.17487/RFC4861"/> </reference> <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4862" quoteTitle="true" derivedAnchor="RFC4862"> <front> <title>IPv6 Stateless Address Autoconfiguration</title> <author initials="S." surname="Thomson" fullname="S. Thomson"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Narten" fullname="T. Narten"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Jinmei" fullname="T. Jinmei"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="September"/> <abstract> <t indent="0">This document specifies theflow therein. </t> <t>steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. TheTrack identification is validated at egress before restoring the destination MACautoconfiguration process includes generating a link-local address, generating global addresses via stateless address(DMAC)autoconfiguration, andpunting totheupper layer. </t> <t><xref target='fig6t'/> illustrates the Track Forwarding operation which happens atDuplicate Address Detection procedure to verify the6top sublayer, below IP. </t> <figure anchor='fig6t'><name>Track Forwarding, Native Mode</name> <artwork><![CDATA[ | Packet flowing acrossuniqueness of thenetwork ^ +--------------+ | | |addresses on a link. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4862"/> <seriesInfo name="DOI" value="10.17487/RFC4862"/> </reference> <reference anchor="RFC4944" target="https://www.rfc-editor.org/info/rfc4944" quoteTitle="true" derivedAnchor="RFC4944"> <front> <title>Transmission of IPv6| | | +--------------+ | | | 6LoWPAN HC | | | +--------------+ ingress egress | 6top | sets +----+ +----+ restores +--------------+ DMAC to | | | | DMAC to | TSCH MAC | brdcst | | | | dest +--------------+ | | | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ Ingress Relay Relay Egress Stack Layer Node Node Node Node ]]></artwork> </figure> </section> <section><name>Tunnel Mode</name> <t> In tunnel mode, the frames originate from an arbitrary protocolPackets overa compatible MAC that may or may not be synchronized withIEEE 802.15.4 Networks</title> <author initials="G." surname="Montenegro" fullname="G. Montenegro"> <organization showOnFrontPage="true"/> </author> <author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Hui" fullname="J. Hui"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Culler" fullname="D. Culler"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="September"/> <abstract> <t indent="0">This document describes the6TiSCH network. An exampleframe format for transmission ofthis would beIPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include arouter withsimple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4944"/> <seriesInfo name="DOI" value="10.17487/RFC4944"/> </reference> <reference anchor="RFC5889" target="https://www.rfc-editor.org/info/rfc5889" quoteTitle="true" derivedAnchor="RFC5889"> <front> <title>IP Addressing Model in Ad Hoc Networks</title> <author initials="E." surname="Baccelli" fullname="E. Baccelli" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Townsley" fullname="M. Townsley" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2010" month="September"/> <abstract> <t indent="0">This document describes adual radio that is capable of receivingmodel for configuring IP addresses andsending WirelessHART or ISA100.11a frames withsubnet prefixes on thesecond radio, by presenting itself as an access Point or a Backbone Router, respectively. In that mode, some entity (e.g., PCE) can coordinateinterfaces of routers which connect to links witha WirelessHART Network Manager orundetermined connectivity properties. This document is not anISA100.11a System Manager to specify the flows that are transported. </t> <figure anchor='fig6'><name>Track Forwarding, Tunnel Mode</name> <artwork><![CDATA[ +--------------+ | IPv6 | +--------------+ | 6LoWPAN HC | +--------------+ set restore | 6top | +DMAC+ +DMAC+ +--------------+ to|brdcst to|nexthop | TSCH MAC | | | | | +--------------+ | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ | ingress egress | | | +--------------+ | | | LLN PHY | | | +--------------+ | Packet flowing across the network | | TSCH MAC | | | +--------------+ | DMAC = | DMAC = |ISA100/WiHART | | nexthop v nexthop +--------------+ Source Ingress Egress Destination Stack Layer Node Node Node Node ]]></artwork> </figure> <t> In that case, the TrackID that identifies theInternet Standards Trackat the ingress 6TiSCH routerspecification; it isderived from the RX-cell.published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="5889"/> <seriesInfo name="DOI" value="10.17487/RFC5889"/> </reference> <reference anchor="RFC6282" target="https://www.rfc-editor.org/info/rfc6282" quoteTitle="true" derivedAnchor="RFC6282"> <front> <title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title> <author initials="J." surname="Hui" fullname="J. Hui" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Thubert" fullname="P. Thubert"> <organization showOnFrontPage="true"/> </author> <date year="2011" month="September"/> <abstract> <t indent="0">This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). TheDMAC is setcompression format relies on shared context tothis node but the TrackID indicates that the frame must be tunneled over a particular Track soallow compression of arbitrary prefixes. How theframeinformation isnot passed to the upper layer. Instead, the DMACmaintained in that shared context isforced to broadcastout of scope. This document specifies compression of multicast addresses andthe framea framework for compressing next headers. UDP header compression ispassed to the 6top sublayerspecified within this framework. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6282"/> <seriesInfo name="DOI" value="10.17487/RFC6282"/> </reference> <reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6550" quoteTitle="true" derivedAnchor="RFC6550"> <front> <title>RPL: IPv6 Routing Protocol forswitching. </t> <t> At the egress 6TiSCH router, the reverse operation occurs. Based on tunneling informationLow-Power and Lossy Networks</title> <author initials="T." surname="Winter" fullname="T. Winter" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Thubert" fullname="P. Thubert" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Brandt" fullname="A. Brandt"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Hui" fullname="J. Hui"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Kelsey" fullname="R. Kelsey"> <organization showOnFrontPage="true"/> </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 ofthe Track,network in whichmay for instance indicate thatboth thetunneled datagram is an IP packet,routers and their interconnect are constrained. LLN routers 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 to thousands of routers. Supported traffic flows include point-to-point (between devices inside thedatagram is passedLLN), point-to-multipoint (from a central control point to a subset of devices inside theappropriate Link-Layer withLLN), and multipoint-to-point (from devices inside thedestination MAC restored. </t> </section> <section><name>Tunneling Information</name> <t> Tunneling information coming withLLN towards a central control point). This document specifies theTrack configurationIPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside thedestination MAC address of the egress endpointLLN towards a central control point as well as point-to-multipoint traffic from thetunnel mode and specific data depending on the mode, for instance a service access point for frame delivery at egress. </t> <t> If the tunnel egresscentral control pointdoes not have a MAC address that matches the configuration, the Track installation fails. </t> <t> If the Layer-3 destination address belongsto thetunnel termination, then it is possible that the IPv6 address ofdevices inside thedestinationLLN are supported. Support for point-to-point traffic iscompressed at the 6LoWPAN sublayer based on the MAC address. Restoring the wrong MAC address at the egress would thenalsoresult in the wrong IP addressavailable. [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/rfc6551" quoteTitle="true" derivedAnchor="RFC6551"> <front> <title>Routing Metrics Used for Path Calculation inthe packet after decompression. ForLow-Power and Lossy 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 characteristics compared with traditional wired and ad hoc networks thatreason, a packet can be injected in a Track only ifrequire thedestination MAC address is effectively thatspecification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by thetunnel egress point. It is thus mandatoryRouting Protocol for Low-Power and Lossy Networks (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/rfc6552" quoteTitle="true" derivedAnchor="RFC6552"> <front> <title>Objective Function Zero for theingress router to validateRouting Protocol for Low-Power 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 Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by theMAC address that was used atapplication of specific Objective Functions (OFs). An OF states the6LoWPAN sublayer for compression matches thatoutcome of thetunnel egress point before it overwrites itprocess used by a RPL node tobroadcast. The 6top sublayer atselect and optimize routes within a RPL Instance based on thetunnel egress point revertsInformation Objects available; an OF is not an algorithm.</t> <t indent="0">This document specifies a basic Objective Function thatoperation to the MAC address obtained from the tunnel information. </t> </section> </section> <section><name>IPv6 Forwarding</name> <t> Asrelies only on thepackets are routed at Layer-3, traditional QoS and Active Queue Management (AQM) operationsobjects that areexpected to prioritize flows. <!-- the application of Differentiated Services is further discusseddefined in--> <!-- <xref target="I-D.svshah-tsvwg-lln-diffserv-recommendations"/>. --> </t> <figure anchor='fig9'><name>IP Forwarding</name> <artwork><![CDATA[ | Packet flowing acrossthenetwork ^ +--------------+ | | | IPv6 | | +-QoS+ +-QoS+ | +--------------+ | | | | | | | 6LoWPAN HC | | | | | | | +--------------+ | | | | | | | 6top | | | | | | | +--------------+ | | | | | | | TSCH MAC | | | | | | | +--------------+ | | | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ Source Ingress Egress Destination Stack Layer Node Router Router Node ]]></artwork> </figure> </section> <section><name>Fragment Forwarding</name> <t> Considering that per section 4 of <xref target='RFC4944'/> 6LoWPAN packets can be as large as 1280 bytes (the IPv6 minimum MTU),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/rfc6553" quoteTitle="true" derivedAnchor="RFC6553"> <front> <title>The Routing Protocol for Low-Power andthat the non-storing mode ofLossy Networks (RPL) Option for Carrying RPLimplies SourceInformation 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 Routingthat requires spaceProtocol forrouting headers,Low-Power andthat a IEEE Std. 802.15.4 frame with security may carryLossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in theorder of 80 bytes of effective payload, an IPv6 packet might be fragmented into more than 16 fragments at the 6LoWPAN sublayer. </t> <t>routing topology. Thislevel of fragmentation is much higher than that traditionally experienced overdocument describes theInternetRPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]</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/rfc6554" quoteTitle="true" derivedAnchor="RFC6554"> <front> <title>An IPv6 Routing Header for Source Routes withIPv4 fragments, where fragmentation is already known as harmful. </t> <t> InthecaseRouting Protocol 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 constraints on routers may limit them toa multihop route within a 6TiSCH network, Hop-by-Hop recomposition occursmaintaining, ateach hopmost, a few routes. In some configurations, it is necessary toreformuse these memory-constrained routers to deliver datagrams to nodes within thepacket and route it. This creates additional latencyLLN. The Routing Protocol for Low-Power andforces intermediate nodesLossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or aportion of a packet for an undetermined time, thus impacting critical resources such as memory and battery. </t> <t> <xref target='I-D.ietf-6lo-minimal-fragment'/> describes a framework for forwarding fragments end-to-end across a 6TiSCH route-over mesh. Within that framework, <xref target='I-D.ietf-lwig-6lowpan-virtual-reassembly'/> details a virtual reassembly buffer mechanism wherebyfew routers and forward the IPv6 datagramtag in the 6LoWPAN Fragment is used asusing alabel for switching at the 6LoWPAN sublayer. </t> <t> Buildingsource routing technique to avoid large routing tables onthis technique, <xref target='I-D.ietf-6lo-fragment-recovery'/> introducesmemory-constrained routers. This document specifies a newformat for 6LoWPAN fragments that enables the selective recovery of individual fragments, and allowsIPv6 Routing header type for delivering datagrams within adegreeRPL routing domain. [STANDARDS-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/rfc6775" quoteTitle="true" derivedAnchor="RFC6775"> <front> <title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title> <author initials="Z." surname="Shelby" fullname="Z. Shelby" role="editor"> <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 Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage offlow control based on an Explicit Congestion Notification. </t> <figure anchor='fig7'><name>Forwarding First Fragment</name> <artwork><![CDATA[ | Packet flowing acrossmulticast signaling due to energy conservation. In addition, the wireless network^ +--------------+ | | | IPv6 | | +----+ +----+ | +--------------+ | | | | | | | 6LoWPAN HC | | learn learn | +--------------+ | | | | | | | 6top | | | | | | | +--------------+ | | | | | | | TSCH MAC | | | | | | | +--------------+ | | | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ Source Ingress Egress Destination Stack Layer Node Router Router Node ]]></artwork> </figure> <t> In that model,may not strictly follow thefirst fragment is routed basedtraditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6header that is presentlink concept and its heavy use of multicast make it inefficient and sometimes impractical inthat fragment. The 6LoWPAN sublayer learns the next hop selection, generatesanew datagram tag for transmissionlow-power and lossy network. This document describes simple optimizations tothe next hop,IPv6 Neighbor Discovery, its addressing mechanisms, andstores that information indexed by the incoming MACduplicate address detection for Low- power Wireless Personal Area Networks anddatagram tag.similar networks. Thenext fragments are then switched based on that stored state. </t> <figure anchor='fig8'><name>Forwarding Next Fragment</name> <artwork><![CDATA[ | Packet flowing acrossdocument thus updates RFC 4944 to specify thenetwork ^ +--------------+ | | | IPv6 | | | +--------------+ | | | 6LoWPAN HC | | replay replay | +--------------+ | | | | | | | 6top | | | | | | | +--------------+ | | | | | | | TSCH MAC | | | | | | | +--------------+ | | | | | | | LLN PHY | +-------+ +--...-----+ +-------+ +--------------+ Source Ingress Egress Destination Stack Layer Node Router Router Node ]]></artwork> </figure> <t> A bitmapuse 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/rfc7102" quoteTitle="true" derivedAnchor="RFC7102"> <front> <title>Terms Used in Routing for Low-Power andan ECN echoLossy 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 used inthe end-to-end acknowledgment enable the source to resend the missing fragments selectively. The first fragment may be resentrouting requirements and solutions for networks referred tocarveas Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by anew path in casevariety of links. There is apath failure. The ECN echo set indicates that the numberwide scope ofoutstanding fragments should be reduced. </t> </section> </section> <section anchor='rtg'><name>Advanced 6TiSCH Routing</name> <section anchor='pmh'><name>Packet Marking and Handling</name> <t> All packets inside a 6TiSCH domain must carry the RPLInstanceID that identifies the 6TiSCH topologyapplication areas for LLNs, including industrial monitoring, building automation (e.g.,a Track) thatheating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.</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/rfc7228" 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 isto beincreasingly usedfor routingon small devices with severe constraints on power, memory, andforwarding that packet. The locationprocessing resources, creating constrained-node networks. This document provides a number of basic terms thatinformation must behave been useful in thesamestandardization work forall packets forwarded inside the domain. </t> <t> For packets that are routed by a PCE alongconstrained-node networks.</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/rfc7252" 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 aTrack, the tuple formed by 1) (typically) the IPv6 source or (possibly) destination address in thespecialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6Headerover Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and2)alocal RPLInstanceID intypical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t> <t indent="0">CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of theRPI that servesWeb such asTrackID, identify uniquely the TrackURIs andassociated transmit bundle. </t> <t> For packets that are routed by RPL, that information is the RPLInstanceID whichInternet media types. CoAP iscarried indesigned to easily interface with HTTP for integration with theRPL Packet Information (RPI),Web while meeting specialized requirements such asdiscussed in section 11.2 of <xref target='RFC6550'/>, "Loop Avoidancemulticast support, very low overhead, andDetection". The RPI is transported by a RPL optionsimplicity 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/rfc7554" quoteTitle="true" derivedAnchor="RFC7554"> <front> <title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in theIPv6 Hop-By-Hop Header <xref target='RFC6553'/>. </t> <t> A compression mechanismInternet 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 statement, and goals for using theRPL packet artifacts that integratesTime-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in thecompressioncontext ofIP-in-IP encapsulationLow-Power andthe Routing Header type 3 <xref target='RFC6554'/> with thatLossy Networks (LLNs). The set ofthe RPIgoals 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/rfc8025" 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 a6LoWPAN dispatch/header type is specifiednew context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in<xref target='RFC8025'/>terms of Pages and<xref target='RFC8138'/>. </t> <t> <!--Insignaled by a6TiSCH network, the routing dispatch is the recommended encoding the RPL Packet Information.--> </t> <t> Either way, the method and format usednew Paging 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/rfc8137" quoteTitle="true" derivedAnchor="RFC8137"> <front> <title>IEEE 802.15.4 Information Element forencodingtheRPLInstanceID is generalizedIETF</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 toall 6TiSCH topological Instances, which include both RPL Instances and Tracks. </t> </section> <section anchor='pmhrre'><name>Replication, Retries and Elimination</name> <t> 6TiSCH supportsextend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages thePREOF operations of elimination and reorderingregistry ofpackets alongthe Information Elements. This document formulates acomplex Track, but has no requirement about whetherrequest for ANA to allocate asequencenumberis tagged in the packet forfrom thatpurpose. With 6TiSCH,registry for theschedule can tell when multiple receive timeslots correspondIETF and describes how the IE is formatted tocopies ofprovide 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/rfc8138" 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 asame packet,new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, whichcase the receiver may avoid listening to the extra copies once it had received one instance ofinitially covers thepacket. </t> <t> The semanticsneeds ofthe configuration will enable correlated timeslots to be groupedRouting Protocol fortransmit (and respectively receive) with a 'OR' relations,Low-Power andthen a 'AND' relation would be configurable between groups. The semantics is that if the transmit (and respectively receive) operation succeeded in one timeslot inLossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a'OR' group, then all the other timeslots in the group are ignored. Now, if there are at least two groups,method to compress the'AND' relation betweenRPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP 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/rfc8180" quoteTitle="true" derivedAnchor="RFC8180"> <front> <title>Minimal IPv6 over thegroups indicates that oneTSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration</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 operationmust succeed in eachfor an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies thegroups. </t> <t> Onbaseline set of protocols that need to be supported and thetransmit side, timeslots provisioned for retries along a same branchrecommended configurations and modes of operation sufficient to enable aTrack are placed6TiSCH functional network. 6TiSCH provides IPv6 connectivity over asame 'OR' group. The 'OR' relation indicates that ifTime-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses atransmission is acknowledged, then retransmissionscollection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, 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 thatpacketinterface to IEEE Std 802.15.4 TSCH. This minimal mode of operation shouldnotbeattempted for remaining timeslots in that group. There are as many 'OR' groups as there are branchesimplemented 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/rfc8200" 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 theTrack departing from this node. Different 'OR' groups are programmedInternet Protocol (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/rfc8453" quoteTitle="true" derivedAnchor="RFC8453"> <front> <title>Framework forthe purposeAbstraction 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 ofreplication, each group correspondingmechanisms toone branch of the Track. The 'AND' relation betweenfacilitate thegroups indicates that transmission over any of branches must be attempted regardlessseparation ofwhether a transmission succeeded in another branch. It isthe data plane and control plane. They alsopossible to place cells to different next-hop routers inhave asame 'OR' group. This allows to route along multi-path Tracks, trying one next-hoprange of management andthen another only if sendingprovisioning protocols tothe first fails. </t> <t> On the receive side, all timeslots are programmed in a same 'OR' group. Retries of a same copy as well as converging branchesconfigure and activate network resources. These mechanisms represent key technologies forelimination are converged, meaning that the first successful reception is enoughenabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network thatall the other timeslots can be ignored. A 'AND' group denotes different packets that must all be received and transmitted overuses any connection-oriented technology under theassociated transmit groups within their respected 'AND' or 'OR' rules. </t> <t> As an example say that we havecontrol of asimple network as represented in <xref target='figANDORref'/>, and we wantdistributed or centralized control plane toenable PREOF between an ingress node I and an egress node E. </t> <figure align='center' anchor='figANDORref'><name>Scheduling PREOF on a Simple Network</name> <artwork align='center'><![CDATA[ +-+ +-+ -- |A| ------ |C| -- / +-+ +-+ \ / \ +-+ +-+ |I| |E| +-+ +-+ \ / \ +-+ +-+ / -- |B| ------- |D| -- +-+ +-+ ]]></artwork> </figure> <t> The assumption for this particular problemsupport dynamic provisioning of end-to- end connectivity.</t> <t indent="0">Abstraction of network resources is a technique that can be applied to a6TiSCH node hassingle network domain or across multiple domains to create a singleradio, so it cannot perform 2 receive and/or transmit operations atvirtualized network that is under thesame time, even on 2 different channels. </t> <t> Say we have 6 possible channels, and at least 10 timeslots per slotframe. <xref target='figsc'/> showscontrol of apossible schedule whereby each transmission is retried 2network operator or3 times,the customer of the operator that actually owns the network resources.</t> <t indent="0">This document provides a framework for Abstraction andredundant copies are forwarded in parallel via AControl of TE Networks (ACTN) to support virtual network services andC onconnectivity 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/rfc8480" 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 of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on onehand, and B and D onanother. 6P is part of theother, providing time diversity, spatial diversity though different physical paths, and frequency diversity. </t> <figure anchor='figsc'><name>Example Global Schedule</name> <artwork align='center'> <![CDATA[ slotOffset 0 1 2 3 4 5 6 7 9 +----+----+----+----+----+----+----+----+----+ channelOffset 0 | | | | | | |B->D| | | ... +----+----+----+----+----+----+----+----+----+ channelOffset 1 | |I->A| |A->C|B->D| | | | | ... +----+----+----+----+----+----+----+----+----+ channelOffset 2 |I->A| | |I->B| |C->E| |D->E| | ... +----+----+----+----+----+----+----+----+----+ channelOffset 3 | | | | |A->C| | | | | ... +----+----+----+----+----+----+----+----+----+ channelOffset 4 | | |I->B| | |B->D| | |D->E| ... +----+----+----+----+----+----+----+----+----+ channelOffset 5 | | |A->C| | | |C->E| | | ... +----+----+----+----+----+----+----+----+----+ ]]> </artwork> </figure> <t> This translates6TiSCH 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 ina different slotframethis document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope forevery node thatthis document; however, this document provides thewaking and sleeping times,requirements 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/rfc8505" quoteTitle="true" derivedAnchor="RFC8505"> <front> <title>Registration Extensions for IPv6 over Low-Power Wireless Personal 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 thechannelOffsetregistration operation in 6LoWPAN routers, as well as to provide enhancements tobe used when awake. <xref target='figsfA'/> showsthecorresponding slotframeregistration capabilities and mobility detection fornode A. </t> <figure anchor='figsfA'><name>Example Slotframedifferent network topologies, including the Routing Registrars performing routing forNode A</name> <artwork align='center'> <![CDATA[ slotOffset 0 1 2 3 4 5 6 7 9 +----+----+----+----+----+----+----+----+----+ operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ... +----+----+----+----+----+----+----+----+----+ channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ... +----+----+----+----+----+----+----+----+----+ ]]> </artwork> </figure> <t> <!-- If, say, node A successfully transmits at slotOffset 2 then it may sleep at slotOffsets 3host routes and/or 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/rfc8655" 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 specified unicast or multicast data flows for real-time applications with extremely low data loss rates and4. --> The logical relationship betweenbounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of thetimeslots is given byintermediate nodes along thefollowing table: </t> <figure anchor='figslog' suppress-title='true'> <artwork align='center'> <![CDATA[ +------+---------------------+------------------------+ | Node | rcv slotOffset | xmit slotOffset | +------+---------------------+------------------------+ | I | N/A | (0 OR 1) AND (2 OR 3) | | A | (0 OR 1) | (2 OR 3 OR 4) | | B | (2 OR 3) | (4 OR 5 OR 6) | | C | (2 OR 3 OR 4) | (5 OR 6) | | D | (4 OR 5 OR 6) | (7 OR 8) | | E | (5 OR 6 OR 7 OR 8) | N/A | +------+---------------------+------------------------+ ]]> </artwork> </figure> <!-- <texttable title="schedule" anchor="schedtable"> <ttcol>Node</ttcol> <ttcol align="center"> rcv slotOffset</ttcol> <ttcol align="center"> xmit slotOffset</ttcol> <c>I</c> <c> N/A </c> <c> (0 OR 1) AND (2 OR 3) </c> <c>A</c> <c> (0 OR 1)</c> <c> (2 OR 3 OR 4) </c> <c>B</c> <c> (2 OR 3) </c> <c> (4 OR 5 OR 6) </c> <c>C</c> <c> (2 OR 3 OR 4)</c> <c> (5 OR 6) </c> <c>D</c> <c> (4 OR 5 OR 6) </c> <c> (7 OR 8) </c> <c>E</c> <c> (5 OR 6 OR 7 OR 8) </c> <c> N/A </c> </texttable> --> </section> <!-- <section anchor="pmhds" title="Differentiated Services Per-Hop-Behavior"> --> <!-- <t> --> <!-- A future document could define a PHBpath of the flow, 2) providing explicit routes forDeterministic Flows,DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space tobe indicated --> <!--ensure delivery of each packet's data in spite of theIANA registry where IETF-defined PHBs are listed. --> <!-- </t> --> <!-- </section> --> </section> </section> <section><name>IANA Considerations</name> <t> Thisloss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies 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/rfc8928" 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 documentdoes not require IANA action. </t> </section> <section anchor='sec'><name>Security Considerations</name> <t> The <xref target='I-D.ietf-6tisch-minimal-security'>"Minimal Security Framework for 6TiSCH"</xref> was optimized forupdates the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 andTSCH operations.8505. Thereadernew extension isencouraged to reviewcalled Address-Protected Neighbor Discovery (AP-ND), and it protects theSecurity Considerations sectionowner ofthat document, which discusses 6TiSCH security issuesan 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 one or moredetails. </t> <section anchor='det'><name>AvailabilityofRemote Services</name> <t>their Registered Addresses. TheoperationCrypto-ID identifies the owner of6TiSCH Tracks inherits its high level operation from DetNetthe Registered Address andis subjectcan be used tothe observations in section 5provide proof of<xref target='RFC8655'/>. The installationownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof of ownership is provided, only themaintenanceowner of that address can modify the6TiSCH Tracks depends onregistration 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/rfc8929" 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-Abegnoli"> <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 theavailabilitywireless edge of acontroller withbackbone and federate multiple wireless links to form aPCEsingle Multi-Link Subnet (MLSN).</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/rfc8930" 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 tocomputeenable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency andpush them inreliability as well as reduce thenetwork. When that connectivity is lost, existing Tracksbuffer requirements in intermediate nodes; it maycontinue to operate until the end of their lifetime, but cannotberemoved or updated,implemented using RFC 4944 andnew Tracks cannot be installed. </t> <t> In a LLN, the communicationVirtual 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/rfc8931" 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 aremote PCE may be slowprotocol that forwards individual fragments across a route-over mesh andunreactiverecovers them end torapid changes in the condition of the wireless communication. An attacker may introduce extra delay by selectively jamming some packets or some flows. The expectation is that the 6TiSCH Tracks enable enough redundancyend, with congestion control capabilities tomaintainprotect thecritical traffic in operation while new routes are calculatednetwork.</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/rfc9008" quoteTitle="true" derivedAnchor="RFC9008"> <front> <title>Using RPI Option Type, Routing Header for Source Routes, andprogrammed into the network. </t> <t> As with DetNetIPv6-in-IPv6 Encapsulation ingeneral, the communication withthePCE must be secured and should be protected against DoS attacks, including delay injectionRPL 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 andblackholing attacks,Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power andsecured as discussed inLossy Networks) is used to establish routing. The document enumerates thesecurity considerations defined for Abstractioncases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RFC 6554), andControl of Traffic Engineered Networks (ACTN) in Section 9 of <xref target='RFC8453'/>,IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon whichapplies equallytoDetNet and 6TiSCH. Indesign efficient compression of these headers. This document updates RFC 6553 by adding asimilar manner,change to thecommunication withRPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in theJRC must be securedDODAG Information Object (DIO) Configuration option to indicate this change andshould be protected against DoS attacksupdates RFC 8138 as well to consider the new Option Type whenpossible. </t> </section> <section anchor='phy'><name>Selective Jamming</name> <t> The Hopping Sequence of a TSCH networkthe RPL Option iswell-known, meaning that ifdecompressed.</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/rfc9010" quoteTitle="true" derivedAnchor="RFC9010"> <front> <title>Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) 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 arogue manages to identifymechanism for acell ofhost that implements aparticular flow, then it mayrouting-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery toselectively jamobtain reachability services across a network thatcell, without impacting any other traffic. This attack can be performed at the PHY layer without any knowledgeleverages RFC 6550 for its routing operations. It updates 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/rfc9031" quoteTitle="true" derivedAnchor="RFC9031"> <front> <title>Constrained Join Protocol (CoJP) for 6TiSCH</title> <author initials="M" surname="Vučinić" fullname="Mališa Vučinić" role="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 Richardson"> <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/rfc9032" quoteTitle="true" derivedAnchor="RFC9032"> <front> <title>Encapsulation of 6TiSCH Join and Enrollment Information Elements</title> <author initials="D" surname="Dujovne" fullname="Diego Dujovne" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="M" surname="Richardson" fullname="Michael Richardson"> <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/rfc9033" 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 Vilajosana"> <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 ofthe Layer-2 keys,Energy</organization> </author> <date year="2006"/> </front> </reference> <reference anchor="ANIMA" target="https://datatracker.ietf.org/doc/charter-ietf-anima/" quoteTitle="true" derivedAnchor="ANIMA"> <front> <title>Autonomic Networking Integrated Model andis very hard to detectApproach (anima)</title> <author> <organization showOnFrontPage="true">IETF</organization> </author> </front> </reference> <reference anchor="I-D.ietf-roll-aodv-rpl" quoteTitle="true" target="https://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</organization> </author> <author fullname="Mingui Zhang"> <organization showOnFrontPage="true">Huawei Technologies</organization> </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</organization> </author> <date month="April" day="4" year="2021"/> <abstract> <t indent="0"> Route discovery for symmetric anddiagnose because only one flowasymmetric Point-to-Point (P2P) traffic flows isimpacted. </t> <t> <xref target='I-D.tiloca-6tisch-robust-scheduling'/> proposes a method to obfuscate the hopping sequence and make it harder to perpetrate that particular attack. </t> </section> <section anchor='iee'><name>MAC-Layer Security</name> <t> This architecture operates on IEEE Std. 802.15.4 and expects the Link-Layer security to be enabled at all times between connected devices, except for the very first step of the device join process, where a joining device may need some initial, unsecured exchanges so as to obtain its initial key material. Inatypical deployment, all joined nodes use the same keys and rekeying needs to be global. </t> <t> The 6TISCH Architecture relies on the join process to deny authorization of invalid nodesdesirable feature in Low power andpreserve the integrity of the network keys. A rogueLossy Networks (LLNs). For thatmanaged to access the network can performpurpose, this document specifies alarge variety of attacks from DoS to injecting forged packets andreactive P2P route discovery mechanism for both hop-by-hop routinginformation. "Zero-trust" properties would be highly desirable butand source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances aremostly not available at the timeused to construct directional paths, in case some ofthis writing. <xref target='I-D.ietf-6lo-ap-nd'/> is a notable exception that protectstheownership of IPv6 addresseslinks between source andprevents a roguetarget nodewith L2 access from stealing and injecting traffic on behalf of a legitimate node.are asymmetric. </t><!-- <t></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="https://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"> ThejoinAd Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocolcan be zero-touch and leverage ANIMA procedures, as detailedis intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the<xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"> 6tisch Zero-Touch Secure Join protocol</xref>.network in an on-demand fashion. </t><t> Alternatively, the join protocol can be one-touch,</abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-manet-aodvv2-16"/> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-manet-aodvv2-16.txt"/> <refcontent>Work inwhich case the pledge is provisioned with a preshared key (PSK),Progress</refcontent> </reference> <reference anchor="I-D.thubert-6lo-bier-dispatch" quoteTitle="true" target="https://tools.ietf.org/html/draft-thubert-6lo-bier-dispatch-06" derivedAnchor="BITSTRINGS-6LORH"> <front> <title>A 6loRH for BitStrings</title> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor"> <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> <author initials="G" surname="Texier" fullname="Geraldine Texier"> <organization showOnFrontPage="true"/> </author> <date month="January" day="28" year="2019"/> </front> <seriesInfo name="Internet-Draft" value="draft-thubert-6lo-bier-dispatch-06"/> <refcontent>Work in Progress</refcontent> </reference> <reference anchor="CCAMP" target="https://datatracker.ietf.org/doc/charter-ietf-ccamp/" quoteTitle="true" derivedAnchor="CCAMP"> <front> <title>Common Control anduses CoJP as specifiedMeasurement Plane (ccamp)</title> <author> <organization showOnFrontPage="true">IETF</organization> </author> </front> </reference> <reference anchor="CCMstar" target="http://www.ieee802.org/15/pub/2004/15-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://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-10" quoteTitle="true" derivedAnchor="CONSTRAINED-VOUCHER"> <front> <title>Constrained Voucher Artifacts for Bootstrapping Protocols</title> <author initials="M" surname="Richardson" fullname="Michael Richardson"> <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<xref target="I-D.ietf-6tisch-minimal-security"/>. </t> --> </section> <section anchor='ts'><name>Time Synchronization</name> <t> Time SynchronizationProgress</refcontent> </reference> <reference anchor="I-D.ietf-roll-dao-projection" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-roll-dao-projection-16" derivedAnchor="DAO-PROJECTION"> <front> <title>Root initiated routing state inTSCH induces another event horizon wherebyRPL</title> <author fullname="Pascal Thubert"> <organization showOnFrontPage="true">Cisco Systems, Inc</organization> </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 enable anode will only communicate with another node if they are synchronizedRPL Root to install and maintain Projected Routes within its DODAG, along aguard time. The pledge discovers the synchronizationselected 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 thenetwork based on the timeclassical distributed operation ofreceptionRPL, either in terms of thebeacon. If an attacker synchronizes a pledge outsidesize ofthe guard timea Routing Header or in terms of path length, which impacts both thelegitimate nodes then the pledge will never see a legitimate beaconlatency andmay not discovertheattack.packet delivery ratio. </t><t>As discussed</abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-roll-dao-projection-16"/> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-16.txt"/> <refcontent>Work in<xref target='RFC8655'/>, measures must be takenProgress</refcontent> </reference> <reference anchor="I-D.selander-ace-cose-ecdhe" quoteTitle="true" target="https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-14" derivedAnchor="EDHOC"> <front> <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title> <author fullname="Göran Selander"> <organization showOnFrontPage="true">Ericsson AB</organization> </author> <author fullname="John Mattsson"> <organization showOnFrontPage="true">Ericsson AB</organization> </author> <author fullname="Francesca Palombini"> <organization showOnFrontPage="true">Ericsson AB</organization> </author> <date month="September" day="11" year="2019"/> <abstract> <t indent="0"> This document specifies Ephemeral Diffie-Hellman 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 toprotectestablish an OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, thetime synchronization,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-selander-ace-cose-ecdhe-14.txt"/> <refcontent>Work in Progress</refcontent> </reference> <reference anchor="I-D.ietf-ace-coap-est" quoteTitle="true" target="https://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 Richardson"> <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> <organization showOnFrontPage="true">FieldComm Group</organization> </author> </front> </reference> <reference anchor="IEC62439" target="https://webstore.iec.ch/publication/24438" quoteTitle="true" derivedAnchor="IEC62439"> <front> <title>Industrial communication networks - High availability automation networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR)</title> <author> <organization showOnFrontPage="true">IEC</organization> </author> <date year="2016"/> </front> <seriesInfo name="IEC" value="62439-3:2016"/> </reference> <reference anchor="IEEE802154" target="https://ieeexplore.ieee.org/document/7460875" quoteTitle="true" derivedAnchor="IEEE802154"> <front> <title>IEEE Standard for Low-Rate Wireless Networks</title> <author> <organization showOnFrontPage="true">IEEE</organization> </author> <date month="April" year="2016"/> </front> <seriesInfo name="IEEE Standard" value="802.15.4-2015"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/> </reference> <reference anchor="IEEE802154e" target="https://ieeexplore.ieee.org/document/6185525" quoteTitle="true" derivedAnchor="IEEE802154e"> <front> <title>IEEE Standard for Local and metropolitan area networks -- Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer</title> <author> <organization showOnFrontPage="true">IEEE</organization> </author> <date month="April" year="2012"/> </front> <seriesInfo name="IEEE Standard" value="802.15.4e-2012"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6185525"/> </reference> <reference anchor="ISA100" target="https://www.isa.org/isa100/" quoteTitle="true" derivedAnchor="ISA100"> <front> <title>ISA100, Wireless Systems for Automation</title> <author> <organization showOnFrontPage="true">ISA/ANSI</organization> </author> </front> </reference> <reference anchor="ISA100.11a" target="https://webstore.iec.ch/publication/65581" quoteTitle="true" derivedAnchor="ISA100.11a"> <front> <title>Wireless Systems for6TiSCH this includes ensuring that the Absolute Slot Number (ASN), which is the node's sense of time, is not compromised. Once installedIndustrial Automation: Process Control andas long as the node is synchronized to the network, ASN is implicit in the transmissions. </t> <t> <xref target='IEEE802154'>IEEE Std. 802.15.4</xref> specifies thatRelated Applications - ISA100.11a-2011</title> <author> <organization showOnFrontPage="true">ISA/ANSI</organization> </author> <date year="2011"/> </front> <seriesInfo name="IEC" value="62734:2014"/> </reference> <reference anchor="I-D.thubert-6man-unicast-lookup" quoteTitle="true" target="https://tools.ietf.org/html/draft-thubert-6man-unicast-lookup-00" derivedAnchor="ND-UNICAST-LOOKUP"> <front> <title>IPv6 Neighbor Discovery Unicast Lookup</title> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abegnoli"> <organization showOnFrontPage="true"/> </author> <date month="July" day="29" year="2019"/> </front> <seriesInfo name="Internet-Draft" value="draft-thubert-6man-unicast-lookup-00"/> <refcontent>Work ina TSCH network, the nonce that is used for the computation of the Message Integrity Code (MIC) to secure Link-Layer frames is composed of the address of the source of the frameProgress</refcontent> </reference> <reference anchor="PCE" target="https://datatracker.ietf.org/doc/charter-ietf-pce/" quoteTitle="true" derivedAnchor="PCE"> <front> <title>Path Computation Element (pce)</title> <author> <organization showOnFrontPage="true">IETF</organization> </author> </front> </reference> <reference anchor="I-D.pthubert-raw-architecture" quoteTitle="true" target="https://tools.ietf.org/html/draft-pthubert-raw-architecture-05" derivedAnchor="RAW-ARCHITECTURE"> <front> <title>Reliable andof the ASN. The standard assumes that the ASN is distributed securely by other means. The ASN is not passed explicitlyAvailable Wireless Problem Statement</title> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="G. Z." surname="Papadopoulos" fullname="Georgios Papadopoulos"> <organization showOnFrontPage="true"/> </author> <date month="November" day="15" year="2020"/> </front> <seriesInfo name="Internet-Draft" value="draft-pthubert-raw-architecture-05"/> <refcontent>Work inthe data frames and does not constitute a complete anti-replay protection. It results that upper layer protocols must provide a wayProgress</refcontent> </reference> <reference anchor="I-D.ietf-raw-use-cases" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-raw-use-cases-01" derivedAnchor="RAW-USE-CASES"> <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 todetect duplicates and cope with them. </t> <t> If the receiver and the sender have a different sense of ASN, the MIC will not validate and the frame will be dropped. In that sense, TSCH induces an event horizon whereby only nodes that have a common sense of ASN can talkachieve properties similar toone another in an authenticated manner. With 6TiSCH,those of wired deterministic networks. At thepledge discoverssame time, atentative ASN in beacons from nodes that have already joined the network. But even if the beacon can be authenticated, the ASNnumber of use cases cannot betrusted as it could be a replay by an attackersolved with wires andthus could announce an ASN that represents a time in the past. Ifjustify thepledge uses an ASN that is learned from a replayed beacon for an encrypted transmission, a nonce-reuse attack becomes possibleextra effort of going wireless. This document presents wireless use cases demanding reliable andthe network keys may be compromised.available behavior. </t></section> <section anchor='asv'><name>Validating ASN</name> <t> After obtaining the tentative ASN, a pledge that wishes to join the 6TiSCH network must use a join protocol to obtain its security keys. The join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP). In the minimal setting defined</abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-raw-use-cases-01"/> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-raw-use-cases-01.txt"/> <refcontent>Work in<xref target='I-D.ietf-6tisch-minimal-security'/>,Progress</refcontent> </reference> <reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2474" quoteTitle="true" derivedAnchor="RFC2474"> <front> <title>Definition of theauthentication 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 <xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> in order to enable pledge joining based on certificates and/or inter-domain communication. </t> <t> As detailedDifferentiated Services Field (DS Field) in<xref target='rflo'/>, a Join Proxy (JP) helps the pledge for the join procedure by relayingthelink-scope Join Request overIPv4 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 IPnetwork to a Join Registrar/Coordinator (JRC) that can authenticateheader field, called the 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/rfc2545" quoteTitle="true" derivedAnchor="RFC2545"> <front> <title>Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing</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 thepledgeformat of two BGP attributes (MP_REACH_NLRI andvalidateMP_UNREACH_NLRI) thatit is attachedcan be used to announce and withdraw theappropriate network. As a resultannouncement of reachability information. This document defines how compliant systems should make use of those attributes for theCoJP exchange,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/rfc3209" 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 thepledge is in possessionuse ofa Link-Layer materialRSVP (Resource Reservation Protocol), includingkeys and a short address, and ifall theASN is knownnecessary extensions, tobe correct, all traffic can now be secured using CCM* <xref target='CCMstar'/> atestablish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since theLink-Layer. </t> <t> The authentication steps must be such that they cannot be replayed byflow along anattacker, and they must not depend on the tentative ASN being valid. During the authentication,LSP is completely identified by thekeying material thatlabel applied at thepledge obtains fromingress node of theJRC does not provide protection against spoofed ASN. Oncepath, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</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/rfc3444" quoteTitle="true" derivedAnchor="RFC3444"> <front> <title>On thepledgeDifference 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. Schoenwaelder"> <organization showOnFrontPage="true"/> </author> <date year="2003" month="January"/> <abstract> <t indent="0">There hasobtainedbeen ongoing confusion about thekeys to usedifferences between Information Models and Data Models for defining managed objects in network management. This document explains thenetwork, it may still need to verifydifferences between these terms by analyzing how existing network management model specifications (from theASN. IfIETF and other bodies such as thenonce used inInternational Telecommunication Union (ITU) or theLayer-2 security derives fromDistributed Management Task Force (DMTF)) fit into theextended (MAC-64) address, then replayinguniverse of Information Models and Data Models. This memo documents theASN alone cannot enable a nonce-reuse attack unlessmain results of thesame node is lost its state with a previous ASN. But if8th workshop of thenonce derives fromNetwork Management Research Group (NMRG) of theshort address (e.g., assignedInternet Research Task Force (IRTF) hosted by theJRC) thenUniversity of Texas at Austin. This memo provides information for theJRC must ensure that it never assigns short addressesInternet 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/rfc3963" 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 thatwere already givenenables Mobile Networks tothis or other nodes with the same keys. In other words, the network must be rekeyed beforeattach to different points in theJRC runs outInternet. The protocol is an extension ofshort addresses. </t> <!--t> Once theMobile IPv6 and allows session continuity for every nodeobtainsin thekeys fromMobile Network as theJRC, an additional step maynetwork moves. It also allows every node in the Mobile Network to berequiredreachable while moving around. The Mobile Router, which connects the network toensure thattheASNInternet, runs the NEMO Basic Support protocol with its Home Agent. The protocol iscorrect before encrypting any message. Ifdesigned so that network mobility is transparent to theASNnodes inside the Mobile Network. [STANDARDS-TRACK]</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/rfc4080" 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 Bosch"> <organization showOnFrontPage="true"/> </author> <date year="2005" month="June"/> <abstract> <t indent="0">The Next Steps in Signaling (NSIS) working group isnot guaranteed to be correct by other means, the pledge should perform a non-replayable exchange (e.g., usingconsidering protocols for signaling information about anoncedata flow along its path in thepayload that does not derive from ASN) with a peer node that is trusted and has already joined (e.g., the JP or a RPL time parent).network. Therequest by the pledge should not be encrypted at the Link-Layer but only authenticated to avoid nonce-replay attacks. A successful authenticated exchange proves a common sense of ASN and encrypted traffic can now happen. </t--> </section> <section anchor='keying'><name>Network Keying and Rekeying</name> <t> <xref target='rflo'/> provides an overviewNSIS suite ofthe CoJP process described in <xref target='I-D.ietf-6tisch-minimal-security'/> by which an LLN can be assembledprotocols is envisioned to support various signaling applications that need to install and/or manipulate such state in thefield, having been provisioned in a lab. <xref target='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> is futurenetwork. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.</t> <t indent="0">This document provides a model for the network entities thatpreceedstake part in such signaling, andthen leveragesfor theCoJP protocol usingrelationship between signaling and the<xref target='I-D.ietf-anima-constrained-voucher'/> constrained profilerest of<xref target='I-D.ietf-anima-bootstrapping-keyinfra'/> (BRSKI). This later work requires a yet-to-be standardized Lighweight Authenticated Key Exchange protocol. </t> <t> The CoJPnetwork operation. We decompose the overall signaling protocolresults in distribution ofsuite into anetwork-wide key that is to be usedgeneric (lower) layer, with<xref target='IEEE802154'/> security. The details of use are described in <xref target='I-D.ietf-6tisch-minimal-security'/> sections 9.2 and 9.3.2. </t> <t> The BRSKI mechanism may lead toseparate upper layers for each specific signaling application. This memo provides information for the Internet community.</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/rfc4291" 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 theuseaddressing architecture of theCoJP protocol, in which case it also results in distributionIP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations ofa network-wide key. AlternativelyIPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t> <t indent="0">This document obsoletes RFC 3513, "IP Version 6 Addressing 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/rfc4903" 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 theBRSKI mechanismnotion that a subnet maybe followedspan multiple links connected byuse of <xref target='I-D.ietf-ace-coap-est'/> to enroll certificates for each device. In that case,routers. This memo documents thecertificates may be usedissues and potential problems that have been raised with such an<xref target='IEEE802154'/> key agreement protocol.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/rfc4919" 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 statement, and goals for transmitting IP over IEEE 802.15.4 networks. Thedescriptionset of goals enumerated in thismechanism, while conceptually straight forward still has significant standardization hurdles to pass. </t> <t> <xref target='I-D.ietf-6tisch-minimal-security'/> section 9.2document form an initial set only. This memo provides information 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/rfc5340" 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 describesa mechanism to change (rekey)thenetwork. There are a number of reasons to initiate a network rekey:modifications toremove unwanted (corrupt/malicious) nodes,OSPF torecover unused 2-byte short addresses, orsupport version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due tolimitschanges inencryption algorithms. For allprotocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing themechanisms that distribute a network-wide key, rekeyingprotocol version from version 2 to version 3. OSPF for IPv6 is alsoneeded on a periodic basis. In more details: </t> <t></t><ul spacing='normal'> <li> The mechanism described in <xref target='I-D.ietf-6tisch-minimal-security'/> section 9.2 requires advance communicationreferred to as OSPF version 3 (OSPFv3).</t> <t indent="0">Changes betweenthe JRCOSPF for IPv4, OSPF Version 2, andevery one ofOSPF for IPv6 as described herein include thenodes beforefollowing. Addressing semantics have been removed from OSPF packets and thekey change. Given that many nodes may be sleepy, this operation may take a significant amount of time,basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses andmay consumeprefixes. OSPF now runs on asignificant portion ofper-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from theavailable bandwidth. As such, network-wide rekeysOSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).</t> <t indent="0">Even with larger IPv6 addresses, most packets inorder to exclude nodes thatOSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 havebecome malicious will not be particularly quick. If a rekey is alreadybeen relaxed. In addition, option handling has been made more flexible.</t> <t indent="0">All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in 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/rfc5974" quoteTitle="true" derivedAnchor="RFC5974"> <front> <title>NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling</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 Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations inprogress, buttheunwanted node has not yet been updated, then itInternet. It ispossible to to just continue the operation. If the unwanted node has already received the update, thenin accordance with therekey operation will needframework and requirements developed in NSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar tobe restarted. </li> <li>RSVP and extends it. Thecryptographic mechanisms used by IEEE Std. 802.15.4 includeQoS NSLP is independent of the2-byte short address inunderlying QoS specification or architecture and provides support for different reservation models. It is simplified by thecalculationelimination of support for multicast flows. This specification explains thecontext. A nonce-reuse attack may become feasible if a short address is reassigned to another node whileoverall protocol approach, describes thesame network-wide keys aredesign decisions made, and provides examples. It specifies object, message formats, and processing rules. This document defines an Experimental Protocol for the 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/rfc6275" quoteTitle="true" derivedAnchor="RFC6275"> <front> <title>Mobility Support inoperation. A networkIPv6</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 thatgains and losesallows nodeson a regular basis is likelytoreachremain reachable while moving around in the65536 limitIPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the2-byte (16-bit) short addresses, even if the network has onlyInternet. While situated away from its home, afew thousand nodes. Network planners should considermobile node is also associated with a care-of address, which provides information about theneedmobile node's current location. IPv6 packets addressed torekeya mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache thenetwork onbinding of aperiodic basis in ordermobile node's home address with its care-of address, and torecover 2-byte addresses. The rekey can update the short addressesthen send any packets destined foractive nodes if desired, but there is actually no need to do this as long asthekey has been changed. </li> <li> With TSCH asmobile node directly to itstandsatthe time ofthiswriting, the ASN will wrap after 2^40 timeslot durations, which meanscare-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate withthe default values around 350 years. Wrapping ASN is not expected to happen within the lifetimemobile 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/rfc6347" 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 ofmost LLNs. Yet, should the ASN wrap,thenetwork must be rekeyedDatagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications toavoidcommunicate in anonce-reuse attack. </li> <li> Many cipher algorithms have some suggested limits on how many bytes should be encrypted withway thatalgorithm before a new keyisused. These numbers are typically in the manydesigned tohundreds of gigabytes of data. On very fast backbone networks this becomes an important concern. On LLNs with typical data rates in the kilobits/second, this concernprevent eavesdropping, tampering, or message forgery. The DTLS protocol issignificantly less. With IEEE Std. 802.15.4 as it stands at the time of this writing, the ASN will wrap beforebased on thelimitsTransport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of thecurrent L2 crypto (AES-CCM-128)underlying transport arereached, so the problem should never occur. </li> <li> In any fashion, ifpreserved by theLLN is expectedDTLS protocol. This document updates DTLS 1.0 tooperate continuouslywork 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/rfc6606" quoteTitle="true" derivedAnchor="RFC6606"> <front> <title>Problem Statement and Requirements fordecades then the operatorsIPv6 over Low-Power Wireless 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) areadvised to plan for the need to rekey. </li> </ul><t> </t> <t> Except for urgent rekeys causedformed bymalicious nodes,devices that are compatible with therekey operation described in <xref target='I-D.ietf-6tisch-minimal-security'/> canIEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could bedone as a background taskobtained andcanmaintained. Thus, it should bedone incrementally.considered how 6LoWPAN formation and multi-hop routing could be supported.</t> <t indent="0">This document provides the problem statement and design space for 6LoWPAN routing. Itis a make-before-break mechanism. The switch over todefines thenew key is not signaled by time, but rather by observation thatrouting requirements for 6LoWPANs, considering thenew key is in use. As such,low-power and other particular characteristics of theupdate can take as long as needed, or occur in as short a time as practical. </t> </section> </section> <section><name>Acknowledgments</name> <section><name>Contributors</name> <t>The co-authorsdevices and links. The purpose of this documentare listed below: </t><dl spacing='normal'> <dt>Thomas Watteyne</dt><dd> for his contributionis not tothe whole design, in particular on TSCH and security, andrecommend specific solutions but tothe open source community with openWSN that he created. </dd> <dt>Xavier Vilajosana</dt><dd> who leadprovide general, layer-agnostic guidelines about the design ofthe minimal support with RPL and contributed deeply6LoWPAN routing that can lead tothe 6top designfurther analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as theG-MPLS operation ofIETF ROLL WG. This document is not an Internet Standards Trackswitching; </dd> <dt>Kris Pister</dt><dd>specification; it is published forcreating TSCH and his continuing guidance through the elaborationinformational 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/rfc6830" 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 protocol that enables separation ofthis design; </dd> <dt>Malisa Vucinic</dt><dd> for the work on the one-touch join processIP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) andhis contributionRouting Locators (RLOCs). No changes are required to either host protocol stacks or to theSecurity Design Team; </dd> <dt>Michael Richardson</dt><dd> for his leadership role in"core" of theSecurity Design TeamInternet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", andhis contribution throughout this document; </dd> <dt>Tero Kivinen</dt><dd> for his contributionoffers Traffic Engineering, multihoming, and mobility benefits tothe security work in generalearly adopters, even when there are relatively few LISP-capable sites.</t> <t indent="0">Design and development of LISP was largely motivated by thesecurity section in particular. </dd> <dt>Maria Rita Palattella</dt><dd> for managingproblem statement produced by theTerminologyOctober 2006 IAB Routing and Addressing Workshop. This documentmerged into this through the work of 6TiSCH; </dd> <dt>Simon Duquennoy</dt><dd>defines an Experimental Protocol forhis contribution to the open source community withthe6TiSCH implementaton of contiki,Internet community.</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/rfc7426" quoteTitle="true" derivedAnchor="RFC7426"> <front> <title>Software-Defined Networking (SDN): Layers and Architecture Terminology</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 approach forhis contributionnetwork programmability, that is, the capacity toMSFinitialize, control, change, andautonomous unicast cells. </dd> <dt>Qin Wang</dt><dd> who leadmanage network behavior dynamically via open interfaces. SDN emphasizes thedesignrole ofthe 6top sublayer and contributed related text that was moved and/or adaptedsoftware inthis document; </dd> <dt>Rene Struik</dt><dd>running networks through the introduction of an abstraction for thesecurity section and his contributiondata 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 what exactly SDN is, what theSecurity Design Team; </dd> <dt>Robert Assimiti</dt><dd> for his breakthrough work on RPL over TSCH and initial textlayer structure is in an SDN architecture, andguidance; </dd> </dl><t> </t> </section> <section><name>Special Thanks</name><t> Special thanks to Jonathan Simon, Giuseppe Piro, Subir Dashow layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions andYoshihiro Ohbaprovides a concise reference fortheir deep contribution totheinitial security work, to Yasuyuki Tanaka for his workSDN research community based onimplementationrelevant peer-reviewed literature, the RFC series, andsimulationrelevant documents by other standards organizations.</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/rfc8578" 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 industries thattremendously helped buildhave in common arobust system, to Diego Dujovneneed forstarting and leading the SF0 effort"deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane toTengfei Chang for evolving it intheMSF. </t><t> Special thanks also to Pat Kinney, Charlie Perkinstransport of time-sensitive data. These use cases differ notably in their network topologies andBob Heilespecific desired behavior, providing as a group broad industry context fortheir support in maintainingDeterministic Networking (DetNet). For each use case, this document will identify theconnection activeuse case, identify representative solutions used today, andthe design in line with work happening at IEEE 802.15. </t> <t> Special thanks to Ted Lemon who was the INT Area A-D while thisdescribe 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/rfc8613" 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 documentwas initiateddefines Object Security forhis great support and help throughout, and to Suresh Krishnan who took over with that kind efficiencyConstrained RESTful Environments (OSCORE), a method for application-layer protection ofhis till publication. </t><t> Also special thanks to Ralph Droms who performedthefirst INT Area Directorate review, that was very deepConstrained Application Protocol (CoAP), using CBOR Object Signing andthoroughEncryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes andradically changed the orientationsnetworks supporting a range ofthis document, and then to Eliot Learproxy operations, including translation between different transport protocols.</t> <t indent="0">Although an optional functionality of CoAP, OSCORE alters CoAP options processing andCarlos Pignataro who help finalizeIANA registration. Therefore, this documentin preparation toupdates 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/rfc8939" quoteTitle="true" derivedAnchor="RFC8939"> <front> <title>Deterministic Networking (DetNet) Data Plane: IP</title> <author initials="B." surname="Varga" fullname="B. Varga" role="editor"> <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 theIESG reviews,Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service toGorry Fairhurst, David Mandelberg, Qin Wu, Francis Dupont, Eric Vyncke, Mirja Kuhlewind, Roman Danyliw, Benjamin Kaduk and Andrew Malis, who contributedIP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, thefinal shaping of thisexisting IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This documentthroughbuilds on theIESG review procedure. </t> </section> <section><name>And Do not Forget</name> <t>ThisDetNet architecture (RFC 8655) and data plane framework (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/rfc8995" 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 documentis the resultspecifies automated bootstrapping ofmultiple interactions,an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, inparticular duringcombination with a manufacturer's authorizing service, both online and offline. We call this process the6TiSCH (bi)Weekly Interim call, relayed throughBootstrapping 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. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the6TiSCH mailing list atcryptographic identity of theIETF, overnew key infrastructure is successfully deployed to thecourse of more than 5 years. </t><t>device. Theauthors wishestablished secure connection can be used tothank in arbitrary order: Alaeddine Weslati, Chonggang Wang, Georgios Exarchakos, Zhuo Chen, Georgios Papadopoulos, Eric Levy-Abegnoli, Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Deji Chen, Martin Turon, Dominique Barthel, Elvis Vogli, Geraldine Texier, Guillaume Gaillard, Herman Storey, Kazushi Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Toutain, Maik Seewald, Michael Behringer, Nancy Cam Winget, Nicola Accettura, Nicolas Montavont, Oleg Hahm, Patrick Wetterwald, Paul Duffy, Peter van der Stock, Rahul Sen, Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin-Lopez, Raghuram Sudhaakar, Sedat Gormus, Shitanshu Shah, Steve Simlo, Tina Tsou, Tom Phinney, Xavier Lagrange, Ines Robles and Samita Chakrabarti for their participation and various contributions. </t> </section> </section> </middle> <back> <displayreference target="I-D.ietf-6tisch-minimal-security" to="MIN-SECURITY"/> <displayreference target="I-D.ietf-6lo-backbone-router" to="6BBR-DRAFT"/> <displayreference target="I-D.ietf-6lo-fragment-recovery" to="RECOV-FRAG"/> <displayreference target="I-D.ietf-6lo-minimal-fragment" to="MIN-FRAG"/> <displayreference target="I-D.ietf-6lo-ap-nd" to="AP-ND"/> <displayreference target="I-D.ietf-roll-useofrplinfo" to="USEofRPLinfo"/> <displayreference target="I-D.ietf-roll-unaware-leaves" to="RUL-DRAFT"/> <displayreference target="I-D.ietf-6tisch-enrollment-enhanced-beacon" to="ENH-BEACON"/> <displayreference target="I-D.ietf-6tisch-msf" to="MSF"/> <references><name>Normative References</name> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification --> <!-- <?rfc include="reference.RFC.2119"?> Key words for use in RFCsdeploy a locally issued certificate toIndicate Requirement Levels --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml'/> <!-- neighbor Discovery for IP version 6 (IPv6) --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml'/> <!-- IPv6 Stateless Address Autoconfiguration --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml'/> <!-- 6LoWPAN --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml'/> <!-- Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml'/> <!-- RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml'/> <!-- Routing Metrics Used for Path Calculation in LLNs --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6552.xml'/> <!-- RPL OF0: Objective Function Zero for RPL--> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml'/> <!-- RPL Option for Carrying RPL Information in Data-Plane Datagrams --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml'/> <!-- An IPv6 Routing Header for Source Routes with RPL --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml'/> <!-- neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml'/> <!-- CoAP --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml'/> <!-- 6LoRH coding dispatch--> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8137.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8138.xml'/> <!-- 6LoRH routing dispatch--> <!-- <?rfc include='reference.RFC.8174'?> Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words--> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8180.xml'/> <!-- 6TiSCH minimal --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml'/> <!-- Internet Protocol, Version 6 (IPv6) Specification --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8480.xml'/> <!-- 6top protocol --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml'/> <!-- ACTN --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml'/> <!-- RFC6775 update --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml'/> <!-- Terms Used in Routing for Low-Power and Lossy Networks --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7554.xml'/> <!-- 6TiSCH TSCH --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml'/> <!-- Terminology for Constrained-Node Networks --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5889.xml'/> <!-- IP Addressing Model in Ad Hoc Networks --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml'/> <!-- DetNet Architecture --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-minimal-security.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-backbone-router.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-fragment-recovery.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-minimal-fragment.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-ap-nd.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-useofrplinfo.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-unaware-leaves.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-enrollment-enhanced-beacon.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-msf.xml'/> </references> <references><name>Informative References</name> <!-- <?rfc include="reference.RFC.6620"?> FCFS SAVI: First-Come, First-Served Source Address Validation --> <!--?rfc include="reference.RFC.6655"?--> <!-- AES-CCM Cipher Suites for Transport Layer Security (TLS) --> <!--?rfc include="reference.RFC.5191"?--> <!-- Protocol for Carrying Authentication for Network Access (PANA) --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml'/> <!-- OSPFthe 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/rfc9035" quoteTitle="true" derivedAnchor="RFC9035"> <front> <title>A Routing Protocol forIPv6 --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml'/> <!-- Mobility Support in IPv6 --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml'/> <!-- Differentiated Services Field --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml'/> <!-- BGP-4 Multiprotocol ExtensionsLow-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option forIPv6 Inter-Domain Routing --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3963.xml'/> <!-- Network Mobility (NEMO) --> <!-- <?rfc include="reference.RFC.3972"?> CGA --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml'/> <!-- RSVP TE --> <!-- <?rfc include="reference.RFC.3971"?> SEcure Neighbor Discovery (SEND) --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml'/> <!-- IP Version 6 Addressing Architecture --> <!-- <?rfc include="reference.RFC.4429"?> IP Version 6 Optimistic DAD --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3444.xml'/> <!-- OntheDifference between Information Models and Data Models --> <!-- <?rfc include="reference.RFC.3610"?> Counter with CBC-MAC (CCM) --> <!-- 6TiSCH --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4080.xml'/> <!-- Next Steps6LoWPAN 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 inSignaling (NSIS): Framework --> <!-- <?rfc include="reference.RFC.4389"?> IP Version 6 ND Proxy --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml'/> <!-- IPv6 over Low-Power Wireless Personal Area Networks --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4903.xml'/> <!-- IPv6 Multi-Link Subnet Issues --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5974.xml'/> <!-- NSIS Signaling Layerthe Routing Protocol(NSLP)forQuality-of-Service Signaling --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml'/> <!-- Datagram Transport Layer Security Version 1.2 --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml'/> <!-- The Locator/ID Separation Protocol (LISP) --> <!--?rfc include="reference.RFC.6997"?--> <!-- Reactive Discovery of Point-to-Point Routes inLow-Power and Lossy Networks--> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml'/> <!-- Software-Defined Networking (SDN): Layers(RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance andArchitecture Terminology --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6606.xml'/> <!-- Problem Statementto specify the behavior of nodes compliant with RFC 8138 when the bit is set andRequirements 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/reference.I-D.ietf-roll-rpl-industrial-applicability.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-dtsecurity-zerotouch-join.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-object-security.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-manet-aodvv2.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml'/> <!-- Deterministic Networking Use Cases --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-detnet-ip.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-bootstrapping-keyinfra.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-aodv-rpl.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lwig-6lowpan-virtual-reassembly.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-dao-projection.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.rahul-roll-mop-ext.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.selander-ace-cose-ecdhe.xml'/> <!-- <?rfc include='reference.I-D.svshah-tsvwg-lln-diffserv-recommendations'?> --> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-roll-bier.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-bier-replication-elimination.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-6lo-bier-dispatch.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thubert-6man-unicast-lookup.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.pthubert-raw-problem-statement.xml'/> <!--?rfc include='reference.I-D.bernardos-raw-use-cases'?--> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.tiloca-6tisch-robust-scheduling.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ace-coap-est.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-constrained-voucher.xml'/>unset.</t> </abstract> </front> <seriesInfo name="RFC" value="9035"/> <seriesInfo name="DOI" value="10.17487/RFC9035"/> </reference> <referenceanchor='IEEE802154'>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>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area<title>Robust Scheduling against Selective Jamming in 6TiSCH Networks</title> <author fullname="Marco Tiloca"> <organization showOnFrontPage="true">RISE AB</organization> </author> <author fullname="Simon Duquennoy"> <organization showOnFrontPage="true">Yanzi Networks</title> <author> <organization>IEEE standardAB</organization> </author> <author fullname="Gianluca Dini"> <organization showOnFrontPage="true">University of Pisa</organization> </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 forInformation Technology</organization> </author> <date/>6TiSCH. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-tiloca-6tisch-robust-scheduling-02"/> <format type="TXT" target="https://www.ietf.org/archive/id/draft-tiloca-6tisch-robust-scheduling-02.txt"/> <refcontent>Work in Progress</refcontent> </reference> <referenceanchor='CCMstar' target='www.ieee802.org/15/pub/2004/15-04-0537-00-004b-formal-specification-ccm-star-mode-operation.doc'>anchor="I-D.ietf-roll-rpl-industrial-applicability" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-02" derivedAnchor="RPL-APPLICABILITY"> <front><title> Formal Specification of the CCM* Mode of Operation </title><title>RPL applicability in industrial networks</title> <authorfullname='Rene Struik'> <organization>IEEE standard for Information Technology</organization>fullname="Tom Phinney" role="editor"> </author> <author fullname="Pascal Thubert"> </author> <author fullname="Robert Assimiti"> </author> <datemonth='September' year='2004'/>month="October" day="21" year="2013"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-roll-rpl-industrial-applicability-02"/> <refcontent>Work in Progress</refcontent> </reference> <referenceanchor='IEEE802154e'>anchor="I-D.thubert-roll-bier" quoteTitle="true" target="https://tools.ietf.org/html/draft-thubert-roll-bier-02" derivedAnchor="RPL-BIER"> <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</organization><title>RPL-BIER</title> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor"> <organization showOnFrontPage="true"/> </author> <datemonth='April' year='2012'/>month="July" day="24" year="2018"/> </front> <seriesInfo name="Internet-Draft" value="draft-thubert-roll-bier-02"/> <refcontent>Work in Progress</refcontent> </reference><!--reference anchor="IEEE802.1TSNTG" target="http://www.ieee802.org/1/pages/avbridges.html"><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>IEEE 802.1 Time-Sensitive Networks Task Group</title> <author> <organization>IEEE Standards Association</organization><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</organization> </author> <author fullname="Michael Richardson"> <organization showOnFrontPage="true">Sandelman Software Works</organization> </author> <author initials="R" surname="Sahoo" fullname="Rabi Narayan Sahoo"> <organization showOnFrontPage="true">Juniper</organization> </author> <dateday="08"month="March"year="2013" />day="17" year="2021"/> </front></reference--><seriesInfo name="Internet-Draft" value="draft-ietf-roll-capabilities-08"/> <refcontent>Work in Progress</refcontent> </reference> <referenceanchor='WirelessHART'>anchor="S-ALOHA" target="https://dl.acm.org/citation.cfm?id=1024920" quoteTitle="true" derivedAnchor="S-ALOHA"> <front><title>Industrial Communication Networks - Wireless Communication Network<title>ALOHA packet system with andCommunication Profiles - WirelessHART - IEC 62591</title> <author> <organization>www.hartcomm.org</organization>without slots and capture</title> <author surname="Roberts" fullname="Lawrence G. Roberts"> </author> <dateyear='2010'/>month="April" year="1975"/> </front> <refcontent>ACM SIGCOMM Computer Communication Review</refcontent> <seriesInfo name="DOI" value="10.1145/1024916.1024920"/> </reference> <referenceanchor='HART'>anchor="I-D.thubert-bier-replication-elimination" quoteTitle="true" target="https://tools.ietf.org/html/draft-thubert-bier-replication-elimination-03" derivedAnchor="TE-PREF"> <front><title>Highway Addressable remote Transducer, a group of specifications<title>BIER-TE extensions forindustrial processPacket Replication andcontrol devices administered by the HART Foundation</title> <author> <organization>www.hartcomm.org</organization> </author> <date/> </front> </reference> <reference anchor='ISA100.11a' target='http://www.isa.org/Community/SP100WirelessSystemsforAutomation'> <front> <title>Wireless Systems for Industrial Automation: Process ControlElimination Function (PREF) andRelated Applications - ISA100.11a-2011 - IEC 62734</title> <author> <organization>ISA/ANSI</organization>OAM</title> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor"> <organization showOnFrontPage="true"/> </author><date year='2011'/> </front> </reference> <reference anchor='ISA100' target='https://www.isa.org/isa100/'> <front> <title>ISA100, Wireless Systems for Automation</title> <author> <organization>ISA/ANSI</organization><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/><date month="March" day="3" year="2018"/> </front> <seriesInfo name="Internet-Draft" value="draft-thubert-bier-replication-elimination-03"/> <refcontent>Work in Progress</refcontent> </reference> <referenceanchor='TEAS' target='https://dataTracker.ietf.org/doc/charter-ietf-teas/'>anchor="TEAS" target="https://datatracker.ietf.org/doc/charter-ietf-teas/" quoteTitle="true" derivedAnchor="TEAS"> <front> <title>Traffic Engineering Architecture andSignaling</title> <author> <organization>IETF</organization> </author> <date/> </front> </reference> <reference anchor='ANIMA' target='https://dataTracker.ietf.org/doc/charter-ietf-anima/'> <front> <title>Autonomic Networking Integrated Model and Approach</title>Signaling (teas)</title> <author><organization>IETF</organization><organization showOnFrontPage="true">IETF</organization> </author><date/></front> </reference> <referenceanchor='PCE' target='https://dataTracker.ietf.org/doc/charter-ietf-pce/'>anchor="I-D.ietf-lwig-6lowpan-virtual-reassembly" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reassembly-02" derivedAnchor="VIRTUAL-REASSEMBLY"> <front><title>Path Computation Element</title> <author> <organization>IETF</organization><title>Virtual reassembly buffers in 6LoWPAN</title> <author fullname="Carsten Bormann"> <organization showOnFrontPage="true">Universitaet Bremen TZI</organization> </author><date/> </front> </reference> <reference anchor='CCAMP' target='https://dataTracker.ietf.org/doc/charter-ietf-ccamp/'> <front> <title>Common Control and Measurement Plane</title> <author> <organization>IETF</organization><author fullname="Thomas Watteyne"> <organization showOnFrontPage="true">Analog Devices</organization> </author><date/><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. This has been always possible with the original fragmentation design of RFC 4944. Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book, this has not been extensively described in the literature. The present document attempts to fill that gap. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-lwig-6lowpan-virtual-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> <referenceanchor='AMI' target='https://www.energy.gov/sites/prod/files/2016/12/f34/AMI%20Summary%20Report_09-26-16.pdf'>anchor="WirelessHART" target="https://webstore.iec.ch/publication/24433" quoteTitle="true" derivedAnchor="WirelessHART"> <front><title>Advanced Metering Infrastructure<title>Industrial networks - Wireless communication network andCustomer Systems </title>communication profiles - WirelessHART(TM)</title> <author><organization>US Department of Energy</organization><organization showOnFrontPage="true">International Electrotechnical Commission</organization> </author> <dateyear='2006'/>month="March" year="2016"/> </front> <seriesInfo name="IEC" value="62591:2016"/> </reference> <referenceanchor='S-ALOHA' target='https://dl.acm.org/citation.cfm?id=1024920'>anchor="I-D.ietf-6tisch-dtsecurity-zerotouch-join" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join-04" derivedAnchor="ZEROTOUCH-JOIN"> <front><title>ALOHA Packet System With and Without Slots and Capture</title><title>6tisch Zero-Touch Secure Join protocol</title> <authorsurname='Roberts' fullname='Lawrence G. Roberts'> <organization>ACM SIGCOMM Computer Communication Review</organization>fullname="Michael Richardson"> <organization showOnFrontPage="true">Sandelman Software Works</organization> </author> <datemonth='April' year='1975'/> </front> <seriesInfo name='doi' value='10.1145/1024916.1024920'/> </reference> <reference anchor='IEC62439' target='https://webstore.iec.ch/publication/7018'> <front> <title>Industrial communication networks - High availability automation networks - Part 3: Parallel Redundancy Protocol (PRP)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], andHigh-availability Seamless Redundancy (HSR) - IEC62439-3</title> <author> <organization>IEC</organization> </author> <date year='2012'/>is a profile of the constrained voucher mechanism [I-D.ietf-anima-constrained-voucher]. </t> </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><section><name>Related</references> <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a"> <name slugifiedName="name-related-work-in-progress">Related WorkInin Progress</name><t>This<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. The intent was to publish when the WGconcludesconcluded on the covered items. At the time ofpublishingpublishing, the followingspecificationspecifications are still in progress and may affect the evolution of the stack in a 6TiSCH-aware node. </t><!-- <section anchor="chartered" title="Chartered IETF work items"> <t> The operation of the Backbone Router <xref target="I-D.ietf-6lo-backbone-router"/> is stable but the RFC is not published yet. The protection of registered addresses against impersonation and take over will be guaranteed by <xref target="I-D.ietf-6lo-ap-nd">Address Protected Neighbor Discovery for Low-power and Lossy Networks</xref>, which is not yet published either. </t> <t> New procedures have been defined at ROLL that extend RPL and may be of interest for a 6TiSCH stack. In particular <xref target="I-D.ietf-roll-unaware-leaves"/> enables a 6LN that implements only <xref target='RFC8505'/> and avoid the support of RPL. </t> </section> Chartered IETF work items --><sectionanchor='unchartered'><name>Uncharteredanchor="unchartered" numbered="true" removeInRFC="false" toc="include" pn="section-a.1"> <name slugifiedName="name-unchartered-ietf-work-items">Unchartered IETFwork items</name>Work Items</name> <sectionanchor='unchartered-sec'><name>6TiSCH Zerotouch security</name> <t>anchor="unchartered-sec" numbered="true" removeInRFC="false" toc="include" pn="section-a.1.1"> <name slugifiedName="name-6tisch-zero-touch-security">6TiSCH Zero-Touch Security</name> <t indent="0" pn="section-a.1.1-1"> The security model and in particular thezerotouchzero-touch join process <xreftarget='I-D.ietf-6tisch-dtsecurity-zerotouch-join'/> dependstarget="I-D.ietf-6tisch-dtsecurity-zerotouch-join" format="default" sectionFormat="of" derivedContent="ZEROTOUCH-JOIN"/> depend on the ANIMA (Autonomic Networking Integrated Model and Approach) <xreftarget='ANIMA'/> <xref target='I-D.ietf-anima-bootstrapping-keyinfra'>Bootstrappingtarget="ANIMA" format="default" sectionFormat="of" derivedContent="ANIMA"/> "<xref target="RFC8995" format="title" sectionFormat="of" derivedContent="Bootstrapping Remote Secure KeyInfrastructures (BRSKI)</xref>Infrastructure (BRSKI)"/>" <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> to enable zero-touch securityprovisionning;provisioning; for highly constrained nodes, a minimal model based on pre-shared keys (PSK) is also available. Aswritten to this day,currently written, it also depends on a number of documents in progressas CORE,in the CORE (Constrained RESTful Environments) WG and on <xreftarget='I-D.selander-ace-cose-ecdhe'>"Ephemeraltarget="I-D.selander-ace-cose-ecdhe" format="default" sectionFormat="of" derivedContent="EDHOC">"Ephemeral Diffie-Hellman Over COSE (EDHOC)"</xref>, which is being considered for adoptionatby the LAKE (Lightweight Authenticated Key Exchange) WG. </t> </section><!-- "6TiSCH Zerotouch security" --><sectionanchor='unchartered-tracks'><name>6TiSCHanchor="unchartered-tracks" numbered="true" removeInRFC="false" toc="include" pn="section-a.1.2"> <name slugifiedName="name-6tisch-track-setup">6TiSCH Track Setup</name><t><t indent="0" pn="section-a.1.2-1"> ROLL (Routing Over Low power and Lossy networks) is now standardizing a reactive routing protocol based on RPL <xreftarget='I-D.ietf-roll-aodv-rpl'/>target="I-D.ietf-roll-aodv-rpl" format="default" sectionFormat="of" derivedContent="AODV-RPL"/>. The need of a reactive routing protocol to establishon-demandon-demand, constraint-optimized routes and a reservation protocol to establishLayer-3Layer 3 Tracks is being discussedatin 6TiSCH but notchartered for. </t><t> <!--yet chartered. </t> <t indent="0" pn="section-a.1.2-2"> At the time of this writing,the formation of a new working group called RAW for Reliable and Available Wireless networkingthere isbeing considered. Thenew workon centralized Track computation is deferredplanned in the IETF to provide limited deterministic networking capabilities for wireless networks with asubsequent work, not necessarily at 6TiSCH. A Predictablefocus on forwarding behaviors to react quickly andAvailable Wireless (PAW) bar-BoF took place. RAW may formlocally to the changes asa WGdescribed in <xref target="I-D.pthubert-raw-architecture" format="default" sectionFormat="of" derivedContent="RAW-ARCHITECTURE"/>. </t> <t indent="0" pn="section-a.1.2-3"> ROLL is also standardizing an extension to RPL to set up centrally computed routes <xref target="I-D.ietf-roll-dao-projection" format="default" sectionFormat="of" derivedContent="DAO-PROJECTION"/>. </t> <t indent="0" pn="section-a.1.2-4"> The 6TiSCH architecture should thus inherit from the <xref target="RFC8655" format="default" sectionFormat="of" derivedContent="RFC8655">DetNet architecture</xref> anddevelopthus depends on it. The PCE should be ageneric specification for Track operationscore component of thatwould coverarchitecture. An extension to RPL or to TEAS (Traffic Engineering Architecture and Signaling) <xref target="TEAS" format="default" sectionFormat="of" derivedContent="TEAS"/> will be required to expose the 6TiSCHrequirements as expressed in this architecture, morenode capabilities and the network peers to the PCE, possibly in combination with <xref target="I-D.ietf-roll-capabilities" format="default" sectionFormat="of" derivedContent="RPL-MOP"/>. A protocol such as a lightweight Path Computation Element Communication Protocol (PCEP) or an adaptation of Common Control and Measurement Plane (CCAMP) <xreftarget='I-D.thubert-raw-technologies'/>target="CCAMP" format="default" sectionFormat="of" derivedContent="CCAMP"/> GMPLS formats and procedures could be used in combination to <xreftarget='I-D.pthubert-raw-problem-statement'/>. In a large LLN, it is not feasibletarget="I-D.ietf-roll-dao-projection" format="default" sectionFormat="of" derivedContent="DAO-PROJECTION"/> toupdateinstall theroutes fromTracks, as computed by the PCE, to the 6TiSCH nodes. </t> </section> <section anchor="unchartered-bier" numbered="true" removeInRFC="false" toc="include" pn="section-a.1.3"> <name slugifiedName="name-using-bier-in-a-6tisch-netw">Using BIER in acentral controller that resides far over6TiSCH Network</name> <t indent="0" pn="section-a.1.3-1"> ROLL is actively working on Bit Index Explicit Replication (BIER) as a method to compress both theconstrained network atdata-plane packets and thespeed at whichrouting tables in storing mode <xref target="I-D.thubert-roll-bier" format="default" sectionFormat="of" derivedContent="RPL-BIER"/>. </t> <t indent="0" pn="section-a.1.3-2"> BIER could also be used in thequalitycontext of thewireless links varies. RAW would focus on forwarding behaviors to react quicklyDetNet service layer. <xref target="I-D.thubert-bier-replication-elimination" format="default" sectionFormat="of" derivedContent="TE-PREF"> "BIER-TE extensions for Packet Replication andlocallyElimination Function (PREF) and OAM"</xref> leverages BIER Traffic Engineering (TE) to control thechanges in the wireless links. --> At the time of this writing, there is new work plannedDetNet Replication and Elimination activities in theIETFdata plane, and to providelimited deterministic networking capabilities for wireless networks with a focustraceability onforwarding behaviors to react quicklylinks where replication andlocally to the changes as describedloss happen, in<xref target='I-D.pthubert-raw-problem-statement'/>. </t><t> ROLLa manner that isalso standardizing an extension to RPLabstract tosetup centrally-computed routes <xref target='I-D.ietf-roll-dao-projection'/> </t><t> The 6TiSCH Architecture should thus inherit fromthe forwarding information. </t> <t indent="0" pn="section-a.1.3-3"> <xreftarget='RFC8655'>DetNet</xref> architecture and thus dependstarget="I-D.thubert-6lo-bier-dispatch" format="default" sectionFormat="of" derivedContent="BITSTRINGS-6LORH">"A 6loRH for BitStrings"</xref> proposes a 6LoWPAN compression for the BIER BitString based onit.<xref target="RFC8138" format="default" sectionFormat="of" derivedContent="RFC8138">6LoWPAN Routing Header</xref>. </t> </section> </section> <section anchor="external" numbered="true" removeInRFC="false" toc="include" pn="section-a.2"> <name slugifiedName="name-external-non-ietf-work-item">External (Non-IETF) Work Items</name> <t indent="0" pn="section-a.2-1"> ThePath Computation Element (PCE)current charter positions 6TiSCH on IEEE Std 802.15.4 only. Though most of the design should be portable to other link types, 6TiSCH has acore componentstrong dependency on IEEE Std 802.15.4 and its evolution. The impact ofthat architecture. An extension to RPL orchanges toTEAS <xref target='TEAS'/> willTSCH on this architecture should berequiredminimal toexposenonexistent, but deeper work such as 6top and security may be impacted. A 6TiSCH Interest Group at the IEEE maintains the synchronization and helps foster work at the IEEE should 6TiSCH demand it. </t> <t indent="0" pn="section-a.2-2"> Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would logically include the6TiSCH node capabilities and6top sublayer. The interaction with thenetwork peers to6top sublayer and thePCE, possiblyScheduling Functions described incombination withthis document are yet to be defined. </t> <t indent="0" pn="section-a.2-3"> ISA100 <xreftarget='I-D.rahul-roll-mop-ext'/>. A protocol suchtarget="ISA100" format="default" sectionFormat="of" derivedContent="ISA100"/> Common Network Management (CNM) is another external work of interest for 6TiSCH. The group, referred to as ISA100.20, defines alightweight PCEP or an adaptationCommon Network Management framework that should enable the management ofCCAMPresources that are controlled by heterogeneous protocols such as ISA100.11a <xreftarget='CCAMP'/> G-MPLS formats and procedures could be used in combination totarget="ISA100.11a" format="default" sectionFormat="of" derivedContent="ISA100.11a"/>, WirelessHART <xreftarget='I-D.ietf-roll-dao-projection'/> to install the Tracks, as computed by the PCE, totarget="WirelessHART" format="default" sectionFormat="of" derivedContent="WirelessHART"/>, and 6TiSCH. Interestingly, the establishment of 6TiSCHnodes. </t> </section><!-- 6TiSCH Track Setup --> <section anchor='unchartered-bier'><name>Using BIERdeterministic paths, called Tracks, are also ina 6TiSCH Network</name> <t> ROLLscope, and ISA100.20 isactivelyworking onBit Index Explicit Replication (BIER) as a methodrequirements for DetNet. </t> </section> </section> <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.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 tocompress boththedataplane packetsinitial security work, to <contact fullname="Yasuyuki Tanaka"/> for his work on implementation and simulation that tremendously helped build a robust system, to <contact fullname="Diego Dujovne"/> for starting and leading therouting tablesSF0 effort, and to <contact fullname="Tengfei Chang"/> for evolving it instoring mode <xref target='I-D.thubert-roll-bier'/>.the MSF. </t><t> BIER could<t indent="0" pn="section-b.1-2"> Special thanks alsobe usedto <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 Director 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 the first INT Area Directorate review, which was very deep and thorough and radically changed thecontextorientations ofthe DetNet service layer. <xref target='I-D.thubert-bier-replication-elimination'> BIER-TE-based OAM, Replicationthis document, andElimination </xref> leverages BIER Traffic Engineering (TE)then tocontrol<contact fullname="Eliot Lear"/> and <contact fullname="Carlos Pignataro"/>, who helped finalize this document in preparation for thedata plane the DetNet Replication and Elimination activities,IESG reviews, and toprovide traceability on links where replication and loss happen, in a manner that is abstract<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 theforwarding information. </t> <t> <xref target='I-D.thubert-6lo-bier-dispatch'>a 6loRH for BitStrings</xref> proposes a 6LoWPAN compression forfinal shaping of this document through theBIER Bitstring based on <xref target='RFC8138'>6LoWPAN Routing Header</xref>.IESG review procedure. </t> </section><!-- 6TiSCH Track Setup --> </section><!-- Unchartered IETF work items --><sectionanchor='external'><name>External (non-IETF) work items</name> <t> The current charter positions 6TiSCH on IEEE Std. 802.15.4 only. Though mostnumbered="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 thedesign should be portable on other link types,6TiSCHhas a strong dependency on IEEE Std. 802.15.4 and its evolution.(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"> Theimpactauthors 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-Abegnoli"/>, <contact fullname="Alfredo Grieco"/>, <contact fullname="Bert Greevenbosch"/>, <contact fullname="Cedric Adjih"/>, <contact fullname="Deji Chen"/>, <contact fullname="Martin Turon"/>, <contact fullname="Dominique Barthel"/>, <contact fullname="Elvis Vogli"/>, <contact fullname="Geraldine Texier"/>, <contact fullname="Guillaume Gaillard"/>, <contact fullname="Herman Storey"/>, <contact fullname="Kazushi Muraoka"/>, <contact fullname="Ken Bannister"/>, <contact fullname="Kuor Hsin Chang"/>, <contact fullname="Laurent Toutain"/>, <contact fullname="Maik Seewald"/>, <contact fullname="Michael Behringer"/>, <contact fullname="Nancy Cam Winget"/>, <contact fullname="Nicola Accettura"/>, <contact fullname="Nicolas Montavont"/>, <contact fullname="Oleg Hahm"/>, <contact fullname="Patrick Wetterwald"/>, <contact fullname="Paul Duffy"/>, <contact fullname="Peter van der Stok"/>, <contact fullname="Rahul Sen"/>, <contact fullname="Pieter de Mil"/>, <contact fullname="Pouria Zand"/>, <contact fullname="Rouhollah Nabati"/>, <contact fullname="Rafa Marin-Lopez"/>, <contact fullname="Raghuram Sudhaakar"/>, <contact fullname="Sedat Gormus"/>, <contact fullname="Shitanshu Shah"/>, <contact fullname="Steve Simlo"/>, <contact fullname="Tina Tsou"/>, <contact fullname="Tom Phinney"/>, <contact fullname="Xavier Lagrange"/>, <contact fullname="Ines Robles"/>, and <contact fullname="Samita Chakrabarti"/> for their participation and various contributions. </t> </section> </section> <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c"> <name slugifiedName="name-contributors">Contributors</name> <t indent="0" pn="section-appendix.c-1">The co-authors ofchangesthis document are listed below: </t> <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-appendix.c-2"> <li pn="section-appendix.c-2.1"> <t indent="0" pn="section-appendix.c-2.1.1"><contact fullname="Thomas Watteyne"/> for his contributions toTSCHthe whole design, in particular onthis Architecture should beTSCH and security, 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 tonon-existent, but deeper work such asthe 6top design andsecurity may be impacted. A 6TiSCH Interest Group attheIEEE maintainsGMPLS 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 Pister"/> 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 thesynchronization and helps fosterworkaton theIEEE should 6TiSCH demand it. </t> <t> Work is being proposed at IEEE (802.15.12 PAR)one-touch join process and his contribution to the Security Design Team;</t> </li> <li pn="section-appendix.c-2.5"> <t indent="0" pn="section-appendix.c-2.5.1"><contact fullname="Michael Richardson"/> foran LLC that would logically includehis leadership role in the6top sublayer. The interaction withSecurity 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 Kivinen"/> for his contribution to the6top sublayersecurity work in general and theScheduling Functions describedsecurity 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 Rita Palattella"/> for managing the Terminology document that was merged into this documentare yet to be defined. </t> <t> ISA100 <xref target='ISA100'/> Common Network Management (CNM) is another externalthrough the work ofinterest6TiSCH;</t> </li> <li pn="section-appendix.c-2.8"> <t indent="0" pn="section-appendix.c-2.8.1"><contact fullname="Simon Duquennoy"/> for6TiSCH. The group, referredhis contribution toas ISA100.20, defines a Common Network Management framework that should enablethemanagementopen source community with the 6TiSCH implementation ofresources that are controlled by heterogeneous protocols such as ISA100.11a <xref target='ISA100.11a'/>, WirelessHART <xref target='WirelessHART'/>,contiki, and6TiSCH. Interestingly,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 Wang"/>, who led theestablishmentdesign of6TiSCH Deterministic paths, called Tracks, are also in scope,the 6top sublayer andISA100.20 is working on requirementscontributed 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 Struik"/> forDetNet. </t> </section><!-- External IETFthe 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 workitems --> </section><!--title="DependenciesonWork In Progress"-->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="editor"> <organization abbrev="Cisco Systems" showOnFrontPage="true">Cisco Systems, 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>