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