idnits 2.17.1 draft-ietf-6tisch-minimal-10.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 (June 27, 2015) is 3225 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 1059, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 1064, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 1069, but not defined == Unused Reference: 'RFC7102' is defined on line 1035, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 1038, 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: December 29, 2015 University of California Berkeley 6 June 27, 2015 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-10 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 December 29, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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. Enhanced Beacons Configuration and Content . . . . . . . . . 7 62 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Neighbor information . . . . . . . . . . . . . . . . . . . . 9 64 6.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 9 65 6.2. Time Source Neighbor Selection . . . . . . . . . . . . . 9 66 7. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 10 67 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 9. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. RPL Objective Function Zero . . . . . . . . . . . . . . . 11 70 9.1.1. Rank computation . . . . . . . . . . . . . . . . . . 11 71 9.1.2. Rank computation Example . . . . . . . . . . . . . . 13 72 9.2. RPL Configuration . . . . . . . . . . . . . . . . . . . . 14 73 9.2.1. Mode of Operation . . . . . . . . . . . . . . . . . . 15 74 9.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . . 15 75 9.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 15 76 9.2.4. Variable Values . . . . . . . . . . . . . . . . . . . 15 77 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 10.1. Example 1. Information Elements in EBs . . . . . . . . . 16 79 10.2. Example 2. Information Elements in EBs not using default 80 timeslot template . . . . . . . . . . . . . . . . . . . 18 81 10.3. Example 3. Information Elements in ACKs . . . . . . . . 20 82 10.4. Example 4. Auxiliary Security Header . . . . . . . . . . 21 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 87 13.2. Informative References . . . . . . . . . . . . . . . . . 24 88 13.3. External Informative References . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 The nodes in a IEEE 802.15.4 TSCH network follow a communication 94 schedule. The entity (centralized or decentralized) responsible for 95 building and maintaining that schedule has precise control over the 96 trade-off between the network's latency, bandwidth, reliability and 97 power consumption.During early interoperability testing and 98 development, however, simplicity is more important than efficiency. 99 One goal of this document is to define the simplest set of rules for 100 building a TSCH-compliant network, at the necessary price of lesser 101 efficiency. Yet, this minimal mode of operation MAY also be used 102 during network bootstrap before any schedule is installed into the 103 network so nodes can self-organize and the management and 104 configuration information be distributed. In addition, the minimal 105 configuration MAY be used as a fall-back mode of operation, ensuring 106 connectivity of nodes in case that dynamic scheduling mechanisms fail 107 or are not available. [IEEE802154] provides a mechanism whereby the 108 details of slotframe length, timeslot timing, and channel hopping 109 pattern are communicated when a node synchronizes to the network. 110 This document describes specific settings for these parameters. 111 Nodes MUST broadcast properly-formed Enhanced Beacons to announce 112 these values. 114 2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 3. Minimal Schedule Configuration 122 In order to form a network, a minimum schedule configuration is 123 required so nodes can advertise the presence of the network, and 124 allow other nodes to join. 126 3.1. Slotframe 128 The slotframe, as defined in [I-D.ietf-6tisch-terminology], is an 129 abstraction of the link layer that defines a collection of time slots 130 of equal length, and which repeats over time. In order to set up a 131 minimal TSCH network, nodes need to be synchronized with the same 132 slotframe configuration so they can communicate. This document 133 recommends the following slotframe configuration. 135 Minimal configuration 137 +------------------------------------+----------------------+ 138 | Property | Value | 139 +------------------------------------+----------------------+ 140 | Number of time slots per Slotframe | Variable | 141 +------------------------------------+----------------------+ 142 | Number of available frequencies | 16 | 143 +------------------------------------+----------------------+ 144 | Number of scheduled cells | 1 (slotOffset 0) | 145 | | (macLinkType NORMAL) | 146 +------------------------------------+----------------------+ 147 | Number of unscheduled cells | The remainder of the | 148 | | slotframe | 149 +------------------------------------+----------------------+ 150 | Number of MAC retransmissions (max)| 3 (4 transmission | 151 | | attempts) | 152 +------------------------------------+----------------------+ 154 The slotframe is composed of a configurable number of time slots. 155 Choosing the number of time slots per slotframe needs to take into 156 account network requirements such as density, bandwidth per node, 157 etc. In the minimal configuration, there is only a single active 158 slot in slotframe, used to transmit/receive both EBs and data link- 159 layer frames. The trade-off between bandwidth, latency and energy 160 consumption can be controlled by choosing a different slotframe 161 length. The active slot MAY be scheduled at the slotOffset 0x00 and 162 channelOffset 0x00 and MUST be announced in the EBs. EBs are sent 163 using this active slot to the link-layer broadcast address (and are 164 therefore not acknowledged). Data packets, as described in 165 Section 3.2, use the same active slot. Per [IEEE802154], data 166 packets sent unicast on this cell are acknowledged by the receiver. 167 The remaining cells in the slotframe are unscheduled, and MAY be used 168 by dynamic scheduling solutions. Details about such dynamic 169 scheduling solution are out of scope of this document. 171 The slotframe length (expressed in number of time slots) is 172 configurable. The length used determines the duty cycle of the 173 network. For example, a network with a 0.99% duty cycle is composed 174 of a slotframe of 101 slots, which includes 1 active slot. The 175 present document RECOMMENDS the use of a default slot duration set to 176 10ms and its corresponding default timeslot timings defined by the 177 [IEEE802154] macTimeslotTemplate. The use of the default 178 macTimeslotTemplate MUST be announced in the EB by using the Timeslot 179 IE containing only the default macTimeslotTemplateId. Other time 180 slot durations MAY be supported and MUST be announced in the EBs. If 181 one uses a timeslot duration different than 10ms, EBs MUST contain 182 the complete TimeSlot IE as described in Section 3.4. This document 183 also recommends to clearly indicate nodes not supporting the default 184 timeslot value. 186 Example schedule with 0.99% duty cycle 188 Chan. +----------+----------+ +----------+ 189 Off.0 | TxRxS/EB | OFF | | OFF | 190 Chan. +----------+----------+ +----------+ 191 Off.1 | | | ... | | 192 +----------+----------+ +----------+ 193 . 194 . 195 . 196 Chan. +----------+----------+ +----------+ 197 Off.15 | | | | | 198 +----------+----------+ +----------+ 200 slotOffset 0 1 100 202 EB: Enhanced Beacon 203 Tx: Transmit 204 Rx: Receive 205 S: Shared 206 OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism) 208 3.2. Cell Options 210 Per [IEEE802154] TSCH, each scheduled cell has an associated bitmap 211 of cell options, called LinkOptions. The scheduled cell in the 212 minimal schedule is configured as a Hard cell 213 [RFC7554][I-D.ietf-6tisch-6top-interface]. Additional available 214 cells MAY be scheduled by a dynamic scheduling solution. The dynamic 215 scheduling solution is out of scope, and this specification does not 216 make any restriction on the LinkOption associated with those 217 dynamically scheduled cells (i.e. they can be hard cells or soft 218 cells). 220 The active cell is assigned the bitmap of cell options below. 221 Because both the "Transmit" and "Receive" bits are set, a node 222 transmits if there is a packet in its queue, listens otherwise. 223 Because the "shared" bit is set, the back-off mechanism defined in 224 [IEEE802154] is used to resolve contention when transmitting. This 225 results in "Slotted Aloha" behavior. The "Timekeeping" flag is set 226 so nodes initialy joining the network can maintin synchronization to 227 the advertising node using that slot. Other time source neighbors 228 are selected using the DODAG structure of the network (detailed 229 below). 231 b0 = Transmit = 1 (set) 233 b1 = Receive = 1 (set) 235 b2 = Shared = 1 (set) 237 b3 = Timekeeping = 1 (set) 239 b4-b7 = Reserved (clear) 241 All remaining cells are unscheduled. In unscheduled cells, the nodes 242 SHOULD keep their radio off. In a memory-efficient implementation, 243 scheduled cells can be represented by a circular linked list. 244 Unscheduled cells SHOULD NOT occupy any memory. 246 3.3. Retransmissions 248 The maximum number of link layer retransmissions is set to 3. For 249 packets which require an acknowledgment, if none is received after a 250 total of 4 attempts, the transmission is considered failed and the 251 link layer MUST notify the upper layer. Packets sent to the 252 broadcast MAC address (including EBs) are not acknowledged and 253 therefore not retransmitted. 255 3.4. Time Slot timing 257 The figure below shows an active timeslot in which a packet is sent 258 from the transmitter node (TX) to the receiver node (RX). A link- 259 layer acknowledgment is sent by the RX node to the TX node when the 260 packet is to be acknowledged. The TsTxOffset duration defines the 261 instant in the timeslot when the first bit after the Start of Frame 262 Delimiter (SFD) of the transmitted packet leaves the radio of the TX 263 node. The radio of the RX node is turned on tsRxWait/2 before that 264 instant, and listens for at least tsRxWait. This allows for a de- 265 synchronization between the two nodes of at most tsRxWait/2 in either 266 direction (early or late). The RX node needs to send the first bit 267 after the SFD of the MAC acknowledgment exactly TsTxAckDelay after 268 the end of the last byte of the received packet. TX's radio has to 269 be turned on tsAckWait/2 before that time, and keep listening for at 270 least tsAckWait. The TX node can perform a Clear Channel Assessment 271 (CCA) if required, this does not interfere with the scope of this 272 draft. As for a minimal configuration, CCA is OPTIONAL. 274 Time slot internal timing diagram 276 /---------------------- Time Slot Duration ----------------------/ 277 | / (5) / | 278 | | / tsRxAckDelay /| | | | 279 |-------------------+--------------+------------------+------+---| 280 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 281 |----+-------+------+--------------+------------------+------+---| 282 |/ tsTxOffset /| | | | | 283 | | | | | | 284 |-------------------+--------------+------------------+------+---| 285 RX | | | | RX frame | |TX ACK| | 286 |----------------+--+--+-----------+------------------+------+---| 287 | | | | | | | | 288 | / (4) / / tsTxAckDelay / | | 289 Start End 290 of of 291 Slot Slot 292 /(1)/ tsCCAOffset 293 /(2)/ tsCCA 294 /(3)/ tsRxTx 295 /(4)/ tsRxWait 296 /(5)/ tsAckWait 298 The timing parameters for the default macTimeslotTemplate 299 (macTimeslotTemplateId = 0) MUST be used when utilizing the default 300 time slot duration. In this case, the Timeslot IE only transports 301 the macTimeslotTemplateId with value 0x00. If a timeslot template 302 other than the default is used, the EB MUST contain a complete 303 TimeSlot IE indicating the timeslot duration and the corresponding 304 timeslot timings. Note however that in case of discrepancy between 305 the values in this document and [IEEE802154], the IEEE standard has 306 precedence. 308 4. Enhanced Beacons Configuration and Content 310 [IEEE802154] does not define how often EBs are sent, nor their 311 contents. EBs MUST NOT in general be used for synchronization. 312 Synchronization is achieved via acknowledgements to normal packet 313 traffic, and keepalives. For a minimal TSCH configuration, a mote 314 SHOULD send an EB every EB_PERIOD. For additional reference see 315 [RFC7554] where different synchronization approaches are summarized. 316 EBs are only authenticated and neither Payload IEs nor the frame 317 payload are encrypted. Refer to the 6TiSCH architecture document 318 [I-D.ietf-6tisch-architecture] for further details on security 319 aspects. 321 EBs MUST be sent as per [IEEE802154] and MUST carry the Information 322 Elements (IEs) listed below. Refer to Section 10.1 for an example of 323 the Information Elements Header Content. 325 Synchronization IE: Contains synchronization information such as 326 ASN and Join Priority. The value of Join Priority is discussed in 327 Section 6.2. 329 TSCH Timeslot IE: Contains the timeslot template identifier. This 330 specification uses the default timeslot template as defined in 331 [IEEE802154]. In the case that a non-default timeslot template is 332 used, the IE Content MUST follow the specification as defined in 333 [IEEE802154] . Refer to Section 10.1 for an illustrative example 334 of non default timeslot template. 336 Channel Hopping IE: Contains the channel hopping template 337 identifier. This specification uses the default channel hopping 338 template, as defined in [IEEE802154].The default sequence for the 339 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 340 3, 9, 10] [IEEE802154]. Note however that in case of discrepancy 341 between the values in this document and [IEEE802154], the IEEE 342 standard specification has preference. 344 Frame and Link IE: Each node MUST indicate the schedule in each EB 345 through a Frame and Link IE. This enables nodes which implement 346 [IEEE802154] to learn the schedule used in the network as they 347 join it. This draft defines the use of a single cell set at 348 channel offset 0x00, slot offset 0x00 and with linkOption 0xE0 349 (TX, RX, SHARED bits set). 351 5. Acknowledgment 353 Link-layer acknowledgment frames are built according to [IEEE802154]. 354 Unicast frames sent to a unicast MAC destination address request an 355 acknowledgment. The sender node MUST set the ACK requested bit in 356 the MAC header. The acknowledgment frame is of type ACK (version 357 0x10). Each acknowledgment contains the following IE: 359 ACK/NACK Time Correction IE: The ACK/NACK time correction IE 360 carries the measured de-synchronization between the sender and the 361 receiver. Refer to Section 10.3 for an example of the Header IE 362 content. The possible values for the Time Synchronization 363 Information and ACK status are described in [IEEE802154]. 365 6. Neighbor information 367 [IEEE802154] does not define how and when each node in the network 368 keeps information about its neighbors. Keeping the following 369 information in the neighbor table is RECOMMENDED: 371 6.1. Neighbor Table 373 The exact format of the neighbor table is implementation-specific, 374 but it SHOULD contain the following information for each neighbor: 376 Neighbor statistics: 378 numTx: number of transmitted packets to that neighbor 380 numTxAck: number of transmitted packets that have been 381 acknowledged by that neighbor 383 numRx: number of received packets from that neighbor 385 The EUI64 of the neighbor. 387 Timestamp of the last frame received from that neighbor. This can 388 be based on the ASN counter or any other time base. It can be 389 used to trigger a keep-alive message. 391 RPL rank of that neighbor. 393 A flag indicating whether this neighbor is a time source neighbor. 395 Connectivity statistics (e.g., RSSI), which can be used to 396 determine the quality of the link. 398 In addition to that information, each node has to be able to compute 399 some RPL Objective Function (OF), taking into account the neighbor 400 and connectivity statistics. An example RPL objective function is 401 the OF Zero as described in [RFC6552] and Section 9.1.1. 403 6.2. Time Source Neighbor Selection 405 Each node MUST select at least one Time Source Neighbor among the 406 nodes in its RPL routing parent set. When a node joins a network, it 407 has no routing information. To select its time source neighbor, it 408 uses the Join Priority field in the EB, as described in [IEEE802154]. 409 The Sync IE contains the ASN and 1 Byte field named Join Priority. 410 The Join Priority of any node MUST be equivalent to the result of the 411 function DAGRank(rank)-1. The Join Priority of the DAG root is also 412 equivalent to DAGRank(rank)-1. According to Section 9.1.1 the 413 DAGRank(rank(0)) = 1 and therefore the DAGRank(rank(0))-1 is 0 which 414 is compliant with the requirement of Join Priority = 0 imposed by 415 [IEEE802154]. A lower value of the Join Priority indicates higher 416 preference to connect to that device. When a node joins the network, 417 it MUST NOT send EBs before having acquired a RPL rank. This avoids 418 routing loops and matches RPL topology with underlying mesh topology. 419 As soon as a node acquires a RPL rank (see [RFC6550] and 420 Section 9.1.1), it SHOULD send Enhanced Beacons including a Sync IE 421 with Join Priority field set to DAGRank(rank)-1, where rank is the 422 node's rank. If a node receives EBs from different nodes with equal 423 Join Priority, the time source neighbor selection SHOULD be assessed 424 by other metrics that can help determine the better connectivity 425 link. Time source neighbor hysteresis SHOULD be used, according to 426 the rules defined in Section 9.2.3. At any time, a node MUST 427 maintain connectivity to at least one time source neighbor. New time 428 source neighbors MUST be chosen among the neighbors in the RPL 429 routing parent set. 431 The decision for a node to select one Time Source Neighbor when 432 multiple EBs are received is implementation-specific. 434 For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT 435 neighbors have been received to select the best Time Source Neighbor. 436 This condition MAY apply unless a second EB is not received after 437 MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting 438 a first Time Source Neighbor. 440 Optionally, some form of hysteresis SHOULD be implemented to avoid 441 frequent changes in time source neighbors. 443 7. Queues and Priorities 445 [IEEE802154] does not define the use of queues to handle upper layer 446 data (either application or control data from upper layers). The use 447 of a single queue with the following rules is RECOMMENDED: 449 When the node is not synchronized to the network, higher layers 450 are not able to insert packets into the queue. 452 Frames generated by the MAC layer (e.g., EBs and ACK) have a 453 higher queuing priority than packets received from a higher layer. 455 Frame types Beacon and Command have a higher queuing priority than 456 frame types Data and ACK. 458 One entry in the queue is reserved at all times for frames of 459 types Beacon or Command frames. 461 8. Security 463 As this document refers to the interaction between Layer 3 and Layer 464 2 protocols, this interaction MUST be secured by L2 security 465 mechanisms as defined by [IEEE802154]. Two security mechanisms are 466 considered, authentication and encryption, authentication applies to 467 all packet content while encryption applies to header IEs and MAC 468 payload. Key distribution is out of scope of this document, but 469 examples include pre-configured keys at the nodes, shared keys among 470 peers or well-known keys. Refer to the 6TiSCH architecture document 471 [I-D.ietf-6tisch-architecture] for further details on key 472 distribution and advanced security aspects. 474 The present document assumes the existence of two cryptographic keys, 475 which can be pre-configured. One of the keys (K1) is used to 476 authenticate EBs. As defined in Section 4, EBs MUST be 477 authenticated, with no payload encryption. This facilitates logical 478 segregation of distinct networks. A second key (K2) is used to 479 authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and 480 respective header IEs, with payload encryption. Depending on 481 security policy, these keys could be the same (i.e., K1=K2). 483 For early interoperability, K1 MAY be set to 36 54 69 53 43 48 20 6D 484 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15"). 486 9. RPL on TSCH 488 Nodes in the network MUST use the RPL routing protocol [RFC6550]. 490 9.1. RPL Objective Function Zero 492 Nodes in the network MUST use the RPL routing protocol [RFC6550] and 493 implement the RPL Objective Function Zero [RFC6552]. 495 9.1.1. Rank computation 497 The rank computation is described at [RFC6552], Section 4.1. A node 498 rank is computed by the following equation: 500 R(N) = R(P) + rank_increment 502 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 504 Where: 506 R(N): Rank of the node. 508 R(P): Rank of the parent obtained as part of the DIO information. 510 rank_increment: The result of a function that determines the rank 511 increment. 513 Rf (rank_factor): A configurable factor that is used to multiply 514 the effect of the link properties in the rank_increment 515 computation. If none is configured, rank_factor of 1 is used. In 516 this specification, a rank_factor of 1 SHOULD be used. 518 Sp (step_of_rank): (strictly positive integer) - an intermediate 519 computation based on the link properties with a certain neighbor, 520 i.e., the Expected Transmission Count (ETX) which provides an 521 average of number of packet transmissions between two nodes. ETX 522 is defined in detail by [decouto03high] and [RFC6551]. The ETX is 523 computed as the inverse of the Packet Delivery Ratio (PDR), this 524 is the number of transmitted packets, divided by the number of 525 acknowledged packets to a certain node (e.g., ETX = numTX/ 526 numTXAck). According to this specification, Sp SHOULD be set to 527 2*ETX to favour shorter routes. 529 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 530 to the step_of_rank of a preferred parent, to allow the selection 531 of an additional feasible successor. If none is configured to the 532 device, then the step_of_rank is not stretched. In this 533 specification, stretch_of_rank SHOULD be set to 0. 535 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 536 constant DEFAULT_MIN_HOP_rank_increment [RFC6550]. 537 DEFAULT_MIN_HOP_rank_increment has a value of 256. 539 DAGRank(rank): Equivalent to the floor of "rank" as defined by 540 [RFC6550]. Specifically, when an Objective Function computes 541 Rank, this is defined as an unsigned integer (i.e., a 16-bit 542 value) Rank quantity. When the Rank is compared, e.g. to 543 determine parent relationships or loop detection, the integer 544 portion of the Rank is used. The integer portion of the Rank is 545 computed by the DAGRank() macro as floor(x) where floor(x) is the 546 function that evaluates to the greatest integer less than or equal 547 to x. DAGRank(rank) = floor(rank/MinHopRankIncrease). Nodes 548 compute its DAGRank(rank) using DAGRank(R(N)). 550 Rank computation scenario 552 +-------+ 553 | P | R(P) 554 | | 555 +-------+ 556 | 557 | 558 +-------+ 559 | N | R(N)=R(P) + rank_increment 560 | | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 561 +-------+ Sp=2*ETX 563 9.1.2. Rank computation Example 565 This section illustrates with an example the use of the Objective 566 Function Zero. Assume the following parameters: 568 Rf = 1 570 Sp = 2* ETX 572 Sr = 0 574 minHopRankIncrease = 256 (default in RPL) 576 ETX=(numTX/numTXAck) 578 r(n) = r(p) + rank_increment 580 rank_increment = (Rf*Sp + Sr) * minHopRankIncrease 582 rank_increment = 512*numTx/numTxAck 584 Rank computation example for 5 hop network where numTx=100 and 585 numTxAck=75 for all nodes 587 +-------+ 588 | 0 | R(minHopRankIncrease) = 256 589 | | DAGRank(R(0)) = 1 590 +-------+ 591 | 592 | 593 +-------+ 594 | 1 | R(1)=R(0) + 683 = 939 595 | | DAGRank(R(1)) = 3 596 +-------+ 597 | 598 | 599 +-------+ 600 | 2 | R(2)=R(1) + 683 = 1622 601 | | DAGRank(R(2)) = 6 602 +-------+ 603 | 604 | 605 +-------+ 606 | 3 | R(3)=R(2)+683=2305 607 | | DAGRank(R(3)) = 9 608 +-------+ 609 | 610 | 611 +-------+ 612 | 4 | R(4)=R(3)+683=2988 613 | | DAGRank(R(4)) = 11 614 +-------+ 615 | 616 | 617 +-------+ 618 | 5 | R(5)=R(4)+683=3671 619 | | DAGRank(R(5)) = 14 620 +-------+ 622 9.2. RPL Configuration 624 In addition to the Objective Function (OF), a minimal configuration 625 for RPL SHOULD indicate the preferred mode of operation (either 626 Storing Mode or Non-Storing Mode) so different RPL implementations 627 can inter-operate. RPL information and hop-by-hop extension headers 628 MUST follow [RFC6553] and [RFC6554] specification. In the case that 629 the packets formed at the LLN need to cross through intermediate 630 routers, these MUST obey to the IP in IP encapsulation requirement 631 specified by the [RFC6282] and [RFC2460]. RPI and RH3 extension 632 headers and inner IP headers MUST be compressed according to 633 [RFC6282]. 635 9.2.1. Mode of Operation 637 For downstream route maintenance, in a minimal configuration, RPL 638 SHOULD be set to operate in the Non-Storing mode as described by 639 [RFC6550] Section 9.7. Storing mode ([RFC6550] Section 9.8) MAY be 640 supported in less constrained devices. 642 9.2.2. Trickle Timer 644 RPL signaling messages such as DIOs are sent using the Trickle 645 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 646 specification, the Trickle Timer MUST be used with the RPL defined 647 default values [RFC6550] (Section 8.3.1). For a description of the 648 Trickle timer operation see Section 4.2 on [RFC6206]. 650 9.2.3. Hysteresis 652 According to [RFC6552], [RFC6719] recommends the use of a boundary 653 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 654 when ranks are compared. When evaluating a parent that belongs to a 655 smaller path cost than current minimum path, the candidate node is 656 selected as new parent only if the difference between the new path 657 and the current path is greater than the defined 658 PARENT_SWITCH_THRESHOLD.Otherwise the node MAY continue to use the 659 current preferred parent. As for [RFC6719] the recommended value 660 for PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used (in the 661 form 128*ETX), the recommendation for this document is to use 662 PARENT_SWITCH_THRESHOLD equal to 768 if the metric being used is 663 2*ETX*minHopRankIncrease, or a proportional value. This mechanism is 664 suited to deal with parent hysteresis in both cases including routing 665 parent and time source neighbor selection. 667 9.2.4. Variable Values 669 The following table presents the RECOMMENDED values for the RPL- 670 related variables defined in the previous section. 672 Recommended variable values 674 +-------------------------+-------+ 675 | Variable | Value | 676 +-------------------------+-------+ 677 | EB_PERIOD | 10s | 678 +-------------------------+-------+ 679 | MAX_EB_DELAY | 180 | 680 +-------------------------+-------+ 681 | NUM_NEIGHBOURS_TO_WAIT | 2 | 682 +-------------------------+-------+ 683 | PARENT_SWITCH_THRESHOLD | 768 | 684 +-------------------------+-------+ 686 10. Examples 688 Several examples are provided to illustrate the content of the 689 packets used by the minimal configuration as proposed by this 690 document. Each example follows the same structure presenting first a 691 schematic header diagram, then the LSB stream of bytes that conform 692 the header and finally a description of each of the IEs the form the 693 packet. The packet formats are specific for the [IEEE802154-2012] 694 revision and MAY vary in future releases of the IEEE standard. In 695 case of differences between the packet content presented in this 696 section and the [IEEE802154-2012], the later has presedence. 698 The MAC header fields are described in a specific order. All field 699 formats in this examples are depicted in the order in which they are 700 transmitted by the PHY, from left to right, where the leftmost bit is 701 transmitted first in time. Bits within each field are numbered from 702 0 (leftmost and least significant) to k - 1 (rightmost and most 703 significant), where the length of the field is k bits. Fields that 704 are longer than a single octet are sent to the PHY in the order from 705 the octet containing the lowest numbered bits to the octet containing 706 the highest numbered bits, hence little endian ordering. 708 10.1. Example 1. Information Elements in EBs 710 Mandatory content for the EB as proposed by this draft. The example 711 uses a slotframe of 101 slots. The following figure represents 712 schematically the Header IE and Payload IE content of an EB. 714 Schematic representation of the IE header in an EB: 716 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Len3 = 6 |Sub ID = 0x1a|0| ASN 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 ASN | Join Priority | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 OFF = 0x0000 |Link OPT = 0x0F| Len7 = 0x00 |ID=0xf |1| 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 REST OF MAC PAYLOAD ... 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Stream of bytes (in little-endian ordering) that derive 739 from the previous schematic header: 741 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 742 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F 00 F8 ... 744 Description of the IE fields in the example: 746 #Header IE Header 747 Len1 = Header IE Length (0) 748 Element ID = 0x7e - termination IE indicating Payload IE coming next 749 Type 0 751 #Payload IE Header (MLME) 752 Len2 = Payload IE Len (26 Bytes) 753 GroupID = 1 MLME (Nested) 754 Type = 1 756 #MLME-SubIE TSCH Synchronization 757 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 758 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 759 Type = Short (0) 760 ASN = Absolute Sequence Number (5 Bytes) 761 Join Priority = 1 Byte 763 #MLME-SubIE TSCH TimeSlot 764 Len4 = Length in bytes of the sub-IE payload (1 Byte) 765 SubID = 0x1c (MLME-SubIE Timeslot) 766 Type = Short (0) 767 TimeSlot template ID = 0x00 (default) 769 #MLME-SubIE Ch. Hopping 770 Len5 = Length in bytes of the sub-IE payload (1 Byte) 771 SubID = 0x09 (MLME-SubIE Ch. Hopping) 772 Type = Long (1) 773 Channel Hopping Sequence ID = 0x00 (default) 775 #MLME-SubIE TSCH Slotframe and Link 776 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 777 SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 778 Type = Short (0) 779 Number of slotframes = 0x01 780 SlotFrame Handle = 0x00 781 SlotFrame Size = 101 slots (0x65) 782 Number of Links = 0x01 783 Timeslot = 0x0000 (2B) 784 Channel Offset = 0x0000 (2B) 785 Link Option = 0x0f (tx,rx,shared,timekeeping) 787 #Payload IE Header (Termination IE) (MAY be omitted) 788 Len7 = Payload IE Len (0) 789 GroupID = 0xf Termination 790 Type = 1 792 10.2. Example 2. Information Elements in EBs not using default 793 timeslot template 795 Using a non-default timeslot template in EBs. Timeslot length set to 796 15ms instead of the 10ms default. 798 Schematic representation of the IE header in an EB: 800 1 2 3 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Len3 = 6 |Sub ID = 0x1a|0| ASN 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 ASN | Join Priority | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 = 2700 | macTsCCA = 128 | macTsTxOffset 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 = 3300 | macTsAckWait = 600 | macTsRxTx 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 = 192 | macTsMaxAck = 2400 | macTsMaxTx 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Stream of bytes (in little-endian ordering) that derive 828 from the previous schematic header: 830 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 831 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 832 00 0A ... 834 Description of the IE fields in the example: 836 #Header IE Header 837 Len1 = Header IE Length (none) 838 Element ID = 0x7e - termination IE indicating Payload IE coming next 839 Type 0 841 #Payload IE Header (MLME) 842 Len2 = Payload IE Len (53 Bytes) 843 GroupID = 1 MLME (Nested) 844 Type = 1 846 #MLME-SubIE TSCH Synchronization 847 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 848 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 849 Type = Short (0) 850 ASN = Absolute Sequence Number (5 Bytes) 851 Join Priority = 1 Byte 853 #MLME-SubIE TSCH TimeSlot 854 Len4 = Lenght in bytes of the sub-IE payload (25 Bytes) 855 SubID = 0x1c (MLME-SubIE Timeslot) 856 Type = Short (0) 857 TimeSlot template ID = 0x01 (non-default) 859 Example timeslot timming using 15ms timeslot. 860 +--------------------------------+------------+ 861 | IEEE802.15.4 TSCH parameter | Value (us) | 862 +--------------------------------+------------+ 863 | tsCCAOffset | 2700 | 864 +--------------------------------+------------+ 865 | tsCCA | 128 | 866 +--------------------------------+------------+ 867 | tsTxOffset | 3180 | 868 +--------------------------------+------------+ 869 | tsRxOffset | 1680 | 870 +--------------------------------+------------+ 871 | tsRxAckDelay | 1200 | 872 +--------------------------------+------------+ 873 | tsTxAckDelay | 1500 | 874 +--------------------------------+------------+ 875 | tsRxWait | 3300 | 876 +--------------------------------+------------+ 877 | tsAckWait | 600 | 878 +--------------------------------+------------+ 879 | tsRxTx | 192 | 880 +--------------------------------+------------+ 881 | tsMaxAck | 2400 | 882 +--------------------------------+------------+ 883 | tsMaxTx | 4256 | 884 +--------------------------------+------------+ 885 | Time Slot duration | 15000 | 886 +--------------------------------+------------+ 888 #MLME-SubIE Ch. Hopping 889 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 890 SubID = 0x09 (MLME-SubIE Ch. Hopping) 891 Type = Long (1) 892 Channel Hopping Sequence ID = 0x00 (default) 894 10.3. Example 3. Information Elements in ACKs 896 Acknowledgement packets carry the ACK/NACK Time Correction IE (Header 897 IE). The following example illustrates the IE format as specified in 898 [IEEE802154-2012]. 900 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 Stream of bytes (in little-endian ordering) that derive 907 from the previous schematic header: 909 02 0F TS#0 TS#1 911 Description of the IE fields in the example: 913 #Header IE Header 914 Len1 = Header IE Length (2 Bytes) 915 Element ID = 0x1e - ACK/NACK Time Correction IE 916 Type 0 918 10.4. Example 4. Auxiliary Security Header 920 The example illustrates content of the Auxiliary Security Header as 921 mandated by this document, if security is enabled. Security Level in 922 the example is set to ENC-MIC-32 (5). 924 1 925 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 |L = 5|M=1|1|1|0|Key Index = IDX| 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Stream of bytes (in LSB format) that derive from the previous 931 schematic header: 933 6D IDX#0 935 Description of the Security Auxiliary Header fields in the example: 937 #Security Control (1 byte) 938 L = Security Level ENC-MIC-32 (5) 939 M = Key Identifier Mode (0x01) 940 Frame Counter Suppression = 1 (omitting Frame Counter field) 941 Frame Counter Size = 1 (construct Nonce from 5 byte ASN) 942 Reserved = 0 944 #Key Identifier (1 byte) 945 Key Index = IDX (deployment-specific KeyIndex parameter that 946 identifies the cryptographic key) 948 11. IANA Considerations 950 This document requests no immediate action by IANA. 952 12. Acknowledgments 954 The authors would like to acknowledge the guidance and input provided 955 by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola 956 Accettura, Malisa Vucinic and for the exhaustive and detailed review 957 of the examples section to Simon Duquennoy, Guillaume Gaillard, 958 Tengfei Chang and Jonathan Munoz. Also our acknowledge to the 6TiSCH 959 Chairs Pascal Thubert and Thomas Watteyne for their guideance and 960 advice. 962 13. References 964 13.1. Normative References 966 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 967 Hysteresis Objective Function", RFC 6719, September 2012. 969 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 970 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 971 September 2011. 973 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 974 Routing Header for Source Routes with the Routing Protocol 975 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 976 2012. 978 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 979 Power and Lossy Networks (RPL) Option for Carrying RPL 980 Information in Data-Plane Datagrams", RFC 6553, March 981 2012. 983 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 984 Protocol for Low-Power and Lossy Networks (RPL)", RFC 985 6552, March 2012. 987 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 988 Barthel, "Routing Metrics Used for Path Calculation in 989 Low-Power and Lossy Networks", RFC 6551, March 2012. 991 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 992 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 993 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 994 Lossy Networks", RFC 6550, March 2012. 996 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 997 "The Trickle Algorithm", RFC 6206, March 2011. 999 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1000 (IPv6) Specification", RFC 2460, December 1998. 1002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1003 Requirement Levels", BCP 14, RFC 2119, March 1997. 1005 [IEEE802154-2012] 1006 IEEE standard for Information Technology, "IEEE standard 1007 for Information Technology, IEEE std. 802.15.4, Part. 1008 15.4: Wireless Medium Access Control (MAC) and Physical 1009 Layer (PHY) Specifications for Low-Rate Wireless Personal 1010 Area Networks, June 2011 as amended by IEEE std. 1011 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1012 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 1013 2012. 1015 [IEEE802154] 1016 IEEE standard for Information Technology, "IEEE standard 1017 for Information Technology, IEEE std. 802.15.4, Part. 1018 15.4: Wireless Medium Access Control (MAC) and Physical 1019 Layer (PHY) Specifications for Low-Rate Wireless Personal 1020 Area Networks". 1022 [decouto03high] 1023 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 1024 High-Throughput Path Metric for Multi-Hop Wireless 1025 Routing", ACM International Conference on Mobile Computing 1026 and Networking (MobiCom) , June 2003. 1028 13.2. Informative References 1030 [RFC7554] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE 1031 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1032 Internet of Things (IoT): Problem Statement", RFC 7554, 1033 May 2015. 1035 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1036 Lossy Networks", RFC 7102, January 2014. 1038 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1039 CBC-MAC (CCM)", RFC 3610, September 2003. 1041 [I-D.ietf-6tisch-architecture] 1042 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1043 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 1044 in progress), May 2015. 1046 [I-D.ietf-6tisch-terminology] 1047 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1048 "Terminology in IPv6 over the TSCH mode of IEEE 1049 802.15.4e", draft-ietf-6tisch-terminology-04 (work in 1050 progress), March 2015. 1052 [I-D.ietf-6tisch-6top-interface] 1053 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 1054 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 1055 6top-interface-03 (work in progress), March 2015. 1057 13.3. External Informative References 1059 [CCM] National Institute of Standards and Technology, 1060 "Recommendation for Block Cipher Modes of Operation: The 1061 CCM Mode for Authentication and Confidentiality. SP 1062 800-38C", May 2004. 1064 [CCM-Star] 1065 Struik, R., "Formal Specification of the CCM* Mode of 1066 Operation, IEEE P802.15 Working Group for Wireless 1067 Personal Area Networks (WPANs).", September 2005. 1069 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1070 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1071 a Standards-Based Low-Power Wireless Development 1072 Environment", Transactions on Emerging Telecommunications 1073 Technologies , August 2012. 1075 Authors' Addresses 1077 Xavier Vilajosana (editor) 1078 Universitat Oberta de Catalunya 1079 156 Rambla Poblenou 1080 Barcelona, Catalonia 08018 1081 Spain 1083 Phone: +34 (646) 633 681 1084 Email: xvilajosana@uoc.edu 1086 Kris Pister 1087 University of California Berkeley 1088 490 Cory Hall 1089 Berkeley, California 94720 1090 USA 1092 Email: pister@eecs.berkeley.edu