[Docs] [txt|pdf|xml|html] [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: June 1, 2017                  University of California Berkeley
                                                       November 28, 2016


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

Abstract

   This document describes a minimal mode of operation for a 6TiSCH
   Network.  It provides IPv6 connectivity over a Non-Broadcast Multi-
   Access (NBMA) mesh composed of IEEE802.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 IEEE802.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 June 1, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Vilajosana & Pister       Expires June 1, 2017                  [Page 1]


Internet-Draft               6tisch-minimal                November 2016


   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.  IEEE802.15.4 Settings . . . . . . . . . . . . . . . . . . . .   4
     4.1.  TSCH Schedule . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Cell Options  . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Retransmissions . . . . . . . . . . . . . . . . . . . . .   7
     4.4.  Timeslot Timing . . . . . . . . . . . . . . . . . . . . .   7
     4.5.  Frame Formats . . . . . . . . . . . . . . . . . . . . . .   8
       4.5.1.  IEEE802.15.4 Header . . . . . . . . . . . . . . . . .   8
       4.5.2.  Enhanced Beacon Frame . . . . . . . . . . . . . . . .   9
       4.5.3.  Acknowledgment Frame  . . . . . . . . . . . . . . . .  10
     4.6.  Link-Layer Security . . . . . . . . . . . . . . . . . . .  10
   5.  RPL Settings  . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Objective Function  . . . . . . . . . . . . . . . . . . .  10
       5.1.1.  Rank Computation  . . . . . . . . . . . . . . . . . .  11
       5.1.2.  Rank Computation Example  . . . . . . . . . . . . . .  12
     5.2.  Mode of Operation . . . . . . . . . . . . . . . . . . . .  13
     5.3.  Trickle Timer . . . . . . . . . . . . . . . . . . . . . .  13
     5.4.  Packet Formats  . . . . . . . . . . . . . . . . . . . . .  13
   6.  Network Formation and Lifetime  . . . . . . . . . . . . . . .  13
     6.1.  Value of the Join Metric Field  . . . . . . . . . . . . .  13
     6.2.  Initial Time Source Neighbor Selection  . . . . . . . . .  13
     6.3.  When to Start Sending EBs . . . . . . . . . . . . . . . .  14
     6.4.  Time Source Neighbor Selection  . . . . . . . . . . . . .  14
     6.5.  Hysteresis  . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Implementation Recommendations  . . . . . . . . . . . . . . .  14
     7.1.  Neighbor Table  . . . . . . . . . . . . . . . . . . . . .  15
     7.2.  Queues and Priorities . . . . . . . . . . . . . . . . . .  15
     7.3.  Recommended Settings  . . . . . . . . . . . . . . . . . .  16
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  18
     10.3.  External Informative References  . . . . . . . . . . . .  18
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  18
     A.1.  Example: EB with Default Timeslot Template  . . . . . . .  19
     A.2.  Example: EB with Custom  Timeslot Template  . . . . . . .  20
     A.3.  Example: Link-layer Acknowledgment  . . . . . . . . . . .  22
     A.4.  Example: Auxiliary Security Header  . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24



Vilajosana & Pister       Expires June 1, 2017                  [Page 2]


Internet-Draft               6tisch-minimal                November 2016


1.  Introduction

   A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast
   Multi-Access (NBMA) network that is composed of IEEE802.15.4
   Timeslotted Channel Hopping (TSCH) links.

   Nodes in an IEEE802.15.4 TSCH network follow a communication
   schedule.  When following this specification, a node learns the
   schedule of the network when joining, the schedule is static and the
   same for all nodes.

   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.  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 IEEE802.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 at 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 [I-D.ietf-6tisch-terminology].
   The following concepts are used in this document:

   SFD:  Start of Frame Delimiter.

   RX:  Reception.

   TX:  Transmission.

   Join Metric:  Field in the TSCH Synchronization IE.  Number of hops
      separating the node sending the EB, and the PAN coordinator.








Vilajosana & Pister       Expires June 1, 2017                  [Page 3]


Internet-Draft               6tisch-minimal                November 2016


4.  IEEE802.15.4 Settings

   An implementation compliant to this specification MUST implement the
   IEEE802.15.4 [IEEE802154-2015] in "timeslotted channel hopping"
   (TSCH) mode.

   The remainder of this section details the RECOMMENDED TSCH settings,
   which are summarized in Figure 1.  A node MAY use different values.
   Any of the properties marked in the EB column are announced in the
   Enhanced Beacons (EB) the nodes send [IEEE802154-2015].  Changing
   their value hence means changing the contents of the EB.

   In case of discrepancy between the values in this specification and
   the IEEE802.15.4 specification [IEEE802154-2015], the IEEE standard
   has precedence.




































Vilajosana & Pister       Expires June 1, 2017                  [Page 4]


Internet-Draft               6tisch-minimal                November 2016


   +--------------------------------+------------------------------+---+
   |           Property             |     Recommended Setting      |EB*|
   +--------------------------------+------------------------------+---+
   | Slotframe Length               | Tunable. Trades-off          | X |
   |                                | bandwidth against energy.    |   |
   +--------------------------------+------------------------------+---+
   | Number of scheduled cells      | 1 (slotOffset  0x00)         | X |
   | (active)                       |   (chOffset    0x00)         |   |
   |                                |   (link Option 0x0f)         |   |
   |                                |   (macLinkType ADVERTISING)  |   |
   +--------------------------------+------------------------------+---+
   | Number of unscheduled cells    | All remaining cells in the   | X |
   | (off)                          | slotframe                    |   |
   +--------------------------------+------------------------------+---+
   | Max Number MAC retransmissions | 3 (4 transmission attempts)  |   |
   +--------------------------------+------------------------------+---+
   | Timeslot template              | IEEE802.15.4 default         | X |
   |                                | (macTimeslotTemplateId=0)    |   |
   +--------------------------------+------------------------------+---+
   | Enhanced Beacon Period         | Tunable. Trades-off join     |   |
   | (EB_PERIOD)                    | time against energy.         |   |
   +--------------------------------+------------------------------+---+
   | Number used frequencies        | IEEE802.15.4 default         | X |
   | (2.4 GHz O-QPSK PHY)           | (16)                         |   |
   +--------------------------------+------------------------------+---+
   | Channel Hopping sequence       | IEEE802.15.4 default         | X |
   | (2.4 GHz O-QPSK PHY)           | [5, 6, 12, 7, 15, 4, 14, 11, |   |
   |                                |  8, 0,  1, 2, 13, 3,  9, 10] |   |
   +--------------------------------+------------------------------+---+
    * an "X" in this column means this property's value is announced in
      the EB; a new node hence learns it when joining.

             Figure 1: Recommended IEEE802.15.4 TSCH Settings.

4.1.  TSCH Schedule

   The TSCH slotframe is composed of a tunable number of timeslots.  The
   slotframe length (i.e. the number of timeslots it contains) trades
   off bandwidth for energy consumption.  The slotframe length needs to
   be tuned; the way of tuning it is out of scope of this specification.
   The slotframe length is announced in the EB.

   There is only a single scheduled cell in the slotframe.  This cell
   MAY be scheduled at any slotOffset/channelOffset within the
   slotframe.  The location of that cell in the schedule is announced in
   the EB.  The macLinkType of the scheduled cell is ADVERTISING to
   allow EBs to be sent on it.




Vilajosana & Pister       Expires June 1, 2017                  [Page 5]


Internet-Draft               6tisch-minimal                November 2016


   Figure 2 shows an example of a slotframe of length 101 timeslots,
   resulting in a radio duty cycle below 0.99%.

      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 by this specification

           Figure 2: Example slotframe of length 101 timeslots.

   A node MAY use the scheduled cell to transmit/receive all types of
   link-layer frames.  EBs are sent to the link-layer broadcast address,
   and not acknowledged.  Data frames are sent unicast, and acknowledged
   by the receiving neighbor.

   All remaining cells in the slotframe are unscheduled.  Dynamic
   scheduling solutions MAY be defined in the future which schedule
   those cells.  One example is the 6top Protocol (6P)
   [I-D.ietf-6tisch-6top-protocol].  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.  In particular,
   this specification does not make any restriction on the Link Option
   bitmap associated with those dynamically scheduled cells (i.e. they
   can be "Hard" or "Soft" cells, see [I-D.ietf-6tisch-terminology]).

   The default values of the Timeslot template and Channel Hopping
   sequence (defined in [IEEE802154-2015]) SHOULD be used.  A node MAY
   use different values by properly announcing it in its Enhanced
   Beacon.







Vilajosana & Pister       Expires June 1, 2017                  [Page 6]


Internet-Draft               6tisch-minimal                November 2016


4.2.  Cell Options

   In the scheduled cell, a node transmits if there is a packet to
   transmit, listens otherwise (both "TX" and "RX" bits are set).  When
   a node transmits and does not receive a link-layer acknowledgment, it
   uses a back-off mechanism to resolve possible collisions ("Shared"
   bit is set).  A node joining the network maintains time
   synchronization to its initial time source neighbor using that cell
   ("Timekeeping" bit is set).

   This translates into a Link Option for this cell of value 0x0f:

      b0 = TX Link = 1 (set)
      b1 = RX Link = 1 (set)
      b2 = Shared Link = 1 (set)
      b3 = Timekeeping = 1 (set)
      b4 = Priority = 0 (clear)
      b5-b7 = Reserved = 0 (clear)

   The scheduled cell is a "Hard cell" [I-D.ietf-6tisch-terminology],
   i.e. it cannot be moved or relocated by any dynamic scheduling
   mechanism.

4.3.  Retransmissions

   Per Figure 1, the RECOMMENDED maximum number of link-layer
   retransmissions is 3.  This means that, 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 not requiring an acknowledgment (including EBs)
   are not retransmitted.

4.4.  Timeslot Timing

   Figure 3 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)



