RFC 8180
Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration
Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration 🎀
okay bestie, this is RFC 8180, and it's a Best Current Practice (BCP 210 🌸). It's from the IETF, published in May 2017, and the ISSN is 2070-1721. The main editor is X. Vilajosana, Ed. from the Universitat Oberta de Catalunya, with K. Pister from the University of California Berkeley and T. Watteyne from Analog Devices. 🧚 The header doesn't list anything it obsoletes or updates.
Abstract ✨
so the abstract is basically a pitch: this doc describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network 🦋. It lays out the baseline set of protocols that need to be supported, plus the recommended configurations and modes of operation needed to get a 6TiSCH network actually working. 6TiSCH gives you IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh made of IEEE Std 802.15.4 TSCH links. The minimal mode uses a set of protocols with their configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, so you get interoperable IPv6 over IEEE Std 802.15.4 TSCH. 💅
It also says the minimal config gives enough bandwidth for network and security bootstrapping, and it defines the proper link between the IETF protocols that interface with IEEE Std 802.15.4 TSCH. And the big one: this minimal mode should be implemented by all 6TiSCH-compliant devices. 👑
Status of This Memo 🌈
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force (IETF). 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). More info on BCPs is in Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc8180.
Copyright Notice 💜
Copyright (c) 2017 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) as in effect on the date this document was published. Please read these documents carefully, because 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 they're provided without warranty as described in the Simplified BSD License. 🫶
Table of Contents 🦋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IEEE Std 802.15.4 Settings . . . . . . . . . . . . . . . . . 5
4.1. TSCH Schedule . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 8
4.4. Timeslot Timing . . . . . . . . . . . . . . . . . . . . . 8
4.5. Frame Contents . . . . . . . . . . . . . . . . . . . . . 8
4.5.1. IEEE Std 802.15.4 Header . . . . . . . . . . . . . . 8
4.5.2. Enhanced Beacon Frame . . . . . . . . . . . . . . . . 9
4.5.3. Acknowledgment Frame . . . . . . . . . . . . . . . . 10
4.6. Link-Layer Security . . . . . . . . . . . . . . . . . . . 10
5. RPL Settings . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Objective Function . . . . . . . . . . . . . . . . . . . 11
5.1.1. Rank Computation . . . . . . . . . . . . . . . . . . 11
5.1.2. Rank Computation Example . . . . . . . . . . . . . . 13
5.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 14
5.3. Trickle Timer . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Packet Contents . . . . . . . . . . . . . . . . . . . . . 14
6. Network Formation and Lifetime . . . . . . . . . . . . . . . 14
6.1. Value of the Join Metric Field . . . . . . . . . . . . . 14
6.2. Time-Source Neighbor Selection . . . . . . . . . . . . . 15
6.3. When to Start Sending EBs . . . . . . . . . . . . . . . . 15
6.4. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 15
7. Implementation Recommendations . . . . . . . . . . . . . . . 16
7.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 16
7.2. Queues and Priorities . . . . . . . . . . . . . . . . . . 16
7.3. Recommended Settings . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23
A.1. Example: EB with Default Timeslot Template . . . . . . . 23
A.2. Example: EB with Custom Timeslot Template . . . . . . . . 25
A.3. Example: Link-layer Acknowledgment . . . . . . . . . . . 27
A.4. Example: Auxiliary Security Header . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 281. Introduction 🌸
so a 6TiSCH network gives you IPv6 connectivity [RFC2460] over a Time-Slotted Channel Hopping (TSCH) mesh [RFC7554] made of IEEE Std 802.15.4 TSCH links [IEEE.802.15.4]. To get IPv6 working, it uses the 6LoWPAN framework ([RFC4944], [RFC6282], [RFC8025],[RFC8138], and [RFC6775]), RPL [RFC6550], and the RPL Objective Function 0 (OF0) [RFC6552]. ✨
This spec defines the operational parameters and procedures for a minimal mode of operation to build a 6TiSCH network. Any 6TiSCH-compliant device should implement this mode. This configuration gives nodes the bandwidth they need to bootstrap the network, and that bootstrap process covers both initial network configuration and security bootstrapping. Here, the 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and the RPL Objective Function 0 (OF0) [RFC6552] are all used unmodified. The TSCH parameters and particular operations are specified so that nodes in a 6TiSCH network can interoperate. 🦋
In a 6TiSCH network, nodes follow a communication schedule as per 802.15.4 TSCH. Nodes learn that schedule when they join the network. When you follow this spec, the learned schedule is the same for all nodes and doesn't change over time. Future specs may define mechanisms for dynamically managing the communication schedule, but dynamic scheduling solutions are out of scope for this document. 🧚
IPv6 addressing and compression are handled by the 6LoWPAN framework. That framework includes [RFC4944], [RFC6282], [RFC8025], the 6LoWPAN Routing Header dispatch [RFC8138] for addressing and header compression, and [RFC6775] for Duplicate Address Detection (DAD) and address resolution. 💖
More advanced work is expected later to add dynamic operations that can adapt the schedule to the traffic's needs at run time. Ooo, can't wait. 👑
2. 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. ⭐
3. Terminology 🎀
this doc uses terminology from [TERMS-6TiSCH]. These are the concepts it uses:
- 802.15.4: we say "802.15.4" as a short version of "IEEE Std 802.15.4" in this document.
- SFD: Start of Frame Delimiter
- RX: Reception
- TX: Transmission
- IE: Information Element
- EB: Enhanced Beacon
- ASN: Absolute Slot Number
- Join Metric: Field in the TSCH Synchronization IE representing the topological distance between the node sending the EB and the PAN coordinator.
- PAN: Personal Area Network
- MLME: MAC Layer Management Entity
4. IEEE Std 802.15.4 Settings ✨
okay bestie, first things first: any implementation that's compliant with this spec MUST implement IEEE Std 802.15.4 [IEEE.802.15.4] in Time-Slotted Channel Hopping (TSCH) mode 🫶
the rest of this section goes through the RECOMMENDED TSCH settings. they're all summarized in Figure 1 💅 any property marked in the EB column gets announced in the EBs that nodes send [IEEE.802.15.4], and joining nodes learn it from there. so if you change one of those values, you're changing what's in the EB 👀
and if the values here ever disagree with IEEE Std 802.15.4 [IEEE.802.15.4], the IEEE standard wins. no debate 👑
+--------------------------------+------------------------------+---+
| Property | Recommended Setting |EB*|
+--------------------------------+------------------------------+---+
| Slotframe Size | Tunable. Trades off | X |
| | bandwidth against energy. | |
+--------------------------------+------------------------------+---+
| Number of scheduled cells** | 1 | X |
| (active) | Timeslot 0x0000 | |
| | Channel Offset 0x0000 | |
| | Link Options = (TX Link = 1, | |
| | RX Link = 1, Shared Link = 1,| |
| | Timekeeping = 1) | |
+--------------------------------+------------------------------+---+
| Number of unscheduled cells | All remaining cells in the | X |
| (off) | slotframe. | |
+--------------------------------+------------------------------+---+
| Max Number MAC retransmissions | 3 (4 transmission attempts) | |
+--------------------------------+------------------------------+---+
| Timeslot template | IEEE Std 802.15.4 default | X |
| | (macTimeslotTemplateId=0) | |
+--------------------------------+------------------------------+---+
| Enhanced Beacon Period | Tunable. Trades off join | |
| (EB_PERIOD) | time against energy. | |
+--------------------------------+------------------------------+---+
| Number used frequencies | IEEE Std 802.15.4 default | X |
| (2.4 GHz O-QPSK PHY) | (16) | |
+--------------------------------+------------------------------+---+
| Channel Hopping sequence | IEEE Std 802.15.4 default | X |
| (2.4 GHz O-QPSK PHY) | (macHoppingSequenceID = 0) | |
+--------------------------------+------------------------------+---+
* An "X" in this column means this property's value is announced
in the EB; hence, a new node learns it when joining.
** This cell LinkType is set to ADVERTISING.
Figure 1: Recommended IEEE Std 802.15.4 TSCH Settings4.1. TSCH Schedule 🌸
this minimal mode runs on a single slotframe. the slotframe is made of a tunable number of timeslots, and the slotframe size (how many timeslots it has) is a trade-off between bandwidth and energy 🔋 you need to tune it, but how you tune it is out of scope for this spec. the slotframe size gets announced in the EB 📢 the RECOMMENDED value for the slotframe handle (macSlotframeHandle) is 0x00. an implementation MAY pick a different slotframe handle, say, to add other slotframes with higher priority. using other slotframes is out of scope for this doc 🙈
there's only one scheduled cell in the slotframe. that cell MAY sit at any slotOffset/channelOffset inside the slotframe. its location in the schedule gets announced in the EB, and its LinkType is ADVERTISING so EBs can go out on it 🦋
Figure 2 shows an example slotframe that's 101 timeslots long, which gives you a radio duty cycle below 0.99% 🍓
Chan. +----------+----------+ +----------+
Off.0 | TxRxS/EB | OFF | | OFF |
Chan. +----------+----------+ +----------+
Off.1 | OFF | OFF | ... | OFF |
+----------+----------+ +----------+
.
.
.
Chan. +----------+----------+ +----------+
Off.15 | OFF | OFF | | OFF |
+----------+----------+ +----------+
slotOffset 0 1 100
EB: Enhanced Beacon
Tx: Transmit
Rx: Receive
S: Shared
OFF: Unscheduled by this specification
Figure 2: Example Slotframe of Length 101 Timeslotsa node MAY use the scheduled cell to transmit and receive every type of link-layer frame ✨ EBs go to the link-layer broadcast address and nobody acknowledges them. data frames are sent unicast and the receiving neighbor acknowledges them 💌
every other cell in the slotframe is unscheduled. dynamic scheduling solutions might be defined later to schedule those cells, and one example is the 6top Protocol (6P) [PROTO-6P]. dynamic scheduling is out of scope for this document, though 🧚
the default values of the TSCH timeslot template (defined in Section 8.4.2.2.3 of [IEEE.802.15.4]) and the channel hopping sequence (defined in Section 6.2.10 of [IEEE.802.15.4]) SHOULD be used. a node MAY use different values, as long as it properly announces them in its EB 🎀
4.2. Cell Options 💜
in the scheduled cell, a node transmits when it has a packet to send, and listens otherwise. that's why both the "TX" and "RX" bits are set 🔁 when a node transmits and asks for a link-layer acknowledgment per [IEEE.802.15.4] but doesn't get one, it runs a back-off mechanism to sort out possible collisions. that's the "Shared" bit 🤝 and a node that's joining the network keeps its time synchronized to its initial time-source neighbor using that cell. that's the "Timekeeping" bit ⏰
here's what that turns into as a Link Option for this cell:
b0 = TX Link = 1 (set)
b1 = RX Link = 1 (set)
b2 = Shared Link = 1 (set)
b3 = Timekeeping = 1 (set)
b4 = Priority = 0 (clear)
b5-b7 = Reserved = 0 (clear)4.3. Retransmissions 🔄
per Figure 1, the RECOMMENDED maximum number of link-layer retransmissions is 3. so for packets that need an acknowledgment, if none comes back after a total of 4 attempts, the transmission counts as failed and the link layer MUST notify the upper layer 😤 packets that don't need an acknowledgment (EBs included) don't get retransmitted at all 🙅♀️
4.4. Timeslot Timing ⏱️
per Figure 1, the RECOMMENDED timeslot template is the default one (macTimeslotTemplateId=0) defined in [IEEE.802.15.4] 💖
4.5. Frame Contents 🧁
[IEEE.802.15.4] defines the format of frames. it uses a set of flags to decide which fields are present, how long they are, and what values they hold 🌈 this spec goes into the RECOMMENDED contents of 802.15.4 frames, and it still strictly complies with [IEEE.802.15.4] 🫶
4.5.1. IEEE Std 802.15.4 Header 📬
the Frame Version field MUST be set to 0b10 (Frame Version 2). the Sequence Number field MAY be elided 🫣
the EB Destination Address field MUST be set to 0xFFFF (short broadcast address). the EB Source Address field SHOULD be set to the node's short address if that's supported. otherwise, the long address MUST be used 📮
the PAN ID Compression bit SHOULD indicate that the Source PAN ID is "Not Present" and the Destination PAN ID is "Present". the value of the PAN ID Compression bit is specified in Table 7-2 of the IEEE Std 802.15.4-2015 specification, and it depends on the type of the destination and source link-layer addresses (short, extended, not present, and so on) 🧩
nodes follow the reception and rejection rules in Section 6.7.2 of [IEEE.802.15.4] 🚦
the nonce is formatted according to [IEEE.802.15.4]. in the IEEE Std 802.15.4 spec [IEEE.802.15.4], nonce generation is described in Section 9.3.2.2, and byte ordering is described in Section 9.3.1, Annex B.2, and Annex B.2.2 📚
4.5.2. Enhanced Beacon Frame 📡
after booting, a TSCH node starts out unsynchronized and unjoined 🥺 it gets its initial synchronization by listening for EBs. it might hear EBs from multiple networks, and there are lots of ways to tell networks apart, but those details are out of scope 🫠
the IEEE Std 802.15.4 spec doesn't say how often EBs get sent or what they contain [IEEE.802.15.4] 🤷♀️ in a minimal TSCH configuration, a node SHOULD send an EB every EB_PERIOD. tuning EB_PERIOD is a trade-off between joining time and energy consumption ⚖️
EBs should be used to get info about local networks and to synchronize the ASN and time offset of the specific network the node decides to join 🔍 once a node has joined a network, it MAY keep listening for EBs to gather info about other networks, for example. during the joining process, and before secure connections to time parents exist, a node MAY keep itself synchronized using EBs. [RFC7554] talks about different time synchronization approaches 🕰️
the IEEE Std 802.15.4 spec requires EBs to be sent so that nodes can join the network 💌 the EBs SHOULD carry the Information Elements (IEs) listed below [IEEE.802.15.4] 🎁
TSCH Synchronization IE: contains synchronization info like the ASN and Join Metric. the value of the Join Metric field is discussed in Section 6.1 📏
TSCH Timeslot IE: contains the timeslot template identifier. the template is used to specify the internal timing of the timeslot. this spec recommends the default timeslot template 🕒
Channel Hopping IE: contains the channel hopping sequence identifier. this spec recommends the default channel hopping sequence 🦋
TSCH Slotframe and Link IE: lets joining nodes learn the initial schedule they'll use as they join the network 🗓️ this doc recommends using a single cell 💅
if a node strictly follows the recommended settings from Figure 1, the EB it sends has the exact same contents as the EB it received when joining, except for the Join Metric field in the TSCH Synchronization IE ✨
when a node has already joined a network (meaning it received an EB, synchronized to the EB sender, and configured its schedule following this spec), the node SHOULD ignore later EBs that try to change the configured parameters 🛑 this doesn't stop it from listening to EBs from other networks, though 👀
4.5.3. Acknowledgment Frame 🫧
per [IEEE.802.15.4], every acknowledgment contains an ACK/NACK Time Correction IE 💖
4.6. Link-Layer Security 🔐
okay so, when you secure link-layer frames, they MUST be secured with the link-layer security mechanisms from IEEE Std 802.15.4 [IEEE.802.15.4]. Link-layer authentication MUST be applied to the entire frame, including the 802.15.4 header. Link-layer encryption MAY be applied to the 802.15.4 Payload IEs and the 802.15.4 payload. the vibe is "authenticate everything, encrypt the juicy bits if you want" 💜
This spec assumes there are two cryptographic keys floating around:
- Key K1 is used to authenticate EBs. EBs MUST be authenticated only (no encryption), and their contents are defined in Section 4.5.2.
- Key K2 is used to authenticate and encrypt DATA and ACKNOWLEDGMENT frames.
These keys can be pre-configured or learned during a key distribution phase. Key distribution mechanisms are defined, for example, in [SEC-6TISCH] and [SEC-JOIN-6TISCH]. Key distribution is out of scope for this document, so we're not going there today 🙈
How a Joining Node (JN) behaves depends on which key(s) are pre-configured:
- If both keys K1 and K2 are pre-configured, the JN does not rely on a key distribution phase to learn K1 or K2. easy mode ✨
- If key K1 is pre-configured but not key K2, the JN authenticates EBs using K1 and relies on the key distribution phase to learn K2.
- If neither key K1 nor key K2 is pre-configured, the JN accepts EBs as defined in Section 6.3.1.2 of IEEE Std 802.15.4 [IEEE.802.15.4]. That means they get passed forward even "if the status of the unsecuring process indicated an error". The JN then runs the key distribution phase to learn K1 and K2. During that process, the node that the JN is talking to uses the secExempt mechanism (see Section 9.2.4 of [IEEE.802.15.4]) to process frames from the JN. Once the key distribution phase is done, the node that has installed secExempts for the JN MUST clear the installed exception rules. cleanup crew, this part's on you 🧹
In the event of a network reset, the new network MUST either use new cryptographic keys or ensure that the ASN remains monotonically increasing. no recycling old keys after a reset, bestie, that's a whole vibe-killer 💀
5. RPL Settings 🌿
In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used.
5.1. Objective Function 🎯
If RPL is used, nodes MUST implement the RPL Objective Function Zero (OF0) [RFC6552].
5.1.1. Rank Computation
The Rank computation is described in Section 4.1 of [RFC6552]. A node's Rank (see Figure 4 for an example) is computed with these equations:
R(N) = R(P) + rank_increment
rank_increment = (Rf*Sp + Sr) * MinHopRankIncreaseFigure 3 lists the OF0 parameter values that MUST be used if RPL is used.
+----------------------+-------------------------------------+
| OF0 Parameters | Value |
+----------------------+-------------------------------------+
| Rf | 1 |
+----------------------+-------------------------------------+
| Sp | (3*ETX)-2 |
+----------------------+-------------------------------------+
| Sr | 0 |
+----------------------+-------------------------------------+
| MinHopRankIncrease | DEFAULT_MIN_HOP_RANK_INCREASE (256) |
+----------------------+-------------------------------------+
| MINIMUM_STEP_OF_RANK | 1 |
+----------------------+-------------------------------------+
| MAXIMUM_STEP_OF_RANK | 9 |
+----------------------+-------------------------------------+
| ETX limit to select | 3 |
| a parent | |
+----------------------+-------------------------------------+
Figure 3: OF0 ParametersThe step_of_rank (Sp) uses the Expected Transmission Count (ETX) [RFC6551].
An implementation MUST follow OF0's normalization guidance, as discussed in Sections 1 and 4.1 of [RFC6552]. Sp SHOULD be calculated as (3*ETX)-2. The minimum value of Sp (MINIMUM_STEP_OF_RANK) indicates a good quality link. The maximum value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor quality link. The default value of Sp (DEFAULT_STEP_OF_RANK) indicates an average quality link. Candidate parents with ETX greater than 3 SHOULD NOT be selected. This avoids having ETX values on used links that are larger than the maximum allowed transmission attempts. ETX above 3 is a no-go, bestie 🚫
5.1.2. Rank Computation Example
This section shows how OF0 works (see Figure 4). We have:
rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512 +-------+
| 0 | R(minHopRankIncrease) = 256
| | DAGRank(R(0)) = 1
+-------+
|
|
+-------+
| 1 | R(1)=R(0) + 512 = 768
| | DAGRank(R(1)) = 3
+-------+
|
|
+-------+
| 2 | R(2)=R(1) + 512 = 1280
| | DAGRank(R(2)) = 5
+-------+
|
|
+-------+
| 3 | R(3)=R(2) + 512 = 1792
| | DAGRank(R(3)) = 7
+-------+
|
|
+-------+
| 4 | R(4)=R(3) + 512 = 2304
| | DAGRank(R(4)) = 9
+-------+
|
|
+-------+
| 5 | R(5)=R(4) + 512 = 2816
| | DAGRank(R(5)) = 11
+-------+
Figure 4: Rank computation example for a 5-hop network where
numTx=100 and numTxAck=75 for all links.5.2. Mode of Operation 🧭
When RPL is used, nodes MUST implement the non-storing mode of operation (see Section 9.7 of [RFC6550]). The storing mode of operation (see Section 9.8 of [RFC6550]) SHOULD be implemented by nodes with enough capabilities. Nodes not implementing RPL MUST join as leaf nodes. leaf life is still a life 🍃
5.3. Trickle Timer ⏲️
RPL signaling messages such as DODAG Information Objects (DIOs) are sent using the Trickle algorithm (see Section 8.3.1 of [RFC6550] and Section 4.2 of [RFC6206]). For this specification, the Trickle timer MUST be used with the RPL-defined default values (see Section 8.3.1 of [RFC6550]).
5.4. Packet Contents 📦
RPL information and hop-by-hop extension headers MUST follow [RFC6553] and [RFC6554]. For cases in which the packets formed at the Low-Power and Lossy Network (LLN) need to cross through intermediate routers, these MUST follow the IP-in-IP encapsulation requirement specified by [RFC6282] and [RFC2460]. Routing extension headers such as RPL Packet Information (RPI) [RFC6550] and Source Routing Header (SRH) [RFC6554], and outer IP headers in case of encapsulation, MUST be compressed according to [RFC8138] and [RFC8025]. compression is the main character here 💖
6. Network Formation and Lifetime 🌸
6.1. Value of the Join Metric Field 🔢
The Join Metric of the TSCH Synchronization IE in the EB MUST be calculated based on the routing metric of the node, normalized to a value between 0 and 255. A lower value of the Join Metric means the node sending the EB is topologically "closer" to the root of the network. So a lower Join Metric means a joining node should be more likely to sync to that neighbor ✨
In case the network uses RPL, the Join Metric of any node (including the Directed Acyclic Graph (DAG) root) MUST be set to DAGRank(rank)-1. According to Section 5.1.1, DAGRank(rank(0)) = 1. DAGRank(rank(0))-1 = 0 is compliant with 802.15.4's requirement of having the root use Join Metric = 0. the root gets the lowest number, iykyk 👑
In case the network does not use RPL, the Join Metric value MUST follow the rules specified by [IEEE.802.15.4].
6.2. Time-Source Neighbor Selection ⏰
When a node joins a network, it may hear EBs sent by different nodes already in the network. Which neighbor to sync to (for example, which neighbor becomes the node's initial time-source neighbor) is implementation specific. For example, after receiving the first EB, a node MAY listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors. Recommended values for MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5. When receiving EBs from distinct neighbors, the node MAY use the Join Metric field in each EB to select the initial time-source neighbor, as described in Section 6.3.6 of IEEE Std 802.15.4 [IEEE.802.15.4].
At any time, a node MUST maintain synchronization to at least one time-source neighbor. A node's time-source neighbor MUST be chosen among the neighbors in its RPL routing parent set when RPL is used. If a node cannot maintain connectivity to at least one time-source neighbor, it loses synchronization and needs to join the network again. no time-source, no stay, periodt 😭
6.3. When to Start Sending EBs 📡
When a RPL node joins the network, it MUST NOT send EBs before it has acquired a RPL Rank, so the time synchronization structure stays consistent. This applies to other routing protocols with their corresponding routing metrics. As soon as a node acquires routing information (e.g., a RPL Rank, see Section 5.1.1), it SHOULD start sending EBs. wait for your rank, then glow up ✨
6.4. Hysteresis 🎢
Per [RFC6552] and [RFC6719], the specification recommends the use of a boundary value (PARENT_SWITCH_THRESHOLD) to avoid constant parent changes when ranks are compared. When evaluating a parent whose path cost is smaller than the current minimum path, the candidate node is only selected as the new parent if the difference between the new path and the current path is greater than the defined PARENT_SWITCH_THRESHOLD. Otherwise, the node MAY continue to use the current preferred parent. Per [RFC6719], PARENT_SWITCH_THRESHOLD SHOULD be set to 192 when the ETX metric is used (in the form 128*ETX). The recommendation for this document is to use PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is ((3*ETX)-2)*minHopRankIncrease or a proportional value. This handles hysteresis for both routing parent and time-source neighbor selection. no more parent-hopping drama, we're stable now 🦋
7. Implementation Recommendations 🛠️
7.1. Neighbor Table 🗂️
The exact format of the neighbor table is implementation specific. The RECOMMENDED per-neighbor information is (taken from the [openwsn] implementation):
identifier: Identifier(s) of the neighbor (e.g., EUI-64).numTx: Number of link-layer transmission attempts to that neighbor.numTxAck: Number of transmitted link-layer frames that have been link-layer acknowledged by that neighbor.numRx: Number of link-layer frames received from that neighbor.timestamp: When the last frame was received from that neighbor. This can be based on the ASN counter or any other time base. It can be used to trigger a keep-alive message.routing metric: The RPL Rank of that neighbor, for example.time-source neighbor: A flag indicating whether this neighbor is a time-source neighbor.
this table is basically the neighbor's report card 💜
7.2. Queues and Priorities ✨
okay so the IEEE 802.15.4 spec [IEEE.802.15.4] doesn't actually define queues for handling upper-layer data (app data or control data from the layers above). so this part is kinda on us 💅 the following rules are RECOMMENDED:
- A node is configured to keep in the queues a configurable number of upper-layer packets per link (default NUM_UPPERLAYER_PACKETS) for a configurable time that should cover the join process (default MAX_JOIN_TIME).
- Frames generated by the 802.15.4 layer (including EBs) are queued with a priority higher than frames coming from higher layers.
- A frame type BEACON is queued with higher priority than frame types DATA.
7.3. Recommended Settings 🎀
here's the RECOMMENDED values for all the settings we've talked about in this spec 🫶 check out Figure 5:
+-------------------------+-------------------+
| Parameter | RECOMMENDED Value |
+-------------------------+-------------------+
| MAX_EB_DELAY | 180 |
+-------------------------+-------------------+
| NUM_NEIGHBOURS_TO_WAIT | 2 |
+-------------------------+-------------------+
| PARENT_SWITCH_THRESHOLD | 640 |
+-------------------------+-------------------+
| NUM_UPPERLAYER_PACKETS | 1 |
+-------------------------+-------------------+
| MAX_JOIN_TIME | 300 |
+-------------------------+-------------------+
Figure 5: Recommended Settings- Security Considerations 🔥🔥
bestie, this one is serious, so pay attention 😭 this doc is only concerned with link-layer security.
IoT networks are literally out here with nodes in physically vulnerable spots 💀 we should assume nodes WILL get physically compromised, their memories examined, and their keys extracted. fixed secrets will not stay secret. this messes with the node-joining process. provisioning a network with a fixed link key K2 is not secure ❌ for most apps, that means there will be a joining phase where some level of authorization is allowed for nodes that haven't been authenticated. the details are out of scope, but the link layer has to offer some flexibility here.
if an attacker has obtained K1, they can generate fake EBs to attack a whole network by sending authenticated EBs. they can make the joining node start the joining process to the attacker. if the joining process includes authentication and distribution of a K2, the joining process will fail and the JN will notice the attack. but if K2 is also compromised, the JN won't notice and the network will be compromised 😱
even if an attacker doesn't know K1 and K2 (Section 4.6), they can still generate fake EB frames authenticated with an arbitrary key. here's the impact these fake EBs can have, depending on which key(s) are pre-provisioned:
- If both K1 and K2 are pre-provisioned, a joining node can tell legit EBs from fake ones and join the legit network. the fake EBs have no impact.
- The same holds if K1 is pre-provisioned but not K2.
- If neither K1 nor K2 is pre-provisioned, a joining node may mistake a fake EB for a legit one and start a joining process to the attacker. that joining process will fail, because the joining node can't authenticate the attacker during the security handshake. this forces the joining node to start over listening for an EB. so while the joining node never joins the attacker, it costs time and energy and is a vector of attack 🙃
choosing which key(s) to pre-provision needs to balance all the stuff above ⚖️
once the joining process is over, the node that has joined can authenticate EBs (it knows K1). so it can process their contents and use EBs for synchronization ✨
ASN provides a nonce for security operations in a slot. any re-use of ASN with a given key exposes info about encrypted packet contents and risks replay attacks 😬 replay attacks are prevented because, when the network resets, either the new network uses new cryptographic key(s) or ensures that the ASN increases monotonically (Section 4.6).
maintaining accurate time synchronization is critical for network operation 🕰️ accepting timing info from unsecured sources MUST be avoided during normal network operation, as described in Section 4.5.2. during joining, a node may be susceptible to timing attacks before keys K1 and K2 are learned. during network operation, a node MAY maintain statistics on time updates from neighbors and monitor for anomalies 👀
Denial-of-Service (DoS) attacks at the Media Access Control (MAC) layer in an LLN are super easy to pull off with just Radio Frequency (RF) jamming 📡 that's the base case that more sophisticated DoS attacks should be judged against. for example, sending fake EBs announcing a very low Join Metric may make a node waste time and energy trying to join a fake network even when legit EBs are being heard. proper join security will stop the node from joining the false flag, but by then the time and energy is already gone 😩 the energy cost to the attacker would be lower, and the energy cost to the joining node higher, if the attacker just sent loud short packets in the middle of any valid EB it hears 📢
ACK reception probability is less than 100% because of changing channel conditions and unintentional or intentional jamming 📉 this makes the sending node retransmit the same packet until it's acknowledged or a retransmission limit is reached. upper-layer protocols should take this into account, possibly using a sequence number to match retransmissions 🔢
the 6TiSCH layer SHOULD keep track of anomalous events and report them to a higher authority 🚨 for example, EBs reporting low Join Metrics for networks that can't be joined, as described above, may be a sign of attack. also, in normal network operation, message integrity check failures on packets with a valid Cyclic Redundancy Check (CRC) happen at a rate on the order of once per million packets. any significant deviation from that rate may be a sign of a network attack 👾 along the same lines, time updates in ACKs or EBs that don't match the MAC-layer's sense of time and its own plausible time-error drift rate may also be a result of network attack 🕵️♀️
- IANA Considerations 🧚
this document doesn't require any IANA actions, so no paperwork for us 🌈
- References 📚
10.1. Normative References 💜
[IEEE.802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks",
IEEE 802.15.4,
<http://ieeexplore.ieee.org/document/7460875/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012,
<http://www.rfc-editor.org/info/rfc6551>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012,
<http://www.rfc-editor.org/info/rfc6552>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012,
<http://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>.
[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with
Hysteresis Objective Function", RFC 6719,
DOI 10.17487/RFC6719, September 2012,
<http://www.rfc-editor.org/info/rfc6719>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016,
<http://www.rfc-editor.org/info/rfc8025>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <http://www.rfc-editor.org/info/rfc8138>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.10.2. Informative References 📚
- [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, Volume 23 Issue 5, pages 480-493, DOI 10.1002/ett.2558, August 2012.
- [PROTO-6P] Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol (6P)", Work in Progress, draft-ietf-6tisch-6top-protocol-05, May 2017.
- [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, DOI 10.17487/RFC7554, May 2015,
http://www.rfc-editor.org/info/rfc7554. - [SEC-6TISCH] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Minimal Security Framework for 6TiSCH", Work in Progress, draft-ietf-6tisch-minimal-security-02, March 2017.
- [SEC-JOIN-6TISCH] Richardson, M., "6tisch Secure Join protocol", Work in Progress, draft-ietf-6tisch-dtsecurity-secure-join-01, February 2017.
- [TERMS-6TiSCH] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Work in Progress, draft-ietf-6tisch-terminology-08, December 2016.
Appendix A. Examples 🧚
okay so this appendix is basically a little gallery of example packets 🖼️✨ each one comes with three things: a schematic header diagram, the matching bytestream, and a breakdown of every IE (information element) inside it. bestie, these packet formats are tied to the [IEEE.802.15.4] revision, and they might change in future releases of that standard. if the examples and [IEEE.802.15.4] ever disagree, the standard wins, no debate 💅
quick reading guide 🎀 every field gets drawn in the order it's sent, left to right, with the leftmost bit going out first. bits inside a field are numbered 0 (leftmost, least significant) up to k - 1 (rightmost, most significant), where k is the field's length in bits. and anything longer than one octet gets sent to the PHY starting with the octet holding the lowest-numbered bits, so it's little endian 🫶
A.1. Example: EB with Default Timeslot Template
the first one is an EB (Enhanced Beacon) that just uses the default timeslot template 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len3 = 6 |Sub ID = 0x1a|0| ASN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASN | Join Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the bytestream looks like this 👀
Bytestream:
00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00
01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0Fand here's the IE-by-IE breakdown, which is honestly so satisfying 🥹
Description of the IEs:
#Header IE Header
Len1 = Header IE Length (0)
Element ID = 0x7e - termination IE indicating Payload IE
coming next
Type 0
#Payload IE Header (MLME)
Len2 = Payload IE Len (26 bytes)
Group ID = 1 MLME (Nested)
Type = 1
#MLME-SubIE TSCH Synchronization
Len3 = Length in bytes of the sub-IE payload (6 bytes)
Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization)
Type = Short (0)
ASN = Absolute Sequence Number (5 bytes)
Join Metric = 1 byte
#MLME-SubIE TSCH Timeslot
Len4 = Length in bytes of the sub-IE payload (1 byte)
Sub-ID = 0x1c (MLME-SubIE Timeslot)
Type = Short (0)
Timeslot template ID = 0x00 (default)
#MLME-SubIE Channel Hopping
Len5 = Length in bytes of the sub-IE payload (1 byte)
Sub-ID = 0x09 (MLME-SubIE Channel Hopping)
Type = Long (1)
Hopping Sequence ID = 0x00 (default)
#MLME-SubIE TSCH Slotframe and Link
Len6 = Length in bytes of the sub-IE payload (10 bytes)
Sub-ID = 0x1b (MLME-SubIE TSCH Slotframe and Link)
Type = Short (0)
Number of slotframes = 0x01
Slotframe handle = 0x00
Slotframe size = 101 slots (0x65)
Number of Links (Cells) = 0x01
Timeslot = 0x0000 (2B)
Channel Offset = 0x0000 (2B)
Link Options = 0x0F
(TX Link = 1, RX Link = 1, Shared Link = 1,
Timekeeping = 1 )A.2. Example: EB with Custom Timeslot Template
this one swaps in a custom timeslot template, so the timeslot becomes 15 ms ⏱️💖
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len3 = 6 |Sub ID = 0x1a|0| ASN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASN | Join Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 2700 | macTsCCA = 128 | macTsTxOffset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 3180 | macTsRxOffset = 1680 | macTsRxAckDelay
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 1200 | macTsTxAckDelay = 1500 | macTsRxWait
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 3300 | macTsAckWait = 600 | macTsRxTx
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 192 | macTsMaxAck = 2400 | macTsMaxTx
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+bytestream time 🫧
Bytestream:
00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80
00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8
00 0A ...the IE breakdown, including the 15 ms timeslot table 🥰
Description of the IEs:
#Header IE Header
Len1 = Header IE Length (none)
Element ID = 0x7e - termination IE indicating Payload IE
coming next
Type 0
#Payload IE Header (MLME)
Len2 = Payload IE Len (53 bytes)
Group ID = 1 MLME (Nested)
Type = 1
#MLME-SubIE TSCH Synchronization
Len3 = Length in bytes of the sub-IE payload (6 bytes)
Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization)
Type = Short (0)
ASN = Absolute Sequence Number (5 bytes)
Join Metric = 1 byte
#MLME-SubIE TSCH Timeslot
Len4 = Length in bytes of the sub-IE payload (25 bytes)
Sub-ID = 0x1c (MLME-SubIE Timeslot)
Type = Short (0)
Timeslot template ID = 0x01 (non-default)
The 15 ms timeslot announced:
+--------------------------------+------------+
| IEEE 802.15.4 TSCH parameter | Value (us) |
+--------------------------------+------------+
| macTsCCAOffset | 2700 |
+--------------------------------+------------+
| macTsCCA | 128 |
+--------------------------------+------------+
| macTsTxOffset | 3180 |
+--------------------------------+------------+
| macTsRxOffset | 1680 |
+--------------------------------+------------+
| macTsRxAckDelay | 1200 |
+--------------------------------+------------+
| macTsTxAckDelay | 1500 |
+--------------------------------+------------+
| macTsRxWait | 3300 |
+--------------------------------+------------+
| macTsAckWait | 600 |
+--------------------------------+------------+
| macTsRxTx | 192 |
+--------------------------------+------------+
| macTsMaxAck | 2400 |
+--------------------------------+------------+
| macTsMaxTx | 4256 |
+--------------------------------+------------+
| macTsTimeslotLength | 15000 |
+--------------------------------+------------+
#MLME-SubIE Channel Hopping
Len5 = Length in bytes of the sub-IE payload. (1 byte)
Sub-ID = 0x09 (MLME-SubIE Channel Hopping)
Type = Long (1)
Hopping Sequence ID = 0x00 (default)A.3. Example: Link-layer Acknowledgment
enhanced Acknowledgment packets are the ones carrying the Time Correction IE, which lives in the Header IE section 💫
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len1 = 2 |Element ID=0x1e|0| Time Sync Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Bytestream:
02 0F TS#0 TS#1Description of the IEs:
#Header IE Header
Len1 = Header IE Length (2 bytes)
Element ID = 0x1e - ACK/NACK Time Correction IE
Type 0A.4. Example: Auxiliary Security Header
last one! 🔐 this is an 802.15.4 Auxiliary Security Header where the Security Level is set to ENC-MIC-32
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L = 5|M=1|1|1|0|Key Index = IDX|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Bytestream:
6D IDX#0Security Auxiliary Header fields in the example:
#Security Control (1 byte)
L = Security Level ENC-MIC-32 (5)
M = Key Identifier Mode (0x01)
Frame Counter Suppression = 1 (omitting Frame Counter field)
ASN in Nonce = 1 (construct Nonce from 5 byte ASN)
Reserved = 0
#Key Identifier (1 byte)
Key Index = IDX (deployment-specific KeyIndex parameter that
identifies the cryptographic key)Acknowledgments ✨
okay so the authors gave SHOUT-OUTS to a whole squad of people 🫶 Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa Vucinic, and Jonathan Simon all gave guidance and input 💖 Charles Perkins, Brian E. Carpenter, Ralph Droms, Warren Kumari, Mirja Kuehlewind, Ben Campbell, Benoit Claise, and Suresh Krishnan did the exhaustive and detailed reviews 🔥 Simon Duquennoy, Guillaume Gaillard, Tengfei Chang, and Jonathan Munoz did the detailed review of the examples section 🧚 and 6TiSCH co-chair Pascal Thubert gets a big thank you for his guidance and advice 👑
Authors' Addresses 🎀
Xavier Vilajosana (editor) 🌸 Universitat Oberta de Catalunya 156 Rambla Poblenou Barcelona, Catalonia 08018 Spain Email: xvilajosana@uoc.edu
Kris Pister 🦋 University of California Berkeley 512 Cory Hall Berkeley, California 94720 United States of America Email: pister@eecs.berkeley.edu
Thomas Watteyne 💜 Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 United States of America Email: twatteyne@linear.com
📦 where this page comes from
- ietf: rfc8180 2017-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms