idnits 2.17.1 draft-vilajosana-6tisch-minimal-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 09, 2013) is 3849 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 748, but not defined == Missing Reference: 'DeCouto03' is mentioned on line 760, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 754, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 767, but not defined == Unused Reference: 'RFC2119' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6tsch-architecture' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tsch-security' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 735, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 10 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: April 12, 2014 University of California Berkeley 6 October 09, 2013 8 Minimal 6TiSCH Configuration 9 draft-vilajosana-6tisch-minimal-00 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 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 April 12, 2014. 37 Copyright Notice 39 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Minimal Schedule Configuration . . . . . . . . . . . . . . . 3 56 2.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 6 59 2.4. Time Slot timing . . . . . . . . . . . . . . . . . . . . 6 60 3. Enhanced Beacons Configuration and Content . . . . . . . . . 7 61 3.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Frame and Cell IE . . . . . . . . . . . . . . . . . . . . 8 65 3.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 66 3.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 9 67 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 9 69 4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 10 71 5. Neighbour information . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Neighbour Table . . . . . . . . . . . . . . . . . . . . . 10 73 5.2. Time Source Neighbour Selection . . . . . . . . . . . . . 11 74 6. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 11 75 7. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.1. RPL Objective Function Zero . . . . . . . . . . . . . . . 12 77 7.1.1. Rank computation . . . . . . . . . . . . . . . . . . 12 78 7.1.2. Rank computation Example . . . . . . . . . . . . . . 13 79 7.2. RPL Configuration . . . . . . . . . . . . . . . . . . . . 15 80 7.2.1. Mode of Operation . . . . . . . . . . . . . . . . . . 15 81 7.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . . 16 82 7.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 16 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 9.2. Informative References . . . . . . . . . . . . . . . . . 17 87 9.3. External Informative References . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 The nodes in a [IEEE802154e] TSCH network follow a communication 93 schedule. The entity (centralized or decentralized) responsible for 94 building and maintaining that schedule has very precise control over 95 the trade-off between the network's latency, bandwidth, reliability 96 and power consumption. During early interoperability testing and 97 development, however, simplicity is often more important than 98 efficiency. One goal of this document is to define the simplest set 99 of rules for building a [IEEE802154e] TSCH-compliant network, at the 100 necessary price of lesser efficiency. Yet, this minimal mode of 101 operation can also be used during network bootstrap before any 102 schedule is installed into the network so nodes can self organize and 103 the management and configuration information be distributed. In 104 addition, as outlined in 105 [I-D.phinney-roll-rpl-industrial-applicability] the minimal 106 configuration can be used as a fallback mode of operation, ensuring 107 connectivity of nodes in case that dynamic scheduling mechanisms fail 108 or are not available. [IEEE802154e] provides a mechanism whereby the 109 details of slotframe length, timeslot timing, and channel hopping 110 pattern are communicated at synchronization to a node, also Enhanced 111 Beacons can be used to periodically update nodes information. This 112 document describes specific settings for these parameters. Nodes 113 SHOULD broadcast properly formed Enhanced Beacons to announce these 114 values, but during initial implementation and debugging it may be 115 convenient to hard-code these values. 117 2. Minimal Schedule Configuration 119 In order to form a network, a minimum schedule configuration is 120 required so nodes can advertise the presence of the network, and 121 allow other nodes to join. 123 2.1. Slotframe 125 The slotframe, as defined in [I-D.palattella-6tsch-terminology], is 126 an abstraction of the MAC layer that defines a collection of time 127 slots of equal length and priority, and which repeats over time. In 128 order to set up a minimal TSCH network, nodes need to be synchronized 129 with the same slotframe configuration so they can exchange Enhanced 130 Beacons (EBs) and data packets. This document recommends the 131 following slotframe configuration. 133 Minimal configuration 134 +------------------------------------+----------------------+ 135 | Property | Value | 136 +------------------------------------+----------------------+ 137 | Number of time slots per Slotframe | 101 | 138 +------------------------------------+----------------------+ 139 | Number of available channels | 16 | 140 +------------------------------------+----------------------+ 141 | Number of EBs cells | 1 (slotOffset 0) | 142 +------------------------------------+----------------------+ 143 | Number of scheduled cells | 5 (slotOffsets | 144 | | 1,2,3,4,5) | 145 +------------------------------------+----------------------+ 146 | Number of unscheduled cells | 95 (from slotOffset | 147 | | 6 to 100) | 148 +------------------------------------+----------------------+ 149 | Number of MAC retransmissions (max)| 3 | 150 +------------------------------------+----------------------+ 151 | Time Slot duration | 15ms | 152 +------------------------------------+----------------------+ 154 The suggested minimal schedule may be hard-coded in each node. The 155 slotframe is composed of 101 time slots. The first slot in the 156 slotframe is used to send Enhanced Beacons announcing the presence of 157 the network. These EBs are not acknowledged. Five cells are 158 scheduled for exchanging data packets, as described in Section 2.2. 159 These cells are scheduled at slotOffset 1 to 5, and channeOffset 0. 160 Per the IEEE802.15.4e TSCH, data packets sent on these cells to a 161 unicast MAC address are acknowledged by the receiver. The 95 162 remaining cells are unscheduled, but are available to be allocated by 163 dynamic scheduling solutions. 165 Minimal schedule overview 166 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 167 chan.Off. 0 | EB |TxRxS|TxRxS|TxRxS|TxRxS|TxRxS| OFF | ... | OFF | 168 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 169 chan.Off. 1 | | | | | | | | ... | | 170 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 171 ... 172 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 173 chan.Off. 15 | | | | | | | | ... | | 174 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 175 0 1 2 3 4 5 6 100 177 EB: Enhanced Beacon 178 Tx: Transmit 179 Rx: Receive 180 S: Shared 181 OFF: Unscheduled (can be used by a dynamic scheduling mechanism) 183 2.2. Cell Options 185 Per the [IEEE802154e] TSCH, each scheduled cell has a bitmap of cell 186 options assigned, named LinkOption. All scheduled cells in the 187 minimal schedule are configured as Hard cells 188 [I-D.watteyne-6tsch-tsch-lln-context][I-D.wang-6tsch-6top]. 189 Additional available cells can be scheduled by a dynamic scheduling 190 solution and can either be configured as hard cells or soft cells 191 without any restriction. 193 The EB cell is assigned the following bitmap of cell options: 195 b0 = Transmit = 1 (set) 197 b1 = Receive = 0 (clear) 199 b2 = Shared = 0 (clear) 201 b3 = Timekeeping = 0 (clear) 203 b4 = Hard = 1 (set) 205 b5-b7 = Reserved (clear) 207 The data cells are assigned the bitmap of cell options below that 208 results in "Slotted Aloha" behaviour. Because both the "Transmit" 209 and "Receive" bits are set, a node either transmits, if there is a 210 packet in its queue, or listens if it has nothing to transmit. 211 Because the "shared" bit is set, the back-off mechanism defined in 212 [IEEE802154e] is used to resolve contention. 214 b0 = Transmit = 1 (set) 216 b1 = Receive = 1 (set) 218 b2 = Shared = 1 (set) 220 b3 = Timekeeping = 0 (clear) 222 b4 = Hard = 1 (set) 224 b5-b7 = Reserved (clear) 226 All remaining cells are unscheduled. Thus the nodes can keep their 227 radio off. In a memory efficient implementation, scheduled cells 228 could be represented by a circular linked list. Unscheduled cells 229 SHOULD NOT occupy any memory. 231 2.3. Retransmissions 233 The maximum number of MAC-layer retransmissions is set to 3. For 234 packets which require an acknowledgement, if none is received after a 235 total of 4 attempts, the transmissions is considered failed and the 236 MAC layer MUST notify the upper layer. Packets sent to the broadcast 237 MAC address (including EBs) are not acknowledged and therefore not 238 retransmitted. 240 2.4. Time Slot timing 242 The figure below shows an active timeslot in which a packet is sent 243 from the transmitter node (TX) to the receiver node (RX). A MAC 244 acknowledgement is sent back from the RX to the TX node, indicating 245 successful reception. The TsTxOffset duration defines the instant in 246 the timeslot when the first byte of the transmitted packet leaves the 247 radio of the TX node. The radio of the RX node is turned on TsLongGT 248 /2 before that instant, and listen for at least TsLongGT. This 249 allows for a de-synchronization between the two node of at most 250 TsLongGT. The RX node needs to send the first byte of the MAC 251 acknowledgement exactly TsTxAckDelay after the end of the last byte 252 of the received packet. TX's radio has to be turned on TsShortGT/2 253 before that time, and keep listening for at least TsShortGT. 255 Time slot internal timing diagram 257 /------------------- Time Slot duration --------------------/ 258 | /tsShortGT/ | 259 | | | | | | 260 |------------+-----------------+--------------+------+------| 261 TX | | TX-Packet | |RX Ack| | 262 |------------+-----------------+--------------+------+------| 263 |/tsTxOffset/| | | | | 264 | | | | | | 265 |------------+-----------------+--------------+------+------| 266 RX | | | | RX-Packet | |TX Ack| | 267 |---------+--+--+--------------+--------------+------+------| 268 | | | | | | | | 269 | /tsLongGT/ |/TsTxAckDelay/| | | 270 Start End 271 of of 272 Slot Slot 274 [IEEE802154e] does not define the different durations of a time slot. 275 It does allow those durations to be sent in the EBs (through a 276 TimeSlot IE). This document recommends to pre-configure the 277 different durations to the values listed below or use EBs to learn 278 those values included in the TimeSlot IE. 280 Timeslot durations 282 +---------------------------------+------------------+ 283 | IEEE802.15.4e TSCH parameter | Value | 284 +---------------------------------+------------------+ 285 | TsTxOffset | 4000us | 286 +---------------------------------+------------------+ 287 | TsLongGT | 2600us | 288 +---------------------------------+------------------+ 289 | TsTxAckDelay | 4606us | 290 +---------------------------------+------------------+ 291 | TsShortGT | 1000us | 292 +---------------------------------+------------------+ 293 | Time Slot duration | 15000us | 294 +---------------------------------+------------------+ 296 3. Enhanced Beacons Configuration and Content 298 [IEEE802154e] does not define how often or which EBs are sent. The 299 choice of the duration between two EBs needs to take into account 300 whether EBs are used as the only mechanism to synchronize devices, or 301 whether a Keep-Alive (KA) mechanism is used in parallel. For a 302 simplest TSCH configuration, a mote SHOULD send an EB every 10s. For 303 additional reference see [I-D.watteyne-6tsch-tsch-lln-context] where 304 different synchronization approaches are summarized. 306 EBs MUST be sent with the Beacon IEEE802.15.4 frame type and this EBs 307 MUST carry the following Information Elements (IEs): (The content of 308 the IEs is presented here for clarity, however this information is 309 redundant with [I-D.watteyne-6tsch-tsch-lln-context] and 310 [IEEE802154e].) 312 3.1. Sync IE 314 Contains synchronization information such as ASN and Join Priority. 315 The value of Join Priority is discussed in Section 5.2. 317 3.1.1. IE Header 319 Length (b0-b7) = 0x06 321 Sub-ID (b8-b14) = 0x1a 323 Type (b15) = 0x00 (short) 325 3.1.2. IE Content 327 ASN Byte 1 (b16-b23) 329 ASN Byte 2 (b24-b31) 331 ASN Byte 3 (b32-b39) 333 ASN Byte 4 (b40-b47) 335 ASN Byte 5 (b48-b55) 337 Join Priority (b56-b63) 339 3.2. Frame and Cell IE 341 Although the schedule may be hard-coded during development, each node 342 MUST indicate the schedule in each EB through a Frame and Cell IE. 343 This enables nodes which implement [IEEE802154e] fully to configure 344 their schedule as they join the network, and interact with nodes 345 using a hard-coded schedule. 347 3.2.1. IE Header 349 Length (b0-b7) = variable 351 Sub-ID (b8-b14) = 0x1b 353 Type (b15) = 0x00 (short) 355 3.2.2. IE Content 357 # Slotframes (b16-b23) = 0x01 359 Slotframe ID (b24-b31) = 0x01 361 Size Slotframe (b32-b47) = 0x65 (101) 363 # Links (b48-b55) = 0x06 365 For each link in the minimal schedule: 367 Channel Offset (2B) = 0x00 369 Slot Number (2B) = from 0x00 to 0x05 371 LinkOption (1B) = as described in Section 2.2 373 4. Acknowledgement 375 MAC-layer acknowledgement frames are built according to 376 [IEEE802154e]. Data frames and command frames sent to a unicast MAC 377 destination address request an acknowledgement. The acknowledgement 378 frame is of type ACK (0x10). Each acknowledgement contains the 379 following IE: 381 4.1. ACK/NACK Time Correction IE 383 The ACK/NACK time correction IE is used to carry the measured de- 384 synchronization between the sender and the receiver. 386 4.1.1. IE Header 388 Length (b0-b7) = 0x02 390 Sub-ID (b8-b14) = 0x1e 392 Type (b15) = 0x00 (short) 394 4.1.2. IE Content 396 Time Synch Info and ACK status (b16-b31) 398 The possible values for the Time Synch Info and ACK status are 399 described in [IEEE802154e] and reproduced in the following table: 401 ACK status and Time Synchronization information. 403 +-----------------------------------+------------------+ 404 | ACK Status | Value | 405 +-----------------------------------+------------------+ 406 | ACK with positive time correction | 0x0000 - 0x07ff | 407 +-----------------------------------+------------------+ 408 | ACK with negative time correction | 0x0800 - 0x0fff | 409 +-----------------------------------+------------------+ 410 | NACK with positive time correction| 0x8000 - 0x87ff | 411 +-----------------------------------+------------------+ 412 | NACK with negative time correction| 0x8800 - 0x8fff | 413 +-----------------------------------+------------------+ 415 5. Neighbour information 417 [IEEE802154e] does not define how and when each node in the network 418 keeps information about its neighbours. This document recommends to 419 keep the following information in the Neighbour table: 421 5.1. Neighbour Table 423 The exact format of the neighbour table is implementation-specific, 424 but it SHOULD contain the following information for each neighbour: 426 Neighbour statistics: 428 numTx: number of transmitted packets to that neighbour 430 numTxAck: number of transmitted packets that have been 431 acknowledged by that neighbour 433 numRx: number of received packets from that neighbour 435 The EUI64 of the neighbour address. 437 Timestamp when that neighbour was heard for the last time. This 438 can be based on the ASN counter or any other time base. Can be 439 used to trigger a keep-alive message. 441 RPL rank of that neighbour. 443 A flag which indicates whether this neighbour is a time source 444 neighbour. 446 Connectivity statistics (e.g., RSSI), which can be used to 447 determine the quality of the link. 449 In addition of that information, each node has to be able to compute 450 some RPL Objective Function (OF) taking into account the neighbour 451 and connectivity statistics. An example RPL objective function is 452 the OF Zero as described in [RFC6552] and Section 7.1.1. 454 5.2. Time Source Neighbour Selection 456 Each node MUST select at least one time source neighbour amongst its 457 known neighbours in its RPL routing parent set. When a node joins a 458 network, it has no routing information yet. To select its time 459 source neighbour, uses the Join Priority information advertised in 460 the EB as described in Section 5.2.4.13 and Table 52b of 461 [IEEE802154e]. The Sync IE contains the ASN and 1 Byte field named 462 Join Priority. The Join Priority of any node is equivalent to the 463 result of the function DAGRank(rank) as defined by [RFC6550] and 464 Section 7.1.1. The Join Priority of the DAG root is zero, i.e., EBs 465 sent from the DAG root are sent with Join Priority equal to 0. A 466 lower value of the Join Priority indicates that the device is the 467 preferred one to connect to. When a node Joins the network MUST NOT 468 be allowed to send EBs until it has acquired a RPL rank. The latter 469 avoids topology loops and matches RPL topology with underlying mesh 470 topology. As soon as a node acquires a RPL rank (see [RFC6550] and 471 Section 7.1.1), it SHOULD send Enhanced Beacons including a Sync IE 472 with Join Priority field set as DAGRank(rank) where rank is the rank 473 of the actual node. In case of a node receives EBs from different 474 nodes with equal Join Priority, the time source neighbour selection 475 should be assessed by other metrics that can help to determine the 476 better connectivity link. Time source neighbor hysteresis SHOULD be 477 addressed according to the rules defined in Section 7.2.3. If 478 connectivity to the time source neighbor is lost, a new time source 479 neighbor MUST be chosen among the neighbor in the RPL routing parent 480 set. 482 Optionally, some form of hysteresis SHOULD be implemented to avoid 483 frequent changes in time source neighbors. 485 6. Queues and Priorities 487 [IEEE802154e] does not define the use of queues to handle upper layer 488 data (either application or control data from upper layers). This 489 document recommends the use of a single queue with the following 490 rules: 492 When the node is not synchronized to the network, higher layers 493 are not able to insert packets into the queue. 495 Frames generated by the MAC layer (e.g., EBs and ACK) have a 496 higher priority than packets received from a higher layer. 498 IEEE802.15.4 frames of types Beacon and Command have a higher 499 priority than IEEE802.15.4 frames of types Data and ACK. 501 One entry in the queue is reserved at all times for an 502 IEEE802.15.4 frames of types Beacon or Command frames. 504 7. RPL on TSCH 506 Nodes in the network MUST use the RPL routing protocol 508 7.1. RPL Objective Function Zero 510 Nodes in the network MUST use the RPL routing protocol [RFC6550]. 512 7.1.1. Rank computation 514 The rank computation is described at [RFC6552] Section 4.1. Briefly, 515 a node rank is computed by the following equation: 517 R(N) = R(P) + rank_increase 519 rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 521 Where: 523 R(N): Rank of the node. 525 R(P): Rank of the parent obtained as part of the DIO information. 527 rank_increase: The result of a function that determines the rank 528 increment. 530 Rf (rank_factor): A configurable factor that is used to multiply 531 the effect of the link properties in the rank_increase 532 computation. If none is configured, then a rank_factor of 1 is 533 used. For the purpose of this document rank_factor MUST be set to 534 1. 536 Sp (step_of_rank): (strictly positive integer) - an intermediate 537 computation based on the link properties with a certain neighbour. 538 For the purpose of this document 2*ETX (Expected Transmissions) as 539 defined by [DeCouto03] and [RFC6551] MUST be used. The ETX will 540 be computed as the inverse of the Packet Delivery Ratio (PDR) 541 computed as the number of acknowledged packets divided by the 542 number of transmitted packets to a certain node. E.g: Sp=2*numTX/ 543 numTXAck 545 Sr (stretch_of_rank): (unsigned integer) - the maximum 546 augmentation to the step_of_rank of a preferred parent to allow 547 the selection of an additional feasible successor. If none is 548 configured to the device, then the step_of_rank is not stretched. 549 For the present document stretch_of_rank MUST be set to 0. 551 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 552 constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550]. 553 DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. 555 DAGRank(rank): Equivalent to the floor of (Rf*Sp + Sr) as defined 556 by [RFC6550]. Specifically, when an Objective Function computes 557 Rank this is defined as an unsigned integer (i.e., 16-bit) Rank 558 quantity. When the Rank is compared, e.g., for determination of 559 parent relationships or loop detection, the integer portion of the 560 Rank is used. The integer portion of the Rank is computed by the 561 DAGRank() macro as floor(x) where floor(x) is the function that 562 evaluates to the greatest integer less than or equal to x. 563 DAGRank(rank) = floor(rank/MinHopRankIncrease) 565 Rank computation scenario 567 +-------+ 568 | P | R(P) 569 | | 570 +-------+ 571 | 572 | 573 | 574 +-------+ 575 | N | R(N)=R(P) + rank_increase 576 | | rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 577 +-------+ Sp=2*ETX 579 7.1.2. Rank computation Example 580 This sections illustrates with an example the use of the Objective 581 Function Zero. Assume the following parameters: 583 Rf = 1 585 Sp = 2* ETX 587 Sr = 0 589 minHopRankIncrease = 256 (default in RPL) 591 ETX=(numTX/numTXAck) 593 r(n) = r(p) + rank_increase 595 rank_increase = (Rf*Sp + Sr) * minHopRankIncrease 597 rank_increase = 512*numTx/numTxACK 599 Rank computation example for 5 hop network where numTx=100 and 600 numTxAck=75 for all nodes 601 +-------+ 602 | 0 | R(0)=0 603 | | DAGRank(R(0)) = 0 604 +-------+ 605 | 606 | 607 +-------+ 608 | 1 | R(1)=R(0)+683=683 609 | | DAGRank(R(1)) = 2 610 +-------+ 611 | 612 | 613 +-------+ 614 | 2 | R(2)=R(1)+683=1366 615 | | DAGRank(R(2)) = 5 616 +-------+ 617 | 618 | 619 +-------+ 620 | 3 | R(3)=R(2)+683=2049 621 | | DAGRank(R(3)) = 8 622 +-------+ 623 | 624 | 625 +-------+ 626 | 4 | R(4)=R(3)+683=2732 627 | | DAGRank(R(4)) = 10 628 +-------+ 629 | 630 | 631 +-------+ 632 | 5 | R(5)=R(4)+683=3415 633 | | DAGRank(R(5)) = 13 634 +-------+ 636 7.2. RPL Configuration 638 In addition to the Objective Function (OF), a minimal configuration 639 for RPL should indicate the preferred mode of operation and trickle 640 timer operation so different RPL implementations can interoperate. 642 7.2.1. Mode of Operation 644 For downstream route maintenance, in a minimal configuration, RPL 645 MUST be set to operate in the Non-Storing mode as described by 646 [RFC6550] Section 9.7. Storing mode ([RFC6550] Section 9.8) MAY be 647 supported in less constrained devices. 649 7.2.2. Trickle Timer 651 RPL signalling messages such as DIOs are sent using the Trickle 652 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For the purpose 653 of this document, the Trickle Timer MUST be used with the RPL defined 654 default values [RFC6550] (Section 8.3.1). For a description of the 655 Trickle timer operation see Section 4.2 on [RFC6206]. 657 7.2.3. Hysteresis 659 According to [RFC6552] the [RFC6719] recommends the use of a boundary 660 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 661 when ranks are compared. When evaluating a parent that belongs to a 662 smaller path cost than current minimum path, the candidate node is 663 selected as new parent only if the difference between the new path 664 and the current path is greater than the defined 665 PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the 666 current preferred parent. As for [RFC6719] the recommended value for 667 PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used, the 668 recommendation for this document is to use PARENT_SWITCH_THRESHOLD 669 equal to 394 as the metric being used is 2*ETX. This is mechanism is 670 suited to deal with parent hysteresis in both cases routing parent 671 and time source neighbor selection. 673 8. Acknowledgements 675 The authors would like to acknowledge the guidance and input provided 676 by the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne. 678 9. References 680 9.1. Normative References 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, March 1997. 685 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 686 "The Trickle Algorithm", RFC 6206, March 2011. 688 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 689 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 690 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 691 Lossy Networks", RFC 6550, March 2012. 693 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 694 Barthel, "Routing Metrics Used for Path Calculation in 695 Low-Power and Lossy Networks", RFC 6551, March 2012. 697 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 698 Protocol for Low-Power and Lossy Networks (RPL)", RFC 699 6552, March 2012. 701 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 702 Hysteresis Objective Function", RFC 6719, September 2012. 704 9.2. Informative References 706 [I-D.watteyne-6tsch-tsch-lln-context] 707 Watteyne, T., Palattella, M., and L. Grieco, "Using 708 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 709 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 710 context-02 (work in progress), May 2013. 712 [I-D.thubert-6tsch-architecture] 713 Thubert, P., Assimiti, R., and T. Watteyne, "An 714 Architecture for IPv6 over Timeslotted Channel Hopping", 715 draft-thubert-6tsch-architecture-02 (work in progress), 716 July 2013. 718 [I-D.palattella-6tsch-terminology] 719 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 720 "Terminology in IPv6 over Timeslotted Channel Hopping", 721 draft-palattella-6tsch-terminology-01 (work in progress), 722 July 2013. 724 [I-D.wang-6tsch-6top] 725 Wang, Q., Vilajosana, X., and T. Watteyne, "6TSCH 726 Operation Sublayer (6top)", draft-wang-6tsch-6top-00 (work 727 in progress), July 2013. 729 [I-D.ohba-6tsch-security] 730 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 731 A. Yegin, "Security Framework and Key Management Protocol 732 Requirements for 6TSCH", draft-ohba-6tsch-security-01 733 (work in progress), July 2013. 735 [I-D.ietf-roll-terminology] 736 Vasseur, J., "Terms used in Ruting for Low power And Lossy 737 Networks", draft-ietf-roll-terminology-13 (work in 738 progress), October 2013. 740 [I-D.phinney-roll-rpl-industrial-applicability] 741 Phinney, T., Thubert, P., and R. Assimiti, "RPL 742 applicability in industrial networks", draft-phinney-roll- 743 rpl-industrial-applicability-02 (work in progress), 744 February 2013. 746 9.3. External Informative References 748 [IEEE802154e] 749 IEEE standard for Information Technology, "IEEE std. 750 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 751 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 752 2012. 754 [IEEE802154] 755 IEEE standard for Information Technology, "IEEE std. 756 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 757 and Physical Layer (PHY) Specifications for Low-Rate 758 Wireless Personal Area Networks", June 2011. 760 [DeCouto03] 761 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 762 High-Throughput Path Metric for Multi-Hop Wireless 763 Routing", MobiCom '03, The 9th ACM International 764 Conference on Mobile Computing and Networking, San Diego, 765 California", June 2003. 767 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , 768 . 770 Authors' Addresses 772 Xavier Vilajosana (editor) 773 Universitat Oberta de Catalunya 774 156 Rambla Poblenou 775 Barcelona, Catalonia 08018 776 Spain 778 Phone: +34 (646) 633 681 779 Email: xvilajosana@uoc.edu 781 Kris Pister 782 University of California Berkeley 783 490 Cory Hall 784 Berkeley, California 94720 785 USA 787 Email: pister@eecs.berkeley.edu