Skip to main content

6TiSCH Operation Sublayer (6top) Interface
draft-wang-6tisch-6top-interface-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 "Replaced".
Authors Qin Wang , Xavier Vilajosana , Thomas Watteyne
Last updated 2014-01-31
Replaced by draft-ietf-6tisch-6top-interface
RFC stream (None)
Formats
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-6tisch-6top-interface-00
6TiSCH                                                      Q. Wang, Ed.
Internet-Draft                           Univ. of Sci. and Tech. Beijing
Intended status: Informational                             X. Vilajosana
Expires: August 4, 2014                  Universitat Oberta de Catalunya
                                                             T. Watteyne
                                                       Linear Technology
                                                        January 31, 2014

               6TiSCH Operation Sublayer (6top) Interface
                  draft-wang-6tisch-6top-interface-00

Abstract

   The recently published [IEEE802154e] standard formalizes the concept
   of link-layer resources in LLNs.  Nodes are synchronized and follow a
   schedule.  A cell 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.  The [IEEE802154e]
   standard does not, however, present a mechanism to do so, as building
   and managing the schedule is out of scope of the standard.  This
   document describes the 6TiSCH Operation Sublayer (6top) and the
   commands it provides to upper network layers such as RPL or GMPLS.
   The set of functionalities includes feedback metrics from cell states
   so network layers can take routing decisions, TSCH configuration and
   control procedures, and the support for decentralized and centralized
   scheduling.  In addition, 6top can be configured to enable packet
   switching at layer 2.5, analogous to GMPLS.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 4, 2014.

Wang, et al.             Expires August 4, 2014                 [Page 1]
Internet-Draft            6tisch-6top-interface             January 2014

Copyright Notice

   Copyright (c) 2014 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.  6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . .   4
   3.  6top Commands . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Cell Model  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  hard cells  . . . . . . . . . . . . . . . . . . . . .   7
       3.1.2.  soft cells  . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Data Transfer Model . . . . . . . . . . . . . . . . . . .   7
     3.3.  Commands  . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.3.1.  Cell Commands . . . . . . . . . . . . . . . . . . . .  11
       3.3.2.  Slotframe Commands  . . . . . . . . . . . . . . . . .  17
       3.3.3.  Monitoring Commands . . . . . . . . . . . . . . . . .  20
       3.3.4.  Statistics Commands . . . . . . . . . . . . . . . . .  21
       3.3.5.  Network Formation Commands  . . . . . . . . . . . . .  22
       3.3.6.  Time Source Neighbor Commands . . . . . . . . . . . .  24
       3.3.7.  Neighbor Commands . . . . . . . . . . . . . . . . . .  24
       3.3.8.  Queueing Commands . . . . . . . . . . . . . . . . . .  26
       3.3.9.  Data Commands . . . . . . . . . . . . . . . . . . . .  28
       3.3.10. Label Switching Commands  . . . . . . . . . . . . . .  29
       3.3.11. Chunk Command . . . . . . . . . . . . . . . . . . . .  30
       3.3.12. Chunk Cell Command  . . . . . . . . . . . . . . . . .  30
   4.  Generic Data Model  . . . . . . . . . . . . . . . . . . . . .  32
     4.1.  YANG model of 6top MIB  . . . . . . . . . . . . . . . . .  32
     4.2.  YANG model of IEEE802.15.4 PIB  . . . . . . . . . . . . .  47
     4.3.  YANG model of IEEE802.15.4e PIB . . . . . . . . . . . . .  47
   5.  Using 6top  . . . . . . . . . . . . . . . . . . . . . . . . .  47
     5.1.  RPL on 6top . . . . . . . . . . . . . . . . . . . . . . .  47
       5.1.1.  Support to Neighbor Discovery and Parent Selection  .  47
       5.1.2.  Support of Rank Computation . . . . . . . . . . . . .  48
       5.1.3.  Support of Control Messages Broadcast . . . . . . . .  49
       5.1.4.  Support for QoS . . . . . . . . . . . . . . . . . . .  50
     5.2.  GMPLS on 6top . . . . . . . . . . . . . . . . . . . . . .  51

Wang, et al.             Expires August 4, 2014                 [Page 2]
Internet-Draft            6tisch-6top-interface             January 2014

       5.2.1.  Cell Reservation Support for GMPLS on 6top  . . . . .  51
       5.2.2.  Supporting QoS  . . . . . . . . . . . . . . . . . . .  52
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  52
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  52
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  52
     6.3.  External Informative References . . . . . . . . . . . . .  56
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  56

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
   mechanism 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 signalling 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 cell in that topology.  This
   responsibility is left to an upper layer, defined in this document
   and called "6top".

   This document describes the 6TiSCH Operation Sublayer (6top) and the
   main commands provided to upper network layers such as RPL or GMPLS.
   The set of functionalities include feedback metrics from cell state
   so the network layer can take routing decisions, TSCH configuration
   and control procedures, and support for the different scheduling
   mechanisms defined in [I-D.thubert-6tisch-architecture]. 6top
   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. 6top offers a set of commands so control mechanisms can
   be introduced on top of TSCH to configure nodes to join a specific
   node and obtain a unique 16-bit identifier from the network.  Once a
   network is formed, 6top 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

Wang, et al.             Expires August 4, 2014                 [Page 3]
Internet-Draft            6tisch-6top-interface             January 2014

   layers running on top of 6top 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; 6top provides a set
   of commands for upper layers to set up specific schedules, either
   explicitly by detailing specific cell information, or by allowing
   6top to establish a schedule given a bandwidth or latency
   requirement. 6top is designed to enable decentralized, centralized or
   hybrid scheduling solutions. 6top enables internal TSCH queuing
   configuration, size of buffers, packet priorities, transmission
   failure behavior, and defines mechanisms to encrypt and authenticate
   MAC slotframes.

   As described in [label-switching-154e], due to the slotted nature of
   a TSCH network, it is possible to use a label switched architecture
   on top of TSCH cells.  As a cell belongs to a specific track, a label
   header is not needed at each packet; the input cell (or bundle) and
   the output cell (or bundle) uniquely identify the data flow.  The
   6top sublayer provides operations to manage the cell mappings.

2.  6TiSCH Operation Sublayer (6top) Overview

   6top is a sublayer which is the next-higher layer for TSCH
   (Figure 1), as detailed in [I-D.thubert-6tisch-architecture]. 6top
   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.

Wang, et al.             Expires August 4, 2014                 [Page 4]
Internet-Draft            6tisch-6top-interface             January 2014

   Protocol Stack

      +-----------------------------------+
      | PCEP | CoAP |      | 6LoWPAN |    |
      | PCC  | DTLS | PANA |    ND   |RPL |
      +------------------------------------------+
      | TCP  |     UDP     |     ICMP     | RSVP |
      +------------------------------------------+
      |                 IPv6                     |
      +------------------------------------------+
      |               6LoWPAN HC                 |
      +------------------------------------------+
      |                 6top                     |
      +------------------------------------------+
      |          IEEE802.15.4e TSCH              |
      +------------------------------------------+
      |             IEEE802.15.4                 |
      +------------------------------------------+

                                 Figure 1

   6top distinguishes between hard cells and soft cells.  It therefore
   requires an extra flag to all cells in the TSCH schedule, as detailed
   in Section 3.1.

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

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

   YANG is used to express 6top data model, detailed in Section 4.

3.  6top Commands

3.1.  Cell Model

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

         b0 = Transmit

Wang, et al.             Expires August 4, 2014                 [Page 5]
Internet-Draft            6tisch-6top-interface             January 2014

         b1 = Receive

         b2 = Shared

         b3 = Timekeeping

         b4-b7 = Reserved

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

   6top allows an upper layer to schedule a cell at a specific
   slotOffset and channelOffset, in a specific slotframe.

   In addition, 6top allows an upper layer to schedule a certain amount
   of bandwidth to a neighbor, without having to specify the exact
   slotOffset(s) and channelOffset(s).  Once bandwidth is reserved, 6top
   is in charge of ensuring that this requirement is continuously
   satisfied. 6top dynamically reallocates cells if needed, and over-
   provisions if required.

   6top allows an upper layer to associate a cell with a specific track
   by using a TrackID.  A TrackID is a tuple
   (TrackOwnerAddr,InstanceID), where TrackOwnerAddr is the address of
   the node which initializes the process of creating the track, i.e.,
   the owner of the track; and InstanceID is an instance identifier
   given by the owner of the track.  InstanceID comes from upper layer;
   InstanceID could for example be the local instance ID defined in RPL.

   If the TrackID is set to (0,0), the cell can be used by the best-
   effort QoS configuration or as a Shared cell.  If the TrackID is not
   set to (0,0), i.e., the cell belongs to a specific track, the cell
   MUST not be set as Shared cell.

   6top allows an upper layer ask a node manage a a portion of a
   slotframe, which is named as chunk.  Chunks can be delegated
   explicitly by the PCE to a node, or claimed automatically by any node
   that participates to the distributed cell scheduling process.  The
   resource in a chunk can be appropriated by the node, i.e. the owner
   of the chunk.

   Given this mechanism, 6top defines hard cells (which have been
   requested specifically) and soft cells (which can be reallocated
   dynamically).  The hard/soft flag is introduced by the 6top sublayer
   named as CellType, 0: soft cell, 1: hard cell.  This option is
   mandatory; all cells are either hard or soft.

Wang, et al.             Expires August 4, 2014                 [Page 6]
Internet-Draft            6tisch-6top-interface             January 2014

3.1.1.  hard cells

   A hard cell is a cell that cannot be dynamically reallocated by 6top.
   A hard cell is uniquely identified by the following tuple:

         slotframe ID: ID of the slotframe this cell is part of.

         slotOffset: the slotOffset for the cell.

         channelOffset: the channelOffset for the cell.

         LinkOption bitmap: bitmap as defined in [IEEE802154].

         CellType: MUST be set to 1.

3.1.2.  soft cells

   A soft cell is a cell that can be reallocated by 6top dynamically.
   The CellType MUST be set to 0.  This cell is installed by 6top given
   a specific bandwidth requirement.  Soft cells are installed through
   the soft cell negotiation procedure described in "draft-wang-6tisch-
   6top-sublayer".

3.2.  Data Transfer Model

   Once a TSCH schedule is established, 6top is responsible for feeding
   the data from the upper layer into TSCH.  This section describes how
   6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds
   it to TSCH.  Since 6top is a sublayer between TSCH and 6LoWPAN, the
   properties associated with a packet/fragment from the upper layer
   includes the next hop neighbor (DestAddr) and expected sending
   priority of the packet (Priority), and/or TrackID(s).  The output to
   TSCH is the fragment corresponding to the next active cell in the
   TSCH schedule.

Wang, et al.             Expires August 4, 2014                 [Page 7]
Internet-Draft            6tisch-6top-interface             January 2014

   6top Data Transfer Model

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

                                 Figure 2

   In Figure 2, 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 tracks is
   configurable.  For example, for a given queue, only one specific
   track can be used, all of the tracks can be used, or a subset of the
   tracks can be used.

   When 6top receives a packet to transmit through a Send.data command
   (Section 3.3.9), 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 cell by TSCH.
   When invoked, the MUX module goes through the queues, looking for the
   best matching frame to send.  If it finds a frame, it hands it over

Wang, et al.             Expires August 4, 2014                 [Page 8]
Internet-Draft            6tisch-6top-interface             January 2014

   to TSCH for transmission.  If the next active cell is a broadcast
   cell, it selects a fragment only from broadcast queues.

   How the MUX module selects the best frame is configurable.  The
   following rules are a typical example:

         The frame's layer 2 destination address MUST match the neighbor
         address associated with the transmit cell.

         If the transmit cell is associated with a specific track, the
         frames in the queue corresponding to the TrackID have the
         highest priority.

         If the transmit cell is not associated with a specific track,
         i.e., TrackID=(0,0), frames from a queue with a higher priority
         MUST be sent before frames from a queue with a lower priority.

   Further rules can be configured to satisfy specific QoS requirements.

3.3.  Commands

   6top provides a set of commands as the interface with the higher
   layer.  Most of these commands are related to the management of
   slotframes, cells and scheduling information. 6top also provides an
   interface allowing an upper layer to retrieve status information and
   statistics.  This section describes the following commands provided
   by 6top.

         CREATE.hardcell: Section 3.3.1.1

         CREATE.softcell: Section 3.3.1.2

         READ.cell: Section 3.3.1.3

         UPDATE.cell: Section 3.3.1.4

         DELETE.hardcell: Section 3.3.1.5

         DELETE.softcell: Section 3.3.1.6

         REALLOCATE.softcell: Section 3.3.1.7

         CREATE.slotframe: Section 3.3.2.1

         READ.slotframe: Section 3.3.2.2

         UPDATE.slotframe: Section 3.3.2.3

Wang, et al.             Expires August 4, 2014                 [Page 9]
Internet-Draft            6tisch-6top-interface             January 2014

         DELETE.slotframe: Section 3.3.2.4

         CONFIGURE.monitoring: Section 3.3.3.1

         READ.monitoring: Section 3.3.3.2

         CONFIGURE.statistics: Section 3.3.4.1

         READ.statistics: Section 3.3.4.2

         RESET.statistics: Section 3.3.4.3

         CONFIGURE.eb: Section 3.3.5.1

         READ.eb: Section 3.3.5.2

         CONFIGURE.timesource: Section 3.3.6.1

         READ.timesource: Section 3.3.6.2

         CREATE.neighbor: Section 3.3.7.1

         READ.all.neighbor: Section 3.3.7.2

         READ.neighbor: Section 3.3.7.3

         UPDATE.neighbor: Section 3.3.7.4

         DELETE.neighbor: Section 3.3.7.5

         CREATE.queue: Section 3.3.8.1

         READ.queue: Section 3.3.8.2

         READ.queue.stats: Section 3.3.8.3

         UPDATE.queue: Section 3.3.8.4

         DELETE.queue: Section 3.3.8.5

         Send.data: Section 3.3.9.1

         Receive.data: Section 3.3.9.2

         LabelSwitching.map: Section 3.3.10.1

         LabelSwitching.unmap: Section 3.3.10.2

Wang, et al.             Expires August 4, 2014                [Page 10]
Internet-Draft            6tisch-6top-interface             January 2014

         CREATE.chunk: Section 3.3.11.1

         DELETE.chunk: Section 3.3.11.2

         CREATE.hardcell.fromchunk: Section 3.3.12.1

         DELETE.hardcell.fromchunk: Section 3.3.12.2

3.3.1.  Cell Commands

   6top provides the following commands to manage TSCH cells.

3.3.1.1.  CREATE.hardcell

   Creates one or more hard cells in the schedule.  Fails if the cell
   already exists.  A cell is uniquely identified by the tuple
   (slotframe ID, slotOffset, channelOffset).

   To create a hard cell, the upper layer specifies:

         slotframe ID: ID of the slotframe this timeslot will be
         scheduled in.

         slotOffset: the slotOffset for the cell.

         channelOffset: channelOffset for the cell.

         LinkOption bitmap: bitmap as defined in [IEEE802154e]

         LinkType : as defined in section 6.2.19.3 of [IEEE802154e].

         CellType: as defined in Section 3.1

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

         TrackID: ID of the track the cell will belong to.

   6top schedules the cell and marks it as a hard cell, indicating that
   it cannot reschedule this cell.  The return value is CellID and the
   created cell is also filled in CellList (Section 4.1).

   The interaction between 6top and MAC layer caused by CREATE.hardcell
   is as follows.

Wang, et al.             Expires August 4, 2014                [Page 11]
Internet-Draft            6tisch-6top-interface             January 2014

   Firstly, 6top calls the premitive MLME-SET-LINK.request defind in
   section 6.2.19.3 of [IEEE802154e].  The premitive parameters are set
   as follows.

   +---------------------------------+---------------------------------+
   | MLME-SET-LINK.request parameter |          set by 6top            |
   +---------------------------------+---------------------------------+
   |    operation                    |   ADD-LINK                      |
   +---------------------------------+---------------------------------+
   |    LinkHandle                   |   CellID                        |
   +---------------------------------+---------------------------------+
   |    slotframeHandle              |   slotframe ID                  |
   +---------------------------------+---------------------------------+
   |    timeslot                     |   slotOffset                    |
   +---------------------------------+---------------------------------+
   |    channelOffset                |   channelOffset                 |
   +---------------------------------+---------------------------------+
   |    LinkOptions                  |   LinkOption bitmap             |
   +---------------------------------+---------------------------------+
   |    LinkType                     |   LinkType                      |
   +---------------------------------+---------------------------------+
   |    nodeAddr                     |   target node address           |
   +---------------------------------+---------------------------------+

   Secondly, if the status from MLME-SET-LINK.confirm defined in section
   6.2.19.4 of [IEEE802154e] is SUCCESS, then add the LinkHandle to the
   BundleList specified by TrackID, and confirm to upper layer with
   status = SUCCESS; otherwise, confirm to upper layer with status =
   FAIL.

