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