6TiSCH X. Vilajosana, Ed.
Internet-Draft Universitat Oberta de Catalunya
Intended status: Best Current Practice K. Pister
Expires: August 31, 2016 University of California Berkeley
February 28, 2016

Minimal 6TiSCH Configuration
draft-ietf-6tisch-minimal-15

Abstract

This document describes a minimal mode of operation for a 6TiSCH Network, to provide IPv6 connectivity over a Non-Broadcast Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) links.

This minimal mode uses a collection of protocols including the 6LoWPAN framework and RPL to enable interoperable IPv6 connectivity over IEEE 802.15.4 TSCH with minimal network configuration and infrastructure.

Status of This Memo

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 http://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 August 31, 2016.

Copyright Notice

Copyright (c) 2016 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 (http://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.


Table of Contents

1. Introduction

A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) links.

The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires the use of both RPL and the 6LoWPAN adaptation layer framework ([RFC4944], [RFC6282]) as defined over IEEE 802.15.4. 6LoWPAN Neighbor Discovery [RFC6775] (ND) is also required to exchange Compression Contexts, form IPv6 addresses and register them for the purpose of Duplicate Address Detection, Address Resolution and Neighbor Unreachability detection over one TSCH link.

Nodes in an IEEE 802.15.4 TSCH network follow a communication schedule. A network using the simple mode of operation uses a static schedule.

This specification defines operational parameters and procedures for a minimal mode of operation to build a 6TiSCH Network. The 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective Function 0 (OF0) [RFC6552], are used unmodified, but parameters and particular operations of TSCH and RPL are specified to guarantee interoperability between nodes in a 6TiSCH Network.

More advanced work is expected in the future to complement the Minimal Configuration with dynamic operations that can adapt the Schedule to the needs of the traffic in run time.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. Terminology

This document uses terminology from the Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e [I-D.ietf-6tisch-terminology]. The following concepts are used in this document:

4. Minimal Schedule Configuration

In order to form a network, a set of conventions need to be taken to enable initial advertising of the network. Besides a set of parameters need to be defined so joining nodes are configured and hence the network formed and nodes interoperate. These set of rules and default parameters conform a minimal configuration that nodes implementing this specification MUST comply. The timeslot timing, slotframe length, the number of active cells, their slot offset and frequency offset and the purpose of the cells are mandatory configurations for two nodes to communicate. The present document defines those rules. Table 1 summarizes the main configuration parameters for a "minimal" configuration.

A joining node learns the minimal configuration from the Enhanced Beacon, except for the security keys. How the security keys are obtained is out of the scope of this document. More details are given in Section 10.

The present specification is independent of the actual physical layer and it is only dependent on the IEEE 802.15.4 TSCH MAC layer specification.

4.1. Slotframe

The slotframe, as defined in the Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e [I-D.ietf-6tisch-terminology], is an abstraction of the link layer that defines a collection of timeslots of equal length that repeat over time. In order to set up a minimal TSCH network, nodes need to be time synchronized and configured to use the same slotframe configuration so they can communicate. Compliant nodes SHOULD obey to the following configuration as defined in Table 1:

Table 1. Minimal configuration parameters.

+------------------------------------+--------------------------+
|           Property                 |           Value          |
+------------------------------------+--------------------------+
| Number of timeslots per Slotframe  | Variable                 |
|                                    |(default 11)              |
+------------------------------------+--------------------------+
| Number of available frequencies    | 16                       |
+------------------------------------+--------------------------+
| Number of scheduled cells          | 1 (slotOffset 0x00)      |
| (active)                           |   (chOffset   0x00)      |
|                                    |   (linkOption 0x0f)      |
|                                    | (macLinkType NORMAL)     |
+------------------------------------+--------------------------+
| Number of unscheduled cells        | The remainder of the     |
| (off)                              | slotframe                |
+------------------------------------+--------------------------+
| Number of MAC retransmissions (max)| 3 (4 transmission        |
|                                    |    attempts)             | 
+------------------------------------+--------------------------+
| Default timeslot timing            | default                  |  
|                                    | macTimeslotTemplate      |
|                                    | template from            |
|                                    | IEEE802.15.4e            |
|                                    | macTimeslotTemplateId=0  |
+------------------------------------+--------------------------+
| Enhanced Beacon Default Period     | 10s                      | 
| (referred as EB_PERIOD)            |                          |
+------------------------------------+--------------------------+
| Default Channel Hopping sequence   | [5, 6, 12, 7, 15,        |
| for the 2.4GHz OQPSK PHY           |  4, 14, 11, 8, 0,        |
|                                    |  1, 2, 13, 3, 9, 10]     |
+------------------------------------+--------------------------+
 

