Skip to main content

6tus Adaptation Layer Specification
draft-wang-6tsch-6tus-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Qin Wang , Xavier Vilajosana , Thomas Watteyne
Last updated 2013-03-11
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-6tsch-6tus-00
6TSCH                                                       Q. Wang, Ed.
Internet-Draft                           Univ. of Sci. and Tech. Beijing
Intended status: Informational                             X. Vilajosana
Expires: September 12, 2013              Universitat Oberta de Catalunya
                                                             T. Watteyne
                                                       Linear Technology
                                                          March 11, 2013

                  6tus Adaptation Layer Specification
                        draft-wang-6tsch-6tus-00

Abstract

   The recently published [IEEE802154e] standard formalizes the concept
   of link-layer resources in LLNs.  Nodes are synchronized and follow a
   schedule.  A time slot in that schedule corresponds to an atomic
   link-layer resource, and can be allocated to any pair of neighbors in
   the network.  This allows the schedule to be built to tightly match
   each node's bandwidth, latency and energy constraints, while ensuring
   collision-free communication.  The [IEEE802154e] standard does not,
   however, present a mechanism to do so, as building and managing the
   schedule is out of the standard's scope.  Routing layers such as the
   IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to
   route multipoint-to-point traffic (from devices inside the LLN
   towards a central control point) and point-to-multipoint traffic
   (from the central control point to the devices inside the LLN).
   Network layer overlays cannot be optimized and adapted to take
   advantage of the link-based topology created by the underlying TSCH
   MAC layer as a missing set of functionalities need to be defined.
   This document describes the 6tus adaptation layer and the main
   commands it provides to upper network layers such as RPL or GMPLS.
   The set of functionalities includes feedback metrics from link states
   so network layers can take routing decisions, TSCH configuration and
   control procedures, and the support for centralized and decentralized
   scheduling policies.

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

Wang, et al.           Expires September 12, 2013               [Page 1]
Internet-Draft                 6tsch-6tus                     March 2013

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2013.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  6tus Adaptation Layer Specification . . . . . . . . . . . . .   4
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Link Model  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Hard Links  . . . . . . . . . . . . . . . . . . . . .   6
       2.2.2.  Soft Links  . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Data Convey Model . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Commands  . . . . . . . . . . . . . . . . . . . . . . . .   8
       2.4.1.  Link Commands . . . . . . . . . . . . . . . . . . . .   8
       2.4.2.  Slotframe Commands  . . . . . . . . . . . . . . . . .  13
       2.4.3.  Monitoring Commands . . . . . . . . . . . . . . . . .  14
       2.4.4.  Statistics Commands . . . . . . . . . . . . . . . . .  16
       2.4.5.  Network Formation Commands  . . . . . . . . . . . . .  18
       2.4.6.  Time Source Neighbor Commands . . . . . . . . . . . .  20
       2.4.7.  Neighbor Commands . . . . . . . . . . . . . . . . . .  21
       2.4.8.  Queueing Commands . . . . . . . . . . . . . . . . . .  23
       2.4.9.  Security Commands . . . . . . . . . . . . . . . . . .  26
       2.4.10. Data Commands . . . . . . . . . . . . . . . . . . . .  27
     2.5.  Message Formats . . . . . . . . . . . . . . . . . . . . .  29
       2.5.1.  Information Elements  . . . . . . . . . . . . . . . .  29
       2.5.2.  Packet Formats  . . . . . . . . . . . . . . . . . . .  37
     2.6.  Time Sequence . . . . . . . . . . . . . . . . . . . . . .  40
       2.6.1.  Network Formation . . . . . . . . . . . . . . . . . .  40
       2.6.2.  Creating a Soft Link  . . . . . . . . . . . . . . . .  41

Wang, et al.           Expires September 12, 2013               [Page 2]
Internet-Draft                 6tsch-6tus                     March 2013

       2.6.3.  Deleting a Soft Link  . . . . . . . . . . . . . . . .  42
       2.6.4.  Maintaining Soft Links  . . . . . . . . . . . . . . .  42
     2.7.  Statistics  . . . . . . . . . . . . . . . . . . . . . . .  43
       2.7.1.  Statistics Metrics  . . . . . . . . . . . . . . . . .  43
       2.7.2.  Statistics Configuration  . . . . . . . . . . . . . .  44
     2.8.  Monitoring  . . . . . . . . . . . . . . . . . . . . . . .  44
       2.8.1.  Monitor Configuration . . . . . . . . . . . . . . . .  44
       2.8.2.  Actuation . . . . . . . . . . . . . . . . . . . . . .  44
   3.  Using 6tus  . . . . . . . . . . . . . . . . . . . . . . . . .  45
     3.1.  RPL on 6tus . . . . . . . . . . . . . . . . . . . . . . .  45
       3.1.1.  Support to Neighbor Discovery and Parent Selection  .  45
       3.1.2.  Support to Rank Computation . . . . . . . . . . . . .  46
       3.1.3.  Support to Control Messages Broadcast . . . . . . . .  46
       3.1.4.  Support to QoS  . . . . . . . . . . . . . . . . . . .  47
     3.2.  GMPLS on 6tus . . . . . . . . . . . . . . . . . . . . . .  48
       3.2.1.  Link Reservation Support for GMPLS on 6tus  . . . . .  49
       3.2.2.  Supporting QoS  . . . . . . . . . . . . . . . . . . .  49
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  49
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .  50
     4.2.  Informative References  . . . . . . . . . . . . . . . . .  50
     4.3.  External Informative References . . . . . . . . . . . . .  53
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  53

1.  Introduction

   As presented in [I-D.watteyne-6tsch-tsch-lln-context], the
   [IEEE802154e] standard defines the mechanisms for a TSCH node to
   communicate given a schedule.  It does not, however, define the
   policies to build and maintain the TSCH schedule, match that schedule
   to the multi-hop paths maintained by a network layer such as RPL or a
   2.5 layer such as GMPLS, adapt the resources allocated between
   neighbor nodes to the data traffic flows, enforce a differentiated
   treatment for data generated at the application layer and signaling
   messages needed by 6LoWPAN and RPL to discover neighbors, react to
   topology changes, self-configure IP addresses, or manage keying
   material.

   In a TSCH network, the MAC layer is not in charge of setting up the
   schedule that controls the connectivity graph of the network and the
   resources allocated to each link in that topology.  This
   responsibility is left to an upper layer, defined in this document
   and called "6tus" (pronounced "sixtus").

   This document describes the 6tus adaptation layer and the main
   commands provided to upper network layers such as RPL or GMPLS.  The
   set of functionalities include feedback metrics from link state so
   the network layer can take routing decisions, TSCH configuration and
   control procedures and support centralized and decentralized

Wang, et al.           Expires September 12, 2013               [Page 3]
Internet-Draft                 6tsch-6tus                     March 2013

   scheduling policies.  The 6tus layer addresses the set of
   functionalities described in [I-D.watteyne-6tsch-tsch-lln-context].

   For example, network formation in a TSCH network is handled by the
   use of Enhanced Beacons (EB).  EBs include information for joining
   nodes to be able to synchronize and set up an initial network
   topology, however [IEEE802154e] does not specify how the period of
   EBs is configured, nor the rules for a node to select a particular
   node to join.  The 6tus layer offers a set of commands so control
   mechanisms can be introduced on top of TSCH so nodes configure to
   join a specific node and obtain an unique 16-bit identifier from the
   network.  Once a network is formed, 6tus maintains the network's
   health, allowing for nodes to stay synchronized.  It supplies
   mechanisms to manage each node's time source neighbor and configure
   the EB interval.  Network layers running on top of 6tus take
   advantage of the TSCH MAC layer information so routing metrics,
   topological information, energy consumption and latency requirements
   can be adjusted to TSCH and adapted to application requirements.

   TSCH requires a mechanism to manage its schedule; 6tus provides a set
   of commands for upper layers to set up specific schedules, either
   explicitly by detailing specific link information, or by allowing
   6tus to establish a schedule given a bandwidth or latency
   requirement.  6tus is designed to enable centralized, decentralized
   or hybrid scheduling entities.  6tus enables internal TSCH queuing
   configuration, size of buffers, packet priorities, and transmission
   failure behavior, and defines mechanisms to encrypt and authenticate
   MAC slotframes.

2.  6tus Adaptation Layer Specification

2.1.  Overview

   6tus is an adaptation layer which is the next-higher layer for TSCH,
   as detailed in [I-D.draft-thubert-6tsch-architecture].  6tus offers
   both management and data interfaces to an upper layer.  It includes
   monitoring and statistics collection, both of which are configurable
   through the management interface.

   6tus distinguishes between hard links and soft links.  It therefore
   requires an extra flag to all links in the TSCH schedule, as detailed
   in Section 2.2.

   When a higher layer gives 6tus a 6LoWPAN packet for transmission,
   6tus maps it to the appropriate outgoing priority-based queue, as
   detailed in Section 2.3.

Wang, et al.           Expires September 12, 2013               [Page 4]
Internet-Draft                 6tsch-6tus                     March 2013

   All commands of the management and data interfaces are detailed in
   Section 2.4.  This set of commands is designed to support
   centralized, decentralized and hybrid scheduling entities.

   6tus defines TSCH Information Elements (IEs) for neighbors nodes to
   negociate scheduling links in the TSCH schedule.  The format of those
   is given in Section 2.5.

   Example data exchanges between neighbor nodes are illustrated in
   Section 2.6.

   Section 2.7 defines how 6tus gathers statistics (e.g.  link quality,
   energy level, queue usage), and what commands an upper layer can use
   to configure and retrieve statistics.

   6tus can be configured to monitor some links it has scheduled to
   detect links with poor performance.  It can then automatically move
   those links inside the TSCH schedule.  This behavior is described in
   Section 2.8

2.2.  Link Model

   IEEE802.15.4e defines a set of options attached to each link.  A link
   can be a Transmit Link, a Receive Link, a Shared Link or a
   Timekeeping Link.  These options are not exclusive, as a link can be
   qualified with more than one of them.  The IEEE802.15.4e MLME-SET-
   LINK.request command uses a linkOptions bitmap to specify the options
   of a link.  Acceptable values are:

      b0 = Transmit

      b1 = Receive

      b2 = Shared

      b3 = Timekeeping

      b4-b7 = Reserved

   Only Transmit links can also be marked as Shared links.  When the
   shared bit is set, and a back-off procedure is applied to handle
   collisions.  Shared behavior is not defined for Receive links.

   6tus allows an upper layer to schedule a link at a specific timeslot
   and channel offset in a specific slotframe.  This translates directly
   into the MLME-SET-LINK.request primitive described at
   Section 6.2.19.3 of IEEE802.15.4e.  In addition, 6tus allows an upper
   layer to schedule a certain amount of bandwidth to a neighbor,