3.3.1.2.  CREATE.softcell

   To create soft cell(s), the upper layer specifies:

         slotframe ID: ID of the slotframe the cell(s) will be scheduled
         in

         number of cells: the required number of soft cells.

         LinkOption bitmap: bitmap as defined in [IEEE802154e]

         CellType: as defined in Section 3.1

         target node address: the address of the node to communicate
         with over the cell(s).  In case of broadcast cells this is the
         broadcast address.

         TrackID: ID of the track the cell(s) will belong to.

Wang, et al.             Expires August 4, 2014                [Page 12]
Internet-Draft            6tisch-6top-interface             January 2014

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

   6top is responsible for picking the exact slotOffset and
   channelOffset in the schedule, and ensure that the target node choose
   the same cell and TrackID. 6top marks these cells as soft cell,
   indicating that it will continuously monitor their performance and
   reschedule if needed.  The return value is CellID, and the created
   cell is also filled in CellList (Section 4.1).

   6top deals with the allocation process by negotiation with the target
   node.  The command returns the list of created cells defined by
   (slotframe ID, slotOffset, channelOffset).  It fails if the required
   number of cells is higher than the available number of cells in the
   schedule.  It fails if the negotiation with the target node fails.
   It fails if the LinkOption bitmap indicates that the cell(s) MUST be
   Hard.

   The interaction between 6top and TSCH happens on both sides described
   as follows.

   For example, after neigotiation, node A and node B find a specifical
   cell, slotOffset=10, channelOffset=12, as a Tx cell and Rx cell,
   respectively, then the 6top in node A and node B will call the
   premitive MLME-SET-LINK.request defind in section 6.2.19.3 of
   [IEEE802154e], respectively.  The premitive parameters are set in
   node A and node B as follows.

   +---------------------------------+---------------------------------+
   | MLME-SET-LINK.request parameter | set by A's 6top | set by B's top|
   +---------------------------------+---------------------------------+
   |    operation                    | ADD-LINK        | ADD-LINK      |
   +---------------------------------+---------------------------------+
   |    LinkHandle                   | CellID          | CellID        |
   +---------------------------------+---------------------------------+
   |    slotframeHandle              | slotframe ID    | slotframe ID  |
   +---------------------------------+---------------------------------+
   |    timeslot                     | 10              | 10            |
   +---------------------------------+---------------------------------+
   |    channelOffset                | 12              | 12            |
   +---------------------------------+---------------------------------+
   |    LinkOptions                  | Tx              | Rx            |
   +---------------------------------+---------------------------------+
   |    LinkType                     | NORMAL          | NORMAL        |
   +---------------------------------+---------------------------------+
   |    nodeAddr                     | Node A          | Node B        |
   +---------------------------------+---------------------------------+

Wang, et al.             Expires August 4, 2014                [Page 13]
Internet-Draft            6tisch-6top-interface             January 2014

   If the Status from MLME-SET-LINK.confirm defined in section 6.2.19.4
   of [IEEE802154e], 6top will notify upper layer failure.

3.3.1.3.  READ.cell

   Given a (slotframe ID, slotOffset, channelOffset), retrieves the cell
   information.  Fails if the cell does not exist.  The returned
   information contains:

         slotframe ID: ID of the slotframe where this cell is installed.

         slotOffset: the slotOffset for the cell.

         channelOffset: the selected channelOffset for the cell.

         LinkOption bitmap: bitmap as defined in [IEEE802154e]

         CellType: as defined in Section 3.1

         target node address: the target address of that cell.  In case
         of broadcast cells this is the broadcast address.

         TrackID: ID of the track the cell will belong to.

         NumOfStatistics: Number of elements in the following list of
         tuple (StatisticsMetriceID and StatisticsValue)

         list of (StatisticsMetriceID, StatisticsValue):
         StatisticsMetriceID is the index to Statistics Metric defined
         in Section 3.3.4, StatisticsValue is the value corresponding to
         the metric indexd by StatisticsMetriceID

   A read command can be issued for any cell, hard or soft. 6top gets
   cell information from CellList (Section 4.1).

3.3.1.4.  UPDATE.cell

   Update a hard cell, i.e., re-allocate it to a different slotOffset
   and/or channelOffset.  Fails if the cell does not exist.  Requires
   both old (slotframe ID, slotOffset, channelOffset) and new (slotframe
   ID, slotOffset, channelOffset) as parameters.  And, the type of cell,
   target node address and TrackID are the fields that cannot be
   updated.  Soft cells MUST NOT be updated by the UPDATE.cell command.
   REALLOCATE.softcell (Section 3.3.1.7) MUST be used instead.

   It causes a old cell being removed and a new cell being created.

Wang, et al.             Expires August 4, 2014                [Page 14]
Internet-Draft            6tisch-6top-interface             January 2014

3.3.1.5.  DELETE.hardcell

   To remove a hard cell, the upper layer specifies:

         slotframe ID: the ID of the slotframe where this cell is
         installed.

         slotOffset: the slotOffset for the cell.

         channelOffset: the selected channelOffset for the cell.

         LinkOption bitmap: bitmap as defined in [IEEE802154e]

         LinkType : as defined in in section 6.2.19.3 of [IEEE802154e].

         CellType: as defined in Section 3.1

         target node address: the target address of that cell.  In case
         of broadcast cells this is the broadcast address.

         TrackID: ID of the track the cell will belong to.

   This removes the hard cell from the node's schedule, from CellList
   (Section 4.1)as well.

   The interaction between 6top and MAC layer caused by DELETE.hardcell
   is as follows.

   Firstly, 6top calls the premitive MLME-SET-LINK.request defind in
   section 6.2.19.3 of [IEEE802154e].  The premitive parameters are set
   as follows.

Wang, et al.             Expires August 4, 2014                [Page 15]
Internet-Draft            6tisch-6top-interface             January 2014

   +---------------------------------+---------------------------------+
   | MLME-SET-LINK.request parameter |          set by 6top            |
   +---------------------------------+---------------------------------+
   |    operation                    |   DELETE-LINK                   |
   +---------------------------------+---------------------------------+
   |    LinkHandle                   |   CellID                        |
   +---------------------------------+---------------------------------+
   |    slotframeHandle              |   slotframe ID                  |
   +---------------------------------+---------------------------------+
   |    timeslot                     |   slotOffset                    |
   +---------------------------------+---------------------------------+
   |    channelOffset                |   channelOffset                 |
   +---------------------------------+---------------------------------+
   |    LinkOptions                  |   LinkOption bitmap             |
   +---------------------------------+---------------------------------+
   |    LinkType                     |   LinkType                      |
   +---------------------------------+---------------------------------+
   |    nodeAddr                     |   target node address           |
   +---------------------------------+---------------------------------+

   Secondly, if the status from MLME-SET-LINK.confirm defined in section
   6.2.19.4 of [IEEE802154e] is SUCCESS, then remove the LinkHandle from
   its BundleList specified by TrackID, and confirm to upper layer with
   status = SUCCESS; otherwise, confirm to upper layer with status =
   FAIL.

3.3.1.6.  DELETE.softcell

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

         slotframe ID: ID of the slotframe where this cell is installed.

         number of cells: the number of cells to be removed

         LinkOption bitmap: bitmap as defined in [IEEE802154e]

         CellType: as defined in Section 3.1

         target node address: the target address of that cell.  In case
         of broadcast cells this is the broadcast address.

         TrackID: ID of the track the cell will belong to.

   In the case a soft cell wants to be re-allocated from the allocated
   cell so a hard cell can be installed instead, the REALLOCATE.softcell
   (Section 3.3.1.7) MUST be used.

