idnits 2.17.1 draft-ietf-6tisch-msf-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The RECOMMENDED behavior for sending EBs is to have a node send EBs with a probability of 1/(3(N+1)). The RECOMMENDED behavior for sending DIOs is to use a Trickle timer with rate-limiting. There is no recommendation behavior for sending any other broadcast. However, the traffic portion of all broadcast packets on minimal cell, except EBs, MUST not exceed 1/(3(N+1)). -- The document date (March 11, 2019) is 1872 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 641 -- Looks like a reference, but probably isn't: '3' on line 641 -- Looks like a reference, but probably isn't: '4' on line 641 -- Looks like a reference, but probably isn't: '2' on line 641 -- Looks like a reference, but probably isn't: '0' on line 641 -- Looks like a reference, but probably isn't: '5' on line 641 -- Looks like a reference, but probably isn't: '6' on line 641 -- Looks like a reference, but probably isn't: '7' on line 641 -- Looks like a reference, but probably isn't: '9' on line 641 == Missing Reference: 'TEMPORARY' is mentioned on line 956, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-09 ** Downref: Normative reference to an Informational draft: draft-richardson-6tisch-join-enhanced-beacon (ref. 'I-D.richardson-6tisch-join-enhanced-beacon') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2015' ** Downref: Normative reference to an Informational RFC: RFC 7554 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH T. Chang, Ed. 3 Internet-Draft M. Vucinic 4 Intended status: Standards Track Inria 5 Expires: September 12, 2019 X. Vilajosana 6 Universitat Oberta de Catalunya 7 S. Duquennoy 8 RISE SICS 9 D. Dujovne, Ed. 10 Universidad Diego Portales 11 March 11, 2019 13 6TiSCH Minimal Scheduling Function (MSF) 14 draft-ietf-6tisch-msf-02 16 Abstract 18 This specification defines the 6TiSCH Minimal Scheduling Function 19 (MSF). This Scheduling Function describes both the behavior of a 20 node when joining the network, and how the communication schedule is 21 managed in a distributed fashion. MSF builds upon the 6TiSCH 22 Operation Sublayer Protocol (6P) and the Minimal Security Framework 23 for 6TiSCH. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in 30 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 12, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Interface to the Minimal 6TiSCH Configuration . . . . . . . . 4 68 3. Autonomous Cells . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Step 1 - Choosing Frequency . . . . . . . . . . . . . . . 7 72 4.3. Step 2 - Receiving EBs . . . . . . . . . . . . . . . . . 7 73 4.4. Step 3 - Setting up Autonomous Cells during Join Process 7 74 4.5. Step 4 - Installing Autonomous Cells for each neighbor in 75 neighbor table . . . . . . . . . . . . . . . . . . . . . 8 76 4.6. Step 5 - Acquiring a RPL rank . . . . . . . . . . . . . . 8 77 4.7. Step 6 - Send EBs and DIOs . . . . . . . . . . . . . . . 8 78 4.8. Step 7 - Neighbor Polling . . . . . . . . . . . . . . . . 8 79 4.9. End State . . . . . . . . . . . . . . . . . . . . . . . . 9 80 5. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 9 81 5.1. Adapting to Traffic . . . . . . . . . . . . . . . . . . . 9 82 5.2. Switching Parent . . . . . . . . . . . . . . . . . . . . 11 83 5.3. Handling Schedule Collisions . . . . . . . . . . . . . . 12 84 6. 6P SIGNAL command . . . . . . . . . . . . . . . . . . . . . . 13 85 7. Scheduling Function Identifier . . . . . . . . . . . . . . . 13 86 8. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 13 87 9. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 14 88 10. Rule for Ordering Cells . . . . . . . . . . . . . . . . . . . 14 89 11. Meaning of the Metadata Field . . . . . . . . . . . . . . . . 14 90 12. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 14 91 13. Schedule Inconsistency Handling . . . . . . . . . . . . . . . 15 92 14. MSF Constants . . . . . . . . . . . . . . . . . . . . . . . . 15 93 15. MSF Statistics . . . . . . . . . . . . . . . . . . . . . . . 16 94 16. Security Considerations . . . . . . . . . . . . . . . . . . . 16 95 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 17.1. MSF Scheduling Function Identifiers . . . . . . . . . . 17 98 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 18.1. Normative References . . . . . . . . . . . . . . . . . . 17 100 18.2. Informative References . . . . . . . . . . . . . . . . . 18 101 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 18 102 Appendix B. Example of Implementation of SAX hash function . . . 19 103 Appendix C. Implementation Status and Performance Evaluation . . 20 104 Appendix D. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 21 105 Appendix E. [TEMPORARY] Pending Elements . . . . . . . . . . . . 21 106 E.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 21 107 E.2. Performance Related . . . . . . . . . . . . . . . . . . . 21 108 E.2.1. Handling the case when bandwidth allocation exceeds 109 available capacity . . . . . . . . . . . . . . . . . 21 110 E.2.2. Adapting 6P Timeout . . . . . . . . . . . . . . . . . 22 111 E.3. editorial . . . . . . . . . . . . . . . . . . . . . . . . 22 112 E.3.1. Rules for broadcast frames is out of scope of MSF . . 22 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 115 1. Introduction 117 The 6TiSCH Minimal Scheduling Function (MSF), defined in this 118 specification, is a 6TiSCH Scheduling Function (SF). The role of an 119 SF is entirely defined in [RFC8480]: it complements [RFC8480] by 120 providing the rules of when to add/delete cells in the communication 121 schedule. The SF defined in this document follows that definition, 122 and satisfies all the requirements for an SF listed in Section 4.2 of 123 [RFC8480]. 125 MSF builds on top of the following specifications: the Minimal IPv6 126 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration 127 [RFC8180], the 6TiSCH Operation Sublayer Protocol (6P) [RFC8480], and 128 the Minimal Security Framework for 6TiSCH 129 [I-D.ietf-6tisch-minimal-security]. 131 MSF defines both the behavior of a node when joining the network, and 132 how the communication schedule is managed in a distributed fashion. 133 When a node running MSF boots up, it joins the network by following 134 the 7 steps described in Section 4. The end state of the join 135 process is that the node is synchronized to the network, has mutually 136 authenticated to the network, has identified a preferred routing 137 parent, has scheduled one default managed unicast cell (defined in 138 Section 5.1) to/from its preferred routing parent. After the join 139 process, the node can continuously add/delete/relocate cells, as 140 described in Section 5. It does so for 3 reasons: to match the link- 141 layer resources to the traffic, to handle changing parent, to handle 142 a schedule collision. 144 MSF is designed to operate in a wide range of application domains. 145 It is optimized for applications with regular upstream traffic (from 146 the nodes to the root). Appendix C contains a performance evaluation 147 of MSF. 149 This specification follows the recommended structure of an SF 150 specification in Appendix A of [RFC8480], with the following 151 adaptations: 153 o We have reordered part of the sections, in particular to have the 154 section on the node behavior at boot Section 4 appear early in 155 this specification. 156 o We added sections on the interface to the minimal 6TiSCH 157 configuration Section 2, the use of the SIGNAL command Section 6, 158 the MSF constants Section 14, the MSF statistics Section 15, the 159 performance of MSF Appendix C. 160 o This specification does not include an examples section. 162 2. Interface to the Minimal 6TiSCH Configuration 164 A node implementing MSF SHOULD implement the Minimal 6TiSCH 165 Configuration [RFC8180], which defines the "minimal cell", a single 166 shared cell providing minimal connectivity between the nodes in the 167 network. The MSF implementation provided in this specification is 168 based on the implementation of the Minimal 6TiSCH Configuration. An 169 implementor with full-awareness of the Minimal 6TiSCH Configuration 170 implications MAY implement MSF without it. 172 MSF uses the minimal cell to exchange the following packets: 174 1. Enhanced Beacons (EBs), defined by [IEEE802154-2015]. These are 175 broadcast frames. 176 2. DODAG Information Objects (DIOs), defined by [RFC6550], with 177 broadcast type. Unicast type DIOs SHOULD NOT be sent on minimal 178 cell. 180 Because the minimal cell is SHARED, the back-off algorithm defined in 181 [IEEE802154-2015] is used to resolve collisions. To ensure there is 182 enough bandwidth available on the minimal cell, a node implementing 183 MSF SHOULD enforce the following rules for broadcast frames: 185 1. send EBs on a portion of the minimal cells not exceeding 186 1/(3(N+1)), where N is the number of neighbors of the node. 187 2. send any other broadcast packets on a portion of the minimal 188 cells not exceeding 1/(3(N+1)), where N is the number of 189 neighbors of the node. For example, the broadcast DIO and DIS, 190 IPv6 Neighbor Discovery (ND)[RFC4861] and any other application 191 layer broadcast packets. 193 The RECOMMENDED behavior for sending EBs is to have a node send EBs 194 with a probability of 1/(3(N+1)). The RECOMMENDED behavior for 195 sending DIOs is to use a Trickle timer with rate-limiting. There is 196 no recommendation behavior for sending any other broadcast. However, 197 the traffic portion of all broadcast packets on minimal cell, except 198 EBs, MUST not exceed 1/(3(N+1)). 200 Section 4.3 describes how to evaluate the number of neighbors during 201 the joining process. After the joining process, how to evaluate the 202 number of neighbors is implementation-specific. 204 As detailed in Section 2.2 of [RFC8480], MSF MUST schedule cells from 205 Slotframe 1, while Slotframe 0 is used for traffic defined in the 206 Minimal 6TiSCH Configuration. The length of Slotframe 0 and 207 Slotframe 1 SHOULD be the same value. The default of 208 SLOTFRAME_LENGTH is RECOMMENDED for both Slotframe 0 and Slotframe 1, 209 although any value can be advertised in the EBs. 211 3. Autonomous Cells 213 MSF nodes MUST initialize Slotframe 1 with a set of default cells for 214 unicast communication with their neighbors. These cells are referred 215 to as 'autonomous cells', because they are maintained autonomously by 216 each node. To distinguish from the autonomous cells, the cell 217 scheduled by 6P transaction is defined as 'managed cells'. How to 218 schedule managed cells is detailed in Section 5. For autonomous 219 cells, each node has: 221 o One cell at a [slotOffset,channelOffset] computed as a hash of the 222 node's EUI64 (detailed next). The cell options for this cell are 223 TX=1, RX=1, SHARED=0. 224 o One cell at a [slotOffset,channelOffset] computed as a hash of the 225 EUI64 of the Join Proxy or each neighbor in the IPv6 neighbor 226 table (detailed in Section 4.4 and Section 4.5). The cell options 227 for this cell are TX=1, RX=1, SHARED=1. 229 To compute a [slotOffset,channelOffset] from an EUI64 address, nodes 230 MUST use the hash function SAX [SAX-DASFAA]. The coordinates are 231 computed to distribute the cells across all 16 channel offsets, and 232 all but the first time offsets of Slotframe 1. The first time offset 233 is skipped to avoid colliding with the minimal cell in Slotframe 0. 234 The slot coordinates derived from a given EUI64 address are computed 235 as follows: 237 o slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1) 238 o channelOffset(MAC) = hash(EUI64, 16) 239 For interoperability purpose, an example how the hash function is 240 implemented is detailed in Appendix B. 242 Because of hash collisions, there are cases where the autonomous 243 SHARED and non-SHARED cells are scheduled at the same time offset 244 and/or channel offset. Hash collisions among a set of cells at a 245 given time offset is resolved at run-time as follows: 247 o The SHARED cell with the most packets in the outgoing queue takes 248 precedence. 249 o If all SHARED cells have empty outgoing queues, the non-SHARED 250 cell takes precedence. 252 Both SHARED and non-SHARED autonomous cells are scheduled to transmit 253 unicast packets. The autonomous SHARED cells can only be used to 254 transmit packets to the neighbor whose EUI64 address is used in hash 255 function to create this cell. The autonomous non-SHARED cells can be 256 used to transmit packet to any neighbors. The traffic on the 257 autonomous cells are scheduled as: 259 o The Join Request MUST be sent on a SHARED cell, the 6P Request 260 packet MAY be sent on a SHARED cell. 261 o The Join Response MUST be sent on a non-SHARED cell, the 6P 262 Response packet MAY send on a non-SHARED cell. 264 Throughout the network lifetime, nodes MUST maintain the autonomous 265 cells as follows: 267 o The non-SHARED cell MUST always remain scheduled. 268 o Whenever a new IPv6 neighbor is discovered, add a SHARED cell for 269 it. 270 o Whenever an IPv6 neighbor is removed, remove the SHARED cell that 271 was assigned to it. 272 o 6P CLEAR MUST NOT erase autonomous cells. 274 4. Node Behavior at Boot 276 This section details the behavior the node SHOULD follow from the 277 moment it is switched on, until it has successfully joined the 278 network. Section 4.1 details the start state; Section 4.9 details 279 the end state. The other sections detail the 7 steps of the joining 280 process. We use the term "pledge" and "joined node", as defined in 281 [I-D.ietf-6tisch-minimal-security]. 283 4.1. Start State 285 A node implementing MSF MUST implement the Minimal Security Framework 286 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this 287 means that a pledge, before being switched on, is pre-configured with 288 the Pre-Shared Key (PSK) for joining, as well as any other 289 configuration detailed in [I-D.ietf-6tisch-minimal-security]. 291 4.2. Step 1 - Choosing Frequency 293 When switched on, the pledge SHOULD randomly choose a frequency among 294 the available frequencies, and start listening for EBs on that 295 frequency. 297 4.3. Step 2 - Receiving EBs 299 Upon receiving the first EB, the pledge SHOULD continue listening for 300 additional EBs to learn: 302 1. the number of neighbors N in its vicinity 303 2. which neighbor to choose as a Join Proxy (JP) for the joining 304 process 306 While the exact behavior is implementation-specific, the RECOMMENDED 307 behavior is to follow [RFC8180], and listen until EBs sent by 308 NUM_NEIGHBOURS_TO_WAIT nodes (defined in [RFC8180]) have been 309 received. 311 During this step, the pledge MAY synchronize to any EB it receives 312 from the network it wishes to join. How to decide whether an EB 313 originates from a node from the network it wishes to join is 314 implementation-specific, but MAY involve filtering EBs by the PAN ID 315 field it contains, the presence and contents of the IE defined in 316 [I-D.richardson-6tisch-join-enhanced-beacon], or the key used to 317 authenticate it. 319 The decision of which neighbor to use as a JP is implementation- 320 specific, and discussed in [I-D.ietf-6tisch-minimal-security]. 322 4.4. Step 3 - Setting up Autonomous Cells during Join Process 324 After selected the JP, nodes MUST set up their autonomous SHARED 325 cells, as described in Section 3. A Join Request is sent then by 326 pledge to its JP. The JP forwards the request/response between the 327 JRC and the JP, possibly over multiple hops. When JP received the 328 Join Response from JRC, it sends a Join Response to the pledge, where 329 the pledge learns the keying material used in the network, as well as 330 other configurations, and becomes a "joined node". The Join Request 331 and Response traffics are happened on the autonomous cells, which are 332 scheduled as following: 334 o The Joining Request packet MUST be sent on the autonomous SHARED 335 cell to the JP by the pledge. A retransmition with backoff 336 mechanism will be sent later if collision happens. 337 o The Joining Response packet MUST be sent on the autonomous non- 338 SHARED cell to the pledge by the JP. A retransmition will be sent 339 immediately at next autonomous non-SHARED cell if collision 340 happens. 342 After joined, nodes MUST set up their autonomous non-SHARED cell, as 343 described in Section 3. The root node MUST set up its autonomous 344 non-SHARED cell when it is configured as root. 346 4.5. Step 4 - Installing Autonomous Cells for each neighbor in neighbor 347 table 349 Because it has learnt the link-layer keying material used in the 350 network, the joined node can now decrypt any packets sent by its 351 neighbors. Once a new neighbor is added to the neighbor table, a new 352 autonomous SHARED cell MUST be added to that neighbor. The 353 autonomous SHARED cell MUST be removed if the corresponding neighbor 354 is removed from the neighbor table. How to decide the neighbors to 355 keep in neighbor table is implementation-specific. 357 4.6. Step 5 - Acquiring a RPL rank 359 Per [RFC6550], the joined node receives DIOs, computes its own rank, 360 and selects a preferred parent. 362 4.7. Step 6 - Send EBs and DIOs 364 The node SHOULD start sending EBs and DIOs on the minimal cell, while 365 following the transmit rules for broadcast frames from Section 2. 367 4.8. Step 7 - Neighbor Polling 369 The node SHOULD send some form of keep-alive messages to all its 370 neighbors it has managed unicast cell with. The Keep-Alive (KA) 371 mechanism is detailed in [RFC7554]. It uses the keep-alive messages 372 to its preferred parent to stay synchronized. It MAY use the keep- 373 alive messages to other neighbors to have statistics on link quality. 374 It MAY use the keep-alive messages to its children to ensure the 375 child is still reachable. The RECOMMENDED period for sending keep- 376 alive messages is KA_PERIOD. 378 If the keep-alive message to a child fails at the link layer (i.e. 379 the maximum number of link-layer retries is reached), the node SHOULD 380 declare the child as unreachable. This can happen for example when 381 the child node is switched off. 383 When a neighbor is declared unreachable, the node MUST remove all 384 managed unicast cells with that neighbor from its own schedule. In 385 addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at 386 the link-layer). The node MAY be removed from the neighbor table. 387 If so, the autonomous SHARED cell will be removed following the 388 procedure described in Section 3. 390 4.9. End State 392 For a new node, the end state of the joining process is: 394 o it is synchronized to the network 395 o it is using the link-layer keying material it learned through the 396 secure joining process 397 o it has identified its preferred routing parent 398 o it has one autonomous non-SHARED cell and a set of autonomous 399 SHARED cells to/from its neighbors 400 o it is periodically sending DIOs, potentially serving as a router 401 for other nodes' traffic 402 o it is periodically sending EBs, potentially serving as a JP for 403 new joining nodes 405 5. Rules for Adding/Deleting Cells 407 Once a node has joined the 6TiSCH network, it adds/deletes/relocates 408 cells with its preferred parent for three reasons: 410 o to match the link-layer resources to the traffic between the node 411 and its preferred parent (Section 5.1) 412 o to handle switching preferred parent (Section 5.2) 413 o to handle a schedule collision (Section 5.3) 415 5.1. Adapting to Traffic 417 A node implementing MSF MUST implement the behavior described in this 418 section. 420 In order to handle transient traffic bursts, MSF uses the 421 [IEEE802154-2015] frame pending bit (page 152, Section 7.2.1.3). By 422 setting the bit, a node can transmit a series of packets to a given 423 neighbor in consecutive time offsets. The next paragraphs define how 424 to handle longer-term fluctuations in traffic, using 6P. 426 The goal of MSF is to manage the communication schedule in the 6TiSCH 427 schedule in a distributed manner. For a node, this translates into 428 monitoring the current usage of the cells it has to its preferred 429 parent: 431 o If the node determines that the number of link-layer frames it is 432 attempting to exchange with its preferred parent per unit of time 433 is larger than the capacity offered by the TSCH managed unicast 434 cells it has scheduled with it, the node triggers a 6P Transaction 435 with its preferred parent to add dedicated cells to the TSCH 436 schedule of both nodes. 437 o If the traffic is lower than the capacity, the node triggers a 6P 438 Transaction with its preferred parent to delete dedicated cells 439 from the TSCH schedule of both nodes. 441 From the join process, the node already has a set of autonomous 442 cells, as defined in Section 3. The autonomous cells MUST NOT be 443 removed by 6P, so that there always exists an autonomous cell between 444 a node and its preferred parent, even if no frames are being 445 exchanged between them. Autonomous cells are used indistinguishably 446 together with dedicated cells, for broadcast or unicast traffic with 447 the target neighbor. The procedure to remove autonomous cells is 448 described in Section 3. 450 Adding/removing/relocating cells involves exchanging frames that 451 contain 6P commands. All 6P frames MUST be sent on the autonomous 452 cell or managed cell if the node has. 454 The node MUST maintain the following counters for its preferred 455 parent: 457 NumCellsElapsed : Counts the number of managed unicast cells that 458 have elapsed since the counter was initialized. This counter is 459 initialized at 0. Each time the TSCH state machine indicates 460 that the current cell is a managed unicast cell to the preferred 461 parent, NumCellsElapsed is incremented by exactly 1, regardless 462 of whether the cell is used to transmit/receive a frame. 463 NumCellsUsed: Counts the number of managed unicast cells that have 464 been used. This counter is initialized at 0. NumCellsUsed is 465 incremented by exactly 1 when, during a unicast cell to the 466 preferred parent, either of the following happens: 468 * The node sends a frame to its preferred parent. The counter 469 increments regardless of whether a link-layer acknowledgment 470 was received or not. 471 * The node receives a frame from its preferred parent. The 472 frame MUST be able to decrypt with the key assigned during 473 joining process. 475 Implementors MAY choose to create the same counters for each 476 neighbor, and add them as additional statistics in the neighbor 477 table. 479 The counters are used as follows: 481 1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when 482 the node boots. 483 2. After End State defined in Section 4.9, if there is no managed 484 unicast cell to the preferred parent, trigger 6P to add a signle 485 cell to it. 486 3. When the value of NumCellsElapsed reaches MAX_NUMCELLS: 488 * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a 489 single cell to the preferred parent 490 * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a 491 single cell to the preferred parent 492 * Reset both NumCellsElapsed and NumCellsUsed to 0 and go to 493 step 2. 495 To have the counters working, at least one unicast cell need to be 496 maintained all the time and never be removed. 498 The reason why the counter only counts the managed unicast cell, NOT 499 including the autonomous SHARED cell is to avoid the effects of 500 collision. If the autonomous SHARED cell is counted as well, 501 NumCellsUsed > LIM_NUMCELLSUSED_HIGH could be caused by the collision 502 on the cell. A 6P add request on the autonomous SHARED cell will 503 make the collision even worse. 505 Both NumCellsElapsed and NumCellsUsed counters can be used to cell 506 with cell option TX=1 or RX=1. With the rules defined above, the 507 cell to add or remove can be transmitting cell or receiving cell 508 according to which type of cell the two counters are used for. 510 Similar to Join Request and Response, the 6P Request is scheduled to 511 send on the autonomous SHARED cell to the node's parent. The 6P 512 Response is scheduled to send back on the autonomous non-SHARED cell 513 to the node. 515 5.2. Switching Parent 517 A node implementing MSF SHOULD implement the behavior described in 518 this section. 520 Part of its normal operation, the RPL routing protocol can have a 521 node switch preferred parents. The procedure for switching from the 522 old preferred parent to the new preferred parent is: 524 1. if the new parent is not in the neighbor table, the autonomous 525 SHARED cell MUST be added as defined in Section 3 526 2. the node counts the number of managed unicast cell cells it has 527 per slotframe to the old preferred parent 528 3. the node triggers one or more 6P ADD commands to schedule the 529 same number of unicast cells to the new preferred parent 530 4. when that successfully completes, the node issues a 6P CLEAR 531 command to its old preferred parent 533 5.3. Handling Schedule Collisions 535 A node implementing MSF SHOULD implement the behavior described in 536 this section. The "MUST" statements in this section hence only apply 537 if the node implements schedule collision handling. 539 Since scheduling is entirely distributed, there is a non-zero 540 probability that two pairs of nearby neighbor nodes schedule a 541 managed unicast cell at the same [slotOffset,channelOffset] location 542 in the TSCH schedule. In that case, data exchanged by the two pairs 543 may collide on that cell. We call this case a "schedule collision". 545 The node MUST maintain the following counters for each managed 546 unicast cell to its preferred parent: 548 NumTx: Counts the number of transmission attempts on that cell. 549 Each time the node attempts to transmit a frame on that cell, 550 NumTx is incremented by exactly 1. 551 NumTxAck: Counts the number of successful transmission attempts on 552 that cell. Each time the node receives an acknowledgment for a 553 transmission attempt, NumTxAck is incremented by exactly 1. 555 Implementors MAY choose to maintain the same counters for each 556 managed unicast cell in the schedule. 558 Since both NumTx and NumTxAck are initialized to 0, we necessarily 559 have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the 560 ratio NumTxAck/NumTx; and represent it as a percentage. A cell with 561 PDR=50% means that half of the frames transmitted are not 562 acknowledged (and need to be retransmitted). 564 Each time the node switches preferred parent (or during the join 565 process when the node selects a preferred parent for the first time), 566 both NumTx and NumTxAck MUST be reset to 0. They increment over 567 time, as the schedule is executed and the node sends frames to its 568 preferred parent. When NumTx reaches 256, both NumTx and NumTxAck 569 MUST be divided by 2. That is, for example, from NumTx=256 and 570 NumTxAck=128, they become NumTx=128 and NumTxAck=64. This operation 571 does not change the value of the PDR, but allows the counters to keep 572 incrementing. 574 The key for detecting a schedule collision is that, if a node has 575 several cells to the same preferred parent, all cells should exhibit 576 the same PDR. A cell which exhibits a PDR significantly lower than 577 the others indicates than there are collisions on that cell. 579 Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following 580 steps: 582 1. It computes, for each managed unicast cell with its preferred 583 parent (not for the autonomous cell), that cell's PDR. 584 2. Any cell that hasn't yet had NumTx divided by 2 since it was last 585 reset is skipped in steps 3 and 4. This avoids triggering cell 586 relocation when the values of NumTx and NumTxAck are not 587 statistically significant yet. 588 3. It identifies the cell with the highest PDR. 589 4. For each other cell, it compares its PDR against that of the cell 590 with the highest PDR. If it's less than RELOCATE_PDRTHRES, it 591 triggers the relocation of that cell using a 6P RELOCATE command. 593 6. 6P SIGNAL command 595 The 6P SIGNAL command is not used by MSF. 597 7. Scheduling Function Identifier 599 The Scheduling Function Identifier (SFID) of MSF is 600 IANA_6TISCH_SFID_MSF. 602 8. Rules for CellList 604 MSF uses 2-step 6P Transactions exclusively. 6P Transactions are 605 only initiated by a node towards it preferred parent. As a result, 606 the cells to put in the CellList of a 6P ADD command, and in the 607 candidate CellList of a RELOCATE command, are chosen by the node 608 initiating the 6P Transaction. In both cases, the same rules apply: 610 o The CellList SHOULD contain 5 or more cells. 611 o Each cell in the CellList MUST have a different slotOffset value. 612 o For each cell in the CellList, the node MUST NOT have any 613 scheduled cell on the same slotOffset. 614 o The slotOffset value of any cell in the CellList MUST NOT be the 615 same as the slotOffset of the minimal cell (slotOffset=0). 616 o The slotOffset of a cell in the CellList SHOULD be randomly and 617 uniformly chosen among all the slotOffset values that satisfy the 618 restrictions above. 620 o The channelOffset of a cell in the CellList SHOULD be randomly and 621 uniformly chosen in [0..numFrequencies], where numFrequencies 622 represents the number of frequencies a node can communicate on. 624 9. 6P Timeout Value 626 The 6P Timeout is not a constant value. It is calculated as 627 (1/(C+1))*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR, where: 629 o C represents the number of cells per second scheduled to that 630 neighbor 631 o PDR represents the average PDR of those cells 632 o SIXP_TIMEOUT_SEC_FACTOR is a security factor, a constant 634 10. Rule for Ordering Cells 636 Cells are ordered slotOffset first, channelOffset second. 638 The following sequence is correctly ordered (each element represents 639 the [slottOffset,channelOffset] of a cell in the schedule): 641 [1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9] 643 11. Meaning of the Metadata Field 645 The Metadata field is not used by MSF. 647 12. 6P Error Handling 649 Section 6.2.4 of [RFC8480] lists the 6P Return Codes. Figure 1 lists 650 the same error codes, and the behavior a node implementing MSF SHOULD 651 follow. 653 +-----------------+----------------------+ 654 | Code | RECOMMENDED behavior | 655 +-----------------+----------------------+ 656 | RC_SUCCESS | nothing | 657 | RC_EOL | nothing | 658 | RC_ERR | quarantine | 659 | RC_RESET | quarantine | 660 | RC_ERR_VERSION | quarantine | 661 | RC_ERR_SFID | quarantine | 662 | RC_ERR_SEQNUM | clear | 663 | RC_ERR_CELLLIST | clear | 664 | RC_ERR_BUSY | waitretry | 665 | RC_ERR_LOCKED | waitretry | 666 +-----------------+----------------------+ 668 Figure 1: Recommended behavior for each 6P Error Code. 670 The meaning of each behavior from Figure 1 is: 672 nothing: Indicates that this Return Code is not an error. No error 673 handling behavior is triggered. 674 clear: Abort the 6P Transaction. Issue a 6P CLEAR command to that 675 neighbor (this command may fail at the link layer). Remove all 676 cells scheduled with that neighbor from the local schedule. Keep 677 that node in the neighbor and routing tables. 678 quarantine: Same behavior as for "clear". In addition, remove the 679 node from the neighbor and routing tables. Place the node's 680 identifier in a quarantine list for QUARANTINE_DURATION. When in 681 quarantine, drop all frames received from that node. 682 waitretry: Abort the 6P Transaction. Wait for a duration randomly 683 and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX]. 684 Retry the same transaction. 686 13. Schedule Inconsistency Handling 688 The behavior when schedule inconsistency is detected is explained in 689 Figure 1, for 6P Return Code RC_ERR_SEQNUM. 691 14. MSF Constants 693 Figure 2 lists MSF Constants and their RECOMMENDED values. 695 +------------------------------+-------------------+ 696 | Name | RECOMMENDED value | 697 +------------------------------+-------------------+ 698 | KA_PERIOD | 10 s | 699 | LIM_NUMCELLSUSED_HIGH | 75 % | 700 | LIM_NUMCELLSUSED_LOW | 25 % | 701 | HOUSEKEEPINGCOLLISION_PERIOD | 1 min | 702 | RELOCATE_PDRTHRES | 50 % | 703 | SIXP_TIMEOUT_SEC_FACTOR | 3 x | 704 | SLOTFRAME_LENGTH | 101 slots | 705 | QUARANTINE_DURATION | 5 min | 706 | WAITDURATION_MIN | 30 s | 707 | WAITDURATION_MAX | 60 s | 708 +------------------------------+-------------------+ 710 Figure 2: MSF Constants and their RECOMMENDED values. 712 15. MSF Statistics 714 Figure 3 lists MSF Statistics and their RECOMMENDED width. 716 +-----------------+-------------------+ 717 | Name | RECOMMENDED width | 718 +-----------------+-------------------+ 719 | NumCellsElapsed | 1 byte | 720 | NumCellsUsed | 1 byte | 721 | NumTx | 1 byte | 722 | NumTxAck | 1 byte | 723 +-----------------+-------------------+ 725 Figure 3: MSF Statistics and their RECOMMENDED width. 727 16. Security Considerations 729 MSF defines a series of "rules" for the node to follow. It triggers 730 several actions, that are carried out by the protocols defined in the 731 following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 732 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation 733 Sublayer Protocol (6P) [RFC8480], and the Minimal Security Framework 734 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF 735 does not define a new protocol or packet format. 737 MSF relies entirely on the security mechanisms defined in the 738 specifications listed above. 740 17. IANA Considerations 742 17.1. MSF Scheduling Function Identifiers 744 This document adds the following number to the "6P Scheduling 745 Function Identifiers" sub-registry, part of the "IPv6 over the TSCH 746 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by 747 [RFC8480]: 749 +----------------------+-----------------------------+-------------+ 750 | SFID | Name | Reference | 751 +----------------------+-----------------------------+-------------+ 752 | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX | 753 | | (MSF) | (NOTE:this) | 754 +----------------------+-----------------------------+-------------+ 756 Figure 4: IETF IE Subtype '6P'. 758 18. References 760 18.1. Normative References 762 [I-D.ietf-6tisch-minimal-security] 763 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 764 "Minimal Security Framework for 6TiSCH", draft-ietf- 765 6tisch-minimal-security-09 (work in progress), November 766 2018. 768 [I-D.richardson-6tisch-join-enhanced-beacon] 769 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 770 Element encapsulation of 6tisch Join Information", draft- 771 richardson-6tisch-join-enhanced-beacon-03 (work in 772 progress), January 2018. 774 [IEEE802154-2015] 775 IEEE standard for Information Technology, "IEEE Std 776 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 777 Networks (WPANs)", December 2015. 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, 781 DOI 10.17487/RFC2119, March 1997, 782 . 784 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 785 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 786 DOI 10.17487/RFC4861, September 2007, 787 . 789 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 790 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 791 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 792 Low-Power and Lossy Networks", RFC 6550, 793 DOI 10.17487/RFC6550, March 2012, 794 . 796 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 797 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 798 Internet of Things (IoT): Problem Statement", RFC 7554, 799 DOI 10.17487/RFC7554, May 2015, 800 . 802 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 803 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 804 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 805 May 2017, . 807 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 808 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 809 DOI 10.17487/RFC8480, November 2018, 810 . 812 18.2. Informative References 814 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 815 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 816 a Standards-Based Low-Power Wireless Development 817 Environment", Transactions on Emerging Telecommunications 818 Technologies , August 2012. 820 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 821 Code: The Implementation Status Section", RFC 6982, 822 DOI 10.17487/RFC6982, July 2013, 823 . 825 [SAX-DASFAA] 826 Ramakrishna, M. and J. Zobel, "Performance in Practice of 827 String Hashing Functions", DASFAA , 1997. 829 Appendix A. Contributors 831 Beshr Al Nahas (Chalmers University, beshr@chalmers.se) and Olaf 832 Landsiedel (Chalmers University, olafl@chalmers.se) contributed to 833 the design and evaluation of autonomous unicast cells. 835 Appendix B. Example of Implementation of SAX hash function 837 For the consideration of interoperability, this section provides an 838 example of implemention SAX hash function [SAX-DASFAA]. The input 839 parameters of the function are: 841 o T, which is the hashing table length 842 o c, which is the characters of string s, to be hashed 844 In MSF, the T is replaced by the length slotframe 1. String s is 845 replaced by the mote EUI64 address. The characters of the string c0, 846 c1, ..., c7 are the 8 bytes of EUI64 address. 848 The SAX hash function requires shift operation which is defined as 849 follow: 851 o L_shift(v,b), which refers to left shift variable v by b bits 852 o R_shift(v,b), which refers to right shift variable v by b bits 854 The steps to calculate the hash value of SAX hash function are: 856 1. initialize variable h to h0 and variable i to 0, where h is the 857 intermediate hash value and i is the index of the bytes of EUI64 858 address 859 2. sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and ci 860 3. calculate the result of exclusive or bewteen the sum value in 861 Step 2 and h 862 4. modulo the result of Step 3 by T 863 5. assign the result of Step 4 to h 864 6. increase i by 1 865 7. repeat Step2 to Step 6 until i reaches to 8 866 8. assign the result of Step 5 to h 868 The value of variable h the hash value of SAX hash function. 870 For interoperability purpose, the values of h0, l_bit and r_bit in 871 Step 1 and 2 are configured as: 873 o h0 = 0 874 o l_bit = 0 875 o r_bit = 1 877 The appropriate values of l_bit and r_bit could vary depending on the 878 the set of motes' EUI64 address. How to find those values is out of 879 the scope of this specification. 881 Appendix C. Implementation Status and Performance Evaluation 883 This section records the status of known implementations of the 884 protocol defined by this specification at the time of posting of this 885 Internet-Draft, and is based on a proposal described in [RFC6982]. 886 The description of implementations in this section is intended to 887 assist the IETF in its decision processes in progressing drafts to 888 RFCs. Please note that the listing of any individual implementation 889 here does not imply endorsement by the IETF. Furthermore, no effort 890 has been spent to verify the information presented here that was 891 supplied by IETF contributors. This is not intended as, and must not 892 be construed to be, a catalog of available implementations or their 893 features. Readers are advised to note that other implementations may 894 exist. 896 According to [RFC6982], "this will allow reviewers and working groups 897 to assign due consideration to documents that have the benefit of 898 running code, which may serve as evidence of valuable experimentation 899 and feedback that have made the implemented protocols more mature. 900 It is up to the individual working groups to use this information as 901 they see fit". 903 OpenWSN MSF is being implemented in the OpenWSN project [OpenWSN] 904 under a BSD open-source license. The code is open-source and 905 available in two parts: 907 * the firmware, running on embedded hardware: https://github.com/ 908 openwsn-berkeley/openwsn-fw 909 * the software, running on the PC that acts as the LBR of the 910 network: https://github.com/openwsn-berkeley/openvisualizer 912 At the time of writing, OpenWSN implements MSF as specified in 913 this document. The code is tested on the OpenTestbed deployed at 914 Inria in Paris. The testbed consist of 40 OpenMote-B nodes. The 915 experiment is run for 3 hours. With the first 12 minutes of the 916 experiment, all nodes synchronize and securely join the network. 917 Once joined, each node sends a DAO every 1 min to the DAG root. 918 We use the DAO's sequence number to compute end-to-end 919 reliability. After 3 hours, the nodes have generated 7114 DAOs, 920 with an overall end-end reliability of 99.47%. 921 The OpenWSN implementation is work-in-progress, and we expect the 922 final release to yield 100% end-to-end reliability. 923 6TiSCH simulator The 6TiSCH simulator is a Python-based high-level 924 simulator on which MSF is being implemented. More information at 925 https://bitbucket.org/6tisch/simulator/. 927 Appendix D. [TEMPORARY] Changelog 929 o draft-ietf-6tisch-msf-02 931 * Resolve the issues in Pending Elements section. Using 932 autonomous SHARED and non-SHARED cells. Overall revised the 933 specification. 934 o draft-ietf-6tisch-msf-01 936 * Added a section on pending elements. 937 o draft-ietf-6tisch-msf-00 939 * Re-publication after WG adoption. No changes. 940 o draft-chang-6tisch-msf-02 942 * Added autonomous cell. 943 o draft-chang-6tisch-msf-01 945 * When neighbor is unreachable, sending a CLEAR command was a 946 MUST, now a MAY. 947 * Fixing 6P Timeout calculation. 948 * Clearer text for "Handling Schedule Collisions" section. 949 * Typos. 950 * Input from Yasuyuki Tanaka's review (https://www.ietf.org/mail- 951 archive/web/6tisch/current/msg05723.html). 952 o draft-chang-6tisch-msf-00 954 * Initial submission. 956 Appendix E. [TEMPORARY] Pending Elements 958 E.1. Introduction 960 This section contains lessons learnt and suggestions from simulating 961 and experimenting with draft-ietf-6tisch-msf-00. This section is 962 temporary and will be removed once these suggestions are integrated 963 or abandonned. 965 E.2. Performance Related 967 E.2.1. Handling the case when bandwidth allocation exceeds available 968 capacity 970 When node A initializes a 6top ADD transaction to node B, but node B 971 does NOT have enough bandwidth to allocate. What can node B do to 972 indicate this case in its 6top response, and how should node A handle 973 the packet after receiving the response? Related discussion: 974 https://www.ietf.org/mail-archive/web/6tisch/current/msg06095.html 976 [TOD BE DISCUSSED. According to 6top RFC8480, SUCCESS return code 977 will be in the 6top response with an empty cellList possibly. For 978 this case, I don't have a prefect solution. One solution I am using 979 is marking the node B as 'no_resource', then updating it's routing 980 table and filtering out the neighbor marked as 'no_resource'. 981 However, this is a layer-violation design.] 983 E.2.2. Adapting 6P Timeout 985 After 6P TIMEOUT, the next 6P transaction should be configured using 986 a larger TIMEOUT. Issues link: https://github.com/twatteyne/draft- 987 ietf-6tisch-msf/issues/19 989 [TOD BE DISCUSSED. I am not sure this is an issue or not with 990 current version. Need to discuss with Malisa and Simon.] 992 E.3. editorial 994 E.3.1. Rules for broadcast frames is out of scope of MSF 996 In Section 2, the rules for broadcast frames on the minimal cell seem 997 to be an implementation-specific optimization. And it is beyond of 998 the scope of this draft. This idea is about how to use the minimal 999 cell efficiently; it's not directly related to how to use cells 1000 scheduled by MSF. Related discussion: 1001 https://mailarchive.ietf.org/arch/ 1002 msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao 1004 [TOD BE DISCUSSED. I agree with this comment. Should we remove 1005 those text or keep them in the draft but mentioned those rules are 1006 not a MUST but a RECOMMENDED?] 1008 Authors' Addresses 1010 Tengfei Chang (editor) 1011 Inria 1012 2 rue Simone Iff 1013 Paris 75012 1014 France 1016 Email: tengfei.chang@inria.fr 1017 Malisa Vucinic 1018 Inria 1019 2 rue Simone Iff 1020 Paris 75012 1021 France 1023 Email: malisa.vucinic@inria.fr 1025 Xavier Vilajosana 1026 Universitat Oberta de Catalunya 1027 156 Rambla Poblenou 1028 Barcelona, Catalonia 08018 1029 Spain 1031 Email: xvilajosana@uoc.edu 1033 Simon Duquennoy 1034 RISE SICS 1035 Isafjordsgatan 22 1036 164 29 Kista 1037 Sweden 1039 Email: simon.duquennoy@ri.se 1041 Diego Dujovne (editor) 1042 Universidad Diego Portales 1043 Escuela de Informatica y Telecomunicaciones 1044 Av. Ejercito 441 1045 Santiago, Region Metropolitana 1046 Chile 1048 Phone: +56 (2) 676-8121 1049 Email: diego.dujovne@mail.udp.cl