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

Versions: (draft-wang-6tisch-6top-protocol) 00 01 02 03

6TiSCH                                                      Q. Wang, Ed.
Internet-Draft                           Univ. of Sci. and Tech. Beijing
Intended status: Standards Track                           X. Vilajosana
Expires: May 4, 2017                     Universitat Oberta de Catalunya
                                                        October 31, 2016


                           6top Protocol (6P)
                   draft-ietf-6tisch-6top-protocol-03

Abstract

   This document defines the 6top Protocol (6P), which enables
   distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
   in a 6TiSCH network to add/delete TSCH cells to one another.  6P is
   part of the 6TiSCH Operation Sublayer (6top), the next higher layer
   of the IEEE802.15.4 TSCH medium access control layer.  The 6top
   Scheduling Function (SF) decides when to add/delete cells, and
   triggers 6P Transactions.  Several SFs can be defined, each
   identified by a different 6top Scheduling Function Identifier (SFID).
   This document lists the requirements for an SF, but leaves the
   definition of the SF out of scope.  Different SFs are expected to be
   defined in future companion specifications.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

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 May 4, 2017.




Wang & Vilajosana          Expires May 4, 2017                  [Page 1]


Internet-Draft            6tisch-6top-protocol              October 2016


Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   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.  TEMPORARY EDITORIAL NOTES . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  6TiSCH Operation Sublayer (6top)  . . . . . . . . . . . . . .   5
     3.1.  Hard/Soft Cells . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Using 6top with the Minimal 6TiSCH Configuration  . . . .   5
   4.  6top Protocol (6P)  . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  6top Transaction  . . . . . . . . . . . . . . . . . . . .   6
       4.1.1.  2-step 6top Transaction . . . . . . . . . . . . . . .   7
       4.1.2.  3-step 6top Transaction . . . . . . . . . . . . . . .   8
     4.2.  Message Format  . . . . . . . . . . . . . . . . . . . . .  10
       4.2.1.  6top Information Element  . . . . . . . . . . . . . .  10
       4.2.2.  General Message Format  . . . . . . . . . . . . . . .  10
       4.2.3.  6P Message Types  . . . . . . . . . . . . . . . . . .  11
       4.2.4.  6P Command Identifiers  . . . . . . . . . . . . . . .  12
       4.2.5.  6P Return Codes . . . . . . . . . . . . . . . . . . .  12
       4.2.6.  6P CellOptions  . . . . . . . . . . . . . . . . . . .  13
       4.2.7.  6P Cell Format  . . . . . . . . . . . . . . . . . . .  15
       4.2.8.  6P ADD Request Format . . . . . . . . . . . . . . . .  15
       4.2.9.  6P DELETE Request Format  . . . . . . . . . . . . . .  16
       4.2.10. 6P STATUS Request Format  . . . . . . . . . . . . . .  17
       4.2.11. 6P LIST Request Format  . . . . . . . . . . . . . . .  17
       4.2.12. 6P CLEAR Request Format . . . . . . . . . . . . . . .  18
       4.2.13. 6P Response Format  . . . . . . . . . . . . . . . . .  19
       4.2.14. 6P Confirmation Format  . . . . . . . . . . . . . . .  20
     4.3.  Protocol Behavior . . . . . . . . . . . . . . . . . . . .  20
       4.3.1.  Version Checking  . . . . . . . . . . . . . . . . . .  20
       4.3.2.  SFID Checking . . . . . . . . . . . . . . . . . . . .  20
       4.3.3.  Concurrent 6P Transactions  . . . . . . . . . . . . .  21
       4.3.4.  Timeout . . . . . . . . . . . . . . . . . . . . . . .  21
       4.3.5.  SeqNum Mismatch . . . . . . . . . . . . . . . . . . .  21
       4.3.6.  Clearing the Schedule . . . . . . . . . . . . . . . .  22



Wang & Vilajosana          Expires May 4, 2017                  [Page 2]


Internet-Draft            6tisch-6top-protocol              October 2016


       4.3.7.  Adding Cells with 2-way Transaction . . . . . . . . .  22
       4.3.8.  Aborting a 6P Transaction . . . . . . . . . . . . . .  22
       4.3.9.  Deleting Cells  . . . . . . . . . . . . . . . . . . .  23
       4.3.10. Listing Cells . . . . . . . . . . . . . . . . . . . .  23
       4.3.11. Generation Management . . . . . . . . . . . . . . . .  24
       4.3.12. Handling error responses  . . . . . . . . . . . . . .  25
     4.4.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  25
   5.  Guidelines for 6top Scheduling Functions (SF) . . . . . . . .  25
     5.1.  SF Identifier (SFID)  . . . . . . . . . . . . . . . . . .  26
     5.2.  Requirements for an SF  . . . . . . . . . . . . . . . . .  26
     5.3.  Recommended Structure of an SF Specification  . . . . . .  27
   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .  27
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
   8.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .  28
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  29
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  29
   Appendix A.  [TEMPORARY] Changelog  . . . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  TEMPORARY EDITORIAL NOTES

   This document is an Internet Draft, so work-in-progress by nature.
   It contains the following work-in-progress elements:

   o  "TODO" statements are elements which have not yet been written by
      the authors for some reason (lack of time, ongoing discussions
      with no clear consensus, etc).  The statement does indicate that
      the text will be written at some time.
   o  "TEMPORARY" appendices are there to capture current ongoing
      discussions, or the changelog of the document.  These appendices
      will be removed in the final text.
   o  "IANA_" identifiers are placeholders for numbers assigned by IANA.
      These placeholders are to be replaced by the actual values they
      represent after their assignment by IANA.
   o  The string "REMARK" is put before a remark (questions, suggestion,
      etc) from an author, editor of contributor.  These are on-going
      discussions at the time to writing, NOT part of the final text.
   o  This section will be removed in the final text.

2.  Introduction

   All communication in a 6TiSCH network is orchestrated by a schedule
   [RFC7554].  This specification defines the 6top Protocol (6P), part
   of the 6TiSCH Operation sublayer (6top).  6P allow a node to
   communicate with a neighbor to add/delete a TSCH cell to one another.
   6P hence enables distributed scheduling in a 6TiSCH network.




Wang & Vilajosana          Expires May 4, 2017                  [Page 3]


Internet-Draft            6tisch-6top-protocol              October 2016


                                    (R)
                                    / \
                                   /   \
                                (B)-----(C)
                                 |       |
                                 |       |
                                (A)     (D)

                    Figure 1: A simple 6TiSCH network.

   The example network depicted in Figure 1 is used to describe the
   interactions between nodes.  We consider the canonical case where
   node "A" issues 6P requests to node "B".  We keep this example
   throughout this document.  Throughout the discussions, node A will
   always represent the node that issues a 6P request; node B the node
   that receives this request.

   We consider node A in Figure 1 monitoring the communication cells it
   has in its schedule to node B.

   o  If node A determines that the number of link-layer frames it is
      sending to B per unit of time is larger than the capacity offered
      by the TSCH cells it has scheduled to B, it triggers a 6P
      Transaction with node B to add one or more cells to B's TSCH
      schedule.
   o  If the traffic is lower than the capacity, node A triggers a 6P
      Transaction with node B to delete one or more cells in the TSCH
      schedule of both nodes.
   o  Node A MAY also monitor statistics to determine whether collisions
      are happening on a particular cell to node B.  If this feature is
      enabled, node A communicates with node B to add a new cell and
      delete the cell which suffered from collisions.  This conceptually
      results in "relocating" the cell which suffered from collisions to
      a different slotOffset/channelOffset location in the TSCH
      schedule.  The mechanism to handle cell relocation is out of the
      scope of this document and might be handled by the scheduling
      function (see below).

   This results in distributed schedule management in a 6TiSCH network.

   The 6top Scheduling Function (SF) defines when to add/delete a cell
   to a neighbor.  The SF functions as a (required) add-on to 6P.
   Different applications require different SFs, so the SF is left out
   of scope of this document.  Different SFs are expected to be defined
   in future companion specifications.  A node MAY implement multiple
   SFs and run them at the same time.  The SFID field contained in all
   6P messages allows a node to switch between SFs on a per-transaction
   basis.



