6TiSCH Operation Sublayer (6top) Protocol (6P)
Extracted elements (26)
Cells are classified as 'hard' (read-only for 6top, e.g., minimal 6TiSCH configuration cells) or 'soft' (fully managed by 6top). This distinction allows statically provisioned infrastructure cells to coexist with dynamically negotiated cells without 6P inadvertently deleting bootstrap connectivity.
The choice between 2-step and 3-step transactions reflects which node has better knowledge of available cells. In a 2-step transaction, the initiator (A) selects candidate cells because it knows its own schedule best; in a 3-step transaction, the responder (B) selects candidates because B's local conditions (interference, load) are better known to B. An SF MUST specify which mode(s) it uses.
The SeqNum is implemented as a lollipop counter (rolls 0xFF→0x01, not 0xFF→0x00) specifically so that a value of 0x00 is reserved as an unambiguous signal of a node reset or CLEAR. This allows a neighbor to distinguish a freshly-reset node from normal counter progression and detect schedule inconsistency without additional signaling.
When using 6P alongside the minimal 6TiSCH configuration (RFC 8180), it is RECOMMENDED to use two separate slotframes: slotframe 0 for minimal-configuration cells at higher priority, and slotframe 1 for dynamically allocated 6P cells. This prevents dynamically allocated cells from masking the always-on minimal-configuration cell.
At least one Scheduling Function MUST be running at all times. A node MAY implement and run multiple SFs concurrently, and the SFID field in every 6P message selects which SF handles that transaction.
In a 2-step ADD transaction, NumCandidate (the number of cells in the CellList) MUST be greater than or equal to NumCells. If node B receives a CellList shorter than NumCells, it MUST return RC_ERR_CELLLIST. If CellOptions encodes an invalid combination (e.g., TX=0, RX=0, S=0), node B MUST return RC_ERR.
Only a single 6P Transaction at a time in a given direction may occur between two neighbors. A node MUST NOT issue a new 6P Request to a neighbor before the previous transaction has finished or timed out. If a second request arrives before the first is answered, the node MUST respond with RC_RESET and discard the second transaction.
Upon 6P CLEAR completion, both nodes MUST remove all cells scheduled between them and MUST reset SeqNum to 0. During a CLEAR transaction, the SeqNum MUST NOT be checked, and even a SeqNum that would normally signal an inconsistency MUST NOT abort the CLEAR.
When a 6P Timeout expires, the transaction MUST be canceled at the timing-out node. The SF MUST determine the timeout value, which should exceed the longest possible time to receive a 6P Response or Confirmation given link-layer retransmissions and cell scheduling.
When a node receives a 6P message with an unsupported SFID, it MUST reply with RC_ERR_SFID. The SFID in the Response MUST echo the SFID from the Request, and in a 3-step transaction the SFID in the Confirmation MUST match that of the Request and Response.
When a node receives a 6P Response or Confirmation with an error return code, it MUST consider the transaction failed and MUST NOT add, delete, or relocate any cells. An unrecognized return code also causes the transaction to be treated as failed; in a 3-step transaction the requester MUST send a Confirmation with RC_ERR.
When receiving a duplicate 6P message (same SeqNum and type as the last frame from that neighbor), a node MUST send a link-layer acknowledgment but MUST silently ignore the message at 6top. Duplicate messages arise from link-layer retransmissions when a prior L2 ACK is lost.
A 6P Transaction is a complete negotiation between two neighbor nodes to add, delete, or relocate TSCH cells. It begins when a node wishes to modify cells and ends when the operation succeeds on both nodes or fails. Each transaction is triggered by a Scheduling Function (SF) and involves either two or three message exchanges.
In a 2-step 6P Transaction, node A selects the candidate cells and sends them in the 6P Request; node B picks from the list and confirms in a single 6P Response. This mode requires node A to propose at least as many candidate cells as NumCells.
In a 3-step 6P Transaction, node A sends an ADD/RELOCATE Request with an empty CellList; node B proposes candidate cells in the 6P Response; node A selects from those candidates and sends a 6P Confirmation. This adds a round-trip but allows node B to drive cell selection.
The 6P CellOptions field is an 8-bit bitmap with TX, RX, and S (shared) bits mapped to macTxType, macRxType, and macSharedType in the 802.15.4 macLinkTable. Its interpretation differs between ADD/DELETE/RELOCATE requests (cell type to operate on at the receiver) and COUNT/LIST requests (selector for filtering). The SF MAY redefine the bitmap format.
This document assigns IETF IE subtype SUBID_6TOP for the 6top Information Element, registered within the IETF IE registry defined by RFC 8137.
This document creates six 6TiSCH Parameters subregistries: 6P Version Numbers (currently only version 0), 6P Message Types (REQUEST, RESPONSE, CONFIRMATION), 6P Command Identifiers (ADD, DELETE, RELOCATE, COUNT, LIST, CLEAR, SIGNAL), 6P Return Codes (RC_SUCCESS, RC_EOL, RC_ERR, RC_RESET, RC_ERR_VERSION, RC_ERR_SFID, RC_ERR_SEQNUM, RC_ERR_CELLLIST, RC_ERR_BUSY, RC_ERR_LOCKED), 6P Scheduling Function Identifiers, and 6P CellOptions Bitmap values.
6P relies on the underlying 802.15.4 security mechanisms to protect message authenticity and integrity. Without link-layer security, an attacker could forge 6P messages to corrupt the TSCH schedule of any node within radio range, causing loss of connectivity or denial of service.
A schedule inconsistency is detected when a received 6P Request carries a SeqNum that differs from the expected value. Two triggers: (1) a neighbor power-cycles, resetting its SeqNum to 0; (2) maximum link-layer retransmissions are reached on the final ACK, leaving the two nodes with diverged SeqNums. The detecting node MUST return RC_ERR_SEQNUM; the SF then decides whether to issue CLEAR, LIST, or internally roll back.
The SeqNum is maintained per neighbor (and per SF when multiple SFs are active) as a lollipop counter: it resets to 0x00 after CLEAR or device reset, then increments through 0x01–0xFF, rolling over from 0xFF back to 0x01 (never to 0x00). A received SeqNum of 0 when the stored value is non-zero signals a neighbor reset and triggers RC_ERR_SEQNUM. The SeqNum increments by exactly 1 after every completed transaction.
A 6P Cell is a 4-byte field: slotOffset (16 bits, little-endian) followed by channelOffset (16 bits, little-endian), identifying a [slotOffset, channelOffset] tuple in the TSCH schedule.
All 6P messages share a common 4-octet header: Version (4 bits), Type/T (2 bits), Reserved/R (2 bits), Code (8 bits), SFID (8 bits), and SeqNum (8 bits), carried little-endian inside an 802.15.4 Payload IE with Group ID set to the IETF IE value.
The 6P ADD Request appends Metadata (16 bits), CellOptions (8 bits), NumCells (8 bits), and a variable-length CellList to the generic header. The ADD Response and Confirmation contain only the generic header plus a variable-length CellList.
The 6P LIST Request carries Metadata (16 bits), CellOptions (8 bits), Reserved (8 bits), Offset (16 bits), and MaxNumCells (16 bits). The Response returns a variable-length CellList and uses return code RC_EOL to signal the end of the list.
The 6P RELOCATE Request carries Metadata (16 bits), CellOptions (8 bits), NumCells (8 bits), a Relocation CellList of exactly NumCells entries, and a Candidate CellList of NumCandidate entries (0, NumCells, or more). In a 3-step transaction the Candidate CellList MUST be empty.