idnits 2.17.1 draft-chang-6tisch-msf-00.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 (October 30, 2017) is 2367 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 518 -- Looks like a reference, but probably isn't: '3' on line 518 -- Looks like a reference, but probably isn't: '4' on line 518 -- Looks like a reference, but probably isn't: '2' on line 518 -- Looks like a reference, but probably isn't: '0' on line 518 -- Looks like a reference, but probably isn't: '5' on line 518 -- Looks like a reference, but probably isn't: '6' on line 518 -- Looks like a reference, but probably isn't: '7' on line 518 -- Looks like a reference, but probably isn't: '9' on line 518 == Missing Reference: 'TEMPORARY' is mentioned on line 736, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-09 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-04 == Outdated reference: A later version (-03) exists of draft-richardson-6tisch-join-enhanced-beacon-02 ** 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 (~~), 5 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: May 3, 2018 University of Montenegro 6 X. Vilajosana 7 Universitat Oberta de Catalunya 8 October 30, 2017 10 6TiSCH Minimal Scheduling Function (MSF) 11 draft-chang-6tisch-msf-00 13 Abstract 15 This specification defines the 6TiSCH Minimal Scheduling Function 16 (MSF). This Scheduling Function describes both the behavior of a 17 node when joining the network, and how the communication schedule is 18 managed in a distributed fashion. MSF builds upon the 6top Protocol 19 (6P) and the Minimal Security Framework for 6TiSCH. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in 26 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 3, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Interface to the Minimal 6TiSCH Configuration . . . . . . . . 4 64 3. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Step 1 - Choosing Frequency . . . . . . . . . . . . . . . 5 67 3.3. Step 2 - Receiving EBs . . . . . . . . . . . . . . . . . 5 68 3.4. Step 3 - Join Request/Response . . . . . . . . . . . . . 6 69 3.5. Step 4 - Acquiring a RPL rank . . . . . . . . . . . . . . 6 70 3.6. Step 5 - 6P ADD to Preferred Parent . . . . . . . . . . . 6 71 3.7. Step 6 - Send EBs and DIOs . . . . . . . . . . . . . . . 7 72 3.8. Step 7 - Neighbor Polling . . . . . . . . . . . . . . . . 7 73 3.9. End State . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 7 75 4.1. Adapting to Traffic . . . . . . . . . . . . . . . . . . . 8 76 4.2. Switching Parent . . . . . . . . . . . . . . . . . . . . 9 77 4.3. Handling Schedule Collisions . . . . . . . . . . . . . . 9 78 5. 6P SIGNAL command . . . . . . . . . . . . . . . . . . . . . . 11 79 6. Scheduling Function Identifier . . . . . . . . . . . . . . . 11 80 7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 11 81 8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 11 82 9. Rule for Ordering Cells . . . . . . . . . . . . . . . . . . . 11 83 10. Meaning of the Metadata Field . . . . . . . . . . . . . . . . 12 84 11. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 12 85 12. Schedule Inconsistency Handling . . . . . . . . . . . . . . . 12 86 13. MSF Constants . . . . . . . . . . . . . . . . . . . . . . . . 13 87 14. MSF Statistics . . . . . . . . . . . . . . . . . . . . . . . 13 88 15. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 16.1. MSF Scheduling Function Identifiers . . . . . . . . . . 14 91 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 17.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 17.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Appendix A. Implementation Status . . . . . . . . . . . . . . . 15 95 Appendix B. Performance Evaluation . . . . . . . . . . . . . . . 16 96 Appendix C. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 99 1. Introduction 101 The 6TiSCH Minimal Scheduling Function (MSF), defined in this 102 specification, is a 6TiSCH Scheduling Function (SF). The role of an 103 SF is entirely defined in [I-D.ietf-6tisch-6top-protocol]: it 104 complements [I-D.ietf-6tisch-6top-protocol] by providing the rules of 105 when to add/delete cells in the communication schedule. The SF 106 defined in this document follows that definition, and satisfies all 107 the requirements for an SF listed in Section 4.2 of 108 [I-D.ietf-6tisch-6top-protocol]. 110 MSF builds on top of the following specifications: the Minimal IPv6 111 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration 112 [RFC8180], the 6top Protocol (6P) [I-D.ietf-6tisch-6top-protocol], 113 and the Minimal Security Framework for 6TiSCH 114 [I-D.ietf-6tisch-minimal-security]. 116 MSF defines both the behavior of a node when joining the network, and 117 how the communication schedule is managed in a distributed fashion. 118 When a node running MSF boots up, it joins the network by following 119 the 7 steps described in Section 3. The end state of the join 120 process is that the node is synchronized to the network, has mutually 121 authenticated to the network, has identified a preferred routing 122 parent, and has scheduled a single dedicated cell to that parent. 123 After the join process, the node can continuously add/delete/relocate 124 cells, as described in Section 4. It does so for 3 reasons: to match 125 the link-layer resources to the traffic, to handle changing parent, 126 to handle a schedule collision. 128 MSF is designed to operate in a wide range of application domains. 129 It is optimized for applications with regular upstream traffic (from 130 the nodes to the Internet). Appendix B contains a performance 131 evaluation of MSF. 133 This specification follows the recommended structure of an SF 134 specification in Appendix A of [I-D.ietf-6tisch-6top-protocol], with 135 the following adaptations: 137 o We have reordered part of the sections, in particular to have the 138 section on the node behavior at boot Section 3 appear early in 139 this specification. 141 o We added sections on the interface to the minimal 6TiSCH 142 configuration Section 2, the use of the SIGNAL command Section 5, 143 the MSF constants Section 13, the MSF statistics Section 14, the 144 performance of MSF Appendix B. 145 o We have not included an examples section. 147 2. Interface to the Minimal 6TiSCH Configuration 149 A node implementing MSF MUST implement the Minimal 6TiSCH 150 Configuration [RFC8180], which defines the "minimal cell", a single 151 shared cell providing minimal connectivity between the nodes in the 152 network. 154 MSF uses the minimal cell to exchange the following packets: 156 1. Enhanced Beacons (EBs), defined by [IEEE802154-2015]. These are 157 broadcast frames. 158 2. DODAG Information Objects (DIOs), defined by [RFC6550]. These 159 are broadcast frames. 160 3. The Join Request and Join Response packets when sent between the 161 pledge and the Join Proxy, defined by 162 [I-D.ietf-6tisch-minimal-security]. These are unicast frames. 163 4. The first 6P packet a node issues to a neighbor it doesn't have 164 dedicated cells to, as defined by 165 [I-D.ietf-6tisch-6top-protocol]. These are unicast 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 for the unicast 170 traffic, a node implementing MSF SHOULD enforce the following rules 171 for broadcast frames: 173 1. send EBs on a portion of the minimal cells not exceeding 174 1/(3(N+1)), where N is the number of neighbors of the node. 175 2. send DIOs on a portion of the minimal cells not exceeding 176 1/(3(N+1)), where N is the number of neighbors of the node. 178 The RECOMMENDED behavior for sending EBs is to have a node send EBs 179 with a probability of 1/(3(N+1)). The RECOMMENDED behavior for 180 sending DIOs is to use a Trickle timer with rate-limiting. 182 Section 3.3 describes how to evaluate the number of neighbors during 183 the joining process. After the joining process, how to evaluate the 184 number of neighbors is implementation-specific. 186 As detailed in Section 2.2 of [I-D.ietf-6tisch-6top-protocol], MSF 187 MUST schedule cells from Slotframe 1, while Slotframe 0 is used for 188 traffic defined in the Minimal 6TiSCH Configuration. The length of 189 Slotframe 0 and Slotframe 1 MUST be the same value. The default of 190 SLOTFRAME_LENGTH is RECOMMENDED, although any value can be advertised 191 in the EBs. 193 3. Node Behavior at Boot 195 This section details the behavior the node SHOULD follow from the 196 moment it is switched on, until it has successfully joined the 197 network. Section 3.1 details the start state; Section 3.9 details 198 the end state. The other sections detail the 7 steps of the joining 199 process. We use the term "pledge" and "joined node", as defined in 200 [I-D.ietf-6tisch-minimal-security]. 202 3.1. Start State 204 A node implementing MSF MUST implement the Minimal Security Framework 205 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this 206 means that a pledge, before being switched on, is pre-configured with 207 the Pre-Shared Key (PSK) for joining, as well as any other 208 configuration detailed in [I-D.ietf-6tisch-minimal-security]. 210 3.2. Step 1 - Choosing Frequency 212 When switched on, the pledge SHOULD randomly choose a frequency among 213 the available frequencies, and start listening for EBs on that 214 frequency. 216 3.3. Step 2 - Receiving EBs 218 Upon receiving the first EB, the pledge SHOULD continue listening for 219 additional EBs to learn: 221 1. the number of neighbors N in its vicinity 222 2. which neighbor to choose as a Join Proxy (JP) for the joining 223 process 225 While the exact behavior is implementation-specific, the RECOMMENDED 226 behavior is to follow [RFC8180], and listen until EBs sent by 227 NUM_NEIGHBOURS_TO_WAIT (defined in [RFC8180]) have been received. 229 During this step, the pledge MAY synchronize to any EB it receives 230 from the network it wishes to join. How to decide whether an EB 231 originates from a node from the network it wishes to join is 232 implementation-specific, but MAY involve filtering EBs by the PAN ID 233 field it contains, the presence and contents of the IE defined in 234 [I-D.richardson-6tisch-join-enhanced-beacon], or the key used to 235 authenticate it. 237 The decision of which neighbor to use as a JP is implementation- 238 specific, and discussed in [I-D.ietf-6tisch-minimal-security]. 240 3.4. Step 3 - Join Request/Response 242 As per [I-D.ietf-6tisch-minimal-security], after having selected a 243 JP, the pledge sends a Join Request to its JP. Because no dedicated 244 cells are in place at this point, this happens on the minimal cell. 245 The JP then forwards the Join Request to the JRC, possibly over 246 multiple hops. When forwarding this Join Request, a node MUST use a 247 dedicated cell it has with its preferred parent (not the minimal 248 cell). How such dedicated cells are installed is detailed in 249 Section 3.6. 251 As per [I-D.ietf-6tisch-minimal-security], the JRC sends back a Join 252 Response to the pledge, through the JP. When forwarding this Join 253 Response, a node MUST use a dedicated cell it has with its child (not 254 the minimal cell). How such dedicated cells are installed is 255 detailed in Section 3.6. 257 As per [I-D.ietf-6tisch-minimal-security], after receiving the Join 258 Response, the pledge learns the keying material used in the network, 259 as well as other configurations, and becomes a "joined node". 261 3.5. Step 4 - Acquiring a RPL rank 263 Because it has learned the link-layer keying material used in the 264 network, the joined node can now decrypt the DIO packets sent by its 265 neighbors. Per [RFC6550], the joined node receives DIOs, computes 266 its own rank, and selects a preferred parent. 268 3.6. Step 5 - 6P ADD to Preferred Parent 270 After having selected a preferred parent, the joined node MUST issue 271 a 6P ADD command to that parent, with the following fields: 273 o CellOptions: set to TX=1,RX=1,SHARED=1 274 o NumCells: set to 1 275 o CellList: at least 5 cells, chosen according to Section 7 277 After the 6P Transaction is finished, the node MUST synchronize only 278 to its preferred parent. At this point, the node has a dedicated 279 cell which allows for bidirectional communication with its preferred 280 parent. 282 3.7. Step 6 - Send EBs and DIOs 284 The node SHOULD start sending EBs and DIOs on the minimal cell, while 285 following the transmit rules for broadcast frames from Section 2. 287 3.8. Step 7 - Neighbor Polling 289 The node SHOULD send some form of keep-alive messages to all its 290 neighbors it has dedicated cells with. The Keep-Alive (KA) mechanism 291 is detailed in [RFC7554]. It uses the keep-alive messages to its 292 preferred parent to stay synchronized. It uses the keep-alive 293 messages to its children (with which it has a dedicated cell to, 294 which the child has created) to ensure the child is still reachable. 295 The RECOMMENDED period for sending keep-alive messages is KA_PERIOD. 297 If the keep-alive message to a child fails at the link layer (i.e. 298 the maximum number of link-layer retries is reached), the node SHOULD 299 declare the child as unreachable. This can happen for example when 300 the child node is switched off. 302 When a neighbor is declared unreachable, the node MUST issue a 6P 303 CLEAR to that neighbor (which can fail at the link-layer), and MUST 304 remove all dedicated links with that neighbor from its own schedule. 306 3.9. End State 308 For a new node, the end state of the joining process is: 310 o it is synchronized to the network 311 o it is using the link-layer keying material it learned through the 312 secure joining process 313 o it has identified its preferred routing parent 314 o it has a single dedicated cell to its preferred routing parent 315 o it is periodically sending DIOs, potentially serving as a router 316 for other nodes' traffic 317 o it is periodically sending EBs, potentially serving as a JP for 318 new joining nodes 320 4. Rules for Adding/Deleting Cells 322 Once a node has joined the 6TiSCH network, it adds/deletes/relocates 323 cells with its preferred parent for three reasons: 325 o to match the link-layer resources to the traffic between the node 326 and its preferred parent (Section 4.1) 327 o to handle switching preferred parent (Section 4.2) 328 o to handle a schedule collision (Section 4.3) 330 4.1. Adapting to Traffic 332 A node implementing MSF MUST implement the behavior described in this 333 section. 335 The goal of MSF is to manage the communication schedule in the 6TiSCH 336 schedule in a distributed manner. For a node, this translates into 337 monitoring the current usage of the cells it has to its preferred 338 parent: 340 o If the node determines that the number of link-layer frames it is 341 attempting to exchange with its preferred parent per unit of time 342 is larger than the capacity offered by the TSCH cells it has 343 scheduled with it, it triggers a 6P Transaction with its preferred 344 parent to add cells to the TSCH schedule of both nodes. 345 o If the traffic is lower than the capacity, the node triggers a 6P 346 Transaction with its preferred parent to delete cells from the 347 TSCH schedule of both nodes. 349 From the join process, the node already has one dedicated cell 350 scheduled to its preferred parent. A node MUST NOT remove all cells 351 to its preferred parent, i.e. there must always be at least one 352 dedicated cell scheduled between a node and its preferred parent, 353 even if no frames are being exchanged between them. 355 Adding/removing/relocating cells involves exchanging frames that 356 contain 6P commands. Once the first cell has been established as 357 part of the join process, all 6P frames MUST be sent on the dedicated 358 cells (not the minimal cell). 360 The node MUST maintain the following counters for its preferred 361 parent: 363 NumCellsPassed: Counts the number of dedicated cells that have 364 passed since the counter was initialized. This counter is 365 initialized at 0. Each time the TSCH state machine indicates the 366 current cell is a dedicated cell to the preferred parent, 367 NumCellsPassed is incremented by exactly 1. 368 NumCellsUsed: Counts the number of dedicated cells that have been 369 used. This counter is initialized at 0. NumCellsUsed is 370 incremented by exactly 1 when, during a dedicated cell to the 371 preferred parent, either of the following happens: 373 * The node sends a frame to its preferred parent. The counter 374 increments regardless of whether a link-layer acknowledgment 375 was received or not. 376 * The node receives a frame from its preferred parent. 378 Implementors MAY choose to create the same counters for each 379 neighbor, and add them as additional statistics in the neighbor 380 table. 382 The counters are used as follows: 384 1. Both NumCellsPassed and NumCellsUsed are initialized to 0 when 385 the node boots. 386 2. When the value of NumCellsPassed reaches MAX_NUMCELLS: 388 * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a 389 single cell to the preferred parent 390 * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a 391 single cell to the preferred parent 392 * Reset both NumCellsPassed and NumCellsUsed to 0 and go to step 393 2. 395 4.2. Switching Parent 397 A node implementing MSF MUST implement the behavior described in this 398 section. 400 Part of its normal operation, the RPL routing protocol can have a 401 node switch preferred parents. The procedure for switching from the 402 old preferred parent to the new preferred parent is: 404 1. the node counts the number of dedicated cells it has per 405 slotframe to the old preferred parent 406 2. the node triggers one or more 6P ADD commands to schedule the 407 same number of dedicated cells to the new preferred parent 408 3. when that successfully completes, the node issues a 6P CLEAR 409 command to its old preferred parent 411 4.3. Handling Schedule Collisions 413 A node implementing MSF SHOULD implement the behavior described in 414 this section. The "MUST" statements in this section hence only apply 415 if the node implements schedule collision handling. 417 Since scheduling is entirely distributed, there is a non-zero 418 probability that two pairs of nearby neighbor nodes schedule a cell 419 at the same [slotOffset,channelOffset] location in the TSCH schedule. 420 In that case, data exchanged by the two pairs may collide on that 421 cell. We call this case a "schedule collision". 423 The node MUST maintain the following counters for each cell to its 424 preferred parent: 426 NumTx: Counts the number of transmission attempts on that cell. 427 Each time the node attempts to transmit a frame on that cell, 428 NumTx is incremented by exactly 1. 429 NumTxAck: Counts the number of successful transmission attempts on 430 that cell. Each time the node receives an acknowledgment for a 431 transmission attempt, NumTxAck is incremented by exactly 1. 433 Implementors MAY choose to maintain the same counters for each cell 434 in the schedule. 436 Since both NumTx and NumTxAck are initialized to 0, we necessarily 437 have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the 438 ratio NumTxAck/NumTx; and represent it as a percentage. A cell with 439 PDR=50% means that half of the frames transmitted are not 440 acknowledged (and need to be retransmitted). 442 Each time the node switches preferred parent (or during the join 443 process when the node selects a preferred parent for the first time), 444 both NumTx and NumTxAck MUST be reset to 0. They increment over 445 time, as the schedule is executed and the node sends frames to its 446 preferred parent. When NumTx reaches 256, both NumTx and NumTxAck 447 MUST be divided by 2. That is, for example, from NumTx=256 and 448 NumTxAck=128, they become NumTx=128 and NumTxAck=64. This operation 449 does not change the value of the PDR, but allows the counters to keep 450 incrementing. 452 The key for detecting a schedule collision is that, if a node has 453 several cells to the same preferred parent, all cells should exhibit 454 the same PDR. A cell which exhibits a PDR significantly worse than 455 the others indicates than there are collisions on that cell. 457 Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following 458 steps: 460 1. It aborts this series of steps if NumTx hasn't been divided by 2 461 since it was last reset. This avoids triggering cell relocation 462 when the values of NumTx and NumTxAck are not statistically 463 significant yet. 464 2. It computes, for each cell with its preferred parent, that cell's 465 PDR. 466 3. It identifies the cell with the highest PDR. 467 4. For each other cell, it compare its PDR against that of the cell 468 with the highest PDR. If it's less than RELOCATE_PDRTHRES, it 469 triggers the relocation of that cell using a 6P RELOCATE command. 471 5. 6P SIGNAL command 473 The 6P SIGNAL command is not used by MSF. 475 6. Scheduling Function Identifier 477 The Scheduling Function Identifier (SFID) of MSF is 478 IANA_6TISCH_SFID_MSF. 480 7. Rules for CellList 482 MSF uses 2-step 6P Transactions exclusively. 6P Transactions are 483 only initiated by a node towards it preferred parent. As a result, 484 the cells to put in the CellList of a 6P ADD command, and in the 485 candidate CellList of a RELOCATE command, are chosen by the node. In 486 both cases, the same rules apply: 488 the CellList SHOULD contain 5 or more cells. 489 Each cell in the CellList MUST have a different slotOffset value. 490 For each cell in the CellList, the node MUST NOT have any 491 scheduled cell on the same slotOffset. 492 The slotOffset value of any cell in the CellList MUST NOT be the 493 same as the slotOffset of the minimal cell (slotOffset=0). 494 The slotOffset of a cell in the CellList SHOULD be randomly and 495 uniformly chosen among all the slotOffset values that satisfy the 496 restriction above. 497 The channelOffset of a cell in the CellList SHOULD be randomly and 498 uniformly in [0..numFrequencies] where numFrequencies represents 499 the number of frequencies a node can communicate on. 501 8. 6P Timeout Value 503 The 6P Timeout is not a constant value. It is calculated a (C/ 504 PDR)*6PTIMEOUT_SEC_FACTOR, where: 506 o C represents the number of cells per second scheduled to that 507 neighbor 508 o PDR represents the average PDR of those cells 509 o 6PTIMEOUT_SEC_FACTOR is a security factor, a constant 511 9. Rule for Ordering Cells 513 Cells are ordered slotOffset first, channelOffset second. 515 The following sequence is correctly ordered (each element represents 516 the [slottOffset,channelOffset] of a cell in the schedule): 518 [1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9] 520 10. Meaning of the Metadata Field 522 The Metadata field is not used by MSF. 524 11. 6P Error Handling 526 Section 6.2.4 of [I-D.ietf-6tisch-6top-protocol] lists the 6P Return 527 Codes. Figure 1 lists the same error codes, and the behavior a node 528 implementing MSF SHOULD follow. 530 +-------------+----------------------+ 531 | Code | RECOMMENDED behavior | 532 +-------------+----------------------+ 533 | RC_SUCCESS | nothing | 534 | RC_EOL | nothing | 535 | RC_ERROR | quarantine | 536 | RC_RESET | quarantine | 537 | RC_VERSION | quarantine | 538 | RC_SFID | quarantine | 539 | RC_SEQNUM | clear | 540 | RC_CELLLIST | clear | 541 | RC_BUSY | waitretry | 542 | RC_LOCKED | waitretry | 543 +-------------+----------------------+ 545 Figure 1: Recommended behavior for each 6P Error Code. 547 The meaning of each behavior from Figure 1 is: 549 nothing: Indicates that this Return Code is not an error. No error 550 handling behavior is hence triggered. 551 clear: Abort the 6P Transaction. Issue a 6P CLEAR command to that 552 neighbor (this command may fail). Remove all cells scheduled 553 with that neighbor from the local schedule. Keep that node in 554 the neighbor and routing tables. 555 quarantine: Same behavior as for "clear". In addition, remove the 556 node from the neighbor and routing tables. Place the node's 557 identifier in a quarantine list for QUARANTINE_DURATION. When in 558 quarantine, drop all frames received from that node. 559 waitretry: Abort the 6P Transaction. Wait for a duration randomly 560 and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX]. 561 Retry the same transaction. 563 12. Schedule Inconsistency Handling 565 The behavior when schedule inconsistency is detected is explained in 566 Figure 1, for 6P Return Code RC_SEQNUM. 568 13. MSF Constants 570 Figure 2 lists MSF Constants and their RECOMMENDED values. 572 +------------------------------+-------------------+ 573 | Name | RECOMMENDED value | 574 +------------------------------+-------------------+ 575 | KA_PERIOD | 10 s | 576 | LIM_NUMCELLSUSED_HIGH | 75 % | 577 | LIM_NUMCELLSUSED_LOW | 25 % | 578 | HOUSEKEEPINGCOLLISION_PERIOD | 1 min | 579 | RELOCATE_PDRTHRES | 50 % | 580 | 6PTIMEOUT_SEC_FACTOR | 3 x | 581 | SLOTFRAME_LENGTH | 101 slots | 582 | QUARANTINE_DURATION | 5 min | 583 | WAITDURATION_MIN | 30 s | 584 | WAITDURATION_MAX | 60 s | 585 +------------------------------+-------------------+ 587 Figure 2: MSF Constants and their RECOMMENDED values. 589 14. MSF Statistics 591 Figure 3 lists MSF Statistics and their RECOMMENDED width. 593 +-----------------+-------------------+ 594 | Name | RECOMMENDED width | 595 +-----------------+-------------------+ 596 | NumCellsPassed | 1 byte | 597 | NumCellsUsed | 1 byte | 598 | NumTx | 1 byte | 599 | NumTxAck | 1 byte | 600 +-----------------+-------------------+ 602 Figure 3: MSF Statistics and their RECOMMENDED width. 604 15. Security Considerations 606 MSF defines a series of "rules" for the node to follow. It triggers 607 several actions, that are carried out by the protocols defined in the 608 following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 609 802.15.4e (6TiSCH) Configuration [RFC8180], the 6top Protocol (6P) 610 [I-D.ietf-6tisch-6top-protocol], and the Minimal Security Framework 611 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF 612 does not define a new protocol or packet format. 614 MSF relies entirely on the security mechanisms defined in the 615 specifications listed above. 617 16. IANA Considerations 619 16.1. MSF Scheduling Function Identifiers 621 This document adds the following number to the "6P Scheduling 622 Function Identifiers" sub-registry, part of the "IPv6 over the TSCH 623 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by 624 [I-D.ietf-6tisch-6top-protocol]: 626 +----------------------+-----------------------------+-------------+ 627 | SFID | Name | Reference | 628 +----------------------+-----------------------------+-------------+ 629 | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX | 630 | | (MSF) | (NOTE:this) | 631 +----------------------+-----------------------------+-------------+ 633 Figure 4: IETF IE Subtype '6P'. 635 17. References 637 17.1. Normative References 639 [I-D.ietf-6tisch-6top-protocol] 640 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 641 (6P)", draft-ietf-6tisch-6top-protocol-09 (work in 642 progress), October 2017. 644 [I-D.ietf-6tisch-minimal-security] 645 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 646 "Minimal Security Framework for 6TiSCH", draft-ietf- 647 6tisch-minimal-security-04 (work in progress), October 648 2017. 650 [I-D.richardson-6tisch-join-enhanced-beacon] 651 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 652 Element encapsulation of 6tisch Join Information", draft- 653 richardson-6tisch-join-enhanced-beacon-02 (work in 654 progress), July 2017. 656 [IEEE802154-2015] 657 IEEE standard for Information Technology, "IEEE Std 658 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 659 Networks (WPANs)", December 2015. 661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 662 Requirement Levels", BCP 14, RFC 2119, 663 DOI 10.17487/RFC2119, March 1997, 664 . 666 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 667 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 668 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 669 Low-Power and Lossy Networks", RFC 6550, 670 DOI 10.17487/RFC6550, March 2012, 671 . 673 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 674 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 675 Internet of Things (IoT): Problem Statement", RFC 7554, 676 DOI 10.17487/RFC7554, May 2015, 677 . 679 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 680 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 681 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 682 May 2017, . 684 17.2. Informative References 686 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 687 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 688 a Standards-Based Low-Power Wireless Development 689 Environment", Transactions on Emerging Telecommunications 690 Technologies , August 2012. 692 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 693 Code: The Implementation Status Section", RFC 6982, 694 DOI 10.17487/RFC6982, July 2013, 695 . 697 Appendix A. Implementation Status 699 This section records the status of known implementations of the 700 protocol defined by this specification at the time of posting of this 701 Internet-Draft, and is based on a proposal described in [RFC6982]. 702 The description of implementations in this section is intended to 703 assist the IETF in its decision processes in progressing drafts to 704 RFCs. Please note that the listing of any individual implementation 705 here does not imply endorsement by the IETF. Furthermore, no effort 706 has been spent to verify the information presented here that was 707 supplied by IETF contributors. This is not intended as, and must not 708 be construed to be, a catalog of available implementations or their 709 features. Readers are advised to note that other implementations may 710 exist. 712 According to [RFC6982], "this will allow reviewers and working groups 713 to assign due consideration to documents that have the benefit of 714 running code, which may serve as evidence of valuable experimentation 715 and feedback that have made the implemented protocols more mature. 716 It is up to the individual working groups to use this information as 717 they see fit". 719 OpenWSN: MSF is being implemented in the OpenWSN project [OpenWSN] 720 under a BSD open-source license. The authors of this document are 721 collaborating with the OpenWSN community to gather feedback about 722 the status and performance of the protocols described in this 723 document. Results from that discussion will appear in this 724 section in future revision of this specification. More 725 information about this implementation at http://www.openwsn.org/. 726 6TiSCH simulator The 6TiSCH simulator is a Python-based high-level 727 simulator on which MSF is being implemented. More information at 728 https://bitbucket.org/6tisch/simulator/. 730 Appendix B. Performance Evaluation 732 The performance of MSF may be published as companion documents to 733 this specification, possibly under the form a applicability 734 statements. 736 Appendix C. [TEMPORARY] Changelog 738 o draft-chang-6tisch-msf-00 740 * Initial submission. 742 Authors' Addresses 744 Tengfei Chang (editor) 745 Inria 746 2 rue Simone Iff 747 Paris 75012 748 France 750 Email: tengfei.chang@inria.fr 752 Malisa Vucinic 753 University of Montenegro 754 Dzordza Vasingtona bb 755 Podgorica 81000 756 Montenegro 758 Email: malisav@ac.me 759 Xavier Vilajosana 760 Universitat Oberta de Catalunya 761 156 Rambla Poblenou 762 Barcelona, Catalonia 08018 763 Spain 765 Email: xvilajosana@uoc.edu