6TiSCH X. Vilajosana, Ed.
Internet-Draft Universitat Oberta de Catalunya
Intended status: Best Current Practice K. Pister
Expires: December 30, 2016 University of California Berkeley
June 28, 2016
Minimal 6TiSCH Configuration
draft-ietf-6tisch-minimal-16
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 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 December 30, 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
Vilajosana & Pister Expires December 30, 2016 [Page 1]
Internet-Draft 6tisch-minimal June 2016
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Minimal Schedule Configuration . . . . . . . . . . . . . . . 4
4.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 8
4.4. Timeslot timing . . . . . . . . . . . . . . . . . . . . . 8
5. IEEE.802.15.4 Specific Header Fields and Considerations . . . 9
6. Enhanced Beacons Configuration and Content . . . . . . . . . 10
7. Acknowledgement Frames . . . . . . . . . . . . . . . . . . . 11
8. Neighbor information . . . . . . . . . . . . . . . . . . . . 11
8.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 11
8.2. Time Source Neighbor Selection . . . . . . . . . . . . . 12
9. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 13
10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. RPL Objective Function Zero . . . . . . . . . . . . . . 14
11.1.1. Rank computation . . . . . . . . . . . . . . . . . . 14
11.1.2. Rank computation Example . . . . . . . . . . . . . . 16
11.2. RPL Configuration . . . . . . . . . . . . . . . . . . . 17
11.2.1. Mode of Operation . . . . . . . . . . . . . . . . . 18
11.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . 18
11.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 18
12. Variable Values . . . . . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
15.1. Normative References . . . . . . . . . . . . . . . . . . 19
15.2. Informative References . . . . . . . . . . . . . . . . . 21
15.3. External Informative References . . . . . . . . . . . . 22
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Example 1. Information Elements in EBs . . . . . . . . . 23
A.2. Example 2. Information Elements in EBs not using default
timeslot template . . . . . . . . . . . . . . . . . . . . 25
A.3. Example 3. Information Elements in ACKs . . . . . . . . . 27
A.4. Example 4. Auxiliary Security Header . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Vilajosana & Pister Expires December 30, 2016 [Page 2]
Internet-Draft 6tisch-minimal June 2016
1. Introduction
A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast
Multi-Access (NBMA) network 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] (NDlo) 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 are specified to guarantee
interoperability between nodes in a 6TiSCH Network. RPL is a natural
choice for routing on top of IEEE 802.15.4 TSCH, and the specifics
for interoperable interaction between RPL and TSCH are described.
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:
CCA: Clear Channel Assessment.
SFD: Start of Frame Delimiter.
RX: Reception.
Vilajosana & Pister Expires December 30, 2016 [Page 3]
Internet-Draft 6tisch-minimal June 2016
TX: Transmission.
Join Priority: Join Metric.
Join Metric: Field in the TSCH Synchronization IE. Number of hops
separating the node sending the EB, and the PAN coordinator
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 constitute a minimal configuration to which
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 must agreed
upon as configuration parameters 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. More details about security
are given in Section Section 10.
The present specification is independent of the actual physical
layer; 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:
Vilajosana & Pister Expires December 30, 2016 [Page 4]
Internet-Draft 6tisch-minimal June 2016
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) |
| | (link Option 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.4 |
| | 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-2015]. 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
Vilajosana & Pister Expires December 30, 2016 [Page 5]
Internet-Draft 6tisch-minimal June 2016
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-2015]. The remaining cells
in the slotframe are unscheduled, and MAY be used by other (dynamic)
scheduling solutions. Details about such dynamic scheduling
solutions 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-2015].
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.
Vilajosana & Pister Expires December 30, 2016 [Page 6]
Internet-Draft 6tisch-minimal June 2016
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 Link Options bitmap [IEEE802154-2015]. The
active cell in the minimal configuration MUST use a Link Option 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
"Tx Link" and "Rx Link" bits are set. A "Shared Link" 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-2015]. 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.
Link Option bitmap setting for the active cell in the minimal
configuration slotframe:
b0 = Tx Link = 1 (set)
b1 = Rx Link = 1 (set)
Vilajosana & Pister Expires December 30, 2016 [Page 7]
Internet-Draft 6tisch-minimal June 2016
b2 = Shared Link = 1 (set)
b3 = Timekeeping = 1 (set)
b4 = Priority = 0 (clear)
b5-b7 = Reserved (clear)
In addition, the scheduled cell in the schedule is configured as a
Hard cell [RFC7554][I-D.ietf-6tisch-terminology] indicating that it
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 Link Option 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.
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.
Vilajosana & Pister Expires December 30, 2016 [Page 8]
Internet-Draft 6tisch-minimal June 2016
Figure 2. Timeslot internal timing diagram (refer to Figure 6-43 in
[IEEE802154-2015])
/---------------------- 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-2015], 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. The 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
Vilajosana & Pister Expires December 30, 2016 [Page 9]
Internet-Draft 6tisch-minimal June 2016
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-2015].
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 7-6 in the IEEE 802.15.4 2015
specification document, this is accomplished by setting the PAN ID
Compression bit to 0b0 [IEEE802154-2015].
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-2015].
6. Enhanced Beacons Configuration and Content
The IEEE 802.15.4 specification does not define how often EBs are
sent, nor their contents [IEEE802154-2015]. 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; 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-2015].
Refer to Appendix A.1 for an example of the Information Elements
Header Content.
TSCH Synchronization IE: Contains synchronization information such
as ASN and Join Metric. The value of Join Metric is discussed in
Section 8.2.
TSCH Timeslot IE: Contains the timeslot template identifier. This
template is used to specify the internal timing of the timeslot.
This specification uses the default timeslot template as defined
in the IEEE 802.15.4 specification [IEEE802154-2015]. In the case
Vilajosana & Pister Expires December 30, 2016 [Page 10]
Internet-Draft 6tisch-minimal June 2016
that a non-default timeslot template is used, the IE Content MUST
follow the specification as defined in [IEEE802154-2015] . Refer
to Appendix A.1 for an illustrative example of non default
timeslot template.
Channel Hopping IE: Contains the channel hopping sequence
identifier. This specification uses the default channel hopping
sequence (with default HoppingSequenceID = 0x00), as defined in
the IEEE 802.15.4 specification [IEEE802154-2015]. The default
sequence for the 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11,
8, 0, 1, 2, 13, 3, 9, 10] [IEEE802154-2015]. Note however that
in case of discrepancy between the values in this document and
[IEEE802154-2015], the IEEE standard specification has preference.
TSCH SlotFrame and Link IE: Each node MUST indicate the schedule
in each EB through a TSCH SlotFrame and Link IE. This enables
nodes which implement the IEEE 802.15.4 specification
[IEEE802154-2015] to learn the schedule used in the network as
they join it. This document defines the use of a single cell set
at the default channel offset 0x00, default timeslot offset 0x00
and with Link Option 0x0F (TX, RX, SHARED bits set). A node
SHOULD indicate the same information in the "TSCH SlotFrame and
Link IE" in the EBs it sends, than the "TSCH SlotFrame and Link
IE" information it has received in an EB.
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.
The neighbor table SHOULD contain the following information for each
neighbor:
Neighbor statistics:
numTx: number of transmitted packets to that neighbor
Vilajosana & Pister Expires December 30, 2016 [Page 11]
Internet-Draft 6tisch-minimal June 2016
numTxAck: number of transmitted packets that have been
acknowledged by that neighbor
numRx: number of received packets from that neighbor
The EUI-64 of the neighbor.
Timestamp of the last frame received from that neighbor. This can
be based on the ASN counter or any other time base. It can be
used to trigger a keep-alive message.
Routing metric such as the RPL Rank of that neighbor.
A flag indicating whether this neighbor is a time source neighbor.
In addition to that information, each node in a multihop topology and
implementing RPL MUST at least support the use 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 Metric field in the EB, as
described in the IEEE 802.15.4 specification [IEEE802154-2015]. The
Sync IE contains the ASN and 1 Byte field named Join Metric. The
Join Metric 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 Metric of any node MUST be equivalent to
the result of the function DAGRank(rank)-1. The Join Metric 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 Metric = 0 imposed by the IEEE 802.15.4 specification
[IEEE802154-2015]. A lower value of the Join Metric 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
their 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 Metric field set as indicated above. If a node receives
EBs from different nodes with equal Join Metric, the time source
neighbor selection SHOULD be assessed by other metrics that can help
to determine the better connectivity link. Time source neighbor
Vilajosana & Pister Expires December 30, 2016 [Page 12]
Internet-Draft 6tisch-minimal June 2016
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.
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-2015] 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:
A node MAY be configured to keep in the queue a configurable
number of Upper Layer packets per link ( default
NUM_UPPERLAYER_PACKETS = 1) for a configurable time in seconds
that should cover the join process ( default MAX_JOIN_TIME = 300
).
Frames generated by the IEEE 802.15.4 layer are queued with higher
priority than frames containing higher-layer packets.
Frame types BEACON and COMMAND are queued with higher priority
than frame types DATA and ACK.
One entry in the queue is reserved at all times for frames of
types BEACON and COMMAND frames.
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-2015]. 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
Vilajosana & Pister Expires December 30, 2016 [Page 13]
Internet-Draft 6tisch-minimal June 2016
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 testing, it is recommended to set K1 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's 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:
R(N): Rank of the node.
R(P): Rank of the parent obtained as part of the DIO information.
rank_increment: The result of a function that determines the Rank
increment.
Rf (rank_factor): A configurable factor that is used to multiply
the effect of the link properties in the rank_increment
computation. A minimal configuration SHOULD set rank_factor to 1.
Vilajosana & Pister Expires December 30, 2016 [Page 14]
Internet-Draft 6tisch-minimal June 2016
Sp (step_of_rank): (strictly positive integer) - an intermediate
computation based on the link properties with a certain neighbor,
for example the Expected Transmission Count (ETX) which provides
an average of number of packet transmissions between two nodes.
ETX is defined in detail by [decouto03high] and [RFC6551]. The
ETX is computed as the inverse of the Packet Delivery Ratio (PDR),
this is the number of transmitted packets, divided by the number
of acknowledged packets to a certain node (e.g., ETX = numTX/
numTXAck). Note that this specification is designed for the
IEEE802.15.4 MAC [IEEE802154-2015] which assumes L2 ACK. In case
that a future use of this specification relies on a MAC layer that
does not provide L2 ACK this metric needs to be reconsidered. An
implementation MUST follow OF0's normalization guidance as
discussed in Section 1 and Section 4.1 of [RFC6552], maintaining
Sp between MINIMUM_STEP_OF_RANK of 1 to indicate a great quality
and MAXIMUM_STEP_OF_RANK of 9 to indicate a really poor quality,
with DEFAULT_STEP_OF_RANK indicating a normal, average quality.
Sp SHOULD be set to (3*ETX)-2. Candidate parents with ETX greater
than 3 SHOULD not be selected, motivated to avoid ETX values
larger than the allowed retransmissions (4 transmission attempts).
Sr (stretch_of_rank): (unsigned integer) - the maximum increment
to the step_of_rank of a preferred parent, to allow the selection
of an additional feasible successor. In this specification,
stretch_of_rank SHOULD be set to 0.
MinHopRankIncrease: the MinHopRankIncrease is set to the fixed
constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550].
DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256.
DAGRank(rank): Equivalent to the floor of "rank" as defined by
[RFC6550]. DAGRank(rank) = floor(rank/MinHopRankIncrease). Nodes
compute their DAGRank(rank) using DAGRank(R(N)).
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
Vilajosana & Pister Expires December 30, 2016 [Page 15]
Internet-Draft 6tisch-minimal June 2016
11.1.2. Rank computation Example
This section illustrates with an example the use of the Objective
Function Zero (see Figure 4 which uses numTx=100 and numTxAck=75 for
all nodes). Assume the following parameters:
Rf = 1
Sp = (3*ETX)-2
Sr = 0
minHopRankIncrease = 256 (default in RPL)
ETX=(numTx/numTxAck)
r(n) = r(p) + rank_increment
rank_increment = (Rf*Sp + Sr) * minHopRankIncrease
rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512
Vilajosana & Pister Expires December 30, 2016 [Page 16]
Internet-Draft 6tisch-minimal June 2016
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
Vilajosana & Pister Expires December 30, 2016 [Page 17]
Internet-Draft 6tisch-minimal June 2016
[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. The latest is motivated
because most of the practical usages of the RPL protocol in the IoT
space make use of non-storing modes. This is because storing mode
limits the size of the network to the storage capabilities of the
devices, and is more complex to operate due to the distributed
routing operation for routing downwards. In addition, it is
important to note that the Mode of Operation is an administrative
action and changing it causes the DAG to rebuild entirely.
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. In case
a node has a security association with its parent, including routing
parent or time source neighbor, the node SHOULD be allowed to keep
the association despite of fluctuations of the rank.
Vilajosana & Pister Expires December 30, 2016 [Page 18]
Internet-Draft 6tisch-minimal June 2016
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 |
+-------------------------+-------+
| NUM_UPPERLAYER_PACKETS | 1 |
+-------------------------+-------+
| JOIN_TIME | 300 |
+-------------------------+-------+
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 document by Charles Perkins. Also for the detailed review of
the examples section to Simon Duquennoy, Guillaume Gaillard, Tengfei
Chang and Jonathan Munoz. 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,
<http://www.rfc-editor.org/info/rfc6719>.
Vilajosana & Pister Expires December 30, 2016 [Page 19]
Internet-Draft 6tisch-minimal June 2016
[RFC6775] Shelby, Z., Ed., 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,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[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,
<http://www.rfc-editor.org/info/rfc6554>.
[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,
<http://www.rfc-editor.org/info/rfc6553>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012,
<http://www.rfc-editor.org/info/rfc6552>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., 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,
<http://www.rfc-editor.org/info/rfc6551>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., 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,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>.
Vilajosana & Pister Expires December 30, 2016 [Page 20]
Internet-Draft 6tisch-minimal June 2016
[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,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[I-D.ietf-6lo-routing-dispatch]
Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
"6LoWPAN Routing Header", draft-ietf-6lo-routing-
dispatch-05 (work in progress), February 2016.
[I-D.ietf-6lo-paging-dispatch]
Thubert, P., "6LoWPAN Paging Dispatch", draft-ietf-6lo-
paging-dispatch-01 (work in progress), January 2016.
[IEEE802154-2015]
IEEE standard for Information Technology, "IEEE Std
802.15.4-2015 Standard for Low-Rate Wireless Personal Area
Networks (WPANs)", December 2015.
15.2. Informative References
[RFC7554] Watteyne, T., Ed., 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,
<http://www.rfc-editor.org/info/rfc7554>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <http://www.rfc-editor.org/info/rfc3610>.
Vilajosana & Pister Expires December 30, 2016 [Page 21]
Internet-Draft 6tisch-minimal June 2016
[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", draft-ietf-6tisch-terminology-07 (work in
progress), March 2016.
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
in progress), June 2016.
[I-D.ietf-6tisch-6top-protocol]
Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft-
ietf-6tisch-6top-protocol-01 (work in progress), June
2016.
15.3. External Informative References
[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-2015]
Vilajosana & Pister Expires December 30, 2016 [Page 22]
Internet-Draft 6tisch-minimal June 2016
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-2015], 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 Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Vilajosana & Pister Expires December 30, 2016 [Page 23]
Internet-Draft 6tisch-minimal June 2016
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 Metric = 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)
Vilajosana & Pister Expires December 30, 2016 [Page 24]
Internet-Draft 6tisch-minimal June 2016
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 Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Vilajosana & Pister Expires December 30, 2016 [Page 25]
Internet-Draft 6tisch-minimal June 2016
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 Metric = 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 |
+--------------------------------+------------+
Vilajosana & Pister Expires December 30, 2016 [Page 26]
Internet-Draft 6tisch-minimal June 2016
| 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
Enhanced Acknowledgement packets carry the Time Correction IE (Header
IE). Figure 7 illustrates the IE format as specified in
[IEEE802154-2015].
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).
Vilajosana & Pister Expires December 30, 2016 [Page 27]
Internet-Draft 6tisch-minimal June 2016
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
Vilajosana & Pister Expires December 30, 2016 [Page 28]
