RFC 8480
6TiSCH Operation Sublayer (6top) Protocol (6P)
Part 1 of 10 🎀
RFC 8480: 6TiSCH Operation Sublayer (6top) Protocol (6P) 💖
okay bestie, this one is from the IETF (Internet Engineering Task Force, the crew that writes the rules for how the Internet talks to itself 🌈). It's RFC 8480, filed as a Standards Track document in November 2018, with ISSN 2070-1721 if you're keeping receipts ✨. The authors are Q. Wang, Ed. (Univ. of Sci. and Tech. Beijing), X. Vilajosana (Universitat Oberta de Catalunya), and T. Watteyne (Analog Devices). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Abstract 🦋
This doc defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which is what makes distributed scheduling work in 6TiSCH networks 🔥. 6P lets neighbor nodes add and delete Time-Slotted Channel Hopping (TSCH) cells to and on each other. 6P lives inside the 6TiSCH Operation Sublayer (6top), the layer sitting right above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is made of one or more Scheduling Functions (SFs) plus the 6top Protocol defined here. A 6top SF decides when to add or delete cells, and it kicks off 6P Transactions. Defining SFs is out of scope for this doc, but it does give the requirements an SF has to meet 💅.
Status of This Memo 🌸
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚.
For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8480 🔗.
Copyright Notice 🌈
Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License says.
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. 6TiSCH Operation Sublayer (6top) ................................5
2.1. Hard/Soft Cells ............................................6
2.2. Using 6P with the Minimal 6TiSCH Configuration .............6
3. 6top Protocol (6P) ..............................................7
3.1. 6P Transactions ............................................7
3.1.1. 2-Step 6P Transaction ...............................8
3.1.2. 3-Step 6P Transaction ..............................10
3.2. Message Format ............................................12
3.2.1. 6top Information Element (IE) ......................12
3.2.2. Generic 6P Message Format ..........................12
3.2.3. 6P CellOptions .....................................13
3.2.4. 6P CellList ........................................16
3.3. 6P Commands and Operations ................................17
3.3.1. Adding Cells .......................................17
3.3.2. Deleting Cells .....................................19
3.3.3. Relocating Cells ...................................21
3.3.4. Counting Cells .....................................27
3.3.5. Listing Cells ......................................28
3.3.6. Clearing the Schedule ..............................30
3.3.7. Generic Signaling between SFs ......................31
3.4. Protocol Functional Details ...............................31
3.4.1. Version Checking ...................................31
3.4.2. SFID Checking ......................................32
3.4.3. Concurrent 6P Transactions .........................32
3.4.4. 6P Timeout .........................................33
3.4.5. Aborting a 6P Transaction ..........................33
3.4.6. SeqNum Management ..................................33
3.4.7. Handling Error Responses ...........................40
3.5. Security ..................................................40
4. Requirements for 6top Scheduling Function (SF) Specifications ..41
4.1. SF Identifier (SFID) ......................................41
4.2. Requirements for an SF Specification ......................41
5. Security Considerations ........................................42
6. IANA Considerations ............................................43
6.1. IETF IE Subtype 6P ........................................43
6.2. 6TiSCH Parameters Subregistries ...........................43
6.2.1. 6P Version Numbers .................................43
6.2.2. 6P Message Types ...................................44
6.2.3. 6P Command Identifiers .............................44
6.2.4. 6P Return Codes ....................................45
6.2.5. 6P Scheduling Function Identifiers .................46
6.2.6. 6P CellOptions Bitmap ..............................47
7. References .....................................................48
7.1. Normative References ......................................48
7.2. Informative References ....................................48
Appendix A. Recommended Structure of an SF Specification ..........49
Authors' Addresses ................................................501. Introduction ✨
Okay so everything in a 6TiSCH network gets orchestrated by a schedule [RFC7554] 🗓️. The schedule is made of cells, and each cell is identified by a [slotOffset,channelOffset] pair (Section 3.2.4). This spec defines the 6TiSCH Operation Sublayer (6top) Protocol (6P), which is terminated by 6top 💅. 6P lets a node talk to a neighbor so they can add and delete Time-Slotted Channel Hopping (TSCH) cells to and on each other. The result is distributed schedule management across the whole 6TiSCH network, which is giving teamwork 🫶. 6top is made of one or more Scheduling Functions (SFs) plus the 6top Protocol in this doc. Defining SFs is out of scope here, but this doc does spell out the requirements an SF needs to meet.
Figure 1 is our example network, and we use it to show how nodes interact. The main case is node "A" sending 6P Requests (also called "commands" in this doc) to node "B". Node A is always the one issuing a 6P Request, and node B is always the one receiving it, and we stick with those roles all the way through 🧚.
(R)
/ \
/ \
(B)-----(C)
| |
| |
(A) (D)
Figure 1: A Simple 6TiSCH NetworkNode A keeps an eye on the communication cells it has scheduled to node B 👀:
- If node A figures out that the number of link-layer frames it sends to node B per unit of time is more than what the TSCH cells it has scheduled to node B can handle, it starts a 6P Transaction with node B to add one or more cells to the TSCH schedule of both nodes 📈.
- If the traffic is lower than what those scheduled TSCH cells can carry, node A starts a 6P Transaction with node B to delete one or more cells in the TSCH schedule of both nodes 📉.
- Node A MAY also watch statistics to see whether collisions are happening on a particular cell to node B. If that feature is switched on, node A talks to node B to "relocate" that cell to a different
[slotOffset,channelOffset]location in the TSCH schedule 🦋.
That's how you get distributed schedule management in a 6TiSCH network, no cap 🔥.
The 6top SF is the thing that decides when to add or delete a cell to or on a neighbor. Different applications need different SFs, and that topic is out of scope for this doc. Different SFs are expected to show up in future companion specifications 🌸. A node MAY implement multiple SFs and run them at the same time. At least one SF MUST be running. The SFID field in every 6P message lets a node pick the right SF on a per-6P Transaction basis, which is so iconic 👑.
Section 2 describes 6top, Section 3 defines 6P, and Section 4 gives guidelines on how to define an SF 📚.
1.1. Requirements Language 🎀
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🙏.
2. 6TiSCH Operation Sublayer (6top) 🌈
As Figure 2 shows, 6top is the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control (MAC) layer [IEEE802154] 🧁. In this doc we just say "802.15.4" as a short version of "IEEE Std 802.15.4".
.
| . |
| higher layers |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE Std 802.15.4 TSCH |
| . |
.
Figure 2: 6top in the Protocol Stack6top has two main jobs ✨:
- Terminate 6P, which lets neighbor nodes add and delete cells to and on one another.
- Run one or more 6top SFs, which define the rules that decide when to add or delete cells.
2.1. Hard/Soft Cells 💜
Every cell in the schedule is either "hard" or "soft" 🍬:
- A soft cell can be read, added, deleted, or updated by 6top.
- A hard cell is read-only for 6top.
For this spec, every cell 6top uses is a soft cell. Hard cells can be useful when you're "hard-coding" a schedule, as described in [RFC8180] 💅.
2.2. Using 6P with the Minimal 6TiSCH Configuration
6P MAY be used alongside the minimal 6TiSCH configuration [RFC8180]. okay so when it is, it's RECOMMENDED to use two slotframes, as depicted in Figure 3 ✨🎀
- Slotframe 0 is used for traffic defined in the minimal 6TiSCH configuration. In Figure 3, Slotframe 0 is five slots long, but it can be shorter or longer. 🌸
- 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 10 slots long, but it can be shorter or longer. 🦋
| 0 1 2 3 4 | 0 1 2 3 4 |
+------------------------+------------------------+
Slotframe 0 | | | | | | | | | | |
5 slots long | EB | | | | | EB | | | | |
(Minimal 6TiSCH) | | | | | | | | | | |
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 |
+-------------------------------------------------+
Slotframe 1 | | | | | | | | | | |
10 slots long | |A->B| | | | | | |B->A| |
(6P) | | | | | | | | | | |
+-------------------------------------------------+Figure 3: 2-Slotframe Structure when Using 6P alongside the Minimal 6TiSCH Configuration 💜
The minimal 6TiSCH configuration cell SHOULD be allocated from a slotframe of higher priority than the slotframe used by 6P for dynamic cell allocation. This way, dynamically allocated cells cannot "mask" the cells used by the minimal 6TiSCH configuration. 6top MAY support additional slotframes; how to use additional slotframes is out of scope for this document. 🙈
3. 6top Protocol (6P) ✨
6P enables two neighbor nodes to add/delete/relocate cells in their TSCH schedule. Conceptually, two neighbor nodes "negotiate" the location of the cells to add, delete, or relocate in their TSCH schedule. 🫶
3.1. 6P Transactions 💅
We call "6P Transaction" a complete negotiation between two neighbor nodes. A particular 6P Transaction is executed between two nodes as a result of an action triggered by one SF. For a 6P Transaction to succeed, both nodes MUST use the same SF to handle the particular transaction. A 6P Transaction starts when a node wishes to add/delete/relocate one or more cells with one of its neighbors. A 6P Transaction ends when (1) the cell(s) has been added/deleted/relocated in the schedule of both nodes or (2) the 6P Transaction has failed.
6P messages exchanged between nodes A and B during a 6P Transaction SHOULD be exchanged on non-shared unicast cells ("dedicated" cells) between nodes A and B. If no dedicated cells are scheduled between nodes A and B, shared cells MAY be used.
Keeping consistency between the schedules of the two neighbor nodes is important. A loss of consistency can cause loss of connectivity. One example is when node A has a transmit cell to node B but node B does not have the corresponding reception cell. To verify consistency, neighbor nodes maintain a sequence number (SeqNum). Neighbor nodes exchange the SeqNum as part of each 6P Transaction to detect a possible inconsistency. This mechanism is explained in Section 3.4.6.2. 🔥
An implementation MUST include a mechanism to associate each scheduled cell with the SF that scheduled it. This mechanism is implementation specific and is out of scope for this document.
A 6P Transaction can consist of two or three steps. A 2-step transaction is used when node A selects the cells to be allocated. A 3-step transaction is used when node B selects the cells to be allocated. An SF MUST specify whether to use 2-step transactions, 3-step transactions, or both.
We illustrate 2-step and 3-step transactions using the topology in Figure 1. 🌈
3.1.1. 2-Step 6P Transaction 🦋
Figure 4 shows an example 2-step 6P Transaction. In a 2-step transaction, node A selects the candidate cells. Several elements are left out so that the diagram is easier to understand.
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| Type = REQUEST |
| Code = ADD |
| SeqNum = 123 |
cells | NumCells = 2 |
locked | CellList = [(1,2),(2,2),(3,5)] |
+-- |-------------------------------------->|
| | L2 ACK |
| 6P Timeout |<- - - - - - - - - - - - - - - - - - - |
| | | |
| | | 6P Response |
| | | Type = RESPONSE |
| | | Code = RC_SUCCESS |
| | | SeqNum = 123 | cells
| | | CellList = [(2,2),(3,5)] | locked
+-> X |<--------------------------------------| --+
| L2 ACK | |
| - - - - - - - - - - - - - - - - - - ->| <-+
| |Figure 4: An Example 2-Step 6P Transaction 💖
In this example, the 2-step transaction occurs as follows: 🍓
- The SF running on node A determines that two extra cells need to be scheduled to node B.
- The SF running on node A selects candidate cells for node B to choose from. Node A MUST select at least as many candidate cells as the number of cells to add. Here, node A selects three candidate cells. Node A locks those candidate cells in its schedule until it receives a 6P Response. 🔒
- Node A sends a 6P ADD Request to node B, indicating that it wishes to add two cells (the "NumCells" value) and specifying the list of three candidate cells (the "CellList" value). Each cell in the CellList is a [slotOffset,channelOffset] tuple. This 6P ADD Request is link-layer acknowledged by node B (labeled "L2 ACK" in Figure 4). 📨
- After having successfully sent the 6P ADD Request (i.e., receiving the link-layer acknowledgment), node A starts a 6P Timeout to abort the 6P Transaction in the event that no response is received from node B. ⏰
- The SF running on node B selects two out of the three cells from the CellList of the 6P ADD Request. Node B locks those cells in its schedule until the transmission is successful (i.e., node B receives a link-layer ACK from node A). Node B sends back a 6P Response to node A, indicating the cells it has selected. The response is link-layer acknowledged by node A. 🎀
- Upon completion of this 6P Transaction, two cells from node A to node B have been added to the TSCH schedule of both nodes A and B. ✅
- An inconsistency in the schedule can happen if the 6P Timeout expires when the 6P Response is in the air, if the last link-layer ACK for the 6P Response is lost, or if one of the nodes is power-cycled during the transaction. 6P provides an inconsistency detection mechanism to cope with such situations; see Section 3.4.6.2 for details. 💀
3.1.2. 3-Step 6P Transaction ✨
okay so this section is about the 3-step flavour of a 6P Transaction, and the vibe is that node B is the one doing the picking 💅 Figure 5 walks through it. A few bits are left out so the diagram stays readable bestie 🎀
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| Type = REQUEST |
| Code = ADD |
| SeqNum = 178 |
| NumCells = 2 |
| CellList = [] |
|-------------------------------------->|
| L2 ACK |
6P Timeout |<- - - - - - - - - - - - - - - - - - - |
| | |
| | 6P Response |
| | Type = RESPONSE |
| | Code = RC_SUCCESS |
| | SeqNum = 178 | cells
| | CellList = [(1,2),(2,2),(3,5)] | locked
X |<--------------------------------------| --+
| L2 ACK | |
| - - - - - - - - - - - - - - - - - - ->| 6P Timeout |
| | | |
| 6P Confirmation | | |
| Type = CONFIRMATION | | |
| Code = RC_SUCCESS | | |
cells | SeqNum = 178 | | |
locked | CellList = [(2,2),(3,5)] | | |
+-- |-------------------------------------->| X <--+
| | L2 ACK |
+-> |<- - - - - - - - - - - - - - - - - - - |
| |
Figure 5: An Example 3-Step 6P TransactionHere's how the 3-step transaction plays out 👑
- The SF running on node A figures out it needs two extra cells scheduled to node B 🦋 Since it's using a 3-step transaction, it does not pick candidate cells itself.
- Node A sends a 6P ADD Request to node B asking for two cells (that's the
NumCellsvalue), with an emptyCellList🌸 Node B link-layer acknowledges this one. - Once node A has successfully sent that 6P ADD Request, it starts a 6P Timeout ⏰ If no 6P Response shows up from node B, the timeout aborts the transaction 😭
- The SF running on node B picks three candidate cells and locks them 🔒 Then node B sends a 6P Response back to node A listing the three cells it picked. Node A link-layer acknowledges the response.
- After node B has successfully sent the 6P Response, it starts its own 6P Timeout 💜 If no 6P Confirmation arrives from node A, that timeout aborts the transaction.
- The SF running on node A picks two cells out of the
CellListin the 6P Response and locks them 🧚 Node A then sends a 6P Confirmation to node B with the cells it chose. Node B link-layer acknowledges the confirmation. - Once the 6P Transaction is complete, two cells from node A to node B have been added to the TSCH schedule of both nodes A and B 🎀✨
- Okay, but here's the tea ☕ A schedule inconsistency can happen if the 6P Timeout expires while the 6P Confirmation is still in the air, if the last link-layer ACK for the 6P Confirmation gets lost, or if one of the nodes gets power-cycled mid-transaction 🙈 Don't panic though, 6P has an inconsistency detection mechanism to deal with exactly these situations. Check out Section 3.4.6.2 for the details 🦋
3.2. Message Format 🍓
3.2.1. 6top Information Element (IE) 💖
6P messages only travel over a single hop 🧚 They ride inside an 802.15.4 Payload Information Element (IE) [IEEE802154] as its payload, and they're encapsulated within the Payload IE header. The Group ID is set to the IETF IE value defined in [RFC8137], and the content gets wrapped in a subtype ID, also as defined in [RFC8137].
Since 6P messages live in IEs, IEEE bit and byte ordering applies 🌈 Bits within each field of the "6top IE" subtype are numbered from 0 (leftmost and least significant) to k-1 (rightmost and most significant), where k is the field length in bits. Fields longer than a single octet get copied into the packet starting from the octet with the lowest-numbered bits, up to the octet with the highest-numbered bits (little endian) 💅
This document defines the 6top IE, which is a subtype of the IETF IE from [RFC8137], with subtype SUBID_6TOP ✨ The subtype content of the 6top IE is defined in Section 3.2.2, and its length is variable.
3.2.2. Generic 6P Message Format 🎀
Every 6P message follows the generic format in Figure 6 👑
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Fields...
+-+-+-+-+-+-+-+-+-
Figure 6: Generic 6P Message FormatHere's what each field does 🦋
- 6P Version (Version): This is the version of 6P. Only version 0 is defined in this document. Future specifications may define subsequent versions of 6P 🌸
- Type (T): The type of message. The message types are defined in Section 6.2.2 💖
- Reserved (R): Reserved bits. These two bits SHOULD be set to zero when sending the message and MUST be ignored upon reception 🙈
- Code: When the 6P message has a Type value of REQUEST, the Code field holds a 6P command identifier, and Section 6.2.3 lists those. When the 6P message has a Type value of RESPONSE or CONFIRMATION, the Code field holds a 6P return code instead, and Section 6.2.4 lists those. The same return codes are used in both 6P Response and 6P Confirmation messages 🧚
- 6top Scheduling Function Identifier (SFID): The identifier of the SF to use to handle this message. The SFID is defined in Section 4.1 👑
- SeqNum: The sequence number for the 6P Transaction. It's used to match the 6P Request, 6P Response, and 6P Confirmation of the same 6P Transaction. The value of SeqNum MUST be different for each new 6P Request issued to the same neighbor and using the same SF. SeqNum also helps keep the schedules of the two neighbors consistent. Section 3.4.6 details how SeqNum is managed 🔥
- Other Fields: The list of other fields and how they're used is detailed in Section 3.3 ✨
6P Request, 6P Response, and 6P Confirmation messages for a given transaction MUST share the same Version, SFID, and SeqNum values 💜
Future versions of the 6P message SHOULD maintain the format of the 6P Version, Type, and Code fields for backward compatibility 🫶
3.2.3. 6P CellOptions
okay so the 8-bit 6P CellOptions bitmap shows up in five 6P Requests: ADD, DELETE, COUNT, LIST, and RELOCATE 💅 Its format and meaning MAY be redefined by the SF ✨, which means the routine that parses this field is tied to one specific SF 🦋
- In the 6P ADD Request, the bitmap tells you what type of cell to add 🌸
- In the 6P DELETE Request, it tells you what type of cell to delete 🗑️
- In the 6P RELOCATE Request, it tells you what type of cell to relocate 🔁
- In the 6P COUNT and LIST Requests, it works as a selector for a particular type of cells 🔍
The CellOptions bitmap applies to every element in the CellList field, so it's giving consistency 💖 The possible values are:
- TX = 1 (resp. 0) refers to
macTxType = TRUE(resp.FALSE) in themacLinkTableof 802.15.4 [IEEE802154] 🎀 - RX = 1 (resp. 0) refers to
macRxType = TRUE(resp.FALSE) in themacLinkTableof 802.15.4 🦋 - S = 1 (resp. 0) refers to
macSharedType = TRUE(resp.FALSE) in themacLinkTableof 802.15.4 🌈
Section 6.2.6 gives the format of the 6P CellOptions bitmap, and that format applies unless the SF redefines it 🧚 Figure 7 shows what the bitmap means for the 6P ADD, DELETE, and RELOCATE Requests (unless the SF redefines it), and Figure 8 shows what it means for the 6P COUNT and LIST Requests (unless the SF redefines it) 📋
Note: Here, we assume that node A issues the 6P command to node B.
+-------------+-----------------------------------------------------+
| CellOptions | The type of cells B adds/deletes/relocates to its |
| Value | schedule when receiving a 6P ADD/DELETE/RELOCATE |
| | Request from A |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=0| Invalid combination. RC_ERR is returned |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=0| Add/delete/relocate RX cells at B (TX cells at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=0| Add/delete/relocate TX cells at B (RX cells at A) |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=0| Add/delete/relocate TX|RX cells at B (and at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=1| Invalid combination. RC_ERR is returned |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=1| Add/delete/relocate RX|SHARED cells at B |
| | (TX|SHARED cells at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=1| Add/delete/relocate TX|SHARED cells at B |
| | (RX|SHARED cells at A) |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=1| Add/delete/relocate TX|RX|SHARED cells at B |
| | (and at A) |
+-------------+-----------------------------------------------------+
Figure 7: Meaning of the 6P CellOptions Bitmap for the
6P ADD, DELETE, and RELOCATE Requests Note: Here, we assume that node A issues the 6P command to node B.
+-------------+-----------------------------------------------------+
| CellOptions | The type of cells B selects from its schedule when |
| Value | receiving a 6P COUNT or LIST Request from A, |
| | from all the cells B has scheduled with A |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=0| All cells |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=0| All cells marked as RX only |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=0| All cells marked as TX only |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=0| All cells marked as TX and RX only |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=1| All cells marked as SHARED (regardless of TX, RX) |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=1| All cells marked as RX and SHARED only |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=1| All cells marked as TX and SHARED only |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=1| All cells marked as TX, RX, and SHARED |
+-------------+-----------------------------------------------------+
Figure 8: Meaning of the 6P CellOptions Bitmap for the
6P COUNT and LIST RequestsThe CellOptions is basically an opaque set of bits 🫶 It gets sent to the SF unmodified, and the SF MAY redefine the format and meaning of the CellOptions field 🌈
3.2.4. 6P CellList
A CellList field MAY be present in a 6P ADD Request, a 6P DELETE Request, a 6P RELOCATE Request, a 6P Response, or a 6P Confirmation ✨ It's made up of zero or more 6P Cells, as shown in Figure 9 🎀 The CellOptions field sets the options for every cell in the CellList, which means all the cells in the CellList get the same options 💜
A 6P Cell is a 4-byte field, and its default format looks like this 🦋
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 6P Cell FormatslotOffset: The slot offset of the cell 🌸channelOffset: The channel offset of the cell 🌸
The CellList is an opaque set of bytes that gets sent to the SF unmodified 🧚 Its length is implicit, and it's determined by the IE Length field of the Payload IE header, as defined in 802.15.4 🔥 The SF MAY redefine the format of the CellList field, so the routine that parses this field is tied to a specific SF 🌈
3.3. 6P Commands and Operations
3.3.1. Adding Cells
Cells get added with the 6P ADD command 💅 The Type field (T) is set to REQUEST, and the Code field is set to ADD ✨ Figure 10 defines the format of a 6P ADD Request 📋
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-+
Figure 10: 6P ADD Request Format- Metadata: Used as extra signaling to the SF. The contents of the Metadata field are an opaque set of bytes passed unmodified to the SF. The meaning of this field depends on the SF and is out of scope for this document. For example, Metadata can specify in which slotframe to add the cells. 🗓️
- CellOptions: Indicates the options to associate with the cells to be added. If more than one cell is added (NumCells > 1), the same options are associated with each one. This necessarily means that if node A needs to add multiple cells with different options, it needs to initiate multiple 6P ADD Transactions. 🎀
- NumCells: The number of additional cells node A wants to schedule to node B. 💖
- CellList: A list of zero or multiple candidate cells. Its length is implicit and is determined by the Length field of the Payload IE header. 🦋
Figure 11 defines the format of a 6P ADD Response and Confirmation 💜
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 11: 6P ADD Response and Confirmation Format- CellList: A list of zero or more 6P Cells. 🌸
Picture the topology in Figure 1 🌍 In this case, the SF on node A decides to add NumCells cells to node B 💅
Node A's SF selects NumCandidate cells from its schedule. These are the cells that are candidates to be scheduled with node B 🔍 The CellOptions field specifies the type of these cells. NumCandidate MUST be greater than or equal to NumCells. How many cells node A selects (NumCandidate) and how that selection is done are specified in the SF and are out of scope for this document ✨ Node A sends a 6P ADD Request to node B that contains the CellOptions, the value of NumCells, and a selection of NumCandidate cells in the CellList 📬 If the NumCandidate cells do not fit in a single packet, this operation MUST be split into multiple independent 6P ADD Requests, each for a subset of the number of cells that eventually need to be added. In the case of a 3-step transaction, the SF is responsible for ensuring that the returned Candidate CellList fits into the 6P Response 🧚
Once node B gets the request, it checks whether the CellOptions are set to a valid value, as noted by Figure 7 👀 If that's not the case, a Response with code RC_ERR is returned 🙈 If the number of cells in the received CellList in node B is smaller than NumCells, node B MUST return a 6P Response with the RC_ERR_CELLLIST code. Otherwise, node B's SF checks which of the cells in the CellList it can install in node B's schedule, following the specified CellOptions field 💖 How that selection is done is specified in the SF and is out of scope for this document. The 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 (fewer than NumCells cells from the CellList can be used) 😭 In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and that specifies the list of cells that were scheduled following the CellOptions field. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed) 🦋
Once node A gets the response, it adds the cells in the CellList according to the CellOptions field 🌈✨
3.3.2. Deleting Cells 🗑️
Okay so deleting cells is done with the 6P DELETE command 💅. The Type field (T) gets set to REQUEST and the Code field gets set to DELETE. Figure 12 shows what a 6P DELETE Request looks like 🎀.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 12: 6P DELETE Request FormatMetadata: same usage as the 6P ADD command, so peek at Section 3.3.1 🧚. The format is the same as in 6P ADD, but the content could be different ✨.
CellOptions: the options the cells need to be associated with, so you know which cells you're deleting 🎀. Only cells matching the CellOptions can be deleted 🙈.
NumCells: the number of cells from the specified CellList the sender wants to delete from the schedule of both sender and receiver 💜.
CellList: a list of zero or more 6P Cells. Its length is determined by the Length field of the Payload IE header 🍓.
Figure 13 is the 6P DELETE Response and Confirmation 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| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 13: 6P DELETE Response and Confirmation FormatCellList: a list of zero or more 6P Cells.
Deleting works just like adding, except for these twists 🌈:
- The nodes delete the cells they agree upon instead of adding them 🧹.
- All cells in the CellList MUST already be scheduled between the two nodes and MUST match the CellOptions field. If node A puts cells in its CellList that aren't already scheduled between the two nodes or don't match the CellOptions field, node B MUST reply with a
RC_ERR_CELLLISTreturn code 🙅♀️. - The CellList in a 6P Request (2-step transaction) or 6P Response (3-step transaction) MUST be empty, contain exactly NumCells cells, or contain more than NumCells cells. A CellList that isn't empty but has fewer than NumCells cells is not supported, so the
RC_ERR_CELLLISTcode MUST be returned when the CellList has fewer than NumCells cells 🚫. If the CellList is empty, the SF on the receiving node MUST choose NumCells cells scheduled to the sender that match the CellOptions field and delete them 🫶. If the CellList has more than NumCells cells, the SF on the receiving node chooses exactly NumCells cells from the CellList to delete 🎯.
3.3.3. Relocating Cells 🦋
Cell relocation means moving a cell to a different [slotOffset,channelOffset] location in the schedule 🌸. The Type field (T) is set to REQUEST and the Code field is set to RELOCATE. Figure 14 shows the 6P RELOCATE Request 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| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relocation CellList ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Candidate CellList ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 14: 6P RELOCATE Request FormatMetadata: same usage as the 6P ADD command, so see Section 3.3.1 🎀.
CellOptions: the options that need to be associated with the cells being relocated 💜.
NumCells: the number of cells to relocate. It MUST be greater than or equal to 1 🌟.
Relocation CellList: the list of NumCells 6P Cells to relocate 🔁.
Candidate CellList: a list of NumCandidate candidate cells for node B to pick from. NumCandidate MUST be 0, equal to NumCells, or greater than NumCells. Its length is determined by the Length field of the Payload IE header 🍓.
In a 2-step 6P RELOCATE Transaction, node A specifies both (1) the cells it needs to relocate and (2) the list of candidate cells to relocate to 🫧. The Relocation CellList MUST contain exactly NumCells entries. The Candidate CellList MUST contain at least NumCells entries (NumCandidate >= NumCells).
In a 3-step 6P RELOCATE Transaction, node A only specifies the cells it needs to relocate, not the candidate cells to relocate to 🙃. The Candidate CellList MUST therefore be empty.
Figure 15 shows the 6P RELOCATE Response and Confirmation 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| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 15: 6P RELOCATE Response and Confirmation FormatCellList: a list of zero or more 6P Cells.
Here's the play-by-play 🎬. Node A's SF wants to relocate NumCells cells. Node A creates a 6P RELOCATE Request and lists the cells it wants to move in the Relocation CellList. It also picks NumCandidate cells from its schedule as candidates to move them to, and puts those in the Candidate CellList. The CellOptions field says what type of cell(s) to relocate 🧠. NumCandidate MUST be greater than or equal to NumCells. How many cells get selected (NumCandidate) and how that selection happens are specified in the SF and are out of scope for this document 🙌. Node A then sends the 6P RELOCATE Request to node B 📨.
When node B gets the request, it checks whether the length of the Candidate CellList is greater than or equal to NumCells 👀. Node B's SF also verifies that all the cells in the Relocation CellList are scheduled with node A and are associated with the options in the CellOptions field. If either check fails, node B MUST send a 6P Response to node A with return code RC_ERR_CELLLIST 🚨. If both checks pass, node B's SF checks which cells in the Candidate CellList it can install in its schedule. How that selection is done is specified in the SF and is out of scope for this document 🫶. That verification can succeed (NumCells cells from the Candidate CellList can be used), fail (none of the cells from the Candidate CellList can be used), or partially succeed (fewer than NumCells cells from the Candidate CellList can be used) 🎲. In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and specifies the list of cells that will be rescheduled following the CellOptions field 💌. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed). If N < NumCells cells appear in the CellList, that means the first N cells in the Relocation CellList have been relocated and the rest have not 🧩.
When node A gets a response with code RC_SUCCESS, it relocates the cells in the Relocation CellList of its RELOCATE Request to the new locations in the CellList of the 6P Response, in the same order 🏃♀️. If the return code is RC_ERR_CELLLIST, the transaction is aborted and no cell gets relocated 🛑. In a 2-step transaction, node B relocates the selected cells once it receives the link-layer ACK for the 6P Response ✅. In a 3-step transaction, node B relocates the selected cells once it receives the 6P Confirmation 🎉.
The SF SHOULD NOT relocate all cells between two nodes at the same time, because that could make the schedules of both nodes diverge a lot 🙈💀.
Figure 16 shows an example of a successful 2-step 6P RELOCATE Transaction 👑.
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 11 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] |
|-------------------------------------->| B prepares
| L2 ACK | to relocate
|<- - - - - - - - - - - - - - - - - - - | (1,2)->(5,3)
| | and
| | (2,2)->(3,3)
| 6P Response |
| Code = RC_SUCCESS |
| SeqNum = 11 |
| CellList = [(5,3),(3,3)] |
A relocates |<--------------------------------------|
(1,2)->(5,3) | L2 ACK |
and | - - - - - - - - - - - - - - - - - - ->| B relocates
(2,2)->(3,3) | | (1,2)->(5,3)
| | and
| | (2,2)->(3,3)
Figure 16: Example of a Successful 2-Step 6P RELOCATE TransactionFigure 17 shows an example of a partially successful 2-step 6P RELOCATE Transaction 🌷.
okay bestie, the relocate flow has three flavors and each one hits different 🦋 first up is the partially successful 2-step version, where B says yes to some cells and no to others 💅
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 199 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] | B prepares
|-------------------------------------->| to relocate
| L2 ACK | (1,2)->(4,3)
|<- - - - - - - - - - - - - - - - - - - | but cannot
| | relocate (2,2)
| 6P Response |
| Type = RESPONSE |
| Code = RC_SUCCESS |
| SeqNum = 199 |
| CellList = [(4,3)] |
A relocates |<--------------------------------------|
(1,2)->(4,3) | L2 ACK |
| - - - - - - - - - - - - - - - - - - ->| B relocates
| | (1,2)->(4,3)
| |
| |
Figure 17: Example of a Partially Successful 2-Step 6P
RELOCATE TransactionFigure 18 is the failed 2-step RELOCATE transaction 💀 nobody's winning here, so read it and feel the vibes 🫶
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 53 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] |
|-------------------------------------->| B cannot
| L2 ACK | relocate
|<- - - - - - - - - - - - - - - - - - - | (1,2)
| | or (2,2)
| 6P Response |
| Type = RESPONSE |
| Code = RC_SUCCESS |
| SeqNum = 53 |
| CellList = [] |
|<--------------------------------------| B does not
| L2 ACK | relocate
A does not | - - - - - - - - - - - - - - - - - - ->|
relocate | |
| |
Figure 18: Failed 2-Step 6P RELOCATE Transaction ExampleFigure 19 is the main character moment ⭐ a successful 3-step RELOCATE, where A and B both end up relocating cells 👑
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 11 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [] |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - | B identifies
| | candidate
| | cells
| 6P Response | (3,3),
| Code = RC_SUCCESS | (4,3), and
| SeqNum = 11 | (5,3)
| CellList = [(3,3),(4,3),(5,3)] |
A prepares |<--------------------------------------|
to relocate | L2 ACK |
(1,2)->(5,3) | - - - - - - - - - - - - - - - - - - ->|
and | |
(2,2)->(3,3) | 6P Confirmation |
| Code = RC_SUCCESS |
| SeqNum = 11 |
| CellList = [(5,3),(3,3)] |
|-------------------------------------->| B relocates
| L2 ACK | (1,2)->(5,3)
A relocates |<- - - - - - - - - - - - - - - - - - - | and
(1,2)->(5,3) | | (2,2)->(3,3)
and | |
(2,2)->(3,3) | |
| |
Figure 19: Example of a Successful 3-Step 6P RELOCATE Transaction3.3.4. Counting Cells 🔢
wanna know how many cells node A has scheduled with B? 🧮 node A sends a 6P COUNT command. The Type field (T) is set to REQUEST, and the Code field is set to COUNT. Figure 20 shows the format of a 6P COUNT Request 🎀
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: 6P COUNT Request FormatMetadata: same usage as the 6P ADD command, so check Section 3.3.1 💅 The format is the same as in 6P ADD, but the content can be different 🌸CellOptions: tells you which type of cell to count 🧁
Figure 21 is the 6P COUNT Response 🦋
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: 6P COUNT Response FormatNumCells: the number of cells that match the fields of the request 🍓
So the flow is: node A sends a COUNT command to node B with some cell options 💜 Once B gets the 6P COUNT Request, it goes through its own schedule and counts the cells it has scheduled with node A that match the cell options in the CellOptions field of the request. If you're curious how CellOptions works, Section 3.2.3 has all the tea ☕
Then node B sends back a 6P Response to node A with the return code RC_SUCCESS and NumCells filled in with how many cells matched 🎉
3.3.5. Listing Cells 📋
okay now if node A wants the actual list of cells it has with B, it sends a 6P LIST command 📜 Same deal: the Type field (T) is set to REQUEST and the Code field is set to LIST. Figure 22 is the format of a 6P LIST Request 💖
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | MaxNumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: 6P LIST Request FormatMetadata: same usage as the 6P ADD command, see Section 3.3.1 💅 Its format matches the 6P ADD one, but the content can be different ✨CellOptions: tells you which type of cell to list 🌈Reserved: reserved bits. These bits SHOULD be set to zero when sending the message and MUST be ignored upon reception 🙈Offset: the offset of the first scheduled cell being requested. The mechanism assumes the cells are ordered by a rule defined in the SF, and the rule MUST always order the cells in the same way 🧚MaxNumCells: the maximum number of cells to list. Node B MAY return fewer thanMaxNumCellscells, for example ifMaxNumCellscells don't fit in the frame 🫧
Figure 23 is the 6P LIST Response 🌸
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 23: 6P LIST Response FormatCellList: a list of zero or more 6P Cells 🍭
When node B gets a LIST command, it returns the cells scheduled with A in its schedule that match the CellOptions field, as specified in Section 3.2.3 💜
Here's the important bit 👑 When node B receives a LIST Request, the CellList in the 6P Response holds between 0 and MaxNumCells cells, starting from the specified offset. Node B SHOULD include as many cells as will fit in the frame. If the response contains the last cell, node B MUST set the Code field in the response to RC_EOL ("End of List", as per Figure 38 in Section 6.2.4), which tells node A there are no more matching cells 🏁 Node B MUST return at least one cell, unless the specified offset is beyond the end of B's cell list in its schedule. And if node B has fewer than Offset cells that match the request, it returns an empty CellList with the Code field set to RC_EOL 🫶
3.3.6. Clearing the Schedule 🧹✨
Okay so bestie, when the schedule gets totally out of sync (like a schedule inconsistency that gets detected 😭), node A can wipe the slate clean by issuing a CLEAR command. The Type field (T) is set to REQUEST and the Code field is set to CLEAR. Figure 24 shows what a 6P CLEAR Request looks like 💅
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: 6P CLEAR Request FormatMetadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. 🎀
Figure 25 is the 6P CLEAR Response, and it's giving very clean energy 🦋
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: 6P CLEAR Response FormatNow the important part, so listen up 🚨 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 means node A MUST remove all the cells scheduled with node B, and node B MUST remove all the cells scheduled with node A. In a 6P CLEAR command, the SeqNum MUST NOT be checked. Like, even if the request has a SeqNum value that would normally make node B detect a schedule inconsistency, the transaction MUST NOT be aborted 💀 Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0.
The return code sent back for a 6P CLEAR command SHOULD be RC_SUCCESS, unless the operation can't be executed. When the CLEAR operation can't be executed, the return code MUST be set to RC_RESET 🙈
3.3.7. Generic Signaling between SFs 📡💜
The 6P SIGNAL message lets the SF implementations on two neighbor nodes swap generic commands. The payload in a received SIGNAL message is an opaque set of bytes that gets passed unmodified to the SF. The length of the payload is determined by the Length field of the Payload IE header. How the generic SIGNAL command gets used is specified by the SF and is outside the scope of this document. The Type field (T) is set to REQUEST and the Code field is set to SIGNAL. Figure 26 shows the 6P SIGNAL Request 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| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: 6P SIGNAL Request FormatMetadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different.
Figure 27 is the 6P SIGNAL Response 🧚
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: 6P SIGNAL Response Format3.4. Protocol Functional Details 🧠💅
3.4.1. Version Checking 🔢
Every message has a Version field. If multiple protocol versions of 6P get defined (in future specs, for Version values other than 0), a node MAY implement multiple protocol versions at the same time. When a node gets a 6P message with a version number it doesn't implement, the node MUST reply with a 6P Response whose return code field is set to RC_ERR_VERSION. The format of this 6P Response message MUST be compliant with version 0 and MUST be supported by all future versions of the protocol. This is what makes sure that when node B sends a 6P Response to node A saying it doesn't implement the 6P version in the 6P Request, node A can still parse that response successfully. Iconic, right? ✨
When a node supports a version number received in a 6P Request message, the Version field in the 6P Response MUST be the same as the Version field in the corresponding 6P Request. Similarly, in a 3-step transaction, the Version field in the 6P Confirmation MUST match that of the 6P Request and 6P Response of the same transaction.
3.4.2. SFID Checking 🆔
Every message has an SFID field. A node MAY support multiple SFs at the same time. When a node receives a 6P message with an unsupported SFID, it MUST reply with a 6P Response with a return code of RC_ERR_SFID. The SFID field in the 6P Response MUST be the same as the SFID field in the corresponding 6P Request. In a 3-step transaction, the SFID field in the 6P Confirmation MUST match that of the 6P Request and the 6P Response of the same transaction.
3.4.3. Concurrent 6P Transactions 🚦
Only one 6P Transaction at a time, in a given direction, can happen between two neighbors. So a node MUST NOT issue a new 6P Request to a given neighbor before the previous 6P Transaction it started has finished (or possibly timed out). If a node gets a 6P Request from a given neighbor before it has 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_RESET (as per Figure 38 in Section 6.2.4) and discard this ongoing second transaction. A node that receives an RC_RESET code MUST abort the second transaction and treat it as though it never happened (that is, reverting any changes to the schedule or SeqNum made by this transaction). 🙃
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 with different neighbors. In this case, the cells involved in an 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. If a node doesn't have enough resources to handle concurrent 6P Transactions from different neighbors, it MUST reply with a 6P Response with return code RC_ERR_BUSY (as per Figure 38 in Section 6.2.4). If the requested cells are locked, it MUST reply to that request with a 6P Response with return code RC_ERR_LOCKED (as per Figure 38). The node receiving RC_ERR_BUSY or RC_ERR_LOCKED MAY implement a retry mechanism as defined by the SF. 🔁
3.4.4. 6P Timeout ⏰
A timeout happens when the node that successfully sent a 6P Request doesn't get the corresponding 6P Response within an amount of time specified by the SF. In a 3-step transaction, a timeout also happens when a node sending the 6P Response doesn't get a 6P Confirmation. When a timeout happens, the transaction MUST be canceled at the node where the timeout occurs. The value of the 6P Timeout should be greater than the longest possible time it takes to receive the 6P Response or Confirmation. So the value of the 6P Timeout depends on the number of cells scheduled between the neighbor nodes, the maximum number of link-layer retransmissions, and so on. The SF MUST determine the value of the timeout. The value of the timeout is out of scope for this document. 🕰️
3.4.5. Aborting a 6P Transaction 🛑
If the receiver of a 6P Request fails during a 6P Transaction and can't complete it, it SHOULD reply to that request with a 6P Response with return code RC_RESET. When the initiator of the 6P Transaction gets this 6P Response, it MUST consider the 6P Transaction as having failed.
Similarly, in the case of a 3-step transaction, when the receiver of a 6P Response fails during the 6P Transaction and can't complete it, it MUST reply to that 6P Response with a 6P Confirmation with return code RC_RESET. When the sender of the 6P Response gets this 6P Confirmation, it MUST consider the 6P Transaction as having failed. 💔
3.4.6. SeqNum Management 🔢🌸
The SeqNum is the field in the 6top IE header used to match Request, Response, and Confirmation messages for a given transaction. The SeqNum is used to detect and handle duplicate commands (Section 3.4.6.1) and inconsistent schedules (Section 3.4.6.2). Each node remembers the last used SeqNum for each neighbor. That means a node stores as many SeqNum values as it has neighbors. If a node supports multiple SFs at a time, a SeqNum value is maintained per SF and per neighbor. In the rest of this section, we describe how SeqNum is used between two neighbors. The same thing happens for each other neighbor, independently.
When a node resets, or after a CLEAR Transaction, it MUST reset SeqNum to 0. The 6P Response and 6P Confirmation for a transaction MUST use the same SeqNum value as the request. After every transaction, the SeqNum MUST be incremented by exactly 1.
Specifically, if node A receives the link-layer acknowledgment for its 6P Request, it increments the SeqNum by exactly 1 after the 6P Transaction ends. This makes sure that the next 6P Transaction where it sends a 6P Request has a different SeqNum. 🙌
Similarly, node B increments the SeqNum by exactly 1 after receiving the link-layer acknowledgment for the 6P Response (2-step 6P Transaction), or after sending the link-layer acknowledgment for the 6P Confirmation (3-step 6P Transaction).
When node B gets a 6P Request from node A with SeqNum equal to 0, it checks the stored SeqNum for A. If A is a new neighbor, the stored SeqNum in B will be 0, and the transaction can continue. If the stored SeqNum for A in B is different from 0, a potential inconsistency is detected. In this case, B MUST return RC_ERR_SEQNUM with SeqNum=0. The SF of node A MAY decide what to do next, as described in Section 3.4.6.2. 🤔
The SeqNum MUST be implemented as a lollipop counter: it rolls over from 0xFF to 0x01 (not to 0x00). This is how a neighbor reset gets detected. Figure 28 lists the possible values of the SeqNum 📋
+-----------+------------------------------+
| Value | Meaning |
+-----------+------------------------------+
| 0x00 | Clear, or after device reset |
| 0x01-0xFF | Lollipop counter values |
+-----------+------------------------------+
Figure 28: Possible Values of the SeqNum3.4.6.1. Detecting and Handling Duplicate 6P Messages ✨
Okay bestie, so every 6P command gets a link-layer acknowledgment 🫶. A duplicate is when a node gets a second 6P Request, Response, or Confirmation 😭. That happens when the link-layer ACK never shows up, so the link layer retransmits 🔁. Duplicates are normal and literally unavoidable, so no panic 💅.
Figure 29 shows a 2-step transaction where node A gets a duplicate 6P Response 🦋.
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P Request (SeqNum=456) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=456) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - -X | no ACK:
| | link-layer
| 6P Response (SeqNum=456) | retransmit
duplicate |<--------------------------------------|
6P Response | L2 ACK |
received | - - - - - - - - - - - - - - - - - - ->|
| |
Figure 29: Example Duplicate 6P MessageFigure 30 is a 3-step transaction where node A gets an out-of-order duplicate 6P Response right after it already sent a 6P Confirmation 👀.
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P Request (SeqNum=123) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=123) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - -X | no ACK:
| | link-layer
| 6P Confirmation (SeqNum=123) | retransmit
|-------------------------------------->| |
| L2 ACK | |
|<- - - - - - - - - - - - - - - - - - - | frame
| | queued
| 6P Response (SeqNum=123) | |
duplicate |<--------------------------------------| <--+
out-of-order | L2 ACK |
6P Response | - - - - - - - - - - - - - - - - - - ->|
received | |
Figure 30: Example Out-of-Order Duplicate 6P MessageHere's how a node spots one 🕵️♀️: it's a duplicate when the message has the same SeqNum and the same type as the last frame it received from that neighbor. When that happens, the node MUST send a link-layer acknowledgment 💌 but MUST silently ignore the 6P message at 6top 🤫. Ack it, but don't process it, periodt ✨.
3.4.6.2. Detecting and Handling a Schedule Inconsistency 🚨
Okay this one is serious bestie 😭. A schedule inconsistency is when the schedules of nodes A and B don't match. For example, node A has a transmit cell to node B, but node B doesn't have the matching receive cell, so it isn't listening to A on that cell 📻. A schedule inconsistency results in loss of connectivity 💀.
The SeqNum field is in every 6P message, and that's how we catch an inconsistency 🔍. SeqNum goes up by 1 in each message, as detailed in Section 3.4.6. A node works out the SeqNum it expects for the next 6P Transaction. If a node gets a 6P Request with a SeqNum that isn't the expected value, boom, it has detected an inconsistency 🎯.
There are two ways this can happen 👇.
The first way is when a node loses state, like when it gets power-cycled (turned off, then back on) 🔌. Its SeqNum value gets reset to 0 🫠. Since SeqNum is a lollipop counter, its neighbor notices the inconsistency in the next 6P Transaction 🍭. Figures 31 and 32 show this.
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=87 | | SeqNum=87
| |
| 6P Request (SeqNum=87) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=87) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
| ==== power-cycle
| |
SeqNum=88 | | SeqNum=0
| |
| 6P Request (SeqNum=88) |
|-------------------------------------->| Inconsistency
| L2 ACK | detected
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
Figure 31: Example of Inconsistency Because Node B Resets
(Detected by Node B)
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=97 | | SeqNum=97
| |
| 6P Request (SeqNum=97) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=97) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
| ==== power-cycle
| |
SeqNum=98 | | SeqNum=0
| |
| 6P Request (SeqNum=0) |
Inconsistency |<--------------------------------------|
detected | L2 ACK |
|- - - - - - - - - - - - - - - - - - - >|
| |
| 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
Figure 32: Example of Inconsistency Because Node B Resets
(Detected by Node A)The second way is when the maximum number of link-layer retransmissions gets hit on the 6P Response of a 2-step transaction (or, the same thing, on a 6P Confirmation of a 3-step transaction) 🥲. Figure 33 has the picture.
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=87 | | SeqNum=87
| |
| 6P Request (SeqNum=87) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=87) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
SeqNum=88 | | no ACK:
| 6P Response (SeqNum=87) | retrans. 1
(duplicate) |<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
| | no ACK:
| 6P Response (SeqNum=87) | retrans. 2
(duplicate) |<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
| | max. retrans.:
| | inconsistency
| | detected
Figure 33: Example Inconsistency Because of Maximum Link-Layer
Retransmissions (where Maximum = 2)In both cases, node B is the one that detects the inconsistency 🕵️.
When the inconsistency gets caught during a 6P Transaction (like Figure 31), the node that caught it MUST send back a 6P Response or 6P Confirmation with an error code of RC_ERR_SEQNUM 🙅♀️. In that message, the SeqNum field MUST be set to the value of the sender of the message. In the Figure 31 example, that's 0 🧚.
The SF of the node that caught the inconsistency MUST define how to handle it 👑. There are three possible ways to do that:
- Issue a 6P CLEAR Request to clear the schedule, and then rebuild.
- Issue a 6P LIST Request to retrieve the schedule.
- Internally "roll back" the schedule.
How to handle an inconsistency is out of scope for this document. The SF defines how to handle an inconsistency 🌈✨.
3.4.7. Handling Error Responses ❌
okay so, any return code marked Yes in the "Is Error?" column of Figure 38 (Section 6.2.4) means something went wrong 😭 When a node gets a 6P Response or 6P Confirmation with an error, it MUST consider the 6P Transaction as having failed. Lowkey the big one: if it was a response to a 6P ADD, DELETE, or RELOCATE Request, the node MUST NOT add, delete, or relocate any of the cells involved in that transaction. 🙅♀️
Same energy on the sending side. A node sending a 6P Response or a 6P Confirmation with an error code MUST NOT add, delete, or relocate any cells as part of that 6P Transaction. And if a node gets a return code it doesn't recognize, the 6P Transaction MUST be considered as having failed. 💀
In a 3-step 6P Transaction it goes like this 🦋 When the requester (node A) gets a 6P Response with a return code it does not recognize, it MUST send a 6P Confirmation to the responder (node B) with return code RC_ERR and consider the transaction failed. Then, when the responder gets a 6P Confirmation with return code RC_ERR, it MUST consider the transaction failed as well. 🫶
What happens after an error is out of scope for this document, bestie 🙈 The SF is the one that decides what to do after an error has occurred.
3.5. Security 🔐
6P messages MUST be secured through link-layer security. This works because 6P messages are carried as Payload IEs. 🔒
4. Requirements for 6top Scheduling Function (SF) Specifications 📋
4.1. SF Identifier (SFID) 🆔
Each SF has a 1-byte identifier. Section 6.2.5 defines the rules for applying for an SFID. ✨
4.2. Requirements for an SF Specification 📝
The specification for an SF:
- MUST specify an identifier for that SF.
- MUST specify the rule for a node to decide when to add/delete one or more cells to/on a neighbor.
- MUST specify the rule for a transaction source to select cells to add to the CellList field in the 6P ADD Request.
- MUST specify the rule for a transaction destination to select cells from the CellList to add to its schedule.
- MUST specify a value for the 6P Timeout or a rule/equation to calculate it.
- MUST specify the rule for ordering cells.
- MUST specify a meaning for the Metadata field in the 6P ADD Request.
- MUST specify the SF behavior of a node when it boots.
- MUST specify how to handle a schedule inconsistency.
- MUST specify what to do after an error has occurred (the node either sent a 6P Response with an error code or received one).
- MUST specify the list of statistics to gather. Example statistics include the number of transmitted frames to each neighbor. If the SF does not require that statistics be gathered, the SF specification MUST explicitly say so.
- SHOULD clearly state the application domain the SF is created for.
- SHOULD contain examples that highlight normal and error scenarios.
- SHOULD contain a list of current implementations, at least during the Internet-Draft (I-D) state of the document, per [RFC7942].
- SHOULD contain a performance evaluation of the scheme, possibly through references to external documents.
- SHOULD define the format of the SIGNAL command payload and its use.
- MAY redefine the format of the CellList field.
- MAY redefine the format of the CellOptions field.
- MAY redefine the meaning of the CellOptions field.
5. Security Considerations 🚨
okay bestie, this part is SERIOUS 😤 6P messages are carried inside 802.15.4 Payload Information Elements (IEs). Those Payload IEs are encrypted and authenticated at the link layer through CCM* [CCM-Star] ("CCM" stands for "Cipher block Chaining -- Message authentication code"). So 6P gets the same level of security as any other Payload IE. 🛡️ 6P does not define its own security mechanisms. Key management is out of scope for this document, but 6P will benefit from whatever key management solution the network uses. This matters a lot, because forgery and misattribution attacks get way more damaging when a single key is shared amongst a group of more than two participants. 😬
6P does not provide protection against DoS attacks. ⚠️ Example attacks include not sending confirmation messages in 3-step transactions and sending incorrectly formatted requests. These cases SHOULD be handled by an appropriate policy, such as rate-limiting or time-limited blacklisting of the attacker after several attempts. The effect on the overall network is mostly localized to the two nodes in question, as communication happens in dedicated cells.
6. IANA Considerations 📚
6.1. IETF IE Subtype 6P 🏷️
This document adds the following number to the "IEEE Std 802.15.4 IETF IE Subtype IDs" registry defined by [RFC8137]:
+--------+------------+-----------+
| Value | Subtype ID | Reference |
+--------+------------+-----------+
| 1 | SUBID_6TOP | RFC 8480 |
+---------------------+-----------+
Figure 34: IETF IE Subtype SUBID_6TOP6.2. 6TiSCH Parameters Subregistries 🗂️
This section defines subregistries within the "IPv6 Over the TSCH Mode of IEEE 802.15.4e (6TiSCH)" parameters registry, hereafter referred to as the "6TiSCH parameters" registry. Each subregistry gets its own subsection. 💖
6.2.1. 6P Version Numbers 🔢
The name of the subregistry is "6P Version Numbers".
The following note is included in this registry: "In the 6top Protocol (6P) [RFC8480], there is a field to identify the version of the protocol. This field is 4 bits in size."
Each entry in the subregistry must include the version in the range 0-15 and a reference to the 6P version's documentation.
The initial entry in this subregistry is as follows:
+---------+-----------+
| Version | Reference |
+---------+-----------+
| 0 | RFC 8480 |
+---------+-----------+
Figure 35: 6P Version Number EntryAll other version numbers are Unassigned. 🤷♀️
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126]. 📮
6.2.2. 6P Message Types 📨
The name of the subregistry is "6P Message Types".
The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a field to identify the type of message. This field is 2 bits in size."
Each entry in the subregistry must include the message type in the range b00-b11, the corresponding name, and a reference to the 6P message type's documentation.
Initial entries in this subregistry are as follows:
+------+--------------+-----------+
| Type | Name | Reference |
+------+--------------+-----------+
| b00 | REQUEST | RFC 8480 |
| b01 | RESPONSE | RFC 8480 |
| b10 | CONFIRMATION | RFC 8480 |
+------+--------------+-----------+
Figure 36: 6P Message TypesAll other message types are Unassigned. 🌸
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126]. 📮
6.2.3. 6P Command Identifiers 🎯
The name of the subregistry is "6P Command Identifiers".
The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in size. In a 6P Request, the value of this Code field is used to identify the command."
Each entry in the subregistry must include an identifier in the range 0-255, the corresponding name, and a reference to the 6P command identifier's documentation.
Initial entries in this subregistry are as follows:
+------------+------------+-----------+
| Identifier | Name | Reference |
+------------+------------+-----------+
| 0 | Reserved | RFC 8480 |
| 1 | ADD | RFC 8480 |
| 2 | DELETE | RFC 8480 |
| 3 | RELOCATE | RFC 8480 |
| 4 | COUNT | RFC 8480 |
| 5 | LIST | RFC 8480 |
| 6 | SIGNAL | RFC 8480 |
| 7 | CLEAR | RFC 8480 |
| 8-254 | Unassigned | |
| 255 | Reserved | RFC 8480 |
+------------+------------+-----------+
Figure 37: 6P Command IdentifiersThe IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126]. 📮
6.2.4. 6P Return Codes 🚦
The name of the subregistry is "6P Return Codes".
The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in size. In a 6P Response or 6P Confirmation, the value of this Code field is used to identify the return code."
Each entry in the subregistry must include a return code in the range 0-255, the corresponding name, the corresponding description, and a reference to the 6P return code's documentation. If the return code corresponds to a Response error, the "Is Error?" entry must indicate "Yes". Otherwise, "No" must be used.
Initial entries in this subregistry are as follows:
+------+-----------------+---------------------------+-----------+
| Code | Name | Description | Is Error? |
+------+-----------------+---------------------------+-----------+
| 0 | RC_SUCCESS | operation succeeded | No |
| 1 | RC_EOL | end of list | No |
| 2 | RC_ERR | generic error | Yes |
| 3 | RC_RESET | critical error, reset | Yes |
| 4 | RC_ERR_VERSION | unsupported 6P version | Yes |
| 5 | RC_ERR_SFID | unsupported SFID | Yes |
| 6 | RC_ERR_SEQNUM | schedule inconsistency | Yes |
| 7 | RC_ERR_CELLLIST | cellList error | Yes |
| 8 | RC_ERR_BUSY | busy | Yes |
| 9 | RC_ERR_LOCKED | cells are locked | Yes |
+------+-----------------+---------------------------+-----------+
Figure 38: 6P Return CodesAll other message types are Unassigned. 🌈
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126]. 📮
6.2.5. 6P Scheduling Function Identifiers ✨
okay bestie, this subregistry is called "6P Scheduling Function Identifiers" 💖
The note on it says: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a field to identify the Scheduling Function to handle the message. This field is 8 bits in size." 🎀
Every entry needs an SFID in the range 0-255, a name, and a reference to the 6P Scheduling Function's documentation. The entry also has to follow the rules for whatever that documentation says 🫶
There are currently no entries in this subregistry 🥺
+------+---------------------------------+--------------------------+
| SFID | Name | Reference |
+------+---------------------------------+--------------------------+
| 0-255| Unassigned | |
+------+---------------------------------+--------------------------+Figure 39: SF Identifier (SFID) Entry
All message types are Unassigned 🦋
The IANA policy for future additions depends on the SFID value. These specifications must follow the guidelines of Section 4. Basically the lower half and the upper half of the range get different treatment, and I'm obsessed with how neat that is 💅
+-----------+------------------------------+
| Range | Registration Procedures |
+-----------+------------------------------+
| 0-127 | IETF Review or IESG Approval |
| 128-255 | Expert Review |
+-----------+------------------------------+Figure 40: SF Identifier (SFID): Registration Procedure
6.2.6. 6P CellOptions Bitmap ✨
the name of this subregistry is "6P CellOptions Bitmap" 🌸
The note says: "In version 0 of the 6top Protocol (6P) [RFC8480], there is an optional CellOptions field that is 8 bits in size." So it's giving tiny little byte energy 🍓
Each entry needs a bit position in the range 0-7, a name, and a reference to that bit's documentation. The entry must include all three, no skipping 🧚
The initial entries look like this:
+-----+---------------+-----------+
| bit | Name | Reference |
+-----+---------------+-----------+
| 0 | TX (Transmit) | RFC 8480 |
| 1 | RX (Receive) | RFC 8480 |
| 2 | SHARED | RFC 8480 |
| 3-7 | Reserved | |
+-----+---------------+-----------+Figure 41: 6P CellOptions Bitmap
All other message types are Unassigned 💜
For future additions, the IANA policy is "IETF Review" or "IESG Approval" as described in [RFC8126]. Iconic, honestly 👑
7. References 📚
7.1. Normative References
[IEEE802154]IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4, DOI10.1109/IEEESTD.2016.7460875.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI10.17487/RFC2119, March 1997,<https://www.rfc-editor.org/info/rfc2119>.[RFC8137]Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information Element for the IETF", RFC 8137, DOI10.17487/RFC8137, May 2017,<https://www.rfc-editor.org/info/rfc8137>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI10.17487/RFC8174, May 2017,<https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[CCM-Star]Struik, R., "Formal Specification of the CCM* Mode of Operation", IEEE P802.15-4/0537r2, September 2005.[RFC7554]Watteyne, T., Ed., 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, DOI10.17487/RFC7554, May 2015,<https://www.rfc-editor.org/info/rfc7554>.[RFC7942]Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI10.17487/RFC7942, July 2016,<https://www.rfc-editor.org/info/rfc7942>.[RFC8126]Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI10.17487/RFC8126, June 2017,<https://www.rfc-editor.org/info/rfc8126>.[RFC8180]Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI10.17487/RFC8180, May 2017,<https://www.rfc-editor.org/info/rfc8180>.
Appendix A. Recommended Structure of an SF Specification 🧩
The following section structure for an SF document is RECOMMENDED, so this is your cheat sheet for writing one:
- Introduction
- RFC 2119 Requirements Language (if applicable)
- Scheduling Function Identifier
- Rules for Adding/Deleting Cells
- Rules for CellList
- 6P Timeout Value
- Rule for Ordering Cells
- Meaning of the Metadata Field
- Node Behavior at Boot
- Schedule Inconsistency Handling
- 6P Error Handling
- Examples
- Implementation Status
- Security Considerations
- IANA Considerations
- Normative References (if applicable)
- Informative References (if applicable)
Authors' Addresses 💌
Qin Wang (editor)
Univ. of Sci. and Tech. Beijing
30 Xueyuan Road
Beijing, Hebei 100083
China
Email: wangqin@ies.ustb.edu.cn
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
Barcelona, Catalonia 08018
Spain
Email: xvilajosana@uoc.edu
Thomas Watteyne
Analog Devices
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
United States of America
Email: thomas.watteyne@analog.comThat's the whole spec, bestie! 🌈🦋 Thanks for hanging in there with me 🫶
📦 where this page comes from
- ietf: rfc8480 2018-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms