| 6TiSCH | Q. Wang, Ed. |
| Internet-Draft | Univ. of Sci. and Tech. Beijing |
| Intended status: Informational | X. Vilajosana |
| Expires: January 26, 2017 | Universitat Oberta de Catalunya |
| July 25, 2016 |
6top Protocol (6P)
draft-ietf-6tisch-6top-protocol-02
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document is an Internet Draft, so work-in-progress by nature. It contains the following work-in-progress elements:
All communication in a 6TiSCH network is orchestrated by a schedule [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.
(R)
/ \
/ \
(B)-----(C)
| |
| |
(A) (D)
Figure 1: A simple 6TiSCH network.
The example network depicted in Figure 1 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.
We consider node A in Figure 1 monitoring the communication cells it has in its schedule to node B.
This results in distributed schedule management in a 6TiSCH network.
The 6top Scheduling Function (SF) defines when to add/delete a cell to a neighbor. 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.
Section 3 describes the 6TiSCH Operation Sublayer (6top). Section 4 defines the 6top Protocol (6P). Section 5 provides guidelines on how to design an SF.
As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the next higher layer to the IEEE802.15.4 TSCH medium access control layer [IEEE802154-2015].
.
| . |
| next higher layer |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE802.15.4 TSCH |
| . |
.
Figure 2: The 6top sublayer in the protocol stack.
The roles of the 6top sublayer are:
6top qualifies each cell in the schedule as either "hard" or "soft":
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 [I-D.ietf-6tisch-minimal].
6P MAY be used alongside the Minimal 6TiSCH Configuration [I-D.ietf-6tisch-minimal]. In this case, it is RECOMMENDED to use 2 slotframes, as depicted in Figure 3:
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.
| 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 | | | | | | | | | | |
+-------------------------------------------------+
Figure 3: 2-slotframe structure when using 6top alongside the Minimal 6TiSCH Configuration.
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.
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.
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.
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 Section 4.3.11.
We reuse the topology in Figure 1 to illustrate 2-step and 3-step transactions.
Figure 4 is a sequence diagram to help understand the core principle of 6P (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.
+----------+ +----------+
| 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)] |
|<--------------------------------------|
| |
Figure 4: A 2-step 6P Transaction.
In this example, the 2-step transaction occurs as follows:
Figure 5 is a sequence diagram to help understand the core principle of 6P (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 B proposes the cells to use.
+----------+ +----------+
| 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)] |
|-------------------------------------->|
| |
Figure 5: A 3-step 6P Transaction.
In this example, the 3-step transaction occurs as follows:
6P messages are carried as payload of IEEE802.15.4 Payload Information Elements (IE) [IEEE802154-2015]. 6p messages travel over a single hop.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [draft-kivinen-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 Section 4.2. The Payload Termination IE is defined by the IEEE802.15.4 standard [IEEE802154-2015]. TODO: IETF IE specified in Appendix A for now, but to be specified in a separate draft in the future, possibly/probably [draft-kivinen-ie].
In all 6P messages, the 6top IE content has the following format:
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| Code | SFID | SeqNum|GAB|GBA| Other Fields...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 lists the 6P command identifiers.
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_AB | IANA_6TOP_CMD_LIST_AB | list the scheduled cells | | | | outgoing from A to B | +--------------+-----------------------+----------------------------+ | CMD_LIST_BA | IANA_6TOP_CMD_LIST_BA | list the scheduled cells | | | | outgoing from B to A | +--------------+-----------------------+----------------------------+ | CMD_CLEAR | IANA_6TOP_CMD_CLEAR | clear all cells on both | | | | node A and node B | +--------------+-----------------------+----------------------------+ | reserved | TODO-0xf | reserved | +--------------+-----------------------+----------------------------+
Figure 6: 6P Command Identifiers
Figure 7 lists the 6P Return Codes and their meaning.
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 | abort 6P Transaction | +--------------+------------------------+---------------------------+ | RC_ERR | IANA_6TOP_RC_ERR | generic error | +--------------+------------------------+---------------------------+ | reserved | TODO-0xf | | +--------------+------------------------+---------------------------+
Figure 7: 6P Return Codes
The 6P Cell is an element which is present in several messages. It is a 4-byte field, its RECOMMENDED format is:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| slotOffset | channelOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CellList is an opaque set of bytes, sent unmodified to the SF. The SF MAY redefine the format of the CellList field.
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| Code | SFID |SeqNum |GAB|GBA| NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellList ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 6P DELETE Request has the exact same format as the 6P ADD Request, except for the code which is set to CMD_DELETE.
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| Code | SFID |SeqNum |GAB|GBA| Metadata
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metadata |
+-+-+-+-+-+-+-+-+
The command lists the cells scheduled from node A to node B.
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| Code | SFID | SeqNum|GAB|GBA| Metadata
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metadata | Offset | numCells
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+
The 6P LIST_BA Request has the exact same format as the 6P LIST_BA Request, except for the code which is set to CMD_LIST_BA. 6P LIST_BA lists the cells scheduled from note B to node A.
The 6P CLEAR Request has the exact same format as the 6P STATUS Request, except for the code which is set to CMD_CLEAR.
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| Code | SFID | SeqNum|GAB|GBA| Other Fields...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When responding to an ADD, DELETE, LIST_AB or LIST_BA command, the "Other Field" contains a list of 0, 1 or multiple 6P Cells. The format of a 6P Cell is defined in Section 4.2.5.
When responding to an STATUS command, the "Other Field" contains Figure 8.
This is shown in
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| Code | SFID | SeqNum|GAB|GBA| num. AB cells
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number BA cells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8
When responding to an CLEAR command, the "Other Field" is empty.
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. It is only the fact that it appears as the third step in a 3-step transaction that distinguishes it from a 6P Response. In particular, 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.
We use the topology in Figure 1 for illustration. We assume node A negotiates to add/delete cells to node B.
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.
All messages contain a SFID field. If multiple SFs have 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 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.
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.
A node MAY support concurrent 6P Transactions from different neighbors. In this case, the cells involved in the ongoing 6P Transaction MUST be locked until the transaction finishes. For example, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and R. In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors it MUST reply with a 6P Response with return code RC_ERR_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 decided by the SF.
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.
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.
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 transmit and receive cells with node B, and node B MUST remove all transmit and receive cells with node 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.
We assume the topology in Figure 1 where the SF on node A decides to add NumCell cells to node B.
Node A's SF selects NumCandidate>=NumCell cells from its schedule as candidate transmit cells to node B. 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 A sends a 6P ADD Request to node B which contains the value of NumCells and the NumCandidate cells in the CellList.
Upon receiving the request, node B's SF verifies which of the cells in the CellList it can add as receive cells from node A 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 B MUST send a 6P Response with return code set to RC_SUCCESS, and which specifies the list of cells that were scheduled as receive cells from A. That can contain 0 elements (when the verification failed), NumCell elements (succeeded) or between 0 and NumCell elements (partially succeeded).
Upon receiving the response, node A adds the cells specified in the CellList as transmit (Tx) cells to node B.
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.
The behavior for deleting cells is equivalent to that of adding cells except that:
When a node A issues a LIST_AB or LIST_BA command, it specifies:
When receiving a LIST_AB command, node B returns the cells that are scheduled from A to B in its schedule (i.e. receive cells from node A). When receiving a LIST_BA command, node B returns the cells that are scheduled from B to A in its schedule (i.e. transmit cells to node A). The RECOMMENDED format of each 6P Cell is defined in Section 4.2.5. The SF MAY redefine the format of the CellList field.
Depending on how many cells node B has in its schedule with match the LIST_AB or LIST_BA request, the cellList returned in the 6P Response contains between 0 and numCells cells:
If node A requests more cells than can fit in the response, node B MUST return code RC_ERR_NORES and an empty cell list.
For each neighbor, a node maintains 2 two-bit generation numbers. These numbers are variables internal to the node.
GTX and GRX are 2-bit variables. Their possible values are:
Value Meaning
+-----------+---------------------------+
| 0b00 | Clear or never scheduled |
+-----------+---------------------------+
| 0b01-0b10 | Lollipop Counter values |
+-----------+---------------------------+
| 0b11 | Reserved |
+-----------+---------------------------+
Figure 9: Possible values of the GRX and GTX generation numbers.
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 schedul (e.g. after a succesful 6P ADD or 6P DELETE transactions). The value rolls over to 0b01 after 0b10. This results in a lollipop counter with 0x00 the start value and 0b01 and 0b10 the count values.
Each 6P message contains a GAB and GBA, 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:
Upon receiving a 6P message, a node MUST do the following checks:
If any of these comparisons is false, the node has detected a schedule generation inconsistency.
When a schedule generation inconsistency is detected:
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.
A return code with a name starting with "RC_ERR" in Figure 7 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.
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.
Each SF has an identifier. The identifier is encoded as a 1-byte field. The identifier space is divided in the following ranges.
Range Meaning
+-----------+-------------+
| 0x00-0xef | managed |
+-----------+--------------
| 0xf0-0xfe | unmanaged |
+-----------+-------------+
| 0xff | reserved |
+-----------+-------------+
Figure 10: SFID range.
SF identifiers in the managed space MUST be managed by IANA.
The specification for an SF
The following section structure for a SF document is RECOMMENDED:
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
According to [RFC6982], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".
TODO: explicit risks
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.
TODO: write out this section as soon as the discussion with the IEEE about a possible IETF IE ID has concluded.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [IEEE802154-2015] | IEEE standard for Information Technology, "IEEE Std 802.15.4-2015 - IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs)", October 2015. |
| [draft-kivinen-ie] | IETF. draft-kivinen-802-15-ie (work in progress), "IEEE 802.15.4 Information Element for IETF", April 2016. |
| [RFC7554] | Watteyne, T., Palattella, M. and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015. |
| [RFC6982] | Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013. |
| [I-D.ietf-6tisch-minimal] | Vilajosana, X. and K. Pister, "Minimal 6TiSCH Configuration", Internet-Draft draft-ietf-6tisch-minimal-16, June 2016. |
| [I-D.ietf-6tisch-terminology] | Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Internet-Draft draft-ietf-6tisch-terminology-07, March 2016. |
| [OpenWSN] | Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S. and K. Pister, "OpenWSN: a Standards-Based Low-Power Wireless Development Environment", Transactions on Emerging Telecommunications Technologies , August 2012. |
[draft-kivinen-ie] has been published and will probably replace this section. As soon as [draft-kivinen-ie] is adopted, we will remove this section and revise this document if needed.
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.
The proposal is to use an IETF IE, 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 [IEEE802154-2015], 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.
Other options are being discussed between the IETF 6TiSCH WG and the IEEE 6TiSCH IG, and listed in https://www.ietf.org/mail-archive/web/6tisch/current/msg04469.html. These options concern the way 6P Messages are transported as IEEE802.15.4 IEs, and do not impact the format of those messages.
This liaison work has resulted in the publication of [draft-kivinen-ie]. As soon as [draft-kivinen-ie] is adopted, we will remove this section and revise this document if needed.
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 Appendix A).
Terms introduced by this document, and which needs to be added to [I-D.ietf-6tisch-terminology]: