idnits 2.17.1 draft-ietf-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 (October 22, 2018) is 1984 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 605 -- Looks like a reference, but probably isn't: '3' on line 605 -- Looks like a reference, but probably isn't: '4' on line 605 -- Looks like a reference, but probably isn't: '2' on line 605 -- Looks like a reference, but probably isn't: '0' on line 605 -- Looks like a reference, but probably isn't: '5' on line 605 -- Looks like a reference, but probably isn't: '6' on line 605 -- Looks like a reference, but probably isn't: '7' on line 605 -- Looks like a reference, but probably isn't: '9' on line 605 == Missing Reference: 'TEMPORARY' is mentioned on line 858, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-06 ** Downref: Normative reference to an Informational draft: draft-richardson-6tisch-join-enhanced-beacon (ref. 'I-D.richardson-6tisch-join-enhanced-beacon') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2015' ** Downref: Normative reference to an Informational RFC: RFC 7554 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH T. Chang, Ed. 3 Internet-Draft Inria 4 Intended status: Standards Track M. Vucinic 5 Expires: April 25, 2019 University of Montenegro 6 X. Vilajosana 7 Universitat Oberta de Catalunya 8 S. Duquennoy 9 RISE SICS 10 D. Dujovne, Ed. 11 Universidad Diego Portales 12 October 22, 2018 14 6TiSCH Minimal Scheduling Function (MSF) 15 draft-ietf-6tisch-msf-01 17 Abstract 19 This specification defines the 6TiSCH Minimal Scheduling Function 20 (MSF). This Scheduling Function describes both the behavior of a 21 node when joining the network, and how the communication schedule is 22 managed in a distributed fashion. MSF builds upon the 6TiSCH 23 Operation Sublayer Protocol (6P) and the Minimal Security Framework 24 for 6TiSCH. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in 31 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 25, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Interface to the Minimal 6TiSCH Configuration . . . . . . . . 4 69 3. Autonomous Unicast Cells . . . . . . . . . . . . . . . . . . 5 70 4. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.2. Step 1 - Choosing Frequency . . . . . . . . . . . . . . . 7 73 4.3. Step 2 - Receiving EBs . . . . . . . . . . . . . . . . . 7 74 4.4. Step 3 - Setting up Autonomous Unicast Cells . . . . . . 7 75 4.5. Step 4 - Join Request/Response . . . . . . . . . . . . . 7 76 4.6. Step 5 - Acquiring a RPL rank . . . . . . . . . . . . . . 8 77 4.7. Step 6 - Send EBs and DIOs . . . . . . . . . . . . . . . 8 78 4.8. Step 7 - Neighbor Polling . . . . . . . . . . . . . . . . 8 79 4.9. End State . . . . . . . . . . . . . . . . . . . . . . . . 8 80 5. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 9 81 5.1. Adapting to Traffic . . . . . . . . . . . . . . . . . . . 9 82 5.2. Switching Parent . . . . . . . . . . . . . . . . . . . . 11 83 5.3. Handling Schedule Collisions . . . . . . . . . . . . . . 11 84 6. 6P SIGNAL command . . . . . . . . . . . . . . . . . . . . . . 12 85 7. Scheduling Function Identifier . . . . . . . . . . . . . . . 12 86 8. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 12 87 9. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 13 88 10. Rule for Ordering Cells . . . . . . . . . . . . . . . . . . . 13 89 11. Meaning of the Metadata Field . . . . . . . . . . . . . . . . 13 90 12. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 13 91 13. Schedule Inconsistency Handling . . . . . . . . . . . . . . . 14 92 14. MSF Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 93 15. MSF Statistics . . . . . . . . . . . . . . . . . . . . . . . 15 94 16. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 96 17.1. MSF Scheduling Function Identifiers . . . . . . . . . . 16 97 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 18.1. Normative References . . . . . . . . . . . . . . . . . . 16 99 18.2. Informative References . . . . . . . . . . . . . . . . . 17 100 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 17 101 Appendix B. Implementation Status . . . . . . . . . . . . . . . 17 102 Appendix C. Performance Evaluation . . . . . . . . . . . . . . . 18 103 Appendix D. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 18 104 Appendix E. [TEMPORARY] Pending Elements . . . . . . . . . . . . 19 105 E.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 19 106 E.2. Security Related . . . . . . . . . . . . . . . . . . . . 19 107 E.2.1. Security issue on autonomous cell installation . . . 19 108 E.3. Performance Related . . . . . . . . . . . . . . . . . . . 19 109 E.3.1. Handling the case when bandwidth allocation exceeds 110 available capacity . . . . . . . . . . . . . . . . . 19 111 E.3.2. joining traffic MUST be sent in minimal cell . . . . 19 112 E.3.3. NumCellsPassed shouldn't update on shared dedicated 113 cell . . . . . . . . . . . . . . . . . . . . . . . . 19 114 E.3.4. non-trusted packet shouldn't be accounted for for 115 adapting traffic . . . . . . . . . . . . . . . . . . 20 116 E.3.5. Customize the backoff exponent on dedicated shared 117 cell. . . . . . . . . . . . . . . . . . . . . . . . . 20 118 E.3.6. Adapting 6P Timeout . . . . . . . . . . . . . . . . . 20 119 E.3.7. Timeout calculation is wrong . . . . . . . . . . . . 20 120 E.3.8. Separate Cell Counters for TX and RX . . . . . . . . 20 121 E.3.9. Two slotframes . . . . . . . . . . . . . . . . . . . 20 122 E.4. editorial . . . . . . . . . . . . . . . . . . . . . . . . 21 123 E.4.1. Parameters for SAX is missing . . . . . . . . . . . . 21 124 E.4.2. Wrong end state statement . . . . . . . . . . . . . . 21 125 E.4.3. Dependency on RFC8180 shouldn't be a MUST . . . . . . 21 126 E.4.4. DIO can be unicast packet as indicated in RFC6550 . . 21 127 E.4.5. Rules for broadcast frames is out of scope of MSF . . 21 128 E.4.6. Wrong statement in Step 4 . . . . . . . . . . . . . . 21 129 E.4.7. Rephrase NumCellsPassed to NumCellsElapsed . . . . . 22 130 E.4.8. Create a list of packets that be able to be sent on 131 minimal cell . . . . . . . . . . . . . . . . . . . . 22 132 E.4.9. Clarify term 'dedicated cell' . . . . . . . . . . . . 22 133 E.4.10. text is missing . . . . . . . . . . . . . . . . . . . 22 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 136 1. Introduction 138 The 6TiSCH Minimal Scheduling Function (MSF), defined in this 139 specification, is a 6TiSCH Scheduling Function (SF). The role of an 140 SF is entirely defined in [I-D.ietf-6tisch-6top-protocol]: it 141 complements [I-D.ietf-6tisch-6top-protocol] by providing the rules of 142 when to add/delete cells in the communication schedule. The SF 143 defined in this document follows that definition, and satisfies all 144 the requirements for an SF listed in Section 4.2 of 145 [I-D.ietf-6tisch-6top-protocol]. 147 MSF builds on top of the following specifications: the Minimal IPv6 148 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration 149 [RFC8180], the 6TiSCH Operation Sublayer Protocol (6P) 150 [I-D.ietf-6tisch-6top-protocol], and the Minimal Security Framework 151 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. 153 MSF defines both the behavior of a node when joining the network, and 154 how the communication schedule is managed in a distributed fashion. 155 When a node running MSF boots up, it joins the network by following 156 the 7 steps described in Section 4. The end state of the join 157 process is that the node is synchronized to the network, has mutually 158 authenticated to the network, has identified a preferred routing 159 parent, has scheduled one default unicast cell to/from each of its 160 neighbors. After the join process, the node can continuously 161 add/delete/relocate cells, as described in Section 5. It does so for 162 3 reasons: to match the link-layer resources to the traffic, to 163 handle changing parent, to handle a schedule collision. 165 MSF is designed to operate in a wide range of application domains. 166 It is optimized for applications with regular upstream traffic (from 167 the nodes to the root). Appendix C contains a performance evaluation 168 of MSF. 170 This specification follows the recommended structure of an SF 171 specification in Appendix A of [I-D.ietf-6tisch-6top-protocol], with 172 the following adaptations: 174 o We have reordered part of the sections, in particular to have the 175 section on the node behavior at boot Section 4 appear early in 176 this specification. 177 o We added sections on the interface to the minimal 6TiSCH 178 configuration Section 2, the use of the SIGNAL command Section 6, 179 the MSF constants Section 14, the MSF statistics Section 15, the 180 performance of MSF Appendix C. 181 o This specification does not include an examples section. 183 2. Interface to the Minimal 6TiSCH Configuration 185 A node implementing MSF MUST implement the Minimal 6TiSCH 186 Configuration [RFC8180], which defines the "minimal cell", a single 187 shared cell providing minimal connectivity between the nodes in the 188 network. 190 MSF uses the minimal cell to exchange the following packets: 192 1. Enhanced Beacons (EBs), defined by [IEEE802154-2015]. These are 193 broadcast frames. 195 2. DODAG Information Objects (DIOs), defined by [RFC6550]. These 196 are broadcast frames. 198 Because the minimal cell is SHARED, the back-off algorithm defined in 199 [IEEE802154-2015] is used to resolve collisions. To ensure there is 200 enough bandwidth available on the minimal cell, a node implementing 201 MSF SHOULD enforce the following rules for broadcast frames: 203 1. send EBs on a portion of the minimal cells not exceeding 204 1/(3(N+1)), where N is the number of neighbors of the node. 205 2. send DIOs on a portion of the minimal cells not exceeding 206 1/(3(N+1)), where N is the number of neighbors of the node. 208 The RECOMMENDED behavior for sending EBs is to have a node send EBs 209 with a probability of 1/(3(N+1)). The RECOMMENDED behavior for 210 sending DIOs is to use a Trickle timer with rate-limiting. 212 Section 4.3 describes how to evaluate the number of neighbors during 213 the joining process. After the joining process, how to evaluate the 214 number of neighbors is implementation-specific. 216 As detailed in Section 2.2 of [I-D.ietf-6tisch-6top-protocol], MSF 217 MUST schedule cells from Slotframe 1, while Slotframe 0 is used for 218 traffic defined in the Minimal 6TiSCH Configuration. The length of 219 Slotframe 0 and Slotframe 1 SHOULD be the same value. The default of 220 SLOTFRAME_LENGTH is RECOMMENDED, although any value can be advertised 221 in the EBs. 223 3. Autonomous Unicast Cells 225 MSF nodes MUST initialize Slotframe 1 with a set of default cells for 226 unicast communication with their neighbors. These cells are referred 227 to as 'autonomous cells', because they are maintained autonomously by 228 each node. Each node has: 230 1. One cell to receive, at a [slotOffset,channelOffset] computed as 231 a hash of the node's EUI64 (detailed next). The cell options for 232 this cell are RX=1. 233 2. For each neighbor in the IPv6 neighbor table, one cell to 234 transmit, at a [slotOffset,channelOffset] computed as a hash of 235 the neighbor's EUI64 (detailed next). The cell options for this 236 cell are TX=1, SHARED=1. 238 To compute a [slotOffset,channelOffset] from an EUI64 address, nodes 239 MUST use the hash function SAX [SAX-DASFAA]. The coordinates are 240 computed to distribute the cells across all 16 channel offsets, and 241 all but the first time offsets of Slotframe 1. The first time offset 242 is skipped to avoid colliding with the minimal cell in Slotframe 0. 244 The slot coordinates derived from a given EUI64 address are computed 245 as follows: 247 slotOffset(MAC) = 1 + hash(EUI64) % (length(Slotframe_1) - 1) 248 channelOffset(MAC) = hash(EUI64) % 16 250 Because of hash collisions, there are cases where one node has 251 multiple cells scheduled at the same time offset and/or channel 252 offset. Note that nodes have only one autonomous RX cell and 253 potentially multiple TX cells. Hash collisions among a set of cells 254 at a given time offset is resolved at run-time as follows: 256 1. The TX cell with the most packets in outgoing queue takes 257 precedence. 258 2. If all TX cells have empty outgoing queues, the RX cell takes 259 precedence. 261 Throughout the network lifetime, nodes MUST maintain the autonomous 262 cells as follows: 264 1. The receive cell MUST always remain scheduled. 265 2. Whenever a new neighbor is discovered, add a transmit cell for 266 it. 267 3. Whenever a new neighbor is removed, remove transmit cell that was 268 assigned to it. 269 4. 6P CLEAR MUST NOT erase autonomous cells. 271 4. Node Behavior at Boot 273 This section details the behavior the node SHOULD follow from the 274 moment it is switched on, until it has successfully joined the 275 network. Section 4.1 details the start state; Section 4.9 details 276 the end state. The other sections detail the 7 steps of the joining 277 process. We use the term "pledge" and "joined node", as defined in 278 [I-D.ietf-6tisch-minimal-security]. 280 4.1. Start State 282 A node implementing MSF MUST implement the Minimal Security Framework 283 for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this 284 means that a pledge, before being switched on, is pre-configured with 285 the Pre-Shared Key (PSK) for joining, as well as any other 286 configuration detailed in [I-D.ietf-6tisch-minimal-security]. 288 4.2. Step 1 - Choosing Frequency 290 When switched on, the pledge SHOULD randomly choose a frequency among 291 the available frequencies, and start listening for EBs on that 292 frequency. 294 4.3. Step 2 - Receiving EBs 296 Upon receiving the first EB, the pledge SHOULD continue listening for 297 additional EBs to learn: 299 1. the number of neighbors N in its vicinity 300 2. which neighbor to choose as a Join Proxy (JP) for the joining 301 process 303 While the exact behavior is implementation-specific, the RECOMMENDED 304 behavior is to follow [RFC8180], and listen until EBs sent by 305 NUM_NEIGHBOURS_TO_WAIT nodes (defined in [RFC8180]) have been 306 received. 308 During this step, the pledge MAY synchronize to any EB it receives 309 from the network it wishes to join. How to decide whether an EB 310 originates from a node from the network it wishes to join is 311 implementation-specific, but MAY involve filtering EBs by the PAN ID 312 field it contains, the presence and contents of the IE defined in 313 [I-D.richardson-6tisch-join-enhanced-beacon], or the key used to 314 authenticate it. 316 The decision of which neighbor to use as a JP is implementation- 317 specific, and discussed in [I-D.ietf-6tisch-minimal-security]. 319 4.4. Step 3 - Setting up Autonomous Unicast Cells 321 After joining, nodes MUST set up their autonomous unicast cells, as 322 described in Section 3. This enables unicast communication in 323 Slotframe 1, until more cells are added with 6P as defined in 324 Section 5. 326 4.5. Step 4 - Join Request/Response 328 As per [I-D.ietf-6tisch-minimal-security], after having selected a 329 JP, the pledge sends a Join Request to its JP. Because no dedicated 330 cells are in place at this point, this happens on the autonomous 331 unicast cell. The JP then forwards the Join Request to the JRC, 332 possibly over multiple hops. When forwarding this Join Request, a 333 node MUST use a unicast cell (autonomous or dedicated) it has with 334 its preferred parent. How dedicated cells are installed is detailed 335 in Section 5. 337 As per [I-D.ietf-6tisch-minimal-security], the JRC sends back a Join 338 Response to the pledge, through the JP. When forwarding this Join 339 Response, a node MUST use a unicast (autonomous or dedicated) cell it 340 has with its child (not the minimal cell). 342 As per [I-D.ietf-6tisch-minimal-security], after receiving the Join 343 Response, the pledge learns the keying material used in the network, 344 as well as other configurations, and becomes a "joined node". 346 4.6. Step 5 - Acquiring a RPL rank 348 Because it has learned the link-layer keying material used in the 349 network, the joined node can now decrypt the DIO packets sent by its 350 neighbors. Per [RFC6550], the joined node receives DIOs, computes 351 its own rank, and selects a preferred parent. 353 4.7. Step 6 - Send EBs and DIOs 355 The node SHOULD start sending EBs and DIOs on the minimal cell, while 356 following the transmit rules for broadcast frames from Section 2. 358 4.8. Step 7 - Neighbor Polling 360 The node SHOULD send some form of keep-alive messages to all its 361 neighbors it has unicast cells with. The Keep-Alive (KA) mechanism 362 is detailed in [RFC7554]. It uses the keep-alive messages to its 363 preferred parent to stay synchronized. It uses the keep-alive 364 messages to its children (with which it has a unicast cell to) to 365 ensure the child is still reachable. The RECOMMENDED period for 366 sending keep-alive messages is KA_PERIOD. 368 If the keep-alive message to a child fails at the link layer (i.e. 369 the maximum number of link-layer retries is reached), the node SHOULD 370 declare the child as unreachable. This can happen for example when 371 the child node is switched off. 373 When a neighbor is declared unreachable, the node MUST remove all 374 dedicated cells with that neighbor from its own schedule. In 375 addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at 376 the link-layer). If the node has autonmous cells to the unreachable 377 neighbor those cells will be removed following the procedure 378 described in Section 3. 380 4.9. End State 382 For a new node, the end state of the joining process is: 384 o it is synchronized to the network 385 o it is using the link-layer keying material it learned through the 386 secure joining process 387 o it has identified its preferred routing parent 388 o it has a set of autonomous unicast cells to/from its neighbors 389 o it is periodically sending DIOs, potentially serving as a router 390 for other nodes' traffic 391 o it is periodically sending EBs, potentially serving as a JP for 392 new joining nodes 394 5. Rules for Adding/Deleting Cells 396 Once a node has joined the 6TiSCH network, it adds/deletes/relocates 397 cells with its preferred parent for three reasons: 399 o to match the link-layer resources to the traffic between the node 400 and its preferred parent (Section 5.1) 401 o to handle switching preferred parent (Section 5.2) 402 o to handle a schedule collision (Section 5.3) 404 5.1. Adapting to Traffic 406 A node implementing MSF MUST implement the behavior described in this 407 section. 409 In order to handle transient traffic bursts, MSF uses the 410 [IEEE802154-2015] frame pending bit (page 152, Section 7.2.1.3). By 411 setting the bit, a node can transmit a series of packets to a given 412 neighbor in consecutive time offsets. The next paragraphs define how 413 to handle longer-term fluctuations in traffic, using 6P. 415 The goal of MSF is to manage the communication schedule in the 6TiSCH 416 schedule in a distributed manner. For a node, this translates into 417 monitoring the current usage of the cells it has to its preferred 418 parent: 420 o If the node determines that the number of link-layer frames it is 421 attempting to exchange with its preferred parent per unit of time 422 is larger than the capacity offered by the TSCH unicast cells 423 (dedicated and autonmous cells) it has scheduled with it, the node 424 triggers a 6P Transaction with its preferred parent to add 425 dedicated cells to the TSCH schedule of both nodes. 426 o If the traffic is lower than the capacity, the node triggers a 6P 427 Transaction with its preferred parent to delete dedicated cells 428 from the TSCH schedule of both nodes. 430 From the join process, the node already has a set of autonmous 431 unicast cells, as defined in Section 3. The autonomous cells MUST 432 NOT be removed by 6P, so that there always exists a unicast cell 433 between a node and its preferred parent, even if no frames are being 434 exchanged between them. Autonomous cells are used indistinguishably 435 together with dedicated cells, for broadcast or unicast traffic with 436 the target neighbor. The procedure to remove autonomous cells is 437 described in Section 3. 439 Adding/removing/relocating cells involves exchanging frames that 440 contain 6P commands. All 6P frames MUST be sent on the unicast cells 441 (and not the minimal cell). 443 The node MUST maintain the following counters for its preferred 444 parent: 446 NumCellsPassed: Counts the number of unicast cells (dedicated and 447 autonmous cells) that have passed since the counter was 448 initialized. This counter is initialized at 0. Each time the 449 TSCH state machine indicates that the current cell is a unicast 450 cell to the preferred parent, NumCellsPassed is incremented by 451 exactly 1, regardless of whether the cell is used to transmit/ 452 receive a frame. 453 NumCellsUsed: Counts the number of unicast cells that have been 454 used. This counter is initialized at 0. NumCellsUsed is 455 incremented by exactly 1 when, during a unicast cell to the 456 preferred parent, either of the following happens: 458 * The node sends a frame to its preferred parent. The counter 459 increments regardless of whether a link-layer acknowledgment 460 was received or not. 461 * The node receives a frame from its preferred parent. 463 Implementors MAY choose to create the same counters for each 464 neighbor, and add them as additional statistics in the neighbor 465 table. 467 The counters are used as follows: 469 1. Both NumCellsPassed and NumCellsUsed are initialized to 0 when 470 the node boots. 471 2. When the value of NumCellsPassed reaches MAX_NUMCELLS: 473 * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a 474 single cell to the preferred parent 475 * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a 476 single cell to the preferred parent 477 * Reset both NumCellsPassed and NumCellsUsed to 0 and go to step 478 2. 480 5.2. Switching Parent 482 A node implementing MSF MUST implement the behavior described in this 483 section. 485 Part of its normal operation, the RPL routing protocol can have a 486 node switch preferred parents. The procedure for switching from the 487 old preferred parent to the new preferred parent is: 489 1. the node counts the number of dedicated (unicast but not 490 autonomous) cells it has per slotframe to the old preferred 491 parent 492 2. the node triggers one or more 6P ADD commands to schedule the 493 same number of dedicated cells to the new preferred parent 494 3. when that successfully completes, the node issues a 6P CLEAR 495 command to its old preferred parent 497 5.3. Handling Schedule Collisions 499 A node implementing MSF SHOULD implement the behavior described in 500 this section. The "MUST" statements in this section hence only apply 501 if the node implements schedule collision handling. 503 Since scheduling is entirely distributed, there is a non-zero 504 probability that two pairs of nearby neighbor nodes schedule a cell 505 at the same [slotOffset,channelOffset] location in the TSCH schedule. 506 In that case, data exchanged by the two pairs may collide on that 507 cell. We call this case a "schedule collision". 509 The node MUST maintain the following counters for each cell to its 510 preferred parent: 512 NumTx: Counts the number of transmission attempts on that cell. 513 Each time the node attempts to transmit a frame on that cell, 514 NumTx is incremented by exactly 1. 515 NumTxAck: Counts the number of successful transmission attempts on 516 that cell. Each time the node receives an acknowledgment for a 517 transmission attempt, NumTxAck is incremented by exactly 1. 519 Implementors MAY choose to maintain the same counters for each cell 520 in the schedule. 522 Since both NumTx and NumTxAck are initialized to 0, we necessarily 523 have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the 524 ratio NumTxAck/NumTx; and represent it as a percentage. A cell with 525 PDR=50% means that half of the frames transmitted are not 526 acknowledged (and need to be retransmitted). 528 Each time the node switches preferred parent (or during the join 529 process when the node selects a preferred parent for the first time), 530 both NumTx and NumTxAck MUST be reset to 0. They increment over 531 time, as the schedule is executed and the node sends frames to its 532 preferred parent. When NumTx reaches 256, both NumTx and NumTxAck 533 MUST be divided by 2. That is, for example, from NumTx=256 and 534 NumTxAck=128, they become NumTx=128 and NumTxAck=64. This operation 535 does not change the value of the PDR, but allows the counters to keep 536 incrementing. 538 The key for detecting a schedule collision is that, if a node has 539 several cells to the same preferred parent, all cells should exhibit 540 the same PDR. A cell which exhibits a PDR significantly lower than 541 the others indicates than there are collisions on that cell. 543 Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following 544 steps: 546 1. It computes, for each dedicated cell with its preferred parent 547 (not for the autonomous cell), that cell's PDR. 548 2. Any cell that hasn't yet had NumTx divided by 2 since it was last 549 reset is skipped in steps 3 and 4. This avoids triggering cell 550 relocation when the values of NumTx and NumTxAck are not 551 statistically significant yet. 552 3. It identifies the cell with the highest PDR. 553 4. For each other cell, it compares its PDR against that of the cell 554 with the highest PDR. If it's less than RELOCATE_PDRTHRES, it 555 triggers the relocation of that cell using a 6P RELOCATE command. 557 6. 6P SIGNAL command 559 The 6P SIGNAL command is not used by MSF. 561 7. Scheduling Function Identifier 563 The Scheduling Function Identifier (SFID) of MSF is 564 IANA_6TISCH_SFID_MSF. 566 8. Rules for CellList 568 MSF uses 2-step 6P Transactions exclusively. 6P Transactions are 569 only initiated by a node towards it preferred parent. As a result, 570 the cells to put in the CellList of a 6P ADD command, and in the 571 candidate CellList of a RELOCATE command, are chosen by the node 572 initiating the 6P Transaction. In both cases, the same rules apply: 574 o The CellList SHOULD contain 5 or more cells. 575 o Each cell in the CellList MUST have a different slotOffset value. 577 o For each cell in the CellList, the node MUST NOT have any 578 scheduled cell on the same slotOffset. 579 o The slotOffset value of any cell in the CellList MUST NOT be the 580 same as the slotOffset of the minimal cell (slotOffset=0). 581 o The slotOffset of a cell in the CellList SHOULD be randomly and 582 uniformly chosen among all the slotOffset values that satisfy the 583 restrictions above. 584 o The channelOffset of a cell in the CellList SHOULD be randomly and 585 uniformly chosen in [0..numFrequencies], where numFrequencies 586 represents the number of frequencies a node can communicate on. 588 9. 6P Timeout Value 590 The 6P Timeout is not a constant value. It is calculated as 591 (1/C)*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR, where: 593 o C represents the number of cells per second scheduled to that 594 neighbor 595 o PDR represents the average PDR of those cells 596 o SIXP_TIMEOUT_SEC_FACTOR is a security factor, a constant 598 10. Rule for Ordering Cells 600 Cells are ordered slotOffset first, channelOffset second. 602 The following sequence is correctly ordered (each element represents 603 the [slottOffset,channelOffset] of a cell in the schedule): 605 [1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9] 607 11. Meaning of the Metadata Field 609 The Metadata field is not used by MSF. 611 12. 6P Error Handling 613 Section 6.2.4 of [I-D.ietf-6tisch-6top-protocol] lists the 6P Return 614 Codes. Figure 1 lists the same error codes, and the behavior a node 615 implementing MSF SHOULD follow. 617 +-----------------+----------------------+ 618 | Code | RECOMMENDED behavior | 619 +-----------------+----------------------+ 620 | RC_SUCCESS | nothing | 621 | RC_EOL | nothing | 622 | RC_ERR | quarantine | 623 | RC_RESET | quarantine | 624 | RC_ERR_VERSION | quarantine | 625 | RC_ERR_SFID | quarantine | 626 | RC_ERR_SEQNUM | clear | 627 | RC_ERR_CELLLIST | clear | 628 | RC_ERR_BUSY | waitretry | 629 | RC_ERR_LOCKED | waitretry | 630 +-----------------+----------------------+ 632 Figure 1: Recommended behavior for each 6P Error Code. 634 The meaning of each behavior from Figure 1 is: 636 nothing: Indicates that this Return Code is not an error. No error 637 handling behavior is triggered. 638 clear: Abort the 6P Transaction. Issue a 6P CLEAR command to that 639 neighbor (this command may fail at the link layer). Remove all 640 cells scheduled with that neighbor from the local schedule. Keep 641 that node in the neighbor and routing tables. 642 quarantine: Same behavior as for "clear". In addition, remove the 643 node from the neighbor and routing tables. Place the node's 644 identifier in a quarantine list for QUARANTINE_DURATION. When in 645 quarantine, drop all frames received from that node. 646 waitretry: Abort the 6P Transaction. Wait for a duration randomly 647 and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX]. 648 Retry the same transaction. 650 13. Schedule Inconsistency Handling 652 The behavior when schedule inconsistency is detected is explained in 653 Figure 1, for 6P Return Code RC_ERR_SEQNUM. 655 14. MSF Constants 657 Figure 2 lists MSF Constants and their RECOMMENDED values. 659 +------------------------------+-------------------+ 660 | Name | RECOMMENDED value | 661 +------------------------------+-------------------+ 662 | KA_PERIOD | 10 s | 663 | LIM_NUMCELLSUSED_HIGH | 75 % | 664 | LIM_NUMCELLSUSED_LOW | 25 % | 665 | HOUSEKEEPINGCOLLISION_PERIOD | 1 min | 666 | RELOCATE_PDRTHRES | 50 % | 667 | SIXP_TIMEOUT_SEC_FACTOR | 3 x | 668 | SLOTFRAME_LENGTH | 101 slots | 669 | QUARANTINE_DURATION | 5 min | 670 | WAITDURATION_MIN | 30 s | 671 | WAITDURATION_MAX | 60 s | 672 +------------------------------+-------------------+ 674 Figure 2: MSF Constants and their RECOMMENDED values. 676 15. MSF Statistics 678 Figure 3 lists MSF Statistics and their RECOMMENDED width. 680 +-----------------+-------------------+ 681 | Name | RECOMMENDED width | 682 +-----------------+-------------------+ 683 | NumCellsPassed | 1 byte | 684 | NumCellsUsed | 1 byte | 685 | NumTx | 1 byte | 686 | NumTxAck | 1 byte | 687 +-----------------+-------------------+ 689 Figure 3: MSF Statistics and their RECOMMENDED width. 691 16. Security Considerations 693 MSF defines a series of "rules" for the node to follow. It triggers 694 several actions, that are carried out by the protocols defined in the 695 following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 696 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation 697 Sublayer Protocol (6P) [I-D.ietf-6tisch-6top-protocol], and the 698 Minimal Security Framework for 6TiSCH 699 [I-D.ietf-6tisch-minimal-security]. In particular, MSF does not 700 define a new protocol or packet format. 702 MSF relies entirely on the security mechanisms defined in the 703 specifications listed above. 705 17. IANA Considerations 707 17.1. MSF Scheduling Function Identifiers 709 This document adds the following number to the "6P Scheduling 710 Function Identifiers" sub-registry, part of the "IPv6 over the TSCH 711 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by 712 [I-D.ietf-6tisch-6top-protocol]: 714 +----------------------+-----------------------------+-------------+ 715 | SFID | Name | Reference | 716 +----------------------+-----------------------------+-------------+ 717 | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX | 718 | | (MSF) | (NOTE:this) | 719 +----------------------+-----------------------------+-------------+ 721 Figure 4: IETF IE Subtype '6P'. 723 18. References 725 18.1. Normative References 727 [I-D.ietf-6tisch-6top-protocol] 728 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 729 Operation Sublayer Protocol (6P)", draft-ietf-6tisch-6top- 730 protocol-12 (work in progress), June 2018. 732 [I-D.ietf-6tisch-minimal-security] 733 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 734 "Minimal Security Framework for 6TiSCH", draft-ietf- 735 6tisch-minimal-security-06 (work in progress), May 2018. 737 [I-D.richardson-6tisch-join-enhanced-beacon] 738 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 739 Element encapsulation of 6tisch Join Information", draft- 740 richardson-6tisch-join-enhanced-beacon-03 (work in 741 progress), January 2018. 743 [IEEE802154-2015] 744 IEEE standard for Information Technology, "IEEE Std 745 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 746 Networks (WPANs)", December 2015. 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, 750 DOI 10.17487/RFC2119, March 1997, 751 . 753 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 754 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 755 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 756 Low-Power and Lossy Networks", RFC 6550, 757 DOI 10.17487/RFC6550, March 2012, 758 . 760 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 761 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 762 Internet of Things (IoT): Problem Statement", RFC 7554, 763 DOI 10.17487/RFC7554, May 2015, 764 . 766 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 767 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 768 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 769 May 2017, . 771 18.2. Informative References 773 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 774 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 775 a Standards-Based Low-Power Wireless Development 776 Environment", Transactions on Emerging Telecommunications 777 Technologies , August 2012. 779 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 780 Code: The Implementation Status Section", RFC 6982, 781 DOI 10.17487/RFC6982, July 2013, 782 . 784 [SAX-DASFAA] 785 Ramakrishna, M. and J. Zobel, "Performance in Practice of 786 String Hashing Functions", DASFAA , 1997. 788 Appendix A. Contributors 790 Beshr Al Nahas (Chalmers University, beshr@chalmers.se) and Olaf 791 Landsiedel (Chalmers University, olafl@chalmers.se) contributed to 792 the design and evaluation of autonomous unicast cells. 794 Appendix B. Implementation Status 796 This section records the status of known implementations of the 797 protocol defined by this specification at the time of posting of this 798 Internet-Draft, and is based on a proposal described in [RFC6982]. 799 The description of implementations in this section is intended to 800 assist the IETF in its decision processes in progressing drafts to 801 RFCs. Please note that the listing of any individual implementation 802 here does not imply endorsement by the IETF. Furthermore, no effort 803 has been spent to verify the information presented here that was 804 supplied by IETF contributors. This is not intended as, and must not 805 be construed to be, a catalog of available implementations or their 806 features. Readers are advised to note that other implementations may 807 exist. 809 According to [RFC6982], "this will allow reviewers and working groups 810 to assign due consideration to documents that have the benefit of 811 running code, which may serve as evidence of valuable experimentation 812 and feedback that have made the implemented protocols more mature. 813 It is up to the individual working groups to use this information as 814 they see fit". 816 OpenWSN: MSF is being implemented in the OpenWSN project [OpenWSN] 817 under a BSD open-source license. The authors of this document are 818 collaborating with the OpenWSN community to gather feedback about 819 the status and performance of the protocols described in this 820 document. Results from that discussion will appear in this 821 section in future revision of this specification. More 822 information about this implementation at http://www.openwsn.org/. 823 6TiSCH simulator The 6TiSCH simulator is a Python-based high-level 824 simulator on which MSF is being implemented. More information at 825 https://bitbucket.org/6tisch/simulator/. 827 Appendix C. Performance Evaluation 829 The performance of MSF may be published as companion documents to 830 this specification, possibly under the form a applicability 831 statements. 833 Appendix D. [TEMPORARY] Changelog 835 o draft-ietf-6tisch-msf-01 837 * Added a section on pending elements. 838 o draft-ietf-6tisch-msf-00 840 * Re-publication after WG adoption. No changes. 841 o draft-chang-6tisch-msf-02 843 * Added autonomous cell. 844 o draft-chang-6tisch-msf-01 846 * When neighbor is unreachable, sending a CLEAR command was a 847 MUST, now a MAY. 848 * Fixing 6P Timeout calculation. 850 * Clearer text for "Handling Schedule Collisions" section. 851 * Typos. 852 * Input from Yasuyuki Tanaka's review (https://www.ietf.org/mail- 853 archive/web/6tisch/current/msg05723.html). 854 o draft-chang-6tisch-msf-00 856 * Initial submission. 858 Appendix E. [TEMPORARY] Pending Elements 860 E.1. Introduction 862 This section contains lessons learnt and suggestions from simulating 863 and experimenting with draft-ietf-6tisch-msf-00. This section is 864 temporary and will be removed once these suggestions are integrated 865 or abandonned. 867 E.2. Security Related 869 E.2.1. Security issue on autonomous cell installation 871 The autonomous cell to the pledge is installed on the join proxy 872 before the pledge is authorized, which is a security issue. Related 873 discussion: https://www.ietf.org/mail-archive/web/6tisch/current/ 874 msg05723.html 876 E.3. Performance Related 878 E.3.1. Handling the case when bandwidth allocation exceeds available 879 capacity 881 When node A initializes a 6top ADD transaction to node B, but node B 882 does NOT have enough bandwidth to allocate. What can node B do to 883 indicate this case in its 6top response, and how should node A handle 884 the packet after receiving the response? Related discussion: 885 https://www.ietf.org/mail-archive/web/6tisch/current/msg06095.html 887 E.3.2. joining traffic MUST be sent in minimal cell 889 Joining traffic MUST be sent in minimal cell. Issues link: 890 https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/11 892 E.3.3. NumCellsPassed shouldn't update on shared dedicated cell 894 NumCellsPassed is used to track under/overuse of cells. If we are 895 backing off, i.e. skipping cells, should those skipped cells count 896 towards NumCellsPassed? Issues link: https://github.com/twatteyne/ 897 draft-ietf-6tisch-msf/issues/13 899 E.3.4. non-trusted packet shouldn't be accounted for for adapting 900 traffic 902 Mention that the untrusted packet (e.g. join request/response) 903 shouldn't be counted for adapting the traffic. Issues link: 904 https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/15 906 E.3.5. Customize the backoff exponent on dedicated shared cell. 908 Use small backoff exponent on dedicated cell since it's only shared 909 by two nodes. Discussion: do we still have this case with the merger 910 of ASF? Issues link: https://github.com/twatteyne/draft-ietf-6tisch- 911 msf/issues/17 913 E.3.6. Adapting 6P Timeout 915 After 6P TIMEOUT, the next 6P transaction should be configured using 916 a larger TIMEOUT. Issues link: https://github.com/twatteyne/draft- 917 ietf-6tisch-msf/issues/19 919 E.3.7. Timeout calculation is wrong 921 The 6P Timeout is calculated as : 923 o (1/C)*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR 925 It should be 927 o (1/(C+1))*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR 929 according to the paper: https://arxiv.org/pdf/1507.05810.pdf Related 930 link is at: https://github.com/twatteyne/draft-ietf-6tisch-msf/ 931 issues/22 933 E.3.8. Separate Cell Counters for TX and RX 935 NumCellsUsed and NumCellsElapsed counter should be separated between 936 TX and RX. Question: still applies? Related Link is at: 937 https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/20 939 E.3.9. Two slotframes 941 Why are they two slotframes in same length? Issues link: 942 https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/25 944 E.4. editorial 946 E.4.1. Parameters for SAX is missing 948 It'd be nice to have an example or a test vector in the draft in 949 order to validate a SAX implementation used for MSF. This is 950 critical for interoperability. Related discussion: 951 https://www.ietf.org/mail-archive/web/6tisch/current/msg05723.html 953 E.4.2. Wrong end state statement 955 In Section 1, one of the end states of the join process is having 956 "one default unicast cell to/from each of its neighbors". It should 957 be an autonomous TX cells to its Join Proxy. Related discussion: 958 https://www.ietf.org/mail-archive/web/6tisch/current/msg05723.html 960 E.4.3. Dependency on RFC8180 shouldn't be a MUST 962 Section 2 states "A node implementing MSF MUST implement the Minimal 963 6TiSCH Configuration [RFC8180], which defines the "minimal cell", a 964 single shared cell providing minimal connectivity between the nodes 965 in the network". MUST here is too strong. Some may want to use MSF 966 with a base schedule other than the one defined in RFC8180, with full 967 understanding on the implications by not following RFC8180. Proposal 968 is to replace MUST by SHOULD. Related discussion: 969 https://www.ietf.org/mail-archive/web/6tisch/current/msg05723.html 971 E.4.4. DIO can be unicast packet as indicated in RFC6550 973 Section 2 states "DODAG Information Objects (DIOs), defined by 974 [RFC6550]. These are broadcast frames." However, the DIO as a 975 response to a DIS is a unicast frame. Related discussion: 976 https://www.ietf.org/mail-archive/web/6tisch/current/msg05723.html 978 E.4.5. Rules for broadcast frames is out of scope of MSF 980 In Section 2, the rules for broadcast frames on the minimal cell seem 981 to be an implementation-specific optimization. And it is beyond of 982 the scope of this draft. This idea is about how to use the minimal 983 cell efficiently; it's not directly related to how to use cells 984 scheduled by MSF. Related discussion: https://www.ietf.org/mail- 985 archive/web/6tisch/current/msg05723.html 987 E.4.6. Wrong statement in Step 4 989 In Section 4.4 Step 3, the statement "After joining" in the 990 explanation of step 3 should be "After having chosen a JP"? At this 991 step 3, "joining" is not done. Related discussion: 992 https://www.ietf.org/mail-archive/web/6tisch/current/msg05723.html 994 E.4.7. Rephrase NumCellsPassed to NumCellsElapsed 996 Rephrase NumCellsPassed to NumCellsElapsed Issues link: 997 https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/14 999 E.4.8. Create a list of packets that be able to be sent on minimal cell 1001 The current text enumerates explicitly EBs and DIOs. The other 1002 broadcast packets are not mentioned. For example: RPL DIS or 1003 application-layer broadcast? It should mention EBs and DIOs but also 1004 say "any other broadcast packet". Issues link: 1005 https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/24 1007 E.4.9. Clarify term 'dedicated cell' 1009 Terminology: "dedicated" needs to be clarified in MSF. Issues link: 1010 https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/26 1012 E.4.10. text is missing 1014 The text that describes the 6P command with cell options etc. was 1015 accidentally removed. Needs adding back somewhere. The text was: 1016 Step 5 - 6P ADD to Preferred Parent After having selected a preferred 1017 parent, the joined node MUST issue a 6P ADD command to that parent, 1018 with the following fields: 1020 o CellOptions: set to TX=1,RX=1,SHARED=1 1021 o CellOptions: set to TX=1,RX=1,SHARED=1 1022 o NumCells: set to 1 1023 o CellList: at least 5 cells, chosen according to Section 7 1025 After the 6P Transaction is finished, the node MUST synchronize only 1026 to its preferred parent. At this point, the node has a dedicated 1027 cell which allows for bidirectional communication with its preferred 1028 parent. Issues link: https://github.com/twatteyne/draft-ietf-6tisch- 1029 msf/issues/29 1031 Authors' Addresses 1032 Tengfei Chang (editor) 1033 Inria 1034 2 rue Simone Iff 1035 Paris 75012 1036 France 1038 Email: tengfei.chang@inria.fr 1040 Malisa Vucinic 1041 University of Montenegro 1042 Dzordza Vasingtona bb 1043 Podgorica 81000 1044 Montenegro 1046 Email: malisav@ac.me 1048 Xavier Vilajosana 1049 Universitat Oberta de Catalunya 1050 156 Rambla Poblenou 1051 Barcelona, Catalonia 08018 1052 Spain 1054 Email: xvilajosana@uoc.edu 1056 Simon Duquennoy 1057 RISE SICS 1058 Isafjordsgatan 22 1059 164 29 Kista 1060 Sweden 1062 Email: simon.duquennoy@ri.se 1064 Diego Dujovne (editor) 1065 Universidad Diego Portales 1066 Escuela de Informatica y Telecomunicaciones 1067 Av. Ejercito 441 1068 Santiago, Region Metropolitana 1069 Chile 1071 Phone: +56 (2) 676-8121 1072 Email: diego.dujovne@mail.udp.cl