Wang, et al.           Expires September 12, 2013               [Page 5]
Internet-Draft                 6tsch-6tus                     March 2013

   without having to specify the exact timeslot(s) and channel
   offset(s).  Instead, 6tus follows the reservation process described
   in Section 2.6.2.  Once bandwidth is reserved, 6tus is in charge of
   ensuring that this requirement is continuously satisfied, as
   described in Section 2.8.  6tus dynamically reallocates slots if
   needed, and overprovisions if required.  Given this mechanism, 6tus
   defines hard links (which have been requested specifically) and soft
   links (which that can be reallocated dynamically).  The hard/soft
   flag is introduced by the 6tus layer as an extension of the
   IEEE802.15.4e Link Option flags.  This option is mandatory; all links
   are either hard or soft.

   With the addition of the Hard/Soft flag, the resulting flags are:

      b0 = Transmit

      b1 = Receive

      b2 = Shared

      b3 = Timekeeping

      b4 = Hard (1)/Soft (0)

      b5-b7 = Reserved

2.2.1.  Hard Links

   A Hard Link is a link that cannot be dynamically reallocated by 6tus.
   A Hard link is uniquely identified by the following tuple:

      slotframe id: id of the slotframe this link is part of.

      timeslot: the slot within the slotframe.

      channel offset.

      Link Option bitmap: bitmap as defined in Section 2.2, including
      the hard/soft bit which must be set to 1.

2.2.2.  Soft Links

   A Soft Link is a link that can be reallocated by 6tus dynamically.
   The hard/soft bit must be set to 0.  This link is installed by 6tus
   given a specific bandwidth requirement.  Soft links are installed
   through the soft link negotiation process described in Section 2.8.

Wang, et al.           Expires September 12, 2013               [Page 6]
Internet-Draft                 6tsch-6tus                     March 2013

2.3.  Data Convey Model

   Based on the established TSCH schedule, 6tus is responsible for
   feeding the data flow from the upper layer into TSCH.  This section
   describes how 6tus shapes data from upper layer (e.g.  RPL, 6LoWPAN),
   and feeds it to TSCH.  Since 6tus is a adaptation layer between TSCH
   and 6LoWPAN, the properties assciated with a packet/fragment from the
   upper layer includes the next hop neighbor (DestAddr) and expected
   sending priority of the packet (Priority).  The output to TSCH is the
   fragment corresponding to the next active link in the TSCH schedule.

   6tus Data Convey Model

                       |
                       | (DestAddr, Priority, Fragment)
                       |
   +---------------------------------------+
   |                 I-MUX                 |
   +---------------------------------------+
     |       |       |       |    ....   |
     |       |       |       |           |
   +---+   +---+   +---+   +---+       +---+
   |   |   |   |   |   |   |   |       |   |
   |Q1 |   |Q2 |   |Q3 |   |Q4 |       |Qn |
   |   |   |   |   |   |   |   |       |   |
   +---+   +---+   +---+   +---+       +---+
     |       |       |       |           |
     |       |       |       |           |
   +---------------------------------------+
   |                 MUX                   |
   +---------------------------------------+
                      |
                      |
                    +---+
                    |PDU|
                    +---+
                      |
                      | TSCH MAC-payload
                      |

                                 Figure 1

   In Figure 1, Qi represents a queue, which is either broadcast or
   unicast, and is assigned a priority.  The number of queues is
   configurable.  The relationship between queues and slotframes is
   configurable.  For example, for a given queue, only one specific
   slotframe can be used, or all of the slotframes can be used, or a
   subset of slotframes can be used.

Wang, et al.           Expires September 12, 2013               [Page 7]
Internet-Draft                 6tsch-6tus                     March 2013

   When 6tus receives a packet to transmit through a Send.data command
   (Section 2.4.10), the I-MUX module selects a queue in which to insert
   it.  If the packet's destination address is a unicast (resp.
   broadcast) address, it will be inserted into a unicast (resp.
   broadcast) queue.

   The MUX module is invoked at each scheduled transmit link by TSCH.
   When invoked, the MUX module goes through the queues, looking for the
   best frame to send.  If it finds a frame, it hands it over to TSCH
   for transmission.  If the next active link is a broadcast link, it
   selects a fragment only from broadcast queues.

   How the MUX module selects the best frame is configurable.
   Typically, the following rules are used:

      The frame's layer 2 destination address must match the neighbor
      address associated with the transmit link.

      Frames from a queue with a high priority must be sent before
      frames from a queue with a low priority.

   Further rules can be configured to satisfy specific QoS requirements.

2.4.  Commands

   6tus provides a set of commands a higher layer can call, including
   management commands and data commands.  Most of these commands are
   related to the management of slotframes, time slots and scheduling
   information.  6tus also provides an interface allowing an upper layer
   to retrieve status information and statistics.  This section lists
   the commands offered by 6tus.

2.4.1.  Link Commands

   The following methods allow an upper layer to manage the network
   schedule:

2.4.1.1.  CREATE.hardlink

   Creates one or more hard links in the schedule.  Fails if the link
   already exists.  A link is uniquely identified by the tuple
   (slotframe id, timeslot, channel offset).

   To create a hard link, the upper layer specifies:

      slotframe id: id of the slotframe this slot will be scheduled in.

      time slot: the specific time slot number.

Wang, et al.           Expires September 12, 2013               [Page 8]
Internet-Draft                 6tsch-6tus                     March 2013

      channel offset: the frequency offset.

      Link Option bitmap: bitmap as defined in Section 2.2

      target node address: the address of that node to communicate with
      over this link.  In case of broadcast links this is the broadcast
      address.

   6tus schedules the link and marks it as a hard link, indicating that
   it cannot reschedule this link.

2.4.1.2.  CREATE.softlink

   To create a soft link, the upper layer specifies:

      slotframe id: id of the slotframe this slot will be scheduled in

      number of links: the required number of soft links.

      Link Option bitmap: bitmap as defined in Section 2.2

      target node address: the address of that node to communicate with
      over this link.  In case of broadcast links this is the broadcast
      address.

      QoS level: the link redundancy policy.  The policy can be for
      example STRICT, BEST_EFFORT, etc.

   6tus is responsible for picking the exact timeslot and channel offset
   in the schedule, and ensure that the target node chooses the same.
   6tus marks these links as soft link, indicating that it will
   continuously monitor their performance and reschedule if needed.

   6tus deals with the allocation process by negotiation with the target
   node.  The negotiation process is described in Section 2.6.2.  The
   command returns the list of created links defined by (slotframe id,
   time slot number, channel offset).  It fails if the required number
   of links is higher than the available number of links in the
   schedule.  It fails if the negotiation with the target node fails.
   It fails if the Link Option bitmap indicates that the link MUST be
   Hard.

2.4.1.3.  READ.link

   Given a (slotframe id, time slot number, channel offset), retrieves
   the link information.  Fails if the link does not exist.  The
   returned information contains:

Wang, et al.           Expires September 12, 2013               [Page 9]
Internet-Draft                 6tsch-6tus                     March 2013

      slotframe id: the id of the slotframe where this link is
      installed.

      time slot: the time slot where the link is set.

      channel offset: the selected channel offset for the link.

      Link Option bitmap: bitmap as defined in Section 2.2

      target node address: the target address of that link.  In case of
      broadcast links this is the broadcast address.

   A read command can be issued for any link, hard or soft.

2.4.1.4.  UPDATE.link

   Update a hard link, i.e.  move it to a different timeslot and/or
   channel offset.  Fails if the link does not exist.  Requires a
   (slotframe id, time slot, channel offset), type of link and target
   node are the fields that can be updated.  Soft links cannot be
   updated by the UPDATE.link command.  REALLOCATE.softlink
   (Section 2.4.1.7) MUST be used instead.

2.4.1.5.  DELETE.hardlink

   To removes a hard link, the upper layer specifies:

      slotframe id: the id of the slotframe where this link is
      installed.

      time slot: the time slot where the link is set.

      channel offset: the selected channel offset for the link.

   This removes the hard link from the node's schedule.

2.4.1.6.  DELETE.softlink

   To remove a (number of) soft link(s), the upper layer specifies:

      slotframe id: the id of the slotframe where this link is
      installed.

      number of links: the number of links to be removed

      Link Option bitmap: bitmap as defined in Section 2.2

Wang, et al.           Expires September 12, 2013              [Page 10]
Internet-Draft                 6tsch-6tus                     March 2013

      target node address: the target address of that link.  In case of
      broadcast links this is the broadcast address.

   In the case a soft link wants to be moved from the allocated slot so
   a hard link can be installed instead, the REALLOCATE.softlink
   (Section 2.4.1.7) MUST be used.

2.4.1.7.  REALLOCATE.softlink

   To force a move of a soft link, the upper layer specifies:

      slotframe id: the id of the slotframe where the link is allocated.

      time slot: the slot number where that link is installed.

      channel offset: the channel offset for that link.

   The reallocated link will be installed in a different slot, channel
   offset but same slotframe.  Hard links cannot be reallocated.

2.4.1.8.  HardLink Command Behavior

   The following table describe the behavior of 6tus upon reception of
   the Hard Link management commands.

   Hard Link Operations behavior

Wang, et al.           Expires September 12, 2013              [Page 11]
Internet-Draft                 6tsch-6tus                     March 2013

   +---------------------------------+---------------------------------+
   |        6tus commands            |          6tus behavior          |
   +---------------------------------+---------------------------------+
   | Create.hardlink                 | MLME-SET-LINK.request           |
   | (NeigAddr, SlotframeID,         |  (operation=ADD_LINK)           |
   | SlotOffset,                     | If  NeigAddr ==Broadcast Address|
   | ChannelOffset, LinkOption)      | Then LinkType=ADVERTISING       |
   |                                 | Add Link to EB's FrameAndLinkIE |
   +---------------------------------+---------------------------------+
   | Read.Link                       | MLME-GET.request                |
   |(NeigAddr,SlotframeID,SlotOffset,|                                 |
   | ChannelOffset, LinkOption)      |                                 |
   +---------------------------------+---------------------------------+
   | Delete.hardlink                 | MLME-SET-LINK.request           |
   | (NeigAddr ,SlotOffset,          | (operation=DELETE_LINK)         |
   | ChannelOffset, LinkOption)      | If LinkType=ADVERTISING, it is a|
   |                                 | broadcast link, Then Remove link|
   |                                 | from EB's FrameAndLinkIE of EB  |
   +---------------------------------+---------------------------------+
   | Update.Link                     | MLME-SET-LINK.request           |
   | (OldFrameID, OldSlotOffset,     | (operation=DELETE_LINK)         |
   |  OldChannelOffset, NewFrameID,  | MLME-SET-LINK.request           |
   |  NewSlotOffset,NewChannelOffset)| (operation=ADD_LINK,            |
   |                                 |  with same NeigAddr,LinkOption) |
   |                                 | If old Link is in EB            |
   |                                 | Then modify EB                  |
   +---------------------------------+---------------------------------+