Vilajosana & Pister       Expires June 1, 2017                  [Page 7]


Internet-Draft               6tisch-minimal                November 2016


   if required; this does not interfere with the scope of this document.
   The use of CCA is OPTIONAL.

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

    Figure 3: Timeslot internal timing diagram (refer to Figure 6-43 in
                            IEEE802.15.4-2015.)

   Per Figure 1, the RECOMMENDED timeslot template is the default one
   defined in [IEEE802154-2015].

4.5.  Frame Formats

   The following sections detail the RECOMMENDED format of link-layer
   frames of different types.  A node MAY use a different formats (bit
   settings, etc), but MUST implement IEEE802.15.4 TSCH correctly.  As
   long as an implementation follows IEEE802.15.4 TSCH correctly, it is
   compliant to this specification.

4.5.1.  IEEE802.15.4 Header

   The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames
   SHOULD include the Source Address field and the Destination Address
   field.  The Frame Version field SHOULD be set to 0b10 (Frame Version
   2).  The IEEE802.15.4 header SHOULD include Source Address field and
   the Destination Address field.  The Sequence Number field MAY be
   elided.




Vilajosana & Pister       Expires June 1, 2017                  [Page 8]


Internet-Draft               6tisch-minimal                November 2016


   The PAN ID Compression bit SHOULD indicate that the Source PAN ID is
   "Not Present" and the Destination PAN ID is "Present".  The value of
   the PAN ID Compression bit is specified in Table 7-6 of the
   IEEE802.15.4 2015 specification, and depends on the type of the
   destination and source link-layer addresses (short, extended, not
   present).

   While listening for EBs, a joining node set its own PAN ID to 0xffff
   in order to meet the filtering rules in the IEEE802.15.4
   specification [IEEE802154-2015].

   The Nonce is formatted according to [IEEE802154-2015].  In the
   IEEE802.15.4 specification [IEEE802154-2015], nonce generation is
   described in Section 9.3.2.2, and byte ordering in Section 9.3.1,
   Annex B.2 and Annex B.2.2.