Wang, et al.             Expires August 4, 2014                [Page 16]
Internet-Draft            6tisch-6top-interface             January 2014

   After the pair of nodes figure out the specific cell(s) to be
   removed, the interaction between 6top and TSCH on both sides will be
   similar to that caused by DELETE.hardcell, except LinkType should be
   set to NORMAL.

3.3.1.7.  REALLOCATE.softcell

   To force a re-allocation of a soft cell, the upper layer specifies:

         slotframe ID: ID of the slotframe where the cell is allocated.

         slotOffset: the slotOffset for that cell.

         channelOffset: the channelOffset for that cell.

   The reallocated cell will be installed in a different slotOffset,
   channelOffset but slotframe and TrackID remain the same.  Hard cells
   MUST NOT be reallocated.

   The interaction between 6top and TSCH caused by this command includes
   that described in Section 3.3.1.6 and Section 3.3.1.2.

3.3.2.  Slotframe Commands

   6top provides the following commands to manage TSCH slotframes.

3.3.2.1.  CREATE.slotframe

   Creates a new slotframe.  The command requires:

         slotframe ID: unique identifier of the slotframe, corresponding
         to its priority.

         number of timeslots: the required number of timeslots in the
         slotframe.

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

   The interaction between 6top and MAC layer caused by CREATE.slotframe
   is as follows.

   Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind
   in section 6.2.19.1 of [IEEE802154e].  The premitive parameters are
   set as follows.

Wang, et al.             Expires August 4, 2014                [Page 17]
Internet-Draft            6tisch-6top-interface             January 2014

   +---------------------------------+---------------------------------+
   | MLME-SET-SLOTFRAME.request      |                                 |
   |         parameter               |          set by 6top            |
   +---------------------------------+---------------------------------+
   |    slotframeHandle              |   slotframe ID                  |
   +---------------------------------+---------------------------------+
   |    operation                    |   ADD                           |
   +---------------------------------+---------------------------------+
   |    size                         |   number of timeslot            |
   +---------------------------------+---------------------------------+

   Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in
   section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper
   layer with status = SUCCESS; otherwise, confirm to upper layer with
   status = FAIL.

3.3.2.2.  READ.slotframe

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

         slotframe ID: ID of the slotframe.  (SlotFrameHandle)

         number of timeslots: the number of timeslots in the slotframe.

   Fails if the slotframe ID does not exist.

   TODO: access a specific slotframe with PIBAttribute of MLME-
   GET.request

3.3.2.3.  UPDATE.slotframe

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

         slotframe ID: ID of the slotframe.

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

   Fails if the number of required timeslots is less than zero.  Fails
   if the slotframe ID does not exist.

   The interaction between 6top and MAC layer caused by UPDATE.slotframe
   is as follows.

   Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind
   in section 6.2.19.1 of [IEEE802154e].  The premitive parameters are
   set as follows.

Wang, et al.             Expires August 4, 2014                [Page 18]
Internet-Draft            6tisch-6top-interface             January 2014

   +---------------------------------+---------------------------------+
   | MLME-SET-SLOTFRAME.request      |                                 |
   |         parameter               |          set by 6top            |
   +---------------------------------+---------------------------------+
   |    slotframeHandle              |   slotframe ID                  |
   +---------------------------------+---------------------------------+
   |    operation                    |   MODIFY                        |
   +---------------------------------+---------------------------------+
   |    size                         |   number of timeslot            |
   +---------------------------------+---------------------------------+

   Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in
   section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper
   layer with status = SUCCESS; otherwise, confirm to upper layer with
   status = FAIL.

3.3.2.4.  DELETE.slotframe

   Deletes a slotframe.  The command requires:

         slotframe ID: ID of the slotframe.

         number of timeslot: the number of timeslots in the slotframe.

   Fails if the slotframe ID does not exist.

   The interaction between 6top and MAC layer caused by DELETE.slotframe
   is as follows.

   Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind
   in section 6.2.19.1 of [IEEE802154e].  The premitive parameters are
   set as follows.

   +---------------------------------+---------------------------------+
   | MLME-SET-SLOTFRAME.request      |                                 |
   |         parameter               |          set by 6top            |
   +---------------------------------+---------------------------------+
   |    slotframeHandle              |   slotframe ID                  |
   +---------------------------------+---------------------------------+
   |    operation                    |   DELETE                        |
   +---------------------------------+---------------------------------+
   |    size                         |   number of timeslot            |
   +---------------------------------+---------------------------------+

   Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in
   section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper
   layer with status = SUCCESS; otherwise, confirm to upper layer with
   status = FAIL.

Wang, et al.             Expires August 4, 2014                [Page 19]
Internet-Draft            6tisch-6top-interface             January 2014

3.3.3.  Monitoring Commands

   Monitoring commands provide the means for upper layers to configure
   whether 6top must ensure the required bandwidth.  This procedure is
   achieved through overprovisioning according to cell status feedback.
   Monitoring is also in charge of reallocating soft cells that are
   under the required QoS.

3.3.3.1.  CONFIGURE.monitoring

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

         slotframe ID: ID of the slotframe.

         target node address: the target neighbor address.

         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.

3.3.3.2.  READ.monitoring.status

   Reads the current Monitoring status.  Requires the following
   parameters.

         slotframe ID: the ID of the slotframe.

         target node address: the target neighbor address.

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

         allocated_hard: Number of hard cells allocated.

         allocated_soft: Number of soft cells allocated.

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

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

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

Wang, et al.             Expires August 4, 2014                [Page 20]
Internet-Draft            6tisch-6top-interface             January 2014

   Fails if the slotframe ID does not exist.

3.3.4.  Statistics Commands

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

3.3.4.1.  CONFIGURE.statistics

   Configures Statistics process.  The command requires:

         slotframe ID: ID of the slotframe.  If empty monitors all
         slotframe IDs

         slotOffset: specific slotOffset to be monitored.  If empty all
         timeslots are monitored

         channelOffset: specific channelOffset to be monitored.  If
         empty all channels are monitored.

         target node address: the target neighbor address.  If empty,
         all neighbor 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 timeslot, etc.  The CONFIGURE.statistics
   enables flexible configuration and supports empty parameters that
   will force 6top to conduct statistics on all members of that
   dimension.  For example, if ChannelOffset is empty and metric is set
   as PDR, then, 6top will conduct the statistics of PDR on all of
   channels.

3.3.4.2.  READ.statistics

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

Wang, et al.             Expires August 4, 2014                [Page 21]
Internet-Draft            6tisch-6top-interface             January 2014

         slotframe ID: ID of the slotframe.  If empty aggregates
         information of all slotframe IDs

         slotOffset: the specific slotOffset for which the information
         is required.  If empty all timeslots are aggregated

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

         target node address: the target neighbor address.  If empty all
         neighbor addresses are aggregated.

         metric: metric to be read.

   Returns the value for the requested metric.

   Fails if empty metric or metric does not exits.

3.3.4.3.  RESET.statistics

   Resets the gathered statistics.  The command requires:

         slotframe ID: ID of the slotframe.  If empty resets the
         information of all slotframe IDs

         slotOffset: the specific slotOffset for which the information
         wants to be reset.  If empty statistics from all timeslots are
         reset

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

         target node address: the target neighbor address.  If empty all
         neighbor addresses are aggregated.

         metric: metric to be reset.

   Fails if empty metric or metric does not exits.

3.3.5.  Network Formation Commands

   EBs need to be configured, including their transmission period, the
   slotOffset and channelOffset that they SHOULD be sent on, and the
   join priority they contain.  The parameters for that command are
   optional and enable 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

Wang, et al.             Expires August 4, 2014                [Page 22]
Internet-Draft            6tisch-6top-interface             January 2014

   configured slotOffset is allocated.  The slotOffset enforces the EB
   to a specific timeslot.  In case slotOffset parameter is not present,
   the EB is sent in the first available transmit timeslot.  In case
   channelOffset parameter is not set, the EB is configured to use the
   first available channel.

3.3.5.1.  CONFIGURE.eb

   Configures EBs.  The command requires:

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

         slotOffset: the slotOffset where the EBs MUST be sent.  Zero if
         any timeslot can be used.

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

         period: the EBs period, in seconds.

         Expiration: 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 or DAGRANK(rank) as
         decribed in in [I-D.vilajosana-6tisch-minimal].

   Fails if the tuple (slotframe ID, slotOffset, channelOffset) is
   already scheduled.

