6TiSCH | S. Duquennoy, Ed. |
Internet-Draft | RISE SICS |
Intended status: Standards Track | X. Vilajosana |
Expires: September 3, 2018 | Universitat Oberta de Catalunya |
T. Watteyne | |
Inria | |
March 2, 2018 |
6TiSCH Autonomous Scheduling Function (ASF)
draft-duquennoy-6tisch-asf-01
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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document is an Internet Draft, so work-in-progress by nature. It contains the following work-in-progress elements:
This document defines an autonomous Scheduling Function for the 6top sublayer [I-D.ietf-6tisch-6top-protocol], 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 [I-D.ietf-6tisch-6top-protocol]. The organization of this document follows section "Recommended Structure of an SF Specification" in [I-D.ietf-6tisch-6top-protocol]. This document follows the terminology defined in [I-D.ietf-6tisch-terminology].
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 [Orchestra-SenSys].
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 Section 3.2). To derive coordinates from a MAC (EUI-64) address, nodes MUST use the hash function provided at configuration time, see Section 4. One example hash function is SAX [SAX-DASFAA]. 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:
There are three different types of slotframes, described next. Section 4 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 [RFC8180].
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 [IEEE802154-2015] '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.
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 [IEEE802154-2015] 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 Figure 1) 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:
Figure 1 describes the format of the ASF SIGNAL command.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # Slotframes | Slotframe list ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the ASF SIGNAL command.
Where:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slotf. handle | Slotframe size | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min. channel offset | Max. channel offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Cell Opt | Rx Cell Opt | Nbr Set | Hash func. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # Filters | Traffic filter list ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: Format of the ASF SIGNAL slotframe descriptor.
Figure 2 shows the format of a slotframe descriptor, where:
+-----------+---------------------------------+ | Num. | Description | +-----------+---------------------------------+ | 0 | Rendez-vous slotframe | +-----------+---------------------------------+ | 1 | Receiver-based slotframe | +-----------+---------------------------------+ | 2 | Sender-based slotframe | +-----------+---------------------------------+ | 128--255 | Reserved | +-----------+---------------------------------+
Figure 3: Field: types of slotframes.
+-----------+---------------------------------+ | Num. | Description | +-----------+---------------------------------+ | 0 | Empty set | +-----------+---------------------------------+ | 1 | All TSCH time sources | +-----------+---------------------------------+ | 2 | All RPL parents | +-----------+---------------------------------+ | 3 | The RPL preferred parent | +-----------+---------------------------------+ | 4 | All IPv6 NDP neighbors | +-----------+---------------------------------+ | 128--255 | Reserved | +-----------+---------------------------------+
Figure 4: Field: neighbor set.
+-----------+---------------------------------+ | Num. | Description | +-----------+---------------------------------+ | 0 | SAX (Shift-Add-XOR) | +-----------+---------------------------------+ | 1--255 | Reserved | +-----------+---------------------------------+
Figure 5: Field: Hash function
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FT | UC/BC | IP protocol | Type / Code / Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the ASF SIGNAL traffic filters.
The fields for traffic filter descriptions (Figure 6) are described next:
Example filters are given next:
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 [I-D.ietf-6tisch-6top-protocol].
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.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of the Metadata Field.
The Metadata 16-bit field is used as follows: Figure 7 shows the format of the Metadata field, where:
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 Section 4.
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 [RFC6982]. 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 [RFC6982], "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".
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 Section 4. When this command is not secured, the security of the network is equivalent to that of the 6TiSCH minimal configuration ([RFC8180]). 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 [I-D.ietf-6tisch-6top-protocol]:
+----------------------+--------------------------------+-----------+ | SFID | Name | Reference | +----------------------+--------------------------------+-----------+ | IANA_6TiSCH_SFID_ASF | Autonomous Scheduling Function | RFCXXXX | | | (ASF) | | +----------------------+--------------------------------+-----------+
Figure 8: 6P Scheduling Function Identifiers 'ASF'.
[IEEE802154-2015] | IEEE standard for Information Technology, "IEEE Std 802.15.4-2015 Standard for Low-Rate Wireless Personal Area Networks (WPANs)", December 2015. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
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