Wang & Vilajosana          Expires May 4, 2017                  [Page 4]


Internet-Draft            6tisch-6top-protocol              October 2016


   Section 3 describes the 6TiSCH Operation Sublayer (6top).  Section 4
   defines the 6top Protocol (6P).  Section 5 provides guidelines on how
   to design an SF.

3.  6TiSCH Operation Sublayer (6top)

   As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the
   next higher layer to the IEEE802.15.4 TSCH medium access control
   layer [IEEE802154-2015].

                                   .
               |                   .                      |
               |             higher layers                |
               +------------------------------------------+
               |                 6top                     |
               +------------------------------------------+
               |           IEEE802.15.4 TSCH              |
               |                   .                      |
                                   .

            Figure 2: The 6top sublayer in the protocol stack.

   The roles of the 6top sublayer are to:

   o  Implement and terminate the 6top Protocol (6P), which allows
      neighbor nodes to communicate to add/delete cells to one another.
   o  Run one or more 6top Scheduling Functions (SF), which define the
      algorithm to decide when to add/delete cells.

3.1.  Hard/Soft Cells

   6top qualifies each cell in the schedule as either "hard" or "soft":

   o  a soft cell can be read, added, deleted or updated by 6top.
   o  a hard cell is read-only for 6top.

   In the context of this specification, all the cells used by 6top are
   soft cells.  Hard cells can be used for example when "hard-coding" a
   scheduling.  This is done, for example, in the Minimal 6TiSCH
   Configuration [I-D.ietf-6tisch-minimal].

3.2.  Using 6top with the Minimal 6TiSCH Configuration

   6P MAY be used alongside the Minimal 6TiSCH Configuration
   [I-D.ietf-6tisch-minimal].  In this case, it is RECOMMENDED to use 2
   slotframes, as depicted in Figure 3:





Wang & Vilajosana          Expires May 4, 2017                  [Page 5]


Internet-Draft            6tisch-6top-protocol              October 2016


   o  Slotframe 0 is used for traffic defined in the Minimal 6TiSCH
      Configuration.  In Figure 3, this slotframe is 5 slots long, but
      it can be of any length.
   o  Slotframe 1 is used by 6top to allocate cells from.  In Figure 3,
      this slotframe is 10 slots long, but it can be of any length.

   Slotframe 0 SHOULD be of higher priority than Slotframe 1 to avoid
   for cells in slotframe 1 to "mask" cells in slotframe 0.  6top MAY
   support further slotframes; how to use more slotframes is out of the
   scope for this document.

                   | 0    1    2    3    4  | 0    1    2    3    4  |
                   +------------------------+------------------------+
       Slotframe 0 |    |    |    |    |    |    |    |    |    |    |
      5 slots long | EB |    |    |    |    | EB |    |    |    |    |
     high priority |    |    |    |    |    |    |    |    |    |    |
                   +-------------------------------------------------+

                   | 0    1    2    3    4    5    6    7    8    9  |
                   +-------------------------------------------------+
       Slotframe 1 |    |    |    |    |    |    |    |    |    |    |
     10 slots long |    |A->B|    |    |    |    |    |    |B->A|    |
      low priority |    |    |    |    |    |    |    |    |    |    |
                   +-------------------------------------------------+

   Figure 3: 2-slotframe structure when using 6top alongside the Minimal
                           6TiSCH Configuration.

4.  6top Protocol (6P)

   The 6top Protocol (6P) allows two neighbor nodes to communicate to
   add/delete cells to their TSCH schedule.  Conceptually, two neighbor
   nodes "negotiate" the location of the cell(s) to add/delete.

4.1.  6top Transaction

   We call "6top Transaction" a complete negotiation between two
   neighbor nodes.  A 6P Transaction starts when a node wishes to add/
   delete one or more cells to one of its neighbors.  It ends when the
   cell(s) have been added/removed from the schedule of both neighbors,
   or when the 6P Transaction has failed.

   A 6P Transaction can consist of 2 or 3 steps.  It is the SF which
   determines whether to use 2-step or 3-step transactions.  An SF MAY
   use both 2-step and 3-step transactions.

   Consistency between the schedules of two neighbor nodes is of utmost
   importance.  A loss of consistency (e.g. node A has a transmit cell



Wang & Vilajosana          Expires May 4, 2017                  [Page 6]


Internet-Draft            6tisch-6top-protocol              October 2016


   to node B, but node B does not have the corresponding reception cell)
   can cause loss of connectivity.  To verify consistency, neighbors
   nodes increment the "schedule generation" number of their schedule
   each time they add/remove a cell.  Neighbor nodes exchange generation
   numbers at each 6P Transaction to detect possible inconsistencies.
   This mechanism is explained in Section 4.3.11.

   We reuse the topology in Figure 1 to illustrate 2-step and 3-step
   transactions.

4.1.1.  2-step 6top Transaction

   Figure 4 is a sequence diagram to help understand the 2-step 6top
   transaction (several elements are left out to simplify
   understanding).  We assume the SF running on node A determines 2
   extra cells need to be scheduled to node B.  In this example, node A
   proposes the cells to use.

            +----------+                           +----------+
            |  Node A  |                           |  Node B  |
            +----+-----+                           +-----+----+
                 |                                       |
                 | 6P ADD Request                        |
                 |   NumCells     = 2                    |
                 |   CellList     = [(1,2),(2,2),(3,5)]  |
                 |-------------------------------------->|
                 |                                       |
                 | 6P Response                           |
                 |   Return Code  = RC_SUCCESS           |
                 |   CellList     = [(2,2),(3,5)]        |
                 |<--------------------------------------|
                 |                                       |

                    Figure 4: A 2-step 6P Transaction.

   In this example, the 2-step transaction occurs as follows:

   1.  The SF running on node A selects 3 candidate cells.
   2.  Node A sends a 6P ADD Request to node B, indicating it wishes to
       add 2 cells (the "NumCells" value), and specifying the list of 3
       candidate cells (the "CellList" value).  Each cell in the
       CellList is a [slotOffset,channelOffset] tuple.
   3.  Node A at the same time sets a timeout timer to abort the
       transaction if no response has been received when it expires.
       The value of the timeout is out of the scope of this document and
       MAY be defined by the SF.  More details are given in
       Section 4.3.8.




Wang & Vilajosana          Expires May 4, 2017                  [Page 7]


Internet-Draft            6tisch-6top-protocol              October 2016


   4.  The SF running on node B selects 2 of the 3 cells in the CellList
       of the 6P ADD Request.  Node B sends back a 6P Response to node
       A, indicating the cells it selected.
   5.  The result of this 6P Transaction is that 2 cells from A to B
       have been added to the TSCH schedule of both nodes A and B.

4.1.2.  3-step 6top Transaction

   Figure 5 is a sequence diagram to help understand the 3-step 6top
   transaction.  We assume the SF running on node A determines 2 extra
   cells need to be scheduled to node B.  In this example, node B
   proposes the cells to use.

           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
                |                                       |
                | 6P ADD Request                        |
                |   NumCells     = 2                    |
                |   CellList     = []                   |
                |-------------------------------------->|
                |                                       |
                | 6P Response                           |
                |   Return Code  = RC_SUCCESS           |
                |   CellList     = [(1,2),(2,2),(3,5)]  |
                |<--------------------------------------|
                |                                       |
                | 6P Confirmation                       |
                |   Return Code  = RC_SUCCESS           |
                |   CellList     = [(2,2),(3,5)]        |
                |-------------------------------------->|
                |                                       |

                    Figure 5: A 3-step 6P Transaction.

   In this example, the 3-step transaction occurs as follows:

   1.  The SF running on node A determines 2 extra cells need to be
       scheduled to node B, but does not select candidate cells.
   2.  Node A sends a 6P ADD Request to node B, indicating it wishes to
       add 2 cells (the "NumCells" value), with an empty "CellList".
   3.  Node A at the same time sets a timeout timer to abort the
       transaction if no response has been received when it expires.
       The value of the timeout is out of the scope of this document and
       MAY be defined by the SF.  More details are given in
       Section 4.3.8.
   4.  The SF running on node B selects 3 candidate cells.  Node B sends
       back a 6P Response to node A, indicating the 3 cells it selected.



Wang & Vilajosana          Expires May 4, 2017                  [Page 8]


Internet-Draft            6tisch-6top-protocol              October 2016


   5.  Node B at the same time sets a timeout timer to abort the
       transaction if no response has been received when it expires.
       The value of the timeout is out of the scope of this document and
       MAY be defined by the SF.  More details are given in
       Section 4.3.8.
   6.  The SF running on node A selects 2 cells.  Node A sends back a 6P
       Confirmation to node B, indicating the cells it selected.
   7.  The result of this 6P Transaction is that 2 cells from A to B
       have been added to the TSCH schedule of both nodes A and B.

   When in a transaction, node A proposes a candidate CellList to node B
   and B cannot allocate any of those cells.  Node B SHOULD respond with
   a CellList suggesting alternatives.  This approach facilitates the
   agreement between A and B and enables A to not guess what cells may
   be not used in B.  The following figure ilustrated these 3-step
   transaction.

           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
                |                                       |
                | 6P ADD Request                        |
                |   NumCells     = 2                    |
                |   CellList     = [(1,2),(2,2),(3,5)]  |
                |-------------------------------------->|
                |                                       |
                | 6P Response                           |
                |   Return Code  = RC_SUCCESS           |
                |   CellList     = [(6,2),(7,2),(8,5)]  |
                |<--------------------------------------|
                |                                       |
                | 6P Confirmation                       |
                |   Return Code  = RC_SUCCESS           |
                |   CellList     = [(7,2),(8,5)]        |
                |-------------------------------------->|
                |                                       |

          Figure 6: A 3-step 6P Transaction with cell suggestion.

   In this example, the 3-step transaction occurs as follows:

   1.  The SF running on node A determines 2 extra cells need to be
       scheduled to node B, and selects a candidate list of cells.
   2.  Node A sends a 6P ADD Request to node B, indicating it wishes to
       add 2 cells (the "NumCells" value), with an the proposed
       "CellList".
   3.  Node A at the same time sets a timeout timer to abort the
       transaction if no response has been received when it expires.



Wang & Vilajosana          Expires May 4, 2017                  [Page 9]


Internet-Draft            6tisch-6top-protocol              October 2016


       The value of the timeout is out of the scope of this document and
       MAY be defined by the SF.  More details are given in
       Section 4.3.8.
   4.  The SF running on node B cannot match any of the proposed cells
       and selects 3 alternative candidate cells.  Node B sends back a
       6P Response to node A, indicating the 3 candidate alternative
       cells it selected.
   5.  Node B at the same time sets a timeout timer to abort the
       transaction if no response has been received when it expires.
       The value of the timeout is out of the scope of this document and
       MAY be defined by the SF.  More details are given in
       Section 4.3.8.
   6.  The SF running on node A selects 2 cells from the proposed
       CellList.  Node A sends back a 6P Confirmation to node B,
       indicating the cells it selected.
   7.  The result of this 6P Transaction is that 2 cells from A to B
       have been added to the TSCH schedule of both nodes A and B.

4.2.  Message Format

4.2.1.  6top Information Element

   6P messages are carried as payload of IEEE802.15.4 Payload
   Information Elements (IE) [IEEE802154-2015].  6p messages travel over
   a single hop.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Payload IE Length   |GroupID|T|    Sub-ID     |6top IE Content
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Payload Termination IE        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 6top IE is an IEEE Payload IE with GroupID IANA_IETF_IE_GROUP_ID.
   The 6top IE complies with the IE format defined in
   [I-D.kivinen-802-15-ie].  The Sub-ID used by the 6top IE is
   IANA_6TOP_SUBIE_ID.  The length of the 6top IE content is variable.
   The content of the 6top IE is specified in Section 4.2.  The Payload
   Termination IE is defined by the IEEE802.15.4 standard
   [IEEE802154-2015].

4.2.2.  General Message Format

   In all 6P messages, the 6top IE content has the following format:






Wang & Vilajosana          Expires May 4, 2017                 [Page 10]


Internet-Draft            6tisch-6top-protocol              October 2016


                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Other Fields...
     +-+-+-+-+-+-+-+-+-

   Version (6P Version):  The version of the 6P protocol.  Only version
         IANA_6TOP_6P_VERSION is defined in this document.  Future
         specifications MAY define further versions of the 6P protocol.
   Type (T):  Type of message.  The possible messages types are defined
         in Section 4.2.3.
   Reserved (R):  These two bits SHOULD be set to zero when sending the
         message and MUST be ignored on reception.
   Code: Command to carry out, or response code.  The list of command
         identifiers and return codes is defined only for version
         IANA_6TOP_6P_VERSION in this document.
   SFID (6top Scheduling Function Identifier):  The identifier of the SF
         to use to handle this message.  The SFID is defined in
         Section 5.1.
   SeqNum:  An identifier of the packet, used to match the 6P Request,
         6P Response and 6P Confirmation of the same 6P Transaction.
         The value of SeqNum MUST increment by exactly one at each new
         6P request issued to the same neighbor.
   GAB:  Schedule Generation for the cells scheduled from node A to node
         B.  The generation is used to ensure consistency between the
         schedule of the two neighbors.  Section 4.3.11 details how
         schedule generation is managed.
   GBA:  Schedule Generation for the cells scheduled from node B to node
         A.
   Other Fields:  The list of other fields depends on the value of the
         code field, as detailed below.

4.2.3.  6P Message Types

   Figure 7 lists the 6P message types.














Wang & Vilajosana          Expires May 4, 2017                 [Page 11]


Internet-Draft            6tisch-6top-protocol              October 2016


         Value of the "Type" field   Meaning
       +---------------------------+--------------------------------+
       | b00                       | 6P Request                     |
       +---------------------------+--------------------------------+
       | b01                       | 6P Response                    |
       +---------------------------+--------------------------------+
       | b10                       | 6P Confirmation                |
       |                           | (3-step 6top Transaction only) |
       +---------------------------+--------------------------------+
       | b11                       | Reserved                       |
       +---------------------------+--------------------------------+

                        Figure 7: 6P Message Types

4.2.4.  6P Command Identifiers

   The Code field contains a 6P Command Identifier when 6P Message is a
   6P Request.  Figure 8 lists the 6P command identifiers.

    Command ID     Value                   Description
   +--------------+-----------------------+----------------------------+
   | CMD_ADD      | IANA_6TOP_CMD_ADD     | add one or more cells      |
   +--------------+-----------------------+----------------------------+
   | CMD_DELETE   | IANA_6TOP_CMD_DELETE  | delete one or more cells   |
   +--------------+-----------------------+----------------------------+
   | CMD_STATUS   | IANA_6TOP_CMD_STATUS  | status of the schedule     |
   +--------------+-----------------------+----------------------------+
   | CMD_LIST     | IANA_6TOP_CMD_LIST    | list the scheduled cells   |
   |              |                       | in node B                  |
   +--------------+-----------------------+----------------------------+
   | CMD_CLEAR    | IANA_6TOP_CMD_CLEAR   | clear all cells on both    |
   |              |                       | node A and node B          |
   +--------------+-----------------------+----------------------------+
   | reserved     | TODO-0xf              | reserved                   |
   +--------------+-----------------------+----------------------------+

                     Figure 8: 6P Command Identifiers

4.2.5.  6P Return Codes

   The Code field contains a 6P Return Code when 6P Message is a 6P
   Response or a 6P Confirmation.  Figure 9 lists the 6P Return Codes
   and their meaning.








Wang & Vilajosana          Expires May 4, 2017                 [Page 12]


Internet-Draft            6tisch-6top-protocol              October 2016


    Return Code              Value          Description
   +--------------+------------------------+---------------------------+
   | RC_SUCCESS   | IANA_6TOP_RC_SUCCESS   | operation succeeded       |
   +--------------+------------------------+---------------------------+
   | RC_ERR_VER   | IANA_6TOP_RC_ERR_VER   | unsupported 6P version    |
   +--------------+------------------------+---------------------------+
   | RC_ERR_SFID  | IANA_6TOP_RC_ERR_SFID  | unsupported SFID          |
   +--------------+------------------------+---------------------------+
   | RC_ERR_GEN   | IANA_6TOP_RC_ERR_GEN   | schedule generation error |
   +--------------+------------------------+---------------------------+
   | RC_ERR_BUSY  | IANA_6TOP_RC_ERR_BUSY  | handling previous request |
   +--------------+------------------------+---------------------------+
   | RC_ERR_NORES | IANA_6TOP_RC_ERR_NORES | not enough resources      |
   +--------------+------------------------+---------------------------+
   | RC_ERR_RESET | IANA_6TOP_RC_ERR_RESET | error in state machine    |
   |              |                        | wrong sequence of         |
   |              |                        | commands                  |
   +--------------+------------------------+---------------------------+
   | RC_ERR       | IANA_6TOP_RC_ERR       | generic error             |
   +--------------+------------------------+---------------------------+
   | reserved     | TODO-0xf               |                           |
   +--------------+------------------------+---------------------------+

                         Figure 9: 6P Return Codes

4.2.6.  6P CellOptions

   The 6P CellOptions field is present in the 6P ADD, the 6P DELETE, the
   6P STATUS and the 6P LIST requests.  The 6P CellOptions apply to all
   elements contained in the CellList field.  Hence all cells in the
   CellList will be of the same type.  In the 6P ADD request, it is used
   to specify what type of cell to add.  In the 6P DELETE request, it is
   used to specify what type of cell to delete.  In the 6P STATUS and
   the 6P LIST requests, it is used as a selector of particular types of
   cells.  Figure 10 contains the RECOMMENDED format of the 6P
   CellOptions field.  Figure 11 contains the RECOMMENDED meaning of the
   6P CellOptions field for the 6P STATUS and 6P LIST requests.














Wang & Vilajosana          Expires May 4, 2017                 [Page 13]


Internet-Draft            6tisch-6top-protocol              October 2016


                      +---------+--------------------+
                      | bit 0   | Transmit (TX) cell |
                      +---------+--------------------+
                      | bit 1   | Receive (RX) cell  |
                      +---------+--------------------+
                      | bit 2   | SHARED cell        |
                      +---------+--------------------+
                      | bit 3-7 | Reserved           |
                      +---------+--------------------+

                Figure 10: Format of the CellOptions field

   Note: assuming node A issues the 6P command to node B.
       +-------------+-----------------------------------------------+
       | CellOptions | B's action when receiving a 6P message from A |
       | Value       |                                               |
       +-------------+-----------------------------------------------+
       |TX=0,RX=0,S=0| select all cells scheduled with A             |
       +-------------+-----------------------------------------------+
       |TX=1,RX=0,S=0| select the cells scheduled with A             |
       |             | and marked as RX                              |
       +-------------+-----------------------------------------------+
       |TX=0,RX=1,S=0| select the cells scheduled with A             |
       |             | and marked as TX                              |
       +-------------+-----------------------------------------------+
       |TX=1,RX=1,S=0| select the cells scheduled with A             |
       |             | and marked as TX and RX                       |
       +-------------+-----------------------------------------------+
       |TX=0,RX=0,S=1| select the cells scheduled with A             |
       |             | and marked as SHARED                          |
       +-------------+-----------------------------------------------+
       |TX=1,RX=0,S=1| select the cells scheduled with A             |
       |             | and marked as RX and SHARED                   |
       +-------------+-----------------------------------------------+
       |TX=0,RX=1,S=1| select the cells scheduled with A             |
       |             | and marked as TX and SHARED                   |
       +-------------+-----------------------------------------------+
       |TX=1,RX=1,S=1| select the cells scheduled with A             |
       |             | and marked as TX and RX and SHARED            |
       +-------------+-----------------------------------------------+

   Figure 11: Meaning of the 6P CellOptions field for the 6P STATUS and
                            the 6PLIST requests

   The CellOptions is an opaque set of bits, sent unmodified to the SF.
   The SF MAY redefine the format of the CellOptions field.  The SF MAY
   redefine the meaning of the CellOptions field.




Wang & Vilajosana          Expires May 4, 2017                 [Page 14]


Internet-Draft            6tisch-6top-protocol              October 2016


4.2.7.  6P Cell Format

   A CellList field MAY be present in a 6P ADD Request, 6P DELETE
   Request, a 6P Response or a 6P Confirmation.  It is composed of zero,
   one of more 6P Cell containers.  The CellOptions field defines the
   type of the cells in a particular CellList.  All cells in the
   CellList will be of the same type.  The 6P Cell is a 4-byte field,
   its RECOMMENDED format is:

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          slotOffset           |         channelOffset         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   slotOffset:  The slot offset of the cell.
   channelOffset:  The channel offset of the cell.

   The CellList is an opaque set of bytes, sent unmodified to the SF.
   The SF MAY redefine the format of the CellList field.

4.2.8.  6P ADD Request Format

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |  CellOptions  |   NumCells    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CellList ...
     +-+-+-+-+-+-+-+-+-

   Version:  Set to IANA_6TOP_6P_VERSION.
   Type: Set to 6P Request (see Figure 7).
   Reserved:  Set to 0.
   Code: Set to CMD_ADD (see Section 4.2.4).
   SFID: Identifier of the SF to be used by the receiver to handle the
         message.
   SeqNum:  Packet identifier to match 6P Request and 6P Response.
   GAB:  Schedule Generation for the cells scheduled from node A to node
         B.
   GBA:  Schedule Generation for the cells scheduled from node B to node
         A.
   Metadata:  Metadata used as extra signaling to the SF.  The contents
         of the Metadata field is an opaque set of bytes, and passed
         unmodified to the SF.  The meaning of this field depends on the




