idnits 2.17.1 draft-ietf-6tisch-minimal-19.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 -- The document date (January 25, 2017) is 2646 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2015' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-03 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-08 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-00 == Outdated reference: A later version (-01) exists of draft-ietf-6tisch-dtsecurity-secure-join-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH X. Vilajosana, Ed. 3 Internet-Draft Universitat Oberta de Catalunya 4 Intended status: Best Current Practice K. Pister 5 Expires: July 29, 2017 University of California Berkeley 6 T. Watteyne 7 Linear Technology 8 January 25, 2017 10 Minimal 6TiSCH Configuration 11 draft-ietf-6tisch-minimal-19 13 Abstract 15 This document describes a minimal mode of operation for a 6TiSCH 16 Network. A minimal mode of operation is a baseline set of protocols, 17 recommended configurations and modes of operation sufficient to 18 enable a 6TiSCH functional network. 6TiSCH provides IPv6 19 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh 20 composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a 21 collection of protocols with the respective configurations, including 22 the 6LoWPAN framework, enabling interoperable IPv6 connectivity over 23 IEEE Std 802.15.4 TSCH. This minimal configuration provides the 24 necessary bandwidth for network and security bootstrap, and defines 25 the proper link between the IETF protocols that interface to IEEE Std 26 802.15.4 TSCH. This minimal mode of operation should be implemented 27 by all 6TiSCH compliant devices. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 29, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. IEEE Std 802.15.4 Settings . . . . . . . . . . . . . . . . . 4 67 4.1. TSCH Schedule . . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 7 70 4.4. Timeslot Timing . . . . . . . . . . . . . . . . . . . . . 7 71 4.5. Frame Contents . . . . . . . . . . . . . . . . . . . . . 7 72 4.5.1. IEEE Std 802.15.4 Header . . . . . . . . . . . . . . 7 73 4.5.2. Enhanced Beacon Frame . . . . . . . . . . . . . . . . 8 74 4.5.3. Acknowledgment Frame . . . . . . . . . . . . . . . . 9 75 4.6. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9 76 5. RPL Settings . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Objective Function . . . . . . . . . . . . . . . . . . . 10 78 5.1.1. Rank Computation . . . . . . . . . . . . . . . . . . 10 79 5.1.2. Rank Computation Example . . . . . . . . . . . . . . 11 80 5.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 12 81 5.3. Trickle Timer . . . . . . . . . . . . . . . . . . . . . . 13 82 5.4. Packet Contents . . . . . . . . . . . . . . . . . . . . . 13 83 6. Network Formation and Lifetime . . . . . . . . . . . . . . . 13 84 6.1. Value of the Join Metric Field . . . . . . . . . . . . . 13 85 6.2. Time Source Neighbor Selection . . . . . . . . . . . . . 13 86 6.3. When to Start Sending EBs . . . . . . . . . . . . . . . . 14 87 6.4. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 14 88 7. Implementation Recommendations . . . . . . . . . . . . . . . 14 89 7.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 14 90 7.2. Queues and Priorities . . . . . . . . . . . . . . . . . . 15 91 7.3. Recommended Settings . . . . . . . . . . . . . . . . . . 15 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 97 11.2. Informative References . . . . . . . . . . . . . . . . . 20 98 11.3. External Informative References . . . . . . . . . . . . 20 99 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20 100 A.1. Example: EB with Default Timeslot Template . . . . . . . 21 101 A.2. Example: EB with Custom Timeslot Template . . . . . . . 22 102 A.3. Example: Link-layer Acknowledgment . . . . . . . . . . . 24 103 A.4. Example: Auxiliary Security Header . . . . . . . . . . . 25 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 106 1. Introduction 108 A 6TiSCH Network provides IPv6 connectivity [RFC2460] over a Time 109 Synchronized Channel Hopping (TSCH) mesh [RFC7554] composed of IEEE 110 Std 802.15.4 TSCH links [IEEE802154-2015]. IPv6 connectivity is 111 obtained by the use of the 6LoWPAN framework ([RFC4944], [RFC6282], 112 [RFC8025],[I-D.ietf-6lo-routing-dispatch] and [RFC6775]), RPL 113 [RFC6550], and its Objective Function 0 (OF0) [RFC6552]. 115 This specification defines operational parameters and procedures for 116 a minimal mode of operation to build a 6TiSCH Network. Any 6TiSCH 117 compliant device SHOULD implement this mode of operation. This 118 operational parameter configuration provides the necessary bandwidth 119 for nodes to bootstrap the network. The bootstrap process includes 120 initial network configuration and security bootstrap. In this 121 specification, the 802.15.4 TSCH mode, the 6LoWPAN framework, RPL 122 [RFC6550], and its Objective Function 0 (OF0) [RFC6552] are used 123 unmodified. Parameters and particular operations of TSCH are 124 specified to guarantee interoperability between nodes in a 6TiSCH 125 Network. RPL is specified to provide the framework for time 126 synchronization in an 802.15.4 TSCH network. The specifics for 127 interoperable interaction between RPL and TSCH are described. 129 In a 6TiSCH network, nodes follow a communication schedule as per 130 802.15.4 TSCH. In it, nodes learn the schedule of the network when 131 joining. When following this specification, the learned schedule is 132 the same for all nodes and does not change over time. Future 133 specifications may define mechanisms for dynamically managing the 134 communication schedule. Dynamic scheduling solutions are out of 135 scope of this document. 137 IPv6 addressing and compression are achieved by the 6LoWPAN 138 framework. The framework includes [RFC4944], [RFC6282], [RFC8025], 139 the 6LoWPAN Routing Header dispatch [I-D.ietf-6lo-routing-dispatch] 140 for addressing and header compression, and [RFC6775] for duplicate 141 address detection (DAD) and address resolution. 143 More advanced work is expected in the future to complement the 144 Minimal Configuration with dynamic operations that can adapt the 145 schedule to the needs of the traffic at run time. 147 2. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 3. Terminology 155 This document uses terminology from [I-D.ietf-6tisch-terminology]. 156 The following concepts are used in this document: 158 802.15.4: We use "802.15.4" as a short version of "IEEE Std 159 802.15.4" in this document. 161 SFD: Start of Frame Delimiter. 163 RX: Reception. 165 TX: Transmission. 167 Join Metric: Field in the TSCH Synchronization IE. Number of hops 168 separating the node sending the EB, and the PAN coordinator. 170 4. IEEE Std 802.15.4 Settings 172 An implementation compliant to this specification MUST implement IEEE 173 Std 802.15.4 [IEEE802154-2015] in "timeslotted channel hopping" 174 (TSCH) mode. 176 The remainder of this section details the RECOMMENDED TSCH settings, 177 which are summarized in Figure 1. A node MAY use different values. 178 Any of the properties marked in the EB column are announced in the 179 Enhanced Beacons (EB) the nodes send [IEEE802154-2015] and learned by 180 those joining the network. Changing their value hence means changing 181 the contents of the EB. 183 In case of discrepancy between the values in this specification and 184 IEEE Std 802.15.4 [IEEE802154-2015], the IEEE standard has 185 precedence. 187 +--------------------------------+------------------------------+---+ 188 | Property | Recommended Setting |EB*| 189 +--------------------------------+------------------------------+---+ 190 | Slotframe Size | Tunable. Trades-off | X | 191 | | bandwidth against energy. | | 192 +--------------------------------+------------------------------+---+ 193 | Number of scheduled cells | 1 (slotOffset 0x0000) | X | 194 | (active) | (chOffset 0x0000) | | 195 | | (link Option 0x0f) | | 196 | | (LinkType ADVERTISING) | | 197 +--------------------------------+------------------------------+---+ 198 | Number of unscheduled cells | All remaining cells in the | X | 199 | (off) | slotframe | | 200 +--------------------------------+------------------------------+---+ 201 | Max Number MAC retransmissions | 3 (4 transmission attempts) | | 202 +--------------------------------+------------------------------+---+ 203 | Timeslot template | IEEE Std 802.15.4 default | X | 204 | | (macTimeslotTemplateId=0) | | 205 +--------------------------------+------------------------------+---+ 206 | Enhanced Beacon Period | Tunable. Trades-off join | | 207 | (EB_PERIOD) | time against energy. | | 208 +--------------------------------+------------------------------+---+ 209 | Number used frequencies | IEEE Std 802.15.4 default | X | 210 | (2.4 GHz O-QPSK PHY) | (16) | | 211 +--------------------------------+------------------------------+---+ 212 | Channel Hopping sequence | IEEE Std 802.15.4 default | X | 213 | (2.4 GHz O-QPSK PHY) | (macHoppingSequenceID = 0) | | 214 +--------------------------------+------------------------------+---+ 215 * an "X" in this column means this property's value is announced in 216 the EB; a new node hence learns it when joining. 218 Figure 1: Recommended IEEE Std 802.15.4 TSCH Settings. 220 4.1. TSCH Schedule 222 This minimal mode of operation uses a single slotframe. The TSCH 223 slotframe is composed of a tunable number of timeslots. The 224 slotframe size (i.e. the number of timeslots it contains) trades off 225 bandwidth for energy consumption. The slotframe size needs to be 226 tuned; the way of tuning it is out of scope of this specification. 227 The slotframe size is announced in the EB. The RECOMMENDED value for 228 the slotframe handle (macSlotframeHandle) is 0x00. An implementation 229 MAY choose to use a different slotframe handle, for example to add 230 other slotframes with higher priority. The use of other slotframes 231 is out of the scope of this document. 233 There is only a single scheduled cell in the slotframe. This cell 234 MAY be scheduled at any slotOffset/channelOffset within the 235 slotframe. The location of that cell in the schedule is announced in 236 the EB. The LinkType of the scheduled cell is ADVERTISING to allow 237 EBs to be sent on it. 239 Figure 2 shows an example of a slotframe of length 101 timeslots, 240 resulting in a radio duty cycle below 0.99%. 242 Chan. +----------+----------+ +----------+ 243 Off.0 | TxRxS/EB | OFF | | OFF | 244 Chan. +----------+----------+ +----------+ 245 Off.1 | OFF | OFF | ... | OFF | 246 +----------+----------+ +----------+ 247 . 248 . 249 . 250 Chan. +----------+----------+ +----------+ 251 Off.15 | OFF | OFF | | OFF | 252 +----------+----------+ +----------+ 254 slotOffset 0 1 100 256 EB: Enhanced Beacon 257 Tx: Transmit 258 Rx: Receive 259 S: Shared 260 OFF: Unscheduled by this specification 262 Figure 2: Example slotframe of length 101 timeslots. 264 A node MAY use the scheduled cell to transmit/receive all types of 265 link-layer frames. EBs are sent to the link-layer broadcast address, 266 and not acknowledged. Data frames are sent unicast, and acknowledged 267 by the receiving neighbor. 269 All remaining cells in the slotframe are unscheduled. Dynamic 270 scheduling solutions may be defined in the future which schedule 271 those cells. One example is the 6top Protocol (6P) 272 [I-D.ietf-6tisch-6top-protocol]. Dynamic scheduling solutions are 273 out of scope of this document. 275 The default values of the TSCH Timeslot template (defined in 276 [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence 277 (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. A node 278 MAY use different values by properly announcing them in its Enhanced 279 Beacon. 281 4.2. Cell Options 283 In the scheduled cell, a node transmits if there is a packet to 284 transmit, listens otherwise (both "TX" and "RX" bits are set). When 285 a node transmits, requesting a link-layer acknowledgment per 286 [IEEE802154-2015], and does not receive it, it uses a back-off 287 mechanism to resolve possible collisions ("Shared" bit is set). A 288 node joining the network maintains time synchronization to its 289 initial time source neighbor using that cell ("Timekeeping" bit is 290 set). 292 This translates into a Link Option for this cell of value 0x0f: 294 b0 = TX Link = 1 (set) 295 b1 = RX Link = 1 (set) 296 b2 = Shared Link = 1 (set) 297 b3 = Timekeeping = 1 (set) 298 b4 = Priority = 0 (clear) 299 b5-b7 = Reserved = 0 (clear) 301 4.3. Retransmissions 303 Per Figure 1, the RECOMMENDED maximum number of link-layer 304 retransmissions is 3. This means that, for packets requiring an 305 acknowledgment, if none are received after a total of 4 attempts, the 306 transmission is considered failed and the link layer MUST notify the 307 upper layer. Packets not requiring an acknowledgment (including EBs) 308 are not retransmitted. 310 4.4. Timeslot Timing 312 Per Figure 1, the RECOMMENDED timeslot template is the default one 313 (macTimeslotTemplateId=0) defined in [IEEE802154-2015]. 315 4.5. Frame Contents 317 [IEEE802154-2015] defines the format of frames. Through a set of 318 flags, [IEEE802154-2015] allows for several fields to be present or 319 not, to have different lengths, and to have different values. This 320 specification details the RECOMMENDED contents of 802.15.4 frames, 321 while strictly complying to [IEEE802154-2015]. 323 4.5.1. IEEE Std 802.15.4 Header 325 The Frame Version field SHOULD be set to 0b10 (Frame Version 2). The 326 Sequence Number field MAY be elided. 328 EB Destination Address field SHOULD be set to 0xFFFF (short broadcast 329 address). The EB Source Address field SHOULD be set as the node's 330 short address if this is supported. Otherwise the long address 331 SHOULD be used. 333 The PAN ID Compression bit SHOULD indicate that the Source PAN ID is 334 "Not Present" and the Destination PAN ID is "Present". The value of 335 the PAN ID Compression bit is specified in Table 7-2 of the IEEE Std 336 802.15.4-2015 specification, and depends on the type of the 337 destination and source link-layer addresses (short, extended, not 338 present). 340 Nodes follow the reception and rejection rules as per Section 6.7.2 341 of [IEEE802154-2015]. 343 The Nonce is formatted according to [IEEE802154-2015]. In the IEEE 344 Std 802.15.4 specification [IEEE802154-2015], nonce generation is 345 described in Section 9.3.2.2, and byte ordering in Section 9.3.1, 346 Annex B.2 and Annex B.2.2. 348 4.5.2. Enhanced Beacon Frame 350 After booting, a TSCH node starts in an unsynchronized, unjoined 351 state. Initial synchronization is achieved by listening for EBs. 352 EBs from multiple networks may be heard. Many mechanisms exist for 353 discrimination between networks, the details of which are out of 354 scope. 356 The IEEE Std 802.15.4 specification does not define how often EBs are 357 sent, nor their contents [IEEE802154-2015]. In a minimal TSCH 358 configuration, a node SHOULD send an EB every EB_PERIOD. Tuning 359 EB_PERIOD allows a trade-off between joining time and energy 360 consumption. 362 EBs SHOULD be used to obtain information about local networks, and to 363 synchronize ASN and time offset of the specific network that the node 364 decides to join. Once joined to a particular network, a node MAY 365 choose to continue to listen for EBs, to gather more information 366 about other networks, for example. During the joining process, 367 before secure connections to time parents have been created, it MAY 368 be necessary for a node to maintain synchronization using EBs. 369 [RFC7554] discusses different time synchronization approaches. 371 EBs MUST be sent as per the IEEE Std 802.15.4 specification and 372 SHOULD carry the Information Elements (IEs) listed below 373 [IEEE802154-2015]. 375 TSCH Synchronization IE: Contains synchronization information such 376 as ASN and Join Metric. The value of the Join Metric field is 377 discussed in Section 6.1. 379 TSCH Timeslot IE: Contains the timeslot template identifier. This 380 template is used to specify the internal timing of the timeslot. 381 This specification RECOMMENDS the default timeslot template. 383 Channel Hopping IE: Contains the channel hopping sequence 384 identifier. This specification RECOMMENDS the default channel 385 hopping sequence. 387 TSCH Slotframe and Link IE: Enables joining nodes to learn the 388 initial schedule to be used as they join the network. This 389 document RECOMMENDS the use of a single cell. 391 If a node strictly follows the recommended setting from Figure 1, the 392 EB it sends has the exact same contents as an EB it has received when 393 joining, except for the Join Metric field in the TSCH Synchronization 394 IE. 396 4.5.3. Acknowledgment Frame 398 Per [IEEE802154-2015], each acknowledgment contain an ACK/NACK Time 399 Correction IE. 401 4.6. Link-Layer Security 403 When securing link-layer frames, link-layer frames MUST be secured by 404 the link-layer security mechanisms defined in IEEE Std 802.15.4 405 [IEEE802154-2015]. Link-layer authentication MUST be applied to the 406 entire frame, including the 802.15.4 header. Link-layer encryption 407 MAY be applied to 802.15.4 payload IEs and the 802.15.4 payload. 409 This specification assumes the existence of two cryptographic keys: 411 Key K1 is used to authenticate EBs. As defined in Section 4.5.2, 412 EBs MUST be authenticated only (no encryption). 414 Key K2 is used to authenticate and encrypt DATA and ACKNOWLEDGMENT 415 frames. 417 These keys can be pre-configured, or learned during a key 418 distribution phase. Key distribution mechanisms are defined for 419 example in [I-D.ietf-6tisch-minimal-security] and 420 [I-D.ietf-6tisch-dtsecurity-secure-join]. Key distribution is out of 421 scope of this document. 423 The behavior of a Joining Node (JN) is different depending on which 424 key(s) are pre-configured: 426 If both keys K1 and K2 are pre-configured, the JN does not rely on 427 a key distribution phase to learn K1 or K2. 429 If key K1 is pre-configured but not key K2, the JN authenticates 430 EBs using K1, and relies on the key distribution phase to learn 431 K2. 433 If neither key K1 nor key K2 is pre-configured, the JN uses the 434 secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process 435 EBs, and relies on the key distribution phase to learn K1 and K2. 436 Once K1 and K2 are learned, the secExempt mechanism MUST be 437 disabled and EBs properly authenticated using K1. 439 In the event of a network reset, the new network MUST either use new 440 cryptographic keys, or ensure that the ASN remains monotonically 441 increasing. 443 5. RPL Settings 445 In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be 446 used. 448 5.1. Objective Function 450 If RPL is used, nodes MUST implement the RPL Objective Function Zero 451 (OF0) [RFC6552]. 453 5.1.1. Rank Computation 455 The Rank computation is described at [RFC6552], Section 4.1. A 456 node's Rank (see Figure 4 for an example) is computed by the 457 following equations: 459 R(N) = R(P) + rank_increment 461 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 463 Figure 3 lists the OF0 parameter values that MUST be used if RPL is 464 used. 466 +----------------------+-------------------------------------+ 467 | OF0 Parameters | Value | 468 +----------------------+-------------------------------------+ 469 | Rf | 1 | 470 +----------------------+-------------------------------------+ 471 | Sp | (3*ETX)-2 | 472 +----------------------+-------------------------------------+ 473 | Sr | 0 | 474 +----------------------+-------------------------------------+ 475 | MinHopRankIncrease | DEFAULT_MIN_HOP_RANK_INCREASE (256) | 476 +----------------------+-------------------------------------+ 477 | MINIMUM_STEP_OF_RANK | 1 | 478 +----------------------+-------------------------------------+ 479 | MAXIMUM_STEP_OF_RANK | 9 | 480 +----------------------+-------------------------------------+ 481 | ETX limit to select | 3 | 482 | a parent | | 483 +----------------------+-------------------------------------+ 485 Figure 3: OF0 parameters. 487 The step_of_rank (Sp) uses Expected Transmission Count (ETX) 488 [RFC6551]. 490 An implementation MUST follow OF0's normalization guidance as 491 discussed in Section 1 and Section 4.1 of [RFC6552]. Sp SHOULD be 492 calculated as (3*ETX)-2. The minimum value of Sp 493 (MINIMUM_STEP_OF_RANK) indicates a good quality link. The maximum 494 value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor quality link. 495 The default value of Sp (DEFAULT_STEP_OF_RANK) indicates an average 496 quality link. Candidate parents with ETX greater than 3 SHOULD NOT 497 be selected. This avoids having ETX values on used links which are 498 larger that the maximum allowed transmission attempts. 500 5.1.2. Rank Computation Example 502 This section illustrates the use of the Objective Function Zero (see 503 Figure 4). We have: 505 rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512 506 +-------+ 507 | 0 | R(minHopRankIncrease) = 256 508 | | DAGRank(R(0)) = 1 509 +-------+ 510 | 511 | 512 +-------+ 513 | 1 | R(1)=R(0) + 512 = 768 514 | | DAGRank(R(1)) = 3 515 +-------+ 516 | 517 | 518 +-------+ 519 | 2 | R(2)=R(1) + 512 = 1280 520 | | DAGRank(R(2)) = 5 521 +-------+ 522 | 523 | 524 +-------+ 525 | 3 | R(3)=R(2) + 512 = 1792 526 | | DAGRank(R(3)) = 7 527 +-------+ 528 | 529 | 530 +-------+ 531 | 4 | R(4)=R(3) + 512 = 2304 532 | | DAGRank(R(4)) = 9 533 +-------+ 534 | 535 | 536 +-------+ 537 | 5 | R(5)=R(4) + 512 = 2816 538 | | DAGRank(R(5)) = 11 539 +-------+ 541 Figure 4: Rank computation example for 5-hop network where numTx=100 542 and numTxAck=75 for all links. 544 5.2. Mode of Operation 546 When RPL is used, nodes MUST implement the non-storing ([RFC6550] 547 Section 9.7) mode of operation. The storing ([RFC6550] Section 9.8) 548 mode of operation SHOULD be implemented by nodes with enough 549 capabilities. Nodes not implementing RPL MUST join as leaf nodes. 551 5.3. Trickle Timer 553 RPL signaling messages such as DIOs are sent using the Trickle 554 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206] (Section 4.2). For 555 this specification, the Trickle Timer MUST be used with the RPL 556 defined default values [RFC6550] (Section 8.3.1). 558 5.4. Packet Contents 560 RPL information and hop-by-hop extension headers MUST follow 561 [RFC6553] and [RFC6554]. In the case the packets formed at the LLN 562 need to cross through intermediate routers, these MUST follow the IP- 563 in-IP encapsulation requirement specified by the [RFC6282] and 564 [RFC2460]. Routing extension headers such as RPI [RFC6550] and SRH 565 [RFC6554], and outer IP headers in case of encapsulation MUST be 566 compressed according to [I-D.ietf-6lo-routing-dispatch] and 567 [RFC8025]. 569 6. Network Formation and Lifetime 571 6.1. Value of the Join Metric Field 573 The Join Metric of the TSCH Synchronization IE in the EB MUST be 574 calculated based on the routing metric of the node, normalized to a 575 value between 0 and 255. A lower value of the Join Metric indicates 576 the node sending the EB is topologically "closer" to the root of the 577 network. A lower value of the Join Metric hence indicates higher 578 preference for a joining node to synchronize to that neighbor. 580 In case the network uses RPL, the Join Metric of any node (including 581 the DAG root) MUST be set to DAGRank(rank)-1. According to 582 Section 5.1.1, DAGRank(rank(0)) = 1. DAGRank(rank(0))-1 = 0 is 583 compliant with 802.15.4's requirement of having the root use Join 584 Metric = 0. 586 In case the network does not use RPL, the Join Metric value SHOULD 587 follow the rules specified by [IEEE802154-2015]. 589 6.2. Time Source Neighbor Selection 591 When a node joins a network, it may hear EBs sent by different nodes 592 already in the network. The decision of which neighbor to 593 synchronize to (e.g. which neighbor becomes the node's initial time 594 source neighbor) is implementation-specific. For example, after 595 having received the first EB, a node MAY listen for at most 596 MAX_EB_DELAY seconds until it has received EBs from 597 NUM_NEIGHBOURS_TO_WAIT distinct neighbors. When receiving EBs from 598 distinct neighbors, the node MAY use the Join Metric field in each EB 599 to select the initial time source neighbor, as described in IEEE Std 600 802.15.4 [IEEE802154-2015], Section 6.3.6. 602 At any time, a node MUST maintain connectivity to at least one time 603 source neighbor. A node's time source neighbor MUST be chosen among 604 the neighbors in its RPL routing parent set. 606 6.3. When to Start Sending EBs 608 When a RPL node joins the network, it MUST NOT send EBs before having 609 acquired a RPL Rank to avoid inconsistencies in the time 610 synchronization structure. This applies to other routing protocols 611 with their corresponding routing metrics. As soon as a node acquires 612 routing information (e.g. a RPL Rank, see Section 5.1.1), it SHOULD 613 start sending Enhanced Beacons. 615 6.4. Hysteresis 617 Per [RFC6552] and [RFC6719], the specification RECOMMENDS the use of 618 a boundary value (PARENT_SWITCH_THRESHOLD) to avoid constant changes 619 of parent when ranks are compared. When evaluating a parent that 620 belongs to a smaller path cost than the current minimum path, the 621 candidate node is selected as new parent only if the difference 622 between the new path and the current path is greater than the defined 623 PARENT_SWITCH_THRESHOLD. Otherwise, the node MAY continue to use the 624 current preferred parent. Per [RFC6719], the PARENT_SWITCH_THRESHOLD 625 SHOULD be set to 192 when ETX metric is used (in the form 128*ETX), 626 the recommendation for this document is to use 627 PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is 628 ((3*ETX)-2)*minHopRankIncrease, or a proportional value. This deals 629 with hysteresis both for routing parent and time source neighbor 630 selection. In case a node has a security association with its 631 parent, including routing parent or time source neighbor, the node 632 SHOULD be allowed to keep the association despite of fluctuations of 633 the rank. 635 7. Implementation Recommendations 637 7.1. Neighbor Table 639 The exact format of the neighbor table is implementation-specific. 640 The RECOMMENDED per-neighbor information is (taken from the [openwsn] 641 implementation): 643 identifier: Identifier(s) of the neighbor (e.g. EUI-64). 645 numTx: Number of link-layer transmission attempts to that 646 neighbor. 648 numTxAck: Number of transmitted link-layer frames that have been 649 link-layer acknowledged by that neighbor. 651 numRx: Number of link-layer frames received from that neighbor. 653 timestamp: When the last frame was received from that neighbor. 654 This can be based on the ASN counter or any other time 655 base. It can be used to trigger a keep-alive message. 657 routing metric: Such as the RPL Rank of that neighbor. 659 time source neighbor: A flag indicating whether this neighbor is a 660 time source neighbor. 662 7.2. Queues and Priorities 664 The IEEE Std 802.15.4 specification [IEEE802154-2015] does not define 665 the use of queues to handle upper layer data (either application or 666 control data from upper layers). The following rules are 667 RECOMMENDED: 669 A node is configured to keep in the queues a configurable number 670 of Upper Layer packets per link (default NUM_UPPERLAYER_PACKETS) 671 for a configurable time that should cover the join process 672 (default MAX_JOIN_TIME). 674 Frames generated by the 802.15.4 layer (including EBs) are queued 675 with a priority higher than frames coming from higher-layers. 677 Frame type BEACON is queued with higher priority than frame types 678 DATA. 680 One entry in the queue is reserved at all times for frames of type 681 BEACON. 683 7.3. Recommended Settings 685 Figure 5 lists RECOMMENDED values for the settings discussed in this 686 specification. 688 +-------------------------+-------------------+ 689 | Parameter | RECOMMENDED Value | 690 +-------------------------+-------------------+ 691 | MAX_EB_DELAY | 180 | 692 +-------------------------+-------------------+ 693 | NUM_NEIGHBOURS_TO_WAIT | 2 | 694 +-------------------------+-------------------+ 695 | PARENT_SWITCH_THRESHOLD | 640 | 696 +-------------------------+-------------------+ 697 | NUM_UPPERLAYER_PACKETS | 1 | 698 +-------------------------+-------------------+ 699 | MAX_JOIN_TIME | 300 | 700 +-------------------------+-------------------+ 702 Figure 5: Recommended Settings. 704 8. Security Considerations 706 This document is concerned only with link-layer security. 708 By their nature, many IoT networks have nodes in physically 709 vulnerable locations. We should assume that nodes will be physically 710 compromised, their memories examined, and their keys extracted. 711 Fixed secrets will not remain secret. This impacts the node joining 712 process. Provisioning a network with a fixed link key K2 is not 713 secure. For most applications, this implies that there will be a 714 joining phase during which some level of authorization be allowed for 715 nodes which have not been authenticated. Details are out of scope, 716 but the link layer must provide some flexibility here. 718 Even if an attacker does not know the value of K1 and K2 719 (Section 4.6), it can still generate fake EB frames, authenticated 720 with an arbitrary key. We here discuss the impact these fake EBs can 721 have, depending on what key(s) are pre-provisioned. 723 If both K1 and K2 are pre-provisioned, a joining node can 724 distinguish legitimate from fake EBs, and join the legitimate 725 network. The fake EBs have no impact. 727 The same holds if K1 is pre-provisioned but not K2. 729 If neither K1 nor K2 is pre-provisioned, a joining node uses the 730 secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process 731 all correctly-formatted EBs. It therefore may mistake a fake EB 732 for a legitimate one and initiate a joining process to the 733 attacker. That joining process will fail, as the joining node 734 will not be able to authenticate the attacker during the security 735 handshake. This will force the joining node to start over 736 listening for an EB. So while the joining node never joins the 737 attacker, this costs the joining node time and energy, and is a 738 vector of attack. 740 Choosing what key(s) to pre-provision need to balance the different 741 discussions above. 743 Once the joining process is over, the node that has joined can 744 authenticate EBs (it knows K1). This means it can process their 745 contents and use EBs for synchronization. 747 ASN provides a nonce for security operations in a slot. Any re-use 748 of ASN with a given key exposes information about encrypted packet 749 contents, and risks replay attacks. Replay attacks are prevented 750 because, when the network resets, either the new network uses new 751 cryptographic key(s), or ensures that the ASN increases monotonically 752 (Section 4.6). 754 Maintaining accurate time synchronization is critical for network 755 operation. Accepting timing information from unsecured sources MUST 756 be avoided during normal network operation, as described in 757 Section 4.5.2. During joining, a node may be susceptible to timing 758 attacks before key K1 and K2 are learned. During network operation, 759 a node MAY maintain statistics on time updates from neighbors and 760 monitor for anomalies. 762 Denial of service attacks at the MAC layer in an LLN are easy to 763 achieve simply by RF jamming. This is the base case against which 764 more sophisticated DoS attacks should be judged. For example, 765 sending fake EBs announcing a very low Join Metric may cause a node 766 to waste time and energy trying to join a fake network even when 767 legitimate EBs are being heard. Proper join security will prevent 768 the node from joining the false flag, but by then the time and energy 769 will have been wasted. However, the energy cost to the attacker 770 would be lower and the energy cost to the joining node higher if the 771 attacker simply sent loud short packets in the middle of any valid EB 772 that it hears. 774 The MAC layer SHOULD keep track of anomalous events and report them 775 to a higher authority. For example, EBs reporting low Join Metrics 776 for networks which can not be joined, as described above, may be a 777 sign of attack. Additionally, in normal network operation, message 778 integrity check failures on packets with valid CRC will occur at a 779 rate on the order of once per million packets. Any significant 780 deviation from this rate may be a sign of network attack. Along the 781 same lines, time updates in ACKs or EBs that are inconsistent with 782 the MAC-layer's sense of time and its own plausible time error drift 783 rate may also be a result of network attack. 785 9. IANA Considerations 787 This document requests no immediate action by IANA. 789 10. Acknowledgments 791 The authors acknowledge the guidance and input from Rene Struik, Pat 792 Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa 793 Vucinic and Jonathan Simon. Thanks to Charles Perkins, Brian E. 794 Carpenter, Ralph Droms and Suresh Krishnan for the exhaustive and 795 detailed reviews. Thanks to Simon Duquennoy, Guillaume Gaillard, 796 Tengfei Chang and Jonathan Munoz for the detailed review of the 797 examples section. Thanks to 6TiSCH co-chair Pascal Thubert for his 798 guidance and advice. 800 11. References 802 11.1. Normative References 804 [I-D.ietf-6lo-routing-dispatch] 805 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 806 "6LoWPAN Routing Header", draft-ietf-6lo-routing- 807 dispatch-05 (work in progress), February 2016. 809 [IEEE802154-2015] 810 IEEE standard for Information Technology, "IEEE Std 811 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 812 Networks (WPANs)", December 2015. 814 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 815 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 816 RFC 8025, DOI 10.17487/RFC8025, November 2016, 817 . 819 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 820 Bormann, "Neighbor Discovery Optimization for IPv6 over 821 Low-Power Wireless Personal Area Networks (6LoWPANs)", 822 RFC 6775, DOI 10.17487/RFC6775, November 2012, 823 . 825 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 826 Hysteresis Objective Function", RFC 6719, 827 DOI 10.17487/RFC6719, September 2012, 828 . 830 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 831 Routing Header for Source Routes with the Routing Protocol 832 for Low-Power and Lossy Networks (RPL)", RFC 6554, 833 DOI 10.17487/RFC6554, March 2012, 834 . 836 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 837 Power and Lossy Networks (RPL) Option for Carrying RPL 838 Information in Data-Plane Datagrams", RFC 6553, 839 DOI 10.17487/RFC6553, March 2012, 840 . 842 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 843 Protocol for Low-Power and Lossy Networks (RPL)", 844 RFC 6552, DOI 10.17487/RFC6552, March 2012, 845 . 847 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 848 and D. Barthel, "Routing Metrics Used for Path Calculation 849 in Low-Power and Lossy Networks", RFC 6551, 850 DOI 10.17487/RFC6551, March 2012, 851 . 853 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 854 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 855 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 856 Low-Power and Lossy Networks", RFC 6550, 857 DOI 10.17487/RFC6550, March 2012, 858 . 860 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 861 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 862 DOI 10.17487/RFC6282, September 2011, 863 . 865 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 866 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 867 March 2011, . 869 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 870 "Transmission of IPv6 Packets over IEEE 802.15.4 871 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 872 . 874 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 875 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 876 December 1998, . 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, 880 DOI 10.17487/RFC2119, March 1997, 881 . 883 11.2. Informative References 885 [I-D.ietf-6tisch-6top-protocol] 886 Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- 887 ietf-6tisch-6top-protocol-03 (work in progress), October 888 2016. 890 [I-D.ietf-6tisch-terminology] 891 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 892 "Terminology in IPv6 over the TSCH mode of IEEE 893 802.15.4e", draft-ietf-6tisch-terminology-08 (work in 894 progress), December 2016. 896 [I-D.ietf-6tisch-minimal-security] 897 malisa.vucinic@st.com, m., Simon, J., and K. Pister, 898 "Minimal Security Framework for 6TiSCH", draft-ietf- 899 6tisch-minimal-security-00 (work in progress), December 900 2016. 902 [I-D.ietf-6tisch-dtsecurity-secure-join] 903 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 904 6tisch-dtsecurity-secure-join-00 (work in progress), 905 December 2016. 907 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 908 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 909 Internet of Things (IoT): Problem Statement", RFC 7554, 910 DOI 10.17487/RFC7554, May 2015, 911 . 913 11.3. External Informative References 915 [openwsn] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 916 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 917 a Standards-Based Low-Power Wireless Development 918 Environment", Transactions on Emerging Telecommunications 919 Technologies , August 2012. 921 Appendix A. Examples 923 This section contains several example packets. Each example contains 924 (1) a schematic header diagram, (2) the corresponding bytestream, (3) 925 a description of each of the IEs that form the packet. Packet 926 formats are specific for the [IEEE802154-2015] revision and may vary 927 in future releases of the IEEE standard. In case of differences 928 between the packet content presented in this section and 929 [IEEE802154-2015], the latter has precedence. 931 The MAC header fields are described in a specific order. All field 932 formats in this examples are depicted in the order in which they are 933 transmitted, from left to right, where the leftmost bit is 934 transmitted first. Bits within each field are numbered from 0 935 (leftmost and least significant) to k - 1 (rightmost and most 936 significant), where the length of the field is k bits. Fields that 937 are longer than a single octet are sent to the PHY in the order from 938 the octet containing the lowest numbered bits to the octet containing 939 the highest numbered bits (little endian). 941 A.1. Example: EB with Default Timeslot Template 943 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Len3 = 6 |Sub ID = 0x1a|0| ASN 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 ASN | Join Metric | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 Bytestream: 965 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 966 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F 968 Description of the IEs: 970 #Header IE Header 971 Len1 = Header IE Length (0) 972 Element ID = 0x7e - termination IE indicating Payload IE 973 coming next 975 Type 0 977 #Payload IE Header (MLME) 978 Len2 = Payload IE Len (26 Bytes) 979 Group ID = 1 MLME (Nested) 980 Type = 1 982 #MLME-SubIE TSCH Synchronization 983 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 984 Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization) 985 Type = Short (0) 986 ASN = Absolute Sequence Number (5 Bytes) 987 Join Metric = 1 Byte 989 #MLME-SubIE TSCH Timeslot 990 Len4 = Length in bytes of the sub-IE payload (1 Byte) 991 Sub-ID = 0x1c (MLME-SubIE Timeslot) 992 Type = Short (0) 993 Timeslot template ID = 0x00 (default) 995 #MLME-SubIE Channel Hopping 996 Len5 = Length in bytes of the sub-IE payload (1 Byte) 997 Sub-ID = 0x09 (MLME-SubIE Channel Hopping) 998 Type = Long (1) 999 Hopping Sequence ID = 0x00 (default) 1001 #MLME-SubIE TSCH Slotframe and Link 1002 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 1003 Sub-ID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 1004 Type = Short (0) 1005 Number of slotframes = 0x01 1006 Slotframe handle = 0x00 1007 Slotframe size = 101 slots (0x65) 1008 Number of Links (Cells) = 0x01 1009 Timeslot = 0x0000 (2B) 1010 Channel Offset = 0x0000 (2B) 1011 Link Options = 0x0F 1012 (TX Link, RX Link, Shared Link, Timekeeping) 1014 A.2. Example: EB with Custom Timeslot Template 1016 Using a custom timeslot template in EBs: setting timeslot length to 1017 15ms. 1019 1 2 3 1020 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 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Len3 = 6 |Sub ID = 0x1a|0| ASN 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 ASN | Join Metric | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 = 2700 | macTsCCA = 128 | macTsTxOffset 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 = 3300 | macTsAckWait = 600 | macTsRxTx 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 = 192 | macTsMaxAck = 2400 | macTsMaxTx 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 Bytestream: 1047 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 1048 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 1049 00 0A ... 1051 Description of the IEs: 1053 #Header IE Header 1054 Len1 = Header IE Length (none) 1055 Element ID = 0x7e - termination IE indicating Payload IE 1056 coming next 1057 Type 0 1059 #Payload IE Header (MLME) 1060 Len2 = Payload IE Len (53 Bytes) 1061 Group ID = 1 MLME (Nested) 1062 Type = 1 1064 #MLME-SubIE TSCH Synchronization 1065 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 1066 Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization) 1067 Type = Short (0) 1068 ASN = Absolute Sequence Number (5 Bytes) 1069 Join Metric = 1 Byte 1071 #MLME-SubIE TSCH Timeslot 1072 Len4 = Length in bytes of the sub-IE payload (25 Bytes) 1073 Sub-ID = 0x1c (MLME-SubIE Timeslot) 1074 Type = Short (0) 1075 Timeslot template ID = 0x01 (non-default) 1077 The 15ms timeslot announced: 1078 +--------------------------------+------------+ 1079 | IEEE 802.15.4 TSCH parameter | Value (us) | 1080 +--------------------------------+------------+ 1081 | macTsCCAOffset | 2700 | 1082 +--------------------------------+------------+ 1083 | macTsCCA | 128 | 1084 +--------------------------------+------------+ 1085 | macTsTxOffset | 3180 | 1086 +--------------------------------+------------+ 1087 | macTsRxOffset | 1680 | 1088 +--------------------------------+------------+ 1089 | macTsRxAckDelay | 1200 | 1090 +--------------------------------+------------+ 1091 | macTsTxAckDelay | 1500 | 1092 +--------------------------------+------------+ 1093 | macTsRxWait | 3300 | 1094 +--------------------------------+------------+ 1095 | macTsAckWait | 600 | 1096 +--------------------------------+------------+ 1097 | macTsRxTx | 192 | 1098 +--------------------------------+------------+ 1099 | macTsMaxAck | 2400 | 1100 +--------------------------------+------------+ 1101 | macTsMaxTx | 4256 | 1102 +--------------------------------+------------+ 1103 | macTsTimeslotLength | 15000 | 1104 +--------------------------------+------------+ 1106 #MLME-SubIE Channel Hopping 1107 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 1108 Sub-ID = 0x09 (MLME-SubIE Channel Hopping) 1109 Type = Long (1) 1110 Hopping Sequence ID = 0x00 (default) 1112 A.3. Example: Link-layer Acknowledgment 1114 Enhanced Acknowledgment packets carry the Time Correction IE (Header 1115 IE). 1117 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 Bytestream: 1125 02 0F TS#0 TS#1 1127 Description of the IEs: 1129 #Header IE Header 1130 Len1 = Header IE Length (2 Bytes) 1131 Element ID = 0x1e - ACK/NACK Time Correction IE 1132 Type 0 1134 A.4. Example: Auxiliary Security Header 1136 802.15.4 Auxiliary Security Header with security Level set to ENC- 1137 MIC-32. 1139 1 1140 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 |L = 5|M=1|1|1|0|Key Index = IDX| 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 Bytestream: 1147 6D IDX#0 1149 Security Auxiliary Header fields in the example: 1151 #Security Control (1 byte) 1152 L = Security Level ENC-MIC-32 (5) 1153 M = Key Identifier Mode (0x01) 1154 Frame Counter Suppression = 1 (omitting Frame Counter field) 1155 ASN in Nonce = 1 (construct Nonce from 5 byte ASN) 1156 Reserved = 0 1158 #Key Identifier (1 byte) 1159 Key Index = IDX (deployment-specific KeyIndex parameter that 1160 identifies the cryptographic key) 1162 Authors' Addresses 1164 Xavier Vilajosana (editor) 1165 Universitat Oberta de Catalunya 1166 156 Rambla Poblenou 1167 Barcelona, Catalonia 08018 1168 Spain 1170 Email: xvilajosana@uoc.edu 1172 Kris Pister 1173 University of California Berkeley 1174 512 Cory Hall 1175 Berkeley, California 94720 1176 USA 1178 Email: pister@eecs.berkeley.edu 1180 Thomas Watteyne 1181 Linear Technology 1182 32990 Alvarado-Niles Road, Suite 910 1183 Union City, CA 94587 1184 USA 1186 Email: twatteyne@linear.com