2.4.1.9.  SoftLink Command Behavior

   The following table describe the behavior of 6tus upon reception of
   the SoftLink management commands.

   Soft Link Operations behavior

Wang, et al.           Expires September 12, 2013              [Page 12]
Internet-Draft                 6tsch-6tus                     March 2013

   +--------------------------------+----------------------------------+
   |         6tus commands          |                 6tus behavior    |
   +--------------------------------+----------------------------------+
   | Create.softlink                | 6tus_ReserveLinkReq() ---- ACK   |
   |(NeigAddr, NumLink,LinkOption,  |    ACK --- 6tus_ReserveLinkResp()|
   | SlotframeID, QoSLevel)         |                                  |
   +--------------------------------+----------------------------------+
   | Read.Link                      | MLME-GET.request                 |
   |(NeigAddr,SlotframeID,          |                                  |
   | SlotOffset,ChannelOffset)      |                                  |
   +--------------------------------+----------------------------------+
   | Delete.softlink                | 6tus_RemoveLinkReq() --- ACK     |
   | (NeigAddr ,NumLink,            | If LinkType =ADVERTISING         |
   | LinkOption, SlotframeID)       | i.e. a broadcast link Then Remove|
   |                                | link from EB's FrameAndLinkIE    |
   +--------------------------------+----------------------------------+
   | Reallocate.softLink            | 6tus_RemoveLinkReq() --- ACK     |
   |(NeigAddr,SlotframeID,          | 6tus_ReserveLinkReq() --- ACK    |
   | SlotOffset,ChannelOffset)      | ACK --- 6tus_ReserveLinkResp()   |
   +--------------------------------+----------------------------------+

2.4.2.  Slotframe Commands

   6tus provides the following commands to manage TSCH slotframes.

2.4.2.1.  CREATE.slotframe

   Creates a new slotframe.  Returns the slotframe id that corresponds
   to its priority (SlotFrameHandle).  The command requires:

      number of slots: the required number of slots.

   Fails if the number of required slots is less than zero.

2.4.2.2.  READ.slotframe

   Returns the information of a slotframe given its slotframe id.  The
   command returns:

      slotframe id: the id of the slotframe.  (SlotFrameHandle)

      number of slots: the number of slots.

   Fails if the slotframe id does not exist.

2.4.2.3.  UPDATE.slotframe

Wang, et al.           Expires September 12, 2013              [Page 13]
Internet-Draft                 6tsch-6tus                     March 2013

   Change the number of slots in a slotframe.  The command requires:

      slotframe id: the id of the slotframe.

      number of slots: the number of slots to be updated.

   Fails if the number of required slots is less than zero.  Fails if
   the slotframe id does not exist.

2.4.2.4.  DELETE.slotframe

   Deletes a slotframe.  The command requires:

      slotframe id: the id of the slotframe.

   Fails if the slotframe id does not exist.

2.4.2.5.  Slotframe Command Behavior

   The following table describes the behavior of 6tus upon reception of
   the Slotframe management commands.

   Slotframe Management Operations behavior

   +--------------------------------+----------------------------------+
   |            6tus commands       |             6tus behavior        |
   +--------------------------------+----------------------------------+
   | Create.slotframe(NumSlot)      | MLME-SET-SLOTFRAME.request       |
   |                                |(operation=ADD)                   |
   +--------------------------------+----------------------------------+
   | Read.slotframe(SlotframeID)    | MLME-GET.request                 |
   +--------------------------------+----------------------------------+
   | Delete.slotframe(SlotframeID)  | MLME-SET-SLOTFRAME.request       |
   |                                |(operation=DELETE)                |
   +--------------------------------|----------------------------------+
   | Update.slotframe(SlotframeID   | MLME-SET-SLOTFRAME.request       |
   |  ,NumSlot)                     |(operation=MODIFY)                |
   +--------------------------------+----------------------------------+

2.4.3.  Monitoring Commands

   Monitoring commands provide the means for upper layers to configure
   whether 6tus must ensure the required bandwidth.  This procedure is
   achieved through over-provisioning according to link status feedback.
   Monitoring is also in charge of reallocating soft links that are
   under the required QoS.  The mechanism is described in Section 2.8.

Wang, et al.           Expires September 12, 2013              [Page 14]
Internet-Draft                 6tsch-6tus                     March 2013

2.4.3.1.  CONFIGURE.monitoring

   Configures the level of QoS the Monitoring process must enforce.  The
   command requires:

      slotframe id: the id of the slotframe.

      target node: the destination node.

      enforce policy: The policy used to enforce the QoS requirements.
      Can be for example DISABLE, BEST_EFFORT, STRICT, OVER-PROVISION,
      etc.

   Fails if the slotframe id does not exist.

2.4.3.2.  READ.monitoring.status

   Reads the current Monitoring status.  Requires the following
   parameters.

      slotframe id: the id of the slotframe.

      target node: the destination node.

   Returns the QoS levels for that Target node on that slotframe.

      allocated_hard: Number of hard links allocated.

      allocated_soft: Number of soft links allocated.

      provisioned: the extra provisioned links.  0 if CONFIGURE.qos
      enforce is DISABLE.

      QoS: the current QoS.  Including overprovisioned links, i.e what
      bandwidth is being obtained including the overprovisioned links.

      RQoS: the real QoS without provisioned links.  What is the actual
      bandwidth without taking into account the overprovisioned links.

   Fails if the slotframe id does not exist.

2.4.3.3.  Monitoring Command Behavior

   The following table describes the behavior of 6tus upon reception of
   the Monitoring management commands.

   Monitoring Management Operations behavior

Wang, et al.           Expires September 12, 2013              [Page 15]
Internet-Draft                 6tsch-6tus                     March 2013

   +------------------------------------+------------------------------+
   |            6tus commands           |             6tus behavior    |
   +------------------------------------+------------------------------+
   | Configure.monitoring(NeigAdd,      | Create/Update Monitoring MIB |
   | SlotframeID,Enforce)               | Starts monitoring service    |
   +------------------------------------+------------------------------+
   | Read.monitoring.status(SlotframeID)| Reads 6tus Monitoring MIB    |
   +------------------------------------+------------------------------+

                                 Figure 2

2.4.4.  Statistics Commands

   6tus keeps track of TSCH statistics for upper layers to adapt
   correctly to medium changes.  The exact metrics for statistics are
   out of the scope of this document but the present commands should be
   used to configure and read monitored information regardless of the
   specific metric.

2.4.4.1.  CONFIGURE.statistics

   Configures Statistics process.  The command requires:

      slotframe id: the id of the slotframe.  If empty monitors all
      slotframe ids

      time slot: slot number to be monitored.  If empty all slots are
      monitored

      channel offset: specific channel offset to be monitored.  If empty
      all channels are monitored.

      target node: the destination node.  If empty, all target nodes are
      monitored.

      metric: metric to be monitored.  This may be PDR, ETX, queuing
      statistics, energy-related metrics, etc.)

      window: time window to be considered for the calculations.  If 0
      all historical data is considered.

      enable: Enables statistics or disables them.

   Fails if the slotframe id does not exist.  The statistics service can
   be configured to retrieve statistics at different levels.  For
   example to aggregate information by slotframe id, or to retrieve
   statistics for a particular slot, etc.  the CONFIGURE.statistics
   enables flexible configuration by supporting empty parameters that

Wang, et al.           Expires September 12, 2013              [Page 16]
Internet-Draft                 6tsch-6tus                     March 2013

   will force the monitoring of the statistics by all members of that
   dimension.

2.4.4.2.  READ.statistics

   Reads a metric for the specified dimension.  Information is
   aggregated according to the parameters.  The command requires:

      slotframe id: the id of the slotframe.  If empty aggregates
      information of all slotframe ids

      time slot: the slot number for which the information is required.
      If empty all slots are aggregated

      channel offset: the specific channel offset for which the
      information is required.  If empty all channels are aggregated.

      target node: the destination node.  If empty all target nodes are
      aggregated.

      metric: metric to be read.

   Returns the value for the requested metric.

   Fails if empty metric or metric does not exits.

2.4.4.3.  RESET.statistics

   Resets the gathered statistics.  The command requires:

      slotframe id: the id of the slotframe.  If empty resets the
      information of all slotframe ids

      time slot: the slot number for which the information wants to be
      reset.  If empty statistics from all slots are reset

      channel offset: the specific channel offset for which the
      information wants to be reset.  If empty all statistics for all
      channels are reset.

      target node: the destination node.  If empty all statistics for
      the target node are reset.

      metric: metric to be reset.

   Fails if empty metric or metric does not exits.

Wang, et al.           Expires September 12, 2013              [Page 17]
Internet-Draft                 6tsch-6tus                     March 2013

2.4.4.4.  Statistics Command Behavior

   The following table describes the behavior of 6tus upon reception of
   the Statistics management commands.

   Statistics Management Operations behavior

   +--------------------------------+----------------------------------+
   |            6tus commands       |             6tus behavior        |
   +--------------------------------+----------------------------------+
   | Configure.statistics           |                                  |
   | (SlotFrameID,TSlot, ChannelOff,| Configures Statistics MIB.       |
   | NeigAdd,Metric,Window,En)      | Enables statistics service       |
   +--------------------------------+----------------------------------+
   | Read.statistics(SlotFrameID)   | Returns the statistic MIB for the|
   | Ch.Off,NeigAdd,Metric)         | requested parameters             |
   +--------------------------------+----------------------------------+
   | Reset.statistics(SlotFrameID)  | Resets the required statistic MIB|
   | Ch.Off,NeigAdd,Metric)         |                                  |
   +--------------------------------+----------------------------------+

2.4.5.  Network Formation Commands

   EBs need to be configured, including their transmission period, the
   slot number and channel offset that they should be sent on, and the
   priority announced.  The parameters for that command are optional and
   enable a very flexible configuration of EBs.  If slotframe id is
   specified, the EBs will be configured to use that specific slotframe;
   if not they will use the first slotframe where the configured time
   slot is allocated.  Time slot enforces the EB to a specific time
   slot.  In case time slot parameter is not present, the EB is sent in
   the first available transmit time slot.  In case channel offset
   parameter is not set, the EB is configured to use the first available
   channel.

