idnits 2.17.1 draft-ietf-6tisch-minimal-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2015) is 3338 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 940, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 946, but not defined == Missing Reference: 'CCM' is mentioned on line 952, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 957, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 968, but not defined == Unused Reference: 'RFC3610' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'I-D.richardson-6tisch-security-architecture' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 933, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-05 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-05 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-03 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-02 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH X. Vilajosana, Ed. 3 Internet-Draft Universitat Oberta de Catalunya 4 Intended status: Informational K. Pister 5 Expires: September 9, 2015 University of California Berkeley 6 March 8, 2015 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-06 11 Abstract 13 This document describes the minimal set of rules to operate an IEEE 14 802.15.4e Timeslotted Channel Hopping (TSCH) network. This minimal 15 mode of operation can be used during network bootstrap, as a fall- 16 back mode of operation when no dynamic scheduling solution is 17 available or functioning, or during early interoperability testing 18 and development. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 9, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Minimal Schedule Configuration . . . . . . . . . . . . . . . 3 57 3.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 6 60 3.4. Time Slot timing . . . . . . . . . . . . . . . . . . . . 6 61 4. Enhanced Beacons Configuration and Content . . . . . . . . . 8 62 4.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 9 65 4.2. TSCH Timeslot IE . . . . . . . . . . . . . . . . . . . . 9 66 4.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 9 68 4.3. Channel Hopping IE . . . . . . . . . . . . . . . . . . . 10 69 4.3.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3.2. IE Content . . . . . . . . . . . . . . . . . . . . . 10 71 4.4. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 11 72 4.4.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 11 73 4.4.2. IE Content . . . . . . . . . . . . . . . . . . . . . 11 74 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 12 76 5.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 12 77 5.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 12 78 6. Neighbor information . . . . . . . . . . . . . . . . . . . . 12 79 6.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 12 80 6.2. Time Source Neighbor Selection . . . . . . . . . . . . . 13 81 7. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 14 82 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9.1. RPL Objective Function Zero . . . . . . . . . . . . . . . 15 85 9.1.1. Rank computation . . . . . . . . . . . . . . . . . . 15 86 9.1.2. Rank computation Example . . . . . . . . . . . . . . 16 87 9.2. RPL Configuration . . . . . . . . . . . . . . . . . . . . 18 88 9.2.1. Mode of Operation . . . . . . . . . . . . . . . . . . 18 89 9.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . . 18 90 9.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 18 91 9.2.4. Variable Values . . . . . . . . . . . . . . . . . . . 19 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 11.2. Informative References . . . . . . . . . . . . . . . . . 20 96 11.3. External Informative References . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 The nodes in a [IEEE802154e] TSCH network follow a communication 103 schedule. The entity (centralized or decentralized) responsible for 104 building and maintaining that schedule has precise control over the 105 trade-off between the network's latency, bandwidth, reliability and 106 power consumption.During early interoperability testing and 107 development, however, simplicity is more important than efficiency. 108 One goal of this document is to define the simplest set of rules for 109 building a [IEEE802154e] TSCH-compliant network, at the necessary 110 price of lesser efficiency. Yet, this minimal mode of operation MAY 111 also be used during network bootstrap before any schedule is 112 installed into the network so nodes can self-organize and the 113 management and configuration information be distributed. In 114 addition, the minimal configuration MAY be used as a fall-back mode 115 of operation, ensuring connectivity of nodes in case that dynamic 116 scheduling mechanisms fail or are not available. [IEEE802154e] 117 provides a mechanism whereby the details of slotframe length, 118 timeslot timing, and channel hopping pattern are communicated when a 119 node synchronizes to the network. This document describes specific 120 settings for these parameters. Nodes MUST broadcast properly-formed 121 Enhanced Beacons to announce these values. 123 2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Minimal Schedule Configuration 131 In order to form a network, a minimum schedule configuration is 132 required so nodes can advertise the presence of the network, and 133 allow other nodes to join. 135 3.1. Slotframe 137 The slotframe, as defined in [I-D.ietf-6tisch-terminology], is an 138 abstraction of the link layer that defines a collection of time slots 139 of equal length, and which repeats over time. In order to set up a 140 minimal TSCH network, nodes need to be synchronized with the same 141 slotframe configuration so they can communicate. This document 142 recommends the following slotframe configuration. 144 Minimal configuration 146 +------------------------------------+----------------------+ 147 | Property | Value | 148 +------------------------------------+----------------------+ 149 | Number of time slots per Slotframe | Variable | 150 +------------------------------------+----------------------+ 151 | Number of available frequencies | 16 | 152 +------------------------------------+----------------------+ 153 | Number of scheduled cells | 1 (slotOffset 0) | 154 | | (macLinkType NORMAL) | 155 +------------------------------------+----------------------+ 156 | Number of unscheduled cells | The remainder of the | 157 | | slotframe | 158 +------------------------------------+----------------------+ 159 | Number of MAC retransmissions (max)| 3 (4 attempts to tx) | 160 +------------------------------------+----------------------+ 162 The slotframe is composed of a configurable number of time slots. 163 Choosing the number of time slots per slotframe needs to take into 164 account network requirements such as density, bandwidth per node, 165 etc. In the minimal configuration, there is only a single active 166 slot in slotframe, used to transmit/receive both EBs and data link- 167 layer frames. The trade-off between bandwidth, latency and energy 168 consumption can be controlled by choosing a different slotframe 169 length. The active slot MAY be scheduled at the slotOffset 0x00 and 170 channelOffset 0x00 and MUST be announced in the EBs. EBs are sent 171 using this active slot to the link-layer broadcast address (and are 172 therefore not acknowledged). Data packets, as described in 173 Section 3.2, use the same active slot. Per [IEEE802154e], data 174 packets sent unicast on this cell are acknowledged by the receiver. 175 The remaining cells in the slotframe are unscheduled, and MAY be used 176 by dynamic scheduling solutions. Details about such dynamic 177 scheduling solution are out of scope of this document. 179 The slotframe length (expressed in number of time slots) is 180 configurable. The length used determines the duty cycle of the 181 network. For example, a network with a 0.99% duty cycle is composed 182 of a slotframe of 101 slots, which includes 1 active slot. The 183 present document RECOMMENDS the use of a default slot duration set to 184 10ms and its corresponding default timeslot timings defined by the 185 [IEEE802154e] macTimeslotTemplate. The use of the default 186 macTimeslotTemplate MUST be announced in the EB by using the Timeslot 187 IE containing only the default macTimeslotTemplateId. Other time 188 slot durations MAY be supported and MUST be announced in the EBs. If 189 one uses a timeslot duration different than 10ms, EBs MUST contain 190 the complete TimeSlot IE as described in Section 3.4. This document 191 also recommends to clearly indicate nodes not supporting the default 192 timeslot value. 194 Example schedule with 0.99% duty cycle 196 Chan. +----------+----------+ +----------+ 197 Off.0 | TxRxS/EB | OFF | | OFF | 198 Chan. +----------+----------+ +----------+ 199 Off.1 | | | ... | | 200 +----------+----------+ +----------+ 201 . 202 . 203 . 204 Chan. +----------+----------+ +----------+ 205 Off.15 | | | | | 206 +----------+----------+ +----------+ 208 slotOffset 0 1 100 210 EB: Enhanced Beacon 211 Tx: Transmit 212 Rx: Receive 213 S: Shared 214 OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism) 216 3.2. Cell Options 218 Per [IEEE802154e] TSCH, each scheduled cell has an associated bitmap 219 of cell options, called LinkOptions. The scheduled cell in the 220 minimal schedule is configured as a Hard cell 221 [I-D.ietf-6tisch-tsch][I-D.ietf-6tisch-6top-interface]. Additional 222 available cells MAY 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, listens otherwise. 231 Because the "shared" bit is set, the back-off mechanism defined in 232 [IEEE802154e] is used to resolve contention when transmitting. This 233 results in "Slotted Aloha" behavior. The "Timekeeping" flag is never 234 set, since the time source neighbor is selected using the DODAG 235 structure of the network (detailed below). 237 b0 = Transmit = 1 (set) 238 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 3.3. Retransmissions 253 The maximum number of link layer retransmissions is set to 3. For 254 packets which require an acknowledgment, 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 3.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 acknowledgment 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 bit after the Start of Frame 267 Delimiter (SFD) of the transmitted packet leaves the radio of the TX 268 node. The radio of the RX node is turned on tsRxWait/2 before that 269 instant, and listens for at least tsRxWait. This allows for a de- 270 synchronization between the two nodes of at most tsRxWait/2 in either 271 direction (early or late). The RX node needs to send the first bit 272 after the SFD of the MAC acknowledgment exactly TsTxAckDelay after 273 the end of the last byte of the received packet. TX's radio has to 274 be turned on tsAckWait/2 before that time, and keep listening for at 275 least tsAckWait. The TX node can perform a Clear Channel Assessment 276 (CCA) if required, this does not interfere with the scope of this 277 draft. As for a minimal configuration, CCA is OPTIONAL. 279 Time slot internal timing diagram 281 /---------------------- Time Slot Duration ----------------------/ 282 | / (5) / | 283 | | / tsRxAckDelay /| | | | 284 |-------------------+--------------+------------------+------+---| 285 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 286 |----+-------+------+--------------+------------------+------+---| 287 |/ tsTxOffset /| | | | | 288 | | | | | | 289 |-------------------+--------------+------------------+------+---| 290 RX | | | | RX frame | |TX ACK| | 291 |----------------+--+--+-----------+------------------+------+---| 292 | | | | | | | | 293 | / (4) / / tsTxAckDelay / | | 294 Start End 295 of of 296 Slot Slot 297 /(1)/ tsCCAOffset 298 /(2)/ tsCCA 299 /(3)/ tsRxTx 300 /(4)/ tsRxWait 301 /(5)/ tsAckWait 303 A 10ms time slot length is the default value defined by 304 [IEEE802154e]. Section 6.4.3.3.3 of [IEEE802154e] defines a default 305 macTimeslotTemplate, i.e. the different duration within the slot. 306 These values are summarized in the following table and MUST be used 307 when utilizing the default time slot duration. In this case, the 308 Timeslot IE only transports the macTimeslotTemplateId (0x00) as the 309 timing values are well known. If a timeslot template other than the 310 default is used, the EB MUST contain a complete TimeSlot IE 311 indicating the timeslot duration and the corresponding timeslot 312 timings, requiring 25 bytes. Note however that in case of 313 discrepancy between the values in this document and [IEEE802154e], 314 the IEEE standard specification has precedence. 316 Default timeslot durations (per [IEEE802154e], Section 6.4.3.3.3) 318 +--------------------------------+------------+ 319 | IEEE802.15.4e TSCH parameter | Value (us) | 320 +--------------------------------+------------+ 321 | tsCCAOffset | 1800 | 322 +--------------------------------+------------+ 323 | tsCCA | 128 | 324 +--------------------------------+------------+ 325 | tsTxOffset | 2120 | 326 +--------------------------------+------------+ 327 | tsRxOffset | 1120 | 328 +--------------------------------+------------+ 329 | tsRxAckDelay | 800 | 330 +--------------------------------+------------+ 331 | tsTxAckDelay | 1000 | 332 +--------------------------------+------------+ 333 | tsRxWait | 2200 | 334 +--------------------------------+------------+ 335 | tsAckWait | 400 | 336 +--------------------------------+------------+ 337 | tsRxTx | 192 | 338 +--------------------------------+------------+ 339 | tsMaxAck | 2400 | 340 +--------------------------------+------------+ 341 | tsMaxTx | 4256 | 342 +--------------------------------+------------+ 343 | Time Slot duration | 10000 | 344 +--------------------------------+------------+ 346 4. Enhanced Beacons Configuration and Content 348 [IEEE802154e] does not define how often EBs are sent, nor their 349 contents. EBs should not in general be used for synchronization. 350 Synchronization is achieved via acknowledgements to normal packet 351 traffic, and keepalives. For a minimal TSCH configuration, a mote 352 SHOULD send an EB every EB_PERIOD. For additional reference see 353 [I-D.ietf-6tisch-tsch] where different synchronization approaches are 354 summarized. EBs are only authenticated and payload is not encrypted. 355 Refer to the 6TiSCH architecture document 356 [I-D.ietf-6tisch-architecture] for further details on security 357 aspects. 359 EBs MUST be sent with the Beacon IEEE802.15.4 frame type and this EB 360 MUST carry the Information Elements (IEs) listed below. 362 The content of the IEs is presented here for completeness, however 363 this information is redundant with [IEEE802154e]. 365 4.1. Sync IE 367 Contains synchronization information such as ASN and Join Priority. 368 The value of Join Priority is discussed in Section 6.2. 370 4.1.1. IE Header 372 Length (b0-b7) = 0x06 374 Sub-ID (b8-b14) = 0x1a 376 Type (b15) = 0x00 (short) 378 4.1.2. IE Content 380 ASN Byte 1 (b16-b23) 382 ASN Byte 2 (b24-b31) 384 ASN Byte 3 (b32-b39) 386 ASN Byte 4 (b40-b47) 388 ASN Byte 5 (b48-b55) 390 Join Priority (b56-b63) 392 4.2. TSCH Timeslot IE 394 Contains the timeslot template identifier. This specification uses 395 the default timeslot template as defined in [IEEE802154e], 396 Section 5.2.4.15. 398 4.2.1. IE Header 400 Length (b0-b7) = 0x01 402 Sub-ID (b8-b14) = 0x1c 404 Type (b15) = 0x00 (short) 406 4.2.2. IE Content 408 Timeslot Template ID (b0-b7) = 0x00 410 In the case that a different than the default timeslot template is 411 used, the IE Content MUST follow the following specification as 412 defined in [IEEE802154e], Section 5.2.4.15. 414 Timeslot Template ID (b0-b7) 416 macTsCCAOffset (b8-b23) 418 macTsCCA (b24-b39) 420 macTsTxOffset (b40-b55) 422 macTsRxOffset (b56-b71) 424 macTsRxAckDelay (b72-b87) 426 macTsTxAckDelay (b88-b103) 428 macTsRxWait (b104-b119) 430 macTsAckWait (b120-b135) 432 macTsRxTx (b136-b151) 434 macTsMaxAck (b152-b167) 436 macTsMaxTx (b168-b183) 438 macTsTimeslotLength (b184-b199) 440 4.3. Channel Hopping IE 442 Contains the channel hopping template identifier. This specification 443 uses the default channel hopping template, as defined in 444 [IEEE802154e], Section 5.2.4.16. 446 4.3.1. IE Header 448 Length (b0-b7) = 0x01 450 Sub-ID (b8-b14) = 0x1d 452 Type (b15) = 0x00 (short) 454 4.3.2. IE Content 456 Channel Hopping Template ID (b0-b7) = 0x00 458 The default sequence for the 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 459 14, 11, 8, 0, 1, 2, 13, 3, 9, 10] per section 5.1.1a of 460 [IEEE802154e]. Note however that in case of discrepancy between the 461 values in this document and [IEEE802154e], the IEEE standard 462 specification has preference. 464 4.4. Frame and Link IE 466 Each node MUST indicate the schedule in each EB through a Frame and 467 Link IE. This enables nodes which implement [IEEE802154e] to learn 468 the schedule used in the network as they join it. 470 4.4.1. IE Header 472 Length (b0-b7) = variable 474 Sub-ID (b8-b14) = 0x1b 476 Type (b15) = 0x00 (short) 478 4.4.2. IE Content 480 # Slotframes (b16-b23) = 0x01 482 Slotframe ID (b24-b31) = 0x01 484 Size Slotframe (b32-b47) = variable 486 # Links (b48-b55) = 0x01 488 For the active cell in the minimal schedule: 490 Channel Offset (2B) = 0x00 492 Slot Number (2B) = 0x00 494 LinkOption (1B) = as described in Section 3.2 496 5. Acknowledgment 498 Link-layer acknowledgment frames are built according to 499 [IEEE802154e]. Unicast frames sent to a unicast MAC destination 500 address request an acknowledgment. The sender node MUST set the ACK 501 requested bit in the IEEE802.15.4 header. The acknowledgment frame 502 is of type ACK (0x10). Each acknowledgment contains the following 503 IE: 505 5.1. ACK/NACK Time Correction IE 507 The ACK/NACK time correction IE carries the measured de- 508 synchronization between the sender and the receiver. 510 5.1.1. IE Header 512 Length (b0-b7) = 0x02 514 Sub-ID (b8-b14) = 0x1e 516 Type (b15) = 0x00 (short) 518 5.1.2. IE Content 520 Time Synchronization Information and ACK status (b16-b31) 522 The possible values for the Time Synchronization Information and ACK 523 status are described in [IEEE802154e] and reproduced in the following 524 table: 526 ACK status and Time Synchronization Information. 528 +-----------------------------------+-----------------+ 529 | ACK Status | Value | 530 +-----------------------------------+-----------------+ 531 | ACK with positive time correction | 0x0000 - 0x07ff | 532 +-----------------------------------+-----------------+ 533 | ACK with negative time correction | 0x0800 - 0x0fff | 534 +-----------------------------------+-----------------+ 535 | NACK with positive time correction| 0x8000 - 0x87ff | 536 +-----------------------------------+-----------------+ 537 | NACK with negative time correction| 0x8800 - 0x8fff | 538 +-----------------------------------+-----------------+ 540 6. Neighbor information 542 [IEEE802154e] does not define how and when each node in the network 543 keeps information about its neighbors. Keeping the following 544 information in the neighbor table is RECOMMENDED: 546 6.1. Neighbor Table 548 The exact format of the neighbor table is implementation-specific, 549 but it SHOULD contain the following information for each neighbor: 551 Neighbor statistics: 553 numTx: number of transmitted packets to that neighbor 555 numTxAck: number of transmitted packets that have been 556 acknowledged by that neighbor 558 numRx: number of received packets from that neighbor 560 The EUI64 of the neighbor. 562 Timestamp when that neighbor was heard for the last time. This 563 can be based on the ASN counter or any other time base. It can be 564 used to trigger a keep-alive message. 566 RPL rank of that neighbor. 568 A flag indicating whether this neighbor is a time source neighbor. 570 Connectivity statistics (e.g., RSSI), which can be used to 571 determine the quality of the link. 573 In addition to that information, each node has to be able to compute 574 some RPL Objective Function (OF), taking into account the neighbor 575 and connectivity statistics. An example RPL objective function is 576 the OF Zero as described in [RFC6552] and Section 9.1.1. 578 6.2. Time Source Neighbor Selection 580 Each node MUST select at least one Time Source Neighbor among the 581 nodes in its RPL routing parent set. When a node joins a network, it 582 has no routing information. To select its time source neighbor, it 583 uses the Join Priority field in the EB, as described in 584 Section 5.2.4.13 and Table 52b of [IEEE802154e]. The Sync IE 585 contains the ASN and 1 Byte field named Join Priority. The Join 586 Priority of any node MUST be equivalent to the result of the function 587 DAGRank(rank) as defined by [RFC6550] and Section 9.1.1. The Join 588 Priority of the DAG root is zero, i.e., EBs sent from the DAG root 589 are sent with Join Priority equal to 0. A lower value of the Join 590 Priority indicates higher preference to connect to that device. When 591 a node joins the network, it MUST NOT send EBs before having acquired 592 a RPL rank. This avoids routing loops and matches RPL topology with 593 underlying mesh topology. As soon as a node acquires a RPL rank (see 594 [RFC6550] and Section 9.1.1), it SHOULD send Enhanced Beacons 595 including a Sync IE with Join Priority field set to DAGRank(rank), 596 where rank is the node's rank. If a node receives EBs from different 597 nodes with equal Join Priority, the time source neighbor selection 598 SHOULD be assessed by other metrics that can help determine the 599 better connectivity link. Time source neighbor hysteresis SHOULD be 600 used, according to the rules defined in Section 9.2.3. If 601 connectivity to the time source neighbor is lost, a new time source 602 neighbor MUST be chosen among the neighbors in the RPL routing parent 603 set. 605 The decision for a node to select one Time Source Neighbor when 606 multiple EBs are received is implementation-specific. 608 For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT 609 neighbors have been received to select the best Time Source Neighbor. 610 This condition MAY apply unless a second EB is not received after 611 MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting 612 a first Time Source Neighbor. 614 Optionally, some form of hysteresis SHOULD be implemented to avoid 615 frequent changes in time source neighbors. 617 7. Queues and Priorities 619 [IEEE802154e] does not define the use of queues to handle upper layer 620 data (either application or control data from upper layers). The use 621 of a single queue with the following rules is RECOMMENDED: 623 When the node is not synchronized to the network, higher layers 624 are not able to insert packets into the queue. 626 Frames generated by the MAC layer (e.g., EBs and ACK) have a 627 higher queuing priority than packets received from a higher layer. 629 IEEE802.15.4 frame types Beacon and Command have a higher queuing 630 priority than IEEE802.15.4 frame types Data and ACK. 632 One entry in the queue is reserved at all times for an 633 IEEE802.15.4 frames of types Beacon or Command frames. 635 8. Security 637 As this document refers to the interaction between Layer 3 and Layer 638 2 protocols, this interaction MUST be secured by L2 security 639 mechanisms as defined by [IEEE802154e]. Two security mechanisms are 640 considered, authentication and encryption, authentication applies to 641 the all packet content while encryption applies to header IEs and MAC 642 payload. Key distribution is out of scope of this document, but 643 examples include pre-configured keys at the nodes, shared keys among 644 peers or well-known keys. Refer to the 6TiSCH architecture document 645 [I-D.ietf-6tisch-architecture] for further details on key 646 distribution and advanced security aspects. 648 The present document assumes the existence of two keys, which can be 649 well-known by the network devices and/or pre-configured. One of the 650 keys (K1) is used to authenticate EBs (all frame). As defined in 651 Section 4 EBs MUST be authenticated but payload not encrypted. This 652 prevents two independent networks to interfere or enable non-allowed 653 nodes to join a particular network. A second key (K2) is used to 654 authenticate and encrypt the payload of DATA, ACKNOWLEDGEMENT, MAC 655 COMMAND frame types and respective header IEs. 657 9. RPL on TSCH 659 Nodes in the network MUST use the RPL routing protocol [RFC6550]. 661 9.1. RPL Objective Function Zero 663 Nodes in the network MUST use the RPL routing protocol [RFC6550] and 664 implement the RPL Objective Function Zero [RFC6552]. 666 9.1.1. Rank computation 668 The rank computation is described at [RFC6552], Section 4.1. A node 669 rank is computed by the following equation: 671 R(N) = R(P) + rank_increment 673 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 675 Where: 677 R(N): Rank of the node. 679 R(P): Rank of the parent obtained as part of the DIO information. 681 rank_increment: The result of a function that determines the rank 682 increment. 684 Rf (rank_factor): A configurable factor that is used to multiply 685 the effect of the link properties in the rank_increment 686 computation. If none is configured, rank_factor of 1 is used. In 687 this specification, a rank_factor of 1 MUST be used. 689 Sp (step_of_rank): (strictly positive integer) - an intermediate 690 computation based on the link properties with a certain neighbor. 691 In this specification, 2*ETX (Expected Transmissions) as defined 692 by [decouti03high] and [RFC6551] MUST be used. The ETX is 693 computed as the inverse of the Packet Delivery Ratio (PDR), and 694 MAY be computed as the number of acknowledged packets, divided by 695 the number of transmitted packets to a certain node. E.g: 696 Sp=2*numTX/numTXAck 698 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 699 to the step_of_rank of a preferred parent, to allow the selection 700 of an additional feasible successor. If none is configured to the 701 device, then the step_of_rank is not stretched. In this 702 specification, stretch_of_rank MUST be set to 0. 704 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 705 constant DEFAULT_MIN_HOP_rank_increment [RFC6550]. 706 DEFAULT_MIN_HOP_rank_increment has a value of 256. 708 DAGRank(rank): Equivalent to the floor of (Rf*Sp + Sr) as defined 709 by [RFC6550]. Specifically, when an Objective Function computes 710 Rank, this is defined as an unsigned integer (i.e., a 16-bit 711 value) Rank quantity. When the Rank is compared, e.g. to 712 determine parent relationships or loop detection, the integer 713 portion of the Rank is used. The integer portion of the Rank is 714 computed by the DAGRank() macro as floor(x) where floor(x) is the 715 function that evaluates to the greatest integer less than or equal 716 to x. DAGRank(rank) = floor(rank/MinHopRankIncrease) 718 Rank computation scenario 720 +-------+ 721 | P | R(P) 722 | | 723 +-------+ 724 | 725 | 726 +-------+ 727 | N | R(N)=R(P) + rank_increment 728 | | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 729 +-------+ Sp=2*ETX 731 9.1.2. Rank computation Example 733 This section illustrates with an example the use of the Objective 734 Function Zero. Assume the following parameters: 736 Rf = 1 738 Sp = 2* ETX 740 Sr = 0 742 minHopRankIncrease = 256 (default in RPL) 743 ETX=(numTX/numTXAck) 745 r(n) = r(p) + rank_increment 747 rank_increment = (Rf*Sp + Sr) * minHopRankIncrease 749 rank_increment = 512*numTx/numTxACK 751 Rank computation example for 5 hop network where numTx=100 and 752 numTxAck=75 for all nodes 754 +-------+ 755 | 0 | R(0)=0 756 | | DAGRank(R(0)) = 0 757 +-------+ 758 | 759 | 760 +-------+ 761 | 1 | R(1)=R(0)+683=683 762 | | DAGRank(R(1)) = 2 763 +-------+ 764 | 765 | 766 +-------+ 767 | 2 | R(2)=R(1)+683=1366 768 | | DAGRank(R(2)) = 5 769 +-------+ 770 | 771 | 772 +-------+ 773 | 3 | R(3)=R(2)+683=2049 774 | | DAGRank(R(3)) = 8 775 +-------+ 776 | 777 | 778 +-------+ 779 | 4 | R(4)=R(3)+683=2732 780 | | DAGRank(R(4)) = 10 781 +-------+ 782 | 783 | 784 +-------+ 785 | 5 | R(5)=R(4)+683=3415 786 | | DAGRank(R(5)) = 13 787 +-------+ 789 9.2. RPL Configuration 791 In addition to the Objective Function (OF), a minimal configuration 792 for RPL SHOULD indicate the preferred mode of operation (either 793 Storing Mode or Non-Storing Mode) so different RPL implementations 794 can inter-operate. RPL information and hop-by-hop extension headers 795 MUST follow [RFC6553] and [RFC6554] specification. In the case that 796 the packets formed at the LLN need to cross through intermediate 797 routers, these MUST obey to the IP in IP encapsulation requirement 798 specified by the [RFC6282] and [RFC2460]. RPI and RH3 extension 799 headers and inner IP headers MUST be compressed according to 800 [RFC6282]. 802 9.2.1. Mode of Operation 804 For downstream route maintenance, in a minimal configuration, RPL 805 SHOULD be set to operate in the Non-Storing mode as described by 806 [RFC6550] Section 9.7. Storing mode ([RFC6550] Section 9.8) MAY be 807 supported in less constrained devices. 809 9.2.2. Trickle Timer 811 RPL signaling messages such as DIOs are sent using the Trickle 812 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 813 specification, the Trickle Timer MUST be used with the RPL defined 814 default values [RFC6550] (Section 8.3.1). For a description of the 815 Trickle timer operation see Section 4.2 on [RFC6206]. 817 9.2.3. Hysteresis 819 According to [RFC6552], [RFC6719] recommends the use of a boundary 820 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 821 when ranks are compared. When evaluating a parent that belongs to a 822 smaller path cost than current minimum path, the candidate node is 823 selected as new parent only if the difference between the new path 824 and the current path is greater than the defined 825 PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the 826 current preferred parent. As for [RFC6719] the recommended value for 827 PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used, the 828 recommendation for this document is to use PARENT_SWITCH_THRESHOLD 829 equal to 394 as the metric being used is 2*ETX. This is mechanism is 830 suited to deal with parent hysteresis in both cases routing parent 831 and time source neighbor selection. 833 9.2.4. Variable Values 835 The following table presents the RECOMMENDED values for the RPL- 836 related variables defined in the previous section. 838 Recommended variable values 840 +-------------------------+-------+ 841 | Variable | Value | 842 +-------------------------+-------+ 843 | EB_PERIOD | 10s | 844 +-------------------------+-------+ 845 | MAX_EB_DELAY | 180 | 846 +-------------------------+-------+ 847 | NUM_NEIGHBOURS_TO_WAIT | 2 | 848 +-------------------------+-------+ 849 | PARENT_SWITCH_THRESHOLD | 394 | 850 +-------------------------+-------+ 852 10. Acknowledgments 854 The authors would like to acknowledge the guidance and input provided 855 by the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne. 857 11. References 859 11.1. Normative References 861 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 862 Hysteresis Objective Function", RFC 6719, September 2012. 864 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 865 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 866 September 2011. 868 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 869 Routing Header for Source Routes with the Routing Protocol 870 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 871 2012. 873 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 874 Power and Lossy Networks (RPL) Option for Carrying RPL 875 Information in Data-Plane Datagrams", RFC 6553, March 876 2012. 878 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 879 Protocol for Low-Power and Lossy Networks (RPL)", RFC 880 6552, March 2012. 882 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 883 Barthel, "Routing Metrics Used for Path Calculation in 884 Low-Power and Lossy Networks", RFC 6551, March 2012. 886 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 887 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 888 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 889 Lossy Networks", RFC 6550, March 2012. 891 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 892 "The Trickle Algorithm", RFC 6206, March 2011. 894 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 895 CBC-MAC (CCM)", RFC 3610, September 2003. 897 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 898 (IPv6) Specification", RFC 2460, December 1998. 900 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 901 Requirement Levels", BCP 14, RFC 2119, March 1997. 903 11.2. Informative References 905 [I-D.ietf-6tisch-tsch] 906 Watteyne, T., Palattella, M., and L. Grieco, "Using 907 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 908 Statement and Goals", draft-ietf-6tisch-tsch-05 (work in 909 progress), January 2015. 911 [I-D.ietf-6tisch-architecture] 912 Thubert, P., Watteyne, T., Struik, R., and M. Richardson, 913 "An Architecture for IPv6 over the TSCH mode of IEEE 914 802.15.4e", draft-ietf-6tisch-architecture-05 (work in 915 progress), January 2015. 917 [I-D.ietf-6tisch-terminology] 918 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 919 "Terminology in IPv6 over the TSCH mode of IEEE 920 802.15.4e", draft-ietf-6tisch-terminology-03 (work in 921 progress), January 2015. 923 [I-D.ietf-6tisch-6top-interface] 924 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 925 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 926 6top-interface-02 (work in progress), October 2014. 928 [I-D.richardson-6tisch-security-architecture] 929 Richardson, M., "security architecture for 6top: 930 requirements and structure", draft-richardson-6tisch- 931 security-architecture-02 (work in progress), April 2014. 933 [I-D.ietf-roll-terminology] 934 Vasseur, J., "Terms used in Routing for Low power And 935 Lossy Networks", draft-ietf-roll-terminology-13 (work in 936 progress), October 2013. 938 11.3. External Informative References 940 [IEEE802154e] 941 IEEE standard for Information Technology, "IEEE std. 942 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 943 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 944 2012. 946 [IEEE802154] 947 IEEE standard for Information Technology, "IEEE std. 948 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 949 and Physical Layer (PHY) Specifications for Low-Rate 950 Wireless Personal Area Networks", June 2011. 952 [CCM] National Institute of Standards and Technology, 953 "Recommendation for Block Cipher Modes of Operation: The 954 CCM Mode for Authentication and Confidentiality. SP 955 800-38C", May 2004. 957 [CCM-Star] 958 Struik, R., "Formal Specification of the CCM* Mode of 959 Operation, IEEE P802.15 Working Group for Wireless 960 Personal Area Networks (WPANs).", September 2005. 962 [decouti03high] 963 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 964 High-Throughput Path Metric for Multi-Hop Wireless 965 Routing", ACM International Conference on Mobile Computing 966 and Networking (MobiCom) , June 2003. 968 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 969 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 970 a Standards-Based Low-Power Wireless Development 971 Environment", Transactions on Emerging Telecommunications 972 Technologies , August 2012. 974 Authors' Addresses 976 Xavier Vilajosana (editor) 977 Universitat Oberta de Catalunya 978 156 Rambla Poblenou 979 Barcelona, Catalonia 08018 980 Spain 982 Phone: +34 (646) 633 681 983 Email: xvilajosana@uoc.edu 985 Kris Pister 986 University of California Berkeley 987 490 Cory Hall 988 Berkeley, California 94720 989 USA 991 Email: pister@eecs.berkeley.edu