4.5.2.  Enhanced Beacon Frame

   The IEEE802.15.4 specification does not define how often EBs are
   sent, nor their contents [IEEE802154-2015].  In a minimal TSCH
   configuration, a node SHOULD send an EB every EB_PERIOD.  Tuning
   EB_PERIOD allows a trade-off between joining time and energy
   consumption.

   EBs SHOULD NOT be used for time synchronization.  Time
   synchronization SHOULD only be achieved through normal data traffic
   and keep-alive frames.  [RFC7554] further discusses different time
   synchronization approaches.

   EBs MUST be sent as per the IEEE802.15.4 specification and SHOULD
   carry the Information Elements (IEs) listed below [IEEE802154-2015].

   TSCH Synchronization IE:  Contains synchronization information such
      as ASN and Join Metric.  The value of the Join Metric field is
      discussed in Section 6.1.

   TSCH Timeslot IE:  Contains the timeslot template identifier.  This
      template is used to specify the internal timing of the timeslot.
      This specification RECOMMENDS the default timeslot template.

   Channel Hopping IE:  Contains the channel hopping sequence
      identifier.  This specification RECOMMENDS the default channel
      hopping sequence.

   TSCH SlotFrame and Link IE:  Enables joining nodes to learn the
      initial schedule to be used as they join the network.  This
      document RECOMMENDS the use of a single cell.




Vilajosana & Pister       Expires June 1, 2017                  [Page 9]


