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

Versions: (draft-wang-6tisch-6top-protocol) 00 01 02 03 04 05 06 07 08 09 10 11 12

6TiSCH                                                      Q. Wang, Ed.
Internet-Draft                           Univ. of Sci. and Tech. Beijing
Intended status: Standards Track                           X. Vilajosana
Expires: December 22, 2018               Universitat Oberta de Catalunya
                                                             T. Watteyne
                                                          Analog Devices
                                                           June 20, 2018


                6TiSCH Operation Sublayer Protocol (6P)
                   draft-ietf-6tisch-6top-protocol-12

Abstract

   This document defines the IPv6 over the TSCH mode of IEEE 802.15.4e
   (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables
   distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
   to add/delete TSCH cells to one another.  6P is part of the 6TiSCH
   Operation Sublayer (6top), the next higher layer to the IEEE Std
   802.15.4 TSCH medium access control layer.  The 6top layer terminates
   the 6top Protocol defined in this document, and runs one or more 6top
   Scheduling Function(s).  A 6top Scheduling Function (SF) decides when
   to add/delete cells, and triggers 6P Transactions.  This document
   lists the requirements for an SF, but leaves the definition of SFs
   out of scope.

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 https://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."




Wang, et al.            Expires December 22, 2018               [Page 1]


Internet-Draft            6tisch-6top-protocol                 June 2018


   This Internet-Draft will expire on December 22, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  6TiSCH Operation Sublayer (6top)  . . . . . . . . . . . . . .   4
     2.1.  Hard/Soft Cells . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Using 6P with the Minimal 6TiSCH Configuration  . . . . .   5
   3.  6top Protocol (6P)  . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  6P Transactions . . . . . . . . . . . . . . . . . . . . .   6
       3.1.1.  2-step 6P Transaction . . . . . . . . . . . . . . . .   7
       3.1.2.  3-step 6P Transaction . . . . . . . . . . . . . . . .   9
     3.2.  Message Format  . . . . . . . . . . . . . . . . . . . . .  11
       3.2.1.  6top Information Element (IE) . . . . . . . . . . . .  11
       3.2.2.  Generic 6P Message Format . . . . . . . . . . . . . .  11
       3.2.3.  6P CellOptions  . . . . . . . . . . . . . . . . . . .  12
       3.2.4.  6P CellList . . . . . . . . . . . . . . . . . . . . .  15
     3.3.  6P Commands and Operations  . . . . . . . . . . . . . . .  16
       3.3.1.  Adding Cells  . . . . . . . . . . . . . . . . . . . .  16
       3.3.2.  Deleting Cells  . . . . . . . . . . . . . . . . . . .  18
       3.3.3.  Relocating Cells  . . . . . . . . . . . . . . . . . .  19
       3.3.4.  Counting Cells  . . . . . . . . . . . . . . . . . . .  25
       3.3.5.  Listing Cells . . . . . . . . . . . . . . . . . . . .  26
       3.3.6.  Clearing the Schedule . . . . . . . . . . . . . . . .  28
       3.3.7.  Generic Signaling Between SFs . . . . . . . . . . . .  29
     3.4.  Protocol Functional Details . . . . . . . . . . . . . . .  29
       3.4.1.  Version Checking  . . . . . . . . . . . . . . . . . .  29
       3.4.2.  SFID Checking . . . . . . . . . . . . . . . . . . . .  30
       3.4.3.  Concurrent 6P Transactions  . . . . . . . . . . . . .  30
       3.4.4.  6P Timeout  . . . . . . . . . . . . . . . . . . . . .  31
       3.4.5.  Aborting a 6P Transaction . . . . . . . . . . . . . .  31
       3.4.6.  SeqNum Management . . . . . . . . . . . . . . . . . .  31
       3.4.7.  Handling Error Responses  . . . . . . . . . . . . . .  38



Wang, et al.            Expires December 22, 2018               [Page 2]


Internet-Draft            6tisch-6top-protocol                 June 2018


     3.5.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  38
   4.  Requirements for 6top Scheduling Functions (SF) Specification  38
     4.1.  SF Identifier (SFID)  . . . . . . . . . . . . . . . . . .  38
     4.2.  Requirements for an SF specification  . . . . . . . . . .  38
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  39
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  39
     6.1.  IETF IE Subtype '6P'  . . . . . . . . . . . . . . . . . .  40
     6.2.  6TiSCH parameters sub-registries  . . . . . . . . . . . .  40
       6.2.1.  6P Version Numbers  . . . . . . . . . . . . . . . . .  40
       6.2.2.  6P Message Types  . . . . . . . . . . . . . . . . . .  41
       6.2.3.  6P Command Identifiers  . . . . . . . . . . . . . . .  41
       6.2.4.  6P Return Codes . . . . . . . . . . . . . . . . . . .  42
       6.2.5.  6P Scheduling Function Identifiers  . . . . . . . . .  43
       6.2.6.  6P CellOptions bitmap . . . . . . . . . . . . . . . .  44
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  44
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  45
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  45
   Appendix A.  Recommended Structure of an SF Specification . . . .  46
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

1.  Introduction

   All communication in a IPv6 over the TSCH mode of IEEE 802.15.4e
   (6TiSCH) network is orchestrated by a schedule [RFC7554].  The
   schedule is composed of cells, each identified by a
   [slotOffset,channelOffset].  This specification defines the 6TiSCH
   Operation Sublayer (6top) Protocol (6P), terminated by the 6TiSCH
   Operation sublayer (6top).  6P allows a node to communicate with a
   neighbor node to add/delete TSCH cells to one another.  This results
   in distributed schedule management in a 6TiSCH network.  The 6top
   layer terminates the 6top Protocol, and runs one or more 6top
   Scheduling Functions (SFs) that decide when to add/delete cells and
   trigger 6P Transactions.  The SF is out of scope of this document but
   this document defines the requirements for an SF.

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

                    Figure 1: A simple 6TiSCH network.

   The example network depicted in Figure 1 is used to describe the
   interaction between nodes.  We consider the canonical case where node
   "A" issues 6P requests to node "B".  We keep this example throughout



Wang, et al.            Expires December 22, 2018               [Page 3]


Internet-Draft            6tisch-6top-protocol                 June 2018


   this document.  Throughout the document, node A always represents the
   node that issues a 6P request; node B the node that receives this
   request.

   We consider that node A monitors 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 node B per unit of time exceeds the capacity offered by
      the TSCH cells it has scheduled to node B, it triggers a 6P
      Transaction with node B to add one or more cells to the TSCH
      schedule of both nodes.
   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 "relocate" the cell
      which undergoes collisions to a different
      [slotOffset,channelOffset] location in the TSCH schedule.

   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.  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.  At least one
   SF MUST be running.  The SFID field contained in all 6P messages
   allows a node to invoke the appropriate SF on a per-6P Transaction
   basis.

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

2.  6TiSCH Operation Sublayer (6top)

   As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the
   next higher layer to the IEEE Std 802.15.4 TSCH medium access control
   (MAC) layer [IEEE802154].  We use "802.15.4" as a short version of
   "IEEE Std 802.15.4" in this document.









Wang, et al.            Expires December 22, 2018               [Page 4]


Internet-Draft            6tisch-6top-protocol                 June 2018


                                   .
               |                   .                      |
               |             higher layers                |
               +------------------------------------------+
               |                 6top                     |
               +------------------------------------------+
               |          IEEE Std 802.15.4 TSCH          |
               |                   .                      |
                                   .

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

   The roles of the 6top sublayer are to:

   o  Terminate the 6top Protocol (6P), which allows neighbor nodes to
      communicate to add/delete cells to one another.
   o  Run one or multiple 6top Scheduling Functions (SFs), which define
      the rules that decide when to add/delete cells.

2.1.  Hard/Soft Cells

   Each cell in the schedule is 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
   schedule [RFC8180].

2.2.  Using 6P with the Minimal 6TiSCH Configuration

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

   o  Slotframe 0 is used for traffic defined in the Minimal 6TiSCH
      Configuration.  In Figure 3, Slotframe 0 is 5 slots long, but it
      can be shorter or longer.
   o  6P allocates cells from Slotframe 1.  In Figure 3, Slotframe 1 is
      10 slots long, but it can be shorter or longer.










Wang, et al.            Expires December 22, 2018               [Page 5]


Internet-Draft            6tisch-6top-protocol                 June 2018


                    | 0    1    2    3    4  | 0    1    2    3    4  |
                    +------------------------+------------------------+
        Slotframe 0 |    |    |    |    |    |    |    |    |    |    |
       5 slots long | EB |    |    |    |    | EB |    |    |    |    |
   (Minimal 6TiSCH) |    |    |    |    |    |    |    |    |    |    |
                    +-------------------------------------------------+

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

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

   The Minimal 6TiSCH Configuration cell SHOULD be allocated from a
   slotframe of higher priority than the slotframe used by 6P for
   dynamic cell allocation.  This way, dynamically allocated cells
   cannot "mask" the cells used by the Minimal 6TiSCH Configuration.
   6top MAY support additional slotframes; how to use additional
   slotframes is out of scope for this document.

3.  6top Protocol (6P)

   The 6top Protocol (6P) enables two neighbor nodes to add/delete/
   relocate cells in their TSCH schedule.  Conceptually, two neighbor
   nodes "negotiate" the location of the cells to add, delete, or
   relocate in their TSCH schedule.

3.1.  6P Transactions

   We call "6P Transaction" a complete negotiation between two neighbor
   nodes.  A particular 6P Transaction is executed between two nodes as
   a result of an action triggered by one SF.  For a 6P Transaction to
   succeed, both nodes must use the same SF to handle the particular
   transaction.  A 6P Transaction starts when a node wishes to
   add/delete/relocate one or more cells with one of its neighbors.  A
   6P Transaction ends when the cell(s) have been added/deleted/
   relocated in the schedule of both nodes, or when the 6P Transaction
   has failed.

   6P messages exchanged between nodes A and B during a 6P Transaction
   SHOULD be exchanged on non-shared unicast cells ("dedicated" cells)
   between A and B.  If no dedicated cells are scheduled between nodes A
   and B, shared cells MAY be used.




Wang, et al.            Expires December 22, 2018               [Page 6]


Internet-Draft            6tisch-6top-protocol                 June 2018


   Keeping consistency between the schedules of the two neighbor nodes
   is important.  A loss of consistency can cause loss of connectivity.
   One example is when node A has a transmit cell to node B, but node B
   does not have the corresponding reception cell.  To verify
   consistency, neighbor nodes maintain a Sequence Number (SeqNum).
   Neighbor nodes exchange the SeqNum as part of each 6P Transaction to
   detect a possible inconsistency.  This mechanism is explained in
   Section 3.4.6.2.

   An implementation MUST include a mechanism to associate each
   scheduled cell with the SF that scheduled it.  This mechanism is
   implementation-specific and out of scope of this document.

   A 6P Transaction can consist of 2 or 3 steps.  A 2-step transaction
   is used when node A selects the cells to be allocated.  A 3-step
   transaction is used when node B selects the cells to be allocated.
   An SF MUST specify whether to use 2-step transactions, 3-step
   transactions, or both.

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

3.1.1.  2-step 6P Transaction

   Figure 4 shows an example 2-step 6P Transaction.  In a 2-step
   transaction, node A selects the candidate cells.  Several elements
   are left out to simplify understanding.
























Wang, et al.            Expires December 22, 2018               [Page 7]


Internet-Draft            6tisch-6top-protocol                 June 2018


                +----------+                           +----------+
                |  Node A  |                           |  Node B  |
                +----+-----+                           +-----+----+
                     |                                       |
                     | 6P ADD Request                        |
                     |   Type         = REQUEST              |
                     |   Code         = ADD                  |
                     |   SeqNum       = 123                  |
      cells          |   NumCells     = 2                    |
      locked         |   CellList     = [(1,2),(2,2),(3,5)]  |
       +--           |-------------------------------------->|
       |             |                                L2 ACK |
       |  6P Timeout |<- - - - - - - - - - - - - - - - - - - |
       |        |    |                                       |
       |        |    | 6P Response                           |
       |        |    |   Type         = RESPONSE             |
       |        |    |   Code         = RC_SUCCESS           |
       |        |    |   SeqNum       = 123                  | cells
       |        |    |   CellList     = [(2,2),(3,5)]        | locked
       +->      X    |<--------------------------------------| --+
                     | L2 ACK                                |   |
                     | - - - - - - - - - - - - - - - - - - ->| <-+
                     |                                       |

                Figure 4: An example 2-step 6P Transaction.

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

   1.  The SF running on node A determines that 2 extra cells need to be
       scheduled to node B.
   2.  The SF running on node A selects candidate cells for node B to
       choose from.  Node A MUST select at least as many candidate cells
       as the number of cells to add.  Here, node A selects 3 candidate
       cells.  Node A locks those candidate cells in its schedule until
       it receives a 6P response.
   3.  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.  This 6P ADD
       Request is link-layer acknowledged by node B (labeled "L2 ACK" in
       Figure 4).
   4.  After having successfully sent the 6P ADD Request (i.e. receiving
       the link-layer acknowledgment), node A starts a 6P Timeout to
       abort the 6P Transaction in case no response is received from
       node B.
   5.  The SF running on node B selects 2 out of the 3 cells from the
       CellList of the 6P ADD Request.  Node B locks those cells in its
       schedule until the transmission is successful (i.e. node B



Wang, et al.            Expires December 22, 2018               [Page 8]


Internet-Draft            6tisch-6top-protocol                 June 2018


       receives a link-layer ACK from node A).  Node B sends back a 6P
       Response to node A, indicating the cells it has selected.  The
       response is link-layer acknowledged by node A.
   6.  Upon completion of this 6P Transaction, 2 cells from A to B have
       been added to the TSCH schedule of both nodes A and B.
   7.  An inconsistency in the schedule can happen if the 6P Timeout
       expires when the 6P Response is in the air, if the last link-
       layer ACK for the 6P Response is lost, or if one of the nodes is
       power cycled during the transaction.  6P provides an
       inconsistency detection mechanism described in Section 3.4.6.1 to
       cope with such situations.

3.1.2.  3-step 6P Transaction

   Figure 5 shows an example 3-step 6P Transaction.  In a 3-step
   transaction, node B selects the candidate cells.  Several elements
   are left out to simplify understanding.


































Wang, et al.            Expires December 22, 2018               [Page 9]


Internet-Draft            6tisch-6top-protocol                 June 2018


            +----------+                           +----------+
            |  Node A  |                           |  Node B  |
            +----+-----+                           +-----+----+
                 |                                       |
                 | 6P ADD Request                        |
                 |   Type         = REQUEST              |
                 |   Code         = ADD                  |
                 |   SeqNum       = 178                  |
                 |   NumCells     = 2                    |
                 |   CellList     = []                   |
                 |-------------------------------------->|
                 |                                L2 ACK |
      6P Timeout |<- - - - - - - - - - - - - - - - - - - |
            |    |                                       |
            |    | 6P Response                           |
            |    |   Type         = RESPONSE             |
            |    |   Code         = RC_SUCCESS           |
            |    |   SeqNum       = 178                  |         cells
            |    |   CellList     = [(1,2),(2,2),(3,5)]  |        locked
            X    |<--------------------------------------|          --+
                 | L2 ACK                                |            |
                 | - - - - - - - - - - - - - - - - - - ->| 6P Timeout |
                 |                                       |    |       |
                 | 6P Confirmation                       |    |       |
                 |   Type         = CONFIRMATION         |    |       |
                 |   Code         = RC_SUCCESS           |    |       |
    cells        |   SeqNum       = 178                  |    |       |
    locked       |   CellList     = [(2,2),(3,5)]        |    |       |
     +--         |-------------------------------------->|    X    <--+
     |           |                                L2 ACK |
     +->         |<- - - - - - - - - - - - - - - - - - - |
                 |                                       |

                Figure 5: An example 3-step 6P Transaction.

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

   1.  The SF running on node A determines that 2 extra cells need to be
       scheduled to node B.  The SF uses a 3-step transaction, so it
       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".
       This 6P ADD Request is link-layer acknowledged by node B.
   3.  After having successfully sent the 6P ADD Request, node A starts
       a 6P Timeout to abort the transaction in case no 6P Response is
       received from node B.
   4.  The SF running on node B selects 3 candidate cells, and locks
       them.  Node B sends back a 6P Response to node A, indicating the



Wang, et al.            Expires December 22, 2018              [Page 10]


Internet-Draft            6tisch-6top-protocol                 June 2018


       3 cells it has selected.  The response is link-layer acknowledged
       by node A.
   5.  After having successfully sent the 6P Response, node B starts a
       6P Timeout to abort the transaction in case no 6P Confirmation is
       received from node A.
   6.  The SF running on node A selects 2 cells from the CellList field
       in the 6P Response, and locks those.  Node A sends back a 6P
       Confirmation to node B, indicating the cells it selected.  The
       confirmation is link-layer acknowledged by node B.
   7.  Upon completion of the 6P Transaction, 2 cells from A to B have
       been added to the TSCH schedule of both nodes A and B.
   8.  An inconsistency in the schedule can happen if the 6P Timeout
       expires when the 6P Confirmation is in the air, if the last link-
       layer ACK for the 6P Confirmation is lost, or if one of the nodes
       is power cycled during the transaction.  6P provides an
       inconsistency detection mechanism described in Section 3.4.6.1 to
       cope with such situations.

3.2.  Message Format

3.2.1.  6top Information Element (IE)

   6P messages travel over a single hop.  6P messages are carried as
   payload of an 802.15.4 Payload Information Element (IE) [IEEE802154].
   The messages are encapsulated within the Payload IE Header.  The
   Group ID is set to the IETF IE value defined in [RFC8137].  The
   content is encapsulated by a SubType ID, as defined in [RFC8137].

   Since 6P messages are carried in IEs, IEEE bit/byte ordering applies.
   Bits within each field in the 6top IE are numbered from 0 (leftmost
   and least significant) to k-1 (rightmost and most significant), where
   the length of the field is k bits.  Fields that are longer than a
   single octet are copied to the packet in the order from the octet
   containing the lowest numbered bits to the octet containing the
   highest numbered bits (little endian).

   This document defines the "6top IE", a SubType of the IETF IE defined
   in [RFC8137], with subtype ID IANA_6TOP_SUBIE_ID.  The SubType
   Content of the "6top IE" is defined in Section 3.2.2.  The length of
   the "6top IE" content is variable.

3.2.2.  Generic 6P Message Format

   All 6P messages follow the generic format shown in Figure 6.







Wang, et al.            Expires December 22, 2018              [Page 11]


Internet-Draft            6tisch-6top-protocol                 June 2018


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

                   Figure 6: Generic 6P Message Format.

   6P Version (Version):  The version of the 6P protocol.  Only version
         0 is defined in this document.  Future specifications may
         define further versions of the 6P protocol.
   Type (T):  Type of message.  The message types are defined in
         Section 6.2.2.
   Reserved (R):  Reserved bits.  These two bits SHOULD be set to zero
         when sending the message, and MUST be ignored upon reception.
   Code: The Code field contains a 6P Command Identifier when the 6P
         message is of Type REQUEST.  Section 6.2.3 lists the 6P command
         identifiers.  The Code field contains a 6P return code when the
         6P message is of Type RESPONSE or CONFIRMATION.  Section 6.2.4
         lists the 6P return codes.  The same return codes are used in
         both 6P Response and 6P Confirmation messages.
   6top Scheduling Function Identifier (SFID):  The identifier of the SF
         to use to handle this message.  The SFID is defined in
         Section 4.1.
   SeqNum:  Sequence number associated with the 6P Transaction, used to
         match the 6P Request, 6P Response and 6P Confirmation of the
         same 6P Transaction.  The value of SeqNum MUST be different at
         each new 6P Request issued to the same neighbor and using the
         same SF.  The SeqNum is also used to ensure consistency between
         the schedules of the two neighbors.  Section 3.4.6 details how
         the SeqNum is managed.
   Other Fields:  The list of other fields and how they are used is
         detailed in Section 3.3.

   6P Requests, 6P Response and 6P Confirmation messages for a same
   transaction MUST share the same Version, SFID and SeqNum values.

   Future versions of the 6P Message SHOULD maintain the format of the
   6P Version, Type and Code fields for backward compatibility.

3.2.3.  6P CellOptions

   An 8-bit 6P CellOptions bitmap is present in the following 6P
   requests: ADD, DELETE, COUNT, LIST, RELOCATE.  The format and meaning
   of this field MAY be redefined by the SF; the routine that parses
   this field is therefore associated with a specific SF.



Wang, et al.            Expires December 22, 2018              [Page 12]


Internet-Draft            6tisch-6top-protocol                 June 2018


   o  In the 6P ADD request, the 6P CellOptions bitmap is used to
      specify what type of cell to add.
   o  In the 6P DELETE request, the 6P CellOptions bitmap is used to
      specify what type of cell to delete.
   o  In the 6P RELOCATE request, the 6P CellOptions bitmap is used to
      specify what type of cell to relocate.
   o  In the 6P COUNT and the 6P LIST requests, the 6P CellOptions
      bitmap is used as a selector of a particular type of cells.

   The content of the 6P CellOptions bitmap applies to all elements in
   the CellList field.  The possible values of the 6P CellOptions are:
   TX = 1 (resp. 0) refers to macTxType = TRUE (resp.  FALSE) in the
   macLinkTable of 802.15.4 [IEEE802154].  RX = 1 (resp. 0) refers to
   macRxType = TRUE (resp.  FALSE) in the macLinkTable of 802.15.4.  S =
   1 (resp. 0) refers to macSharedType = TRUE (resp.  FALSE) in the
   macLinkTable of 802.15.4.  Section 6.2.6 contains the format of the
   6P CellOptions bitmap, unless redefined by the SF.  Figure 7 contains
   the meaning of the 6P CellOptions bitmap for the 6P ADD, DELETE,
   RELOCATE requests, unless redefined by the SF.  Figure 8 contains the
   meaning of the 6P CellOptions bitmap for the 6P COUNT, LIST requests,
   unless redefined by the SF.






























Wang, et al.            Expires December 22, 2018              [Page 13]


Internet-Draft            6tisch-6top-protocol                 June 2018


    Note: assuming node A issues the 6P command to node B.
   +-------------+-----------------------------------------------------+
   | CellOptions | The type of cells B adds/deletes/relocates to its   |
   | Value       | schedule when receiving a 6P ADD/DELETE/RELOCATE    |
   |             | Request from A.                                     |
   +-------------+-----------------------------------------------------+
   |TX=0,RX=0,S=0| Invalid combination. RC_ERR is returned.            |
   +-------------+-----------------------------------------------------+
   |TX=1,RX=0,S=0| add/delete/relocate RX cells at B (TX cells at A)   |
   +-------------+-----------------------------------------------------+
   |TX=0,RX=1,S=0| add/delete/relocate TX cells at B (RX cells at A)   |
   +-------------+-----------------------------------------------------+
   |TX=1,RX=1,S=0| add/delete/relocate TX|RX cells at B (and at A)     |
   +-------------+-----------------------------------------------------+
   |TX=0,RX=0,S=1| Invalid combination. RC_ERR is returned.            |
   +-------------+-----------------------------------------------------+
   |TX=1,RX=0,S=1| add/delete/relocate RX|SHARED cells at B            |
   |             | (TX|SHARED cells at A)                              |
   +-------------+-----------------------------------------------------+
   |TX=0,RX=1,S=1| add/delete/relocate TX|SHARED cells at B            |
   |             | (RX|SHARED cells at A)                              |
   +-------------+-----------------------------------------------------+
   |TX=1,RX=1,S=1| add/delete/relocate TX|RX|SHARED cells at B         |
   |             | (and at A)                                          |
   +-------------+-----------------------------------------------------+

      Figure 7: Meaning of the 6P CellOptions bitmap for the 6P ADD,
                        DELETE, RELOCATE requests.























Wang, et al.            Expires December 22, 2018              [Page 14]


Internet-Draft            6tisch-6top-protocol                 June 2018


    Note: assuming node A issues the 6P command to node B.
   +-------------+-----------------------------------------------------+
   | CellOptions | The type of cells B selects from its schedule when  |
   | Value       | receiving a 6P COUNT or LIST Request from A,        |
   |             | from all the cells B has scheduled with A           |
   +-------------+-----------------------------------------------------+
   |TX=0,RX=0,S=0| all cells                                           |
   +-------------+-----------------------------------------------------+
   |TX=1,RX=0,S=0| all cells marked as RX only                         |
   +-------------+-----------------------------------------------------+
   |TX=0,RX=1,S=0| all cells marked as TX only                         |
   +-------------+-----------------------------------------------------+
   |TX=1,RX=1,S=0| all cells marked as TX and RX only                  |
   +-------------+-----------------------------------------------------+
   |TX=0,RX=0,S=1| all cells marked as SHARED (regardless of TX, RX)   |
   +-------------+-----------------------------------------------------+
   |TX=1,RX=0,S=1| all cells marked as RX and SHARED only              |
   +-------------+-----------------------------------------------------+
   |TX=0,RX=1,S=1| all cells marked as TX and SHARED only              |
   +-------------+-----------------------------------------------------+
   |TX=1,RX=1,S=1| all cells marked as TX and RX and SHARED            |
   +-------------+-----------------------------------------------------+

   Figure 8: Meaning of the 6P CellOptions bitmap for the 6P COUNT, LIST
                                 requests.

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

3.2.4.  6P CellList

   A CellList field MAY be present in a 6P ADD Request, a 6P DELETE
   Request, a 6P RELOCATE Request, a 6P Response, or a 6P Confirmation.
   It is composed of a concatenation of zero, one or more 6P Cells as
   defined in Figure 9.  The content of the CellOptions field specifies
   the options associated with all cells in the CellList.  This
   necessarily means that the same options are associated with all cells
   in the CellList.

   A 6P Cell is a 4-byte field, its default 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         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 9: 6P Cell Format.



Wang, et al.            Expires December 22, 2018              [Page 15]


Internet-Draft            6tisch-6top-protocol                 June 2018


   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 length of the CellList field is implicit, and determined by the
   IE Length field of the Payload IE header as defined in 802.15.4.  The
   SF MAY redefine the format of the CellList field; the routine that
   parses this field is therefore associated with a specific SF.

3.3.  6P Commands and Operations

3.3.1.  Adding Cells

   Cells are added by using the 6P ADD command.  The Type field (T) is
   set to REQUEST.  The Code field is set to ADD.  Figure 10 defines the
   format of a 6P ADD Request.

                          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    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |  CellOptions  |   NumCells    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CellList ...
     +-+-+-+-+-+-+-+-+-

                     Figure 10: 6P ADD Request Format.

   Metadata:  Used as extra signaling to the SF.  The contents of the
         Metadata field is an opaque set of bytes passed unmodified to
         the SF.  The meaning of this field depends on the SF, and is
         out of scope of this document.  For example, Metadata can
         specify in which slotframe to add the cells.
   CellOptions:  Indicates the options to associate with the cells to be
         added.  If more than one cell is added (NumCells>1), the same
         options are associated with each one.  This necessarily means
         that, if node A needs to add multiple cells with different
         options, it needs to initiate multiple 6P ADD Transactions.
   NumCells:  The number of additional cells node A wants to schedule to
         node B.
   CellList:  A list of 0 or multiple candidate cells.  Its length is
         implicit and determined by the Length field of the Payload IE
         header.

   Figure 11 defines the format of a 6P ADD Response and Confirmation.





Wang, et al.            Expires December 22, 2018              [Page 16]


Internet-Draft            6tisch-6top-protocol                 June 2018


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

           Figure 11: 6P ADD Response and Confirmation Formats.

   CellList:  A list of 0 or more 6P Cells.

   Consider 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 cells from its schedule.  These are
   cells that are candidates to be scheduled with node B.  The
   CellOptions field specifies the type of these cells.  NumCandidate
   MUST be larger or equal to NumCells.  How many cells node A 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
   selection of NumCandidate cells in the CellList.  In case the
   NumCandidate cells do not fit in a single packet, this operation MUST
   be split into multiple independent 6P ADD Requests, each for a subset
   of the number of cells that eventually need to be added.  In case of
   a 3-step transaction, the SF is responsible for ensuring that the
   returned candidate CellList fits into the 6P Response.

   Upon receiving the request, node B checks whether the cellOptions are
   set to a valid value as noted by Figure 7.  If this is not the case,
   a Response with code RC_ERR is returned.  If the cells in the
   received CellList in node B is smaller than NumCells, Node B MUST
   return a 6P Response with RC_ERR_CELLLIST code.  Otherwise, node B's
   SF verifies which of the cells in the CellList it can install in node
   B's schedule, following the specified CellOptions field.  How that
   selection is done is specified in the SF and out of scope of this
   document.  The 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 (fewer 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 NumCells elements (succeed), 0 elements (fail), or between 0
   and NumCells elements (partially succeed).

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



Wang, et al.            Expires December 22, 2018              [Page 17]


Internet-Draft            6tisch-6top-protocol                 June 2018


3.3.2.  Deleting Cells

   Cells are deleted by using the 6P DELETE command.  The Type field (T)
   is set to REQUEST.  The Code field is set to DELETE.  Figure 12
   defines the format of a 6P DELETE Request.

                          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     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |  CellOptions  |   NumCells    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CellList ...
     +-+-+-+-+-+-+-+-+-

                   Figure 12: 6P DELETE Request Format.

   Metadata:  Same usage as for the 6P ADD command, see Section 3.3.1.
         Its format is the same as that in the 6P ADD command, but its
         content could be different.
   CellOptions:  Indicates the options that need to be associated to the
         cells to delete.  Only cells matching the CellOptions can are
         deleted.
   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 or more 6P Cells.  Its length is determined by
         the Length field of the Payload IE header.

   Figure 13 defines the format of a 6P DELETE Response and
   Confirmation.

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

          Figure 13: 6P DELETE Response and Confirmation Formats.

   CellList:  A list of 0 or more 6P Cells.

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





Wang, et al.            Expires December 22, 2018              [Page 18]


Internet-Draft            6tisch-6top-protocol                 June 2018


   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 MUST 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 MUST reply with
      a RC_ERR_CELLLIST return code.
   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 fewer than NumCells cells is
      not supported.  RC_ERR_CELLLIST code MUST be returned when the
      CellList contains fewer than NumCells cells.  If the CellList is
      empty, the SF on the receiving node SHOULD choose NumCells cells
      with the sender from its schedule, which match the CellOption
      field, and delete them.  If the CellList contains more than
      NumCells cells, the SF on the receiving node chooses exactly
      NumCells cells from the CellList to delete.

3.3.3.  Relocating Cells

   Cell relocation consists in moving a cell to a different
   [slotOffset,channelOffset] location in the schedule.  The Type field
   (T) is set to REQUEST.  The Code is set to RELOCATE.  Figure 14
   defines the format of a 6P RELOCATE Request.

                          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    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |  CellOptions  |   NumCells    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Relocation CellList          ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     | Candidate CellList           ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

                  Figure 14: 6P RELOCATE Request Format.

   Metadata:  Same usage as for the 6P ADD command, see Section 3.3.1.
   CellOptions:  Indicates the options that need to be associated with
         cells to be relocated.
   NumCells:  The number of cells to relocate, which MUST be equal or
         greater than 1.
   Relocation CellList:  The list of NumCells 6P Cells to relocate.
   Candidate CellList:  A list of NumCandidate candidate cells for node
         B to pick from.  NumCandidate MUST be 0, equal to NumCells, or



Wang, et al.            Expires December 22, 2018              [Page 19]


Internet-Draft            6tisch-6top-protocol                 June 2018


         greater than NumCells.  Its length is determined by the Length
         field of the Payload IE header.

   In a 2-step 6P RELOCATE Transaction, node A specifies both the cells
   it needs to relocate, and the list of candidate cells to relocate to.
   The Relocation CellList MUST contain exactly NumCells entries.  The
   Candidate CellList MUST contain at least NumCells entries
   (NumCandidate>=NumCells).

   In a 3-step 6P RELOCATE Transaction, node A specifies only the cells
   it needs to relocate, but not the list of candidate cells to relocate
   to.  The Candidate CellList MUST therefore be empty.

   Figure 15 defines the format of a 6P RELOCATE Response and
   Confirmation.

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

         Figure 15: 6P RELOCATE Response and Confirmation Formats.

   CellList:  A list of 0 or more 6P Cells.

   Node A's SF wants to relocate NumCells cells.  Node A creates a 6P
   RELOCATE Request, and indicates the cells it wants to relocate in the
   Relocation CellList.  It also selects NumCandidate cells from its
   schedule as candidate cells to relocate the cells to, and puts those
   in the Candidate CellList.  The CellOptions field specifies the type
   of the cell(s) to relocate.  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 the 6P RELOCATE Request to node B.

   Upon receiving the request, Node B checks if the length of the
   Candidate CellList is larger or equal to NumCells.  Node B's SF
   verifies that all the cells in the Relocation CellList are scheduled
   with node A, and are associate the options specified in the
   CellOptions field.  If either check fails, node B MUST send a 6P
   Response to node A with return code RC_ERR_CELLLIST.  If both checks
   pass, node B's SF verifies which of the cells in the Candidate
   CellList it can install in its schedule.  How that selection is done
   is specified in the SF and out of scope of this document.  That
   verification on Candidate CellList can succeed (NumCells cells from



Wang, et al.            Expires December 22, 2018              [Page 20]


Internet-Draft            6tisch-6top-protocol                 June 2018


   the Candidate CellList can be used), fail (none of the cells from the
   Candidate CellList can be used) or partially succeed (fewer than
   NumCells cells from the Candidate 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 will be re-
   scheduled following the CellOptions field.  That can contain NumCells
   elements (succeed), 0 elements (fail), between 0 and NumCells
   elements (partially succeed).  If N < NumCells cells appear in the
   CellList, this means the first N cells in the Relocation CellList
   have been relocated, the remainder have not.

   Upon receiving the response with Code RC_SUCCESS, node A relocates
   the cells specified in Relocation CellList of its RELOCATE Request to
   the new locations specified in the CellList of the 6P Response, in
   the same order.  In case the received return code is RC_ERR_CELLLIST,
   the transaction is aborted and no cell is relocated.  In case of a
   2-step transaction, Node B relocates the selected cells upon
   receiving the link-layer ACK for the 6P Response.  In case of a
   3-step transaction, Node B relocates the selected cells upon
   receiving the 6P Confirmation.

   The SF SHOULD NOT relocate all cells between two nodes at the same
   time, which might result in the schedules of both nodes diverging
   significantly.

   Figure 16 shows an example of a successful 2-step 6P RELOCATION
   Transaction.
























Wang, et al.            Expires December 22, 2018              [Page 21]


Internet-Draft            6tisch-6top-protocol                 June 2018


           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
                |                                       |
                | 6P RELOCATE Request                   |
                |   Type         = REQUEST              |
                |   Code         = RELOCATE             |
                |   SeqNum       = 11                   |
                |   NumCells     = 2                    |
                |   R.CellList   = [(1,2),(2,2)]        |
                |   C.CellList   = [(3,3),(4,3),(5,3)]  |
                |-------------------------------------->| B prepares
                |                                L2 ACK | to relocate
                |<- - - - - - - - - - - - - - - - - - - | (1,2)->(5,3)
                |                                       | and
                |                                       | (2,2)->(3,3)
                | 6P Response                           |
                |   Code         = RC_SUCCESS           |
                |   SeqNum       = 11                   |
                |   CellList     = [(5,3),(3,3)]        |
     A relocates|<--------------------------------------|
    (1,2)->(5,3)| L2 ACK                                |
    and         | - - - - - - - - - - - - - - - - - - ->|B relocates
    (2,2)->(3,3)|                                       |(1,2)->(5,3)
                |                                       |and
                |                                       |(2,2)->(3,3)


   Figure 16: Example of a successful 2-step 6P RELOCATION Transaction.

   Figure 17 shows an example of a partially successful 2-step 6P
   RELOCATION Transaction.



















Wang, et al.            Expires December 22, 2018              [Page 22]


Internet-Draft            6tisch-6top-protocol                 June 2018


           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
                |                                       |
                | 6P RELOCATE Request                   |
                |   Type         = REQUEST              |
                |   Code         = RELOCATE             |
                |   SeqNum       = 199                  |
                |   NumCells     = 2                    |
                |   R.CellList   = [(1,2),(2,2)]        |
                |   C.CellList   = [(3,3),(4,3),(5,3)]  |B prepares
                |-------------------------------------->|to relocate
                |                                L2 ACK |(1,2)->(4,3)
                |<- - - - - - - - - - - - - - - - - - - |but cannot
                |                                       |relocate (2,2)
                | 6P Response                           |
                |   Type         = RESPONSE             |
                |   Code         = RC_SUCCESS           |
                |   SeqNum       = 199                  |
                |   CellList     = [(4,3)]              |
    A relocates |<--------------------------------------|
    (1,2)->(4,3)| L2 ACK                                |
                | - - - - - - - - - - - - - - - - - - ->|B relocates
                |                                       |(1,2)->(4,3)
                |                                       |
                |                                       |

     Figure 17: Example of a partially successful 2-step 6P RELOCATION
                               Transaction.

   Figure 18 shows an example of a failed 2-step 6P RELOCATION
   Transaction.



















Wang, et al.            Expires December 22, 2018              [Page 23]


Internet-Draft            6tisch-6top-protocol                 June 2018


           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
                |                                       |
                | 6P RELOCATE Request                   |
                |   Type         = REQUEST              |
                |   Code         = RELOCATE             |
                |   SeqNum       = 53                   |
                |   NumCells     = 2                    |
                |   R.CellList   = [(1,2),(2,2)]        |
                |   C.CellList   = [(3,3),(4,3),(5,3)]  |
                |-------------------------------------->| B cannot
                |                                L2 ACK | relocate
                |<- - - - - - - - - - - - - - - - - - - | (1,2)
                |                                       | nor (2,2)
                | 6P Response                           |
                |   Type         = RESPONSE             |
                |   Code         = RC_SUCCESS           |
                |   SeqNum       = 53                   |
                |   CellList     = []                   |
                |<--------------------------------------| B does not
                | L2 ACK                                | relocate
     A does not | - - - - - - - - - - - - - - - - - - ->|
       relocate |                                       |
                |                                       |

        Figure 18: Failed 2-step 6P RELOCATION Transaction Example.

   Figure 19 shows an example of a successful 3-step 6P RELOCATION
   Transaction.





















Wang, et al.            Expires December 22, 2018              [Page 24]


Internet-Draft            6tisch-6top-protocol                 June 2018


           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
                |                                       |
                | 6P RELOCATE Request                   |
                |   Type         = REQUEST              |
                |   Code         = RELOCATE             |
                |   SeqNum       = 11                   |
                |   NumCells     = 2                    |
                |   R.CellList   = [(1,2),(2,2)]        |
                |   C.CellList   = []                   |
                |-------------------------------------->|
                |                                L2 ACK |
                |<- - - - - - - - - - - - - - - - - - - | B identifies
                |                                       | candidate
                |                                       | cells
                | 6P Response                           | (3,3),
                |   Code         = RC_SUCCESS           | (4,3) and
                |   SeqNum       = 11                   | (5,3)
                |   CellList     = [(3,3),(4,3),(5,3)]  |
     A prepares |<--------------------------------------|
    to relocate | L2 ACK                                |
   (1,2)->(5,3) | - - - - - - - - - - - - - - - - - - ->|
            and |                                       |
   (2,2)->(3,3) | 6P Confirmation                       |
                |   Code         = RC_SUCCESS           |
                |   SeqNum       = 11                   |
                |   CellList     = [(5,3),(3,3)]        |
                |-------------------------------------->| B relocates
                |                                L2 ACK | (1,2)->(5,3)
    A relocates |<- - - - - - - - - - - - - - - - - - - | and
    (1,2)->(5,3)|                                       | (2,2)->(3,3)
    and         |                                       |
    (2,2)->(3,3)|                                       |
                |                                       |

   Figure 19: Example of a successful 3-step 6P RELOCATION Transaction.

3.3.4.  Counting Cells

   To retrieve the number of scheduled cells node A has with B, node A
   issues a 6P COUNT command.  The Type field (T) is set to REQUEST.
   The Code field is set to COUNT.  Figure 20 defines the format of a 6P
   COUNT Request.







Wang, et al.            Expires December 22, 2018              [Page 25]


Internet-Draft            6tisch-6top-protocol                 June 2018


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

                    Figure 20: 6P COUNT Request Format.

   Metadata:  Same usage as for the 6P ADD command, see Section 3.3.1.
         Its format is the same as that in the 6P ADD command, but its
         content could be different.
   CellOptions:  Specifies which type of cell to be counted.

   Figure 21 defines the format of a 6P COUNT Response.

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

                   Figure 21: 6P COUNT Response Format.

   NumCells:  The number of cells which correspond to the fields of the
         request.

   Node A issues a COUNT command to node B, specifying some cell
   options.  Upon receiving the 6P COUNT request, node B goes through
   its schedule and counts the number of cells scheduled with node A in
   its own schedule which match the cell options in the CellOptions
   field of the request.  Section 3.2.3 details the use of the
   CellOptions field.

   Node B issues a 6P response to node A with return code set to
   RC_SUCCESS, and with NumCells containing the number of cells that
   match the request.

3.3.5.  Listing Cells

   To retrieve a list of scheduled cells node A has with node B, node A
   issues a 6P LIST command.  The Type field (T) is set to REQUEST.  The
   Code field is set to LIST.  Figure 22 defines the format of a 6P LIST
   Request.




Wang, et al.            Expires December 22, 2018              [Page 26]


Internet-Draft            6tisch-6top-protocol                 June 2018


                        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    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Metadata            |  CellOptions  |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Offset              |          MaxNumCells          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 22: 6P LIST Request Format.

   Metadata:  Same usage as for the 6P ADD command, see Section 3.3.1.
         Its format is the same as that in the 6P ADD command, but its
         content could be different.
   CellOptions:  Specifies which type of cell to be listed.
   Reserved:  Reserved bits.  These bits SHOULD be set to zero when
         sending the message, and MUST be ignored upon reception.
   Offset:  The Offset of the first scheduled cell that is requested.
         The mechanism assumes cells are ordered according to a rule
         defined in the SF.  The rule MUST always order the cells in the
         same way.
   MaxNumCells:  The maximum number of cells to be listed.  Node B MAY
         return fewer than MaxNumCells cells, for example if MaxNumCells
         cells do not fit in the frame.

   Figure 23 defines the format of a 6P LIST Response.

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

                    Figure 23: 6P LIST Response Format.

   CellList:  A list of 0 or more 6P Cells.

   When receiving a LIST command, node B returns the cells scheduled
   with A in its schedule that match the CellOptions field as specified
   in Section 3.2.3.

   When node B receives a LIST request, the returned CellList in the 6P
   Response contains between 0 and MaxNumCells cells, starting from the
   specified offset.  Node B SHOULD include as many cells as fit in the
   frame.  If the response contains the last cell, Node B MUST set the



Wang, et al.            Expires December 22, 2018              [Page 27]


Internet-Draft            6tisch-6top-protocol                 June 2018


   Code field in the response to RC_EOL ("End of List", as per
   Figure 38), indicating to Node A that there no more cells that match
   the request.  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 fewer than Offset cells that match the request, node B
   returns an empty CellList and a Code field set to RC_EOL.

3.3.6.  Clearing the Schedule

   To clear the schedule between nodes A and B (for example after a
   schedule inconsistency is detected), node A issues a CLEAR command.
   The Type field (T) is set to 6P Request.  The Code field is set to
   CLEAR.  Figure 24 defines the format of a 6P CLEAR Request.

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

                    Figure 24: 6P CLEAR Request Format.

   Metadata:  Same usage as for the 6P ADD command, see Section 3.3.1.
         Its format is the same as that in the 6P ADD command, but its
         content could be different.

   Figure 25 defines the format of a 6P CLEAR Response.

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

                   Figure 25: 6P CLEAR Response Format.

   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 scheduled with node B, and node B
   MUST remove all the cells scheduled with node A.  In a 6P CLEAR
   command, the SeqNum MUST NOT be checked.  In particular, even if the
   request contains a SeqNum value that would normally cause node B to
   detect a schedule inconsistency, the transaction MUST NOT be aborted.
   Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0.





Wang, et al.            Expires December 22, 2018              [Page 28]


Internet-Draft            6tisch-6top-protocol                 June 2018


   The return code to a 6P CLEAR command SHOULD be RC_SUCCESS unless the
   operation cannot be executed.  When the CLEAR operation cannot be
   executed, the return code MUST be set to RC_RESET.

3.3.7.  Generic Signaling Between SFs

   The 6P SIGNAL message allows the SF implementations on two neighbor
   nodes to exchange generic commands.  The payload in a received SIGNAL
   message is an opaque set of bytes passed unmodified to the SF.  The
   length of the payload is determined through the length field of the
   Payload IE Header.  How the generic SIGNAL command is used is
   specified by the SF, and outside the scope of this document.  The
   Type field (T) is set to REQUEST.  The Code field is set to SIGNAL.
   Figure 26 defines the format of a 6P SIGNAL Request.

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

                   Figure 26: 6P SIGNAL Request Format.

   Metadata:  Same usage as for the 6P ADD command, see Section 3.3.1.
         Its format is the same as that in the 6P ADD command, but its
         content could be different.

   Figure 27 defines the format of a 6P SIGNAL Response.

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

                   Figure 27: 6P SIGNAL Response Format.

3.4.  Protocol Functional Details

3.4.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 from 0), a node MAY implement multiple protocol



Wang, et al.            Expires December 22, 2018              [Page 29]


Internet-Draft            6tisch-6top-protocol                 June 2018


   versions at the same time.  When a node receives a 6P message with a
   Version number it does not implement, the node MUST reply with a 6P
   Response with a return code field set to RC_ERR_VERSION.  The format
   of this 6P Response message MUST be compliant with Version 0 and MUST
   be supported by all future versions of the protocol.  This ensures
   that, when node B sends a 6P Response to node A indicating it does
   not implement the 6P version in the 6P Request, node A can
   successfully parse that response.

   When a node supports a version number received in a 6P Request
   message, the Version field in the 6P Response MUST be the same as the
   Version field in the corresponding 6P Request.  Similarly, in a
   3-step transaction, the Version field in the 6P Confirmation MUST
   match that of the 6P Request and 6P Response of the same transaction.

3.4.2.  SFID Checking

   All messages contain an 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 with return code of
   RC_ERR_SFID.  The SFID field in the 6P Response MUST be the same as
   the SFID field in the corresponding 6P Request.  In a 3-step
   transaction, the SFID field in the 6P Confirmation MUST match that of
   the 6P Request and the 6P Response of the same transaction.

3.4.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 the previous 6P
   Transaction it initiated has finished (possibly 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_RESET (as per
   Figure 38) and discard this ongoing second transaction.  A node
   receiving a RC_RESET code MUST abort the second transaction and
   consider it never happened (i.e. reverting changes to the schedule or
   SeqNum done by this transaction).

   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 with 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_BUSY (as per Figure 38).  In case



Wang, et al.            Expires December 22, 2018              [Page 30]


Internet-Draft            6tisch-6top-protocol                 June 2018


   the requested cells are locked, it MUST reply to that request with a
   6P Response with return code RC_ERR_LOCKED (as per Figure 38).  The
   node receiving RC_ERR_BUSY or a RC_ERR_LOCKED MAY implement a retry
   mechanism, defined by the SF.

3.4.4.  6P Timeout

   A timeout occurs when the node that successfully sent a 6P Request
   does not receive the corresponding 6P Response within an amount of
   time specified by the SF.  In a 3-step transaction, a timeout also
   occurs when a node sending the 6P Response does not receive a 6P
   Confirmation.  When a timeout occurs, the transaction MUST be
   canceled at the node where the timeout occurs.  The value of the 6P
   Timeout should be larger than the longest possible time it takes to
   receive the 6P Response or Confirmation.  The value of the 6P Timeout
   hence depends on the number of cells scheduled between the neighbor
   nodes, the maximum number of link-layer retransmissions, etc.  The SF
   MUST determine the value of the timeout.  The value of the timeout is
   out of scope of this document.

3.4.5.  Aborting a 6P Transaction

   In case the receiver of a 6P 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_RESET.  Upon receiving this 6P
   Response, the initiator of the 6P Transaction MUST consider the 6P
   Transaction as failed.

   Similarly, in the case of 3-step transaction, when the receiver of a
   6P Response fails during the 6P Transaction and is unable to complete
   it, it MUST reply to that 6P Response with a 6P Confirmation with
   return code RC_RESET.  Upon receiving this 6P Confirmation, the
   sender of the 6P Response MUST consider the 6P Transaction as failed.

3.4.6.  SeqNum Management

   The SeqNum is the field in the 6top IE header used to match Request,
   Response and Confirmation.  The SeqNum is used to detect and handle
   duplicate commands (Section 3.4.6.1) and schedule inconsistencies
   (Section 3.4.6.2).  Each node remembers the last used SeqNum for each
   neighbor.  That is, a node stores as many SeqNum values as it has
   neighbors.  In case of supporting multiple SFs at a time, a SeqNum
   value is maintained per SF and per neighbor.  In the remainder of
   this section, we describe the use of SeqNum between two neighbors;
   the same happens for each other neighbor, independently.

   When a node resets or after a CLEAR transaction, it MUST reset SeqNum
   to 0.  The 6P Response and 6P Confirmation for a transaction MUST use



Wang, et al.            Expires December 22, 2018              [Page 31]


Internet-Draft            6tisch-6top-protocol                 June 2018


   the same SeqNum value as that in the Request.  After every
   transaction, the SeqNum MUST be incremented by exactly 1.

   Specifically, if node A receives the link-layer acknowledgment for
   its 6P Request, it commits to incrementing the SeqNum by exactly 1
   after the 6P Transaction ends.  This ensure that, at the next 6P
   Transaction where it sends a 6P Request, 6P Request will have a
   different SeqNum.

   Similarly, a node B increments the SeqNum by exactly 1 after having
   received the link-layer acknowledgment for the 6P Response (2-step 6P
   Transaction), or after having sent the link-layer acknowledgment for
   the 6P Confirmation (3-step 6P Transaction) .

   When a node B receives a 6P Request from node A with SeqNum equal to
   0, it checks the stored SeqNum for A.  If A is a new neighbor, the
   stored SeqNum in B will be 0.  The transaction can continue.  If the
   stored SeqNum for A in B is different than 0, a potential
   inconsistency is detected.  In this case, B MUST return RC_ERR_SEQNUM
   with SeqNum=0.  The SF of node A MAY decide what to do next, as
   described in Section 3.4.6.2.

   The SeqNum MUST be implemented as a lollipop counter: it rolls over
   from 0xFF to 0x01 (not to 0x00).  This is used to detect a neighbor
   reset.  Figure 28 lists the possible values of the SeqNum.

                 +-----------+-----------------------------+
                 |   Value   | Meaning                     |
                 +-----------+-----------------------------+
                 |      0x00 | Clear or After device Reset |
                 | 0x01-0xFF | Lollipop Counter values     |
                 +-----------+-----------------------------+

                 Figure 28: Possible values of the SeqNum.

3.4.6.1.  Detecting and Handling Duplicate 6P Messages

   All 6P commands are link-layer acknowledged.  A duplicate message
   means that a node receives a second 6P Request, Response or
   Confirmation.  This happens when the link-layer acknowledgment is not
   received, and a link-layer retransmission happens.  Duplicate
   messages are normal and unavoidable.

   Figure 29 shows an example 2-step transaction in which Node A
   receives a duplicate 6P Response.






Wang, et al.            Expires December 22, 2018              [Page 32]


Internet-Draft            6tisch-6top-protocol                 June 2018


           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
                |                                       |
                | 6P Request (SeqNum=456)               |
                |-------------------------------------->|
                |                                L2 ACK |
                |<- - - - - - - - - - - - - - - - - - - |
                |                                       |
                | 6P Response  (SeqNum=456)             |
                |<--------------------------------------|
                | L2 ACK                                |
                | - - - - - - - - - - -X                | No ACK:
                |                                       | link-layer
                | 6P Response  (SeqNum=456)             | retransmit
      duplicate |<--------------------------------------|
    6P Response | L2 ACK                                |
       received | - - - - - - - - - - - - - - - - - - ->|
                |                                       |

                 Figure 29: Example duplicate 6P message.

   Figure 30 shows example 3-step transaction in which Node A receives a
   out-of-order duplicate 6P Response after having sent a 6P
   Confirmation.


























Wang, et al.            Expires December 22, 2018              [Page 33]


Internet-Draft            6tisch-6top-protocol                 June 2018


           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
                |                                       |
                | 6P Request  (SeqNum=123)              |
                |-------------------------------------->|
                |                                L2 ACK |
                |<- - - - - - - - - - - - - - - - - - - |
                |                                       |
                | 6P Response  (SeqNum=123)             |
                |<--------------------------------------|
                | L2 ACK                                |
                | - - - - - - - - - - -X                | No ACK:
                |                                       | link-layer
                | 6P Confirmation  (SeqNum=123)         | retransmit
                |-------------------------------------->|    |
                |                                L2 ACK |    |
                |<- - - - - - - - - - - - - - - - - - - |  frame
                |                                       |  queued
                | 6P Response  (SeqNum=123)             |    |
      duplicate |<--------------------------------------| <--+
   out-of-order | L2 ACK                                |
    6P Response | - - - - - - - - - - - - - - - - - - ->|
       received |                                       |

           Figure 30: Example out-of-order duplicate 6P message.

   A node detects a duplicate 6P message when it has the same SeqNum and
   type as the last frame received from the same neighbor.  When
   receiving a duplicate 6P message, a node MUST send a link-layer
   acknowledgment, but MUST silently ignore the 6P message at the 6top
   sublayer.

3.4.6.2.  Detecting and Handling a Schedule Inconsistency

   A schedule inconsistency happens when the schedules of nodes A and B
   are inconsistent.  For example, when node A has a transmit cell to
   node B, but node B does not have the corresponding receive cell, and
   therefore isn't listening to node A on that cell.  A schedule
   inconsistency results in loss of connectivity.

   The SeqNum field, which is present in each 6P message, is used to
   detect an inconsistency.  The SeqNum field increments by 1 at each
   message, as detailed in Section 3.4.6.  A node computes the expected
   SeqNum field for the next 6P Transaction.  If a node receives a 6P
   Request with a SeqNum value that is not the expected one, it has
   detected an inconsistency.




Wang, et al.            Expires December 22, 2018              [Page 34]


Internet-Draft            6tisch-6top-protocol                 June 2018


   There are at least 2 cases in which a schedule inconsistency happens.

   The first case is when a node loses state, for example when it is
   power cycled (turned off, then on).  In that case, its SeqNum value
   is reset to 0.  Since the SeqNum is a lollipop counter, its neighbor
   detects an inconsistency at the next 6P transaction.  This is
   illustrated in Figure 31 and Figure 32.

           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
      SeqNum=87 |                                       | SeqNum=87
                |                                       |
                | 6P Request  (SeqNum=87)               |
                |-------------------------------------->|
                |                                L2 ACK |
                |<- - - - - - - - - - - - - - - - - - - |
                |                                       |
                | 6P Response  (SeqNum=87)              |
                |<--------------------------------------|
                | L2 ACK                                |
                | - - - - - - - - - - - - - - - - - - ->|
                |                                     ==== power-cycle
                |                                       |
      SeqNum=88 |                                       | SeqNum=0
                |                                       |
                | 6P Request (SeqNum=88)                |
                |-------------------------------------->| Inconsistency
                |                                L2 ACK | Detected
                |<- - - - - - - - - - - - - - - - - - - |
                |                                       |
                | 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
                |<--------------------------------------|
                | L2 ACK                                |
                | - - - - - - - - - - - - - - - - - - ->|

       Figure 31: Example of inconsistency because of node B reset.
                            Detected by node B













Wang, et al.            Expires December 22, 2018              [Page 35]


Internet-Draft            6tisch-6top-protocol                 June 2018


           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
      SeqNum=97 |                                       | SeqNum=97
                |                                       |
                | 6P Request  (SeqNum=97)               |
                |-------------------------------------->|
                |                                L2 ACK |
                |<- - - - - - - - - - - - - - - - - - - |
                |                                       |
                | 6P Response  (SeqNum=97)              |
                |<--------------------------------------|
                | L2 ACK                                |
                | - - - - - - - - - - - - - - - - - - ->|
                |                                     ==== power-cycle
                |                                       |
      SeqNum=98 |                                       | SeqNum=0
                |                                       |
                | 6P Request (SeqNum=0)                 |
   Inconsistency|<--------------------------------------|
   Detected     | L2 ACK                                |
                |- - - - - - - - - - - - - - - - - - - >|
                |                                       |
                | 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
                |-------------------------------------->|
                | L2 ACK                                |
                |<- - - - - - - - - - - - - - - - - - - |

   Figure 32: Example of inconsistency because node B resets.  Detected
                                 by node A

   The second case is when the maximum number of link-layer
   retransmissions is reached on the 6P Response of a 2-step transaction
   (or equivalently on a 6P Confirmation of a 3-step transaction).  This
   is illustrated in Figure 33.
















Wang, et al.            Expires December 22, 2018              [Page 36]


Internet-Draft            6tisch-6top-protocol                 June 2018


           +----------+                           +----------+
           |  Node A  |                           |  Node B  |
           +----+-----+                           +-----+----+
      SeqNum=87 |                                       | SeqNum=87
                |                                       |
                | 6P Request  (SeqNum=87)               |
                |-------------------------------------->|
                |                                L2 ACK |
                |<- - - - - - - - - - - - - - - - - - - |
                |                                       |
                | 6P Response  (SeqNum=87)              |
                |<--------------------------------------|
                | L2 ACK                                |
                | - - - - - - - - X                     |
      SeqNum=88 |                                       | no ACK:
                | 6P Response  (SeqNum=87)              | retrans. 1
    (duplicate) |<--------------------------------------|
                | L2 ACK                                |
                | - - - - - - - - X                     |
                |                                       | no ACK:
                | 6P Response  (SeqNum=87)              | retrans. 2
    (duplicate) |<--------------------------------------|
                | L2 ACK                                |
                | - - - - - - - - X                     |
                |                                       | max retrans.:
                |                                       | Inconsistency
                |                                       | Detected

      Figure 33: Example inconsistency because of maximum link-layer
                         retransmissions (here 2).

   In both cases, node B detects the inconsistency.

   If the inconsistency is detected during a 6P Transaction (Figure 31),
   the node that has detected it MUST send back a 6P Response or 6P
   Confirmation with an error code of RC_ERR_SEQNUM.  In this 6P
   Response or 6P Confirmation, the SeqNum field MUST be set to the
   value of the sender of the message (0 in the example in Figure 31).

   The SF of the node which has detected the inconsistency MUST define
   how to handle the inconsistency.  A first possibility is to issue a
   6P CLEAR request to clear the schedule, and rebuild.  A second
   possibility is to issue a 6P LIST request to retrieve the schedule.
   A third possibility is to internally "roll-back" the schedule.  How
   to handle an inconsistency is out of scope of this document.  The SF
   defines how to handle an inconsistency.





Wang, et al.            Expires December 22, 2018              [Page 37]


Internet-Draft            6tisch-6top-protocol                 June 2018


3.4.7.  Handling Error Responses

   A return code marked as Yes in the "Is Error" column in Figure 38
   indicates an error.  When a node receives a 6P Response or 6P
   Confirmation with an error, it MUST consider the 6P Transaction as
   failed.  In particular, if this was a response to a 6P ADD, DELETE or
   RELOCATE Request, the node MUST NOT add, delete or relocate any of
   the cells involved in this 6P Transaction.  Similarly, a node sending
   a 6P Response or a 6P Confirmation with an error code MUST NOT add,
   delete, relocate any cells as part of that 6P Transaction.  If a node
   receives an unrecognized return code the 6P Transaction MUST be
   considered as failed.  In particular, in a 3 step 6P Transaction, a
   6P Response with an unrecognized return code MUST be responded with a
   6P Confirmation with return code RC_ERR and consider the transaction
   as failed.  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.

3.5.  Security

   6P messages MUST be secured through link-layer security.  This is
   possible because 6P messages are carried as Payload IEs.

4.  Requirements for 6top Scheduling Functions (SF) Specification

4.1.  SF Identifier (SFID)

   Each SF has a 1-byte identifier.  Section 6.2.5 defines the rules for
   applying for an SFID.

4.2.  Requirements for an SF specification

   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 the rule for ordering cells.
   o  MUST specify a meaning for the "Metadata" field in the 6P ADD
      Request.
   o  MUST specify the SF behavior of a node when it boots.
   o  MUST specify how to handle a schedule inconsistency.



Wang, et al.            Expires December 22, 2018              [Page 38]


Internet-Draft            6tisch-6top-protocol                 June 2018


   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.  Example statistics
      include 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  SHOULD define the format of the SIGNAL command payload and its
      use.

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

5.  Security Considerations

   6P messages are carried inside 802.15.4 Payload Information Elements
   (IEs).  Those Payload IEs are encrypted and authenticated at the link
   layer through CCM* [CCM-Star].  6P benefits from the same level of
   security as any other Payload IE.  The 6P protocol does not define
   its own security mechanisms.  In particular, although a key
   management solution is out of scope of this document, the 6P protocol
   will benefit for the key management solution used in the network.
   This is relevant as security attacks such as forgery and
   misattribution attacks become more damaging when a single key is
   shared amongst a group of more than 2 participants.

   The 6P protocol does not provide protection against DOS attacks.
   Example attacks include, not sending confirmation messages in 3-step
   transaction, and sending wrongly formatted requests.  These cases
   SHOULD be handled by an appropriate policy, such as rate-limiting or
   time-limited blacklisting the attacker after several attempts.  The
   effect on the overall network is mostly localized to those two nodes,
   as communication happens in dedicated cells.

6.  IANA Considerations








Wang, et al.            Expires December 22, 2018              [Page 39]


Internet-Draft            6tisch-6top-protocol                 June 2018


6.1.  IETF IE Subtype '6P'

   This document adds the following number to the "IEEE Std 802.15.4
   IETF IE subtype IDs" registry defined by [RFC8137]:

                  +--------+------------+-----------+
                  | Value  | Subtype ID | Reference |
                  +--------+------------+-----------+
                  | <TBD>  | SUBID_6TOP | RFCXXXX   |
                  +---------------------+-----------+

                  Figure 34: IETF IE Subtype SUBID_6TOP.

6.2.  6TiSCH parameters sub-registries

   This section defines sub-registries within the "IPv6 over the TSCH
   mode of IEEE 802.15.4e (6TiSCH) parameters" registry, hereafter
   referred to as the "6TiSCH parameters" registry.  Each sub-registry
   is described in a subsection.

6.2.1.  6P Version Numbers

   The name of the sub-registry is "6P Version Numbers".

   A Note included in this registry should say: "In the 6top Protocol
   (6P) [RFCXXXX] there is a field to identify the version of the
   protocol.  This field is 4 bits in size."

   Each entry in the sub-registry must include the Version in the range
   0-15, and a reference to the 6P version's documentation.

   The initial entry in this sub-registry is as follows:

                          +---------+-----------+
                          | Version | Reference |
                          +---------+-----------+
                          |       0 |   RFCXXXX |
                          +---------+-----------+

                      Figure 35: 6P Version Numbers.

   All other Version Numbers are Unassigned.

   The IANA policy for future additions to this sub-registry is "IETF
   Review or IESG Approval" as described in [RFC8126].






Wang, et al.            Expires December 22, 2018              [Page 40]


Internet-Draft            6tisch-6top-protocol                 June 2018


6.2.2.  6P Message Types

   The name of the sub-registry is "6P Message Types".

   A note included in this registry should say: "In the 6top Protocol
   (6P) version 0 [RFCXXXX], there is a field to identify the type of
   message.  This field is 2 bits in size."

   Each entry in the sub-registry must include the Type in range
   b00-b11, the corresponding Name, and a reference to the 6P message
   type's documentation.

   Initial entries in this sub-registry are as follows:

                  +------+--------------+-----------+
                  | Type | Name         | Reference |
                  +------+--------------+-----------+
                  | b00  | REQUEST      |   RFCXXXX |
                  | b01  | RESPONSE     |   RFCXXXX |
                  | b10  | CONFIRMATION |   RFCXXXX |
                  +------+--------------+-----------+

                       Figure 36: 6P Message Types.

   All other Message Types are Reserved.

   The IANA policy for future additions to this sub-registry is "IETF
   Review or IESG Approval" as described in [RFC8126].

6.2.3.  6P Command Identifiers

   The name of the sub-registry is "6P Command Identifiers".

   A Note included in this registry should say: "In the 6top Protocol
   (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in
   size.  In a 6P Request, the value of this Code field is used to
   identify the command."

   Each entry in the sub-registry must include an Identifier in the
   range 0-255, the corresponding Name, and a reference to the 6P
   command identifier's documentation.

   Initial entries in this sub-registry are as follows:








Wang, et al.            Expires December 22, 2018              [Page 41]


Internet-Draft            6tisch-6top-protocol                 June 2018


                   +------------+------------+-----------+
                   | Identifier | Name       | Reference |
                   +------------+------------+-----------+
                   |          0 | Reserved   |           |
                   |          1 | ADD        | RFCXXXX   |
                   |          2 | DELETE     | RFCXXXX   |
                   |          3 | RELOCATE   | RFCXXXX   |
                   |          4 | COUNT      | RFCXXXX   |
                   |          5 | LIST       | RFCXXXX   |
                   |          6 | SIGNAL     | RFCXXXX   |
                   |          7 | CLEAR      | RFCXXXX   |
                   |      8-254 | Unassigned |           |
                   |        255 | Reserved   |           |
                   +------------+------------+-----------+

                    Figure 37: 6P Command Identifiers.

   The IANA policy for future additions to this sub-registry is "IETF
   Review or IESG Approval" as described in [RFC8126].

6.2.4.  6P Return Codes

   The name of the sub-registry is "6P Return Codes".

   A Note included in this registry should say: "In the 6top Protocol
   (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in
   size.  In a 6P Response or 6P Confirmation, the value of this Code
   field is used to identify the return code."

   Each entry in the sub-registry must include a Code in the range
   0-255, the corresponding Name, the corresponding Description, and a
   reference to the 6P return code's documentation.

   Initial entries in this sub-registry are as follows:

















Wang, et al.            Expires December 22, 2018              [Page 42]


Internet-Draft            6tisch-6top-protocol                 June 2018


      +------+-----------------+---------------------------+-----------+
      | Code | Name            | Description               | Is Error? |
      +------+-----------------+---------------------------+-----------+
      |    0 | RC_SUCCESS      | operation succeeded       |        No |
      |    1 | RC_EOL          | end of list               |        No |
      |    2 | RC_ERR          | generic error             |       Yes |
      |    3 | RC_RESET        | critical error, reset     |       Yes |
      |    4 | RC_ERR_VERSION  | unsupported 6P version    |       Yes |
      |    5 | RC_ERR_SFID     | unsupported SFID          |       Yes |
      |    6 | RC_ERR_SEQNUM   | schedule inconsistency    |       Yes |
      |    7 | RC_ERR_CELLLIST | cellList error            |       Yes |
      |    8 | RC_ERR_BUSY     | busy                      |       Yes |
      |    9 | RC_ERR_LOCKED   | cells are locked          |       Yes |
      +------+-----------------+---------------------------+-----------+

                        Figure 38: 6P Return Codes.

   All other Message Types are Unassigned.

   The IANA policy for future additions to this sub-registry is "IETF
   Review or IESG Approval" as described in [RFC8126].

6.2.5.  6P Scheduling Function Identifiers

   6P Scheduling Function Identifiers.

   A Note included in this registry should say: "In the 6top Protocol
   (6P) version 0 [RFCXXXX], there is a field to identify the scheduling
   function to handle the message.  This field is 8 bits in size."

   Each entry in the sub-registry must include an SFID in the range
   0-255, the corresponding Name, and a reference to the 6P Scheduling
   Function's documentation.

   Initial entries in this sub-registry are as follows:

   +----+---------------------------------+----------------------------+
   |SFID| Name                            | Reference                  |
   +----+---------------------------------+----------------------------+
   |  0 | Minimal Scheduling Function     | draft-chang-6tisch-msf     |
   |    | (MSF)                           |                            |
   +----+---------------------------------+----------------------------+

                     Figure 39: SF Identifiers (SFID).

   All other Message Types are Unassigned.





Wang, et al.            Expires December 22, 2018              [Page 43]


Internet-Draft            6tisch-6top-protocol                 June 2018


   The IANA policy for future additions to this sub-registry depends on
   the value of the SFID, as defined in Figure 40.  These specifications
   must follow the guidelines of Section 4.

                +-----------+------------------------------+
                |     Range | Registration Procedures      |
                +-----------+------------------------------+
                |     0-127 | IETF Review or IESG Approval |
                |   128-255 | Expert Review                |
                +-----------+------------------------------+

         Figure 40: SF Identifier (SFID): Registration Procedure.

6.2.6.  6P CellOptions bitmap

   The name of the sub-registry is "6P CellOptions bitmap".

   A Note included in this registry should say: "In the 6top Protocol
   (6P) version 0 [RFCXXXX], there is an optional CellOptions field
   which is 8 bits in size."

   Each entry in the sub-registry must include a bit position in the
   range 0-7, the corresponding Name, and a reference to the bit's
   documentation.

   Initial entries in this sub-registry are as follows:

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

                     Figure 41: 6P CellOptions bitmap.

   All other Message Types are Reserved.

   The IANA policy for future additions to this sub-registry is "IETF
   Review or IESG Approval" as described in [RFC8126].

7.  References







Wang, et al.            Expires December 22, 2018              [Page 44]


Internet-Draft            6tisch-6top-protocol                 June 2018


7.1.  Normative References

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

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

   [RFC8137]  Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information
              Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May
              2017, <https://www.rfc-editor.org/info/rfc8137>.

7.2.  Informative References

   [CCM-Star]
              Struik, R., "Formal Specification of the CCM* Mode of
              Operation, IEEE P802.15 Working Group for Wireless
              Personal Area Networks (WPANs).", September 2005.

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

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

   [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,
              <https://www.rfc-editor.org/info/rfc7554>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.







Wang, et al.            Expires December 22, 2018              [Page 45]


Internet-Draft            6tisch-6top-protocol                 June 2018


   [RFC8180]  Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
              IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
              Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
              May 2017, <https://www.rfc-editor.org/info/rfc8180>.

Appendix A.  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  Rule for Ordering Cells
   o  Meaning of the Metadata Field
   o  Node Behavior at Boot
   o  Schedule Inconsistency Handling
   o  6P Error Handling
   o  Examples
   o  Implementation Status
   o  Security Considerations
   o  IANA Considerations

Authors' Addresses

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

   Email: wangqin@ies.ustb.edu.cn


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

   Email: xvilajosana@uoc.edu









Wang, et al.            Expires December 22, 2018              [Page 46]


Internet-Draft            6tisch-6top-protocol                 June 2018


   Thomas Watteyne
   Analog Devices
   32990 Alvarado-Niles Road, Suite 910
   Union City, CA  94587
   USA

   Email: thomas.watteyne@analog.com












































Wang, et al.            Expires December 22, 2018              [Page 47]


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