idnits 2.17.1 draft-ietf-6tisch-minimal-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([IEEE802154e]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 28, 2014) is 3437 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 881, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 887, but not defined == Missing Reference: 'CCM' is mentioned on line 893, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 898, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 909, but not defined == Unused Reference: 'RFC3610' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'I-D.richardson-6tisch-security-architecture' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 863, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-03 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-04 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-02 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-02 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 2 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: Informational K. Pister 5 Expires: June 1, 2015 University of California Berkeley 6 November 28, 2014 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-04 11 Abstract 13 This document describes the minimal set of rules to operate a 14 [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This 15 minimal mode of operation can be used during network bootstrap, as a 16 fall-back mode of operation when no dynamic scheduling solution is 17 available or functioning, or during early interoperability testing 18 and development. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 1, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Minimal Schedule Configuration . . . . . . . . . . . . . . . 3 57 3.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 6 60 3.4. Time Slot timing . . . . . . . . . . . . . . . . . . . . 6 61 4. Enhanced Beacons Configuration and Content . . . . . . . . . 8 62 4.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 9 65 4.2. TSCH Timeslot IE . . . . . . . . . . . . . . . . . . . . 9 66 4.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 9 68 4.3. Channel Hopping IE . . . . . . . . . . . . . . . . . . . 10 69 4.3.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3.2. IE Content . . . . . . . . . . . . . . . . . . . . . 10 71 4.4. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 10 72 4.4.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 10 73 4.4.2. IE Content . . . . . . . . . . . . . . . . . . . . . 10 74 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 11 76 5.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 11 77 5.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 11 78 6. Neighbor information . . . . . . . . . . . . . . . . . . . . 12 79 6.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 12 80 6.2. Time Source Neighbor Selection . . . . . . . . . . . . . 12 81 7. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 13 82 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.1. RPL Objective Function Zero . . . . . . . . . . . . . . . 14 85 9.1.1. Rank computation . . . . . . . . . . . . . . . . . . 14 86 9.1.2. Rank computation Example . . . . . . . . . . . . . . 15 87 9.2. RPL Configuration . . . . . . . . . . . . . . . . . . . . 17 88 9.2.1. Mode of Operation . . . . . . . . . . . . . . . . . . 17 89 9.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . . 17 90 9.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 17 91 9.2.4. Variable Values . . . . . . . . . . . . . . . . . . . 17 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 95 11.2. Informative References . . . . . . . . . . . . . . . . . 19 96 11.3. External Informative References . . . . . . . . . . . . 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 100 1. Introduction 102 The nodes in a [IEEE802154e] TSCH network follow a communication 103 schedule. The entity (centralized or decentralized) responsible for 104 building and maintaining that schedule has very precise control over 105 the trade-off between the network's latency, bandwidth, reliability 106 and power consumption. During early interoperability testing and 107 development, however, simplicity is often more important than 108 efficiency. One goal of this document is to define the simplest set 109 of rules for building a [IEEE802154e] TSCH-compliant network, at the 110 necessary price of lesser efficiency. Yet, this minimal mode of 111 operation MAY also be used during network bootstrap before any 112 schedule is installed into the network so nodes can self-organize and 113 the management and configuration information be distributed. In 114 addition, as outlined in 115 [I-D.phinney-roll-rpl-industrial-applicability], the minimal 116 configuration MAY be used as a fall-back mode of operation, ensuring 117 connectivity of nodes in case that dynamic scheduling mechanisms fail 118 or are not available. [IEEE802154e] provides a mechanism whereby the 119 details of slotframe length, timeslot timing, and channel hopping 120 pattern are communicated at synchronization to a node. This document 121 describes specific settings for these parameters. Nodes MUST 122 broadcast properly formed Enhanced Beacons to announce these values. 124 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 3. Minimal Schedule Configuration 132 In order to form a network, a minimum schedule configuration is 133 required so nodes can advertise the presence of the network, and 134 allow other nodes to join. 136 3.1. Slotframe 138 The slotframe, as defined in [I-D.ietf-6tisch-terminology], is an 139 abstraction of the link layer that defines a collection of time slots 140 of equal length, and which repeats over time. In order to set up a 141 minimal TSCH network, nodes need to be synchronized with the same 142 slotframe configuration so they can exchange Enhanced Beacons (EBs) 143 and data packets. This document recommends the following slotframe 144 configuration. 146 Minimal configuration 148 +------------------------------------+----------------------+ 149 | Property | Value | 150 +------------------------------------+----------------------+ 151 | Number of time slots per Slotframe | Variable | 152 +------------------------------------+----------------------+ 153 | Number of available frequencies | 16 | 154 +------------------------------------+----------------------+ 155 | Number of scheduled cells | 1 (slotOffset 0) | 156 | | (macLinkType NORMAL) | 157 +------------------------------------+----------------------+ 158 | Number of unscheduled cells | The remainder of the | 159 | | slotframe | 160 +------------------------------------+----------------------+ 161 | Number of MAC retransmissions (max)| 3 (4 attempts to tx)| 162 +------------------------------------+----------------------+ 164 The slotframe is composed of a configurable number of time slots. 165 Choosing the number of time slots per slotframe needs to take into 166 account network requirements such as density, bandwidth per node, 167 etc. In the minimal configuration, there is only a single active 168 slot in slotframe, used to transmit data and EBs, and receive 169 information. The trade-off between bandwidth, latency and energy 170 consumption can be controlled by choosing a different slotframe 171 length. The active slot MAY be scheduled at the slotOffset 0x00 and 172 channelOffset 0x00 and MUST be announced in the EBs. EBs are sent 173 using this active slot to the link-layer broadcast address (and are 174 therefore not acknowledged). Data packets, as described in 175 Section 3.2, use the same active slot. Per [IEEE802154e], data 176 packets sent unicast on this cell are acknowledged by the receiver. 177 The remaining cells in the slotframe are unscheduled, and MAY be used 178 by dynamic scheduling solutions. Details about such dynamic 179 scheduling solution are out of scope of this document. 181 The slotframe length (expressed in number of time slots) is 182 configurable. The length used determines the duty cycle of the 183 network. For example, a network with a 0.99% duty cycle is composed 184 of a slotframe of 101 slots, which includes 1 active slot. The 185 present document RECOMMENDS the use of a default slot duration set to 186 10ms and its corresponding default timeslot timings defined by the 187 [IEEE802154e] macTimeslotTemplate. The use of the default 188 macTimeslotTemplate MUST be announced in the EB by using the Timeslot 189 IE containing only the default macTimeslotTemplateId. Other time 190 slot durations MAY be supported and MUST be announced in the EBs. If 191 one uses a timeslot duration different than 10ms, it is RECOMMENDED 192 to use a power-of-two of 10ms (i.e. 20ms, 40ms, 80ms, etc.). In this 193 case, EBs MUST contain the complete TimeSlot IE as described in 194 Section 3.4. This document also recommends to manufacturers to 195 clearly indicate nodes not supporting the default timeslot value. 197 Example schedule with 0.99% duty cycle 199 Chan. +----------+----------+ +----------+ 200 Off.0 | TxRxS/EB | OFF | | OFF | 201 Chan. +----------+----------+ +----------+ 202 Off.1 | | | ... | | 203 +----------+----------+ +----------+ 204 . 205 . 206 . 207 Chan. +----------+----------+ +----------+ 208 Off.15 | | | | | 209 +----------+----------+ +----------+ 211 slotOffset 0 1 100 213 EB: Enhanced Beacon 214 Tx: Transmit 215 Rx: Receive 216 S: Shared 217 OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism) 219 3.2. Cell Options 221 Per [IEEE802154e] TSCH, each scheduled cell has an associated bitmap 222 of cell options, called LinkOptions. The scheduled cell in the 223 minimal schedule is configured as a Hard cell 224 [I-D.ietf-6tisch-tsch][I-D.ietf-6tisch-6top-interface]. Additional 225 available cells MAY be scheduled by a dynamic scheduling solution. 226 The dynamic scheduling solution is out of scope, and this 227 specification does not make any restriction on the LinkOption 228 associated with those dynamically scheduled cells (i.e. they can be 229 hard cells or soft cells). 231 The active cell is assigned the bitmap of cell options below. 232 Because both the "Transmit" and "Receive" bits are set, a node 233 transmits if there is a packet in its queue, listens otherwise. 234 Because the "shared" bit is set, the back-off mechanism defined in 235 [IEEE802154e] is used to resolve contention when transmitting. This 236 results in "Slotted Aloha" behavior. The "Timekeeping" flag is never 237 set, since the time source neighbor is selected using the DODAG 238 structure of the network (detailed below). 240 b0 = Transmit = 1 (set) 241 b1 = Receive = 1 (set) 243 b2 = Shared = 1 (set) 245 b3 = Timekeeping = 0 (clear) 247 b4-b7 = Reserved (clear) 249 All remaining cells are unscheduled. In unscheduled cells, the nodes 250 SHOULD keep their radio off. In a memory-efficient implementation, 251 scheduled cells can be represented by a circular linked list. 252 Unscheduled cells SHOULD NOT occupy any memory. 254 3.3. Retransmissions 256 The maximum number of link layer retransmissions is set to 3. For 257 packets which require an acknowledgment, if none is received after a 258 total of 4 attempts, the transmissions is considered failed and the 259 link layer MUST notify the upper layer. Packets sent to the 260 broadcast MAC address (including EBs) are not acknowledged and 261 therefore not retransmitted. 263 3.4. Time Slot timing 265 The figure below shows an active timeslot in which a packet is sent 266 from the transmitter node (TX) to the receiver node (RX). A link- 267 layer acknowledgment is sent by the RX node to the TX node when the 268 packet is to be acknowledged. The TsTxOffset duration defines the 269 instant in the timeslot when the first byte of the transmitted packet 270 leaves the radio of the TX node. The radio of the RX node is turned 271 on tsRxWait/2 before that instant, and listens for at least tsRxWait. 272 This allows for a de-synchronization between the two nodes of at most 273 tsRxWait. The RX node needs to send the first byte of the MAC 274 acknowledgment exactly TsTxAckDelay after the end of the last byte of 275 the received packet. TX's radio has to be turned on tsAckWait/2 276 before that time, and keep listening for at least tsAckWait. The TX 277 node can perform a Clear Channel Assessment (CCA) if required, this 278 does not interfere with the scope of this draft. As for a minimal 279 configuration, CCA is not mandatory. 281 Time slot internal timing diagram 283 /---------------------- Time Slot Duration ----------------------/ 284 | / (5) / | 285 | | / tsRxAckDelay /| | | | 286 |-------------------+--------------+------------------+------+---| 287 TX |/(1)/ (2) / (3) /| TX packet | |RX ack| | 288 |----+-------+------+--------------+------------------+------+---| 289 |/ tsTxOffset /| | | | | 290 | | | | | | 291 |-------------------+--------------+------------------+------+---| 292 RX | | | | RX packet | |TX ack| | 293 |----------------+--+--+-----------+------------------+------+---| 294 | | | | | | | | 295 | / (4) / / tsTxAckDelay / | | 296 Start End 297 of of 298 Slot Slot 299 /(1)/ tsCCAOffset 300 /(2)/ tsCCA 301 /(3)/ tsRxTx 302 /(4)/ tsRxWait 303 /(5)/ tsAckWait 305 A 10ms time slot length is the default value defined by 306 [IEEE802154e]. Section 6.4.3.3.3 of [IEEE802154e] defines a default 307 macTimeslotTemplate, i.e. the different duration within the slot. 308 These values are summarized in the following table and MUST be used 309 when utilizing the default time slot duration. In this case, the 310 Timeslot IE only transports the macTimeslotTemplateId (0x00) as the 311 timing values are well-known. If a timeslot template other than the 312 default is used, the EB MUST contain a complete TimeSlot IE 313 indicating the timeslot duration and the corresponding timeslot 314 timings, requiring 25 bytes. 316 Default timeslot durations (per [IEEE802154e], Section 6.4.3.3.3) 318 +--------------------------------+------------+ 319 | IEEE802.15.4e TSCH parameter | Value (us) | 320 +--------------------------------+------------+ 321 | tsCCAOffset | 1800 | 322 +--------------------------------+------------+ 323 | tsCCA | 128 | 324 +--------------------------------+------------+ 325 | tsTxOffset | 2120 | 326 +--------------------------------+------------+ 327 | tsRxOffset | 1120 | 328 +--------------------------------+------------+ 329 | tsRxAckDelay | 800 | 330 +--------------------------------+------------+ 331 | tsTxAckDelay | 1000 | 332 +--------------------------------+------------+ 333 | tsRxWait | 2200 | 334 +--------------------------------+------------+ 335 | tsAckWait | 400 | 336 +--------------------------------+------------+ 337 | tsRxTx | 192 | 338 +--------------------------------+------------+ 339 | tsMaxAck | 2400 | 340 +--------------------------------+------------+ 341 | tsMaxTx | 4256 | 342 +--------------------------------+------------+ 343 | Time Slot duration | 10000 | 344 +--------------------------------+------------+ 346 4. Enhanced Beacons Configuration and Content 348 [IEEE802154e] does not define how often EBs are sent, nor their 349 contents. The choice of the duration between two EBs needs to take 350 into account whether EBs are used as the only mechanism to 351 synchronize devices, or whether a Keep-Alive (KA) mechanism is also 352 used. For a minimal TSCH configuration, a mote SHOULD send an EB 353 every EB_PERIOD. For additional reference see [I-D.ietf-6tisch-tsch] 354 where different synchronization approaches are summarized. 356 EBs MUST be sent with the Beacon IEEE802.15.4 frame type and this EBs 357 MUST carry the Information Elements (IEs) listed below. 359 The content of the IEs is presented here for completeness, however 360 this information is redundant with [I-D.ietf-6tisch-tsch] and 361 [IEEE802154e]. 363 4.1. Sync IE 365 Contains synchronization information such as ASN and Join Priority. 366 The value of Join Priority is discussed in Section 6.2. 368 4.1.1. IE Header 370 Length (b0-b7) = 0x06 372 Sub-ID (b8-b14) = 0x1a 374 Type (b15) = 0x00 (short) 376 4.1.2. IE Content 378 ASN Byte 1 (b16-b23) 380 ASN Byte 2 (b24-b31) 382 ASN Byte 3 (b32-b39) 384 ASN Byte 4 (b40-b47) 386 ASN Byte 5 (b48-b55) 388 Join Priority (b56-b63) 390 4.2. TSCH Timeslot IE 392 Contains the timeslot template identifier. This specification uses 393 the default timeslot template as defined in [IEEE802154e], 394 Section 5.2.4.15. 396 4.2.1. IE Header 398 Length (b0-b7) = 0x01 400 Sub-ID (b8-b14) = 0x1c 402 Type (b15) = 0x00 (short) 404 4.2.2. IE Content 406 Timeslot Template ID (b0-b7) = 0x00 408 4.3. Channel Hopping IE 410 Contains the channel hopping template identifier. This specification 411 uses the default channel hopping template, as defined in 412 [IEEE802154e], Section 5.2.4.16. 414 4.3.1. IE Header 416 Length (b0-b7) = 0x01 418 Sub-ID (b8-b14) = 0x1d 420 Type (b15) = 0x00 (short) 422 4.3.2. IE Content 424 Channel Hopping Template ID (b0-b7) = 0x00 426 The default sequence for the 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 427 14, 11, 8, 0, 1, 2, 13, 3, 9, 10] per section 5.1.1a of 428 [IEEE802154e]. 430 4.4. Frame and Link IE 432 Each node MUST indicate the schedule in each EB through a Frame and 433 Link IE. This enables nodes which implement [IEEE802154e] to 434 configure their schedule as they join the network. 436 4.4.1. IE Header 438 Length (b0-b7) = variable 440 Sub-ID (b8-b14) = 0x1b 442 Type (b15) = 0x00 (short) 444 4.4.2. IE Content 446 # Slotframes (b16-b23) = 0x01 448 Slotframe ID (b24-b31) = 0x01 450 Size Slotframe (b32-b47) = variable 452 # Links (b48-b55) = 0x01 454 For the active cell in the minimal schedule: 456 Channel Offset (2B) = 0x00 458 Slot Number (2B) = 0x00 460 LinkOption (1B) = as described in Section 3.2 462 5. Acknowledgment 464 Link-layer acknowledgment frames are built according to 465 [IEEE802154e]. Data frames and command frames sent to a unicast MAC 466 destination address request an acknowledgment. The acknowledgment 467 frame is of type ACK (0x10). Each acknowledgment contains the 468 following IE: 470 5.1. ACK/NACK Time Correction IE 472 The ACK/NACK time correction IE carries the measured de- 473 synchronization between the sender and the receiver. 475 5.1.1. IE Header 477 Length (b0-b7) = 0x02 479 Sub-ID (b8-b14) = 0x1e 481 Type (b15) = 0x00 (short) 483 5.1.2. IE Content 485 Time Synchronization Information and ACK status (b16-b31) 487 The possible values for the Time Synchronization Information and ACK 488 status are described in [IEEE802154e] and reproduced in the following 489 table: 491 ACK status and Time Synchronization Information. 493 +-----------------------------------+-----------------+ 494 | ACK Status | Value | 495 +-----------------------------------+-----------------+ 496 | ACK with positive time correction | 0x0000 - 0x07ff | 497 +-----------------------------------+-----------------+ 498 | ACK with negative time correction | 0x0800 - 0x0fff | 499 +-----------------------------------+-----------------+ 500 | NACK with positive time correction| 0x8000 - 0x87ff | 501 +-----------------------------------+-----------------+ 502 | NACK with negative time correction| 0x8800 - 0x8fff | 503 +-----------------------------------+-----------------+ 505 6. Neighbor information 507 [IEEE802154e] does not define how and when each node in the network 508 keeps information about its neighbors. Keeping the following 509 information in the neighbor table is RECOMMENDED: 511 6.1. Neighbor Table 513 The exact format of the neighbor table is implementation-specific, 514 but it SHOULD contain the following information for each neighbor: 516 Neighbor statistics: 518 numTx: number of transmitted packets to that neighbor 520 numTxAck: number of transmitted packets that have been 521 acknowledged by that neighbor 523 numRx: number of received packets from that neighbor 525 The EUI64 of the neighbor. 527 Timestamp when that neighbor was heard for the last time. This 528 can be based on the ASN counter or any other time base. Can be 529 used to trigger a keep-alive message. 531 RPL rank of that neighbor. 533 A flag indicating whether this neighbor is a time source neighbor. 535 Connectivity statistics (e.g., RSSI), which can be used to 536 determine the quality of the link. 538 In addition to that information, each node has to be able to compute 539 some RPL Objective Function (OF), taking into account the neighbor 540 and connectivity statistics. An example RPL objective function is 541 the OF Zero as described in [RFC6552] and Section 9.1.1. 543 6.2. Time Source Neighbor Selection 545 Each node MUST select at least one Time Source Neighbor among the 546 nodes in its RPL routing parent set. When a node joins a network, it 547 has no routing information. To select its time source neighbor, it 548 uses the Join Priority field in the EB, as described in 549 Section 5.2.4.13 and Table 52b of [IEEE802154e]. The Sync IE 550 contains the ASN and 1 Byte field named Join Priority. The Join 551 Priority of any node is equivalent to the result of the function 552 DAGRank(rank) as defined by [RFC6550] and Section 9.1.1. The Join 553 Priority of the DAG root is zero, i.e., EBs sent from the DAG root 554 are sent with Join Priority equal to 0. A lower value of the Join 555 Priority indicates higher preference to connect to that device. When 556 a node joins the network, it MUST NOT send EBs before having acquired 557 a RPL rank. This avoids routing loops and matches RPL topology with 558 underlying mesh topology. As soon as a node acquires a RPL rank (see 559 [RFC6550] and Section 9.1.1), it SHOULD send Enhanced Beacons 560 including a Sync IE with Join Priority field set to DAGRank(rank), 561 where rank is the node's rank. If a node receives EBs from different 562 nodes with equal Join Priority, the time source neighbor selection 563 SHOULD be assessed by other metrics that can help determine the 564 better connectivity link. Time source neighbor hysteresis SHOULD be 565 used, according to the rules defined in Section 9.2.3. If 566 connectivity to the time source neighbor is lost, a new time source 567 neighbor MUST be chosen among the neighbors in the RPL routing parent 568 set. 570 The decision for a node to select one Time Source Neighbor when 571 multiple EBs are received is open to implementers. For example, a 572 node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT neighbors have 573 been received to select the best Time Source Neighbor. This 574 condition MAY apply unless a second EB is not received after 575 MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting 576 a first Time Source Neighbor. 578 Optionally, some form of hysteresis SHOULD be implemented to avoid 579 frequent changes in time source neighbors. 581 7. Queues and Priorities 583 [IEEE802154e] does not define the use of queues to handle upper layer 584 data (either application or control data from upper layers). The use 585 of a single queue with the following rules is RECOMMENDED: 587 When the node is not synchronized to the network, higher layers 588 are not able to insert packets into the queue. 590 Frames generated by the MAC layer (e.g., EBs and ACK) have a 591 higher priority than packets received from a higher layer. 593 IEEE802.15.4 frame types Beacon and Command have a higher priority 594 than IEEE802.15.4 frame types Data and ACK. 596 One entry in the queue is reserved at all times for an 597 IEEE802.15.4 frames of types Beacon or Command frames. 599 8. Security 601 As this document refers to the interaction between Layer 3 and Layer 602 2 protocols, this interaction MUST be secured by L2 security 603 mechanisms as defined by [IEEE802154e]. Key distribution is out of 604 scope of this document, but examples include pre-configured keys at 605 the nodes, shared keys amongst peers or well-known keys. Refer to 606 the 6TiSCH architecture document [I-D.ietf-6tisch-architecture] for 607 further details on security aspects. 609 9. RPL on TSCH 611 Nodes in the network MUST use the RPL routing protocol [RFC6550]. 613 9.1. RPL Objective Function Zero 615 Nodes in the network MUST use the RPL routing protocol [RFC6550] and 616 implement the RPL Objective Function Zero [RFC6552]. 618 9.1.1. Rank computation 620 The rank computation is described at [RFC6552], Section 4.1. 621 Briefly, a node rank is computed by the following equation: 623 R(N) = R(P) + rank_increase 625 rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 627 Where: 629 R(N): Rank of the node. 631 R(P): Rank of the parent obtained as part of the DIO information. 633 rank_increase: The result of a function that determines the rank 634 increment. 636 Rf (rank_factor): A configurable factor that is used to multiply 637 the effect of the link properties in the rank_increase 638 computation. If none is configured, rank_factor of 1 is used. In 639 this specification, a rank_factor of 1 MUST be used. 641 Sp (step_of_rank): (strictly positive integer) - an intermediate 642 computation based on the link properties with a certain neighbor. 643 In this specification, 2*ETX (Expected Transmissions) as defined 644 by [decouti03high] and [RFC6551] MUST be used. The ETX is 645 computed as the inverse of the Packet Delivery Ratio (PDR), and 646 MAY be computed as the number of acknowledged packets, divided by 647 the number of transmitted packets to a certain node. E.g: 648 Sp=2*numTX/numTXAck 650 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 651 to the step_of_rank of a preferred parent, to allow the selection 652 of an additional feasible successor. If none is configured to the 653 device, then the step_of_rank is not stretched. In this 654 specification, stretch_of_rank MUST be set to 0. 656 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 657 constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550]. 658 DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. 660 DAGRank(rank): Equivalent to the floor of (Rf*Sp + Sr) as defined 661 by [RFC6550]. Specifically, when an Objective Function computes 662 Rank, this is defined as an unsigned integer (i.e., a 16-bit 663 value) Rank quantity. When the Rank is compared, e.g. to 664 determine parent relationships or loop detection, the integer 665 portion of the Rank is used. The integer portion of the Rank is 666 computed by the DAGRank() macro as floor(x) where floor(x) is the 667 function that evaluates to the greatest integer less than or equal 668 to x. DAGRank(rank) = floor(rank/MinHopRankIncrease) 670 Rank computation scenario 672 +-------+ 673 | P | R(P) 674 | | 675 +-------+ 676 | 677 | 678 +-------+ 679 | N | R(N)=R(P) + rank_increase 680 | | rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 681 +-------+ Sp=2*ETX 683 9.1.2. Rank computation Example 685 This section illustrates with an example the use of the Objective 686 Function Zero. Assume the following parameters: 688 Rf = 1 690 Sp = 2* ETX 692 Sr = 0 694 minHopRankIncrease = 256 (default in RPL) 695 ETX=(numTX/numTXAck) 697 r(n) = r(p) + rank_increase 699 rank_increase = (Rf*Sp + Sr) * minHopRankIncrease 701 rank_increase = 512*numTx/numTxACK 703 Rank computation example for 5 hop network where numTx=100 and 704 numTxAck=75 for all nodes 706 +-------+ 707 | 0 | R(0)=0 708 | | DAGRank(R(0)) = 0 709 +-------+ 710 | 711 | 712 +-------+ 713 | 1 | R(1)=R(0)+683=683 714 | | DAGRank(R(1)) = 2 715 +-------+ 716 | 717 | 718 +-------+ 719 | 2 | R(2)=R(1)+683=1366 720 | | DAGRank(R(2)) = 5 721 +-------+ 722 | 723 | 724 +-------+ 725 | 3 | R(3)=R(2)+683=2049 726 | | DAGRank(R(3)) = 8 727 +-------+ 728 | 729 | 730 +-------+ 731 | 4 | R(4)=R(3)+683=2732 732 | | DAGRank(R(4)) = 10 733 +-------+ 734 | 735 | 736 +-------+ 737 | 5 | R(5)=R(4)+683=3415 738 | | DAGRank(R(5)) = 13 739 +-------+ 741 9.2. RPL Configuration 743 In addition to the Objective Function (OF), a minimal configuration 744 for RPL SHOULD indicate the preferred mode of operation and trickle 745 timer operation so different RPL implementations can inter-operate. 746 RPL information and hop-by-hop extension headers MUST be compressed 747 according to the specification described in [I-D.thubert-6lo-rpl-nhc] 749 9.2.1. Mode of Operation 751 For downstream route maintenance, in a minimal configuration, RPL 752 SHOULD be set to operate in the Non-Storing mode as described by 753 [RFC6550] Section 9.7. Storing mode ([RFC6550] Section 9.8) MAY be 754 supported in less constrained devices. 756 9.2.2. Trickle Timer 758 RPL signaling messages such as DIOs are sent using the Trickle 759 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 760 specification, the Trickle Timer MUST be used with the RPL defined 761 default values [RFC6550] (Section 8.3.1). For a description of the 762 Trickle timer operation see Section 4.2 on [RFC6206]. 764 9.2.3. Hysteresis 766 According to [RFC6552], [RFC6719] recommends the use of a boundary 767 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 768 when ranks are compared. When evaluating a parent that belongs to a 769 smaller path cost than current minimum path, the candidate node is 770 selected as new parent only if the difference between the new path 771 and the current path is greater than the defined 772 PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the 773 current preferred parent. As for [RFC6719] the recommended value for 774 PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used, the 775 recommendation for this document is to use PARENT_SWITCH_THRESHOLD 776 equal to 394 as the metric being used is 2*ETX. This is mechanism is 777 suited to deal with parent hysteresis in both cases routing parent 778 and time source neighbor selection. 780 9.2.4. Variable Values 782 The following table presents the RECOMMENDED values for the RPL- 783 related variables defined in the previous section. 785 Recommended variable values 787 +-------------------------+-------+ 788 | Variable | Value | 789 +-------------------------+-------+ 790 | EB_PERIOD | 10s | 791 +-------------------------+-------+ 792 | MAX_EB_DELAY | 180 | 793 +-------------------------+-------+ 794 | NUM_NEIGHBOURS_TO_WAIT | 2 | 795 +-------------------------+-------+ 796 | PARENT_SWITCH_THRESHOLD | 394 | 797 +-------------------------+-------+ 799 10. Acknowledgments 801 The authors would like to acknowledge the guidance and input provided 802 by the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne. 804 11. References 806 11.1. Normative References 808 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 809 Hysteresis Objective Function", RFC 6719, September 2012. 811 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 812 Protocol for Low-Power and Lossy Networks (RPL)", RFC 813 6552, March 2012. 815 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 816 Barthel, "Routing Metrics Used for Path Calculation in 817 Low-Power and Lossy Networks", RFC 6551, March 2012. 819 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 820 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 821 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 822 Lossy Networks", RFC 6550, March 2012. 824 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 825 "The Trickle Algorithm", RFC 6206, March 2011. 827 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 828 CBC-MAC (CCM)", RFC 3610, September 2003. 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, March 1997. 833 11.2. Informative References 835 [I-D.ietf-6tisch-tsch] 836 Watteyne, T., Palattella, M., and L. Grieco, "Using 837 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 838 Statement and Goals", draft-ietf-6tisch-tsch-03 (work in 839 progress), October 2014. 841 [I-D.ietf-6tisch-architecture] 842 Thubert, P., Watteyne, T., and R. Assimiti, "An 843 Architecture for IPv6 over the TSCH mode of IEEE 844 802.15.4e", draft-ietf-6tisch-architecture-04 (work in 845 progress), October 2014. 847 [I-D.ietf-6tisch-terminology] 848 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 849 "Terminology in IPv6 over the TSCH mode of IEEE 850 802.15.4e", draft-ietf-6tisch-terminology-02 (work in 851 progress), July 2014. 853 [I-D.ietf-6tisch-6top-interface] 854 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 855 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 856 6top-interface-02 (work in progress), October 2014. 858 [I-D.richardson-6tisch-security-architecture] 859 Richardson, M., "security architecture for 6top: 860 requirements and structure", draft-richardson-6tisch- 861 security-architecture-02 (work in progress), April 2014. 863 [I-D.ietf-roll-terminology] 864 Vasseur, J., "Terms used in Routing for Low power And 865 Lossy Networks", draft-ietf-roll-terminology-13 (work in 866 progress), October 2013. 868 [I-D.phinney-roll-rpl-industrial-applicability] 869 Phinney, T., Thubert, P., and R. Assimiti, "RPL 870 applicability in industrial networks", draft-phinney-roll- 871 rpl-industrial-applicability-02 (work in progress), 872 February 2013. 874 [I-D.thubert-6lo-rpl-nhc] 875 Thubert, P. and C. Bormann, "A compression mechanism for 876 the RPL option", draft-thubert-6lo-rpl-nhc-02 (work in 877 progress), October 2014. 879 11.3. External Informative References 881 [IEEE802154e] 882 IEEE standard for Information Technology, "IEEE std. 883 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 884 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 885 2012. 887 [IEEE802154] 888 IEEE standard for Information Technology, "IEEE std. 889 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 890 and Physical Layer (PHY) Specifications for Low-Rate 891 Wireless Personal Area Networks", June 2011. 893 [CCM] National Institute of Standards and Technology, 894 "Recommendation for Block Cipher Modes of Operation: The 895 CCM Mode for Authentication and Confidentiality. SP 896 800-38C", May 2004. 898 [CCM-Star] 899 Struik, R., "Formal Specification of the CCM* Mode of 900 Operation, IEEE P802.15 Working Group for Wireless 901 Personal Area Networks (WPANs).", September 2005. 903 [decouti03high] 904 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 905 High-Throughput Path Metric for Multi-Hop Wireless 906 Routing", ACM International Conference on Mobile Computing 907 and Networking (MobiCom) , June 2003. 909 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 910 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 911 a Standards-Based Low-Power Wireless Development 912 Environment", Transactions on Emerging Telecommunications 913 Technologies , August 2012. 915 Authors' Addresses 917 Xavier Vilajosana (editor) 918 Universitat Oberta de Catalunya 919 156 Rambla Poblenou 920 Barcelona, Catalonia 08018 921 Spain 923 Phone: +34 (646) 633 681 924 Email: xvilajosana@uoc.edu 925 Kris Pister 926 University of California Berkeley 927 490 Cory Hall 928 Berkeley, California 94720 929 USA 931 Email: pister@eecs.berkeley.edu