Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8480

Proposed STD
Pages: 50
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: 6TISCH

6TiSCH Operation Sublayer (6top) Protocol (6P)

Part 1 of 4, p. 1 to 16
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                      Q. Wang, Ed.
Request for Comments: 8480               Univ. of Sci. and Tech. Beijing
Category: Standards Track                                  X. Vilajosana
ISSN: 2070-1721                          Universitat Oberta de Catalunya
                                                             T. Watteyne
                                                          Analog Devices
                                                           November 2018


             6TiSCH Operation Sublayer (6top) Protocol (6P)

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 Time-Slotted Channel Hopping (TSCH) cells to/on one
   another.  6P is part of the 6TiSCH Operation Sublayer (6top), the
   layer just above the IEEE Std 802.15.4 TSCH Medium Access Control
   layer.  6top is composed of one or more Scheduling Functions (SFs)
   and the 6top Protocol defined in this document.  A 6top SF decides
   when to add/delete cells, and it triggers 6P Transactions.  The
   definition of SFs is out of scope for this document; however, this
   document provides the requirements for an SF.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8480.

Top      ToC       Page 2 
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
      1.1. Requirements Language ......................................5
   2. 6TiSCH Operation Sublayer (6top) ................................5
      2.1. Hard/Soft Cells ............................................6
      2.2. Using 6P with the Minimal 6TiSCH Configuration .............6
   3. 6top Protocol (6P) ..............................................7
      3.1. 6P Transactions ............................................7
           3.1.1. 2-Step 6P Transaction ...............................8
           3.1.2. 3-Step 6P Transaction ..............................10
      3.2. Message Format ............................................12
           3.2.1. 6top Information Element (IE) ......................12
           3.2.2. Generic 6P Message Format ..........................12
           3.2.3. 6P CellOptions .....................................13
           3.2.4. 6P CellList ........................................16
      3.3. 6P Commands and Operations ................................17
           3.3.1. Adding Cells .......................................17
           3.3.2. Deleting Cells .....................................19
           3.3.3. Relocating Cells ...................................21
           3.3.4. Counting Cells .....................................27
           3.3.5. Listing Cells ......................................28
           3.3.6. Clearing the Schedule ..............................30
           3.3.7. Generic Signaling between SFs ......................31
      3.4. Protocol Functional Details ...............................31
           3.4.1. Version Checking ...................................31
           3.4.2. SFID Checking ......................................32
           3.4.3. Concurrent 6P Transactions .........................32
           3.4.4. 6P Timeout .........................................33
           3.4.5. Aborting a 6P Transaction ..........................33
           3.4.6. SeqNum Management ..................................33
           3.4.7. Handling Error Responses ...........................40
      3.5. Security ..................................................40

Top      ToC       Page 3 
   4. Requirements for 6top Scheduling Function (SF) Specifications ..41
      4.1. SF Identifier (SFID) ......................................41
      4.2. Requirements for an SF Specification ......................41
   5. Security Considerations ........................................42
   6. IANA Considerations ............................................43
      6.1. IETF IE Subtype 6P ........................................43
      6.2. 6TiSCH Parameters Subregistries ...........................43
           6.2.1. 6P Version Numbers .................................43
           6.2.2. 6P Message Types ...................................44
           6.2.3. 6P Command Identifiers .............................44
           6.2.4. 6P Return Codes ....................................45
           6.2.5. 6P Scheduling Function Identifiers .................46
           6.2.6. 6P CellOptions Bitmap ..............................47
   7. References .....................................................48
      7.1. Normative References ......................................48
      7.2. Informative References ....................................48
   Appendix A. Recommended Structure of an SF Specification ..........49
   Authors' Addresses ................................................50

1.  Introduction

   All communication in an "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] (Section 3.2.4).  This specification
   defines the 6TiSCH Operation Sublayer (6top) Protocol (6P), which is
   terminated by 6top.  6P allows a node to communicate with a neighbor
   node to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on
   one another.  This results in distributed schedule management in a
   6TiSCH network.  6top is composed of one or more Scheduling Functions
   (SFs) and the 6top Protocol defined in this document.  The definition
   of SFs is out of scope for this document; however, this document
   provides the requirements for an SF.

Top      ToC       Page 4 
   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 (also referred to as "commands" in this
   document) to node "B".  We use this example throughout this document:
   node A always represents the node that issues a 6P Request, and
   node B represents the node that receives this request.

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

                     Figure 1: A Simple 6TiSCH Network

   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 offered by the TSCH
      cells it has scheduled to node B, 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" this
      particular cell to a different [slotOffset,channelOffset] location
      in the TSCH schedule.

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

   The 6top SF defines when to add/delete a cell to/on a neighbor.
   Different applications require different SFs; this topic is out of
   scope for 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.