The slotframe is composed of a configurable number of timeslots. The number of timeslots in the slotframe is referred as slotframe length [IEEE802154]. This document defines a default slotframe length of 11 slots. Choosing the number of time slots per slotframe needs to take into account network requirements such as density, bandwidth per node, etc. In the minimal configuration, there is only a single active cell in the slotframe, used to transmit/receive both EBs and data link-layer frames. The trade-off between bandwidth, latency and energy consumption can be controlled by choosing a different slotframe length. The active cell MAY be scheduled at any slotOffset (default 0x00) and any channelOffset (default 0x00) within the slotframe and this location MUST be announced in the EBs. EBs are sent using this active cell to the link-layer broadcast address (and are therefore not acknowledged). Data packets, as described in Section 4.2, use the same active cell. Per IEEE 802.15.4 specification, data packets sent unicast on this cell are acknowledged by the receiver [IEEE802154]. The remaining cells in the slotframe are unscheduled, and MAY be used by other (dynamic) scheduling solutions. Details about such dynamic scheduling solution are out of scope of this document. Details about the usage of the non scheduled cells are out of scope of this document.

The slotframe length determines the duty cycle of the network and MUST be announced in the SlotFrame and Link IE of the EB. For example, a network with a 0.99% duty cycle (as presented in Figure 1) is composed of a slotframe of 101 timeslots, which includes 1 active cell.

In a minimal configuration, a default timeslot duration set to 10ms and its corresponding default timeslot internal timings defined by the IEEE 802.15.4 specification SHOULD be used [IEEE802154]. The timeslot timing is defined by the macTimeslotTemplate in the IEEE802.15.4 specification. The use of the default macTimeslotTemplate MUST be announced in the Enhanced Beacon (EB) by using the Timeslot Information Element (IE) containing only the default macTimeslotTemplateId. Other timeslot durations MAY be supported and MUST be announced in the EBs. Joining nodes MUST learn the configuration from the received EB. If a network uses a timeslot duration different than the default (10ms), EBs MUST contain the complete Timeslot IE and fill all the fields of the macTimeslotTemplate as described in Section 4.4. Nodes not supporting the default timeslot value SHOULD be clearly indicated.

Figure 1. Example schedule with 0.99% duty cycle. A slotframe of 101 timeslots and 16 channel offsets. Only one active cell at slotOffset 0x00 and channelOffset 0x00. The remaining cells are unscheduled.

   Chan.  +----------+----------+          +----------+
   Off.0  | TxRxS/EB |   OFF    |          |   OFF    |
   Chan.  +----------+----------+          +----------+
   Off.1  |   OFF    |   OFF    |   ...    |   OFF    |
          +----------+----------+          +----------+
              .
              .
              .
   Chan.  +----------+----------+          +----------+
   Off.15 |   OFF    |   OFF    |          |   OFF    |
          +----------+----------+          +----------+

slotOffset     0          1                    100

EB:  Enhanced Beacon
Tx:  Transmit
Rx:  Receive
S:   Shared
OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism)

4.2. Cell Options

According to the IEEE 802.15.4 TSCH specification, each scheduled cell is associated with a LinkOption bitmap [IEEE802154]. The active cell in the minimal configuration MUST use a LinkOption with Value 0x0F. The bitmap in the active cell indicates that a node transmits if there is a packet in its queue, listens otherwise as the "Transmit" and "Receive" bits are set. A "Shared" bit is set and therefore the back-off mechanism defined in the IEEE 802.15.4 specification is used to resolve contention when transmitting [IEEE802154]. This results in a behavior that is similar to that of "Slotted Aloha". The "Timekeeping" flag is set so nodes initially joining the network can maintain time synchronization to the advertising node using that cell. Other time source neighbors MAY be selected using the routing structure, e.g the DODAG structure of the network if RPL is used.