2.4.5.1.  CONFIGURE.eb

   Configures EBs.  The command requires:

      slotframe id: the id of the slotframe where the EBs MUST be sent.
      Zero if any slotframe can be used.

      time slot: the slot number where the EBs MUST be sent.  Zero if
      any timeslot can be used.

      channel offset: the channel offset where the EBs MUST be sent.
      Zero if any channel offset can be used.

Wang, et al.           Expires September 12, 2013              [Page 18]
Internet-Draft                 6tsch-6tus                     March 2013

      period: the EBs period, in seconds.

      expires: when the EBs periodicity will stop.  If Zero the period
      never stops.

      priority: the joining priority model that will be used for
      advertisement.  Joining priority MAY be for example
      SAME_AS_PARENT, RANDOM, BEST_PARENT+1.

   Fails if the tuple slotframe id, timeslot, channel offset is already
   scheduled.

2.4.5.2.  READ.eb

   Reads the EBs configuration.  No parameters are required.

   Returns the current EBs configuraton for that slotframe, which
   contains:

      slotframe id: the slotframe where the EB is being sent.

      time slot: the slot number where the EBs is being sent.

      channel offset: the channel offset the EBs is being sent on.

      period: the EBs period.

      expires: when the EBs periodicity stops.  If 0 the period never
      stops.

      priority: the joining priority that this node advertises.

   Fails if the slotframe id does not exist.

2.4.5.3.  Network Formation Command Behavior

   The following table describes the behavior of 6tus upon reception of
   the Network Configuration management commands.

   Network Configuration Management Operations behavior

Wang, et al.           Expires September 12, 2013              [Page 19]
Internet-Draft                 6tsch-6tus                     March 2013

   +----------------------------------+--------------------------------+
   |            6tus commands         |             6tus behavior      |
   +----------------------------------+--------------------------------+
   | Configure.EB(SlotFrameID,TSlot,  | Configures the 6tus MIB        |
   | Ch.Off,Period,Expires,Prio,Con_p)| regarding EB configuration     |
   +----------------------------------+--------------------------------+
   | Read.EB()                        | Reads 6tus EB MIB              |
   |                                  |                                |
   +----------------------------------+--------------------------------+

2.4.6.  Time Source Neighbor Commands

   Commands to select time source neighbors.

2.4.6.1.  CONFIGURE.timesource

   Configures the Time Source Neighbor selection process.  More than one
   time source neighbor can be selected.  The command requires:

      selection policy: The policy used to select the time parent.  The
      policy MAY be for example ALL_PARENTS, BEST_CONNECTED,
      LOWEST_JOIN_PRIORITY, etc.

   Fails if any of the time source neighbors do not exist or it is not
   reachable.

2.4.6.2.  READ.timesource

   Retrieves information about the time parents of that node.  The
   command does not require any parameter.

   Returns the following information for each of the time sources:

      target node: address of the time parent.

      statistics: includes for example minimum, maximum, average time
      correction for that time parent

      policy: the used policy

   Fails if the slotframe id or no time source neighbors exist.

Wang, et al.           Expires September 12, 2013              [Page 20]
Internet-Draft                 6tsch-6tus                     March 2013

2.4.6.3.  Time Source Neighbor Command Behavior

   The following table describes the behavior of 6tus upon reception of
   the Time Source Neighbor Configuration management commands.

   Time Source Neighbors Configuration Management Operations behavior

   +---------------------------------+---------------------------------+
   |            6tus commands        |             6tus behavior       |
   +---------------------------------+---------------------------------+
   | Configure.timesource(Policy)    | Configures the 6tus MIB         |
   |                                 | regarding timesource parents    |
   +---------------------------------+---------------------------------+
   | Read.timesource()               | Read 6tus timesource MIB        |
   |                                 |                                 |
   +---------------------------------+---------------------------------+

                                 Figure 3

2.4.7.  Neighbor Commands

   Commands to manage neighbor table.  The commands SHOULD be used by
   the upper layer to query the neighbor related information and by the
   lower layer to keep track of neighbors information.

2.4.7.1.  CREATE.neighbor

   Creates an entry for a neighbor in the neighbor table.

      neighbor address: The address of the neighbor.

      neighbor stats: for example, RSSI of the last received packet from
      that neighbor, ASN when that neighbor has been added, etc.

   Returns whether the neighbor is created or not.

2.4.7.2.  READ.all.neighbor

   Returns the list of neighbors of that node.  Fails if empty.  For
   each neighbor in the list it returns:

      neighbor address: The address of the neighbor.

      neighbor stats: for example, RSSI of the last received packet from
      that neighbor, ASN when that neighbor has been added, packets
      received from that neighbor, packets sent to it, etc.  .

Wang, et al.           Expires September 12, 2013              [Page 21]
Internet-Draft                 6tsch-6tus                     March 2013

2.4.7.3.  READ.neighbor

   Returns the information of a specific neighbors of that node
   specified by its neighbor address.  Fails if it does not exists.  For
   that neighbor it returns:

      neighbor address: The address of the neighbor.

      neighbor stats: for example, RSSI of the last received packet from
      that neighbor, ASN when that neighbor has been added, packets
      received from that neighbor, packets sent to it, etc.

2.4.7.4.  UPDATE.neighbor

   Updates an entry for a neighbor in the neighbor table.  Fails if the
   neighbor does not exist.  Updates stats parameters.  Requires:

      neighbor address: The address of the neighbor.

      neighbor stats: for example, RSSI of the last received packet from
      that neighbor, ASN when that neighbor has been added, etc.  .

   Returns whether the neighbor is updated or not.

2.4.7.5.  DELETE.neighbor

   Deletes a neighbor given its address.  Fails if the neighbor does not
   exists.

2.4.7.6.  Neighbors Command Behavior

   The following table describes the behavior of 6tus upon reception of
   the Neighbors Configuration management commands.

   Neighbors Management Operations behavior

Wang, et al.           Expires September 12, 2013              [Page 22]
Internet-Draft                 6tsch-6tus                     March 2013

   +---------------------------------+---------------------------------+
   |            6tus commands        |             6tus behavior       |
   +---------------------------------+---------------------------------+
   | Create.neighbor(address,stats)  | Adds a neighbor to the neighbor |
   |                                 | table in the 6tus MIB.          |
   +---------------------------------+---------------------------------+
   | Read.all.neighbor()             | lists all neighbors from the    |
   |                                 | neighbor table.                 |
   +---------------------------------+---------------------------------+
   | Read.neighbor(address)          | Reads neighbor information from |
   |                                 | neighbor table in the 6tus MIB  |
   +---------------------------------+---------------------------------+
   | Update.neighbor(address,stats)  | Updates an entry for a neighbor |
   |                                 | in the 6tus MIB                 |
   +---------------------------------+---------------------------------+
   | Delete.neighbor(address)        | Removes the neighbor from the   |
   |                                 | 6tus MIB                        |
   +---------------------------------+---------------------------------+

2.4.8.  Queueing Commands

   TSCH MAC layer queues need to be configured.  This includes queue
   length, retransmission policy, discarding of packets, etc.

2.4.8.1.  CREATE.queue

   Creates and Configures TSCH Queues.  The command SHOULD be applied
   for each required queue.  The command requires:

      txqlength: the desired transmission queue length.

      rxqlength: the desired reception queue length.

      numrtx: number of allowed retransmissions.

      age: discard packet according to its age on the queue.  0 if no
      discards are allowed.

      rtxbackoff: retransmission back off in number of slotframes.  0 if
      next available slot wants to be used.

      statswindow: window of time used to compute stats.

      queue priority: the priority of this queue.

   Returns the queue id.

Wang, et al.           Expires September 12, 2013              [Page 23]
Internet-Draft                 6tsch-6tus                     March 2013

2.4.8.2.  READ.queue

   Reads the queue configuration.  Requires the queue id.

   The command returns:

      txqlength: the transmission queue length.

      rxqlength: the reception queue length.

      numrtx: number of allowed retransmissions.

      age: maximum age of a packet befoer being discarded.  0 if no
      discards are allowed.

      rtxbackoff: retransmission backoff in number of slotframes.  0 if
      next available slot is used.

2.4.8.3.  READ.queue.stats

   Reads the queue stats.  Requires queue id.

   The command returns:

      txqlengthstats: average, maximum, minimum length of the
      transmission queue.

      rxqlengthstats: average, maximum, minimum length of the reception
      queue.

      numrtxstats: average, maximum, minimum number of retransmissions.

      agestats: average, maximum, minimum age of a packet in the queue.

      rtxbackoffstats: average, maximum, minimum retransmission backoff.

      queue priority: the priority of this queue.

2.4.8.4.  UPDATE.queue

   Update a TSCH Queue.  The command requires:

      queueid: the desired transmission queue length.

      txqlength: the desired transmission queue length.

      rxqlength: the desired reception queue length.

Wang, et al.           Expires September 12, 2013              [Page 24]
Internet-Draft                 6tsch-6tus                     March 2013

      numrtx: number of allowed retransmissions.

      age: discard packet according to its age on the queue.  0 if no
      discards are allowed.

      rtxbackoff: retransmission backoff in number of slotframes.  0 if
      next available slot wants to be used.

      statswindow: window of time used to compute stats.

2.4.8.5.  DELETE.queue

   Deletes a TSCH Queue.  The command requires the queue id.  All
   packets in the queue are discarded and the queue is deleted.

2.4.8.6.  Queueing Command Behavior

   The following table describes the behavior of 6tus upon reception of
   the Queue management commands.

   Queue Management Operations behavior

   +---------------------------------+---------------------------------+
   |            6tus commands        |             6tus behavior       |
   +---------------------------------+---------------------------------+
   | Create.queue(tqlen,trlen,numrtx,| Creates a queue with specified  |
   | age,rtxbackoff,prio)            | parameters. Updates 6tus MIB.   |
   +---------------------------------+---------------------------------+
   | Read.queue(id)                  | Reads the queue configuration   |
   |                                 | from 6tus MIB.                  |
   +---------------------------------+---------------------------------+
   | Update.queue(id,tqlen,trlen,    | Updates the queue configuration |
   | numrtx,age,rtxbackoff,prio)     | from 6tus MIB. Readjustes actual|
   |                                 | queue size if required.         |
   +---------------------------------+---------------------------------+
   | Delete.queue(id)                | Deletes the queue from MIB.     |
   |                                 |                                 |
   +---------------------------------+---------------------------------+
   | Read.queue.stats()              | Reads the queue                 |
   |                                 | stats from 6tus MIB.            |
   +---------------------------------+---------------------------------+

Wang, et al.           Expires September 12, 2013              [Page 25]
Internet-Draft                 6tsch-6tus                     March 2013

2.4.9.  Security Commands

   The following commands are used to manage underlying layer security.
   In that case 6tus acts as delegating interface to IEEE802.15.4
   security configuration commands.