Internet-Draft               6tisch-minimal                November 2016


   If a node strictly follows the recommended setting from Figure 1, the
   EB it sends has the exact same contents as an EB it has received when
   joining, except for the Join Metric field in the TSCH Synchronization
   IE.

4.5.3.  Acknowledgment Frame

   Per [IEEE802154-2015], each acknowledgment contain an ACK/NACK Time
   Correction IE.

4.6.  Link-Layer Security

   All link-layer frames MUST be secured by the link-layer security
   mechanisms defined in IEEE802.15.4 [IEEE802154-2015]: link-layer
   authentication and link-layer encryption.  Link-layer authentication
   applies to the entire frame, including the IEEE802.15.4 header.
   Link-layer encryption applies only to IEEE802.15.4 payload IEs and
   the IEEE802.15.4 payload.

   This specification assumes the existence of two cryptographic keys.
   These keys can be pre-configured, or learned during a key
   distribution phase.  Key distribution is out of scope of this
   document.

   Key K1 is used to authenticate EBs.  As defined in Section 4.5.2, EBs
   MUST be authenticated only (no encryption).  This facilitates logical
   segregation of distinct networks.

   Key K2 is used to authenticate and encrypt DATA and ACKNOWLEDGMENT
   frames.  Depending on the security policy, K1 and K2 could be the
   same key.

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

5.  RPL Settings

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

5.1.  Objective Function

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







Vilajosana & Pister       Expires June 1, 2017                 [Page 10]


Internet-Draft               6tisch-minimal                November 2016


5.1.1.  Rank Computation

   The Rank computation is described at [RFC6552], Section 4.1.  A
   node's Rank (see Figure 4 for an example) is computed by the
   following equations:

      R(N) = R(P) + rank_increment

      rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease

   Figure 4 lists the OF0 parameter values that MUST be used if RPL is
   used.

       +----------------------+-------------------------------------+
       |    OF0 Parameters    |              Value                  |
       +----------------------+-------------------------------------+
       | Rf                   |                                   1 |
       +----------------------+-------------------------------------+
       | Sp                   |                           (3*ETX)-2 |
       +----------------------+-------------------------------------+
       | Sr                   |                                   0 |
       +----------------------+-------------------------------------+
       | MinHopRankIncrease   | DEFAULT_MIN_HOP_RANK_INCREASE (256) |
       +----------------------+-------------------------------------+
       | MINIMUM_STEP_OF_RANK |                                   1 |
       +----------------------+-------------------------------------+
       | MAXIMUM_STEP_OF_RANK |                                   9 |
       +----------------------+-------------------------------------+
       | ETX limit to select  |                                   3 |
       | a parent             |                                     |
       +----------------------+-------------------------------------+

                         Figure 4: OF0 parameters.

   The step_of_rank (Sp) uses Expected Transmission Count (ETX)
   [RFC6551].  ETX is computed using the reception/non-reception of
   link-layer ACKs.

   An implementation MUST follow OF0's normalization guidance as
   discussed in Section 1 and Section 4.1 of [RFC6552].  Sp SHOULD be
   calculated as (3*ETX)-2.  The minimum value of Sp
   (MINIMUM_STEP_OF_RANK) indicates a good quality link.  The maximum
   value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor quality link.
   The default value of Sp (DEFAULT_STEP_OF_RANK) indicates an average
   quality link.  Candidate parents with ETX greater than 3 SHOULD NOT
   be selected.  This avoids having ETX values on used links which are
   larger that the maximum allowed transmission attempts.




Vilajosana & Pister       Expires June 1, 2017                 [Page 11]


Internet-Draft               6tisch-minimal                November 2016


5.1.2.  Rank Computation Example

   This section illustrates the use of the Objective Function Zero (see
   Figure 5).  We have:

      rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512

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

   Figure 5: Rank computation example for 5-hop network where numTx=100
                      and numTxAck=75 for all links.







Vilajosana & Pister       Expires June 1, 2017                 [Page 12]


Internet-Draft               6tisch-minimal                November 2016


5.2.  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.  Nodes not supporting RPL MUST join as leaf nodes.

5.3.  Trickle Timer

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

5.4.  Packet Formats

   RPL information and hop-by-hop extension headers MUST follow
   [RFC6553] and [RFC6554] specification.  In the case the packets
   formed at the LLN need to cross through intermediate routers, these
   MUST follow the IP-in-IP encapsulation requirement specified by the
   [RFC6282] and [RFC2460].  Routing extension headers such as RPI
   [RFC6550] and SRH [RFC6554], and outer IP headers in case of
   encapsulation MUST be compressed according to
   [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch].

