One document matched: draft-ietf-6tisch-6top-protocol-03.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-6tisch-6top-protocol-03">
<front>
<title abbrev="6tisch-6top-protocol">
6top Protocol (6P)
</title>
<author initials="Q" surname="Wang" fullname="Qin Wang" role="editor">
<organization>Univ. of Sci. and Tech. Beijing </organization>
<address>
<postal>
<street>30 Xueyuan Road</street>
<city>Beijing</city>
<region>Hebei</region>
<code>100083</code>
<country>China</country>
</postal>
<phone>+86 (10) 6233 4781</phone>
<email>wangqin@ies.ustb.edu.cn</email>
</address>
</author>
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana" >
<organization>Universitat Oberta de Catalunya</organization>
<address>
<postal>
<street>156 Rambla Poblenou</street>
<city>Barcelona</city>
<region>Catalonia</region>
<code>08018</code>
<country>Spain</country>
</postal>
<phone>+34 (646) 633 681</phone>
<email>xvilajosana@uoc.edu</email>
</address>
</author>
<date/>
<area>Internet Area</area>
<workgroup>6TiSCH</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>
This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks.
6P allows neighbor nodes in a 6TiSCH network to add/delete TSCH cells to one another.
6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer of the IEEE802.15.4 TSCH medium access control layer.
The 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions.
Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID).
This document lists the requirements for an SF, but leaves the definition of the SF out of scope.
Different SFs are expected to be defined in future companion specifications.
</t>
</abstract>
<note title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="TEMPORARY EDITORIAL NOTES">
<t>
This document is an Internet Draft, so work-in-progress by nature.
It contains the following work-in-progress elements:
<list style="symbols">
<t>
"TODO" statements are elements which have not yet been written by the authors for some reason (lack of time, ongoing discussions with no clear consensus, etc).
The statement does indicate that the text will be written at some time.
</t>
<t>
"TEMPORARY" appendices are there to capture current ongoing discussions, or the changelog of the document.
These appendices will be removed in the final text.
</t>
<t>
"IANA_" identifiers are placeholders for numbers assigned by IANA.
These placeholders are to be replaced by the actual values they represent after their assignment by IANA.
</t>
<t>
The string "REMARK" is put before a remark (questions, suggestion, etc) from an author, editor of contributor.
These are on-going discussions at the time to writing, NOT part of the final text.
</t>
<t>
This section will be removed in the final text.
</t>
</list>
</t>
</section>
<section title="Introduction">
<t>
All communication in a 6TiSCH network is orchestrated by a schedule <xref target="RFC7554"/>.
This specification defines the 6top Protocol (6P), part of the 6TiSCH Operation sublayer (6top).
6P allow a node to communicate with a neighbor to add/delete a TSCH cell to one another.
6P hence enables distributed scheduling in a 6TiSCH network.
</t>
<figure title="A simple 6TiSCH network." anchor="fig_network">
<artwork><![CDATA[
(R)
/ \
/ \
(B)-----(C)
| |
| |
(A) (D)
]]></artwork>
</figure>
<t>
The example network depicted in <xref target="fig_network"/> is used to describe the interactions between nodes.
We consider the canonical case where node "A" issues 6P requests to node "B".
We keep this example throughout this document.
Throughout the discussions, node A will always represent the node that issues a 6P request; node B the node that receives this request.
</t>
<t>
We consider node A in <xref target="fig_network"/> monitoring the communication cells it has in its schedule to node B.
</t>
<t>
<list style="symbols">
<t>
If node A determines that the number of link-layer frames it is sending to B per unit of time is larger than the capacity offered by the TSCH cells it has scheduled to B, it triggers a 6P Transaction with node B to add one or more cells to B's TSCH schedule.
</t>
<t>
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.
</t>
<t>
Node A MAY also monitor statistics to determine whether collisions are happening on a particular cell to node B.
If this feature is enabled, node A communicates with node B to add a new cell and delete the cell which suffered from collisions.
This conceptually results in "relocating" the cell which suffered from collisions to a different slotOffset/channelOffset location in the TSCH schedule.
The mechanism to handle cell relocation is out of the scope of this document and might be handled by the scheduling function (see below).
</t>
</list>
</t>
<t>
This results in distributed schedule management in a 6TiSCH network.
</t>
<t>
The 6top Scheduling Function (SF) defines when to add/delete a cell to a neighbor.
The SF functions as a (required) add-on to 6P.
Different applications require different SFs, so the SF is left out of scope of this document.
Different SFs are expected to be defined in future companion specifications.
A node MAY implement multiple SFs and run them at the same time.
The SFID field contained in all 6P messages allows a node to switch between SFs on a per-transaction basis.
</t>
<t>
<xref target="sec_6top"/> describes the 6TiSCH Operation Sublayer (6top).
<xref target="sec_6p"/> defines the 6top Protocol (6P).
<xref target="sec_sf"/> provides guidelines on how to design an SF.
</t>
</section>
<section title="6TiSCH Operation Sublayer (6top)" anchor="sec_6top">
<t>
As depicted in <xref target="fig_stack"/>, the 6TiSCH Operation Sublayer (6top) is the next higher layer to the IEEE802.15.4 TSCH medium access control layer <xref target="IEEE802154-2015"/>.
</t>
<figure title="The 6top sublayer in the protocol stack." anchor="fig_stack">
<artwork><![CDATA[
.
| . |
| higher layers |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE802.15.4 TSCH |
| . |
.
]]></artwork>
</figure>
<t>
The roles of the 6top sublayer are to:
<list style="symbols">
<t>Implement and terminate the 6top Protocol (6P), which allows neighbor nodes to communicate to add/delete cells to one another.</t>
<t>Run one or more 6top Scheduling Functions (SF), which define the algorithm to decide when to add/delete cells.</t>
</list>
</t>
<section title="Hard/Soft Cells" anchor="sec_cells">
<t>
6top qualifies each cell in the schedule as either "hard" or "soft":
<list style="symbols">
<t>a soft cell can be read, added, deleted or updated by 6top.</t>
<t>a hard cell is read-only for 6top.</t>
</list>
</t>
<t>
In the context of this specification, all the cells used by 6top are soft cells.
Hard cells can be used for example when "hard-coding" a scheduling.
This is done, for example, in the Minimal 6TiSCH Configuration <xref target="I-D.ietf-6tisch-minimal"/>.
</t>
</section>
<section title="Using 6top with the Minimal 6TiSCH Configuration" anchor="sec_6top_minimal">
<t>
6P MAY be used alongside the Minimal 6TiSCH Configuration <xref target="I-D.ietf-6tisch-minimal"/>.
In this case, it is RECOMMENDED to use 2 slotframes, as depicted in <xref target="fig_slotframes"/>:
<list style="symbols">
<t>
Slotframe 0 is used for traffic defined in the Minimal 6TiSCH Configuration.
In <xref target="fig_slotframes"/>, this slotframe is 5 slots long, but it can be of any length.
</t>
<t>
Slotframe 1 is used by 6top to allocate cells from.
In <xref target="fig_slotframes"/>, this slotframe is 10 slots long, but it can be of any length.
</t>
</list>
</t>
<t>
Slotframe 0 SHOULD be of higher priority than Slotframe 1 to avoid for cells in slotframe 1 to "mask" cells in slotframe 0.
6top MAY support further slotframes; how to use more slotframes is out of the scope for this document.
</t>
<figure title="2-slotframe structure when using 6top alongside the Minimal 6TiSCH Configuration." anchor="fig_slotframes">
<artwork><![CDATA[
| 0 1 2 3 4 | 0 1 2 3 4 |
+------------------------+------------------------+
Slotframe 0 | | | | | | | | | | |
5 slots long | EB | | | | | EB | | | | |
high priority | | | | | | | | | | |
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 |
+-------------------------------------------------+
Slotframe 1 | | | | | | | | | | |
10 slots long | |A->B| | | | | | |B->A| |
low priority | | | | | | | | | | |
+-------------------------------------------------+
]]></artwork>
</figure>
</section>
</section>
<section title="6top Protocol (6P)" anchor="sec_6p">
<t>
The 6top Protocol (6P) allows two neighbor nodes to communicate to add/delete cells to their TSCH schedule.
Conceptually, two neighbor nodes "negotiate" the location of the cell(s) to add/delete.
</t>
<section title="6top Transaction" anchor="sec_6p_transaction">
<t>
We call "6top Transaction" a complete negotiation between two neighbor nodes.
A 6P Transaction starts when a node wishes to add/delete one or more cells to one of its neighbors.
It ends when the cell(s) have been added/removed from the schedule of both neighbors, or when the 6P Transaction has failed.
</t>
<t>
A 6P Transaction can consist of 2 or 3 steps.
It is the SF which determines whether to use 2-step or 3-step transactions.
An SF MAY use both 2-step and 3-step transactions.
</t>
<t>
Consistency between the schedules of two neighbor nodes is of utmost importance.
A loss of consistency (e.g. node A has a transmit cell to node B, but node B does not have the corresponding reception cell) can cause loss of connectivity.
To verify consistency, neighbors nodes increment the "schedule generation" number of their schedule each time they add/remove a cell.
Neighbor nodes exchange generation numbers at each 6P Transaction to detect possible inconsistencies.
This mechanism is explained in <xref target="sec_generation"/>.
</t>
<t>
We reuse the topology in <xref target="fig_network"/> to illustrate 2-step and 3-step transactions.
</t>
<section title="2-step 6top Transaction" anchor="sec_2step">
<t>
<xref target="fig_2-step"/> is a sequence diagram to help understand the 2-step 6top transaction (several elements are left out to simplify understanding).
We assume the SF running on node A determines 2 extra cells need to be scheduled to node B.
In this example, node A proposes the cells to use.
</t>
<figure title="A 2-step 6P Transaction." anchor="fig_2-step">
<artwork><![CDATA[
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| NumCells = 2 |
| CellList = [(1,2),(2,2),(3,5)] |
|-------------------------------------->|
| |
| 6P Response |
| Return Code = RC_SUCCESS |
| CellList = [(2,2),(3,5)] |
|<--------------------------------------|
| |
]]></artwork>
</figure>
<t>
In this example, the 2-step transaction occurs as follows:
<list style="numbers">
<t>
The SF running on node A selects 3 candidate cells.
</t>
<t>
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.
</t>
<t>
Node A at the same time sets a timeout timer to abort the transaction if no response has been received when it expires.
The value of the timeout is out of the scope of this document and MAY be defined by the SF.
More details are given in <xref target="sec_abort"/>.
</t>
<t>
The SF running on node B selects 2 of the 3 cells in the CellList of the 6P ADD Request.
Node B sends back a 6P Response to node A, indicating the cells it selected.
</t>
<t>
The result of this 6P Transaction is that 2 cells from A to B have been added to the TSCH schedule of both nodes A and B.
</t>
</list>
</t>
</section>
<section title="3-step 6top Transaction" anchor="sec_3step">
<t>
<xref target="fig_3-step"/> is a sequence diagram to help understand the 3-step 6top transaction.
We assume the SF running on node A determines 2 extra cells need to be scheduled to node B.
In this example, node B proposes the cells to use.
</t>
<figure title="A 3-step 6P Transaction." anchor="fig_3-step">
<artwork><![CDATA[
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| NumCells = 2 |
| CellList = [] |
|-------------------------------------->|
| |
| 6P Response |
| Return Code = RC_SUCCESS |
| CellList = [(1,2),(2,2),(3,5)] |
|<--------------------------------------|
| |
| 6P Confirmation |
| Return Code = RC_SUCCESS |
| CellList = [(2,2),(3,5)] |
|-------------------------------------->|
| |
]]></artwork>
</figure>
<t>
In this example, the 3-step transaction occurs as follows:
<list style="numbers">
<t>
The SF running on node A determines 2 extra cells need to be scheduled to node B, but does not select candidate cells.
</t>
<t>
Node A sends a 6P ADD Request to node B, indicating it wishes to add 2 cells (the "NumCells" value), with an empty "CellList".
</t>
<t>
Node A at the same time sets a timeout timer to abort the transaction if no response has been received when it expires.
The value of the timeout is out of the scope of this document and MAY be defined by the SF.
More details are given in <xref target="sec_abort"/>.
</t>
<t>
The SF running on node B selects 3 candidate cells.
Node B sends back a 6P Response to node A, indicating the 3 cells it selected.
</t>
<t>
Node B at the same time sets a timeout timer to abort the transaction if no response has been received when it expires.
The value of the timeout is out of the scope of this document and MAY be defined by the SF.
More details are given in <xref target="sec_abort"/>.
</t>
<t>
The SF running on node A selects 2 cells.
Node A sends back a 6P Confirmation to node B, indicating the cells it selected.
</t>
<t>
The result of this 6P Transaction is that 2 cells from A to B have been added to the TSCH schedule of both nodes A and B.
</t>
</list>
</t>
<t>
When in a transaction, node A proposes a candidate CellList to node B and B cannot allocate any of those cells. Node B SHOULD respond with a CellList suggesting alternatives. This approach facilitates the agreement between A and B and enables A to not guess what cells may be not used in B. The following figure ilustrated these 3-step transaction.
</t>
<figure title="A 3-step 6P Transaction with cell suggestion." anchor="fig_3b-step">
<artwork><![CDATA[
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| NumCells = 2 |
| CellList = [(1,2),(2,2),(3,5)] |
|-------------------------------------->|
| |
| 6P Response |
| Return Code = RC_SUCCESS |
| CellList = [(6,2),(7,2),(8,5)] |
|<--------------------------------------|
| |
| 6P Confirmation |
| Return Code = RC_SUCCESS |
| CellList = [(7,2),(8,5)] |
|-------------------------------------->|
| |
]]></artwork>
</figure>
<t>
In this example, the 3-step transaction occurs as follows:
<list style="numbers">
<t>
The SF running on node A determines 2 extra cells need to be scheduled to node B, and selects a candidate list of cells.
</t>
<t>
Node A sends a 6P ADD Request to node B, indicating it wishes to add 2 cells (the "NumCells" value), with an the proposed "CellList".
</t>
<t>
Node A at the same time sets a timeout timer to abort the transaction if no response has been received when it expires.
The value of the timeout is out of the scope of this document and MAY be defined by the SF.
More details are given in <xref target="sec_abort"/>.
</t>
<t>
The SF running on node B cannot match any of the proposed cells and selects 3 alternative candidate cells.
Node B sends back a 6P Response to node A, indicating the 3 candidate alternative cells it selected.
</t>
<t>
Node B at the same time sets a timeout timer to abort the transaction if no response has been received when it expires.
The value of the timeout is out of the scope of this document and MAY be defined by the SF.
More details are given in <xref target="sec_abort"/>.
</t>
<t>
The SF running on node A selects 2 cells from the proposed CellList.
Node A sends back a 6P Confirmation to node B, indicating the cells it selected.
</t>
<t>
The result of this 6P Transaction is that 2 cells from A to B have been added to the TSCH schedule of both nodes A and B.
</t>
</list>
</t>
</section>
</section>
<section title="Message Format" anchor="sec_message_formats">
<section title="6top Information Element" anchor="sec_6top_ie">
<t>
6P messages are carried as payload of IEEE802.15.4 Payload Information Elements (IE) <xref target="IEEE802154-2015"/>.
6p messages travel over a single hop.
</t>
<figure>
<artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload IE Length |GroupID|T| Sub-ID |6top IE Content
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Termination IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
The 6top IE is an IEEE Payload IE with GroupID IANA_IETF_IE_GROUP_ID.
The 6top IE complies with the IE format defined in <xref target="I-D.kivinen-802-15-ie"/>.
The Sub-ID used by the 6top IE is IANA_6TOP_SUBIE_ID.
The length of the 6top IE content is variable.
The content of the 6top IE is specified in <xref target="sec_message_formats"/>.
The Payload Termination IE is defined by the IEEE802.15.4 standard <xref target="IEEE802154-2015"/>.
</t>
</section>
<section title="General Message Format">
<t>
In all 6P messages, the 6top IE content has the following format:
</t>
<figure>
<artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum|GAB|GBA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Fields...
+-+-+-+-+-+-+-+-+-
]]></artwork>
</figure>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Version (6P Version):">
The version of the 6P protocol.
Only version IANA_6TOP_6P_VERSION is defined in this document.
Future specifications MAY define further versions of the 6P protocol.
</t>
<t hangText="Type (T):">
Type of message.
The possible messages types are defined in <xref target="sec_6p_type"/>.
</t>
<t hangText="Reserved (R):">
These two bits SHOULD be set to zero when sending the message and MUST be ignored on reception.
</t>
<t hangText="Code:">
Command to carry out, or response code.
The list of command identifiers and return codes is defined only for version IANA_6TOP_6P_VERSION in this document.
</t>
<t hangText="SFID (6top Scheduling Function Identifier):">
The identifier of the SF to use to handle this message.
The SFID is defined in <xref target="sec_sfid"/>.
</t>
<t hangText="SeqNum:">
An identifier of the packet, used to match the 6P Request, 6P Response and 6P Confirmation of the same 6P Transaction.
The value of SeqNum MUST increment by exactly one at each new 6P request issued to the same neighbor.
</t>
<t hangText="GAB:">
Schedule Generation for the cells scheduled from node A to node B.
The generation is used to ensure consistency between the schedule of the two neighbors.
<xref target="sec_generation"/> details how schedule generation is managed.
</t>
<t hangText="GBA:">
Schedule Generation for the cells scheduled from node B to node A.
</t>
<t hangText="Other Fields:">
The list of other fields depends on the value of the code field, as detailed below.
</t>
</list>
</t>
</section>
<section title="6P Message Types" anchor="sec_6p_type">
<t>
<xref target="fig_6p_type"/> lists the 6P message types.
</t>
<figure title="6P Message Types" anchor="fig_6p_type">
<artwork><![CDATA[
Value of the "Type" field Meaning
+---------------------------+--------------------------------+
| b00 | 6P Request |
+---------------------------+--------------------------------+
| b01 | 6P Response |
+---------------------------+--------------------------------+
| b10 | 6P Confirmation |
| | (3-step 6top Transaction only) |
+---------------------------+--------------------------------+
| b11 | Reserved |
+---------------------------+--------------------------------+
]]></artwork>
</figure>
</section>
<section title="6P Command Identifiers" anchor="sec_6p_cmdid">
<t>
The Code field contains a 6P Command Identifier when 6P Message is a 6P Request.
<xref target="fig_6p_cmdid"/> lists the 6P command identifiers.
</t>
<figure title="6P Command Identifiers" anchor="fig_6p_cmdid">
<artwork><![CDATA[
Command ID Value Description
+--------------+-----------------------+----------------------------+
| CMD_ADD | IANA_6TOP_CMD_ADD | add one or more cells |
+--------------+-----------------------+----------------------------+
| CMD_DELETE | IANA_6TOP_CMD_DELETE | delete one or more cells |
+--------------+-----------------------+----------------------------+
| CMD_STATUS | IANA_6TOP_CMD_STATUS | status of the schedule |
+--------------+-----------------------+----------------------------+
| CMD_LIST | IANA_6TOP_CMD_LIST | list the scheduled cells |
| | | in node B |
+--------------+-----------------------+----------------------------+
| CMD_CLEAR | IANA_6TOP_CMD_CLEAR | clear all cells on both |
| | | node A and node B |
+--------------+-----------------------+----------------------------+
| reserved | TODO-0xf | reserved |
+--------------+-----------------------+----------------------------+
]]></artwork>
</figure>
</section>
<section title="6P Return Codes" anchor="sec_6p_rc">
<t>
The Code field contains a 6P Return Code when 6P Message is a 6P Response or a 6P Confirmation.
<xref target="fig_6p_rc"/> lists the 6P Return Codes and their meaning.
</t>
<figure title="6P Return Codes" anchor="fig_6p_rc">
<artwork><![CDATA[
Return Code Value Description
+--------------+------------------------+---------------------------+
| RC_SUCCESS | IANA_6TOP_RC_SUCCESS | operation succeeded |
+--------------+------------------------+---------------------------+
| RC_ERR_VER | IANA_6TOP_RC_ERR_VER | unsupported 6P version |
+--------------+------------------------+---------------------------+
| RC_ERR_SFID | IANA_6TOP_RC_ERR_SFID | unsupported SFID |
+--------------+------------------------+---------------------------+
| RC_ERR_GEN | IANA_6TOP_RC_ERR_GEN | schedule generation error |
+--------------+------------------------+---------------------------+
| RC_ERR_BUSY | IANA_6TOP_RC_ERR_BUSY | handling previous request |
+--------------+------------------------+---------------------------+
| RC_ERR_NORES | IANA_6TOP_RC_ERR_NORES | not enough resources |
+--------------+------------------------+---------------------------+
| RC_ERR_RESET | IANA_6TOP_RC_ERR_RESET | error in state machine |
| | | wrong sequence of |
| | | commands |
+--------------+------------------------+---------------------------+
| RC_ERR | IANA_6TOP_RC_ERR | generic error |
+--------------+------------------------+---------------------------+
| reserved | TODO-0xf | |
+--------------+------------------------+---------------------------+
]]></artwork>
</figure>
</section>
<section title="6P CellOptions" anchor="sec_6p_celloptions">
<t>
The 6P CellOptions field is present in the 6P ADD, the 6P DELETE, the 6P STATUS and the 6P LIST requests.
The 6P CellOptions apply to all elements contained in the CellList field. Hence all cells in the CellList will be of the same type.
In the 6P ADD request, it is used to specify what type of cell to add.
In the 6P DELETE request, it is used to specify what type of cell to delete.
In the 6P STATUS and the 6P LIST requests, it is used as a selector of particular types of cells.
<xref target="tab_celloptions_format"/> contains the RECOMMENDED format of the 6P CellOptions field.
<xref target="tab_celloptions_meaning"/> contains the RECOMMENDED meaning of the 6P CellOptions field for the 6P STATUS and 6P LIST requests.
</t>
<figure title="Format of the CellOptions field" anchor="tab_celloptions_format">
<artwork><![CDATA[
+---------+--------------------+
| bit 0 | Transmit (TX) cell |
+---------+--------------------+
| bit 1 | Receive (RX) cell |
+---------+--------------------+
| bit 2 | SHARED cell |
+---------+--------------------+
| bit 3-7 | Reserved |
+---------+--------------------+
]]></artwork>
</figure>
<figure title="Meaning of the 6P CellOptions field for the 6P STATUS and the 6PLIST requests" anchor="tab_celloptions_meaning">
<artwork><![CDATA[
Note: assuming node A issues the 6P command to node B.
+-------------+-----------------------------------------------+
| CellOptions | B's action when receiving a 6P message from A |
| Value | |
+-------------+-----------------------------------------------+
|TX=0,RX=0,S=0| select all cells scheduled with A |
+-------------+-----------------------------------------------+
|TX=1,RX=0,S=0| select the cells scheduled with A |
| | and marked as RX |
+-------------+-----------------------------------------------+
|TX=0,RX=1,S=0| select the cells scheduled with A |
| | and marked as TX |
+-------------+-----------------------------------------------+
|TX=1,RX=1,S=0| select the cells scheduled with A |
| | and marked as TX and RX |
+-------------+-----------------------------------------------+
|TX=0,RX=0,S=1| select the cells scheduled with A |
| | and marked as SHARED |
+-------------+-----------------------------------------------+
|TX=1,RX=0,S=1| select the cells scheduled with A |
| | and marked as RX and SHARED |
+-------------+-----------------------------------------------+
|TX=0,RX=1,S=1| select the cells scheduled with A |
| | and marked as TX and SHARED |
+-------------+-----------------------------------------------+
|TX=1,RX=1,S=1| select the cells scheduled with A |
| | and marked as TX and RX and SHARED |
+-------------+-----------------------------------------------+
]]></artwork>
</figure>
<t>
The CellOptions is an opaque set of bits, sent unmodified to the SF.
The SF MAY redefine the format of the CellOptions field.
The SF MAY redefine the meaning of the CellOptions field.
</t>
</section>
<section title="6P Cell Format" anchor="sec_6p_cell">
<t>
A CellList field MAY be present in a 6P ADD Request, 6P DELETE Request, a 6P Response or a 6P Confirmation.
It is composed of zero, one of more 6P Cell containers.
The CellOptions field defines the type of the cells in a particular CellList. All cells in the CellList will be of the same type.
The 6P Cell is a 4-byte field, its RECOMMENDED format is:
</t>
<figure>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging" hangIndent="6">
<t hangText="slotOffset:">
The slot offset of the cell.
</t>
<t hangText="channelOffset:">
The channel offset of the cell.
</t>
</list>
</t>
<t>
The CellList is an opaque set of bytes, sent unmodified to the SF.
The SF MAY redefine the format of the CellList field.
</t>
</section>
<section title="6P ADD Request Format">
<figure>
<artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum|GAB|GBA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
]]></artwork>
</figure>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Version:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="Type:">
Set to 6P Request (see <xref target="fig_6p_type"/>).
</t>
<t hangText="Reserved:">
Set to 0.
</t>
<t hangText="Code:">
Set to CMD_ADD (see <xref target="sec_6p_cmdid"/>).
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
</t>
<t hangText="SeqNum:">
Packet identifier to match 6P Request and 6P Response.
</t>
<t hangText="GAB:">
Schedule Generation for the cells scheduled from node A to node B.
</t>
<t hangText="GBA:">
Schedule Generation for the cells scheduled from node B to node A.
</t>
<t hangText="Metadata:">
Metadata used as extra signaling to the SF.
The contents of the Metadata field is an opaque set of bytes, and passed unmodified to the SF.
The meaning of this field depends on the SF, and is out of scope of this document.
One example use can be to specify which slotframe to schedule the cells to.
</t>
<t hangText="CellOptions:">
Indicates the type of cells to add. All cells in the CellList for a particular request will use the same CellOption.
When different types of cells need to be allocated those need to be handled in separate ADD requests using different CellOptions.
The CellOptions is an opaque set of bits, sent unmodified to the SF.
The RECOMMENDED format of the CellOptions field is defined in <xref target="sec_6p_celloptions"/>.
The SF MAY redefine the format or the meaning of the CellOptions field.
</t>
<t hangText="NumCells:">
The number of additional cells the sender wants to schedule to the receiver according.
</t>
<t hangText="CellList:">
A list of 0, 1 or multiple 6P Cells.
The CellList is an opaque set of bytes, sent unmodified to the SF.
The RECOMMENDED format of each 6P Cell is defined in <xref target="sec_6p_cell"/>.
The SF MAY redefine the format of the CellList field.
</t>
</list>
</t>
</section>
<section title="6P DELETE Request Format">
<figure>
<artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum|GAB|GBA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
]]></artwork>
</figure>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Version:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="Type:">
Set to 6P Request (see <xref target="fig_6p_type"/>).
</t>
<t hangText="Reserved:">
Set to 0.
</t>
<t hangText="Code:">
Set to CMD_DELETE (see <xref target="sec_6p_cmdid"/>).
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
</t>
<t hangText="SeqNum:">
Packet identifier to match 6P Request and 6P Response.
</t>
<t hangText="GAB:">
Schedule Generation for the cells scheduled from node A to node B.
</t>
<t hangText="GBA:">
Schedule Generation for the cells scheduled from node B to node A.
</t>
<t hangText="Metadata:">
Metadata used as extra signaling to the SF.
The contents of the Metadata field is an opaque set of bytes, and passed unmodified to the SF.
The meaning of this field depends on the SF, and is hence out of scope of this document.
One example use can be to specify which slotframe to delete the cells from.
</t>
<t hangText="CellOptions:">
Indicates the type of cells to delete.
The CellOptions is an opaque set of bits, sent unmodified to the SF.
The RECOMMENDED format of the CellOptions field is defined in <xref target="sec_6p_celloptions"/>.
The SF MAY redefine the format or the meaning of the CellOptions field.
</t>
<t hangText="NumCells:">
The number of cells from the specified CellList the sender wants to delete from the schedule of both sender and receiver.
</t>
<t hangText="CellList:">
A list of 0, 1 or multiple 6P Cells.
The CellList is an opaque set of bytes, sent unmodified to the SF.
The RECOMMENDED format of each 6P Cell is defined in <xref target="sec_6p_cell"/>.
The SF MAY redefine the format of the CellList field.
</t>
</list>
</t>
</section>
<section title="6P STATUS Request Format">
<figure>
<artwork><![CDATA[
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum|GAB|GBA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Version:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="Type:">
Set to 6P Request (see <xref target="fig_6p_type"/>).
</t>
<t hangText="Reserved:">
Set to 0.
</t>
<t hangText="Code:">
Set to CMD_STATUS (see <xref target="sec_6p_cmdid"/>).
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
</t>
<t hangText="SeqNum:">
Packet identifier to match request and response.
</t>
<t hangText="GAB:">
Schedule Generation for the cells scheduled from node A to node B.
</t>
<t hangText="GBA:">
Schedule Generation for the cells scheduled from node B to node A.
</t>
<t hangText="Metadata:">
Metadata used as extra signaling to the SF.
The contents of the Metadata field is an opaque set of bytes, and passed unmodified to the SF.
The meaning of this field depends on the SF, and is hence out of scope of this document.
One example use can be to specify which slotframe to get the status from.
</t>
<t hangText="CellOptions:">
Further selects which types of cells to be considered.
The CellOptions is an opaque set of bits, sent unmodified to the SF.
The RECOMMENDED format and meaning of the CellOptions field is defined in <xref target="sec_6p_celloptions"/>.
The SF MAY redefine the format or the meaning of the CellOptions field.
</t>
</list>
</t>
</section>
<section title="6P LIST Request Format">
<t>
The command lists the cells scheduled from node A to node B according to the specified CellOptions.
</t>
<figure>
<artwork><![CDATA[
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum|GAB|GBA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | MaxNumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Version:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="Type:">
Set to 6P Request (see <xref target="fig_6p_type"/>).
</t>
<t hangText="Reserved:">
Set to 0.
</t>
<t hangText="Code:">
Set to CMD_LIST (see <xref target="sec_6p_cmdid"/>).
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
</t>
<t hangText="SeqNum:">
Packet identifier to match request and response.
</t>
<t hangText="GAB:">
Schedule Generation for the cells scheduled from node A to node B.
</t>
<t hangText="GBA:">
Schedule Generation for the cells scheduled from node B to node A.
</t>
<t hangText="Metadata:">
Metadata used as extra signaling to the SF.
One example use can be to specify which slotframe to list the cells from.
The contents of the Metadata field is an opaque set of bytes, and passed unmodified to the SF.
The meaning of this field depends on the SF, and is hence out of scope of this document.
</t>
<t hangText="CellOptions:">
Further selects which types of cells to be considered.
The CellOptions is an opaque set of bits, sent unmodified to the SF.
The RECOMMENDED format and meaning of the CellOptions field is defined in <xref target="sec_6p_celloptions"/>.
The SF MAY redefine the format or the meaning of the CellOptions field.
</t>
<t hangText="Reserved:">
Set to 0.
</t>
<t hangText="Offset:">
The Offset of the first scheduled cell that is requested.
The mechanism assumes cells are ordered according to some rule.
The ordering rule is defined by the SF.
</t>
<t hangText="MaxNumCells:">
The maximum number of requested cells.
Less cells than MaxNumCells can be returned if they do not fit in the packet.
</t>
</list>
</t>
</section>
<section title="6P CLEAR Request Format">
<figure>
<artwork><![CDATA[
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum|GAB|GBA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Version:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="Type:">
Set to 6P Request (see <xref target="fig_6p_type"/>).
</t>
<t hangText="Reserved:">
Set to 0.
</t>
<t hangText="Code:">
Set to CMD_CLEAR (see <xref target="sec_6p_cmdid"/>).
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
</t>
<t hangText="SeqNum:">
Packet identifier to match request and response.
</t>
<t hangText="GAB:">
Schedule Generation for the cells scheduled from node A to node B.
</t>
<t hangText="GBA:">
Schedule Generation for the cells scheduled from node B to node A.
</t>
<t hangText="Metadata:">
Metadata used as extra signaling to the SF.
One example use can be to specify which slotframe to be cleared.
The contents of the Metadata field is an opaque set of bytes, and passed unmodified to the SF.
The meaning of this field depends on the SF, and is hence out of scope of this document.
</t>
</list>
</t>
</section>
<section title="6P Response Format">
<figure>
<artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum|GAB|GBA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Fields...
+-+-+-+-+-+-+-+-+-
]]></artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Version:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="Type:">
Set to 6P Response (see <xref target="fig_6p_type"/>).
</t>
<t hangText="Reserved:">
Set to 0.
</t>
<t hangText="Code:">
One of the 6P Return Codes listed in <xref target="sec_6p_rc"/>.
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
The response MUST contain the same SFID value as the value in the SFID field of the 6P Request is responds to.
</t>
<t hangText="SeqNum:">
Packet identifier to match request and response.
The response MUST contain the same SeqNum value as the value in the SeqNum field of the 6P Request is responds to.
</t>
<t hangText="GAB:">
Schedule Generation for the cells scheduled from node A to node B.
</t>
<t hangText="GBA:">
Schedule Generation for the cells scheduled from node B to node A.
</t>
<t hangText="Other Fields:">
The contents depends on the Code field in the request, and listed below.
</t>
</list>
</t>
<t>
When responding to an ADD, DELETE, LIST request, the "Other Field" contains a list of 0, 1 or multiple 6P Cells.
The format of a 6P Cell is defined in <xref target="sec_6p_cell"/>.
</t>
<t>
When responding to an STATUS request, the "Other Field" contains the number of cells scheduled between node A and node B that match the CellOptions field, encoded as a 2-octet unsigned integer.
This is shown in <xref target="fig_response_status"/>.
</t>
<figure anchor="fig_response_status">
<artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum|GAB|GBA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num. Cells |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
When responding to an CLEAR request, the "Other Field" is empty.
</t>
</section>
<section title="6P Confirmation Format">
<t>
A 6P Confirmation is only used in a 3-step transaction, as the third step.
A 6P Confirmation Message has the exact same format as a 6P Response Message, except that the Type field is set to 6P Confirmation (see <xref target="fig_6p_type"/>).
The same Return Codes are used in both 6P Response and 6P Confirmation messages.
The confirmation MUST contain the same SeqNum value as the value in the SeqNum field of the 6P Request and 6P Response of the same transaction.
</t>
</section>
</section>
<section title="Protocol Behavior">
<t>
We use the topology in <xref target="fig_network"/> for illustration.
We assume node A negotiates to add/delete cells to node B.
</t>
<section title="Version Checking">
<t>
All messages contain a Version field.
If multiple Versions of the 6P protocol have been defined (in future specifications for Version values different than IANA_6TOP_6P_VERSION), a node MAY implement multiple protocol versions at the same time.
When receiving a 6P message with a Version number it does not implement, a node MUST reply with a 6P Response and a return code of RC_ERR_VER.
The Version field in the 6P Response MUST be the same as the Version field in the corresponding 6P Request.
</t>
</section>
<section title="SFID Checking">
<t>
All messages contain a SFID field.
A node MAY support multiple SFs at the same time.
When receiving a 6P message with an unsupported SFID, a node MUST reply with a 6P Response and a return code of RC_ERR_SFID.
The Version field in the 6P Response MUST be the same as the Version field in the corresponding 6P Request.
In a 3-step transaction, the Version field in the 6P Confirmation MUST match that of the 6P Request and 6P Response in the same transaction.
</t>
</section>
<section title="Concurrent 6P Transactions">
<t>
Only a single 6P Transaction between two neighbors, in a given direction, can take place at the same time.
That is, a node MUST NOT issue a new 6P Request to a given neighbor before having received the 6P Response for a previous request to that neighbor.
The only exception to this rule is when the previous 6P Transaction has timed out.
If a node receives a 6P Request from a given neighbor before having sent the 6P Response to the previous 6P Request from that neighbor, it MUST send back a 6P Response with a return code of RC_ERR_RESET.
A node receiving RC_ERR_RESET MUST abort the transaction and consider it never happened.
</t>
<t>
Nodes A and B MAY support having two transactions going on at the same time, one in each direction.
Similarly, a node MAY support concurrent 6P Transactions from different neighbors.
In this case, the cells involved in an ongoing 6P Transaction MUST be locked until the transaction finishes.
For example, in <xref target="fig_network"/>, node C can have a different ongoing 6P Transaction with nodes B and R.
In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors it MUST reply with a 6P Response with return code RC_ERR_NORES.
In case the requested cells are locked, it MUST reply to that request with a 6P Response with return code RC_ERR_BUSY.
The node receiving RC_ERR_BUSY or an RC_ERR_NORES may implement a retry mechanism, as defined by the SF.
</t>
</section>
<section title="Timeout">
<t>
A timeout happens when the node sending the 6P Request has not received the 6P Response.
The timeout should be longer than the longest possible time it can take for the 6P Transaction to finish.
The value of the timeout hence depends on the number of cells schedule between the neighbor nodes, on the maximum number of link-layer retransmissions, etc.
The SF determines the value of the timeout.
The value of the timeout is out of scope of this document.
</t>
</section>
<section title="SeqNum Mismatch">
<t>
When a node receives a 6P Response with SeqNum value different from the SeqNum value in the 6P Request, it MUST drop the packet and consider the 6P Transaction as having failed.
This rules applies as well to a 6P Confirmation with a SeqNum value different from that of the 6P Request or 6P Response of the same transaction.
</t>
</section>
<section title="Clearing the Schedule" anchor="sec_clear_sched">
<t>
When a 6P CLEAR command is issued from node A to node B, both nodes A and B MUST remove all the cells scheduled between them.
That is, node A MUST remove all the cells is has scheduled with B, and node B MUST remove all the cells is has scheduled with A.
In a 6P CLEAR command, the generation counters GAB and GBA MUST NOT be checked.
That is, their value is "don't care".
In particular, even if a schedule generation mismatch is detected, it MUST NOT cause the transaction to abort.
</t>
</section>
<section title="Adding Cells with 2-way Transaction">
<t>
We assume the topology in <xref target="fig_network"/> where the SF on node A decides to add NumCells cells to node B.
</t>
<t>
Node A's SF selects NumCandidate>=NumCells cells from its schedule as candidate cells to node B.
The CellOptions field specifies the type of this cells.
NumCandidate MUST be larger or equal to NumCells.
How many cells it selects (NumCandidate) and how that selection is done is specified in the SF and out of scope of this document.
Node A sends a 6P ADD Request to node B which contains the CellOptions, the value of NumCells and a seleciton of NumCandidate cells in the CellList.
</t>
<t>
Upon receiving the request, node B's SF verifies which of the cells in the CellList it can install in its schedule following the specified CellOptions field.
How that selection is done is specified in the SF and out of scope of this document.
That verification can succeed (NumCells cells from the CellList can be used), fail (none of the cells from the CellList can be used) or partially succeed (less than NumCells cells from the CellList can be used).
In all cases, node B MUST send a 6P Response with return code set to RC_SUCCESS, and which specifies the list of cells that were scheduled following the CellOptions field.
That can contain 0 elements (when the verification failed), NumCells elements (succeeded) or between 0 and NumCells elements (partially succeeded).
</t>
<t>
Upon receiving the response, node A adds the cells specified in the CellList according to the request CellOptions field.
</t>
</section>
<section title="Aborting a 6P Transaction" anchor="sec_abort">
<t>
In case the receiver of a 6top request fails during a 6P Transaction and is unable to complete it, it SHOULD reply to that request with a 6P Response with return code RC_ERR_RESET.
Upon receiving this 6top reply, the initiator of the 6P Transaction MUST consider the 6P Transaction as failed.
</t>
</section>
<section title="Deleting Cells">
<t>
The behavior for deleting cells is equivalent to that of adding cells except that:
<list style="symbols">
<t>
The nodes delete the cells they agree upon rather than adding them.
</t>
<t>
All cells in the CellList MUST already be scheduled between the two nodes and match the CellOptions field.
If node A puts cells in its CellList that are not already scheduled between the two nodes and match the CellOptions field, node B replies with a RC_ERR_RESET return code.
</t>
<t>
If the CellList in the 6P Request is empty, the SF on the receiving node is free to delete any cell from the sender, as long as it matches the CellOptions field.
</t>
<t>
The CellList in a 6P Request (2-step transaction) or 6P Response (3-step transaction) MUST either be empty, contain exactly NumCells cells, or more than NumCells cells.
The case where the CellList is not empty but contains less than NumCells cells is not supported.
</t>
</list>
</t>
</section>
<section title="Listing Cells">
<t>
When a node A issues a LIST command, it specifies:
<list style="symbols">
<t>
Through the CellOptions field, the type of cells to list, according to <xref target="sec_6p_celloptions"/>.
</t>
<t>
Through the Offset field, the offset of the first CellOptions type cell to be present in the returned list.
The cell ordering policy is defined by the SF.
</t>
<t>
Through the MaxNumCells field, the maximum number of cells to be present in the response.
</t>
</list>
</t>
<t>
When receiving a LIST command, node B returns the cells in its schedule that match the CellOptions field as specified in <xref target="sec_6p_celloptions"/>
The RECOMMENDED format of each 6P Cell is defined in <xref target="sec_6p_cell"/>.
The SF MAY redefine the format of the CellList field.
</t>
<t>
When node B receives a LIST request, the returned CellList in the 6P Response contains between 1 and MaxNumCells cells, starting from the specified Offset, as many as fit in the frame.
Node B MUST return at least one cell, unless the specified Offset is beyond the end of B's cell list in its schedule.
If node B has less than Offset cells of CellOptions type, the CellList it returns is empty.
</t>
</section>
<section title="Generation Management" anchor="sec_generation">
<t>
For each neighbor, a node maintains 2 two-bit generation numbers.
These numbers are variables internal to the node.
<list style="symbols">
<t>
GTX is the generation number for the transmission cells to the neighbor.
</t>
<t>
GRX is the generation number for the receive cells from the neighbor.
</t>
</list>
</t>
<section title="Incrementing GTX and GRX" anchor="sec_gen_incrementing">
<t>
GTX and GRX are 2-bit variables.
Their possible values are:
</t>
<figure title="Possible values of the GRX and GTX generation numbers." anchor="fig_gen_ranges">
<artwork><![CDATA[
Value Meaning
+-----------+---------------------------+
| 0b00 | Clear or never scheduled |
+-----------+---------------------------+
| 0b01-0b10 | Lollipop Counter values |
+-----------+---------------------------+
| 0b11 | Reserved |
+-----------+---------------------------+
]]></artwork>
</figure>
<t>
GTX and GRX are set to 0 upon initialization, and after a 6P CLEAR command.
GTX and GRX are incremented by 1 after each time a cell with that neighbor is added/deleted from the schedule (e.g. after a successful 6P ADD or 6P DELETE transactions).
The value rolls from 0b10 to 0b01.
This results in a lollipop counter with 0x00 as the start value, and 0b01 and 0b10 the count values.
</t>
</section>
<section title="Setting GAB and GBA fields" anchor="sec_gen_gab_gba">
<t>
Each 6P message contains a GAB and a GBA field, used to indicate the current generation counters of the node transmitting the message.
The value of the GAB and GBA fields MUST be set according to the following rules:
<list style="symbols">
<t>
When node A sends a 6P Request or 6P confirmation to node B, node A sets GAB to its GTX and GBA to its GRX.
</t>
<t>
When node B sends a 6P Response to node A, node B sets GAB to its GRX and GBA to its GTX.
</t>
</list>
</t>
</section>
<section title="Detecting and Handling Schedule Generation Inconsistencies" anchor="sec_gen_inco">
<t>
Upon receiving a 6P message, a node MUST do the following checks:
<list style="symbols">
<t>
When node B receives a 6P Request of 6P confirmation from node A, it verifies that GAB==GRX and GBA==GTX.
</t>
<t>
When node A receives a 6P Response from node B, it verifies that GAB==GTX and GBA==GRX.
</t>
</list>
</t>
<t>
If any of these comparisons is false, the node has detected a schedule generation inconsistency.
</t>
<t>
When a schedule generation inconsistency is detected:
<list style="symbols">
<t>
If the code of the 6P Request is different from CMD_CLEAR, the node MUST reply with error code RC_ERR_GEN.
</t>
<t>
If the code of the 6P Request is CMD_CLEAR, the schedule generation inconsistency MUST be ignored.
</t>
</list>
</t>
<t>
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.
</t>
</section>
</section>
<section title="Handling error responses">
<t>
A return code with a name starting with "RC_ERR" in <xref target="fig_6p_rc"/> indicates an error.
When a node receives a 6P Response with such an error, it MUST consider the 6P Transaction failed.
In particular, if this was a response to a 6P ADD/DELETE Request, the node MUST NOT add/delete any of the cells involved in this 6P Transaction.
Similarly, a node sending a 6P Response with an "RC_ERR" return code MUST NOT add/delete any cells as part of that 6P Transaction.
Defining what to do after an error has occurred is out of scope of this document.
The SF defines what to do after an error has occurred.
</t>
</section>
</section>
<section title="Security" anchor="sec_6p_security">
<t>
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.
</t>
</section>
</section>
<section title="Guidelines for 6top Scheduling Functions (SF)" anchor="sec_sf">
<section title="SF Identifier (SFID)" anchor="sec_sfid">
<t>
Each SF has an identifier.
The identifier is encoded as a 1-byte field.
The identifier space is divided in the following ranges.
</t>
<figure title="SFID range." anchor="fig_sfid_ranges">
<artwork><![CDATA[
Range Meaning
+-----------+-------------+
| 0x00-0xef | managed |
+-----------+--------------
| 0xf0-0xfe | unmanaged |
+-----------+-------------+
| 0xff | reserved |
+-----------+-------------+
]]></artwork>
</figure>
<t>
SF identifiers in the managed space MUST be managed by IANA.
</t>
</section>
<section title="Requirements for an SF">
<t>
The specification for an SF
<list style="symbols">
<t>MUST specify an identifier for that SF.</t>
<t>MUST specify the rule for a node to decide when to add/delete one or more cells to a neighbor.</t>
<t>MUST specify the rule for a Transaction source to select cells to add to the CellList field in the 6P ADD Request.</t>
<t>MUST specify the rule for a Transaction destination to select cells from CellList to add to its schedule.</t>
<t>MUST specify a value for the 6P Timeout, or a rule/equation to calculate it.</t>
<t>MUST specify a meaning for the "Metadata" field in the 6P ADD Request.</t>
<t>MUST specify the behavior of a node when it boots.</t>
<t>MUST specify what to do after an error has occurred (either the node sent a 6P Response with an error code, or received one).</t>
<t>
MUST specify the list of statistics to gather.
An example statistic if the number of transmitted frames to each neighbor.
In case the SF requires no statistics to be gathered, the specific of the SF MUST explicitly state so.
</t>
<t>SHOULD clearly state the application domain the SF is created for.</t>
<t>SHOULD contain examples which highlight normal and error scenarios.</t>
<t>SHOULD contain a list of current implementations, at least during the I-D state of the document, per <xref target="RFC6982" />.</t>
<t>SHOULD contain a performance evaluation of the scheme, possibly through references to external documents.</t>
<t>MAY redefine the format of the CellList field.</t>
<t>MAY redefine the format of the CellOptions field.</t>
<t>MAY redefine the meaning of the CellOptions field.</t>
</list>
</t>
</section>
<section title="Recommended Structure of an SF Specification">
<t>
The following section structure for a SF document is RECOMMENDED:
<list style="symbols">
<t>Introduction</t>
<t>Scheduling Function Identifier</t>
<t>Rules for Adding/Deleting Cells</t>
<t>Rules for CellList</t>
<t>6P Timeout Value</t>
<t>Meaning of the Metadata Field</t>
<t>Node Behavior at Boot</t>
<t>6P Error Handling</t>
<t>Examples</t>
<t>Implementation Status</t>
<t>Security Considerations</t>
<t>IANA Considerations</t>
</list>
</t>
</section>
</section>
<section title="Implementation Status">
<!-- START BOILERPLATE FROM RFC6982 -->
<t>
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 <xref target="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.
</t>
<t>
According to <xref target="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".
</t>
<!-- STOP BOILERPLATE FROM RFC6982 -->
<t>
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="OpenWSN:">
6P is implemented in the OpenWSN project <xref target="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/.
</t>
<t hangText="Wireshark Dissector:">
A Wireshark dissector for 6P is implemented under a BSD open-source license.
It is not yet merged into the main Wireshark build, but can be downloaded at https://github.com/openwsn-berkeley/dissectors/.
</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>
6P messages are carried inside IEEE802.15.4 Payload Information Elements (IEs).
Those Payload IEs are encrypted and authenticated at the link layer through CCM*.
6P benefits from the same level of security as any other Payload IE.
The 6P protocol does not define its own security mechanisms.
A key management solution is out of scope for this document.
The 6P protocol will benefit for the key management solution used in the network.
</t>
</section>
<section title="IANA Consideration">
<t>
TODO: write out this section as soon as the discussion with the IEEE about a possible IETF IE ID has concluded.
</t>
<t>
<list style="symbols">
<t>TODO: IANA_IETF_IE_GROUP_ID</t>
<t>TODO: IANA_6TOP_SUBIE_ID</t>
<t>TODO: IANA_6TOP_6P_VERSION</t>
<t>TODO: IANA_6TOP_CMD_ADD</t>
<t>TODO: IANA_6TOP_CMD_DELETE</t>
<t>TODO: IANA_6TOP_CMD_STATUS</t>
<t>TODO: IANA_6TOP_CMD_LIST</t>
<t>TODO: IANA_6TOP_CMD_CLEAR</t>
<t>TODO: IANA_6TOP_RC_SUCCESS</t>
<t>TODO: IANA_6TOP_RC_ERR_VER</t>
<t>TODO: IANA_6TOP_RC_ERR_SFID</t>
<t>TODO: IANA_6TOP_RC_ERR_GEN</t>
<t>TODO: IANA_6TOP_RC_ERR_BUSY</t>
<t>TODO: IANA_6TOP_RC_ERR_NORES</t>
<t>TODO: IANA_6TOP_RC_ERR_RESET</t>
<t>TODO: IANA_6TOP_RC_ERR</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- RFC 6TiSCH-->
<!-- RFC others -->
<?rfc include='reference.RFC.2119'?> <!-- Key words for use in RFCs to Indicate Requirement Levels -->
<!-- I-D 6TiSCH -->
<!-- I-D others -->
<?rfc include='reference.I-D.kivinen-802-15-ie'?>
<!-- external -->
<reference anchor="IEEE802154-2015">
<front>
<title>IEEE Std 802.15.4-2015 - IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs)</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="October" year="2015"/>
</front>
</reference>
</references>
<references title="Informative References">
<!-- RFC 6TiSCH-->
<?rfc include='reference.RFC.7554'?> <!-- Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement -->
<!-- RFC others -->
<?rfc include='reference.RFC.6982'?> <!-- Improving Awareness of Running Code: The Implementation Status Section -->
<!-- I-D 6TiSCH -->
<?rfc include='reference.I-D.ietf-6tisch-minimal'?>
<!-- I-D others -->
<!-- external -->
<reference anchor="OpenWSN">
<front>
<title>OpenWSN: a Standards-Based Low-Power Wireless Development Environment</title>
<author initials="T" surname="Watteyne" fullname="Thomas Watteyne" />
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana" />
<author initials="B" surname="Kerkez" fullname="Branko Kerkez" />
<author initials="F" surname="Chraim" fullname="Fabien Chraim" />
<author initials="K" surname="Weekly" fullname="Kevin Weekly" />
<author initials="Q" surname="Wang" fullname="Qin Wang" />
<author initials="S" surname="Glaser" fullname="Steven Glaser" />
<author initials="K" surname="Pister" fullname="Kris Pister" />
<date month="August" year="2012" />
</front>
<seriesInfo name="Transactions on Emerging Telecommunications Technologies" value="" />
</reference>
</references>
<section title="[TEMPORARY] Changelog">
<t>
<list style="symbols">
<t>draft-ietf-6tisch-6top-protocol-03
<list style="symbols">
<t>Added a reference to <xref target="I-D.kivinen-802-15-ie"/>.</t>
<t>Added the Type field.</t>
<t>Editorial changes (figs, typos, ...)</t>
</list>
</t>
<t>draft-ietf-6tisch-6top-protocol-02
<list style="symbols">
<t>Rename COUNT to STATUS</t>
<t>Split LIST to LIST AB and LIST BA</t>
<t>Added generation counters and describing generation tracking of the schedule</t>
<t>Editorial changes (figs, typos, ...)</t>
</list>
</t>
<t>draft-ietf-6tisch-6top-protocol-01
<list style="symbols">
<t>Clarifying locking of resources in concurrent transactions</t>
<t>Clarifying return of RC_ERR_BUSY in case of concurrent transactions without enough resources</t>
</list>
</t>
<t>draft-ietf-6tisch-6top-protocol-00
<list style="symbols">
<t>Informational to Std track</t>
</list>
</t>
<t>draft-wang-6tisch-6top-protocol-00
<list style="symbols">
<t>Editorial overhaul: fixing typos, increasing readability, clarifying figures.</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/47</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/54</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/55</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/49</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/53</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/44</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/48</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/43</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/52</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/45</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/51</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/50</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/46</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/41</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/42</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/39</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/40</t>
</list>
</t>
<t>draft-wang-6tisch-6top-sublayer-05
<list style="symbols">
<t>Specifies format of IE</t>
<t>Adds token in messages to match request and response</t>
</list>
</t>
<t>draft-wang-6tisch-6top-sublayer-04
<list style="symbols">
<t>Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID.</t>
<t>Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC.</t>
<t>Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub-IE.</t>
</list>
</t>
<t>draft-wang-6tisch-6top-sublayer-03
<list style="symbols">
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/32/missing-command-list</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/31/missing-command-count</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/30/missing-command-clear</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/37/6top-atomic-transaction-6p-transaction</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/35/separate-opcode-from-rc</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/36/add-length-field-in-ie</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/27/differentiate-rc_err_busy-and</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/29/missing-rc-rc_reset</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/28/the-sf-must-specify-the-behavior-of-a-mote</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/26/remove-including-their-number</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/34/6of-sf</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/issues/33/add-a-figure-showing-the-negociation</t>
</list>
</t>
<t>draft-wang-6tisch-6top-sublayer-02
<list style="symbols">
<t>introduces the 6P protocol and the notion of 6top Transaction.</t>
<t>introduces the concept of 6OF and its 6OFID.</t>
</list>
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 06:48:45 |