idnits 2.17.1 draft-ietf-6tisch-minimal-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3218 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CCM' is mentioned on line 1108, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 1113, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 1118, but not defined == Unused Reference: 'RFC7102' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 1087, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2012' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-08 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-04 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-03 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 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: Standards Track K. Pister 5 Expires: January 7, 2016 University of California Berkeley 6 July 6, 2015 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-11 11 Abstract 13 This document describes the minimal set of rules to operate an IEEE 14 802.15.4 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 January 7, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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. IEEE.802.15.4 Specific Header Fields and Considerations . . . 7 62 5. Enhanced Beacons Configuration and Content . . . . . . . . . 8 63 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. Neighbor information . . . . . . . . . . . . . . . . . . . . 10 65 7.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 10 66 7.2. Time Source Neighbor Selection . . . . . . . . . . . . . 10 67 8. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 11 68 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 10. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 10.1. RPL Objective Function Zero . . . . . . . . . . . . . . 12 71 10.1.1. Rank computation . . . . . . . . . . . . . . . . . . 12 72 10.1.2. Rank computation Example . . . . . . . . . . . . . . 14 73 10.2. RPL Configuration . . . . . . . . . . . . . . . . . . . 15 74 10.2.1. Mode of Operation . . . . . . . . . . . . . . . . . 16 75 10.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . 16 76 10.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 16 77 10.2.4. Variable Values . . . . . . . . . . . . . . . . . . 16 78 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 11.1. Example 1. Information Elements in EBs . . . . . . . . . 17 80 11.2. Example 2. Information Elements in EBs not using default 81 timeslot template . . . . . . . . . . . . . . . . . . . 19 82 11.3. Example 3. Information Elements in ACKs . . . . . . . . 21 83 11.4. Example 4. Auxiliary Security Header . . . . . . . . . . 22 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 14.2. Informative References . . . . . . . . . . . . . . . . . 25 89 14.3. External Informative References . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 92 1. Introduction 94 The nodes in a IEEE 802.15.4 TSCH network follow a communication 95 schedule. The entity (centralized or decentralized) responsible for 96 building and maintaining that schedule has precise control over the 97 trade-off between the network's latency, bandwidth, reliability and 98 power consumption.During early interoperability testing and 99 development, however, simplicity is more important than efficiency. 100 One goal of this document is to define the simplest set of rules for 101 building a TSCH-compliant network, at the necessary price of lesser 102 efficiency. Yet, this minimal mode of operation MAY also be used 103 during network bootstrap before any schedule is installed into the 104 network so nodes can self-organize and the management and 105 configuration information be distributed. In addition, the minimal 106 configuration MAY be used as a fall-back mode of operation, ensuring 107 connectivity of nodes in case that dynamic scheduling mechanisms fail 108 or are not available. [IEEE802154] provides a mechanism whereby the 109 details of slotframe length, timeslot timing, and channel hopping 110 pattern are communicated when a node synchronizes to the network. 111 This document describes specific settings for these parameters. 112 Nodes MUST broadcast properly-formed Enhanced Beacons to announce 113 these values. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 3. Minimal Schedule Configuration 123 In order to form a network, a minimum schedule configuration is 124 required so nodes can advertise the presence of the network, and 125 allow other nodes to join. 127 3.1. Slotframe 129 The slotframe, as defined in [I-D.ietf-6tisch-terminology], is an 130 abstraction of the link layer that defines a collection of time slots 131 of equal length, and which repeats over time. In order to set up a 132 minimal TSCH network, nodes need to be synchronized with the same 133 slotframe configuration so they can communicate. This document 134 recommends the following slotframe configuration. 136 Minimal configuration 138 +------------------------------------+----------------------+ 139 | Property | Value | 140 +------------------------------------+----------------------+ 141 | Number of time slots per Slotframe | Variable | 142 +------------------------------------+----------------------+ 143 | Number of available frequencies | 16 | 144 +------------------------------------+----------------------+ 145 | Number of scheduled cells | 1 (slotOffset 0) | 146 | | (macLinkType NORMAL) | 147 +------------------------------------+----------------------+ 148 | Number of unscheduled cells | The remainder of the | 149 | | slotframe | 150 +------------------------------------+----------------------+ 151 | Number of MAC retransmissions (max)| 3 (4 transmission | 152 | | attempts) | 153 +------------------------------------+----------------------+ 155 The slotframe is composed of a configurable number of time slots. 156 Choosing the number of time slots per slotframe needs to take into 157 account network requirements such as density, bandwidth per node, 158 etc. In the minimal configuration, there is only a single active 159 slot in slotframe, used to transmit/receive both EBs and data link- 160 layer frames. The trade-off between bandwidth, latency and energy 161 consumption can be controlled by choosing a different slotframe 162 length. The active slot MAY be scheduled at the slotOffset 0x00 and 163 channelOffset 0x00 and MUST be announced in the EBs. EBs are sent 164 using this active slot to the link-layer broadcast address (and are 165 therefore not acknowledged). Data packets, as described in 166 Section 3.2, use the same active slot. Per [IEEE802154], data 167 packets sent unicast on this cell are acknowledged by the receiver. 168 The remaining cells in the slotframe are unscheduled, and MAY be used 169 by dynamic scheduling solutions. Details about such dynamic 170 scheduling solution are out of scope of this document. 172 The slotframe length (expressed in number of time slots) is 173 configurable. The length used determines the duty cycle of the 174 network. For example, a network with a 0.99% duty cycle is composed 175 of a slotframe of 101 slots, which includes 1 active slot. The 176 present document RECOMMENDS the use of a default slot duration set to 177 10ms and its corresponding default timeslot timings defined by the 178 [IEEE802154] macTimeslotTemplate. The use of the default 179 macTimeslotTemplate MUST be announced in the EB by using the Timeslot 180 IE containing only the default macTimeslotTemplateId. Other time 181 slot durations MAY be supported and MUST be announced in the EBs. If 182 one uses a timeslot duration different than 10ms, EBs MUST contain 183 the complete TimeSlot IE as described in Section 3.4. This document 184 also recommends to clearly indicate nodes not supporting the default 185 timeslot value. 187 Example schedule with 0.99% duty cycle 189 Chan. +----------+----------+ +----------+ 190 Off.0 | TxRxS/EB | OFF | | OFF | 191 Chan. +----------+----------+ +----------+ 192 Off.1 | | | ... | | 193 +----------+----------+ +----------+ 194 . 195 . 196 . 197 Chan. +----------+----------+ +----------+ 198 Off.15 | | | | | 199 +----------+----------+ +----------+ 201 slotOffset 0 1 100 203 EB: Enhanced Beacon 204 Tx: Transmit 205 Rx: Receive 206 S: Shared 207 OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism) 209 3.2. Cell Options 211 Per [IEEE802154] TSCH, each scheduled cell has an associated bitmap 212 of cell options, called LinkOptions. The scheduled cell in the 213 minimal schedule is configured as a Hard cell 214 [RFC7554][I-D.ietf-6tisch-6top-interface]. Additional available 215 cells MAY be scheduled by a dynamic scheduling solution. The dynamic 216 scheduling solution is out of scope, and this specification does not 217 make any restriction on the LinkOption associated with those 218 dynamically scheduled cells (i.e. they can be hard cells or soft 219 cells). 221 The active cell is assigned the bitmap of cell options below. 222 Because both the "Transmit" and "Receive" bits are set, a node 223 transmits if there is a packet in its queue, listens otherwise. 224 Because the "shared" bit is set, the back-off mechanism defined in 225 [IEEE802154] is used to resolve contention when transmitting. This 226 results in "Slotted Aloha" behavior. The "Timekeeping" flag is set 227 so nodes initialy joining the network can maintin synchronization to 228 the advertising node using that slot. Other time source neighbors 229 are selected using the DODAG structure of the network (detailed 230 below). 232 b0 = Transmit = 1 (set) 234 b1 = Receive = 1 (set) 236 b2 = Shared = 1 (set) 238 b3 = Timekeeping = 1 (set) 240 b4-b7 = Reserved (clear) 242 All remaining cells are unscheduled. In unscheduled cells, the nodes 243 SHOULD keep their radio off. In a memory-efficient implementation, 244 scheduled cells can be represented by a circular linked list. 245 Unscheduled cells SHOULD NOT occupy any memory. 247 3.3. Retransmissions 249 The maximum number of link layer retransmissions is set to 3. For 250 packets which require an acknowledgment, if none is received after a 251 total of 4 attempts, the transmission is considered failed and the 252 link layer MUST notify the upper layer. Packets sent to the 253 broadcast MAC address (including EBs) are not acknowledged and 254 therefore not retransmitted. 256 3.4. Time Slot timing 258 The figure below shows an active timeslot in which a packet is sent 259 from the transmitter node (TX) to the receiver node (RX). A link- 260 layer acknowledgment is sent by the RX node to the TX node when the 261 packet is to be acknowledged. The TsTxOffset duration defines the 262 instant in the timeslot when the first bit after the Start of Frame 263 Delimiter (SFD) of the transmitted packet leaves the radio of the TX 264 node. The radio of the RX node is turned on tsRxWait/2 before that 265 instant, and listens for at least tsRxWait. This allows for a de- 266 synchronization between the two nodes of at most tsRxWait/2 in either 267 direction (early or late). The RX node needs to send the first bit 268 after the SFD of the MAC acknowledgment exactly TsTxAckDelay after 269 the end of the last byte of the received packet. TX's radio has to 270 be turned on tsAckWait/2 before that time, and keep listening for at 271 least tsAckWait. The TX node can perform a Clear Channel Assessment 272 (CCA) if required, this does not interfere with the scope of this 273 draft. As for a minimal configuration, CCA is OPTIONAL. 275 Time slot internal timing diagram 277 /---------------------- Time Slot Duration ----------------------/ 278 | / (5) / | 279 | | / tsRxAckDelay /| | | | 280 |-------------------+--------------+------------------+------+---| 281 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 282 |----+-------+------+--------------+------------------+------+---| 283 |/ tsTxOffset /| | | | | 284 | | | | | | 285 |-------------------+--------------+------------------+------+---| 286 RX | | | | RX frame | |TX ACK| | 287 |----------------+--+--+-----------+------------------+------+---| 288 | | | | | | | | 289 | / (4) / / tsTxAckDelay / | | 290 Start End 291 of of 292 Slot Slot 293 /(1)/ tsCCAOffset 294 /(2)/ tsCCA 295 /(3)/ tsRxTx 296 /(4)/ tsRxWait 297 /(5)/ tsAckWait 299 The timing parameters for the default macTimeslotTemplate 300 (macTimeslotTemplateId = 0) MUST be used when utilizing the default 301 time slot duration. In this case, the Timeslot IE only transports 302 the macTimeslotTemplateId with value 0x00. If a timeslot template 303 other than the default is used, the EB MUST contain a complete 304 TimeSlot IE indicating the timeslot duration and the corresponding 305 timeslot timings. Note however that in case of discrepancy between 306 the values in this document and [IEEE802154], the IEEE standard has 307 precedence. 309 4. IEEE.802.15.4 Specific Header Fields and Considerations 311 The IEEE802.15.4 header of all frames MUST include the Sequence 312 Number field, the Source Address field and the Destination Address 313 field. In the Frame Control Field, this translates to: 315 the Frame Version field MUST be set to 0b10 (Frame Version 2) 317 the Sequence Number Suppression bit MUST be set to 0b0 319 the Source Addressing Mode MUST set to 0b11 (long address) 321 the Destination Addressing Mode MUST set to 0b11 (long address) 322 except for the broadcast address for which Destination Addressing 323 Mode SHOULD set to 0b10 (short address). The use of long 324 addresses is a REQUIRED as no association procedure is defined in 325 this document. 327 the PAN ID Compression bit MUST be set to 0b0. According to the 328 Table 2a in [IEEE802154-2012], this translates into the 329 Destination PAN ID field being "Present" and the Source PAN ID 330 field being "Not Present". 332 IEEE802.15.4 General MAC Frame Format 334 +-----+---+-----+----+-----+----+---+---+-------+-------+---+ 335 | | | | | | | | | | | | 336 |Frame|Seq| Dst |Dst | Src |Src |Aux|Hdr|Payload|Frame |FCS| 337 |Ctrl |Num|PANID|Addr|PANID|Addr|Sec|IEs| IEs |Payload| | 338 | | | | | | |Hdr| | | | | 339 +-----+---+-----+----+-----+----+---+---+-------+-------+---+ 341 Frame Control field with the values defined for the configuration 342 proposed in this document: 343 +-----+-------+-----+-----+------+-----+----+-------+----+-----+----+ 344 |Frame|Sec. |Frame| AR |PANID | Res |Seq |IE |Dst |Frame|Src | 345 |Type |Enabled|Pend | |Compr.|erved|Num |List |Addr|Ver. |Addr| 346 |(0-5)| (0,1) |(0,1)|(0,1)| 0b0 | |Supr|Present|Mode|0b10 |Mode| 347 | | | | | | |0b0 | (0,1) |0b11| |0b11| 348 +-----+-------+-----+-----+------+-----+----+-------+----+-----+----+ 350 PANID Compression configuration as per table 2a in [IEEE802154-2012]. 352 Src Dst Frame Frame Src Dst PANID 353 Address Address Version Types PANID PANID Compress 354 +---------+---------+-------+------------+---------+-------+--------+ 355 | | | |ACk, DATA, | Not | | | 356 | Present | Present | 0b10 |Beacon, MAC | Present |Present| 0 | 357 | | | |Multipurpose| | | | 358 +---------+---------+-------+------------+---------+-------+--------+ 360 5. Enhanced Beacons Configuration and Content 362 [IEEE802154] does not define how often EBs are sent, nor their 363 contents. EBs MUST NOT in general be used for synchronization. 364 Synchronization is achieved via acknowledgements to normal packet 365 traffic, and keepalives. For a minimal TSCH configuration, a mote 366 SHOULD send an EB every EB_PERIOD. For additional reference see 367 [RFC7554] where different synchronization approaches are summarized. 368 EBs are only authenticated and neither Payload IEs nor the frame 369 payload are encrypted. Refer to the 6TiSCH architecture document 371 [I-D.ietf-6tisch-architecture] for further details on security 372 aspects. 374 EBs MUST be sent as per [IEEE802154] and MUST carry the Information 375 Elements (IEs) listed below. Refer to Section 11.1 for an example of 376 the Information Elements Header Content. 378 Synchronization IE: Contains synchronization information such as 379 ASN and Join Priority. The value of Join Priority is discussed in 380 Section 7.2. 382 TSCH Timeslot IE: Contains the timeslot template identifier. This 383 specification uses the default timeslot template as defined in 384 [IEEE802154]. In the case that a non-default timeslot template is 385 used, the IE Content MUST follow the specification as defined in 386 [IEEE802154] . Refer to Section 11.1 for an illustrative example 387 of non default timeslot template. 389 Channel Hopping IE: Contains the channel hopping template 390 identifier. This specification uses the default channel hopping 391 template, as defined in [IEEE802154].The default sequence for the 392 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 393 3, 9, 10] [IEEE802154]. Note however that in case of discrepancy 394 between the values in this document and [IEEE802154], the IEEE 395 standard specification has preference. 397 Frame and Link IE: Each node MUST indicate the schedule in each EB 398 through a Frame and Link IE. This enables nodes which implement 399 [IEEE802154] to learn the schedule used in the network as they 400 join it. This draft defines the use of a single cell set at 401 channel offset 0x00, slot offset 0x00 and with linkOption 0xE0 402 (TX, RX, SHARED bits set). 404 6. Acknowledgment 406 Link-layer acknowledgment frames are built according to [IEEE802154]. 407 Unicast frames sent to a unicast MAC destination address request an 408 acknowledgment. The sender node MUST set the ACK requested bit in 409 the MAC header. The acknowledgment frame is of type ACK (version 410 0x10). Each acknowledgment contains the following IE: 412 ACK/NACK Time Correction IE: The ACK/NACK time correction IE 413 carries the measured de-synchronization between the sender and the 414 receiver. Refer to Section 11.3 for an example of the Header IE 415 content. The possible values for the Time Synchronization 416 Information and ACK status are described in [IEEE802154]. 418 7. Neighbor information 420 [IEEE802154] does not define how and when each node in the network 421 keeps information about its neighbors. Keeping the following 422 information in the neighbor table is RECOMMENDED: 424 7.1. Neighbor Table 426 The exact format of the neighbor table is implementation-specific, 427 but it SHOULD contain the following information for each neighbor: 429 Neighbor statistics: 431 numTx: number of transmitted packets to that neighbor 433 numTxAck: number of transmitted packets that have been 434 acknowledged by that neighbor 436 numRx: number of received packets from that neighbor 438 The EUI64 of the neighbor. 440 Timestamp of the last frame received from that neighbor. This can 441 be based on the ASN counter or any other time base. It can be 442 used to trigger a keep-alive message. 444 RPL rank of that neighbor. 446 A flag indicating whether this neighbor is a time source neighbor. 448 Connectivity statistics (e.g., RSSI), which can be used to 449 determine the quality of the link. 451 In addition to that information, each node has to be able to compute 452 some RPL Objective Function (OF), taking into account the neighbor 453 and connectivity statistics. An example RPL objective function is 454 the OF Zero as described in [RFC6552] and Section 10.1.1. 456 7.2. Time Source Neighbor Selection 458 Each node MUST select at least one Time Source Neighbor among the 459 nodes in its RPL routing parent set. When a node joins a network, it 460 has no routing information. To select its time source neighbor, it 461 uses the Join Priority field in the EB, as described in [IEEE802154]. 462 The Sync IE contains the ASN and 1 Byte field named Join Priority. 463 The Join Priority of any node MUST be equivalent to the result of the 464 function DAGRank(rank)-1. The Join Priority of the DAG root is also 465 equivalent to DAGRank(rank)-1. According to Section 10.1.1 the 466 DAGRank(rank(0)) = 1 and therefore the DAGRank(rank(0))-1 is 0 which 467 is compliant with the requirement of Join Priority = 0 imposed by 468 [IEEE802154]. A lower value of the Join Priority indicates higher 469 preference to connect to that device. When a node joins the network, 470 it MUST NOT send EBs before having acquired a RPL rank. This avoids 471 routing loops and matches RPL topology with underlying mesh topology. 472 As soon as a node acquires a RPL rank (see [RFC6550] and 473 Section 10.1.1), it SHOULD send Enhanced Beacons including a Sync IE 474 with Join Priority field set to DAGRank(rank)-1, where rank is the 475 node's rank. If a node receives EBs from different nodes with equal 476 Join Priority, the time source neighbor selection SHOULD be assessed 477 by other metrics that can help determine the better connectivity 478 link. Time source neighbor hysteresis SHOULD be used, according to 479 the rules defined in Section 10.2.3. At any time, a node MUST 480 maintain connectivity to at least one time source neighbor. New time 481 source neighbors MUST be chosen among the neighbors in the RPL 482 routing parent set. 484 The decision for a node to select one Time Source Neighbor when 485 multiple EBs are received is implementation-specific. 487 For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT 488 neighbors have been received to select the best Time Source Neighbor. 489 This condition MAY apply unless a second EB is not received after 490 MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting 491 a first Time Source Neighbor. 493 Optionally, some form of hysteresis SHOULD be implemented to avoid 494 frequent changes in time source neighbors. 496 8. Queues and Priorities 498 [IEEE802154] does not define the use of queues to handle upper layer 499 data (either application or control data from upper layers). The use 500 of a single queue with the following rules is RECOMMENDED: 502 When the node is not synchronized to the network, higher layers 503 are not able to insert packets into the queue. 505 Frames generated by the MAC layer (e.g., EBs and ACK) have a 506 higher queuing priority than packets received from a higher layer. 508 Frame types Beacon and Command have a higher queuing priority than 509 frame types Data and ACK. 511 One entry in the queue is reserved at all times for frames of 512 types Beacon or Command frames. 514 9. Security 516 As this document refers to the interaction between Layer 3 and Layer 517 2 protocols, this interaction MUST be secured by L2 security 518 mechanisms as defined by [IEEE802154]. Two security mechanisms are 519 considered, authentication and encryption, authentication applies to 520 all packet content while encryption applies to header IEs and MAC 521 payload. Key distribution is out of scope of this document, but 522 examples include pre-configured keys at the nodes, shared keys among 523 peers or well-known keys. Refer to the 6TiSCH architecture document 524 [I-D.ietf-6tisch-architecture] for further details on key 525 distribution and advanced security aspects. 527 The present document assumes the existence of two cryptographic keys, 528 which can be pre-configured. One of the keys (K1) is used to 529 authenticate EBs. As defined in Section 4, EBs MUST be 530 authenticated, with no payload encryption. This facilitates logical 531 segregation of distinct networks. A second key (K2) is used to 532 authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and 533 respective header IEs, with payload encryption. Depending on 534 security policy, these keys could be the same (i.e., K1=K2). 536 For early interoperability, K1 MAY be set to 36 54 69 53 43 48 20 6D 537 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15"). 539 10. RPL on TSCH 541 Nodes in the network MUST use the RPL routing protocol [RFC6550]. 543 10.1. RPL Objective Function Zero 545 Nodes in the network MUST use the RPL routing protocol [RFC6550] and 546 implement the RPL Objective Function Zero [RFC6552]. 548 10.1.1. Rank computation 550 The rank computation is described at [RFC6552], Section 4.1. A node 551 rank is computed by the following equation: 553 R(N) = R(P) + rank_increment 555 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 557 Where: 559 R(N): Rank of the node. 561 R(P): Rank of the parent obtained as part of the DIO information. 563 rank_increment: The result of a function that determines the rank 564 increment. 566 Rf (rank_factor): A configurable factor that is used to multiply 567 the effect of the link properties in the rank_increment 568 computation. If none is configured, rank_factor of 1 is used. In 569 this specification, a rank_factor of 1 SHOULD be used. 571 Sp (step_of_rank): (strictly positive integer) - an intermediate 572 computation based on the link properties with a certain neighbor, 573 i.e., the Expected Transmission Count (ETX) which provides an 574 average of number of packet transmissions between two nodes. ETX 575 is defined in detail by [decouto03high] and [RFC6551]. The ETX is 576 computed as the inverse of the Packet Delivery Ratio (PDR), this 577 is the number of transmitted packets, divided by the number of 578 acknowledged packets to a certain node (e.g., ETX = numTX/ 579 numTXAck). An implementation MUST follow OF0's normalization 580 guidance as discussed in Section 1 and Section 4.1 of [RFC6552], 581 maintaining Sp between MINIMUM_STEP_OF_RANK of 1 to indicate a 582 great quality and MAXIMUM_STEP_OF_RANK of 9 to indicate a really 583 poor quality, with DEFAULT_STEP_OF_RANK indicating a normal, 584 average quality. One RECOMMENDED way to achieve this in an 585 interoperable fashion is to set Sp to 2*ETX. 587 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 588 to the step_of_rank of a preferred parent, to allow the selection 589 of an additional feasible successor. If none is configured to the 590 device, then the step_of_rank is not stretched. In this 591 specification, stretch_of_rank SHOULD be set to 0. 593 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 594 constant DEFAULT_MIN_HOP_rank_increment [RFC6550]. 595 DEFAULT_MIN_HOP_rank_increment has a value of 256. 597 DAGRank(rank): Equivalent to the floor of "rank" as defined by 598 [RFC6550]. Specifically, when an Objective Function computes 599 Rank, this is defined as an unsigned integer (i.e., a 16-bit 600 value) Rank quantity. When the Rank is compared, e.g. to 601 determine parent relationships or loop detection, the integer 602 portion of the Rank is used. The integer portion of the Rank is 603 computed by the DAGRank() macro as floor(x) where floor(x) is the 604 function that evaluates to the greatest integer less than or equal 605 to x. DAGRank(rank) = floor(rank/MinHopRankIncrease). Nodes 606 compute its DAGRank(rank) using DAGRank(R(N)). 608 Rank computation scenario 610 +-------+ 611 | P | R(P) 612 | | 613 +-------+ 614 | 615 | 616 +-------+ 617 | N | R(N)=R(P) + rank_increment 618 | | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 619 +-------+ Sp=2*ETX 621 10.1.2. Rank computation Example 623 This section illustrates with an example the use of the Objective 624 Function Zero. Assume the following parameters: 626 Rf = 1 628 Sp = 2* ETX 630 Sr = 0 632 minHopRankIncrease = 256 (default in RPL) 634 ETX=(numTX/numTXAck) 636 r(n) = r(p) + rank_increment 638 rank_increment = (Rf*Sp + Sr) * minHopRankIncrease 640 rank_increment = 512*numTx/numTxAck 642 Rank computation example for 5 hop network where numTx=100 and 643 numTxAck=75 for all nodes 645 +-------+ 646 | 0 | R(minHopRankIncrease) = 256 647 | | DAGRank(R(0)) = 1 648 +-------+ 649 | 650 | 651 +-------+ 652 | 1 | R(1)=R(0) + 683 = 939 653 | | DAGRank(R(1)) = 3 654 +-------+ 655 | 656 | 657 +-------+ 658 | 2 | R(2)=R(1) + 683 = 1622 659 | | DAGRank(R(2)) = 6 660 +-------+ 661 | 662 | 663 +-------+ 664 | 3 | R(3)=R(2)+683=2305 665 | | DAGRank(R(3)) = 9 666 +-------+ 667 | 668 | 669 +-------+ 670 | 4 | R(4)=R(3)+683=2988 671 | | DAGRank(R(4)) = 11 672 +-------+ 673 | 674 | 675 +-------+ 676 | 5 | R(5)=R(4)+683=3671 677 | | DAGRank(R(5)) = 14 678 +-------+ 680 10.2. RPL Configuration 682 In addition to the Objective Function (OF), a minimal configuration 683 for RPL SHOULD indicate the preferred mode of operation (either 684 Storing Mode or Non-Storing Mode) so different RPL implementations 685 can inter-operate. RPL information and hop-by-hop extension headers 686 MUST follow [RFC6553] and [RFC6554] specification. In the case that 687 the packets formed at the LLN need to cross through intermediate 688 routers, these MUST obey to the IP in IP encapsulation requirement 689 specified by the [RFC6282] and [RFC2460]. RPI and RH3 extension 690 headers and inner IP headers MUST be compressed according to 691 [RFC6282]. 693 10.2.1. Mode of Operation 695 For downstream route maintenance, in a minimal configuration, RPL 696 SHOULD be set to operate in the Non-Storing mode as described by 697 [RFC6550] Section 9.7. Storing mode ([RFC6550] Section 9.8) MAY be 698 supported in less constrained devices. 700 10.2.2. Trickle Timer 702 RPL signaling messages such as DIOs are sent using the Trickle 703 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 704 specification, the Trickle Timer MUST be used with the RPL defined 705 default values [RFC6550] (Section 8.3.1). For a description of the 706 Trickle timer operation see Section 4.2 on [RFC6206]. 708 10.2.3. Hysteresis 710 According to [RFC6552], [RFC6719] recommends the use of a boundary 711 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 712 when ranks are compared. When evaluating a parent that belongs to a 713 smaller path cost than current minimum path, the candidate node is 714 selected as new parent only if the difference between the new path 715 and the current path is greater than the defined 716 PARENT_SWITCH_THRESHOLD.Otherwise the node MAY continue to use the 717 current preferred parent. As for [RFC6719] the recommended value 718 for PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used (in the 719 form 128*ETX), the recommendation for this document is to use 720 PARENT_SWITCH_THRESHOLD equal to 768 if the metric being used is 721 2*ETX*minHopRankIncrease, or a proportional value. This mechanism is 722 suited to deal with parent hysteresis in both cases including routing 723 parent and time source neighbor selection. 725 10.2.4. Variable Values 727 The following table presents the RECOMMENDED values for the RPL- 728 related variables defined in the previous section. 730 Recommended variable values 732 +-------------------------+-------+ 733 | Variable | Value | 734 +-------------------------+-------+ 735 | EB_PERIOD | 10s | 736 +-------------------------+-------+ 737 | MAX_EB_DELAY | 180 | 738 +-------------------------+-------+ 739 | NUM_NEIGHBOURS_TO_WAIT | 2 | 740 +-------------------------+-------+ 741 | PARENT_SWITCH_THRESHOLD | 768 | 742 +-------------------------+-------+ 744 11. Examples 746 Several examples are provided to illustrate the content of the 747 packets used by the minimal configuration as proposed by this 748 document. Each example follows the same structure presenting first a 749 schematic header diagram, then the LSB stream of bytes that conform 750 the header and finally a description of each of the IEs the form the 751 packet. The packet formats are specific for the [IEEE802154-2012] 752 revision and MAY vary in future releases of the IEEE standard. In 753 case of differences between the packet content presented in this 754 section and the [IEEE802154-2012], the later has presedence. 756 The MAC header fields are described in a specific order. All field 757 formats in this examples are depicted in the order in which they are 758 transmitted by the PHY, from left to right, where the leftmost bit is 759 transmitted first in time. Bits within each field are numbered from 760 0 (leftmost and least significant) to k - 1 (rightmost and most 761 significant), where the length of the field is k bits. Fields that 762 are longer than a single octet are sent to the PHY in the order from 763 the octet containing the lowest numbered bits to the octet containing 764 the highest numbered bits, hence little endian ordering. 766 11.1. Example 1. Information Elements in EBs 768 Mandatory content for the EB as proposed by this draft. The example 769 uses a slotframe of 101 slots. The following figure represents 770 schematically the Header IE and Payload IE content of an EB. 772 Schematic representation of the IE header in an EB: 774 1 2 3 775 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Len3 = 6 |Sub ID = 0x1a|0| ASN 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 ASN | Join Priority | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Stream of bytes (in little-endian ordering) that derive 795 from the previous schematic header: 797 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 798 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F 800 Description of the IE fields in the example: 802 #Header IE Header 803 Len1 = Header IE Length (0) 804 Element ID = 0x7e - termination IE indicating Payload IE coming next 805 Type 0 807 #Payload IE Header (MLME) 808 Len2 = Payload IE Len (26 Bytes) 809 GroupID = 1 MLME (Nested) 810 Type = 1 812 #MLME-SubIE TSCH Synchronization 813 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 814 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 815 Type = Short (0) 816 ASN = Absolute Sequence Number (5 Bytes) 817 Join Priority = 1 Byte 819 #MLME-SubIE TSCH TimeSlot 820 Len4 = Length in bytes of the sub-IE payload (1 Byte) 821 SubID = 0x1c (MLME-SubIE Timeslot) 822 Type = Short (0) 823 TimeSlot template ID = 0x00 (default) 824 #MLME-SubIE Ch. Hopping 825 Len5 = Length in bytes of the sub-IE payload (1 Byte) 826 SubID = 0x09 (MLME-SubIE Ch. Hopping) 827 Type = Long (1) 828 Channel Hopping Sequence ID = 0x00 (default) 830 #MLME-SubIE TSCH Slotframe and Link 831 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 832 SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 833 Type = Short (0) 834 Number of slotframes = 0x01 835 SlotFrame Handle = 0x00 836 SlotFrame Size = 101 slots (0x65) 837 Number of Links = 0x01 838 Timeslot = 0x0000 (2B) 839 Channel Offset = 0x0000 (2B) 840 Link Option = 0x0F (tx,rx,shared,timekeeping) 842 11.2. Example 2. Information Elements in EBs not using default 843 timeslot template 845 Using a non-default timeslot template in EBs. Timeslot length set to 846 15ms instead of the 10ms default. 848 Schematic representation of the IE header in an EB: 850 1 2 3 851 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Len3 = 6 |Sub ID = 0x1a|0| ASN 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 ASN | Join Priority | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 = 2700 | macTsCCA = 128 | macTsTxOffset 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 = 3300 | macTsAckWait = 600 | macTsRxTx 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 = 192 | macTsMaxAck = 2400 | macTsMaxTx 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 Stream of bytes (in little-endian ordering) that derive 877 from the previous schematic header: 879 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 880 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 881 00 0A ... 883 Description of the IE fields in the example: 885 #Header IE Header 886 Len1 = Header IE Length (none) 887 Element ID = 0x7e - termination IE indicating Payload IE coming next 888 Type 0 890 #Payload IE Header (MLME) 891 Len2 = Payload IE Len (53 Bytes) 892 GroupID = 1 MLME (Nested) 893 Type = 1 895 #MLME-SubIE TSCH Synchronization 896 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 897 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 898 Type = Short (0) 899 ASN = Absolute Sequence Number (5 Bytes) 900 Join Priority = 1 Byte 902 #MLME-SubIE TSCH TimeSlot 903 Len4 = Lenght in bytes of the sub-IE payload (25 Bytes) 904 SubID = 0x1c (MLME-SubIE Timeslot) 905 Type = Short (0) 906 TimeSlot template ID = 0x01 (non-default) 908 Example timeslot timming using 15ms timeslot. 909 +--------------------------------+------------+ 910 | IEEE802.15.4 TSCH parameter | Value (us) | 911 +--------------------------------+------------+ 912 | tsCCAOffset | 2700 | 913 +--------------------------------+------------+ 914 | tsCCA | 128 | 915 +--------------------------------+------------+ 916 | tsTxOffset | 3180 | 917 +--------------------------------+------------+ 918 | tsRxOffset | 1680 | 919 +--------------------------------+------------+ 920 | tsRxAckDelay | 1200 | 921 +--------------------------------+------------+ 922 | tsTxAckDelay | 1500 | 923 +--------------------------------+------------+ 924 | tsRxWait | 3300 | 925 +--------------------------------+------------+ 926 | tsAckWait | 600 | 927 +--------------------------------+------------+ 928 | tsRxTx | 192 | 929 +--------------------------------+------------+ 930 | tsMaxAck | 2400 | 931 +--------------------------------+------------+ 932 | tsMaxTx | 4256 | 933 +--------------------------------+------------+ 934 | Time Slot duration | 15000 | 935 +--------------------------------+------------+ 937 #MLME-SubIE Ch. Hopping 938 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 939 SubID = 0x09 (MLME-SubIE Ch. Hopping) 940 Type = Long (1) 941 Channel Hopping Sequence ID = 0x00 (default) 943 11.3. Example 3. Information Elements in ACKs 945 Acknowledgement packets carry the ACK/NACK Time Correction IE (Header 946 IE). The following example illustrates the IE format as specified in 947 [IEEE802154-2012]. 949 1 2 3 950 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Stream of bytes (in little-endian ordering) that derive 956 from the previous schematic header: 958 02 0F TS#0 TS#1 960 Description of the IE fields in the example: 962 #Header IE Header 963 Len1 = Header IE Length (2 Bytes) 964 Element ID = 0x1e - ACK/NACK Time Correction IE 965 Type 0 967 11.4. Example 4. Auxiliary Security Header 969 The example illustrates content of the Auxiliary Security Header as 970 mandated by this document, if security is enabled. Security Level in 971 the example is set to ENC-MIC-32 (5). 973 1 974 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 |L = 5|M=1|1|1|0|Key Index = IDX| 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 Stream of bytes (in LSB format) that derive from the previous 980 schematic header: 982 6D IDX#0 984 Description of the Security Auxiliary Header fields in the example: 986 #Security Control (1 byte) 987 L = Security Level ENC-MIC-32 (5) 988 M = Key Identifier Mode (0x01) 989 Frame Counter Suppression = 1 (omitting Frame Counter field) 990 Frame Counter Size = 1 (construct Nonce from 5 byte ASN) 991 Reserved = 0 993 #Key Identifier (1 byte) 994 Key Index = IDX (deployment-specific KeyIndex parameter that 995 identifies the cryptographic key) 997 12. IANA Considerations 999 This document requests no immediate action by IANA. 1001 13. Acknowledgments 1003 The authors would like to acknowledge the guidance and input provided 1004 by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola 1005 Accettura, Malisa Vucinic and for the exhaustive and detailed review 1006 of the examples section to Simon Duquennoy, Guillaume Gaillard, 1007 Tengfei Chang and Jonathan Munoz. Also our acknowledge to the 6TiSCH 1008 Chairs Pascal Thubert and Thomas Watteyne for their guideance and 1009 advice. 1011 14. References 1013 14.1. Normative References 1015 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 1016 Hysteresis Objective Function", RFC 6719, September 2012. 1018 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1019 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1020 September 2011. 1022 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1023 Routing Header for Source Routes with the Routing Protocol 1024 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 1025 2012. 1027 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1028 Power and Lossy Networks (RPL) Option for Carrying RPL 1029 Information in Data-Plane Datagrams", RFC 6553, March 1030 2012. 1032 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 1033 Protocol for Low-Power and Lossy Networks (RPL)", RFC 1034 6552, March 2012. 1036 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 1037 Barthel, "Routing Metrics Used for Path Calculation in 1038 Low-Power and Lossy Networks", RFC 6551, March 2012. 1040 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1041 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1042 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1043 Lossy Networks", RFC 6550, March 2012. 1045 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1046 "The Trickle Algorithm", RFC 6206, March 2011. 1048 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1049 (IPv6) Specification", RFC 2460, December 1998. 1051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1052 Requirement Levels", BCP 14, RFC 2119, March 1997. 1054 [IEEE802154-2012] 1055 IEEE standard for Information Technology, "IEEE standard 1056 for Information Technology, IEEE std. 802.15.4, Part. 1057 15.4: Wireless Medium Access Control (MAC) and Physical 1058 Layer (PHY) Specifications for Low-Rate Wireless Personal 1059 Area Networks, June 2011 as amended by IEEE std. 1060 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1061 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 1062 2012. 1064 [IEEE802154] 1065 IEEE standard for Information Technology, "IEEE standard 1066 for Information Technology, IEEE std. 802.15.4, Part. 1067 15.4: Wireless Medium Access Control (MAC) and Physical 1068 Layer (PHY) Specifications for Low-Rate Wireless Personal 1069 Area Networks". 1071 [decouto03high] 1072 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 1073 High-Throughput Path Metric for Multi-Hop Wireless 1074 Routing", ACM International Conference on Mobile Computing 1075 and Networking (MobiCom) , June 2003. 1077 14.2. Informative References 1079 [RFC7554] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE 1080 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1081 Internet of Things (IoT): Problem Statement", RFC 7554, 1082 May 2015. 1084 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1085 Lossy Networks", RFC 7102, January 2014. 1087 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1088 CBC-MAC (CCM)", RFC 3610, September 2003. 1090 [I-D.ietf-6tisch-architecture] 1091 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1092 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 1093 in progress), May 2015. 1095 [I-D.ietf-6tisch-terminology] 1096 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1097 "Terminology in IPv6 over the TSCH mode of IEEE 1098 802.15.4e", draft-ietf-6tisch-terminology-04 (work in 1099 progress), March 2015. 1101 [I-D.ietf-6tisch-6top-interface] 1102 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 1103 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 1104 6top-interface-03 (work in progress), March 2015. 1106 14.3. External Informative References 1108 [CCM] National Institute of Standards and Technology, 1109 "Recommendation for Block Cipher Modes of Operation: The 1110 CCM Mode for Authentication and Confidentiality. SP 1111 800-38C", May 2004. 1113 [CCM-Star] 1114 Struik, R., "Formal Specification of the CCM* Mode of 1115 Operation, IEEE P802.15 Working Group for Wireless 1116 Personal Area Networks (WPANs).", September 2005. 1118 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1119 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1120 a Standards-Based Low-Power Wireless Development 1121 Environment", Transactions on Emerging Telecommunications 1122 Technologies , August 2012. 1124 Authors' Addresses 1126 Xavier Vilajosana (editor) 1127 Universitat Oberta de Catalunya 1128 156 Rambla Poblenou 1129 Barcelona, Catalonia 08018 1130 Spain 1132 Phone: +34 (646) 633 681 1133 Email: xvilajosana@uoc.edu 1135 Kris Pister 1136 University of California Berkeley 1137 490 Cory Hall 1138 Berkeley, California 94720 1139 USA 1141 Email: pister@eecs.berkeley.edu