3.3.5.2.  READ.eb

   Reads the EBs configuration.  No parameters are required.

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

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

         slotOffset: the slotOffset where the EBs is being sent.

         channelOffset: the channelOffset the EBs is being sent on.

         period: the EBs period.

Wang, et al.             Expires August 4, 2014                [Page 23]
Internet-Draft            6tisch-6top-interface             January 2014

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

3.3.6.  Time Source Neighbor Commands

   Commands to select time source neighbors.

3.3.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 source
         neighbor.  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.

3.3.6.2.  READ.timesource

   Retrieves information about the time source neighbors 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 source neighbor.

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

         policy: the used policy

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

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

Wang, et al.             Expires August 4, 2014                [Page 24]
Internet-Draft            6tisch-6top-interface             January 2014

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

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

3.3.7.3.  READ.neighbor

   Returns the information of a specific neighbor 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.

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

Wang, et al.             Expires August 4, 2014                [Page 25]
Internet-Draft            6tisch-6top-interface             January 2014

3.3.7.5.  DELETE.neighbor

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

3.3.8.  Queueing Commands

   Queues need to be configured.  This includes queue length,
   retransmission policy, discarding of packets, etc.

3.3.8.1.  CREATE.queue

   Creates and Configures 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 backoff in number of slotframes. 0
         if next available timeslot wants to be used.

         statswindow: window of time used to compute stats.

         queue priority: the priority of this queue.

         TrackIDs: a set of TrackIDs.  While it is empty, no specific
         track is associated with the queue

   Returns the queue ID.

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

Wang, et al.             Expires August 4, 2014                [Page 26]
Internet-Draft            6tisch-6top-interface             January 2014

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

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

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

         TrackIDs: a set of TrackIDs.

3.3.8.4.  UPDATE.queue

   Update a Queue.  The command requires:

         queueid: the queue ID.

         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 backoff in number of slotframes. 0
         if next available timeslot wants to be used.

Wang, et al.             Expires August 4, 2014                [Page 27]
Internet-Draft            6tisch-6top-interface             January 2014

         statswindow: window of time used to compute stats.

         queue priority: the desired priority of this queue.

         TrackIDs: the desired set of TrackIDs.

3.3.8.5.  DELETE.queue

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

3.3.9.  Data Commands

3.3.9.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 scope.  Once a packet is inserted into a queue it waits to be
   transmitted by TSCH according to the model defined in Section 3.2.
   If the queue is full or destination address is not a L2 neighbor of
   the node, failure to enqueue will be indicated to the caller.

   The required parameters are:

         src address: L2 address

         dest address: L2 unicast or broadcast address

         priority: packet priority, usually is consistent with queue
         priority

         message length: the length of the message

         message: control message or data message

         securityLevel:As defined by [IEEE802154e].

3.3.9.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
   terminate this indication.

   The function has the following parameters:

         src address: L2 source address

Wang, et al.             Expires August 4, 2014                [Page 28]
Internet-Draft            6tisch-6top-interface             January 2014

         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

3.3.10.  Label Switching Commands

3.3.10.1.  LabelSwitching.map

   The command used by an upper layer to map an input cell or a bundle
   of input cells to an output cell or a bundle of output cells. 6top
   stores this mapping and makes sure that the packets are forwarded at
   the specific output cell/bundle.  Label Switching is enabled by the
   specified bundle as soon as the mapping is installed.

   The required parameters are:

         input cells: list of input cells (one or more cells in a
         bundle).  Each input cells is described by an unique tuple
         (slotOffset, channelOffset, destination address).

         output cells: list of output cells (one or more cells in a
         bundle).  Each output cells is described by an unique tuple
         (slotOffset, channelOffset, destination address).

         load balancing policy: A policy for load balance cell usage.
         The policy is out of scope, however an example can be use ROUND
         ROBIN policy within the cells of the same bundle.

3.3.10.2.  LabelSwitching.unmap

   The command used by upper layers to unmap one input cell or a bundle
   of input cells to an output cell or a bundle of output cells.  The
   mapping is removed from the state kept by 6top.

   The required parameters are:

         input cells: list of input cells (one or more cells in a
         bundle).  Each input cells is described by an unique tuple
         (slotOffset, channelOffset, destination address).

         output cells: list of output cells (one or more cells in a
         bundle).  Each output cells is described by an unique tuple
         (slotOffset, channelOffset, destination address).

Wang, et al.             Expires August 4, 2014                [Page 29]
Internet-Draft            6tisch-6top-interface             January 2014

3.3.11.  Chunk Command

3.3.11.1.  Create.chunk

   Create a chunk which consists of one or more unappropriated cells.

   To create a chunk, upper layer specifies:

         slotframe ID: ID of the slotframe which this chunk belongs to.

         NumOfCells: number of the cells which the chunk includes.

         list of (slotOffset, channelOffset):

                  slotOffset: the slotOffset for the cell.

                  channelOffset: channelOffset for the cell.

   ChunkID is the return value of the command (Section 4.1).

3.3.11.2.  Delete.chunk

   To delete a chunk, upper layer specifies ChunkID.

   It removes the chunk from ChunkList (Section 4.1).  It also causes
   all of the appropriated cells in the chunk are deleted from CellList
   (Section 4.1) and TSCH schedule as well.

3.3.12.  Chunk Cell Command

3.3.12.1.  CREATE.hardcell.fromchunk

   Creates one or more hard cells from a chunk.  Fails if the cell
   already exists.  A cell is uniquely identified by the tuple
   (slotframe ID, slotOffset, channelOffset).

   To create a hard cell from a chunk which is corresponding to a
   specific slotframe ID, the upper layer specifies:

         chunkID: ID of the chunk which this cell belongs to.

         slotOffset: the slotOffset for the cell.

         channelOffset: channelOffset for the cell.

         LinkOption bitmap: bitmap as defined in [IEEE802154e]

         LinkType : as defined in section 6.2.19.3 of [IEEE802154e].

Wang, et al.             Expires August 4, 2014                [Page 30]
Internet-Draft            6tisch-6top-interface             January 2014

         CellType: as defined in Section 3.1

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

         TrackID: ID of the track the cell will belong to.

   6top schedules the cell and marks it as a hard cell, indicating that
   it cannot reschedule this cell.  In addition, 6top will change the
   attributes corresponding to the cell in the ChunkList, i.e. its
   CellID is changed to the same CellID in the CellList, and its Status
   is changed to APPROPRIATED (Section 4.1).

   The interaction between 6top and MAC layer caused by
   CREATE.hardcell.fromchunk is same as that caused by CREATE.hardcell
   (Section 3.3.1.1).

3.3.12.2.  DELETE.hardcell.fromchunk

   To remove a hard cell which comes from a chunk, the upper layer
   specifies:

         slotframe ID: the ID of the slotframe where this cell is
         installed.

         slotOffset: the slotOffset for the cell.

         channelOffset: the selected channelOffset for the cell.

         LinkOption bitmap: bitmap as defined in [IEEE802154e]

         LinkType : as defined in in section 6.2.19.3 of [IEEE802154e].

         CellType: as defined in Section 3.1

         target node address: the target address of that cell.  In case
         of broadcast cells this is the broadcast address.

         TrackID: ID of the track the cell will belong to.

   This removes the hard cell from the node's schedule and CellList
   (Section 4.1).  In addition, it changes the attributes corresponding
   to the cell in the ChunkList, i.e. its CellID is changed back to
   FFFF, and its Status is changed to UNAPPROPRIATED (Section 4.1).

   The interaction between 6top and MAC layer caused by DELETE.hardcell
   is same as that caused by DELETE.hardcell (Section 3.3.1.5).

Wang, et al.             Expires August 4, 2014                [Page 31]
Internet-Draft            6tisch-6top-interface             January 2014

4.  Generic Data Model

   YANG model is used to express the generic data model as follows.  The
   data model includes that corresponding to 6top MIB, part of
   [IEEE802154] PIB and part of [IEEE802154e] PIB.