2.4.9.1.  CONFIGURE.security

   Enables/Disables Security and configures the MAC PIB.  The command
   requires:

      enable: enables underlying layer security.

      macAutoRequestSecurityLevel: the security level used for automatic
      data requests as described by IEEE 802.15.4 table 61.

      macAutoRequestKeyIdMode: the key identifier mode used for
      automatic data requests as described by IEEE 802.15.4 table 61.

      macAutoRequestKeySource: the originator of the key for automatic
      data requests as described by IEEE 802.15.4 table 61.

      macAutoRequestKeyIndex: the index of the key used for automatic
      data requests as described by IEEE 802.15.4 table 61.

      macDefaultKeySource: the originator of the default key used for
      key identifier mode 0x01 as described by IEEE 802.15.4 table 61.

      macPANCordinatorExtendedAddress: Address of the PAN coordinator as
      described by IEEE 802.15.4 table 61.

      macPANCordinatorShortAddress: Short address of the PAN coordinator
      as described by IEEE 802.15.4 table 61.

2.4.9.2.  CONFIGURE.security.macKeyTable

   Configures Security Keys.  The command requires:

      KeyIdLookupList: list of keyIdLookupDescriptor Entries as defined
      by IEEE 802.15.4 table 61.

      DeviceDescriptorHandleList: Implementation specific list of
      devices that are using this key.  As defined by IEEE 802.15.4
      table 61.

      KeyUsageList: List of slotframe types on which this key is being
      used as specified by IEEE 802.15.4 section 7.4.1.2

Wang, et al.           Expires September 12, 2013              [Page 26]
Internet-Draft                 6tsch-6tus                     March 2013

      Key: 16 octets key.  As specified by IEEE 802.15.4 table 61.

2.4.9.3.  CONFIGURE.security.macSecurityLevelTable

   Configures the set of security levels.  The command requires:

      FrameType: Slotframe type as defined by IEEE802.15.4e std.

      Command Identifier: The command identifier as defined by
      IEEE802.15.4e std.

      Security Minimum: The minimum required security level as specified
      by IEEE 802.15.4e

      Device Override Security Minimum: whether the minimum security
      level can be overridden as specified by IEEE 802.15.4 Table 64

      Allowed Security Levels: the key identifier field that identifies
      the key that is being used as specified by IEEE 802.15.4 section
      7.4.3

2.4.9.4.  Security Command Behavior

   6tus offers the interface to upper layers so underlying MAC layer can
   be configured.  In that sense, 6tus acts as a "none-layer" by only
   delegating the functionalities to the MAC security services.  For
   more details Section 7 on IEEE802.15.4-2011 and its amendments on
   IEEE802.15.4e-2012 should be referred.

2.4.10.  Data Commands

2.4.10.1.  Send.data

   The command used by upper layers to queue a packet so underlying TSCH
   sends it.  According to the specific priority the packet is pushed
   into a Queue with the equivalent priority or following a criteria out
   of the scope of this document.  Once a packet is inserted into a
   queue it waits to be transmitted by TSCH according to the model
   defined in Section 2.3.

   The required parameters are:

      src address: L2 source address

      dest address: L2 unicast or broadcast destination address

      priority: packet priority, usually is consistent with queue
      priority

Wang, et al.           Expires September 12, 2013              [Page 27]
Internet-Draft                 6tsch-6tus                     March 2013

      message length: the length of the message.

      message: control message or data message

      securityLevel:As defined by IEEE802.15.4e std.

2.4.10.2.  Receive.data

   The command is invoked whenever a packet is received and inserted
   into a reception queue.  The method acts as a callback function to
   notify to the upper layers the received message.  Upper layers MUST
   provide an implementation for that method.

   The function has the following parameters:

      src address: L2 source address

      dest address: L2 unicast or broadcast destination address

      priority: packet priority, usually is consistent with queue
      priority

      message length: the length of the message.

      message: control message or data message

2.4.10.3.  Data Command Behavior

   The following table describes the behavior of 6tus upon reception of
   the Data Communication Configuration management commands.

Wang, et al.           Expires September 12, 2013              [Page 28]
Internet-Draft                 6tsch-6tus                     March 2013

   Data Communication Management Operations behavior

   +---------------------------------+---------------------------------+
   |            6tus commands        |             6tus behavior       |
   +---------------------------------+---------------------------------+
   | Send.data(src,dest,prio,        | The message is inserted in the  |
   |           len,msg,seclevel)     | the queue corresponding to the  |
   |                                 | required priority. Fails if the |
   |                                 | queue is full. Fails if the     |
   |                                 | destination address is not a    |
   |                                 | L2 neighbor of the node.        |
   +---------------------------------+---------------------------------+
   | Receive.data(src,dest,prio,len, | The method is invoked whenever a|
   |  msg)                           | message is inserted in the queue|
   |                                 | after successful reception.     |
   +---------------------------------+---------------------------------+

                                 Figure 4

2.5.  Message Formats

   6tus has to negotiate the scheduling of soft links with neighbor
   nodes.  This negotiation happens through 6tus-specific TSCH
   Information Elements, the format of which is defined in this section.
   This section also details the formats of the IEs defined in
   [IEEE802154e] and reused without modification.

   6tus messages can contain one or more IEs.  Section 2.5.1 defines the
   different IEs used by 6tus, both the ones used without modification
   from [IEEE802154e], and the new ones defined by 6tus.  Section 2.5.2
   shows how those IEs are assembled to form the different packets used
   by 6tus.

2.5.1.  Information Elements

   IEEE802.15.4e defines Information elements (IEs) which are formatted
   data objects consisting of an ID, a length, and a data payload used
   to pass data between layers or devices.  IEEE802.15.4e defines Header
   IEs and Payload IEs; 6tus only uses Payload IEs.  A Payload IE
   includes one or more IEs, and ends with a termination IE (ID = 0xf,
   see [IEEE802154e]).

   6tus uses the following Information Elements, in which the first four
   IEs are defined in IEEE802.15.4e, and other three IEs are introduced
   in this document.

      Defined in [IEEE802154e] and used by 6tus without modification:

Wang, et al.           Expires September 12, 2013              [Page 29]
Internet-Draft                 6tsch-6tus                     March 2013

         TSCH Synchronization IE (Section 2.5.1.1)

         TSCH Slotframe and Link IE (Section 2.5.1.2)

         TSCH Timeslot Template IE (Section 2.5.1.3)

         TSCH Channel Hopping IE (Section 2.5.1.4)

      Defined by 6tus:

         6tus Opcode IE (Section 2.5.1.5)

         6tus Bandwidth IE (Section 2.5.1.6)

         6tus Generic Schedule IE (Section 2.5.1.7)

2.5.1.1.  TSCH Synchronization IE

   A Synchronization IE (SyncIE) contains Information allowing a node to
   synchronize to a TSCH network, including the current ASN and a join
   priority.  Synchronization IE must be included in all TSCH Enhanced
   Beacons.

   6tus re-uses this IE as defined in [IEEE802154e].

   Format of a TSCH Synchronization IE (SyncIE).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |    SubID    |T|          ASN                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 ASN                           | Join Priority |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 5

   Length=6

   SubID=0x1a

   T=0, i.e.  short type

   ASN (5 octets) contains the Absolute Slot Number corresponding to the
   timeslot in which the TSCH Enhanced Beacon is sent.

Wang, et al.           Expires September 12, 2013              [Page 30]
Internet-Draft                 6tsch-6tus                     March 2013

   The Join Priority can be used by a joining device to select among
   beaconing devices when multiple beacons are heard.  The PAN
   coordinator's join priority is zero.  A lower value of join priority
   indicates that the device is the preferred one to connect to.  The
   beaconing device's join priority is the lowest join priority heard
   when it joined the network plus one.

2.5.1.2.  TSCH Slotframe and Link IE

   The Slotframe and Link IE (FrameAndLinkIE) contains one or more
   slotframes and their respective links that a beaconing device
   advertises to allow other devices to join the network.

   6tus re-uses this IE as defined in [IEEE802154e].

   Format of a TSCH Slotframe and Link IE (FrameAndLinkIE).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |    SubID    |T|  NumFrame     |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                                                               |
   //               Slotframe and link information                //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 6

   Length=variable

   SubID=0x1b

   T=0, i.e.  short type

   NumFrame is set to the total number of slotframe descriptors
   contained in the TSCH Enhanced Beacon.

Wang, et al.           Expires September 12, 2013              [Page 31]
Internet-Draft                 6tsch-6tus                     March 2013

   Format of a slotframe descriptor.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   FrameID      |            FrameLen          |   NumLink     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //          Link information for each link (5x NumLink)        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 7

   FrameID field shall be set to the slotframeHandle that uniquely
   identifies the slotframe.

   FrameLen field shall be set to the size of the slotframe in number of
   timeslots.

   NumLink field shall be set to the number of links that belong to the
   specific slotframe identified by the slotframeHandle.

   Format of a Link information.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        SlotOffset             |        ChannelOffset          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  LinkOption   |
   +-+-+-+-+-+-+-+-+

                                 Figure 8

   SlotOffset shall be set to the timeslot of this link.

   ChannelOffset shall be set to the logic channel of this link.

   LinkOption indicates whether this link is a TX link, an RX link, or a
   SHARED TX link, whether the device to which it is being linked is to
   be used for clock synchronization, and whether this link is Hard
   link.

2.5.1.3.  TSCH Timeslot Template IE

   Timeslot Template IE (SlotTemplateIE) defines Timeslot template being
   used by the TSCH device.

   6tus re-uses this IE as defined in [IEEE802154e].

Wang, et al.           Expires September 12, 2013              [Page 32]
Internet-Draft                 6tsch-6tus                     March 2013

   Format of a TSCH Timeslot Template IE (SlotTemplateIE).

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |    SubID    |T|  TemplateID   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 9

   Length=1

   SubID=0x1c

   T=0, i.e.  short type

   TemplateID shall be set to a Timeslot template handle.  The full
   time-slot template, which contains the macTimeslotTemplate of TSCH
   (total 25 octets), may be included.(see IEEE802.15.4e).

2.5.1.4.  TSCH Channel Hopping IE

   Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being
   used by the TSCH device.

   6tus re-uses this IE as defined in [IEEE802154e].

   Format of a TSCH Channel Hopping IE (ChHoppingIE).

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Length         | SubID |T| HopSequenceID |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 10

   Length=1

   SubID=0x09

   T=1, i.e.  long type

   HopSequenceID shall be set to a Hopping Sequence handle.  The full
   Hopping Sequence information may be included.  (see IEEE802.15.4e).

