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