4.1.  YANG model of 6top MIB

    list CellList {
       key "CellID";

       description
       "List of of scheduled cells of a node with all of its neighbors,
       in all of its slotframes.";

       leaf CellID {
          type uint16;
          description
          "equal to Linkhandle in the linkTable of TSCH";
          reference
          "IEEE802154e";
       }
       leaf SlotframeID {
          type uint8;
          description
          "equal to SlotframeHandle defined in TSCH";
          reference
          "IEEE802154e";
       }
       leaf SlotOffset {
          type uint16;
          description
          "Defined in IEEE802154e.";
          reference
          "IEEE802154e";
       }
       leaf ChannelOffset {
          type uint8;
          description
          "Defined in IEEE802154e. Value range is 0..15";
          reference
          "IEEE802154e";
       }
       leaf LinkOption {
          type bits {
             bit Transmit {
                position 0;
             }

Wang, et al.             Expires August 4, 2014                [Page 32]
Internet-Draft            6tisch-6top-interface             January 2014

             bit Receive {
                position 1;
             }
             bit Share {
                position 2;
             }
             bit Timekeeping {
                position 3;
             }
             bit Reserved1 {
                position 4;
             }
             bit Reserved2 {
                position 5;
             }
             bit Reserved3 {
                position 6;
             }
             bit Reserved4 {
                position 7;
             }
          }
          description
          "Defined in IEEE802154e.";
          reference
          "IEEE802154e";
       }
       leaf LinkType {
          type enumeration {
             enum NORMAL;
             enum ADVERTISING;
          }
          description
          "defined in IEEE802154";
          reference
          "IEEE802154";
       }
       leaf CellType {
          type enumeration {
             enum SOFT;
             enum HARD;
          }
          description
          "defined in 6top";
       }
       leaf TargetNodeAddress {
          type uint64;
          description

Wang, et al.             Expires August 4, 2014                [Page 33]
Internet-Draft            6tisch-6top-interface             January 2014

          "defined by 6top, but being constrained by TSCH macNodeAddress
          size, 2-octets. If using TSCH as MAC, higher 6-octets should
          be filled with "0", and lowest 2-octets is neighbor address";
       }
       leaf TrackID {
          type uint16;
          description
          "A TrackID is a tuple (TrackOwnerAddr,InstanceID), where
          TrackOwnerAddr is the address of the node which initializes
          the process of creating the track, i.e., the owner of the
          track; and InstanceID is an instance identifier given by the
          owner of the track.";
       }
       container Statistic {
          leaf NumOfStatistic {
             type uint8;
             description
             "number of statistics conducted on the cell";
          }
          list MeasureList {
             key "StatisticsMetricsID";
             leaf StatisticsMetricsID{
                type uint16;
             }
             leaf StatisticsValue{
                type uint16;
             }
          }
       }
    }

   list SlotframeList {
      key "SlotframeID";
      leaf SlotframeID {
         type uint8;
      }
      leaf NumOfSlots {
         type uint16;
      }
   }

   list MonitoringStatusList {
      key "MonitoringStatusID";
      leaf MonitoringStatusID {
         type uint16;
      }
      leaf SlotframeID {
         type uint8;

Wang, et al.             Expires August 4, 2014                [Page 34]
Internet-Draft            6tisch-6top-interface             January 2014

      }
      leaf TargetNodeAddress {
         type uint64;
      }
      leaf EnforcePolicy {
         type enumeration {
            enum DISABLE;
            enum BESTEFFORT;
            enum STRICT;
            enum OVERPROVISION;
         }
         description
         "current enforced QoS policy";
      }
      leaf AllocatedHard {
         type uint16;
         description
         "Number of hard cells allocated";
      }
      leaf AllocatedSoft {
         type uint16;
         description
         "Number of soft cells allocated";
      }
      leaf OverProvision {
         type uint16;
         description
         "Overprovisioned cells. 0 if CONFIGURE.qos enforce is DISABLE";
      }
      leaf QoS {
         type uint16;
         description
         "Current QoS including overprovisioned cells, i.e. the
         bandwidth obtained including the overprovisioned cells.";
      }
      leaf NQoS {
         type uint16;
         description
         "real QoS without provisioned cells, i.e. the actual bandwidth
         without taking into account the overprovisioned cells.";
      }
   }

 list StatisticsMetricsList {
    key "StatisticsMetricsID";
    leaf StatisticsMetricsID {
       type uint16;
    }

Wang, et al.             Expires August 4, 2014                [Page 35]
Internet-Draft            6tisch-6top-interface             January 2014

    leaf SlotframeID {
       type uint16;
       description
       "ID of the slotframe.  If empty monitors all slotframe IDs";
       reference
       "IEEE802154e";
    }
    leaf SlotOffset {
       type uint16;
       description
       "Specific slotOffset to be monitored.  If empty all timeslots are
        monitored";
       reference
       "IEEE802154e";
    }
    leaf ChannelOffset {
       type uint8;
       description
       "Specific channelOffset to be monitored.  If empty all channels
        are monitored";
       reference
       "IEEE802154e";
    }
    leaf TargetNodeAddress {
       type uint64;
       description
       "If empty, all neighbor nodes are monitored.";
    }
    leaf Metrics {
       type enumeration {
          enum PDR;
          enum ETX;
          enum RSSI;
          enum LQI;
       }
       description
       "The metric to be monitored.";
    }
    leaf Window {
       type uint16;
       description
       "measurement period, in Number of the slotframe size";
    }
    leaf Enable {
       type enumeration {
          enum DISABLE;
          enum ENABLE;
       }

Wang, et al.             Expires August 4, 2014                [Page 36]
Internet-Draft            6tisch-6top-interface             January 2014

    }
 }

   list EBList {
      key "EbID";
      leaf EbID {
         type uint8;
      }
      leaf CellID {
         type uint16;
         description
         "equal to LinkHandle in IEEE802154e";
      }
      leaf Peroid {
         type uint16;
         description
         "the EBs period, in seconds";
      }
      leaf Expiration {
         type enumeration {
            enum NEVERSTOP;
            enum EXPIRATION;
         }
         description
         "with Period to indicate when the EBs periodicity will stop.
         If Zero the period never stops.";
      }
      leaf Priority {
         type uint8;
         description
         "the joining priority model that will be used for advertisement.
         Joining priority MAY be for example SAME_AS_PARENT, RANDOM,
         BEST_PARENT+1 or DAGRANK(rank).";
      }
   }

Wang, et al.             Expires August 4, 2014                [Page 37]
Internet-Draft            6tisch-6top-interface             January 2014

   container TimeSource {
      leaf policy {
         type enumeration {
            enum ALLPARENT;
            enum BESTCONNECTED;
            enum LOWESTJOINPRIORITY;
         }
      }
      leaf TargetNodeAddress {
         type uint64;
         description
         "address of the time source neighbor";
      }
      leaf MinTimeCorrection {
         type uint16;
         description
         "in microsecond";
      }
      leaf MaxTimeCorrection {
         type uint16;
         description
         "in microsecond";
      }
      leaf AveTimeCorrection {
         type uint16;
         description
         "in microsecond";
      }
   }