2.5.1.5.  6tus Opcode IE

   6tus Opcode IE (OpcodeIE) defines operation codes of packets in 6tus
   layer.

Wang, et al.           Expires September 12, 2013              [Page 33]
Internet-Draft                 6tsch-6tus                     March 2013

   This IE is not present in [IEEE802154e] and is defined by 6tus.

   Format of a 6tus Opcode IE (OpcodeIE).

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |    SubID    |T|   OpcodeID    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 11

   Length=1

   SubID=0x41

   T=0, i.e.  short type

   OpcodeID field shall be set to one of the following codes.

      0x00: Reserve Link Request

      0x01: Reserve Link Response

      0x02: Remove Link Request

2.5.1.6.  6tus Bandwidth IE

   Bandwidth IE (BwIE) defines the number of links to be reserved.

   This IE is not present in [IEEE802154e] and is defined by 6tus.

   Format of a 6tus Bandwidth IE (BwIE).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |    SubID    |T|    FrameID    |   NumLink     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 12

   Length=2

   SubID=0x42

   T=0, i.e.  short type

Wang, et al.           Expires September 12, 2013              [Page 34]
Internet-Draft                 6tsch-6tus                     March 2013

   FrameID field may be set to the SlotFrameHandle to identify the
   slotframe from which links are reserved.  FrameID field may be set to
   NOP, which means no specific slotframe is associated.

   NumLink field shall be set to the number of links.  When BwIE is
   combined with the OpecodeID of Reserve Link Request, NumLink presents
   how many links are required to reserve; and when BwIE is combined
   with the OpecodeID of Reserve Link Response, NumLink presents how
   many links are reserved successfully.

2.5.1.7.  6tus Generic Schedule IE

   Generic Schedule IE (ScheduleIE) describes link sets.  In different
   packet, ScheduleIE represents different information.  See
   Section 2.5.2 for more detail.

   This IE is not present in [IEEE802154e] and is defined by 6tus.

   Format of a 6tus Generic Schedule IE (ScheduleIE).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |    SubID    |T|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   //                   Schedule Body                             //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 13

   Length=variable

   SubID=0x43

   T=0, i.e.  short type

   Schedule Body carries one or more schedule object.  An object may
   carry a TLV, which may itself comprise other TLVs.  TLV format is as
   follows.  Type: 1 byte, Length: 1 byte, Value: variable

   The following are some examples of schedule object TLV.

   Example 1.  Link Set TLV

Wang, et al.           Expires September 12, 2013              [Page 35]
Internet-Draft                 6tsch-6tus                     March 2013

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=1      |    Length     |     FrameID   |  NumLink    |F|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        LinkObjects                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 14

   FrameID shall be set to the slotframeHandle that uniquely identifies
   the slotframe.

   NumLink shall be set to the number of links that belong to the
   specific slotframe identified by the slotframeHandle.

   F=1 means the specified links equals to what are listed in
   LinkObjects, and F=0 means the specified links equals to what are not
   listed in LinkObjects.

   LinkObjects carries the information for one or more links, including
   SlotOffset, ChannelOffset, LinkOption (Figure 8).

   Example 2.  Schedule Matrix TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=2      |    Length     |  FrameID      |StartSlotOffset|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |StartSLotOffset|    NumSlot    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   //                 SlotBitMap (2x NumSlot)                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 15

   FrameID field shall be set to the slotframeHandle that uniquely
   identifies the slotframe.

   StartSlotOffset field (2 octets) shall be set to the slotoffset in
   the specific slotframe identified by the slotframeHandle.

   NumSlot field shall be set to the number of slots from
   StartSlotOffset in the specific slotframe identified by the
   slotframeHandle.

Wang, et al.           Expires September 12, 2013              [Page 36]
Internet-Draft                 6tsch-6tus                     March 2013

   SlotBitMap (per slot) indicates for the given slot which channels are
   specified.  For the 16 channels in 2.4GHz band, 2-octets are used to
   indicate which channel is specified.  For example, given a slot and a
   SlotBitmap with value (10001000,00010000); the bitmap represents that
   ChannelOffset-0, ChannelOffset-4, ChannelOffset-11 are specified.

2.5.2.  Packet Formats

   This section describes the packets used in 6tus to form a network and
   reserve/maintain bandwidth using soft links.  Each of these packets
   use one of more IEs defined in Section 2.5.1.

2.5.2.1.  TSCH Enhanced Beacon

   The TSCH Enhanced Beacon is used to announce the presence of the
   network and allow new nodes to join.  It is and IEEE802.15.4e
   Enhanced Beacon packet with the following Payload IEs:

      TSCH Synchronization IE (Section 2.5.1.1)

      TSCH Timeslot Template IE (Section 2.5.1.3)

      TSCH Channel Hopping IE (Section 2.5.1.4)

      TSCH Slotframe and Link IE (Section 2.5.1.2)

   Payload IE of TSCH Enhanced Beacon Packet

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Length        |GroupID|T|             SyncIE            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SyncIE                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         SyncIE                |      SlotTemplateIE           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |SlotTemplateIE |               ChHoppingIE                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        FrameAndLinkIE                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 16

   Length=variable

   GroupID=0x1, i.e.  MLME IE

Wang, et al.           Expires September 12, 2013              [Page 37]
Internet-Draft                 6tsch-6tus                     March 2013

   T=1, i.e.  payload IE

   See Section 2.5.1.1, Section 2.5.1.3, Section 2.5.1.4,Section 2.5.1.2
   for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndLinkIE.

2.5.2.2.  Link Reservation Request

   Link Reservation Request packet is formatted in Data packet of
   IEEE802.15.4e with following payload IE.

   Payload IE of Link Reservation Request

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Length        |GroupID|T|          OpcodeIE             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OpcodeIE      |                  BwIE                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BwIE       |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   //                          ScheduleIE                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 17

   Length=variable

   GroupID=0x1, i.e.  MLME IE

   T=1, i.e.  payload IE

   The OpcodeID field in the 3-octet OpcodeIE should be set to 0x00,
   indicates Reserve Link Request operation.

   The NumLink field in 4-octet BwIE should be set to the number of
   links needed to be reserved.

   The ScheduleIE specifies a candidate link set, from which the links
   should be reserved.  ScheduleIE may be empty, means there is no
   constrain on which links should not be reserved.

2.5.2.3.  Link Reservation Response

   Link Reservation Response is formatted in Data packet of
   IEEE802.15.4e with following payload IE.

Wang, et al.           Expires September 12, 2013              [Page 38]
Internet-Draft                 6tsch-6tus                     March 2013

   Payload IE of Link Reservation Response

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Length        |GroupID|T|          OpcodeIE             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OpcodeIE      |                  BwIE                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BwIE       |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   //                          ScheduleIE                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 18

   Length=variable

   GroupID=0x1, i.e.  MLME IE

   T=1, i.e.  payload IE

   The OpcodeID field in the 3-octet OpcodeIE should be set to 0x01,
   indicates Reserve Link Response operation.

   The NumLink field in 4-octet BwIE should be set to the number of
   links which have been reserved successfully.

   The ScheduleIE should specify all of the links which have been
   reserved successfully.

2.5.2.4.  Link Remove Request

   Link Remove Request is formatted in a Data packet of IEEE802.15.4e
   with the following payload IE.

Wang, et al.           Expires September 12, 2013              [Page 39]
Internet-Draft                 6tsch-6tus                     March 2013

   Payload IE of Link Remove Request

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Length        |GroupID|T|          OpcodeIE             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OpcodeIE      |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   //                          ScheduleIE                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 19

   Length=variable

   GroupID=0x1, i.e.  MLME IE

   T=1, i.e.  payload IE

   The OpcodeID field in the 3-octet OpcodeIE should be set to 0x02,
   indicates Remove Link Request operation.

   The ScheduleIE should specify all the links that need to be removed.

2.6.  Time Sequence

   6tus neighbors exchange 6tus-specific packets in the following cases,
   each detailed in a subsection.

      Network formation is detailed in Section 2.6.1.

      Creating a soft link is detailed in Section 2.6.2.

      Deleting a soft link is detailed in Section 2.6.3.

      Maintaining soft links is detailed in Section 2.6.4.

2.6.1.  Network Formation

   Network formation consists of two processes: joining and maintenance.

2.6.1.1.  Joining

   A node already in the network sends out TSCH Enhanced Beacons
   periodically.

Wang, et al.           Expires September 12, 2013              [Page 40]
Internet-Draft                 6tsch-6tus                     March 2013

   When a node is joining an existing network, it listens for TSCH
   Enhanced Beacons.  After collecting one or more TSCH Enhanced BEACONs
   (the format of which is detailed in Section 2.5.2.1), the joining
   node must do the following.

      Initialize a neighbor table.  Establish a neighbor table and
      record all of the information described in the TSCH Enhanced
      BEACONs as its initial schedule with those neighbors.

      Select a time source neighbor.  According to the Joining Priority
      described by SyncIEs, the joining node chooses one or more of the
      advertisers as its time source neighbors.  6tus does not specify
      the criteria to choose time source neighbors from the Enhanced
      BEACONs.

      Select links for Enhanced Beacons.  The joining node selects one
      or more links to broadcast its own Enhanced Beacons, which may be
      same as the links used by its neighbors for Enhanced Beacon
      broadcast, and record those link(s) into the TSCH schedule with
      LinkType=ADVERTISING.

      From its Enhanced Beacons, including the link(s) for its Enhanced
      Beacon, which LinkOption should be set to "Receive" and
      "Timekeeping", telling its neighbors that the link is used for
      broadcast.

      Start broadcasting Enhanced Beacon and communicate with neighbors.

2.6.1.2.  Maintenance

   Nodes may broadcast Enhance Beacons on the links marked with
   LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors
   on the links with LinkOption = "Receive" and "Timekeeping".  If a
   link with both LinkType=ADVERTISING has both the "Receive" and
   "Timekeeping" LinkOption, it is shared by neighbors and itself to
   broadcast, then broadcast Enhanced Beacon has higher priority.

   Whenever a node receives an Enhanced Beacon, it must update its
   schedule if there is a difference.

2.6.2.  Creating a Soft Link

   The upper layer instructs 6tus to schedule one of more soft links by
   calling the Create Soft Link command.  This command can also be
   called by the monitoring process internal to 6tus.

   When receiving a Create Soft Link command, Node A's 6tus layer forms
   a Link Reservation Request packet which includes BwIE and ScheduleIE.

