6TiSCH Autonomous Scheduling Function (ASF)
RISE SICSIsafjordsgatan 22164 29 KistaSwedensimon.duquennoy@ri.seUniversitat 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 Autonomous Scheduling Function.
With ASF, nodes maintain their TSCH schedule based on local neighborhood knowledge, without any signaling after association.
Hashes of the nodes' MAC address are used to deterministically derive the [slotOffset,channelOffset] location of cells in the TSCH schedule.
Different traffic types (e.g. TSCH EB, RPL DIO, UDP etc.) 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 runtime signaling, keeping the TSCH schedule consistent between neighbors at all times (slots for transmission and reception always match).
ASF uses 6P solely for configuration at association time (6P SIGNAL) and for schedule inspection (6P STATUS and LIST).
ASF isolates different traffic types into 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 EBs, RPL or UDP 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.
Cell coordinates in ASF are either fixed or derived from a MAC address (depending on the slotframe type, see ).
To derive coordinates from a MAC (EUI-64) address, nodes MUST use the hash function provided at configuration time, see .
One example hash function is SAX .
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)]
There are three different types of slotframes, described next.
provides full details on cell options and other aspects.
Contains a single contention-based rendez-vous cell, at coordinates [slot offset: 0; channel offset: 0].
This slotframe is equivalent to the 6TiSCH minimal schedule .
Coordinates computed as the hash of the node's own MAC address.
One Tx cell per neighbor.
Coordinates computed as the hash of the neighbor's MAC address.
Coordinates computed as the hash of the node's own MAC address.
One Rx cell per neighbor.
Coordinates computed as the hash of the neighbor's MAC address.
In order to handle traffic bursts, ASF utilizes conditional cells.
When a node has several frames in its queue for a given neighbor, it can set the 'frame pending' bit in unicast transmissions to that neighbor.
Cells at upcoming time offsets will be used to carry more frames.
Note that collisions may happen on these conditional cells, which MUST therefore have the 'Shared' bit set.
A sender with multiple unicast frames in its queue for a given neighbor MAY send frames with the 'frame pending' bit set.
After sending a unicast frame with the 'frame pending' bit set, if a link-layer Acknowledgment (ACK) is received, the sender immediately schedules a temporary Tx cell.
Compared to the initial cell, the temporary cell has
the same Link Options plus the 'Shared' bit,
the same channel offset, and
a time offset incremented by 1 (modulo the slotframe length).
The next frame will be sent on this temporary cell, and may set the 'frame pending' bit again to signal more traffic to come.
The procedure repeats until the transmit queue is empty, or until no acknowledgment is received for a frame.
Upon receiving a unicast frame with the 'frame pending' bit set, the node first sends a link-layer ACK.
It then schedules a temporary Rx cell, with same Link Options, same channel offset, and time offset incremented by 1.
If, in the new cell, it receives a unicast frame with the 'frame pending' bit set, it continues scheduling additional Rx cells to receive subsequent frames.
ASF is expected to maintain multiple slotframes, each dedicated to a different traffic type.
As the slotframes repeat over time, cells from different slotframes overlap periodically.
In case a node has multiple cells scheduled at the same time, the precedence rules from apply.
In order to distribute cell overlap uniformly, it is RECOMMENDED to select slotframe lengths that are co-primes.
An ASF configuration consists of a series of slotframes with attributes.
ASF uses the 6P SIGNAL command (format in ) to disseminate its configuration.
SIGNAL commands are directly included as IETF IE in each EB, so that nodes learn the ASF configuration directly at join-time.
6TiSCH EBs are not secured.
For applications that require the ASF schedule to be sent securely, the ASF SIGNAL command MAY be sent instead in separate data broadcast packets, after join-time.
To summarize, there are two cases:
The node configures itself to run the ASF configuration provided.
The node runs the 6TiSCH minimal schedule () at association.
When later receiving a packet with ASF SIGNAL, the node replaces the 6TiSCH minimal schedule with the ASF configuration provided.
describes the format of the ASF SIGNAL command.
Where:
The number of ASF slotframes
The list of slotframes, with format described in shows the format of a slotframe descriptor, where:
The IEEE 802.15.4 slotframe handle (8 bits)
The IEEE 802.15.4 slotframe size (16 bits)
The ASF slotframe type.
The set of possible values for this field is presented in .
The different slotframe types are described in .
ASF slotframes are assigned a channel offset range.
This defines the lower bound for the range.
ASF slotframes are assigned a channel offset range.
This defines the upper bound for the range.
The options to be used for the Tx Cells, if any.
The options to be used for the Rx Cells, if any.
The set of neighbors for which Cells are instantiated.
The set of possible values for this field is presented in .
The hash function used to compute cell coordinates from a node's EUI-64 address, as defined in .
The set of possible values for this field is presented in .
ASF slotframes are assigned a subset of the traffic each.
One or several traffic filters will be applied to only select packets with the intended properties.
When there are several traffic filters, they are combined with a OR, i.e., packets that satisfy any of the filters will be sent on the slotframe.
This field defines how many filters are in place.
The filter descriptions follow inline, with format defined in .
The fields for traffic filter descriptions () are described next:
The IEEE 802.15.4 frame type. Examples; 0: Beacon; 1: Data.
Unicast/broadcast nature. Possible values; 0: unicast; 1: broadcast; 2: any.
The IP protocol number. Examples; 0x3a: ICMPv6; 0x11: UDP.
A value of 0x00 ignores this field.
In the case of ICMPv6: the Type (first 8 bits) followed by the Code (last 8 bits).
In case of UDP or TCP: the 16-bit port.
A value of 0x00 ignores this field.
Example filters are given next:
FT: 0 (beacon), UC/BC: 1 (broadcast), IP protocol: 0, Type: 0.
FT: 1 (data), UC/BC: 2 (unicast and broadcast), IP protocol: 0x3a (ICMPv6), Type: 0x9b (RPL), Code: 0x00
FT: 1 (data), UC/BC: 0 (unicast), IP protocol: 0x3a (ICMPv6), Type: 0x9b (RPL), Code: 0x01 (DIO)
FT: 1 (data), UC/BC: 2 (unicast and broadcast), IP protocol: 0x11 (UDP), Port: 5683
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.
Cells are ordered by increasing slotframe handle, then by timeslot, then channel offset.
The Metadata 16-bit field is used as follows:
shows the format of the Metadata field, where:
Slotframe: is used to identify a slotframe by its handle.
Bits 8-15 are reserved.
At boot, nodes start with an empty schedule.
When associating, they configure their schedule with the 6P ASF SIGNAL command, which is included either in the initial EB or later packets, as described in .
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 .
At run-time, 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.
At configuration time, ASF relies on a 6P SIGNAL command.
This command MAY be secured as described in .
When this command is not secured, the security of the network is equivalent to that of the 6TiSCH minimal configuration ().
That is, the network schedule is propagated directly through EBs.
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-01
Defines ASF configuration parameters and procedure;Defines packet format to disseminate configurations (6P signal);Defines burst mode (conditional cells based on 'frame pending' bit);Makes Hash function configurable (SAX remains default).draft-duquennoy-6tisch-asf-00
Initial draft.