Wang, et al.             Expires August 4, 2014                [Page 38]
Internet-Draft            6tisch-6top-interface             January 2014

   typedef asntype {
      description
         "the type to store ASN. String of 5 bytes";
      type string {
         length "0..5";
       }
   }

   list NeighborList {
      key "TargetNodeAddress";

      leaf TargetNodeAddress {
         type uint64;
         description
         "address of the time source neighbor";
      }

      leaf RSSI {
         type uint8;
         description
       "the received signal strength";
      }

      leaf LinkQuality {
       type uint8;
       description
       "the LQI metric";
       }

       leaf ASN {
          type asntype;
          description
              "the 5 ASN bytes";
        }
   }

   list QueueList {
     key "QueueId";

     leaf QueueId {
      type uint8;
      description
      "address of the time source neighbor";
     }
     leaf TxqLength {
      type uint8;
      description
      "the tx queue length in number of packets";

Wang, et al.             Expires August 4, 2014                [Page 39]
Internet-Draft            6tisch-6top-interface             January 2014

     }
     leaf RxqLength {
      type uint8;
      description
      "the rxqueue length in number of packets";
     }
     leaf NumrTx {
      type uint8;
      description
      "number of allowed retransmissions.";
     }
     leaf Age {
      type uint16;
      description
      "In seconds. Discard packet according to its age
       on the queue. 0 if no discards are allowed.";
     }

     leaf RTXbackoff {
      type uint8;
      description
      "retransmission backoff in number of slotframes.
       0 if next available timeslot wants to be used.";
     }

     leaf StatsWindow {
      type uint16;
      description
      "In second, window of time used to compute stats.";
     }

     leaf QueuePriority {
      type uint8;
      description
      "the priority for this queue.";
     }

     list TrackIds {
      key "TrackID";
      unique "TrackID";

      leaf TrackID{
       type uint16;
       description
       "the TrackID.";
      }
     }

Wang, et al.             Expires August 4, 2014                [Page 40]
Internet-Draft            6tisch-6top-interface             January 2014

     leaf MinLenTXQueue {
      type uint8;
      description
      "Statistics, lowest TX queue len registered in the window.";
     }

     leaf MaxLenTXQueue {
      type uint8;
      description
      "Statistics, largest TX queue len registered in the window.";
     }

     leaf AvgLenTXQueue {
      type uint8;
      description
      "Statistics, avg TX queue len registered in the window.";
     }

     leaf MinLenRXQueue {
      type uint8;
      description
      "Statistics, lowest RX queue len registered in the window.";
     }

     leaf MaxLenRXQueue {
      type uint8;
      description
      "Statistics, largest RX queue len registered in the window.";
     }

     leaf AvgLenRXQueue {
      type uint8;
      description
      "Statistics, avg RX queue len
       registered in the window.";
     }

     leaf MinRetransmissions {
      type uint8;
      description
      "Statistics, lowest number of
       retransmissions registered in the window.";
     }

     leaf MaxRetransmissions {
      type uint8;
      description
      "Statistics, largest number of retransmissions registered

Wang, et al.             Expires August 4, 2014                [Page 41]
Internet-Draft            6tisch-6top-interface             January 2014

       in the window.";
     }

     leaf AvgRetransmissions {
      type uint8;
      description
      "Statistics, average number of retransmissions registered
       in the window.";
     }

     leaf MinPacketAge {
      type uint16;
      description
      "Statistics, in seconds, minimum time a packet stayed in
       the queue during the observed window.";
     }

     leaf MaxPacketAge {
      type uint16;
      description
      "Statistics, in seconds, maximum time a packet stayed
       in the queue during the observed window.";
     }

     leaf AvgPacketAge {
      type uint16;
      description
      "Statistics, in seconds, average time a packet stayed in
       the queue during the observed window.";
     }

     leaf MinBackoff {
      type uint8;
      description
      "Statistics, in number of slotframes, minimum Backoff
       for a packet in the queue during the observed window.";
     }

     leaf MaxBackoff {
      type uint8;
      description
      "Statistics, in number of slotframes, maximum Backoff
       for a packet in the queue during the observed window.";
     }

     leaf AvgBackoff {
      type uint8;

Wang, et al.             Expires August 4, 2014                [Page 42]
Internet-Draft            6tisch-6top-interface             January 2014

      description
      "Statistics, in number of slotframes, average Backoff
       for a packet in the queue during the observed window.";
     }
    }

   list LabelSwitchList {
     key "LabelSwitchID";

     leaf LabelSwitchID {
      type uint16;
     }

     list InputCellIds {
      key "CellID";
      leaf CellID{
       type uint16;
       description
       "the CellID.";
      }
     }

     list OutputCellIds {
      key "CellID";
      leaf CellID{
       type uint16;
       description
       "the CellID.";
      }
     }

     leaf LoadBalancingPolicy {
      type enumeration {
       enum ROUNDROBIN;
       enum OTHER;
      }
      description
      "The Load Balancing policy.";
     }
    }

   list BundleList {
     key "BundleID";

     leaf BundleID {
      type uint8;
     }

Wang, et al.             Expires August 4, 2014                [Page 43]
Internet-Draft            6tisch-6top-interface             January 2014

     leaf TargetNodeAddress {
      type uint64;
      description
      "The destination address for this bundle.";
     }

     leaf TrackID{
        type uint16;
        description
        "the track which the bundle is associted";
     }

     list CellIds {
      key "CellID";
      leaf CellID{
       type uint16;
       description
       "the CellID.";
      }
     }

     leaf NumOfStatistics {
      type uint8;
      description
      "The number of statistics being monitored in the bundle.";
     }

     list Statistics {
      key "StatisticsMatriceId";

      leaf StatisticsMatriceId{
       type uint16;
       description
       "the Statistics List ID.";
      }

      leaf StatisticsValue{
       type uint16;
       description
       "Their meaning depends on the value of Metrics
        indexed by StatisticsMatriceId.";
      }
     }
   }

Wang, et al.             Expires August 4, 2014                [Page 44]
Internet-Draft            6tisch-6top-interface             January 2014

list TrackList {
   key "TrackId";

   leaf TrackId {
      type uint16;
   }
   leaf TrackOwnerAddr {
      type uint64;
      description
      "the address of the node which initializes the process of creating
      the track, i.e., the owner of the track;";
   }
   leaf InstanceID {
      type uint16;
      description
      "InstanceID is an instance identifier given by the owner of the
      track. InstanceID comes from upper layer; InstanceID could for
      example be the local instance ID defined in RPL.";
   }
  }
}

Wang, et al.             Expires August 4, 2014                [Page 45]
Internet-Draft            6tisch-6top-interface             January 2014

      list ChunkList {
         key "ChunkId";

         leaf ChunkId{
            type uint16;
            description
            "the id of a Chunk";
         }

         leaf SlotframeId{
            type uint8;
            description
            "the id of the slotframe that is mapped to this chunk";
         }

         list ChunkCells {
            key "SlotOffset ChannelOffset";

            leaf SlotOffset{
               type uint16;
               description
               "the slotoffset.";
            }

            leaf ChannelOffset{
               type uint16;
               description
               "the channeloffset.";
            }

            leaf CellID{
               type uint16;
               description
               "initial value of CellID is FFFF. When the cell is
               appropriated, the value of CellID is same as that in
               CellList";
            }

            leaf ChunkCellStatus {
               type enumeration {
                  enum UNAPPROPRIATED;
                  enum APPROPRIATED;
               }
            }
         }
      }

Wang, et al.             Expires August 4, 2014                [Page 46]
Internet-Draft            6tisch-6top-interface             January 2014

4.2.  YANG model of IEEE802.15.4 PIB

   This section describes the YANG model of the part of [IEEE802154] PIB
   used in 6top, such as security related attributes.  This part of data
   will be accessed by using primitives like MLME-GET and MLME-SET
   ([IEEE802154]).

   TODO

4.3.  YANG model of IEEE802.15.4e PIB

   This section describes the YANG model of the part of [IEEE802154e]
   PIB used in 6top, such as TSCH related attributes.  This part of data
   will be accessed by using primitives like MLME-GET and MLME-SET
   ([IEEE802154]).

   TODO

5.  Using 6top

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

5.1.  RPL on 6top

   6top 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 6top sublayer.

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

         RPL Neighbor Discovery and Parent Selection

         RPL Rank Computation

         RPL Control Messages Broadcast

         QoS

5.1.1.  Support to Neighbor Discovery and Parent Selection

   The Section 3.3.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 6top
   sublayer to create an entry to the neighbors table.  A neighbor table
   entry contains a set of statistics with respect to that specific

Wang, et al.             Expires August 4, 2014                [Page 47]
Internet-Draft            6tisch-6top-interface             January 2014

   neighbor such as the ASN when the last packet has been received from
   that neighbor, a set of cell quality metrics (RSSI, LQI), number of
   packets sent to it or number of packets received from it amongst
   others. 6top 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 for example
   the Zero Objective function as described in
   [I-D.vilajosana-6tisch-minimal].  Parent selection can also be driven
   by the information contained on the neighbor table as well as
   complemented with the cells statistics defined in Section 3.3.4.

   6top 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 3.3.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 3.3.6 describes the 6top command to set up the desired
   policy.  The policy is selected by RPL and enforced by the 6top
   sublayer.

   The rule for 6top to select and maintain time source neighbors is as
   follows:

         The time source neighbor of a node SHOULD be a member of the
         node's neighbor set.

         Time source neighbors SHOULD be the neighbors which have a
         relatively lower join priority in the neighbor set.  A lower
         join priority indicates that the neighbor is closer to the TSCH
         PAN coordinator.

         The link between a node and one of its time source neighbors
         SHOULD be a good link quality.