LinkOption bitmap setting for the active cell in the minimal configuration slotframe:

In addition, the scheduled cell in the schedule is configured as a Hard cell [RFC7554][I-D.ietf-6tisch-terminology] indicating that cannot be moved or relocated by any dynamic scheduling mechanism. Additional available cells MAY be scheduled by a dynamic scheduling solution. The dynamic scheduling solution is out of scope, and this specification does not make any restriction on the LinkOption bitmap associated with those dynamically scheduled cells (i.e. they can be Hard cells or Soft cells as defined by the 6TiSCH Terminology document [I-D.ietf-6tisch-terminology]).

All remaining cells are unscheduled. In unscheduled cells, the nodes SHOULD keep their radio off.

4.3. Retransmissions

The maximum number of link layer retransmissions is set to 3. For packets requiring an acknowledgment, if none are received after a total of 4 attempts, the transmission is considered failed and the link layer MUST notify the upper layer. Packets sent to the broadcast MAC address (including EBs) are not acknowledged and therefore not retransmitted.

4.4. Timeslot timing

Figure 2 shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX). A link-layer acknowledgment is sent by the RX node to the TX node when the packet is to be acknowledged. The TsTxOffset duration defines the instant in the timeslot when the first bit after the Start of Frame Delimiter (SFD) of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on tsRxWait/2 before that instant, and listens for at least tsRxWait. This allows for a de-synchronization between the two nodes of at most tsRxWait/2 in either direction (early or late). The RX node needs to send the first bit after the SFD of the MAC acknowledgment exactly TsTxAckDelay after the end of the last byte of the received packet. TX's radio has to be turned on tsAckWait/2 before that time, and keep listening for at least tsAckWait. The TX node can perform a Clear Channel Assessment (CCA) if required, this does not interfere with the scope of this document. For the minimal configuration specified in this document, the use of CCA is OPTIONAL.

Figure 2. Timeslot internal timing diagram

   /---------------------- Timeslot Duration -----------------------/
   |                                                  / (5) /       |
   |                   |              / tsRxAckDelay /|  |  |       |
   |-------------------+--------------+------------------+------+---|
TX |/(1)/  (2)  / (3) /|   TX frame   |                  |RX ACK|   |
   |----+-------+------+--------------+------------------+------+---|
   |/    tsTxOffset   /|              |                  |      |   |
   |                   |              |                  |      |   |
   |-------------------+--------------+------------------+------+---|
RX |                |  |  | RX frame  |                  |TX ACK|   |
   |----------------+--+--+-----------+------------------+------+---|
   |                |  |  |           |                  |      |   |
   |                / (4) /           /   tsTxAckDelay   /      |   |
   Start                                                          End
   of                                                              of
   Slot                                                          Slot
/(1)/ tsCCAOffset
/(2)/ tsCCA
/(3)/ tsRxTx
/(4)/ tsRxWait
/(5)/ tsAckWait

The timing parameters for the default macTimeslotTemplate (macTimeslotTemplateId = 0) MUST be used when utilizing the default timeslot duration. In this case, the TSCH Timeslot IE only transports the macTimeslotTemplateId with value 0x00. If a timeslot template other than the default is used, the EB MUST contain a complete TimeSlot IE indicating the timeslot duration and the corresponding timeslot timings. Note that in case of discrepancy between the values in this document and the IEEE 802.15.4 specification [IEEE802154], the IEEE standard has precedence.

5. IEEE.802.15.4 Specific Header Fields and Considerations

The IEEE802.15.4 header of BEACON, DATA, acknowledgment, MAC COMMAND frames MUST include the Sequence Number field, the Source Address field and the Destination Address field. Frame Version field MUST be set to 0b10 (Frame Version 2).

The PAN ID Compression bit in a BEACON frame MUST indicate that the Source PAN ID is "Not Present" and the Destination PAN ID is "Present". The source address field MUST be filled with an extended address (64 bit) and this be indicated in the corresponding Frame Control field. The Destination address field MUST be filled with a short address (16bit) with a value of 0xffff to represent the broadcast short address.

A Node aiming to join a network by receiving a properly formed BEACON MUST use a PAN ID set to 0xffff in order meet the filtering rules in the IEEE 802.15.4 specification [IEEE802154].