Wang & Vilajosana          Expires May 4, 2017                 [Page 15]


Internet-Draft            6tisch-6top-protocol              October 2016


         SF, and is out of scope of this document.  One example use can
         be to specify which slotframe to schedule the cells to.
   CellOptions:  Indicates the type of cells to add.  All cells in the
         CellList for a particular request will use the same CellOption.
         When different types of cells need to be allocated those need
         to be handled in separate ADD requests using different
         CellOptions.  The CellOptions is an opaque set of bits, sent
         unmodified to the SF.  The RECOMMENDED format of the
         CellOptions field is defined in Section 4.2.6.  The SF MAY
         redefine the format or the meaning of the CellOptions field.
   NumCells:  The number of additional cells the sender wants to
         schedule to the receiver according.
   CellList:  A list of 0, 1 or multiple 6P Cells.  The CellList is an
         opaque set of bytes, sent unmodified to the SF.  The
         RECOMMENDED format of each 6P Cell is defined in Section 4.2.7.
         The SF MAY redefine the format of the CellList field.

4.2.9.  6P DELETE Request Format

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |  CellOptions  |   NumCells    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CellList ...
     +-+-+-+-+-+-+-+-+-

   Version:  Set to IANA_6TOP_6P_VERSION.
   Type: Set to 6P Request (see Figure 7).
   Reserved:  Set to 0.
   Code: Set to CMD_DELETE (see Section 4.2.4).
   SFID: Identifier of the SF to be used by the receiver to handle the
         message.
   SeqNum:  Packet identifier to match 6P Request and 6P Response.
   GAB:  Schedule Generation for the cells scheduled from node A to node
         B.
   GBA:  Schedule Generation for the cells scheduled from node B to node
         A.
   Metadata:  Metadata used as extra signaling to the SF.  The contents
         of the Metadata field is an opaque set of bytes, and passed
         unmodified to the SF.  The meaning of this field depends on the
         SF, and is hence out of scope of this document.  One example
         use can be to specify which slotframe to delete the cells from.
   CellOptions:  Indicates the type of cells to delete.  The CellOptions
         is an opaque set of bits, sent unmodified to the SF.  The
         RECOMMENDED format of the CellOptions field is defined in



Wang & Vilajosana          Expires May 4, 2017                 [Page 16]


Internet-Draft            6tisch-6top-protocol              October 2016


         Section 4.2.6.  The SF MAY redefine the format or the meaning
         of the CellOptions field.
   NumCells:  The number of cells from the specified CellList the sender
         wants to delete from the schedule of both sender and receiver.
   CellList:  A list of 0, 1 or multiple 6P Cells.  The CellList is an
         opaque set of bytes, sent unmodified to the SF.  The
         RECOMMENDED format of each 6P Cell is defined in Section 4.2.7.
         The SF MAY redefine the format of the CellList field.

4.2.10.  6P STATUS Request Format

                        1                   2
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |  CellOptions  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version:  Set to IANA_6TOP_6P_VERSION.
   Type: Set to 6P Request (see Figure 7).
   Reserved:  Set to 0.
   Code: Set to CMD_STATUS (see Section 4.2.4).
   SFID: Identifier of the SF to be used by the receiver to handle the
         message.
   SeqNum:  Packet identifier to match request and response.
   GAB:  Schedule Generation for the cells scheduled from node A to node
         B.
   GBA:  Schedule Generation for the cells scheduled from node B to node
         A.
   Metadata:  Metadata used as extra signaling to the SF.  The contents
         of the Metadata field is an opaque set of bytes, and passed
         unmodified to the SF.  The meaning of this field depends on the
         SF, and is hence out of scope of this document.  One example
         use can be to specify which slotframe to get the status from.
   CellOptions:  Further selects which types of cells to be considered.
         The CellOptions is an opaque set of bits, sent unmodified to
         the SF.  The RECOMMENDED format and meaning of the CellOptions
         field is defined in Section 4.2.6.  The SF MAY redefine the
         format or the meaning of the CellOptions field.

4.2.11.  6P LIST Request Format

   The command lists the cells scheduled from node A to node B according
   to the specified CellOptions.






Wang & Vilajosana          Expires May 4, 2017                 [Page 17]


Internet-Draft            6tisch-6top-protocol              October 2016


                        1                   2
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |  CellOptions  |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Offset              |          MaxNumCells          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version:  Set to IANA_6TOP_6P_VERSION.
   Type: Set to 6P Request (see Figure 7).
   Reserved:  Set to 0.
   Code: Set to CMD_LIST (see Section 4.2.4).
   SFID: Identifier of the SF to be used by the receiver to handle the
         message.
   SeqNum:  Packet identifier to match request and response.
   GAB:  Schedule Generation for the cells scheduled from node A to node
         B.
   GBA:  Schedule Generation for the cells scheduled from node B to node
         A.
   Metadata:  Metadata used as extra signaling to the SF.  One example
         use can be to specify which slotframe to list the cells from.
         The contents of the Metadata field is an opaque set of bytes,
         and passed unmodified to the SF.  The meaning of this field
         depends on the SF, and is hence out of scope of this document.
   CellOptions:  Further selects which types of cells to be considered.
         The CellOptions is an opaque set of bits, sent unmodified to
         the SF.  The RECOMMENDED format and meaning of the CellOptions
         field is defined in Section 4.2.6.  The SF MAY redefine the
         format or the meaning of the CellOptions field.
   Reserved:  Set to 0.
   Offset:  The Offset of the first scheduled cell that is requested.
         The mechanism assumes cells are ordered according to some rule.
         The ordering rule is defined by the SF.
   MaxNumCells:  The maximum number of requested cells.  Less cells than
         MaxNumCells can be returned if they do not fit in the packet.

4.2.12.  6P CLEAR Request Format

                        1                   2
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Wang & Vilajosana          Expires May 4, 2017                 [Page 18]


Internet-Draft            6tisch-6top-protocol              October 2016


   Version:  Set to IANA_6TOP_6P_VERSION.
   Type: Set to 6P Request (see Figure 7).
   Reserved:  Set to 0.
   Code: Set to CMD_CLEAR (see Section 4.2.4).
   SFID: Identifier of the SF to be used by the receiver to handle the
         message.
   SeqNum:  Packet identifier to match request and response.
   GAB:  Schedule Generation for the cells scheduled from node A to node
         B.
   GBA:  Schedule Generation for the cells scheduled from node B to node
         A.
   Metadata:  Metadata used as extra signaling to the SF.  One example
         use can be to specify which slotframe to be cleared.  The
         contents of the Metadata field is an opaque set of bytes, and
         passed unmodified to the SF.  The meaning of this field depends
         on the SF, and is hence out of scope of this document.

4.2.13.  6P Response Format

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Other Fields...
     +-+-+-+-+-+-+-+-+-

   Version:  Set to IANA_6TOP_6P_VERSION.
   Type:  Set to 6P Response (see Figure 7).
   Reserved:  Set to 0.
   Code:  One of the 6P Return Codes listed in Section 4.2.5.
   SFID:  Identifier of the SF to be used by the receiver to handle the
      message.  The response MUST contain the same SFID value as the
      value in the SFID field of the 6P Request is responds to.
   SeqNum:  Packet identifier to match request and response.  The
      response MUST contain the same SeqNum value as the value in the
      SeqNum field of the 6P Request is responds to.
   GAB:  Schedule Generation for the cells scheduled from node A to node
      B.
   GBA:  Schedule Generation for the cells scheduled from node B to node
      A.
   Other Fields:  The contents depends on the Code field in the request,
      and listed below.

   When responding to an ADD, DELETE, LIST request, the "Other Field"
   contains a list of 0, 1 or multiple 6P Cells.  The format of a 6P
   Cell is defined in Section 4.2.7.




