[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

6TiSCH                                                      Q. Wang, Ed.
Internet-Draft                           Univ. of Sci. and Tech. Beijing
Intended status: Informational                             X. Vilajosana
Expires: August 18, 2014                 Universitat Oberta de Catalunya
                                                             T. Watteyne
                                                       Linear Technology
                                                       February 14, 2014


                    6TiSCH Operation Sublayer (6top)
                   draft-wang-6tisch-6top-sublayer-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 18, 2014.





Wang, et al.             Expires August 18, 2014                [Page 1]


Internet-Draft            6tisch-6top-sublayer             February 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . .   5
     2.1.  Cell Model  . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.1.  hard cells  . . . . . . . . . . . . . . . . . . . . .   7
       2.1.2.  soft cells  . . . . . . . . . . . . . . . . . . . . .   8
     2.2.  Data Transfer Model . . . . . . . . . . . . . . . . . . .   8
   3.  6top Commands . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Cell Commands . . . . . . . . . . . . . . . . . . . . . .  13
       3.1.1.  CREATE.hardcell . . . . . . . . . . . . . . . . . . .  13
       3.1.2.  CREATE.softcell . . . . . . . . . . . . . . . . . . .  15
       3.1.3.  READ.cell . . . . . . . . . . . . . . . . . . . . . .  16
       3.1.4.  UPDATE.cell . . . . . . . . . . . . . . . . . . . . .  17
       3.1.5.  DELETE.hardcell . . . . . . . . . . . . . . . . . . .  17
       3.1.6.  DELETE.softcell . . . . . . . . . . . . . . . . . . .  18
       3.1.7.  REALLOCATE.softcell . . . . . . . . . . . . . . . . .  19
     3.2.  Slotframe Commands  . . . . . . . . . . . . . . . . . . .  19
       3.2.1.  CREATE.slotframe  . . . . . . . . . . . . . . . . . .  19
       3.2.2.  READ.slotframe  . . . . . . . . . . . . . . . . . . .  20
       3.2.3.  UPDATE.slotframe  . . . . . . . . . . . . . . . . . .  20
       3.2.4.  DELETE.slotframe  . . . . . . . . . . . . . . . . . .  21
     3.3.  Monitoring Commands . . . . . . . . . . . . . . . . . . .  22
       3.3.1.  CONFIGURE.monitoring  . . . . . . . . . . . . . . . .  22
       3.3.2.  READ.monitoring.status  . . . . . . . . . . . . . . .  22
     3.4.  Statistics Commands . . . . . . . . . . . . . . . . . . .  23
       3.4.1.  CONFIGURE.statistics  . . . . . . . . . . . . . . . .  23
       3.4.2.  READ.statistics . . . . . . . . . . . . . . . . . . .  23
       3.4.3.  RESET.statistics  . . . . . . . . . . . . . . . . . .  24
     3.5.  Network Formation Commands  . . . . . . . . . . . . . . .  24
       3.5.1.  CONFIGURE.eb  . . . . . . . . . . . . . . . . . . . .  25
       3.5.2.  READ.eb . . . . . . . . . . . . . . . . . . . . . . .  25
     3.6.  Time Source Neighbor Commands . . . . . . . . . . . . . .  26



Wang, et al.             Expires August 18, 2014                [Page 2]


Internet-Draft            6tisch-6top-sublayer             February 2014


       3.6.1.  CONFIGURE.timesource  . . . . . . . . . . . . . . . .  26
       3.6.2.  READ.timesource . . . . . . . . . . . . . . . . . . .  26
     3.7.  Neighbor Commands . . . . . . . . . . . . . . . . . . . .  26
       3.7.1.  CREATE.neighbor . . . . . . . . . . . . . . . . . . .  27
       3.7.2.  READ.all.neighbor . . . . . . . . . . . . . . . . . .  27
       3.7.3.  READ.neighbor . . . . . . . . . . . . . . . . . . . .  27
       3.7.4.  UPDATE.neighbor . . . . . . . . . . . . . . . . . . .  27
       3.7.5.  DELETE.neighbor . . . . . . . . . . . . . . . . . . .  28
     3.8.  Queueing Commands . . . . . . . . . . . . . . . . . . . .  28
       3.8.1.  CREATE.queue  . . . . . . . . . . . . . . . . . . . .  28
       3.8.2.  READ.queue  . . . . . . . . . . . . . . . . . . . . .  28
       3.8.3.  READ.queue.stats  . . . . . . . . . . . . . . . . . .  29
       3.8.4.  UPDATE.queue  . . . . . . . . . . . . . . . . . . . .  29
       3.8.5.  DELETE.queue  . . . . . . . . . . . . . . . . . . . .  30
     3.9.  Label Switching Commands  . . . . . . . . . . . . . . . .  30
       3.9.1.  LabelSwitching.map  . . . . . . . . . . . . . . . . .  30
       3.9.2.  LabelSwitching.unmap  . . . . . . . . . . . . . . . .  30
     3.10. Chunk Command . . . . . . . . . . . . . . . . . . . . . .  31
       3.10.1.  Create.chunk . . . . . . . . . . . . . . . . . . . .  31
       3.10.2.  READ.chunk . . . . . . . . . . . . . . . . . . . . .  31
       3.10.3.  Delete.chunk . . . . . . . . . . . . . . . . . . . .  32
     3.11. Chunk Cell Command  . . . . . . . . . . . . . . . . . . .  32
       3.11.1.  CREATE.hardcell.fromchunk  . . . . . . . . . . . . .  32
       3.11.2.  READ.chunkcell . . . . . . . . . . . . . . . . . . .  33
       3.11.3.  DELETE.hardcell.fromchunk  . . . . . . . . . . . . .  33
     3.12. Data Commands . . . . . . . . . . . . . . . . . . . . . .  34
       3.12.1.  Send.data  . . . . . . . . . . . . . . . . . . . . .  34
       3.12.2.  Receive.data . . . . . . . . . . . . . . . . . . . .  34
   4.  6top Communication Protocol . . . . . . . . . . . . . . . . .  35
     4.1.  Message Formats . . . . . . . . . . . . . . . . . . . . .  35
       4.1.1.  Information Elements  . . . . . . . . . . . . . . . .  35
       4.1.2.  Packet Formats  . . . . . . . . . . . . . . . . . . .  43
     4.2.  Time Sequences  . . . . . . . . . . . . . . . . . . . . .  48
       4.2.1.  Network Formation . . . . . . . . . . . . . . . . . .  49
       4.2.2.  Creating soft cells . . . . . . . . . . . . . . . . .  50
       4.2.3.  Deleting soft cells . . . . . . . . . . . . . . . . .  51
       4.2.4.  Maintaining soft cells  . . . . . . . . . . . . . . .  51
       4.2.5.  Creating hard cells . . . . . . . . . . . . . . . . .  51
       4.2.6.  Deleting hard cells . . . . . . . . . . . . . . . . .  52
   5.  Statistics  . . . . . . . . . . . . . . . . . . . . . . . . .  52
     5.1.  Statistics Metrics  . . . . . . . . . . . . . . . . . . .  52
     5.2.  Statistics Configuration  . . . . . . . . . . . . . . . .  53
   6.  Monitoring  . . . . . . . . . . . . . . . . . . . . . . . . .  53
     6.1.  Monitor Configuration . . . . . . . . . . . . . . . . . .  53
     6.2.  Actuation . . . . . . . . . . . . . . . . . . . . . . . .  54
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  54
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  54



Wang, et al.             Expires August 18, 2014                [Page 3]


Internet-Draft            6tisch-6top-sublayer             February 2014


     7.3.  External Informative References . . . . . . . . . . . . .  55
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  55

1.  Introduction

   As presented in [I-D.ietf-6tisch-tsch], 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 the next-higher layer, defined in this
   document, 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.ietf-6tisch-architecture]. 6top addresses
   the set of functionalities described in [I-D.ietf-6tisch-tsch].

   For example, network formation in a TSCH network involves the
   transmission 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.  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 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



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


Internet-Draft            6tisch-6top-sublayer             February 2014


   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), which architecture is detailed in
   [I-D.ietf-6tisch-architecture], and generaic data model is detailed
   in [I-D.wang-6tisch-6top-interface]. 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.

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



Wang, et al.             Expires August 18, 2014                [Page 5]


Internet-Draft            6tisch-6top-sublayer             February 2014


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

   All 6top commands of the management and data interfaces are detailed
   in Section 3.  This set of commands is designed to support
   decentralized, centralized and hybrid scheduling solutions.  They
   form a conceptual interface an upper layer can used; implementations
   can use this set of commands, or any equivalent alternative.

   6top defines TSCH Information Elements (IEs) for neighbors nodes to
   negotiate scheduling cells in the TSCH schedule.  The format of those
   IEs is given in Section 4.1.  Example data exchanges between neighbor
   nodes are given in Section 4.2.

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

   6top can be configured to monitor the cells it has scheduled in order
   to detect cells with poor performance.  It can automatically re-
   allocate those cells inside the TSCH schedule.  This behavior is
   described in Section 6

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

         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.





Wang, et al.             Expires August 18, 2014                [Page 6]


Internet-Draft            6tisch-6top-sublayer             February 2014


   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 and channelOffset of the corresponding cell(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).  TrackOwnerAddr is the address of the
   node which initiates the process of creating the track, i.e. the
   owner of the track.  InstanceID is an instance identifier given by
   the owner of the track.  InstanceID comes from the upper layer; it
   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 to ask a node to manage a portion of a
   slotframe, called a 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 cells in a chunk can
   be appropriated by the node, i.e. the node is in charge of managing
   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.

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



Wang, et al.             Expires August 18, 2014                [Page 7]


Internet-Draft            6tisch-6top-sublayer             February 2014


         CellType: MUST be set to 1.

2.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 Section 4.2.

2.2.  Data Transfer Model

   The TSCH MAC layer is decoupled from the upper layer; the interaction
   between the upper layer and 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 for the MAC layer to read
   it and send it in a particular timeslot according to its destination
   and priority. 6top provides a set of queue management operations
   which enable upper layers to create different queues and set their
   priorities.  This allows different classes of traffic to be handled
   by the forwarding plane by inserting a packet into the queue
   appropriate for its priority.

   A 6top implementation MUST provide at least a Broadcast Queue and a
   Transmit Queue.  The Broadcast Queue is associated with cells with
   LinkType=ADVERTISING in the sender's schedule, and
   LinkOption="Receive" and "Timekeeping" in all its neighbors'
   schedule.  For example, NodeA uses slotOffset=5 and channelOffset=12
   as Broadcast cell to its neighbors NodeB and NodeC.  Then, in the
   schedule of NodeA the cell will be featured with neighbor address is
   Broadcast address, LinkType=ADVERTISING; and in the schedules of both
   nodeB and nodeC the cell will be featured with nodeA address as
   neighbor address, and LinkOption="Receive" and "Timekeeping", which
   ensure nodeB and nodeC will be active at least one time in the cell
   to receive broadcast packet during a Timekeeping period.  A Transmit
   Queue is associated with the dedicated Transmit cells or Shared
   Cells.

   Data Communication Commands (Section 3.12) can be used to send
   control messages and data messages.  The operation is used to insert
   a message into a specific queue.

   For example, a configuration can include two Broadcast Queues with
   priority High and Low, and three Transmit Queues with priority High,
   Mid, and Low.




Wang, et al.             Expires August 18, 2014                [Page 8]


Internet-Draft            6tisch-6top-sublayer             February 2014


   When DestAddr is the 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 into
   broadcast cells.

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

   The QoS policy enforced by 6top is out of scope.  As an example,
   packets in higher priority queues could be transmitted before the
   packets in lower priority queue.  As a result, when there is an
   available broadcast/unicast cell, 6top checks the broadcast/unicast
   queue with higher priority first. 6top continues this search until it
   finds a broadcast/unicast packet, or finds that all of broadcast/
   unicast queues are empty.

   Figure Figure 2 shows how 6top shapes data from the upper layer
   (e.g., RPL, 6LoWPAN), and feeds it to TSCH.  The properties
   associated with a packet/fragment from the upper layer includes the
   next hop neighbor (DestAddr), the packet priority, and TrackID(s).





























Wang, et al.             Expires August 18, 2014                [Page 9]


Internet-Draft            6tisch-6top-sublayer             February 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.12), 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 is 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 18, 2014               [Page 10]


Internet-Draft            6tisch-6top-sublayer             February 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.  6top Commands

   6top provides a set of commands as the interface with the higher
   layer.  Most of these commands are related to the configuration of
   slotframes, cells and scheduling information. 6top also provides an
   interface allowing an upper layer to retrieve status information and
   statistics.  The management commands provided by 6top are listed
   below.  Note that this set defines a conceptual interface only; an
   implementation can choose to use this exact set of commands, or any
   equivalent alternative.

         CREATE.hardcell: Section 3.1.1

         CREATE.softcell: Section 3.1.2

         READ.cell: Section 3.1.3

         UPDATE.cell: Section 3.1.4

         DELETE.hardcell: Section 3.1.5

         DELETE.softcell: Section 3.1.6

         REALLOCATE.softcell: Section 3.1.7

         CREATE.slotframe: Section 3.2.1

         READ.slotframe: Section 3.2.2




Wang, et al.             Expires August 18, 2014               [Page 11]


Internet-Draft            6tisch-6top-sublayer             February 2014


         UPDATE.slotframe: Section 3.2.3

         DELETE.slotframe: Section 3.2.4

         CONFIGURE.monitoring: Section 3.3.1

         READ.monitoring: Section 3.3.2

         CONFIGURE.statistics: Section 3.4.1

         READ.statistics: Section 3.4.2

         RESET.statistics: Section 3.4.3

         CONFIGURE.eb: Section 3.5.1

         READ.eb: Section 3.5.2

         CONFIGURE.timesource: Section 3.6.1

         READ.timesource: Section 3.6.2

         CREATE.neighbor: Section 3.7.1

         READ.all.neighbor: Section 3.7.2

         READ.neighbor: Section 3.7.3

         UPDATE.neighbor: Section 3.7.4

         DELETE.neighbor: Section 3.7.5

         CREATE.queue: Section 3.8.1

         READ.queue: Section 3.8.2

         READ.queue.stats: Section 3.8.3

         UPDATE.queue: Section 3.8.4

         DELETE.queue: Section 3.8.5

         LabelSwitching.map: Section 3.9.1

         LabelSwitching.unmap: Section 3.9.2

         CREATE.chunk: Section 3.10.1




Wang, et al.             Expires August 18, 2014               [Page 12]


Internet-Draft            6tisch-6top-sublayer             February 2014


         READ.chunk: Section 3.10.2

         DELETE.chunk: Section 3.10.3

         CREATE.hardcell.fromchunk: Section 3.11.1

         READ.chunkcell: Section 3.11.2

         DELETE.hardcell.fromchunk: Section 3.11.3

   Besides management commands, 6top provides the following data
   commands:

         Send.data: Section 3.12.1

         Receive.data: Section 3.12.2

   In addition, 6top offers a delegation interface allowing an upper
   layer to configure TSCH. 6top only delegates the functionalities to
   the MAC security services.  In other words, 6top allows an upper
   layer to access the security PIB (Table 60, Table 61, Table 63 in
   [IEEE802154]) by using MLME-GET/MLME-SET primitives defined in
   [IEEE802154].

3.1.  Cell Commands

   6top provides the following commands to manage TSCH cells.

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 2.1



Wang, et al.             Expires August 18, 2014               [Page 13]


Internet-Draft            6tisch-6top-sublayer             February 2014


         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
   ([I-D.wang-6tisch-6top-interface]).

   The interaction between 6top and MAC layer caused by CREATE.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.

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








Wang, et al.             Expires August 18, 2014               [Page 14]


Internet-Draft            6tisch-6top-sublayer             February 2014


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

         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 ([I-D.wang-6tisch-6top-interface]).

   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.





Wang, et al.             Expires August 18, 2014               [Page 15]


Internet-Draft            6tisch-6top-sublayer             February 2014


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

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

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





Wang, et al.             Expires August 18, 2014               [Page 16]


Internet-Draft            6tisch-6top-sublayer             February 2014


         list of (StatisticsMetriceID, StatisticsValue):
         StatisticsMetriceID is the index to Statistics Metric defined
         in Section 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 ([I-D.wang-6tisch-6top-interface]).

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.1.7) MUST be used instead.

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

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 2.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
   ([I-D.wang-6tisch-6top-interface])as well.

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




Wang, et al.             Expires August 18, 2014               [Page 17]


Internet-Draft            6tisch-6top-sublayer             February 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                    |   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.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 2.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.





Wang, et al.             Expires August 18, 2014               [Page 18]


Internet-Draft            6tisch-6top-sublayer             February 2014


   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.1.7) MUST be used.

   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.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.1.6 and Section 3.1.2.

3.2.  Slotframe Commands

   6top provides the following commands to manage TSCH slotframes.

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 18, 2014               [Page 19]


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

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 18, 2014               [Page 20]


Internet-Draft            6tisch-6top-sublayer             February 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.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 18, 2014               [Page 21]


Internet-Draft            6tisch-6top-sublayer             February 2014


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.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.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 18, 2014               [Page 22]


Internet-Draft            6tisch-6top-sublayer             February 2014


   Fails if the slotframe ID does not exist.

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.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.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 18, 2014               [Page 23]


Internet-Draft            6tisch-6top-sublayer             February 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.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.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 18, 2014               [Page 24]


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

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

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 18, 2014               [Page 25]


Internet-Draft            6tisch-6top-sublayer             February 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.6.  Time Source Neighbor Commands

   Commands to select time source neighbors.

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.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.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 18, 2014               [Page 26]


Internet-Draft            6tisch-6top-sublayer             February 2014


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.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.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.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 18, 2014               [Page 27]


Internet-Draft            6tisch-6top-sublayer             February 2014


3.7.5.  DELETE.neighbor

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

3.8.  Queueing Commands

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

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.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 18, 2014               [Page 28]


Internet-Draft            6tisch-6top-sublayer             February 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.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.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 18, 2014               [Page 29]


Internet-Draft            6tisch-6top-sublayer             February 2014


         statswindow: window of time used to compute stats.

         queue priority: the desired priority of this queue.

         TrackIDs: the desired set of TrackIDs.

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.9.  Label Switching Commands

   6top is responsible for maintaining the mapping of input cells and
   output cells in the same track in a particular node.  By keeping that
   mapping, layer 3 routing can be avoided as packets are forwarded by
   the 6top sublayer according to the input cells they were received on.
   The selected output cell is one of the cells that forward the packet
   to the subsequent hop in the track.

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




Wang, et al.             Expires August 18, 2014               [Page 30]


Internet-Draft            6tisch-6top-sublayer             February 2014


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

3.10.  Chunk Command

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

         ChunkSize: number of the cells which the chunk includes.

         SlotBase : the base slotOffset of the chunk.

         SlotStep : the incremental of slotOffset in the chunk.

         ChannelBase: the base channelOffset of the chunk.

         ChannelStep: the incremental of channalOffset in the chunk.

   ChunkID is the return value of the command
   ([I-D.wang-6tisch-6top-interface]).  The chunk is a set of cells in
   the given slotframe, consisting of (slotOffset(i),channelOffset(i)),
   i=0..Chunksize-1, slotOffset(i)= (slotBase + i * slotStep) %
   slotframeLen, channelOffset(i) = (channelBase + i * channelStep) %
   16".  Those cells will be added into ChunkCellList
   ([I-D.wang-6tisch-6top-interface]) also.

3.10.2.  READ.chunk

   Returns the information of a chunk given its ChunkId.  The command
   returns:

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

         ChunkSize: number of the cells which the chunk includes.

         SlotBase : the base slotOffset of the chunk.



Wang, et al.             Expires August 18, 2014               [Page 31]


Internet-Draft            6tisch-6top-sublayer             February 2014


         SlotStep : the incremental of slotOffset in the chunk.

         ChannelBase: the base channelOffset of the chunk.

         ChannelStep: the incremental of channalOffset in the chunk.

   Fails if the ChunkId does not exist.

3.10.3.  Delete.chunk

   To delete a chunk, upper layer specifies ChunkID.

   It removes the chunk from ChunkList
   ([I-D.wang-6tisch-6top-interface]), and also remove those entries
   corresponding to the cells of the chunk from
   ChunkCellList([I-D.wang-6tisch-6top-interface]).  In addition, it
   also causes all of the scheduled cells in the chunk are deleted from
   CellList ([I-D.wang-6tisch-6top-interface]) and TSCH schedule as
   well.

3.11.  Chunk Cell Command

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

         CellType: as defined in Section 2.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.



Wang, et al.             Expires August 18, 2014               [Page 32]


Internet-Draft            6tisch-6top-sublayer             February 2014


   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 ChunkCellList, i.e. its
   CellID is changed to the same CellID in the CellList, and its Status
   is changed to USED ([I-D.wang-6tisch-6top-interface]).

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

3.11.2.  READ.chunkcell

   Returns the cell information of a chunk given its ChunkId.  For each
   cell of the chunk, the command returns:

         slotOffset: the slotOffset of the cell.

         channelOffset: channelOffset of the cell.

         cellId: the cellID in the CellList if scheduled.

         Status: USED/UNUSED

   Fails if the ChunkId does not exist.

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




Wang, et al.             Expires August 18, 2014               [Page 33]


Internet-Draft            6tisch-6top-sublayer             February 2014


   This removes the hard cell from the node's schedule and CellList
   ([I-D.wang-6tisch-6top-interface]).  In addition, it changes the
   attributes corresponding to the cell in the ChunkCellList, i.e. its
   CellID is changed back to FFFF, and its Status is changed to UNUSED
   ([I-D.wang-6tisch-6top-interface]).

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

3.12.  Data Commands

3.12.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 2.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.12.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

         dest address: L2 unicast or broadcast destination address



Wang, et al.             Expires August 18, 2014               [Page 34]


Internet-Draft            6tisch-6top-sublayer             February 2014


         priority: packet priority, usually is consistent with queue
         priority

         message length: the length of the message.

         message: control message or data message

4.  6top Communication Protocol

   This section defines the Information Element (IE) based message
   formats, and the 6top-to-6top communication time sequences.

