idnits 2.17.1 draft-chang-6tisch-msf-01.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 (March 1, 2018) is 2220 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 520 -- Looks like a reference, but probably isn't: '3' on line 520 -- Looks like a reference, but probably isn't: '4' on line 520 -- Looks like a reference, but probably isn't: '2' on line 520 -- Looks like a reference, but probably isn't: '0' on line 520 -- Looks like a reference, but probably isn't: '5' on line 520 -- Looks like a reference, but probably isn't: '6' on line 520 -- Looks like a reference, but probably isn't: '7' on line 520 -- Looks like a reference, but probably isn't: '9' on line 520 == Missing Reference: 'TEMPORARY' is mentioned on line 738, 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 ** 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 Inria 4 Intended status: Standards Track M. Vucinic 5 Expires: September 2, 2018 University of Montenegro 6 X. Vilajosana 7 Universitat Oberta de Catalunya 8 March 1, 2018 10 6TiSCH Minimal Scheduling Function (MSF) 11 draft-chang-6tisch-msf-01 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 September 2, 2018. 45 Copyright Notice 47 Copyright (c) 2018 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 root). Appendix B contains a performance evaluation 131 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 sent between the 161 pledge and the Join Proxy, defined by 162 [I-D.ietf-6tisch-minimal-security]. These are unicast frames. 163 4. 6P packets to schedule the first dedicated cell with a neighbor. 164 These are unicast frames. 166 Because the minimal cell is SHARED, the back-off algorithm defined in 167 [IEEE802154-2015] is used to resolve collisions. To ensure there is 168 enough bandwidth available on the minimal cell for the unicast 169 traffic, a node implementing MSF SHOULD enforce the following rules 170 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 3.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 MUST be the same value. The default of 189 SLOTFRAME_LENGTH is RECOMMENDED, although any value can be advertised 190 in the EBs. 192 3. Node Behavior at Boot 194 This section details the behavior the node SHOULD follow from the 195 moment it is switched on, until it has successfully joined the 196 network. Section 3.1 details the start state; Section 3.9 details 197 the end state. The other sections detail the 7 steps of the joining 198 process. We use the term "pledge" and "joined node", as defined in 199 [I-D.ietf-6tisch-minimal-security]. 201 3.1. Start State 203 A node implementing MSF MUST implement the Minimal Security Framework 204 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this 205 means that a pledge, before being switched on, is pre-configured with 206 the Pre-Shared Key (PSK) for joining, as well as any other 207 configuration detailed in [I-D.ietf-6tisch-minimal-security]. 209 3.2. Step 1 - Choosing Frequency 211 When switched on, the pledge SHOULD randomly choose a frequency among 212 the available frequencies, and start listening for EBs on that 213 frequency. 215 3.3. Step 2 - Receiving EBs 217 Upon receiving the first EB, the pledge SHOULD continue listening for 218 additional EBs to learn: 220 1. the number of neighbors N in its vicinity 221 2. which neighbor to choose as a Join Proxy (JP) for the joining 222 process 224 While the exact behavior is implementation-specific, the RECOMMENDED 225 behavior is to follow [RFC8180], and listen until EBs sent by 226 NUM_NEIGHBOURS_TO_WAIT nodes (defined in [RFC8180]) have been 227 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 remove all 303 dedicated cells with that neighbor from its own schedule. In 304 addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at 305 the link-layer). 307 3.9. End State 309 For a new node, the end state of the joining process is: 311 o it is synchronized to the network 312 o it is using the link-layer keying material it learned through the 313 secure joining process 314 o it has identified its preferred routing parent 315 o it has a single dedicated cell to its preferred routing parent 316 o it is periodically sending DIOs, potentially serving as a router 317 for other nodes' traffic 318 o it is periodically sending EBs, potentially serving as a JP for 319 new joining nodes 321 4. Rules for Adding/Deleting Cells 323 Once a node has joined the 6TiSCH network, it adds/deletes/relocates 324 cells with its preferred parent for three reasons: 326 o to match the link-layer resources to the traffic between the node 327 and its preferred parent (Section 4.1) 328 o to handle switching preferred parent (Section 4.2) 329 o to handle a schedule collision (Section 4.3) 331 4.1. Adapting to Traffic 333 A node implementing MSF MUST implement the behavior described in this 334 section. 336 The goal of MSF is to manage the communication schedule in the 6TiSCH 337 schedule in a distributed manner. For a node, this translates into 338 monitoring the current usage of the cells it has to its preferred 339 parent: 341 o If the node determines that the number of link-layer frames it is 342 attempting to exchange with its preferred parent per unit of time 343 is larger than the capacity offered by the TSCH cells it has 344 scheduled with it, it triggers a 6P Transaction with its preferred 345 parent to add cells to the TSCH schedule of both nodes. 346 o If the traffic is lower than the capacity, the node triggers a 6P 347 Transaction with its preferred parent to delete cells from the 348 TSCH schedule of both nodes. 350 From the join process, the node already has one dedicated cell 351 scheduled to its preferred parent. A node MUST NOT remove all cells 352 to its preferred parent, i.e. there must always be at least one 353 dedicated cell scheduled between a node and its preferred parent, 354 even if no frames are being exchanged between them. 356 Adding/removing/relocating cells involves exchanging frames that 357 contain 6P commands. Once the first cell has been established as 358 part of the join process, all 6P frames MUST be sent on the dedicated 359 cells (not the minimal cell). 361 The node MUST maintain the following counters for its preferred 362 parent: 364 NumCellsPassed: Counts the number of dedicated cells that have 365 passed since the counter was initialized. This counter is 366 initialized at 0. Each time the TSCH state machine indicates the 367 current cell is a dedicated cell to the preferred parent, 368 NumCellsPassed is incremented by exactly 1, regardless of whether 369 the cell is used to transmit/receive a frame. 370 NumCellsUsed: Counts the number of dedicated cells that have been 371 used. This counter is initialized at 0. NumCellsUsed is 372 incremented by exactly 1 when, during a dedicated cell to the 373 preferred parent, either of the following happens: 375 * The node sends a frame to its preferred parent. The counter 376 increments regardless of whether a link-layer acknowledgment 377 was received or not. 378 * The node receives a frame from its preferred parent. 380 Implementors MAY choose to create the same counters for each 381 neighbor, and add them as additional statistics in the neighbor 382 table. 384 The counters are used as follows: 386 1. Both NumCellsPassed and NumCellsUsed are initialized to 0 when 387 the node boots. 388 2. When the value of NumCellsPassed reaches MAX_NUMCELLS: 390 * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a 391 single cell to the preferred parent 392 * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a 393 single cell to the preferred parent 394 * Reset both NumCellsPassed and NumCellsUsed to 0 and go to step 395 2. 397 4.2. Switching Parent 399 A node implementing MSF MUST implement the behavior described in this 400 section. 402 Part of its normal operation, the RPL routing protocol can have a 403 node switch preferred parents. The procedure for switching from the 404 old preferred parent to the new preferred parent is: 406 1. the node counts the number of dedicated cells it has per 407 slotframe to the old preferred parent 408 2. the node triggers one or more 6P ADD commands to schedule the 409 same number of dedicated cells to the new preferred parent 410 3. when that successfully completes, the node issues a 6P CLEAR 411 command to its old preferred parent 413 4.3. Handling Schedule Collisions 415 A node implementing MSF SHOULD implement the behavior described in 416 this section. The "MUST" statements in this section hence only apply 417 if the node implements schedule collision handling. 419 Since scheduling is entirely distributed, there is a non-zero 420 probability that two pairs of nearby neighbor nodes schedule a cell 421 at the same [slotOffset,channelOffset] location in the TSCH schedule. 422 In that case, data exchanged by the two pairs may collide on that 423 cell. We call this case a "schedule collision". 425 The node MUST maintain the following counters for each cell to its 426 preferred parent: 428 NumTx: Counts the number of transmission attempts on that cell. 429 Each time the node attempts to transmit a frame on that cell, 430 NumTx is incremented by exactly 1. 431 NumTxAck: Counts the number of successful transmission attempts on 432 that cell. Each time the node receives an acknowledgment for a 433 transmission attempt, NumTxAck is incremented by exactly 1. 435 Implementors MAY choose to maintain the same counters for each cell 436 in the schedule. 438 Since both NumTx and NumTxAck are initialized to 0, we necessarily 439 have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the 440 ratio NumTxAck/NumTx; and represent it as a percentage. A cell with 441 PDR=50% means that half of the frames transmitted are not 442 acknowledged (and need to be retransmitted). 444 Each time the node switches preferred parent (or during the join 445 process when the node selects a preferred parent for the first time), 446 both NumTx and NumTxAck MUST be reset to 0. They increment over 447 time, as the schedule is executed and the node sends frames to its 448 preferred parent. When NumTx reaches 256, both NumTx and NumTxAck 449 MUST be divided by 2. That is, for example, from NumTx=256 and 450 NumTxAck=128, they become NumTx=128 and NumTxAck=64. This operation 451 does not change the value of the PDR, but allows the counters to keep 452 incrementing. 454 The key for detecting a schedule collision is that, if a node has 455 several cells to the same preferred parent, all cells should exhibit 456 the same PDR. A cell which exhibits a PDR significantly lower than 457 the others indicates than there are collisions on that cell. 459 Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following 460 steps: 462 1. It computes, for each cell with its preferred parent, that cell's 463 PDR. 464 2. Any cell that hasn't yet had NumTx divided by 2 since it was last 465 reset is skipped in steps 3 and 4. This avoids triggering cell 466 relocation when the values of NumTx and NumTxAck are not 467 statistically significant yet. 468 3. It identifies the cell with the highest PDR. 469 4. For each other cell, it compares its PDR against that of the cell 470 with the highest PDR. If it's less than RELOCATE_PDRTHRES, it 471 triggers the relocation of that cell using a 6P RELOCATE command. 473 5. 6P SIGNAL command 475 The 6P SIGNAL command is not used by MSF. 477 6. Scheduling Function Identifier 479 The Scheduling Function Identifier (SFID) of MSF is 480 IANA_6TISCH_SFID_MSF. 482 7. Rules for CellList 484 MSF uses 2-step 6P Transactions exclusively. 6P Transactions are 485 only initiated by a node towards it preferred parent. As a result, 486 the cells to put in the CellList of a 6P ADD command, and in the 487 candidate CellList of a RELOCATE command, are chosen by the node 488 initiating the 6P Transaction. In both cases, the same rules apply: 490 o the CellList SHOULD contain 5 or more cells. 491 o Each cell in the CellList MUST have a different slotOffset value. 492 o For each cell in the CellList, the node MUST NOT have any 493 scheduled cell on the same slotOffset. 494 o The slotOffset value of any cell in the CellList MUST NOT be the 495 same as the slotOffset of the minimal cell (slotOffset=0). 496 o The slotOffset of a cell in the CellList SHOULD be randomly and 497 uniformly chosen among all the slotOffset values that satisfy the 498 restrictions above. 499 o The channelOffset of a cell in the CellList SHOULD be randomly and 500 uniformly chosen in [0..numFrequencies], where numFrequencies 501 represents the number of frequencies a node can communicate on. 503 8. 6P Timeout Value 505 The 6P Timeout is not a constant value. It is calculated as 506 (1/C)*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR, where: 508 o C represents the number of cells per second scheduled to that 509 neighbor 510 o PDR represents the average PDR of those cells 511 o SIXP_TIMEOUT_SEC_FACTOR is a security factor, a constant 513 9. Rule for Ordering Cells 515 Cells are ordered slotOffset first, channelOffset second. 517 The following sequence is correctly ordered (each element represents 518 the [slottOffset,channelOffset] of a cell in the schedule): 520 [1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9] 522 10. Meaning of the Metadata Field 524 The Metadata field is not used by MSF. 526 11. 6P Error Handling 528 Section 6.2.4 of [I-D.ietf-6tisch-6top-protocol] lists the 6P Return 529 Codes. Figure 1 lists the same error codes, and the behavior a node 530 implementing MSF SHOULD follow. 532 +-----------------+----------------------+ 533 | Code | RECOMMENDED behavior | 534 +-----------------+----------------------+ 535 | RC_SUCCESS | nothing | 536 | RC_EOL | nothing | 537 | RC_ERR | quarantine | 538 | RC_RESET | quarantine | 539 | RC_ERR_VERSION | quarantine | 540 | RC_ERR_SFID | quarantine | 541 | RC_ERR_SEQNUM | clear | 542 | RC_ERR_CELLLIST | clear | 543 | RC_ERR_BUSY | waitretry | 544 | RC_ERR_LOCKED | waitretry | 545 +-----------------+----------------------+ 547 Figure 1: Recommended behavior for each 6P Error Code. 549 The meaning of each behavior from Figure 1 is: 551 nothing: Indicates that this Return Code is not an error. No error 552 handling behavior is hence triggered. 553 clear: Abort the 6P Transaction. Issue a 6P CLEAR command to that 554 neighbor (this command may fail at the link layer). Remove all 555 cells scheduled with that neighbor from the local schedule. Keep 556 that node in the neighbor and routing tables. 557 quarantine: Same behavior as for "clear". In addition, remove the 558 node from the neighbor and routing tables. Place the node's 559 identifier in a quarantine list for QUARANTINE_DURATION. When in 560 quarantine, drop all frames received from that node. 561 waitretry: Abort the 6P Transaction. Wait for a duration randomly 562 and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX]. 563 Retry the same transaction. 565 12. Schedule Inconsistency Handling 567 The behavior when schedule inconsistency is detected is explained in 568 Figure 1, for 6P Return Code RC_ERR_SEQNUM. 570 13. MSF Constants 572 Figure 2 lists MSF Constants and their RECOMMENDED values. 574 +------------------------------+-------------------+ 575 | Name | RECOMMENDED value | 576 +------------------------------+-------------------+ 577 | KA_PERIOD | 10 s | 578 | LIM_NUMCELLSUSED_HIGH | 75 % | 579 | LIM_NUMCELLSUSED_LOW | 25 % | 580 | HOUSEKEEPINGCOLLISION_PERIOD | 1 min | 581 | RELOCATE_PDRTHRES | 50 % | 582 | SIXP_TIMEOUT_SEC_FACTOR | 3 x | 583 | SLOTFRAME_LENGTH | 101 slots | 584 | QUARANTINE_DURATION | 5 min | 585 | WAITDURATION_MIN | 30 s | 586 | WAITDURATION_MAX | 60 s | 587 +------------------------------+-------------------+ 589 Figure 2: MSF Constants and their RECOMMENDED values. 591 14. MSF Statistics 593 Figure 3 lists MSF Statistics and their RECOMMENDED width. 595 +-----------------+-------------------+ 596 | Name | RECOMMENDED width | 597 +-----------------+-------------------+ 598 | NumCellsPassed | 1 byte | 599 | NumCellsUsed | 1 byte | 600 | NumTx | 1 byte | 601 | NumTxAck | 1 byte | 602 +-----------------+-------------------+ 604 Figure 3: MSF Statistics and their RECOMMENDED width. 606 15. Security Considerations 608 MSF defines a series of "rules" for the node to follow. It triggers 609 several actions, that are carried out by the protocols defined in the 610 following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 611 802.15.4e (6TiSCH) Configuration [RFC8180], the 6top Protocol (6P) 612 [I-D.ietf-6tisch-6top-protocol], and the Minimal Security Framework 613 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF 614 does not define a new protocol or packet format. 616 MSF relies entirely on the security mechanisms defined in the 617 specifications listed above. 619 16. IANA Considerations 621 16.1. MSF Scheduling Function Identifiers 623 This document adds the following number to the "6P Scheduling 624 Function Identifiers" sub-registry, part of the "IPv6 over the TSCH 625 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by 626 [I-D.ietf-6tisch-6top-protocol]: 628 +----------------------+-----------------------------+-------------+ 629 | SFID | Name | Reference | 630 +----------------------+-----------------------------+-------------+ 631 | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX | 632 | | (MSF) | (NOTE:this) | 633 +----------------------+-----------------------------+-------------+ 635 Figure 4: IETF IE Subtype '6P'. 637 17. References 639 17.1. Normative References 641 [I-D.ietf-6tisch-6top-protocol] 642 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 643 (6P)", draft-ietf-6tisch-6top-protocol-09 (work in 644 progress), October 2017. 646 [I-D.ietf-6tisch-minimal-security] 647 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 648 "Minimal Security Framework for 6TiSCH", draft-ietf- 649 6tisch-minimal-security-04 (work in progress), October 650 2017. 652 [I-D.richardson-6tisch-join-enhanced-beacon] 653 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 654 Element encapsulation of 6tisch Join Information", draft- 655 richardson-6tisch-join-enhanced-beacon-03 (work in 656 progress), January 2018. 658 [IEEE802154-2015] 659 IEEE standard for Information Technology, "IEEE Std 660 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 661 Networks (WPANs)", December 2015. 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, 665 DOI 10.17487/RFC2119, March 1997, 666 . 668 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 669 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 670 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 671 Low-Power and Lossy Networks", RFC 6550, 672 DOI 10.17487/RFC6550, March 2012, 673 . 675 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 676 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 677 Internet of Things (IoT): Problem Statement", RFC 7554, 678 DOI 10.17487/RFC7554, May 2015, 679 . 681 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 682 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 683 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 684 May 2017, . 686 17.2. Informative References 688 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 689 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 690 a Standards-Based Low-Power Wireless Development 691 Environment", Transactions on Emerging Telecommunications 692 Technologies , August 2012. 694 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 695 Code: The Implementation Status Section", RFC 6982, 696 DOI 10.17487/RFC6982, July 2013, 697 . 699 Appendix A. Implementation Status 701 This section records the status of known implementations of the 702 protocol defined by this specification at the time of posting of this 703 Internet-Draft, and is based on a proposal described in [RFC6982]. 704 The description of implementations in this section is intended to 705 assist the IETF in its decision processes in progressing drafts to 706 RFCs. Please note that the listing of any individual implementation 707 here does not imply endorsement by the IETF. Furthermore, no effort 708 has been spent to verify the information presented here that was 709 supplied by IETF contributors. This is not intended as, and must not 710 be construed to be, a catalog of available implementations or their 711 features. Readers are advised to note that other implementations may 712 exist. 714 According to [RFC6982], "this will allow reviewers and working groups 715 to assign due consideration to documents that have the benefit of 716 running code, which may serve as evidence of valuable experimentation 717 and feedback that have made the implemented protocols more mature. 718 It is up to the individual working groups to use this information as 719 they see fit". 721 OpenWSN: MSF is being implemented in the OpenWSN project [OpenWSN] 722 under a BSD open-source license. The authors of this document are 723 collaborating with the OpenWSN community to gather feedback about 724 the status and performance of the protocols described in this 725 document. Results from that discussion will appear in this 726 section in future revision of this specification. More 727 information about this implementation at http://www.openwsn.org/. 728 6TiSCH simulator The 6TiSCH simulator is a Python-based high-level 729 simulator on which MSF is being implemented. More information at 730 https://bitbucket.org/6tisch/simulator/. 732 Appendix B. Performance Evaluation 734 The performance of MSF may be published as companion documents to 735 this specification, possibly under the form a applicability 736 statements. 738 Appendix C. [TEMPORARY] Changelog 740 o draft-chang-6tisch-msf-01 742 * When neighbor is unreachable, sending a CLEAR command was a 743 MUST, now a MAY. 744 * Fixing 6P Timeout calculation. 745 * Clearer text for "Handling Schedule Collisions" section. 746 * Typos. 747 * Input from Yasuyuki Tanaka's review (https://www.ietf.org/mail- 748 archive/web/6tisch/current/msg05723.html). 749 o draft-chang-6tisch-msf-00 751 * Initial submission. 753 Authors' Addresses 755 Tengfei Chang (editor) 756 Inria 757 2 rue Simone Iff 758 Paris 75012 759 France 761 Email: tengfei.chang@inria.fr 762 Malisa Vucinic 763 University of Montenegro 764 Dzordza Vasingtona bb 765 Podgorica 81000 766 Montenegro 768 Email: malisav@ac.me 770 Xavier Vilajosana 771 Universitat Oberta de Catalunya 772 156 Rambla Poblenou 773 Barcelona, Catalonia 08018 774 Spain 776 Email: xvilajosana@uoc.edu