idnits 2.17.1 draft-ietf-6tisch-minimal-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Sp (step_of_rank): (strictly positive integer) - an intermediate computation based on the link properties with a certain neighbor, for example the Expected Transmission Count (ETX) which provides an average of number of packet transmissions between two nodes. ETX is defined in detail by [decouto03high] and [RFC6551]. The ETX is computed as the inverse of the Packet Delivery Ratio (PDR), this is the number of transmitted packets, divided by the number of acknowledged packets to a certain node (e.g., ETX = numTX/ numTXAck). Note that this specification is designed for the IEEE802.15.4 MAC [IEEE802154-2015] which assumes L2 ACK. In case that a future use of this specification relies on a MAC layer that does not provide L2 ACK this metric needs to be reconsidered. An implementation MUST follow OF0's normalization guidance as discussed in Section 1 and Section 4.1 of [RFC6552], maintaining Sp between MINIMUM_STEP_OF_RANK of 1 to indicate a great quality and MAXIMUM_STEP_OF_RANK of 9 to indicate a really poor quality, with DEFAULT_STEP_OF_RANK indicating a normal, average quality. Sp SHOULD be set to (3*ETX)-2. Candidate parents with ETX greater than 3 SHOULD not be selected, motivated to avoid ETX values larger than the allowed retransmissions (4 transmission attempts). -- The document date (June 28, 2016) is 2857 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CCM' is mentioned on line 967, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 972, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 977, but not defined == Unused Reference: 'RFC7102' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-6top-protocol' is defined on line 954, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-05) exists of draft-ietf-6lo-paging-dispatch-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2015' == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-07 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-10 == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-01 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH X. Vilajosana, Ed. 3 Internet-Draft Universitat Oberta de Catalunya 4 Intended status: Best Current Practice K. Pister 5 Expires: December 30, 2016 University of California Berkeley 6 June 28, 2016 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-16 11 Abstract 13 This document describes a minimal mode of operation for a 6TiSCH 14 Network, to provide IPv6 connectivity over a Non-Broadcast Multi- 15 Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted 16 Channel Hopping (TSCH) links. 18 This minimal mode uses a collection of protocols including the 19 6LoWPAN framework to enable interoperable IPv6 connectivity over IEEE 20 802.15.4 TSCH with minimal network configuration and infrastructure. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 30, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Minimal Schedule Configuration . . . . . . . . . . . . . . . 4 60 4.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 8 63 4.4. Timeslot timing . . . . . . . . . . . . . . . . . . . . . 8 64 5. IEEE.802.15.4 Specific Header Fields and Considerations . . . 9 65 6. Enhanced Beacons Configuration and Content . . . . . . . . . 10 66 7. Acknowledgement Frames . . . . . . . . . . . . . . . . . . . 11 67 8. Neighbor information . . . . . . . . . . . . . . . . . . . . 11 68 8.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 11 69 8.2. Time Source Neighbor Selection . . . . . . . . . . . . . 12 70 9. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 13 71 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 11. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 11.1. RPL Objective Function Zero . . . . . . . . . . . . . . 14 74 11.1.1. Rank computation . . . . . . . . . . . . . . . . . . 14 75 11.1.2. Rank computation Example . . . . . . . . . . . . . . 16 76 11.2. RPL Configuration . . . . . . . . . . . . . . . . . . . 17 77 11.2.1. Mode of Operation . . . . . . . . . . . . . . . . . 18 78 11.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . 18 79 11.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 18 80 12. Variable Values . . . . . . . . . . . . . . . . . . . . . . . 19 81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 83 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 85 15.2. Informative References . . . . . . . . . . . . . . . . . 21 86 15.3. External Informative References . . . . . . . . . . . . 22 87 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 22 88 A.1. Example 1. Information Elements in EBs . . . . . . . . . 23 89 A.2. Example 2. Information Elements in EBs not using default 90 timeslot template . . . . . . . . . . . . . . . . . . . . 25 91 A.3. Example 3. Information Elements in ACKs . . . . . . . . . 27 92 A.4. Example 4. Auxiliary Security Header . . . . . . . . . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast 98 Multi-Access (NBMA) network that is formed of IEEE 802.15.4 99 Timeslotted Channel Hopping (TSCH) links. 101 The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires the 102 use of both RPL and the 6LoWPAN adaptation layer framework 103 ([RFC4944], [RFC6282]) as defined over IEEE 802.15.4. 6LoWPAN 104 Neighbor Discovery [RFC6775] (NDlo) is also required to exchange 105 Compression Contexts, form IPv6 addresses and register them for the 106 purpose of Duplicate Address Detection, Address Resolution and 107 Neighbor Unreachability detection over one TSCH link. 109 Nodes in an IEEE 802.15.4 TSCH network follow a communication 110 schedule. A network using the simple mode of operation uses a static 111 schedule. 113 This specification defines operational parameters and procedures for 114 a minimal mode of operation to build a 6TiSCH Network. The 802.15.4 115 TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective 116 Function 0 (OF0) [RFC6552], are used unmodified, but parameters and 117 particular operations of TSCH are specified to guarantee 118 interoperability between nodes in a 6TiSCH Network. RPL is a natural 119 choice for routing on top of IEEE 802.15.4 TSCH, and the specifics 120 for interoperable interaction between RPL and TSCH are described. 122 More advanced work is expected in the future to complement the 123 Minimal Configuration with dynamic operations that can adapt the 124 Schedule to the needs of the traffic in run time. 126 2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 3. Terminology 134 This document uses terminology from the Terminology in IPv6 over the 135 TSCH mode of IEEE 802.15.4e [I-D.ietf-6tisch-terminology]. The 136 following concepts are used in this document: 138 CCA: Clear Channel Assessment. 140 SFD: Start of Frame Delimiter. 142 RX: Reception. 144 TX: Transmission. 146 Join Priority: Join Metric. 148 Join Metric: Field in the TSCH Synchronization IE. Number of hops 149 separating the node sending the EB, and the PAN coordinator 151 4. Minimal Schedule Configuration 153 In order to form a network, a set of conventions need to be taken to 154 enable initial advertising of the network. Besides a set of 155 parameters need to be defined so joining nodes are configured and 156 hence the network formed and nodes interoperate. These set of rules 157 and default parameters constitute a minimal configuration to which 158 nodes implementing this specification MUST comply. The timeslot 159 timing, slotframe length, the number of active cells, their slot 160 offset and frequency offset and the purpose of the cells must agreed 161 upon as configuration parameters for two nodes to communicate. The 162 present document defines those rules. Table 1 summarizes the main 163 configuration parameters for a minimal configuration. 165 A joining node learns the minimal configuration from the Enhanced 166 Beacon, except for the security keys. More details about security 167 are given in Section Section 10. 169 The present specification is independent of the actual physical 170 layer; it is only dependent on the IEEE 802.15.4 TSCH MAC layer 171 specification. 173 4.1. Slotframe 175 The slotframe, as defined in the Terminology in IPv6 over the TSCH 176 mode of IEEE 802.15.4e [I-D.ietf-6tisch-terminology], is an 177 abstraction of the link layer that defines a collection of timeslots 178 of equal length that repeat over time. In order to set up a minimal 179 TSCH network, nodes need to be time synchronized and configured to 180 use the same slotframe configuration so they can communicate. 181 Compliant nodes SHOULD obey to the following configuration as defined 182 in Table 1: 184 Table 1. Minimal configuration parameters. 186 +------------------------------------+--------------------------+ 187 | Property | Value | 188 +------------------------------------+--------------------------+ 189 | Number of timeslots per Slotframe | Variable | 190 | |(default 11) | 191 +------------------------------------+--------------------------+ 192 | Number of available frequencies | 16 | 193 +------------------------------------+--------------------------+ 194 | Number of scheduled cells | 1 (slotOffset 0x00) | 195 | (active) | (chOffset 0x00) | 196 | | (link Option 0x0f) | 197 | | (macLinkType NORMAL) | 198 +------------------------------------+--------------------------+ 199 | Number of unscheduled cells | The remainder of the | 200 | (off) | slotframe | 201 +------------------------------------+--------------------------+ 202 | Number of MAC retransmissions (max)| 3 (4 transmission | 203 | | attempts) | 204 +------------------------------------+--------------------------+ 205 | Default timeslot timing | default | 206 | | macTimeslotTemplate | 207 | | template from | 208 | | IEEE802.15.4 | 209 | | macTimeslotTemplateId=0 | 210 +------------------------------------+--------------------------+ 211 | Enhanced Beacon Default Period | 10s | 212 | (referred as EB_PERIOD) | | 213 +------------------------------------+--------------------------+ 214 | Default Channel Hopping sequence | [5, 6, 12, 7, 15, | 215 | for the 2.4GHz OQPSK PHY | 4, 14, 11, 8, 0, | 216 | | 1, 2, 13, 3, 9, 10] | 217 +------------------------------------+--------------------------+ 219 The slotframe is composed of a configurable number of timeslots. The 220 number of timeslots in the slotframe is referred as slotframe length 221 [IEEE802154-2015]. This document defines a default slotframe length 222 of 11 slots. Choosing the number of time slots per slotframe needs 223 to take into account network requirements such as density, bandwidth 224 per node, etc. In the minimal configuration, there is only a single 225 active cell in the slotframe, used to transmit/receive both EBs and 226 data link-layer frames. The trade-off between bandwidth, latency and 227 energy consumption can be controlled by choosing a different 228 slotframe length. The active cell MAY be scheduled at any slotOffset 229 (default 0x00) and any channelOffset (default 0x00) within the 230 slotframe and this location MUST be announced in the EBs. EBs are 231 sent using this active cell to the link-layer broadcast address (and 232 are therefore not acknowledged). Data packets, as described in 233 Section 4.2, use the same active cell. Per IEEE 802.15.4 234 specification, data packets sent unicast on this cell are 235 acknowledged by the receiver [IEEE802154-2015]. The remaining cells 236 in the slotframe are unscheduled, and MAY be used by other (dynamic) 237 scheduling solutions. Details about such dynamic scheduling 238 solutions are out of scope of this document. Details about the usage 239 of the non scheduled cells are out of scope of this document. 241 The slotframe length determines the duty cycle of the network and 242 MUST be announced in the SlotFrame and Link IE of the EB. For 243 example, a network with a 0.99% duty cycle (as presented in Figure 1) 244 is composed of a slotframe of 101 timeslots, which includes 1 active 245 cell. 247 In a minimal configuration, a default timeslot duration set to 10ms 248 and its corresponding default timeslot internal timings defined by 249 the IEEE 802.15.4 specification SHOULD be used [IEEE802154-2015]. 250 The timeslot timing is defined by the macTimeslotTemplate in the 251 IEEE802.15.4 specification. The use of the default 252 macTimeslotTemplate MUST be announced in the Enhanced Beacon (EB) by 253 using the Timeslot Information Element (IE) containing only the 254 default macTimeslotTemplateId. Other timeslot durations MAY be 255 supported and MUST be announced in the EBs. Joining nodes MUST learn 256 the configuration from the received EB. If a network uses a timeslot 257 duration different than the default (10ms), EBs MUST contain the 258 complete Timeslot IE and fill all the fields of the 259 macTimeslotTemplate as described in Section 4.4. Nodes not 260 supporting the default timeslot value SHOULD be clearly indicated. 262 Figure 1. Example schedule with 0.99% duty cycle. A slotframe of 263 101 timeslots and 16 channel offsets. Only one active cell at 264 slotOffset 0x00 and channelOffset 0x00. The remaining cells are 265 unscheduled. 267 Chan. +----------+----------+ +----------+ 268 Off.0 | TxRxS/EB | OFF | | OFF | 269 Chan. +----------+----------+ +----------+ 270 Off.1 | OFF | OFF | ... | OFF | 271 +----------+----------+ +----------+ 272 . 273 . 274 . 275 Chan. +----------+----------+ +----------+ 276 Off.15 | OFF | OFF | | OFF | 277 +----------+----------+ +----------+ 279 slotOffset 0 1 100 281 EB: Enhanced Beacon 282 Tx: Transmit 283 Rx: Receive 284 S: Shared 285 OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism) 287 4.2. Cell Options 289 According to the IEEE 802.15.4 TSCH specification, each scheduled 290 cell is associated with a Link Options bitmap [IEEE802154-2015]. The 291 active cell in the minimal configuration MUST use a Link Option with 292 Value 0x0F. The bitmap in the active cell indicates that a node 293 transmits if there is a packet in its queue, listens otherwise as the 294 "Tx Link" and "Rx Link" bits are set. A "Shared Link" bit is set and 295 therefore the back-off mechanism defined in the IEEE 802.15.4 296 specification is used to resolve contention when transmitting 297 [IEEE802154-2015]. The "Timekeeping" flag is set so nodes initially 298 joining the network can maintain time synchronization to the 299 advertising node using that cell. Other time source neighbors MAY be 300 selected using the routing structure, e.g the DODAG structure of the 301 network if RPL is used. 303 Link Option bitmap setting for the active cell in the minimal 304 configuration slotframe: 306 b0 = Tx Link = 1 (set) 308 b1 = Rx Link = 1 (set) 309 b2 = Shared Link = 1 (set) 311 b3 = Timekeeping = 1 (set) 313 b4 = Priority = 0 (clear) 315 b5-b7 = Reserved (clear) 317 In addition, the scheduled cell in the schedule is configured as a 318 Hard cell [RFC7554][I-D.ietf-6tisch-terminology] indicating that it 319 cannot be moved or relocated by any dynamic scheduling mechanism. 320 Additional available cells MAY be scheduled by a dynamic scheduling 321 solution. The dynamic scheduling solution is out of scope, and this 322 specification does not make any restriction on the Link Option bitmap 323 associated with those dynamically scheduled cells (i.e. they can be 324 Hard cells or Soft cells as defined by the 6TiSCH Terminology 325 document [I-D.ietf-6tisch-terminology]). 327 All remaining cells are unscheduled. 329 4.3. Retransmissions 331 The maximum number of link layer retransmissions is set to 3. For 332 packets requiring an acknowledgment, if none are received after a 333 total of 4 attempts, the transmission is considered failed and the 334 link layer MUST notify the upper layer. Packets sent to the 335 broadcast MAC address (including EBs) are not acknowledged and 336 therefore not retransmitted. 338 4.4. Timeslot timing 340 Figure 2 shows an active timeslot in which a packet is sent from the 341 transmitter node (TX) to the receiver node (RX). A link-layer 342 acknowledgment is sent by the RX node to the TX node when the packet 343 is to be acknowledged. The tsTxOffset duration defines the instant 344 in the timeslot when the first bit after the Start of Frame Delimiter 345 (SFD) of the transmitted packet leaves the radio of the TX node. The 346 radio of the RX node is turned on tsRxWait/2 before that instant, and 347 listens for at least tsRxWait. This allows for a de-synchronization 348 between the two nodes of at most tsRxWait/2 in either direction 349 (early or late). The RX node needs to send the first bit after the 350 SFD of the MAC acknowledgment exactly tsTxAckDelay after the end of 351 the last byte of the received packet. TX's radio has to be turned on 352 tsAckWait/2 before that time, and keep listening for at least 353 tsAckWait. The TX node can perform a Clear Channel Assessment (CCA) 354 if required; this does not interfere with the scope of this document. 355 For the minimal configuration specified in this document, the use of 356 CCA is OPTIONAL. 358 Figure 2. Timeslot internal timing diagram (refer to Figure 6-43 in 359 [IEEE802154-2015]) 361 /---------------------- Timeslot Duration -----------------------/ 362 | / (5) / | 363 | | / tsRxAckDelay /| | | | 364 |-------------------+--------------+------------------+------+---| 365 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 366 |----+-------+------+--------------+------------------+------+---| 367 |/ tsTxOffset /| | | | | 368 | | | | | | 369 |-------------------+--------------+------------------+------+---| 370 RX | | | | RX frame | |TX ACK| | 371 |----------------+--+--+-----------+------------------+------+---| 372 | | | | | | | | 373 | / (4) / / tsTxAckDelay / | | 374 Start End 375 of of 376 Slot Slot 377 /(1)/ tsCCAOffset 378 /(2)/ tsCCA 379 /(3)/ tsRxTx 380 /(4)/ tsRxWait 381 /(5)/ tsAckWait 383 The timing parameters for the default macTimeslotTemplate 384 (macTimeslotTemplateId = 0) MUST be used when utilizing the default 385 timeslot duration. In this case, the TSCH Timeslot IE only 386 transports the macTimeslotTemplateId with value 0x00. If a timeslot 387 template other than the default is used, the EB MUST contain a 388 complete TimeSlot IE indicating the timeslot duration and the 389 corresponding timeslot timings. Note that in case of discrepancy 390 between the values in this document and the IEEE 802.15.4 391 specification [IEEE802154-2015], the IEEE standard has precedence. 393 5. IEEE.802.15.4 Specific Header Fields and Considerations 395 The IEEE802.15.4 header of BEACON, DATA, acknowledgment, MAC COMMAND 396 frames MUST include the Sequence Number field, the Source Address 397 field and the Destination Address field. The Frame Version field 398 MUST be set to 0b10 (Frame Version 2). 400 The PAN ID Compression bit in a BEACON frame MUST indicate that the 401 Source PAN ID is "Not Present" and the Destination PAN ID is 402 "Present". The source address field MUST be filled with an extended 403 address (64 bit) and this be indicated in the corresponding Frame 404 Control field. The Destination address field MUST be filled with a 405 short address (16bit) with a value of 0xffff to represent the 406 broadcast short address. 408 A Node aiming to join a network by receiving a properly formed BEACON 409 MUST use a PAN ID set to 0xffff in order meet the filtering rules in 410 the IEEE 802.15.4 specification [IEEE802154-2015]. 412 When using DATA, ACKNOWLEDGMENT, MAC COMMAND frame types the source 413 and destination address fields MUST be filled with an extended 414 address (64 bit) and this be indicated in the corresponding Frame 415 Control field. The Destination PAN ID MUST be present, the Source 416 PAN ID MUST be elided. The PAN ID Compression field MUST indicate 417 that the Destination PAN ID is "Present" and the Source PAN ID is 418 "Not Present". According to Table 7-6 in the IEEE 802.15.4 2015 419 specification document, this is accomplished by setting the PAN ID 420 Compression bit to 0b0 [IEEE802154-2015]. 422 When preparing the security header, the Absolute Sequence Number 423 (ASN) MUST be written into the Nonce in most significant byte first 424 (MSB) format as indicated in the IEEE 802.15.4 specification 425 [IEEE802154-2015]. 427 6. Enhanced Beacons Configuration and Content 429 The IEEE 802.15.4 specification does not define how often EBs are 430 sent, nor their contents [IEEE802154-2015]. EBs are not used for 431 time synchronization. Time synchronization is achieved via 432 acknowledgements to normal packet traffic, and keepalives. For 433 additional reference see [RFC7554] where different time 434 synchronization approaches are summarized. 436 In a minimal TSCH configuration, a node SHOULD send an EB every 437 EB_PERIOD (default value = 10s). EBs are only authenticated; neither 438 Payload IEs nor the frame payload are encrypted. 440 EBs MUST be sent as per the IEEE 802.15.4 specification and MUST 441 carry the Information Elements (IEs) listed below [IEEE802154-2015]. 442 Refer to Appendix A.1 for an example of the Information Elements 443 Header Content. 445 TSCH Synchronization IE: Contains synchronization information such 446 as ASN and Join Metric. The value of Join Metric is discussed in 447 Section 8.2. 449 TSCH Timeslot IE: Contains the timeslot template identifier. This 450 template is used to specify the internal timing of the timeslot. 451 This specification uses the default timeslot template as defined 452 in the IEEE 802.15.4 specification [IEEE802154-2015]. In the case 453 that a non-default timeslot template is used, the IE Content MUST 454 follow the specification as defined in [IEEE802154-2015] . Refer 455 to Appendix A.1 for an illustrative example of non default 456 timeslot template. 458 Channel Hopping IE: Contains the channel hopping sequence 459 identifier. This specification uses the default channel hopping 460 sequence (with default HoppingSequenceID = 0x00), as defined in 461 the IEEE 802.15.4 specification [IEEE802154-2015]. The default 462 sequence for the 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11, 463 8, 0, 1, 2, 13, 3, 9, 10] [IEEE802154-2015]. Note however that 464 in case of discrepancy between the values in this document and 465 [IEEE802154-2015], the IEEE standard specification has preference. 467 TSCH SlotFrame and Link IE: Each node MUST indicate the schedule 468 in each EB through a TSCH SlotFrame and Link IE. This enables 469 nodes which implement the IEEE 802.15.4 specification 470 [IEEE802154-2015] to learn the schedule used in the network as 471 they join it. This document defines the use of a single cell set 472 at the default channel offset 0x00, default timeslot offset 0x00 473 and with Link Option 0x0F (TX, RX, SHARED bits set). A node 474 SHOULD indicate the same information in the "TSCH SlotFrame and 475 Link IE" in the EBs it sends, than the "TSCH SlotFrame and Link 476 IE" information it has received in an EB. 478 7. Acknowledgement Frames 480 Unicast frames sent to a unicast MAC destination address MUST request 481 an acknowledgment. Each acknowledgment MUST contain an ACK/NACK Time 482 Correction IE. 484 8. Neighbor information 486 The IEEE 802.15.4 specification does not define how and when each 487 node in the network keeps information about its neighbours. A node 488 SHOULD keep at least the following information in a neighbor table: 490 8.1. Neighbor Table 492 The exact format of the neighbor table is implementation-specific. 493 The neighbor table SHOULD contain the following information for each 494 neighbor: 496 Neighbor statistics: 498 numTx: number of transmitted packets to that neighbor 499 numTxAck: number of transmitted packets that have been 500 acknowledged by that neighbor 502 numRx: number of received packets from that neighbor 504 The EUI-64 of the neighbor. 506 Timestamp of the last frame received from that neighbor. This can 507 be based on the ASN counter or any other time base. It can be 508 used to trigger a keep-alive message. 510 Routing metric such as the RPL Rank of that neighbor. 512 A flag indicating whether this neighbor is a time source neighbor. 514 In addition to that information, each node in a multihop topology and 515 implementing RPL MUST at least support the use OF Zero as described 516 in [RFC6552] and Section 11.1.1. 518 8.2. Time Source Neighbor Selection 520 Each node MUST select at least one Time Source Neighbor among the 521 nodes in its routing parent set (e.g the RPL parent set). When a 522 node joins a network, it has no routing information. To select its 523 time source neighbor, it uses the Join Metric field in the EB, as 524 described in the IEEE 802.15.4 specification [IEEE802154-2015]. The 525 Sync IE contains the ASN and 1 Byte field named Join Metric. The 526 Join Metric of any node MUST be based on the routing metric of the 527 network and normalized to a value between 0 and 15. In case that the 528 network uses RPL, the Join Metric of any node MUST be equivalent to 529 the result of the function DAGRank(rank)-1. The Join Metric of the 530 DAG root MUST also be equivalent to DAGRank(rank)-1. According to 531 Section 11.1.1 the DAGRank(rank(0)) = 1 and therefore the 532 DAGRank(rank(0))-1 is 0 which is compliant with the requirement of 533 Join Metric = 0 imposed by the IEEE 802.15.4 specification 534 [IEEE802154-2015]. A lower value of the Join Metric indicates higher 535 preference to connect to that device. 537 When a RPL node joins the network, it MUST NOT send EBs before having 538 acquired a RPL Rank. This applies to other routing protocols with 539 their corresponding routing metrics. This avoids inconsistencies in 540 the time synchronization structure. As soon as a node acquires 541 routing information (e.g RPL Rank (see [RFC6550] and 542 Section 11.1.1)), it SHOULD send Enhanced Beacons including a Sync IE 543 with Join Metric field set as indicated above. If a node receives 544 EBs from different nodes with equal Join Metric, the time source 545 neighbor selection SHOULD be assessed by other metrics that can help 546 to determine the better connectivity link. Time source neighbor 547 hysteresis SHOULD be used, according to the rules defined in 548 Section 11.2.3. At any time, a node MUST maintain connectivity to at 549 least one time source neighbor. New time source neighbours MUST be 550 chosen among the neighbours in the routing parent set. 552 The decision for a node to select one Time Source Neighbor when 553 multiple EBs are received is implementation-specific. 555 For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT 556 neighbours have been received to select the best Time Source 557 Neighbor. This condition MAY apply unless a second EB is not 558 received after MAX_EB_DELAY seconds. This avoids initial hysteresis 559 when selecting a first Time Source Neighbor. 561 Some form of hysteresis SHOULD be implemented to avoid frequent 562 changes in time source neighbours. 564 9. Queues and Priorities 566 The IEEE 802.15.4 specification [IEEE802154-2015] does not define the 567 use of queues to handle upper layer data (either application or 568 control data from upper layers). A single queue with the following 569 rules SHOULD be used: 571 A node MAY be configured to keep in the queue a configurable 572 number of Upper Layer packets per link ( default 573 NUM_UPPERLAYER_PACKETS = 1) for a configurable time in seconds 574 that should cover the join process ( default MAX_JOIN_TIME = 300 575 ). 577 Frames generated by the IEEE 802.15.4 layer are queued with higher 578 priority than frames containing higher-layer packets. 580 Frame types BEACON and COMMAND are queued with higher priority 581 than frame types DATA and ACK. 583 One entry in the queue is reserved at all times for frames of 584 types BEACON and COMMAND frames. 586 10. Security 588 As this document refers to the interaction between Layer 3 and Layer 589 2 protocols, this interaction MUST be secured by L2 security 590 mechanisms as defined by the IEEE 802.15.4 specification 591 [IEEE802154-2015]. Two security mechanisms are considered, 592 authentication and encryption; authentication applies to all packet 593 content while encryption applies to header IEs and MAC payload. Key 594 distribution is out of scope of this document, but examples include 595 pre-configured keys at the nodes, shared keys among peers or well- 596 known keys. 598 The present document assumes the existence of two cryptographic keys, 599 which can be pre-configured. One of the keys (K1) is used to 600 authenticate EBs. As defined in Section 6, EBs MUST be 601 authenticated, with no payload encryption. This facilitates logical 602 segregation of distinct networks. A second key (K2) is used to 603 authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and 604 respective header IEs, with payload encryption. Depending on 605 security policy, these keys could be the same (i.e., K1=K2). 607 For early interoperability testing, it is recommended to set K1 to 36 608 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15"). 610 11. RPL on TSCH 612 In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be 613 used. 615 11.1. RPL Objective Function Zero 617 If RPL is used, nodes MUST implement the RPL Objective Function Zero 618 (OF0) [RFC6552]. 620 11.1.1. Rank computation 622 The Rank computation is described at [RFC6552], Section 4.1. 624 A node's Rank (see Figure 3 for an example) is computed by the 625 following equation: 627 R(N) = R(P) + rank_increment 629 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 631 Where: 633 R(N): Rank of the node. 635 R(P): Rank of the parent obtained as part of the DIO information. 637 rank_increment: The result of a function that determines the Rank 638 increment. 640 Rf (rank_factor): A configurable factor that is used to multiply 641 the effect of the link properties in the rank_increment 642 computation. A minimal configuration SHOULD set rank_factor to 1. 644 Sp (step_of_rank): (strictly positive integer) - an intermediate 645 computation based on the link properties with a certain neighbor, 646 for example the Expected Transmission Count (ETX) which provides 647 an average of number of packet transmissions between two nodes. 648 ETX is defined in detail by [decouto03high] and [RFC6551]. The 649 ETX is computed as the inverse of the Packet Delivery Ratio (PDR), 650 this is the number of transmitted packets, divided by the number 651 of acknowledged packets to a certain node (e.g., ETX = numTX/ 652 numTXAck). Note that this specification is designed for the 653 IEEE802.15.4 MAC [IEEE802154-2015] which assumes L2 ACK. In case 654 that a future use of this specification relies on a MAC layer that 655 does not provide L2 ACK this metric needs to be reconsidered. An 656 implementation MUST follow OF0's normalization guidance as 657 discussed in Section 1 and Section 4.1 of [RFC6552], maintaining 658 Sp between MINIMUM_STEP_OF_RANK of 1 to indicate a great quality 659 and MAXIMUM_STEP_OF_RANK of 9 to indicate a really poor quality, 660 with DEFAULT_STEP_OF_RANK indicating a normal, average quality. 661 Sp SHOULD be set to (3*ETX)-2. Candidate parents with ETX greater 662 than 3 SHOULD not be selected, motivated to avoid ETX values 663 larger than the allowed retransmissions (4 transmission attempts). 665 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 666 to the step_of_rank of a preferred parent, to allow the selection 667 of an additional feasible successor. In this specification, 668 stretch_of_rank SHOULD be set to 0. 670 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 671 constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550]. 672 DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. 674 DAGRank(rank): Equivalent to the floor of "rank" as defined by 675 [RFC6550]. DAGRank(rank) = floor(rank/MinHopRankIncrease). Nodes 676 compute their DAGRank(rank) using DAGRank(R(N)). 678 Figure 3. Rank computation scenario. 680 +-------+ 681 | P | R(P) 682 | | 683 +-------+ 684 | 685 | 686 +-------+ 687 | N | R(N)=R(P) + rank_increment 688 | | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 689 +-------+ Sp= (3*ETX) - 2 691 11.1.2. Rank computation Example 693 This section illustrates with an example the use of the Objective 694 Function Zero (see Figure 4 which uses numTx=100 and numTxAck=75 for 695 all nodes). Assume the following parameters: 697 Rf = 1 699 Sp = (3*ETX)-2 701 Sr = 0 703 minHopRankIncrease = 256 (default in RPL) 705 ETX=(numTx/numTxAck) 707 r(n) = r(p) + rank_increment 709 rank_increment = (Rf*Sp + Sr) * minHopRankIncrease 711 rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512 713 Figure 4. Rank computation example for 5 hop network where numTx=100 714 and numTxAck=75 for all nodes 716 +-------+ 717 | 0 | R(minHopRankIncrease) = 256 718 | | DAGRank(R(0)) = 1 719 +-------+ 720 | 721 | 722 +-------+ 723 | 1 | R(1)=R(0) + 512 = 768 724 | | DAGRank(R(1)) = 3 725 +-------+ 726 | 727 | 728 +-------+ 729 | 2 | R(2)=R(1) + 512 = 1280 730 | | DAGRank(R(2)) = 5 731 +-------+ 732 | 733 | 734 +-------+ 735 | 3 | R(3)=R(2) + 512 = 1792 736 | | DAGRank(R(3)) = 7 737 +-------+ 738 | 739 | 740 +-------+ 741 | 4 | R(4)=R(3) + 512 = 2304 742 | | DAGRank(R(4)) = 9 743 +-------+ 744 | 745 | 746 +-------+ 747 | 5 | R(5)=R(4) + 512 = 2816 748 | | DAGRank(R(5)) = 11 749 +-------+ 751 11.2. RPL Configuration 753 In addition to the Objective Function (OF), nodes in a multihop 754 network using RPL MUST indicate the preferred mode of operation using 755 the MOP field in the DIO. Nodes not being able to operate in the 756 specified mode of operation MUST only join as leaf nodes. RPL 757 information and hop-by-hop extension headers MUST follow [RFC6553] 758 and [RFC6554] specification. In the case that the packets formed at 759 the LLN need to cross through intermediate routers, these MUST follow 760 the IP in IP encapsulation requirement specified by the [RFC6282] and 762 [RFC2460]. Routing extension headers such as RPI [RFC6550] and SRH 763 [RFC6554], and outer IP headers in case of encapsulation MUST be 764 compressed according to [I-D.ietf-6lo-routing-dispatch] and 765 [I-D.ietf-6lo-paging-dispatch]. 767 11.2.1. Mode of Operation 769 When RPL is used, nodes MUST support the non-storing ([RFC6550] 770 Section 9.7) mode of operation. The storing ([RFC6550] Section 9.8) 771 mode of operation SHOULD be supported by nodes with enough 772 capabilities. Non-storing mode of operation is the default mode that 773 a node selects when acting as a DAG root. The latest is motivated 774 because most of the practical usages of the RPL protocol in the IoT 775 space make use of non-storing modes. This is because storing mode 776 limits the size of the network to the storage capabilities of the 777 devices, and is more complex to operate due to the distributed 778 routing operation for routing downwards. In addition, it is 779 important to note that the Mode of Operation is an administrative 780 action and changing it causes the DAG to rebuild entirely. 782 11.2.2. Trickle Timer 784 RPL signaling messages such as DIOs are sent using the Trickle 785 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 786 specification, the Trickle Timer MUST be used with the RPL defined 787 default values [RFC6550] (Section 8.3.1). For a description of the 788 Trickle timer operation see Section 4.2 on [RFC6206]. 790 11.2.3. Hysteresis 792 According to [RFC6552], [RFC6719] recommends the use of a boundary 793 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 794 when ranks are compared. When evaluating a parent that belongs to a 795 smaller path cost than the current minimum path, the candidate node 796 is selected as new parent only if the difference between the new path 797 and the current path is greater than the defined 798 PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the 799 current preferred parent. As for [RFC6719] the 800 PARENT_SWITCH_THRESHOLD SHOULD be set to 192 when ETX metric is used 801 (in the form 128*ETX), the recommendation for this document is to use 802 PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is 803 ((3*ETX)-2)*minHopRankIncrease, or a proportional value. This 804 mechanism is suited to deal with parent hysteresis in both cases 805 including routing parent and time source neighbor selection. In case 806 a node has a security association with its parent, including routing 807 parent or time source neighbor, the node SHOULD be allowed to keep 808 the association despite of fluctuations of the rank. 810 12. Variable Values 812 Table 2 presents the values for the variables defined in this 813 document that SHOULD be used. 815 Table 2. Recommended variable values 817 +-------------------------+-------+ 818 | Variable | Value | 819 +-------------------------+-------+ 820 | MAX_EB_DELAY | 180 | 821 +-------------------------+-------+ 822 | NUM_NEIGHBOURS_TO_WAIT | 2 | 823 +-------------------------+-------+ 824 | PARENT_SWITCH_THRESHOLD | 640 | 825 +-------------------------+-------+ 826 | NUM_UPPERLAYER_PACKETS | 1 | 827 +-------------------------+-------+ 828 | JOIN_TIME | 300 | 829 +-------------------------+-------+ 831 13. IANA Considerations 833 This document requests no immediate action by IANA. 835 14. Acknowledgements 837 The authors would like to acknowledge the guidance and input provided 838 by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola 839 Accettura, Malisa Vucinic and for the exhaustive and detailed review 840 of the document by Charles Perkins. Also for the detailed review of 841 the examples section to Simon Duquennoy, Guillaume Gaillard, Tengfei 842 Chang and Jonathan Munoz. Also our acknowledge to the 6TiSCH Chairs 843 Pascal Thubert and Thomas Watteyne for their guidance and advice. 845 15. References 847 15.1. Normative References 849 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 850 Hysteresis Objective Function", RFC 6719, 851 DOI 10.17487/RFC6719, September 2012, 852 . 854 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 855 Bormann, "Neighbor Discovery Optimization for IPv6 over 856 Low-Power Wireless Personal Area Networks (6LoWPANs)", 857 RFC 6775, DOI 10.17487/RFC6775, November 2012, 858 . 860 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 861 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 862 DOI 10.17487/RFC6282, September 2011, 863 . 865 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 866 Routing Header for Source Routes with the Routing Protocol 867 for Low-Power and Lossy Networks (RPL)", RFC 6554, 868 DOI 10.17487/RFC6554, March 2012, 869 . 871 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 872 Power and Lossy Networks (RPL) Option for Carrying RPL 873 Information in Data-Plane Datagrams", RFC 6553, 874 DOI 10.17487/RFC6553, March 2012, 875 . 877 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 878 Protocol for Low-Power and Lossy Networks (RPL)", 879 RFC 6552, DOI 10.17487/RFC6552, March 2012, 880 . 882 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 883 and D. Barthel, "Routing Metrics Used for Path Calculation 884 in Low-Power and Lossy Networks", RFC 6551, 885 DOI 10.17487/RFC6551, March 2012, 886 . 888 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 889 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 890 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 891 Low-Power and Lossy Networks", RFC 6550, 892 DOI 10.17487/RFC6550, March 2012, 893 . 895 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 896 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 897 March 2011, . 899 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 900 "Transmission of IPv6 Packets over IEEE 802.15.4 901 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 902 . 904 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 905 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 906 December 1998, . 908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 909 Requirement Levels", BCP 14, RFC 2119, 910 DOI 10.17487/RFC2119, March 1997, 911 . 913 [I-D.ietf-6lo-routing-dispatch] 914 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 915 "6LoWPAN Routing Header", draft-ietf-6lo-routing- 916 dispatch-05 (work in progress), February 2016. 918 [I-D.ietf-6lo-paging-dispatch] 919 Thubert, P., "6LoWPAN Paging Dispatch", draft-ietf-6lo- 920 paging-dispatch-01 (work in progress), January 2016. 922 [IEEE802154-2015] 923 IEEE standard for Information Technology, "IEEE Std 924 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 925 Networks (WPANs)", December 2015. 927 15.2. Informative References 929 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 930 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 931 Internet of Things (IoT): Problem Statement", RFC 7554, 932 DOI 10.17487/RFC7554, May 2015, 933 . 935 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 936 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 937 2014, . 939 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 940 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 941 2003, . 943 [I-D.ietf-6tisch-terminology] 944 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 945 "Terminology in IPv6 over the TSCH mode of IEEE 946 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 947 progress), March 2016. 949 [I-D.ietf-6tisch-architecture] 950 Thubert, P., "An Architecture for IPv6 over the TSCH mode 951 of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work 952 in progress), June 2016. 954 [I-D.ietf-6tisch-6top-protocol] 955 Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- 956 ietf-6tisch-6top-protocol-01 (work in progress), June 957 2016. 959 15.3. External Informative References 961 [decouto03high] 962 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 963 High-Throughput Path Metric for Multi-Hop Wireless 964 Routing", ACM International Conference on Mobile Computing 965 and Networking (MobiCom) , June 2003. 967 [CCM] National Institute of Standards and Technology, 968 "Recommendation for Block Cipher Modes of Operation: The 969 CCM Mode for Authentication and Confidentiality. SP 970 800-38C", May 2004. 972 [CCM-Star] 973 Struik, R., "Formal Specification of the CCM* Mode of 974 Operation, IEEE P802.15 Working Group for Wireless 975 Personal Area Networks (WPANs).", September 2005. 977 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 978 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 979 a Standards-Based Low-Power Wireless Development 980 Environment", Transactions on Emerging Telecommunications 981 Technologies , August 2012. 983 Appendix A. Examples 985 Several examples are provided to illustrate the content of the 986 packets used by the minimal configuration as proposed by this 987 document. Each example follows the same structure presenting first a 988 schematic header diagram, then the LSB stream of bytes that conform 989 the header and finally a description of each of the IEs that form the 990 packet. The packet formats are specific for the [IEEE802154-2015] 991 revision and may vary in future releases of the IEEE standard. In 992 case of differences between the packet content presented in this 993 section and the [IEEE802154-2015], the latter has precedence. 995 The MAC header fields are described in a specific order. All field 996 formats in this examples are depicted in the order in which they are 997 transmitted by the PHY, from left to right, where the leftmost bit is 998 transmitted first in time. Bits within each field are numbered from 999 0 (leftmost and least significant) to k - 1 (rightmost and most 1000 significant), where the length of the field is k bits. Fields that 1001 are longer than a single octet are sent to the PHY in the order from 1002 the octet containing the lowest numbered bits to the octet containing 1003 the highest numbered bits, hence little endian ordering. 1005 A.1. Example 1. Information Elements in EBs 1007 Mandatory content for the EB as proposed by this draft. The example 1008 uses a slotframe of 101 slots. Figure 5 represents schematically the 1009 Header IE and Payload IE content of an EB. 1011 Figure 5. Example of the IEs as proposed by this draft. 1013 1 2 3 1014 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 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Len3 = 6 |Sub ID = 0x1a|0| ASN 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 ASN | Join Metric | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 Stream of bytes (in little-endian ordering) that derive 1034 from the previous schematic header: 1036 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 1037 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F 1038 Description of the IE fields in the example: 1040 #Header IE Header 1041 Len1 = Header IE Length (0) 1042 Element ID = 0x7e - termination IE indicating Payload IE coming next 1043 Type 0 1045 #Payload IE Header (MLME) 1046 Len2 = Payload IE Len (26 Bytes) 1047 GroupID = 1 MLME (Nested) 1048 Type = 1 1050 #MLME-SubIE TSCH Synchronization 1051 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 1052 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 1053 Type = Short (0) 1054 ASN = Absolute Sequence Number (5 Bytes) 1055 Join Metric = 1 Byte 1057 #MLME-SubIE TSCH TimeSlot 1058 Len4 = Length in bytes of the sub-IE payload (1 Byte) 1059 SubID = 0x1c (MLME-SubIE Timeslot) 1060 Type = Short (0) 1061 TimeSlot template ID = 0x00 (default) 1063 #MLME-SubIE Ch. Hopping 1064 Len5 = Length in bytes of the sub-IE payload (1 Byte) 1065 SubID = 0x09 (MLME-SubIE Ch. Hopping) 1066 Type = Long (1) 1067 Channel Hopping Sequence ID = 0x00 (default) 1069 #MLME-SubIE TSCH Slotframe and Link 1070 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 1071 SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 1072 Type = Short (0) 1073 Number of slotframes = 0x01 1074 SlotFrame Handle = 0x00 1075 SlotFrame Size = 101 slots (0x65) 1076 Number of Links = 0x01 1077 Timeslot = 0x0000 (2B) 1078 Channel Offset = 0x0000 (2B) 1079 Link Option = 0x0F (tx,rx,shared,timekeeping) 1081 A.2. Example 2. Information Elements in EBs not using default timeslot 1082 template 1084 Using a non-default timeslot template in EBs. Timeslot length set to 1085 15ms instead of the 10ms default. Refer to Figure 6 for the specific 1086 IE fields. 1088 Figure 6. Example of a non-default timeslot template in EB. 1090 Schematic representation of the IE header in an EB: 1092 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Len3 = 6 |Sub ID = 0x1a|0| ASN 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 ASN | Join Metric | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 = 2700 | macTsCCA = 128 | macTsTxOffset 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 = 3300 | macTsAckWait = 600 | macTsRxTx 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 = 192 | macTsMaxAck = 2400 | macTsMaxTx 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 Stream of bytes (in little-endian ordering) that derive 1119 from the previous schematic header: 1121 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 1122 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 1123 00 0A ... 1125 Description of the IE fields in the example: 1127 #Header IE Header 1128 Len1 = Header IE Length (none) 1129 Element ID = 0x7e - termination IE indicating Payload IE coming next 1130 Type 0 1132 #Payload IE Header (MLME) 1133 Len2 = Payload IE Len (53 Bytes) 1134 GroupID = 1 MLME (Nested) 1135 Type = 1 1137 #MLME-SubIE TSCH Synchronization 1138 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 1139 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 1140 Type = Short (0) 1141 ASN = Absolute Sequence Number (5 Bytes) 1142 Join Metric = 1 Byte 1144 #MLME-SubIE TSCH TimeSlot 1145 Len4 = Length in bytes of the sub-IE payload (25 Bytes) 1146 SubID = 0x1c (MLME-SubIE Timeslot) 1147 Type = Short (0) 1148 TimeSlot template ID = 0x01 (non-default) 1150 Example timeslot timing using 15ms timeslot. 1151 +--------------------------------+------------+ 1152 | IEEE802.15.4 TSCH parameter | Value (us) | 1153 +--------------------------------+------------+ 1154 | tsCCAOffset | 2700 | 1155 +--------------------------------+------------+ 1156 | tsCCA | 128 | 1157 +--------------------------------+------------+ 1158 | tsTxOffset | 3180 | 1159 +--------------------------------+------------+ 1160 | tsRxOffset | 1680 | 1161 +--------------------------------+------------+ 1162 | tsRxAckDelay | 1200 | 1163 +--------------------------------+------------+ 1164 | tsTxAckDelay | 1500 | 1165 +--------------------------------+------------+ 1166 | tsRxWait | 3300 | 1167 +--------------------------------+------------+ 1168 | tsAckWait | 600 | 1169 +--------------------------------+------------+ 1170 | tsRxTx | 192 | 1171 +--------------------------------+------------+ 1172 | tsMaxAck | 2400 | 1173 +--------------------------------+------------+ 1174 | tsMaxTx | 4256 | 1175 +--------------------------------+------------+ 1176 | Timeslot duration | 15000 | 1177 +--------------------------------+------------+ 1179 #MLME-SubIE Ch. Hopping 1180 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 1181 SubID = 0x09 (MLME-SubIE Ch. Hopping) 1182 Type = Long (1) 1183 Channel Hopping Sequence ID = 0x00 (default) 1185 A.3. Example 3. Information Elements in ACKs 1187 Enhanced Acknowledgement packets carry the Time Correction IE (Header 1188 IE). Figure 7 illustrates the IE format as specified in 1189 [IEEE802154-2015]. 1191 Figure 7. Acknowledgement packet IE content. 1193 1 2 3 1194 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 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 Stream of bytes (in little-endian ordering) that derive 1200 from the previous schematic header: 1202 02 0F TS#0 TS#1 1204 Description of the IE fields in the example: 1206 #Header IE Header 1207 Len1 = Header IE Length (2 Bytes) 1208 Element ID = 0x1e - ACK/NACK Time Correction IE 1209 Type 0 1211 A.4. Example 4. Auxiliary Security Header 1213 Figure 8 illustrates the content of the Auxiliary Security Header as 1214 mandated by this document, if security is enabled. Security Level in 1215 the example is set to ENC-MIC-32 (5). 1217 Figure 8. Example auxiliary security header. 1219 1 1220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 |L = 5|M=1|1|1|0|Key Index = IDX| 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Stream of bytes (in LSB format) that derive from the previous 1226 schematic header: 1228 6D IDX#0 1230 Description of the Security Auxiliary Header fields in the example: 1232 #Security Control (1 byte) 1233 L = Security Level ENC-MIC-32 (5) 1234 M = Key Identifier Mode (0x01) 1235 Frame Counter Suppression = 1 (omitting Frame Counter field) 1236 Frame Counter Size = 1 (construct Nonce from 5 byte ASN) 1237 Reserved = 0 1239 #Key Identifier (1 byte) 1240 Key Index = IDX (deployment-specific KeyIndex parameter that 1241 identifies the cryptographic key) 1243 Authors' Addresses 1245 Xavier Vilajosana (editor) 1246 Universitat Oberta de Catalunya 1247 156 Rambla Poblenou 1248 Barcelona, Catalonia 08018 1249 Spain 1251 Phone: +34 (646) 633 681 1252 Email: xvilajosana@uoc.edu 1254 Kris Pister 1255 University of California Berkeley 1256 490 Cory Hall 1257 Berkeley, California 94720 1258 USA 1260 Email: pister@eecs.berkeley.edu