Top      ToC       Page 5 
   Section 2 describes 6top.  Section 3 defines 6P.  Section 4 provides
   guidelines on how to define an SF.

1.1.  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
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  6TiSCH Operation Sublayer (6top)

   As depicted in Figure 2, 6top is the layer just above 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.

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

                   Figure 2: 6top in the Protocol Stack

   The roles of 6top are to:

   o  Terminate 6P, which allows neighbor nodes to communicate to
      add/delete cells to/on one another.

   o  Run one or multiple 6top SFs, which define the rules that decide
      when to add/delete cells.

Top      ToC       Page 6 
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 two 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 five 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.

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

Top      ToC       Page 7 
3.  6top Protocol (6P)

   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 (1) the cell(s) has been added/deleted/
   relocated in the schedule of both nodes or (2) 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 nodes A and B.  If no dedicated cells are scheduled between
   nodes A and B, shared cells MAY be used.

   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 is out of scope for this document.

   A 6P Transaction can consist of two or three 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.

Top      ToC       Page 8 
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 so that the diagram is easier to understand.

                +----------+                           +----------+
                |  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 two 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 three
       candidate cells.  Node A locks those candidate cells in its
       schedule until it receives a 6P Response.

Top      ToC       Page 9 
   3.  Node A sends a 6P ADD Request to node B, indicating that it
       wishes to add two cells (the "NumCells" value) and specifying the
       list of three 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 the event that no response
       is received from node B.

   5.  The SF running on node B selects two out of the three 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
       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, two cells from node A to
       node 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 to cope with such situations;
       see Section 3.4.6.2 for details.

Top      ToC       Page 10 
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 so that the diagram is easier to understand.

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

Top      ToC       Page 11 
   In this example, the 3-step transaction occurs as follows:

   1.  The SF running on node A determines that two 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 that it
       wishes to add two 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 the event that no 6P
       Response is received from node B.

   4.  The SF running on node B selects three candidate cells and locks
       them.  Node B sends back a 6P Response to node A, indicating the
       three 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 the event that no 6P
       Confirmation is received from node A.

   6.  The SF running on node A selects two cells from the CellList
       field in the 6P Response and locks them.  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, two cells from node A to
       node 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 to cope with such situations;
       see Section 3.4.6.2 for details.

Top      ToC       Page 12 
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" subtype 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 SUBID_6TOP.  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.

                          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 6P.  Only version 0 is defined
         in this document.  Future specifications may define subsequent
         versions of 6P.

   Type (T):  The 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.

Top      ToC       Page 13 
   Code:  The Code field contains a 6P command identifier when the 6P
         message has a Type value of REQUEST.  Section 6.2.3 lists the
         6P command identifiers.  The Code field contains a 6P return
         code when the 6P message has a Type value of 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:  The 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 for 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 are
         detailed in Section 3.3.

   6P Request, 6P Response, and 6P Confirmation messages for a given
   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, and 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.

   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 LIST Requests, the 6P CellOptions bitmap is
      used as a selector of a particular type of cells.

Top      ToC       Page 14 
   The content of the 6P CellOptions bitmap applies to all elements in
   the CellList field.  The possible values of the 6P CellOptions are as
   follows:

   o  TX = 1 (resp. 0) refers to macTxType = TRUE (resp. FALSE) in the
      macLinkTable of 802.15.4 [IEEE802154].

   o  RX = 1 (resp. 0) refers to macRxType = TRUE (resp. FALSE) in the
      macLinkTable of 802.15.4.

   o  S = 1 (resp. 0) refers to macSharedType = TRUE (resp. FALSE) in
      the macLinkTable of 802.15.4.

   Section 6.2.6 provides the format of the 6P CellOptions bitmap; this
   format applies unless redefined by the SF.  Figure 7 shows the
   meaning of the 6P CellOptions bitmap for the 6P ADD, DELETE, and
   RELOCATE Requests (unless redefined by the SF).  Figure 8 shows the
   meaning of the 6P CellOptions bitmap for the 6P COUNT and LIST
   Requests (unless redefined by the SF).

    Note: Here, we assume that 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, and RELOCATE Requests

Top      ToC       Page 15 
    Note: Here, we assume that 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, RX, and SHARED              |
   +-------------+-----------------------------------------------------+

          Figure 8: Meaning of the 6P CellOptions Bitmap for the
                        6P COUNT and LIST Requests

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

Top      ToC       Page 16 
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 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

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


Next Section