idnits 2.17.1 draft-ietf-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 (November 19, 2013) is 3810 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 745, but not defined == Missing Reference: 'DeCouto03' is mentioned on line 757, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 751, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 764, but not defined == Unused Reference: 'RFC2119' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tisch-security' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 732, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-00 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-00 == Outdated reference: A later version (-01) exists of draft-ohba-6tisch-security-00 Summary: 3 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: May 23, 2014 University of California Berkeley 6 November 19, 2013 8 Minimal 6TiSCH Configuration 9 draft-ietf-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 May 23, 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 . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 14 80 7.2.1. Mode of Operation . . . . . . . . . . . . . . . . . . 15 81 7.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . . 15 82 7.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 15 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 9.2. Informative References . . . . . . . . . . . . . . . . . 16 87 9.3. External Informative References . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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.ietf-6tisch-terminology], is an 126 abstraction of the MAC layer that defines a collection of time slots 127 of equal length and priority, and which repeats over time. In order 128 to set up a minimal TSCH network, nodes need to be synchronized with 129 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-6tisch-tsch][I-D.wang-6tisch-6top]. Additional 189 available cells can be scheduled by a dynamic scheduling solution and 190 can either be configured as hard cells or soft cells without any 191 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 256 /------------------- Time Slot duration --------------------/ 257 | /tsShortGT/ | 258 | | | | | | 259 |------------+-----------------+--------------+------+------| 260 TX | | TX-Packet | |RX Ack| | 261 |------------+-----------------+--------------+------+------| 262 |/tsTxOffset/| | | | | 263 | | | | | | 264 |------------+-----------------+--------------+------+------| 265 RX | | | | RX-Packet | |TX Ack| | 266 |---------+--+--+--------------+--------------+------+------| 267 | | | | | | | | 268 | /tsLongGT/ |/TsTxAckDelay/| | | 269 Start End 270 of of 271 Slot Slot 273 [IEEE802154e] does not define the different durations of a time slot. 274 It does allow those durations to be sent in the EBs (through a 275 TimeSlot IE). This document recommends to pre-configure the 276 different durations to the values listed below or use EBs to learn 277 those values included in the TimeSlot IE. 279 Timeslot durations 281 +---------------------------------+------------------+ 282 | IEEE802.15.4e TSCH parameter | Value | 283 +---------------------------------+------------------+ 284 | TsTxOffset | 4000us | 285 +---------------------------------+------------------+ 286 | TsLongGT | 2600us | 287 +---------------------------------+------------------+ 288 | TsTxAckDelay | 4606us | 289 +---------------------------------+------------------+ 290 | TsShortGT | 1000us | 291 +---------------------------------+------------------+ 292 | Time Slot duration | 15000us | 293 +---------------------------------+------------------+ 295 3. Enhanced Beacons Configuration and Content 297 [IEEE802154e] does not define how often or which EBs are sent. The 298 choice of the duration between two EBs needs to take into account 299 whether EBs are used as the only mechanism to synchronize devices, or 300 whether a Keep-Alive (KA) mechanism is used in parallel. For a 301 simplest TSCH configuration, a mote SHOULD send an EB every 10s. For 302 additional reference see [I-D.watteyne-6tisch-tsch] where different 303 synchronization approaches are summarized. 305 EBs MUST be sent with the Beacon IEEE802.15.4 frame type and this EBs 306 MUST carry the following Information Elements (IEs): (The content of 307 the IEs is presented here for clarity, however this information is 308 redundant with [I-D.watteyne-6tisch-tsch] and [IEEE802154e].) 310 3.1. Sync IE 312 Contains synchronization information such as ASN and Join Priority. 313 The value of Join Priority is discussed in Section 5.2. 315 3.1.1. IE Header 317 Length (b0-b7) = 0x06 319 Sub-ID (b8-b14) = 0x1a 321 Type (b15) = 0x00 (short) 323 3.1.2. IE Content 325 ASN Byte 1 (b16-b23) 327 ASN Byte 2 (b24-b31) 329 ASN Byte 3 (b32-b39) 331 ASN Byte 4 (b40-b47) 333 ASN Byte 5 (b48-b55) 335 Join Priority (b56-b63) 337 3.2. Frame and Cell IE 339 Although the schedule may be hard-coded during development, each node 340 MUST indicate the schedule in each EB through a Frame and Cell IE. 341 This enables nodes which implement [IEEE802154e] fully to configure 342 their schedule as they join the network, and interact with nodes 343 using a hard-coded schedule. 345 3.2.1. IE Header 347 Length (b0-b7) = variable 349 Sub-ID (b8-b14) = 0x1b 351 Type (b15) = 0x00 (short) 353 3.2.2. IE Content 355 # Slotframes (b16-b23) = 0x01 357 Slotframe ID (b24-b31) = 0x01 359 Size Slotframe (b32-b47) = 0x65 (101) 361 # Links (b48-b55) = 0x06 363 For each link in the minimal schedule: 365 Channel Offset (2B) = 0x00 367 Slot Number (2B) = from 0x00 to 0x05 369 LinkOption (1B) = as described in Section 2.2 371 4. Acknowledgement 373 MAC-layer acknowledgement frames are built according to 374 [IEEE802154e]. Data frames and command frames sent to a unicast MAC 375 destination address request an acknowledgement. The acknowledgement 376 frame is of type ACK (0x10). Each acknowledgement contains the 377 following IE: 379 4.1. ACK/NACK Time Correction IE 381 The ACK/NACK time correction IE is used to carry the measured de- 382 synchronization between the sender and the receiver. 384 4.1.1. IE Header 386 Length (b0-b7) = 0x02 388 Sub-ID (b8-b14) = 0x1e 390 Type (b15) = 0x00 (short) 392 4.1.2. IE Content 394 Time Synch Info and ACK status (b16-b31) 396 The possible values for the Time Synch Info and ACK status are 397 described in [IEEE802154e] and reproduced in the following table: 399 ACK status and Time Synchronization information. 401 +-----------------------------------+------------------+ 402 | ACK Status | Value | 403 +-----------------------------------+------------------+ 404 | ACK with positive time correction | 0x0000 - 0x07ff | 405 +-----------------------------------+------------------+ 406 | ACK with negative time correction | 0x0800 - 0x0fff | 407 +-----------------------------------+------------------+ 408 | NACK with positive time correction| 0x8000 - 0x87ff | 409 +-----------------------------------+------------------+ 410 | NACK with negative time correction| 0x8800 - 0x8fff | 411 +-----------------------------------+------------------+ 413 5. Neighbour information 415 [IEEE802154e] does not define how and when each node in the network 416 keeps information about its neighbours. This document recommends to 417 keep the following information in the Neighbour table: 419 5.1. Neighbour Table 421 The exact format of the neighbour table is implementation-specific, 422 but it SHOULD contain the following information for each neighbour: 424 Neighbour statistics: 426 numTx: number of transmitted packets to that neighbour 428 numTxAck: number of transmitted packets that have been 429 acknowledged by that neighbour 431 numRx: number of received packets from that neighbour 433 The EUI64 of the neighbour address. 435 Timestamp when that neighbour was heard for the last time. This 436 can be based on the ASN counter or any other time base. Can be 437 used to trigger a keep-alive message. 439 RPL rank of that neighbour. 441 A flag which indicates whether this neighbour is a time source 442 neighbour. 444 Connectivity statistics (e.g., RSSI), which can be used to 445 determine the quality of the link. 447 In addition of that information, each node has to be able to compute 448 some RPL Objective Function (OF) taking into account the neighbour 449 and connectivity statistics. An example RPL objective function is 450 the OF Zero as described in [RFC6552] and Section 7.1.1. 452 5.2. Time Source Neighbour Selection 454 Each node MUST select at least one time source neighbour amongst its 455 known neighbours in its RPL routing parent set. When a node joins a 456 network, it has no routing information yet. To select its time 457 source neighbour, uses the Join Priority information advertised in 458 the EB as described in Section 5.2.4.13 and Table 52b of 459 [IEEE802154e]. The Sync IE contains the ASN and 1 Byte field named 460 Join Priority. The Join Priority of any node is equivalent to the 461 result of the function DAGRank(rank) as defined by [RFC6550] and 462 Section 7.1.1. The Join Priority of the DAG root is zero, i.e., EBs 463 sent from the DAG root are sent with Join Priority equal to 0. A 464 lower value of the Join Priority indicates that the device is the 465 preferred one to connect to. When a node Joins the network MUST NOT 466 be allowed to send EBs until it has acquired a RPL rank. The latter 467 avoids topology loops and matches RPL topology with underlying mesh 468 topology. As soon as a node acquires a RPL rank (see [RFC6550] and 469 Section 7.1.1), it SHOULD send Enhanced Beacons including a Sync IE 470 with Join Priority field set as DAGRank(rank) where rank is the rank 471 of the actual node. In case of a node receives EBs from different 472 nodes with equal Join Priority, the time source neighbour selection 473 should be assessed by other metrics that can help to determine the 474 better connectivity link. Time source neighbor hysteresis SHOULD be 475 addressed according to the rules defined in Section 7.2.3. If 476 connectivity to the time source neighbor is lost, a new time source 477 neighbor MUST be chosen among the neighbor in the RPL routing parent 478 set. 480 Optionally, some form of hysteresis SHOULD be implemented to avoid 481 frequent changes in time source neighbors. 483 6. Queues and Priorities 485 [IEEE802154e] does not define the use of queues to handle upper layer 486 data (either application or control data from upper layers). This 487 document recommends the use of a single queue with the following 488 rules: 490 When the node is not synchronized to the network, higher layers 491 are not able to insert packets into the queue. 493 Frames generated by the MAC layer (e.g., EBs and ACK) have a 494 higher priority than packets received from a higher layer. 496 IEEE802.15.4 frames of types Beacon and Command have a higher 497 priority than IEEE802.15.4 frames of types Data and ACK. 499 One entry in the queue is reserved at all times for an 500 IEEE802.15.4 frames of types Beacon or Command frames. 502 7. RPL on TSCH 504 Nodes in the network MUST use the RPL routing protocol 506 7.1. RPL Objective Function Zero 508 Nodes in the network MUST use the RPL routing protocol [RFC6550]. 510 7.1.1. Rank computation 512 The rank computation is described at [RFC6552] Section 4.1. Briefly, 513 a node rank is computed by the following equation: 515 R(N) = R(P) + rank_increase 517 rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 519 Where: 521 R(N): Rank of the node. 523 R(P): Rank of the parent obtained as part of the DIO information. 525 rank_increase: The result of a function that determines the rank 526 increment. 528 Rf (rank_factor): A configurable factor that is used to multiply 529 the effect of the link properties in the rank_increase 530 computation. If none is configured, then a rank_factor of 1 is 531 used. For the purpose of this document rank_factor MUST be set to 532 1. 534 Sp (step_of_rank): (strictly positive integer) - an intermediate 535 computation based on the link properties with a certain neighbour. 536 For the purpose of this document 2*ETX (Expected Transmissions) as 537 defined by [DeCouto03] and [RFC6551] MUST be used. The ETX will 538 be computed as the inverse of the Packet Delivery Ratio (PDR) 539 computed as the number of acknowledged packets divided by the 540 number of transmitted packets to a certain node. E.g: Sp=2*numTX/ 541 numTXAck 542 Sr (stretch_of_rank): (unsigned integer) - the maximum 543 augmentation to the step_of_rank of a preferred parent to allow 544 the selection of an additional feasible successor. If none is 545 configured to the device, then the step_of_rank is not stretched. 546 For the present document stretch_of_rank MUST be set to 0. 548 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 549 constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550]. 550 DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. 552 DAGRank(rank): Equivalent to the floor of (Rf*Sp + Sr) as defined 553 by [RFC6550]. Specifically, when an Objective Function computes 554 Rank this is defined as an unsigned integer (i.e., 16-bit) Rank 555 quantity. When the Rank is compared, e.g., for determination of 556 parent relationships or loop detection, the integer portion of the 557 Rank is used. The integer portion of the Rank is computed by the 558 DAGRank() macro as floor(x) where floor(x) is the function that 559 evaluates to the greatest integer less than or equal to x. 560 DAGRank(rank) = floor(rank/MinHopRankIncrease) 562 Rank computation scenario 564 +-------+ 565 | P | R(P) 566 | | 567 +-------+ 568 | 569 | 570 | 571 +-------+ 572 | N | R(N)=R(P) + rank_increase 573 | | rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 574 +-------+ Sp=2*ETX 576 7.1.2. Rank computation Example 578 This sections illustrates with an example the use of the Objective 579 Function Zero. Assume the following parameters: 581 Rf = 1 583 Sp = 2* ETX 585 Sr = 0 587 minHopRankIncrease = 256 (default in RPL) 588 ETX=(numTX/numTXAck) 590 r(n) = r(p) + rank_increase 592 rank_increase = (Rf*Sp + Sr) * minHopRankIncrease 594 rank_increase = 512*numTx/numTxACK 596 Rank computation example for 5 hop network where numTx=100 and 597 numTxAck=75 for all nodes 599 +-------+ 600 | 0 | R(0)=0 601 | | DAGRank(R(0)) = 0 602 +-------+ 603 | 604 | 605 +-------+ 606 | 1 | R(1)=R(0)+683=683 607 | | DAGRank(R(1)) = 2 608 +-------+ 609 | 610 | 611 +-------+ 612 | 2 | R(2)=R(1)+683=1366 613 | | DAGRank(R(2)) = 5 614 +-------+ 615 | 616 | 617 +-------+ 618 | 3 | R(3)=R(2)+683=2049 619 | | DAGRank(R(3)) = 8 620 +-------+ 621 | 622 | 623 +-------+ 624 | 4 | R(4)=R(3)+683=2732 625 | | DAGRank(R(4)) = 10 626 +-------+ 627 | 628 | 629 +-------+ 630 | 5 | R(5)=R(4)+683=3415 631 | | DAGRank(R(5)) = 13 632 +-------+ 634 7.2. RPL Configuration 635 In addition to the Objective Function (OF), a minimal configuration 636 for RPL should indicate the preferred mode of operation and trickle 637 timer operation so different RPL implementations can interoperate. 639 7.2.1. Mode of Operation 641 For downstream route maintenance, in a minimal configuration, RPL 642 MUST be set to operate in the Non-Storing mode as described by 643 [RFC6550] Section 9.7. Storing mode ([RFC6550] Section 9.8) MAY be 644 supported in less constrained devices. 646 7.2.2. Trickle Timer 648 RPL signalling messages such as DIOs are sent using the Trickle 649 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For the purpose 650 of this document, the Trickle Timer MUST be used with the RPL defined 651 default values [RFC6550] (Section 8.3.1). For a description of the 652 Trickle timer operation see Section 4.2 on [RFC6206]. 654 7.2.3. Hysteresis 656 According to [RFC6552] the [RFC6719] recommends the use of a boundary 657 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 658 when ranks are compared. When evaluating a parent that belongs to a 659 smaller path cost than current minimum path, the candidate node is 660 selected as new parent only if the difference between the new path 661 and the current path is greater than the defined 662 PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the 663 current preferred parent. As for [RFC6719] the recommended value for 664 PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used, the 665 recommendation for this document is to use PARENT_SWITCH_THRESHOLD 666 equal to 394 as the metric being used is 2*ETX. This is mechanism is 667 suited to deal with parent hysteresis in both cases routing parent 668 and time source neighbor selection. 670 8. Acknowledgements 672 The authors would like to acknowledge the guidance and input provided 673 by the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne. 675 9. References 677 9.1. Normative References 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 683 "The Trickle Algorithm", RFC 6206, March 2011. 685 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 686 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 687 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 688 Lossy Networks", RFC 6550, March 2012. 690 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 691 Barthel, "Routing Metrics Used for Path Calculation in 692 Low-Power and Lossy Networks", RFC 6551, March 2012. 694 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 695 Protocol for Low-Power and Lossy Networks (RPL)", RFC 696 6552, March 2012. 698 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 699 Hysteresis Objective Function", RFC 6719, September 2012. 701 9.2. Informative References 703 [I-D.watteyne-6tisch-tsch] 704 Watteyne, T., Palattella, M., and L. Grieco, "Using 705 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 706 Statement and Goals", draft-watteyne-6tisch-tsch-00 (work 707 in progress), October 2013. 709 [I-D.ietf-6tisch-architecture] 710 Thubert, P., Watteyne, T., and R. Assimiti, "An 711 Architecture for IPv6 over the TSCH mode of IEEE 712 802.15.4e", draft-ietf-6tisch-architecture-00 (work in 713 progress), November 2013. 715 [I-D.ietf-6tisch-terminology] 716 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 717 "Terminology in IPv6 over the TSCH mode of IEEE 718 802.15.4e", draft-ietf-6tisch-terminology-00 (work in 719 progress), November 2013. 721 [I-D.wang-6tisch-6top] 722 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 723 Operation Sublayer (6top)", draft-wang-6tisch-6top-00 724 (work in progress), October 2013. 726 [I-D.ohba-6tisch-security] 727 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 728 A. Yegin, "Security Framework and Key Management Protocol 729 Requirements for 6TiSCH", draft-ohba-6tisch-security-00 730 (work in progress), October 2013. 732 [I-D.ietf-roll-terminology] 733 Vasseur, J., "Terms used in Routing for Low power And 734 Lossy Networks", draft-ietf-roll-terminology-13 (work in 735 progress), October 2013. 737 [I-D.phinney-roll-rpl-industrial-applicability] 738 Phinney, T., Thubert, P., and R. Assimiti, "RPL 739 applicability in industrial networks", draft-phinney-roll- 740 rpl-industrial-applicability-02 (work in progress), 741 February 2013. 743 9.3. External Informative References 745 [IEEE802154e] 746 IEEE standard for Information Technology, "IEEE std. 747 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 748 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 749 2012. 751 [IEEE802154] 752 IEEE standard for Information Technology, "IEEE std. 753 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 754 and Physical Layer (PHY) Specifications for Low-Rate 755 Wireless Personal Area Networks", June 2011. 757 [DeCouto03] 758 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 759 High-Throughput Path Metric for Multi-Hop Wireless 760 Routing", MobiCom '03, The 9th ACM International 761 Conference on Mobile Computing and Networking, San Diego, 762 California", June 2003. 764 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", 765 . 767 Authors' Addresses 768 Xavier Vilajosana (editor) 769 Universitat Oberta de Catalunya 770 156 Rambla Poblenou 771 Barcelona, Catalonia 08018 772 Spain 774 Phone: +34 (646) 633 681 775 Email: xvilajosana@uoc.edu 777 Kris Pister 778 University of California Berkeley 779 490 Cory Hall 780 Berkeley, California 94720 781 USA 783 Email: pister@eecs.berkeley.edu