idnits 2.17.1 draft-chang-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 -- The document date (July 2, 2018) is 2124 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 572 -- Looks like a reference, but probably isn't: '3' on line 572 -- Looks like a reference, but probably isn't: '4' on line 572 -- Looks like a reference, but probably isn't: '2' on line 572 -- Looks like a reference, but probably isn't: '0' on line 572 -- Looks like a reference, but probably isn't: '5' on line 572 -- Looks like a reference, but probably isn't: '6' on line 572 -- Looks like a reference, but probably isn't: '7' on line 572 -- Looks like a reference, but probably isn't: '9' on line 572 == Missing Reference: 'TEMPORARY' is mentioned on line 800, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-06 ** 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 (~~), 3 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 Inria 4 Intended status: Standards Track M. Vucinic 5 Expires: January 3, 2019 University of Montenegro 6 X. Vilajosana 7 Universitat Oberta de Catalunya 8 S. Duquennoy 9 RISE SICS 10 D. Dujovne, Ed. 11 Universidad Diego Portales 12 July 2, 2018 14 6TiSCH Minimal Scheduling Function (MSF) 15 draft-chang-6tisch-msf-02 17 Abstract 19 This specification defines the 6TiSCH Minimal Scheduling Function 20 (MSF). This Scheduling Function describes both the behavior of a 21 node when joining the network, and how the communication schedule is 22 managed in a distributed fashion. MSF builds upon the 6TiSCH 23 Operation Sublayer Protocol (6P) and the Minimal Security Framework 24 for 6TiSCH. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in 31 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 3, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Interface to the Minimal 6TiSCH Configuration . . . . . . . . 4 69 3. Autonomous Unicast Cells . . . . . . . . . . . . . . . . . . 5 70 4. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.2. Step 1 - Choosing Frequency . . . . . . . . . . . . . . . 6 73 4.3. Step 2 - Receiving EBs . . . . . . . . . . . . . . . . . 6 74 4.4. Step 3 - Setting up Autonomous Unicast Cells . . . . . . 7 75 4.5. Step 4 - Join Request/Response . . . . . . . . . . . . . 7 76 4.6. Step 5 - Acquiring a RPL rank . . . . . . . . . . . . . . 7 77 4.7. Step 6 - Send EBs and DIOs . . . . . . . . . . . . . . . 7 78 4.8. Step 7 - Neighbor Polling . . . . . . . . . . . . . . . . 7 79 4.9. End State . . . . . . . . . . . . . . . . . . . . . . . . 8 80 5. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 8 81 5.1. Adapting to Traffic . . . . . . . . . . . . . . . . . . . 8 82 5.2. Switching Parent . . . . . . . . . . . . . . . . . . . . 10 83 5.3. Handling Schedule Collisions . . . . . . . . . . . . . . 10 84 6. 6P SIGNAL command . . . . . . . . . . . . . . . . . . . . . . 12 85 7. Scheduling Function Identifier . . . . . . . . . . . . . . . 12 86 8. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 12 87 9. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 12 88 10. Rule for Ordering Cells . . . . . . . . . . . . . . . . . . . 12 89 11. Meaning of the Metadata Field . . . . . . . . . . . . . . . . 13 90 12. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 13 91 13. Schedule Inconsistency Handling . . . . . . . . . . . . . . . 13 92 14. MSF Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 93 15. MSF Statistics . . . . . . . . . . . . . . . . . . . . . . . 14 94 16. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 96 17.1. MSF Scheduling Function Identifiers . . . . . . . . . . 15 97 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 18.1. Normative References . . . . . . . . . . . . . . . . . . 15 99 18.2. Informative References . . . . . . . . . . . . . . . . . 16 100 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 101 Appendix B. Implementation Status . . . . . . . . . . . . . . . 17 102 Appendix C. Performance Evaluation . . . . . . . . . . . . . . . 17 103 Appendix D. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 106 1. Introduction 108 The 6TiSCH Minimal Scheduling Function (MSF), defined in this 109 specification, is a 6TiSCH Scheduling Function (SF). The role of an 110 SF is entirely defined in [I-D.ietf-6tisch-6top-protocol]: it 111 complements [I-D.ietf-6tisch-6top-protocol] by providing the rules of 112 when to add/delete cells in the communication schedule. The SF 113 defined in this document follows that definition, and satisfies all 114 the requirements for an SF listed in Section 4.2 of 115 [I-D.ietf-6tisch-6top-protocol]. 117 MSF builds on top of the following specifications: the Minimal IPv6 118 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration 119 [RFC8180], the 6TiSCH Operation Sublayer Protocol (6P) 120 [I-D.ietf-6tisch-6top-protocol], and the Minimal Security Framework 121 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. 123 MSF defines both the behavior of a node when joining the network, and 124 how the communication schedule is managed in a distributed fashion. 125 When a node running MSF boots up, it joins the network by following 126 the 7 steps described in Section 4. The end state of the join 127 process is that the node is synchronized to the network, has mutually 128 authenticated to the network, has identified a preferred routing 129 parent, has scheduled one default unicast cell to/from each of its 130 neighbors. After the join process, the node can continuously 131 add/delete/relocate cells, as described in Section 5. It does so for 132 3 reasons: to match the link-layer resources to the traffic, to 133 handle changing parent, to handle a schedule collision. 135 MSF is designed to operate in a wide range of application domains. 136 It is optimized for applications with regular upstream traffic (from 137 the nodes to the root). Appendix C contains a performance evaluation 138 of MSF. 140 This specification follows the recommended structure of an SF 141 specification in Appendix A of [I-D.ietf-6tisch-6top-protocol], with 142 the following adaptations: 144 o We have reordered part of the sections, in particular to have the 145 section on the node behavior at boot Section 4 appear early in 146 this specification. 147 o We added sections on the interface to the minimal 6TiSCH 148 configuration Section 2, the use of the SIGNAL command Section 6, 149 the MSF constants Section 14, the MSF statistics Section 15, the 150 performance of MSF Appendix C. 151 o This specification does not include an examples section. 153 2. Interface to the Minimal 6TiSCH Configuration 155 A node implementing MSF MUST implement the Minimal 6TiSCH 156 Configuration [RFC8180], which defines the "minimal cell", a single 157 shared cell providing minimal connectivity between the nodes in the 158 network. 160 MSF uses the minimal cell to exchange the following packets: 162 1. Enhanced Beacons (EBs), defined by [IEEE802154-2015]. These are 163 broadcast frames. 164 2. DODAG Information Objects (DIOs), defined by [RFC6550]. These 165 are broadcast frames. 167 Because the minimal cell is SHARED, the back-off algorithm defined in 168 [IEEE802154-2015] is used to resolve collisions. To ensure there is 169 enough bandwidth available on the minimal cell, a node implementing 170 MSF SHOULD enforce the following rules for broadcast frames: 172 1. send EBs on a portion of the minimal cells not exceeding 173 1/(3(N+1)), where N is the number of neighbors of the node. 174 2. send DIOs on a portion of the minimal cells not exceeding 175 1/(3(N+1)), where N is the number of neighbors of the node. 177 The RECOMMENDED behavior for sending EBs is to have a node send EBs 178 with a probability of 1/(3(N+1)). The RECOMMENDED behavior for 179 sending DIOs is to use a Trickle timer with rate-limiting. 181 Section 4.3 describes how to evaluate the number of neighbors during 182 the joining process. After the joining process, how to evaluate the 183 number of neighbors is implementation-specific. 185 As detailed in Section 2.2 of [I-D.ietf-6tisch-6top-protocol], MSF 186 MUST schedule cells from Slotframe 1, while Slotframe 0 is used for 187 traffic defined in the Minimal 6TiSCH Configuration. The length of 188 Slotframe 0 and Slotframe 1 SHOULD be the same value. The default of 189 SLOTFRAME_LENGTH is RECOMMENDED, although any value can be advertised 190 in the EBs. 192 3. Autonomous Unicast Cells 194 MSF nodes MUST initialize Slotframe 1 with a set of default cells for 195 unicast communication with their neighbors. These cells are referred 196 to as 'autonomous cells', because they are maintained autonomously by 197 each node. Each node has: 199 1. One cell to receive, at a [slotOffset,channelOffset] computed as 200 a hash of the node's EUI64 (detailed next). The cell options for 201 this cell are RX=1. 202 2. For each neighbor in the IPv6 neighbor table, one cell to 203 transmit, at a [slotOffset,channelOffset] computed as a hash of 204 the neighbor's EUI64 (detailed next). The cell options for this 205 cell are TX=1, SHARED=1. 207 To compute a [slotOffset,channelOffset] from an EUI64 address, nodes 208 MUST use the hash function SAX [SAX-DASFAA]. The coordinates are 209 computed to distribute the cells across all 16 channel offsets, and 210 all but the first time offsets of Slotframe 1. The first time offset 211 is skipped to avoid colliding with the minimal cell in Slotframe 0. 212 The slot coordinates derived from a given EUI64 address are computed 213 as follows: 215 slotOffset(MAC) = 1 + hash(EUI64) % (length(Slotframe_1) - 1) 216 channelOffset(MAC) = hash(EUI64) % 16 218 Because of hash collisions, there are cases where one node has 219 multiple cells scheduled at the same time offset and/or channel 220 offset. Note that nodes have only one autonomous RX cell and 221 potentially multiple TX cells. Hash collisions among a set of cells 222 at a given time offset is resolved at run-time as follows: 224 1. The TX cell with the most packets in outgoing queue takes 225 precedence. 226 2. If all TX cells have empty outgoing queues, the RX cell takes 227 precedence. 229 Throughout the network lifetime, nodes MUST maintain the autonomous 230 cells as follows: 232 1. The receive cell MUST always remain scheduled. 233 2. Whenever a new neighbor is discovered, add a transmit cell for 234 it. 235 3. Whenever a new neighbor is removed, remove transmit cell that was 236 assigned to it. 237 4. 6P CLEAR MUST NOT erase autonomous cells. 239 4. Node Behavior at Boot 241 This section details the behavior the node SHOULD follow from the 242 moment it is switched on, until it has successfully joined the 243 network. Section 4.1 details the start state; Section 4.9 details 244 the end state. The other sections detail the 7 steps of the joining 245 process. We use the term "pledge" and "joined node", as defined in 246 [I-D.ietf-6tisch-minimal-security]. 248 4.1. Start State 250 A node implementing MSF MUST implement the Minimal Security Framework 251 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this 252 means that a pledge, before being switched on, is pre-configured with 253 the Pre-Shared Key (PSK) for joining, as well as any other 254 configuration detailed in [I-D.ietf-6tisch-minimal-security]. 256 4.2. Step 1 - Choosing Frequency 258 When switched on, the pledge SHOULD randomly choose a frequency among 259 the available frequencies, and start listening for EBs on that 260 frequency. 262 4.3. Step 2 - Receiving EBs 264 Upon receiving the first EB, the pledge SHOULD continue listening for 265 additional EBs to learn: 267 1. the number of neighbors N in its vicinity 268 2. which neighbor to choose as a Join Proxy (JP) for the joining 269 process 271 While the exact behavior is implementation-specific, the RECOMMENDED 272 behavior is to follow [RFC8180], and listen until EBs sent by 273 NUM_NEIGHBOURS_TO_WAIT nodes (defined in [RFC8180]) have been 274 received. 276 During this step, the pledge MAY synchronize to any EB it receives 277 from the network it wishes to join. How to decide whether an EB 278 originates from a node from the network it wishes to join is 279 implementation-specific, but MAY involve filtering EBs by the PAN ID 280 field it contains, the presence and contents of the IE defined in 281 [I-D.richardson-6tisch-join-enhanced-beacon], or the key used to 282 authenticate it. 284 The decision of which neighbor to use as a JP is implementation- 285 specific, and discussed in [I-D.ietf-6tisch-minimal-security]. 287 4.4. Step 3 - Setting up Autonomous Unicast Cells 289 After joining, nodes MUST set up their autonomous unicast cells, as 290 described in Section 3. This enables unicast communication in 291 Slotframe 1, until more cells are added with 6P as defined in 292 Section 5. 294 4.5. Step 4 - Join Request/Response 296 As per [I-D.ietf-6tisch-minimal-security], after having selected a 297 JP, the pledge sends a Join Request to its JP. Because no dedicated 298 cells are in place at this point, this happens on the autonomous 299 unicast cell. The JP then forwards the Join Request to the JRC, 300 possibly over multiple hops. When forwarding this Join Request, a 301 node MUST use a unicast cell (autonomous or dedicated) it has with 302 its preferred parent. How dedicated cells are installed is detailed 303 in Section 5. 305 As per [I-D.ietf-6tisch-minimal-security], the JRC sends back a Join 306 Response to the pledge, through the JP. When forwarding this Join 307 Response, a node MUST use a unicast (autonomous or dedicated) cell it 308 has with its child (not the minimal cell). 310 As per [I-D.ietf-6tisch-minimal-security], after receiving the Join 311 Response, the pledge learns the keying material used in the network, 312 as well as other configurations, and becomes a "joined node". 314 4.6. Step 5 - Acquiring a RPL rank 316 Because it has learned the link-layer keying material used in the 317 network, the joined node can now decrypt the DIO packets sent by its 318 neighbors. Per [RFC6550], the joined node receives DIOs, computes 319 its own rank, and selects a preferred parent. 321 4.7. Step 6 - Send EBs and DIOs 323 The node SHOULD start sending EBs and DIOs on the minimal cell, while 324 following the transmit rules for broadcast frames from Section 2. 326 4.8. Step 7 - Neighbor Polling 328 The node SHOULD send some form of keep-alive messages to all its 329 neighbors it has unicast cells with. The Keep-Alive (KA) mechanism 330 is detailed in [RFC7554]. It uses the keep-alive messages to its 331 preferred parent to stay synchronized. It uses the keep-alive 332 messages to its children (with which it has a unicast cell to) to 333 ensure the child is still reachable. The RECOMMENDED period for 334 sending keep-alive messages is KA_PERIOD. 336 If the keep-alive message to a child fails at the link layer (i.e. 337 the maximum number of link-layer retries is reached), the node SHOULD 338 declare the child as unreachable. This can happen for example when 339 the child node is switched off. 341 When a neighbor is declared unreachable, the node MUST remove all 342 dedicated cells with that neighbor from its own schedule. In 343 addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at 344 the link-layer). If the node has autonmous cells to the unreachable 345 neighbor those cells will be removed following the procedure 346 described in Section 3. 348 4.9. End State 350 For a new node, the end state of the joining process is: 352 o it is synchronized to the network 353 o it is using the link-layer keying material it learned through the 354 secure joining process 355 o it has identified its preferred routing parent 356 o it has a set of autonomous unicast cells to/from its neighbors 357 o it is periodically sending DIOs, potentially serving as a router 358 for other nodes' traffic 359 o it is periodically sending EBs, potentially serving as a JP for 360 new joining nodes 362 5. Rules for Adding/Deleting Cells 364 Once a node has joined the 6TiSCH network, it adds/deletes/relocates 365 cells with its preferred parent for three reasons: 367 o to match the link-layer resources to the traffic between the node 368 and its preferred parent (Section 5.1) 369 o to handle switching preferred parent (Section 5.2) 370 o to handle a schedule collision (Section 5.3) 372 5.1. Adapting to Traffic 374 A node implementing MSF MUST implement the behavior described in this 375 section. 377 In order to handle transient traffic bursts, MSF uses the 378 [IEEE802154-2015] frame pending bit (page 152, Section 7.2.1.3). By 379 setting the bit, a node can transmit a series of packets to a given 380 neighbor in consecutive time offsets. The next paragraphs define how 381 to handle longer-term fluctuations in traffic, using 6P. 383 The goal of MSF is to manage the communication schedule in the 6TiSCH 384 schedule in a distributed manner. For a node, this translates into 385 monitoring the current usage of the cells it has to its preferred 386 parent: 388 o If the node determines that the number of link-layer frames it is 389 attempting to exchange with its preferred parent per unit of time 390 is larger than the capacity offered by the TSCH unicast cells 391 (dedicated and autonmous cells) it has scheduled with it, the node 392 triggers a 6P Transaction with its preferred parent to add 393 dedicated cells to the TSCH schedule of both nodes. 394 o If the traffic is lower than the capacity, the node triggers a 6P 395 Transaction with its preferred parent to delete dedicated cells 396 from the TSCH schedule of both nodes. 398 From the join process, the node already has a set of autonmous 399 unicast cells, as defined in Section 3. The autonomous cells MUST 400 NOT be removed by 6P, so that there always exists a unicast cell 401 between a node and its preferred parent, even if no frames are being 402 exchanged between them. Autonomous cells are used indistinguishably 403 together with dedicated cells, for broadcast or unicast traffic with 404 the target neighbor. The procedure to remove autonomous cells is 405 described in Section 3. 407 Adding/removing/relocating cells involves exchanging frames that 408 contain 6P commands. All 6P frames MUST be sent on the unicast cells 409 (and not the minimal cell). 411 The node MUST maintain the following counters for its preferred 412 parent: 414 NumCellsPassed: Counts the number of unicast cells (dedicated and 415 autonmous cells) that have passed since the counter was 416 initialized. This counter is initialized at 0. Each time the 417 TSCH state machine indicates that the current cell is a unicast 418 cell to the preferred parent, NumCellsPassed is incremented by 419 exactly 1, regardless of whether the cell is used to transmit/ 420 receive a frame. 421 NumCellsUsed: Counts the number of unicast cells that have been 422 used. This counter is initialized at 0. NumCellsUsed is 423 incremented by exactly 1 when, during a unicast cell to the 424 preferred parent, either of the following happens: 426 * The node sends a frame to its preferred parent. The counter 427 increments regardless of whether a link-layer acknowledgment 428 was received or not. 429 * The node receives a frame from its preferred parent. 431 Implementors MAY choose to create the same counters for each 432 neighbor, and add them as additional statistics in the neighbor 433 table. 435 The counters are used as follows: 437 1. Both NumCellsPassed and NumCellsUsed are initialized to 0 when 438 the node boots. 439 2. When the value of NumCellsPassed reaches MAX_NUMCELLS: 441 * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a 442 single cell to the preferred parent 443 * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a 444 single cell to the preferred parent 445 * Reset both NumCellsPassed and NumCellsUsed to 0 and go to step 446 2. 448 5.2. Switching Parent 450 A node implementing MSF MUST implement the behavior described in this 451 section. 453 Part of its normal operation, the RPL routing protocol can have a 454 node switch preferred parents. The procedure for switching from the 455 old preferred parent to the new preferred parent is: 457 1. the node counts the number of dedicated (unicast but not 458 autonomous) cells it has per slotframe to the old preferred 459 parent 460 2. the node triggers one or more 6P ADD commands to schedule the 461 same number of dedicated cells to the new preferred parent 462 3. when that successfully completes, the node issues a 6P CLEAR 463 command to its old preferred parent 465 5.3. Handling Schedule Collisions 467 A node implementing MSF SHOULD implement the behavior described in 468 this section. The "MUST" statements in this section hence only apply 469 if the node implements schedule collision handling. 471 Since scheduling is entirely distributed, there is a non-zero 472 probability that two pairs of nearby neighbor nodes schedule a cell 473 at the same [slotOffset,channelOffset] location in the TSCH schedule. 474 In that case, data exchanged by the two pairs may collide on that 475 cell. We call this case a "schedule collision". 477 The node MUST maintain the following counters for each cell to its 478 preferred parent: 480 NumTx: Counts the number of transmission attempts on that cell. 481 Each time the node attempts to transmit a frame on that cell, 482 NumTx is incremented by exactly 1. 483 NumTxAck: Counts the number of successful transmission attempts on 484 that cell. Each time the node receives an acknowledgment for a 485 transmission attempt, NumTxAck is incremented by exactly 1. 487 Implementors MAY choose to maintain the same counters for each cell 488 in the schedule. 490 Since both NumTx and NumTxAck are initialized to 0, we necessarily 491 have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the 492 ratio NumTxAck/NumTx; and represent it as a percentage. A cell with 493 PDR=50% means that half of the frames transmitted are not 494 acknowledged (and need to be retransmitted). 496 Each time the node switches preferred parent (or during the join 497 process when the node selects a preferred parent for the first time), 498 both NumTx and NumTxAck MUST be reset to 0. They increment over 499 time, as the schedule is executed and the node sends frames to its 500 preferred parent. When NumTx reaches 256, both NumTx and NumTxAck 501 MUST be divided by 2. That is, for example, from NumTx=256 and 502 NumTxAck=128, they become NumTx=128 and NumTxAck=64. This operation 503 does not change the value of the PDR, but allows the counters to keep 504 incrementing. 506 The key for detecting a schedule collision is that, if a node has 507 several cells to the same preferred parent, all cells should exhibit 508 the same PDR. A cell which exhibits a PDR significantly lower than 509 the others indicates than there are collisions on that cell. 511 Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following 512 steps: 514 1. It computes, for each dedicated cell with its preferred parent 515 (not for the autonomous cell), that cell's PDR. 516 2. Any cell that hasn't yet had NumTx divided by 2 since it was last 517 reset is skipped in steps 3 and 4. This avoids triggering cell 518 relocation when the values of NumTx and NumTxAck are not 519 statistically significant yet. 520 3. It identifies the cell with the highest PDR. 521 4. For each other cell, it compares its PDR against that of the cell 522 with the highest PDR. If it's less than RELOCATE_PDRTHRES, it 523 triggers the relocation of that cell using a 6P RELOCATE command. 525 6. 6P SIGNAL command 527 The 6P SIGNAL command is not used by MSF. 529 7. Scheduling Function Identifier 531 The Scheduling Function Identifier (SFID) of MSF is 532 IANA_6TISCH_SFID_MSF. 534 8. Rules for CellList 536 MSF uses 2-step 6P Transactions exclusively. 6P Transactions are 537 only initiated by a node towards it preferred parent. As a result, 538 the cells to put in the CellList of a 6P ADD command, and in the 539 candidate CellList of a RELOCATE command, are chosen by the node 540 initiating the 6P Transaction. In both cases, the same rules apply: 542 o The CellList SHOULD contain 5 or more cells. 543 o Each cell in the CellList MUST have a different slotOffset value. 544 o For each cell in the CellList, the node MUST NOT have any 545 scheduled cell on the same slotOffset. 546 o The slotOffset value of any cell in the CellList MUST NOT be the 547 same as the slotOffset of the minimal cell (slotOffset=0). 548 o The slotOffset of a cell in the CellList SHOULD be randomly and 549 uniformly chosen among all the slotOffset values that satisfy the 550 restrictions above. 551 o The channelOffset of a cell in the CellList SHOULD be randomly and 552 uniformly chosen in [0..numFrequencies], where numFrequencies 553 represents the number of frequencies a node can communicate on. 555 9. 6P Timeout Value 557 The 6P Timeout is not a constant value. It is calculated as 558 (1/C)*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR, where: 560 o C represents the number of cells per second scheduled to that 561 neighbor 562 o PDR represents the average PDR of those cells 563 o SIXP_TIMEOUT_SEC_FACTOR is a security factor, a constant 565 10. Rule for Ordering Cells 567 Cells are ordered slotOffset first, channelOffset second. 569 The following sequence is correctly ordered (each element represents 570 the [slottOffset,channelOffset] of a cell in the schedule): 572 [1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9] 574 11. Meaning of the Metadata Field 576 The Metadata field is not used by MSF. 578 12. 6P Error Handling 580 Section 6.2.4 of [I-D.ietf-6tisch-6top-protocol] lists the 6P Return 581 Codes. Figure 1 lists the same error codes, and the behavior a node 582 implementing MSF SHOULD follow. 584 +-----------------+----------------------+ 585 | Code | RECOMMENDED behavior | 586 +-----------------+----------------------+ 587 | RC_SUCCESS | nothing | 588 | RC_EOL | nothing | 589 | RC_ERR | quarantine | 590 | RC_RESET | quarantine | 591 | RC_ERR_VERSION | quarantine | 592 | RC_ERR_SFID | quarantine | 593 | RC_ERR_SEQNUM | clear | 594 | RC_ERR_CELLLIST | clear | 595 | RC_ERR_BUSY | waitretry | 596 | RC_ERR_LOCKED | waitretry | 597 +-----------------+----------------------+ 599 Figure 1: Recommended behavior for each 6P Error Code. 601 The meaning of each behavior from Figure 1 is: 603 nothing: Indicates that this Return Code is not an error. No error 604 handling behavior is triggered. 605 clear: Abort the 6P Transaction. Issue a 6P CLEAR command to that 606 neighbor (this command may fail at the link layer). Remove all 607 cells scheduled with that neighbor from the local schedule. Keep 608 that node in the neighbor and routing tables. 609 quarantine: Same behavior as for "clear". In addition, remove the 610 node from the neighbor and routing tables. Place the node's 611 identifier in a quarantine list for QUARANTINE_DURATION. When in 612 quarantine, drop all frames received from that node. 613 waitretry: Abort the 6P Transaction. Wait for a duration randomly 614 and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX]. 615 Retry the same transaction. 617 13. Schedule Inconsistency Handling 619 The behavior when schedule inconsistency is detected is explained in 620 Figure 1, for 6P Return Code RC_ERR_SEQNUM. 622 14. MSF Constants 624 Figure 2 lists MSF Constants and their RECOMMENDED values. 626 +------------------------------+-------------------+ 627 | Name | RECOMMENDED value | 628 +------------------------------+-------------------+ 629 | KA_PERIOD | 10 s | 630 | LIM_NUMCELLSUSED_HIGH | 75 % | 631 | LIM_NUMCELLSUSED_LOW | 25 % | 632 | HOUSEKEEPINGCOLLISION_PERIOD | 1 min | 633 | RELOCATE_PDRTHRES | 50 % | 634 | SIXP_TIMEOUT_SEC_FACTOR | 3 x | 635 | SLOTFRAME_LENGTH | 101 slots | 636 | QUARANTINE_DURATION | 5 min | 637 | WAITDURATION_MIN | 30 s | 638 | WAITDURATION_MAX | 60 s | 639 +------------------------------+-------------------+ 641 Figure 2: MSF Constants and their RECOMMENDED values. 643 15. MSF Statistics 645 Figure 3 lists MSF Statistics and their RECOMMENDED width. 647 +-----------------+-------------------+ 648 | Name | RECOMMENDED width | 649 +-----------------+-------------------+ 650 | NumCellsPassed | 1 byte | 651 | NumCellsUsed | 1 byte | 652 | NumTx | 1 byte | 653 | NumTxAck | 1 byte | 654 +-----------------+-------------------+ 656 Figure 3: MSF Statistics and their RECOMMENDED width. 658 16. Security Considerations 660 MSF defines a series of "rules" for the node to follow. It triggers 661 several actions, that are carried out by the protocols defined in the 662 following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 663 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation 664 Sublayer Protocol (6P) [I-D.ietf-6tisch-6top-protocol], and the 665 Minimal Security Framework for 6TiSCH 666 [I-D.ietf-6tisch-minimal-security]. In particular, MSF does not 667 define a new protocol or packet format. 669 MSF relies entirely on the security mechanisms defined in the 670 specifications listed above. 672 17. IANA Considerations 674 17.1. MSF Scheduling Function Identifiers 676 This document adds the following number to the "6P Scheduling 677 Function Identifiers" sub-registry, part of the "IPv6 over the TSCH 678 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by 679 [I-D.ietf-6tisch-6top-protocol]: 681 +----------------------+-----------------------------+-------------+ 682 | SFID | Name | Reference | 683 +----------------------+-----------------------------+-------------+ 684 | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX | 685 | | (MSF) | (NOTE:this) | 686 +----------------------+-----------------------------+-------------+ 688 Figure 4: IETF IE Subtype '6P'. 690 18. References 692 18.1. Normative References 694 [I-D.ietf-6tisch-6top-protocol] 695 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 696 Operation Sublayer Protocol (6P)", draft-ietf-6tisch-6top- 697 protocol-12 (work in progress), June 2018. 699 [I-D.ietf-6tisch-minimal-security] 700 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 701 "Minimal Security Framework for 6TiSCH", draft-ietf- 702 6tisch-minimal-security-06 (work in progress), May 2018. 704 [I-D.richardson-6tisch-join-enhanced-beacon] 705 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 706 Element encapsulation of 6tisch Join Information", draft- 707 richardson-6tisch-join-enhanced-beacon-03 (work in 708 progress), January 2018. 710 [IEEE802154-2015] 711 IEEE standard for Information Technology, "IEEE Std 712 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 713 Networks (WPANs)", December 2015. 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, 717 DOI 10.17487/RFC2119, March 1997, 718 . 720 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 721 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 722 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 723 Low-Power and Lossy Networks", RFC 6550, 724 DOI 10.17487/RFC6550, March 2012, 725 . 727 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 728 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 729 Internet of Things (IoT): Problem Statement", RFC 7554, 730 DOI 10.17487/RFC7554, May 2015, 731 . 733 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 734 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 735 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 736 May 2017, . 738 18.2. Informative References 740 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 741 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 742 a Standards-Based Low-Power Wireless Development 743 Environment", Transactions on Emerging Telecommunications 744 Technologies , August 2012. 746 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 747 Code: The Implementation Status Section", RFC 6982, 748 DOI 10.17487/RFC6982, July 2013, 749 . 751 [SAX-DASFAA] 752 Ramakrishna, M. and J. Zobel, "Performance in Practice of 753 String Hashing Functions", DASFAA , 1997. 755 Appendix A. Contributors 757 Beshr Al Nahas (Chalmers University, beshr@chalmers.se) and Olaf 758 Landsiedel (Chalmers University, olafl@chalmers.se) contributed to 759 the design and evaluation of autonomous unicast cells. 761 Appendix B. Implementation Status 763 This section records the status of known implementations of the 764 protocol defined by this specification at the time of posting of this 765 Internet-Draft, and is based on a proposal described in [RFC6982]. 766 The description of implementations in this section is intended to 767 assist the IETF in its decision processes in progressing drafts to 768 RFCs. Please note that the listing of any individual implementation 769 here does not imply endorsement by the IETF. Furthermore, no effort 770 has been spent to verify the information presented here that was 771 supplied by IETF contributors. This is not intended as, and must not 772 be construed to be, a catalog of available implementations or their 773 features. Readers are advised to note that other implementations may 774 exist. 776 According to [RFC6982], "this will allow reviewers and working groups 777 to assign due consideration to documents that have the benefit of 778 running code, which may serve as evidence of valuable experimentation 779 and feedback that have made the implemented protocols more mature. 780 It is up to the individual working groups to use this information as 781 they see fit". 783 OpenWSN: MSF is being implemented in the OpenWSN project [OpenWSN] 784 under a BSD open-source license. The authors of this document are 785 collaborating with the OpenWSN community to gather feedback about 786 the status and performance of the protocols described in this 787 document. Results from that discussion will appear in this 788 section in future revision of this specification. More 789 information about this implementation at http://www.openwsn.org/. 790 6TiSCH simulator The 6TiSCH simulator is a Python-based high-level 791 simulator on which MSF is being implemented. More information at 792 https://bitbucket.org/6tisch/simulator/. 794 Appendix C. Performance Evaluation 796 The performance of MSF may be published as companion documents to 797 this specification, possibly under the form a applicability 798 statements. 800 Appendix D. [TEMPORARY] Changelog 802 o draft-chang-6tisch-msf-02 804 * Added autonomous cell. 805 o draft-chang-6tisch-msf-01 807 * When neighbor is unreachable, sending a CLEAR command was a 808 MUST, now a MAY. 810 * Fixing 6P Timeout calculation. 811 * Clearer text for "Handling Schedule Collisions" section. 812 * Typos. 813 * Input from Yasuyuki Tanaka's review (https://www.ietf.org/mail- 814 archive/web/6tisch/current/msg05723.html). 815 o draft-chang-6tisch-msf-00 817 * Initial submission. 819 Authors' Addresses 821 Tengfei Chang (editor) 822 Inria 823 2 rue Simone Iff 824 Paris 75012 825 France 827 Email: tengfei.chang@inria.fr 829 Malisa Vucinic 830 University of Montenegro 831 Dzordza Vasingtona bb 832 Podgorica 81000 833 Montenegro 835 Email: malisav@ac.me 837 Xavier Vilajosana 838 Universitat Oberta de Catalunya 839 156 Rambla Poblenou 840 Barcelona, Catalonia 08018 841 Spain 843 Email: xvilajosana@uoc.edu 845 Simon Duquennoy 846 RISE SICS 847 Isafjordsgatan 22 848 164 29 Kista 849 Sweden 851 Email: simon.duquennoy@ri.se 852 Diego Dujovne (editor) 853 Universidad Diego Portales 854 Escuela de Informatica y Telecomunicaciones 855 Av. Ejercito 441 856 Santiago, Region Metropolitana 857 Chile 859 Phone: +56 (2) 676-8121 860 Email: diego.dujovne@mail.udp.cl