6.  Network Formation and Lifetime

6.1.  Value of the Join Metric Field

   The Join Metric of the TSCH Synchronization IE in the EB MUST be
   calculated based on the routing metric of the node, normalized to a
   value between 0 and 255.  A lower value of the Join Metric indicates
   the node sending the EB is topologically "closer" to the root of the
   network.  A lower value of the Join Metric hence indicates higher
   preference for a joining node to synchronize to that neighbor.  In
   case that the network uses RPL, the Join Metric of any node
   (including the DAG root) MUST be set to DAGRank(rank)-1.  According
   to Section 5.1.1, DAGRank(rank(0)) = 1.  DAGRank(rank(0))-1 = 0 is
   compliant IEEE802.15.4's requirement of having the root use Join
   Metric = 0.

6.2.  Initial Time Source Neighbor Selection

   When a node joins a network, it may hear EBs sent by different nodes
   already in the network.  The decision of which neighbor to
   synchronize to (e.g. which neighbor becomes the node's initial time
   source neighbor) is implementation-specific.




Vilajosana & Pister       Expires June 1, 2017                 [Page 13]


Internet-Draft               6tisch-minimal                November 2016


   For example, after having received the first EB, a node MAY listen
   for at most MAX_EB_DELAY seconds until it has received EBs from
   NUM_NEIGHBOURS_TO_WAIT distinct neighbors.  When receiving EBs from
   distinct neighbors, the node MAY use the Join Metric field in each EB
   to select the initial time source neighbor, as described in
   IEEE802.15.4 [IEEE802154-2015], Section 6.3.6.

6.3.  When to Start Sending EBs

   When a RPL node joins the network, it MUST NOT send EBs before having
   acquired a RPL Rank to avoid inconsistencies in the time
   synchronization structure.  This applies to other routing protocols
   with their corresponding routing metrics.  As soon as a node acquires
   routing information (e.g. a RPL Rank, see Section 5.1.1), it SHOULD
   start sending Enhanced Beacons.

6.4.  Time Source Neighbor Selection

   At any time, a node MUST maintain connectivity to at least one time
   source neighbor.  A node's time source neighbor MUST be chosen among
   the neighbors in its routing parent set.

6.5.  Hysteresis

   Per [RFC6552] and [RFC6719], the specification 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.  Per [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 deals
   with hysteresis both for 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.

7.  Implementation Recommendations








Vilajosana & Pister       Expires June 1, 2017                 [Page 14]


Internet-Draft               6tisch-minimal                November 2016


7.1.  Neighbor Table

   The exact format of the neighbor table is implementation-specific.
   The RECOMMENDED per-neighbor information is (taken from the [openwsn]
   implementation):

   identifier: Identifier(s) of the neighbor (e.g.  EUI-64).

   numTx:      Number of link-layer transmission attempts to that
               neighbor.

   numTxAck:   Number of transmitted link-layer frames that have been
               link-layer acknowledged by that neighbor.

   numRx:      Number of link-layer frames received from that neighbor.

   timestamp:  When the last frame was 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.

   time source neighbor:  A flag indicating whether this neighbor is a
               time source neighbor.

7.2.  Queues and Priorities

   The IEEE802.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).  The following rules are
   RECOMMENDED:

      A node is configured to keep in the queues a configurable number
      of Upper Layer packets per link (default NUM_UPPERLAYER_PACKETS)
      for a configurable time that should cover the join process
      (default MAX_JOIN_TIME).

      Frames generated by the IEEE802.15.4 layer (including EBs) are
      queued with a priority higher than frames coming from higher-
      layers.

      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.





Vilajosana & Pister       Expires June 1, 2017                 [Page 15]


Internet-Draft               6tisch-minimal                November 2016


7.3.  Recommended Settings

   Figure 6 lists RECOMMENDED values for the settings discussed in this
   specification.

           +-------------------------+-------------------+
           | Parameter               | RECOMMENDED Value |
           +-------------------------+-------------------+
           | MAX_EB_DELAY            |               180 |
           +-------------------------+-------------------+
           | NUM_NEIGHBOURS_TO_WAIT  |                 2 |
           +-------------------------+-------------------+
           | PARENT_SWITCH_THRESHOLD |               640 |
           +-------------------------+-------------------+
           | NUM_UPPERLAYER_PACKETS  |                 1 |
           +-------------------------+-------------------+
           | MAX_JOIN_TIME           |               300 |
           +-------------------------+-------------------+

                      Figure 6: Recommended Settings.

