idnits 2.17.1 draft-ietf-6tisch-minimal-18.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 20, 2017) is 2653 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 24, 2017 University of California Berkeley 6 January 20, 2017 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-18 11 Abstract 13 This document describes a minimal mode of operation for a 6TiSCH 14 Network. A minimal mode of operation is a baseline set of protocols, 15 recommended configurations and modes of operation sufficient to 16 enable a 6TiSCH functional network. 6TiSCH provides IPv6 17 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh 18 composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a 19 collection of protocols with the respective configurations, including 20 the 6LoWPAN framework, enabling interoperable IPv6 connectivity over 21 IEEE Std 802.15.4 TSCH. This minimal configuration provides the 22 necessary bandwidth for network and security bootstrap and defines 23 the proper link between the IETF protocols that interface to the IEEE 24 Std 802.15.4 TSCH. This minimal mode of operation should be 25 implemented by all 6TiSCH compliant devices. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 24, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. IEEE Std 802.15.4 Settings . . . . . . . . . . . . . . . . . 4 65 4.1. TSCH Schedule . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 7 68 4.4. Timeslot Timing . . . . . . . . . . . . . . . . . . . . . 7 69 4.5. Frame Contents . . . . . . . . . . . . . . . . . . . . . 7 70 4.5.1. IEEE Std 802.15.4 Header . . . . . . . . . . . . . . 7 71 4.5.2. Enhanced Beacon Frame . . . . . . . . . . . . . . . . 8 72 4.5.3. Acknowledgment Frame . . . . . . . . . . . . . . . . 9 73 4.6. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9 74 5. RPL Settings . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Objective Function . . . . . . . . . . . . . . . . . . . 10 76 5.1.1. Rank Computation . . . . . . . . . . . . . . . . . . 10 77 5.1.2. Rank Computation Example . . . . . . . . . . . . . . 11 78 5.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 12 79 5.3. Trickle Timer . . . . . . . . . . . . . . . . . . . . . . 13 80 5.4. Packet Formats . . . . . . . . . . . . . . . . . . . . . 13 81 6. Network Formation and Lifetime . . . . . . . . . . . . . . . 13 82 6.1. Value of the Join Metric Field . . . . . . . . . . . . . 13 83 6.2. Time Source Neighbor Selection . . . . . . . . . . . . . 13 84 6.3. When to Start Sending EBs . . . . . . . . . . . . . . . . 14 85 6.4. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 14 86 7. Implementation Recommendations . . . . . . . . . . . . . . . 14 87 7.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 14 88 7.2. Queues and Priorities . . . . . . . . . . . . . . . . . . 15 89 7.3. Recommended Settings . . . . . . . . . . . . . . . . . . 15 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 95 11.2. Informative References . . . . . . . . . . . . . . . . . 20 96 11.3. External Informative References . . . . . . . . . . . . 20 98 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20 99 A.1. Example: EB with Default Timeslot Template . . . . . . . 21 100 A.2. Example: EB with Custom Timeslot Template . . . . . . . 22 101 A.3. Example: Link-layer Acknowledgment . . . . . . . . . . . 24 102 A.4. Example: Auxiliary Security Header . . . . . . . . . . . 25 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 105 1. Introduction 107 A 6TiSCH Network provides IPv6 connectivity [RFC2460] over a Time 108 Synchronized Channel Hopping (TSCH) mesh [RFC7554] composed of IEEE 109 Std 802.15.4 TSCH links [IEEE802154-2015]. IPv6 connectivity is 110 obtained by the use of the 6LoWPAN framework ([RFC4944], [RFC6282], 111 [RFC8025],[I-D.ietf-6lo-routing-dispatch] and [RFC6775]), RPL 112 [RFC6550], and its Objective Function 0 (OF0) [RFC6552]. 114 This specification defines operational parameters and procedures for 115 a minimal mode of operation to build a 6TiSCH Network. Any 6TiSCH 116 complaint device SHOULD implement this mode of operation. This 117 operational parameters configuration provides the necessary bandwidth 118 for nodes to bootstrap the network. The bootstrap process includes 119 initial network configuration and security bootstrap. In this 120 specification, the 802.15.4 TSCH mode, the 6LoWPAN framework, RPL 121 [RFC6550], and its Objective Function 0 (OF0) [RFC6552], are used 122 unmodified. Parameters and particular operations of TSCH are 123 specified to guarantee interoperability between nodes in a 6TiSCH 124 Network. RPL is specified to provide the framework for time 125 synchronization in an 802.15.4 TSCH network. The specifics for 126 interoperable interaction between RPL and TSCH are described. 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-6lo-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 Join Metric: Field in the TSCH Synchronization IE. Number of hops 167 separating the node sending the EB, and the PAN coordinator. 169 4. IEEE Std 802.15.4 Settings 171 An implementation compliant to this specification MUST implement IEEE 172 Std 802.15.4 [IEEE802154-2015] in "timeslotted channel hopping" 173 (TSCH) mode. 175 The remainder of this section details the RECOMMENDED TSCH settings, 176 which are summarized in Figure 1. A node MAY use different values. 177 Any of the properties marked in the EB column are announced in the 178 Enhanced Beacons (EB) the nodes send [IEEE802154-2015] and learned by 179 those joining the network. Changing their value hence means changing 180 the contents of the EB. 182 In case of discrepancy between the values in this specification and 183 IEEE Std 802.15.4 [IEEE802154-2015], the IEEE standard has 184 precedence. 186 +--------------------------------+------------------------------+---+ 187 | Property | Recommended Setting |EB*| 188 +--------------------------------+------------------------------+---+ 189 | Slotframe Size | Tunable. Trades-off | X | 190 | | bandwidth against energy. | | 191 +--------------------------------+------------------------------+---+ 192 | Number of scheduled cells | 1 (slotOffset 0x0000) | X | 193 | (active) | (chOffset 0x0000) | | 194 | | (link Option 0x0f) | | 195 | | (LinkType ADVERTISING) | | 196 +--------------------------------+------------------------------+---+ 197 | Number of unscheduled cells | All remaining cells in the | X | 198 | (off) | slotframe | | 199 +--------------------------------+------------------------------+---+ 200 | Max Number MAC retransmissions | 3 (4 transmission attempts) | | 201 +--------------------------------+------------------------------+---+ 202 | Timeslot template | IEEE Std 802.15.4 default | X | 203 | | (macTimeslotTemplateId=0) | | 204 +--------------------------------+------------------------------+---+ 205 | Enhanced Beacon Period | Tunable. Trades-off join | | 206 | (EB_PERIOD) | time against energy. | | 207 +--------------------------------+------------------------------+---+ 208 | Number used frequencies | IEEE Std 802.15.4 default | X | 209 | (2.4 GHz O-QPSK PHY) | (16) | | 210 +--------------------------------+------------------------------+---+ 211 | Channel Hopping sequence | IEEE Std 802.15.4 default | X | 212 | (2.4 GHz O-QPSK PHY) | (macHoppingSequenceID = 0) | | 213 +--------------------------------+------------------------------+---+ 214 * an "X" in this column means this property's value is announced in 215 the EB; a new node hence learns it when joining. 217 Figure 1: Recommended IEEE Std 802.15.4 TSCH Settings. 219 4.1. TSCH Schedule 221 This minimal mode of operation uses a single slotframe. The TSCH 222 slotframe is composed of a tunable number of timeslots. The 223 slotframe size (i.e. the number of timeslots it contains) trades off 224 bandwidth for energy consumption. The slotframe size needs to be 225 tuned; the way of tuning it is out of scope of this specification. 226 The slotframe size is announced in the EB. The slotframe handle 227 (macSlotframeHandle) MAY be set to 0x80 so the slotframe has a medium 228 priority (refer to [IEEE802154-2015] section 6.2.6.4), enabling other 229 mechanism to position slotframes with higher or lower priority if 230 needed. The use of other slotframes is out of the scope of this 231 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 acknowledgement 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. EBs are not secure. 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. EBs heard after joining a network 367 SHOULD NOT be used for time synchronization, or to change any other 368 network parameters. During the joining process, before secure 369 connections to time parents have been created, it MAY be necessary 370 for a node to maintain synchronization using EBs. [RFC7554] 371 discusses different time synchronization approaches. 373 EBs MUST be sent as per the IEEE Std 802.15.4 specification and 374 SHOULD carry the Information Elements (IEs) listed below 375 [IEEE802154-2015]. 377 TSCH Synchronization IE: Contains synchronization information such 378 as ASN and Join Metric. The value of the Join Metric field is 379 discussed in Section 6.1. 381 TSCH Timeslot IE: Contains the timeslot template identifier. This 382 template is used to specify the internal timing of the timeslot. 383 This specification RECOMMENDS the default timeslot template. 385 Channel Hopping IE: Contains the channel hopping sequence 386 identifier. This specification RECOMMENDS the default channel 387 hopping sequence. 389 TSCH Slotframe and Link IE: Enables joining nodes to learn the 390 initial schedule to be used as they join the network. This 391 document RECOMMENDS the use of a single cell. 393 If a node strictly follows the recommended setting from Figure 1, the 394 EB it sends has the exact same contents as an EB it has received when 395 joining, except for the Join Metric field in the TSCH Synchronization 396 IE. 398 4.5.3. Acknowledgment Frame 400 Per [IEEE802154-2015], each acknowledgment contain an ACK/NACK Time 401 Correction IE. 403 4.6. Link-Layer Security 405 When securing link-layer frames, link-layer frames MUST be secured by 406 the link-layer security mechanisms defined in IEEE Std 802.15.4 407 [IEEE802154-2015]. Link-layer authentication MUST be applied to the 408 entire frame, including the 802.15.4 header. Link-layer encryption 409 MAY be applied to 802.15.4 payload IEs and the 802.15.4 payload. 411 During normal network operation a cryptographic key KL is used to 412 authenticate and optionally encrypt DATA and ACKNOWLEDGMENT frames. 413 KL may be pre-provisioned. Key distribution is out of scope of this 414 document. Provisioning mechanisms are defined for example in 415 [I-D.ietf-6tisch-minimal-security] and 416 [I-D.ietf-6tisch-dtsecurity-secure-join]. Some provisioning 417 mechanisms will require some level of network access during the 418 joining process. 420 During the join process, if KL has not been provisioned yet, a 421 protocol identifier PI SHOULD be used in place of KL until both 422 transmitter and receiver have KL. In particular, PI is used to 423 authenticate EBs. In this case, PI MUST be pre-configured, and 424 provides no security. PI does indicate that the authenticated frame 425 was intended as a 6TiSCH EB. In a crowded 802.15.4 RF environment, 426 this facilitates logical segregation of distinct networks. The value 427 36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 38 ("6TiSCH minimal18") 428 is RECOMMENDED for PI, but a network operator MAY change it for 429 administrative and segregation reasons. 431 In the event of a network reset, the new network MUST either use a 432 new cryptographic key or keys KL, or ensure that the ASN remains 433 monotonically increasing. 435 5. RPL Settings 437 In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be 438 used. 440 5.1. Objective Function 442 If RPL is used, nodes MUST implement the RPL Objective Function Zero 443 (OF0) [RFC6552]. 445 5.1.1. Rank Computation 447 The Rank computation is described at [RFC6552], Section 4.1. A 448 node's Rank (see Figure 4 for an example) is computed by the 449 following equations: 451 R(N) = R(P) + rank_increment 453 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 455 Figure 3 lists the OF0 parameter values that MUST be used if RPL is 456 used. 458 +----------------------+-------------------------------------+ 459 | OF0 Parameters | Value | 460 +----------------------+-------------------------------------+ 461 | Rf | 1 | 462 +----------------------+-------------------------------------+ 463 | Sp | (3*ETX)-2 | 464 +----------------------+-------------------------------------+ 465 | Sr | 0 | 466 +----------------------+-------------------------------------+ 467 | MinHopRankIncrease | DEFAULT_MIN_HOP_RANK_INCREASE (256) | 468 +----------------------+-------------------------------------+ 469 | MINIMUM_STEP_OF_RANK | 1 | 470 +----------------------+-------------------------------------+ 471 | MAXIMUM_STEP_OF_RANK | 9 | 472 +----------------------+-------------------------------------+ 473 | ETX limit to select | 3 | 474 | a parent | | 475 +----------------------+-------------------------------------+ 477 Figure 3: OF0 parameters. 479 The step_of_rank (Sp) uses Expected Transmission Count (ETX) 480 [RFC6551]. 482 An implementation MUST follow OF0's normalization guidance as 483 discussed in Section 1 and Section 4.1 of [RFC6552]. Sp SHOULD be 484 calculated as (3*ETX)-2. The minimum value of Sp 485 (MINIMUM_STEP_OF_RANK) indicates a good quality link. The maximum 486 value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor quality link. 487 The default value of Sp (DEFAULT_STEP_OF_RANK) indicates an average 488 quality link. Candidate parents with ETX greater than 3 SHOULD NOT 489 be selected. This avoids having ETX values on used links which are 490 larger that the maximum allowed transmission attempts. 492 5.1.2. Rank Computation Example 494 This section illustrates the use of the Objective Function Zero (see 495 Figure 4). We have: 497 rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512 498 +-------+ 499 | 0 | R(minHopRankIncrease) = 256 500 | | DAGRank(R(0)) = 1 501 +-------+ 502 | 503 | 504 +-------+ 505 | 1 | R(1)=R(0) + 512 = 768 506 | | DAGRank(R(1)) = 3 507 +-------+ 508 | 509 | 510 +-------+ 511 | 2 | R(2)=R(1) + 512 = 1280 512 | | DAGRank(R(2)) = 5 513 +-------+ 514 | 515 | 516 +-------+ 517 | 3 | R(3)=R(2) + 512 = 1792 518 | | DAGRank(R(3)) = 7 519 +-------+ 520 | 521 | 522 +-------+ 523 | 4 | R(4)=R(3) + 512 = 2304 524 | | DAGRank(R(4)) = 9 525 +-------+ 526 | 527 | 528 +-------+ 529 | 5 | R(5)=R(4) + 512 = 2816 530 | | DAGRank(R(5)) = 11 531 +-------+ 533 Figure 4: Rank computation example for 5-hop network where numTx=100 534 and numTxAck=75 for all links. 536 5.2. Mode of Operation 538 When RPL is used, nodes MUST implement the non-storing ([RFC6550] 539 Section 9.7) mode of operation. The storing ([RFC6550] Section 9.8) 540 mode of operation SHOULD be implemented by nodes with enough 541 capabilities. Nodes not implementing RPL MUST join as leaf nodes. 543 5.3. Trickle Timer 545 RPL signaling messages such as DIOs are sent using the Trickle 546 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206] (Section 4.2). For 547 this specification, the Trickle Timer MUST be used with the RPL 548 defined default values [RFC6550] (Section 8.3.1). 550 5.4. Packet Formats 552 RPL information and hop-by-hop extension headers MUST follow 553 [RFC6553] and [RFC6554] specification. In the case the packets 554 formed at the LLN need to cross through intermediate routers, these 555 MUST follow the IP-in-IP encapsulation requirement specified by the 556 [RFC6282] and [RFC2460]. Routing extension headers such as RPI 557 [RFC6550] and SRH [RFC6554], and outer IP headers in case of 558 encapsulation MUST be compressed according to 559 [I-D.ietf-6lo-routing-dispatch] and [RFC8025]. 561 6. Network Formation and Lifetime 563 6.1. Value of the Join Metric Field 565 The Join Metric of the TSCH Synchronization IE in the EB MUST be 566 calculated based on the routing metric of the node, normalized to a 567 value between 0 and 255. A lower value of the Join Metric indicates 568 the node sending the EB is topologically "closer" to the root of the 569 network. A lower value of the Join Metric hence indicates higher 570 preference for a joining node to synchronize to that neighbor. In 571 case that the network uses RPL, the Join Metric of any node 572 (including the DAG root) MUST be set to DAGRank(rank)-1. According 573 to Section 5.1.1, DAGRank(rank(0)) = 1. DAGRank(rank(0))-1 = 0 is 574 compliant with 802.15.4's requirement of having the root use Join 575 Metric = 0. When a node is not using RPL, the Join Metric value 576 SHOULD follow the rules specified by [IEEE802154-2015]. 578 6.2. Time Source Neighbor Selection 580 When a node joins a network, it may hear EBs sent by different nodes 581 already in the network. The decision of which neighbor to 582 synchronize to (e.g. which neighbor becomes the node's initial time 583 source neighbor) is implementation-specific. For example, after 584 having received the first EB, a node MAY listen for at most 585 MAX_EB_DELAY seconds until it has received EBs from 586 NUM_NEIGHBOURS_TO_WAIT distinct neighbors. When receiving EBs from 587 distinct neighbors, the node MAY use the Join Metric field in each EB 588 to select the initial time source neighbor, as described in IEEE Std 589 802.15.4 [IEEE802154-2015], Section 6.3.6. 591 At any time, a node MUST maintain connectivity to at least one time 592 source neighbor. A node's time source neighbor MUST be chosen among 593 the neighbors in its RPL routing parent set. 595 6.3. When to Start Sending EBs 597 When a RPL node joins the network, it MUST NOT send EBs before having 598 acquired a RPL Rank to avoid inconsistencies in the time 599 synchronization structure. This applies to other routing protocols 600 with their corresponding routing metrics. As soon as a node acquires 601 routing information (e.g. a RPL Rank, see Section 5.1.1), it SHOULD 602 start sending Enhanced Beacons. 604 6.4. Hysteresis 606 Per [RFC6552] and [RFC6719], the specification RECOMMENDS the use of 607 a boundary value (PARENT_SWITCH_THRESHOLD) to avoid constant changes 608 of parent when ranks are compared. When evaluating a parent that 609 belongs to a smaller path cost than the current minimum path, the 610 candidate node is selected as new parent only if the difference 611 between the new path and the current path is greater than the defined 612 PARENT_SWITCH_THRESHOLD. Otherwise, the node MAY continue to use the 613 current preferred parent. Per [RFC6719], the PARENT_SWITCH_THRESHOLD 614 SHOULD be set to 192 when ETX metric is used (in the form 128*ETX), 615 the recommendation for this document is to use 616 PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is 617 ((3*ETX)-2)*minHopRankIncrease, or a proportional value. This deals 618 with hysteresis both for routing parent and time source neighbor 619 selection. In case a node has a security association with its 620 parent, including routing parent or time source neighbor, the node 621 SHOULD be allowed to keep the association despite of fluctuations of 622 the rank. 624 7. Implementation Recommendations 626 7.1. Neighbor Table 628 The exact format of the neighbor table is implementation-specific. 629 The RECOMMENDED per-neighbor information is (taken from the [openwsn] 630 implementation): 632 identifier: Identifier(s) of the neighbor (e.g. EUI-64). 634 numTx: Number of link-layer transmission attempts to that 635 neighbor. 637 numTxAck: Number of transmitted link-layer frames that have been 638 link-layer acknowledged by that neighbor. 640 numRx: Number of link-layer frames received from that neighbor. 642 timestamp: When the last frame was received from that neighbor. 643 This can be based on the ASN counter or any other time 644 base. It can be used to trigger a keep-alive message. 646 routing metric: Such as the RPL Rank of that neighbor. 648 time source neighbor: A flag indicating whether this neighbor is a 649 time source neighbor. 651 7.2. Queues and Priorities 653 The IEEE Std 802.15.4 specification [IEEE802154-2015] does not define 654 the use of queues to handle upper layer data (either application or 655 control data from upper layers). The following rules are 656 RECOMMENDED: 658 A node is configured to keep in the queues a configurable number 659 of Upper Layer packets per link (default NUM_UPPERLAYER_PACKETS) 660 for a configurable time that should cover the join process 661 (default MAX_JOIN_TIME). 663 Frames generated by the 802.15.4 layer (including EBs) are queued 664 with a priority higher than frames coming from higher-layers. 666 Frame types BEACON and COMMAND are queued with higher priority 667 than frame types DATA. 669 One entry in the queue is reserved at all times for frames of 670 types BEACON and COMMAND frames. 672 7.3. Recommended Settings 674 Figure 5 lists RECOMMENDED values for the settings discussed in this 675 specification. 677 +-------------------------+-------------------+ 678 | Parameter | RECOMMENDED Value | 679 +-------------------------+-------------------+ 680 | MAX_EB_DELAY | 180 | 681 +-------------------------+-------------------+ 682 | NUM_NEIGHBOURS_TO_WAIT | 2 | 683 +-------------------------+-------------------+ 684 | PARENT_SWITCH_THRESHOLD | 640 | 685 +-------------------------+-------------------+ 686 | NUM_UPPERLAYER_PACKETS | 1 | 687 +-------------------------+-------------------+ 688 | MAX_JOIN_TIME | 300 | 689 +-------------------------+-------------------+ 691 Figure 5: Recommended Settings. 693 8. Security Considerations 695 This document is concerned only with MAC-layer security. 697 By their nature, many IoT networks have nodes in physically 698 vulnerable locations. We should assume that nodes will be physically 699 compromised, their memories examined, and their keys extracted. 700 Fixed secrets will not remain secret. This impacts the node joining 701 process. Provisioning a network with a fixed link key KL is not 702 secure. For most applications, this implies that there will be a 703 joining phase during which some level of authorization be allowed for 704 nodes which have not been authenticated. Details are out of scope, 705 but the MAC layer must provide some flexibility here. 707 During the joining phase, there are three choices for EB message 708 integrity and security. 710 EBs could be sent with no message integrity. In this case, it is 711 possible to misinterpret 802.15.4 MAC frames: errors may be caused 712 by packet corruption not caught by the CRC-16, networks running an 713 earlier or later version of the same protocol, or networks running 714 an entirely different protocol but sharing the same information 715 elements. Indeed, numerous deployments have shown that this 716 occurs with some frequency, due to significant regularity and 717 overlap in the structure of 802.15.4 packets. Sending frames with 718 no message integrity is to be avoided if possible. 720 Assuming EB frames are sent with message integrity, then a key 721 must be chosen to perform the MIC calculation. A natural first 722 choice is a cryptographic key such as KL. Choosing a fixed key is 723 not secure, as it will certainly be exposed. Choosing a random 724 key for each network then requires some out of band means of 725 provisioning that key into all nodes joining the network. This is 726 a good approach from a security point of view, but may present an 727 unacceptable overhead for some applications. 729 The third option is to send EBs with message integrity, and use a 730 published protocol identifier, PI, to perform the MIC calculation. 731 This provides no security, as the "key" is published. The purpose 732 is to provide a non-cryptographic checksum of the EBs, to 733 establish with high probability that the EB was intentionally sent 734 as a 6TiSCH minimal EB. There is no guarantee that the EB is 735 valid. PI provides no security. 737 ASN provides a nonce for security operations in a slot. Any re-use 738 of ASN with a given key exposes information about encrypted packet 739 contents, and risks replay attacks. Replay attacks are prevented 740 because, when the network resets, either the new network uses new 741 cryptographic key(s), or ensures that the ASN increases monotonically 742 (Section 4.6). 744 Maintaining accurate time synchronization is critical for network 745 operation. Accepting timing information from unsecured sources MUST 746 be avoided during normal network operation, as described in 747 Section 4.5.2. During joining, a node may be susceptible to timing 748 attacks before key KL is provisioned. During network operation, a 749 node MAY maintain statistics on time updates from neighbors and 750 monitor for anomalies. 752 Denial of service attacks at the MAC layer in an LLN are easy to 753 achieve simply by RF jamming. This is the base case against which 754 more sophisticated DoS attacks should be judged. For example, 755 sending false EBs announcing a very low Join Metric may cause a node 756 to waste time and energy trying to join a bogus network even when 757 valid EBs are being heard. Proper join security will prevent the 758 node from joining the false flag, but by then the time and energy 759 will have been wasted. However, the energy cost to the attacker 760 would be lower and the energy cost to the joining node higher if the 761 attacker simply sent loud short packets in the middle of any valid EB 762 that it hears. 764 The MAC-layer SHOULD keep track of anomalous events and report them 765 to a higher authority. For example, EBs reporting low Join Metrics 766 for networks which can not be joined, as described above, may be a 767 sign of attack. Additionally, in normal network operation message 768 integrity check failures on packets with valid CRC will occur at a 769 rate on the order of once per million packets. Any significant 770 deviation from this rate may be a sign of network attack. Along the 771 same lines, time updates in ACKs or EBs that are inconsistent with 772 the MAC-layer's sense of time and its own plausible time error drift 773 rate may also be a result of network attack. 775 9. IANA Considerations 777 This document requests no immediate action by IANA. 779 10. Acknowledgments 781 The authors acknowledge the guidance and input from Rene Struik, Pat 782 Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa 783 Vucinic, Jonathan Simon and thank Charles Perkins, Brian Carpenter 784 and Suresh Krishnan for the exhaustive and detailed review. Thanks 785 to Simon Duquennoy, Guillaume Gaillard, Tengfei Chang and Jonathan 786 Munoz for the detailed review of the examples section. Thanks to 787 6TiSCH co-chairs Pascal Thubert and Thomas Watteyne for their 788 guidance and advice. 790 11. References 792 11.1. Normative References 794 [I-D.ietf-6lo-routing-dispatch] 795 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 796 "6LoWPAN Routing Header", draft-ietf-6lo-routing- 797 dispatch-05 (work in progress), February 2016. 799 [IEEE802154-2015] 800 IEEE standard for Information Technology, "IEEE Std 801 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 802 Networks (WPANs)", December 2015. 804 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 805 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 806 RFC 8025, DOI 10.17487/RFC8025, November 2016, 807 . 809 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 810 Bormann, "Neighbor Discovery Optimization for IPv6 over 811 Low-Power Wireless Personal Area Networks (6LoWPANs)", 812 RFC 6775, DOI 10.17487/RFC6775, November 2012, 813 . 815 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 816 Hysteresis Objective Function", RFC 6719, 817 DOI 10.17487/RFC6719, September 2012, 818 . 820 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 821 Routing Header for Source Routes with the Routing Protocol 822 for Low-Power and Lossy Networks (RPL)", RFC 6554, 823 DOI 10.17487/RFC6554, March 2012, 824 . 826 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 827 Power and Lossy Networks (RPL) Option for Carrying RPL 828 Information in Data-Plane Datagrams", RFC 6553, 829 DOI 10.17487/RFC6553, March 2012, 830 . 832 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 833 Protocol for Low-Power and Lossy Networks (RPL)", 834 RFC 6552, DOI 10.17487/RFC6552, March 2012, 835 . 837 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 838 and D. Barthel, "Routing Metrics Used for Path Calculation 839 in Low-Power and Lossy Networks", RFC 6551, 840 DOI 10.17487/RFC6551, March 2012, 841 . 843 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 844 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 845 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 846 Low-Power and Lossy Networks", RFC 6550, 847 DOI 10.17487/RFC6550, March 2012, 848 . 850 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 851 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 852 DOI 10.17487/RFC6282, September 2011, 853 . 855 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 856 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 857 March 2011, . 859 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 860 "Transmission of IPv6 Packets over IEEE 802.15.4 861 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 862 . 864 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 865 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 866 December 1998, . 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, 870 DOI 10.17487/RFC2119, March 1997, 871 . 873 11.2. Informative References 875 [I-D.ietf-6tisch-6top-protocol] 876 Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- 877 ietf-6tisch-6top-protocol-03 (work in progress), October 878 2016. 880 [I-D.ietf-6tisch-terminology] 881 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 882 "Terminology in IPv6 over the TSCH mode of IEEE 883 802.15.4e", draft-ietf-6tisch-terminology-08 (work in 884 progress), December 2016. 886 [I-D.ietf-6tisch-minimal-security] 887 malisa.vucinic@st.com, m., Simon, J., and K. Pister, 888 "Minimal Security Framework for 6TiSCH", draft-ietf- 889 6tisch-minimal-security-00 (work in progress), December 890 2016. 892 [I-D.ietf-6tisch-dtsecurity-secure-join] 893 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 894 6tisch-dtsecurity-secure-join-00 (work in progress), 895 December 2016. 897 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 898 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 899 Internet of Things (IoT): Problem Statement", RFC 7554, 900 DOI 10.17487/RFC7554, May 2015, 901 . 903 11.3. External Informative References 905 [openwsn] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 906 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 907 a Standards-Based Low-Power Wireless Development 908 Environment", Transactions on Emerging Telecommunications 909 Technologies , August 2012. 911 Appendix A. Examples 913 This section contains several example packets. Each example contains 914 (1) a schematic header diagram, (2) the corresponding bytestream, (3) 915 a description of each of the IEs that form the packet. Packet 916 formats are specific for the [IEEE802154-2015] revision and may vary 917 in future releases of the IEEE standard. In case of differences 918 between the packet content presented in this section and 919 [IEEE802154-2015], the latter has precedence. 921 The MAC header fields are described in a specific order. All field 922 formats in this examples are depicted in the order in which they are 923 transmitted, from left to right, where the leftmost bit is 924 transmitted first. Bits within each field are numbered from 0 925 (leftmost and least significant) to k - 1 (rightmost and most 926 significant), where the length of the field is k bits. Fields that 927 are longer than a single octet are sent to the PHY in the order from 928 the octet containing the lowest numbered bits to the octet containing 929 the highest numbered bits (little endian). 931 A.1. Example: EB with Default Timeslot Template 933 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Len3 = 6 |Sub ID = 0x1a|0| ASN 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 ASN | Join Metric | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | #SF = 0x01 | SF ID = 0x80 | SF LEN = 0x65 (101 slots) | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Bytestream: 955 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 956 01 C8 00 0A 1B 01 80 65 00 01 00 00 00 00 0F 958 Description of the IEs: 960 #Header IE Header 961 Len1 = Header IE Length (0) 962 Element ID = 0x7e - termination IE indicating Payload IE 963 coming next 965 Type 0 967 #Payload IE Header (MLME) 968 Len2 = Payload IE Len (26 Bytes) 969 Group ID = 1 MLME (Nested) 970 Type = 1 972 #MLME-SubIE TSCH Synchronization 973 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 974 Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization) 975 Type = Short (0) 976 ASN = Absolute Sequence Number (5 Bytes) 977 Join Metric = 1 Byte 979 #MLME-SubIE TSCH Timeslot 980 Len4 = Length in bytes of the sub-IE payload (1 Byte) 981 Sub-ID = 0x1c (MLME-SubIE Timeslot) 982 Type = Short (0) 983 Timeslot template ID = 0x00 (default) 985 #MLME-SubIE Channel Hopping 986 Len5 = Length in bytes of the sub-IE payload (1 Byte) 987 Sub-ID = 0x09 (MLME-SubIE Channel Hopping) 988 Type = Long (1) 989 Hopping Sequence ID = 0x00 (default) 991 #MLME-SubIE TSCH Slotframe and Link 992 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 993 Sub-ID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 994 Type = Short (0) 995 Number of slotframes = 0x01 996 Slotframe handle = 0x80 997 Slotframe size = 101 slots (0x65) 998 Number of Links (Cells) = 0x01 999 Timeslot = 0x0000 (2B) 1000 Channel Offset = 0x0000 (2B) 1001 Link Options = 0x0F 1002 (TX Link, RX Link, Shared Link, Timekeeping) 1004 A.2. Example: EB with Custom Timeslot Template 1006 Using a custom timeslot template in EBs: setting timeslot length to 1007 15ms. 1009 1 2 3 1010 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 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Len3 = 6 |Sub ID = 0x1a|0| ASN 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 ASN | Join Metric | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 = 2700 | macTsCCA = 128 | macTsTxOffset 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 = 3300 | macTsAckWait = 600 | macTsRxTx 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 = 192 | macTsMaxAck = 2400 | macTsMaxTx 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 Bytestream: 1037 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 1038 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 1039 00 0A ... 1041 Description of the IEs: 1043 #Header IE Header 1044 Len1 = Header IE Length (none) 1045 Element ID = 0x7e - termination IE indicating Payload IE 1046 coming next 1047 Type 0 1049 #Payload IE Header (MLME) 1050 Len2 = Payload IE Len (53 Bytes) 1051 Group ID = 1 MLME (Nested) 1052 Type = 1 1054 #MLME-SubIE TSCH Synchronization 1055 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 1056 Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization) 1057 Type = Short (0) 1058 ASN = Absolute Sequence Number (5 Bytes) 1059 Join Metric = 1 Byte 1061 #MLME-SubIE TSCH Timeslot 1062 Len4 = Length in bytes of the sub-IE payload (25 Bytes) 1063 Sub-ID = 0x1c (MLME-SubIE Timeslot) 1064 Type = Short (0) 1065 Timeslot template ID = 0x01 (non-default) 1067 The 15ms timeslot announced: 1068 +--------------------------------+------------+ 1069 | IEEE 802.15.4 TSCH parameter | Value (us) | 1070 +--------------------------------+------------+ 1071 | macTsCCAOffset | 2700 | 1072 +--------------------------------+------------+ 1073 | macTsCCA | 128 | 1074 +--------------------------------+------------+ 1075 | macTsTxOffset | 3180 | 1076 +--------------------------------+------------+ 1077 | macTsRxOffset | 1680 | 1078 +--------------------------------+------------+ 1079 | macTsRxAckDelay | 1200 | 1080 +--------------------------------+------------+ 1081 | macTsTxAckDelay | 1500 | 1082 +--------------------------------+------------+ 1083 | macTsRxWait | 3300 | 1084 +--------------------------------+------------+ 1085 | macTsAckWait | 600 | 1086 +--------------------------------+------------+ 1087 | macTsRxTx | 192 | 1088 +--------------------------------+------------+ 1089 | macTsMaxAck | 2400 | 1090 +--------------------------------+------------+ 1091 | macTsMaxTx | 4256 | 1092 +--------------------------------+------------+ 1093 | macTsTimeslotLength | 15000 | 1094 +--------------------------------+------------+ 1096 #MLME-SubIE Channel Hopping 1097 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 1098 Sub-ID = 0x09 (MLME-SubIE Channel Hopping) 1099 Type = Long (1) 1100 Hopping Sequence ID = 0x00 (default) 1102 A.3. Example: Link-layer Acknowledgment 1104 Enhanced Acknowledgment packets carry the Time Correction IE (Header 1105 IE). 1107 1 2 3 1108 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 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Bytestream: 1115 02 0F TS#0 TS#1 1117 Description of the IEs: 1119 #Header IE Header 1120 Len1 = Header IE Length (2 Bytes) 1121 Element ID = 0x1e - ACK/NACK Time Correction IE 1122 Type 0 1124 A.4. Example: Auxiliary Security Header 1126 802.15.4 Auxiliary Security Header with security Level set to ENC- 1127 MIC-32. 1129 1 1130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 |L = 5|M=1|1|1|0|Key Index = IDX| 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 Bytestream: 1137 6D IDX#0 1139 Security Auxiliary Header fields in the example: 1141 #Security Control (1 byte) 1142 L = Security Level ENC-MIC-32 (5) 1143 M = Key Identifier Mode (0x01) 1144 Frame Counter Suppression = 1 (omitting Frame Counter field) 1145 ASN in Nonce = 1 (construct Nonce from 5 byte ASN) 1146 Reserved = 0 1148 #Key Identifier (1 byte) 1149 Key Index = IDX (deployment-specific KeyIndex parameter that 1150 identifies the cryptographic key) 1152 Authors' Addresses 1154 Xavier Vilajosana (editor) 1155 Universitat Oberta de Catalunya 1156 156 Rambla Poblenou 1157 Barcelona, Catalonia 08018 1158 Spain 1160 Email: xvilajosana@uoc.edu 1162 Kris Pister 1163 University of California Berkeley 1164 512 Cory Hall 1165 Berkeley, California 94720 1166 USA 1168 Email: pister@eecs.berkeley.edu