idnits 2.17.1 draft-ietf-6tisch-minimal-17.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 a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 28, 2016) is 2700 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: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2015' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-03 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-07 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: Best Current Practice K. Pister 5 Expires: June 1, 2017 University of California Berkeley 6 November 28, 2016 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-17 11 Abstract 13 This document describes a minimal mode of operation for a 6TiSCH 14 Network. It provides IPv6 connectivity over a Non-Broadcast Multi- 15 Access (NBMA) mesh composed of IEEE802.15.4 Timeslotted Channel 16 Hopping (TSCH) links. This minimal mode uses a collection of 17 protocols including the 6LoWPAN framework to enable interoperable 18 IPv6 connectivity over IEEE802.15.4 TSCH with minimal network 19 configuration and infrastructure. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 1, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. IEEE802.15.4 Settings . . . . . . . . . . . . . . . . . . . . 4 59 4.1. TSCH Schedule . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 7 62 4.4. Timeslot Timing . . . . . . . . . . . . . . . . . . . . . 7 63 4.5. Frame Formats . . . . . . . . . . . . . . . . . . . . . . 8 64 4.5.1. IEEE802.15.4 Header . . . . . . . . . . . . . . . . . 8 65 4.5.2. Enhanced Beacon Frame . . . . . . . . . . . . . . . . 9 66 4.5.3. Acknowledgment Frame . . . . . . . . . . . . . . . . 10 67 4.6. Link-Layer Security . . . . . . . . . . . . . . . . . . . 10 68 5. RPL Settings . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Objective Function . . . . . . . . . . . . . . . . . . . 10 70 5.1.1. Rank Computation . . . . . . . . . . . . . . . . . . 11 71 5.1.2. Rank Computation Example . . . . . . . . . . . . . . 12 72 5.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 13 73 5.3. Trickle Timer . . . . . . . . . . . . . . . . . . . . . . 13 74 5.4. Packet Formats . . . . . . . . . . . . . . . . . . . . . 13 75 6. Network Formation and Lifetime . . . . . . . . . . . . . . . 13 76 6.1. Value of the Join Metric Field . . . . . . . . . . . . . 13 77 6.2. Initial Time Source Neighbor Selection . . . . . . . . . 13 78 6.3. When to Start Sending EBs . . . . . . . . . . . . . . . . 14 79 6.4. Time Source Neighbor Selection . . . . . . . . . . . . . 14 80 6.5. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 14 81 7. Implementation Recommendations . . . . . . . . . . . . . . . 14 82 7.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 15 83 7.2. Queues and Priorities . . . . . . . . . . . . . . . . . . 15 84 7.3. Recommended Settings . . . . . . . . . . . . . . . . . . 16 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 10.2. Informative References . . . . . . . . . . . . . . . . . 18 90 10.3. External Informative References . . . . . . . . . . . . 18 91 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 92 A.1. Example: EB with Default Timeslot Template . . . . . . . 19 93 A.2. Example: EB with Custom Timeslot Template . . . . . . . 20 94 A.3. Example: Link-layer Acknowledgment . . . . . . . . . . . 22 95 A.4. Example: Auxiliary Security Header . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast 101 Multi-Access (NBMA) network that is composed of IEEE802.15.4 102 Timeslotted Channel Hopping (TSCH) links. 104 Nodes in an IEEE802.15.4 TSCH network follow a communication 105 schedule. When following this specification, a node learns the 106 schedule of the network when joining, the schedule is static and the 107 same for all nodes. 109 This specification defines operational parameters and procedures for 110 a minimal mode of operation to build a 6TiSCH Network. The 802.15.4 111 TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective 112 Function 0 (OF0) [RFC6552], are used unmodified. Parameters and 113 particular operations of TSCH are specified to guarantee 114 interoperability between nodes in a 6TiSCH Network. RPL is a natural 115 choice for routing on top of IEEE802.15.4 TSCH, and the specifics for 116 interoperable interaction between RPL and TSCH are described. 118 More advanced work is expected in the future to complement the 119 Minimal Configuration with dynamic operations that can adapt the 120 schedule to the needs of the traffic at run time. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 3. Terminology 130 This document uses terminology from [I-D.ietf-6tisch-terminology]. 131 The following concepts are used in this document: 133 SFD: Start of Frame Delimiter. 135 RX: Reception. 137 TX: Transmission. 139 Join Metric: Field in the TSCH Synchronization IE. Number of hops 140 separating the node sending the EB, and the PAN coordinator. 142 4. IEEE802.15.4 Settings 144 An implementation compliant to this specification MUST implement the 145 IEEE802.15.4 [IEEE802154-2015] in "timeslotted channel hopping" 146 (TSCH) mode. 148 The remainder of this section details the RECOMMENDED TSCH settings, 149 which are summarized in Figure 1. A node MAY use different values. 150 Any of the properties marked in the EB column are announced in the 151 Enhanced Beacons (EB) the nodes send [IEEE802154-2015]. Changing 152 their value hence means changing the contents of the EB. 154 In case of discrepancy between the values in this specification and 155 the IEEE802.15.4 specification [IEEE802154-2015], the IEEE standard 156 has precedence. 158 +--------------------------------+------------------------------+---+ 159 | Property | Recommended Setting |EB*| 160 +--------------------------------+------------------------------+---+ 161 | Slotframe Length | Tunable. Trades-off | X | 162 | | bandwidth against energy. | | 163 +--------------------------------+------------------------------+---+ 164 | Number of scheduled cells | 1 (slotOffset 0x00) | X | 165 | (active) | (chOffset 0x00) | | 166 | | (link Option 0x0f) | | 167 | | (macLinkType ADVERTISING) | | 168 +--------------------------------+------------------------------+---+ 169 | Number of unscheduled cells | All remaining cells in the | X | 170 | (off) | slotframe | | 171 +--------------------------------+------------------------------+---+ 172 | Max Number MAC retransmissions | 3 (4 transmission attempts) | | 173 +--------------------------------+------------------------------+---+ 174 | Timeslot template | IEEE802.15.4 default | X | 175 | | (macTimeslotTemplateId=0) | | 176 +--------------------------------+------------------------------+---+ 177 | Enhanced Beacon Period | Tunable. Trades-off join | | 178 | (EB_PERIOD) | time against energy. | | 179 +--------------------------------+------------------------------+---+ 180 | Number used frequencies | IEEE802.15.4 default | X | 181 | (2.4 GHz O-QPSK PHY) | (16) | | 182 +--------------------------------+------------------------------+---+ 183 | Channel Hopping sequence | IEEE802.15.4 default | X | 184 | (2.4 GHz O-QPSK PHY) | [5, 6, 12, 7, 15, 4, 14, 11, | | 185 | | 8, 0, 1, 2, 13, 3, 9, 10] | | 186 +--------------------------------+------------------------------+---+ 187 * an "X" in this column means this property's value is announced in 188 the EB; a new node hence learns it when joining. 190 Figure 1: Recommended IEEE802.15.4 TSCH Settings. 192 4.1. TSCH Schedule 194 The TSCH slotframe is composed of a tunable number of timeslots. The 195 slotframe length (i.e. the number of timeslots it contains) trades 196 off bandwidth for energy consumption. The slotframe length needs to 197 be tuned; the way of tuning it is out of scope of this specification. 198 The slotframe length is announced in the EB. 200 There is only a single scheduled cell in the slotframe. This cell 201 MAY be scheduled at any slotOffset/channelOffset within the 202 slotframe. The location of that cell in the schedule is announced in 203 the EB. The macLinkType of the scheduled cell is ADVERTISING to 204 allow EBs to be sent on it. 206 Figure 2 shows an example of a slotframe of length 101 timeslots, 207 resulting in a radio duty cycle below 0.99%. 209 Chan. +----------+----------+ +----------+ 210 Off.0 | TxRxS/EB | OFF | | OFF | 211 Chan. +----------+----------+ +----------+ 212 Off.1 | OFF | OFF | ... | OFF | 213 +----------+----------+ +----------+ 214 . 215 . 216 . 217 Chan. +----------+----------+ +----------+ 218 Off.15 | OFF | OFF | | OFF | 219 +----------+----------+ +----------+ 221 slotOffset 0 1 100 223 EB: Enhanced Beacon 224 TX: Transmit 225 RX: Receive 226 S: Shared 227 OFF: Unscheduled by this specification 229 Figure 2: Example slotframe of length 101 timeslots. 231 A node MAY use the scheduled cell to transmit/receive all types of 232 link-layer frames. EBs are sent to the link-layer broadcast address, 233 and not acknowledged. Data frames are sent unicast, and acknowledged 234 by the receiving neighbor. 236 All remaining cells in the slotframe are unscheduled. Dynamic 237 scheduling solutions MAY be defined in the future which schedule 238 those cells. One example is the 6top Protocol (6P) 239 [I-D.ietf-6tisch-6top-protocol]. Dynamic scheduling solutions are 240 out of scope of this document. Details about the usage of the non- 241 scheduled cells are out of scope of this document. In particular, 242 this specification does not make any restriction on the Link Option 243 bitmap associated with those dynamically scheduled cells (i.e. they 244 can be "Hard" or "Soft" cells, see [I-D.ietf-6tisch-terminology]). 246 The default values of the Timeslot template and Channel Hopping 247 sequence (defined in [IEEE802154-2015]) SHOULD be used. A node MAY 248 use different values by properly announcing it in its Enhanced 249 Beacon. 251 4.2. Cell Options 253 In the scheduled cell, a node transmits if there is a packet to 254 transmit, listens otherwise (both "TX" and "RX" bits are set). When 255 a node transmits and does not receive a link-layer acknowledgment, it 256 uses a back-off mechanism to resolve possible collisions ("Shared" 257 bit is set). A node joining the network maintains time 258 synchronization to its initial time source neighbor using that cell 259 ("Timekeeping" bit is set). 261 This translates into a Link Option for this cell of value 0x0f: 263 b0 = TX Link = 1 (set) 264 b1 = RX Link = 1 (set) 265 b2 = Shared Link = 1 (set) 266 b3 = Timekeeping = 1 (set) 267 b4 = Priority = 0 (clear) 268 b5-b7 = Reserved = 0 (clear) 270 The scheduled cell is a "Hard cell" [I-D.ietf-6tisch-terminology], 271 i.e. it cannot be moved or relocated by any dynamic scheduling 272 mechanism. 274 4.3. Retransmissions 276 Per Figure 1, the RECOMMENDED maximum number of link-layer 277 retransmissions is 3. This means that, for packets requiring an 278 acknowledgment, if none are received after a total of 4 attempts, the 279 transmission is considered failed and the link layer MUST notify the 280 upper layer. Packets not requiring an acknowledgment (including EBs) 281 are not retransmitted. 283 4.4. Timeslot Timing 285 Figure 3 shows an active timeslot in which a packet is sent from the 286 transmitter node (TX) to the receiver node (RX). A link-layer 287 acknowledgment is sent by the RX node to the TX node when the packet 288 is to be acknowledged. The tsTxOffset duration defines the instant 289 in the timeslot when the first bit after the Start of Frame Delimiter 290 (SFD) of the transmitted packet leaves the radio of the TX node. The 291 radio of the RX node is turned on tsRxWait/2 before that instant, and 292 listens for at least tsRxWait. This allows for a de-synchronization 293 between the two nodes of at most tsRxWait/2 in either direction 294 (early or late). The RX node needs to send the first bit after the 295 SFD of the MAC acknowledgment exactly tsTxAckDelay after the end of 296 the last byte of the received packet. TX's radio has to be turned on 297 tsAckWait/2 before that time, and keep listening for at least 298 tsAckWait. The TX node can perform a Clear Channel Assessment (CCA) 299 if required; this does not interfere with the scope of this document. 300 The use of CCA is OPTIONAL. 302 /---------------------- Timeslot Duration -----------------------/ 303 | / (5) / | 304 | | / tsRxAckDelay /| | | | 305 |-------------------+--------------+------------------+------+---| 306 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 307 |----+-------+------+--------------+------------------+------+---| 308 |/ tsTxOffset /| | | | | 309 | | | | | | 310 |-------------------+--------------+------------------+------+---| 311 RX | | | | RX frame | |TX ACK| | 312 |----------------+--+--+-----------+------------------+------+---| 313 | | | | | | | | 314 | / (4) / / tsTxAckDelay / | | 315 Start End 316 of of 317 Slot Slot 318 /(1)/ tsCCAOffset 319 /(2)/ tsCCA 320 /(3)/ tsRxTx 321 /(4)/ tsRxWait 322 /(5)/ tsAckWait 324 Figure 3: Timeslot internal timing diagram (refer to Figure 6-43 in 325 IEEE802.15.4-2015.) 327 Per Figure 1, the RECOMMENDED timeslot template is the default one 328 defined in [IEEE802154-2015]. 330 4.5. Frame Formats 332 The following sections detail the RECOMMENDED format of link-layer 333 frames of different types. A node MAY use a different formats (bit 334 settings, etc), but MUST implement IEEE802.15.4 TSCH correctly. As 335 long as an implementation follows IEEE802.15.4 TSCH correctly, it is 336 compliant to this specification. 338 4.5.1. IEEE802.15.4 Header 340 The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames 341 SHOULD include the Source Address field and the Destination Address 342 field. The Frame Version field SHOULD be set to 0b10 (Frame Version 343 2). The IEEE802.15.4 header SHOULD include Source Address field and 344 the Destination Address field. The Sequence Number field MAY be 345 elided. 347 The PAN ID Compression bit SHOULD indicate that the Source PAN ID is 348 "Not Present" and the Destination PAN ID is "Present". The value of 349 the PAN ID Compression bit is specified in Table 7-6 of the 350 IEEE802.15.4 2015 specification, and depends on the type of the 351 destination and source link-layer addresses (short, extended, not 352 present). 354 While listening for EBs, a joining node set its own PAN ID to 0xffff 355 in order to meet the filtering rules in the IEEE802.15.4 356 specification [IEEE802154-2015]. 358 The Nonce is formatted according to [IEEE802154-2015]. In the 359 IEEE802.15.4 specification [IEEE802154-2015], nonce generation is 360 described in Section 9.3.2.2, and byte ordering in Section 9.3.1, 361 Annex B.2 and Annex B.2.2. 363 4.5.2. Enhanced Beacon Frame 365 The IEEE802.15.4 specification does not define how often EBs are 366 sent, nor their contents [IEEE802154-2015]. In a minimal TSCH 367 configuration, a node SHOULD send an EB every EB_PERIOD. Tuning 368 EB_PERIOD allows a trade-off between joining time and energy 369 consumption. 371 EBs SHOULD NOT be used for time synchronization. Time 372 synchronization SHOULD only be achieved through normal data traffic 373 and keep-alive frames. [RFC7554] further discusses different time 374 synchronization approaches. 376 EBs MUST be sent as per the IEEE802.15.4 specification and SHOULD 377 carry the Information Elements (IEs) listed below [IEEE802154-2015]. 379 TSCH Synchronization IE: Contains synchronization information such 380 as ASN and Join Metric. The value of the Join Metric field is 381 discussed in Section 6.1. 383 TSCH Timeslot IE: Contains the timeslot template identifier. This 384 template is used to specify the internal timing of the timeslot. 385 This specification RECOMMENDS the default timeslot template. 387 Channel Hopping IE: Contains the channel hopping sequence 388 identifier. This specification RECOMMENDS the default channel 389 hopping sequence. 391 TSCH SlotFrame and Link IE: Enables joining nodes to learn the 392 initial schedule to be used as they join the network. This 393 document RECOMMENDS the use of a single cell. 395 If a node strictly follows the recommended setting from Figure 1, the 396 EB it sends has the exact same contents as an EB it has received when 397 joining, except for the Join Metric field in the TSCH Synchronization 398 IE. 400 4.5.3. Acknowledgment Frame 402 Per [IEEE802154-2015], each acknowledgment contain an ACK/NACK Time 403 Correction IE. 405 4.6. Link-Layer Security 407 All link-layer frames MUST be secured by the link-layer security 408 mechanisms defined in IEEE802.15.4 [IEEE802154-2015]: link-layer 409 authentication and link-layer encryption. Link-layer authentication 410 applies to the entire frame, including the IEEE802.15.4 header. 411 Link-layer encryption applies only to IEEE802.15.4 payload IEs and 412 the IEEE802.15.4 payload. 414 This specification assumes the existence of two cryptographic keys. 415 These keys can be pre-configured, or learned during a key 416 distribution phase. Key distribution is out of scope of this 417 document. 419 Key K1 is used to authenticate EBs. As defined in Section 4.5.2, EBs 420 MUST be authenticated only (no encryption). This facilitates logical 421 segregation of distinct networks. 423 Key K2 is used to authenticate and encrypt DATA and ACKNOWLEDGMENT 424 frames. Depending on the security policy, K1 and K2 could be the 425 same key. 427 For early interoperability testing, value 36 54 69 53 43 48 20 6D 69 428 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1. 430 5. RPL Settings 432 In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be 433 used. 435 5.1. Objective Function 437 If RPL is used, nodes MUST implement the RPL Objective Function Zero 438 (OF0) [RFC6552]. 440 5.1.1. Rank Computation 442 The Rank computation is described at [RFC6552], Section 4.1. A 443 node's Rank (see Figure 4 for an example) is computed by the 444 following equations: 446 R(N) = R(P) + rank_increment 448 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 450 Figure 4 lists the OF0 parameter values that MUST be used if RPL is 451 used. 453 +----------------------+-------------------------------------+ 454 | OF0 Parameters | Value | 455 +----------------------+-------------------------------------+ 456 | Rf | 1 | 457 +----------------------+-------------------------------------+ 458 | Sp | (3*ETX)-2 | 459 +----------------------+-------------------------------------+ 460 | Sr | 0 | 461 +----------------------+-------------------------------------+ 462 | MinHopRankIncrease | DEFAULT_MIN_HOP_RANK_INCREASE (256) | 463 +----------------------+-------------------------------------+ 464 | MINIMUM_STEP_OF_RANK | 1 | 465 +----------------------+-------------------------------------+ 466 | MAXIMUM_STEP_OF_RANK | 9 | 467 +----------------------+-------------------------------------+ 468 | ETX limit to select | 3 | 469 | a parent | | 470 +----------------------+-------------------------------------+ 472 Figure 4: OF0 parameters. 474 The step_of_rank (Sp) uses Expected Transmission Count (ETX) 475 [RFC6551]. ETX is computed using the reception/non-reception of 476 link-layer ACKs. 478 An implementation MUST follow OF0's normalization guidance as 479 discussed in Section 1 and Section 4.1 of [RFC6552]. Sp SHOULD be 480 calculated as (3*ETX)-2. The minimum value of Sp 481 (MINIMUM_STEP_OF_RANK) indicates a good quality link. The maximum 482 value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor quality link. 483 The default value of Sp (DEFAULT_STEP_OF_RANK) indicates an average 484 quality link. Candidate parents with ETX greater than 3 SHOULD NOT 485 be selected. This avoids having ETX values on used links which are 486 larger that the maximum allowed transmission attempts. 488 5.1.2. Rank Computation Example 490 This section illustrates the use of the Objective Function Zero (see 491 Figure 5). We have: 493 rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512 495 +-------+ 496 | 0 | R(minHopRankIncrease) = 256 497 | | DAGRank(R(0)) = 1 498 +-------+ 499 | 500 | 501 +-------+ 502 | 1 | R(1)=R(0) + 512 = 768 503 | | DAGRank(R(1)) = 3 504 +-------+ 505 | 506 | 507 +-------+ 508 | 2 | R(2)=R(1) + 512 = 1280 509 | | DAGRank(R(2)) = 5 510 +-------+ 511 | 512 | 513 +-------+ 514 | 3 | R(3)=R(2) + 512 = 1792 515 | | DAGRank(R(3)) = 7 516 +-------+ 517 | 518 | 519 +-------+ 520 | 4 | R(4)=R(3) + 512 = 2304 521 | | DAGRank(R(4)) = 9 522 +-------+ 523 | 524 | 525 +-------+ 526 | 5 | R(5)=R(4) + 512 = 2816 527 | | DAGRank(R(5)) = 11 528 +-------+ 530 Figure 5: Rank computation example for 5-hop network where numTx=100 531 and numTxAck=75 for all links. 533 5.2. Mode of Operation 535 When RPL is used, nodes MUST support the non-storing ([RFC6550] 536 Section 9.7) mode of operation. The storing ([RFC6550] Section 9.8) 537 mode of operation SHOULD be supported by nodes with enough 538 capabilities. Nodes not supporting RPL MUST join as leaf nodes. 540 5.3. Trickle Timer 542 RPL signaling messages such as DIOs are sent using the Trickle 543 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206] (Section 4.2). For 544 this specification, the Trickle Timer MUST be used with the RPL 545 defined default values [RFC6550] (Section 8.3.1). 547 5.4. Packet Formats 549 RPL information and hop-by-hop extension headers MUST follow 550 [RFC6553] and [RFC6554] specification. In the case the packets 551 formed at the LLN need to cross through intermediate routers, these 552 MUST follow the IP-in-IP encapsulation requirement specified by the 553 [RFC6282] and [RFC2460]. Routing extension headers such as RPI 554 [RFC6550] and SRH [RFC6554], and outer IP headers in case of 555 encapsulation MUST be compressed according to 556 [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch]. 558 6. Network Formation and Lifetime 560 6.1. Value of the Join Metric Field 562 The Join Metric of the TSCH Synchronization IE in the EB MUST be 563 calculated based on the routing metric of the node, normalized to a 564 value between 0 and 255. A lower value of the Join Metric indicates 565 the node sending the EB is topologically "closer" to the root of the 566 network. A lower value of the Join Metric hence indicates higher 567 preference for a joining node to synchronize to that neighbor. In 568 case that the network uses RPL, the Join Metric of any node 569 (including the DAG root) MUST be set to DAGRank(rank)-1. According 570 to Section 5.1.1, DAGRank(rank(0)) = 1. DAGRank(rank(0))-1 = 0 is 571 compliant IEEE802.15.4's requirement of having the root use Join 572 Metric = 0. 574 6.2. Initial Time Source Neighbor Selection 576 When a node joins a network, it may hear EBs sent by different nodes 577 already in the network. The decision of which neighbor to 578 synchronize to (e.g. which neighbor becomes the node's initial time 579 source neighbor) is implementation-specific. 581 For example, after having received the first EB, a node MAY listen 582 for at most MAX_EB_DELAY seconds until it has received EBs from 583 NUM_NEIGHBOURS_TO_WAIT distinct neighbors. When receiving EBs from 584 distinct neighbors, the node MAY use the Join Metric field in each EB 585 to select the initial time source neighbor, as described in 586 IEEE802.15.4 [IEEE802154-2015], Section 6.3.6. 588 6.3. When to Start Sending EBs 590 When a RPL node joins the network, it MUST NOT send EBs before having 591 acquired a RPL Rank to avoid inconsistencies in the time 592 synchronization structure. This applies to other routing protocols 593 with their corresponding routing metrics. As soon as a node acquires 594 routing information (e.g. a RPL Rank, see Section 5.1.1), it SHOULD 595 start sending Enhanced Beacons. 597 6.4. Time Source Neighbor Selection 599 At any time, a node MUST maintain connectivity to at least one time 600 source neighbor. A node's time source neighbor MUST be chosen among 601 the neighbors in its routing parent set. 603 6.5. Hysteresis 605 Per [RFC6552] and [RFC6719], the specification RECOMMENDS the use of 606 a boundary value (PARENT_SWITCH_THRESHOLD) to avoid constant changes 607 of parent when ranks are compared. When evaluating a parent that 608 belongs to a smaller path cost than the current minimum path, the 609 candidate node is selected as new parent only if the difference 610 between the new path and the current path is greater than the defined 611 PARENT_SWITCH_THRESHOLD. Otherwise, the node MAY continue to use the 612 current preferred parent. Per [RFC6719], the PARENT_SWITCH_THRESHOLD 613 SHOULD be set to 192 when ETX metric is used (in the form 128*ETX), 614 the recommendation for this document is to use 615 PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is 616 ((3*ETX)-2)*minHopRankIncrease, or a proportional value. This deals 617 with hysteresis both for routing parent and time source neighbor 618 selection. In case a node has a security association with its 619 parent, including routing parent or time source neighbor, the node 620 SHOULD be allowed to keep the association despite of fluctuations of 621 the rank. 623 7. Implementation Recommendations 624 7.1. Neighbor Table 626 The exact format of the neighbor table is implementation-specific. 627 The RECOMMENDED per-neighbor information is (taken from the [openwsn] 628 implementation): 630 identifier: Identifier(s) of the neighbor (e.g. EUI-64). 632 numTx: Number of link-layer transmission attempts to that 633 neighbor. 635 numTxAck: Number of transmitted link-layer frames that have been 636 link-layer acknowledged by that neighbor. 638 numRx: Number of link-layer frames received from that neighbor. 640 timestamp: When the last frame was received from that neighbor. 641 This can be based on the ASN counter or any other time 642 base. It can be used to trigger a keep-alive message. 644 routing metric: Such as the RPL Rank of that neighbor. 646 time source neighbor: A flag indicating whether this neighbor is a 647 time source neighbor. 649 7.2. Queues and Priorities 651 The IEEE802.15.4 specification [IEEE802154-2015] does not define the 652 use of queues to handle upper layer data (either application or 653 control data from upper layers). The following rules are 654 RECOMMENDED: 656 A node is configured to keep in the queues a configurable number 657 of Upper Layer packets per link (default NUM_UPPERLAYER_PACKETS) 658 for a configurable time that should cover the join process 659 (default MAX_JOIN_TIME). 661 Frames generated by the IEEE802.15.4 layer (including EBs) are 662 queued with a priority higher than frames coming from higher- 663 layers. 665 Frame types BEACON and COMMAND are queued with higher priority 666 than frame types DATA and ACK. 668 One entry in the queue is reserved at all times for frames of 669 types BEACON and COMMAND frames. 671 7.3. Recommended Settings 673 Figure 6 lists RECOMMENDED values for the settings discussed in this 674 specification. 676 +-------------------------+-------------------+ 677 | Parameter | RECOMMENDED Value | 678 +-------------------------+-------------------+ 679 | MAX_EB_DELAY | 180 | 680 +-------------------------+-------------------+ 681 | NUM_NEIGHBOURS_TO_WAIT | 2 | 682 +-------------------------+-------------------+ 683 | PARENT_SWITCH_THRESHOLD | 640 | 684 +-------------------------+-------------------+ 685 | NUM_UPPERLAYER_PACKETS | 1 | 686 +-------------------------+-------------------+ 687 | MAX_JOIN_TIME | 300 | 688 +-------------------------+-------------------+ 690 Figure 6: Recommended Settings. 692 8. IANA Considerations 694 This document requests no immediate action by IANA. 696 9. Acknowledgments 698 The authors acknowledge the guidance and input from Rene Struik, Pat 699 Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa 700 Vucinic, and thank Charles Perkins and Suresh Krishnan for the 701 exhaustive and detailed review. Thanks to Simon Duquennoy, Guillaume 702 Gaillard, Tengfei Chang and Jonathan Munoz for the detailed review of 703 the examples section. Thanks to 6TiSCH co-chairs Pascal Thubert and 704 Thomas Watteyne for their guidance and advice. 706 10. References 708 10.1. Normative References 710 [I-D.ietf-6lo-routing-dispatch] 711 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 712 "6LoWPAN Routing Header", draft-ietf-6lo-routing- 713 dispatch-05 (work in progress), February 2016. 715 [I-D.ietf-6lo-paging-dispatch] 716 Thubert, P. and R. Cragie, "6LoWPAN Paging Dispatch", 717 draft-ietf-6lo-paging-dispatch-05 (work in progress), 718 October 2016. 720 [IEEE802154-2015] 721 IEEE standard for Information Technology, "IEEE Std 722 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 723 Networks (WPANs)", December 2015. 725 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 726 Hysteresis Objective Function", RFC 6719, 727 DOI 10.17487/RFC6719, September 2012, 728 . 730 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 731 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 732 DOI 10.17487/RFC6282, September 2011, 733 . 735 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 736 Routing Header for Source Routes with the Routing Protocol 737 for Low-Power and Lossy Networks (RPL)", RFC 6554, 738 DOI 10.17487/RFC6554, March 2012, 739 . 741 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 742 Power and Lossy Networks (RPL) Option for Carrying RPL 743 Information in Data-Plane Datagrams", RFC 6553, 744 DOI 10.17487/RFC6553, March 2012, 745 . 747 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 748 Protocol for Low-Power and Lossy Networks (RPL)", 749 RFC 6552, DOI 10.17487/RFC6552, March 2012, 750 . 752 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 753 and D. Barthel, "Routing Metrics Used for Path Calculation 754 in Low-Power and Lossy Networks", RFC 6551, 755 DOI 10.17487/RFC6551, March 2012, 756 . 758 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 759 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 760 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 761 Low-Power and Lossy Networks", RFC 6550, 762 DOI 10.17487/RFC6550, March 2012, 763 . 765 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 766 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 767 March 2011, . 769 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 770 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 771 December 1998, . 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 10.2. Informative References 780 [I-D.ietf-6tisch-6top-protocol] 781 Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- 782 ietf-6tisch-6top-protocol-03 (work in progress), October 783 2016. 785 [I-D.ietf-6tisch-terminology] 786 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 787 "Terminology in IPv6 over the TSCH mode of IEEE 788 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 789 progress), March 2016. 791 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 792 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 793 Internet of Things (IoT): Problem Statement", RFC 7554, 794 DOI 10.17487/RFC7554, May 2015, 795 . 797 10.3. External Informative References 799 [openwsn] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 800 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 801 a Standards-Based Low-Power Wireless Development 802 Environment", Transactions on Emerging Telecommunications 803 Technologies , August 2012. 805 Appendix A. Examples 807 This section contains several example packets. Each example contains 808 (1) a schematic header diagram, (2) the corresponding bytestream, (3) 809 a description of each of the IEs that form the packet. Packet 810 formats are specific for the [IEEE802154-2015] revision and may vary 811 in future releases of the IEEE standard. In case of differences 812 between the packet content presented in this section and 813 [IEEE802154-2015], the latter has precedence. 815 The MAC header fields are described in a specific order. All field 816 formats in this examples are depicted in the order in which they are 817 transmitted, from left to right, where the leftmost bit is 818 transmitted first. Bits within each field are numbered from 0 819 (leftmost and least significant) to k - 1 (rightmost and most 820 significant), where the length of the field is k bits. Fields that 821 are longer than a single octet are sent to the PHY in the order from 822 the octet containing the lowest numbered bits to the octet containing 823 the highest numbered bits (little endian). 825 A.1. Example: EB with Default Timeslot Template 827 1 2 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Len3 = 6 |Sub ID = 0x1a|0| ASN 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 ASN | Join Metric | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Bytestream: 849 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 850 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F 852 Description of the IEs: 854 #Header IE Header 855 Len1 = Header IE Length (0) 856 Element ID = 0x7e - termination IE indicating Payload IE 857 coming next 858 Type 0 860 #Payload IE Header (MLME) 861 Len2 = Payload IE Len (26 Bytes) 862 GroupID = 1 MLME (Nested) 863 Type = 1 865 #MLME-SubIE TSCH Synchronization 866 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 867 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 868 Type = Short (0) 869 ASN = Absolute Sequence Number (5 Bytes) 870 Join Metric = 1 Byte 872 #MLME-SubIE TSCH TimeSlot 873 Len4 = Length in bytes of the sub-IE payload (1 Byte) 874 SubID = 0x1c (MLME-SubIE Timeslot) 875 Type = Short (0) 876 TimeSlot template ID = 0x00 (default) 878 #MLME-SubIE Ch. Hopping 879 Len5 = Length in bytes of the sub-IE payload (1 Byte) 880 SubID = 0x09 (MLME-SubIE Ch. Hopping) 881 Type = Long (1) 882 Channel Hopping Sequence ID = 0x00 (default) 884 #MLME-SubIE TSCH Slotframe and Link 885 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 886 SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 887 Type = Short (0) 888 Number of slotframes = 0x01 889 SlotFrame Handle = 0x00 890 SlotFrame Size = 101 slots (0x65) 891 Number of Links = 0x01 892 Timeslot = 0x0000 (2B) 893 Channel Offset = 0x0000 (2B) 894 Link Option = 0x0F (tx,rx,shared,timekeeping) 896 A.2. Example: EB with Custom Timeslot Template 898 Using a custom timeslot template in EBs: setting timeslot length to 899 15ms. 901 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Len3 = 6 |Sub ID = 0x1a|0| ASN 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 ASN | Join Metric | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 = 2700 | macTsCCA = 128 | macTsTxOffset 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 = 3300 | macTsAckWait = 600 | macTsRxTx 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 = 192 | macTsMaxAck = 2400 | macTsMaxTx 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Bytestream: 930 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 931 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 932 00 0A ... 934 Description of the IEs: 936 #Header IE Header 937 Len1 = Header IE Length (none) 938 Element ID = 0x7e - termination IE indicating Payload IE 939 coming next 940 Type 0 942 #Payload IE Header (MLME) 943 Len2 = Payload IE Len (53 Bytes) 944 GroupID = 1 MLME (Nested) 945 Type = 1 947 #MLME-SubIE TSCH Synchronization 948 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 949 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 950 Type = Short (0) 951 ASN = Absolute Sequence Number (5 Bytes) 952 Join Metric = 1 Byte 954 #MLME-SubIE TSCH TimeSlot 955 Len4 = Length in bytes of the sub-IE payload (25 Bytes) 956 SubID = 0x1c (MLME-SubIE Timeslot) 957 Type = Short (0) 958 TimeSlot template ID = 0x01 (non-default) 960 The 15ms timeslot announced: 961 +--------------------------------+------------+ 962 | IEEE802.15.4 TSCH parameter | Value (us) | 963 +--------------------------------+------------+ 964 | tsCCAOffset | 2700 | 965 +--------------------------------+------------+ 966 | tsCCA | 128 | 967 +--------------------------------+------------+ 968 | tsTxOffset | 3180 | 969 +--------------------------------+------------+ 970 | tsRxOffset | 1680 | 971 +--------------------------------+------------+ 972 | tsRxAckDelay | 1200 | 973 +--------------------------------+------------+ 974 | tsTxAckDelay | 1500 | 975 +--------------------------------+------------+ 976 | tsRxWait | 3300 | 977 +--------------------------------+------------+ 978 | tsAckWait | 600 | 979 +--------------------------------+------------+ 980 | tsRxTx | 192 | 981 +--------------------------------+------------+ 982 | tsMaxAck | 2400 | 983 +--------------------------------+------------+ 984 | tsMaxTx | 4256 | 985 +--------------------------------+------------+ 986 | Timeslot duration | 15000 | 987 +--------------------------------+------------+ 989 #MLME-SubIE Ch. Hopping 990 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 991 SubID = 0x09 (MLME-SubIE Ch. Hopping) 992 Type = Long (1) 993 Channel Hopping Sequence ID = 0x00 (default) 995 A.3. Example: Link-layer Acknowledgment 997 Enhanced Acknowledgment packets carry the Time Correction IE (Header 998 IE). 1000 1 2 3 1001 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 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 Bytestream: 1008 02 0F TS#0 TS#1 1010 Description of the IEs: 1012 #Header IE Header 1013 Len1 = Header IE Length (2 Bytes) 1014 Element ID = 0x1e - ACK/NACK Time Correction IE 1015 Type 0 1017 A.4. Example: Auxiliary Security Header 1019 IEEE802.15.4 Auxiliary Security Header with security Level set to 1020 ENC-MIC-32. 1022 1 1023 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 |L = 5|M=1|1|1|0|Key Index = IDX| 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 Bytestream: 1030 6D IDX#0 1032 Security Auxiliary Header fields in the example: 1034 #Security Control (1 byte) 1035 L = Security Level ENC-MIC-32 (5) 1036 M = Key Identifier Mode (0x01) 1037 Frame Counter Suppression = 1 (omitting Frame Counter field) 1038 Frame Counter Size = 1 (construct Nonce from 5 byte ASN) 1039 Reserved = 0 1041 #Key Identifier (1 byte) 1042 Key Index = IDX (deployment-specific KeyIndex parameter that 1043 identifies the cryptographic key) 1045 Authors' Addresses 1047 Xavier Vilajosana (editor) 1048 Universitat Oberta de Catalunya 1049 156 Rambla Poblenou 1050 Barcelona, Catalonia 08018 1051 Spain 1053 Email: xvilajosana@uoc.edu 1055 Kris Pister 1056 University of California Berkeley 1057 512 Cory Hall 1058 Berkeley, California 94720 1059 USA 1061 Email: pister@eecs.berkeley.edu