+---------+---------------------------+
               | Value   | Meaning                   |
               +---------+---------------------------+
               |     0x0 | Clear or never scheduled  |
               | 0x1-0x9 | Lollipop Counter values   |
               | 0xa-0xf | Reserved                  |
               +---------+---------------------------+
    

Figure 22: Possible values of the generation number.

The generation number is set to 0 upon initialization, and after a 6P CLEAR command. The generation number is incremented by exactly 1 each time a cell with that neighbor is added/deleted/relocated from the schedule (e.g. after a successful 6P ADD, 6P DELETE or 6P RELOCATE transaction). The value rolls from 0x9 to 0x1 (i.e. not 0x0). This results in a lollipop counter with 0x0 the start value, and 0x1-0x9 the count values. Values from 0xa to 0xf are reserved and MUST NOT be used.

4.4.7.2. Setting GEN field in the 6P Message Header

Each 6P message contains a GEN field, used to indicate the current generation number of the node transmitting the message. The value of the GEN field MUST be set according to the following rules:

• When node A sends a 6P Request or 6P Confirmation to node B, node A sets GEN to its generation number for Node B.
• When node B sends a 6P Response to node A, node B sets GEN to its generation number for node A.

4.4.7.3. Detecting and Handling Schedule Generation Inconsistencies

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

• When node B receives a 6P Request or 6P Confirmation from node A, it verifies that the value of the GEN field in the 6P message is equal to its internal generation number.
• When node A receives a 6P Response from node B, it verifies that the value of the GEN field in the 6P message is equal to its internal generation number.

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

When a schedule generation inconsistency is detected:

• If the code of the 6P Request is different from CLEAR, the node MUST reply with error code GEN_ERR.
• If the code of the 6P Request is CLEAR, the schedule generation inconsistency MUST be ignored.

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

4.4.8. Handling Error Responses

A return code marked as YES in the "Is Error" column in Figure 27 indicates an error. When a node receives a 6P Response or 6P Confirmation with such an error, it MUST consider the 6P Transaction failed. In particular, if this was a response to a 6P ADD/DELETE/RELOCATE Request, the node MUST NOT add/delete/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. Defining what to do after an error has occurred is out of scope of this document. The SF defines what to do after an error has occurred.

4.5. Security

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

5. Guidelines for 6top Scheduling Functions (SF)

5.1. SF Identifier (SFID)

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

5.2. Requirements for an SF

The specification for an SF

• MUST specify an identifier for that SF.
• MUST specify the rule for a node to decide when to add/delete one or more cells to a neighbor.
• MUST specify the rule for a Transaction source to select cells to add to the CellList field in the 6P ADD Request.
• MUST specify the rule for a Transaction destination to select cells from CellList to add to its schedule.
• MUST specify a value for the 6P Timeout, or a rule/equation to calculate it.
• MUST specify the rule for ordering cells.
• MUST specify a meaning for the "Metadata" field in the 6P ADD Request.
• MUST specify the SF behavior of a node when it boots.
• MUST specify what to do after an error has occurred (either the node sent a 6P Response with an error code, or received one).
• MUST specify the list of statistics to gather. An example statistic is 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.

• SHOULD clearly state the application domain the SF is created for.
• SHOULD contain examples which highlight normal and error scenarios.
• SHOULD contain a list of current implementations, at least during the I-D state of the document, per [RFC6982].
• SHOULD contain a performance evaluation of the scheme, possibly through references to external documents.

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

5.3. Recommended Structure of an SF Specification

The following section structure for a SF document is RECOMMENDED:

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

6. Implementation Status

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

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

ETSI 6TiSCH/6lo plugtests:

6P was one of the protocols addressed during the ETSI 6TiSCH #3 plugtests organized on 15-17 July 2016 in Berlin, Germany. 15 entities participated in this event, verifying the compliance and interoperability of their implementation of 6P. This event happened under NDA, so neither the name of the entities nor the test results are public. This event is, however, a clear indication of the maturity of 6P, and the interest it generates. More information about the event at http://www.etsi.org/news-events/events/1077-6tisch-6lo-plugtests.

ETSI 6TiSCH #2 plugtests:

6P was one of two protocols addressed during the ETSI 6TiSCH #2 plugtests organized on 2-4 February 2016 in Paris, France. 14 entities participated in this event, verifying the compliance and interoperability of their implementation of 6P. This event happened under NDA, so neither the name of the entities nor the test results are public. This event is, however, a clear indication of the maturity of 6P, and the interest it generates. More information about the event at http://www.etsi.org/news-events/events/1022-6TiSCH-2-plugtests.

OpenWSN:

6P is implemented in the OpenWSN project [OpenWSN] under a BSD open-source license. The authors of this document are collaborating with the OpenWSN community to gather feedback about the status and performance of the protocols described in this document. Results from that discussion will appear in this section in future revision of this specification. More information about this implementation at http://www.openwsn.org/.

Wireshark Dissector:

A Wireshark dissector for 6P is implemented under a BSD open-source license. It is developed and maintained at https://github.com/openwsn-berkeley/dissectors/, and regularly merged into the main Wireshark repository. Please see the Wireshark documentation to see what version of 6P it supports.

7. 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*. 6P benefits from the same level of security as any other Payload IE. The 6P protocol does not define its own security mechanisms. A key management solution is out of scope for this document. The 6P protocol will benefit for the key management solution used in the network.

8. IANA Considerations

8.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 [I-D.kivinen-802-15-ie]:

               +--------------------+------+-----------+
               | Subtype            | Name | Reference |
               +--------------------+------+-----------+
               | IANA_6TOP_SUBIE_ID | 6P   | RFCXXXX   |
               +--------------------+------+-----------+

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

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

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

    +--------+-------------+---------------------------+-----------+
    |   Code | Name        | Description               | Is Error? |
    +--------+-------------+---------------------------+-----------+
    |      0 | SUCCESS     | operation succeeded       |    No     |
    |      1 | ERROR       | generic error             |   Yes     |  
    |      2 | EOL         | end of list               |    No     |
    |      3 | RESET       | critical error, reset     |   Yes     |  
    |      4 | VER_ERR     | unsupported 6P version    |   Yes     |  
    |      5 | SFID_ERR    | unsupported SFID          |   Yes     |  
    |      6 | GEN_ERR     | wrong schedule generation |   Yes     |  
    |      7 | BUSY        | busy                      |   Yes     |
    |      8 | NORES       | not enough resources      |   Yes     |
    |      9 | CELLLIST_ERR| cellList error            |   Yes     |
    +--------+-------------+---------------------------+-----------+

   +-------+--------------------------+----------------------------+
   |  SFID | Name                     | Reference                  |
   +-------+--------------------------+----------------------------+
   |     0 | Scheduling Function Zero | draft-ietf-6tisch-6top-sf0 |
   +-------+--------------------------+----------------------------+

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

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