4.1.  Message Formats

   6top has to negotiate the scheduling of soft cells with neighbor
   nodes.  This negotiation happens through 6top-specific TSCH
   Information Elements, the format of which is defined in this section.
   For completeness, this section also details the formats of the IEs
   already defined in [IEEE802154e] and presented here without
   modification.

   6top messages can contain one or more IEs.  Section 4.1.1 defines the
   different IEs used by 6top, both the ones used without modification
   from [IEEE802154e], and the new ones defined by this document.
   Section 4.1.2 shows how several IEs are assembled to form the
   different frames used by 6top.

4.1.1.  Information Elements

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

   6top uses the following Information Elements, some defined in
   [IEEE802154e], others introduced in this document.

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



               TSCH Synchronization IE (Section 4.1.1.1)

               TSCH Slotframe and Link IE (Section 4.1.1.2)

               TSCH Timeslot Template IE (Section 4.1.1.3)



Wang, et al.             Expires August 18, 2014               [Page 35]


Internet-Draft            6tisch-6top-sublayer             February 2014


               TSCH Channel Hopping IE (Section 4.1.1.4)

         Defined by 6top:



               6top Opcode IE (Section 4.1.1.5)

               6top Bandwidth IE (Section 4.1.1.6)

               6top TrackID IE (Section 4.1.1.7)

               6top Generic Schedule IE (Section 4.1.1.8)

4.1.1.1.  TSCH Synchronization IE

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

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

   Format of a TSCH Synchronization IE (SyncIE).

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

                                 Figure 3

   Length=6

   SubID=0x1a

   T=0, i.e., short type

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

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




Wang, et al.             Expires August 18, 2014               [Page 36]


Internet-Draft            6tisch-6top-sublayer             February 2014


   suggested by [I-D.ietf-6tisch-minimal], the beaconing device's join
   priority is its DAGRank(rank).

4.1.1.2.  TSCH Slotframe and Link IE

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

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

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

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Length      |    SubID    |T|  NumFrame     |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      |                                                               |
      //               Slotframe and cell information                //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

   Length=variable

   SubID=0x1b

   T=0, i.e., short type

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

   Format of a slotframe descriptor.

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   FrameID      |            FrameLen          |   NumCell     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //          Cell information for each cell (5x NumCell)        //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 5

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



Wang, et al.             Expires August 18, 2014               [Page 37]


Internet-Draft            6tisch-6top-sublayer             February 2014


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

   The NumCell field shall be set to the number of cells that belong to
   the specific slotframe identified by the slotframeHandle.

   Format of a Cell information.

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        SlotOffset             |        ChannelOffset          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  LinkOption   |
      +-+-+-+-+-+-+-+-+

                                 Figure 6

   SlotOffset shall be set to the slotOffset of this cell.

   ChannelOffset shall be set to the channelOffset of this cell.

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

4.1.1.3.  TSCH Timeslot Template IE

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

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

   Format of a TSCH Timeslot Template IE (SlotTemplateIE).

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

                                 Figure 7

   Length=1

   SubID=0x1c

   T=0, i.e., short type




Wang, et al.             Expires August 18, 2014               [Page 38]


Internet-Draft            6tisch-6top-sublayer             February 2014


   TemplateID shall be set to a Timeslot template handle.  The full
   timeslot template, which contains the macTimeslotTemplate of TSCH
   (total 25 octets), MAY be included.(see [IEEE802154e]).

4.1.1.4.  TSCH Channel Hopping IE

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

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

   Format of a TSCH Channel Hopping IE (ChHoppingIE).

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

                                 Figure 8

   Length=1

   SubID=0x09

   T=1, i.e., long type

   HopSequenceID shall be set to a Hopping Sequence handle.  The full
   Hopping Sequence information MAY be included. (see [IEEE802154e]).

4.1.1.5.  6top Opcode IE

   6top Opcode IE (OpcodeIE) defines operation codes of packets in 6top
   sublayer.

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

   Format of a 6top Opcode IE (OpcodeIE).

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

                                 Figure 9

   Length=1

   SubID=0x41



Wang, et al.             Expires August 18, 2014               [Page 39]


Internet-Draft            6tisch-6top-sublayer             February 2014


   T=0, i.e., short type

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

         0x00: Reserve Soft Cell Request

         0x01: Reserve Soft Cell Response

         0x02: Remove Soft Cell Request

         0x03: Reserve Hard Cell Request

         0x04: Remove Hard Cell Request

4.1.1.6.  6top Bandwidth IE

   Bandwidth IE (BwIE) defines the number of cells to be reserved or
   actually be reserved.

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

   Format of a 6top Bandwidth IE (BwIE).

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

                                 Figure 10

   Length=2

   SubID=0x42

   T=0, i.e., short type

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

   NumCell shall be set to the number of cells.  When BwIE is combined
   with the OpecodeID of Reserve Soft Cell Request, NumCell presents how
   many cells are required to reserve; and when BwIE is combined with
   the OpecodeID of Reserve Soft Cell Response, NumCell presents how
   many cells are reserved successfully.






Wang, et al.             Expires August 18, 2014               [Page 40]


Internet-Draft            6tisch-6top-sublayer             February 2014


4.1.1.7.  6top TrackID IE

   TrackID IE (TrackIdIE) describes the track which the reserved/removed
   cell(s) are associated with.

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

   Format of a 6top TrackID IE (TrackIdIE).

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Length      |    SubID    |T|OwnerInstID|rev|               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      //                                                              //
      |                   TrackOwnerAddr                              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 11

   Length=3 or 7.  When length=3, TrackOwnerAddr is 2 bytes short
   address, and when length=7, TrackOwnerAddr is 6 bytes long address.

   SubID=0x43

   T=0, i.e., short type

   The combination of TrackOwnerAddr and OwnerInstId represents a
   specific TrackID.

4.1.1.8.  6top Generic Schedule IE

   Generic Schedule IE (ScheduleIE) describes cell sets.  In different
   packets, ScheduleIE represents different information.  See
   Section 4.1.2 for more detail.

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