Wang & Vilajosana          Expires May 4, 2017                 [Page 19]


Internet-Draft            6tisch-6top-protocol              October 2016


   When responding to an STATUS request, the "Other Field" contains the
   number of cells scheduled between node A and node B that match the
   CellOptions field, encoded as a 2-octet unsigned integer.  This is
   shown in Figure 12.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num. Cells    |
     +-+-+-+-+-+-+-+-+

                                 Figure 12

   When responding to an CLEAR request, the "Other Field" is empty.

4.2.14.  6P Confirmation Format

   A 6P Confirmation is only used in a 3-step transaction, as the third
   step.  A 6P Confirmation Message has the exact same format as a 6P
   Response Message, except that the Type field is set to 6P
   Confirmation (see Figure 7).  The same Return Codes are used in both
   6P Response and 6P Confirmation messages.  The confirmation MUST
   contain the same SeqNum value as the value in the SeqNum field of the
   6P Request and 6P Response of the same transaction.

4.3.  Protocol Behavior

   We use the topology in Figure 1 for illustration.  We assume node A
   negotiates to add/delete cells to node B.

4.3.1.  Version Checking

   All messages contain a Version field.  If multiple Versions of the 6P
   protocol have been defined (in future specifications for Version
   values different than IANA_6TOP_6P_VERSION), a node MAY implement
   multiple protocol versions at the same time.  When receiving a 6P
   message with a Version number it does not implement, a node MUST
   reply with a 6P Response and a return code of RC_ERR_VER.  The
   Version field in the 6P Response MUST be the same as the Version
   field in the corresponding 6P Request.

4.3.2.  SFID Checking

   All messages contain a SFID field.  A node MAY support multiple SFs
   at the same time.  When receiving a 6P message with an unsupported
   SFID, a node MUST reply with a 6P Response and a return code of



Wang & Vilajosana          Expires May 4, 2017                 [Page 20]


Internet-Draft            6tisch-6top-protocol              October 2016


   RC_ERR_SFID.  The Version field in the 6P Response MUST be the same
   as the Version field in the corresponding 6P Request.  In a 3-step
   transaction, the Version field in the 6P Confirmation MUST match that
   of the 6P Request and 6P Response in the same transaction.

4.3.3.  Concurrent 6P Transactions

   Only a single 6P Transaction between two neighbors, in a given
   direction, can take place at the same time.  That is, a node MUST NOT
   issue a new 6P Request to a given neighbor before having received the
   6P Response for a previous request to that neighbor.  The only
   exception to this rule is when the previous 6P Transaction has timed
   out.  If a node receives a 6P Request from a given neighbor before
   having sent the 6P Response to the previous 6P Request from that
   neighbor, it MUST send back a 6P Response with a return code of
   RC_ERR_RESET.  A node receiving RC_ERR_RESET MUST abort the
   transaction and consider it never happened.

   Nodes A and B MAY support having two transactions going on at the
   same time, one in each direction.  Similarly, a node MAY support
   concurrent 6P Transactions from different neighbors.  In this case,
   the cells involved in an ongoing 6P Transaction MUST be locked until
   the transaction finishes.  For example, in Figure 1, node C can have
   a different ongoing 6P Transaction with nodes B and R.  In case a
   node does not have enough resources to handle concurrent 6P
   Transactions from different neighbors it MUST reply with a 6P
   Response with return code RC_ERR_NORES.  In case the requested cells
   are locked, it MUST reply to that request with a 6P Response with
   return code RC_ERR_BUSY.  The node receiving RC_ERR_BUSY or an
   RC_ERR_NORES may implement a retry mechanism, as defined by the SF.

4.3.4.  Timeout

   A timeout happens when the node sending the 6P Request has not
   received the 6P Response.  The timeout should be longer than the
   longest possible time it can take for the 6P Transaction to finish.
   The value of the timeout hence depends on the number of cells
   schedule between the neighbor nodes, on the maximum number of link-
   layer retransmissions, etc.  The SF determines the value of the
   timeout.  The value of the timeout is out of scope of this document.

4.3.5.  SeqNum Mismatch

   When a node receives a 6P Response with SeqNum value different from
   the SeqNum value in the 6P Request, it MUST drop the packet and
   consider the 6P Transaction as having failed.  This rules applies as
   well to a 6P Confirmation with a SeqNum value different from that of
   the 6P Request or 6P Response of the same transaction.



Wang & Vilajosana          Expires May 4, 2017                 [Page 21]


Internet-Draft            6tisch-6top-protocol              October 2016


4.3.6.  Clearing the Schedule

   When a 6P CLEAR command is issued from node A to node B, both nodes A
   and B MUST remove all the cells scheduled between them.  That is,
   node A MUST remove all the cells is has scheduled with B, and node B
   MUST remove all the cells is has scheduled with A.  In a 6P CLEAR
   command, the generation counters GAB and GBA MUST NOT be checked.
   That is, their value is "don't care".  In particular, even if a
   schedule generation mismatch is detected, it MUST NOT cause the
   transaction to abort.

4.3.7.  Adding Cells with 2-way Transaction

   We assume the topology in Figure 1 where the SF on node A decides to
   add NumCells cells to node B.

   Node A's SF selects NumCandidate>=NumCells cells from its schedule as
   candidate cells to node B.  The CellOptions field specifies the type
   of this cells.  NumCandidate MUST be larger or equal to NumCells.
   How many cells it selects (NumCandidate) and how that selection is
   done is specified in the SF and out of scope of this document.  Node
   A sends a 6P ADD Request to node B which contains the CellOptions,
   the value of NumCells and a seleciton of NumCandidate cells in the
   CellList.

   Upon receiving the request, node B's SF verifies which of the cells
   in the CellList it can install in its schedule following the
   specified CellOptions field.  How that selection is done is specified
   in the SF and out of scope of this document.  That verification can
   succeed (NumCells cells from the CellList can be used), fail (none of
   the cells from the CellList can be used) or partially succeed (less
   than NumCells cells from the CellList can be used).  In all cases,
   node B MUST send a 6P Response with return code set to RC_SUCCESS,
   and which specifies the list of cells that were scheduled following
   the CellOptions field.  That can contain 0 elements (when the
   verification failed), NumCells elements (succeeded) or between 0 and
   NumCells elements (partially succeeded).

   Upon receiving the response, node A adds the cells specified in the
   CellList according to the request CellOptions field.

4.3.8.  Aborting a 6P Transaction

   In case the receiver of a 6top request fails during a 6P Transaction
   and is unable to complete it, it SHOULD reply to that request with a
   6P Response with return code RC_ERR_RESET.  Upon receiving this 6top
   reply, the initiator of the 6P Transaction MUST consider the 6P
   Transaction as failed.



Wang & Vilajosana          Expires May 4, 2017                 [Page 22]


Internet-Draft            6tisch-6top-protocol              October 2016


4.3.9.  Deleting Cells

   The behavior for deleting cells is equivalent to that of adding cells
   except that:

   o  The nodes delete the cells they agree upon rather than adding
      them.
   o  All cells in the CellList MUST already be scheduled between the
      two nodes and match the CellOptions field.  If node A puts cells
      in its CellList that are not already scheduled between the two
      nodes and match the CellOptions field, node B replies with a
      RC_ERR_RESET return code.
   o  If the CellList in the 6P Request is empty, the SF on the
      receiving node is free to delete any cell from the sender, as long
      as it matches the CellOptions field.
   o  The CellList in a 6P Request (2-step transaction) or 6P Response
      (3-step transaction) MUST either be empty, contain exactly
      NumCells cells, or more than NumCells cells.  The case where the
      CellList is not empty but contains less than NumCells cells is not
      supported.