Wang, et al.           Expires September 12, 2013              [Page 41]
Internet-Draft                 6tsch-6tus                     March 2013

   The BwIE includes the number of links needed to be reserved (N1), and
   ScheduleIE includes a candidate link set from which the new links
   should be selected.  If the ScheduleIE is empty, Node A indicates
   there is no constraint on link selection.  The Link Reservation
   Request is then sent to the neighbor (Node B) with whom new links
   need to be added.  After receiving the Link Reservation Request, Node
   B selects the links from the candidate link set defined by the
   ScheludeIE in the Link Reservation Request, and forms a Link
   Reservation Response packet, in which BwIE indicates the number of
   links actually being reserved (N2), and ScheduleIE indicates those
   reserved links.  If N2 is smaller than N1, node B indicates to node A
   that there are not enough qualified links to be reserved.  Node B
   must record the reserved links into its local schedule while sending
   out Link Reservation Response.  After receiving the Link Reservation
   Response, Node A must record the reserved links into its local
   schedule.

   The policy to build a candidate link set and the policy to select
   links from the candidate link set to reserve, and expression of
   Schedule Body are out of the scope.  The policy to deal with the
   failure or not fully satisfaction in a Soft Link Reservation process
   is flexible.  For example, Node A may initiate another soft link
   reservation procedure, or simply report to upper layer.

2.6.3.  Deleting a Soft Link

   The upper layer instructs 6tus to delete one of more soft links by
   calling the Delete Soft Link command.  This command can also be
   called by the monitoring process internal to 6tus.

   When receiving a Delete Soft Link command, Node A's 6tus layer
   selects links to be removed from its local schedule, and creates a
   Link Remove Request, including a ScheduleIE.  The ScheduleIE
   indicates which specific links to remove with a neighbor (Node B).
   The links specified in the ScheduleIE should be removed from local
   schedule of Node A while the Link Remove Request is sent to Node B.
   When receiving the Link Remove Request, the links specified in the
   ScheduleIE should be removed from the local schedule of Node B.

   The policy to select links corresponding to a Delete Soft Link
   command is out of scope.

2.6.4.  Maintaining Soft Links

Wang, et al.           Expires September 12, 2013              [Page 42]
Internet-Draft                 6tsch-6tus                     March 2013

   The monitoring process internal to 6tus (Section 2.8) is responsible
   for monitoring and re-scheduling soft links to meet some QoS
   requirements.  The monitoring process may issue a Soft Link
   Maintenance command, which indicate a set of links to be moved in the
   TSCH schedule.

   When a receiving a Soft Link Maintenance command command, 6tus
   initializes a Link Reservation Request (Section 2.6.2) with the
   neighbor in question, followed by a Link Remove Request
   (Section 2.6.3).

2.7.  Statistics

   The 6tus Statistics Fuction (SF) is responsible for collecting
   statistics, which it can provide to an upper layer and the Monitoring
   Function (Section 2.8).

2.7.1.  Statistics Metrics

   6tus is in charge of keeping statistics from a set of metrics
   gathered from the behavior of the TSCH layer.

   The statistics data related to node states and link metrics should be
   provided to upper layer for management, e.g.  for RPL to calculate
   Rank or to GMPLS to determine whether the path is meeting the
   required bandwidth.  The specific algorithm to generate the
   statistics is implementation dependent and hence out of the scope of
   this document.  However, the statistics component should include the
   following metrics:

   1.  PathThroughput: associated with a path, Node A->Node B.  For
       example, PathThroughput can be calculated with:
       SUM(NumOfLink(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration)
       where NumOfLink(i) is the total number of links from Node A to
       Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i.

   2.  Latency: associated with a path, Node A->Node B.  For example,
       latency can be expressed as Minimum and Maximum Latency.  Minimum
       Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum
       Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where,
       MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum
       number of slots between two dedicated links from Node A to Node B
       in Slotframe-i, respectively.

   3.  LinkQuality.  For example, average LQI, ETX;

   4.  TafficLoad.  For example, Queue Full Rate, Queue Empty Rate;

Wang, et al.           Expires September 12, 2013              [Page 43]
Internet-Draft                 6tsch-6tus                     March 2013

   5.  NodeEnergy.  For example, E_E=E_bat / [E_0 (T-t)/T].

2.7.2.  Statistics Configuration

   Statistics Function should be configurable.  The configuration
   parameters should include:

      LinkQualityStatisticsEn.

      TafficLoadStatisticsEn.

      DeviceStatisticsEn.

   6tus statistics function is enabled/disabled and configured by the
   commands defined in Section 2.4.4

2.8.  Monitoring

   Monitoring Fuction (MF) in 6tus is responsible for monitoring link
   quality, traffic load, and issuing Soft Link Maintenance command, or
   Create/Delete Soft Link command.  The data provided by Statistics
   Function may be used as a input of MF in making monitoring decision.

2.8.1.  Monitor Configuration

   Monitoring Function should be configurable.  The configuration
   parameters should include:

      MaintainLinkEn.

      CreateDeleteLinkEn.

      QosLevel.  QosLevel should associate with specific neighbor
      address.  QosLevel may reflect the latency constraint, link
      quality constraint, and so on.  The value of QosLevel works as the
      bandwidth redundancy coefficient.

   6tus monitoring function is enabled/disabled and configured by the
   commands defined in Section 2.4.3

2.8.2.  Actuation

   The link quality statistics may be used to generate Soft Link
   Maintenance command, which leads to a Soft Link Maintenance procedure
   (see Section 2.6.4).  The traffic load statistics may be used to
   generate internal Create/Delete Soft Link commands, which leads to a
   Soft Link Reservation process or a Soft Link Remove process,
   respectively.  (see Section 2.6.2 and Section 2.6.3)

Wang, et al.           Expires September 12, 2013              [Page 44]
Internet-Draft                 6tsch-6tus                     March 2013

   The policy to generate the Soft Link Maintenance command and the
   policy to generate Create/Delete Soft Link commands is out of the
   scope.

   The policy to generate Create/Delete Soft Link commands may take
   QosLevel into account.  For example, there are two slotframes
   existing, Slotframe-1 consists of 32 slots, Slotframe-2 consists of
   96 slots; Slot duration is 10ms; QosLevel=1.5.  If, from the traffic
   load statistics, MF figures out 2 packet/second should be added, then
   it leads to a Create Soft Link command, where FrameID=2, NumLink=3.

3.  Using 6tus

   This part describes how 6tus gives support to specific upper layers.

3.1.  RPL on 6tus

   6tus provides a set of functionalities so higher layers can obtain
   information about the status of the network and take advantage of the
   slotted structure to improve metric calculation and objective
   function optimization.  The following sections describe how RPL can
   make use of 6tus adaptation layer.

   In order to optimize the combination of RPL and TSCH, 6tus provides
   specific support to RPL in the following aspects:

      RPL Neighbor Discovery and Parent Selection

      RPL Rank Computation

      RPL Control Messages Broadcast

      QoS

3.1.1.  Support to Neighbor Discovery and Parent Selection

   The Section 2.4.7 defines a set of commands so the neighbor table can
   be managed and queried by RPL.  An entry to the neighbor table is
   inserted whenever an EBs is received at L2.  The EB causes the 6tus
   layer to create an entry to the neighbors table.  A neighbor table
   entry contains a set of statistics with respect to that specific
   neighbor such as the ASN when the last packet has been received from
   that neighbor, a set of link quality metrics (RSSI, LQI), number of
   packets sent to it or number of packets received from it amongst
   others.  6tus updates that table upon sending or reception of a
   packet from/to a neighbor.  RPL can query at any time the neighbor
   table to retrieve information about a particular neighbor.  This
   information can be used to compute the routing objective function as

Wang, et al.           Expires September 12, 2013              [Page 45]
Internet-Draft                 6tsch-6tus                     March 2013

   for example the inverse of the Probability Delivery Ratio (PDR).
   Parent selection can also be driven by the information contained on
   the neighbor table as well as complemented with the links statistics
   defined in Section 2.4.4 and Section 2.7.

   6tus enables RPL to configure EB periodicity.  By controlling the EBs
   periodicity, RPL can configure how network dynamism and support to
   mobility are addressed, as more frequent beacons the more prone to
   cope with mobility.  Section 2.4.5 enables to configure how the
   network is formed and EBs periodicity.

   RPL may want to select the policy to determine the time source
   neighbor, this can be interesting when time source neighbors can be
   aligned to the routing topology, i.e, the selected time source
   neighbor can be the node's favorite parent in a specific DODAG.
   Section 2.4.6 describes the 6tus command to setup the desired policy.
   The policy is selected by RPL and enforced by 6tus layer.

   The rule for 6tus to select and maintain time sources is as follows.

      Time source of one node should be one member of the node's
      neighbor set.

      Time sources should be the neighbors which have relatively lower
      Join Priority in the neighbor set.  Lower Join Priority means
      closer to TSCH Pan coordinator.

      The path from a node to its time sources should be in a good link
      quality.

3.1.2.  Support to Rank Computation

   RPL objective function is computed by a set of metrics.  The specific
   metrics and how the objective function is calculated are out of the
   scope of the present document, however, 6tus builds a set of
   functionalities to provide more accurate statistics of the underlying
   layer so the objective function can be accommodated to the nature of
   a TSCH MAC layer.

   6tus provides Statistics for Rank computation as described in
   sections(Section 2.4.4 and Section 2.7).  The function to compute the
   Rank based on those statistics is out of scope of 6tus, however the
   provided metrics are aligned to the behavior of the TSCH MAC layer.

3.1.3.  Support to Control Messages Broadcast

   In RPL, some control messages, e.g.  DIO, and DAO in sorting mode,
   need to be broadcasted to the neighbors.  The broadcast channel

Wang, et al.           Expires September 12, 2013              [Page 46]
Internet-Draft                 6tsch-6tus                     March 2013

   requirement has to be addressed by 6tus by configuring TSCH to
   provide such a channel.

   In order to decouple the upper (RPL) layer to TSCH, instead of
   carrying DIO message in the Enhance Beacon, 6tus introduces a
   mechanism to establish broadcast links.

   In TSCH schedule, every link has the LinkType attribute.  If
   LinkType=ADVERTISING, indicates that the link may be used to send an
   Enhanced Beacon.  When a node forms its Enhanced Beacon, the link,
   with LinkType=ADVERTISING, should be included in the FrameAndLinkIE,
   and its LinkOption field should be set to the combination of
   "Receive" and "Timekeeping".  The receiver of the Enhanced Beacon may
   listen to at the link to get the Enhanced Beacon ([IEEE802154e]).
   6tus takes this way to establish broadcast channel, which not only
   allows TSCH broadcast Enhanced Beacon, but also allows an upper layer
   like RPL broadcast.

   To support DIO and DAO broadcast, 6tus uses the payload of a Data
   Packet to carry the DIO or DAO.  The message is inserted into the
   queue associated with the links which LinkType is set to ADVERTISING.
   Then, taking advantage of the broadcast link feature established with
   FrameAndLinkIE as described above, the data packet with DIO or DAO in
   payload can be received by neighbors, which leads to the maintenance
   of DODAG.

   The LinkOption of combining "Receive" and "Timekeeping" let the
   receivers of the Enhanced Beacon understand that the link is used as
   broadcast link.  But the frequency of sending Enhance Beacon or other
   broadcast messages by upper layer is determined by the timers
   associated with the messages, e.g.  Enhance Beacon is triggered by
   the timer in 6tus, and the DIO message is triggered by the trickle
   timer of RPL.  Therefore, for energy efficiency, receivers can have
   some policy to wake up at the broadcast link, but it is
   implementation dependent.

3.1.4.  Support to QoS

   TSCH MAC layer is decoupled from the upper layers and its interaction
   with them is asynchronous.  This means that the MAC layer executes a
   schedule and checks at each slot according to the type of link
   whether there is something to send or receive.  If that is the case
   the packet is sent and the MAC layer continues its operation.  When
   an upper layer sends a packet, this packet is pushed into a queue
   waiting to the MAC layer to read it and sent it in a particular slot
   according to is destination and priority (Section 2.3).  6tus
   provides a set of queue management operations which enable upper
   layers to create different queues and determine their priorities.  In

Wang, et al.           Expires September 12, 2013              [Page 47]
Internet-Draft                 6tsch-6tus                     March 2013

   that sense different classes of traffic can be handled by the routing
   layer, i.e inserting a packet to a specific queue according to its
   priority.

   6tus provides at least a Broadcast Queue, a Transmit Queue, and a
   Receive Queue.  RPL can configure the queues with Internal Queueing
   Command (Section 2.4.8.1).  Broadcast Queue are associated with links
   with LinkType=ADVERTISING in sender's schedule, and
   LinkOption="Receive" and "Timekeeping" in all neighbors' schedule.
   That indicates the links can be used for broadcast from the sender to
   its neighbors.  Transmit Queues are associated with the dedicated
   Transmit links or Shared Links.  RPL can benefit from having
   different priority queues in order to improve latency or provide
   integrated services with different priorities, i.e different traffic
   classes.

   Data Communication Command (Section 2.4.10) can be used to send
   control messages and data messages.  The operation is used to insert
   a message to an specific queue.

   For example a suitable configuration can include two Broadcast Queues
   with priority High and Low, respectively; three Transmit Queues, with
   priority High, Mid, and Low, respectively; and one Receive Queue.

   When DestAddr is a broadcast address, its related MAC layer packets
   will be pushed into the Broadcast Queue with the corresponding
   priority.  6tus is responsible for feeding these packets to TSCH at
   broadcast links.

   When DestAddr is unicast address, its related MAC layer packets will
   be push into the Transmit Queue with corresponding priority.  6tus is
   responsible for feeding these packets to TSCH at Transmit links or
   Shared Links.

   6tus conducts a QoS policy, which is out of scope.  Here is an
   example.  Packets in higher priority queue MUST be sent out before
   the packets in lower priority queue.  Then, when there is an
   available broadcast/unicast link, 6tus checks the broadcast/unicast
   queue with higher priority first, if there is a packet, then feed it
   to TSCH at the link, otherwise checks broadcast/unicast queue with
   lower priority further.  Repeat the process, until find a broadcast/
   unicast packet to feed to TSCH or find all of broadcast/unicast
   queues are empty.

3.2.  GMPLS on 6tus

   GMPLS is a 2.5 layer service that is used to forward packets based on
   the concept of generalized label.  Labels are determined by a

Wang, et al.           Expires September 12, 2013              [Page 48]
Internet-Draft                 6tsch-6tus                     March 2013

   reservation protocol during the formation of a path.  As defined by
   [RFC3471],[RFC3473] and [RFC4606] a generalized label identifies a
   flow of data through a set of nodes that conform to a multi-hop path.
   Instead of being appended to each packet as is the case in MPLS
   [RFC3031], the generalized label it is kept at each node in the form
   of a table.  The table can be used to map input links to output links
   so routing decisions can be taken at that layer.

   In order to optimize the combination of GMPLS and TSCH, 6tus provides
   specific support to GMPLS in the following aspects:

      Link Reservation Support

      QoS

3.2.1.  Link Reservation Support for GMPLS on 6tus

   The GMPLS control plane is used to transmit path reservation requests
   and reservation confirmations.  When reservation confirmations are
   received, GMPLS needs to configure the underlying MAC layer to
   provide the required bandwidth.  6tus provides a set of commands to
   deal with bandwidth allocation, i.e.  link allocation.  Section 2.4.1
   describes the operations that GMPLS layer may use for link
   configuration.  Note that 6tus supports different types of
   reservations: soft link and hard link.  How the reservation
   requirements are expressed is out of scope of this document, but 6tus
   is able to handle a reservation done as a specific bandwidth
   requirement, done through specifying exact links.

   GMPLS can also give different priorities to its control plane and
   data plane.  It can for example be interesting to have a higher
   priority for control messages so the network adapts to new bandwidth
   requirements quickly.  In contrast, data plane messages can be given
   a higher priority when they need to meet higher throughput or lower
   latency.  6tus provides commands (Section 2.4.8) to manage MAC layer
   queues and assign different priorities to them.

3.2.2.  Supporting QoS

   GMPLS can use 6tus statistics to determine whether some QoS
   requirement is met.  Metrics defined in Section 2.7 and operations
   defined in Section 2.4.4.4 can be used by GMPLS to trigger new
   bandwidth allocation, or to map different input bundles to output
   bundles.

4.  References

Wang, et al.           Expires September 12, 2013              [Page 49]
Internet-Draft                 6tsch-6tus                     March 2013

4.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

4.2.  Informative References

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
              B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, July 2004.

   [RFC4606]  Mannie, E. and D. Papadimitriou, "Generalized Multi-
              Protocol Label Switching (GMPLS) Extensions for
              Synchronous Optical Network (SONET) and Synchronous
              Digital Hierarchy (SDH) Control", RFC 4606, August 2006.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals", RFC
              4919, August 2007.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

Wang, et al.           Expires September 12, 2013              [Page 50]
Internet-Draft                 6tsch-6tus                     March 2013

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks", RFC
              5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

   [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
              Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
              Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
              Lossy Networks", RFC 6550, March 2012.

   [RFC6568]  Kim, E., Kaspar, D., and JP. Vasseur, "Design and
              Application Spaces for IPv6 over Low-Power Wireless
              Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.

   [RFC6606]  Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
              Statement and Requirements for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Routing", RFC
              6606, May 2012.

   [RFC6755]  Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
              for OAuth", RFC 6755, October 2012.

   [I-D.thubert-roll-forwarding-frags]
              Thubert, P. and J. Hui, "LLN Fragment Forwarding and
              Recovery", draft-thubert-roll-forwarding-frags-01 (work in
              progress), February 2013.

   [I-D.tsao-roll-security-framework]
              Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
              Security Framework for Routing over Low Power and Lossy
              Networks", draft-tsao-roll-security-framework-02 (work in
              progress), March 2010.

