[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-vilajosana-6tisch-minimal) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 RFC 8180

6TiSCH                                                X. Vilajosana, Ed.
Internet-Draft                           Universitat Oberta de Catalunya
Intended status: Best Current Practice                         K. Pister
Expires: August 30, 2016               University of California Berkeley
                                                       February 27, 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 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



Vilajosana & Pister      Expires August 30, 2016                [Page 1]


Internet-Draft               6tisch-minimal                February 2016


   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Minimal Schedule Configuration  . . . . . . . . . . . . . . .   3
     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 . . . . . . . . . . . . . .  15
     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 . . . . . . . . . . . . . . . . . . . . . . .  18
   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 . . . . . . . . . . . . . . . . . . . .  24
     A.3.  Example 3. Information Elements in ACKs . . . . . . . . .  27
     A.4.  Example 4. Auxiliary Security Header  . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28





Vilajosana & Pister      Expires August 30, 2016                [Page 2]


Internet-Draft               6tisch-minimal                February 2016


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:

      CCA: Clear Channel Assessment.

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



Vilajosana & Pister      Expires August 30, 2016                [Page 3]


Internet-Draft               6tisch-minimal                February 2016


   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:























Vilajosana & Pister      Expires August 30, 2016                [Page 4]


Internet-Draft               6tisch-minimal                February 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)      |
   |                                    |   (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



Vilajosana & Pister      Expires August 30, 2016                [Page 5]


Internet-Draft               6tisch-minimal                February 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].  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.





















Vilajosana & Pister      Expires August 30, 2016                [Page 6]


Internet-Draft               6tisch-minimal                February 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 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:

      b0 = Transmit = 1 (set)

      b1 = Receive = 1 (set)



Vilajosana & Pister      Expires August 30, 2016                [Page 7]


Internet-Draft               6tisch-minimal                February 2016


      b2 = Shared = 1 (set)

      b3 = Timekeeping = 1 (set)

      b4-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
   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.




Vilajosana & Pister      Expires August 30, 2016                [Page 8]


Internet-Draft               6tisch-minimal                February 2016


   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.



Vilajosana & Pister      Expires August 30, 2016                [Page 9]


Internet-Draft               6tisch-minimal                February 2016


   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.

      Synchronization IE: Contains synchronization information such as
      ASN and Join Priority.  The value of Join Priority 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].  In the case that
      a non-default timeslot template is used, the IE Content MUST
      follow the specification as defined in [IEEE802154] . Refer to




Vilajosana & Pister      Expires August 30, 2016               [Page 10]


Internet-Draft               6tisch-minimal                February 2016


      Appendix A.1 for an illustrative example of non default timeslot
      template.

      Channel Hopping IE: Contains the channel hopping template
      identifier.  This specification uses the default channel hopping
      template, as defined in the IEEE 802.15.4 specification
      [IEEE802154].  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].  Note however that in case of discrepancy between
      the values in this document and [IEEE802154], the IEEE standard
      specification has preference.

      SlotFrame and Link IE: Each node MUST indicate the schedule in
      each EB through a SlotFrame and Link IE.  This enables nodes which
      implement the IEEE 802.15.4 specification [IEEE802154] 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 linkOption 0x0F (TX,
      RX, SHARED bits set).  A node SHOULD indicate the same information
      in the "SlotFrame and Link IE" in the EBs it sends, than the
      "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.
   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:

      Neighbor statistics:

         numTx: number of transmitted packets to that neighbor

         numTxAck: number of transmitted packets that have been
         acknowledged by that neighbor




Vilajosana & Pister      Expires August 30, 2016               [Page 11]


Internet-Draft               6tisch-minimal                February 2016


         numRx: number of received packets from that neighbor

      The EUI64 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.

      Connectivity statistics (e.g., RSSI), which can be used to
      determine the quality of the link.

   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



Vilajosana & Pister      Expires August 30, 2016               [Page 12]


Internet-Draft               6tisch-minimal                February 2016


   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:

      A node MUST not queue frames containing higher-layer packets until
      the node has successfully joined a network.

      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].  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.



Vilajosana & Pister      Expires August 30, 2016               [Page 13]


Internet-Draft               6tisch-minimal                February 2016


   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:

      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.

      Sp (step_of_rank): (strictly positive integer) - an intermediate
      computation based on the link properties with a certain neighbor,



Vilajosana & Pister      Expires August 30, 2016               [Page 14]


Internet-Draft               6tisch-minimal                February 2016


      i.e., 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).  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.

      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 its 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

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:

      Rf = 1




Vilajosana & Pister      Expires August 30, 2016               [Page 15]


Internet-Draft               6tisch-minimal                February 2016


      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 August 30, 2016               [Page 16]


Internet-Draft               6tisch-minimal                February 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 August 30, 2016               [Page 17]


Internet-Draft               6tisch-minimal                February 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.

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.









Vilajosana & Pister      Expires August 30, 2016               [Page 18]


Internet-Draft               6tisch-minimal                February 2016


   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 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>.

   [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>.






Vilajosana & Pister      Expires August 30, 2016               [Page 19]


Internet-Draft               6tisch-minimal                February 2016


   [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>.

   [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>.




Vilajosana & Pister      Expires August 30, 2016               [Page 20]


Internet-Draft               6tisch-minimal                February 2016


   [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-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., 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>.

   [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-06 (work in
              progress), November 2015.




Vilajosana & Pister      Expires August 30, 2016               [Page 21]


Internet-Draft               6tisch-minimal                February 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-09 (work
              in progress), 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



Vilajosana & Pister      Expires August 30, 2016               [Page 22]


Internet-Draft               6tisch-minimal                February 2016


   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



Vilajosana & Pister      Expires August 30, 2016               [Page 23]


Internet-Draft               6tisch-minimal                February 2016


    #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:



Vilajosana & Pister      Expires August 30, 2016               [Page 24]


Internet-Draft               6tisch-minimal                February 2016


                       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)



Vilajosana & Pister      Expires August 30, 2016               [Page 25]


Internet-Draft               6tisch-minimal                February 2016


    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)







Vilajosana & Pister      Expires August 30, 2016               [Page 26]


Internet-Draft               6tisch-minimal                February 2016


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).



















Vilajosana & Pister      Expires August 30, 2016               [Page 27]


Internet-Draft               6tisch-minimal                February 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 August 30, 2016               [Page 28]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/