8.  IANA Considerations

   This document requests no immediate action by IANA.

9.  Acknowledgments

   The authors acknowledge the guidance and input from Rene Struik, Pat
   Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa
   Vucinic, and thank Charles Perkins and Suresh Krishnan for the
   exhaustive and detailed review.  Thanks to Simon Duquennoy, Guillaume
   Gaillard, Tengfei Chang and Jonathan Munoz for the detailed review of
   the examples section.  Thanks to 6TiSCH co-chairs Pascal Thubert and
   Thomas Watteyne for their guidance and advice.

10.  References

10.1.  Normative References

   [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. and R. Cragie, "6LoWPAN Paging Dispatch",
              draft-ietf-6lo-paging-dispatch-05 (work in progress),
              October 2016.



Vilajosana & Pister       Expires June 1, 2017                 [Page 16]


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

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

   [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 June 1, 2017                 [Page 17]


Internet-Draft               6tisch-minimal                November 2016


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

10.2.  Informative References

   [I-D.ietf-6tisch-6top-protocol]
              Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft-
              ietf-6tisch-6top-protocol-03 (work in progress), October
              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.

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

10.3.  External Informative References

   [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

   This section contains several example packets.  Each example contains
   (1) a schematic header diagram, (2) the corresponding bytestream, (3)
   a description of each of the IEs that form the packet.  Packet
   formats are specific for the [IEEE802154-2015] revision and may vary
   in future releases of the IEEE standard.  In case of differences
   between the packet content presented in this section and
   [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



Vilajosana & Pister       Expires June 1, 2017                 [Page 18]


Internet-Draft               6tisch-minimal                November 2016


   transmitted, from left to right, where the leftmost bit is
   transmitted first.  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 (little endian).

A.1.  Example: EB with Default Timeslot Template

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

   Bytestream:

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

       #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




Vilajosana & Pister       Expires June 1, 2017                 [Page 19]


Internet-Draft               6tisch-minimal                November 2016


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

A.2.  Example: EB with Custom Timeslot Template

   Using a custom timeslot template in EBs: setting timeslot length to
   15ms.

                     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



Vilajosana & Pister       Expires June 1, 2017                 [Page 20]


Internet-Draft               6tisch-minimal                November 2016


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

   Bytestream:

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

       #Header IE Header
           Len1 = Header IE Length (none)
           Element ID = 0x7e - termination IE indicating Payload IE
               coming next
           Type 0

       #Payload IE Header (MLME)
           Len2 = Payload IE Len (53 Bytes)
           GroupID = 1 MLME (Nested)
           Type = 1

       #MLME-SubIE TSCH Synchronization
           Len3 = Length in bytes of the sub-IE payload (6 Bytes)
           SubID = 0x1a (MLME-SubIE TSCH Synchronization)
           Type = Short (0)
           ASN  = Absolute Sequence Number (5 Bytes)
           Join 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)

           The 15ms timeslot announced:
           +--------------------------------+------------+



Vilajosana & Pister       Expires June 1, 2017                 [Page 21]


Internet-Draft               6tisch-minimal                November 2016


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

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

A.3.  Example: Link-layer Acknowledgment

   Enhanced Acknowledgment packets carry the Time Correction IE (Header
   IE).














Vilajosana & Pister       Expires June 1, 2017                 [Page 22]


Internet-Draft               6tisch-minimal                November 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 =   2  |Element ID=0x1e|0|        Time Sync Info         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bytestream:

       02 0F TS#0 TS#1

   Description of the IEs:

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

A.4.  Example: Auxiliary Security Header

   IEEE802.15.4 Auxiliary Security Header with security Level set to
   ENC-MIC-32.

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

   Bytestream:

       6D IDX#0

   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)







Vilajosana & Pister       Expires June 1, 2017                 [Page 23]


Internet-Draft               6tisch-minimal                November 2016


Authors' Addresses

   Xavier Vilajosana (editor)
   Universitat Oberta de Catalunya
   156 Rambla Poblenou
   Barcelona, Catalonia  08018
   Spain

   Email: xvilajosana@uoc.edu


   Kris Pister
   University of California Berkeley
   512 Cory Hall
   Berkeley, California  94720
   USA

   Email: pister@eecs.berkeley.edu

































Vilajosana & Pister       Expires June 1, 2017                 [Page 24]


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