idnits 2.17.1 draft-dujovne-6tisch-on-the-fly-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2014) is 3735 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 278, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 284, but not defined == Missing Reference: 'TASA-PIMRC' is mentioned on line 290, but not defined == Missing Reference: 'DeTAS' is mentioned on line 297, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-00 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: July 28, 2014 Politecnico di Bari 6 MR. Palattella 7 University of Luxembourg 8 N. Accettura 9 Politecnico di Bari 10 January 24, 2014 12 6TiSCH On-the-Fly Scheduling 13 draft-dujovne-6tisch-on-the-fly-01 15 Abstract 17 This document describes the environment, problem statement, and goals 18 of On-The-Fly (OTF) scheduling for the IEEE802.15.4e TSCH MAC 19 protocol in the context of LLNs. The purpose of OTF is to 20 dynamically adapt the number of reserved Softcells between neighbor 21 nodes to satisfy different types of constraints, based on the 22 specific application. The Softcell reservation with OTF is 23 distributed: neighbor nodes negotiate the cell(s) to be (re)allocated 24 /deleted among them, without the intervention of a centralized 25 entity. This document aims to define a module which uses the 26 functionalities provided by the 6top sublayer to extract statistics 27 and to reserve/delete Softcells in the schedule, leaving the 28 reservation/deletion algorithm, and the number and type of statistics 29 to be used in the algorithm itself, open. OTF allows to reserve/ 30 delete either a single Softcell between a couple of nodes, or a 31 Bundle in the TSCH schedule. Also, OTF allows to negotiate the 32 aggregate bandwidth without explicitly dealing with a reservation of 33 a specific subset of Softcells. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on July 28, 2014. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Allocation policy . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Allocation methods . . . . . . . . . . . . . . . . . . . . . 4 71 4. Input parameters: statistics and instant values . . . . . . . 4 72 5. Bundle usage management in OTF: TODO . . . . . . . . . . . . 5 73 5.1. Cell Reservation/Deletion . . . . . . . . . . . . . . . . 5 74 5.2. Bundle Size Increase/Decrease . . . . . . . . . . . . . . 5 75 6. Schedule storage on OTF: TODO . . . . . . . . . . . . . . . . 5 76 7. Scheduling Algorithm container and selection . . . . . . . . 5 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 9.1. Informative References . . . . . . . . . . . . . . . . . 6 80 9.2. External Informative References . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an 86 amendment to the Medium Access Control (MAC) protocol defined by the 87 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel 88 Hopping (TSCH) mode of IEEE802.15.4e is the object of this document. 90 On-The-Fly (OTF) scheduling is a distributed protocol intended to 91 enable a node to define a common schedule with its neighbors without 92 the intervention of a centralized entity. In particular, this 93 document describes the methods, flows and packets involved in this 94 process by using the functionalities offered by the 6top sublayer, as 95 defined in [I-D.wang-6tisch-6top]. In order to be extensible, and 96 thus, applicable in different scenarios, this draft is a general 97 framework. The exact scheduling algorithm and set of statistics is 98 out of scope of this document. This document follows the terminology 99 defined in [I-D.ietf-6tisch-terminology] and the mechanisms described 100 on [I-D.ietf-6tisch-tsch] 102 2. Allocation policy 104 OTF Softcell scheduling is distributed. OTF sends scheduling 105 requests to the 6top module, which allocates the requested Softcells. 106 Softcell scheduling requests to the 6top layer are negotiated on a 107 peer to peer basis without the participation of a PCE. While a 108 distributed mechanism reduces the latency compared to a centralized 109 one, this may generate Softcell allocation collisions between 110 different pairs of neighbor nodes. OTF keeps track of the Softcell 111 and Bundle scheduling. 113 An allocation policy describes which are the rules to follow in order 114 to comply with the requirements of different types of traffic, 115 according to its variability, throughput and latency restrictions. 117 OTF supports 3 types of allocation policies, namely Single, Group and 118 Hybrid allocation policies. 120 Single allocation policy: OTF schedules individual Softcells in 121 response to the current algorithm requests. OTF schedules single 122 Softcells from the scheduling requests to 6top. After the softcells 123 are granted, OTF keeps track of the number of cells allocated for 124 each of the neighbours. If the algorithm decides to free cells to 125 any neighbour, a deallocation request is issued to 6top. When the 126 deallocation is confirmed, OTF updates the internal cell allocation 127 tables. 129 On the Pre-allocation policy, given a decision from the algorithm, 130 OTF requests to 6top the allocation of a block of Softcells, called a 131 Bundle. When the allocation is granted, the algorithm decides which 132 of the allocated cells inside the Bundle is used for communication. 133 The remaining cells inside the Bundle remains allocated but not used. 134 OTF keeps track of the allocated Bundles, and the number of used 135 cells inside the Bundle. Used cells inside a Bundle are consecutive 136 starting from the first cell in the Bundle. When the algorihtm 137 decides to enlarge or reduce the Bundle size, OTF forwards this 138 request to 6top. 140 On the Hybrid allocation policy, when the algorithm issues an 141 allocation request for new cells, OTF must decide between allocating 142 individual softcells, incrementing the number of used cells within a 143 Bundle, or request to 6top to enlarge the Bundle if there were no 144 free cells inside. OTF keeps track of the individual softcells, the 145 allocated Bundles and the number of allocated cells inside the 146 Bundle. 148 3. Allocation methods 150 Unlike the Allocation Policies, an allocation method deals with the 151 specific mechanisms to schedule cells from 6top. Given an Allocation 152 Policy, the algorithm uses one or two methods altogether. OTF uses 153 two allocation methods: Bundle and Softcell. 155 The Bundle allocation method requests to 6top a group of cells called 156 a Bundle. OTF manages internally the allocation of individual cells 157 within the Bundle. The goal of this allocation method is to provide 158 a low-delay response after a surge in bandwidth usage, at the expense 159 of energy consumption: Since Bundles represent a group of pre- 160 scheduled Softcells, they become immediately available. Unlike 161 SoftCell scheduling, which requires a negotiation period between the 162 node's 6top layers, the delay is reduced when a Softcell from a 163 Bundle is used. Nevertheless, the use of Bundles forces the receiver 164 module from the node to be in the Active state during the length of 165 the Bundle, thus increasing power consumption. 167 Once the Bundle is allocated, OTF may ask for sizing/re-sizing BW of 168 a bundle, which implies softcells are reserved. For this purpose, 169 OTF only calculates the required Bandwidth, and 6top maps the BW to 170 the number of soft cells according to some QoS setting, e.g. over- 171 provision ratio, and finally allocates and maintains them. 173 The Softcell allocation method calculates the required Bandwidth and 174 requests individual Softcells to 6top. The 6top layer allocates and 175 maintains the individual softcells. This method reduces energy 176 consumption by allocating only the required bandwidth, to the expense 177 of increasing cell allocation latency: When there is a scheduling 178 request to 6top for a new Softcell, the 6top layer negotiates this 179 request with the 6top layer of the neighbor. This negotiation may 180 take one or more Softcells to complete, thus increasing the overhead. 181 On the other side, when Softcell scheduling is used, the receiver 182 module from the node only stays in the Active node for the scheduled 183 Softcells, thus saving energy. This mechanism assumes that the OTF 184 algorithm schedules Softcells only when they are required. 186 4. Input parameters: statistics and instant values 188 Short summary of a potential set of statistics and instant values 189 that could be used as input parameters. Direct interaction with 190 6top. 192 List of parameters available from 6top: mainly statistics related to 193 queues 195 Method to configure 6top to provide historical values for each 196 requested parameter 198 Method to ask 6top for instant values for each requested parameter 200 Method for asking for a list of parameters from 6top and thus, for 201 checking if a parameter is available or not 203 5. Bundle usage management in OTF: TODO 205 Methods that trigger the request of increasing/decreasing the bundle, 206 and thus, adding/deleting cells 208 5.1. Cell Reservation/Deletion 210 The commands to reserve/delete Softcells. Direct interaction with 211 6top 213 5.2. Bundle Size Increase/Decrease 215 The commands to increase/decrease the Bundle size. Direct 216 interaction with 6top 218 6. Schedule storage on OTF: TODO 220 The description and access to the schedule storage on OTF 222 The commands to retrieve bundle usage values and statistics from OTF 223 (based on previous values obtained by 6top?) 225 7. Scheduling Algorithm container and selection 227 There can be several scheduling algorithms for OTF. The current 228 algorithm can be selected with an external command. The commands 229 allowed are: SET and GET. Scheduling algorithms are numbered from 1 230 to 255. OTF algorithm 0 is reserved for the default scheduling 231 algorithm, defined as follows: 233 Step 1: Obtain the Bandwidth requests from child nodes (incoming 234 traffic) 236 Step 2: Obtain the node Bandwidth requirement from the application 237 (self traffic) 238 Step 3: Obtain the current outgoing scheduled Bandwidth (outgoing 239 traffic) 241 Step 4: If (outgoing < incoming + self) then schedule a number of 242 Soft Cells to satisfy requirements 244 Step 5: If (outgoing > incoming + self) then unschedule the unused 245 Soft Cells 247 Step 6: Loop to Step 1 249 8. Acknowledgements 251 Thanks to the Fondecyt 1121475 Project, to INRIA Chile "Network 252 Design" group and to the IoT6 European Project (STREP) of the 7th 253 Framework Program (Grant 288445). 255 9. References 257 9.1. Informative References 259 [I-D.ietf-6tisch-terminology] 260 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 261 "Terminology in IPv6 over the TSCH mode of IEEE 262 802.15.4e", draft-ietf-6tisch-terminology-00 (work in 263 progress), November 2013. 265 [I-D.wang-6tisch-6top] 266 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 267 Operation Sublayer (6top)", draft-wang-6tisch-6top-00 268 (work in progress), October 2013. 270 [I-D.ietf-6tisch-tsch] 271 Watteyne, T., Palattella, M., and L. Grieco, "Using 272 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 273 Statement and Goals", draft-ietf-6tisch-tsch-00 (work in 274 progress), November 2013. 276 9.2. External Informative References 278 [IEEE802154e] 279 IEEE standard for Information Technology, "IEEE std. 280 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 281 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 282 2012. 284 [IEEE802154] 285 IEEE standard for Information Technology, "IEEE std. 286 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 287 and Physical Layer (PHY) Specifications for Low-Rate 288 Wireless Personal Area Networks", June 2011. 290 [TASA-PIMRC] 291 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 292 and G. Boggia, "Traffic Aware Scheduling Algorithm for 293 Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept. 294 2012, < http://www.cttc.es/resources/doc/ 295 120531-submitted-tasa-25511.pdf>. 297 [DeTAS] Accettura, N., Palattella, , Boggia, G., Grieco, LA., and 298 M. Dohler, "DeTAS: a Decentralized Traffic Aware 299 Scheduling technique enabling IoT-compliant Multi-hop Low- 300 power and Lossy Networks", IEEE WoWMoM on the Internet of 301 Things 2013, June 2013, < http://www.gtti.it/GTTI13/papers 302 /Accettura_et_al_GTTI2013.pdf>. 304 Authors' Addresses 306 Diego Dujovne (editor) 307 Universidad Diego Portales 308 Escuela de Informatica y Telecomunicaciones 309 Av. Ejercito 441 310 Santiago, Region Metropolitana 311 Chile 313 Phone: +56 (2) 676-8121 314 Email: diego.dujovne@mail.udp.cl 316 Luigi Alfredo Grieco 317 Politecnico di Bari 318 Department of Electrical and Information Engineering 319 Via Orabona 4 320 Bari 70125 321 Italy 323 Phone: 00390805963911 324 Email: a.grieco@poliba.it 325 Maria Rita Palattella 326 University of Luxembourg 327 Interdisciplinary Centre for Security, Reliability and Trust 328 4, rue Alphonse Weicker 329 Luxembourg L-2721 330 LUXEMBOURG 332 Phone: (+352) 46 66 44 5841 333 Email: maria-rita.palattella@uni.lu 335 Nicola Accettura 336 Politecnico di Bari 337 Electrical and Electronics Department 338 Via Orabona 4 339 Bari 70125 340 Italy 342 Phone: +39 080 5963301 343 Email: n.accettura@poliba.it