idnits 2.17.1 draft-ietf-6tisch-minimal-09.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 15, 2015) is 3238 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 1050, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 1055, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 1060, but not defined == Unused Reference: 'RFC7102' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 1029, 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 17, 2015 University of California Berkeley 6 June 15, 2015 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-09 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 17, 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 never 226 set, since the time source neighbor is selected using the DODAG 227 structure of the network (detailed below). 229 b0 = Transmit = 1 (set) 230 b1 = Receive = 1 (set) 232 b2 = Shared = 1 (set) 234 b3 = Timekeeping = 0 (clear) 236 b4-b7 = Reserved (clear) 238 All remaining cells are unscheduled. In unscheduled cells, the nodes 239 SHOULD keep their radio off. In a memory-efficient implementation, 240 scheduled cells can be represented by a circular linked list. 241 Unscheduled cells SHOULD NOT occupy any memory. 243 3.3. Retransmissions 245 The maximum number of link layer retransmissions is set to 3. For 246 packets which require an acknowledgment, if none is received after a 247 total of 4 attempts, the transmission is considered failed and the 248 link layer MUST notify the upper layer. Packets sent to the 249 broadcast MAC address (including EBs) are not acknowledged and 250 therefore not retransmitted. 252 3.4. Time Slot timing 254 The figure below shows an active timeslot in which a packet is sent 255 from the transmitter node (TX) to the receiver node (RX). A link- 256 layer acknowledgment is sent by the RX node to the TX node when the 257 packet is to be acknowledged. The TsTxOffset duration defines the 258 instant in the timeslot when the first bit after the Start of Frame 259 Delimiter (SFD) of the transmitted packet leaves the radio of the TX 260 node. The radio of the RX node is turned on tsRxWait/2 before that 261 instant, and listens for at least tsRxWait. This allows for a de- 262 synchronization between the two nodes of at most tsRxWait/2 in either 263 direction (early or late). The RX node needs to send the first bit 264 after the SFD of the MAC acknowledgment exactly TsTxAckDelay after 265 the end of the last byte of the received packet. TX's radio has to 266 be turned on tsAckWait/2 before that time, and keep listening for at 267 least tsAckWait. The TX node can perform a Clear Channel Assessment 268 (CCA) if required, this does not interfere with the scope of this 269 draft. As for a minimal configuration, CCA is OPTIONAL. 271 Time slot internal timing diagram 273 /---------------------- Time Slot Duration ----------------------/ 274 | / (5) / | 275 | | / tsRxAckDelay /| | | | 276 |-------------------+--------------+------------------+------+---| 277 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 278 |----+-------+------+--------------+------------------+------+---| 279 |/ tsTxOffset /| | | | | 280 | | | | | | 281 |-------------------+--------------+------------------+------+---| 282 RX | | | | RX frame | |TX ACK| | 283 |----------------+--+--+-----------+------------------+------+---| 284 | | | | | | | | 285 | / (4) / / tsTxAckDelay / | | 286 Start End 287 of of 288 Slot Slot 289 /(1)/ tsCCAOffset 290 /(2)/ tsCCA 291 /(3)/ tsRxTx 292 /(4)/ tsRxWait 293 /(5)/ tsAckWait 295 The timing parameters for the default macTimeslotTemplate 296 (macTimeslotTemplateId = 0) MUST be used when utilizing the default 297 time slot duration. In this case, the Timeslot IE only transports 298 the macTimeslotTemplateId with value 0x00. If a timeslot template 299 other than the default is used, the EB MUST contain a complete 300 TimeSlot IE indicating the timeslot duration and the corresponding 301 timeslot timings. Note however that in case of discrepancy between 302 the values in this document and [IEEE802154], the IEEE standard has 303 precedence. 305 4. Enhanced Beacons Configuration and Content 307 [IEEE802154] does not define how often EBs are sent, nor their 308 contents. EBs MUST NOT in general be used for synchronization. 309 Synchronization is achieved via acknowledgements to normal packet 310 traffic, and keepalives. For a minimal TSCH configuration, a mote 311 SHOULD send an EB every EB_PERIOD. For additional reference see 312 [RFC7554] where different synchronization approaches are summarized. 313 EBs are only authenticated and neither Payload IEs nor the frame 314 payload are encrypted. Refer to the 6TiSCH architecture document 315 [I-D.ietf-6tisch-architecture] for further details on security 316 aspects. 318 EBs MUST be sent as per [IEEE802154] and MUST carry the Information 319 Elements (IEs) listed below. Refer to Section 10.1 for an example of 320 the Information Elements Header Content. 322 Synchronization IE: Contains synchronization information such as 323 ASN and Join Priority. The value of Join Priority is discussed in 324 Section 6.2. 326 TSCH Timeslot IE: Contains the timeslot template identifier. This 327 specification uses the default timeslot template as defined in 328 [IEEE802154]. In the case that a non-default timeslot template is 329 used, the IE Content MUST follow the specification as defined in 330 [IEEE802154] . Refer to Section 10.1 for an illustrative example 331 of non default timeslot template. 333 Channel Hopping IE: Contains the channel hopping template 334 identifier. This specification uses the default channel hopping 335 template, as defined in [IEEE802154].The default sequence for the 336 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 337 3, 9, 10] [IEEE802154]. Note however that in case of discrepancy 338 between the values in this document and [IEEE802154], the IEEE 339 standard specification has preference. 341 Frame and Link IE: Each node MUST indicate the schedule in each EB 342 through a Frame and Link IE. This enables nodes which implement 343 [IEEE802154] to learn the schedule used in the network as they 344 join it. This draft defines the use of a single cell set at 345 channel offset 0x00, slot offset 0x00 and with linkOption 0xE0 346 (TX, RX, SHARED bits set). 348 5. Acknowledgment 350 Link-layer acknowledgment frames are built according to [IEEE802154]. 351 Unicast frames sent to a unicast MAC destination address request an 352 acknowledgment. The sender node MUST set the ACK requested bit in 353 the MAC header. The acknowledgment frame is of type ACK (version 354 0x10). Each acknowledgment contains the following IE: 356 ACK/NACK Time Correction IE: The ACK/NACK time correction IE 357 carries the measured de-synchronization between the sender and the 358 receiver. Refer to Section 10.3 for an example of the Header IE 359 content. The possible values for the Time Synchronization 360 Information and ACK status are described in [IEEE802154]. 362 6. Neighbor information 364 [IEEE802154] does not define how and when each node in the network 365 keeps information about its neighbors. Keeping the following 366 information in the neighbor table is RECOMMENDED: 368 6.1. Neighbor Table 370 The exact format of the neighbor table is implementation-specific, 371 but it SHOULD contain the following information for each neighbor: 373 Neighbor statistics: 375 numTx: number of transmitted packets to that neighbor 377 numTxAck: number of transmitted packets that have been 378 acknowledged by that neighbor 380 numRx: number of received packets from that neighbor 382 The EUI64 of the neighbor. 384 Timestamp of the last frame received from that neighbor. This can 385 be based on the ASN counter or any other time base. It can be 386 used to trigger a keep-alive message. 388 RPL rank of that neighbor. 390 A flag indicating whether this neighbor is a time source neighbor. 392 Connectivity statistics (e.g., RSSI), which can be used to 393 determine the quality of the link. 395 In addition to that information, each node has to be able to compute 396 some RPL Objective Function (OF), taking into account the neighbor 397 and connectivity statistics. An example RPL objective function is 398 the OF Zero as described in [RFC6552] and Section 9.1.1. 400 6.2. Time Source Neighbor Selection 402 Each node MUST select at least one Time Source Neighbor among the 403 nodes in its RPL routing parent set. When a node joins a network, it 404 has no routing information. To select its time source neighbor, it 405 uses the Join Priority field in the EB, as described in [IEEE802154]. 406 The Sync IE contains the ASN and 1 Byte field named Join Priority. 407 The Join Priority of any node MUST be equivalent to the result of the 408 function DAGRank(rank) as defined by [RFC6550] and Section 9.1.1. 409 The Join Priority of the DAG root is zero, i.e., EBs sent from the 410 DAG root are sent with Join Priority equal to 0. A lower value of 411 the Join Priority indicates higher preference to connect to that 412 device. When a node joins the network, it MUST NOT send EBs before 413 having acquired a RPL rank. This avoids routing loops and matches 414 RPL topology with underlying mesh topology. As soon as a node 415 acquires a RPL rank (see [RFC6550] and Section 9.1.1), it SHOULD send 416 Enhanced Beacons including a Sync IE with Join Priority field set to 417 DAGRank(rank), where rank is the node's rank. If a node receives EBs 418 from different nodes with equal Join Priority, the time source 419 neighbor selection SHOULD be assessed by other metrics that can help 420 determine the better connectivity link. Time source neighbor 421 hysteresis SHOULD be used, according to the rules defined in 422 Section 9.2.3. If connectivity to the time source neighbor is lost, 423 a new time source neighbor MUST be chosen among the neighbors in the 424 RPL routing parent set. 426 The decision for a node to select one Time Source Neighbor when 427 multiple EBs are received is implementation-specific. 429 For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT 430 neighbors have been received to select the best Time Source Neighbor. 431 This condition MAY apply unless a second EB is not received after 432 MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting 433 a first Time Source Neighbor. 435 Optionally, some form of hysteresis SHOULD be implemented to avoid 436 frequent changes in time source neighbors. 438 7. Queues and Priorities 440 [IEEE802154] does not define the use of queues to handle upper layer 441 data (either application or control data from upper layers). The use 442 of a single queue with the following rules is RECOMMENDED: 444 When the node is not synchronized to the network, higher layers 445 are not able to insert packets into the queue. 447 Frames generated by the MAC layer (e.g., EBs and ACK) have a 448 higher queuing priority than packets received from a higher layer. 450 Frame types Beacon and Command have a higher queuing priority than 451 frame types Data and ACK. 453 One entry in the queue is reserved at all times for frames of 454 types Beacon or Command frames. 456 8. Security 458 As this document refers to the interaction between Layer 3 and Layer 459 2 protocols, this interaction MUST be secured by L2 security 460 mechanisms as defined by [IEEE802154]. Two security mechanisms are 461 considered, authentication and encryption, authentication applies to 462 all packet content while encryption applies to header IEs and MAC 463 payload. Key distribution is out of scope of this document, but 464 examples include pre-configured keys at the nodes, shared keys among 465 peers or well-known keys. Refer to the 6TiSCH architecture document 466 [I-D.ietf-6tisch-architecture] for further details on key 467 distribution and advanced security aspects. 469 The present document assumes the existence of two cryptographic keys, 470 which can be pre-configured. One of the keys (K1) is used to 471 authenticate EBs. As defined in Section 4, EBs MUST be 472 authenticated, with no payload encryption. This facilitates logical 473 segregation of distinct networks. A second key (K2) is used to 474 authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and 475 respective header IEs, with payload encryption. Depending on 476 security policy, these keys could be the same (i.e., K1=K2). 478 For early interoperability, K1 MAY be set to 36 54 69 53 43 48 20 6D 479 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15"). 481 9. RPL on TSCH 483 Nodes in the network MUST use the RPL routing protocol [RFC6550]. 485 9.1. RPL Objective Function Zero 487 Nodes in the network MUST use the RPL routing protocol [RFC6550] and 488 implement the RPL Objective Function Zero [RFC6552]. 490 9.1.1. Rank computation 492 The rank computation is described at [RFC6552], Section 4.1. A node 493 rank is computed by the following equation: 495 R(N) = R(P) + rank_increment 497 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 499 Where: 501 R(N): Rank of the node. 503 R(P): Rank of the parent obtained as part of the DIO information. 505 rank_increment: The result of a function that determines the rank 506 increment. 508 Rf (rank_factor): A configurable factor that is used to multiply 509 the effect of the link properties in the rank_increment 510 computation. If none is configured, rank_factor of 1 is used. In 511 this specification, a rank_factor of 1 MUST be used. 513 Sp (step_of_rank): (strictly positive integer) - an intermediate 514 computation based on the link properties with a certain neighbor, 515 i.e., the Expected Transmission Count (ETX) which provides an 516 average of number of packet transmissions between two nodes. ETX 517 is defined in detail by [decouto03high] and [RFC6551]. The ETX is 518 computed as the inverse of the Packet Delivery Ratio (PDR), this 519 is the number of transmitted packets, divided by the number of 520 acknowledged packets to a certain node (e.g., ETX = numTX/ 521 numTXAck). According to this specification, Sp MUST be set to 522 2*ETX, for the reason of preferring shorter routes. 524 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 525 to the step_of_rank of a preferred parent, to allow the selection 526 of an additional feasible successor. If none is configured to the 527 device, then the step_of_rank is not stretched. In this 528 specification, stretch_of_rank MUST be set to 0. 530 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 531 constant DEFAULT_MIN_HOP_rank_increment [RFC6550]. 532 DEFAULT_MIN_HOP_rank_increment has a value of 256. 534 DAGRank(rank): Equivalent to the floor of (Rf*Sp + Sr) as defined 535 by [RFC6550]. Specifically, when an Objective Function computes 536 Rank, this is defined as an unsigned integer (i.e., a 16-bit 537 value) Rank quantity. When the Rank is compared, e.g. to 538 determine parent relationships or loop detection, the integer 539 portion of the Rank is used. The integer portion of the Rank is 540 computed by the DAGRank() macro as floor(x) where floor(x) is the 541 function that evaluates to the greatest integer less than or equal 542 to x. DAGRank(rank) = floor(rank/MinHopRankIncrease) 544 Rank computation scenario 546 +-------+ 547 | P | R(P) 548 | | 549 +-------+ 550 | 551 | 552 +-------+ 553 | N | R(N)=R(P) + rank_increment 554 | | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 555 +-------+ Sp=2*ETX 557 9.1.2. Rank computation Example 559 This section illustrates with an example the use of the Objective 560 Function Zero. Assume the following parameters: 562 Rf = 1 564 Sp = 2* ETX 566 Sr = 0 568 minHopRankIncrease = 256 (default in RPL) 570 ETX=(numTX/numTXAck) 572 r(n) = r(p) + rank_increment 574 rank_increment = (Rf*Sp + Sr) * minHopRankIncrease 576 rank_increment = 512*numTx/numTxAck 578 Rank computation example for 5 hop network where numTx=100 and 579 numTxAck=75 for all nodes 581 +-------+ 582 | 0 | R(minHopRankIncrease) = 256 583 | | DAGRank(R(0)) = 1 584 +-------+ 585 | 586 | 587 +-------+ 588 | 1 | R(1)=R(0) + 683 = 939 589 | | DAGRank(R(1)) = 3 590 +-------+ 591 | 592 | 593 +-------+ 594 | 2 | R(2)=R(1) + 683 = 1622 595 | | DAGRank(R(2)) = 6 596 +-------+ 597 | 598 | 599 +-------+ 600 | 3 | R(3)=R(2)+683=2305 601 | | DAGRank(R(3)) = 9 602 +-------+ 603 | 604 | 605 +-------+ 606 | 4 | R(4)=R(3)+683=2988 607 | | DAGRank(R(4)) = 11 608 +-------+ 609 | 610 | 611 +-------+ 612 | 5 | R(5)=R(4)+683=3671 613 | | DAGRank(R(5)) = 14 614 +-------+ 616 9.2. RPL Configuration 618 In addition to the Objective Function (OF), a minimal configuration 619 for RPL SHOULD indicate the preferred mode of operation (either 620 Storing Mode or Non-Storing Mode) so different RPL implementations 621 can inter-operate. RPL information and hop-by-hop extension headers 622 MUST follow [RFC6553] and [RFC6554] specification. In the case that 623 the packets formed at the LLN need to cross through intermediate 624 routers, these MUST obey to the IP in IP encapsulation requirement 625 specified by the [RFC6282] and [RFC2460]. RPI and RH3 extension 626 headers and inner IP headers MUST be compressed according to 627 [RFC6282]. 629 9.2.1. Mode of Operation 631 For downstream route maintenance, in a minimal configuration, RPL 632 SHOULD be set to operate in the Non-Storing mode as described by 633 [RFC6550] Section 9.7. Storing mode ([RFC6550] Section 9.8) MAY be 634 supported in less constrained devices. 636 9.2.2. Trickle Timer 638 RPL signaling messages such as DIOs are sent using the Trickle 639 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 640 specification, the Trickle Timer MUST be used with the RPL defined 641 default values [RFC6550] (Section 8.3.1). For a description of the 642 Trickle timer operation see Section 4.2 on [RFC6206]. 644 9.2.3. Hysteresis 646 According to [RFC6552], [RFC6719] recommends the use of a boundary 647 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 648 when ranks are compared. When evaluating a parent that belongs to a 649 smaller path cost than current minimum path, the candidate node is 650 selected as new parent only if the difference between the new path 651 and the current path is greater than the defined 652 PARENT_SWITCH_THRESHOLD.Otherwise the node MAY continue to use the 653 current preferred parent. As for [RFC6719] the recommended value 654 for PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used (in the 655 form 128*ETX), the recommendation for this document is to use 656 PARENT_SWITCH_THRESHOLD equal to 768 as the metric being used is 657 2*ETX*minHopRankIncrease. This is mechanism is suited to deal with 658 parent hysteresis in both cases routing parent and time source 659 neighbor selection. 661 9.2.4. Variable Values 663 The following table presents the RECOMMENDED values for the RPL- 664 related variables defined in the previous section. 666 Recommended variable values 668 +-------------------------+-------+ 669 | Variable | Value | 670 +-------------------------+-------+ 671 | EB_PERIOD | 10s | 672 +-------------------------+-------+ 673 | MAX_EB_DELAY | 180 | 674 +-------------------------+-------+ 675 | NUM_NEIGHBOURS_TO_WAIT | 2 | 676 +-------------------------+-------+ 677 | PARENT_SWITCH_THRESHOLD | 768 | 678 +-------------------------+-------+ 680 10. Examples 682 Several examples are provided to illustrate the content of the 683 packets used by the minimal configuration as proposed by this 684 document. Each example follows the same structure presenting first a 685 schematic header diagram, then the LSB stream of bytes that conform 686 the header and finally a description of each of the IEs the form the 687 packet. The packet formats are specific for the [IEEE802154-2012] 688 revision and MAY vary in future releases of the IEEE standard. In 689 case of differences between the packet content presented in this 690 section and the [IEEE802154-2012], the later has presedence. 692 The MAC header fields are described in a specific order. All field 693 formats in this examples are depicted in the order in which they are 694 transmitted by the PHY, from left to right, where the leftmost bit is 695 transmitted first in time. Bits within each field are numbered from 696 0 (leftmost and least significant) to k - 1 (rightmost and most 697 significant), where the length of the field is k bits. Fields that 698 are longer than a single octet are sent to the PHY in the order from 699 the octet containing the lowest numbered bits to the octet containing 700 the highest numbered bits, hence LSB format. 702 10.1. Example 1. Information Elements in EBs 704 Mandatory content for the EB as proposed by this draft. The example 705 uses a slotframe of 101 slots. The following figure represents 706 schematically the Header IE and Payload IE content of an EB. 708 Schematic representation of the IE header in an EB: 710 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Len3 = 6 |Sub ID = 0x1a|0| ASN 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 ASN | Join Priority | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Len4 = 1 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | #SF = 0x01 | SF ID = 0x01 | SF LEN = 0x65 (101 slots) | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 OFF = 0x0000 |Link OPT = 0x07| Len7 = 0x00 |ID=0xf |1| 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 REST OF MAC PAYLOAD ... 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 Stream of bytes (in LSB format) that derive from the previous 733 schematic header: 735 00 FC 1A 88 06 34 ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 38 00 736 00 33 00 0A 36 01 01 65 00 01 00 00 00 00 07 00 1F ... 738 Description of the IE fields in the example: 740 #Header IE Header 741 Len1 = Header IE Length (0) 742 Element ID = 0x7e - termination IE indicating Payload IE coming next 743 Type 0 745 #Payload IE Header (MLME) 746 Len2 = Payload IE Len (26 Bytes) 747 GroupID = 1 MLME (Nested) 748 Type = 1 750 #MLME-SubIE TSCH Synchronization 751 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 752 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 753 Type = Short (0) 754 ASN = Absolute Sequence Number (5 Bytes) 755 Join Priority = 1 Byte 757 #MLME-SubIE TSCH TimeSlot 758 Len4 = Length in bytes of the sub-IE payload (1 Byte) 759 SubID = 0x1c (MLME-SubIE Timeslot) 760 Type = Short (0) 761 TimeSlot template ID = 0x00 (default) 763 #MLME-SubIE Ch. Hopping 764 Len5 = Length in bytes of the sub-IE payload (1 Byte) 765 SubID = 0x09 (MLME-SubIE Ch. Hopping) 766 Type = Long (1) 767 Channel Hopping Sequence ID = 0x00 (default) 769 #MLME-SubIE TSCH Slotframe and Link 770 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 771 SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 772 Type = Short (0) 773 Number of slotframes = 0x01 774 SlotFrame Handle = 0x00 775 SlotFrame Size = 101 slots (0x65) 776 Number of Links = 0x01 777 Timeslot = 0x0000 (2B) 778 Channel Offset = 0x0000 (2B) 779 Link Option = 0x07 (tx,rx,shared) 781 #Payload IE Header (Termination IE) (MAY be ommitted) 782 Len7 = Payload IE Len (0) 783 GroupID = 0xf Termination 784 Type = 0 786 10.2. Example 2. Information Elements in EBs not using default 787 timeslot template 789 Using a non-default timeslot template in EBs. Timeslot length set to 790 15ms instead of the 10ms default. 792 Schematic representation of the IE header in an EB: 794 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Len3 = 6 |Sub ID = 0x1a|0| ASN 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 ASN | Join Priority | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 = 2700 | macTsCCA = 128 | macTsTxOffset 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 = 3300 | macTsAckWait = 600 | macTsRxTx 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 = 192 | macTsMaxAck = 2400 | macTsMaxTx 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Stream of bytes (in LSB format) that derive from the previous 822 schematic header: 824 00 FC 1A 88 06 34 ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 38 00 33 0A 80 825 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 826 00 0A ... 828 Description of the IE fields in the example: 830 #Header IE Header 831 Len1 = Header IE Length (none) 832 Element ID = 0x7e - termination IE indicating Payload IE coming next 833 Type 0 835 #Payload IE Header (MLME) 836 Len2 = Payload IE Len (53 Bytes) 837 GroupID = 1 MLME (Nested) 838 Type = 1 840 #MLME-SubIE TSCH Synchronization 841 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 842 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 843 Type = Short (0) 844 ASN = Absolute Sequence Number (5 Bytes) 845 Join Priority = 1 Byte 847 #MLME-SubIE TSCH TimeSlot 848 Len4 = Lenght in bytes of the sub-IE payload (25 Bytes) 849 SubID = 0x1c (MLME-SubIE Timeslot) 850 Type = Short (0) 851 TimeSlot template ID = 0x01 (non-default) 853 Example timeslot timming using 15ms timeslot. 854 +--------------------------------+------------+ 855 | IEEE802.15.4 TSCH parameter | Value (us) | 856 +--------------------------------+------------+ 857 | tsCCAOffset | 2700 | 858 +--------------------------------+------------+ 859 | tsCCA | 128 | 860 +--------------------------------+------------+ 861 | tsTxOffset | 3180 | 862 +--------------------------------+------------+ 863 | tsRxOffset | 1680 | 864 +--------------------------------+------------+ 865 | tsRxAckDelay | 1200 | 866 +--------------------------------+------------+ 867 | tsTxAckDelay | 1500 | 868 +--------------------------------+------------+ 869 | tsRxWait | 3300 | 870 +--------------------------------+------------+ 871 | tsAckWait | 600 | 872 +--------------------------------+------------+ 873 | tsRxTx | 192 | 874 +--------------------------------+------------+ 875 | tsMaxAck | 2400 | 876 +--------------------------------+------------+ 877 | tsMaxTx | 4256 | 878 +--------------------------------+------------+ 879 | Time Slot duration | 15000 | 880 +--------------------------------+------------+ 882 #MLME-SubIE Ch. Hopping 883 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 884 SubID = 0x09 (MLME-SubIE Ch. Hopping) 885 Type = Long (1) 886 Channel Hopping Sequence ID = 0x00 (default) 888 10.3. Example 3. Information Elements in ACKs 890 Acknowledgement packets carry the ACK/NACK Time Correction IE (Header 891 IE). The following example illustrates the IE format as specified in 892 [IEEE802154-2012]. 894 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Stream of bytes (in LSB format) that derive from the previous 901 schematic header: 903 40 F0 TS#0 TS#1 905 Description of the IE fields in the example: 907 #Header IE Header 908 Len1 = Header IE Length (2 Bytes) 909 Element ID = 0x1e - ACK/NACK Time Correction IE 910 Type 0 912 10.4. Example 4. Auxiliary Security Header 914 The example illustrates content of the Auxiliary Security Header as 915 mandated by this document, if security is enabled. Security Level in 916 the example is set to ENC-MIC-32 (5). 918 1 919 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 |L = 5|M=1|1|1|0|Key Index = IDX| 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 Stream of bytes (in LSB format) that derive from the previous 925 schematic header: 927 6D IDX#0 929 Description of the Security Auxiliary Header fields in the example: 931 #Security Control (1 byte) 932 L = Security Level ENC-MIC-32 (5) 933 M = Key Identifier Mode (0x01) 934 Frame Counter Suppression = 1 (omitting Frame Counter field) 935 Frame Counter Size = 1 (construct Nonce from 5 byte ASN) 936 Reserved = 0 938 #Key Identifier (1 byte) 939 Key Index = IDX (deployment-specific KeyIndex parameter that 940 identifies the cryptographic key) 942 11. IANA Considerations 944 This document requests no immediate action by IANA. 946 12. Acknowledgments 948 The authors would like to acknowledge the guidance and input provided 949 by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola 950 Accettura, Malisa Vucinic and the 6TiSCH Chairs Pascal Thubert and 951 Thomas Watteyne. 953 13. References 955 13.1. Normative References 957 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 958 Hysteresis Objective Function", RFC 6719, September 2012. 960 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 961 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 962 September 2011. 964 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 965 Routing Header for Source Routes with the Routing Protocol 966 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 967 2012. 969 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 970 Power and Lossy Networks (RPL) Option for Carrying RPL 971 Information in Data-Plane Datagrams", RFC 6553, March 972 2012. 974 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 975 Protocol for Low-Power and Lossy Networks (RPL)", RFC 976 6552, March 2012. 978 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 979 Barthel, "Routing Metrics Used for Path Calculation in 980 Low-Power and Lossy Networks", RFC 6551, March 2012. 982 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 983 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 984 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 985 Lossy Networks", RFC 6550, March 2012. 987 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 988 "The Trickle Algorithm", RFC 6206, March 2011. 990 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 991 (IPv6) Specification", RFC 2460, December 1998. 993 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 994 Requirement Levels", BCP 14, RFC 2119, March 1997. 996 [IEEE802154-2012] 997 IEEE standard for Information Technology, "IEEE standard 998 for Information Technology, IEEE std. 802.15.4, Part. 999 15.4: Wireless Medium Access Control (MAC) and Physical 1000 Layer (PHY) Specifications for Low-Rate Wireless Personal 1001 Area Networks, June 2011 as amended by IEEE std. 1002 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1003 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 1004 2012. 1006 [IEEE802154] 1007 IEEE standard for Information Technology, "IEEE standard 1008 for Information Technology, IEEE std. 802.15.4, Part. 1009 15.4: Wireless Medium Access Control (MAC) and Physical 1010 Layer (PHY) Specifications for Low-Rate Wireless Personal 1011 Area Networks". 1013 [decouto03high] 1014 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 1015 High-Throughput Path Metric for Multi-Hop Wireless 1016 Routing", ACM International Conference on Mobile Computing 1017 and Networking (MobiCom) , June 2003. 1019 13.2. Informative References 1021 [RFC7554] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE 1022 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1023 Internet of Things (IoT): Problem Statement", RFC 7554, 1024 May 2015. 1026 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1027 Lossy Networks", RFC 7102, January 2014. 1029 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1030 CBC-MAC (CCM)", RFC 3610, September 2003. 1032 [I-D.ietf-6tisch-architecture] 1033 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1034 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 1035 in progress), May 2015. 1037 [I-D.ietf-6tisch-terminology] 1038 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1039 "Terminology in IPv6 over the TSCH mode of IEEE 1040 802.15.4e", draft-ietf-6tisch-terminology-04 (work in 1041 progress), March 2015. 1043 [I-D.ietf-6tisch-6top-interface] 1044 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 1045 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 1046 6top-interface-03 (work in progress), March 2015. 1048 13.3. External Informative References 1050 [CCM] National Institute of Standards and Technology, 1051 "Recommendation for Block Cipher Modes of Operation: The 1052 CCM Mode for Authentication and Confidentiality. SP 1053 800-38C", May 2004. 1055 [CCM-Star] 1056 Struik, R., "Formal Specification of the CCM* Mode of 1057 Operation, IEEE P802.15 Working Group for Wireless 1058 Personal Area Networks (WPANs).", September 2005. 1060 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1061 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1062 a Standards-Based Low-Power Wireless Development 1063 Environment", Transactions on Emerging Telecommunications 1064 Technologies , August 2012. 1066 Authors' Addresses 1068 Xavier Vilajosana (editor) 1069 Universitat Oberta de Catalunya 1070 156 Rambla Poblenou 1071 Barcelona, Catalonia 08018 1072 Spain 1074 Phone: +34 (646) 633 681 1075 Email: xvilajosana@uoc.edu 1077 Kris Pister 1078 University of California Berkeley 1079 490 Cory Hall 1080 Berkeley, California 94720 1081 USA 1083 Email: pister@eecs.berkeley.edu