One document matched: draft-wang-6tisch-6top-sublayer-04.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="yes"?>
<rfc category="info" ipr="trust200902" docName="draft-wang-6tisch-6top-sublayer-04">
<front>
<title abbrev="6tisch-6top-sublayer">
6TiSCH Operation Sublayer (6top)
</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 6TiSCH Operation Sublayer (6top), which offers mechanisms for distributed scheduling in 6TiSCH networks.
The 6top sublayer is the next higher layer of the IEEE802.15.4e TSCH medium access control layer.
The 6top Protocol (6P) defined in this document allows neighbor nodes to add/delete TSCH cells to one another.
To be able to match different application requirements, the 6top Scheduling Function (SF) decides when to add/delete cells.
The SF is left out of scope, and will be specified in one or more companion documents.
</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="Introduction">
<t>
All communication in a 6TiSCH network is orchestrated by a schedule <xref target="RFC7554"/>.
This specification defines the mechanisms offered by the 6TiSCH Operation Sublayer (6top) sublayer.
These mechanisms allow a node to communicate with its neighbor node(s) to agree on a TSCH schedule in a distributed manner.
</t>
<figure title="A simple 6TiSCH network." anchor="fig_network">
<artwork><![CDATA[
(A)
/ \
/ \
(B)-----(C)
| |
| |
(D) (E)
]]></artwork>
</figure>
<t>
For example, node C in <xref target="fig_network"/> monitors the communication cells to node A it has in its schedule.
</t>
<t>
<list style="symbols">
<t>
If node C determines the number of frames it is sending to A per unit of time is larger than the capacity offered by the TSCH cells it has scheduled to A, it communicates with node A to add one or more such cells.
</t>
<t>
If the traffic is lower than the capacity, node C communicates with node A to delete one or more cells to A.
</t>
<t>
Node C might also monitor statistics to determine whether collisions are happening on a particular cell to node A.
If this feature is enabled, node C communicates with node A to add a new cell and delete the cell which suffered from collisions.
This results, conceptually, in "relocating" the cell which suffered from collisions to a different slotOffset/channelOffset location in the TSCH schedule.
The mechanism handling cell relocation is out of the scope of this document.
</t>
</list>
</t>
<t>
This results in a distributed schedule management solution.
</t>
<t>
The mechanisms needed to enable this interaction are defined by the 6TiSCH Operation Sublayer (6top) sublayer, described in <xref target="sec_6top"/>.
The 6top Protocol (6P), specified in <xref target="sec_6p"/>, defines the communication between neighbor nodes in this context.
The 6top sublayer includes a 6top Scheduling Function (SF) which defines the policy of when to add/delete a cell to a neighbor.
Different applications require different SFs, so the SF is left out of scope of this document.
One or more SFs will be defined in one or more companion documents.
<xref target="sec_sf"/> provides some 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) sits directly above the IEEE802.15.4e TSCH medium access control layer <xref target="IEEE802154e"/>.
</t>
<figure title="The 6top sublayer in the protocol stack." anchor="fig_stack">
<artwork><![CDATA[
.
| . |
| next higher layer |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE802.15.4e TSCH |
| . |
.
]]></artwork>
</figure>
<t>
The roles of the 6top sublayer are:
<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 a 6top Scheduling Function (SF) which defines the algorithm to decide when to add/delete cells.</t>
<t>Offer a way for a neighbor node to discover which SF is being used.</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 cell (e.g. the 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>
6top 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 (SFR0) 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 (SFR1) 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>
SFR0 SHOULD be of higher priority than SFR1.
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 |
+------------------------+------------------------+
SFR0 | EB | | | | | EB | | | | |
| | | | | | | | | | |
+-------------------------------------------------+
SFR1 | |A->B| | | | | | |B->A| |
| | | | | | | | | | |
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 |
]]></artwork>
</figure>
</section>
</section>
<section title="6top Protocol (6P)" anchor="sec_6p">
<t>
The 6top Protocol (6P) allows two neighbor nodes to pass information to add/delete cells to their TSCH schedule.
This information is carried as IEEE802.15.4 Information Elements (IE) <xref target="IEEE802154e"/> and travels only a single hop.
</t>
<t>
Conceptually, two neighbor nodes "negotiate" the location of the cells to add/delete.
We reuse the topology in <xref target="fig_network"/> to illustrate how the protocol works.
</t>
<t>
When node A wants to add (resp. delete) 2 cells to node B:
<list style="numbers">
<t>
Node A sends a message to node B indicating it wants to add (resp. delete) 2 cells to node B to its schedule, and listing 2 or more candidate cells.
</t>
<t>
Node B responds with a message indicating that the operation succeeded, and specifying which cells from the candidate list it added (resp. deleted).
This allows node A to add (resp. delete) the same cells to/from its schedule.
</t>
</list>
</t>
<t>
<xref target="fig_seq_diagram"/> is a sequence diagram which illustrates this exchange.
Here, node A requests 2 cells to node B.
It sends a 6P ADD Request to node be indicatig it wishes to add 2 cells (the "NumCells" value), and specifying a list of 3 candidate cells from which node B can choose (the "CellList" value).
Each cell in the CellList is a tuple with the (slotOffset,channelOffset) coordinates of the candidate cell in the TSCH schedule.
Node B selects 2 of the 3 cells in the CellList of the 6P ADD Request, and sends a 6P Response back to node A specifying the cells it selected from the specified container (e.g Slotframe, Chunk, etc ...).
This allow nodes A and B to add those two cells to their schedule.
</t>
<figure title="Sequence diagram to illustrate the 6P negotiation." anchor="fig_seq_diagram">
<artwork><![CDATA[
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| NumCells = 2 |
| Container ID = 1 |
| CellList = [(1,2),(2,2),(3,5)] |
|-------------------------------------->|
| |
| 6P Response |
| Return Code = IANA_6TOP_RC_SUCCESS|
| CellList = [(2,2),(3,5)] |
|<--------------------------------------|
| |
]]></artwork>
</figure>
<t>
We call "6P Transaction" the action of two neighbor nodes exchanging a 6P Request Message and the corresponding 6P Reply message.
</t>
<section title="Message Format" anchor="sec_message_formats">
<section title="6top Information Element" anchor="sec_6top_ie">
<t>
The messages exchanges as part of the 6P protocol are carried in a 6top Information Element.
The 6top Information Element is a IETF IE with Group ID IANA_IETF_IE_GROUP_ID.
The Sub-ID used by the Information Element is IANA_6TOP_SUBIE_ID.
The length of the 6top Information Element is variable.
The content of the 6top Information Element is specified in <xref target="sec_message_formats"/>.
TODO: IETF IE specified in <xref target="sec_ietf_ie" /> for now, but to be specified in separate draft in the future.
</t>
</section>
<section title="General Message Format">
<t>
All 6P messages have the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Code | SFID | Other Fields
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Ver (6P Version):">
The version of the 6P protocol.
Only version IANA_6TOP_6P_VERSION is defined in this document.
Future specification might define further version of the 6P protocol.
</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="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 Command Identifiers" anchor="sec_6p_cmdid">
<t>
<xref target="fig_6p_cmdid"/> lists the 6P command identifiers.
<figure title="6P Command Identifiers" anchor="fig_6p_cmdid">
<artwork><![CDATA[
Value Command ID Description
+----------------------+--------------+---------------------------+
| IANA_6TOP_CMD_ADD | CMD_ADD | add one or more cells |
+----------------------+------------------------------------------+
| IANA_6TOP_CMD_DELETE | CMD_DELETE | delete one or more cells |
+----------------------+------------------------------------------+
| IANA_6TOP_CMD_COUNT | CMD_COUNT | count scheduled cells |
+----------------------+------------------------------------------+
| IANA_6TOP_CMD_LIST | CMD_LIST | list the scheduled cells |
+----------------------+------------------------------------------+
| IANA_6TOP_CMD_CLEAR | CMD_CLEAR | clear all cells |
+----------------------+------------------------------------------+
| TODO-0xf | reserved |
+----------------------+------------------------------------------+
]]></artwork>
</figure>
</t>
</section>
<section title="6P Return Codes" anchor="sec_6p_rc">
<t>
<xref target="fig_6p_rc"/> lists the 6P Return Codes and their meaning.
<figure title="6P Return Codes" anchor="fig_6p_rc">
<artwork><![CDATA[
Value Return Code Description
+-----------------------+----------------------------------------+
| IANA_6TOP_RC_SUCCESS | RC_SUCCESS | operation succeeded |
+-----------------------+----------------------------------------+
| IANA_6TOP_RC_VER_ERR | RC_VER_ERR | unsupported 6P version |
+-----------------------+----------------------------------------+
| IANA_6TOP_RC_SFID_ERR | RC_SFID_ERR | unsupported SFID |
+-----------------------+----------------------------------------+
| IANA_6TOP_RC_BUSY | RC_BUSY | handling previous request|
+-----------------------+----------------------------------------+
| IANA_6TOP_RC_RESET | RC_RESET | abort 6P transaction |
+-----------------------+----------------------------------------+
| IANA_6TOP_RC_ERR | RC_ERR | operation failed |
+-----------------------+----------------------------------------+
| TODO-0xf | reserved |
+-----------------------+----------------------------------------+
]]></artwork>
</figure>
</t>
</section>
<section title="6P Cell Format" anchor="sec_6p_cell">
<t>
The 6P Cell is an element which is present in several messages.
It is a 4-byte field formatted as:
<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>
<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>
</section>
<section title="6P ADD Request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Code | SFID | NumCells | Container |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-
]]></artwork>
</figure>
</t>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Ver:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="Code:">
Set to IANA_6TOP_CMD_ADD for a 6P ADD Request.
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
</t>
<t hangText="NumCells:">
The number of additional TX cells the sender wants to schedule to the receiver.
</t>
<t hangText="Container:">
An indication of where in the schedule to take the cells from (which slotframe, which chunk, etc.).
This value is an indication to the SF.
The meaning of this field depends on the SF, and is hence out of scope of this document.
</t>
<t hangText="CellList:">
A list of 0, 1 or multiple 6P Cells.
The format of a 6P Cell is defined in <xref target="sec_6p_cell"/>
</t>
</list>
</t>
</section>
<section title="6P DELETE Request Format">
<t>
The 6P DELETE Request has the exact same format as the 6P ADD Request, except for the code which is set to IANA_6TOP_CMD_DELETE.
</t>
</section>
<section title="6P COUNT Request Format">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Code | SFID | Container |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<list style="hanging" hangIndent="6">
<t hangText="Ver:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="Code:">
Set to IANA_6TOP_CMD_COUNT for a 6P COUNT Request.
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
</t>
<t hangText="Container:">
An indication of where in the schedule to take the cells from (which slotframe, which chunk, etc.).
This value is an indication 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 LIST Request Format">
<t>
The 6P LIST Request has the exact same format as the 6P COUNT Request, except for the code which is set to IANA_6TOP_CMD_LIST.
</t>
</section>
<section title="6P CLEAR Request Format">
<t>
The 6P CLEAR Request has the exact same format as the 6P COUNT Request, except for the code which is set to IANA_6TOP_CMD_CLEAR.
</t>
</section>
<section title="6P Response 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Code | SFID | Other Fields ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<list style="hanging">
<t hangText="Ver:">
Set to IANA_6TOP_6P_VERSION.
</t>
<t hangText="SFID:">
Identifier of the SF to be used by the receiver to handle the message.
</t>
<t hangText="Code:">
One of the 6P Return Codes listed in <xref target="sec_6p_rc"/>.
</t>
<t hangText="Other Fields:">
The fields depends on what command the request is for:
<list style="hanging">
<t hangText="Response to an ADD, DELETE or LIST command:">
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 hangText="Response to COUNT command:">
The number of cells scheduled from the requestor to the receiver by the 6P protocol, encoded as a 2-octet unsigned integer.
</t>
<t hangText="Response to CLEAR command:">
No other fields are present in the response.
</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="Protocol Behavior">
<t>
For illustration, we assume we use the topology in <xref target="fig_network"/>, and that 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 IANA_6TOP_RC_VER_ERR.
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.
If multiple SFs has been defined, 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 IANA_6TOP_RC_SFID_ERR.
The Version field in the 6P Response MUST be the same as the Version field in the corresponding 6P Request.
</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 IANA_6TOP_RC_ERR.
</t>
<t>
A node MAY support concurrent 6P Transactions from different neighbors.
In this case, in <xref target="fig_network"/>, node C can have a different ongoing 6P Transaction with nodes B and E.
In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors, when it receives a 6P Request from a neighbor while already handling a different request from a different neighbor, it MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY.
</t>
</section>
<section title="Timeout">
<t>
A timeout happens when the node sending the 6P Request has not received the 6P Response.
The value of the timeout is coupled with how the cells between the nodes are scheduled.
The SF determines the value of the timeout.
The value of the timeout is out of scope of this document.
</t>
</section>
<section title="Adding cells">
<t>
We assume the topology in <xref target="fig_network"/> where the SF on node C decides to add NumCell cells to node A.
</t>
<t>
Node C's SF selects NumCandidate>=NumCell cells from its schedule as candidate transmit cells to node A.
NumCandidate MUST be larger or equal to NumCell.
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 C sends a 6P ADD Request to node A which contains the value of NumCells and the NumCandidate cells in the CellList.
</t>
<t>
Upon receiving the request, node A's SF verifies which of the cells in the CellList it can add as receive cells from node C in its own schedule.
How that selection is done is specified in the SF and out of scope of this document.
That verification can succeed (NumCell cells from the CellList can be used), fail (none of the cells from the CellList can be used) or partially succeed (less than NumCell cells from the CellList can be used).
In all cases, node A MUST send a 6P Response with return code set to IANA_6TOP_RC_SUCCESS, and which specifies the list of cells that were scheduled as receive cells from C.
That can contain 0 elements (when the verification failed), NumCell elements (succeeded) or between 0 and NumCell elements (partially succeeded).
</t>
<t>
Upon receiving the response, node C adds the cells specified in the CellList as transmit cells to node A.
</t>
</section>
<section title="Aborting a 6P Transaction">
<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 IANA_6TOP_RC_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 be already scheduled between the two nodes.
</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.
</t>
<t>
The CellList MUST either be equal, contain exactly NumCell cells, or more than NumCell cells.
The case where the CellList is not empty but contains less than NumCell cells is not supported.
</t>
</list>
</t>
</section>
<section title="Handling error responses">
<t>
A return code with a name starting with "RC_ERR" as 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.
The SF defines what to do after an error has occurred.
Defining what to do after an error has occurred is out of scope of this document.
</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.
<figure title="SFID range." anchor="fig_sfid_ranges">
<artwork><![CDATA[
Range Meaning
+-----------+-------------+
| 0x00 | reserved |
+-----------+--------------
| 0x01-0xef | managed |
+-----------+--------------
| 0xf0-0xfe | unmanaged |
+-----------+-------------+
| 0xff | reserved |
+-----------+-------------+
]]></artwork>
</figure>
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>SHOULD clearly state the application domain the SF is created for.</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 to calculate it.</t>
<t>MUST specify a meaning for the "Container" 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>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>
</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 Container 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="OpenWSN:">
This specification is implemented in the OpenWSN project <xref target="OpenWSN" />.
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.
</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>
TODO: analyze risks
</t>
<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>
<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_LIST</t>
<t>TODO: IANA_6TOP_CMD_COUNT</t>
<t>TODO: IANA_6TOP_CMD_CLEAR</t>
<t>TODO: IANA_6TOP_RC_SUCCESS</t>
<t>TODO: IANA_6TOP_RC_VER_ERR</t>
<t>TODO: IANA_6TOP_RC_SFID_ERR</t>
<t>TODO: IANA_6TOP_RC_BUSY</t>
<t>TODO: IANA_6TOP_RC_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 -->
<!-- external -->
<reference anchor="IEEE802154e">
<front>
<title>IEEE std. 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="April" year="2012"/>
</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'?>
<?rfc include='reference.I-D.ietf-6tisch-terminology'?>
<!-- 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] IETF IE" anchor="sec_ietf_ie">
<t>
This section contains a proposal for the specification of an IETF IE.
If this proposal is supported by the 6TiSCH WG, the authors of this draft recommend for the specification of the IETF IE to be its own draft, possibly developed in the 6TiSCH WG.
The reason for having it a separated document is that the scope of the IETF IE is wider that the 6P protocol defined in this document.
</t>
<t>
The IETF IE is a IEEE802.15.4 Payload Information Element with the Group ID set to IANA_IETF_IE_GROUP_ID.
The value of IANA_IETF_IE_GROUP_ID is defined by the IEEE, communicated to the IETF, and noted by IANA.
The format of the IETF IE is exactly the same as the format of an MLME Information Element, as specified in <xref target="IEEE802154e"/>, Section 5.2.4.5.
The difference is that the space of Sub-IDs is managed by the IETF/IANA.
The Sub-ID used by 6top commands is IANA_6TOP_SUBIE_ID with value 0x00.
</t>
</section>
<section title="[TEMPORARY] IEEE Liaison Considerations">
<t>
If the specification described in this document is supported by the 6TiSCH WG, the authors of this document ask the 6TiSCH WG chairs to liaise with the IEEE to request a Payload Information Element Group ID to be assigned to the IETF (Group ID IANA_IETF_IE_GROUP_ID described in <xref target="sec_ietf_ie" />).
</t>
</section>
<section title="[TEMPORARY] Terms for the Terminology Draft">
<t>
Terms introduced by this document, and which needs to be added to <xref target="I-D.ietf-6tisch-terminology"/>:
<list hangIndent="12" style="hanging">
<t hangText="6top:">
The "6TiSCH Operation Sublayer" (6top) is the next highest layer of the IEEE802.15.4e TSCH medium access control layer.
It implements and terminates the "6top Protocol" (6P), and contains a "6top Scheduling Function" (SF).
It is defined in TODO_LINK_draft-wang-6tisch-6top-sublayer.
</t>
<t hangText="SF:">
The "6top Scheduling Function" (SF) is the policy inside the "6TiSCH Operation Sublayer" (6top) which decides when to add/remove cells.
It is defined in TODO_LINK_draft-wang-6tisch-6top-sublayer.
</t>
<t hangText="SFID:">
The "6top Scheduling Function Identifier" (SFID) is a 4-bit field identifying a SF.
It is defined in TODO_LINK_draft-wang-6tisch-6top-sublayer.
</t>
<t hangText="6P:">
The "6top Protocol" (6P) allows neighbor nodes to communicate to add/delete cells to one another in their TSCH schedule.
It is defined in TODO_LINK_draft-wang-6tisch-6top-sublayer.
</t>
<t hangText="6P Transaction:">
Part of the "6top Protocol" (6P), the action of two neighbors exchanging a 6P request message and the corresponding 6P response message.
It is defined in TODO_LINK_draft-wang-6tisch-6top-sublayer.
</t>
</list>
</t>
</section>
<section title="[TEMPORARY] Changelog">
<t>
<list style="symbols">
<t>-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>-03
<list style="symbols">
<t></t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/32/missing-command-list</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/31/missing-command-count</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/30/missing-command-clear</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/37/6top-atomic-transaction-6p-transaction</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/35/separate-opcode-from-rc</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/36/add-length-field-in-ie</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/27/differentiate-rc_err_busy-and</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/29/missing-rc-rc_reset</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/28/the-sf-must-specify-the-behavior-of-a-mote</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/26/remove-including-their-number</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/34/6of-sf</t>
<t>https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/issues/33/add-a-figure-showing-the-negociation</t>
</list>
</t>
<t>-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-21 08:56:47 |