When using DATA, ACKNOWLEDGMENT, MAC COMMAND frame types the source and destination address fields MUST be filled with an extended address (64 bit) and this be indicated in the corresponding Frame Control field. The Destination PAN ID MUST be present, the Source PAN ID MUST be elided. The PAN ID Compression field MUST indicate that the Destination PAN ID is "Present" and the Source PAN ID is "Not Present". According to Table 2a in the IEEE 802.15.4e 2012 specification document, this is accomplished by setting the PAN ID Compression bit to 0b0 [IEEE802154-2012].

When preparing the security header, the Absolute Sequence Number (ASN) MUST be written into the Nonce in most significant byte first (MSB) format as indicated in the IEEE 802.15.4 specification [IEEE802154].

6. Enhanced Beacons Configuration and Content

The IEEE 802.15.4 specification does not define how often EBs are sent, nor their contents [IEEE802154]. EBs are not used for time synchronization. Time synchronization is achieved via acknowledgements to normal packet traffic, and keepalives. For additional reference see [RFC7554] where different time synchronization approaches are summarized.

In a minimal TSCH configuration, a node SHOULD send an EB every EB_PERIOD (default value = 10s). EBs are only authenticated and neither Payload IEs nor the frame payload are encrypted.

EBs MUST be sent as per the IEEE 802.15.4 specification and MUST carry the Information Elements (IEs) listed below [IEEE802154]. Refer to Appendix A.1 for an example of the Information Elements Header Content.

7. Acknowledgement Frames

Unicast frames sent to a unicast MAC destination address MUST request an acknowledgment. Each acknowledgment MUST contain an ACK/NACK Time Correction IE.

8. Neighbor information

The IEEE 802.15.4 specification does not define how and when each node in the network keeps information about its neighbours. A node SHOULD keep at least the following information in a neighbor table:

8.1. Neighbor Table

The exact format of the neighbor table is implementation-specific. Future version of the 6top Protocol [draft-wang-6tisch-sublayer] MAY require those information and statistics. The neighbor table SHOULD contain the following information for each neighbor:

In addition to that information, each node in a multihop topology and implementing RPL has to be able to compute some RPL Objective Function (OF), taking into account the neighbor and connectivity statistics. An example RPL objective function is the OF Zero as described in [RFC6552] and Section 11.1.1.

8.2. Time Source Neighbor Selection

Each node MUST select at least one Time Source Neighbor among the nodes in its routing parent set (e.g the RPL parent set). When a node joins a network, it has no routing information. To select its time source neighbor, it uses the Join Priority field in the EB, as described in the IEEE 802.15.4 specification [IEEE802154]. The Sync IE contains the ASN and 1 Byte field named Join Priority. The Join Priority of any node MUST be based on the routing metric of the network and normalized to a value between 0 and 15. In case that the network uses RPL, the Join Priority of any node MUST be equivalent to the result of the function DAGRank(rank)-1. The Join Priority of the DAG root MUST also be equivalent to DAGRank(rank)-1. According to Section 11.1.1 the DAGRank(rank(0)) = 1 and therefore the DAGRank(rank(0))-1 is 0 which is compliant with the requirement of Join Priority = 0 imposed by the IEEE 802.15.4 specification [IEEE802154]. A lower value of the Join Priority indicates higher preference to connect to that device.

When a RPL node joins the network, it MUST NOT send EBs before having acquired a RPL Rank. This applies to other routing protocols with its corresponding routing metrics. This avoids inconsistencies in the time synchronization structure. As soon as a node acquires routing information (e.g RPL Rank (see [RFC6550] and Section 11.1.1)), it SHOULD send Enhanced Beacons including a Sync IE with Join Priority field set as indicated above. If a node receives EBs from different nodes with equal Join Priority, the time source neighbor selection SHOULD be assessed by other metrics that can help to determine the better connectivity link. Time source neighbor hysteresis SHOULD be used, according to the rules defined in Section 11.2.3. At any time, a node MUST maintain connectivity to at least one time source neighbor. New time source neighbours MUST be chosen among the neighbours in the routing parent set.

The decision for a node to select one Time Source Neighbor when multiple EBs are received is implementation-specific.

For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT neighbours have been received to select the best Time Source Neighbor. This condition MAY apply unless a second EB is not received after MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting a first Time Source Neighbor.

Optionally, some form of hysteresis SHOULD be implemented to avoid frequent changes in time source neighbours.

9. Queues and Priorities

The IEEE 802.15.4 specification [IEEE802154] does not define the use of queues to handle upper layer data (either application or control data from upper layers). A single queue with the following rules SHOULD be used:

10. Security

As this document refers to the interaction between Layer 3 and Layer 2 protocols, this interaction MUST be secured by L2 security mechanisms as defined by the IEEE 802.15.4 specification [IEEE802154]. Two security mechanisms are considered, authentication and encryption, authentication applies to all packet content while encryption applies to header IEs and MAC payload. Key distribution is out of scope of this document, but examples include pre-configured keys at the nodes, shared keys among peers or well-known keys.

The present document assumes the existence of two cryptographic keys, which can be pre-configured. One of the keys (K1) is used to authenticate EBs. As defined in Section 6, EBs MUST be authenticated, with no payload encryption. This facilitates logical segregation of distinct networks. A second key (K2) is used to authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and respective header IEs, with payload encryption. Depending on security policy, these keys could be the same (i.e., K1=K2).

For early interoperability, K1 MAY be set to 36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15").

11. RPL on TSCH

In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used.

11.1. RPL Objective Function Zero

If RPL is used, nodes MUST implement the RPL Objective Function Zero (OF0) [RFC6552].

11.1.1. Rank computation

The Rank computation is described at [RFC6552], Section 4.1.

A node Rank (see Figure 3 for an example) is computed by the following equation:

R(N) = R(P) + rank_increment

rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease

Where:

Figure 3. Rank computation scenario.

    +-------+
    |   P   | R(P)
    |       |
    +-------+
        |
        |
    +-------+
    |   N   | R(N)=R(P) + rank_increment
    |       | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease
    +-------+ Sp= (3*ETX) - 2

11.1.2. Rank computation Example

This section illustrates with an example the use of the Objective Function Zero (refer to Figure 4 for specific details). Assume the following parameters:

Figure 4. Rank computation example for 5 hop network where numTx=100 and numTxAck=75 for all nodes

    +-------+
    |   0   | R(minHopRankIncrease) = 256
    |       | DAGRank(R(0)) = 1
    +-------+
        |
        |
    +-------+
    |   1   | R(1)=R(0) + 512 = 768
    |       | DAGRank(R(1)) = 3
    +-------+
        |
        |
    +-------+
    |   2   | R(2)=R(1) + 512 = 1280
    |       | DAGRank(R(2)) = 5
    +-------+
        |
        |
    +-------+
    |   3   | R(3)=R(2) + 512 = 1792
    |       | DAGRank(R(3)) = 7
    +-------+
        |
        |
    +-------+
    |   4   | R(4)=R(3) + 512 = 2304
    |       | DAGRank(R(4)) = 9
    +-------+
        |
        |
    +-------+
    |   5   | R(5)=R(4) + 512 = 2816
    |       | DAGRank(R(5)) = 11
    +-------+

11.2. RPL Configuration

In addition to the Objective Function (OF), nodes in a multihop network using RPL MUST indicate the preferred mode of operation using the MOP field in the DIO. Nodes not being able to operate in the specified mode of operation MUST only join as leaf nodes. RPL information and hop-by-hop extension headers MUST follow [RFC6553] and [RFC6554] specification. In the case that the packets formed at the LLN need to cross through intermediate routers, these MUST follow the IP in IP encapsulation requirement specified by the [RFC6282] and [RFC2460]. Routing extension headers such as RPI [RFC6550] and SRH [RFC6554], and outer IP headers in case of encapsulation MUST be compressed according to [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch].

11.2.1. Mode of Operation

When RPL is used, nodes MUST support the non-storing ([RFC6550] Section 9.7) mode of operation. The storing ([RFC6550] Section 9.8) mode of operation SHOULD be supported by nodes with enough capabilities. Non-storing mode of operation is the default mode that a node selects when acting as a DAG root.

11.2.2. Trickle Timer

RPL signaling messages such as DIOs are sent using the Trickle Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this specification, the Trickle Timer MUST be used with the RPL defined default values [RFC6550] (Section 8.3.1). For a description of the Trickle timer operation see Section 4.2 on [RFC6206].

