idnits 2.17.1 draft-dujovne-6tisch-6top-sf0-00.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 19, 2015) is 3105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE802154e' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'IEEE802154' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC7554' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 350, 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-05 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-02 Summary: 0 errors (**), 0 flaws (~~), 7 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: April 21, 2016 Politecnico di Bari 6 MR. Palattella 7 University of Luxembourg 8 N. Accettura 9 University of California Berkeley 10 October 19, 2015 12 6TiSCH 6top Scheduling Function Zero (SF0) 13 draft-dujovne-6tisch-6top-sf0-00 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 specific application's 20 bandwidth requirements and the network condition. 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 April 21, 2016. 50 Copyright Notice 52 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . 5 75 6. Meaning of Container Field . . . . . . . . . . . . . . . . . 5 76 7. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 5 77 8. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 6 78 9. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 6 79 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 81 12. Security Considerations . . . . . . . . . . . . . . . . . . . 7 82 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 83 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 15.1. Normative References . . . . . . . . . . . . . . . . . . 7 86 15.2. Informative References . . . . . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 89 1. Introduction 91 This document defines the a Scheduling Function for the 6top sublayer 92 [I-D.wang-6tisch-6top-sublayer] called "Scheduling Function Zero" 93 (SF0). 95 This document addresses the requirements for a scheduling function 96 listed in [I-D.wang-6tisch-6top-sublayer], Section 4.2, and follows 97 the recommended outline from Section 4.3. 99 2. Scheduling Function Identifier 101 The Scheduling Function Identifier (SFID) of SF0 is IANA_SFID_SF0. 103 3. Rules for Adding/Deleting Cells 105 A node running SF0 determines when to add/delete cells in a three- 106 step process: 108 1. It waits for a triggering event (Section 3.1). 109 2. It applies the Bandwidth Estimation Algorithm for a particular 110 neighbor to determine how many cells are required to that 111 neighbor (Section 3.2). 112 3. It applies the Allocation Policy to compare the number of 113 required cells to the number of already scheduled cells, and 114 determine the number of cells to add/delete (Section 3.3). 116 3.1. SF0 Triggering Events 118 We RECOMMEND SF0 to monitor the bandwidth usage on the node (local 119 node bandwidth) and bandwidth requests from neighbour nodes (incoming 120 bandwidth). This allows SF0 to be triggered by any change in local 121 node bandwidth and/or incoming bandwidth. The exact mechanism of 122 when SF0 is triggered is implementation-specific. 124 3.2. SF0 Bandwidth Estimation Algorithm 126 The Bandwidth Estimation Algorithm takes into account the sum of the 127 incoming bandwidth requirements from the neighbour nodes and the 128 local bandwidth requirements. This allows the node to calculate the 129 total outcoming bandwidth requirement. As a consequence, the 130 Bandwidth Estimation Algorithm for SF0 follows the steps described 131 below: 133 1. Collect the Incoming Bandwidth Requirements from neighbour nodes 134 (IBR). 135 2. Collect the Local node Bandwidth Requirements (LBR). 136 3. Calculate the updated total Outgoing Bandwidth Requirement (OBR) 137 as: OBR=LBR+IBR and submit the request to the allocation policy. 138 4. Return to step 1. 140 3.3. SF0 Allocation Policy 142 The "Allocation Policy" is the set of rules used by SF0 to decide 143 when to add/delete cells to a particular neighbor to satisfy the 144 bandwidth requirements. 146 SF0 uses the following parameters: 148 SCHEDULEDCELLS: The number of cells scheduled from the current cell 149 to a particular neighbor. 150 REQUIREDCELLS: The number of cells calculated by the Bandwidth 151 Estimation Algorithm from the current node to that neighbor. 152 SF0THRESH: Threshold parameter introducing cell over-provisioning in 153 the allocation policy. It is a non-negative value expressed as 154 number of cells. The definition of this value is implementation- 155 specific; however, it is RECOMMENDED a SF0THRESH value of 3 cells. 156 A setting of SF0THRESH>0 will cause the node to allocate at least 157 SF0THRESH cells to each of its' neighbours. 159 The SF0 allocation policy compares REQUIREDCELLS with SCHEDULEDCELLS 160 and decides to add/delete cells taking into account SF0THRESH. This 161 is illustrated in Figure 1. 163 SCHEDULEDCELLS 164 <---------------------------------> 165 +---+---+---+---+---+---+---+---+---+ 166 | | | | | | | | | | 167 +---+---+---+---+---+---+---+---+---+ 168 |<----------------->| 169 | SF0THRESH | 170 | | 171 REQUIREDCELLS | | 172 +---+---+ | | DELETE 173 | | | | | ONE/MORE 174 +---+---+ | | CELLS 175 | | 176 REQUIREDCELLS | 177 +---+---+---+---+---+---+ | DO 178 | | | | | | | | NOTHING 179 +---+---+---+---+---+---+ | 180 | | 181 REQUIREDCELLS | 182 +---+---+---+---+---+---+---+---+---+---+ ADD 183 | | | | | | | | | | | ONE/MORE 184 +---+---+---+---+---+---+---+---+---+---+ CELLS 186 Figure 1: The SF0 Allocation Policy 188 1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more 189 cells. 190 2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do 191 nothing. 192 3. If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells. 194 When SF0THRESH equals 0, any discrepancy between REQUIREDCELLS and 195 SCHEDULEDCELLS triggers an action to add/delete cells. Positive 196 values of SF0THRESH reduce the number of 6P Transactions. 198 4. Rules for CellList 200 When issuing a 6top ADD Request, SF0 executes the following sequence: 202 The Transaction Source node, for each of the cells to be put in 203 the CellList field, first selects the slotOffset randomly; second, 204 it verifies if the slotOffset is free and third it chooses the 205 channelOffset randomly. 206 The Transaction Destination node goes through the cells in the 207 CellList in order. For each one, it verifies whether it has a 208 cell schedule with the same slotOffset. If yes, it skips the 209 cell. If not, it allocates the cell. This stops when either (1) 210 it has scheduled NumCells cells or (2) there are no more cells in 211 the CellList. 213 5. 6P Timeout Value 215 The 6P Timeout Value provided by SF0 allows the maximum number of 216 TSCH link-layer retries. Given the TSCH parameters for the backoff 217 mechanism, macMinBE and macMaxBE, and the length in seconds of the 218 minimal Slotframe, SM, the timeout value is computed as: timeout = 219 (2^(macMaxBE+1)-2^macMinBE) * SM 221 6. Meaning of Container Field 223 TODO: length of the SlotFrame SHOULD be an integer multiple of the 224 length of the minimal SlotFrame. 226 7. Node Behavior at Boot 228 In order to define a known state after the node is restarted, a CLEAR 229 command is issued to each of the neighbour nodes to enable a new 230 allocation process. 232 8. Relocating Cells 234 SF0 uses Packet Delivery Rate (PDR) statistics to monitor the 235 currently allocated cells for cell re-allocation (by changing their 236 slotOffset and/or channelOffset) when it finds out that the PDR of 237 one or more softcells is much lower than average. 239 9. 6P Error Handling 241 A node implementing SF0 handles a 6P Response depending on the Return 242 Code it contains: 244 RC_SUCCESS: 245 If the number of elements in the CellList is the number of cells 246 specified in the NumCells field of the 6P ALL Request, the 247 operation is complete. The node does not take further action. 248 If the number of elements in the CellList is smaller (possibly 0) 249 than the number of cells specified in the NumCells field of the 6P 250 ALL Request, the neighbor has received the request, but less than 251 NumCells of the cells in the CellList were. In that case, the 252 node MAY retry immediately with a different CellList if the amount 253 of storage space permits, or build a new (random) CellList. 254 RC_ERR_VER: The node MUST NOT retry immediately. The node MAY add 255 the neighbor node on a blacklist. The node MAY retry to contact 256 this neighbor later. 257 RC_ERR_6OFID: The node MUST NOT retry immediately. The node MAY add 258 the neighbor node on a blacklist. The node MAY retry to contact 259 this neighbor later. 260 RC_ERR_NORESOURCES: Wait for a timeout and restart the scheduling 261 process. 262 RC_ERR_BUSY: Issue a RESET command. 264 10. Examples 266 TODO 268 11. Implementation Status 270 This section records the status of known implementations of the 271 protocol defined by this specification at the time of posting of this 272 Internet-Draft, and is based on a proposal described in [RFC6982]. 273 The description of implementations in this section is intended to 274 assist the IETF in its decision processes in progressing drafts to 275 RFCs. Please note that the listing of any individual implementation 276 here does not imply endorsement by the IETF. Furthermore, no effort 277 has been spent to verify the information presented here that was 278 supplied by IETF contributors. This is not intended as, and must not 279 be construed to be, a catalog of available implementations or their 280 features. Readers are advised to note that other implementations may 281 exist. 283 According to [RFC6982], "this will allow reviewers and working groups 284 to assign due consideration to documents that have the benefit of 285 running code, which may serve as evidence of valuable experimentation 286 and feedback that have made the implemented protocols more mature. 287 It is up to the individual working groups to use this information as 288 they see fit". 290 OpenWSN: This specification is implemented in the OpenWSN project 291 [OpenWSN]. The authors of this document are collaborating with 292 the OpenWSN community to gather feedback about the status and 293 performance of the protocols described in this document. Results 294 from that discussion will appear in this section in future 295 revision of this specification. 297 12. Security Considerations 299 TODO 301 13. IANA Considerations 303 o IANA_SFID_SF0 305 14. Acknowledgments 307 Thanks to Kris Pister for his contribution in designing the default 308 Bandwidth Estimation Algorithm. Thanks to Qin Wang and Thomas 309 Watteyne for their support in defining the interaction between SF0 310 and the 6top sublayer. 312 This work is partially supported by the Fondecyt 1121475 Project, the 313 Inria-Chile "Network Design" group, and the IoT6 European Project 314 (STREP) of the 7th Framework Program (Grant 288445). 316 15. References 318 15.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [IEEE802154e] 326 IEEE standard for Information Technology, "IEEE std. 327 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 328 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 329 2012. 331 [IEEE802154] 332 IEEE standard for Information Technology, "IEEE std. 333 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 334 and Physical Layer (PHY) Specifications for Low-Rate 335 Wireless Personal Area Networks", June 2011. 337 15.2. Informative References 339 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 340 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 341 Internet of Things (IoT): Problem Statement", RFC 7554, 342 DOI 10.17487/RFC7554, May 2015, 343 . 345 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 346 Code: The Implementation Status Section", RFC 6982, 347 DOI 10.17487/RFC6982, July 2013, 348 . 350 [I-D.ietf-6tisch-terminology] 351 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 352 "Terminology in IPv6 over the TSCH mode of IEEE 353 802.15.4e", draft-ietf-6tisch-terminology-05 (work in 354 progress), July 2015. 356 [I-D.wang-6tisch-6top-sublayer] 357 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 358 (6top)", draft-wang-6tisch-6top-sublayer-02 (work in 359 progress), October 2015. 361 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 362 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 363 a Standards-Based Low-Power Wireless Development 364 Environment", Transactions on Emerging Telecommunications 365 Technologies , August 2012. 367 Authors' Addresses 368 Diego Dujovne (editor) 369 Universidad Diego Portales 370 Escuela de Informatica y Telecomunicaciones 371 Av. Ejercito 441 372 Santiago, Region Metropolitana 373 Chile 375 Phone: +56 (2) 676-8121 376 Email: diego.dujovne@mail.udp.cl 378 Luigi Alfredo Grieco 379 Politecnico di Bari 380 Department of Electrical and Information Engineering 381 Via Orabona 4 382 Bari 70125 383 Italy 385 Phone: 00390805963911 386 Email: a.grieco@poliba.it 388 Maria Rita Palattella 389 University of Luxembourg 390 Interdisciplinary Centre for Security, Reliability and Trust 391 4, rue Alphonse Weicker 392 Luxembourg L-2721 393 LUXEMBOURG 395 Phone: (+352) 46 66 44 5841 396 Email: maria-rita.palattella@uni.lu 398 Nicola Accettura 399 University of California Berkeley 400 Berkeley Sensor & Actuator Center 401 490 Cory Hall 402 Berkeley, California 94720 403 USA 405 Email: nicola.accettura@eecs.berkeley.edu