idnits 2.17.1 draft-vilajosana-6tsch-basic-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([IEEE802154e]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3939 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 512, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 518, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 524, but not defined == Unused Reference: 'RFC2119' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6tsch-architecture' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tsch-security' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is defined on line 504, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-thubert-6tsch-architecture-01 == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-12 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH X. Vilajosana, Ed. 3 Internet-Draft Universitat Oberta de Catalunya 4 Intended status: Informational K. Pister 5 Expires: January 15, 2014 University of California Berkeley 6 July 14, 2013 8 Minimal 6TSCH Configuration 9 draft-vilajosana-6tsch-basic-01 11 Abstract 13 This document describes the minimal set of rules to operate a 14 [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. These 15 rules can be used during early interoperability testing and 16 development, when the centralized and distributed solutions developed 17 by the 6TSCH group are not fully implemented yet, or otherwise not 18 available. 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 January 15, 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. Basic Schedule . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 5 59 2.4. Time Slot timming . . . . . . . . . . . . . . . . . . . . 5 60 3. Enhanced Beacons Configuration and Content . . . . . . . . . 6 61 3.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7 63 3.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 7 65 3.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8 67 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 8 69 4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8 71 5. Neighbor information . . . . . . . . . . . . . . . . . . . . 9 72 5.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 9 73 5.2. Time Parent Selection . . . . . . . . . . . . . . . . . . 10 74 6. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 10 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 7.2. Informative References . . . . . . . . . . . . . . . . . 11 78 7.3. External Informative References . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The nodes in a [IEEE802154e] TSCH network follow a communication 84 schedule. The entity (centralized or decentralized) responsible for 85 building and maintaining that schedule has very precise control over 86 the trade-off between the network's latency, bandwidth, reliability 87 and power consumption. During early interoperability testing and 88 development, however, simplicity is often more important than 89 efficiency. The goal of this document is to define the simplest set 90 of rules for building a [IEEE802154e] TSCH-compliant network, at the 91 necessary price of lesser efficiency. 93 2. Basic Schedule 94 In order to form a network, a minimum schedule configuration is 95 required so nodes can advertise the presence of the network, and 96 allow other nodes to join. 98 2.1. Slotframe 100 The Slotframe, as defined in [I-D.palattella-6tsch-terminology], is 101 an abstraction of the MAC layer that defines a collection of time 102 slots of equal length and priority, and which repeats over time. In 103 order to set up a basic TSCH network, nodes need to be synchronized 104 with the same slotframe configuration so they can exchange Enhanced 105 Beacons (EBs) and data packets. This document recommends the 106 following slotframe configuration. 108 Basic configuration 110 +------------------------------------+----------------------+ 111 | Property | Value | 112 +------------------------------------+----------------------+ 113 | Number of time slots per Slotframe | 101 | 114 +------------------------------------+----------------------+ 115 | Number of available channels | 16 | 116 +------------------------------------+----------------------+ 117 | Number of EBs cells | 1 (slotOffset 0) | 118 +------------------------------------+----------------------+ 119 | Number of scheduled cells | 5 (slotOffsets | 120 | | 1,2,3,4,5) | 121 +------------------------------------+----------------------+ 122 | Number of unscheduled cells | 95 (from slotOffset | 123 | | 6 to 100) | 124 +------------------------------------+----------------------+ 125 | Number of MAC retransmissions (max)| 3 | 126 +------------------------------------+----------------------+ 127 | Time Slot duration | 15ms | 128 +------------------------------------+----------------------+ 130 The suggested basic schedule is hard-coded in each node. The 131 slotframe is composed of 101 time slots. The first slot in the 132 slotframe is used to send Enhanced Beacons announcing the presence of 133 the network. These EBs are not acknowledged. Five cells are 134 scheduled for exchanging data packets, as described in Section 2.2. 135 These cells are scheduled at slotOffset 1 to 5, and channeOffset 0. 136 Per the IEEE802.15.4e TSCH standard, data packets sent on these cells 137 to a unicast MAC address are acknowledged by the receiver. The 95 138 remaining cells are unscheduled, i.e., the radio of the nodes remains 139 off. 141 Basic schedule overview 143 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 144 chan.Off. 0 | EB |TxRxS|TxRxS|TxRxS|TxRxS|TxRxS| OFF | ... | OFF | 145 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 146 chan.Off. 1 | | | | | | | | ... | | 147 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 148 ... 149 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 150 chan.Off. 15 | | | | | | | | ... | | 151 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 152 0 1 2 3 4 5 6 100 154 2.2. Cell Options 156 Per the [IEEE802154e] TSCH standard, each scheduled cell has a bitmap 157 of cell options assigned. All scheduled cells in the basic schedule 158 are configured as Hard cells 159 [I-D.watteyne-6tsch-tsch-lln-context][I-D.draft-wang-6tsch-6top] 160 since reallocation is not considered in that simple approach. 162 The EB cell is assigned the following bitmap of cell options: 164 b0 = Transmit = 1 (set) 166 b1 = Receive = 0 (clear) 168 b2 = Shared = 0 (clear) 170 b3 = Timekeeping = 0 (clear) 172 b4 = Hard = 1 (set) 174 b5-b7 = Reserved (clear) 176 The data cells are assigned the bitmap of cell options below that 177 results in "Slotted Aloha" behavior. Because both the "Transmit" and 178 "Receive" bits are set, a node either transmits, if there is a packet 179 in its queue, or listens if it has nothing to transmit. Because the 180 "shared" bit is set,in presence of collisions it uses the backoff 181 mechanism defined in [IEEE802154e]. 183 b0 = Transmit = 1 (set) 185 b1 = Receive = 1 (set) 187 b2 = Shared = 1 (set) 188 b3 = Timekeeping = 0 (clear) 190 b4 = Hard = 1 (set) 192 b5-b7 = Reserved (clear) 194 All remaining cells are unscheduled. Thus the nodes can keep their 195 radio off. In a memory efficient implementation, scheduled cells 196 could be represented by a circular linked list. Unscheduled cells 197 should not occupy any memory. 199 2.3. Retransmissions 201 The maximum number of MAC-layer retransmissions is set to 3. For 202 packets which require an acknowledgement, if none is received after a 203 total of 4 attempts, the transmissions is considered failed at the 204 MAC layer, and the upper layer needs to be notified. Packets sent to 205 the broadcast MAC address (including EBs) are not acknowledged and 206 therefore not retransmitted. 208 2.4. Time Slot timming 210 The figure below shows an active timeslot in which a packet is sent 211 from the transmitter node (TX) to the receiver node (RX), and a MAC 212 acknowledgement is sent back from the RX to the TX node, indicating 213 successful reception. The TsTxOffset duration defines the instant in 214 the timeslot when the first byte of the transmitted packet leaves the 215 radio of the TX node. The radio of the RX node is turned on TsLongGT 216 /2 before that instant, and listen for at least TsLongGT. This 217 allows for a de-synchronization between the two node of at most 218 TsLongGT. The RX node needs to send the first byte of the MAC 219 acknowledgement exactly TsTxAckDelay after the end of the last byte 220 of the received packet. TX's radio has to be turned on TsShortGT/2 221 before that time, and keep listening for at least TsShortGT. 223 Time slot internal timing diagram 224 /------------------- Time Slot duration --------------------/ 225 | /tsShortGT/ | 226 | | | | | | 227 |------------+-----------------+--------------+------+------| 228 TX | | TX-Packet | |RX Ack| | 229 |------------+-----------------+--------------+------+------| 230 |/tsTxOffset/| | | | | 231 | | | | | | 232 |------------+-----------------+--------------+------+------| 233 RX | | | | RX-Packet | |TX Ack| | 234 |---------+--+--+--------------+--------------+------+------| 235 | | | | | | | | 236 | /tsLongGT/ |/TsTxAckDelay/| | | 237 Start End 238 of of 239 Slot Slot 241 [IEEE802154e] does not define the different durations of a time slot. 242 It does allow those durations to be sent in the EBs (through a 243 TimeSlot IE), but for simplicity, this document recommends to hard- 244 code the different durations to the values listed below. 246 Timeslot durations 248 +---------------------------------+------------------+ 249 | IEEE802.15.4e TSCH parmeter | Value | 250 +---------------------------------+------------------+ 251 | TsTxOffset | 4000us | 252 +---------------------------------+------------------+ 253 | TsLongGT | 2600us | 254 +---------------------------------+------------------+ 255 | TsTxAckDelay | 4606us | 256 +---------------------------------+------------------+ 257 | TsShortGT | 1000us | 258 +---------------------------------+------------------+ 259 | Time Slot duration | 15000us | 260 +---------------------------------+------------------+ 262 3. Enhanced Beacons Configuration and Content 264 [IEEE802154e] does not define how often or which EBs are sent. The 265 choice of the duration between two EBs needs to take into account 266 whether EBs are used as the only mechanism to synchronize devices, or 267 whether a Keep-Alive (KA) mechanism is used in parallel. For a 268 simplest TSCH configuration, it is recommended to sent EBs at least 269 once every 10s. For additional reference see 271 [I-D.watteyne-6tsch-tsch-lln-context] where different synchronization 272 approaches are summarized. 274 EBs must be sent with the Beacon IEEE802.15.4 frame type and this 275 document recommends that they carry the following Information 276 Elements (IEs): 278 3.1. Sync IE 280 Contains synchronization information such as ASN and join priority. 282 3.1.1. IE Header 284 Length (b0-b7) = 0x06 286 Sub-ID (b8-b14) = 0x1a 288 Type (b15) = 0x00 (short) 290 3.1.2. IE Content 292 ASN Byte 1 (b16-b23) 294 ASN Byte 2 (b24-b31) 296 ASN Byte 3 (b32-b39) 298 ASN Byte 4 (b40-b47) 300 ASN Byte 5 (b48-b55) 302 Join Priority (b56-b63) 304 3.2. Frame and Link IE 306 Although the schedule is hard-coded in each node, this document 307 recommends to indicate the schedule in each EB through a Frame and 308 Link IE. This enables nodes which implement [IEEE802154e] fully to 309 be able to configure their schedule as they join the network, and 310 interact with nodes using a hard-coded schedule. 312 3.2.1. IE Header 314 Length (b0-b7) = variable 316 Sub-ID (b8-b14) = 0x1b 318 Type (b15) = 0x00 (short) 320 3.2.2. IE Content 322 # Slotframes (b16-b23) = 0x01 324 Slotframe ID (b24-b31) = 0x01 326 Size Slotframe (b32-b47) = 0x65 328 # Links (b48-b55) = 0x06 330 For each link in the basic schedule: 332 Channel Offset (2B) = 0x00 334 Slot Number (2B) = from (0x00 to 0x05) 336 LinkOption (1B) = as described in Section 2.2 338 4. Acknowledgement 340 MAC-layer acknowledgement frames are built according to 341 [IEEE802154e]. Data frames and command frames sent to a unicast MAC 342 destination address request an acknowledgement. The acknowledgement 343 frame is of type ACK (0x10). Each acknowledgement contains the 344 following IE: 346 4.1. ACK/NACK Time Correction IE 348 The ACK/NACK time correction IE is used to carry the measured 349 desynchronization between the sender and the receiver. 351 4.1.1. IE Header 353 Length (b0-b7) = 0x02 355 Sub-ID (b8-b14) = 0x1e 357 Type (b15) = 0x00 (short) 359 4.1.2. IE Content 361 Time Synch Info and ACK status (b16-b31) 363 The possible values for the Time Synch Info and ACK status are 364 described in the following table: 366 ACK status and Time Synch information. 368 +-----------------------------------+------------------+ 369 | ACK Status | Value | 370 +-----------------------------------+------------------+ 371 | ACK with positive time correction | 0x0000 - 0x07ff | 372 +-----------------------------------+------------------+ 373 | ACK with negative time correction | 0x0800 - 0x0fff | 374 +-----------------------------------+------------------+ 375 | NACK with positive time correction| 0x8000 - 0x87ff | 376 +-----------------------------------+------------------+ 377 | NACK with negative time correction| 0x8800 - 0x8fff | 378 +-----------------------------------+------------------+ 380 5. Neighbor information 382 [IEEE802154e] does not define how and when each node in the network 383 keeps information about its neighbors. This document recommends to 384 keep the following information in the neighbor table: 386 5.1. Neighbor Table 388 The exact format of the neighbor table is implementation-specific, 389 but it should at least contain the following information, for each 390 neighbor: 392 Neighbor statistics: 394 number of transmitted packets to that neighbor 396 number of transmitted packets that have been acknowledged by 397 that neighbor 399 number of received packets from that neighbor 401 number of received packets that have been acknowledged for that 402 neighbor 404 Neighbor address. 406 ASN when that neighbor was heard for the last time. This can be 407 used to trigger a keep-alive message. 409 RPL rank of that neighbor. 411 A flag which indicates whether this neighbor is a time source 412 neighbor. 414 Connectivity statistics (RSSI, LQI, etc), which can be used to 415 determine the quality of the link. 417 In addition of that information, each node has to be able to compute 418 some RPL objective function (OF) taking into account the neighbor and 419 connectivity statistics. An example RPL objective function is the 420 ETX. 422 5.2. Time Parent Selection 424 Each node selects a time parent amongst its known neighbors. When a 425 node joins a network, it has no routing information yet. Its 426 (possibly temporary) time parent is the node it can hear "best", for 427 example based on RSSI measurements of the EBs it received. After 428 having acquired a RPL rank, the RPL routing parents should also be 429 IEEE802.15.4e time source neighbors. 431 Optionally, a node can choose to use an counter to avoid frequent 432 changes in time source neighbor selection. Based on some thresholds 433 (on RSSI for example), if the quality of the link with time parent 434 changes over or below the thresholds for a certain number of times 435 (e.g., 3), the instability counter is incremented and another time 436 parent is selected. 438 6. Queues and Priorities 440 [IEEE802154e] does not define the use of queues to handle upper layer 441 data (either application or control data from upper layers). This 442 document recommends to use a single queue with the following rules: 444 When the node is not synchronized to the network, higher layers 445 are not able to insert packets into the queue. 447 Lower-layer packets have a higher priority that packets received 448 from a higher layer. 450 IEEE802.15.4 frames of types Beacon and Command have a higher 451 priority than IEEE802.15.4 frames of types Data and ACK. 453 One entry in the queue is reserved at all times for a IEEE802.15.4 454 frames of types Beacon or Command frames. 456 7. References 458 7.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 464 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 465 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 466 Lossy Networks", RFC 6550, March 2012. 468 7.2. Informative References 470 [I-D.watteyne-6tsch-tsch-lln-context] 471 Watteyne, T., Palattella, M., and L. Grieco, "Using 472 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 473 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 474 context-02 (work in progress), May 2013. 476 [I-D.thubert-6tsch-architecture] 477 Thubert, P., Assimiti, R., and T. Watteyne, "An 478 Architecture for IPv6 over Time Slotted Channel Hopping", 479 draft-thubert-6tsch-architecture-01 (work in progress), 480 April 2013. 482 [I-D.palattella-6tsch-terminology] 483 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 484 "Terminology in IPv6 over Time Slotted Channel Hopping", 485 draft-palattella-6tsch-terminology-00 (work in progress), 486 March 2013. 488 [I-D.draft-wang-6tsch-6top] 489 Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TSCH 490 Operation Sublayer (6top). draft-wang-6tsch-6top-00 (work 491 in progress) ", July 2013. 493 [I-D.ohba-6tsch-security] 494 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 495 A. Yegin, "Security Framework and Key Management Protocol 496 Requirements for 6TSCH", draft-ohba-6tsch-security-01 497 (work in progress), July 2013. 499 [I-D.ietf-roll-terminology] 500 Vasseur, J., "Terminology in Low power And Lossy 501 Networks", draft-ietf-roll-terminology-12 (work in 502 progress), March 2013. 504 [I-D.phinney-roll-rpl-industrial-applicability] 505 Phinney, T., Thubert, P., and R. Assimiti, "RPL 506 applicability in industrial networks", draft-phinney-roll- 507 rpl-industrial-applicability-02 (work in progress), 508 February 2013. 510 7.3. External Informative References 512 [IEEE802154e] 513 IEEE standard for Information Technology, "IEEE std. 514 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 515 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 516 2012. 518 [IEEE802154] 519 IEEE standard for Information Technology, "IEEE std. 520 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 521 and Physical Layer (PHY) Specifications for Low-Rate 522 Wireless Personal Area Networks", June 2011. 524 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , 525 . 527 Authors' Addresses 529 Xavier Vilajosana (editor) 530 Universitat Oberta de Catalunya 531 156 Rambla Poblenou 532 Barcelona, Catalonia 08018 533 Spain 535 Phone: +34 (646) 633 681 536 Email: xvilajosana@uoc.edu 538 Kris Pister 539 University of California Berkeley 540 490 Cory Hall 541 Berkeley, California 94720 542 USA 544 Email: pister@eecs.berkeley.edu