11.2.3. Hysteresis

According to [RFC6552], [RFC6719] recommends the use of a boundary value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent when ranks are compared. When evaluating a parent that belongs to a smaller path cost than the current minimum path, the candidate node is selected as new parent only if the difference between the new path and the current path is greater than the defined PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the current preferred parent. As for [RFC6719] the PARENT_SWITCH_THRESHOLD SHOULD be set to 192 when ETX metric is used (in the form 128*ETX), the recommendation for this document is to use PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is (3*ETX-2)*minHopRankIncrease, or a proportional value. This mechanism is suited to deal with parent hysteresis in both cases including routing parent and time source neighbor selection.

12. Variable Values

Table 2 presents the values for the variables defined in this document that SHOULD be used.

Table 2. Recommended variable values

+-------------------------+-------+
| Variable                | Value |
+-------------------------+-------+
| MAX_EB_DELAY            |   180 |
+-------------------------+-------+
| NUM_NEIGHBOURS_TO_WAIT  |     2 |
+-------------------------+-------+
| PARENT_SWITCH_THRESHOLD |   640 |
+-------------------------+-------+

13. IANA Considerations

This document requests no immediate action by IANA.

14. Acknowledgements

The authors would like to acknowledge the guidance and input provided by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa Vucinic and for the exhaustive and detailed review of the examples section to Simon Duquennoy, Guillaume Gaillard, Tengfei Chang and Jonathan Muñoz. Also our acknowledge to the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne for their guidance and advice.

15. References

15.1. Normative References

