idnits 2.17.1 draft-ietf-6tisch-minimal-15.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 neighbor, 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 (February 27, 2016) is 2953 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 450 -- Looks like a reference, but probably isn't: '6' on line 450 -- Looks like a reference, but probably isn't: '12' on line 450 -- Looks like a reference, but probably isn't: '7' on line 450 -- Looks like a reference, but probably isn't: '15' on line 450 -- Looks like a reference, but probably isn't: '4' on line 450 -- Looks like a reference, but probably isn't: '14' on line 450 -- Looks like a reference, but probably isn't: '11' on line 450 -- Looks like a reference, but probably isn't: '8' on line 450 -- Looks like a reference, but probably isn't: '0' on line 450 -- Looks like a reference, but probably isn't: '1' on line 450 -- Looks like a reference, but probably isn't: '2' on line 450 -- Looks like a reference, but probably isn't: '13' on line 450 -- Looks like a reference, but probably isn't: '3' on line 450 -- Looks like a reference, but probably isn't: '9' on line 450 -- Looks like a reference, but probably isn't: '10' on line 450 == Missing Reference: 'CCM' is mentioned on line 947, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 952, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 957, but not defined == Unused Reference: 'RFC7102' is defined on line 916, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 920, 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-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 (-30) exists of draft-ietf-6tisch-architecture-09 Summary: 1 error (**), 0 flaws (~~), 11 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: August 30, 2016 University of California Berkeley 6 February 27, 2016 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-15 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 August 30, 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. Neighbor information . . . . . . . . . . . . . . . . . . . . 11 69 8.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 11 70 8.2. Time Source Neighbor 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 . . . . . . . . . . . . . . . . . . . . 24 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 to 142 enable initial advertising of the network. Besides a set of 143 parameters need to be defined so joining nodes are configured and 144 hence the network formed and nodes interoperate. These set of rules 145 and 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 repeat 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 indicates 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 a behavior that is similar to that of 287 "Slotted Aloha". The "Timekeeping" flag is set so nodes initially 288 joining the network can maintain time synchronization to the 289 advertising node using that cell. Other time source neighbors MAY be 290 selected using the routing structure, e.g the DODAG structure of the 291 network if RPL is used. 293 LinkOption bitmap setting for the active cell in the minimal 294 configuration slotframe: 296 b0 = Transmit = 1 (set) 298 b1 = Receive = 1 (set) 299 b2 = Shared = 1 (set) 301 b3 = Timekeeping = 1 (set) 303 b4-b7 = Reserved (clear) 305 In addition, the scheduled cell in the schedule is configured as a 306 Hard cell [RFC7554][I-D.ietf-6tisch-terminology] indicating that 307 cannot be moved or relocated by any dynamic scheduling mechanism. 308 Additional available cells MAY be scheduled by a dynamic scheduling 309 solution. The dynamic scheduling solution is out of scope, and this 310 specification does not make any restriction on the LinkOption bitmap 311 associated with those dynamically scheduled cells (i.e. they can be 312 Hard cells or Soft cells as defined by the 6TiSCH Terminology 313 document [I-D.ietf-6tisch-terminology]). 315 All remaining cells are unscheduled. In unscheduled cells, the nodes 316 SHOULD keep their radio off. 318 4.3. Retransmissions 320 The maximum number of link layer retransmissions is set to 3. For 321 packets requiring an acknowledgment, if none are received after a 322 total of 4 attempts, the transmission is considered failed and the 323 link layer MUST notify the upper layer. Packets sent to the 324 broadcast MAC address (including EBs) are not acknowledged and 325 therefore not retransmitted. 327 4.4. Timeslot timing 329 Figure 2 shows an active timeslot in which a packet is sent from the 330 transmitter node (TX) to the receiver node (RX). A link-layer 331 acknowledgment is sent by the RX node to the TX node when the packet 332 is to be acknowledged. The TsTxOffset duration defines the instant 333 in the timeslot when the first bit after the Start of Frame Delimiter 334 (SFD) of the transmitted packet leaves the radio of the TX node. The 335 radio of the RX node is turned on tsRxWait/2 before that instant, and 336 listens for at least tsRxWait. This allows for a de-synchronization 337 between the two nodes of at most tsRxWait/2 in either direction 338 (early or late). The RX node needs to send the first bit after the 339 SFD of the MAC acknowledgment exactly TsTxAckDelay after the end of 340 the last byte of the received packet. TX's radio has to be turned on 341 tsAckWait/2 before that time, and keep listening for at least 342 tsAckWait. The TX node can perform a Clear Channel Assessment (CCA) 343 if required, this does not interfere with the scope of this document. 344 For the minimal configuration specified in this document, the use of 345 CCA is OPTIONAL. 347 Figure 2. Timeslot internal timing diagram 349 /---------------------- Timeslot Duration -----------------------/ 350 | / (5) / | 351 | | / tsRxAckDelay /| | | | 352 |-------------------+--------------+------------------+------+---| 353 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 354 |----+-------+------+--------------+------------------+------+---| 355 |/ tsTxOffset /| | | | | 356 | | | | | | 357 |-------------------+--------------+------------------+------+---| 358 RX | | | | RX frame | |TX ACK| | 359 |----------------+--+--+-----------+------------------+------+---| 360 | | | | | | | | 361 | / (4) / / tsTxAckDelay / | | 362 Start End 363 of of 364 Slot Slot 365 /(1)/ tsCCAOffset 366 /(2)/ tsCCA 367 /(3)/ tsRxTx 368 /(4)/ tsRxWait 369 /(5)/ tsAckWait 371 The timing parameters for the default macTimeslotTemplate 372 (macTimeslotTemplateId = 0) MUST be used when utilizing the default 373 timeslot duration. In this case, the TSCH Timeslot IE only 374 transports the macTimeslotTemplateId with value 0x00. If a timeslot 375 template other than the default is used, the EB MUST contain a 376 complete TimeSlot IE indicating the timeslot duration and the 377 corresponding timeslot timings. Note that in case of discrepancy 378 between the values in this document and the IEEE 802.15.4 379 specification [IEEE802154], the IEEE standard has precedence. 381 5. IEEE.802.15.4 Specific Header Fields and Considerations 383 The IEEE802.15.4 header of BEACON, DATA, acknowledgment, MAC COMMAND 384 frames MUST include the Sequence Number field, the Source Address 385 field and the Destination Address field. Frame Version field MUST be 386 set to 0b10 (Frame Version 2). 388 The PAN ID Compression bit in a BEACON frame MUST indicate that the 389 Source PAN ID is "Not Present" and the Destination PAN ID is 390 "Present". The source address field MUST be filled with an extended 391 address (64 bit) and this be indicated in the corresponding Frame 392 Control field. The Destination address field MUST be filled with a 393 short address (16bit) with a value of 0xffff to represent the 394 broadcast short address. 396 A Node aiming to join a network by receiving a properly formed BEACON 397 MUST use a PAN ID set to 0xffff in order meet the filtering rules in 398 the IEEE 802.15.4 specification [IEEE802154]. 400 When using DATA, ACKNOWLEDGMENT, MAC COMMAND frame types the source 401 and destination address fields MUST be filled with an extended 402 address (64 bit) and this be indicated in the corresponding Frame 403 Control field. The Destination PAN ID MUST be present, the Source 404 PAN ID MUST be elided. The PAN ID Compression field MUST indicate 405 that the Destination PAN ID is "Present" and the Source PAN ID is 406 "Not Present". According to Table 2a in the IEEE 802.15.4e 2012 407 specification document, this is accomplished by setting the PAN ID 408 Compression bit to 0b0 [IEEE802154-2012]. 410 When preparing the security header, the Absolute Sequence Number 411 (ASN) MUST be written into the Nonce in most significant byte first 412 (MSB) format as indicated in the IEEE 802.15.4 specification 413 [IEEE802154]. 415 6. Enhanced Beacons Configuration and Content 417 The IEEE 802.15.4 specification does not define how often EBs are 418 sent, nor their contents [IEEE802154]. EBs are not used for time 419 synchronization. Time synchronization is achieved via 420 acknowledgements to normal packet traffic, and keepalives. For 421 additional reference see [RFC7554] where different time 422 synchronization approaches are summarized. 424 In a minimal TSCH configuration, a node SHOULD send an EB every 425 EB_PERIOD (default value = 10s). EBs are only authenticated and 426 neither Payload IEs nor the frame payload are encrypted. 428 EBs MUST be sent as per the IEEE 802.15.4 specification and MUST 429 carry the Information Elements (IEs) listed below [IEEE802154]. 430 Refer to Appendix A.1 for an example of the Information Elements 431 Header Content. 433 Synchronization IE: Contains synchronization information such as 434 ASN and Join Priority. The value of Join Priority is discussed in 435 Section 8.2. 437 TSCH Timeslot IE: Contains the timeslot template identifier. This 438 template is used to specify the internal timing of the timeslot. 439 This specification uses the default timeslot template as defined 440 in the IEEE 802.15.4 specification [IEEE802154]. In the case that 441 a non-default timeslot template is used, the IE Content MUST 442 follow the specification as defined in [IEEE802154] . Refer to 443 Appendix A.1 for an illustrative example of non default timeslot 444 template. 446 Channel Hopping IE: Contains the channel hopping template 447 identifier. This specification uses the default channel hopping 448 template, as defined in the IEEE 802.15.4 specification 449 [IEEE802154]. The default sequence for the 2.4GHz OQPSK PHY is 450 [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10] 451 [IEEE802154]. Note however that in case of discrepancy between 452 the values in this document and [IEEE802154], the IEEE standard 453 specification has preference. 455 SlotFrame and Link IE: Each node MUST indicate the schedule in 456 each EB through a SlotFrame and Link IE. This enables nodes which 457 implement the IEEE 802.15.4 specification [IEEE802154] to learn 458 the schedule used in the network as they join it. This document 459 defines the use of a single cell set at the default channel offset 460 0x00, default timeslot offset 0x00 and with linkOption 0x0F (TX, 461 RX, SHARED bits set). A node SHOULD indicate the same information 462 in the "SlotFrame and Link IE" in the EBs it sends, than the 463 "SlotFrame and Link IE" information it has received in an EB. 465 7. Acknowledgement Frames 467 Unicast frames sent to a unicast MAC destination address MUST request 468 an acknowledgment. Each acknowledgment MUST contain an ACK/NACK Time 469 Correction IE. 471 8. Neighbor information 473 The IEEE 802.15.4 specification does not define how and when each 474 node in the network keeps information about its neighbours. A node 475 SHOULD keep at least the following information in a neighbor table: 477 8.1. Neighbor Table 479 The exact format of the neighbor table is implementation-specific. 480 Future version of the 6top Protocol [draft-wang-6tisch-sublayer] MAY 481 require those information and statistics. The neighbor table SHOULD 482 contain the following information for each neighbor: 484 Neighbor statistics: 486 numTx: number of transmitted packets to that neighbor 488 numTxAck: number of transmitted packets that have been 489 acknowledged by that neighbor 490 numRx: number of received packets from that neighbor 492 The EUI64 of the neighbor. 494 Timestamp of the last frame received from that neighbor. This can 495 be based on the ASN counter or any other time base. It can be 496 used to trigger a keep-alive message. 498 Routing metric such as the RPL Rank of that neighbor. 500 A flag indicating whether this neighbor is a time source neighbor. 502 Connectivity statistics (e.g., RSSI), which can be used to 503 determine the quality of the link. 505 In addition to that information, each node in a multihop topology and 506 implementing RPL has to be able to compute some RPL Objective 507 Function (OF), taking into account the neighbor and connectivity 508 statistics. An example RPL objective function is the OF Zero as 509 described in [RFC6552] and Section 11.1.1. 511 8.2. Time Source Neighbor Selection 513 Each node MUST select at least one Time Source Neighbor among the 514 nodes in its routing parent set (e.g the RPL parent set). When a 515 node joins a network, it has no routing information. To select its 516 time source neighbor, it uses the Join Priority field in the EB, as 517 described in the IEEE 802.15.4 specification [IEEE802154]. The Sync 518 IE contains the ASN and 1 Byte field named Join Priority. The Join 519 Priority of any node MUST be based on the routing metric of the 520 network and normalized to a value between 0 and 15. In case that the 521 network uses RPL, the Join Priority of any node MUST be equivalent to 522 the result of the function DAGRank(rank)-1. The Join Priority of the 523 DAG root MUST also be equivalent to DAGRank(rank)-1. According to 524 Section 11.1.1 the DAGRank(rank(0)) = 1 and therefore the 525 DAGRank(rank(0))-1 is 0 which is compliant with the requirement of 526 Join Priority = 0 imposed by the IEEE 802.15.4 specification 527 [IEEE802154]. A lower value of the Join Priority indicates higher 528 preference to connect to that device. 530 When a RPL node joins the network, it MUST NOT send EBs before having 531 acquired a RPL Rank. This applies to other routing protocols with 532 its corresponding routing metrics. This avoids inconsistencies in 533 the time synchronization structure. As soon as a node acquires 534 routing information (e.g RPL Rank (see [RFC6550] and 535 Section 11.1.1)), it SHOULD send Enhanced Beacons including a Sync IE 536 with Join Priority field set as indicated above. If a node receives 537 EBs from different nodes with equal Join Priority, the time source 538 neighbor selection SHOULD be assessed by other metrics that can help 539 to determine the better connectivity link. Time source neighbor 540 hysteresis SHOULD be used, according to the rules defined in 541 Section 11.2.3. At any time, a node MUST maintain connectivity to at 542 least one time source neighbor. New time source neighbours MUST be 543 chosen among the neighbours in the routing parent set. 545 The decision for a node to select one Time Source Neighbor when 546 multiple EBs are received is implementation-specific. 548 For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT 549 neighbours have been received to select the best Time Source 550 Neighbor. This condition MAY apply unless a second EB is not 551 received after MAX_EB_DELAY seconds. This avoids initial hysteresis 552 when selecting a first Time Source Neighbor. 554 Optionally, some form of hysteresis SHOULD be implemented to avoid 555 frequent changes in time source neighbours. 557 9. Queues and Priorities 559 The IEEE 802.15.4 specification [IEEE802154] does not define the use 560 of queues to handle upper layer data (either application or control 561 data from upper layers). A single queue with the following rules 562 SHOULD be used: 564 A node MUST not queue frames containing higher-layer packets until 565 the node has successfully joined a network. 567 Frames generated by the IEEE 802.15.4 layer are queued with higher 568 priority than frames containing higher-layer packets. 570 Frame types BEACON and COMMAND are queued with higher priority 571 than frame types DATA and ACK. 573 One entry in the queue is reserved at all times for frames of 574 types BEACON and COMMAND frames. 576 10. Security 578 As this document refers to the interaction between Layer 3 and Layer 579 2 protocols, this interaction MUST be secured by L2 security 580 mechanisms as defined by the IEEE 802.15.4 specification 581 [IEEE802154]. Two security mechanisms are considered, authentication 582 and encryption, authentication applies to all packet content while 583 encryption applies to header IEs and MAC payload. Key distribution 584 is out of scope of this document, but examples include pre-configured 585 keys at the nodes, shared keys among peers or well-known keys. 587 The present document assumes the existence of two cryptographic keys, 588 which can be pre-configured. One of the keys (K1) is used to 589 authenticate EBs. As defined in Section 6, EBs MUST be 590 authenticated, with no payload encryption. This facilitates logical 591 segregation of distinct networks. A second key (K2) is used to 592 authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and 593 respective header IEs, with payload encryption. Depending on 594 security policy, these keys could be the same (i.e., K1=K2). 596 For early interoperability, K1 MAY be set to 36 54 69 53 43 48 20 6D 597 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15"). 599 11. RPL on TSCH 601 In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be 602 used. 604 11.1. RPL Objective Function Zero 606 If RPL is used, nodes MUST implement the RPL Objective Function Zero 607 (OF0) [RFC6552]. 609 11.1.1. Rank computation 611 The Rank computation is described at [RFC6552], Section 4.1. 613 A node Rank (see Figure 3 for an example) is computed by the 614 following equation: 616 R(N) = R(P) + rank_increment 618 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 620 Where: 622 R(N): Rank of the node. 624 R(P): Rank of the parent obtained as part of the DIO information. 626 rank_increment: The result of a function that determines the Rank 627 increment. 629 Rf (rank_factor): A configurable factor that is used to multiply 630 the effect of the link properties in the rank_increment 631 computation. A minimal configuration SHOULD set rank_factor to 1. 633 Sp (step_of_rank): (strictly positive integer) - an intermediate 634 computation based on the link properties with a certain neighbor, 635 i.e., the Expected Transmission Count (ETX) which provides an 636 average of number of packet transmissions between two nodes. ETX 637 is defined in detail by [decouto03high] and [RFC6551]. The ETX is 638 computed as the inverse of the Packet Delivery Ratio (PDR), this 639 is the number of transmitted packets, divided by the number of 640 acknowledged packets to a certain node (e.g., ETX = numTX/ 641 numTXAck). An implementation MUST follow OF0's normalization 642 guidance as discussed in Section 1 and Section 4.1 of [RFC6552], 643 maintaining Sp between MINIMUM_STEP_OF_RANK of 1 to indicate a 644 great quality and MAXIMUM_STEP_OF_RANK of 9 to indicate a really 645 poor quality, with DEFAULT_STEP_OF_RANK indicating a normal, 646 average quality. Sp SHOULD be set to (3*ETX)-2. Candidate 647 parents with ETX greater than 3 SHOULD not be selected. 649 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 650 to the step_of_rank of a preferred parent, to allow the selection 651 of an additional feasible successor. In this specification, 652 stretch_of_rank SHOULD be set to 0. 654 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 655 constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550]. 656 DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. 658 DAGRank(rank): Equivalent to the floor of "rank" as defined by 659 [RFC6550]. DAGRank(rank) = floor(rank/MinHopRankIncrease). Nodes 660 compute its DAGRank(rank) using DAGRank(R(N)). 662 Figure 3. Rank computation scenario. 664 +-------+ 665 | P | R(P) 666 | | 667 +-------+ 668 | 669 | 670 +-------+ 671 | N | R(N)=R(P) + rank_increment 672 | | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 673 +-------+ Sp= (3*ETX) - 2 675 11.1.2. Rank computation Example 677 This section illustrates with an example the use of the Objective 678 Function Zero (refer to Figure 4 for specific details). Assume the 679 following parameters: 681 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 the 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]. Routing extension headers such as RPI [RFC6550] and SRH 746 [RFC6554], and outer IP headers in case of encapsulation MUST be 747 compressed according to [I-D.ietf-6lo-routing-dispatch] and 748 [I-D.ietf-6lo-paging-dispatch]. 750 11.2.1. Mode of Operation 752 When RPL is used, nodes MUST support the non-storing ([RFC6550] 753 Section 9.7) mode of operation. The storing ([RFC6550] Section 9.8) 754 mode of operation SHOULD be supported by nodes with enough 755 capabilities. Non-storing mode of operation is the default mode that 756 a node selects when acting as a DAG root. 758 11.2.2. Trickle Timer 760 RPL signaling messages such as DIOs are sent using the Trickle 761 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 762 specification, the Trickle Timer MUST be used with the RPL defined 763 default values [RFC6550] (Section 8.3.1). For a description of the 764 Trickle timer operation see Section 4.2 on [RFC6206]. 766 11.2.3. Hysteresis 768 According to [RFC6552], [RFC6719] recommends the use of a boundary 769 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 770 when ranks are compared. When evaluating a parent that belongs to a 771 smaller path cost than the current minimum path, the candidate node 772 is selected as new parent only if the difference between the new path 773 and the current path is greater than the defined 774 PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the 775 current preferred parent. As for [RFC6719] the 776 PARENT_SWITCH_THRESHOLD SHOULD be set to 192 when ETX metric is used 777 (in the form 128*ETX), the recommendation for this document is to use 778 PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is 779 (3*ETX-2)*minHopRankIncrease, or a proportional value. This 780 mechanism is suited to deal with parent hysteresis in both cases 781 including routing parent and time source neighbor selection. 783 12. Variable Values 785 Table 2 presents the values for the variables defined in this 786 document that SHOULD be used. 788 Table 2. Recommended variable values 790 +-------------------------+-------+ 791 | Variable | Value | 792 +-------------------------+-------+ 793 | MAX_EB_DELAY | 180 | 794 +-------------------------+-------+ 795 | NUM_NEIGHBOURS_TO_WAIT | 2 | 796 +-------------------------+-------+ 797 | PARENT_SWITCH_THRESHOLD | 640 | 798 +-------------------------+-------+ 800 13. IANA Considerations 802 This document requests no immediate action by IANA. 804 14. Acknowledgements 806 The authors would like to acknowledge the guidance and input provided 807 by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola 808 Accettura, Malisa Vucinic and for the exhaustive and detailed review 809 of the examples section to Simon Duquennoy, Guillaume Gaillard, 810 Tengfei Chang and Jonathan Munoz. Also our acknowledge to the 6TiSCH 811 Chairs Pascal Thubert and Thomas Watteyne for their guidance and 812 advice. 814 15. References 816 15.1. Normative References 818 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 819 Hysteresis Objective Function", RFC 6719, 820 DOI 10.17487/RFC6719, September 2012, 821 . 823 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 824 Bormann, "Neighbor Discovery Optimization for IPv6 over 825 Low-Power Wireless Personal Area Networks (6LoWPANs)", 826 RFC 6775, DOI 10.17487/RFC6775, November 2012, 827 . 829 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 830 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 831 DOI 10.17487/RFC6282, September 2011, 832 . 834 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 835 Routing Header for Source Routes with the Routing Protocol 836 for Low-Power and Lossy Networks (RPL)", RFC 6554, 837 DOI 10.17487/RFC6554, March 2012, 838 . 840 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 841 Power and Lossy Networks (RPL) Option for Carrying RPL 842 Information in Data-Plane Datagrams", RFC 6553, 843 DOI 10.17487/RFC6553, March 2012, 844 . 846 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 847 Protocol for Low-Power and Lossy Networks (RPL)", 848 RFC 6552, DOI 10.17487/RFC6552, March 2012, 849 . 851 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 852 and D. Barthel, "Routing Metrics Used for Path Calculation 853 in Low-Power and Lossy Networks", RFC 6551, 854 DOI 10.17487/RFC6551, March 2012, 855 . 857 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 858 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 859 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 860 Low-Power and Lossy Networks", RFC 6550, 861 DOI 10.17487/RFC6550, March 2012, 862 . 864 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 865 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 866 March 2011, . 868 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 869 "Transmission of IPv6 Packets over IEEE 802.15.4 870 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 871 . 873 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 874 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 875 December 1998, . 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, 879 DOI 10.17487/RFC2119, March 1997, 880 . 882 [I-D.ietf-6lo-routing-dispatch] 883 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 884 "6LoWPAN Routing Header", draft-ietf-6lo-routing- 885 dispatch-05 (work in progress), February 2016. 887 [I-D.ietf-6lo-paging-dispatch] 888 Thubert, P., "6LoWPAN Paging Dispatch", draft-ietf-6lo- 889 paging-dispatch-01 (work in progress), January 2016. 891 [IEEE802154-2012] 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, June 2011 as amended by IEEE std. 897 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 898 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 899 2012. 901 [IEEE802154] 902 IEEE standard for Information Technology, "IEEE standard 903 for Information Technology, IEEE std. 802.15.4, Part. 904 15.4: Wireless Medium Access Control (MAC) and Physical 905 Layer (PHY) Specifications for Low-Rate Wireless Personal 906 Area Networks". 908 15.2. Informative References 910 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 911 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 912 Internet of Things (IoT): Problem Statement", RFC 7554, 913 DOI 10.17487/RFC7554, May 2015, 914 . 916 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 917 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 918 2014, . 920 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 921 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 922 2003, . 924 [I-D.ietf-6tisch-terminology] 925 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 926 "Terminology in IPv6 over the TSCH mode of IEEE 927 802.15.4e", draft-ietf-6tisch-terminology-06 (work in 928 progress), November 2015. 930 [I-D.ietf-6tisch-architecture] 931 Thubert, P., "An Architecture for IPv6 over the TSCH mode 932 of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work 933 in progress), November 2015. 935 15.3. External Informative References 937 [draft-wang-6tisch-sublayer] 938 IETF, "6TiSCH Operation Sublayer (6top) (work in 939 progress)", Nov 2015. 941 [decouto03high] 942 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 943 High-Throughput Path Metric for Multi-Hop Wireless 944 Routing", ACM International Conference on Mobile Computing 945 and Networking (MobiCom) , June 2003. 947 [CCM] National Institute of Standards and Technology, 948 "Recommendation for Block Cipher Modes of Operation: The 949 CCM Mode for Authentication and Confidentiality. SP 950 800-38C", May 2004. 952 [CCM-Star] 953 Struik, R., "Formal Specification of the CCM* Mode of 954 Operation, IEEE P802.15 Working Group for Wireless 955 Personal Area Networks (WPANs).", September 2005. 957 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 958 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 959 a Standards-Based Low-Power Wireless Development 960 Environment", Transactions on Emerging Telecommunications 961 Technologies , August 2012. 963 Appendix A. Examples 965 Several examples are provided to illustrate the content of the 966 packets used by the minimal configuration as proposed by this 967 document. Each example follows the same structure presenting first a 968 schematic header diagram, then the LSB stream of bytes that conform 969 the header and finally a description of each of the IEs that form the 970 packet. The packet formats are specific for the [IEEE802154-2012] 971 revision and may vary in future releases of the IEEE standard. In 972 case of differences between the packet content presented in this 973 section and the [IEEE802154-2012], the latter has precedence. 975 The MAC header fields are described in a specific order. All field 976 formats in this examples are depicted in the order in which they are 977 transmitted by the PHY, from left to right, where the leftmost bit is 978 transmitted first in time. Bits within each field are numbered from 979 0 (leftmost and least significant) to k - 1 (rightmost and most 980 significant), where the length of the field is k bits. Fields that 981 are longer than a single octet are sent to the PHY in the order from 982 the octet containing the lowest numbered bits to the octet containing 983 the highest numbered bits, hence little endian ordering. 985 A.1. Example 1. Information Elements in EBs 987 Mandatory content for the EB as proposed by this draft. The example 988 uses a slotframe of 101 slots. Figure 5 represents schematically the 989 Header IE and Payload IE content of an EB. 991 Figure 5. Example of the IEs as proposed by this draft. 993 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Len3 = 6 |Sub ID = 0x1a|0| ASN 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 ASN | Join Priority | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 Stream of bytes (in little-endian ordering) that derive 1014 from the previous schematic header: 1016 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 1017 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F 1019 Description of the IE fields in the example: 1021 #Header IE Header 1022 Len1 = Header IE Length (0) 1023 Element ID = 0x7e - termination IE indicating Payload IE coming next 1024 Type 0 1025 #Payload IE Header (MLME) 1026 Len2 = Payload IE Len (26 Bytes) 1027 GroupID = 1 MLME (Nested) 1028 Type = 1 1030 #MLME-SubIE TSCH Synchronization 1031 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 1032 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 1033 Type = Short (0) 1034 ASN = Absolute Sequence Number (5 Bytes) 1035 Join Priority = 1 Byte 1037 #MLME-SubIE TSCH TimeSlot 1038 Len4 = Length in bytes of the sub-IE payload (1 Byte) 1039 SubID = 0x1c (MLME-SubIE Timeslot) 1040 Type = Short (0) 1041 TimeSlot template ID = 0x00 (default) 1043 #MLME-SubIE Ch. Hopping 1044 Len5 = Length in bytes of the sub-IE payload (1 Byte) 1045 SubID = 0x09 (MLME-SubIE Ch. Hopping) 1046 Type = Long (1) 1047 Channel Hopping Sequence ID = 0x00 (default) 1049 #MLME-SubIE TSCH Slotframe and Link 1050 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 1051 SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 1052 Type = Short (0) 1053 Number of slotframes = 0x01 1054 SlotFrame Handle = 0x00 1055 SlotFrame Size = 101 slots (0x65) 1056 Number of Links = 0x01 1057 Timeslot = 0x0000 (2B) 1058 Channel Offset = 0x0000 (2B) 1059 Link Option = 0x0F (tx,rx,shared,timekeeping) 1061 A.2. Example 2. Information Elements in EBs not using default timeslot 1062 template 1064 Using a non-default timeslot template in EBs. Timeslot length set to 1065 15ms instead of the 10ms default. Refer to Figure 6 for the specific 1066 IE fields. 1068 Figure 6. Example of a non-default timeslot template in EB. 1070 Schematic representation of the IE header in an EB: 1072 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Len3 = 6 |Sub ID = 0x1a|0| ASN 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 ASN | Join Priority | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 = 2700 | macTsCCA = 128 | macTsTxOffset 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 = 3300 | macTsAckWait = 600 | macTsRxTx 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 = 192 | macTsMaxAck = 2400 | macTsMaxTx 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 Stream of bytes (in little-endian ordering) that derive 1099 from the previous schematic header: 1101 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 1102 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 1103 00 0A ... 1105 Description of the IE fields in the example: 1107 #Header IE Header 1108 Len1 = Header IE Length (none) 1109 Element ID = 0x7e - termination IE indicating Payload IE coming next 1110 Type 0 1112 #Payload IE Header (MLME) 1113 Len2 = Payload IE Len (53 Bytes) 1114 GroupID = 1 MLME (Nested) 1115 Type = 1 1117 #MLME-SubIE TSCH Synchronization 1118 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 1119 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 1120 Type = Short (0) 1121 ASN = Absolute Sequence Number (5 Bytes) 1122 Join Priority = 1 Byte 1124 #MLME-SubIE TSCH TimeSlot 1125 Len4 = Length in bytes of the sub-IE payload (25 Bytes) 1126 SubID = 0x1c (MLME-SubIE Timeslot) 1127 Type = Short (0) 1128 TimeSlot template ID = 0x01 (non-default) 1130 Example timeslot timing using 15ms timeslot. 1131 +--------------------------------+------------+ 1132 | IEEE802.15.4 TSCH parameter | Value (us) | 1133 +--------------------------------+------------+ 1134 | tsCCAOffset | 2700 | 1135 +--------------------------------+------------+ 1136 | tsCCA | 128 | 1137 +--------------------------------+------------+ 1138 | tsTxOffset | 3180 | 1139 +--------------------------------+------------+ 1140 | tsRxOffset | 1680 | 1141 +--------------------------------+------------+ 1142 | tsRxAckDelay | 1200 | 1143 +--------------------------------+------------+ 1144 | tsTxAckDelay | 1500 | 1145 +--------------------------------+------------+ 1146 | tsRxWait | 3300 | 1147 +--------------------------------+------------+ 1148 | tsAckWait | 600 | 1149 +--------------------------------+------------+ 1150 | tsRxTx | 192 | 1151 +--------------------------------+------------+ 1152 | tsMaxAck | 2400 | 1153 +--------------------------------+------------+ 1154 | tsMaxTx | 4256 | 1155 +--------------------------------+------------+ 1156 | Timeslot duration | 15000 | 1157 +--------------------------------+------------+ 1159 #MLME-SubIE Ch. Hopping 1160 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 1161 SubID = 0x09 (MLME-SubIE Ch. Hopping) 1162 Type = Long (1) 1163 Channel Hopping Sequence ID = 0x00 (default) 1165 A.3. Example 3. Information Elements in ACKs 1167 Acknowledgement packets carry the ACK/NACK Time Correction IE (Header 1168 IE). Figure 7 illustrates the IE format as specified in 1169 [IEEE802154-2012]. 1171 Figure 7. Acknowledgement packet IE content. 1173 1 2 3 1174 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 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 Stream of bytes (in little-endian ordering) that derive 1180 from the previous schematic header: 1182 02 0F TS#0 TS#1 1184 Description of the IE fields in the example: 1186 #Header IE Header 1187 Len1 = Header IE Length (2 Bytes) 1188 Element ID = 0x1e - ACK/NACK Time Correction IE 1189 Type 0 1191 A.4. Example 4. Auxiliary Security Header 1193 Figure 8 illustrates the content of the Auxiliary Security Header as 1194 mandated by this document, if security is enabled. Security Level in 1195 the example is set to ENC-MIC-32 (5). 1197 Figure 8. Example auxiliary security header. 1199 1 1200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 |L = 5|M=1|1|1|0|Key Index = IDX| 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 Stream of bytes (in LSB format) that derive from the previous 1206 schematic header: 1208 6D IDX#0 1210 Description of the Security Auxiliary Header fields in the example: 1212 #Security Control (1 byte) 1213 L = Security Level ENC-MIC-32 (5) 1214 M = Key Identifier Mode (0x01) 1215 Frame Counter Suppression = 1 (omitting Frame Counter field) 1216 Frame Counter Size = 1 (construct Nonce from 5 byte ASN) 1217 Reserved = 0 1219 #Key Identifier (1 byte) 1220 Key Index = IDX (deployment-specific KeyIndex parameter that 1221 identifies the cryptographic key) 1223 Authors' Addresses 1225 Xavier Vilajosana (editor) 1226 Universitat Oberta de Catalunya 1227 156 Rambla Poblenou 1228 Barcelona, Catalonia 08018 1229 Spain 1231 Phone: +34 (646) 633 681 1232 Email: xvilajosana@uoc.edu 1234 Kris Pister 1235 University of California Berkeley 1236 490 Cory Hall 1237 Berkeley, California 94720 1238 USA 1240 Email: pister@eecs.berkeley.edu