idnits 2.17.1 draft-ietf-6tisch-minimal-12.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 (September 21, 2015) is 3111 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 1103, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 1108, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 1113, but not defined == Unused Reference: 'RFC7102' is defined on line 1082, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 1086, 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 (-10) exists of draft-ietf-6tisch-terminology-05 Summary: 1 error (**), 0 flaws (~~), 7 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: March 24, 2016 University of California Berkeley 6 September 21, 2015 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-12 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 March 24, 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 . . . . . . . . . . . . . . . . . . . . 9 65 7.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 9 66 7.2. Time Source Neighbor Selection . . . . . . . . . . . . . 10 67 8. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 11 68 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . 13 73 10.2. RPL Configuration . . . . . . . . . . . . . . . . . . . 15 74 10.2.1. Mode of Operation . . . . . . . . . . . . . . . . . 15 75 10.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . 15 76 10.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 15 77 10.2.4. Variable Values . . . . . . . . . . . . . . . . . . 16 78 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 11.1. Example 1. Information Elements in EBs . . . . . . . . . 16 80 11.2. Example 2. Information Elements in EBs not using default 81 timeslot template . . . . . . . . . . . . . . . . . . . 18 82 11.3. Example 3. Information Elements in ACKs . . . . . . . . 20 83 11.4. Example 4. Auxiliary Security Header . . . . . . . . . . 21 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 88 14.2. Informative References . . . . . . . . . . . . . . . . . 24 89 14.3. External Informative References . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 other (dynamic) scheduling solutions. Details about such dynamic 170 scheduling solution are out of scope of this document. Details about 171 the usage of the non scheduled cells are out of scope of this 172 document. 174 The slotframe length (expressed in number of time slots) is 175 configurable. The length used determines the duty cycle of the 176 network. For example, a network with a 0.99% duty cycle is composed 177 of a slotframe of 101 slots, which includes 1 active slot. The 178 present document RECOMMENDS the use of a default slot duration set to 179 10ms and its corresponding default timeslot timings defined by the 180 [IEEE802154] macTimeslotTemplate. The use of the default 181 macTimeslotTemplate MUST be announced in the EB by using the Timeslot 182 IE containing only the default macTimeslotTemplateId. Other time 183 slot durations MAY be supported and MUST be announced in the EBs. If 184 one uses a timeslot duration different than 10ms, EBs MUST contain 185 the complete TimeSlot IE as described in Section 3.4. This document 186 also recommends to clearly indicate nodes not supporting the default 187 timeslot value. 189 Example schedule with 0.99% duty cycle 191 Chan. +----------+----------+ +----------+ 192 Off.0 | TxRxS/EB | OFF | | OFF | 193 Chan. +----------+----------+ +----------+ 194 Off.1 | | | ... | | 195 +----------+----------+ +----------+ 196 . 197 . 198 . 199 Chan. +----------+----------+ +----------+ 200 Off.15 | | | | | 201 +----------+----------+ +----------+ 203 slotOffset 0 1 100 205 EB: Enhanced Beacon 206 Tx: Transmit 207 Rx: Receive 208 S: Shared 209 OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism) 211 3.2. Cell Options 213 Per [IEEE802154] TSCH, each scheduled cell has an associated bitmap 214 of cell options, called LinkOptions. The scheduled cell in the 215 minimal schedule is configured as a Hard cell 216 [RFC7554][I-D.ietf-6tisch-6top-interface]. Additional available 217 cells MAY be scheduled by a dynamic scheduling solution. The dynamic 218 scheduling solution is out of scope, and this specification does not 219 make any restriction on the LinkOption associated with those 220 dynamically scheduled cells (i.e. they can be hard cells or soft 221 cells). 223 The active cell is assigned the bitmap of cell options below. 224 Because both the "Transmit" and "Receive" bits are set, a node 225 transmits if there is a packet in its queue, listens otherwise. 226 Because the "shared" bit is set, the back-off mechanism defined in 227 [IEEE802154] is used to resolve contention when transmitting. This 228 results in "Slotted Aloha" behavior. The "Timekeeping" flag is set 229 so nodes initialy joining the network can maintin synchronization to 230 the advertising node using that slot. Other time source neighbors 231 are selected using the DODAG structure of the network (detailed 232 below). 234 b0 = Transmit = 1 (set) 236 b1 = Receive = 1 (set) 238 b2 = Shared = 1 (set) 240 b3 = Timekeeping = 1 (set) 242 b4-b7 = Reserved (clear) 244 All remaining cells are unscheduled. In unscheduled cells, the nodes 245 SHOULD keep their radio off. In a memory-efficient implementation, 246 scheduled cells can be represented by a circular linked list. 247 Unscheduled cells SHOULD NOT occupy any memory. 249 3.3. Retransmissions 251 The maximum number of link layer retransmissions is set to 3. For 252 packets which require an acknowledgment, if none is received after a 253 total of 4 attempts, the transmission is considered failed and the 254 link layer MUST notify the upper layer. Packets sent to the 255 broadcast MAC address (including EBs) are not acknowledged and 256 therefore not retransmitted. 258 3.4. Time Slot timing 260 The figure below shows an active timeslot in which a packet is sent 261 from the transmitter node (TX) to the receiver node (RX). A link- 262 layer acknowledgment is sent by the RX node to the TX node when the 263 packet is to be acknowledged. The TsTxOffset duration defines the 264 instant in the timeslot when the first bit after the Start of Frame 265 Delimiter (SFD) of the transmitted packet leaves the radio of the TX 266 node. The radio of the RX node is turned on tsRxWait/2 before that 267 instant, and listens for at least tsRxWait. This allows for a de- 268 synchronization between the two nodes of at most tsRxWait/2 in either 269 direction (early or late). The RX node needs to send the first bit 270 after the SFD of the MAC acknowledgment exactly TsTxAckDelay after 271 the end of the last byte of the received packet. TX's radio has to 272 be turned on tsAckWait/2 before that time, and keep listening for at 273 least tsAckWait. The TX node can perform a Clear Channel Assessment 274 (CCA) if required, this does not interfere with the scope of this 275 document. As for a minimal configuration, CCA is OPTIONAL. 277 Time slot internal timing diagram 279 /---------------------- Time Slot Duration ----------------------/ 280 | / (5) / | 281 | | / tsRxAckDelay /| | | | 282 |-------------------+--------------+------------------+------+---| 283 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 284 |----+-------+------+--------------+------------------+------+---| 285 |/ tsTxOffset /| | | | | 286 | | | | | | 287 |-------------------+--------------+------------------+------+---| 288 RX | | | | RX frame | |TX ACK| | 289 |----------------+--+--+-----------+------------------+------+---| 290 | | | | | | | | 291 | / (4) / / tsTxAckDelay / | | 292 Start End 293 of of 294 Slot Slot 295 /(1)/ tsCCAOffset 296 /(2)/ tsCCA 297 /(3)/ tsRxTx 298 /(4)/ tsRxWait 299 /(5)/ tsAckWait 301 The timing parameters for the default macTimeslotTemplate 302 (macTimeslotTemplateId = 0) MUST be used when utilizing the default 303 time slot duration. In this case, the Timeslot IE only transports 304 the macTimeslotTemplateId with value 0x00. If a timeslot template 305 other than the default is used, the EB MUST contain a complete 306 TimeSlot IE indicating the timeslot duration and the corresponding 307 timeslot timings. Note however that in case of discrepancy between 308 the values in this document and [IEEE802154], the IEEE standard has 309 precedence. 311 4. IEEE.802.15.4 Specific Header Fields and Considerations 313 The IEEE802.15.4 header of BEACON, DATA, ACKNOWLEDGEMENT, MAC COMMAND 314 frames MUST include the Sequence Number field, the Source Address 315 field and the Destination Address field. Frame Version field MUST be 316 set to 0b10 (Frame Version 2). 318 The PAN ID Compression bit in a BEACON frame MUST indicate that the 319 Source PAN ID is "Not Present" and the Destination PAN ID is 320 "Present". The source address field MUST be filled with an extended 321 address (64 bit) and this be indicated in the corresponding Frame 322 Control field. The Destination address field MUST be filled with a 323 short address (16bit) with a value of 0xffff to represent the 324 broadcast short address. 326 A Node aiming to join the network by receving a properly formed 327 BEACON shall enter in a scan phase and shall store the value of 328 macPANId and then set it to 0xffff for the duration of the scan in 329 order to meet the filtering rules in [IEEE802154]. 331 When using DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types the source 332 and destination address fields MUST be filled with an extended 333 address (64 bit) and this be indicated in the corresponding Frame 334 Control field. The Destination PAN ID MUST be present, the Source 335 PAN ID MUST be elided. The PAN ID Compression field MUST indicate 336 that the Destination PAN ID is "Present" and the Source PAN ID is 337 "Not Present". With [IEEE802154-2012] and according to Table 2a, 338 this is accomplished by setting the PAN ID Compression bit to 0b0. 340 When preparing the security header, the ASN MUST be written into the 341 Nonce in MSB format (most significant byte first) as indicated in 342 [IEEE802154]. 344 5. Enhanced Beacons Configuration and Content 346 [IEEE802154] does not define how often EBs are sent, nor their 347 contents. EBs MUST NOT in general be used for synchronization. 348 Synchronization is achieved via acknowledgements to normal packet 349 traffic, and keepalives. For a minimal TSCH configuration, a mote 350 SHOULD send an EB every EB_PERIOD. For additional reference see 351 [RFC7554] where different synchronization approaches are summarized. 352 EBs are only authenticated and neither Payload IEs nor the frame 353 payload are encrypted. 355 EBs MUST be sent as per [IEEE802154] and MUST carry the Information 356 Elements (IEs) listed below. Refer to Section 11.1 for an example of 357 the Information Elements Header Content. 359 Synchronization IE: Contains synchronization information such as 360 ASN and Join Priority. The value of Join Priority is discussed in 361 Section 7.2. 363 TSCH Timeslot IE: Contains the timeslot template identifier. This 364 specification uses the default timeslot template as defined in 365 [IEEE802154]. In the case that a non-default timeslot template is 366 used, the IE Content MUST follow the specification as defined in 367 [IEEE802154] . Refer to Section 11.1 for an illustrative example 368 of non default timeslot template. 370 Channel Hopping IE: Contains the channel hopping template 371 identifier. This specification uses the default channel hopping 372 template, as defined in [IEEE802154]. The default sequence for 373 the 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 374 13, 3, 9, 10] [IEEE802154]. Note however that in case of 375 discrepancy between the values in this document and [IEEE802154], 376 the IEEE standard specification has preference. 378 Frame and Link IE: Each node MUST indicate the schedule in each EB 379 through a Frame and Link IE. This enables nodes which implement 380 [IEEE802154] to learn the schedule used in the network as they 381 join it. This draft defines the use of a single cell set at 382 channel offset 0x00, slot offset 0x00 and with linkOption 0x0F 383 (TX, RX, SHARED bits set). 385 6. Acknowledgment 387 Link-layer acknowledgment frames are built according to [IEEE802154]. 388 Unicast frames sent to a unicast MAC destination address MUST request 389 an acknowledgment. The sender node MUST set the ACK requested bit in 390 the MAC header. The acknowledgment frame is of type ACK (frame type 391 value 0b010). Each acknowledgment contains the following IE: 393 ACK/NACK Time Correction IE: The ACK/NACK time correction IE 394 carries the measured de-synchronization between the sender and the 395 receiver. Refer to Section 11.3 for an example of the Header IE 396 content. The possible values for the Time Synchronization 397 Information and ACK status are described in [IEEE802154]. 399 7. Neighbor information 401 [IEEE802154] does not define how and when each node in the network 402 keeps information about its neighbors. Keeping the following 403 information in the neighbor table is RECOMMENDED: 405 7.1. Neighbor Table 407 The exact format of the neighbor table is implementation-specific, 408 but it SHOULD contain the following information for each neighbor: 410 Neighbor statistics: 412 numTx: number of transmitted packets to that neighbor 414 numTxAck: number of transmitted packets that have been 415 acknowledged by that neighbor 417 numRx: number of received packets from that neighbor 419 The EUI64 of the neighbor. 421 Timestamp of the last frame received from that neighbor. This can 422 be based on the ASN counter or any other time base. It can be 423 used to trigger a keep-alive message. 425 RPL rank of that neighbor. 427 A flag indicating whether this neighbor is a time source neighbor. 429 Connectivity statistics (e.g., RSSI), which can be used to 430 determine the quality of the link. 432 In addition to that information, each node has to be able to compute 433 some RPL Objective Function (OF), taking into account the neighbor 434 and connectivity statistics. An example RPL objective function is 435 the OF Zero as described in [RFC6552] and Section 10.1.1. 437 7.2. Time Source Neighbor Selection 439 Each node MUST select at least one Time Source Neighbor among the 440 nodes in its RPL routing parent set. When a node joins a network, it 441 has no routing information. To select its time source neighbor, it 442 uses the Join Priority field in the EB, as described in [IEEE802154]. 443 The Sync IE contains the ASN and 1 Byte field named Join Priority. 444 The Join Priority of any node MUST be equivalent to the result of the 445 function DAGRank(rank)-1. The Join Priority of the DAG root is also 446 equivalent to DAGRank(rank)-1. According to Section 10.1.1 the 447 DAGRank(rank(0)) = 1 and therefore the DAGRank(rank(0))-1 is 0 which 448 is compliant with the requirement of Join Priority = 0 imposed by 449 [IEEE802154]. A lower value of the Join Priority indicates higher 450 preference to connect to that device. When a node joins the network, 451 it MUST NOT send EBs before having acquired a RPL rank. This avoids 452 routing loops and matches RPL topology with underlying mesh topology. 453 As soon as a node acquires a RPL rank (see [RFC6550] and 454 Section 10.1.1), it SHOULD send Enhanced Beacons including a Sync IE 455 with Join Priority field set to DAGRank(rank)-1, where rank is the 456 node's rank. If a node receives EBs from different nodes with equal 457 Join Priority, the time source neighbor selection SHOULD be assessed 458 by other metrics that can help determine the better connectivity 459 link. Time source neighbor hysteresis SHOULD be used, according to 460 the rules defined in Section 10.2.3. At any time, a node MUST 461 maintain connectivity to at least one time source neighbor. New time 462 source neighbors MUST be chosen among the neighbors in the RPL 463 routing parent set. 465 The decision for a node to select one Time Source Neighbor when 466 multiple EBs are received is implementation-specific. 468 For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT 469 neighbors have been received to select the best Time Source Neighbor. 470 This condition MAY apply unless a second EB is not received after 471 MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting 472 a first Time Source Neighbor. 474 Optionally, some form of hysteresis SHOULD be implemented to avoid 475 frequent changes in time source neighbors. 477 8. Queues and Priorities 479 [IEEE802154] does not define the use of queues to handle upper layer 480 data (either application or control data from upper layers). The use 481 of a single queue with the following rules is RECOMMENDED: 483 When the node is not synchronized to the network, higher layers 484 are not able to insert packets into the queue. 486 Frames generated by the MAC layer (e.g., EBs and ACK) have a 487 higher queuing priority than packets received from a higher layer. 489 Frame types Beacon and Command have a higher queuing priority than 490 frame types Data and ACK. 492 One entry in the queue is reserved at all times for frames of 493 types Beacon or Command frames. 495 9. Security 497 As this document refers to the interaction between Layer 3 and Layer 498 2 protocols, this interaction MUST be secured by L2 security 499 mechanisms as defined by [IEEE802154]. Two security mechanisms are 500 considered, authentication and encryption, authentication applies to 501 all packet content while encryption applies to header IEs and MAC 502 payload. Key distribution is out of scope of this document, but 503 examples include pre-configured keys at the nodes, shared keys among 504 peers or well-known keys. 506 The present document assumes the existence of two cryptographic keys, 507 which can be pre-configured. One of the keys (K1) is used to 508 authenticate EBs. As defined in Section Section 5, EBs MUST be 509 authenticated, with no payload encryption. This facilitates logical 510 segregation of distinct networks. A second key (K2) is used to 511 authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and 512 respective header IEs, with payload encryption. Depending on 513 security policy, these keys could be the same (i.e., K1=K2). 515 For early interoperability, K1 MAY be set to 36 54 69 53 43 48 20 6D 516 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15"). 518 10. RPL on TSCH 520 Nodes in a multihop network MUST use the RPL routing protocol 521 [RFC6550]. 523 10.1. RPL Objective Function Zero 525 Nodes in the multihop network MUST implement the RPL Objective 526 Function Zero [RFC6552]. 528 10.1.1. Rank computation 530 The rank computation is described at [RFC6552], Section 4.1. A node 531 rank is computed by the following equation: 533 R(N) = R(P) + rank_increment 535 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 537 Where: 539 R(N): Rank of the node. 541 R(P): Rank of the parent obtained as part of the DIO information. 543 rank_increment: The result of a function that determines the rank 544 increment. 546 Rf (rank_factor): A configurable factor that is used to multiply 547 the effect of the link properties in the rank_increment 548 computation. If none is configured, rank_factor of 1 is used. In 549 this specification, a rank_factor of 1 SHOULD be used. 551 Sp (step_of_rank): (strictly positive integer) - an intermediate 552 computation based on the link properties with a certain neighbor, 553 i.e., the Expected Transmission Count (ETX) which provides an 554 average of number of packet transmissions between two nodes. ETX 555 is defined in detail by [decouto03high] and [RFC6551]. The ETX is 556 computed as the inverse of the Packet Delivery Ratio (PDR), this 557 is the number of transmitted packets, divided by the number of 558 acknowledged packets to a certain node (e.g., ETX = numTX/ 559 numTXAck). An implementation MUST follow OF0's normalization 560 guidance as discussed in Section 1 and Section 4.1 of [RFC6552], 561 maintaining Sp between MINIMUM_STEP_OF_RANK of 1 to indicate a 562 great quality and MAXIMUM_STEP_OF_RANK of 9 to indicate a really 563 poor quality, with DEFAULT_STEP_OF_RANK indicating a normal, 564 average quality. One RECOMMENDED way to achieve this in an 565 interoperable fashion is to set Sp to (3*ETX)-2. 567 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 568 to the step_of_rank of a preferred parent, to allow the selection 569 of an additional feasible successor. If none is configured to the 570 device, then the step_of_rank is not stretched. In this 571 specification, stretch_of_rank SHOULD be set to 0. 573 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 574 constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550]. 575 DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. 577 DAGRank(rank): Equivalent to the floor of "rank" as defined by 578 [RFC6550]. Specifically, when an Objective Function computes 579 Rank, this is defined as an unsigned integer (i.e., a 16-bit 580 value) Rank quantity. When the Rank is compared, e.g. to 581 determine parent relationships or loop detection, the integer 582 portion of the Rank is used. The integer portion of the Rank is 583 computed by the DAGRank() macro as floor(x) where floor(x) is the 584 function that evaluates to the greatest integer less than or equal 585 to x. DAGRank(rank) = floor(rank/MinHopRankIncrease). Nodes 586 compute its DAGRank(rank) using DAGRank(R(N)). 588 Rank computation scenario 590 +-------+ 591 | P | R(P) 592 | | 593 +-------+ 594 | 595 | 596 +-------+ 597 | N | R(N)=R(P) + rank_increment 598 | | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 599 +-------+ Sp= (3*ETX) - 2 601 10.1.2. Rank computation Example 603 This section illustrates with an example the use of the Objective 604 Function Zero. Assume the following parameters: 606 Rf = 1 608 Sp = (3*ETX)-2 610 Sr = 0 611 minHopRankIncrease = 256 (default in RPL) 613 ETX=(numTX/numTXAck) 615 r(n) = r(p) + rank_increment 617 rank_increment = (Rf*Sp + Sr) * minHopRankIncrease 619 rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512 621 Rank computation example for 5 hop network where numTx=100 and 622 numTxAck=75 for all nodes 624 +-------+ 625 | 0 | R(minHopRankIncrease) = 256 626 | | DAGRank(R(0)) = 1 627 +-------+ 628 | 629 | 630 +-------+ 631 | 1 | R(1)=R(0) + 512 = 768 632 | | DAGRank(R(1)) = 3 633 +-------+ 634 | 635 | 636 +-------+ 637 | 2 | R(2)=R(1) + 512 = 1280 638 | | DAGRank(R(2)) = 5 639 +-------+ 640 | 641 | 642 +-------+ 643 | 3 | R(3)=R(2) + 512 = 1792 644 | | DAGRank(R(3)) = 7 645 +-------+ 646 | 647 | 648 +-------+ 649 | 4 | R(4)=R(3) + 512 = 2304 650 | | DAGRank(R(4)) = 9 651 +-------+ 652 | 653 | 654 +-------+ 655 | 5 | R(5)=R(4) + 512 = 2816 656 | | DAGRank(R(5)) = 11 657 +-------+ 659 10.2. RPL Configuration 661 In addition to the Objective Function (OF), nodes in a multihop 662 network MUST indicate the preferred mode of operation using the MOP 663 field in DIO. Nodes not being able to operate in the specified mode 664 of operation MUST only join as leaf nodes. RPL information and hop- 665 by-hop extension headers MUST follow [RFC6553] and [RFC6554] 666 specification. In the case that the packets formed at the LLN need 667 to cross through intermediate routers, these MUST obey to the IP in 668 IP encapsulation requirement specified by the [RFC6282] and 669 [RFC2460]. RPI and RH3 extension headers and inner IP headers MUST 670 be compressed according to [RFC6282]. 672 10.2.1. Mode of Operation 674 Nodes implementing a minimal configuration and forming a multihop 675 network, MUST support the non-storing ([RFC6550] Section 9.7) mode of 676 operation. The storing ([RFC6550] Section 9.8) mode of operation 677 SHOULD be supported by nodes with enough capabilities. Non-storing 678 mode of operation is the default mode that a node selects when acting 679 as a DAG root. 681 10.2.2. Trickle Timer 683 RPL signaling messages such as DIOs are sent using the Trickle 684 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 685 specification, the Trickle Timer MUST be used with the RPL defined 686 default values [RFC6550] (Section 8.3.1). For a description of the 687 Trickle timer operation see Section 4.2 on [RFC6206]. 689 10.2.3. Hysteresis 691 According to [RFC6552], [RFC6719] recommends the use of a boundary 692 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 693 when ranks are compared. When evaluating a parent that belongs to a 694 smaller path cost than current minimum path, the candidate node is 695 selected as new parent only if the difference between the new path 696 and the current path is greater than the defined 697 PARENT_SWITCH_THRESHOLD.Otherwise the node MAY continue to use the 698 current preferred parent. As for [RFC6719] the recommended value 699 for PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used (in the 700 form 128*ETX), the recommendation for this document is to use 701 PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is 702 (3*ETX-2)*minHopRankIncrease, or a proportional value. This 703 mechanism is suited to deal with parent hysteresis in both cases 704 including routing parent and time source neighbor selection. 706 10.2.4. Variable Values 708 The following table presents the RECOMMENDED values for the RPL- 709 related variables defined in the previous section. 711 Recommended variable values 713 +-------------------------+-------+ 714 | Variable | Value | 715 +-------------------------+-------+ 716 | EB_PERIOD | 10s | 717 +-------------------------+-------+ 718 | MAX_EB_DELAY | 180 | 719 +-------------------------+-------+ 720 | NUM_NEIGHBOURS_TO_WAIT | 2 | 721 +-------------------------+-------+ 722 | PARENT_SWITCH_THRESHOLD | 640 | 723 +-------------------------+-------+ 725 11. Examples 727 Several examples are provided to illustrate the content of the 728 packets used by the minimal configuration as proposed by this 729 document. Each example follows the same structure presenting first a 730 schematic header diagram, then the LSB stream of bytes that conform 731 the header and finally a description of each of the IEs the form the 732 packet. The packet formats are specific for the [IEEE802154-2012] 733 revision and may vary in future releases of the IEEE standard. In 734 case of differences between the packet content presented in this 735 section and the [IEEE802154-2012], the later has presedence. 737 The MAC header fields are described in a specific order. All field 738 formats in this examples are depicted in the order in which they are 739 transmitted by the PHY, from left to right, where the leftmost bit is 740 transmitted first in time. Bits within each field are numbered from 741 0 (leftmost and least significant) to k - 1 (rightmost and most 742 significant), where the length of the field is k bits. Fields that 743 are longer than a single octet are sent to the PHY in the order from 744 the octet containing the lowest numbered bits to the octet containing 745 the highest numbered bits, hence little endian ordering. 747 11.1. Example 1. Information Elements in EBs 749 Mandatory content for the EB as proposed by this draft. The example 750 uses a slotframe of 101 slots. The following figure represents 751 schematically the Header IE and Payload IE content of an EB. 753 Schematic representation of the IE header in an EB: 755 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Len3 = 6 |Sub ID = 0x1a|0| ASN 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 ASN | Join Priority | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Stream of bytes (in little-endian ordering) that derive 776 from the previous schematic header: 778 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 779 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F 781 Description of the IE fields in the example: 783 #Header IE Header 784 Len1 = Header IE Length (0) 785 Element ID = 0x7e - termination IE indicating Payload IE coming next 786 Type 0 788 #Payload IE Header (MLME) 789 Len2 = Payload IE Len (26 Bytes) 790 GroupID = 1 MLME (Nested) 791 Type = 1 793 #MLME-SubIE TSCH Synchronization 794 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 795 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 796 Type = Short (0) 797 ASN = Absolute Sequence Number (5 Bytes) 798 Join Priority = 1 Byte 800 #MLME-SubIE TSCH TimeSlot 801 Len4 = Length in bytes of the sub-IE payload (1 Byte) 802 SubID = 0x1c (MLME-SubIE Timeslot) 803 Type = Short (0) 804 TimeSlot template ID = 0x00 (default) 806 #MLME-SubIE Ch. Hopping 807 Len5 = Length in bytes of the sub-IE payload (1 Byte) 808 SubID = 0x09 (MLME-SubIE Ch. Hopping) 809 Type = Long (1) 810 Channel Hopping Sequence ID = 0x00 (default) 812 #MLME-SubIE TSCH Slotframe and Link 813 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 814 SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 815 Type = Short (0) 816 Number of slotframes = 0x01 817 SlotFrame Handle = 0x00 818 SlotFrame Size = 101 slots (0x65) 819 Number of Links = 0x01 820 Timeslot = 0x0000 (2B) 821 Channel Offset = 0x0000 (2B) 822 Link Option = 0x0F (tx,rx,shared,timekeeping) 824 11.2. Example 2. Information Elements in EBs not using default 825 timeslot template 827 Using a non-default timeslot template in EBs. Timeslot length set to 828 15ms instead of the 10ms default. 830 Schematic representation of the IE header in an EB: 832 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Len3 = 6 |Sub ID = 0x1a|0| ASN 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 ASN | Join Priority | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 = 2700 | macTsCCA = 128 | macTsTxOffset 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 = 3300 | macTsAckWait = 600 | macTsRxTx 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 = 192 | macTsMaxAck = 2400 | macTsMaxTx 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 Stream of bytes (in little-endian ordering) that derive 860 from the previous schematic header: 862 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 863 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 864 00 0A ... 866 Description of the IE fields in the example: 868 #Header IE Header 869 Len1 = Header IE Length (none) 870 Element ID = 0x7e - termination IE indicating Payload IE coming next 871 Type 0 873 #Payload IE Header (MLME) 874 Len2 = Payload IE Len (53 Bytes) 875 GroupID = 1 MLME (Nested) 876 Type = 1 878 #MLME-SubIE TSCH Synchronization 879 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 880 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 881 Type = Short (0) 882 ASN = Absolute Sequence Number (5 Bytes) 883 Join Priority = 1 Byte 885 #MLME-SubIE TSCH TimeSlot 886 Len4 = Lenght in bytes of the sub-IE payload (25 Bytes) 887 SubID = 0x1c (MLME-SubIE Timeslot) 888 Type = Short (0) 889 TimeSlot template ID = 0x01 (non-default) 891 Example timeslot timming using 15ms timeslot. 892 +--------------------------------+------------+ 893 | IEEE802.15.4 TSCH parameter | Value (us) | 894 +--------------------------------+------------+ 895 | tsCCAOffset | 2700 | 896 +--------------------------------+------------+ 897 | tsCCA | 128 | 898 +--------------------------------+------------+ 899 | tsTxOffset | 3180 | 900 +--------------------------------+------------+ 901 | tsRxOffset | 1680 | 902 +--------------------------------+------------+ 903 | tsRxAckDelay | 1200 | 904 +--------------------------------+------------+ 905 | tsTxAckDelay | 1500 | 906 +--------------------------------+------------+ 907 | tsRxWait | 3300 | 908 +--------------------------------+------------+ 909 | tsAckWait | 600 | 910 +--------------------------------+------------+ 911 | tsRxTx | 192 | 912 +--------------------------------+------------+ 913 | tsMaxAck | 2400 | 914 +--------------------------------+------------+ 915 | tsMaxTx | 4256 | 916 +--------------------------------+------------+ 917 | Time Slot duration | 15000 | 918 +--------------------------------+------------+ 920 #MLME-SubIE Ch. Hopping 921 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 922 SubID = 0x09 (MLME-SubIE Ch. Hopping) 923 Type = Long (1) 924 Channel Hopping Sequence ID = 0x00 (default) 926 11.3. Example 3. Information Elements in ACKs 928 Acknowledgement packets carry the ACK/NACK Time Correction IE (Header 929 IE). The following example illustrates the IE format as specified in 930 [IEEE802154-2012]. 932 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Stream of bytes (in little-endian ordering) that derive 939 from the previous schematic header: 941 02 0F TS#0 TS#1 943 Description of the IE fields in the example: 945 #Header IE Header 946 Len1 = Header IE Length (2 Bytes) 947 Element ID = 0x1e - ACK/NACK Time Correction IE 948 Type 0 950 11.4. Example 4. Auxiliary Security Header 952 The example illustrates content of the Auxiliary Security Header as 953 mandated by this document, if security is enabled. Security Level in 954 the example is set to ENC-MIC-32 (5). 956 1 957 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 |L = 5|M=1|1|1|0|Key Index = IDX| 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Stream of bytes (in LSB format) that derive from the previous 963 schematic header: 965 6D IDX#0 967 Description of the Security Auxiliary Header fields in the example: 969 #Security Control (1 byte) 970 L = Security Level ENC-MIC-32 (5) 971 M = Key Identifier Mode (0x01) 972 Frame Counter Suppression = 1 (omitting Frame Counter field) 973 Frame Counter Size = 1 (construct Nonce from 5 byte ASN) 974 Reserved = 0 976 #Key Identifier (1 byte) 977 Key Index = IDX (deployment-specific KeyIndex parameter that 978 identifies the cryptographic key) 980 12. IANA Considerations 982 This document requests no immediate action by IANA. 984 13. Acknowledgments 986 The authors would like to acknowledge the guidance and input provided 987 by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola 988 Accettura, Malisa Vucinic and for the exhaustive and detailed review 989 of the examples section to Simon Duquennoy, Guillaume Gaillard, 990 Tengfei Chang and Jonathan Munoz. Also our acknowledge to the 6TiSCH 991 Chairs Pascal Thubert and Thomas Watteyne for their guideance and 992 advice. 994 14. References 996 14.1. Normative References 998 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 999 Hysteresis Objective Function", RFC 6719, 1000 DOI 10.17487/RFC6719, September 2012, 1001 . 1003 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1004 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1005 DOI 10.17487/RFC6282, September 2011, 1006 . 1008 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1009 Routing Header for Source Routes with the Routing Protocol 1010 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1011 DOI 10.17487/RFC6554, March 2012, 1012 . 1014 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1015 Power and Lossy Networks (RPL) Option for Carrying RPL 1016 Information in Data-Plane Datagrams", RFC 6553, 1017 DOI 10.17487/RFC6553, March 2012, 1018 . 1020 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 1021 Protocol for Low-Power and Lossy Networks (RPL)", 1022 RFC 6552, DOI 10.17487/RFC6552, March 2012, 1023 . 1025 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1026 and D. Barthel, "Routing Metrics Used for Path Calculation 1027 in Low-Power and Lossy Networks", RFC 6551, 1028 DOI 10.17487/RFC6551, March 2012, 1029 . 1031 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1032 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1033 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1034 Low-Power and Lossy Networks", RFC 6550, 1035 DOI 10.17487/RFC6550, March 2012, 1036 . 1038 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1039 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 1040 March 2011, . 1042 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1043 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1044 December 1998, . 1046 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1047 Requirement Levels", BCP 14, RFC 2119, 1048 DOI 10.17487/RFC2119, March 1997, 1049 . 1051 [IEEE802154-2012] 1052 IEEE standard for Information Technology, "IEEE standard 1053 for Information Technology, IEEE std. 802.15.4, Part. 1054 15.4: Wireless Medium Access Control (MAC) and Physical 1055 Layer (PHY) Specifications for Low-Rate Wireless Personal 1056 Area Networks, June 2011 as amended by IEEE std. 1057 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1058 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 1059 2012. 1061 [IEEE802154] 1062 IEEE standard for Information Technology, "IEEE standard 1063 for Information Technology, IEEE std. 802.15.4, Part. 1064 15.4: Wireless Medium Access Control (MAC) and Physical 1065 Layer (PHY) Specifications for Low-Rate Wireless Personal 1066 Area Networks". 1068 [decouto03high] 1069 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 1070 High-Throughput Path Metric for Multi-Hop Wireless 1071 Routing", ACM International Conference on Mobile Computing 1072 and Networking (MobiCom) , June 2003. 1074 14.2. Informative References 1076 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1077 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1078 Internet of Things (IoT): Problem Statement", RFC 7554, 1079 DOI 10.17487/RFC7554, May 2015, 1080 . 1082 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1083 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1084 2014, . 1086 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1087 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 1088 2003, . 1090 [I-D.ietf-6tisch-terminology] 1091 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1092 "Terminology in IPv6 over the TSCH mode of IEEE 1093 802.15.4e", draft-ietf-6tisch-terminology-05 (work in 1094 progress), July 2015. 1096 [I-D.ietf-6tisch-6top-interface] 1097 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 1098 (6top) Interface", draft-ietf-6tisch-6top-interface-04 1099 (work in progress), July 2015. 1101 14.3. External Informative References 1103 [CCM] National Institute of Standards and Technology, 1104 "Recommendation for Block Cipher Modes of Operation: The 1105 CCM Mode for Authentication and Confidentiality. SP 1106 800-38C", May 2004. 1108 [CCM-Star] 1109 Struik, R., "Formal Specification of the CCM* Mode of 1110 Operation, IEEE P802.15 Working Group for Wireless 1111 Personal Area Networks (WPANs).", September 2005. 1113 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1114 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1115 a Standards-Based Low-Power Wireless Development 1116 Environment", Transactions on Emerging Telecommunications 1117 Technologies , August 2012. 1119 Authors' Addresses 1121 Xavier Vilajosana (editor) 1122 Universitat Oberta de Catalunya 1123 156 Rambla Poblenou 1124 Barcelona, Catalonia 08018 1125 Spain 1127 Phone: +34 (646) 633 681 1128 Email: xvilajosana@uoc.edu 1130 Kris Pister 1131 University of California Berkeley 1132 490 Cory Hall 1133 Berkeley, California 94720 1134 USA 1136 Email: pister@eecs.berkeley.edu