6TiSCH Autonomous Scheduling Function (ASF)
Inria40 Avenue HalleyBuilding AVilleneuve d'AscqFrancesimon.duquennoy@inria.frUniversitat Oberta de Catalunya156 Rambla PoblenouBarcelonaCatalonia08018Spainxvilajosana@uoc.eduInria2 Rue Simone IffParisFrancethomas.watteyne@inria.fr
Internet Area
6TiSCHDraft
This document defines a Scheduling Function called "ASF": the 6TiSCH Autoonomous Scheduling Function.
With ASF, nodes maintain their TSCH schedule based on local neighborhood knowledge, without any signaling.
Hashes of the nodes' MAC address are used to deterministically derive the [slotOffset,channelOffset] location of cells in the TSCH schedule.
The MAC, control, and application traffic planes are assigned to distinct slotframes, for isolation and flexible dimensioning.
This approach provides over-provisioned schedules with low maintenance, in pursuit for simplicity rather than optimality.
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 RFC 2119.
This document is an Internet Draft, so work-in-progress by nature.
It contains the following work-in-progress elements:
"TODO" statements are elements which have not yet been written by the authors for some reason (lack of time, ongoing discussions with no clear consensus, etc).
The statement does indicate that the text will be written at some point.
"TEMPORARY" appendices are there to capture current ongoing discussions, or the changelog of the document.
These appendices will be removed in the final text.
"IANA_*" identifiers are placeholders for numbers assigned by IANA.
These placeholders are to be replaced by the actual values they represent after their assignment by IANA.
"RFCXXXX" refers to the RFC number of this specification, once published.
The string "REMARK" is put before a remark (questions, suggestion, etc) from an author, editor or contributor.
These are on-going discussions at the time of writing, and will not be part of the final text.
This section will be removed in the final text.
This document defines an autonomous Scheduling Function for the 6top sublayer , called "ASF".
It is designed to operate without any signaling, keeping the TSCH schedule consistent between neighbors at all times (matching slots for transmission and reception).
ASF uses 6P for neighbor schedule inspection (commands STATUS and LIST), but not for adding/deleting cells.
ASF isolates the traffic from different planes in distinct slotframes, so as to avoid any disruption between MAC synchronization, control and application traffic.
ASF addresses all requirements listed in Section "Requirements for an SF" from .
The organization of this document follows section "Recommended Structure of an SF Specification" in .
This document follows the terminology defined in .
ASF is primarily targeted at applications with random traffic flows, such as interactive CoAP traffic.
Its main strength is its signaling-free nature, which ensures the slots installed at neighboring nodes are consistent at all times.
Its main weakness is its contention-based nature and its need to over-provision the schedule, rendering it unable to meet stringent latency and energy requirements.
An example application domains is building instrumentation.
ASF was evaluated experimentally and shown to achieve over 99.99% end-to-end delivery in 6TiSCH/RPL testbeds .
ASF uses multiple slotframes, each assigned to one particular type of traffic, e.g. TSCH synchronization, routing control or application traffic.
Nodes maintain the cells within the slotframes autonomously, based on the hash of either the source's or destination's MAC address.
Each slotframe is uniquely assigned a set of channel offsets.
There are three different types of slotframes, decribed next:
Contains a contention-based rendez-vous cell with fixed coordinates, options Rx, Tx, and Shared.
The cell can be used for any type of traffic, including broadcast.
This slotframe is equivalent to the 6TiSCH minimal schedule .
Nodes have one receive (option Rx) cell at coordinates derived from a hash of their MAC address.
For transmitting to a given neighbor, nodes maintain a cell (options Tx, Shared) at coordinates derived from a hash of the neighbor's MAC address.
For instance, a node may maintain such a transmit cell for each known neighbor in the IPv6 NDP cache, or to a subset such as the RPL preferred parent(s) or TSCH time source(s).
Nodes have one transmit cell (options Tx, Shared) at coordinates derived from a hash of their MAC address.
To listen to a given neighbor, they maintain a cell (option Rx) at coordinates derived from a hash of the neighbor's MAC address.
Typically, nodes only listen to a subset of neighbors, such as the RPL preferred parent(s) or TSCH time source(s).
Cell coordinates in ASF are either fixed (for rendez-vous slotframes) or derived from a MAC address (for receiver- and sender-based slotframes).
To derive coordinates from a MAC address, nodes MUST use the hash function SAX on the EUI-64.
Let S_len be the length of slotframe S, and S_channels be the set of channels assigned to slotframe S.
The slot coordinates derived from a given MAC address are computed as follows:
slotOffset(MAC) = hash(MAC) % S_len channelOffset(MAC) = S_channels[(hash(MAC) / L) % len(S_channels)]
By default, nodes maintain the four following slotframes:
Nodes MUST send all TSCH Enhanced Beacons (EBs) on this slotframe.
This is a sender-based slotframe.
Nodes have one transmit cell based on their MAC address, and listen to their TSCH time source with one receive cell (with additional option TimeKeeping).
Nodes MUST send all Keep-Alives (KAs) on this slotframe.
This is a receiver-based slotframe.
Nodes have one receive cell based on their MAC address, and one transmit cell towards their TSCH time source (with additional option TimeKeeping).
Nodes MUST send all unicast UDP and TCP frames in this slotframe.
This is a received-based slotframe.
Nodes have one receive cell based on their MAC address, and maintain as many transmit cells as they have neighbors in their IPv6 NDP cache.
Every time a node is added/removed to the NDP cache, a new transmit cell is immediatly added/removed.
Nodes MUST send all other traffic to this slotframe, such as 6P or ICMPv6 traffic.
This is a rendez-vous slotrame.
All nodes have one single cell at slotOffset 0 and at the first channel offset of the slotframe.
As the slotframes repeat over time, cells from different slotframes will overlap periodically.
In case a node has multiple cells schedule at the same time, the precedence rules from apply.
In order to fully isolate the different planes, we RECOMMEND provisioning separate packet queues for each slotframe.
This ensures that transient bursts at the application layer will not affect TSCH synchronization nor routing topology maintenance.
Conversely, occasional routing or TSCH traffic will not affect each other nor affect the application.
ASF defines a set of configuration parameters listed in .
In order to distribute cell overlap uniformly (see ), we RECOMMEND selecting slotframe lengths that are co-primes.
TODO define how configuration is discovered. Can be through new EB IEs, or through new/extended 6P command(s).
+--------------------------------+----------------------------------+
| Property | Example Setting |
+--------------------------------+----------------------------------+
| SlotframeA length | 397 |
+--------------------------------+----------------------------------+
| SlotframeA handle | 4 (lowest precedence) |
+--------------------------------+----------------------------------+
| SlotframeA channelOffsets | 0 |
+--------------------------------+----------------------------------+
| SlotframeA type of cells | ADVERTISING |
+--------------------------------+----------------------------------+
| SlotframeB length | 389 |
+--------------------------------+----------------------------------+
| SlotframeB handle | 0 (highest precedence) |
+--------------------------------+----------------------------------+
| SlotframeB channelOffsets | 1 |
+--------------------------------+----------------------------------+
| SlotframeB type of cells | NORMAL |
+--------------------------------+----------------------------------+
| SlotframeC length | Trades-off app. traffic capacity |
| | against energy. Ex. value: 17 |
+--------------------------------+----------------------------------+
| SlotframeC handle | 1 |
+--------------------------------+----------------------------------+
| SlotframeC channelOffsets | 2 to 14 |
+--------------------------------+----------------------------------+
| SlotframeA type of cells | NORMAL |
+--------------------------------+----------------------------------+
| SlotframeD length | 31 |
+--------------------------------+----------------------------------+
| SlotframeD handle | 2 |
+--------------------------------+----------------------------------+
| SlotframeD channelOffsets | 15 |
+--------------------------------+----------------------------------+
| SlotframeD type of cells | NORMAL |
+--------------------------------+----------------------------------+
The Scheduling Function Identifier (SFID) of ASF is IANA_SFID_ASF.
ASF nodes maintain their cells autonomously, and do not use 6P ADD nor DELETE.
For the 6P LIST command, ASF uses the default CellList field format defined in Section 4.2.4 [TODO: update if needed] of .
The timeout is of low criticality in ASF as 6P Requests are only used for schedule inspection, not for cell addition/removal.
The RECOMMENDED timeout value in slots is:
2^(macMaxBe+2)*SlotframeD_len
which is an upper bound of the maximum time spent in transmission attempts of a 6P Request and Response, over slotframeD (where 6P traffic is sent).
The upper bound is conservative, giving extra time for time spent in packet queues.
Assuming default values ( and ), that is macMaxBe==5 and Slotframe2_len==31, this results in a timeout of 3968 timeslots.
Cells are ordered by increasing slotframe handle, then by timeslot, then channel offset.
The Metadata 16-bit field is used as follows:
Figure shows the format of the Metadata field, where:
Slotframe: is used to identify a slotframe by its handle.
BITS 8-15 are reserved.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slotframe | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
At boot, ASF creates four empty slotframes with length and handle described in .
TODO describe configuration discovery.
ASF only uses 6P commands COUNT and LIST.
In case of error on STATUS or LIST, the node MAY retry to contact this neighbor after the 6P timeout.
TODO
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in .
The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog of available implementations or their features.
Readers are advised to note that other implementations may exist.
According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as they see fit".
The mechanism behind this specification is implemented in the Contiki project .
Adjustments to exactly match this specification are in progress.
The mechanism was evaluated experimentally in large-scale testbeds in .
ASF is not threatened by attacks on 6P messages as it operates without signaling.
However, it bases its TSCH schedule on external information, namely:
(1) the identify of the current TSCH time source and
(2) the MAC address of its neighbors.
ASF relies on link-layer security to ensure the integrity of the above information.
This document adds the following number to the "6P Scheduling Function Identifiers" registry defined by :
IEEE Std 802.15.4-2015 Standard for Low-Rate Wireless Personal Area Networks (WPANs)
IEEE standard for Information TechnologyThe Contiki Open Source OS for the Internet of ThingsOrchestra: Robust Mesh Networks Through Autonomously Scheduled TSCH Performance in Practice of String Hashing Functions
Beshr Al Nahas (Chalmers University, beshr@chalmers.se) and Olaf Landsiedel (Chalmers University, olafl@chalmers.se) contributed to the design and evaluation of ASF.
TODO people
TODO projects
draft-duquennoy-6tisch-asf-00
Initial draft.