idnits 2.17.1 draft-wang-6tisch-6top-sublayer-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 == 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 (July 4, 2014) is 3555 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 2542, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 2548, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 2554, but not defined == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 2514, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-6tisch-6top-sublayer' is defined on line 2530, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-coap' is defined on line 2535, 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-02 == 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-01 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-00 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-00 == Outdated reference: A later version (-03) exists of draft-ietf-6tisch-coap-00 Summary: 3 errors (**), 0 flaws (~~), 17 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: January 5, 2015 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 July 4, 2014 10 6TiSCH Operation Sublayer (6top) 11 draft-wang-6tisch-6top-sublayer-01 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, centralized or 28 hybrid scheduling. In addition, 6top can be configured to enable 29 packet switching at layer 2.5, analogous to GMPLS. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 35 "OPTIONAL" in this document are to be interpreted as described in RFC 36 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 5, 2015. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. 6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . . 5 74 2.1. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 7 75 2.1.1. hard cells . . . . . . . . . . . . . . . . . . . . . 8 76 2.1.2. soft cells . . . . . . . . . . . . . . . . . . . . . 8 77 2.2. Data Transfer Model . . . . . . . . . . . . . . . . . . . 8 78 3. 6top Commands . . . . . . . . . . . . . . . . . . . . . . . . 11 79 3.1. Cell Commands . . . . . . . . . . . . . . . . . . . . . . 13 80 3.1.1. CREATE.hardcell . . . . . . . . . . . . . . . . . . . 13 81 3.1.2. CREATE.softcell . . . . . . . . . . . . . . . . . . . 15 82 3.1.3. READ.cell . . . . . . . . . . . . . . . . . . . . . . 16 83 3.1.4. UPDATE.cell . . . . . . . . . . . . . . . . . . . . . 17 84 3.1.5. DELETE.hardcell . . . . . . . . . . . . . . . . . . . 17 85 3.1.6. DELETE.softcell . . . . . . . . . . . . . . . . . . . 18 86 3.1.7. REALLOCATE.softcell . . . . . . . . . . . . . . . . . 19 87 3.2. Slotframe Commands . . . . . . . . . . . . . . . . . . . 19 88 3.2.1. CREATE.slotframe . . . . . . . . . . . . . . . . . . 19 89 3.2.2. READ.slotframe . . . . . . . . . . . . . . . . . . . 20 90 3.2.3. UPDATE.slotframe . . . . . . . . . . . . . . . . . . 20 91 3.2.4. DELETE.slotframe . . . . . . . . . . . . . . . . . . 21 92 3.3. Monitoring Commands . . . . . . . . . . . . . . . . . . . 22 93 3.3.1. CONFIGURE.monitoring . . . . . . . . . . . . . . . . 22 94 3.3.2. READ.monitoring.status . . . . . . . . . . . . . . . 22 95 3.4. Statistics Commands . . . . . . . . . . . . . . . . . . . 23 96 3.4.1. CONFIGURE.statistics . . . . . . . . . . . . . . . . 23 97 3.4.2. READ.statistics . . . . . . . . . . . . . . . . . . . 23 98 3.4.3. RESET.statistics . . . . . . . . . . . . . . . . . . 24 99 3.5. Network Formation Commands . . . . . . . . . . . . . . . 24 100 3.5.1. CONFIGURE.eb . . . . . . . . . . . . . . . . . . . . 25 101 3.5.2. READ.eb . . . . . . . . . . . . . . . . . . . . . . . 25 102 3.6. Time Source Neighbor Commands . . . . . . . . . . . . . . 26 103 3.6.1. CONFIGURE.timesource . . . . . . . . . . . . . . . . 26 104 3.6.2. READ.timesource . . . . . . . . . . . . . . . . . . . 26 105 3.7. Neighbor Commands . . . . . . . . . . . . . . . . . . . . 26 106 3.7.1. CREATE.neighbor . . . . . . . . . . . . . . . . . . . 27 107 3.7.2. READ.all.neighbor . . . . . . . . . . . . . . . . . . 27 108 3.7.3. READ.neighbor . . . . . . . . . . . . . . . . . . . . 27 109 3.7.4. UPDATE.neighbor . . . . . . . . . . . . . . . . . . . 27 110 3.7.5. DELETE.neighbor . . . . . . . . . . . . . . . . . . . 28 111 3.8. Queueing Commands . . . . . . . . . . . . . . . . . . . . 28 112 3.8.1. CREATE.queue . . . . . . . . . . . . . . . . . . . . 28 113 3.8.2. READ.queue . . . . . . . . . . . . . . . . . . . . . 28 114 3.8.3. READ.queue.stats . . . . . . . . . . . . . . . . . . 29 115 3.8.4. UPDATE.queue . . . . . . . . . . . . . . . . . . . . 29 116 3.8.5. DELETE.queue . . . . . . . . . . . . . . . . . . . . 30 117 3.9. Label Switching Commands . . . . . . . . . . . . . . . . 30 118 3.9.1. LabelSwitching.map . . . . . . . . . . . . . . . . . 30 119 3.9.2. LabelSwitching.unmap . . . . . . . . . . . . . . . . 30 120 3.10. Chunk Command . . . . . . . . . . . . . . . . . . . . . . 31 121 3.10.1. Create.chunk . . . . . . . . . . . . . . . . . . . . 31 122 3.10.2. READ.chunk . . . . . . . . . . . . . . . . . . . . . 31 123 3.10.3. Delete.chunk . . . . . . . . . . . . . . . . . . . . 32 124 3.11. Chunk Cell Command . . . . . . . . . . . . . . . . . . . 32 125 3.11.1. CREATE.hardcell.fromchunk . . . . . . . . . . . . . 32 126 3.11.2. READ.chunkcell . . . . . . . . . . . . . . . . . . . 33 127 3.11.3. DELETE.hardcell.fromchunk . . . . . . . . . . . . . 33 128 3.12. Data Commands . . . . . . . . . . . . . . . . . . . . . . 34 129 3.12.1. Send.data . . . . . . . . . . . . . . . . . . . . . 34 130 3.12.2. Receive.data . . . . . . . . . . . . . . . . . . . . 34 131 4. 6top Communication Protocol . . . . . . . . . . . . . . . . . 35 132 4.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 35 133 4.1.1. Information Elements . . . . . . . . . . . . . . . . 35 134 4.1.2. Packet Formats . . . . . . . . . . . . . . . . . . . 43 135 4.2. Time Sequences . . . . . . . . . . . . . . . . . . . . . 48 136 4.2.1. Network Formation . . . . . . . . . . . . . . . . . . 49 137 4.2.2. Creating soft cells . . . . . . . . . . . . . . . . . 50 138 4.2.3. Deleting soft cells . . . . . . . . . . . . . . . . . 51 139 4.2.4. Maintaining soft cells . . . . . . . . . . . . . . . 51 140 4.2.5. Creating hard cells . . . . . . . . . . . . . . . . . 51 141 4.2.6. Deleting hard cells . . . . . . . . . . . . . . . . . 52 142 5. Statistics . . . . . . . . . . . . . . . . . . . . . . . . . 52 143 5.1. Statistics Metrics . . . . . . . . . . . . . . . . . . . 52 144 5.2. Statistics Configuration . . . . . . . . . . . . . . . . 53 145 6. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 53 146 6.1. Monitor Configuration . . . . . . . . . . . . . . . . . . 53 147 6.2. Actuation . . . . . . . . . . . . . . . . . . . . . . . . 54 148 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 149 7.1. Normative References . . . . . . . . . . . . . . . . . . 54 150 7.2. Informative References . . . . . . . . . . . . . . . . . 54 151 7.3. External Informative References . . . . . . . . . . . . . 55 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 154 1. Introduction 156 As presented in [I-D.ietf-6tisch-tsch], the [IEEE802154e] standard 157 defines the mechanisms for a TSCH node to communicate, given a 158 schedule. It does not, however, define the mechanism to build and 159 maintain the TSCH schedule, match that schedule to the multi-hop 160 paths maintained by a network layer such as RPL or a 2.5 layer such 161 as GMPLS, adapt the resources allocated between neighbor nodes to the 162 data traffic flows, enforce a differentiated treatment for data 163 generated at the application layer and signalling messages needed by 164 6LoWPAN and RPL to discover neighbors, react to topology changes, 165 self-configure IP addresses, or manage keying material. 167 In a TSCH network, the MAC layer is not in charge of setting up the 168 schedule that controls the connectivity graph of the network and the 169 resources allocated to each node in that topology. This 170 responsibility is left to the next-higher layer, defined in this 171 document, called "6top". 173 This document describes the 6TiSCH Operation Sublayer (6top) and the 174 main commands provided to upper network layers such as RPL or GMPLS. 175 The set of functionalities include feedback metrics from cell state 176 so the network layer can take routing decisions, TSCH configuration 177 and control procedures, and support for the different scheduling 178 mechanisms defined in [I-D.ietf-6tisch-architecture]. 6top addresses 179 the set of functionalities described in [I-D.ietf-6tisch-tsch]. 181 For example, network formation in a TSCH network involves the 182 transmission of Enhanced Beacons (EB). EBs include information for 183 joining nodes to be able to synchronize and set up an initial network 184 topology. However, [IEEE802154e] does not specify how the period of 185 EBs is configured, nor the rules for a node to select a particular 186 node to join. 6top offers a set of commands so control mechanisms can 187 be introduced on top of TSCH to configure nodes to join a specific 188 node. Once a network is formed, 6top maintains the network's health, 189 allowing for nodes to stay synchronized. It supplies mechanisms to 190 manage each node's time source neighbor and configure the EB 191 interval. Network layers running on top of 6top take advantage of 192 the TSCH MAC layer information so routing metrics, topological 193 information, energy consumption and latency requirements can be 194 adjusted to TSCH, and adapted to application requirements. 196 TSCH requires a mechanism to manage its schedule; 6top provides a set 197 of commands for upper layers to set up specific schedules, either 198 explicitly by detailing specific cell information, or by allowing 199 6top to establish a schedule given a bandwidth or latency 200 requirement. 6top is designed to enable decentralized, centralized or 201 hybrid scheduling solutions. 6top enables internal TSCH queuing 202 configuration, size of buffers, packet priorities, transmission 203 failure behavior, and defines mechanisms to encrypt and authenticate 204 MAC slotframes. 206 As described in [label-switching-154e], due to the slotted nature of 207 a TSCH network, it is possible to use a label switched architecture 208 on top of TSCH cells. As a cell belongs to a specific track, a label 209 header is not needed at each packet; the input cell (or bundle) and 210 the output cell (or bundle) uniquely identify the data flow. The 211 6top sublayer provides operations to manage the cell mappings. 213 2. 6TiSCH Operation Sublayer (6top) Overview 215 6top is a sublayer which is the next-higher layer for TSCH 216 (Figure 1), which architecture is detailed in 217 [I-D.ietf-6tisch-architecture], and generaic data model is detailed 218 in [I-D.ietf-6tisch-6top-interface]. 6top offers both management and 219 data interfaces to an upper layer. It includes monitoring and 220 statistics collection, both of which are configurable through the 221 management interface. 223 Protocol Stack 225 +-----------------------------------+ 226 | PCEP | CoAP | | 6LoWPAN | | 227 | PCC | DTLS | PANA | ND |RPL | 228 +------------------------------------------+ 229 | TCP | UDP | ICMP | RSVP | 230 +------------------------------------------+ 231 | IPv6 | 232 +------------------------------------------+ 233 | 6LoWPAN HC | 234 +------------------------------------------+ 235 | 6top | 236 +------------------------------------------+ 237 | IEEE802.15.4e TSCH | 238 +------------------------------------------+ 239 | IEEE802.15.4 | 240 +------------------------------------------+ 242 Figure 1 244 6top distinguishes between hard cells and soft cells. It therefore 245 requires an extra flag to all cells in the TSCH schedule, as detailed 246 in Section 2.1. 248 When a higher layer gives 6top a 6LoWPAN packet for transmission, 249 6top maps it to the appropriate outgoing priority-based queue, as 250 detailed in Section 2.2. 252 All 6top commands of the management and data interfaces are detailed 253 in Section 3. This set of commands is designed to support 254 decentralized, centralized and hybrid scheduling solutions. They 255 form a conceptual interface an upper layer can use; implementations 256 can use this set of commands, or any equivalent alternative. 258 6top defines TSCH Information Elements (IEs) for neighbors nodes to 259 negotiate scheduling cells in the TSCH schedule. The format of those 260 IEs is given in Section 4.1. Example data exchanges between neighbor 261 nodes are given in Section 4.2. 263 Section 5 defines how 6top gathers statistics (e.g. link quality, 264 energy level, queue usage), and what commands an upper layer can use 265 to configure and retrieve those statistics. 267 6top can be configured to monitor the cells it has scheduled in order 268 to detect cells with poor performance. It can automatically re- 269 allocate those cells inside the TSCH schedule. This behavior is 270 described in Section 6 272 2.1. Cell Model 274 [IEEE802154e] defines a set of options attached to each cell. A cell 275 can be a Transmit cell, a Receive cell, a Shared cell or a 276 Timekeeping cell. These options are not exclusive, as a cell can be 277 qualified with more than one of them. The MLME-SET-LINK.request 278 command defined in [IEEE802154e] uses a linkOptions bitmap to specify 279 the options of a cell. Acceptable values are: 281 b0 = Transmit 283 b1 = Receive 285 b2 = Shared 287 b3 = Timekeeping 289 b4-b7 = Reserved 291 Only Transmit cells can also be marked as Shared cells. When the 292 shared bit is set, a back-off procedure is applied to handle 293 collisions. Shared behavior does not apply to Receive cells. 295 6top allows an upper layer to schedule a cell at a specific 296 slotOffset and channelOffset, in a specific slotframe. 298 In addition, 6top allows an upper layer to schedule a certain amount 299 of bandwidth to a neighbor, without having to specify the exact 300 slotOffset and channelOffset of the corresponding cell(s). Once 301 bandwidth is reserved, 6top is in charge of ensuring that this 302 requirement is continuously satisfied. 6top dynamically reallocates 303 cells if needed, and over-provisions if required. 305 6top allows an upper layer to associate a cell with a specific track 306 by using a TrackID. A TrackID is a tuple 307 (TrackOwnerAddr,InstanceID). TrackOwnerAddr is the address of the 308 node which initiates the process of creating the track, i.e. the 309 owner of the track. InstanceID is an instance identifier given by 310 the owner of the track. InstanceID comes from the upper layer; it 311 could for example be the local instance ID defined in RPL. 313 If the TrackID is set to (0,0), the cell can be used by the best- 314 effort QoS configuration or as a Shared cell. If the TrackID is not 315 set to (0,0), i.e. the cell belongs to a specific track, the cell 316 MUST not be set as Shared cell. 318 6top allows an upper layer to ask a node to manage a portion of a 319 slotframe, called a chunk. Chunks can be delegated explicitly by the 320 PCE to a node, or claimed automatically by any node that participates 321 to the distributed cell scheduling process. The cells in a chunk can 322 be appropriated by the node, i.e. the node is in charge of managing 323 the chunk. 325 Given this mechanism, 6top defines hard cells (which have been 326 requested specifically) and soft cells (which can be reallocated 327 dynamically). The hard/soft flag is introduced by the 6top sublayer 328 named as CellType (0: soft cell, 1: hard cell). This option is 329 mandatory; all cells are either hard or soft. 331 2.1.1. hard cells 333 A hard cell is a cell that cannot be dynamically reallocated by 6top. 334 A hard cell is uniquely identified by the following tuple: 336 slotframe ID: ID of the slotframe this cell is part of. 338 slotOffset: the slotOffset for the cell. 340 channelOffset: the channelOffset for the cell. 342 LinkOption bitmap: bitmap as defined in [IEEE802154]. 344 CellType: MUST be set to 1. 346 2.1.2. soft cells 348 A soft cell is a cell that can be reallocated by 6top dynamically. 349 The CellType MUST be set to 0. This cell is installed by 6top given 350 a specific bandwidth requirement. Soft cells are installed through 351 the soft cell negotiation procedure described in Section 4.2. 353 2.2. Data Transfer Model 355 The TSCH MAC layer is decoupled from the upper layer; the interaction 356 between the upper layer and TSCH is asynchronous. This means that 357 the MAC layer executes a schedule and checks at each timeslot 358 according to the type of cell(i.e Transmit, Shared or Receive), 359 whether there is something to send or receive. If that is the case, 360 the packet is transmitted and the MAC layer continues its operation. 361 When an upper layer sends a packet, this packet is pushed into a 362 queue waiting for the MAC layer to read it and send it in a 363 particular timeslot according to its destination and priority. 6top 364 provides a set of queue management operations which enable upper 365 layers to create different queues and set their priorities. This 366 allows different classes of traffic to be handled by the forwarding 367 plane by inserting a packet into the queue appropriate for its 368 priority. 370 A 6top implementation MUST provide at least a Broadcast Queue and a 371 Transmit Queue. The Broadcast Queue is associated with cells with 372 LinkType=ADVERTISING in the sender's schedule, and 373 LinkOption="Receive" and "Timekeeping" in all its neighbors' 374 schedule. For example, NodeA uses slotOffset=5 and channelOffset=12 375 as Broadcast cell to its neighbors NodeB and NodeC. Then, in the 376 schedule of NodeA the cell will be featured with neighbor address is 377 Broadcast address, LinkType=ADVERTISING; and in the schedules of both 378 nodeB and nodeC the cell will be featured with nodeA address as 379 neighbor address, and LinkOption="Receive" and "Timekeeping", which 380 ensure nodeB and nodeC will be active at least one time in the cell 381 to receive broadcast packet during a Timekeeping period. A Transmit 382 Queue is associated with the dedicated Transmit cells or Shared 383 Cells. 385 Data Communication Commands (Section 3.12) can be used to send 386 control messages and data messages. The operation is used to insert 387 a message into a specific queue. 389 For example, a configuration can include two Broadcast Queues with 390 priority High and Low, and three Transmit Queues with priority High, 391 Mid, and Low. 393 When DestAddr is the broadcast address, its related MAC layer packets 394 will be pushed into the Broadcast Queue with the corresponding 395 priority. 6top is responsible for feeding these packets into 396 broadcast cells. 398 When DestAddr is a unicast address, its related MAC layer packets 399 will be pushed into the Transmit Queue with the corresponding 400 priority. 6top is responsible for feeding these packets into Transmit 401 or Shared Cells. 403 The QoS policy enforced by 6top is out of scope. As an example, 404 packets in higher priority queues could be transmitted before the 405 packets in lower priority queue. As a result, when there is an 406 available broadcast/unicast cell, 6top checks the broadcast/unicast 407 queue with higher priority first. 6top continues this search until it 408 finds a broadcast/unicast packet, or finds that all of broadcast/ 409 unicast queues are empty. 411 Figure 2 shows how 6top shapes data from the upper layer (e.g., RPL, 412 6LoWPAN), and feeds it to TSCH. The properties associated with a 413 packet/fragment from the upper layer includes the next hop neighbor 414 (DestAddr), the packet priority, and TrackID(s). 416 6top Data Transfer Model 418 | 419 | (DestAddr, Priority, Fragment) 420 | 421 +---------------------------------------+ 422 | I-MUX | 423 +---------------------------------------+ 424 | | | | | 425 | | | | | 426 +---+ +---+ +---+ +---+ +---+ 427 | | | | | | | | | | 428 |Q1 | |Q2 | |Q3 | |Q4 | ... |Qn | 429 | | | | | | | | | | 430 +---+ +---+ +---+ +---+ +---+ 431 | | | | | 432 | | | | | 433 +---------------------------------------+ 434 | MUX | 435 +---------------------------------------+ 436 | 437 | 438 +---+ 439 |PDU| 440 +---+ 441 | 442 | TSCH MAC-payload 443 | 445 Figure 2 447 In Figure 2, Qi represents a queue, which is either broadcast or 448 unicast, and is assigned a priority. The number of queues is 449 configurable. The relationship between queues and tracks is 450 configurable. For example, for a given queue, only one specific 451 track can be used, all of the tracks can be used, or a subset of the 452 tracks can be used. 454 When 6top receives a packet to transmit through a Send.data command 455 (Section 3.12), the I-MUX module selects a queue in which to insert 456 it. If the packet's destination address is a unicast (resp. 457 broadcast) address, it is inserted into a unicast (resp. broadcast) 458 queue. 460 The MUX module is invoked at each scheduled transmit cell by TSCH. 461 When invoked, the MUX module goes through the queues, looking for the 462 best matching frame to send. If it finds a frame, it hands it over 463 to TSCH for transmission. If the next active cell is a broadcast 464 cell, it selects a fragment only from broadcast queues. 466 How the MUX module selects the best frame is configurable. The 467 following rules are a typical example: 469 The frame's layer 2 destination address MUST match the neighbor 470 address associated with the transmit cell. 472 If the transmit cell is associated with a specific track, the 473 frames in the queue corresponding to the TrackID have the 474 highest priority. 476 If the transmit cell is not associated with a specific track, 477 i.e., TrackID=(0,0), frames from a queue with a higher priority 478 MUST be sent before frames from a queue with a lower priority. 480 Further rules can be configured to satisfy specific QoS requirements. 482 3. 6top Commands 484 6top provides a set of commands as the interface with the higher 485 layer. Most of these commands are related to the configuration of 486 slotframes, cells and scheduling information. 6top also provides an 487 interface allowing an upper layer to retrieve status information and 488 statistics. The management commands provided by 6top are listed 489 below. Note that this set defines a conceptual interface only; an 490 implementation can choose to use this exact set of commands, or any 491 equivalent alternative. 493 CREATE.hardcell: Section 3.1.1 495 CREATE.softcell: Section 3.1.2 497 READ.cell: Section 3.1.3 499 UPDATE.cell: Section 3.1.4 501 DELETE.hardcell: Section 3.1.5 503 DELETE.softcell: Section 3.1.6 505 REALLOCATE.softcell: Section 3.1.7 507 CREATE.slotframe: Section 3.2.1 509 READ.slotframe: Section 3.2.2 510 UPDATE.slotframe: Section 3.2.3 512 DELETE.slotframe: Section 3.2.4 514 CONFIGURE.monitoring: Section 3.3.1 516 READ.monitoring: Section 3.3.2 518 CONFIGURE.statistics: Section 3.4.1 520 READ.statistics: Section 3.4.2 522 RESET.statistics: Section 3.4.3 524 CONFIGURE.eb: Section 3.5.1 526 READ.eb: Section 3.5.2 528 CONFIGURE.timesource: Section 3.6.1 530 READ.timesource: Section 3.6.2 532 CREATE.neighbor: Section 3.7.1 534 READ.all.neighbor: Section 3.7.2 536 READ.neighbor: Section 3.7.3 538 UPDATE.neighbor: Section 3.7.4 540 DELETE.neighbor: Section 3.7.5 542 CREATE.queue: Section 3.8.1 544 READ.queue: Section 3.8.2 546 READ.queue.stats: Section 3.8.3 548 UPDATE.queue: Section 3.8.4 550 DELETE.queue: Section 3.8.5 552 LabelSwitching.map: Section 3.9.1 554 LabelSwitching.unmap: Section 3.9.2 556 CREATE.chunk: Section 3.10.1 557 READ.chunk: Section 3.10.2 559 DELETE.chunk: Section 3.10.3 561 CREATE.hardcell.fromchunk: Section 3.11.1 563 READ.chunkcell: Section 3.11.2 565 DELETE.hardcell.fromchunk: Section 3.11.3 567 Besides management commands, 6top provides the following data 568 commands: 570 Send.data: Section 3.12.1 572 Receive.data: Section 3.12.2 574 In addition, 6top offers a delegation interface allowing an upper 575 layer to configure TSCH. 6top only delegates the functionalities to 576 the MAC security services. In other words, 6top allows an upper 577 layer to access the security PIB (Table 60, Table 61, Table 63 in 578 [IEEE802154]) by using MLME-GET/MLME-SET primitives defined in 579 [IEEE802154]. 581 3.1. Cell Commands 583 6top provides the following commands to manage TSCH cells. 585 3.1.1. CREATE.hardcell 587 Creates one or more hard cells in the schedule. Fails if the cell 588 already exists. A cell is uniquely identified by the tuple 589 (slotframe ID, slotOffset, channelOffset). 591 To create a hard cell, the upper layer specifies: 593 slotframe ID: ID of the slotframe this timeslot will be 594 scheduled in. 596 slotOffset: the slotOffset for the cell. 598 channelOffset: channelOffset for the cell. 600 LinkOption bitmap: bitmap as defined in [IEEE802154e] 602 LinkType : as defined in section 6.2.19.3 of [IEEE802154e]. 604 CellType: as defined in Section 2.1 605 target node address: the address of that node to communicate 606 with over this cell. In case of broadcast cells this is the 607 broadcast address. 609 TrackID: ID of the track the cell will belong to. 611 6top schedules the cell and marks it as a hard cell, indicating that 612 it cannot reschedule this cell. The return value is CellID and the 613 created cell is also filled in CellList 614 ([I-D.ietf-6tisch-6top-interface]). 616 The interaction between 6top and MAC layer caused by CREATE.hardcell 617 is as follows. 619 Firstly, 6top calls the primitive MLME-SET-LINK.request defined in 620 section 6.2.19.3 of [IEEE802154e]. The primitive parameters are set 621 as follows. 623 +---------------------------------+---------------------------------+ 624 | MLME-SET-LINK.request parameter | set by 6top | 625 +---------------------------------+---------------------------------+ 626 | operation | ADD-LINK | 627 +---------------------------------+---------------------------------+ 628 | LinkHandle | CellID | 629 +---------------------------------+---------------------------------+ 630 | slotframeHandle | slotframe ID | 631 +---------------------------------+---------------------------------+ 632 | timeslot | slotOffset | 633 +---------------------------------+---------------------------------+ 634 | channelOffset | channelOffset | 635 +---------------------------------+---------------------------------+ 636 | LinkOptions | LinkOption bitmap | 637 +---------------------------------+---------------------------------+ 638 | LinkType | LinkType | 639 +---------------------------------+---------------------------------+ 640 | nodeAddr | target node address | 641 +---------------------------------+---------------------------------+ 643 Secondly, if the status from MLME-SET-LINK.confirm defined in section 644 6.2.19.4 of [IEEE802154e] is SUCCESS, then add the LinkHandle to the 645 BundleList specified by TrackID, and confirm to upper layer with 646 status = SUCCESS; otherwise, confirm to upper layer with status = 647 FAIL. 649 3.1.2. CREATE.softcell 651 To create soft cell(s), the upper layer specifies: 653 slotframe ID: ID of the slotframe the cell(s) will be scheduled 654 in 656 number of cells: the required number of soft cells. 658 LinkOption bitmap: bitmap as defined in [IEEE802154e] 660 CellType: as defined in Section 2.1 662 target node address: the address of the node to communicate 663 with over the cell(s). In case of broadcast cells this is the 664 broadcast address. 666 TrackID: ID of the track the cell(s) will belong to. 668 QoS level: the cell redundancy policy. The policy can be for 669 example STRICT, BEST_EFFORT, etc. 671 6top is responsible for picking the exact slotOffset and 672 channelOffset in the schedule, and ensure that the target node choose 673 the same cell and TrackID. 6top marks these cells as soft cell, 674 indicating that it will continuously monitor their performance and 675 reschedule if needed. The return value is CellID, and the created 676 cell is also filled in CellList ([I-D.ietf-6tisch-6top-interface]). 678 6top deals with the allocation process by negotiation with the target 679 node. The command returns the number and the list of created cells 680 defined by (slotframe ID, slotOffset, channelOffset). The number of 681 crated cells is less than the required number of cells if the 682 required number of cells is higher than the available number of cells 683 in the schedule. The number of created cells equals to zero if the 684 negotiation with the target node fails. The number of created cells 685 equals to zero if the CellType bitmap indicates that the cell(s) MUST 686 be Hard. 688 The interaction between 6top and TSCH happens on both sides described 689 as follows. 691 For example, after negotiation, node A and node B find a specific 692 cell, slotOffset=10, channelOffset=12, as a Tx cell and Rx cell, 693 respectively, then the 6top in node A and node B will call the 694 primitive MLME-SET-LINK.request defined in section 6.2.19.3 of 695 [IEEE802154e], respectively. The primitive parameters are set in 696 node A and node B as follows. 698 +---------------------------------+---------------------------------+ 699 | MLME-SET-LINK.request parameter | set by A's 6top | set by B's top| 700 +---------------------------------+---------------------------------+ 701 | operation | ADD-LINK | ADD-LINK | 702 +---------------------------------+---------------------------------+ 703 | LinkHandle | CellID | CellID | 704 +---------------------------------+---------------------------------+ 705 | slotframeHandle | slotframe ID | slotframe ID | 706 +---------------------------------+---------------------------------+ 707 | timeslot | 10 | 10 | 708 +---------------------------------+---------------------------------+ 709 | channelOffset | 12 | 12 | 710 +---------------------------------+---------------------------------+ 711 | LinkOptions | Tx | Rx | 712 +---------------------------------+---------------------------------+ 713 | LinkType | NORMAL | NORMAL | 714 +---------------------------------+---------------------------------+ 715 | nodeAddr | Node A | Node B | 716 +---------------------------------+---------------------------------+ 718 If the Status from MLME-SET-LINK.confirm defined in section 6.2.19.4 719 of [IEEE802154e], 6top will notify upper layer failure. 721 3.1.3. READ.cell 723 Given a (slotframe ID, slotOffset, channelOffset), retrieves the cell 724 information. Fails if the cell does not exist. The returned 725 information contains: 727 slotframe ID: ID of the slotframe where this cell is installed. 729 slotOffset: the slotOffset for the cell. 731 channelOffset: the selected channelOffset for the cell. 733 LinkOption bitmap: bitmap as defined in [IEEE802154e] 735 CellType: as defined in Section 2.1 737 target node address: the target address of that cell. In case 738 of broadcast cells this is the broadcast address. 740 TrackID: ID of the track the cell will belong to. 742 NumOfStatistics: Number of elements in the following list of 743 tuple (StatisticsMetriceID and StatisticsValue) 744 list of (StatisticsMetriceID, StatisticsValue): 745 StatisticsMetriceID is the index to Statistics Metric defined 746 in Section 3.4, StatisticsValue is the value corresponding to 747 the metric indexed by StatisticsMetriceID 749 A read command can be issued for any cell, hard or soft. 6top gets 750 cell information from CellList ([I-D.ietf-6tisch-6top-interface]). 752 3.1.4. UPDATE.cell 754 Update a hard cell, i.e., re-allocate it to a different slotOffset 755 and/or channelOffset. Fails if the cell does not exist. Requires 756 both old (slotframe ID, slotOffset, channelOffset) and new (slotframe 757 ID, slotOffset, channelOffset) as parameters. And, the type of cell, 758 target node address and TrackID are the fields that cannot be 759 updated. Soft cells MUST NOT be updated by the UPDATE.cell command. 760 REALLOCATE.softcell (Section 3.1.7) MUST be used instead. 762 It causes a old cell being removed and a new cell being created. 764 3.1.5. DELETE.hardcell 766 To remove a hard cell, the upper layer specifies: 768 slotframe ID: the ID of the slotframe where this cell is 769 installed. 771 slotOffset: the slotOffset for the cell. 773 channelOffset: the selected channelOffset for the cell. 775 LinkOption bitmap: bitmap as defined in [IEEE802154e] 777 LinkType : as defined in section 6.2.19.3 of [IEEE802154e]. 779 CellType: as defined in Section 2.1 781 target node address: the target address of that cell. In case 782 of broadcast cells this is the broadcast address. 784 TrackID: ID of the track the cell will belong to. 786 This removes the hard cell from the node's schedule, from CellList 787 ([I-D.ietf-6tisch-6top-interface])as well. 789 The interaction between 6top and MAC layer caused by DELETE.hardcell 790 is as follows. 792 Firstly, 6top calls the primitive MLME-SET-LINK.request defined in 793 section 6.2.19.3 of [IEEE802154e]. The primitive parameters are set 794 as follows. 796 +---------------------------------+---------------------------------+ 797 | MLME-SET-LINK.request parameter | set by 6top | 798 +---------------------------------+---------------------------------+ 799 | operation | DELETE-LINK | 800 +---------------------------------+---------------------------------+ 801 | LinkHandle | CellID | 802 +---------------------------------+---------------------------------+ 803 | slotframeHandle | slotframe ID | 804 +---------------------------------+---------------------------------+ 805 | timeslot | slotOffset | 806 +---------------------------------+---------------------------------+ 807 | channelOffset | channelOffset | 808 +---------------------------------+---------------------------------+ 809 | LinkOptions | LinkOption bitmap | 810 +---------------------------------+---------------------------------+ 811 | LinkType | LinkType | 812 +---------------------------------+---------------------------------+ 813 | nodeAddr | target node address | 814 +---------------------------------+---------------------------------+ 816 Secondly, if the status from MLME-SET-LINK.confirm defined in section 817 6.2.19.4 of [IEEE802154e] is SUCCESS, then remove the LinkHandle from 818 its BundleList specified by TrackID, and confirm to upper layer with 819 status = SUCCESS; otherwise, confirm to upper layer with status = 820 FAIL. 822 3.1.6. DELETE.softcell 824 To remove a (number of) soft cell(s), the upper layer specifies: 826 slotframe ID: ID of the slotframe where this cell is installed. 828 number of cells: the number of cells to be removed 830 LinkOption bitmap: bitmap as defined in [IEEE802154e] 832 CellType: as defined in Section 2.1 834 target node address: the target address of that cell. In case 835 of broadcast cells this is the broadcast address. 837 TrackID: ID of the track the cell will belong to. 839 In the case a soft cell wants to be re-allocated from the allocated 840 cell so a hard cell can be installed instead, the REALLOCATE.softcell 841 (Section 3.1.7) MUST be used. 843 After the pair of nodes figure out the specific cell(s) to be 844 removed, the interaction between 6top and TSCH on both sides will be 845 similar to that caused by DELETE.hardcell, except LinkType should be 846 set to NORMAL. 848 3.1.7. REALLOCATE.softcell 850 To force a re-allocation of a soft cell, the upper layer specifies: 852 slotframe ID: ID of the slotframe where the cell is allocated. 854 slotOffset: the slotOffset for that cell. 856 channelOffset: the channelOffset for that cell. 858 The reallocated cell will be installed in a different slotOffset, 859 channelOffset but slotframe and TrackID remain the same. Hard cells 860 MUST NOT be reallocated. 862 The interaction between 6top and TSCH caused by this command includes 863 that described in Section 3.1.6 and Section 3.1.2. 865 3.2. Slotframe Commands 867 6top provides the following commands to manage TSCH slotframes. 869 3.2.1. CREATE.slotframe 871 Creates a new slotframe. The command requires: 873 slotframe ID: unique identifier of the slotframe, corresponding 874 to its priority. 876 number of timeslots: the required number of timeslots in the 877 slotframe. 879 Fails if the number of required timeslots is less than zero. 881 The interaction between 6top and MAC layer caused by CREATE.slotframe 882 is as follows. 884 Firstly, 6top calls the primitive MLME-SET-SLOTFRAME.request defined 885 in section 6.2.19.1 of [IEEE802154e]. The primitive parameters are 886 set as follows. 888 +---------------------------------+---------------------------------+ 889 | MLME-SET-SLOTFRAME.request | | 890 | parameter | set by 6top | 891 +---------------------------------+---------------------------------+ 892 | slotframeHandle | slotframe ID | 893 +---------------------------------+---------------------------------+ 894 | operation | ADD | 895 +---------------------------------+---------------------------------+ 896 | size | number of timeslot | 897 +---------------------------------+---------------------------------+ 899 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 900 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 901 layer with status = SUCCESS; otherwise, confirm to upper layer with 902 status = FAIL. 904 3.2.2. READ.slotframe 906 Returns the information of a slotframe given its slotframe ID. The 907 command returns: 909 slotframe ID: ID of the slotframe. (SlotFrameHandle) 911 number of timeslots: the number of timeslots in the slotframe. 913 Fails if the slotframe ID does not exist. 915 3.2.3. UPDATE.slotframe 917 Change the number of timeslots in a slotframe. The command requires: 919 slotframe ID: ID of the slotframe. 921 number of timeslots: the number of timeslots to be updated. 923 Fails if the number of required timeslots is less than zero. Fails 924 if the slotframe ID does not exist. 926 The interaction between 6top and MAC layer caused by UPDATE.slotframe 927 is as follows. 929 Firstly, 6top calls the primitive MLME-SET-SLOTFRAME.request defined 930 in section 6.2.19.1 of [IEEE802154e]. The primitive parameters are 931 set as follows. 933 +---------------------------------+---------------------------------+ 934 | MLME-SET-SLOTFRAME.request | | 935 | parameter | set by 6top | 936 +---------------------------------+---------------------------------+ 937 | slotframeHandle | slotframe ID | 938 +---------------------------------+---------------------------------+ 939 | operation | MODIFY | 940 +---------------------------------+---------------------------------+ 941 | size | number of timeslot | 942 +---------------------------------+---------------------------------+ 944 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 945 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 946 layer with status = SUCCESS; otherwise, confirm to upper layer with 947 status = FAIL. 949 3.2.4. DELETE.slotframe 951 Deletes a slotframe. The command requires: 953 slotframe ID: ID of the slotframe. 955 number of timeslot: the number of timeslots in the slotframe. 957 Fails if the slotframe ID does not exist. 959 The interaction between 6top and MAC layer caused by DELETE.slotframe 960 is as follows. 962 Firstly, 6top calls the primitive MLME-SET-SLOTFRAME.request defined 963 in section 6.2.19.1 of [IEEE802154e]. The primitive parameters are 964 set as follows. 966 +---------------------------------+---------------------------------+ 967 | MLME-SET-SLOTFRAME.request | | 968 | parameter | set by 6top | 969 +---------------------------------+---------------------------------+ 970 | slotframeHandle | slotframe ID | 971 +---------------------------------+---------------------------------+ 972 | operation | DELETE | 973 +---------------------------------+---------------------------------+ 974 | size | number of timeslot | 975 +---------------------------------+---------------------------------+ 977 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 978 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 979 layer with status = SUCCESS; otherwise, confirm to upper layer with 980 status = FAIL. 982 3.3. Monitoring Commands 984 Monitoring commands provide the means for upper layers to configure 985 whether 6top must ensure the required bandwidth. This procedure is 986 achieved through overprovisioning according to cell status feedback. 987 Monitoring is also in charge of reallocating soft cells that are 988 under the required QoS. 990 3.3.1. CONFIGURE.monitoring 992 Configures the level of QoS the Monitoring process MUST enforce. The 993 command requires: 995 slotframe ID: ID of the slotframe. 997 target node address: the target neighbor address. 999 enforce policy: The policy used to enforce the QoS 1000 requirements. Can be for example DISABLE, BEST_EFFORT, STRICT, 1001 OVER-PROVISION, etc. 1003 Fails if the slotframe ID does not exist. 1005 3.3.2. READ.monitoring.status 1007 Reads the current Monitoring status. Requires the following 1008 parameters. 1010 slotframe ID: the ID of the slotframe. 1012 target node address: the target neighbor address. 1014 Returns the QoS levels for that Target node on that slotframe. 1016 allocated_hard: Number of hard cells allocated. 1018 allocated_soft: Number of soft cells allocated. 1020 provisioned: the extra provisioned cells. 0 if CONFIGURE.qos 1021 enforce is DISABLE. 1023 QoS: the current QoS. Including overprovisioned cells, i.e 1024 what bandwidth is being obtained including the overprovisioned 1025 cells. 1027 RQoS: the real QoS without provisioned cells. What is the 1028 actual bandwidth without taking into account the 1029 overprovisioned cells. 1031 Fails if the slotframe ID does not exist. 1033 3.4. Statistics Commands 1035 6top keeps track of TSCH statistics for upper layers to adapt 1036 correctly to medium changes. The exact metrics for statistics are 1037 out of scope but the present commands SHOULD be used to configure and 1038 read monitored information regardless of the specific metric. 1040 3.4.1. CONFIGURE.statistics 1042 Configures Statistics process. The command requires: 1044 slotframe ID: ID of the slotframe. If empty monitors all 1045 slotframe IDs 1047 slotOffset: specific slotOffset to be monitored. If empty all 1048 timeslots are monitored 1050 channelOffset: specific channelOffset to be monitored. If 1051 empty all channels are monitored. 1053 target node address: the target neighbor address. If empty, 1054 all neighbor nodes are monitored. 1056 metric: metric to be monitored. This MAY be PDR, ETX, queuing 1057 statistics, energy-related metrics, etc.) 1059 window: time window to be considered for the calculations. If 1060 0 all historical data is considered. 1062 enable: Enables statistics or disables them. 1064 Fails if the slotframe ID does not exist. The statistics service can 1065 be configured to retrieve statistics at different levels. For 1066 example to aggregate information by slotframe ID, or to retrieve 1067 statistics for a particular timeslot, etc. The CONFIGURE.statistics 1068 enables flexible configuration and supports empty parameters that 1069 will force 6top to conduct statistics on all members of that 1070 dimension. For example, if ChannelOffset is empty and metric is set 1071 as PDR, then, 6top will conduct the statistics of PDR on all of 1072 channels. 1074 3.4.2. READ.statistics 1076 Reads a metric for the specified dimension. Information is 1077 aggregated according to the parameters. The command requires: 1079 slotframe ID: ID of the slotframe. If empty aggregates 1080 information of all slotframe IDs 1082 slotOffset: the specific slotOffset for which the information 1083 is required. If empty all timeslots are aggregated 1085 channelOffset: the specific channelOffset for which the 1086 information is required. If empty all channels are aggregated. 1088 target node address: the target neighbor address. If empty all 1089 neighbor addresses are aggregated. 1091 metric: metric to be read. 1093 Returns the value for the requested metric. 1095 Fails if empty metric or metric does not exits. 1097 3.4.3. RESET.statistics 1099 Resets the gathered statistics. The command requires: 1101 slotframe ID: ID of the slotframe. If empty resets the 1102 information of all slotframe IDs 1104 slotOffset: the specific slotOffset for which the information 1105 wants to be reset. If empty statistics from all timeslots are 1106 reset 1108 channelOffset: the specific channelOffset for which the 1109 information wants to be reset. If empty all statistics for all 1110 channels are reset. 1112 target node address: the target neighbor address. If empty all 1113 neighbor addresses are aggregated. 1115 metric: metric to be reset. 1117 Fails if empty metric or metric does not exits. 1119 3.5. Network Formation Commands 1121 EBs need to be configured, including their transmission period, the 1122 slotOffset and channelOffset that they SHOULD be sent on, and the 1123 join priority they contain. The parameters for that command are 1124 optional and enable flexible configuration of EBs. If slotframe ID 1125 is specified, the EBs will be configured to use that specific 1126 slotframe; if not, they will use the first slotframe where the 1127 configured slotOffset is allocated. The slotOffset enforces the EB 1128 to a specific timeslot. In case slotOffset parameter is not present, 1129 the EB is sent in the first available transmit timeslot. In case 1130 channelOffset parameter is not set, the EB is configured to use the 1131 first available channel. 1133 3.5.1. CONFIGURE.eb 1135 Configures EBs. The command requires: 1137 slotframe ID: ID of the slotframe where the EBs MUST be sent. 1138 Zero if any slotframe can be used. 1140 slotOffset: the slotOffset where the EBs MUST be sent. Zero if 1141 any timeslot can be used. 1143 channelOffset: the channelOffset where the EBs MUST be sent. 1144 Zero if any channelOffset can be used. 1146 period: the EBs period, in seconds. 1148 Expiration: when the EBs periodicity will stop. If Zero the 1149 period never stops. 1151 priority: the joining priority model that will be used for 1152 advertisement. Joining priority MAY be for example 1153 SAME_AS_PARENT, RANDOM, BEST_PARENT+1 or DAGRANK(rank) as 1154 decribed in in [I-D.ietf-6tisch-minimal]. 1156 Fails if the tuple (slotframe ID, slotOffset, channelOffset) is 1157 already scheduled. 1159 3.5.2. READ.eb 1161 Reads the EBs configuration. No parameters are required. 1163 Returns the current EBs configuration for that slotframe, which 1164 contains: 1166 slotframe ID: the slotframe where the EB is being sent. 1168 slotOffset: the slotOffset where the EBs is being sent. 1170 channelOffset: the channelOffset the EBs is being sent on. 1172 period: the EBs period. 1174 Expiration: when the EBs periodicity stops. If 0 the period 1175 never stops. 1177 priority: the joining priority that this node advertises. 1179 Fails if the slotframe ID does not exist. 1181 3.6. Time Source Neighbor Commands 1183 Commands to select time source neighbors. 1185 3.6.1. CONFIGURE.timesource 1187 Configures the Time Source Neighbor selection process. More than one 1188 time source neighbor can be selected. The command requires: 1190 selection policy: The policy used to select the time source 1191 neighbor. The policy MAY be for example ALL_PARENTS, 1192 BEST_CONNECTED, LOWEST_JOIN_PRIORITY, etc. 1194 Fails if any of the time source neighbors do not exist or it is not 1195 reachable. 1197 3.6.2. READ.timesource 1199 Retrieves information about the time source neighbors of that node. 1200 The command does not require any parameter. 1202 Returns the following information for each of the time sources: 1204 target node: address of the time source neighbor. 1206 statistics: includes for example minimum, maximum, average time 1207 correction for that time source neighbor 1209 policy: the used policy 1211 Fails if the slotframe ID or no time source neighbors exist. 1213 3.7. Neighbor Commands 1215 Commands to manage neighbor table. The commands SHOULD be used by 1216 the upper layer to query the neighbor related information and by the 1217 lower layer to keep track of neighbors information. 1219 3.7.1. CREATE.neighbor 1221 Creates an entry for a neighbor in the neighbor table. 1223 neighbor address: The address of the neighbor. 1225 neighbor stats: for example, RSSI of the last received packet 1226 from that neighbor, ASN when that neighbor has been added, etc. 1228 Returns whether the neighbor is created or not. 1230 3.7.2. READ.all.neighbor 1232 Returns the list of neighbors of that node. Fails if empty. For 1233 each neighbor in the list it returns: 1235 neighbor address: The address of the neighbor. 1237 neighbor stats: for example, RSSI of the last received packet 1238 from that neighbor, ASN when that neighbor has been added, 1239 packets received from that neighbor, packets sent to it, etc. 1241 3.7.3. READ.neighbor 1243 Returns the information of a specific neighbor of that node specified 1244 by its neighbor address. Fails if it does not exists. For that 1245 neighbor it returns: 1247 neighbor address: The address of the neighbor. 1249 neighbor stats: for example, RSSI of the last received packet 1250 from that neighbor, ASN when that neighbor has been added, 1251 packets received from that neighbor, packets sent to it, etc. 1253 3.7.4. UPDATE.neighbor 1255 Updates an entry for a neighbor in the neighbor table. Fails if the 1256 neighbor does not exist. Updates stats parameters. Requires: 1258 neighbor address: The address of the neighbor. 1260 neighbor stats: for example, RSSI of the last received packet 1261 from that neighbor, ASN when that neighbor has been added, etc. 1263 Returns whether the neighbor is updated or not. 1265 3.7.5. DELETE.neighbor 1267 Deletes a neighbor given its address. Fails if the neighbor does not 1268 exists. 1270 3.8. Queueing Commands 1272 Queues need to be configured. This includes queue length, 1273 retransmission policy, discarding of packets, etc. 1275 3.8.1. CREATE.queue 1277 Creates and Configures Queues. The command SHOULD be applied for 1278 each required queue. The command requires: 1280 txqlength: the desired transmission queue length. 1282 rxqlength: the desired reception queue length. 1284 numrtx: number of allowed retransmissions. 1286 age: discard packet according to its age on the queue. 0 if no 1287 discards are allowed. 1289 rtxbackoff: retransmission backoff in number of slotframes. 0 1290 if next available timeslot wants to be used. 1292 statswindow: window of time used to compute statistics. 1294 queue priority: the priority of this queue. 1296 TrackIDs: a set of TrackIDs. While it is empty, no specific 1297 track is associated with the queue 1299 Returns the queue ID. 1301 3.8.2. READ.queue 1303 Reads the queue configuration. Requires the queue ID. 1305 The command returns: 1307 txqlength: the transmission queue length. 1309 rxqlength: the reception queue length. 1311 numrtx: number of allowed retransmissions. 1313 age: maximum age of a packet before being discarded. 0 if no 1314 discards are allowed. 1316 rtxbackoff: retransmission backoff in number of slotframes. 0 1317 if next available timeslot is used. 1319 3.8.3. READ.queue.stats 1321 Reads the queue stats. Requires queue ID. 1323 The command returns: 1325 txqlengthstats: average, maximum, minimum length of the 1326 transmission queue. 1328 rxqlengthstats: average, maximum, minimum length of the 1329 reception queue. 1331 numrtxstats: average, maximum, minimum number of 1332 retransmissions. 1334 agestats: average, maximum, minimum age of a packet in the 1335 queue. 1337 rtxbackoffstats: average, maximum, minimum retransmission 1338 backoff. 1340 queue priority: the priority of this queue. 1342 TrackIDs: a set of TrackIDs. 1344 3.8.4. UPDATE.queue 1346 Update a Queue. The command requires: 1348 queueid: the queue ID. 1350 txqlength: the desired transmission queue length. 1352 rxqlength: the desired reception queue length. 1354 numrtx: number of allowed retransmissions. 1356 age: discard packet according to its age on the queue. 0 if no 1357 discards are allowed. 1359 rtxbackoff: retransmission backoff in number of slotframes. 0 1360 if next available timeslot wants to be used. 1362 statswindow: window of time used to compute stats. 1364 queue priority: the desired priority of this queue. 1366 TrackIDs: the desired set of TrackIDs. 1368 3.8.5. DELETE.queue 1370 Deletes a Queue. The command requires the queue ID. All packets in 1371 the queue are discarded and the queue is deleted. 1373 3.9. Label Switching Commands 1375 6top is responsible for maintaining the mapping of input cells and 1376 output cells in the same track in a particular node. By keeping that 1377 mapping, layer 3 routing can be avoided as packets are forwarded by 1378 the 6top sublayer according to the input cells they were received on. 1379 The selected output cell is one of the cells that forward the packet 1380 to the subsequent hop in the track. 1382 3.9.1. LabelSwitching.map 1384 The command used by an upper layer to map an input cell or a bundle 1385 of input cells to an output cell or a bundle of output cells. 6top 1386 stores this mapping and makes sure that the packets are forwarded at 1387 the specific output cell/bundle. Label Switching is enabled by the 1388 specified bundle as soon as the mapping is installed. 1390 The required parameters are: 1392 input cells: list of input cells (one or more cells in a 1393 bundle). Each input cells is described by an unique tuple 1394 (slotOffset, channelOffset, destination address). 1396 output cells: list of output cells (one or more cells in a 1397 bundle). Each output cells is described by an unique tuple 1398 (slotOffset, channelOffset, destination address). 1400 load balancing policy: A policy for load balance cell usage. 1401 The policy is out of scope, however an example can be use ROUND 1402 ROBIN policy within the cells of the same bundle. 1404 3.9.2. LabelSwitching.unmap 1406 The command used by upper layers to unmap one input cell or a bundle 1407 of input cells to an output cell or a bundle of output cells. The 1408 mapping is removed from the state kept by 6top. 1410 The required parameters are: 1412 input cells: list of input cells (one or more cells in a 1413 bundle). Each input cells is described by an unique tuple 1414 (slotOffset, channelOffset, destination address). 1416 output cells: list of output cells (one or more cells in a 1417 bundle). Each output cells is described by an unique tuple 1418 (slotOffset, channelOffset, destination address). 1420 3.10. Chunk Command 1422 3.10.1. Create.chunk 1424 Create a chunk which consists of one or more unappropriated cells. 1426 To create a chunk, upper layer specifies: 1428 slotframe ID: ID of the slotframe which this chunk belongs to. 1430 ChunkSize: number of the cells which the chunk includes. 1432 SlotBase : the base slotOffset of the chunk. 1434 SlotStep : the incremental of slotOffset in the chunk. 1436 ChannelBase: the base channelOffset of the chunk. 1438 ChannelStep: the incremental of channalOffset in the chunk. 1440 ChunkID is the return value of the command 1441 ([I-D.ietf-6tisch-6top-interface]). The chunk is a set of cells in 1442 the given slotframe, consisting of (slotOffset(i),channelOffset(i)), 1443 i=0..Chunksize-1, slotOffset(i)= (slotBase + i * slotStep) % 1444 slotframeLen, channelOffset(i) = (channelBase + i * channelStep) % 1445 16". Those cells will be added into ChunkCellList 1446 ([I-D.ietf-6tisch-6top-interface]) also. 1448 3.10.2. READ.chunk 1450 Returns the information of a chunk given its ChunkId. The command 1451 returns: 1453 slotframe ID: ID of the slotframe which this chunk belongs to. 1455 ChunkSize: number of the cells which the chunk includes. 1457 SlotBase : the base slotOffset of the chunk. 1459 SlotStep : the incremental of slotOffset in the chunk. 1461 ChannelBase: the base channelOffset of the chunk. 1463 ChannelStep: the incremental of channalOffset in the chunk. 1465 Fails if the ChunkId does not exist. 1467 3.10.3. Delete.chunk 1469 To delete a chunk, upper layer specifies ChunkID. 1471 It removes the chunk from ChunkList 1472 ([I-D.ietf-6tisch-6top-interface]), and also remove those entries 1473 corresponding to the cells of the chunk from 1474 ChunkCellList([I-D.ietf-6tisch-6top-interface]). In addition, it 1475 also causes all of the scheduled cells in the chunk are deleted from 1476 CellList ([I-D.ietf-6tisch-6top-interface]) and TSCH schedule as 1477 well. 1479 3.11. Chunk Cell Command 1481 3.11.1. CREATE.hardcell.fromchunk 1483 Creates one or more hard cells from a chunk. Fails if the cell 1484 already exists. A cell is uniquely identified by the tuple 1485 (slotframe ID, slotOffset, channelOffset). 1487 To create a hard cell from a chunk which is corresponding to a 1488 specific slotframe ID, the upper layer specifies: 1490 chunkID: ID of the chunk which this cell belongs to. 1492 slotOffset: the slotOffset for the cell. 1494 channelOffset: channelOffset for the cell. 1496 LinkOption bitmap: bitmap as defined in [IEEE802154e] 1498 LinkType : as defined in section 6.2.19.3 of [IEEE802154e]. 1500 CellType: as defined in Section 2.1 1502 target node address: the address of that node to communicate 1503 with over this cell. In case of broadcast cells this is the 1504 broadcast address. 1506 TrackID: ID of the track the cell will belong to. 1508 6top schedules the cell and marks it as a hard cell, indicating that 1509 it cannot reschedule this cell. In addition, 6top will change the 1510 attributes corresponding to the cell in the ChunkCellList, i.e. its 1511 CellID is changed to the same CellID in the CellList, and its Status 1512 is changed to USED ([I-D.ietf-6tisch-6top-interface]). 1514 The interaction between 6top and MAC layer caused by 1515 CREATE.hardcell.fromchunk is same as that caused by CREATE.hardcell 1516 (Section 3.1.1). 1518 3.11.2. READ.chunkcell 1520 Returns the cell information of a chunk given its ChunkId. For each 1521 cell of the chunk, the command returns: 1523 slotOffset: the slotOffset of the cell. 1525 channelOffset: channelOffset of the cell. 1527 cellId: the cellID in the CellList if scheduled. 1529 Status: USED/UNUSED 1531 Fails if the ChunkId does not exist. 1533 3.11.3. DELETE.hardcell.fromchunk 1535 To remove a hard cell which comes from a chunk, the upper layer 1536 specifies: 1538 slotframe ID: the ID of the slotframe where this cell is 1539 installed. 1541 slotOffset: the slotOffset for the cell. 1543 channelOffset: the selected channelOffset for the cell. 1545 LinkOption bitmap: bitmap as defined in [IEEE802154e] 1547 LinkType : as defined in in section 6.2.19.3 of [IEEE802154e]. 1549 CellType: as defined in Section 2.1 1551 target node address: the target address of that cell. In case 1552 of broadcast cells this is the broadcast address. 1554 TrackID: ID of the track the cell will belong to. 1556 This removes the hard cell from the node's schedule and CellList 1557 ([I-D.ietf-6tisch-6top-interface]). In addition, it changes the 1558 attributes corresponding to the cell in the ChunkCellList, i.e. its 1559 CellID is changed back to FFFF, and its Status is changed to UNUSED 1560 ([I-D.ietf-6tisch-6top-interface]). 1562 The interaction between 6top and MAC layer caused by DELETE.hardcell 1563 is same as that caused by DELETE.hardcell (Section 3.1.5). 1565 3.12. Data Commands 1567 3.12.1. Send.data 1569 The command used by upper layers to queue a packet so underlying TSCH 1570 sends it. According to the specific priority, the packet is pushed 1571 into a Queue with the equivalent priority or following a criteria out 1572 of scope. Once a packet is inserted into a queue it waits to be 1573 transmitted by TSCH according to the model defined in Section 2.2. 1574 If the queue is full or destination address is not a L2 neighbor of 1575 the node, failure to enqueue will be indicated to the caller. 1577 The required parameters are: 1579 src address: L2 address 1581 dest address: L2 unicast or broadcast address 1583 priority: packet priority, usually is consistent with queue 1584 priority 1586 message length: the length of the message 1588 message: control message or data message 1590 securityLevel:As defined by [IEEE802154e]. 1592 3.12.2. Receive.data 1594 The command is invoked whenever a packet is received and inserted 1595 into a reception queue. The method acts as a callback function to 1596 notify to the upper layers the received message. Upper layers MUST 1597 terminate this indication. 1599 The function has the following parameters: 1601 src address: L2 source address 1603 dest address: L2 unicast or broadcast destination address 1604 priority: packet priority, usually is consistent with queue 1605 priority 1607 message length: the length of the message. 1609 message: control message or data message 1611 4. 6top Communication Protocol 1613 This section defines the Information Element (IE) based message 1614 formats, and the 6top-to-6top communication time sequences. 1616 4.1. Message Formats 1618 6top has to negotiate the scheduling of soft cells with neighbor 1619 nodes. This negotiation happens through 6top-specific TSCH 1620 Information Elements, the format of which is defined in this section. 1621 For completeness, this section also details the formats of the IEs 1622 already defined in [IEEE802154e] and presented here without 1623 modification. 1625 6top messages can contain one or more IEs. Section 4.1.1 defines the 1626 different IEs used by 6top, both the ones used without modification 1627 from [IEEE802154e], and the new ones defined by this document. 1628 Section 4.1.2 shows how several IEs are assembled to form the 1629 different frames used by 6top. 1631 4.1.1. Information Elements 1633 [IEEE802154e] defines Information elements (IEs). IEs are formatted 1634 data objects consisting of an ID, a length, and a data payload used 1635 to pass data between layers or devices. [IEEE802154e] defines Header 1636 IEs and Payload IEs; 6top only uses Payload IEs. A Payload IE 1637 includes one or more IEs, and ends with a termination IE (ID = 0x0f, 1638 see [IEEE802154e]). 1640 6top uses the following Information Elements, some defined in 1641 [IEEE802154e], others introduced in this document. 1643 Defined in [IEEE802154e] and used by 6top without modification: 1645 TSCH Synchronization IE (Section 4.1.1.1) 1647 TSCH Slotframe and Link IE (Section 4.1.1.2) 1649 TSCH Timeslot Template IE (Section 4.1.1.3) 1650 TSCH Channel Hopping IE (Section 4.1.1.4) 1652 Defined by 6top: 1654 6top Opcode IE (Section 4.1.1.5) 1656 6top Bandwidth IE (Section 4.1.1.6) 1658 6top TrackID IE (Section 4.1.1.7) 1660 6top Generic Schedule IE (Section 4.1.1.8) 1662 4.1.1.1. TSCH Synchronization IE 1664 A Synchronization IE (SyncIE) contains Information allowing a node to 1665 synchronize to a TSCH network, including the current ASN and a join 1666 priority. Synchronization IE MUST be included in all TSCH Enhanced 1667 Beacons. 1669 6top re-uses this IE as defined in [IEEE802154e]. 1671 Format of a TSCH Synchronization IE (SyncIE). 1673 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 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Length | SubID |T| ASN | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | ASN | Join Priority | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 Figure 3 1682 Length=6 1684 SubID=0x1a 1686 T=0, i.e., short type 1688 ASN (5 octets) contains the Absolute Slot Number corresponding to the 1689 timeslot in which the TSCH Enhanced Beacon is sent. 1691 The Join Priority can be used by a joining device to select among 1692 beaconing devices when multiple beacons are heard. The PAN 1693 coordinator's join priority is zero. A lower value of join priority 1694 indicates that the device is the preferred one to connect to. As 1695 suggested by [I-D.ietf-6tisch-minimal], the beaconing device's join 1696 priority is its DAGRank(rank). 1698 4.1.1.2. TSCH Slotframe and Link IE 1700 The Slotframe and Link IE (FrameAndLinkIE) contains one or more 1701 slotframes and their respective cells that a beaconing device 1702 advertises to allow other devices to join the network. 1704 6top re-uses this IE as defined in [IEEE802154e]. 1706 Format of a TSCH Slotframe and Link IE (FrameAndLinkIE). 1708 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 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Length | SubID |T| NumFrame | | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1712 | | 1713 // Slotframe and cell information // 1714 | | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 Figure 4 1719 Length=variable 1721 SubID=0x1b 1723 T=0, i.e., short type 1725 NumFrame is set to the total number of slotframe descriptors 1726 contained in the TSCH Enhanced Beacon. 1728 Format of a slotframe descriptor. 1730 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 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | FrameID | FrameLen | NumCell | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | | 1735 // Cell information for each cell (5x NumCell) // 1736 | | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 Figure 5 1741 The FrameID field shall be set to the slotframeHandle that uniquely 1742 identifies the slotframe. 1744 The FrameLen field shall be set to the size of the slotframe in 1745 number of timeslots. 1747 The NumCell field shall be set to the number of cells that belong to 1748 the specific slotframe identified by the slotframeHandle. 1750 Format of a Cell information. 1752 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 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | SlotOffset | ChannelOffset | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | LinkOption | 1757 +-+-+-+-+-+-+-+-+ 1759 Figure 6 1761 SlotOffset shall be set to the slotOffset of this cell. 1763 ChannelOffset shall be set to the channelOffset of this cell. 1765 LinkOption indicates whether this cell is a TX cell, an RX cell, or a 1766 SHARED TX cell, whether the device to which it is being linked is to 1767 be used for clock synchronization, and whether this cell is hard 1768 cell. 1770 4.1.1.3. TSCH Timeslot Template IE 1772 Timeslot Template IE (SlotTemplateIE) defines Timeslot template being 1773 used by the TSCH device. 1775 6top re-uses this IE as defined in [IEEE802154e]. 1777 Format of a TSCH Timeslot Template IE (SlotTemplateIE). 1779 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | Length | SubID |T| TemplateID | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 Figure 7 1786 Length=1 1788 SubID=0x1c 1790 T=0, i.e., short type 1791 TemplateID shall be set to a Timeslot template handle. The full 1792 timeslot template, which contains the macTimeslotTemplate of TSCH 1793 (total 25 octets), MAY be included.(see [IEEE802154e]). 1795 4.1.1.4. TSCH Channel Hopping IE 1797 Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being 1798 used by the TSCH device. 1800 6top re-uses this IE as defined in [IEEE802154e]. 1802 Format of a TSCH Channel Hopping IE (ChHoppingIE). 1804 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Length | SubID |T| HopSequenceID | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 Figure 8 1811 Length=1 1813 SubID=0x09 1815 T=1, i.e., long type 1817 HopSequenceID shall be set to a Hopping Sequence handle. The full 1818 Hopping Sequence information MAY be included. (see [IEEE802154e]). 1820 4.1.1.5. 6top Opcode IE 1822 6top Opcode IE (OpcodeIE) defines operation codes of packets in 6top 1823 sublayer. 1825 This IE is not present in [IEEE802154e] and is defined by 6top. 1827 Format of a 6top Opcode IE (OpcodeIE). 1829 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | Length | SubID |T| OpcodeID | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 Figure 9 1836 Length=1 1838 SubID=0x41 1839 T=0, i.e., short type 1841 OpcodeID field shall be set to one of the following codes. 1843 0x00: Reserve Soft Cell Request 1845 0x01: Reserve Soft Cell Response 1847 0x02: Remove Soft Cell Request 1849 0x03: Reserve Hard Cell Request 1851 0x04: Remove Hard Cell Request 1853 4.1.1.6. 6top Bandwidth IE 1855 Bandwidth IE (BwIE) defines the number of cells to be reserved or 1856 actually been reserved. 1858 This IE is not present in [IEEE802154e] and is defined by 6top. 1860 Format of a 6top Bandwidth IE (BwIE). 1862 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 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | Length | SubID |T| FrameID | NumCell | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 Figure 10 1869 Length=2 1871 SubID=0x42 1873 T=0, i.e., short type 1875 FrameID MAY be set to the SlotFrameHandle to identify the slotframe 1876 from which cells are reserved. FrameID field MAY be set to NOP, 1877 which means no specific slotframe is associated. 1879 NumCell shall be set to the number of cells. When BwIE is combined 1880 with the OpecodeID of Reserve Soft Cell Request, NumCell presents how 1881 many cells are required to reserve; and when BwIE is combined with 1882 the OpecodeID of Reserve Soft Cell Response, NumCell presents how 1883 many cells are reserved successfully. 1885 4.1.1.7. 6top TrackID IE 1887 TrackID IE (TrackIdIE) describes the track which the reserved/removed 1888 cell(s) are associated with. 1890 This IE is not present in [IEEE802154e] and is defined by 6top. 1892 Format of a 6top TrackID IE (TrackIdIE). 1894 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 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | Length | SubID |T|OwnerInstID|rev| | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1898 // // 1899 | TrackOwnerAddr | 1900 | | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 Figure 11 1905 Length=3 or 7. When length=3, TrackOwnerAddr is 2 bytes short 1906 address, and when length=7, TrackOwnerAddr is 6 bytes long address. 1908 SubID=0x43 1910 T=0, i.e., short type 1912 The combination of TrackOwnerAddr and OwnerInstId represents a 1913 specific TrackID. 1915 4.1.1.8. 6top Generic Schedule IE 1917 Generic Schedule IE (ScheduleIE) describes cell sets. In different 1918 packets, ScheduleIE represents different information. See 1919 Section 4.1.2 for more detail. 1921 This IE is not present in [IEEE802154e] and is defined by 6top. 1923 Format of a 6top Generic Schedule IE (ScheduleIE). 1925 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 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Length | SubID |T| | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1929 | | 1930 // Schedule Body // 1931 | | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 Figure 12 1936 Length=variable 1938 SubID=0x44 1940 T=0, i.e., short type 1942 Schedule Body carries one or more schedule object. An object MAY 1943 carry a TLV (Type-Length-Value), which MAY itself comprise other 1944 TLVs. TLV format is as follows. Type: 1 byte, Length: 1 byte, 1945 Value: variable 1947 The following are some examples of schedule object TLV. 1949 Example 1. Cell Set TLV 1951 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 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | Type=1 | Length | FrameID | NumCell |F| 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | | 1956 // CellObjects // 1957 | | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 Figure 13 1962 FrameID shall be set to the slotframeHandle that uniquely identifies 1963 the slotframe. 1965 NumCell shall be set to the number of cells that belong to the 1966 specific slotframe identified by the slotframeHandle. 1968 F=1 means the specified cells equals to what are listed in 1969 CellObjects, and F=0 means the specified cells equals to what are not 1970 listed in CellObjects. 1972 CellObjects carries the information for one or more cells, including 1973 SlotOffset, ChannelOffset, LinkOption (Figure 6). 1975 Example 2. Schedule Matrix TLV 1977 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 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Type=2 | Length | FrameID |StartSlotOffset| 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 |StartSLotOffset| NumSlot | | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1983 | | 1984 // SlotBitMap (2x NumSlot) // 1985 | | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 Figure 14 1990 FrameID field MUST be set to the slotframeHandle that uniquely 1991 identifies the slotframe. 1993 StartSlotOffset field (2 octets) MUST be set to the slotOffset in the 1994 specific slotframe identified by the slotframeHandle. 1996 NumSlot field MUST be set to the number of timeslots from 1997 StartSlotOffset in the specific slotframe identified by the 1998 slotframeHandle. 2000 SlotBitMap (per timeslot) indicates for the given timeslot which 2001 channels are specified. For the 16 channels in 2.4GHz band, 2-octets 2002 are used to indicate which channel is specified. For example, given 2003 a timeslot and a SlotBitmap with value (10001000,00010000); the 2004 bitmap represents that ChannelOffset-0, ChannelOffset-4, 2005 ChannelOffset-11 are specified. 2007 4.1.2. Packet Formats 2009 This section describes the packets used in 6top to form a network, 2010 reserve/maintain bandwidth using soft cells, and reserve/remove hard 2011 cells in both the transmitter side and receiver sides. Each of these 2012 packets uses one or more IEs defined in Section 4.1.1. 2014 4.1.2.1. TSCH Enhanced Beacon 2016 The TSCH Enhanced Beacon is used to announce the presence of the 2017 network and allows new nodes to join. It is an Enhanced Beacon 2018 packet defined in [IEEE802154e] with the following Payload IEs: 2020 TSCH Synchronization IE (Section 4.1.1.1) 2022 TSCH Timeslot Template IE (Section 4.1.1.3) 2024 TSCH Channel Hopping IE (Section 4.1.1.4) 2026 TSCH Slotframe and Link IE (Section 4.1.1.2) 2028 Payload IE of TSCH Enhanced Beacon Packet 2030 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 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Length |GroupID|T| SyncIE | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | SyncIE | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | SyncIE | SlotTemplateIE | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 |SlotTemplateIE | ChHoppingIE | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | | 2041 // FrameAndLinkIE // 2042 | | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 Figure 15 2047 Length=variable 2049 GroupID=0x1, i.e., MLME IE 2051 T=1, i.e., payload IE 2053 See Section 4.1.1.1, Section 4.1.1.3, Section 4.1.1.4,Section 4.1.1.2 2054 for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndLinkIE. 2056 4.1.2.2. Soft Cell Reservation Request 2058 A Soft Cell Reservation Request packet is a DATA packet defined in 2059 [IEEE802154e] with the following payload IE. 2061 Payload IE of Soft Cell Reservation Request 2063 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 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Length |GroupID|T| OpcodeIE | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | OpcodeIE | BwIE | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | BwIE | | 2070 +-+-+-+-+-+-+-+-+ | 2071 // ScheduleIE // 2072 | | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 Figure 16 2077 Length=variable 2079 GroupID=0x1, i.e., MLME IE 2081 T=1, i.e., payload IE 2083 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x00, 2084 indicates Reserve Soft Cell Request operation. 2086 The NumCell field in 4-octet BwIE SHOULD be set to the number of 2087 cells needed to be reserved. 2089 The ScheduleIE specifies a candidate cell set, from which the cells 2090 SHOULD be reserved. ScheduleIE MAY be empty, means there is no 2091 constrain on which cells SHOULD not be reserved. 2093 In addition, TrackIdIE can be added in the packet to associate the 2094 reserved soft cells to a specific TrackID. 2096 4.1.2.3. Soft Cell Reservation Response 2098 Soft Cell Reservation Response is a DATA packet defined in 2099 [IEEE802154e] with the following payload IE. 2101 Payload IE of Soft Cell Reservation Response 2103 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 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Length |GroupID|T| OpcodeIE | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | OpcodeIE | BwIE | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | BwIE | | 2110 +-+-+-+-+-+-+-+-+ | 2111 // ScheduleIE // 2112 | | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 Figure 17 2117 Length=variable 2119 GroupID=0x1, i.e., MLME IE 2121 T=1, i.e., payload IE 2123 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x01, 2124 indicates Reserve Soft Cell Response operation. 2126 The NumCell field in 4-octet BwIE SHOULD be set to the number of 2127 cells which have been reserved successfully. 2129 The ScheduleIE SHOULD specify all of the cells which have been 2130 reserved successfully. 2132 In addition, TrackIdIE can be added in the packet to associate the 2133 reserved soft cells to a specific TrackID. 2135 4.1.2.4. Soft Cell Remove Request 2137 Soft Cell Remove Request is a DATA packet defined in [IEEE802154e] 2138 with the following payload IE. 2140 Payload IE of Soft Cell Remove Request 2142 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 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | Length |GroupID|T| OpcodeIE | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | OpcodeIE | | 2147 +-+-+-+-+-+-+-+-+ | 2148 // ScheduleIE // 2149 | | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 Figure 18 2154 Length=variable 2156 GroupID=0x1, i.e., MLME IE 2158 T=1, i.e., payload IE 2160 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x02, 2161 indicates Remove Soft Cell Request operation. 2163 The ScheduleIE SHOULD specify all the cells that need to be removed. 2165 4.1.2.5. Hard Cell Reservation Request 2167 Hard Cell Reservation Request packet is a DATA packet defined in 2168 [IEEE802154e] with the following payload IE. 2170 Payload IE of Hard Cell Reservation Request 2172 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 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Length |GroupID|T| OpcodeIE | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | OpcodeIE | | 2177 +-+-+-+-+-+-+-+-+ | 2178 // ScheduleIE // 2179 | | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 Figure 19 2184 Length=variable 2186 GroupID=0x1, i.e., MLME IE 2187 T=1, i.e., payload IE 2189 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x03, 2190 indicates Reserve Hard Cell Request operation. 2192 The ScheduleIE SHOULD specify all the cell that need to be reserved. 2194 In addition, TrackIdIE can be added in the packet to associate the 2195 reserved hard cells to a specific TrackID. 2197 4.1.2.6. Hard Cell Remove Request 2199 Hard Cell Remove Request is a DATA packet defined in [IEEE802154e] 2200 with the following payload IE. 2202 Payload IE of Hard Cell Remove Request 2204 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 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | Length |GroupID|T| OpcodeIE | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | OpcodeIE | | 2209 +-+-+-+-+-+-+-+-+ | 2210 // ScheduleIE // 2211 | | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 Figure 20 2216 Length=variable 2218 GroupID=0x1, i.e., MLME IE 2220 T=1, i.e., payload IE 2222 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x04, 2223 indicates Remove Hard Cell Request operation. 2225 The ScheduleIE SHOULD specify all the cells that need to be removed. 2227 4.2. Time Sequences 2229 6top neighbors exchange 6top-specific packets in the following cases, 2230 each detailed in a subsection. 2232 Network formation (Section 4.2.1) 2234 Creating soft cells (Section 4.2.2) 2235 Deleting soft cells (Section 4.2.3) 2237 Maintaining soft cells (Section 4.2.4) 2239 Creating hard cells (Section 4.2.5) 2241 Deleting hard cells (Section 4.2.6) 2243 4.2.1. Network Formation 2245 Network formation consists of two processes: joining and maintenance. 2247 4.2.1.1. Joining 2249 A node already in the network sends out TSCH Enhanced Beacons 2250 periodically. 2252 When a node is joining an existing network, it listens for TSCH 2253 Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs 2254 (the format of which is detailed in Section 4.1.2.1), the joining 2255 node MUST do the following. 2257 Initialize a neighbor table. Establish a neighbor table and 2258 record all of the information described in the TSCH Enhanced 2259 BEACONs as its initial schedule with those neighbors. 2261 Select a time source neighbor. According to the Joining 2262 Priority described by SyncIEs, the joining node chooses time 2263 source neighbors. 6top does not specify the criteria to choose 2264 time source neighbors from the Enhanced BEACONs. 2266 Select cells for Enhanced Beacons. The joining node selects 2267 one or more cells to indicate in its own Enhanced Beacons, 2268 which MAY be the same as the cells used by its neighbors for 2269 Enhanced Beacon broadcast, and record those cell(s) into the 2270 TSCH schedule with LinkType=ADVERTISING. 2272 Its Enhanced Beacons SHOULD include the cell(s) selected for EB 2273 purposes. The EB cells MUST be configured with LinkOption to 2274 "Receive" and "Timekeeping", telling its neighbors that the 2275 cell is used for broadcast. 2277 Start broadcasting Enhanced Beacon and communicate with 2278 neighbors. 2280 4.2.1.2. Maintenance 2282 Nodes MAY broadcast Enhance Beacons on the cells marked with 2283 LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors 2284 on the cells with LinkOptions "Receive" and "Timekeeping". If a cell 2285 with LinkType=ADVERTISING has both the "Receive" and "Timekeeping" 2286 LinkOptions set, which means that the cell is shared by neighbors and 2287 itself for broadcasting, then broadcasting Enhanced Beacon has higher 2288 priority. 2290 Whenever a node receives an Enhanced Beacon, it SHOULD update its 2291 schedule if there is a difference regarding to the cells used for 2292 synchronizing with the advertiser of the Enhanced Beacon. 2294 4.2.2. Creating soft cells 2296 The upper layer instructs 6top to schedule one or more soft cells by 2297 calling the Create soft cell command. This command can also be 2298 called by the monitoring process internal to 6top. 2300 When receiving a Create soft cell command, Node A's 6top sublayer 2301 forms a Soft Cell Reservation Request packet which includes the BwIE 2302 and ScheduleIE Information Elements. The BwIE indicates the number 2303 of cells to be reserved (N1); the ScheduleIE indicates set of a 2304 candidate cells from which the new cells SHOULD be selected. If the 2305 ScheduleIE is empty, Node A indicates there is no constraint on cell 2306 selection. 2308 The Soft Cell Reservation Request is sent to the neighbor (Node B) 2309 with whom new cells need to be scheduled. After receiving the Soft 2310 Cell Reservation Request, Node B selects the cells from the candidate 2311 cell set defined by the ScheduleIE in the Soft Cell Reservation 2312 Request, and forms a Soft Cell Reservation Response packet. In the 2313 Cell Reservation Response packet, the BwIE indicates the number of 2314 cells actually being reserved (N2); the ScheduleIE indicates those 2315 reserved cells. If N2 is smaller than N1, node B indicates to node A 2316 that there are not enough qualified cells to be reserved. Node B 2317 MUST record the reserved cells into its local schedule when sending 2318 the Soft Cell Reservation Response. After receiving the Soft Cell 2319 Reservation Response, Node A MUST record the reserved cells into its 2320 local schedule. 2322 The policy to build a candidate cell set and the policy to select 2323 cells from the candidate cell set to reserve are out of scope. 2325 The format of Schedule Body is flexible. For example, Node A can use 2326 Cell Set TLV defined in Figure 13 with field 'F' set to '0', and the 2327 CellObjects includes all of the cells being used by Node A. In 2328 another word, the cell candidate set is all of the cells not being 2329 included in the list defined by CellObjects. 2331 The behavior of the nodes when the soft cells negotiation fails is 2332 out of scope. 2334 4.2.3. Deleting soft cells 2336 The upper layer instructs 6top to delete one or more soft cells by 2337 calling the Delete soft cell command (Section 3.1.6). This command 2338 can also be called by the monitoring process internal to 6top 2339 (Section 6). 2341 When receiving a Delete soft cell command, Node A's 6top sublayer 2342 selects cells to be removed from its local schedule, and creates a 2343 Soft Cell Remove Request, which includes a ScheduleIE Information 2344 Element. The ScheduleIE indicates which specific cells to remove 2345 with a neighbor (Node B). The cells specified in the ScheduleIE 2346 SHOULD be removed from local schedule of Node A when the Soft Cell 2347 Remove Request is sent to Node B. When receiving the Soft Cell 2348 Remove Request, the cells specified in the ScheduleIE SHOULD be 2349 removed from the local schedule of Node B. 2351 The policy to select cells corresponding to a Delete soft cell 2352 command is out of scope. 2354 4.2.4. Maintaining soft cells 2356 The monitoring process internal to 6top (Section 6) is responsible 2357 for monitoring and re-scheduling soft cells to meet some QoS 2358 requirements. The monitoring process MAY issue a soft cell 2359 Maintenance command, which indicate a set of cells to be re-allocated 2360 in the TSCH schedule. 2362 When receiving a soft cell Maintenance command, 6top initializes a 2363 Soft Cell Remove Request (Section 4.2.3) with the neighbor in 2364 question, followed by a Soft Cell Reservation Request 2365 (Section 4.2.2). 2367 4.2.5. Creating hard cells 2369 The upper layer instructs 6top to create one or more hard cells by 2370 calling the Create hard cell command. 2372 When receiving a Create hard cell command, Node A's 6top sublayer 2373 creates a Hard Cell Reservation Request, including a ScheduleIE. The 2374 ScheduleIE indicates which specific cells with a neighbor (Node B) to 2375 be added. The cells specified in the ScheduleIE SHOULD be added in 2376 local schedule of Node A while the Hard Cell Reserve Request is sent 2377 to Node B. When receiving the Hard Cell Reserve Request, the cells 2378 specified in the ScheduleIE SHOULD be added in the local schedule of 2379 Node B. 2381 4.2.6. Deleting hard cells 2383 The upper layer instructs 6top to delete one or more hard cells by 2384 calling the Delete hard cell command. 2386 When receiving a Delete hard cell command, Node A's 6top sublayer 2387 creates a Hard Cell Remove Request, including a ScheduleIE. The 2388 ScheduleIE indicates which specific cells with a neighbor (Node B) to 2389 be removed. The cells specified in the ScheduleIE SHOULD be removed 2390 from local schedule of Node A while the Hard Cell Remove Request is 2391 sent to Node B. When receiving the Hard Cell Remove Request, the 2392 cells specified in the ScheduleIE SHOULD be removed from the local 2393 schedule of Node B. 2395 5. Statistics 2397 The 6top Statistics Function (SF) is responsible for collecting 2398 statistics, which it can provide to an upper layer and the Monitoring 2399 Function (Section 6). 2401 5.1. Statistics Metrics 2403 6top is in charge of keeping statistics from a set of metrics 2404 gathered from the behavior of the TSCH layer. 2406 The statistics data related to node states and cell metrics SHOULD be 2407 provided to upper layer for management, e.g., for RPL to calculate 2408 the node's Rank or for GMPLS to the required bandwidth is met. The 2409 specific algorithm to generate the statistics is out of scope. 2410 However, the statistics component SHOULD include the following 2411 metrics: 2413 1. LinkThroughput: associated with a link, Node A->Node B. For 2414 example, LinkThroughput can be calculated with: 2415 SUM(NumOfCell(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration) 2416 where NumOfCell(i) is the total number of cells from Node A to 2417 Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i. 2418 The unit is Byte/second. 2420 2. Latency: associated with a link, Node A->Node B. For example, 2421 latency can be expressed as Minimum and Maximum Latency. Minimum 2422 Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum 2423 Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where, 2424 MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum 2425 number of timeslots between two dedicated cells from Node A to 2426 Node B in Slotframe-i, respectively. 2428 3. LinkQuality. For example, average LQI, ETX, PDR, RSSI. 2430 4. TrafficLoad. For example, Queue Full Rate, Queue Empty Rate. 2432 5. NodeEnergy. For example, E_E=E_bat / [E_0 (T-t)/T]. 2434 5.2. Statistics Configuration 2436 The Statistics Function SHOULD be configurable. The configuration 2437 parameters SHOULD include: 2439 LinkQualityStatisticsEn 2441 TafficLoadStatisticsEn 2443 DeviceStatisticsEn 2445 6top statistics function is enabled/disabled and configured by the 2446 commands defined in Section 3.4 2448 6. Monitoring 2450 The 6top Monitoring Function (MF) is responsible for monitoring cell 2451 quality, traffic load, and issuing soft cell Maintenance commands, or 2452 Create/Delete soft cell commands. The data provided by the 2453 Statistics Function MAY be used as an input of MF in taking a 2454 monitoring decision. 2456 6.1. Monitor Configuration 2458 Monitoring Function SHOULD be configurable. The configuration 2459 parameters SHOULD include: 2461 MaintainCellEn. 2463 CreateDeleteCellEn. 2465 QosLevel. QosLevel SHOULD associate with specific neighbor 2466 address. QosLevel MAY reflect the latency constraint, cell 2467 quality constraint, and so on. The value of QosLevel works as 2468 the bandwidth redundancy coefficient. 2470 The 6top monitoring function is enabled/disabled and configured by 2471 the commands defined in Section 3.3 2473 6.2. Actuation 2475 The cell quality statistics MAY be used to generate soft a cell 2476 Maintenance command, which triggers a soft cell Maintenance procedure 2477 (see Section 4.2.4). The traffic load statistics MAY be used to 2478 generate internal Create (resp. Delete) soft cell commands, which 2479 trggiers a soft cell Reservation (resp. Remove) process (see 2480 Section 4.2.2 and Section 4.2.3). 2482 The policy to generate the soft cell Maintenance command and the 2483 policy to generate Create/Delete soft cell commands is out of scope. 2485 The policy to generate Create/Delete soft cell commands MAY take 2486 QosLevel into account. For example, there are two slotframes 2487 existing, Slotframe-1 consists of 32 timeslots, Slotframe-2 consists 2488 of 96 timeslots; timeslot duration is 10ms; QosLevel=1.5. If, from 2489 the traffic load statistics, MF determines that 2 packet/second 2490 SHOULD be added, then the MF generates a Create soft cell command, 2491 where FrameID=2, NumCell=3. 2493 7. References 2495 7.1. Normative References 2497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2498 Requirement Levels", BCP 14, RFC 2119, March 1997. 2500 7.2. Informative References 2502 [I-D.ietf-6tisch-tsch] 2503 Watteyne, T., Palattella, M., and L. Grieco, "Using 2504 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 2505 Statement and Goals", draft-ietf-6tisch-tsch-00 (work in 2506 progress), November 2013. 2508 [I-D.ietf-6tisch-architecture] 2509 Thubert, P., Watteyne, T., and R. Assimiti, "An 2510 Architecture for IPv6 over the TSCH mode of IEEE 2511 802.15.4e", draft-ietf-6tisch-architecture-02 (work in 2512 progress), June 2014. 2514 [I-D.ietf-6tisch-terminology] 2515 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 2516 "Terminology in IPv6 over the TSCH mode of IEEE 2517 802.15.4e", draft-ietf-6tisch-terminology-01 (work in 2518 progress), February 2014. 2520 [I-D.ietf-6tisch-minimal] 2521 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 2522 Configuration", draft-ietf-6tisch-minimal-01 (work in 2523 progress), June 2014. 2525 [I-D.ietf-6tisch-6top-interface] 2526 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 2527 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 2528 6top-interface-00 (work in progress), March 2014. 2530 [I-D.wang-6tisch-6top-sublayer] 2531 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 2532 Operation Sublayer (6top)", draft-wang-6tisch-6top- 2533 sublayer-00 (work in progress), February 2014. 2535 [I-D.ietf-6tisch-coap] 2536 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 2537 Interaction using CoAP", draft-ietf-6tisch-coap-00 (work 2538 in progress), May 2014. 2540 7.3. External Informative References 2542 [IEEE802154e] 2543 IEEE standard for Information Technology, "IEEE std. 2544 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2545 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2546 2012. 2548 [IEEE802154] 2549 IEEE standard for Information Technology, "IEEE std. 2550 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2551 and Physical Layer (PHY) Specifications for Low-Rate 2552 Wireless Personal Area Networks", June 2011. 2554 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 2555 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 2556 a Standards-Based Low-Power Wireless Development 2557 Environment", Transactions on Emerging Telecommunications 2558 Technologies , August 2012. 2560 [label-switching-154e] 2561 Morell, A., Vilajosana, X., Lopez-Vicario, J., and T. 2562 Watteyne, "Label Switching over IEEE802.15.4e Networks. 2563 Transactions on Emerging Telecommunications Technologies", 2564 June 2013. 2566 Authors' Addresses 2568 Qin Wang (editor) 2569 Univ. of Sci. and Tech. Beijing 2570 30 Xueyuan Road 2571 Beijing, Hebei 100083 2572 China 2574 Phone: +86 (10) 6233 4781 2575 Email: wangqin@ies.ustb.edu.cn 2577 Xavier Vilajosana 2578 Universitat Oberta de Catalunya 2579 156 Rambla Poblenou 2580 Barcelona, Catalonia 08018 2581 Spain 2583 Phone: +34 (646) 633 681 2584 Email: xvilajosana@uoc.edu 2586 Thomas Watteyne 2587 Linear Technology 2588 30695 Huntwood Avenue 2589 Hayward, CA 94544 2590 USA 2592 Phone: +1 (510) 400-2978 2593 Email: twatteyne@linear.com