idnits 2.17.1 draft-vilajosana-6tsch-basic-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 date (June 20, 2013) is 3955 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 498, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 504, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 510, but not defined == Unused Reference: 'RFC2119' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'I-D.watteyne-6tsch-tsch-lln-context' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-thubert-6tsch-architecture' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-wang-6tsch-6tus' is defined on line 491, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-12 == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 == Outdated reference: A later version (-02) exists of draft-thubert-6tsch-architecture-00 Summary: 3 errors (**), 0 flaws (~~), 14 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 June 20, 2013 5 Expires: December 22, 2013 7 Minimal 6TSCH Configuration 8 draft-vilajosana-6tsch-basic-00 10 Abstract 12 This document describes the minimal set of rules to operate a 13 [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. These 14 rules can be used during early interoperability testing and 15 development, when the centralized and distributed solutions developed 16 by the 6TSCH group are not fully implemented yet, or otherwise not 17 available. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 22, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Cells and cells Options . . . . . . . . . . . . . . . . . 4 57 2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 5 58 2.4. Time Slot timming . . . . . . . . . . . . . . . . . . . . 5 59 3. Enhanced Beacons Configuration and Content . . . . . . . . . 6 60 3.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7 63 3.2. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 7 64 3.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7 66 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 8 68 4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8 70 5. Neighbor information . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 9 72 5.2. Time Parent Selection . . . . . . . . . . . . . . . . . . 10 73 6. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 11 77 7.3. External Informative References . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 The nodes in a [IEEE802154e] TSCH network follow a communication 83 schedule. The entity responsible for building and maintaining that 84 schedule has very precise control over the trade-off between the 85 network's latency, bandwidth, reliability and power consumption. 86 During early interoperability testing and development, however, 87 simplicity is often more important than efficiency. The goal of this 88 document is to defines the simplest set of rules for building a 90 [IEEE802154e] TSCH-compliant network, at the necessary price of 91 lesser efficiency. 93 2. Schedule 95 In order to form a network, a minimum schedule configuration is 96 required so nodes can advertise the presence of the network, and 97 exchange data. 99 2.1. Slotframe 101 The slotframe, as defined by 102 [I-D.draft-palattella-6tsch-terminology], is an abstraction of the 103 MAC layer that defines a collection of time slots of equal length and 104 priority, and which repeats over time. In order to set up a minimal 105 TSCH network, nodes need to use the same slotframe configuration so 106 they can exchange Enhanced Beacons (EBs) and data packets. This 107 document recommends the following slotframe configuration. 109 Basic configuration configuration 111 +---------------------------------+----------------------+ 112 | Property | Value | 113 +---------------------------------+----------------------+ 114 | Number of time slots | 101 | 115 +---------------------------------+----------------------+ 116 | Number of available channels | 16 | 117 +---------------------------------+----------------------+ 118 | Number of EBs slots | 1 (slotOffset 0) | 119 +---------------------------------+----------------------+ 120 | Number of active cells | 5 (slotOffsets | 121 | | 1,2,3,4,5) | 122 +---------------------------------+----------------------+ 123 | Number of inactive slots | 95 (from slotOffset | 124 | | 6 to 100) | 125 +---------------------------------+----------------------+ 126 | Number of MAC retransmissions | 3 | 127 +---------------------------------+----------------------+ 128 | Time Slot duration | 15ms | 129 +---------------------------------+----------------------+ 131 This schedule is hard-coded in each node. The slotframe is composed 132 of 101 time slots, the first slot in the slotframe is used to send 133 Enhanced Beacons to announce the presence of the network. These EBs 134 are not acknowledged. Five cells are scheduled for exchangeing data 135 packets, as described in Section 2.2. These cells are scheduled at 136 slotOffset 1 to 5, and channeOffset 0. Per the IEEE802.15.4e TSCH 137 standard, data packets sent on these cells to a unicast MAC address 138 are acknowledged by the receiver. The 95 remaining cells are 139 inactive, i.e. the radio of the nodes remains 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. Cells and cells Options 156 Per the [IEEE802154e] TSCH standard, each active cell is assigned a 157 bitmap of cell options. 159 The EB cell is assigned the following bitmap of cell options: 161 b0 = Transmit = 1 (set) 163 b1 = Receive = 0 (clear) 165 b2 = Shared = 0 (clear) 167 b3 = Timekeeping = 0 (clear) 169 b4 = Hard = 1 (set) 171 b5-b7 = Reserved (clear) 173 The data cells are assigned the bitmap of cell options below. This 174 results in "Slotted Aloha" behavior. Because both the "Transmit" and 175 "Receive" bits are set, the either transmits, or listens when it has 176 nothing to transmit. Because the "shared" bit it set, it uses the 177 backoff mechanism defined in [IEEE802154e] TSCH to resolve 178 collisions. 180 b0 = Transmit = 1 (set) 182 b1 = Receive = 1 (set) 183 b2 = Shared = 1 (set) 185 b3 = Timekeeping = 0 (clear) 187 b4 = Hard = 1 (set) 189 b5-b7 = Reserved (clear) 191 All remaining cells are inactive, and so the nodes' radios remain 192 off. In a memory efficient implementation, active cells could be 193 represented by a circular linked list. Inactive cells should not 194 occupy any memory. 196 2.3. Retransmissions 198 The maximum number of MAC-layer retransmissions is set to 3. For 199 packets which require an acknowledgement, if none is received after a 200 total of 4 attempts, the transmissions is considered failed at the 201 MAC layer, and the upper layer needs to be notified. Packets sent to 202 the broadcast MAC address (including EBs) are not acknowledged and 203 therefore not retransmitted. 205 2.4. Time Slot timming 207 The figure below shows an active timeslot in which a packet is sent 208 from the transmitter node (TX) to the receiver node (RX), and a MAC 209 acknowledgement is sent back from the RX to the TX node, indicating 210 successful reception. The TsTxOffset duration defines the instant in 211 the timeslot when the first byte of the transmitted packet leaves the 212 radio of the TX node. The radio of the RX node is turned on TsLongGT 213 /2 before that instant, and listen for at least TsLongGT. This 214 allows for a de-synchronization between the two node of at most 215 TsLongGT. The RX node needs to send the first byte of the MAC 216 acknowledgement exactly TsTxAckDelay after the end of the last byte 217 of the received packet. TX's radio has to be turned on TsShortGT/2 218 before that time, and keep listening for at least TsShortGT. 220 Time slot internal timing diagram 221 /------------------- Time Slot duration --------------------/ 222 | /tsShortGT/ | 223 | | | | | | 224 |------------+-----------------+--------------+------+------| 225 TX | | TX-Packet | |RX Ack| | 226 |------------+-----------------+--------------+------+------| 227 |/tsTxOffset/| | | | | 228 | | | | | | 229 |------------+-----------------+--------------+------+------| 230 RX | | | | RX-Packet | |TX Ack| | 231 |---------+--+--+--------------+--------------+------+------| 232 | | | | | | | | 233 | /tsLongGT/ |/TsTxAckDelay/| | | 234 Start End 235 of of 236 Slot Slot 238 [IEEE802154e] does not define the different durations of a time slot. 239 It does allow those durations to be sent in the EBs (through a 240 TimeSlot IE), but for simplicity, this document recommends to hard- 241 code the different durations to the values listed below. 243 Timeslot durations 245 +---------------------------------+------------------+ 246 | IEEE802.15.4e TSCH duration | Value | 247 +---------------------------------+------------------+ 248 | TsTxOffset | 4000us | 249 +---------------------------------+------------------+ 250 | TsLongGT | 1300us | 251 +---------------------------------+------------------+ 252 | TsTxAckDelay | 4606us | 253 +---------------------------------+------------------+ 254 | TsShortGT | 500us | 255 +---------------------------------+------------------+ 256 | Time Slot duration | 15000us | 257 +---------------------------------+------------------+ 259 3. Enhanced Beacons Configuration and Content 261 [IEEE802154e] does not define when EBs are sent. The choice of the 262 duration between two EBs needs to take into account whether EBs are 263 used as the only mechanism to synchronize devices, or whether a Keep- 264 Alive (KA) mechanism is used in parallel. For a simplest TSCH 265 configuration, it is recommended to sent EBs at least once every 10s. 267 EBs must be sent with the Beacon IEEE802.15.4 frame type and this 268 document recommends that they carry the following Information 269 Elements (IEs): 271 3.1. Sync IE 273 Contains synchronization information such as ASN and join priority. 275 3.1.1. IE Header 277 Length (b0-b7) = 0x06 279 Sub-ID (b8-b14) = 0x1a 281 Type (b15) = 0x00 (short) 283 3.1.2. IE Content 285 ASN Byte 1 (b16-b23) 287 ASN Byte 2 (b24-b31) 289 ASN Byte 3 (b32-b39) 291 ASN Byte 4 (b40-b47) 293 ASN Byte 5 (b48-b55) 295 Join Priority (b56-b63) 297 3.2. Frame and Link IE 299 Although the schedule is hard-coded in each node, this document 300 recommends to indicate the schedule in each EB through a Frame and 301 Link IE. This enables nodes which implement [IEEE802154e] fully to 302 be able to configure their schedule as they join the network, and 303 interact with nodes using a hard-coded schedule. 305 3.2.1. IE Header 307 Length (b0-b7) = variable 309 Sub-ID (b8-b14) = 0x1b 311 Type (b15) = 0x00 (short) 313 3.2.2. IE Content 314 # Slotframes (b16-b23) = 0x01 316 Slotframe ID (b24-b31) = 0x01 318 Size Slotframe (b32-b47) = 0x65 320 # Links (b48-b55) = 0x06 322 For each link in the basic schedule: 324 Channel Offset (2B) = 0x00 326 Slot Number (2B) = from (0x00 to 0x05) 328 LinkOption (1B) = as described in Section 2.2 330 4. Acknowledgement 332 MAC-layer acknowledgement frames are built according to 333 [IEEE802154e]. Data frames and command frames sent to a unicast MAC 334 destination address request an acknowledged. The acknowledgement 335 frame is of type ACK (0x10). Each acknowledgement contains the 336 following IE: 338 4.1. ACK/NACK Time Correction IE 340 The ACK/NACK time correction IE is used to carry the measured 341 desynchronization between the sender and the receiver. 343 4.1.1. IE Header 345 Length (b0-b7) = 0x02 347 Sub-ID (b8-b14) = 0x1e 349 Type (b15) = 0x00 (short) 351 4.1.2. IE Content 353 Time Synch Info and ACK status (b16-b31) 355 The possible values for the Time Synch Info and ACK status are 356 described in the following table: 358 ACK status and Time Synch information. 360 +-----------------------------------+------------------+ 361 | ACK Status | Value | 362 +-----------------------------------+------------------+ 363 | ACK with positive time correction | 0x0000 - 0x07ff | 364 +-----------------------------------+------------------+ 365 | ACK with negative time correction | 0x0800 - 0x0fff | 366 +-----------------------------------+------------------+ 367 | NACK with positive time correction| 0x8000 - 0x87ff | 368 +-----------------------------------+------------------+ 369 | NACK with negative time correction| 0x8800 - 0x8fff | 370 +-----------------------------------+------------------+ 372 5. Neighbor information 374 [IEEE802154e] does not define when information is be kept at each 375 node about each neighbor. This document recommends to keep the 376 following information in the neighbor table: 378 5.1. Neighbor Table 380 The exact format of the neighbor table is implementation-specific, 381 but it should at least contain the following information, for each 382 neighbor: 384 Neighbor statistics: 386 number of transmitted packets to that neighbor 388 number of transmitted packets that have been acknowledged by 389 that neighbor 391 number of received packets from that neighbor 393 number of received packets that have been acknowledged for that 394 neighbor 396 Neighbor address. 398 ASN when that neighbor was last heard. This can be used to 399 trigger a keep-alive. 401 RPL rank of that neighbor. 403 A flag which indicates whether this neighbor is a time source 404 neighbor. 406 Connectivity statistics (RSSI, LQI, etc), which can be used to 407 help determine the quality of the link. 409 In addition of that information, each node has to be able to compute 410 some RPL objective function (OF) taking into account the neighbor and 411 connectivity statistics. An example RPL objective function is the 412 ETX. 414 5.2. Time Parent Selection 416 Each node selects a time parent amongst its known neighbors. When a 417 node joins a network, it has no routing information yet. Its 418 (possibly temporary) time parent is the node it can hear "best", for 419 example based on RSSI measurements of the EBs it received. After 420 having acquired a RPL rank, the RPL routing parents should also be 421 IEEE802.15.4e time source neighbors. 423 Optionally, a node can choose to use an counter to avoid frequent 424 changes in time source neighbor selection. Based on some thresholds 425 (on RSSI for example), if the quality of the link with time parent 426 changes over or below the thresholds for a certain number of times 427 (e.g. 3), the instability counter is incremented and another time 428 parent is selected. 430 6. Queues and Priorities 432 [IEEE802154e] does not define the use of queues to handle upper layer 433 data (either application or control data from upper layers). This 434 document recommends to use a single queue with the following rules: 436 When the node is not synchronized to the network, higher layers 437 are not able to insert packets into the queue. 439 Lower-layer packets have a higher priority that packets received 440 from a higher layer. 442 IEEE802.15.4 frames of types Beacon and Command have a higher 443 priority than IEEE802.15.4 frames of types Data and ACK. 445 One entry in the queue is reserved at all times for a IEEE802.15.4 446 frames of types Beacon or Command frames. 448 7. References 450 7.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 7.2. Informative References 457 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 458 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 459 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 460 Lossy Networks", RFC 6550, March 2012. 462 [I-D.ietf-roll-terminology] 463 Vasseur, J., "Terminology in Low power And Lossy 464 Networks", draft-ietf-roll-terminology-12 (work in 465 progress), March 2013. 467 [I-D.phinney-roll-rpl-industrial-applicability] 468 Phinney, T., Thubert, P., and R. Assimiti, "RPL 469 applicability in industrial networks", draft-phinney-roll- 470 rpl-industrial-applicability-02 (work in progress), 471 February 2013. 473 [I-D.watteyne-6tsch-tsch-lln-context] 474 Watteyne, T., Palattella, M., and L. Grieco, "Using 475 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 476 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 477 context-02 (work in progress), May 2013. 479 [I-D.draft-palattella-6tsch-terminology] 480 Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. 481 Wang, "Terminology in IPv6 over Time Slotted Channel 482 Hopping. draft-palattella-6tsch-terminology-00 (work in 483 progress) ", March 2013. 485 [I-D.draft-thubert-6tsch-architecture] 486 Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An 487 Architecture for IPv6 over Time Synchronized Channel 488 Hopping. draft-thubert-6tsch-architecture-00 (work in 489 progress) ", March 2013. 491 [I-D.draft-wang-6tsch-6tus] 492 Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6tus Sub- 493 Layer Specification. draft-wang-6tsch-6tus-01 (work in 494 progress) ", May 2013. 496 7.3. External Informative References 498 [IEEE802154e] 499 IEEE standard for Information Technology, "IEEE std. 500 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 501 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 502 2012. 504 [IEEE802154] 505 IEEE standard for Information Technology, "IEEE std. 506 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 507 and Physical Layer (PHY) Specifications for Low-Rate 508 Wireless Personal Area Networks", June 2011. 510 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , 511 . 513 Author's Address 515 Xavier Vilajosana (editor) 516 Universitat Oberta de Catalunya 517 156 Rambla Poblenou 518 Barcelona, Catalonia 08018 519 Spain 521 Phone: +34 (646) 633 681 522 Email: xvilajosana@uoc.edu