Wang, et al.             Expires August 18, 2014               [Page 41]


Internet-Draft            6tisch-6top-sublayer             February 2014


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

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

                                 Figure 12

   Length=variable

   SubID=0x44

   T=0, i.e., short type

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

   The following are some examples of schedule object TLV.

   Example 1.  Cell Set TLV

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=1      |    Length     |     FrameID   |  NumCell    |F|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                        CellObjects                          //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 13

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

   NumCell shall be set to the number of cells that belong to the
   specific slotframe identified by the slotframeHandle.

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



Wang, et al.             Expires August 18, 2014               [Page 42]


Internet-Draft            6tisch-6top-sublayer             February 2014


   CellObjects carries the information for one or more cells, including
   SlotOffset, ChannelOffset, LinkOption (Figure 6).

   Example 2.  Schedule Matrix TLV

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=2      |    Length     |  FrameID      |StartSlotOffset|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |StartSLotOffset|    NumSlot    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      //                 SlotBitMap (2x NumSlot)                     //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 14

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

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

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

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

4.1.2.  Packet Formats

   This section describes the packets used in 6top to form a network,
   reserve/maintain bandwidth using soft cells, and reserve/remove hard
   cells in both the transmitter side and receiver sides.  Each of these
   packets uses one or more IEs defined in Section 4.1.1.

4.1.2.1.  TSCH Enhanced Beacon

   The TSCH Enhanced Beacon is used to announce the presence of the
   network and allows new nodes to join.  It is an Enhanced Beacon
   packet defined in [IEEE802154e] with the following Payload IEs:




Wang, et al.             Expires August 18, 2014               [Page 43]


Internet-Draft            6tisch-6top-sublayer             February 2014


         TSCH Synchronization IE (Section 4.1.1.1)

         TSCH Timeslot Template IE (Section 4.1.1.3)

         TSCH Channel Hopping IE (Section 4.1.1.4)

         TSCH Slotframe and Link IE (Section 4.1.1.2)

   Payload IE of TSCH Enhanced Beacon Packet

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length        |GroupID|T|             SyncIE            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        SyncIE                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         SyncIE                |      SlotTemplateIE           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |SlotTemplateIE |               ChHoppingIE                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                        FrameAndLinkIE                       //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 15

   Length=variable

   GroupID=0x1, i.e., MLME IE

   T=1, i.e., payload IE

   See Section 4.1.1.1, Section 4.1.1.3, Section 4.1.1.4,Section 4.1.1.2
   for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndLinkIE.

4.1.2.2.  Soft Cell Reservation Request

   A Soft Cell Reservation Request packet is a DATA packet defined in
   [IEEE802154e] with the following payload IE.











Wang, et al.             Expires August 18, 2014               [Page 44]


Internet-Draft            6tisch-6top-sublayer             February 2014


   Payload IE of Soft Cell Reservation Request

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length        |GroupID|T|          OpcodeIE             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | OpcodeIE      |                  BwIE                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    BwIE       |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      //                          ScheduleIE                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 16

   Length=variable

   GroupID=0x1, i.e., MLME IE

   T=1, i.e., payload IE

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

   The NumCell field in 4-octet BwIE SHOULD be set to the number of
   cells needed to be reserved.

   The ScheduleIE specifies a candidate cell set, from which the cells
   SHOULD be reserved.  ScheduleIE MAY be empty, means there is no
   constrain on which cells SHOULD not be reserved.

   In addition, TrackIdIE can be added in the packet to associate the
   reserved soft cells to a specific TrackID.

4.1.2.3.  Soft Cell Reservation Response

   Soft Cell Reservation Response is a DATA packet defined in
   [IEEE802154e] with the following payload IE.












Wang, et al.             Expires August 18, 2014               [Page 45]


Internet-Draft            6tisch-6top-sublayer             February 2014


   Payload IE of Soft Cell Reservation Response

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length        |GroupID|T|          OpcodeIE             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | OpcodeIE      |                  BwIE                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    BwIE       |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      //                          ScheduleIE                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 17

   Length=variable

   GroupID=0x1, i.e., MLME IE

   T=1, i.e., payload IE

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

   The NumCell field in 4-octet BwIE SHOULD be set to the number of
   cells which have been reserved successfully.

   The ScheduleIE SHOULD specify all of the cells which have been
   reserved successfully.

   In addition, TrackIdIE can be added in the packet to associate the
   reserved soft cells to a specific TrackID.

4.1.2.4.  Soft Cell Remove Request

   Soft Cell Remove Request is a DATA packet defined in [IEEE802154e]
   with the following payload IE.













Wang, et al.             Expires August 18, 2014               [Page 46]


Internet-Draft            6tisch-6top-sublayer             February 2014


   Payload IE of Soft Cell Remove Request

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length        |GroupID|T|          OpcodeIE             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | OpcodeIE      |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      //                          ScheduleIE                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 18

   Length=variable

   GroupID=0x1, i.e., MLME IE

   T=1, i.e., payload IE

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

   The ScheduleIE SHOULD specify all the cells that need to be removed.

4.1.2.5.  Hard Cell Reservation Request

   Hard Cell Reservation Request packet is a DATA packet defined in
   [IEEE802154e] with the following payload IE.

   Payload IE of Hard Cell Reservation Request

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length        |GroupID|T|          OpcodeIE             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | OpcodeIE      |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      //                          ScheduleIE                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 19

   Length=variable

   GroupID=0x1, i.e., MLME IE




Wang, et al.             Expires August 18, 2014               [Page 47]


