idnits 2.17.1 draft-ietf-6tisch-6top-sf0-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 (July 8, 2016) is 2850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SLOTFRAME' is mentioned on line 246, but not defined == Missing Reference: 'WBLIST' is mentioned on line 248, but not defined -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH D. Dujovne, Ed. 3 Internet-Draft Universidad Diego Portales 4 Intended status: Informational LA. Grieco 5 Expires: January 9, 2017 Politecnico di Bari 6 MR. Palattella 7 University of Luxembourg 8 N. Accettura 9 University of California Berkeley 10 July 8, 2016 12 6TiSCH 6top Scheduling Function Zero (SF0) 13 draft-ietf-6tisch-6top-sf0-01 15 Abstract 17 This document defines a 6top Scheduling Function called "Scheduling 18 Function Zero" (SF0). SF0 dynamically adapts the number of reserved 19 cells between neighbor nodes, based on the currently allocated 20 bandwidth and the neighbour nodes' requirements. Neighbor nodes 21 negotiate in a distributed neighbor-to-neighbor basis the cell(s) to 22 be added/deleted. SF0 uses the 6P signaling messages to add/delete 23 cells in the schedule. Some basic rules for deciding when to add/ 24 delete cells and for selecting the cells to be added/deleted within 25 the schedule are also provided. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in RFC 32 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2017. 50 Copyright Notice 52 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Scheduling Function Identifier . . . . . . . . . . . . . . . 3 69 3. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 3 70 3.1. SF0 Triggering Events . . . . . . . . . . . . . . . . . . 3 71 3.2. SF0 Bandwidth Estimation Algorithm . . . . . . . . . . . 3 72 3.3. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . 4 73 4. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 5 74 5. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 6 75 6. Meaning of Metadata Information . . . . . . . . . . . . . . . 6 76 7. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6 77 8. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 6 78 9. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 7 79 10. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 7 80 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 85 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 16.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 16.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 This document defines the Scheduling Function for the 6top sublayer 93 [I-D.wang-6tisch-6top-sublayer] called "Scheduling Function Zero" 94 (SF0). 96 This document addresses the requirements for a scheduling function 97 listed in [I-D.wang-6tisch-6top-sublayer], Section 4.2, and follows 98 the recommended outline from Section 4.3. This draft agrees with the 99 terminology defined on [I-D.ietf-6tisch-terminology] and is designed 100 within the context of [RFC7554] 102 2. Scheduling Function Identifier 104 The Scheduling Function Identifier (SFID) of SF0 is IANA_SFID_SF0. 106 3. Rules for Adding/Deleting Cells 108 A node running SF0 determines when to add/delete cells in a three- 109 step process: 111 1. It waits for a triggering event (Section 3.1). 112 2. It applies the Bandwidth Estimation Algorithm (BEA) for a 113 particular neighbor to determine how much bandwidth is required 114 to that neighbor (Section 3.2). 115 3. It applies the Allocation Policy to compare the number of 116 required cells to the number of already scheduled cells, and 117 determine the number of cells to add/delete (Section 3.3). 119 3.1. SF0 Triggering Events 121 We RECOMMEND SF0 to be triggered at least by the following events: 123 1. If there is a change in the Current Outgoing Bandwidth Usage 124 (COBU) 125 2. If there is any New Incoming Bandwidth Requirements from 126 neighbour nodes (NIBR) 128 This allows SF0 to be triggered by any change in local outgoing 129 bandwidth and/or incoming bandwidth. A relocation request from the 130 neighbour is considered as an Incoming Bandwidth Request, given that 131 it is expected to increase packet delivery rate on the relocated 132 cells, thus increasing the required bandwidth. The exact mechanism 133 of when SF0 is triggered is implementation-specific. 135 3.2. SF0 Bandwidth Estimation Algorithm 137 The Bandwidth Estimation Algorithm takes into account the sum of the 138 incoming bandwidth requirements from the neighbour nodes and also the 139 current outgoing bandwidth value. This allows the node to estimate 140 the total outgoing bandwidth requirement. As a consequence, the 141 Bandwidth Estimation Algorithm for SF0 follows the steps described 142 below: 144 1. Collect the New Incoming Bandwidth Requirements from neighbour 145 nodes (NIBR) 146 2. Obtain the Current Outgoing Bandwidth Usage (COBU) 147 3. Calculate the New Outgoing Bandwidth (NOB) as: NOB=COBU+NIBR 148 4. Submit the request to the allocation policy 149 5. Return to step 1 and wait for a triggering event. 151 3.3. SF0 Allocation Policy 153 The "Allocation Policy" is the set of rules used by SF0 to decide 154 when to add/delete cells to a particular neighbor to satisfy the 155 bandwidth requirements. 157 SF0 uses the following parameters: 159 SCHEDULEDCELLS: The number of cells scheduled from the current node 160 to a particular neighbor. 161 REQUIREDCELLS: The number of cells calculated by the Bandwidth 162 Estimation Algorithm from the current node to that neighbor. 163 SF0THRESH: Threshold parameter introducing cell over-provisioning in 164 the allocation policy. It is a non-negative value expressed as 165 number of cells. The definition of this value is implementation- 166 specific. A setting of SF0THRESH>0 will cause the node to 167 allocate at least SF0THRESH cells to each of its' neighbours. 169 The SF0 allocation policy compares REQUIREDCELLS with SCHEDULEDCELLS 170 and decides to add/delete cells taking into account SF0THRESH. This 171 is illustrated in Figure 1. 173 SCHEDULEDCELLS 174 <---------------------------------> 175 +---+---+---+---+---+---+---+---+---+ 176 | | | | | | | | | | 177 +---+---+---+---+---+---+---+---+---+ 178 |<--------->| 179 | SF0THRESH | 180 | | 181 REQUIREDCELLS | | 182 +---+---+ | | DELETE 183 | | | | | ONE/MORE 184 +---+---+ | | CELLS 185 | | 186 REQUIREDCELLS | 187 +---+---+---+---+---+---+ | DO 188 | | | | | | | | NOTHING 189 +---+---+---+---+---+---+ | 190 | | 191 REQUIREDCELLS | 192 +---+---+---+---+---+---+---+---+---+---+ ADD 193 | | | | | | | | | | | ONE/MORE 194 +---+---+---+---+---+---+---+---+---+---+ CELLS 196 Figure 1: The SF0 Allocation Policy 198 1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more 199 cells. 200 2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do 201 nothing. 202 3. If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells. 204 When SF0THRESH equals 0, any discrepancy between REQUIREDCELLS and 205 SCHEDULEDCELLS triggers an action to add/delete cells. Positive 206 values of SF0THRESH reduce the number of 6P Transactions. 208 The Allocation Policy also translates the bandwidth requirement into 209 cells according to their PDR. For example, if a cell with a 100% PDR 210 is equivalent to 1Kbps, and the required bandwith is 8Kbps, then, the 211 number of scheduled cells will be 8. However, if two of the 212 allocated cells have a 70% PDR, there number of scheduled cells will 213 be 9. 215 4. Rules for CellList 217 When issuing a 6top ADD Request, SF0 executes the following sequence: 219 Whitelist case: 221 The Transaction Source node: Prepares the CellList field by 222 selecting randomly the required cells, verifying that the slot 223 offset and channel offset are not occupied and choose 224 channelOffset randomly for each cell. 225 The Transaction Destination node: Goes through the cells in the 226 CellList in order, verifying whether there are no slotOffset 227 conflicts. 228 Blacklist case: 230 The Transaction Source node: Prepares the CellList field by 231 building a list of currently scheduled cells into the CellList. 232 The Transaction Destination node: Selects randomly the required 233 cells from the unallocated cells on the schedule, verifying 234 that the slot offset and channel offset are not occupied from 235 the ones on the CellList. 237 5. 6P Timeout Value 239 The general timeout equals the equivalent time of the number of slots 240 until the next scheduled cell. 242 6. Meaning of Metadata Information 244 The Metadata 16-bit field is used as follows: 246 BITS 0-7 [SLOTFRAME] are used to identify the slotframe number 247 BITS 8-14 are RESERVED 248 BIT 15 [WBLIST] is used to indicate that the CellList provided is 249 a Whitelist (value=0) or a Blacklist (value=1). 251 TODO: length of the SlotFrame SHOULD be an integer multiple of the 252 length of the minimal SlotFrame. 254 7. Node Behavior at Boot 256 In order to define a known state after the node is restarted, a CLEAR 257 command is issued to each of the neighbour nodes to enable a new 258 allocation process. The 6P Initial Timeout Value provided by SF0 259 allows the maximum number of TSCH link-layer retries. Given the TSCH 260 parameters for the backoff mechanism, macMinBE and macMaxBE, and the 261 length in seconds of the minimal Slotframe, SM, the timeout value is 262 computed as: timeout = (2^(macMaxBE+1)-2^macMinBE) * SM 264 8. Relocating Cells 266 SF0 uses Packet Delivery Rate (PDR) statistics to monitor the 267 currently allocated cells for cell re-allocation (by changing their 268 slotOffset and/or channelOffset) when it finds out that the PDR of 269 one or more softcells below 20% of the average PDR. 271 9. Forced Cell Deletion Policy 273 TODO: When all the cells are scheduled, we need a policy to free 274 cells, for example, under alarm conditions or if a node dissappears 275 from the neighbour list. 277 10. 6P Error Handling 279 A node implementing SF0 handles a 6P Response depending on the Return 280 Code it contains: 282 RC_SUCCESS: 283 If the number of elements in the CellList is the number of cells 284 specified in the NumCells field of the 6P ALL Request, the 285 operation is complete. The node does not take further action. 286 If the number of elements in the CellList is smaller (possibly 0) 287 than the number of cells specified in the NumCells field of the 6P 288 ALL Request, the neighbor has received the request, but less than 289 NumCells of the cells in the CellList were. In that case, the 290 node MAY retry immediately with a different CellList if the amount 291 of storage space permits, or build a new (random) CellList. 292 RC_VER_ERR: The node MUST NOT retry immediately. The node MAY add 293 the neighbor node on a blacklist. The node MAY retry to contact 294 this neighbor later. 295 RC_SFID_ERR: The node MUST NOT retry immediately. The node MAY add 296 the neighbor node on a blacklist. The node MAY retry to contact 297 this neighbor later. 298 RC_BUSY: Wait for a timeout and restart the scheduling process. 299 RC_RESET: Abort 6P Transaction 300 RC_ERR: Abort 6P Transaction. The node MAY retry to contact this 301 neighbor later. 303 11. Examples 305 TODO 307 12. Implementation Status 309 This section records the status of known implementations of the 310 protocol defined by this specification at the time of posting of this 311 Internet-Draft, and is based on a proposal described in [RFC6982]. 312 The description of implementations in this section is intended to 313 assist the IETF in its decision processes in progressing drafts to 314 RFCs. Please note that the listing of any individual implementation 315 here does not imply endorsement by the IETF. Furthermore, no effort 316 has been spent to verify the information presented here that was 317 supplied by IETF contributors. This is not intended as, and must not 318 be construed to be, a catalog of available implementations or their 319 features. Readers are advised to note that other implementations may 320 exist. 322 According to [RFC6982], "this will allow reviewers and working groups 323 to assign due consideration to documents that have the benefit of 324 running code, which may serve as evidence of valuable experimentation 325 and feedback that have made the implemented protocols more mature. 326 It is up to the individual working groups to use this information as 327 they see fit". 329 OpenWSN: This specification is implemented in the OpenWSN project 330 [OpenWSN]. The authors of this document are collaborating with 331 the OpenWSN community to gather feedback about the status and 332 performance of the protocols described in this document. Results 333 from that discussion will appear in this section in future 334 revision of this specification. 336 13. Security Considerations 338 TODO 340 14. IANA Considerations 342 o IANA_SFID_SF0 344 15. Acknowledgments 346 Thanks to Kris Pister for his contribution in designing the default 347 Bandwidth Estimation Algorithm. Thanks to Qin Wang and Thomas 348 Watteyne for their support in defining the interaction between SF0 349 and the 6top sublayer. 351 This work is partially supported by the Fondecyt 1121475 Project, the 352 Inria-Chile "Network Design" group, and the IoT6 European Project 353 (STREP) of the 7th Framework Program (Grant 288445). 355 16. References 357 16.1. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, 361 DOI 10.17487/RFC2119, March 1997, 362 . 364 16.2. Informative References 366 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 367 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 368 Internet of Things (IoT): Problem Statement", RFC 7554, 369 DOI 10.17487/RFC7554, May 2015, 370 . 372 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 373 Code: The Implementation Status Section", RFC 6982, 374 DOI 10.17487/RFC6982, July 2013, 375 . 377 [I-D.ietf-6tisch-terminology] 378 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 379 "Terminology in IPv6 over the TSCH mode of IEEE 380 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 381 progress), March 2016. 383 [I-D.wang-6tisch-6top-sublayer] 384 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 385 (6top)", draft-wang-6tisch-6top-sublayer-04 (work in 386 progress), November 2015. 388 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 389 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 390 a Standards-Based Low-Power Wireless Development 391 Environment", Transactions on Emerging Telecommunications 392 Technologies , August 2012. 394 Authors' Addresses 396 Diego Dujovne (editor) 397 Universidad Diego Portales 398 Escuela de Informatica y Telecomunicaciones 399 Av. Ejercito 441 400 Santiago, Region Metropolitana 401 Chile 403 Phone: +56 (2) 676-8121 404 Email: diego.dujovne@mail.udp.cl 405 Luigi Alfredo Grieco 406 Politecnico di Bari 407 Department of Electrical and Information Engineering 408 Via Orabona 4 409 Bari 70125 410 Italy 412 Phone: 00390805963911 413 Email: a.grieco@poliba.it 415 Maria Rita Palattella 416 University of Luxembourg 417 Interdisciplinary Centre for Security, Reliability and Trust 418 4, rue Alphonse Weicker 419 Luxembourg L-2721 420 LUXEMBOURG 422 Phone: (+352) 46 66 44 5841 423 Email: maria-rita.palattella@uni.lu 425 Nicola Accettura 426 University of California Berkeley 427 Berkeley Sensor & Actuator Center 428 490 Cory Hall 429 Berkeley, California 94720 430 USA 432 Email: nicola.accettura@eecs.berkeley.edu