[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with Hysteresis Objective Function", RFC 6719, DOI 10.17487/RFC6719, September 2012.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011.
[RFC6554] Hui, J., Vasseur, JP., Culler, D. and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012.
[RFC6552] Thubert, P., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N. and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O. and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[I-D.ietf-6lo-routing-dispatch] Thubert, P., Bormann, C., Toutain, L. and R. Cragie, "6LoWPAN Routing Header", Internet-Draft draft-ietf-6lo-routing-dispatch-05, February 2016.
[I-D.ietf-6lo-paging-dispatch] Thubert, P., "6LoWPAN Paging Dispatch", Internet-Draft draft-ietf-6lo-paging-dispatch-01, January 2016.
[IEEE802154-2012] IEEE standard for Information Technology, "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", April 2012.
[IEEE802154] IEEE standard for Information Technology, "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"

15.2. Informative References

[RFC7554] Watteyne, T., Palattella, M. and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014.
[RFC3610] Whiting, D., Housley, R. and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003.
[I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Internet-Draft draft-ietf-6tisch-terminology-06, November 2015.
[I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Internet-Draft draft-ietf-6tisch-architecture-09, November 2015.

15.3. External Informative References

[draft-wang-6tisch-sublayer] IETF, "6TiSCH Operation Sublayer (6top) (work in progress)", Nov 2015.
[decouto03high] De Couto, D., Aguayo, D., Bicket, J. and R. Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", ACM International Conference on Mobile Computing and Networking (MobiCom) , June 2003.
[CCM] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality. SP 800-38C", May 2004.
[CCM-Star] Struik, R., "Formal Specification of the CCM* Mode of Operation, IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs).", September 2005.
[OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S. and K. Pister, "OpenWSN: a Standards-Based Low-Power Wireless Development Environment", Transactions on Emerging Telecommunications Technologies , August 2012.

Appendix A. Examples

Several examples are provided to illustrate the content of the packets used by the minimal configuration as proposed by this document. Each example follows the same structure presenting first a schematic header diagram, then the LSB stream of bytes that conform the header and finally a description of each of the IEs that form the packet. The packet formats are specific for the [IEEE802154-2012] revision and may vary in future releases of the IEEE standard. In case of differences between the packet content presented in this section and the [IEEE802154-2012], the latter has precedence.

The MAC header fields are described in a specific order. All field formats in this examples are depicted in the order in which they are transmitted by the PHY, from left to right, where the leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost and least significant) to k – 1 (rightmost and most significant), where the length of the field is k bits. Fields that are longer than a single octet are sent to the PHY in the order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits, hence little endian ordering.

A.1. Example 1. Information Elements in EBs

Mandatory content for the EB as proposed by this draft. The example uses a slotframe of 101 slots. Figure 5 represents schematically the Header IE and Payload IE content of an EB.

Figure 5. Example of the IEs as proposed by this draft.


                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Len1 =   0  |Element ID=0x7e|0|    Len2 = 26        |GrpId=1|1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Len3 =   6    |Sub ID = 0x1a|0|           ASN             
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 ASN                               | Join Priority |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Len4 = 0x01  |Sub ID = 0x1c|0| TT ID = 0x00  |   Len5 = 0x01   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |ID=0x9 |1| CH ID = 0x00  | Len6 = 0x0A   |Sub ID = 0x1b|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   #SF = 0x01  | SF ID = 0x00  |   SF LEN = 0x65 (101 slots)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | #Links = 0x01 |      SLOT OFFSET = 0x0000     |    CHANNEL
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     OFF  = 0x0000 |Link OPT = 0x0F|         NO MAC PAYLOAD  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Stream of bytes (in little-endian ordering) that derive 
   from the previous schematic header:
   
   00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00  
   01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F      
  
   Description of the IE fields in the example:

   #Header IE Header
   Len1 = Header IE Length (0)
   Element ID = 0x7e - termination IE indicating Payload IE coming next
   Type 0
  
   #Payload IE Header (MLME)
   Len2 = Payload IE Len (26 Bytes) 
   GroupID = 1 MLME (Nested)
   Type = 1

   #MLME-SubIE TSCH Synchronization
   Len3 = Length in bytes of the sub-IE payload (6 Bytes)
   SubID = 0x1a (MLME-SubIE TSCH Synchronization)
   Type = Short (0)
   ASN  = Absolute Sequence Number (5 Bytes)
   Join Priority = 1 Byte

   #MLME-SubIE TSCH TimeSlot
   Len4 = Length in bytes of the sub-IE payload (1 Byte)
   SubID = 0x1c (MLME-SubIE Timeslot)
   Type = Short (0)
   TimeSlot template ID = 0x00 (default)
   
   #MLME-SubIE Ch. Hopping
   Len5 = Length in bytes of the sub-IE payload (1 Byte)
   SubID = 0x09 (MLME-SubIE Ch. Hopping)
   Type = Long (1)
   Channel Hopping Sequence ID = 0x00 (default)
  
   #MLME-SubIE TSCH Slotframe and Link
   Len6 = Length in bytes of the sub-IE payload (10 Bytes)
   SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link)
   Type = Short (0)
   Number of slotframes = 0x01
   SlotFrame Handle = 0x00
   SlotFrame Size = 101 slots (0x65)
   Number of Links = 0x01
   Timeslot = 0x0000 (2B)
   Channel Offset = 0x0000 (2B)
   Link Option = 0x0F (tx,rx,shared,timekeeping)

      

A.2. Example 2. Information Elements in EBs not using default timeslot template

Using a non-default timeslot template in EBs. Timeslot length set to 15ms instead of the 10ms default. Refer to Figure 6 for the specific IE fields.

Figure 6. Example of a non-default timeslot template in EB.

   
   Schematic representation of the IE header in an EB:
  
                      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Len1 =   0  |Element ID=0x7e|0|    Len2 = 53        |GrpId=1|1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Len3 =   6    |Sub ID = 0x1a|0|           ASN             
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 ASN                               | Join Priority |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Len4 = 25    |Sub ID = 0x1c|0| TT ID = 0x01  | macTsCCAOffset    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      = 2700       |  macTsCCA = 128               | macTsTxOffset
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      = 3180       |  macTsRxOffset = 1680         | macTsRxAckDelay
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      = 1200       |  macTsTxAckDelay = 1500       | macTsRxWait
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      = 3300       |  macTsAckWait = 600           | macTsRxTx
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      = 192        |  macTsMaxAck  = 2400          | macTsMaxTx
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      = 4256       | macTsTimeslotLength = 15000   | Len5 = 0x01   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |ID=0x9 |1| CH ID = 0x00  | Len6 = 0x0A   | ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Stream of bytes (in little-endian ordering) that derive  
   from the previous schematic header:

   00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80
   00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 
   00 0A ...     

   Description of the IE fields in the example:

   #Header IE Header
   Len1 = Header IE Length (none)
   Element ID = 0x7e - termination IE indicating Payload IE coming next
   Type 0
  
   #Payload IE Header (MLME)
   Len2 = Payload IE Len (53 Bytes) 
   GroupID = 1 MLME (Nested)
   Type = 1

   #MLME-SubIE TSCH Synchronization
   Len3 = Length in bytes of the sub-IE payload (6 Bytes)
   SubID = 0x1a (MLME-SubIE TSCH Synchronization)
   Type = Short (0)
   ASN  = Absolute Sequence Number (5 Bytes)
   Join Priority = 1 Byte

   #MLME-SubIE TSCH TimeSlot
   Len4 = Length in bytes of the sub-IE payload (25 Bytes)
   SubID = 0x1c (MLME-SubIE Timeslot)
   Type = Short (0)
   TimeSlot template ID = 0x01 (non-default)

   Example timeslot timing using 15ms timeslot.
   +--------------------------------+------------+
   | IEEE802.15.4 TSCH parameter    | Value (us) |
   +--------------------------------+------------+
   | tsCCAOffset                    |    2700    |
   +--------------------------------+------------+
   | tsCCA                          |     128    |
   +--------------------------------+------------+
   | tsTxOffset                     |    3180    |
   +--------------------------------+------------+
   | tsRxOffset                     |    1680    |
   +--------------------------------+------------+
   | tsRxAckDelay                   |    1200    |
   +--------------------------------+------------+
   | tsTxAckDelay                   |    1500    |
   +--------------------------------+------------+
   | tsRxWait                       |    3300    |
   +--------------------------------+------------+
   | tsAckWait                      |     600    |
   +--------------------------------+------------+
   | tsRxTx                         |     192    |
   +--------------------------------+------------+
   | tsMaxAck                       |    2400    |
   +--------------------------------+------------+
   | tsMaxTx                        |    4256    |
   +--------------------------------+------------+
   | Timeslot duration              |   15000    |
   +--------------------------------+------------+

   #MLME-SubIE Ch. Hopping
   Len5 = Length in bytes of the sub-IE payload. (1 Byte)
   SubID = 0x09 (MLME-SubIE Ch. Hopping)
   Type = Long (1)
   Channel Hopping Sequence ID = 0x00 (default)

      

A.3. Example 3. Information Elements in ACKs

Acknowledgement packets carry the ACK/NACK Time Correction IE (Header IE). Figure 7 illustrates the IE format as specified in [IEEE802154-2012].

Figure 7. Acknowledgement packet IE content.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Len1 =   2  |Element ID=0x1e|0|        Time Sync Info         |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Stream of bytes (in little-endian ordering) that derive 
   from the previous schematic header:
   
   02 0F TS#0 TS#1 

   Description of the IE fields in the example:

   #Header IE Header
   Len1 = Header IE Length (2 Bytes)
   Element ID = 0x1e - ACK/NACK Time Correction IE 
   Type 0

      

A.4. Example 4. Auxiliary Security Header

Figure 8 illustrates the content of the Auxiliary Security Header as mandated by this document, if security is enabled. Security Level in the example is set to ENC-MIC-32 (5).

Figure 8. Example auxiliary security header.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L = 5|M=1|1|1|0|Key Index = IDX|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Stream of bytes (in LSB format) that derive from the previous 
   schematic header:
   
   6D IDX#0

   Description of the Security Auxiliary Header fields in the example:

   #Security Control (1 byte)
   L = Security Level ENC-MIC-32 (5)
   M = Key Identifier Mode (0x01)
   Frame Counter Suppression = 1 (omitting Frame Counter field)
   Frame Counter Size = 1 (construct Nonce from 5 byte ASN)
   Reserved = 0

   #Key Identifier (1 byte)
   Key Index = IDX (deployment-specific KeyIndex parameter that 
               identifies the cryptographic key) 

      

Authors' Addresses

Xavier Vilajosana (editor) Universitat Oberta de Catalunya 156 Rambla Poblenou Barcelona, Catalonia 08018 Spain Phone: +34 (646) 633 681 EMail: xvilajosana@uoc.edu
Kris Pister University of California Berkeley 490 Cory Hall Berkeley, California 94720 USA EMail: pister@eecs.berkeley.edu