Internet-Draft            6tisch-6top-sublayer             February 2014


   T=1, i.e., payload IE

   The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x03,
   indicates Reserve Hard Cell Request operation.

   The ScheduleIE SHOULD specify all the cell that need to be reserved.

   In addition, TrackIdIE can be added in the packet to associate the
   reserved hard cells to a specific TrackID.

4.1.2.6.  Hard Cell Remove Request

   Hard Cell Remove Request is a DATA packet defined in [IEEE802154e]
   with the following payload IE.

   Payload IE of Hard Cell Remove Request

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length        |GroupID|T|          OpcodeIE             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | OpcodeIE      |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      //                          ScheduleIE                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 20

   Length=variable

   GroupID=0x1, i.e., MLME IE

   T=1, i.e., payload IE

   The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x04,
   indicates Remove Hard Cell Request operation.

   The ScheduleIE SHOULD specify all the cells that need to be removed.

4.2.  Time Sequences

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

         Network formation (Section 4.2.1)

         Creating soft cells (Section 4.2.2)



Wang, et al.             Expires August 18, 2014               [Page 48]


Internet-Draft            6tisch-6top-sublayer             February 2014


         Deleting soft cells (Section 4.2.3)

         Maintaining soft cells (Section 4.2.4)

         Creating hard cells (Section 4.2.5)

         Deleting hard cells (Section 4.2.6)

4.2.1.  Network Formation

   Network formation consists of two processes: joining and maintenance.

4.2.1.1.  Joining

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

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

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

         Select a time source neighbor.  According to the Joining
         Priority described by SyncIEs, the joining node chooses time
         source neighbors. 6top does not specify the criteria to choose
         time source neighbors from the Enhanced BEACONs.

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

         Its Enhanced Beacons SHOULD include the cell(s) selected for EB
         purposes.  The EB cells MUST be configured with LinkOption to
         "Receive" and "Timekeeping", telling its neighbors that the
         cell is used for broadcast.

         Start broadcasting Enhanced Beacon and communicate with
         neighbors.







Wang, et al.             Expires August 18, 2014               [Page 49]


Internet-Draft            6tisch-6top-sublayer             February 2014


4.2.1.2.  Maintenance

   Nodes MAY broadcast Enhance Beacons on the cells marked with
   LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors
   on the cells with LinkOptions "Receive" and "Timekeeping".  If a cell
   with LinkType=ADVERTISING has both the "Receive" and "Timekeeping"
   LinkOptions set, which means that the cell is shared by neighbors and
   itself for broadcasting, then broadcasting Enhanced Beacon has higher
   priority.

   Whenever a node receives an Enhanced Beacon, it SHOULD update its
   schedule if there is a difference regarding to the cells used for
   synchronizing with the advertiser of the Enhanced Beacon.

4.2.2.  Creating soft cells

   The upper layer instructs 6top to schedule one or more soft cells by
   calling the Create soft cell command.  This command can also be
   called by the monitoring process internal to 6top.

   When receiving a Create soft cell command, Node A's 6top sublayer
   forms a Soft Cell Reservation Request packet which includes the BwIE
   and ScheduleIE Information Elements.  The BwIE indicates the number
   of cells to be reserved (N1); the ScheduleIE indicates set of a
   candidate cells from which the new cells SHOULD be selected.  If the
   ScheduleIE is empty, Node A indicates there is no constraint on cell
   selection.

   The Soft Cell Reservation Request is sent to the neighbor (Node B)
   with whom new cells need to be scheduled.  After receiving the Soft
   Cell Reservation Request, Node B selects the cells from the candidate
   cell set defined by the ScheduleIE in the Soft Cell Reservation
   Request, and forms a Soft Cell Reservation Response packet.  In the
   Cell Reservation Response packet, the BwIE indicates the number of
   cells actually being reserved (N2); the ScheduleIE indicates those
   reserved cells.  If N2 is smaller than N1, node B indicates to node A
   that there are not enough qualified cells to be reserved.  Node B
   MUST record the reserved cells into its local schedule when sending
   the Soft Cell Reservation Response.  After receiving the Soft Cell
   Reservation Response, Node A MUST record the reserved cells into its
   local schedule.

   The policy to build a candidate cell set and the policy to select
   cells from the candidate cell set to reserve are out of scope.

   The format of Schedule Body is flexible.  For example, Node A can use
   Cell Set TLV defined in Figure 13 with field 'F' set to '0', and the
   CellObjects includes all of the cells being used by Node A. In



Wang, et al.             Expires August 18, 2014               [Page 50]


Internet-Draft            6tisch-6top-sublayer             February 2014


   another word, the cell candidate set is all of the cells not being
   included in the list defined by CellObjects.

   The behavior of the nodes when the soft cells negotiation fails is
   out of scope.

4.2.3.  Deleting soft cells

   The upper layer instructs 6top to delete one or more soft cells by
   calling the Delete soft cell command (Section 3.1.6).  This command
   can also be called by the monitoring process internal to 6top
   (Section 6).

   When receiving a Delete soft cell command, Node A's 6top sublayer
   selects cells to be removed from its local schedule, and creates a
   Soft Cell Remove Request, which includes a ScheduleIE Information
   Element.  The ScheduleIE indicates which specific cells to remove
   with a neighbor (Node B).  The cells specified in the ScheduleIE
   SHOULD be removed from local schedule of Node A when the Soft Cell
   Remove Request is sent to Node B. When receiving the Soft Cell Remove
   Request, the cells specified in the ScheduleIE SHOULD be removed from
   the local schedule of Node B.

   The policy to select cells corresponding to a Delete soft cell
   command is out of scope.