4.3.10.  Listing Cells

   When a node A issues a LIST command, it specifies:

   o  Through the CellOptions field, the type of cells to list,
      according to Section 4.2.6.
   o  Through the Offset field, the offset of the first CellOptions type
      cell to be present in the returned list.  The cell ordering policy
      is defined by the SF.
   o  Through the MaxNumCells field, the maximum number of cells to be
      present in the response.

   When receiving a LIST command, node B returns the cells in its
   schedule that match the CellOptions field as specified in
   Section 4.2.6 The RECOMMENDED format of each 6P Cell is defined in
   Section 4.2.7.  The SF MAY redefine the format of the CellList field.

   When node B receives a LIST request, the returned CellList in the 6P
   Response contains between 1 and MaxNumCells cells, starting from the
   specified Offset, as many as fit in the frame.  Node B MUST return at
   least one cell, unless the specified Offset is beyond the end of B's
   cell list in its schedule.  If node B has less than Offset cells of
   CellOptions type, the CellList it returns is empty.







Wang & Vilajosana          Expires May 4, 2017                 [Page 23]


Internet-Draft            6tisch-6top-protocol              October 2016


4.3.11.  Generation Management

   For each neighbor, a node maintains 2 two-bit generation numbers.
   These numbers are variables internal to the node.

   o  GTX is the generation number for the transmission cells to the
      neighbor.
   o  GRX is the generation number for the receive cells from the
      neighbor.

4.3.11.1.  Incrementing GTX and GRX

   GTX and GRX are 2-bit variables.  Their possible values are:

                   Value       Meaning
                 +-----------+---------------------------+
                 | 0b00      | Clear or never scheduled  |
                 +-----------+---------------------------+
                 | 0b01-0b10 | Lollipop Counter values   |
                 +-----------+---------------------------+
                 | 0b11      | Reserved                  |
                 +-----------+---------------------------+

     Figure 13: Possible values of the GRX and GTX generation numbers.

   GTX and GRX are set to 0 upon initialization, and after a 6P CLEAR
   command.  GTX and GRX are incremented by 1 after each time a cell
   with that neighbor is added/deleted from the schedule (e.g. after a
   successful 6P ADD or 6P DELETE transactions).  The value rolls from
   0b10 to 0b01.  This results in a lollipop counter with 0x00 as the
   start value, and 0b01 and 0b10 the count values.

4.3.11.2.  Setting GAB and GBA fields

   Each 6P message contains a GAB and a GBA field, used to indicate the
   current generation counters of the node transmitting the message.
   The value of the GAB and GBA fields MUST be set according to the
   following rules:

   o  When node A sends a 6P Request or 6P confirmation to node B, node
      A sets GAB to its GTX and GBA to its GRX.
   o  When node B sends a 6P Response to node A, node B sets GAB to its
      GRX and GBA to its GTX.








Wang & Vilajosana          Expires May 4, 2017                 [Page 24]


Internet-Draft            6tisch-6top-protocol              October 2016


4.3.11.3.  Detecting and Handling Schedule Generation Inconsistencies

   Upon receiving a 6P message, a node MUST do the following checks:

   o  When node B receives a 6P Request of 6P confirmation from node A,
      it verifies that GAB==GRX and GBA==GTX.
   o  When node A receives a 6P Response from node B, it verifies that
      GAB==GTX and GBA==GRX.

   If any of these comparisons is false, the node has detected a
   schedule generation inconsistency.

   When a schedule generation inconsistency is detected:

   o  If the code of the 6P Request is different from CMD_CLEAR, the
      node MUST reply with error code RC_ERR_GEN.
   o  If the code of the 6P Request is CMD_CLEAR, the schedule
      generation inconsistency MUST be ignored.

   It is up to the Scheduling Function to define the action to take when
   an schedule generation inconsistency is detected.  The RECOMMENDED
   action is to issue a 6P CLEAR command.

4.3.12.  Handling error responses

   A return code with a name starting with "RC_ERR" in Figure 9
   indicates an error.  When a node receives a 6P Response with such an
   error, it MUST consider the 6P Transaction failed.  In particular, if
   this was a response to a 6P ADD/DELETE Request, the node MUST NOT
   add/delete any of the cells involved in this 6P Transaction.
   Similarly, a node sending a 6P Response with an "RC_ERR" return code
   MUST NOT add/delete any cells as part of that 6P Transaction.
   Defining what to do after an error has occurred is out of scope of
   this document.  The SF defines what to do after an error has
   occurred.

4.4.  Security

   6P messages are secured through link-layer security.  When link-layer
   security is enabled, the 6P messages MUST be secured.  This is
   possible because 6P messages are carried as Payload IE.

5.  Guidelines for 6top Scheduling Functions (SF)








Wang & Vilajosana          Expires May 4, 2017                 [Page 25]


Internet-Draft            6tisch-6top-protocol              October 2016


5.1.  SF Identifier (SFID)

   Each SF has an identifier.  The identifier is encoded as a 1-byte
   field.  The identifier space is divided in the following ranges.

                          Range      Meaning
                        +-----------+-------------+
                        | 0x00-0xef | managed     |
                        +-----------+--------------
                        | 0xf0-0xfe | unmanaged   |
                        +-----------+-------------+
                        | 0xff      | reserved    |
                        +-----------+-------------+

                          Figure 14: SFID range.

   SF identifiers in the managed space MUST be managed by IANA.

5.2.  Requirements for an SF

   The specification for an SF

   o  MUST specify an identifier for that SF.
   o  MUST specify the rule for a node to decide when to add/delete one
      or more cells to a neighbor.
   o  MUST specify the rule for a Transaction source to select cells to
      add to the CellList field in the 6P ADD Request.
   o  MUST specify the rule for a Transaction destination to select
      cells from CellList to add to its schedule.
   o  MUST specify a value for the 6P Timeout, or a rule/equation to
      calculate it.
   o  MUST specify a meaning for the "Metadata" field in the 6P ADD
      Request.
   o  MUST specify the behavior of a node when it boots.
   o  MUST specify what to do after an error has occurred (either the
      node sent a 6P Response with an error code, or received one).
   o  MUST specify the list of statistics to gather.  An example
      statistic if the number of transmitted frames to each neighbor.
      In case the SF requires no statistics to be gathered, the specific
      of the SF MUST explicitly state so.
   o  SHOULD clearly state the application domain the SF is created for.
   o  SHOULD contain examples which highlight normal and error
      scenarios.
   o  SHOULD contain a list of current implementations, at least during
      the I-D state of the document, per [RFC6982].
   o  SHOULD contain a performance evaluation of the scheme, possibly
      through references to external documents.
   o  MAY redefine the format of the CellList field.



Wang & Vilajosana          Expires May 4, 2017                 [Page 26]


Internet-Draft            6tisch-6top-protocol              October 2016


   o  MAY redefine the format of the CellOptions field.
   o  MAY redefine the meaning of the CellOptions field.

5.3.  Recommended Structure of an SF Specification

   The following section structure for a SF document is RECOMMENDED:

   o  Introduction
   o  Scheduling Function Identifier
   o  Rules for Adding/Deleting Cells
   o  Rules for CellList
   o  6P Timeout Value
   o  Meaning of the Metadata Field
   o  Node Behavior at Boot
   o  6P Error Handling
   o  Examples
   o  Implementation Status
   o  Security Considerations
   o  IANA Considerations