5.1.2.  Support of Rank Computation

   The RPL objective function is computed using a set of metrics.  The
   [I-D.vilajosana-6tisch-minimal] defines how Zero Objective Function
   is used to configure the rank and metrics used from 6top statistics.
   The specific metrics, and how the objective function is calculated
   are out of scope.  However, 6top builds a set of functionalities to
   provide more accurate statistics of the underlying layer so the

Wang, et al.             Expires August 4, 2014                [Page 48]
Internet-Draft            6tisch-6top-interface             January 2014

   objective function can be accommodated to the nature of a TSCH MAC
   layer.

   6top provides statistics for rank computation as described in
   Section 3.3.4.  The function used to compute the rank based on those
   statistics is out of scope.  However, the provided metrics are
   aligned to the behavior of the TSCH MAC layer.

5.1.3.  Support of Control Messages Broadcast

   In RPL, some control messages, e.g., DIO in storing mode, need to be
   broadcast to all neighbor nodes.  The broadcast channel requirement
   has to be addressed by 6top by configuring TSCH to provide such a
   channel.

   In order to decouple the upper (RPL) layer from TSCH, instead of
   carrying DIO messages in Enhance Beacons, 6top introduces a mechanism
   to establish broadcast cells.

   In TSCH schedule, every cell has the LinkType attribute.  If
   LinkType=ADVERTISING, indicates that the cell MAY be used to send an
   Enhanced Beacon.  When a node forms its Enhanced Beacon, the cell,
   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
   be listening at the cell to get the Enhanced Beacon ([IEEE802154e]).
   6top 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 broadcasts, 6top uses the payload of a Data
   Packet to carry the DIO or DAO.  The message is inserted into the
   queue associated with the cells which LinkType is set to ADVERTISING.
   Then, taking advantage of the broadcast cell feature established with
   FrameAndLinkIE as described above, the data packet with DIO or DAO in
   the payload can be received by neighbors, which enforces to the
   maintenance of DODAG.

   A LinkOption combining "Receive" and "Timekeeping" bits indicates to
   the receivers of the Enhanced Beacon that the cell MUST be used as a
   broadcast cell.  The frequency of sending Enhance Beacon or other
   broadcast messages by upper layer is determined by the timers
   associated with the messages.  For example, the transmission of
   Enhance Beacons is triggered by a timer in 6top; transmission of a
   DIO message is triggered by the trickle timer of RPL.

Wang, et al.             Expires August 4, 2014                [Page 49]
Internet-Draft            6tisch-6top-interface             January 2014

5.1.4.  Support for QoS

   The TSCH MAC layer is decoupled from the upper layer, and the
   interaction between the upper layer ad TSCH is asynchronous.  This
   means that the MAC layer executes a schedule and checks at each
   timeslot according to the type of cell whether there is something to
   send or receive.  If that is the case the packet is transmitted 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 send it in a particular timeslot according to is
   destination and priority (Section 3.2). 6top provides a set of queue
   management operations which enable upper layers to create different
   queues and determine their priorities.  This allows different classes
   of traffic to be handled by the routing layer, i.e. inserting a
   packet to a specific queue according to its priority.

   A 6top implement MUST provide at least a Broadcast Queue, a Transmit
   Queue, and a Receive Queue.  RPL can configure the queues with
   Internal Queueing Command (Section 3.3.8.1).  The Broadcast Queue is
   associated with cells with LinkType=ADVERTISING in sender's schedule,
   and LinkOption="Receive" and "Timekeeping" in all neighbors'
   schedule.  This indicates that the cells can be used as broadcast
   cells from the sender to its neighbors.  A Transmit Queue is
   associated with the dedicated Transmit cells or Shared Cells.  RPL
   can benefit from having different priority queues to improve latency
   or provide integrated services with different priorities, i.e.
   different traffic classes.

   Data Communication Commands (Section 3.3.9) 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. 6top is responsible for feeding these packets to TSCH at
   broadcast cells.

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

   6top conducts a QoS policy, which is out of scope.  Here is an
   example.  Packets in higher priority queue MUST be sent out before

Wang, et al.             Expires August 4, 2014                [Page 50]
Internet-Draft            6tisch-6top-interface             January 2014

   the packets in lower priority queue.  Then, when there is an
   available broadcast/unicast cell, 6top checks the broadcast/unicast
   queue with higher priority first, if there is a packet, then feeds it
   to TSCH at the cell, otherwise it checks broadcast/unicast queue with
   lower priority further. 6top repeats the process, until it finds a
   broadcast/unicast packet to feed to TSCH or finds that all of
   broadcast/unicast queues are empty.

5.2.  GMPLS on 6top

   GMPLS is a 2.5 layer service that is used to forward packets based on
   the concept of generalized labels.  Labels are determined by a
   reservation protocol during the formation of a multi-hop 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 written implicitly into a field in
   each packet, as is the case in MPLS [RFC3031], the generalized label
   is kept at each node in the form of a table.  The table can be used
   to map input cells to output cells so routing decisions can be taken
   at that layer.

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

         Cell Reservation Support

         QoS

5.2.1.  Cell Reservation Support for GMPLS on 6top

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

   The [I-D.vilajosana-6tisch-minimal] defines a pre-configured schedule
   that can be used to bootstrap the network.  Those cells can be seen
   as a GMPLS control plane where RPL routes can be formed and Track
   reservations issued.

Wang, et al.             Expires August 4, 2014                [Page 51]
Internet-Draft            6tisch-6top-interface             January 2014

   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. 6top provides commands (Section 3.3.8) to manage MAC layer
   queues and assign different priorities to them.

5.2.2.  Supporting QoS

   GMPLS can use 6top statistics to determine whether some QoS
   requirement is met.  Operations defined in Section 3.3.4 can be used
   by GMPLS to trigger new bandwidth allocation, or to map different
   input bundles to output bundles.

6.  References

6.1.  Normative References

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

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

Wang, et al.             Expires August 4, 2014                [Page 52]
Internet-Draft            6tisch-6top-interface             January 2014

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

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

Wang, et al.             Expires August 4, 2014                [Page 53]
Internet-Draft            6tisch-6top-interface             January 2014

   [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.watteyne-6tsch-tsch-lln-context]
              Watteyne, T., Palattella, M., and L. Grieco, "Using
              IEEE802.15.4e TSCH in an LLN context: Overview, Problem
              Statement and Goals", draft-watteyne-6tsch-tsch-lln-
              context-02 (work in progress), May 2013.

   [I-D.thubert-6tisch-architecture]
              Thubert, P., Watteyne, T., and R. Assimiti, "An
              Architecture for IPv6 over the TSCH mode of IEEE
              802.15.4e", draft-thubert-6tisch-architecture-01 (work in
              progress), October 2013.

   [I-D.palattella-6tisch-terminology]
              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terminology in IPv6 over the TSCH mode of IEEE
              802.15.4e", draft-palattella-6tisch-terminology-00 (work
              in progress), October 2013.

   [I-D.vilajosana-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", draft-vilajosana-6tisch-minimal-00 (work
              in progress), October 2013.

   [I-D.ohba-6tsch-security]
              Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and
              A. Yegin, "Security Framework and Key Management Protocol
              Requirements for 6TSCH", draft-ohba-6tsch-security-01
              (work in progress), July 2013.

   [I-D.thubert-roll-forwarding-frags]
              Thubert, P. and J. Hui, "LLN Fragment Forwarding and
              Recovery", draft-thubert-roll-forwarding-frags-02 (work in
              progress), September 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 August 4, 2014                [Page 54]
Internet-Draft            6tisch-6top-interface             January 2014

   [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., "Terms used in Routing for Low power And
              Lossy Networks", draft-ietf-roll-terminology-13 (work in
              progress), October 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-17
              (work in progress), March 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-05 (work in progress), August 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., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-18
              (work in progress), June 2013.

Wang, et al.             Expires August 4, 2014                [Page 55]
Internet-Draft            6tisch-6top-interface             January 2014

6.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) Amendment 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/>.

   [label-switching-154e]
              Morell, A., Vilajosana, X., Lopez-Vicario, J., and T.
              Watteyne, "Label Switching over IEEE802.15.4e Networks.
              Transactions on Emerging Telecommunications Technologies",
              June 2013.

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

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

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

Wang, et al.             Expires August 4, 2014                [Page 56]
Internet-Draft            6tisch-6top-interface             January 2014

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

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

Wang, et al.             Expires August 4, 2014                [Page 57]