idnits 2.17.1 draft-ietf-6tisch-msf-03.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 (April 8, 2019) is 1845 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 567 -- Looks like a reference, but probably isn't: '3' on line 567 -- Looks like a reference, but probably isn't: '4' on line 567 -- Looks like a reference, but probably isn't: '2' on line 567 -- Looks like a reference, but probably isn't: '0' on line 567 -- Looks like a reference, but probably isn't: '5' on line 567 -- Looks like a reference, but probably isn't: '6' on line 567 -- Looks like a reference, but probably isn't: '7' on line 567 -- Looks like a reference, but probably isn't: '9' on line 567 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-dtsecurity-zerotouch-join-03 ** Downref: Normative reference to an Informational draft: draft-ietf-6tisch-dtsecurity-zerotouch-join (ref. 'I-D.ietf-6tisch-dtsecurity-zerotouch-join') == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-10 ** 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' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH T. Chang, Ed. 3 Internet-Draft M. Vucinic 4 Intended status: Standards Track Inria 5 Expires: October 10, 2019 X. Vilajosana 6 Universitat Oberta de Catalunya 7 S. Duquennoy 8 RISE SICS 9 D. Dujovne, Ed. 10 Universidad Diego Portales 11 April 8, 2019 13 6TiSCH Minimal Scheduling Function (MSF) 14 draft-ietf-6tisch-msf-03 16 Abstract 18 This specification defines the 6TiSCH Minimal Scheduling Function 19 (MSF). This Scheduling Function describes both the behavior of a 20 node when joining the network, and how the communication schedule is 21 managed in a distributed fashion. MSF builds upon the 6TiSCH 22 Operation Sublayer Protocol (6P) and the Minimal Security Framework 23 for 6TiSCH. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in 30 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 10, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Interface to the Minimal 6TiSCH Configuration . . . . . . . . 4 68 3. Autonomous Cells . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Step 1 - Choosing Frequency . . . . . . . . . . . . . . . 6 72 4.3. Step 2 - Receiving EBs . . . . . . . . . . . . . . . . . 6 73 4.4. Step 3 - Setting up Autonomous Cells for the Join Process 7 74 4.5. Step 4 - Acquiring a RPL rank . . . . . . . . . . . . . . 7 75 4.6. Step 5 - Setting up Autonomous Cells for 6P . . . . . . . 7 76 4.7. Step 6 - Send EBs and DIOs . . . . . . . . . . . . . . . 8 77 4.8. End State . . . . . . . . . . . . . . . . . . . . . . . . 8 78 5. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 8 79 5.1. Adapting to Traffic . . . . . . . . . . . . . . . . . . . 8 80 5.2. Switching Parent . . . . . . . . . . . . . . . . . . . . 10 81 5.3. Handling Schedule Collisions . . . . . . . . . . . . . . 10 82 6. 6P SIGNAL command . . . . . . . . . . . . . . . . . . . . . . 11 83 7. Scheduling Function Identifier . . . . . . . . . . . . . . . 11 84 8. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 12 85 9. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 12 86 10. Rule for Ordering Cells . . . . . . . . . . . . . . . . . . . 12 87 11. Meaning of the Metadata Field . . . . . . . . . . . . . . . . 12 88 12. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 13 89 13. Schedule Inconsistency Handling . . . . . . . . . . . . . . . 13 90 14. MSF Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 91 15. MSF Statistics . . . . . . . . . . . . . . . . . . . . . . . 14 92 16. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 94 17.1. MSF Scheduling Function Identifiers . . . . . . . . . . 15 95 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 18.1. Normative References . . . . . . . . . . . . . . . . . . 15 97 18.2. Informative References . . . . . . . . . . . . . . . . . 16 98 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 99 Appendix B. Example of Implementation of SAX hash function . . . 16 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 102 1. Introduction 104 The 6TiSCH Minimal Scheduling Function (MSF), defined in this 105 specification, is a 6TiSCH Scheduling Function (SF). The role of an 106 SF is entirely defined in [RFC8480]. This specification complements 107 [RFC8480] by providing the rules of when to add/delete cells in the 108 communication schedule. This specification satisfies all the 109 requirements for an SF listed in Section 4.2 of [RFC8480]. 111 MSF builds on top of the following specifications: the Minimal IPv6 112 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration 113 [RFC8180], the 6TiSCH Operation Sublayer Protocol (6P) [RFC8480], and 114 the Minimal Security Framework for 6TiSCH 115 [I-D.ietf-6tisch-minimal-security]. 117 MSF defines both the behavior of a node when joining the network, and 118 how the communication schedule is managed in a distributed fashion. 119 When a node running MSF boots up, it joins the network by following 120 the 7 steps described in Section 4. The end state of the join 121 process is that the node is synchronized to the network, has mutually 122 authenticated to the network, has identified a preferred routing 123 parent, and has scheduled one default managed cell (defined in 124 Section 5.1) to/from its preferred routing parent. After the join 125 process, the node can continuously add/delete/relocate cells, as 126 described in Section 5. It does so for 3 reasons: to match the link- 127 layer resources to the traffic, to handle changing parent, to handle 128 a schedule collision. 130 MSF is designed to operate in a wide range of application domains. 131 It is optimized for applications with regular upstream traffic (from 132 the nodes to the root). 134 This specification follows the recommended structure of an SF 135 specification, given in Appendix A of [RFC8480], with the following 136 adaptations: 138 o We have reordered some sections, in particular to have the section 139 on the node behavior at boot (Section 4) appear early in this 140 specification. 141 o We added sections on the interface to the minimal 6TiSCH 142 configuration (Section 2), the use of the SIGNAL command 143 (Section 6), the MSF constants (Section 14), the MSF statistics 144 (Section 15). 146 o This specification does not include an examples section. 148 2. Interface to the Minimal 6TiSCH Configuration 150 A node implementing MSF SHOULD implement the Minimal 6TiSCH 151 Configuration [RFC8180], which defines the "minimal cell", a single 152 shared cell providing minimal connectivity between the nodes in the 153 network. The MSF implementation provided in this specification is 154 based on the implementation of the Minimal 6TiSCH Configuration. 155 However, an implementor MAY implements MSF without implementing 156 Minimal 6TiSCH Configuration. 158 MSF uses the minimal cell to exchange the following packets: 160 1. Enhanced Beacons (EBs), defined by [IEEE802154-2015]. These are 161 broadcast frames. 162 2. Boradcast DODAG Information Objects (DIOs), defined by [RFC6550]. 163 Unicast DIOs SHOULD NOT be sent on minimal cell. 165 Because the minimal cell is SHARED, the back-off algorithm defined in 166 [IEEE802154-2015] is used to resolve collisions. To ensure there is 167 enough bandwidth available on the minimal cell, a node implementing 168 MSF SHOULD enforce some rules for limiting the traffic of broadcast 169 frames. For example, a Trickle Timer defined in [RFC6550] MAY be 170 applied on DIOs. However, this behvaior is implementation-specific 171 which is out of the scope of MSF. 173 As detailed in Section 2.2 of [RFC8480], MSF MUST schedule cells from 174 Slotframe 1, while Slotframe 0 is used for traffic defined in the 175 Minimal 6TiSCH Configuration. The length of Slotframe 0 and 176 Slotframe 1 SHOULD be the same value. The default of 177 SLOTFRAME_LENGTH is RECOMMENDED for both Slotframe 0 and Slotframe 1, 178 although any value can be advertised in the EBs. 180 3. Autonomous Cells 182 MSF nodes initialize Slotframe 1 with a set of default cells for 183 unicast communication with their neighbors. These cells are called 184 'autonomous cells', because they are maintained autonomously by each 185 node. Cells scheduled by 6P transaction are called 'managed cells'. 186 How to schedule managed cells is detailed in Section 5. For 187 autonomous cells, each node has: 189 o Autonomous Downstream Cell (AutoDownCell), one cell at a 190 [slotOffset,channelOffset] computed as a hash of its own EUI64 191 (detailed next). Its cell options bits are assigned as TX=1, 192 RX=1, SHARED=0. 194 o Autonomous Upstream Cell (AutoUpCell), one cell at a 195 [slotOffset,channelOffset] computed as a hash of the EUI64 of the 196 Join Proxy or its RPL routing parent (detailed in Section 4.4). 197 Its cell options bits are assigned as TX=1, RX=1, SHARED=1. 199 To compute a [slotOffset,channelOffset] from an EUI64 address, nodes 200 MUST use the hash function SAX [SAX-DASFAA]. The coordinates are 201 computed to distribute the cells across all channel offsets, and all 202 but the first time offsets of Slotframe 1. The first time offset is 203 skipped to avoid colliding with the minimal cell in Slotframe 0. The 204 slot coordinates derived from a given EUI64 address are computed as 205 follows: 207 o slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1) 208 o channelOffset(MAC) = hash(EUI64, 16) 210 The second input parameter defines the maxmium return value of the 211 hash function. There are other optional parameters defined in SAX 212 determines the performance of SAX hash function. Those parameters 213 could be broadcasted in EB frame or pre-configured. For 214 interoperability purposes, an example how the hash function is 215 implemented is detailed in Appendix B. 217 Because of hash collisions, there will be cases when the AutoUpCell 218 and AutoDownCell are scheduled at the same slot offset and/or channel 219 offset. Hash collisions among a set of cells at a given time offset 220 is resolved at run-time as follows: 222 o The AutoUpCell with the most packets in the outgoing queue takes 223 precedence. 224 o If the AutoUpCell have empty outgoing queues, the AutoDownCell 225 takes precedence. 227 In case the autonomous cell to be installed is conflicted with a 228 managed cell, a 6P RELOCATE command MUST be issued to the responding 229 neighbor to relocate the conflicting managed cell. 231 The traffic on the autonomous cells are scheduled as: 233 o Join Request packets and 6P ADD/DELETE Request frames to the 234 node's Join Proxy or its RPL routing parent MUST be sent on 235 AutoUpCell. 236 o Join Response packets and 6P ADD/DELETE Response frames to the 237 pledge or its RPL routing child MUST be sent on AutoDownCell. 238 o 6P RELOCATE Request frames to the node's RPL routing child MUST be 239 sent on AutoDownCell. 240 o 6P RELOCATE Response frames to its RPL routing parent MUST be sent 241 on AutoUpCell. 243 Throughout the network lifetime, nodes MUST maintain the autonomous 244 cells as follows: 246 o The AutoDownCell MUST always remain scheduled. 247 o When a new Join Proxy (JP) is selected, add an AutoUpCell to it. 248 o When the node is secured after joining process, remove the 249 AutoUpCell to the JP. 250 o When a new RPL routing parent is selected, add an AutoUpCell to 251 it. 252 o When the routing parent is de-selected, remove the AutoUpCell to 253 it. 254 o 6P CLEAR MUST NOT erase any autonomous cells. 256 4. Node Behavior at Boot 258 This section details the behavior the node SHOULD follow from the 259 moment it is switched on, until it has successfully joined the 260 network. Section 4.1 details the start state; Section 4.8 details 261 the end state. The other sections detail the 6 steps of the joining 262 process. We use the term "pledge" and "joined node", as defined in 263 [I-D.ietf-6tisch-minimal-security]. 265 4.1. Start State 267 A node implementing MSF MUST implement the Minimal Security Framework 268 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this 269 means that a pledge, before being switched on, may be pre-configured 270 with the Pre-Shared Key (PSK) for joining, as well as any other 271 configuration detailed in ([I-D.ietf-6tisch-minimal-security]). This 272 is not needed if the node implements a security solution not based on 273 PSKs, such as ([I-D.ietf-6tisch-dtsecurity-zerotouch-join]). 275 4.2. Step 1 - Choosing Frequency 277 When switched on, the pledge SHOULD randomly choose a frequency among 278 the available frequencies, and start listening for EBs on that 279 frequency. 281 4.3. Step 2 - Receiving EBs 283 Upon receiving the first EB, the pledge SHOULD continue listening for 284 additional EBs to learn: 286 1. the number of neighbors N in its vicinity 287 2. which neighbor to choose as a Join Proxy (JP) for the joining 288 process 290 While the exact behavior is implementation-specific, the RECOMMENDED 291 behavior is to follow [RFC8180], and listen until EBs sent by 292 NUM_NEIGHBOURS_TO_WAIT nodes (defined in [RFC8180]) have been 293 received. 295 During this step, the pledge MAY synchronize to any EB it receives 296 from the network it wishes to join. How to decide whether an EB 297 originates from a node from the network it wishes to join is 298 implementation-specific, but MAY involve filtering EBs by the PAN ID 299 field it contains, the presence and contents of the IE defined in 300 [I-D.richardson-6tisch-join-enhanced-beacon], or the key used to 301 authenticate it. 303 The decision of which neighbor to use as a JP is implementation- 304 specific, and discussed in [I-D.ietf-6tisch-minimal-security]. 306 4.4. Step 3 - Setting up Autonomous Cells for the Join Process 308 After selected a JP, a node MUST set up an AutoUpCell to that JP, as 309 described in Section 3. A Join Request is then sent then by the 310 pledge to its JP over the AutoUpCell. The JP forwards the Join 311 Request to the JRC, possibly over multiple hops, over the AutoUpCells 312 as well. Similarly, the JRC sends the Join Response to the JP, 313 possibly over multiple hops, over the AutoDownCells. When JP 314 received the Join Response from the JRC, it sends that Join Response 315 to the pledge over its AutoDownCell. The pledge thereby learns the 316 keying material used in the network, as well as other configurations, 317 and becomes a "joined node". The AutoUpCell to the JP is removed at 318 the same time by the "joined node". 320 4.5. Step 4 - Acquiring a RPL rank 322 Per [RFC6550], the joined node receives DIOs, computes its own rank, 323 and selects a preferred parent. 325 4.6. Step 5 - Setting up Autonomous Cells for 6P 327 After selected a preferred parent, the joined node MUST set up an 328 AutoUpCell to that parent. Then it MUST issue a 6P ADD command MUST 329 to that parent, with the following fields: 331 o CellOptions: set to TX=1,RX=0,SHARED=0 332 o NumCells: set to 1 333 o CellList: at least 5 cells, chosen according to Section Section 8 335 In case the 6P ADD transaction failed, the node MUST issue another 6P 336 ADD command and repeat until the one cell is installed to the parent. 338 4.7. Step 6 - Send EBs and DIOs 340 The node SHOULD start sending EBs and DIOs on the minimal cell, while 341 following the transmit rules for broadcast frames from Section 2. 343 4.8. End State 345 For a new node, the end state of the joining process is: 347 o it is synchronized to the network 348 o it is using the link-layer keying material it learned through the 349 secure joining process 350 o it has identified its preferred routing parent 351 o it has one AutoUpCell to its parent and one AutoDownCell 352 o it has one Managed Tx Cell to its parent 353 o it starts to send DIOs, potentially serving as a router for other 354 nodes' traffic 355 o it starts to send EBs, potentially serving as a JP for new pledge 357 5. Rules for Adding/Deleting Cells 359 Once a node has joined the 6TiSCH network, it adds/deletes/relocates 360 cells with its preferred parent for three reasons: 362 o to match the link-layer resources to the traffic between the node 363 and its preferred parent (Section 5.1) 364 o to handle switching preferred parent or(Section 5.2) 365 o to handle a schedule collision (Section 5.3) 367 5.1. Adapting to Traffic 369 A node implementing MSF MUST implement the behavior described in this 370 section. 372 The goal of MSF is to manage the communication schedule in the 6TiSCH 373 schedule in a distributed manner. For a node, this translates into 374 monitoring the current usage of the cells it has to its preferred 375 parent: 377 o If the node determines that the number of link-layer frames it is 378 attempting to exchange with its preferred parent per unit of time 379 is larger than the capacity offered by the TSCH managed cells it 380 has scheduled with it, the node issues a 6P ADD command to its 381 preferred parent to add one managed Tx cell to the TSCH schedule. 382 o If the traffic is lower than the capacity, the node issues a 6P 383 DELETE command to its preferred parent to delete one managed cell 384 from the TSCH schedule. 386 Adding/removing/relocating cells involves exchanging frames that 387 contain 6P commands. All 6P Request frames to its parent MUST be 388 sent on the AutoUpCell All 6P Response frames to non-parent neighbor 389 MUST be sent on AutoDownCell. In case a managed cell from non-parent 390 is conflicted with AutoUpCell to be installed, a 6P RELOCATE command 391 needs to be issued to the neighbor, as mentioned in Section 3. The 392 6P RELOCATE Request frame MUST be sent on AutoDownCell and the 393 Response MUST be sent on AutoUpCell. 395 The node MUST maintain the following counters for its preferred 396 parent: 398 NumCellsElapsed : Counts the number of managed cells that have 399 elapsed since the counter was initialized. This counter is 400 initialized at 0. Each time the TSCH state machine indicates 401 that the current cell is a managed cell to the preferred parent, 402 NumCellsElapsed is incremented by exactly 1, regardless of 403 whether the cell is used to transmit/receive a frame. 404 NumCellsUsed: Counts the number of managed cells that have been 405 used. This counter is initialized at 0. NumCellsUsed is 406 incremented by exactly 1 when, during a managed cell to the 407 preferred parent, either of the following happens: 409 * The node sends a frame to its preferred parent. The counter 410 increments regardless of whether a link-layer acknowledgment 411 was received or not. 412 * The node receives a frame from its preferred parent. 414 Both NumCellsElapsed and NumCellsUsed counters can be used to cell 415 with cell option TX=1 or RX=1. All the frames used for increasing/ 416 decreasing the counters MUST be encrypted or decryptable with the key 417 get from joining process. 419 Implementors MAY choose to create the same counters for each 420 neighbor, and add them as additional statistics in the neighbor 421 table. 423 The counters are used as follows: 425 1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when 426 the node boots. 427 2. When the value of NumCellsElapsed reaches MAX_NUMCELLS: 429 * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a 430 single cell to the preferred parent 431 * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a 432 single cell to the preferred parent 434 * Reset both NumCellsElapsed and NumCellsUsed to 0 and go to 435 step 2. 437 5.2. Switching Parent 439 A node implementing MSF SHOULD implement the behavior described in 440 this section. 442 Part of its normal operation, the RPL routing protocol can have a 443 node switch preferred parent. The procedure for switching from the 444 old preferred parent to the new preferred parent is: 446 1. if there is managed cell conflicted with the AutoUpCells to be 447 installed, the node MUST issue a 6P RELOCATE command to relocate 448 the conflicted cell 449 2. if there is no conflicted cell, the node installs the AutoUpCells 450 to its new parent 451 3. the node counts the number of managed cells it has per slotframe 452 to the old preferred parent 453 4. the node triggers one or more 6P ADD commands to schedule the 454 same number of managed cells to the new preferred parent 455 5. when that successfully completes, the node issues a 6P CLEAR 456 command to its old preferred parent 458 5.3. Handling Schedule Collisions 460 A node implementing MSF SHOULD implement the behavior described in 461 this section. The "MUST" statements in this section hence only apply 462 if the node implements schedule collision handling. 464 Since scheduling is entirely distributed, there is a non-zero 465 probability that two pairs of nearby neighbor nodes schedule a 466 managed cell at the same [slotOffset,channelOffset] location in the 467 TSCH schedule. In that case, data exchanged by the two pairs may 468 collide on that cell. We call this case a "schedule collision". 470 The node MUST maintain the following counters for each managed 471 unicast cell to its preferred parent: 473 NumTx: Counts the number of transmission attempts on that cell. 474 Each time the node attempts to transmit a frame on that cell, 475 NumTx is incremented by exactly 1. 476 NumTxAck: Counts the number of successful transmission attempts on 477 that cell. Each time the node receives an acknowledgment for a 478 transmission attempt, NumTxAck is incremented by exactly 1. 480 Implementors MAY choose to maintain the same counters for each 481 managed cell in the schedule. 483 Since both NumTx and NumTxAck are initialized to 0, we necessarily 484 have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the 485 ratio NumTxAck/NumTx; and represent it as a percentage. A cell with 486 PDR=50% means that half of the frames transmitted are not 487 acknowledged (and need to be retransmitted). 489 Each time the node switches preferred parent (or during the join 490 process when the node selects a preferred parent for the first time), 491 both NumTx and NumTxAck MUST be reset to 0. They increment over 492 time, as the schedule is executed and the node sends frames to its 493 preferred parent. When NumTx reaches 256, both NumTx and NumTxAck 494 MUST be divided by 2. That is, for example, from NumTx=256 and 495 NumTxAck=128, they become NumTx=128 and NumTxAck=64. This operation 496 does not change the value of the PDR, but allows the counters to keep 497 incrementing. 499 The key for detecting a schedule collision is that, if a node has 500 several cells to the same preferred parent, all cells should exhibit 501 the same PDR. A cell which exhibits a PDR significantly lower than 502 the others indicates than there are collisions on that cell. 504 Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following 505 steps: 507 1. It computes, for each managed unicast cell with its preferred 508 parent (not for the autonomous cell), that cell's PDR. 509 2. Any cell that hasn't yet had NumTx divided by 2 since it was last 510 reset is skipped in steps 3 and 4. This avoids triggering cell 511 relocation when the values of NumTx and NumTxAck are not 512 statistically significant yet. 513 3. It identifies the cell with the highest PDR. 514 4. For any other cell, it compares its PDR against that of the cell 515 with the highest PDR. If the different is less than 516 RELOCATE_PDRTHRES, it triggers the relocation of that cell using 517 a 6P RELOCATE command. 519 6. 6P SIGNAL command 521 The 6P SIGNAL command is not used by MSF. 523 7. Scheduling Function Identifier 525 The Scheduling Function Identifier (SFID) of MSF is 526 IANA_6TISCH_SFID_MSF. 528 8. Rules for CellList 530 MSF uses 2-step 6P Transactions exclusively. 6P Transactions are 531 only initiated by a node towards it preferred parent. As a result, 532 the cells to put in the CellList of a 6P ADD command, and in the 533 candidate CellList of a RELOCATE command, are chosen by the node 534 initiating the 6P Transaction. In both cases, the same rules apply: 536 o The CellList SHOULD contain 5 or more cells. 537 o Each cell in the CellList MUST have a different slotOffset value. 538 o For each cell in the CellList, the node MUST NOT have any 539 scheduled cell on the same slotOffset. 540 o The slotOffset value of any cell in the CellList MUST NOT be the 541 same as the slotOffset of the minimal cell (slotOffset=0). 542 o The slotOffset of a cell in the CellList SHOULD be randomly and 543 uniformly chosen among all the slotOffset values that satisfy the 544 restrictions above. 545 o The channelOffset of a cell in the CellList SHOULD be randomly and 546 uniformly chosen in [0..numFrequencies], where numFrequencies 547 represents the number of frequencies a node can communicate on. 549 9. 6P Timeout Value 551 It is calculated for the worst case that a 6P response is received, 552 which means the 6P response is sent out successfully at the very 553 latest retransmission. And for each retransmission, it backs-off 554 with largest value. Hence the 6P timeout value is calcualted as 555 ((2^MAXBE)-1)*SLOTFRAME_LENGTH, where: 557 o MAXEB is the maxmium backoff exponent is used 558 o SLOTFRAME_LENGTH represents the length of slotframe 560 10. Rule for Ordering Cells 562 Cells are ordered slotOffset first, channelOffset second. 564 The following sequence is correctly ordered (each element represents 565 the [slottOffset,channelOffset] of a cell in the schedule): 567 [1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9] 569 11. Meaning of the Metadata Field 571 The Metadata field is not used by MSF. 573 12. 6P Error Handling 575 Section 6.2.4 of [RFC8480] lists the 6P Return Codes. Figure 1 lists 576 the same error codes, and the behavior a node implementing MSF SHOULD 577 follow. 579 +-----------------+----------------------+ 580 | Code | RECOMMENDED behavior | 581 +-----------------+----------------------+ 582 | RC_SUCCESS | nothing | 583 | RC_EOL | nothing | 584 | RC_ERR | quarantine | 585 | RC_RESET | quarantine | 586 | RC_ERR_VERSION | quarantine | 587 | RC_ERR_SFID | quarantine | 588 | RC_ERR_SEQNUM | clear | 589 | RC_ERR_CELLLIST | clear | 590 | RC_ERR_BUSY | waitretry | 591 | RC_ERR_LOCKED | waitretry | 592 +-----------------+----------------------+ 594 Figure 1: Recommended behavior for each 6P Error Code. 596 The meaning of each behavior from Figure 1 is: 598 nothing: Indicates that this Return Code is not an error. No error 599 handling behavior is triggered. 600 clear: Abort the 6P Transaction. Issue a 6P CLEAR command to that 601 neighbor (this command may fail at the link layer). Remove all 602 cells scheduled with that neighbor from the local schedule. Keep 603 that node in the neighbor and routing tables. 604 quarantine: Same behavior as for "clear". In addition, remove the 605 node from the neighbor and routing tables. Place the node's 606 identifier in a quarantine list for QUARANTINE_DURATION. When in 607 quarantine, drop all frames received from that node. 608 waitretry: Abort the 6P Transaction. Wait for a duration randomly 609 and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX]. 610 Retry the same transaction. 612 13. Schedule Inconsistency Handling 614 The behavior when schedule inconsistency is detected is explained in 615 Figure 1, for 6P Return Code RC_ERR_SEQNUM. 617 14. MSF Constants 619 Figure 2 lists MSF Constants and their RECOMMENDED values. 621 +------------------------------+-------------------+ 622 | Name | RECOMMENDED value | 623 +------------------------------+-------------------+ 624 | KA_PERIOD | 10 s | 625 | LIM_NUMCELLSUSED_HIGH | 75 % | 626 | LIM_NUMCELLSUSED_LOW | 25 % | 627 | HOUSEKEEPINGCOLLISION_PERIOD | 1 min | 628 | RELOCATE_PDRTHRES | 50 % | 629 | SLOTFRAME_LENGTH | 101 slots | 630 | QUARANTINE_DURATION | 5 min | 631 | WAITDURATION_MIN | 30 s | 632 | WAITDURATION_MAX | 60 s | 633 +------------------------------+-------------------+ 635 Figure 2: MSF Constants and their RECOMMENDED values. 637 15. MSF Statistics 639 Figure 3 lists MSF Statistics and their RECOMMENDED width. 641 +-----------------+-------------------+ 642 | Name | RECOMMENDED width | 643 +-----------------+-------------------+ 644 | NumCellsElapsed | 1 byte | 645 | NumCellsUsed | 1 byte | 646 | NumTx | 1 byte | 647 | NumTxAck | 1 byte | 648 +-----------------+-------------------+ 650 Figure 3: MSF Statistics and their RECOMMENDED width. 652 16. Security Considerations 654 MSF defines a series of "rules" for the node to follow. It triggers 655 several actions, that are carried out by the protocols defined in the 656 following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 657 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation 658 Sublayer Protocol (6P) [RFC8480], and the Minimal Security Framework 659 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF 660 does not define a new protocol or packet format. 662 MSF relies entirely on the security mechanisms defined in the 663 specifications listed above. 665 17. IANA Considerations 667 17.1. MSF Scheduling Function Identifiers 669 This document adds the following number to the "6P Scheduling 670 Function Identifiers" sub-registry, part of the "IPv6 over the TSCH 671 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by 672 [RFC8480]: 674 +----------------------+-----------------------------+-------------+ 675 | SFID | Name | Reference | 676 +----------------------+-----------------------------+-------------+ 677 | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX | 678 | | (MSF) | (NOTE:this) | 679 +----------------------+-----------------------------+-------------+ 681 Figure 4: IETF IE Subtype '6P'. 683 18. References 685 18.1. Normative References 687 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 688 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 689 draft-ietf-6tisch-dtsecurity-zerotouch-join-03 (work in 690 progress), October 2018. 692 [I-D.ietf-6tisch-minimal-security] 693 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 694 "Minimal Security Framework for 6TiSCH", draft-ietf- 695 6tisch-minimal-security-10 (work in progress), April 2019. 697 [I-D.richardson-6tisch-join-enhanced-beacon] 698 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 699 Element encapsulation of 6tisch Join Information", draft- 700 richardson-6tisch-join-enhanced-beacon-03 (work in 701 progress), January 2018. 703 [IEEE802154-2015] 704 IEEE standard for Information Technology, "IEEE Std 705 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 706 Networks (WPANs)", December 2015. 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, 710 DOI 10.17487/RFC2119, March 1997, 711 . 713 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 714 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 715 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 716 Low-Power and Lossy Networks", RFC 6550, 717 DOI 10.17487/RFC6550, March 2012, 718 . 720 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 721 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 722 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 723 May 2017, . 725 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 726 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 727 DOI 10.17487/RFC8480, November 2018, 728 . 730 18.2. Informative References 732 [SAX-DASFAA] 733 Ramakrishna, M. and J. Zobel, "Performance in Practice of 734 String Hashing Functions", DASFAA , 1997. 736 Appendix A. Contributors 738 Beshr Al Nahas (Chalmers University, beshr@chalmers.se) Olaf 739 Landsiedel (Chalmers University, olafl@chalmers.se) Yasuyuki Tanaka 740 (Inria-Paris, yasuyuki.tanaka@inria.fr) 742 Appendix B. Example of Implementation of SAX hash function 744 For the consideration of interoperability, this section provides an 745 example of implemention SAX hash function [SAX-DASFAA]. The input 746 parameters of the function are: 748 o T, which is the hashing table length 749 o c, which is the characters of string s, to be hashed 751 In MSF, the T is replaced by the length slotframe 1. String s is 752 replaced by the mote EUI64 address. The characters of the string c0, 753 c1, ..., c7 are the 8 bytes of EUI64 address. 755 The SAX hash function requires shift operation which is defined as 756 follow: 758 o L_shift(v,b), which refers to left shift variable v by b bits 759 o R_shift(v,b), which refers to right shift variable v by b bits 760 The steps to calculate the hash value of SAX hash function are: 762 1. initialize variable h to h0 and variable i to 0, where h is the 763 intermediate hash value and i is the index of the bytes of EUI64 764 address 765 2. sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and ci 766 3. calculate the result of exclusive or bewteen the sum value in 767 Step 2 and h 768 4. modulo the result of Step 3 by T 769 5. assign the result of Step 4 to h 770 6. increase i by 1 771 7. repeat Step2 to Step 6 until i reaches to 8 772 8. assign the result of Step 5 to h 774 The value of variable h the hash value of SAX hash function. 776 For interoperability purposes, the values of h0, l_bit and r_bit in 777 Step 1 and 2 are configured as: 779 o h0 = 0 780 o l_bit = 0 781 o r_bit = 1 783 The appropriate values of l_bit and r_bit could vary depending on the 784 the set of motes' EUI64 address. How to find those values is out of 785 the scope of this specification. 787 Authors' Addresses 789 Tengfei Chang (editor) 790 Inria 791 2 rue Simone Iff 792 Paris 75012 793 France 795 Email: tengfei.chang@inria.fr 797 Malisa Vucinic 798 Inria 799 2 rue Simone Iff 800 Paris 75012 801 France 803 Email: malisa.vucinic@inria.fr 804 Xavier Vilajosana 805 Universitat Oberta de Catalunya 806 156 Rambla Poblenou 807 Barcelona, Catalonia 08018 808 Spain 810 Email: xvilajosana@uoc.edu 812 Simon Duquennoy 813 RISE SICS 814 Isafjordsgatan 22 815 164 29 Kista 816 Sweden 818 Email: simon.duquennoy@ri.se 820 Diego Dujovne (editor) 821 Universidad Diego Portales 822 Escuela de Informatica y Telecomunicaciones 823 Av. Ejercito 441 824 Santiago, Region Metropolitana 825 Chile 827 Phone: +56 (2) 676-8121 828 Email: diego.dujovne@mail.udp.cl