idnits 2.17.1 draft-wang-6tisch-6top-sublayer-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 : ---------------------------------------------------------------------------- ** 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.) ** The abstract seems to contain references ([IEEE802154e]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the TrackID is set to (0,0), the cell can be used by the best-effort QoS configuration or as a Shared cell. If the TrackID is not set to (0,0), i.e. the cell belongs to a specific track, the cell MUST not be set as Shared cell. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The ScheduleIE specifies a candidate cell set, from which the cells SHOULD be reserved. ScheduleIE MAY be empty, means there is no constrain on which cells SHOULD not be reserved. -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 2528, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 2534, but not defined == Unused Reference: 'RFC2119' is defined on line 2487, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 2504, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tsch-security' is defined on line 2515, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-01 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-01 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-00 == Outdated reference: A later version (-02) exists of draft-wang-6tisch-6top-interface-01 Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: August 18, 2014 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 February 14, 2014 10 6TiSCH Operation Sublayer (6top) 11 draft-wang-6tisch-6top-sublayer-00 13 Abstract 15 The recently published [IEEE802154e] standard formalizes the concept 16 of link-layer resources in LLNs. Nodes are synchronized and follow a 17 schedule. A cell in that schedule corresponds to an atomic link- 18 layer resource, and can be allocated to any pair of neighbors in the 19 network. This allows the schedule to be built to tightly match each 20 node's bandwidth, latency and energy constraints. The [IEEE802154e] 21 standard does not, however, present a mechanism to do so, as building 22 and managing the schedule is out of scope of the standard. This 23 document describes the 6TiSCH Operation Sublayer (6top) and the 24 commands it provides to upper network layers such as RPL or GMPLS. 25 The set of functionalities includes feedback metrics from cell states 26 so network layers can take routing decisions, TSCH configuration and 27 control procedures, and the support for decentralized and centralized 28 scheduling. In addition, 6top can be configured to enable packet 29 switching at layer 2.5, analogous to GMPLS. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 18, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. 6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . . 5 67 2.1. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1.1. hard cells . . . . . . . . . . . . . . . . . . . . . 7 69 2.1.2. soft cells . . . . . . . . . . . . . . . . . . . . . 8 70 2.2. Data Transfer Model . . . . . . . . . . . . . . . . . . . 8 71 3. 6top Commands . . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.1. Cell Commands . . . . . . . . . . . . . . . . . . . . . . 13 73 3.1.1. CREATE.hardcell . . . . . . . . . . . . . . . . . . . 13 74 3.1.2. CREATE.softcell . . . . . . . . . . . . . . . . . . . 15 75 3.1.3. READ.cell . . . . . . . . . . . . . . . . . . . . . . 16 76 3.1.4. UPDATE.cell . . . . . . . . . . . . . . . . . . . . . 17 77 3.1.5. DELETE.hardcell . . . . . . . . . . . . . . . . . . . 17 78 3.1.6. DELETE.softcell . . . . . . . . . . . . . . . . . . . 18 79 3.1.7. REALLOCATE.softcell . . . . . . . . . . . . . . . . . 19 80 3.2. Slotframe Commands . . . . . . . . . . . . . . . . . . . 19 81 3.2.1. CREATE.slotframe . . . . . . . . . . . . . . . . . . 19 82 3.2.2. READ.slotframe . . . . . . . . . . . . . . . . . . . 20 83 3.2.3. UPDATE.slotframe . . . . . . . . . . . . . . . . . . 20 84 3.2.4. DELETE.slotframe . . . . . . . . . . . . . . . . . . 21 85 3.3. Monitoring Commands . . . . . . . . . . . . . . . . . . . 22 86 3.3.1. CONFIGURE.monitoring . . . . . . . . . . . . . . . . 22 87 3.3.2. READ.monitoring.status . . . . . . . . . . . . . . . 22 88 3.4. Statistics Commands . . . . . . . . . . . . . . . . . . . 23 89 3.4.1. CONFIGURE.statistics . . . . . . . . . . . . . . . . 23 90 3.4.2. READ.statistics . . . . . . . . . . . . . . . . . . . 23 91 3.4.3. RESET.statistics . . . . . . . . . . . . . . . . . . 24 92 3.5. Network Formation Commands . . . . . . . . . . . . . . . 24 93 3.5.1. CONFIGURE.eb . . . . . . . . . . . . . . . . . . . . 25 94 3.5.2. READ.eb . . . . . . . . . . . . . . . . . . . . . . . 25 95 3.6. Time Source Neighbor Commands . . . . . . . . . . . . . . 26 96 3.6.1. CONFIGURE.timesource . . . . . . . . . . . . . . . . 26 97 3.6.2. READ.timesource . . . . . . . . . . . . . . . . . . . 26 98 3.7. Neighbor Commands . . . . . . . . . . . . . . . . . . . . 26 99 3.7.1. CREATE.neighbor . . . . . . . . . . . . . . . . . . . 27 100 3.7.2. READ.all.neighbor . . . . . . . . . . . . . . . . . . 27 101 3.7.3. READ.neighbor . . . . . . . . . . . . . . . . . . . . 27 102 3.7.4. UPDATE.neighbor . . . . . . . . . . . . . . . . . . . 27 103 3.7.5. DELETE.neighbor . . . . . . . . . . . . . . . . . . . 28 104 3.8. Queueing Commands . . . . . . . . . . . . . . . . . . . . 28 105 3.8.1. CREATE.queue . . . . . . . . . . . . . . . . . . . . 28 106 3.8.2. READ.queue . . . . . . . . . . . . . . . . . . . . . 28 107 3.8.3. READ.queue.stats . . . . . . . . . . . . . . . . . . 29 108 3.8.4. UPDATE.queue . . . . . . . . . . . . . . . . . . . . 29 109 3.8.5. DELETE.queue . . . . . . . . . . . . . . . . . . . . 30 110 3.9. Label Switching Commands . . . . . . . . . . . . . . . . 30 111 3.9.1. LabelSwitching.map . . . . . . . . . . . . . . . . . 30 112 3.9.2. LabelSwitching.unmap . . . . . . . . . . . . . . . . 30 113 3.10. Chunk Command . . . . . . . . . . . . . . . . . . . . . . 31 114 3.10.1. Create.chunk . . . . . . . . . . . . . . . . . . . . 31 115 3.10.2. READ.chunk . . . . . . . . . . . . . . . . . . . . . 31 116 3.10.3. Delete.chunk . . . . . . . . . . . . . . . . . . . . 32 117 3.11. Chunk Cell Command . . . . . . . . . . . . . . . . . . . 32 118 3.11.1. CREATE.hardcell.fromchunk . . . . . . . . . . . . . 32 119 3.11.2. READ.chunkcell . . . . . . . . . . . . . . . . . . . 33 120 3.11.3. DELETE.hardcell.fromchunk . . . . . . . . . . . . . 33 121 3.12. Data Commands . . . . . . . . . . . . . . . . . . . . . . 34 122 3.12.1. Send.data . . . . . . . . . . . . . . . . . . . . . 34 123 3.12.2. Receive.data . . . . . . . . . . . . . . . . . . . . 34 124 4. 6top Communication Protocol . . . . . . . . . . . . . . . . . 35 125 4.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 35 126 4.1.1. Information Elements . . . . . . . . . . . . . . . . 35 127 4.1.2. Packet Formats . . . . . . . . . . . . . . . . . . . 43 128 4.2. Time Sequences . . . . . . . . . . . . . . . . . . . . . 48 129 4.2.1. Network Formation . . . . . . . . . . . . . . . . . . 49 130 4.2.2. Creating soft cells . . . . . . . . . . . . . . . . . 50 131 4.2.3. Deleting soft cells . . . . . . . . . . . . . . . . . 51 132 4.2.4. Maintaining soft cells . . . . . . . . . . . . . . . 51 133 4.2.5. Creating hard cells . . . . . . . . . . . . . . . . . 51 134 4.2.6. Deleting hard cells . . . . . . . . . . . . . . . . . 52 135 5. Statistics . . . . . . . . . . . . . . . . . . . . . . . . . 52 136 5.1. Statistics Metrics . . . . . . . . . . . . . . . . . . . 52 137 5.2. Statistics Configuration . . . . . . . . . . . . . . . . 53 138 6. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 53 139 6.1. Monitor Configuration . . . . . . . . . . . . . . . . . . 53 140 6.2. Actuation . . . . . . . . . . . . . . . . . . . . . . . . 54 141 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 142 7.1. Normative References . . . . . . . . . . . . . . . . . . 54 143 7.2. Informative References . . . . . . . . . . . . . . . . . 54 144 7.3. External Informative References . . . . . . . . . . . . . 55 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 147 1. Introduction 149 As presented in [I-D.ietf-6tisch-tsch], the [IEEE802154e] standard 150 defines the mechanisms for a TSCH node to communicate, given a 151 schedule. It does not, however, define the mechanism to build and 152 maintain the TSCH schedule, match that schedule to the multi-hop 153 paths maintained by a network layer such as RPL or a 2.5 layer such 154 as GMPLS, adapt the resources allocated between neighbor nodes to the 155 data traffic flows, enforce a differentiated treatment for data 156 generated at the application layer and signalling messages needed by 157 6LoWPAN and RPL to discover neighbors, react to topology changes, 158 self-configure IP addresses, or manage keying material. 160 In a TSCH network, the MAC layer is not in charge of setting up the 161 schedule that controls the connectivity graph of the network and the 162 resources allocated to each cell in that topology. This 163 responsibility is left to the next-higher layer, defined in this 164 document, called "6top". 166 This document describes the 6TiSCH Operation Sublayer (6top) and the 167 main commands provided to upper network layers such as RPL or GMPLS. 168 The set of functionalities include feedback metrics from cell state 169 so the network layer can take routing decisions, TSCH configuration 170 and control procedures, and support for the different scheduling 171 mechanisms defined in [I-D.ietf-6tisch-architecture]. 6top addresses 172 the set of functionalities described in [I-D.ietf-6tisch-tsch]. 174 For example, network formation in a TSCH network involves the 175 transmission of Enhanced Beacons (EB). EBs include information for 176 joining nodes to be able to synchronize and set up an initial network 177 topology. However, [IEEE802154e] does not specify how the period of 178 EBs is configured, nor the rules for a node to select a particular 179 node to join. 6top offers a set of commands so control mechanisms can 180 be introduced on top of TSCH to configure nodes to join a specific 181 node. Once a network is formed, 6top maintains the network's health, 182 allowing for nodes to stay synchronized. It supplies mechanisms to 183 manage each node's time source neighbor and configure the EB 184 interval. Network layers running on top of 6top take advantage of 185 the TSCH MAC layer information so routing metrics, topological 186 information, energy consumption and latency requirements can be 187 adjusted to TSCH, and adapted to application requirements. 189 TSCH requires a mechanism to manage its schedule; 6top provides a set 190 of commands for upper layers to set up specific schedules, either 191 explicitly by detailing specific cell information, or by allowing 192 6top to establish a schedule given a bandwidth or latency 193 requirement. 6top is designed to enable decentralized, centralized or 194 hybrid scheduling solutions. 6top enables internal TSCH queuing 195 configuration, size of buffers, packet priorities, transmission 196 failure behavior, and defines mechanisms to encrypt and authenticate 197 MAC slotframes. 199 As described in [label-switching-154e], due to the slotted nature of 200 a TSCH network, it is possible to use a label switched architecture 201 on top of TSCH cells. As a cell belongs to a specific track, a label 202 header is not needed at each packet; the input cell (or bundle) and 203 the output cell (or bundle) uniquely identify the data flow. The 204 6top sublayer provides operations to manage the cell mappings. 206 2. 6TiSCH Operation Sublayer (6top) Overview 208 6top is a sublayer which is the next-higher layer for TSCH 209 (Figure 1), which architecture is detailed in 210 [I-D.ietf-6tisch-architecture], and generaic data model is detailed 211 in [I-D.wang-6tisch-6top-interface]. 6top offers both management and 212 data interfaces to an upper layer. It includes monitoring and 213 statistics collection, both of which are configurable through the 214 management interface. 216 Protocol Stack 218 +-----------------------------------+ 219 | PCEP | CoAP | | 6LoWPAN | | 220 | PCC | DTLS | PANA | ND |RPL | 221 +------------------------------------------+ 222 | TCP | UDP | ICMP | RSVP | 223 +------------------------------------------+ 224 | IPv6 | 225 +------------------------------------------+ 226 | 6LoWPAN HC | 227 +------------------------------------------+ 228 | 6top | 229 +------------------------------------------+ 230 | IEEE802.15.4e TSCH | 231 +------------------------------------------+ 232 | IEEE802.15.4 | 233 +------------------------------------------+ 235 Figure 1 237 6top distinguishes between hard cells and soft cells. It therefore 238 requires an extra flag to all cells in the TSCH schedule, as detailed 239 in Section 2.1. 241 When a higher layer gives 6top a 6LoWPAN packet for transmission, 242 6top maps it to the appropriate outgoing priority-based queue, as 243 detailed in Section 2.2. 245 All 6top commands of the management and data interfaces are detailed 246 in Section 3. This set of commands is designed to support 247 decentralized, centralized and hybrid scheduling solutions. They 248 form a conceptual interface an upper layer can used; implementations 249 can use this set of commands, or any equivalent alternative. 251 6top defines TSCH Information Elements (IEs) for neighbors nodes to 252 negotiate scheduling cells in the TSCH schedule. The format of those 253 IEs is given in Section 4.1. Example data exchanges between neighbor 254 nodes are given in Section 4.2. 256 Section 5 defines how 6top gathers statistics (e.g. link quality, 257 energy level, queue usage), and what commands an upper layer can use 258 to configure and retrieve those statistics. 260 6top can be configured to monitor the cells it has scheduled in order 261 to detect cells with poor performance. It can automatically re- 262 allocate those cells inside the TSCH schedule. This behavior is 263 described in Section 6 265 2.1. Cell Model 267 [IEEE802154e] defines a set of options attached to each cell. A cell 268 can be a Transmit cell, a Receive cell, a Shared cell or a 269 Timekeeping cell. These options are not exclusive, as a cell can be 270 qualified with more than one of them. The MLME-SET-LINK.request 271 command defined in [IEEE802154e] uses a linkOptions bitmap to specify 272 the options of a cell. Acceptable values are: 274 b0 = Transmit 276 b1 = Receive 278 b2 = Shared 280 b3 = Timekeeping 282 b4-b7 = Reserved 284 Only Transmit cells can also be marked as Shared cells. When the 285 shared bit is set, a back-off procedure is applied to handle 286 collisions. Shared behavior does not apply to Receive cells. 288 6top allows an upper layer to schedule a cell at a specific 289 slotOffset and channelOffset, in a specific slotframe. 291 In addition, 6top allows an upper layer to schedule a certain amount 292 of bandwidth to a neighbor, without having to specify the exact 293 slotOffset and channelOffset of the corresponding cell(s). Once 294 bandwidth is reserved, 6top is in charge of ensuring that this 295 requirement is continuously satisfied. 6top dynamically reallocates 296 cells if needed, and over-provisions if required. 298 6top allows an upper layer to associate a cell with a specific track 299 by using a TrackID. A TrackID is a tuple 300 (TrackOwnerAddr,InstanceID). TrackOwnerAddr is the address of the 301 node which initiates the process of creating the track, i.e. the 302 owner of the track. InstanceID is an instance identifier given by 303 the owner of the track. InstanceID comes from the upper layer; it 304 could for example be the local instance ID defined in RPL. 306 If the TrackID is set to (0,0), the cell can be used by the best- 307 effort QoS configuration or as a Shared cell. If the TrackID is not 308 set to (0,0), i.e. the cell belongs to a specific track, the cell 309 MUST not be set as Shared cell. 311 6top allows an upper layer to ask a node to manage a portion of a 312 slotframe, called a chunk. Chunks can be delegated explicitly by the 313 PCE to a node, or claimed automatically by any node that participates 314 to the distributed cell scheduling process. The cells in a chunk can 315 be appropriated by the node, i.e. the node is in charge of managing 316 the chunk. 318 Given this mechanism, 6top defines hard cells (which have been 319 requested specifically) and soft cells (which can be reallocated 320 dynamically). The hard/soft flag is introduced by the 6top sublayer 321 named as CellType (0: soft cell, 1: hard cell). This option is 322 mandatory; all cells are either hard or soft. 324 2.1.1. hard cells 326 A hard cell is a cell that cannot be dynamically reallocated by 6top. 327 A hard cell is uniquely identified by the following tuple: 329 slotframe ID: ID of the slotframe this cell is part of. 331 slotOffset: the slotOffset for the cell. 333 channelOffset: the channelOffset for the cell. 335 LinkOption bitmap: bitmap as defined in [IEEE802154]. 337 CellType: MUST be set to 1. 339 2.1.2. soft cells 341 A soft cell is a cell that can be reallocated by 6top dynamically. 342 The CellType MUST be set to 0. This cell is installed by 6top given 343 a specific bandwidth requirement. Soft cells are installed through 344 the soft cell negotiation procedure described in Section 4.2. 346 2.2. Data Transfer Model 348 The TSCH MAC layer is decoupled from the upper layer; the interaction 349 between the upper layer and TSCH is asynchronous. This means that 350 the MAC layer executes a schedule and checks at each timeslot 351 according to the type of cell, whether there is something to send or 352 receive. If that is the case, the packet is transmitted and the MAC 353 layer continues its operation. When an upper layer sends a packet, 354 this packet is pushed into a queue waiting for the MAC layer to read 355 it and send it in a particular timeslot according to its destination 356 and priority. 6top provides a set of queue management operations 357 which enable upper layers to create different queues and set their 358 priorities. This allows different classes of traffic to be handled 359 by the forwarding plane by inserting a packet into the queue 360 appropriate for its priority. 362 A 6top implementation MUST provide at least a Broadcast Queue and a 363 Transmit Queue. The Broadcast Queue is associated with cells with 364 LinkType=ADVERTISING in the sender's schedule, and 365 LinkOption="Receive" and "Timekeeping" in all its neighbors' 366 schedule. For example, NodeA uses slotOffset=5 and channelOffset=12 367 as Broadcast cell to its neighbors NodeB and NodeC. Then, in the 368 schedule of NodeA the cell will be featured with neighbor address is 369 Broadcast address, LinkType=ADVERTISING; and in the schedules of both 370 nodeB and nodeC the cell will be featured with nodeA address as 371 neighbor address, and LinkOption="Receive" and "Timekeeping", which 372 ensure nodeB and nodeC will be active at least one time in the cell 373 to receive broadcast packet during a Timekeeping period. A Transmit 374 Queue is associated with the dedicated Transmit cells or Shared 375 Cells. 377 Data Communication Commands (Section 3.12) can be used to send 378 control messages and data messages. The operation is used to insert 379 a message into a specific queue. 381 For example, a configuration can include two Broadcast Queues with 382 priority High and Low, and three Transmit Queues with priority High, 383 Mid, and Low. 385 When DestAddr is the broadcast address, its related MAC layer packets 386 will be pushed into the Broadcast Queue with the corresponding 387 priority. 6top is responsible for feeding these packets into 388 broadcast cells. 390 When DestAddr is a unicast address, its related MAC layer packets 391 will be pushed into the Transmit Queue with the corresponding 392 priority. 6top is responsible for feeding these packets into Transmit 393 or Shared Cells. 395 The QoS policy enforced by 6top is out of scope. As an example, 396 packets in higher priority queues could be transmitted before the 397 packets in lower priority queue. As a result, when there is an 398 available broadcast/unicast cell, 6top checks the broadcast/unicast 399 queue with higher priority first. 6top continues this search until it 400 finds a broadcast/unicast packet, or finds that all of broadcast/ 401 unicast queues are empty. 403 Figure Figure 2 shows how 6top shapes data from the upper layer 404 (e.g., RPL, 6LoWPAN), and feeds it to TSCH. The properties 405 associated with a packet/fragment from the upper layer includes the 406 next hop neighbor (DestAddr), the packet priority, and TrackID(s). 408 6top Data Transfer Model 410 | 411 | (DestAddr, Priority, Fragment) 412 | 413 +---------------------------------------+ 414 | I-MUX | 415 +---------------------------------------+ 416 | | | | | 417 | | | | | 418 +---+ +---+ +---+ +---+ +---+ 419 | | | | | | | | | | 420 |Q1 | |Q2 | |Q3 | |Q4 | ... |Qn | 421 | | | | | | | | | | 422 +---+ +---+ +---+ +---+ +---+ 423 | | | | | 424 | | | | | 425 +---------------------------------------+ 426 | MUX | 427 +---------------------------------------+ 428 | 429 | 430 +---+ 431 |PDU| 432 +---+ 433 | 434 | TSCH MAC-payload 435 | 437 Figure 2 439 In Figure 2, Qi represents a queue, which is either broadcast or 440 unicast, and is assigned a priority. The number of queues is 441 configurable. The relationship between queues and tracks is 442 configurable. For example, for a given queue, only one specific 443 track can be used, all of the tracks can be used, or a subset of the 444 tracks can be used. 446 When 6top receives a packet to transmit through a Send.data command 447 (Section 3.12), the I-MUX module selects a queue in which to insert 448 it. If the packet's destination address is a unicast (resp. 449 broadcast) address, it is inserted into a unicast (resp. broadcast) 450 queue. 452 The MUX module is invoked at each scheduled transmit cell by TSCH. 453 When invoked, the MUX module goes through the queues, looking for the 454 best matching frame to send. If it finds a frame, it hands it over 455 to TSCH for transmission. If the next active cell is a broadcast 456 cell, it selects a fragment only from broadcast queues. 458 How the MUX module selects the best frame is configurable. The 459 following rules are a typical example: 461 The frame's layer 2 destination address MUST match the neighbor 462 address associated with the transmit cell. 464 If the transmit cell is associated with a specific track, the 465 frames in the queue corresponding to the TrackID have the 466 highest priority. 468 If the transmit cell is not associated with a specific track, 469 i.e., TrackID=(0,0), frames from a queue with a higher priority 470 MUST be sent before frames from a queue with a lower priority. 472 Further rules can be configured to satisfy specific QoS requirements. 474 3. 6top Commands 476 6top provides a set of commands as the interface with the higher 477 layer. Most of these commands are related to the configuration of 478 slotframes, cells and scheduling information. 6top also provides an 479 interface allowing an upper layer to retrieve status information and 480 statistics. The management commands provided by 6top are listed 481 below. Note that this set defines a conceptual interface only; an 482 implementation can choose to use this exact set of commands, or any 483 equivalent alternative. 485 CREATE.hardcell: Section 3.1.1 487 CREATE.softcell: Section 3.1.2 489 READ.cell: Section 3.1.3 491 UPDATE.cell: Section 3.1.4 493 DELETE.hardcell: Section 3.1.5 495 DELETE.softcell: Section 3.1.6 497 REALLOCATE.softcell: Section 3.1.7 499 CREATE.slotframe: Section 3.2.1 501 READ.slotframe: Section 3.2.2 502 UPDATE.slotframe: Section 3.2.3 504 DELETE.slotframe: Section 3.2.4 506 CONFIGURE.monitoring: Section 3.3.1 508 READ.monitoring: Section 3.3.2 510 CONFIGURE.statistics: Section 3.4.1 512 READ.statistics: Section 3.4.2 514 RESET.statistics: Section 3.4.3 516 CONFIGURE.eb: Section 3.5.1 518 READ.eb: Section 3.5.2 520 CONFIGURE.timesource: Section 3.6.1 522 READ.timesource: Section 3.6.2 524 CREATE.neighbor: Section 3.7.1 526 READ.all.neighbor: Section 3.7.2 528 READ.neighbor: Section 3.7.3 530 UPDATE.neighbor: Section 3.7.4 532 DELETE.neighbor: Section 3.7.5 534 CREATE.queue: Section 3.8.1 536 READ.queue: Section 3.8.2 538 READ.queue.stats: Section 3.8.3 540 UPDATE.queue: Section 3.8.4 542 DELETE.queue: Section 3.8.5 544 LabelSwitching.map: Section 3.9.1 546 LabelSwitching.unmap: Section 3.9.2 548 CREATE.chunk: Section 3.10.1 549 READ.chunk: Section 3.10.2 551 DELETE.chunk: Section 3.10.3 553 CREATE.hardcell.fromchunk: Section 3.11.1 555 READ.chunkcell: Section 3.11.2 557 DELETE.hardcell.fromchunk: Section 3.11.3 559 Besides management commands, 6top provides the following data 560 commands: 562 Send.data: Section 3.12.1 564 Receive.data: Section 3.12.2 566 In addition, 6top offers a delegation interface allowing an upper 567 layer to configure TSCH. 6top only delegates the functionalities to 568 the MAC security services. In other words, 6top allows an upper 569 layer to access the security PIB (Table 60, Table 61, Table 63 in 570 [IEEE802154]) by using MLME-GET/MLME-SET primitives defined in 571 [IEEE802154]. 573 3.1. Cell Commands 575 6top provides the following commands to manage TSCH cells. 577 3.1.1. CREATE.hardcell 579 Creates one or more hard cells in the schedule. Fails if the cell 580 already exists. A cell is uniquely identified by the tuple 581 (slotframe ID, slotOffset, channelOffset). 583 To create a hard cell, the upper layer specifies: 585 slotframe ID: ID of the slotframe this timeslot will be 586 scheduled in. 588 slotOffset: the slotOffset for the cell. 590 channelOffset: channelOffset for the cell. 592 LinkOption bitmap: bitmap as defined in [IEEE802154e] 594 LinkType : as defined in section 6.2.19.3 of [IEEE802154e]. 596 CellType: as defined in Section 2.1 597 target node address: the address of that node to communicate 598 with over this cell. In case of broadcast cells this is the 599 broadcast address. 601 TrackID: ID of the track the cell will belong to. 603 6top schedules the cell and marks it as a hard cell, indicating that 604 it cannot reschedule this cell. The return value is CellID and the 605 created cell is also filled in CellList 606 ([I-D.wang-6tisch-6top-interface]). 608 The interaction between 6top and MAC layer caused by CREATE.hardcell 609 is as follows. 611 Firstly, 6top calls the premitive MLME-SET-LINK.request defind in 612 section 6.2.19.3 of [IEEE802154e]. The premitive parameters are set 613 as follows. 615 +---------------------------------+---------------------------------+ 616 | MLME-SET-LINK.request parameter | set by 6top | 617 +---------------------------------+---------------------------------+ 618 | operation | ADD-LINK | 619 +---------------------------------+---------------------------------+ 620 | LinkHandle | CellID | 621 +---------------------------------+---------------------------------+ 622 | slotframeHandle | slotframe ID | 623 +---------------------------------+---------------------------------+ 624 | timeslot | slotOffset | 625 +---------------------------------+---------------------------------+ 626 | channelOffset | channelOffset | 627 +---------------------------------+---------------------------------+ 628 | LinkOptions | LinkOption bitmap | 629 +---------------------------------+---------------------------------+ 630 | LinkType | LinkType | 631 +---------------------------------+---------------------------------+ 632 | nodeAddr | target node address | 633 +---------------------------------+---------------------------------+ 635 Secondly, if the status from MLME-SET-LINK.confirm defined in section 636 6.2.19.4 of [IEEE802154e] is SUCCESS, then add the LinkHandle to the 637 BundleList specified by TrackID, and confirm to upper layer with 638 status = SUCCESS; otherwise, confirm to upper layer with status = 639 FAIL. 641 3.1.2. CREATE.softcell 643 To create soft cell(s), the upper layer specifies: 645 slotframe ID: ID of the slotframe the cell(s) will be scheduled 646 in 648 number of cells: the required number of soft cells. 650 LinkOption bitmap: bitmap as defined in [IEEE802154e] 652 CellType: as defined in Section 2.1 654 target node address: the address of the node to communicate 655 with over the cell(s). In case of broadcast cells this is the 656 broadcast address. 658 TrackID: ID of the track the cell(s) will belong to. 660 QoS level: the cell redundancy policy. The policy can be for 661 example STRICT, BEST_EFFORT, etc. 663 6top is responsible for picking the exact slotOffset and 664 channelOffset in the schedule, and ensure that the target node choose 665 the same cell and TrackID. 6top marks these cells as soft cell, 666 indicating that it will continuously monitor their performance and 667 reschedule if needed. The return value is CellID, and the created 668 cell is also filled in CellList ([I-D.wang-6tisch-6top-interface]). 670 6top deals with the allocation process by negotiation with the target 671 node. The command returns the list of created cells defined by 672 (slotframe ID, slotOffset, channelOffset). It fails if the required 673 number of cells is higher than the available number of cells in the 674 schedule. It fails if the negotiation with the target node fails. 675 It fails if the LinkOption bitmap indicates that the cell(s) MUST be 676 Hard. 678 The interaction between 6top and TSCH happens on both sides described 679 as follows. 681 For example, after neigotiation, node A and node B find a specifical 682 cell, slotOffset=10, channelOffset=12, as a Tx cell and Rx cell, 683 respectively, then the 6top in node A and node B will call the 684 premitive MLME-SET-LINK.request defind in section 6.2.19.3 of 685 [IEEE802154e], respectively. The premitive parameters are set in 686 node A and node B as follows. 688 +---------------------------------+---------------------------------+ 689 | MLME-SET-LINK.request parameter | set by A's 6top | set by B's top| 690 +---------------------------------+---------------------------------+ 691 | operation | ADD-LINK | ADD-LINK | 692 +---------------------------------+---------------------------------+ 693 | LinkHandle | CellID | CellID | 694 +---------------------------------+---------------------------------+ 695 | slotframeHandle | slotframe ID | slotframe ID | 696 +---------------------------------+---------------------------------+ 697 | timeslot | 10 | 10 | 698 +---------------------------------+---------------------------------+ 699 | channelOffset | 12 | 12 | 700 +---------------------------------+---------------------------------+ 701 | LinkOptions | Tx | Rx | 702 +---------------------------------+---------------------------------+ 703 | LinkType | NORMAL | NORMAL | 704 +---------------------------------+---------------------------------+ 705 | nodeAddr | Node A | Node B | 706 +---------------------------------+---------------------------------+ 708 If the Status from MLME-SET-LINK.confirm defined in section 6.2.19.4 709 of [IEEE802154e], 6top will notify upper layer failure. 711 3.1.3. READ.cell 713 Given a (slotframe ID, slotOffset, channelOffset), retrieves the cell 714 information. Fails if the cell does not exist. The returned 715 information contains: 717 slotframe ID: ID of the slotframe where this cell is installed. 719 slotOffset: the slotOffset for the cell. 721 channelOffset: the selected channelOffset for the cell. 723 LinkOption bitmap: bitmap as defined in [IEEE802154e] 725 CellType: as defined in Section 2.1 727 target node address: the target address of that cell. In case 728 of broadcast cells this is the broadcast address. 730 TrackID: ID of the track the cell will belong to. 732 NumOfStatistics: Number of elements in the following list of 733 tuple (StatisticsMetriceID and StatisticsValue) 734 list of (StatisticsMetriceID, StatisticsValue): 735 StatisticsMetriceID is the index to Statistics Metric defined 736 in Section 3.4, StatisticsValue is the value corresponding to 737 the metric indexd by StatisticsMetriceID 739 A read command can be issued for any cell, hard or soft. 6top gets 740 cell information from CellList ([I-D.wang-6tisch-6top-interface]). 742 3.1.4. UPDATE.cell 744 Update a hard cell, i.e., re-allocate it to a different slotOffset 745 and/or channelOffset. Fails if the cell does not exist. Requires 746 both old (slotframe ID, slotOffset, channelOffset) and new (slotframe 747 ID, slotOffset, channelOffset) as parameters. And, the type of cell, 748 target node address and TrackID are the fields that cannot be 749 updated. Soft cells MUST NOT be updated by the UPDATE.cell command. 750 REALLOCATE.softcell (Section 3.1.7) MUST be used instead. 752 It causes a old cell being removed and a new cell being created. 754 3.1.5. DELETE.hardcell 756 To remove a hard cell, the upper layer specifies: 758 slotframe ID: the ID of the slotframe where this cell is 759 installed. 761 slotOffset: the slotOffset for the cell. 763 channelOffset: the selected channelOffset for the cell. 765 LinkOption bitmap: bitmap as defined in [IEEE802154e] 767 LinkType : as defined in in section 6.2.19.3 of [IEEE802154e]. 769 CellType: as defined in Section 2.1 771 target node address: the target address of that cell. In case 772 of broadcast cells this is the broadcast address. 774 TrackID: ID of the track the cell will belong to. 776 This removes the hard cell from the node's schedule, from CellList 777 ([I-D.wang-6tisch-6top-interface])as well. 779 The interaction between 6top and MAC layer caused by DELETE.hardcell 780 is as follows. 782 Firstly, 6top calls the premitive MLME-SET-LINK.request defind in 783 section 6.2.19.3 of [IEEE802154e]. The premitive parameters are set 784 as follows. 786 +---------------------------------+---------------------------------+ 787 | MLME-SET-LINK.request parameter | set by 6top | 788 +---------------------------------+---------------------------------+ 789 | operation | DELETE-LINK | 790 +---------------------------------+---------------------------------+ 791 | LinkHandle | CellID | 792 +---------------------------------+---------------------------------+ 793 | slotframeHandle | slotframe ID | 794 +---------------------------------+---------------------------------+ 795 | timeslot | slotOffset | 796 +---------------------------------+---------------------------------+ 797 | channelOffset | channelOffset | 798 +---------------------------------+---------------------------------+ 799 | LinkOptions | LinkOption bitmap | 800 +---------------------------------+---------------------------------+ 801 | LinkType | LinkType | 802 +---------------------------------+---------------------------------+ 803 | nodeAddr | target node address | 804 +---------------------------------+---------------------------------+ 806 Secondly, if the status from MLME-SET-LINK.confirm defined in section 807 6.2.19.4 of [IEEE802154e] is SUCCESS, then remove the LinkHandle from 808 its BundleList specified by TrackID, and confirm to upper layer with 809 status = SUCCESS; otherwise, confirm to upper layer with status = 810 FAIL. 812 3.1.6. DELETE.softcell 814 To remove a (number of) soft cell(s), the upper layer specifies: 816 slotframe ID: ID of the slotframe where this cell is installed. 818 number of cells: the number of cells to be removed 820 LinkOption bitmap: bitmap as defined in [IEEE802154e] 822 CellType: as defined in Section 2.1 824 target node address: the target address of that cell. In case 825 of broadcast cells this is the broadcast address. 827 TrackID: ID of the track the cell will belong to. 829 In the case a soft cell wants to be re-allocated from the allocated 830 cell so a hard cell can be installed instead, the REALLOCATE.softcell 831 (Section 3.1.7) MUST be used. 833 After the pair of nodes figure out the specific cell(s) to be 834 removed, the interaction between 6top and TSCH on both sides will be 835 similar to that caused by DELETE.hardcell, except LinkType should be 836 set to NORMAL. 838 3.1.7. REALLOCATE.softcell 840 To force a re-allocation of a soft cell, the upper layer specifies: 842 slotframe ID: ID of the slotframe where the cell is allocated. 844 slotOffset: the slotOffset for that cell. 846 channelOffset: the channelOffset for that cell. 848 The reallocated cell will be installed in a different slotOffset, 849 channelOffset but slotframe and TrackID remain the same. Hard cells 850 MUST NOT be reallocated. 852 The interaction between 6top and TSCH caused by this command includes 853 that described in Section 3.1.6 and Section 3.1.2. 855 3.2. Slotframe Commands 857 6top provides the following commands to manage TSCH slotframes. 859 3.2.1. CREATE.slotframe 861 Creates a new slotframe. The command requires: 863 slotframe ID: unique identifier of the slotframe, corresponding 864 to its priority. 866 number of timeslots: the required number of timeslots in the 867 slotframe. 869 Fails if the number of required timeslots is less than zero. 871 The interaction between 6top and MAC layer caused by CREATE.slotframe 872 is as follows. 874 Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind 875 in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are 876 set as follows. 878 +---------------------------------+---------------------------------+ 879 | MLME-SET-SLOTFRAME.request | | 880 | parameter | set by 6top | 881 +---------------------------------+---------------------------------+ 882 | slotframeHandle | slotframe ID | 883 +---------------------------------+---------------------------------+ 884 | operation | ADD | 885 +---------------------------------+---------------------------------+ 886 | size | number of timeslot | 887 +---------------------------------+---------------------------------+ 889 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 890 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 891 layer with status = SUCCESS; otherwise, confirm to upper layer with 892 status = FAIL. 894 3.2.2. READ.slotframe 896 Returns the information of a slotframe given its slotframe ID. The 897 command returns: 899 slotframe ID: ID of the slotframe. (SlotFrameHandle) 901 number of timeslots: the number of timeslots in the slotframe. 903 Fails if the slotframe ID does not exist. 905 3.2.3. UPDATE.slotframe 907 Change the number of timeslots in a slotframe. The command requires: 909 slotframe ID: ID of the slotframe. 911 number of timeslots: the number of timeslots to be updated. 913 Fails if the number of required timeslots is less than zero. Fails 914 if the slotframe ID does not exist. 916 The interaction between 6top and MAC layer caused by UPDATE.slotframe 917 is as follows. 919 Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind 920 in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are 921 set as follows. 923 +---------------------------------+---------------------------------+ 924 | MLME-SET-SLOTFRAME.request | | 925 | parameter | set by 6top | 926 +---------------------------------+---------------------------------+ 927 | slotframeHandle | slotframe ID | 928 +---------------------------------+---------------------------------+ 929 | operation | MODIFY | 930 +---------------------------------+---------------------------------+ 931 | size | number of timeslot | 932 +---------------------------------+---------------------------------+ 934 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 935 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 936 layer with status = SUCCESS; otherwise, confirm to upper layer with 937 status = FAIL. 939 3.2.4. DELETE.slotframe 941 Deletes a slotframe. The command requires: 943 slotframe ID: ID of the slotframe. 945 number of timeslot: the number of timeslots in the slotframe. 947 Fails if the slotframe ID does not exist. 949 The interaction between 6top and MAC layer caused by DELETE.slotframe 950 is as follows. 952 Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind 953 in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are 954 set as follows. 956 +---------------------------------+---------------------------------+ 957 | MLME-SET-SLOTFRAME.request | | 958 | parameter | set by 6top | 959 +---------------------------------+---------------------------------+ 960 | slotframeHandle | slotframe ID | 961 +---------------------------------+---------------------------------+ 962 | operation | DELETE | 963 +---------------------------------+---------------------------------+ 964 | size | number of timeslot | 965 +---------------------------------+---------------------------------+ 967 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 968 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 969 layer with status = SUCCESS; otherwise, confirm to upper layer with 970 status = FAIL. 972 3.3. Monitoring Commands 974 Monitoring commands provide the means for upper layers to configure 975 whether 6top must ensure the required bandwidth. This procedure is 976 achieved through overprovisioning according to cell status feedback. 977 Monitoring is also in charge of reallocating soft cells that are 978 under the required QoS. 980 3.3.1. CONFIGURE.monitoring 982 Configures the level of QoS the Monitoring process MUST enforce. The 983 command requires: 985 slotframe ID: ID of the slotframe. 987 target node address: the target neighbor address. 989 enforce policy: The policy used to enforce the QoS 990 requirements. Can be for example DISABLE, BEST_EFFORT, STRICT, 991 OVER-PROVISION, etc. 993 Fails if the slotframe ID does not exist. 995 3.3.2. READ.monitoring.status 997 Reads the current Monitoring status. Requires the following 998 parameters. 1000 slotframe ID: the ID of the slotframe. 1002 target node address: the target neighbor address. 1004 Returns the QoS levels for that Target node on that slotframe. 1006 allocated_hard: Number of hard cells allocated. 1008 allocated_soft: Number of soft cells allocated. 1010 provisioned: the extra provisioned cells. 0 if CONFIGURE.qos 1011 enforce is DISABLE. 1013 QoS: the current QoS. Including overprovisioned cells, i.e 1014 what bandwidth is being obtained including the overprovisioned 1015 cells. 1017 RQoS: the real QoS without provisioned cells. What is the 1018 actual bandwidth without taking into account the 1019 overprovisioned cells. 1021 Fails if the slotframe ID does not exist. 1023 3.4. Statistics Commands 1025 6top keeps track of TSCH statistics for upper layers to adapt 1026 correctly to medium changes. The exact metrics for statistics are 1027 out of scope but the present commands SHOULD be used to configure and 1028 read monitored information regardless of the specific metric. 1030 3.4.1. CONFIGURE.statistics 1032 Configures Statistics process. The command requires: 1034 slotframe ID: ID of the slotframe. If empty monitors all 1035 slotframe IDs 1037 slotOffset: specific slotOffset to be monitored. If empty all 1038 timeslots are monitored 1040 channelOffset: specific channelOffset to be monitored. If 1041 empty all channels are monitored. 1043 target node address: the target neighbor address. If empty, 1044 all neighbor nodes are monitored. 1046 metric: metric to be monitored. This MAY be PDR, ETX, queuing 1047 statistics, energy-related metrics, etc.) 1049 window: time window to be considered for the calculations. If 1050 0 all historical data is considered. 1052 enable: Enables statistics or disables them. 1054 Fails if the slotframe ID does not exist. The statistics service can 1055 be configured to retrieve statistics at different levels. For 1056 example to aggregate information by slotframe ID, or to retrieve 1057 statistics for a particular timeslot, etc. The CONFIGURE.statistics 1058 enables flexible configuration and supports empty parameters that 1059 will force 6top to conduct statistics on all members of that 1060 dimension. For example, if ChannelOffset is empty and metric is set 1061 as PDR, then, 6top will conduct the statistics of PDR on all of 1062 channels. 1064 3.4.2. READ.statistics 1066 Reads a metric for the specified dimension. Information is 1067 aggregated according to the parameters. The command requires: 1069 slotframe ID: ID of the slotframe. If empty aggregates 1070 information of all slotframe IDs 1072 slotOffset: the specific slotOffset for which the information 1073 is required. If empty all timeslots are aggregated 1075 channelOffset: the specific channelOffset for which the 1076 information is required. If empty all channels are aggregated. 1078 target node address: the target neighbor address. If empty all 1079 neighbor addresses are aggregated. 1081 metric: metric to be read. 1083 Returns the value for the requested metric. 1085 Fails if empty metric or metric does not exits. 1087 3.4.3. RESET.statistics 1089 Resets the gathered statistics. The command requires: 1091 slotframe ID: ID of the slotframe. If empty resets the 1092 information of all slotframe IDs 1094 slotOffset: the specific slotOffset for which the information 1095 wants to be reset. If empty statistics from all timeslots are 1096 reset 1098 channelOffset: the specific channelOffset for which the 1099 information wants to be reset. If empty all statistics for all 1100 channels are reset. 1102 target node address: the target neighbor address. If empty all 1103 neighbor addresses are aggregated. 1105 metric: metric to be reset. 1107 Fails if empty metric or metric does not exits. 1109 3.5. Network Formation Commands 1111 EBs need to be configured, including their transmission period, the 1112 slotOffset and channelOffset that they SHOULD be sent on, and the 1113 join priority they contain. The parameters for that command are 1114 optional and enable flexible configuration of EBs. If slotframe ID 1115 is specified, the EBs will be configured to use that specific 1116 slotframe; if not, they will use the first slotframe where the 1117 configured slotOffset is allocated. The slotOffset enforces the EB 1118 to a specific timeslot. In case slotOffset parameter is not present, 1119 the EB is sent in the first available transmit timeslot. In case 1120 channelOffset parameter is not set, the EB is configured to use the 1121 first available channel. 1123 3.5.1. CONFIGURE.eb 1125 Configures EBs. The command requires: 1127 slotframe ID: ID of the slotframe where the EBs MUST be sent. 1128 Zero if any slotframe can be used. 1130 slotOffset: the slotOffset where the EBs MUST be sent. Zero if 1131 any timeslot can be used. 1133 channelOffset: the channelOffset where the EBs MUST be sent. 1134 Zero if any channelOffset can be used. 1136 period: the EBs period, in seconds. 1138 Expiration: when the EBs periodicity will stop. If Zero the 1139 period never stops. 1141 priority: the joining priority model that will be used for 1142 advertisement. Joining priority MAY be for example 1143 SAME_AS_PARENT, RANDOM, BEST_PARENT+1 or DAGRANK(rank) as 1144 decribed in in [I-D.ietf-6tisch-minimal]. 1146 Fails if the tuple (slotframe ID, slotOffset, channelOffset) is 1147 already scheduled. 1149 3.5.2. READ.eb 1151 Reads the EBs configuration. No parameters are required. 1153 Returns the current EBs configuration for that slotframe, which 1154 contains: 1156 slotframe ID: the slotframe where the EB is being sent. 1158 slotOffset: the slotOffset where the EBs is being sent. 1160 channelOffset: the channelOffset the EBs is being sent on. 1162 period: the EBs period. 1164 Expiration: when the EBs periodicity stops. If 0 the period 1165 never stops. 1167 priority: the joining priority that this node advertises. 1169 Fails if the slotframe ID does not exist. 1171 3.6. Time Source Neighbor Commands 1173 Commands to select time source neighbors. 1175 3.6.1. CONFIGURE.timesource 1177 Configures the Time Source Neighbor selection process. More than one 1178 time source neighbor can be selected. The command requires: 1180 selection policy: The policy used to select the time source 1181 neighbor. The policy MAY be for example ALL_PARENTS, 1182 BEST_CONNECTED, LOWEST_JOIN_PRIORITY, etc. 1184 Fails if any of the time source neighbors do not exist or it is not 1185 reachable. 1187 3.6.2. READ.timesource 1189 Retrieves information about the time source neighbors of that node. 1190 The command does not require any parameter. 1192 Returns the following information for each of the time sources: 1194 target node: address of the time source neighbor. 1196 statistics: includes for example minimum, maximum, average time 1197 correction for that time source neighbor 1199 policy: the used policy 1201 Fails if the slotframe ID or no time source neighbors exist. 1203 3.7. Neighbor Commands 1205 Commands to manage neighbor table. The commands SHOULD be used by 1206 the upper layer to query the neighbor related information and by the 1207 lower layer to keep track of neighbors information. 1209 3.7.1. CREATE.neighbor 1211 Creates an entry for a neighbor in the neighbor table. 1213 neighbor address: The address of the neighbor. 1215 neighbor stats: for example, RSSI of the last received packet 1216 from that neighbor, ASN when that neighbor has been added, etc. 1218 Returns whether the neighbor is created or not. 1220 3.7.2. READ.all.neighbor 1222 Returns the list of neighbors of that node. Fails if empty. For 1223 each neighbor in the list it returns: 1225 neighbor address: The address of the neighbor. 1227 neighbor stats: for example, RSSI of the last received packet 1228 from that neighbor, ASN when that neighbor has been added, 1229 packets received from that neighbor, packets sent to it, etc. 1231 3.7.3. READ.neighbor 1233 Returns the information of a specific neighbor of that node specified 1234 by its neighbor address. Fails if it does not exists. For that 1235 neighbor it returns: 1237 neighbor address: The address of the neighbor. 1239 neighbor stats: for example, RSSI of the last received packet 1240 from that neighbor, ASN when that neighbor has been added, 1241 packets received from that neighbor, packets sent to it, etc. 1243 3.7.4. UPDATE.neighbor 1245 Updates an entry for a neighbor in the neighbor table. Fails if the 1246 neighbor does not exist. Updates stats parameters. Requires: 1248 neighbor address: The address of the neighbor. 1250 neighbor stats: for example, RSSI of the last received packet 1251 from that neighbor, ASN when that neighbor has been added, etc. 1253 Returns whether the neighbor is updated or not. 1255 3.7.5. DELETE.neighbor 1257 Deletes a neighbor given its address. Fails if the neighbor does not 1258 exists. 1260 3.8. Queueing Commands 1262 Queues need to be configured. This includes queue length, 1263 retransmission policy, discarding of packets, etc. 1265 3.8.1. CREATE.queue 1267 Creates and Configures Queues. The command SHOULD be applied for 1268 each required queue. The command requires: 1270 txqlength: the desired transmission queue length. 1272 rxqlength: the desired reception queue length. 1274 numrtx: number of allowed retransmissions. 1276 age: discard packet according to its age on the queue. 0 if no 1277 discards are allowed. 1279 rtxbackoff: retransmission backoff in number of slotframes. 0 1280 if next available timeslot wants to be used. 1282 statswindow: window of time used to compute stats. 1284 queue priority: the priority of this queue. 1286 TrackIDs: a set of TrackIDs. While it is empty, no specific 1287 track is associated with the queue 1289 Returns the queue ID. 1291 3.8.2. READ.queue 1293 Reads the queue configuration. Requires the queue ID. 1295 The command returns: 1297 txqlength: the transmission queue length. 1299 rxqlength: the reception queue length. 1301 numrtx: number of allowed retransmissions. 1303 age: maximum age of a packet before being discarded. 0 if no 1304 discards are allowed. 1306 rtxbackoff: retransmission backoff in number of slotframes. 0 1307 if next available timeslot is used. 1309 3.8.3. READ.queue.stats 1311 Reads the queue stats. Requires queue ID. 1313 The command returns: 1315 txqlengthstats: average, maximum, minimum length of the 1316 transmission queue. 1318 rxqlengthstats: average, maximum, minimum length of the 1319 reception queue. 1321 numrtxstats: average, maximum, minimum number of 1322 retransmissions. 1324 agestats: average, maximum, minimum age of a packet in the 1325 queue. 1327 rtxbackoffstats: average, maximum, minimum retransmission 1328 backoff. 1330 queue priority: the priority of this queue. 1332 TrackIDs: a set of TrackIDs. 1334 3.8.4. UPDATE.queue 1336 Update a Queue. The command requires: 1338 queueid: the queue ID. 1340 txqlength: the desired transmission queue length. 1342 rxqlength: the desired reception queue length. 1344 numrtx: number of allowed retransmissions. 1346 age: discard packet according to its age on the queue. 0 if no 1347 discards are allowed. 1349 rtxbackoff: retransmission backoff in number of slotframes. 0 1350 if next available timeslot wants to be used. 1352 statswindow: window of time used to compute stats. 1354 queue priority: the desired priority of this queue. 1356 TrackIDs: the desired set of TrackIDs. 1358 3.8.5. DELETE.queue 1360 Deletes a Queue. The command requires the queue ID. All packets in 1361 the queue are discarded and the queue is deleted. 1363 3.9. Label Switching Commands 1365 6top is responsible for maintaining the mapping of input cells and 1366 output cells in the same track in a particular node. By keeping that 1367 mapping, layer 3 routing can be avoided as packets are forwarded by 1368 the 6top sublayer according to the input cells they were received on. 1369 The selected output cell is one of the cells that forward the packet 1370 to the subsequent hop in the track. 1372 3.9.1. LabelSwitching.map 1374 The command used by an upper layer to map an input cell or a bundle 1375 of input cells to an output cell or a bundle of output cells. 6top 1376 stores this mapping and makes sure that the packets are forwarded at 1377 the specific output cell/bundle. Label Switching is enabled by the 1378 specified bundle as soon as the mapping is installed. 1380 The required parameters are: 1382 input cells: list of input cells (one or more cells in a 1383 bundle). Each input cells is described by an unique tuple 1384 (slotOffset, channelOffset, destination address). 1386 output cells: list of output cells (one or more cells in a 1387 bundle). Each output cells is described by an unique tuple 1388 (slotOffset, channelOffset, destination address). 1390 load balancing policy: A policy for load balance cell usage. 1391 The policy is out of scope, however an example can be use ROUND 1392 ROBIN policy within the cells of the same bundle. 1394 3.9.2. LabelSwitching.unmap 1396 The command used by upper layers to unmap one input cell or a bundle 1397 of input cells to an output cell or a bundle of output cells. The 1398 mapping is removed from the state kept by 6top. 1400 The required parameters are: 1402 input cells: list of input cells (one or more cells in a 1403 bundle). Each input cells is described by an unique tuple 1404 (slotOffset, channelOffset, destination address). 1406 output cells: list of output cells (one or more cells in a 1407 bundle). Each output cells is described by an unique tuple 1408 (slotOffset, channelOffset, destination address). 1410 3.10. Chunk Command 1412 3.10.1. Create.chunk 1414 Create a chunk which consists of one or more unappropriated cells. 1416 To create a chunk, upper layer specifies: 1418 slotframe ID: ID of the slotframe which this chunk belongs to. 1420 ChunkSize: number of the cells which the chunk includes. 1422 SlotBase : the base slotOffset of the chunk. 1424 SlotStep : the incremental of slotOffset in the chunk. 1426 ChannelBase: the base channelOffset of the chunk. 1428 ChannelStep: the incremental of channalOffset in the chunk. 1430 ChunkID is the return value of the command 1431 ([I-D.wang-6tisch-6top-interface]). The chunk is a set of cells in 1432 the given slotframe, consisting of (slotOffset(i),channelOffset(i)), 1433 i=0..Chunksize-1, slotOffset(i)= (slotBase + i * slotStep) % 1434 slotframeLen, channelOffset(i) = (channelBase + i * channelStep) % 1435 16". Those cells will be added into ChunkCellList 1436 ([I-D.wang-6tisch-6top-interface]) also. 1438 3.10.2. READ.chunk 1440 Returns the information of a chunk given its ChunkId. The command 1441 returns: 1443 slotframe ID: ID of the slotframe which this chunk belongs to. 1445 ChunkSize: number of the cells which the chunk includes. 1447 SlotBase : the base slotOffset of the chunk. 1449 SlotStep : the incremental of slotOffset in the chunk. 1451 ChannelBase: the base channelOffset of the chunk. 1453 ChannelStep: the incremental of channalOffset in the chunk. 1455 Fails if the ChunkId does not exist. 1457 3.10.3. Delete.chunk 1459 To delete a chunk, upper layer specifies ChunkID. 1461 It removes the chunk from ChunkList 1462 ([I-D.wang-6tisch-6top-interface]), and also remove those entries 1463 corresponding to the cells of the chunk from 1464 ChunkCellList([I-D.wang-6tisch-6top-interface]). In addition, it 1465 also causes all of the scheduled cells in the chunk are deleted from 1466 CellList ([I-D.wang-6tisch-6top-interface]) and TSCH schedule as 1467 well. 1469 3.11. Chunk Cell Command 1471 3.11.1. CREATE.hardcell.fromchunk 1473 Creates one or more hard cells from a chunk. Fails if the cell 1474 already exists. A cell is uniquely identified by the tuple 1475 (slotframe ID, slotOffset, channelOffset). 1477 To create a hard cell from a chunk which is corresponding to a 1478 specific slotframe ID, the upper layer specifies: 1480 chunkID: ID of the chunk which this cell belongs to. 1482 slotOffset: the slotOffset for the cell. 1484 channelOffset: channelOffset for the cell. 1486 LinkOption bitmap: bitmap as defined in [IEEE802154e] 1488 LinkType : as defined in section 6.2.19.3 of [IEEE802154e]. 1490 CellType: as defined in Section 2.1 1492 target node address: the address of that node to communicate 1493 with over this cell. In case of broadcast cells this is the 1494 broadcast address. 1496 TrackID: ID of the track the cell will belong to. 1498 6top schedules the cell and marks it as a hard cell, indicating that 1499 it cannot reschedule this cell. In addition, 6top will change the 1500 attributes corresponding to the cell in the ChunkCellList, i.e. its 1501 CellID is changed to the same CellID in the CellList, and its Status 1502 is changed to USED ([I-D.wang-6tisch-6top-interface]). 1504 The interaction between 6top and MAC layer caused by 1505 CREATE.hardcell.fromchunk is same as that caused by CREATE.hardcell 1506 (Section 3.1.1). 1508 3.11.2. READ.chunkcell 1510 Returns the cell information of a chunk given its ChunkId. For each 1511 cell of the chunk, the command returns: 1513 slotOffset: the slotOffset of the cell. 1515 channelOffset: channelOffset of the cell. 1517 cellId: the cellID in the CellList if scheduled. 1519 Status: USED/UNUSED 1521 Fails if the ChunkId does not exist. 1523 3.11.3. DELETE.hardcell.fromchunk 1525 To remove a hard cell which comes from a chunk, the upper layer 1526 specifies: 1528 slotframe ID: the ID of the slotframe where this cell is 1529 installed. 1531 slotOffset: the slotOffset for the cell. 1533 channelOffset: the selected channelOffset for the cell. 1535 LinkOption bitmap: bitmap as defined in [IEEE802154e] 1537 LinkType : as defined in in section 6.2.19.3 of [IEEE802154e]. 1539 CellType: as defined in Section 2.1 1541 target node address: the target address of that cell. In case 1542 of broadcast cells this is the broadcast address. 1544 TrackID: ID of the track the cell will belong to. 1546 This removes the hard cell from the node's schedule and CellList 1547 ([I-D.wang-6tisch-6top-interface]). In addition, it changes the 1548 attributes corresponding to the cell in the ChunkCellList, i.e. its 1549 CellID is changed back to FFFF, and its Status is changed to UNUSED 1550 ([I-D.wang-6tisch-6top-interface]). 1552 The interaction between 6top and MAC layer caused by DELETE.hardcell 1553 is same as that caused by DELETE.hardcell (Section 3.1.5). 1555 3.12. Data Commands 1557 3.12.1. Send.data 1559 The command used by upper layers to queue a packet so underlying TSCH 1560 sends it. According to the specific priority, the packet is pushed 1561 into a Queue with the equivalent priority or following a criteria out 1562 of scope. Once a packet is inserted into a queue it waits to be 1563 transmitted by TSCH according to the model defined in Section 2.2. 1564 If the queue is full or destination address is not a L2 neighbor of 1565 the node, failure to enqueue will be indicated to the caller. 1567 The required parameters are: 1569 src address: L2 address 1571 dest address: L2 unicast or broadcast address 1573 priority: packet priority, usually is consistent with queue 1574 priority 1576 message length: the length of the message 1578 message: control message or data message 1580 securityLevel:As defined by [IEEE802154e]. 1582 3.12.2. Receive.data 1584 The command is invoked whenever a packet is received and inserted 1585 into a reception queue. The method acts as a callback function to 1586 notify to the upper layers the received message. Upper layers MUST 1587 terminate this indication. 1589 The function has the following parameters: 1591 src address: L2 source address 1593 dest address: L2 unicast or broadcast destination address 1594 priority: packet priority, usually is consistent with queue 1595 priority 1597 message length: the length of the message. 1599 message: control message or data message 1601 4. 6top Communication Protocol 1603 This section defines the Information Element (IE) based message 1604 formats, and the 6top-to-6top communication time sequences. 1606 4.1. Message Formats 1608 6top has to negotiate the scheduling of soft cells with neighbor 1609 nodes. This negotiation happens through 6top-specific TSCH 1610 Information Elements, the format of which is defined in this section. 1611 For completeness, this section also details the formats of the IEs 1612 already defined in [IEEE802154e] and presented here without 1613 modification. 1615 6top messages can contain one or more IEs. Section 4.1.1 defines the 1616 different IEs used by 6top, both the ones used without modification 1617 from [IEEE802154e], and the new ones defined by this document. 1618 Section 4.1.2 shows how several IEs are assembled to form the 1619 different frames used by 6top. 1621 4.1.1. Information Elements 1623 [IEEE802154e] defines Information elements (IEs). IEs are formatted 1624 data objects consisting of an ID, a length, and a data payload used 1625 to pass data between layers or devices. [IEEE802154e] defines Header 1626 IEs and Payload IEs; 6top only uses Payload IEs. A Payload IE 1627 includes one or more IEs, and ends with a termination IE (ID = 0x0f, 1628 see [IEEE802154e]). 1630 6top uses the following Information Elements, some defined in 1631 [IEEE802154e], others introduced in this document. 1633 Defined in [IEEE802154e] and used by 6top without modification: 1635 TSCH Synchronization IE (Section 4.1.1.1) 1637 TSCH Slotframe and Link IE (Section 4.1.1.2) 1639 TSCH Timeslot Template IE (Section 4.1.1.3) 1640 TSCH Channel Hopping IE (Section 4.1.1.4) 1642 Defined by 6top: 1644 6top Opcode IE (Section 4.1.1.5) 1646 6top Bandwidth IE (Section 4.1.1.6) 1648 6top TrackID IE (Section 4.1.1.7) 1650 6top Generic Schedule IE (Section 4.1.1.8) 1652 4.1.1.1. TSCH Synchronization IE 1654 A Synchronization IE (SyncIE) contains Information allowing a node to 1655 synchronize to a TSCH network, including the current ASN and a join 1656 priority. Synchronization IE MUST be included in all TSCH Enhanced 1657 Beacons. 1659 6top re-uses this IE as defined in [IEEE802154e]. 1661 Format of a TSCH Synchronization IE (SyncIE). 1663 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | Length | SubID |T| ASN | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | ASN | Join Priority | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 Figure 3 1672 Length=6 1674 SubID=0x1a 1676 T=0, i.e., short type 1678 ASN (5 octets) contains the Absolute Slot Number corresponding to the 1679 timeslot in which the TSCH Enhanced Beacon is sent. 1681 The Join Priority can be used by a joining device to select among 1682 beaconing devices when multiple beacons are heard. The PAN 1683 coordinator's join priority is zero. A lower value of join priority 1684 indicates that the device is the preferred one to connect to. As 1685 suggested by [I-D.ietf-6tisch-minimal], the beaconing device's join 1686 priority is its DAGRank(rank). 1688 4.1.1.2. TSCH Slotframe and Link IE 1690 The Slotframe and Link IE (FrameAndLinkIE) contains one or more 1691 slotframes and their respective cells that a beaconing device 1692 advertises to allow other devices to join the network. 1694 6top re-uses this IE as defined in [IEEE802154e]. 1696 Format of a TSCH Slotframe and Link IE (FrameAndLinkIE). 1698 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Length | SubID |T| NumFrame | | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1702 | | 1703 // Slotframe and cell information // 1704 | | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 Figure 4 1709 Length=variable 1711 SubID=0x1b 1713 T=0, i.e., short type 1715 NumFrame is set to the total number of slotframe descriptors 1716 contained in the TSCH Enhanced Beacon. 1718 Format of a slotframe descriptor. 1720 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | FrameID | FrameLen | NumCell | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | | 1725 // Cell information for each cell (5x NumCell) // 1726 | | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 Figure 5 1731 The FrameID field shall be set to the slotframeHandle that uniquely 1732 identifies the slotframe. 1734 The FrameLen field shall be set to the size of the slotframe in 1735 number of timeslots. 1737 The NumCell field shall be set to the number of cells that belong to 1738 the specific slotframe identified by the slotframeHandle. 1740 Format of a Cell information. 1742 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | SlotOffset | ChannelOffset | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | LinkOption | 1747 +-+-+-+-+-+-+-+-+ 1749 Figure 6 1751 SlotOffset shall be set to the slotOffset of this cell. 1753 ChannelOffset shall be set to the channelOffset of this cell. 1755 LinkOption indicates whether this cell is a TX cell, an RX cell, or a 1756 SHARED TX cell, whether the device to which it is being linked is to 1757 be used for clock synchronization, and whether this cell is hard 1758 cell. 1760 4.1.1.3. TSCH Timeslot Template IE 1762 Timeslot Template IE (SlotTemplateIE) defines Timeslot template being 1763 used by the TSCH device. 1765 6top re-uses this IE as defined in [IEEE802154e]. 1767 Format of a TSCH Timeslot Template IE (SlotTemplateIE). 1769 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Length | SubID |T| TemplateID | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 Figure 7 1776 Length=1 1778 SubID=0x1c 1780 T=0, i.e., short type 1781 TemplateID shall be set to a Timeslot template handle. The full 1782 timeslot template, which contains the macTimeslotTemplate of TSCH 1783 (total 25 octets), MAY be included.(see [IEEE802154e]). 1785 4.1.1.4. TSCH Channel Hopping IE 1787 Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being 1788 used by the TSCH device. 1790 6top re-uses this IE as defined in [IEEE802154e]. 1792 Format of a TSCH Channel Hopping IE (ChHoppingIE). 1794 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Length | SubID |T| HopSequenceID | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 Figure 8 1801 Length=1 1803 SubID=0x09 1805 T=1, i.e., long type 1807 HopSequenceID shall be set to a Hopping Sequence handle. The full 1808 Hopping Sequence information MAY be included. (see [IEEE802154e]). 1810 4.1.1.5. 6top Opcode IE 1812 6top Opcode IE (OpcodeIE) defines operation codes of packets in 6top 1813 sublayer. 1815 This IE is not present in [IEEE802154e] and is defined by 6top. 1817 Format of a 6top Opcode IE (OpcodeIE). 1819 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | Length | SubID |T| OpcodeID | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 Figure 9 1826 Length=1 1828 SubID=0x41 1829 T=0, i.e., short type 1831 OpcodeID field shall be set to one of the following codes. 1833 0x00: Reserve Soft Cell Request 1835 0x01: Reserve Soft Cell Response 1837 0x02: Remove Soft Cell Request 1839 0x03: Reserve Hard Cell Request 1841 0x04: Remove Hard Cell Request 1843 4.1.1.6. 6top Bandwidth IE 1845 Bandwidth IE (BwIE) defines the number of cells to be reserved or 1846 actually be reserved. 1848 This IE is not present in [IEEE802154e] and is defined by 6top. 1850 Format of a 6top Bandwidth IE (BwIE). 1852 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | Length | SubID |T| FrameID | NumCell | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 Figure 10 1859 Length=2 1861 SubID=0x42 1863 T=0, i.e., short type 1865 FrameID MAY be set to the SlotFrameHandle to identify the slotframe 1866 from which cells are reserved. FrameID field MAY be set to NOP, 1867 which means no specific slotframe is associated. 1869 NumCell shall be set to the number of cells. When BwIE is combined 1870 with the OpecodeID of Reserve Soft Cell Request, NumCell presents how 1871 many cells are required to reserve; and when BwIE is combined with 1872 the OpecodeID of Reserve Soft Cell Response, NumCell presents how 1873 many cells are reserved successfully. 1875 4.1.1.7. 6top TrackID IE 1877 TrackID IE (TrackIdIE) describes the track which the reserved/removed 1878 cell(s) are associated with. 1880 This IE is not present in [IEEE802154e] and is defined by 6top. 1882 Format of a 6top TrackID IE (TrackIdIE). 1884 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Length | SubID |T|OwnerInstID|rev| | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1888 // // 1889 | TrackOwnerAddr | 1890 | | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 Figure 11 1895 Length=3 or 7. When length=3, TrackOwnerAddr is 2 bytes short 1896 address, and when length=7, TrackOwnerAddr is 6 bytes long address. 1898 SubID=0x43 1900 T=0, i.e., short type 1902 The combination of TrackOwnerAddr and OwnerInstId represents a 1903 specific TrackID. 1905 4.1.1.8. 6top Generic Schedule IE 1907 Generic Schedule IE (ScheduleIE) describes cell sets. In different 1908 packets, ScheduleIE represents different information. See 1909 Section 4.1.2 for more detail. 1911 This IE is not present in [IEEE802154e] and is defined by 6top. 1913 Format of a 6top Generic Schedule IE (ScheduleIE). 1915 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Length | SubID |T| | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1919 | | 1920 // Schedule Body // 1921 | | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 Figure 12 1926 Length=variable 1928 SubID=0x44 1930 T=0, i.e., short type 1932 Schedule Body carries one or more schedule object. An object MAY 1933 carry a TLV (Type-Length-Value), which MAY itself comprise other 1934 TLVs. TLV format is as follows. Type: 1 byte, Length: 1 byte, 1935 Value: variable 1937 The following are some examples of schedule object TLV. 1939 Example 1. Cell Set TLV 1941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 | Type=1 | Length | FrameID | NumCell |F| 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | | 1946 // CellObjects // 1947 | | 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 Figure 13 1952 FrameID shall be set to the slotframeHandle that uniquely identifies 1953 the slotframe. 1955 NumCell shall be set to the number of cells that belong to the 1956 specific slotframe identified by the slotframeHandle. 1958 F=1 means the specified cells equals to what are listed in 1959 CellObjects, and F=0 means the specified cells equals to what are not 1960 listed in CellObjects. 1962 CellObjects carries the information for one or more cells, including 1963 SlotOffset, ChannelOffset, LinkOption (Figure 6). 1965 Example 2. Schedule Matrix TLV 1967 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Type=2 | Length | FrameID |StartSlotOffset| 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 |StartSLotOffset| NumSlot | | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1973 | | 1974 // SlotBitMap (2x NumSlot) // 1975 | | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 Figure 14 1980 FrameID field MUST be set to the slotframeHandle that uniquely 1981 identifies the slotframe. 1983 StartSlotOffset field (2 octets) MUST be set to the slotOffset in the 1984 specific slotframe identified by the slotframeHandle. 1986 NumSlot field MUST be set to the number of timeslots from 1987 StartSlotOffset in the specific slotframe identified by the 1988 slotframeHandle. 1990 SlotBitMap (per timeslot) indicates for the given timeslot which 1991 channels are specified. For the 16 channels in 2.4GHz band, 2-octets 1992 are used to indicate which channel is specified. For example, given 1993 a timeslot and a SlotBitmap with value (10001000,00010000); the 1994 bitmap represents that ChannelOffset-0, ChannelOffset-4, 1995 ChannelOffset-11 are specified. 1997 4.1.2. Packet Formats 1999 This section describes the packets used in 6top to form a network, 2000 reserve/maintain bandwidth using soft cells, and reserve/remove hard 2001 cells in both the transmitter side and receiver sides. Each of these 2002 packets uses one or more IEs defined in Section 4.1.1. 2004 4.1.2.1. TSCH Enhanced Beacon 2006 The TSCH Enhanced Beacon is used to announce the presence of the 2007 network and allows new nodes to join. It is an Enhanced Beacon 2008 packet defined in [IEEE802154e] with the following Payload IEs: 2010 TSCH Synchronization IE (Section 4.1.1.1) 2012 TSCH Timeslot Template IE (Section 4.1.1.3) 2014 TSCH Channel Hopping IE (Section 4.1.1.4) 2016 TSCH Slotframe and Link IE (Section 4.1.1.2) 2018 Payload IE of TSCH Enhanced Beacon Packet 2020 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | Length |GroupID|T| SyncIE | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | SyncIE | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | SyncIE | SlotTemplateIE | 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 |SlotTemplateIE | ChHoppingIE | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | | 2031 // FrameAndLinkIE // 2032 | | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 Figure 15 2037 Length=variable 2039 GroupID=0x1, i.e., MLME IE 2041 T=1, i.e., payload IE 2043 See Section 4.1.1.1, Section 4.1.1.3, Section 4.1.1.4,Section 4.1.1.2 2044 for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndLinkIE. 2046 4.1.2.2. Soft Cell Reservation Request 2048 A Soft Cell Reservation Request packet is a DATA packet defined in 2049 [IEEE802154e] with the following payload IE. 2051 Payload IE of Soft Cell Reservation Request 2053 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | Length |GroupID|T| OpcodeIE | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | OpcodeIE | BwIE | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | BwIE | | 2060 +-+-+-+-+-+-+-+-+ | 2061 // ScheduleIE // 2062 | | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 Figure 16 2067 Length=variable 2069 GroupID=0x1, i.e., MLME IE 2071 T=1, i.e., payload IE 2073 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x00, 2074 indicates Reserve Soft Cell Request operation. 2076 The NumCell field in 4-octet BwIE SHOULD be set to the number of 2077 cells needed to be reserved. 2079 The ScheduleIE specifies a candidate cell set, from which the cells 2080 SHOULD be reserved. ScheduleIE MAY be empty, means there is no 2081 constrain on which cells SHOULD not be reserved. 2083 In addition, TrackIdIE can be added in the packet to associate the 2084 reserved soft cells to a specific TrackID. 2086 4.1.2.3. Soft Cell Reservation Response 2088 Soft Cell Reservation Response is a DATA packet defined in 2089 [IEEE802154e] with the following payload IE. 2091 Payload IE of Soft Cell Reservation Response 2093 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Length |GroupID|T| OpcodeIE | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | OpcodeIE | BwIE | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | BwIE | | 2100 +-+-+-+-+-+-+-+-+ | 2101 // ScheduleIE // 2102 | | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 Figure 17 2107 Length=variable 2109 GroupID=0x1, i.e., MLME IE 2111 T=1, i.e., payload IE 2113 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x01, 2114 indicates Reserve Soft Cell Response operation. 2116 The NumCell field in 4-octet BwIE SHOULD be set to the number of 2117 cells which have been reserved successfully. 2119 The ScheduleIE SHOULD specify all of the cells which have been 2120 reserved successfully. 2122 In addition, TrackIdIE can be added in the packet to associate the 2123 reserved soft cells to a specific TrackID. 2125 4.1.2.4. Soft Cell Remove Request 2127 Soft Cell Remove Request is a DATA packet defined in [IEEE802154e] 2128 with the following payload IE. 2130 Payload IE of Soft Cell Remove Request 2132 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | Length |GroupID|T| OpcodeIE | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | OpcodeIE | | 2137 +-+-+-+-+-+-+-+-+ | 2138 // ScheduleIE // 2139 | | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 Figure 18 2144 Length=variable 2146 GroupID=0x1, i.e., MLME IE 2148 T=1, i.e., payload IE 2150 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x02, 2151 indicates Remove Soft Cell Request operation. 2153 The ScheduleIE SHOULD specify all the cells that need to be removed. 2155 4.1.2.5. Hard Cell Reservation Request 2157 Hard Cell Reservation Request packet is a DATA packet defined in 2158 [IEEE802154e] with the following payload IE. 2160 Payload IE of Hard Cell Reservation Request 2162 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | Length |GroupID|T| OpcodeIE | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | OpcodeIE | | 2167 +-+-+-+-+-+-+-+-+ | 2168 // ScheduleIE // 2169 | | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 Figure 19 2174 Length=variable 2176 GroupID=0x1, i.e., MLME IE 2177 T=1, i.e., payload IE 2179 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x03, 2180 indicates Reserve Hard Cell Request operation. 2182 The ScheduleIE SHOULD specify all the cell that need to be reserved. 2184 In addition, TrackIdIE can be added in the packet to associate the 2185 reserved hard cells to a specific TrackID. 2187 4.1.2.6. Hard Cell Remove Request 2189 Hard Cell Remove Request is a DATA packet defined in [IEEE802154e] 2190 with the following payload IE. 2192 Payload IE of Hard Cell Remove Request 2194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | Length |GroupID|T| OpcodeIE | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | OpcodeIE | | 2199 +-+-+-+-+-+-+-+-+ | 2200 // ScheduleIE // 2201 | | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 Figure 20 2206 Length=variable 2208 GroupID=0x1, i.e., MLME IE 2210 T=1, i.e., payload IE 2212 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x04, 2213 indicates Remove Hard Cell Request operation. 2215 The ScheduleIE SHOULD specify all the cells that need to be removed. 2217 4.2. Time Sequences 2219 6top neighbors exchange 6top-specific packets in the following cases, 2220 each detailed in a subsection. 2222 Network formation (Section 4.2.1) 2224 Creating soft cells (Section 4.2.2) 2225 Deleting soft cells (Section 4.2.3) 2227 Maintaining soft cells (Section 4.2.4) 2229 Creating hard cells (Section 4.2.5) 2231 Deleting hard cells (Section 4.2.6) 2233 4.2.1. Network Formation 2235 Network formation consists of two processes: joining and maintenance. 2237 4.2.1.1. Joining 2239 A node already in the network sends out TSCH Enhanced Beacons 2240 periodically. 2242 When a node is joining an existing network, it listens for TSCH 2243 Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs 2244 (the format of which is detailed in Section 4.1.2.1), the joining 2245 node MUST do the following. 2247 Initialize a neighbor table. Establish a neighbor table and 2248 record all of the information described in the TSCH Enhanced 2249 BEACONs as its initial schedule with those neighbors. 2251 Select a time source neighbor. According to the Joining 2252 Priority described by SyncIEs, the joining node chooses time 2253 source neighbors. 6top does not specify the criteria to choose 2254 time source neighbors from the Enhanced BEACONs. 2256 Select cells for Enhanced Beacons. The joining node selects 2257 one or more cells to indicate in its own Enhanced Beacons, 2258 which MAY be the same as the cells used by its neighbors for 2259 Enhanced Beacon broadcast, and record those cell(s) into the 2260 TSCH schedule with LinkType=ADVERTISING. 2262 Its Enhanced Beacons SHOULD include the cell(s) selected for EB 2263 purposes. The EB cells MUST be configured with LinkOption to 2264 "Receive" and "Timekeeping", telling its neighbors that the 2265 cell is used for broadcast. 2267 Start broadcasting Enhanced Beacon and communicate with 2268 neighbors. 2270 4.2.1.2. Maintenance 2272 Nodes MAY broadcast Enhance Beacons on the cells marked with 2273 LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors 2274 on the cells with LinkOptions "Receive" and "Timekeeping". If a cell 2275 with LinkType=ADVERTISING has both the "Receive" and "Timekeeping" 2276 LinkOptions set, which means that the cell is shared by neighbors and 2277 itself for broadcasting, then broadcasting Enhanced Beacon has higher 2278 priority. 2280 Whenever a node receives an Enhanced Beacon, it SHOULD update its 2281 schedule if there is a difference regarding to the cells used for 2282 synchronizing with the advertiser of the Enhanced Beacon. 2284 4.2.2. Creating soft cells 2286 The upper layer instructs 6top to schedule one or more soft cells by 2287 calling the Create soft cell command. This command can also be 2288 called by the monitoring process internal to 6top. 2290 When receiving a Create soft cell command, Node A's 6top sublayer 2291 forms a Soft Cell Reservation Request packet which includes the BwIE 2292 and ScheduleIE Information Elements. The BwIE indicates the number 2293 of cells to be reserved (N1); the ScheduleIE indicates set of a 2294 candidate cells from which the new cells SHOULD be selected. If the 2295 ScheduleIE is empty, Node A indicates there is no constraint on cell 2296 selection. 2298 The Soft Cell Reservation Request is sent to the neighbor (Node B) 2299 with whom new cells need to be scheduled. After receiving the Soft 2300 Cell Reservation Request, Node B selects the cells from the candidate 2301 cell set defined by the ScheduleIE in the Soft Cell Reservation 2302 Request, and forms a Soft Cell Reservation Response packet. In the 2303 Cell Reservation Response packet, the BwIE indicates the number of 2304 cells actually being reserved (N2); the ScheduleIE indicates those 2305 reserved cells. If N2 is smaller than N1, node B indicates to node A 2306 that there are not enough qualified cells to be reserved. Node B 2307 MUST record the reserved cells into its local schedule when sending 2308 the Soft Cell Reservation Response. After receiving the Soft Cell 2309 Reservation Response, Node A MUST record the reserved cells into its 2310 local schedule. 2312 The policy to build a candidate cell set and the policy to select 2313 cells from the candidate cell set to reserve are out of scope. 2315 The format of Schedule Body is flexible. For example, Node A can use 2316 Cell Set TLV defined in Figure 13 with field 'F' set to '0', and the 2317 CellObjects includes all of the cells being used by Node A. In 2318 another word, the cell candidate set is all of the cells not being 2319 included in the list defined by CellObjects. 2321 The behavior of the nodes when the soft cells negotiation fails is 2322 out of scope. 2324 4.2.3. Deleting soft cells 2326 The upper layer instructs 6top to delete one or more soft cells by 2327 calling the Delete soft cell command (Section 3.1.6). This command 2328 can also be called by the monitoring process internal to 6top 2329 (Section 6). 2331 When receiving a Delete soft cell command, Node A's 6top sublayer 2332 selects cells to be removed from its local schedule, and creates a 2333 Soft Cell Remove Request, which includes a ScheduleIE Information 2334 Element. The ScheduleIE indicates which specific cells to remove 2335 with a neighbor (Node B). The cells specified in the ScheduleIE 2336 SHOULD be removed from local schedule of Node A when the Soft Cell 2337 Remove Request is sent to Node B. When receiving the Soft Cell Remove 2338 Request, the cells specified in the ScheduleIE SHOULD be removed from 2339 the local schedule of Node B. 2341 The policy to select cells corresponding to a Delete soft cell 2342 command is out of scope. 2344 4.2.4. Maintaining soft cells 2346 The monitoring process internal to 6top (Section 6) is responsible 2347 for monitoring and re-scheduling soft cells to meet some QoS 2348 requirements. The monitoring process MAY issue a soft cell 2349 Maintenance command, which indicate a set of cells to be re-allocated 2350 in the TSCH schedule. 2352 When receiving a soft cell Maintenance command, 6top initializes a 2353 Soft Cell Remove Request (Section 4.2.3) with the neighbor in 2354 question, followed by a Soft Cell Reservation Request 2355 (Section 4.2.2). 2357 4.2.5. Creating hard cells 2359 The upper layer instructs 6top to create one or more hard cells by 2360 calling the Create hard cell command. 2362 When receiving a Create hard cell command, Node A's 6top sublayer 2363 creates a Hard Cell Reservation Request, including a ScheduleIE. The 2364 ScheduleIE indicates which specific cells with a neighbor (Node B) to 2365 be added. The cells specified in the ScheduleIE SHOULD be added in 2366 local schedule of Node A while the Hard Cell Reserve Request is sent 2367 to Node B. When receiving the Hard Cell Reserve Request, the cells 2368 specified in the ScheduleIE SHOULD be added in the local schedule of 2369 Node B. 2371 4.2.6. Deleting hard cells 2373 The upper layer instructs 6top to delete one or more hard cells by 2374 calling the Delete hard cell command. 2376 When receiving a Delete hard cell command, Node A's 6top sublayer 2377 creates a Hard Cell Remove Request, including a ScheduleIE. The 2378 ScheduleIE indicates which specific cells with a neighbor (Node B) to 2379 be removed. The cells specified in the ScheduleIE SHOULD be removed 2380 from local schedule of Node A while the Hard Cell Remove Request is 2381 sent to Node B. When receiving the Hard Cell Remove Request, the 2382 cells specified in the ScheduleIE SHOULD be removed from the local 2383 schedule of Node B. 2385 5. Statistics 2387 The 6top Statistics Function (SF) is responsible for collecting 2388 statistics, which it can provide to an upper layer and the Monitoring 2389 Function (Section 6). 2391 5.1. Statistics Metrics 2393 6top is in charge of keeping statistics from a set of metrics 2394 gathered from the behavior of the TSCH layer. 2396 The statistics data related to node states and cell metrics SHOULD be 2397 provided to upper layer for management, e.g., for RPL to calculate 2398 the node's Rank or for GMPLS to the required bandwidth is met. The 2399 specific algorithm to generate the statistics is out of scope. 2400 However, the statistics component SHOULD include the following 2401 metrics: 2403 1. LinkThroughput: associated with a link, Node A->Node B. For 2404 example, LinkThroughput can be calculated with: 2405 SUM(NumOfCell(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration) 2406 where NumOfCell(i) is the total number of cells from Node A to 2407 Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i. 2408 The unit is Byte/second. 2410 2. Latency: associated with a link, Node A->Node B. For example, 2411 latency can be expressed as Minimum and Maximum Latency. Minimum 2412 Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum 2413 Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where, 2414 MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum 2415 number of timeslots between two dedicated cells from Node A to 2416 Node B in Slotframe-i, respectively. 2418 3. LinkQuality. For example, average LQI, ETX, PDR, RSSI. 2420 4. TrafficLoad. For example, Queue Full Rate, Queue Empty Rate. 2422 5. NodeEnergy. For example, E_E=E_bat / [E_0 (T-t)/T]. 2424 5.2. Statistics Configuration 2426 The Statistics Function SHOULD be configurable. The configuration 2427 parameters SHOULD include: 2429 LinkQualityStatisticsEn 2431 TafficLoadStatisticsEn 2433 DeviceStatisticsEn 2435 6top statistics function is enabled/disabled and configured by the 2436 commands defined in Section 3.4 2438 6. Monitoring 2440 The 6top Monitoring Function (MF) is responsible for monitoring cell 2441 quality, traffic load, and issuing soft cell Maintenance commands, or 2442 Create/Delete soft cell commands. The data provided by the 2443 Statistics Function MAY be used as an input of MF in taking a 2444 monitoring decision. 2446 6.1. Monitor Configuration 2448 Monitoring Function SHOULD be configurable. The configuration 2449 parameters SHOULD include: 2451 MaintainCellEn. 2453 CreateDeleteCellEn. 2455 QosLevel. QosLevel SHOULD associate with specific neighbor 2456 address. QosLevel MAY reflect the latency constraint, cell 2457 quality constraint, and so on. The value of QosLevel works as 2458 the bandwidth redundancy coefficient. 2460 The 6top monitoring function is enabled/disabled and configured by 2461 the commands defined in Section 3.3 2463 6.2. Actuation 2465 The cell quality statistics MAY be used to generate soft a cell 2466 Maintenance command, which triggers a soft cell Maintenance procedure 2467 (see Section 4.2.4). The traffic load statistics MAY be used to 2468 generate internal Create (resp. Delete) soft cell commands, which 2469 trggiers a soft cell Reservation (resp. Remove) process (see 2470 Section 4.2.2 and Section 4.2.3). 2472 The policy to generate the soft cell Maintenance command and the 2473 policy to generate Create/Delete soft cell commands is out of scope. 2475 The policy to generate Create/Delete soft cell commands MAY take 2476 QosLevel into account. For example, there are two slotframes 2477 existing, Slotframe-1 consists of 32 timeslots, Slotframe-2 consists 2478 of 96 timeslots; timeslot duration is 10ms; QosLevel=1.5. If, from 2479 the traffic load statistics, MF determines that 2 packet/second 2480 SHOULD be added, then the MF generates a Create soft cell command, 2481 where FrameID=2, NumCell=3. 2483 7. References 2485 7.1. Normative References 2487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2488 Requirement Levels", BCP 14, RFC 2119, March 1997. 2490 7.2. Informative References 2492 [I-D.ietf-6tisch-tsch] 2493 Watteyne, T., Palattella, M., and L. Grieco, "Using 2494 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 2495 Statement and Goals", draft-ietf-6tisch-tsch-00 (work in 2496 progress), November 2013. 2498 [I-D.ietf-6tisch-architecture] 2499 Thubert, P., Watteyne, T., and R. Assimiti, "An 2500 Architecture for IPv6 over the TSCH mode of IEEE 2501 802.15.4e", draft-ietf-6tisch-architecture-01 (work in 2502 progress), February 2014. 2504 [I-D.ietf-6tisch-terminology] 2505 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 2506 "Terminology in IPv6 over the TSCH mode of IEEE 2507 802.15.4e", draft-ietf-6tisch-terminology-01 (work in 2508 progress), February 2014. 2510 [I-D.ietf-6tisch-minimal] 2511 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 2512 Configuration", draft-ietf-6tisch-minimal-00 (work in 2513 progress), November 2013. 2515 [I-D.ohba-6tsch-security] 2516 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 2517 A. Yegin, "Security Framework and Key Management Protocol 2518 Requirements for 6TSCH", draft-ohba-6tsch-security-01 2519 (work in progress), July 2013. 2521 [I-D.wang-6tisch-6top-interface] 2522 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 2523 Operation Sublayer (6top) Interface", draft-wang-6tisch- 2524 6top-interface-01 (work in progress), February 2014. 2526 7.3. External Informative References 2528 [IEEE802154e] 2529 IEEE standard for Information Technology, "IEEE std. 2530 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2531 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2532 2012. 2534 [IEEE802154] 2535 IEEE standard for Information Technology, "IEEE std. 2536 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2537 and Physical Layer (PHY) Specifications for Low-Rate 2538 Wireless Personal Area Networks", June 2011. 2540 [openwsn] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 2541 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 2542 A Standards-Based Low-Power Wireless Development 2543 Environment. Transactions on Emerging Telecommunications 2544 Technologies.", August 2012. 2546 [label-switching-154e] 2547 Morell, A., Vilajosana, X., Lopez-Vicario, J., and T. 2548 Watteyne, "Label Switching over IEEE802.15.4e Networks. 2549 Transactions on Emerging Telecommunications Technologies", 2550 June 2013. 2552 Authors' Addresses 2553 Qin Wang (editor) 2554 Univ. of Sci. and Tech. Beijing 2555 30 Xueyuan Road 2556 Beijing, Hebei 100083 2557 China 2559 Phone: +86 (10) 6233 4781 2560 Email: wangqin@ies.ustb.edu.cn 2562 Xavier Vilajosana 2563 Universitat Oberta de Catalunya 2564 156 Rambla Poblenou 2565 Barcelona, Catalonia 08018 2566 Spain 2568 Phone: +34 (646) 633 681 2569 Email: xvilajosana@uoc.edu 2571 Thomas Watteyne 2572 Linear Technology 2573 30695 Huntwood Avenue 2574 Hayward, CA 94544 2575 USA 2577 Phone: +1 (510) 400-2978 2578 Email: twatteyne@linear.com