idnits 2.17.1 draft-ietf-6tisch-minimal-01.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 a Security Considerations section. ** 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 (June 27, 2014) is 3584 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 840, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 846, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 859, but not defined == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'I-D.richardson-6tisch-security-architecture' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 822, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-02 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-01 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-00 == Outdated reference: A later version (-05) exists of draft-thubert-6man-flow-label-for-rpl-03 Summary: 3 errors (**), 0 flaws (~~), 12 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: December 29, 2014 University of California Berkeley 6 June 27, 2014 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-01 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 fallback mode of operation when no dynamic scheduling solution is 17 available or functioning, or during early interoperability testing 18 and development. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 24 "OPTIONAL" in this document are to be interpreted as described in RFC 25 2119 [RFC2119]. 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 December 29, 2014. 44 Copyright Notice 46 Copyright (c) 2014 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. Minimal Schedule Configuration . . . . . . . . . . . . . . . 3 63 2.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Time Slot timing . . . . . . . . . . . . . . . . . . . . 6 67 3. Enhanced Beacons Configuration and Content . . . . . . . . . 8 68 3.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8 71 3.2. TSCH Timeslot IE . . . . . . . . . . . . . . . . . . . . 9 72 3.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 73 3.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 9 74 3.3. Channel Hopping IE . . . . . . . . . . . . . . . . . . . 9 75 3.3.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 76 3.3.2. IE Content . . . . . . . . . . . . . . . . . . . . . 9 77 3.4. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 9 78 3.4.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 79 3.4.2. IE Content . . . . . . . . . . . . . . . . . . . . . 10 80 4. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 10 81 4.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 10 82 4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 10 83 4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 10 84 5. Neighbor information . . . . . . . . . . . . . . . . . . . . 11 85 5.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 11 86 5.2. Time Source Neighbor Selection . . . . . . . . . . . . . 12 87 6. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 12 88 7. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 7.1. RPL Objective Function Zero . . . . . . . . . . . . . . . 13 90 7.1.1. Rank computation . . . . . . . . . . . . . . . . . . 13 91 7.1.2. Rank computation Example . . . . . . . . . . . . . . 14 92 7.2. RPL Configuration . . . . . . . . . . . . . . . . . . . . 16 93 7.2.1. Mode of Operation . . . . . . . . . . . . . . . . . . 17 94 7.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . . 17 95 7.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 17 96 7.2.4. Variable Values . . . . . . . . . . . . . . . . . . . 17 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 101 9.2. Informative References . . . . . . . . . . . . . . . . . 19 102 9.3. External Informative References . . . . . . . . . . . . . 20 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 105 1. Introduction 107 The nodes in a [IEEE802154e] TSCH network follow a communication 108 schedule. The entity (centralized or decentralized) responsible for 109 building and maintaining that schedule has very precise control over 110 the trade-off between the network's latency, bandwidth, reliability 111 and power consumption. During early interoperability testing and 112 development, however, simplicity is often more important than 113 efficiency. One goal of this document is to define the simplest set 114 of rules for building a [IEEE802154e] TSCH-compliant network, at the 115 necessary price of lesser efficiency. Yet, this minimal mode of 116 operation can also be used during network bootstrap before any 117 schedule is installed into the network so nodes can self-organize and 118 the management and configuration information be distributed. In 119 addition, as outlined in 120 [I-D.phinney-roll-rpl-industrial-applicability], the minimal 121 configuration can be used as a fallback mode of operation, ensuring 122 connectivity of nodes in case that dynamic scheduling mechanisms fail 123 or are not available. [IEEE802154e] provides a mechanism whereby the 124 details of slotframe length, timeslot timing, and channel hopping 125 pattern are communicated at synchronization to a node, also Enhanced 126 Beacons can be used to periodically update nodes information. This 127 document describes specific settings for these parameters. Nodes 128 MUST broadcast properly formed Enhanced Beacons to announce these 129 values, but during initial implementation and debugging it may be 130 convenient to preconfigure these values. 132 2. Minimal Schedule Configuration 134 In order to form a network, a minimum schedule configuration is 135 required so nodes can advertise the presence of the network, and 136 allow other nodes to join. 138 2.1. Slotframe 140 The slotframe, as defined in [I-D.ietf-6tisch-terminology], is an 141 abstraction of the link layer that defines a collection of time slots 142 of equal length, and which repeats over time. In order to set up a 143 minimal TSCH network, nodes need to be synchronized with the same 144 slotframe configuration so they can exchange Enhanced Beacons (EBs) 145 and data packets. This document recommends the following slotframe 146 configuration. 148 Minimal configuration 150 +------------------------------------+----------------------+ 151 | Property | Value | 152 +------------------------------------+----------------------+ 153 | Number of time slots per Slotframe | Variable | 154 +------------------------------------+----------------------+ 155 | Number of available frequencies | 16 | 156 +------------------------------------+----------------------+ 157 | Number of scheduled cells | 1 (slotOffset 0) | 158 | | (macLinkType NORMAL) | 159 +------------------------------------+----------------------+ 160 | Number of unscheduled cells | The remainder of the | 161 | | slotframe | 162 +------------------------------------+----------------------+ 163 | Number of MAC retransmissions (max)| 3 (4 attempts to tx)| 164 +------------------------------------+----------------------+ 166 The slotframe is composed of a configurable number of time slots. 167 Choosing the number of time slots per slotframe needs to take into 168 account network requirements such as density, bandwidth per node, 169 etc. In the minimal configuration, there is only a single active 170 slot in slotframe, used to transmit data and EBs, and receive 171 information. The trade-off between bandwidth, latency and energy 172 consumption can be controlled by choosing a different slotframe 173 length. The active slot MAY be scheduled at the slotoffset 0x00 and 174 channeloffset 0x00 and MUST be announced in the EBs. EBs are sent 175 using this active slot and are not acknowledged. Data packets, as 176 described in Section 2.2 use the same active slot. Per 177 [IEEE802154e], data packets sent unicast on this cell are 178 acknowledged by the receiver. The remaining cells are unscheduled, 179 and MAY be used by dynamic scheduling solutions. Details about such 180 dynamic scheduling solution are out of scope. 182 The slotframe length (expressed in number of time slots) is 183 configurable. The length used determines the duty cycle of the 184 network. For example, a network with a 1.01% duty cycle is composed 185 of a slotframe of 101 slots, which includes 1 active slot. The 186 present document RECOMMENDS the use of a default slot duration set to 187 10ms and its corresponding default timeslot timings defined by the 188 [IEEE802154e] macTimeslotTemplate. The use of the default 189 macTimeslotTemplate MUST be announced in the EB by using the Timeslot 190 IE containing only the default macTimeslotTemplateId. Other time 191 slot durations MAY be supported and MUST be announced clearly. If 192 one uses a timeslot duration different than 10ms, it is RECOMMENDED 193 to use a power-of-two of 10ms (i.e. 20ms, 40ms, 80ms, etc.). In this 194 case, EBs MUST contain the complete TimeSlot IE as described in 195 Section 2.4. 197 Example schedule with 1.01% duty cycle 199 Chan. +----------+----------+ 200 Off.0 | TxRxS/EB | OFF | 201 Chan. +----------+----------+ 202 Off.1 | | | 203 +----------+----------+ 204 ... 205 Chan. +----------+----------+ 206 Off.15 | | | 207 +----------+----------+ 208 0 1-100 210 EB: Enhanced Beacon 211 Tx: Transmit 212 Rx: Receive 213 S: Shared 214 OFF: Unscheduled (can be used by a dynamic scheduling mechanism) 216 2.2. Cell Options 218 Per the [IEEE802154e] TSCH, each scheduled cell has an associated 219 bitmap of cell options, called LinkOption. The scheduled cell in the 220 minimal schedule is configured as Hard cell 221 [I-D.ietf-6tisch-tsch][I-D.ietf-6tisch-6top-interface]. Additional 222 available cells can be scheduled by a dynamic scheduling solution. 223 The dynamic scheduling solution is out of scope, and this 224 specification does not make any restriction on the LinkOption 225 associated with those dynamically scheduled cells (i.e. they can be 226 hard cells or soft cells). 228 The active cell is assigned the bitmap of cell options below. 229 Because both the "Transmit" and "Receive" bits are set, a node 230 transmits if there is a packet in its queue, and listens otherwise. 231 Because the "shared" bit is set, the back-off mechanism defined in 232 [IEEE802154e] is used to resolve contention. This results in 233 "Slotted Aloha" behavior. The "Timekeeping" flag is never set, since 234 the time source neighbor is selected using the DODAG structure of the 235 network (detailed below). 237 b0 = Transmit = 1 (set) 239 b1 = Receive = 1 (set) 240 b2 = Shared = 1 (set) 242 b3 = Timekeeping = 0 (clear) 244 b4-b7 = Reserved (clear) 246 All remaining cells are unscheduled. In unscheduled cells, the nodes 247 SHOULD keep their radio off. In a memory-efficient implementation, 248 scheduled cells can be represented by a circular linked list. 249 Unscheduled cells SHOULD NOT occupy any memory. 251 2.3. Retransmissions 253 The maximum number of link layer retransmissions is set to 3. For 254 packets which require an acknowledgement, if none is received after a 255 total of 4 attempts, the transmissions is considered failed and the 256 link layer MUST notify the upper layer. Packets sent to the 257 broadcast MAC address (including EBs) are not acknowledged and 258 therefore not retransmitted. 260 2.4. Time Slot timing 262 The figure below shows an active timeslot in which a packet is sent 263 from the transmitter node (TX) to the receiver node (RX). A link- 264 layer acknowledgement is sent by the RX node to the TX node when the 265 packet is to be acknowledged. The TsTxOffset duration defines the 266 instant in the timeslot when the first byte of the transmitted packet 267 leaves the radio of the TX node. The radio of the RX node is turned 268 on TsLongGT/2 before that instant, and listens for at least TsLongGT. 269 This allows for a de-synchronization between the two node of at most 270 TsLongGT. The RX node needs to send the first byte of the MAC 271 acknowledgement exactly TsTxAckDelay after the end of the last byte 272 of the received packet. TX's radio has to be turned on TsShortGT/2 273 before that time, and keep listening for at least TsShortGT. 275 Time slot internal timing diagram 277 /------------------- Time Slot duration --------------------/ 278 | /tsShortGT/ | 279 | | | | | | 280 |------------+-----------------+--------------+------+------| 281 TX | | TX-Packet | |RX Ack| | 282 |------------+-----------------+--------------+------+------| 283 |/tsTxOffset/| | | | | 284 | | | | | | 285 |------------+-----------------+--------------+------+------| 286 RX | | | | RX-Packet | |TX Ack| | 287 |---------+--+--+--------------+--------------+------+------| 288 | | | | | | | | 289 | /tsLongGT/ |/TsTxAckDelay/| | | 290 Start End 291 of of 292 Slot Slot 294 A 10ms time slot length is the default value defined by 295 [IEEE802154e]. Section 6.4.3.3.3 of the [IEEE802154e] defines a 296 default macTimeslotTemplate, i.e. the different duration within the 297 slot. These values are summarized in the following table and MUST be 298 used when utilizing the default time slot duration. In this case, 299 the Timeslot IE only transports the macTimeslotTemplateId (0x00) as 300 the timing values are well-known. If a timeslot template other than 301 the default is used, the EB MUST contain a complete TimeSlot IE, 302 which requires 25 extra bytes. 304 Default timeslot durations (per [IEEE802154e], Section 6.4.3.3.3) 306 +--------------------------------+------------+ 307 | IEEE802.15.4e TSCH parameter | Value | 308 +--------------------------------+------------+ 309 | TsTxOffset | 2120us | 310 +--------------------------------+------------+ 311 | TsLongGT | 2000us | 312 +--------------------------------+------------+ 313 | TsTxAckDelay | 1000us | 314 +--------------------------------+------------+ 315 | TsShortGT | 400us | 316 +--------------------------------+------------+ 317 | Time Slot duration | 10000us | 318 +--------------------------------+------------+ 320 3. Enhanced Beacons Configuration and Content 322 [IEEE802154e] does not define how often EBs are sent, not their 323 contents. The choice of the duration between two EBs needs to take 324 into account whether EBs are used as the only mechanism to 325 synchronize devices, or whether a Keep-Alive (KA) mechanism is also 326 used. For a minimal TSCH configuration, a mote SHOULD send an EB 327 every EB_PERIOD. For additional reference see [I-D.ietf-6tisch-tsch] 328 where different synchronization approaches are summarized. 330 EBs MUST be sent with the Beacon IEEE802.15.4 frame type and this EBs 331 MUST carry the Information Elements (IEs) listed below. 333 The content of the IEs is presented here for completeness, however 334 this information is redundant with [I-D.ietf-6tisch-tsch] and 335 [IEEE802154e]. 337 3.1. Sync IE 339 Contains synchronization information such as ASN and Join Priority. 340 The value of Join Priority is discussed in Section 5.2. 342 3.1.1. IE Header 344 Length (b0-b7) = 0x06 346 Sub-ID (b8-b14) = 0x1a 348 Type (b15) = 0x00 (short) 350 3.1.2. IE Content 352 ASN Byte 1 (b16-b23) 354 ASN Byte 2 (b24-b31) 356 ASN Byte 3 (b32-b39) 358 ASN Byte 4 (b40-b47) 360 ASN Byte 5 (b48-b55) 362 Join Priority (b56-b63) 364 3.2. TSCH Timeslot IE 366 Contains the timeslot template identifier. This specification uses 367 the default timeslot template as defined in [IEEE802154e], 368 Section 5.2.4.15. 370 3.2.1. IE Header 372 Length (b0-b7) = 0x01 374 Sub-ID (b8-b14) = 0x1c 376 Type (b15) = 0x00 (short) 378 3.2.2. IE Content 380 Timeslot Template ID (b0-b7) = 0x00 382 3.3. Channel Hopping IE 384 Contains the channel hopping template identifier. This specification 385 uses the default channel hopping template, as defined in 386 [IEEE802154e], Section 5.2.4.16. 388 3.3.1. IE Header 390 Length (b0-b7) = 0x01 392 Sub-ID (b8-b14) = 0x1d 394 Type (b15) = 0x00 (short) 396 3.3.2. IE Content 398 Channel Hopping Template ID (b0-b7) = 0x00 400 3.4. Frame and Link IE 402 Each node MUST indicate the schedule in each EB through a Frame and 403 Link IE. This enables nodes which implement [IEEE802154e] to 404 configure their schedule as they join the network. 406 3.4.1. IE Header 408 Length (b0-b7) = variable 410 Sub-ID (b8-b14) = 0x1b 411 Type (b15) = 0x00 (short) 413 3.4.2. IE Content 415 # Slotframes (b16-b23) = 0x01 417 Slotframe ID (b24-b31) = 0x01 419 Size Slotframe (b32-b47) = variable 421 # Links (b48-b55) = 0x01 423 For the active cell in the minimal schedule: 425 Channel Offset (2B) = 0x00 427 Slot Number (2B) = 0x00 429 LinkOption (1B) = as described in Section 2.2 431 4. Acknowledgment 433 Link-layer acknowledgment frames are built according to 434 [IEEE802154e]. Data frames and command frames sent to a unicast MAC 435 destination address request an acknowledgment. The acknowledgment 436 frame is of type ACK (0x10). Each acknowledgment contains the 437 following IE: 439 4.1. ACK/NACK Time Correction IE 441 The ACK/NACK time correction IE carries the measured de- 442 synchronization between the sender and the receiver. 444 4.1.1. IE Header 446 Length (b0-b7) = 0x02 448 Sub-ID (b8-b14) = 0x1e 450 Type (b15) = 0x00 (short) 452 4.1.2. IE Content 454 Time Synchronization Information and ACK status (b16-b31) 456 The possible values for the Time Synchronization Information and ACK 457 status are described in [IEEE802154e] and reproduced in the following 458 table: 460 ACK status and Time Synchronization Information. 462 +-----------------------------------+-----------------+ 463 | ACK Status | Value | 464 +-----------------------------------+-----------------+ 465 | ACK with positive time correction | 0x0000 - 0x07ff | 466 +-----------------------------------+-----------------+ 467 | ACK with negative time correction | 0x0800 - 0x0fff | 468 +-----------------------------------+-----------------+ 469 | NACK with positive time correction| 0x8000 - 0x87ff | 470 +-----------------------------------+-----------------+ 471 | NACK with negative time correction| 0x8800 - 0x8fff | 472 +-----------------------------------+-----------------+ 474 5. Neighbor information 476 [IEEE802154e] does not define how and when each node in the network 477 keeps information about its neighbors. This document recommends to 478 keep the following information in the neighbor table: 480 5.1. Neighbor Table 482 The exact format of the neighbor table is implementation-specific, 483 but it SHOULD contain the following information for each neighbor: 485 Neighbor statistics: 487 numTx: number of transmitted packets to that neighbor 489 numTxAck: number of transmitted packets that have been 490 acknowledged by that neighbor 492 numRx: number of received packets from that neighbor 494 The EUI64 of the neighbor. 496 Timestamp when that neighbor was heard for the last time. This 497 can be based on the ASN counter or any other time base. Can be 498 used to trigger a keep-alive message. 500 RPL rank of that neighbor. 502 A flag indicating whether this neighbor is a time source neighbor. 504 Connectivity statistics (e.g., RSSI), which can be used to 505 determine the quality of the link. 507 In addition to that information, each node has to be able to compute 508 some RPL Objective Function (OF), taking into account the neighbor 509 and connectivity statistics. An example RPL objective function is 510 the OF Zero as described in [RFC6552] and Section 7.1.1. 512 5.2. Time Source Neighbor Selection 514 Each node MUST select at least one time source neighbor among the 515 nodes in its RPL routing parent set. When a node joins a network, it 516 has no routing information. To select its time source neighbor, it 517 uses the Join Priority field in the EB, as described in 518 Section 5.2.4.13 and Table 52b of [IEEE802154e]. The Sync IE 519 contains the ASN and 1 Byte field named Join Priority. The Join 520 Priority of any node is equivalent to the result of the function 521 DAGRank(rank) as defined by [RFC6550] and Section 7.1.1. The Join 522 Priority of the DAG root is zero, i.e., EBs sent from the DAG root 523 are sent with Join Priority equal to 0. A lower value of the Join 524 Priority indicates that the device is the preferred one to connect 525 to. When a node joins the network, it MUST NOT send EBs before 526 having acquired a RPL rank. This avoids routing loops and matches 527 RPL topology with underlying mesh topology. As soon as a node 528 acquires a RPL rank (see [RFC6550] and Section 7.1.1), it SHOULD send 529 Enhanced Beacons including a Sync IE with Join Priority field set to 530 DAGRank(rank), where rank is the node's rank. If a node receives EBs 531 from different nodes with equal Join Priority, the time source 532 neighbor selection should be assessed by other metrics that can help 533 determine the better connectivity link. Time source neighbor 534 hysteresis SHOULD be used, according to the rules defined in 535 Section 7.2.3. If connectivity to the time source neighbor is lost, 536 a new time source neighbor MUST be chosen among the neighbors in the 537 RPL routing parent set. 539 The decision for a node to select one Time Source Neighbor when 540 multiple EBs are received is open to implementers. For example a 541 node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT neighbors have 542 been received to select the best Time Source Neighbor. This 543 condition MAY apply unless a second EB is not received after 544 MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting 545 a first Time Source Neighbor. 547 Optionally, some form of hysteresis SHOULD be implemented to avoid 548 frequent changes in time source neighbors. 550 6. Queues and Priorities 552 [IEEE802154e] does not define the use of queues to handle upper layer 553 data (either application or control data from upper layers). This 554 document recommends the use of a single queue with the following 555 rules: 557 When the node is not synchronized to the network, higher layers 558 are not able to insert packets into the queue. 560 Frames generated by the MAC layer (e.g., EBs and ACK) have a 561 higher priority than packets received from a higher layer. 563 IEEE802.15.4 frames of types Beacon and Command have a higher 564 priority than IEEE802.15.4 frames of types Data and ACK. 566 One entry in the queue is reserved at all times for an 567 IEEE802.15.4 frames of types Beacon or Command frames. 569 7. RPL on TSCH 571 Nodes in the network MUST use the RPL routing protocol [RFC6550]. 573 7.1. RPL Objective Function Zero 575 Nodes in the network MUST use the RPL routing protocol [RFC6550] and 576 implement the RPL Objective Function Zero [RFC6552]. 578 7.1.1. Rank computation 580 The rank computation is described at [RFC6552], Section 4.1. 581 Briefly, a node rank is computed by the following equation: 583 R(N) = R(P) + rank_increase 585 rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 587 Where: 589 R(N): Rank of the node. 591 R(P): Rank of the parent obtained as part of the DIO information. 593 rank_increase: The result of a function that determines the rank 594 increment. 596 Rf (rank_factor): A configurable factor that is used to multiply 597 the effect of the link properties in the rank_increase 598 computation. If none is configured, rank_factor of 1 is used. In 599 this specification, a rank_factor of 1 MUST be used. 601 Sp (step_of_rank): (strictly positive integer) - an intermediate 602 computation based on the link properties with a certain neighbor. 603 In this specification, 2*ETX (Expected Transmissions) as defined 604 by [decouti03high] and [RFC6551] MUST be used. The ETX is 605 computed as the inverse of the Packet Delivery Ratio (PDR), and 606 MAY be computed as the number of acknowledged packets, divided by 607 the number of transmitted packets to a certain node. E.g: 608 Sp=2*numTX/numTXAck 610 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 611 to the step_of_rank of a preferred parent, to allow the selection 612 of an additional feasible successor. If none is configured to the 613 device, then the step_of_rank is not stretched. In this 614 specification, stretch_of_rank MUST be set to 0. 616 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 617 constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550]. 618 DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. 620 DAGRank(rank): Equivalent to the floor of (Rf*Sp + Sr) as defined 621 by [RFC6550]. Specifically, when an Objective Function computes 622 Rank, this is defined as an unsigned integer (i.e., a 16-bit 623 value) Rank quantity. When the Rank is compared, e.g. to 624 determine parent relationships or loop detection, the integer 625 portion of the Rank is used. The integer portion of the Rank is 626 computed by the DAGRank() macro as floor(x) where floor(x) is the 627 function that evaluates to the greatest integer less than or equal 628 to x. DAGRank(rank) = floor(rank/MinHopRankIncrease) 630 Rank computation scenario 632 +-------+ 633 | P | R(P) 634 | | 635 +-------+ 636 | 637 | 638 | 639 +-------+ 640 | N | R(N)=R(P) + rank_increase 641 | | rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 642 +-------+ Sp=2*ETX 644 7.1.2. Rank computation Example 646 This section illustrates with an example the use of the Objective 647 Function Zero. Assume the following parameters: 649 Rf = 1 651 Sp = 2* ETX 653 Sr = 0 655 minHopRankIncrease = 256 (default in RPL) 657 ETX=(numTX/numTXAck) 659 r(n) = r(p) + rank_increase 661 rank_increase = (Rf*Sp + Sr) * minHopRankIncrease 663 rank_increase = 512*numTx/numTxACK 665 Rank computation example for 5 hop network where numTx=100 and 666 numTxAck=75 for all nodes 668 +-------+ 669 | 0 | R(0)=0 670 | | DAGRank(R(0)) = 0 671 +-------+ 672 | 673 | 674 +-------+ 675 | 1 | R(1)=R(0)+683=683 676 | | DAGRank(R(1)) = 2 677 +-------+ 678 | 679 | 680 +-------+ 681 | 2 | R(2)=R(1)+683=1366 682 | | DAGRank(R(2)) = 5 683 +-------+ 684 | 685 | 686 +-------+ 687 | 3 | R(3)=R(2)+683=2049 688 | | DAGRank(R(3)) = 8 689 +-------+ 690 | 691 | 692 +-------+ 693 | 4 | R(4)=R(3)+683=2732 694 | | DAGRank(R(4)) = 10 695 +-------+ 696 | 697 | 698 +-------+ 699 | 5 | R(5)=R(4)+683=3415 700 | | DAGRank(R(5)) = 13 701 +-------+ 703 7.2. RPL Configuration 705 In addition to the Objective Function (OF), a minimal configuration 706 for RPL should indicate the preferred mode of operation and trickle 707 timer operation so different RPL implementations can inter-operate. 708 RPL information SHOULD be transported in the flow label in the LLN as 709 defined in [I-D.thubert-6man-flow-label-for-rpl] 711 7.2.1. Mode of Operation 713 For downstream route maintenance, in a minimal configuration, RPL 714 SHOULD be set to operate in the Non-Storing mode as described by 715 [RFC6550] Section 9.7. Storing mode ([RFC6550] Section 9.8) MAY be 716 supported in less constrained devices. 718 7.2.2. Trickle Timer 720 RPL signaling messages such as DIOs are sent using the Trickle 721 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 722 specification, the Trickle Timer MUST be used with the RPL defined 723 default values [RFC6550] (Section 8.3.1). For a description of the 724 Trickle timer operation see Section 4.2 on [RFC6206]. 726 7.2.3. Hysteresis 728 According to [RFC6552], [RFC6719] recommends the use of a boundary 729 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 730 when ranks are compared. When evaluating a parent that belongs to a 731 smaller path cost than current minimum path, the candidate node is 732 selected as new parent only if the difference between the new path 733 and the current path is greater than the defined 734 PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the 735 current preferred parent. As for [RFC6719] the recommended value for 736 PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used, the 737 recommendation for this document is to use PARENT_SWITCH_THRESHOLD 738 equal to 394 as the metric being used is 2*ETX. This is mechanism is 739 suited to deal with parent hysteresis in both cases routing parent 740 and time source neighbor selection. 742 7.2.4. Variable Values 744 The following table presents the RECOMMENDED values for the RPL- 745 related variables defined in the previous section. 747 Recommended variable values 749 +-------------------------+----------+ 750 | Variable | Value | 751 +-------------------------+----------+ 752 | EB_PERIOD | 10s | 753 +-------------------------+----------+ 754 | MAX_EB_DELAY | 180 | 755 +-------------------------+----------+ 756 | NUM_NEIGHBOURS_TO_WAIT | 2 | 757 +-------------------------+----------+ 758 | PARENT_SWITCH_THRESHOLD | 394 | 759 +-------------------------+----------+ 761 8. Acknowledgements 763 The authors would like to acknowledge the guidance and input provided 764 by the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne. 766 9. References 768 9.1. Normative References 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, March 1997. 773 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 774 "The Trickle Algorithm", RFC 6206, March 2011. 776 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 777 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 778 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 779 Lossy Networks", RFC 6550, March 2012. 781 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 782 Barthel, "Routing Metrics Used for Path Calculation in 783 Low-Power and Lossy Networks", RFC 6551, March 2012. 785 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 786 Protocol for Low-Power and Lossy Networks (RPL)", RFC 787 6552, March 2012. 789 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 790 Hysteresis Objective Function", RFC 6719, September 2012. 792 9.2. Informative References 794 [I-D.ietf-6tisch-tsch] 795 Watteyne, T., Palattella, M., and L. Grieco, "Using 796 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 797 Statement and Goals", draft-ietf-6tisch-tsch-00 (work in 798 progress), November 2013. 800 [I-D.ietf-6tisch-architecture] 801 Thubert, P., Watteyne, T., and R. Assimiti, "An 802 Architecture for IPv6 over the TSCH mode of IEEE 803 802.15.4e", draft-ietf-6tisch-architecture-02 (work in 804 progress), June 2014. 806 [I-D.ietf-6tisch-terminology] 807 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 808 "Terminology in IPv6 over the TSCH mode of IEEE 809 802.15.4e", draft-ietf-6tisch-terminology-01 (work in 810 progress), February 2014. 812 [I-D.ietf-6tisch-6top-interface] 813 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 814 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 815 6top-interface-00 (work in progress), March 2014. 817 [I-D.richardson-6tisch-security-architecture] 818 Richardson, M., "security architecture for 6top: 819 requirements and structure", draft-richardson-6tisch- 820 security-architecture-02 (work in progress), April 2014. 822 [I-D.ietf-roll-terminology] 823 Vasseur, J., "Terms used in Routing for Low power And 824 Lossy Networks", draft-ietf-roll-terminology-13 (work in 825 progress), October 2013. 827 [I-D.phinney-roll-rpl-industrial-applicability] 828 Phinney, T., Thubert, P., and R. Assimiti, "RPL 829 applicability in industrial networks", draft-phinney-roll- 830 rpl-industrial-applicability-02 (work in progress), 831 February 2013. 833 [I-D.thubert-6man-flow-label-for-rpl] 834 Thubert, P., "The IPv6 Flow Label within a RPL domain", 835 draft-thubert-6man-flow-label-for-rpl-03 (work in 836 progress), May 2014. 838 9.3. External Informative References 840 [IEEE802154e] 841 IEEE standard for Information Technology, "IEEE std. 842 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 843 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 844 2012. 846 [IEEE802154] 847 IEEE standard for Information Technology, "IEEE std. 848 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 849 and Physical Layer (PHY) Specifications for Low-Rate 850 Wireless Personal Area Networks", June 2011. 852 [decouti03high] 853 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 854 High-Throughput Path Metric for Multi-Hop Wireless 855 Routing", MobiCom '03, The 9th ACM International 856 Conference on Mobile Computing and Networking, San Diego, 857 California", June 2003. 859 [OpenWSN] "Berkeley's OpenWSN Project Homepage", 860 . 862 Authors' Addresses 864 Xavier Vilajosana (editor) 865 Universitat Oberta de Catalunya 866 156 Rambla Poblenou 867 Barcelona, Catalonia 08018 868 Spain 870 Phone: +34 (646) 633 681 871 Email: xvilajosana@uoc.edu 873 Kris Pister 874 University of California Berkeley 875 490 Cory Hall 876 Berkeley, California 94720 877 USA 879 Email: pister@eecs.berkeley.edu