idnits 2.17.1 draft-dujovne-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 (March 21, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SLOTFRAME' is mentioned on line 248, but not defined == Missing Reference: 'WBLIST' is mentioned on line 250, but not defined == Unused Reference: 'IEEE802154e' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'IEEE802154' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'RFC7554' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 387, but no explicit reference was found in the text -- 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 (~~), 8 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: September 22, 2016 Politecnico di Bari 6 MR. Palattella 7 University of Luxembourg 8 N. Accettura 9 University of California Berkeley 10 March 21, 2016 12 6TiSCH 6top Scheduling Function Zero (SF0) 13 draft-dujovne-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 September 22, 2016. 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. 100 2. Scheduling Function Identifier 102 The Scheduling Function Identifier (SFID) of SF0 is IANA_SFID_SF0. 104 3. Rules for Adding/Deleting Cells 106 A node running SF0 determines when to add/delete cells in a three- 107 step process: 109 1. It waits for a triggering event (Section 3.1). 110 2. It applies the Bandwidth Estimation Algorithm (BEA) for a 111 particular neighbor to determine how much bandwidth is required 112 to that neighbor (Section 3.2). 113 3. It applies the Allocation Policy to compare the number of 114 required cells to the number of already scheduled cells, and 115 determine the number of cells to add/delete (Section 3.3). 117 3.1. SF0 Triggering Events 119 We RECOMMEND SF0 to be triggered at least by the following events: 121 1. If the Remaining Available Bandwidth (RAB) is less than the 122 Minimum Remaining Bandwidth (MRB) 123 2. If there is any New Incoming Bandwidth Requirements from 124 neighbour nodes (NIBR) 126 This allows SF0 to be triggered by any change in local node bandwidth 127 and/or incoming bandwidth. The exact mechanism of when SF0 is 128 triggered is implementation-specific. 130 3.2. SF0 Bandwidth Estimation Algorithm 132 The Bandwidth Estimation Algorithm takes into account the sum of the 133 incoming bandwidth requirements from the neighbour nodes and the used 134 outgoing bandwidth. This allows the node to estimate the total 135 outgoing bandwidth requirement. As a consequence, the Bandwidth 136 Estimation Algorithm for SF0 follows the steps described below: 138 1. Collect the New Incoming Bandwidth Requirements from neighbour 139 nodes (NIBR) 140 2. Obtain the Current Outgoing Bandwidth Usage (COBU) 141 3. Obtain the number of Current Scheduled Bandwidth (CSB) 142 4. Calculate the New Outgoing Bandwidth (NOB) as: NOB=COBU+NIBR 143 5. Calculate the Remaining Available Bandwidth (RAB) as RAB=CSB-NOB 144 6. If the RAB is less than the Minimum Remaining Bandwidth (MRB), 145 Add MRB to the NOB: NOB=NOB+MRB 146 7. Submit the request to the allocation policy 147 8. Return to step 1 and wait for a triggering event. 149 3.3. SF0 Allocation Policy 151 The "Allocation Policy" is the set of rules used by SF0 to decide 152 when to add/delete cells to a particular neighbor to satisfy the 153 bandwidth requirements. 155 SF0 uses the following parameters: 157 SCHEDULEDCELLS: The number of cells scheduled from the current node 158 to a particular neighbor. 159 REQUIREDCELLS: The number of cells calculated by the Bandwidth 160 Estimation Algorithm from the current node to that neighbor. 161 SF0THRESH: Threshold parameter introducing cell over-provisioning in 162 the allocation policy. It is a non-negative value expressed as 163 number of cells. The definition of this value is implementation- 164 specific; however, it is RECOMMENDED a SF0THRESH value of 3 cells. 165 A setting of SF0THRESH>0 will cause the node to allocate at least 166 SF0THRESH cells to each of its' neighbours. 168 The SF0 allocation policy compares REQUIREDCELLS with SCHEDULEDCELLS 169 and decides to add/delete cells taking into account SF0THRESH. This 170 is illustrated in Figure 1. 172 SCHEDULEDCELLS 173 <---------------------------------> 174 +---+---+---+---+---+---+---+---+---+ 175 | | | | | | | | | | 176 +---+---+---+---+---+---+---+---+---+ 177 |<----------------->| 178 | SF0THRESH | 179 | | 180 REQUIREDCELLS | | 181 +---+---+ | | DELETE 182 | | | | | ONE/MORE 183 +---+---+ | | CELLS 184 | | 185 REQUIREDCELLS | 186 +---+---+---+---+---+---+ | DO 187 | | | | | | | | NOTHING 188 +---+---+---+---+---+---+ | 189 | | 190 REQUIREDCELLS | 191 +---+---+---+---+---+---+---+---+---+---+ ADD 192 | | | | | | | | | | | ONE/MORE 193 +---+---+---+---+---+---+---+---+---+---+ CELLS 195 Figure 1: The SF0 Allocation Policy 197 1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more 198 cells. 199 2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do 200 nothing. 201 3. If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells. 203 When SF0THRESH equals 0, any discrepancy between REQUIREDCELLS and 204 SCHEDULEDCELLS triggers an action to add/delete cells. Positive 205 values of SF0THRESH reduce the number of 6P Transactions. 207 The Allocation Policy also translates the bandwidth requirement into 208 cells according to their PDR. For example, if a cell with a 100% PDR 209 is equivalent to 1Kbps, and the required bandwith is 8Kbps, then, the 210 number of scheduled cells will be 8. However, if two of the 211 allocated cells have a 70% PDR, there number of scheduled cells will 212 be 9. 214 4. Rules for CellList 216 When issuing a 6top ADD Request, SF0 executes the following sequence: 218 Whitelist case: 220 The Transaction Source node: Prepares the CellList field by 221 selecting randomly the required cells, verifying that the slot 222 offset and channel offset are not occupied. 223 The Transaction Destination node: Goes through the cells in the 224 CellList in order, verifying whether there are no slotOffset 225 conflicts. 226 Blacklist case: 228 The Transaction Source node: Prepares the CellList field by 229 building a list of currently scheduled cells into the CellList. 230 The Transaction Destination node: Selects randomly the required 231 cells, verifying that the slot offset and channel offset are 232 not occupied from the ones on the CellList. 234 5. 6P Timeout Value 236 The 6P Timeout Value provided by SF0 allows the maximum number of 237 TSCH link-layer retries. Given the TSCH parameters for the backoff 238 mechanism, macMinBE and macMaxBE, and the length in seconds of the 239 minimal Slotframe, SM, the timeout value is computed as: timeout = 240 (2^(macMaxBE+1)-2^macMinBE) * SM TODO: Change general timeout to a 241 timeout adapted to the schedule: SF to use the number of slots until 242 the next scheduled cell. 244 6. Meaning of Metadata Information 246 The Metadata 16-bit field is used as follows: 248 BITS 0-7 [SLOTFRAME] are used to identify the slotframe number 249 BITS 8-14 are RESERVED 250 BIT 15 [WBLIST] is used to indicate that the CellList provided is 251 a Whitelist (value=0) or a Blacklist (value=1). 253 TODO: length of the SlotFrame SHOULD be an integer multiple of the 254 length of the minimal SlotFrame. 256 7. Node Behavior at Boot 258 In order to define a known state after the node is restarted, a CLEAR 259 command is issued to each of the neighbour nodes to enable a new 260 allocation process. TODO: Temporary cells from a pool for the join 261 process. 263 8. Relocating Cells 265 SF0 uses Packet Delivery Rate (PDR) statistics to monitor the 266 currently allocated cells for cell re-allocation (by changing their 267 slotOffset and/or channelOffset) when it finds out that the PDR of 268 one or more softcells below 20% of the average PDR. 270 9. Forced Cell Deletion Policy 272 TODO: When all the cells are scheduled, we need a policy to free 273 cells, for example, under alarm conditions or if a node dissappears 274 from the neighbour list. 276 10. 6P Error Handling 278 A node implementing SF0 handles a 6P Response depending on the Return 279 Code it contains: 281 RC_SUCCESS: 282 If the number of elements in the CellList is the number of cells 283 specified in the NumCells field of the 6P ALL Request, the 284 operation is complete. The node does not take further action. 285 If the number of elements in the CellList is smaller (possibly 0) 286 than the number of cells specified in the NumCells field of the 6P 287 ALL Request, the neighbor has received the request, but less than 288 NumCells of the cells in the CellList were. In that case, the 289 node MAY retry immediately with a different CellList if the amount 290 of storage space permits, or build a new (random) CellList. 291 RC_ERR_VER: The node MUST NOT retry immediately. The node MAY add 292 the neighbor node on a blacklist. The node MAY retry to contact 293 this neighbor later. 294 RC_ERR_6OFID: The node MUST NOT retry immediately. The node MAY add 295 the neighbor node on a blacklist. The node MAY retry to contact 296 this neighbor later. 297 RC_ERR_NORESOURCES: Wait for a timeout and restart the scheduling 298 process. 299 RC_ERR_BUSY: Issue a RESET command. 301 11. Examples 303 TODO 305 12. Implementation Status 307 This section records the status of known implementations of the 308 protocol defined by this specification at the time of posting of this 309 Internet-Draft, and is based on a proposal described in [RFC6982]. 310 The description of implementations in this section is intended to 311 assist the IETF in its decision processes in progressing drafts to 312 RFCs. Please note that the listing of any individual implementation 313 here does not imply endorsement by the IETF. Furthermore, no effort 314 has been spent to verify the information presented here that was 315 supplied by IETF contributors. This is not intended as, and must not 316 be construed to be, a catalog of available implementations or their 317 features. Readers are advised to note that other implementations may 318 exist. 320 According to [RFC6982], "this will allow reviewers and working groups 321 to assign due consideration to documents that have the benefit of 322 running code, which may serve as evidence of valuable experimentation 323 and feedback that have made the implemented protocols more mature. 324 It is up to the individual working groups to use this information as 325 they see fit". 327 OpenWSN: This specification is implemented in the OpenWSN project 328 [OpenWSN]. The authors of this document are collaborating with 329 the OpenWSN community to gather feedback about the status and 330 performance of the protocols described in this document. Results 331 from that discussion will appear in this section in future 332 revision of this specification. 334 13. Security Considerations 336 TODO 338 14. IANA Considerations 340 o IANA_SFID_SF0 342 15. Acknowledgments 344 Thanks to Kris Pister for his contribution in designing the default 345 Bandwidth Estimation Algorithm. Thanks to Qin Wang and Thomas 346 Watteyne for their support in defining the interaction between SF0 347 and the 6top sublayer. 349 This work is partially supported by the Fondecyt 1121475 Project, the 350 Inria-Chile "Network Design" group, and the IoT6 European Project 351 (STREP) of the 7th Framework Program (Grant 288445). 353 16. References 355 16.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [IEEE802154e] 363 IEEE standard for Information Technology, "IEEE std. 364 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 365 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 366 2012. 368 [IEEE802154] 369 IEEE standard for Information Technology, "IEEE std. 370 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 371 and Physical Layer (PHY) Specifications for Low-Rate 372 Wireless Personal Area Networks", June 2011. 374 16.2. Informative References 376 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 377 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 378 Internet of Things (IoT): Problem Statement", RFC 7554, 379 DOI 10.17487/RFC7554, May 2015, 380 . 382 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 383 Code: The Implementation Status Section", RFC 6982, 384 DOI 10.17487/RFC6982, July 2013, 385 . 387 [I-D.ietf-6tisch-terminology] 388 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 389 "Terminology in IPv6 over the TSCH mode of IEEE 390 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 391 progress), March 2016. 393 [I-D.wang-6tisch-6top-sublayer] 394 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 395 (6top)", draft-wang-6tisch-6top-sublayer-04 (work in 396 progress), November 2015. 398 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 399 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 400 a Standards-Based Low-Power Wireless Development 401 Environment", Transactions on Emerging Telecommunications 402 Technologies , August 2012. 404 Authors' Addresses 405 Diego Dujovne (editor) 406 Universidad Diego Portales 407 Escuela de Informatica y Telecomunicaciones 408 Av. Ejercito 441 409 Santiago, Region Metropolitana 410 Chile 412 Phone: +56 (2) 676-8121 413 Email: diego.dujovne@mail.udp.cl 415 Luigi Alfredo Grieco 416 Politecnico di Bari 417 Department of Electrical and Information Engineering 418 Via Orabona 4 419 Bari 70125 420 Italy 422 Phone: 00390805963911 423 Email: a.grieco@poliba.it 425 Maria Rita Palattella 426 University of Luxembourg 427 Interdisciplinary Centre for Security, Reliability and Trust 428 4, rue Alphonse Weicker 429 Luxembourg L-2721 430 LUXEMBOURG 432 Phone: (+352) 46 66 44 5841 433 Email: maria-rita.palattella@uni.lu 435 Nicola Accettura 436 University of California Berkeley 437 Berkeley Sensor & Actuator Center 438 490 Cory Hall 439 Berkeley, California 94720 440 USA 442 Email: nicola.accettura@eecs.berkeley.edu