Wang, et al.           Expires September 12, 2013              [Page 51]
Internet-Draft                 6tsch-6tus                     March 2013

   [I-D.thubert-roll-asymlink]
              Thubert, P., "RPL adaptation for asymmetrical links",
              draft-thubert-roll-asymlink-02 (work in progress),
              December 2011.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-11 (work in
              progress), February 2013.

   [I-D.ietf-roll-p2p-rpl]
              Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
              Martocci, "Reactive Discovery of Point-to-Point Routes in
              Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16
              (work in progress), February 2013.

   [I-D.ietf-roll-trickle-mcast]
              Hui, J. and R. Kelsey, "Multicast Protocol for Low power
              and Lossy Networks (MPL)", draft-ietf-roll-trickle-
              mcast-04 (work in progress), February 2013.

   [I-D.thubert-6lowpan-backbone-router]
              Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
              6lowpan-backbone-router-03 (work in progress), February
              2013.

   [I-D.sarikaya-core-sbootstrapping]
              Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
              Cragie, "Security Bootstrapping Solution for Resource-
              Constrained Devices", draft-sarikaya-core-
              sbootstrapping-04 (work in progress), April 2012.

   [I-D.gilger-smart-object-security-workshop]
              Gilger, J. and H. Tschofenig, "Report from the 'Smart
              Object Security Workshop', 23rd March 2012, Paris,
              France", draft-gilger-smart-object-security-workshop-00
              (work in progress), October 2012.

   [I-D.phinney-roll-rpl-industrial-applicability]
              Phinney, T., Thubert, P., and R. Assimiti, "RPL
              applicability in industrial networks", draft-phinney-roll-
              rpl-industrial-applicability-02 (work in progress),
              February 2013.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)", draft-ietf-
              core-coap-13 (work in progress), December 2012.

Wang, et al.           Expires September 12, 2013              [Page 52]
Internet-Draft                 6tsch-6tus                     March 2013

   [I-D.watteyne-6tsch-tsch-lln-context]
              Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context:
              Overview, Problem Statement and Goals", draft-watteyne-
              6tsch-tsch-lln-context-01 (work in progress), February
              2013.

   [I-D.draft-palattella-6tsch-terminology]
              Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q.
              Wang, "Terminology in IPv6 over Time Slotted Channel
              Hopping. draft-palattella-6tsch-terminology-00 (work in
              progress) ", March 2013.

   [I-D.draft-thubert-6tsch-architecture]
              Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An
              Architecture for IPv6 over Time Synchronized Channel
              Hopping. draft-thubert-6tsch-architecture-00 (work in
              progress) ", March 2013.

4.3.  External Informative References

   [IEEE802154e]
              IEEE standard for Information Technology, "IEEE std.
              802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
              Networks (LR-WPANs) Amendament 1: MAC sublayer", April
              2012.

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

   [OpenWSN]  , "Berkeley's OpenWSN Project Homepage", ,
              <http://www.openwsn.org/>.

Authors' Addresses

   Qin Wang (editor)
   Univ. of Sci. and Tech. Beijing
   30 Xueyuan Road
   Beijing, Hebei  100083
   China

   Phone: +86 (10) 6233 4781
   Email: wangqin@ies.ustb.edu.cn

Wang, et al.           Expires September 12, 2013              [Page 53]
Internet-Draft                 6tsch-6tus                     March 2013

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

   Phone: +34 (646) 633 681
   Email: xvilajosana@uoc.edu

   Thomas Watteyne
   Linear Technology
   30695 Huntwood Avenue
   Hayward, CA  94544
   USA

   Phone: +1 (510) 400-2978
   Email: twatteyne@linear.com

Wang, et al.           Expires September 12, 2013              [Page 54]