6.  Implementation Status

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC6982].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC6982], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   ETSI 6TiSCH/6lo plugtests:  6P was one of the protocols addressed
      during the ETSI 6TiSCH #3 plugtests organized on 15-17 July 2016
      in Berlin, Germany.  15 entities participated in this event,
      verifying the compliance and interoperability of their
      implementation of 6P.  This event happened under NDA, so neither
      the name of the entities nor the test results are public.  This



Wang & Vilajosana          Expires May 4, 2017                 [Page 27]


Internet-Draft            6tisch-6top-protocol              October 2016


      event is, however, a clear indication of the maturity of 6P, and
      the interest it generates.  More information about the event at
      http://www.etsi.org/news-events/events/1077-6tisch-6lo-plugtests.
   ETSI 6TiSCH #2 plugtests:  6P was one of two protocols addressed
      during the ETSI 6TiSCH #2 plugtests organized on 2-4 February 2016
      in Paris, France.  14 entities participated in this event,
      verifying the compliance and interoperability of their
      implementation of 6P.  This event happened under NDA, so neither
      the name of the entities nor the test results are public.  This
      event is, however, a clear indication of the maturity of 6P, and
      the interest it generates.  More information about the event at
      http://www.etsi.org/news-events/events/1022-6TiSCH-2-plugtests.
   OpenWSN:  6P is implemented in the OpenWSN project [OpenWSN] under a
      BSD open-source license.  The authors of this document are
      collaborating with the OpenWSN community to gather feedback about
      the status and performance of the protocols described in this
      document.  Results from that discussion will appear in this
      section in future revision of this specification.  More
      information about this implementation at http://www.openwsn.org/.
   Wireshark Dissector:  A Wireshark dissector for 6P is implemented
      under a BSD open-source license.  It is not yet merged into the
      main Wireshark build, but can be downloaded at https://github.com/
      openwsn-berkeley/dissectors/.

7.  Security Considerations

   6P messages are carried inside IEEE802.15.4 Payload Information
   Elements (IEs).  Those Payload IEs are encrypted and authenticated at
   the link layer through CCM*.  6P benefits from the same level of
   security as any other Payload IE.  The 6P protocol does not define
   its own security mechanisms.  A key management solution is out of
   scope for this document.  The 6P protocol will benefit for the key
   management solution used in the network.

8.  IANA Consideration

   TODO: write out this section as soon as the discussion with the IEEE
   about a possible IETF IE ID has concluded.

   o  TODO: IANA_IETF_IE_GROUP_ID
   o  TODO: IANA_6TOP_SUBIE_ID
   o  TODO: IANA_6TOP_6P_VERSION
   o  TODO: IANA_6TOP_CMD_ADD
   o  TODO: IANA_6TOP_CMD_DELETE
   o  TODO: IANA_6TOP_CMD_STATUS
   o  TODO: IANA_6TOP_CMD_LIST
   o  TODO: IANA_6TOP_CMD_CLEAR
   o  TODO: IANA_6TOP_RC_SUCCESS



Wang & Vilajosana          Expires May 4, 2017                 [Page 28]


Internet-Draft            6tisch-6top-protocol              October 2016


   o  TODO: IANA_6TOP_RC_ERR_VER
   o  TODO: IANA_6TOP_RC_ERR_SFID
   o  TODO: IANA_6TOP_RC_ERR_GEN
   o  TODO: IANA_6TOP_RC_ERR_BUSY
   o  TODO: IANA_6TOP_RC_ERR_NORES
   o  TODO: IANA_6TOP_RC_ERR_RESET
   o  TODO: IANA_6TOP_RC_ERR

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [I-D.kivinen-802-15-ie]
              Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information
              Element for IETF", draft-kivinen-802-15-ie-04 (work in
              progress), October 2016.

   [IEEE802154-2015]
              IEEE standard for Information Technology, "IEEE Std
              802.15.4-2015 - IEEE Standard for Low-Rate Wireless
              Personal Area Networks (WPANs)", October 2015.

9.2.  Informative References

   [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
              IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
              Internet of Things (IoT): Problem Statement", RFC 7554,
              DOI 10.17487/RFC7554, May 2015,
              <http://www.rfc-editor.org/info/rfc7554>.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982,
              DOI 10.17487/RFC6982, July 2013,
              <http://www.rfc-editor.org/info/rfc6982>.

   [I-D.ietf-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", draft-ietf-6tisch-minimal-16 (work in
              progress), June 2016.







Wang & Vilajosana          Expires May 4, 2017                 [Page 29]


Internet-Draft            6tisch-6top-protocol              October 2016


   [OpenWSN]  Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
              Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
              a Standards-Based Low-Power Wireless Development
              Environment", Transactions on Emerging Telecommunications
              Technologies , August 2012.

Appendix A.  [TEMPORARY] Changelog

   o  draft-ietf-6tisch-6top-protocol-03

      *  Added a reference to [I-D.kivinen-802-15-ie].
      *  Added the Type field.
      *  Editorial changes (figs, typos, ...)
   o  draft-ietf-6tisch-6top-protocol-02

      *  Rename COUNT to STATUS
      *  Split LIST to LIST AB and LIST BA
      *  Added generation counters and describing generation tracking of
         the schedule
      *  Editorial changes (figs, typos, ...)
   o  draft-ietf-6tisch-6top-protocol-01

      *  Clarifying locking of resources in concurrent transactions
      *  Clarifying return of RC_ERR_BUSY in case of concurrent
         transactions without enough resources
   o  draft-ietf-6tisch-6top-protocol-00

      *  Informational to Std track
   o  draft-wang-6tisch-6top-protocol-00

      *  Editorial overhaul: fixing typos, increasing readability,
         clarifying figures.
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/47
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/54
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/55
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/49
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/53
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/44
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/48
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/43



Wang & Vilajosana          Expires May 4, 2017                 [Page 30]


Internet-Draft            6tisch-6top-protocol              October 2016


      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/52
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/45
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/51
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/50
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/46
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/41
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/42
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/39
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/40
   o  draft-wang-6tisch-6top-sublayer-05

      *  Specifies format of IE
      *  Adds token in messages to match request and response
   o  draft-wang-6tisch-6top-sublayer-04

      *  Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID.
      *  Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC.
      *  Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub-
         IE.
   o  draft-wang-6tisch-6top-sublayer-03

      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/32/missing-command-list
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/31/missing-command-count
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/30/missing-command-clear
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/37/6top-atomic-transaction-6p-transaction
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/35/separate-opcode-from-rc
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/36/add-length-field-in-ie
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/27/differentiate-rc_err_busy-and
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/29/missing-rc-rc_reset
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/28/the-sf-must-specify-the-behavior-of-a-mote



Wang & Vilajosana          Expires May 4, 2017                 [Page 31]


Internet-Draft            6tisch-6top-protocol              October 2016


      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/26/remove-including-their-number
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/
         issues/34/6of-sf
      *  https://bitbucket.org/6tisch/draft-wang-6tisch-6top-
         protocol/issues/33/add-a-figure-showing-the-negociation
   o  draft-wang-6tisch-6top-sublayer-02

      *  introduces the 6P protocol and the notion of 6top Transaction.
      *  introduces the concept of 6OF and its 6OFID.

Authors' Addresses

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

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


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

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




















Wang & Vilajosana          Expires May 4, 2017                 [Page 32]


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