4.2.4.  Maintaining soft cells

   The monitoring process internal to 6top (Section 6) is responsible
   for monitoring and re-scheduling soft cells to meet some QoS
   requirements.  The monitoring process MAY issue a soft cell
   Maintenance command, which indicate a set of cells to be re-allocated
   in the TSCH schedule.

   When receiving a soft cell Maintenance command, 6top initializes a
   Soft Cell Remove Request (Section 4.2.3) with the neighbor in
   question, followed by a Soft Cell Reservation Request
   (Section 4.2.2).

4.2.5.  Creating hard cells

   The upper layer instructs 6top to create one or more hard cells by
   calling the Create hard cell command.

   When receiving a Create hard cell command, Node A's 6top sublayer
   creates a Hard Cell Reservation Request, including a ScheduleIE.  The
   ScheduleIE indicates which specific cells with a neighbor (Node B) to
   be added.  The cells specified in the ScheduleIE SHOULD be added in



Wang, et al.             Expires August 18, 2014               [Page 51]


Internet-Draft            6tisch-6top-sublayer             February 2014


   local schedule of Node A while the Hard Cell Reserve Request is sent
   to Node B. When receiving the Hard Cell Reserve Request, the cells
   specified in the ScheduleIE SHOULD be added in the local schedule of
   Node B.

4.2.6.  Deleting hard cells

   The upper layer instructs 6top to delete one or more hard cells by
   calling the Delete hard cell command.

   When receiving a Delete hard cell command, Node A's 6top sublayer
   creates a Hard Cell Remove Request, including a ScheduleIE.  The
   ScheduleIE indicates which specific cells with a neighbor (Node B) to
   be removed.  The cells specified in the ScheduleIE SHOULD be removed
   from local schedule of Node A while the Hard Cell Remove Request is
   sent to Node B. When receiving the Hard Cell Remove Request, the
   cells specified in the ScheduleIE SHOULD be removed from the local
   schedule of Node B.

5.  Statistics

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

5.1.  Statistics Metrics

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

   The statistics data related to node states and cell metrics SHOULD be
   provided to upper layer for management, e.g., for RPL to calculate
   the node's Rank or for GMPLS to the required bandwidth is met.  The
   specific algorithm to generate the statistics is out of scope.
   However, the statistics component SHOULD include the following
   metrics:

   1.  LinkThroughput: associated with a link, Node A->Node B. For
       example, LinkThroughput can be calculated with:
       SUM(NumOfCell(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration)
       where NumOfCell(i) is the total number of cells from Node A to
       Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i.
       The unit is Byte/second.

   2.  Latency: associated with a link, Node A->Node B. For example,
       latency can be expressed as Minimum and Maximum Latency.  Minimum
       Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum
       Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where,



Wang, et al.             Expires August 18, 2014               [Page 52]


Internet-Draft            6tisch-6top-sublayer             February 2014


       MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum
       number of timeslots between two dedicated cells from Node A to
       Node B in Slotframe-i, respectively.

   3.  LinkQuality.  For example, average LQI, ETX, PDR, RSSI.

   4.  TrafficLoad.  For example, Queue Full Rate, Queue Empty Rate.

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

5.2.  Statistics Configuration

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

         LinkQualityStatisticsEn

         TafficLoadStatisticsEn

         DeviceStatisticsEn

   6top statistics function is enabled/disabled and configured by the
   commands defined in Section 3.4

6.  Monitoring

   The 6top Monitoring Function (MF) is responsible for monitoring cell
   quality, traffic load, and issuing soft cell Maintenance commands, or
   Create/Delete soft cell commands.  The data provided by the
   Statistics Function MAY be used as an input of MF in taking a
   monitoring decision.

6.1.  Monitor Configuration

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

         MaintainCellEn.

         CreateDeleteCellEn.

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

   The 6top monitoring function is enabled/disabled and configured by
   the commands defined in Section 3.3



Wang, et al.             Expires August 18, 2014               [Page 53]


Internet-Draft            6tisch-6top-sublayer             February 2014


6.2.  Actuation

   The cell quality statistics MAY be used to generate soft a cell
   Maintenance command, which triggers a soft cell Maintenance procedure
   (see Section 4.2.4).  The traffic load statistics MAY be used to
   generate internal Create (resp. Delete) soft cell commands, which
   trggiers a soft cell Reservation (resp. Remove) process (see
   Section 4.2.2 and Section 4.2.3).

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

   The policy to generate Create/Delete soft cell commands MAY take
   QosLevel into account.  For example, there are two slotframes
   existing, Slotframe-1 consists of 32 timeslots, Slotframe-2 consists
   of 96 timeslots; timeslot duration is 10ms; QosLevel=1.5.  If, from
   the traffic load statistics, MF determines that 2 packet/second
   SHOULD be added, then the MF generates a Create soft cell command,
   where FrameID=2, NumCell=3.

7.  References

7.1.  Normative References

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

7.2.  Informative References

   [I-D.ietf-6tisch-tsch]
              Watteyne, T., Palattella, M., and L. Grieco, "Using
              IEEE802.15.4e TSCH in an LLN context: Overview, Problem
              Statement and Goals", draft-ietf-6tisch-tsch-00 (work in
              progress), November 2013.

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

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





Wang, et al.             Expires August 18, 2014               [Page 54]


Internet-Draft            6tisch-6top-sublayer             February 2014


   [I-D.ietf-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", draft-ietf-6tisch-minimal-00 (work in
              progress), November 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.wang-6tisch-6top-interface]
              Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
              Operation Sublayer (6top) Interface", draft-wang-6tisch-
              6top-interface-01 (work in progress), February 2014.

7.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]  Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
              Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
              A Standards-Based Low-Power Wireless Development
              Environment. Transactions on Emerging Telecommunications
              Technologies.", August 2012.

   [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








Wang, et al.             Expires August 18, 2014               [Page 55]


Internet-Draft            6tisch-6top-sublayer             February 2014


   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


   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 18, 2014               [Page 56]


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