idnits 2.17.1 draft-wang-6tsch-6tus-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 23, 2013) is 3984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 2492, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 2498, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 2504, but not defined == Unused Reference: 'RFC2119' is defined on line 2330, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 2335, but no explicit reference was found in the text == Unused Reference: 'RFC2464' is defined on line 2339, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 2345, but no explicit reference was found in the text == Unused Reference: 'RFC3819' is defined on line 2356, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 2366, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 2371, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 2375, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 2379, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 2383, but no explicit reference was found in the text == Unused Reference: 'RFC5673' is defined on line 2387, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 2391, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 2395, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 2400, but no explicit reference was found in the text == Unused Reference: 'RFC6606' is defined on line 2404, but no explicit reference was found in the text == Unused Reference: 'RFC6755' is defined on line 2409, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 2412, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 2417, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 2423, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 2428, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 2433, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 2439, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 2444, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 2449, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 2455, but no explicit reference was found in the text == Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is defined on line 2461, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap' is defined on line 2467, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-palattella-6tsch-terminology' is defined on line 2478, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-02) exists of draft-thubert-roll-forwarding-frags-01 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-12 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-04 == Outdated reference: A later version (-05) exists of draft-sarikaya-core-sbootstrapping-04 == Outdated reference: A later version (-03) exists of draft-gilger-smart-object-security-workshop-00 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-16 == Outdated reference: A later version (-02) exists of draft-watteyne-6tsch-tsch-lln-context-01 == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 == Outdated reference: A later version (-02) exists of draft-thubert-6tsch-architecture-00 Summary: 3 errors (**), 0 flaws (~~), 42 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: November 24, 2013 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 May 23, 2013 10 6tus Layer Specification 11 draft-wang-6tsch-6tus-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 time slot in that schedule corresponds to an atomic 18 link-layer resource, and can be allocated to any pair of neighbors in 19 the network. This allows the schedule to be built to tightly match 20 each node's bandwidth, latency and energy constraints, while ensuring 21 collision-free communication. The [IEEE802154e] standard does not, 22 however, present a mechanism to do so, as building and managing the 23 schedule is out of the standard's scope. Routing layers such as the 24 IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to 25 route multipoint-to-point traffic (from devices inside the LLN 26 towards a central control point) and point-to-multipoint traffic 27 (from the central control point to the devices inside the LLN). 28 Network layer overlays cannot be optimized and adapted to take 29 advantage of the cell-based topology created by the underlying TSCH 30 MAC layer as a missing set of functionalities need to be defined. 31 This document describes the 6tus layer and the main commands it 32 provides to upper network layers such as RPL or GMPLS. The set of 33 functionalities includes feedback metrics from cell states so network 34 layers can take routing decisions, TSCH configuration and control 35 procedures, and the support for centralized and decentralized 36 scheduling policies. 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 November 24, 2013. 55 Copyright Notice 57 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. 6tus Layer Specification . . . . . . . . . . . . . . . . . . 4 74 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.2. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.2.1. hard cells . . . . . . . . . . . . . . . . . . . . . 6 77 2.2.2. soft cells . . . . . . . . . . . . . . . . . . . . . 7 78 2.3. Data Convey Model . . . . . . . . . . . . . . . . . . . . 7 79 2.4. Commands . . . . . . . . . . . . . . . . . . . . . . . . 8 80 2.4.1. Cell Commands . . . . . . . . . . . . . . . . . . . . 8 81 2.4.2. Slotframe Commands . . . . . . . . . . . . . . . . . 13 82 2.4.3. Monitoring Commands . . . . . . . . . . . . . . . . . 14 83 2.4.4. Statistics Commands . . . . . . . . . . . . . . . . . 16 84 2.4.5. Network Formation Commands . . . . . . . . . . . . . 18 85 2.4.6. Time Source Neighbor Commands . . . . . . . . . . . . 20 86 2.4.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 21 87 2.4.8. Queueing Commands . . . . . . . . . . . . . . . . . . 23 88 2.4.9. Security Commands . . . . . . . . . . . . . . . . . . 26 89 2.4.10. Data Commands . . . . . . . . . . . . . . . . . . . . 27 90 2.5. Message Formats . . . . . . . . . . . . . . . . . . . . . 29 91 2.5.1. Information Elements . . . . . . . . . . . . . . . . 29 92 2.5.2. Packet Formats . . . . . . . . . . . . . . . . . . . 37 93 2.6. Time Sequence . . . . . . . . . . . . . . . . . . . . . . 41 94 2.6.1. Network Formation . . . . . . . . . . . . . . . . . . 42 95 2.6.2. Creating soft cells . . . . . . . . . . . . . . . . . 43 96 2.6.3. Deleting soft cells . . . . . . . . . . . . . . . . . 44 97 2.6.4. Maintaining soft cells . . . . . . . . . . . . . . . 44 98 2.6.5. Creating hard cells . . . . . . . . . . . . . . . . . 44 99 2.6.6. Deleting hard cells . . . . . . . . . . . . . . . . . 45 100 2.7. Statistics . . . . . . . . . . . . . . . . . . . . . . . 45 101 2.7.1. Statistics Metrics . . . . . . . . . . . . . . . . . 45 102 2.7.2. Statistics Configuration . . . . . . . . . . . . . . 46 103 2.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 46 104 2.8.1. Monitor Configuration . . . . . . . . . . . . . . . . 46 105 2.8.2. Actuation . . . . . . . . . . . . . . . . . . . . . . 47 106 3. Using 6tus . . . . . . . . . . . . . . . . . . . . . . . . . 47 107 3.1. RPL on 6tus . . . . . . . . . . . . . . . . . . . . . . . 47 108 3.1.1. Support to Neighbor Discovery and Parent Selection . 47 109 3.1.2. Support to Rank Computation . . . . . . . . . . . . . 48 110 3.1.3. Support to Control Messages Broadcast . . . . . . . . 49 111 3.1.4. Support to QoS . . . . . . . . . . . . . . . . . . . 50 112 3.2. GMPLS on 6tus . . . . . . . . . . . . . . . . . . . . . . 51 113 3.2.1. Cell Reservation Support for GMPLS on 6tus . . . . . 51 114 3.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 52 115 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 116 4.1. Normative References . . . . . . . . . . . . . . . . . . 52 117 4.2. Informative References . . . . . . . . . . . . . . . . . 52 118 4.3. External Informative References . . . . . . . . . . . . . 55 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 121 1. Introduction 123 As presented in [I-D.watteyne-6tsch-tsch-lln-context], the 124 [IEEE802154e] standard defines the mechanisms for a TSCH node to 125 communicate given a schedule. It does not, however, define the 126 policies to build and maintain the TSCH schedule, match that schedule 127 to the multi-hop paths maintained by a network layer such as RPL or a 128 2.5 layer such as GMPLS, adapt the resources allocated between 129 neighbor nodes to the data traffic flows, enforce a differentiated 130 treatment for data generated at the application layer and signaling 131 messages needed by 6LoWPAN and RPL to discover neighbors, react to 132 topology changes, self-configure IP addresses, or manage keying 133 material. 135 In a TSCH network, the MAC layer is not in charge of setting up the 136 schedule that controls the connectivity graph of the network and the 137 resources allocated to each cell in that topology. This 138 responsibility is left to an upper layer, defined in this document 139 and called "6tus" (pronounced "sixtus"). 141 This document describes the 6tus layer and the main commands provided 142 to upper network layers such as RPL or GMPLS. The set of 143 functionalities include feedback metrics from cell state so the 144 network layer can take routing decisions, TSCH configuration and 145 control procedures and support centralized and decentralized 146 scheduling policies. The 6tus layer addresses the set of 147 functionalities described in [I-D.watteyne-6tsch-tsch-lln-context]. 149 For example, network formation in a TSCH network is handled by the 150 use of Enhanced Beacons (EB). EBs include information for joining 151 nodes to be able to synchronize and set up an initial network 152 topology, however [IEEE802154e] does not specify how the period of 153 EBs is configured, nor the rules for a node to select a particular 154 node to join. The 6tus layer offers a set of commands so control 155 mechanisms can be introduced on top of TSCH so nodes configure to 156 join a specific node and obtain an unique 16-bit identifier from the 157 network. Once a network is formed, 6tus maintains the network's 158 health, allowing for nodes to stay synchronized. It supplies 159 mechanisms to manage each node's time source neighbor and configure 160 the EB interval. Network layers running on top of 6tus take 161 advantage of the TSCH MAC layer information so routing metrics, 162 topological information, energy consumption and latency requirements 163 can be adjusted to TSCH and adapted to application requirements. 165 TSCH requires a mechanism to manage its schedule; 6tus provides a set 166 of commands for upper layers to set up specific schedules, either 167 explicitly by detailing specific cell information, or by allowing 168 6tus to establish a schedule given a bandwidth or latency 169 requirement. 6tus is designed to enable centralized, decentralized 170 or hybrid scheduling entities. 6tus enables internal TSCH queuing 171 configuration, size of buffers, packet priorities, and transmission 172 failure behavior, and defines mechanisms to encrypt and authenticate 173 MAC slotframes. 175 2. 6tus Layer Specification 177 2.1. Overview 179 6tus is a layer which is the next-higher layer for TSCH, as detailed 180 in [I-D.draft-thubert-6tsch-architecture]. 6tus offers both 181 management and data interfaces to an upper layer. It includes 182 monitoring and statistics collection, both of which are configurable 183 through the management interface. 185 6tus distinguishes between hard cells and soft cells. It therefore 186 requires an extra flag to all cells in the TSCH schedule, as detailed 187 in Section 2.2. 189 When a higher layer gives 6tus a 6LoWPAN packet for transmission, 190 6tus maps it to the appropriate outgoing priority-based queue, as 191 detailed in Section 2.3. 193 All commands of the management and data interfaces are detailed in 194 Section 2.4. This set of commands is designed to support 195 centralized, decentralized and hybrid scheduling entities. 197 6tus defines TSCH Information Elements (IEs) for neighbors nodes to 198 negociate scheduling cells in the TSCH schedule. The format of those 199 is given in Section 2.5. 201 Example data exchanges between neighbor nodes are illustrated in 202 Section 2.6. 204 Section 2.7 defines how 6tus gathers statistics (e.g. link quality, 205 energy level, queue usage), and what commands an upper layer can use 206 to configure and retrieve statistics. 208 6tus can be configured to monitor some cells it has scheduled to 209 detect cells with poor performance. It can then automatically move 210 those cells inside the TSCH schedule. This behavior is described in 211 Section 2.8 213 2.2. Cell Model 215 IEEE802.15.4e defines a set of options attached to each cell. A cell 216 can be a Transmit cell, a Receive cell, a Shared cell or a 217 Timekeeping cell. These options are not exclusive, as a cell can be 218 qualified with more than one of them. The IEEE802.15.4e MLME-SET- 219 LINK.request command uses a linkOptions bitmap to specify the options 220 of a cell. Acceptable values are: 222 b0 = Transmit 224 b1 = Receive 226 b2 = Shared 228 b3 = Timekeeping 230 b4-b7 = Reserved 232 Only Transmit cells can also be marked as Shared cells. When the 233 shared bit is set, and a back-off procedure is applied to handle 234 collisions. Shared behavior is not defined for Receive cells. 236 6tus allows an upper layer to schedule a cell at a specific timeslot 237 and channel offset in a specific slotframe. 6tus follows the hard 238 cell reservation process described in Section 2.6.5. 240 In addition, 6tus allows an upper layer to schedule a certain amount 241 of bandwidth to a neighbor, without having to specify the exact 242 timeslot(s) and channel offset(s). 6tus follows the soft cell 243 reservation process described in Section 2.6.2. Once bandwidth is 244 reserved, 6tus is in charge of ensuring that this requirement is 245 continuously satisfied, as described in Section 2.8. 6tus 246 dynamically reallocates slots if needed, and overprovisions if 247 required. 249 Given this mechanism, 6tus defines hard cells (which have been 250 requested specifically) and soft cells (which that can be reallocated 251 dynamically). The hard/soft flag is introduced by the 6tus layer as 252 an extension of the IEEE802.15.4e LinkOption flags. This option is 253 mandatory; all cells are either hard or soft. 255 With the addition of the Hard/Soft flag, the resulting flags are: 257 b0 = Transmit 259 b1 = Receive 261 b2 = Shared 263 b3 = Timekeeping 265 b4 = Hard (1)/Soft (0) 267 b5-b7 = Reserved 269 2.2.1. hard cells 271 A hard cell is a cell that cannot be dynamically reallocated by 6tus. 272 A hard cell is uniquely identified by the following tuple: 274 slotframe id: id of the slotframe this cell is part of. 276 timeslot: the slot within the slotframe. 278 channel offset. 280 LinkOption bitmap: bitmap as defined in Section 2.2, including the 281 hard/soft bit which must be set to 1. 283 2.2.2. soft cells 285 A soft cell is a cell that can be reallocated by 6tus dynamically. 286 The hard/soft bit must be set to 0. This cell is installed by 6tus 287 given a specific bandwidth requirement. soft cells are installed 288 through the soft cell negotiation process described in Section 2.6. 290 2.3. Data Convey Model 292 Based on the established TSCH schedule, 6tus is responsible for 293 feeding the data flow from the upper layer into TSCH. This section 294 describes how 6tus shapes data from upper layer (e.g. RPL, 6LoWPAN), 295 and feeds it to TSCH. Since 6tus is a layer between TSCH and 296 6LoWPAN, the properties assciated with a packet/fragment from the 297 upper layer includes the next hop neighbor (DestAddr) and expected 298 sending priority of the packet (Priority). The output to TSCH is the 299 fragment corresponding to the next active cell in the TSCH schedule. 301 6tus Data Convey Model 303 | 304 | (DestAddr, Priority, Fragment) 305 | 306 +---------------------------------------+ 307 | I-MUX | 308 +---------------------------------------+ 309 | | | | .... | 310 | | | | | 311 +---+ +---+ +---+ +---+ +---+ 312 | | | | | | | | | | 313 |Q1 | |Q2 | |Q3 | |Q4 | |Qn | 314 | | | | | | | | | | 315 +---+ +---+ +---+ +---+ +---+ 316 | | | | | 317 | | | | | 318 +---------------------------------------+ 319 | MUX | 320 +---------------------------------------+ 321 | 322 | 323 +---+ 324 |PDU| 325 +---+ 326 | 327 | TSCH MAC-payload 328 | 330 Figure 1 332 In Figure 1, Qi represents a queue, which is either broadcast or 333 unicast, and is assigned a priority. The number of queues is 334 configurable. The relationship between queues and slotframes is 335 configurable. For example, for a given queue, only one specific 336 slotframe can be used, or all of the slotframes can be used, or a 337 subset of slotframes can be used. 339 When 6tus receives a packet to transmit through a Send.data command 340 (Section 2.4.10), the I-MUX module selects a queue in which to insert 341 it. If the packet's destination address is a unicast (resp. 342 broadcast) address, it will be inserted into a unicast (resp. 343 broadcast) queue. 345 The MUX module is invoked at each scheduled transmit cell by TSCH. 346 When invoked, the MUX module goes through the queues, looking for the 347 best frame to send. If it finds a frame, it hands it over to TSCH 348 for transmission. If the next active cell is a broadcast cell, it 349 selects a fragment only from broadcast queues. 351 How the MUX module selects the best frame is configurable. 352 Typically, the following rules are used: 354 The frame's layer 2 destination address must match the neighbor 355 address associated with the transmit cell. 357 Frames from a queue with a high priority must be sent before 358 frames from a queue with a low priority. 360 Further rules can be configured to satisfy specific QoS requirements. 362 2.4. Commands 364 6tus provides a set of commands a higher layer can call, including 365 management commands and data commands. Most of these commands are 366 related to the management of slotframes, time slots and scheduling 367 information. 6tus also provides an interface allowing an upper layer 368 to retrieve status information and statistics. This section lists 369 the commands offered by 6tus. 371 2.4.1. Cell Commands 373 The following methods allow an upper layer to manage the network 374 schedule: 376 2.4.1.1. CREATE.hardcell 377 Creates one or more hard cells in the schedule. Fails if the cell 378 already exists. A cell is uniquely identified by the tuple 379 (slotframe id, timeslot, channel offset). 381 To create a hard cell, the upper layer specifies: 383 slotframe id: id of the slotframe this slot will be scheduled in. 385 time slot: the specific time slot number. 387 channel offset: the frequency offset. 389 LinkOption bitmap: bitmap as defined in Section 2.2 391 target node address: the address of that node to communicate with 392 over this cell. In case of broadcast cells this is the broadcast 393 address. 395 6tus schedules the cell and marks it as a hard cell, indicating that 396 it cannot reschedule this cell. 398 2.4.1.2. CREATE.softcell 400 To create a soft cell, the upper layer specifies: 402 slotframe id: id of the slotframe this slot will be scheduled in 404 number of cells: the required number of soft cells. 406 LinkOption bitmap: bitmap as defined in Section 2.2 408 target node address: the address of that node to communicate with 409 over this cell. In case of broadcast cells this is the broadcast 410 address. 412 QoS level: the cell redundancy policy. The policy can be for 413 example STRICT, BEST_EFFORT, etc. 415 6tus is responsible for picking the exact timeslot and channel offset 416 in the schedule, and ensure that the target node chooses the same. 417 6tus marks these cells as soft cell, indicating that it will 418 continuously monitor their performance and reschedule if needed. 420 6tus deals with the allocation process by negotiation with the target 421 node. The negotiation process is described in Section 2.6.2. The 422 command returns the list of created cells defined by (slotframe id, 423 time slot number, channel offset). It fails if the required number 424 of cells is higher than the available number of cells in the 425 schedule. It fails if the negotiation with the target node fails. 426 It fails if the cell Option bitmap indicates that the cell MUST be 427 Hard. 429 2.4.1.3. READ.cell 431 Given a (slotframe id, time slot number, channel offset), retrieves 432 the cell information. Fails if the cell does not exist. The 433 returned information contains: 435 slotframe id: the id of the slotframe where this cell is 436 installed. 438 time slot: the time slot where the cell is set. 440 channel offset: the selected channel offset for the cell. 442 LinkOption bitmap: bitmap as defined in Section 2.2 444 target node address: the target address of that cell. In case of 445 broadcast cells this is the broadcast address. 447 A read command can be issued for any cell, hard or soft. 449 2.4.1.4. UPDATE.cell 451 Update a hard cell, i.e. move it to a different timeslot and/or 452 channel offset. Fails if the cell does not exist. Requires a 453 (slotframe id, time slot, channel offset), type of cell and target 454 node are the fields that can be updated. soft cells cannot be 455 updated by the UPDATE.cell command. REALLOCATE.softcell 456 (Section 2.4.1.7) MUST be used instead. 458 2.4.1.5. DELETE.hardcell 460 To removes a hard cell, the upper layer specifies: 462 slotframe id: the id of the slotframe where this cell is 463 installed. 465 time slot: the time slot where the cell is set. 467 channel offset: the selected channel offset for the cell. 469 This removes the hard cell from the node's schedule. 471 2.4.1.6. DELETE.softcell 472 To remove a (number of) soft cell(s), the upper layer specifies: 474 slotframe id: the id of the slotframe where this cell is 475 installed. 477 number of cells: the number of cells to be removed 479 LinkOption bitmap: bitmap as defined in Section 2.2 481 target node address: the target address of that cell. In case of 482 broadcast cells this is the broadcast address. 484 In the case a soft cell wants to be moved from the allocated slot so 485 a hard cell can be installed instead, the REALLOCATE.softcell 486 (Section 2.4.1.7) MUST be used. 488 2.4.1.7. REALLOCATE.softcell 490 To force a move of a soft cell, the upper layer specifies: 492 slotframe id: the id of the slotframe where the cell is allocated. 494 time slot: the slot number where that cell is installed. 496 channel offset: the channel offset for that cell. 498 The reallocated cell will be installed in a different slot, channel 499 offset but same slotframe. hard cells cannot be reallocated. 501 2.4.1.8. Hardcell Command Behavior 503 The following table describe the behavior of 6tus upon reception of 504 the hard cell management commands. 506 hard cell Operations behavior 507 +---------------------------------+---------------------------------+ 508 | 6tus commands | 6tus behavior | 509 +---------------------------------+---------------------------------+ 510 | Create.hardcell | 6tus_ReserveHardCellReq() -ACK | 511 | (NeigAddr, SlotframeID, | | 512 | SlotOffset, | If NeigAddr ==Broadcast Address| 513 | ChannelOffset, LinkOption) | Then LinkType=ADVERTISING | 514 | | Add cell to EB's FrameAndCellIE | 515 +---------------------------------+---------------------------------+ 516 | Read.cell | MLME-GET.request | 517 |(NeigAddr,SlotframeID,SlotOffset,| | 518 | ChannelOffset, LinkOption) | | 519 +---------------------------------+---------------------------------+ 520 | Delete.hardcell | 6tus_RemoveHardCellReq() --ACK | 521 | (NeigAddr ,SlotOffset, | | 522 | ChannelOffset, LinkOption) | If LinkType=ADVERTISING, it is a| 523 | | broadcast cell, Then Remove cell| 524 | | from EB's FrameAndCellIE | 525 +---------------------------------+---------------------------------+ 526 | Update.cell | 6tus_RemoveHardCellReq() --ACK | 527 | (OldFrameID, OldSlotOffset, | 6tus_ReserveHardCellReq() --ACK | 528 | OldChannelOffset, NewFrameID, | (with same NeigAddr,LinkOption) | 529 | NewSlotOffset,NewChannelOffset)| If old cell is in EB | 530 | | Then modify EB | 531 +---------------------------------+---------------------------------+ 533 2.4.1.9. Softcell Command Behavior 535 The following table describe the behavior of 6tus upon reception of 536 the Softcell management commands. 538 soft cell Operations behavior 539 +--------------------------------+----------------------------------+ 540 | 6tus commands | 6tus behavior | 541 +--------------------------------+----------------------------------+ 542 | Create.softcell | 6tus_ReserveSoftCellReq() -ACK | 543 |(NeigAddr, NumCell,LinkOption, | ACK ---6tus_ReserveSoftCellResp()| 544 | SlotframeID, QoSLevel) | | 545 +--------------------------------+----------------------------------+ 546 | Read.cell | MLME-GET.request | 547 |(NeigAddr,SlotframeID, | | 548 | SlotOffset,ChannelOffset) | | 549 +--------------------------------+----------------------------------+ 550 | Delete.softcell | 6tus_RemoveSoftCellReq() -- ACK | 551 | (NeigAddr ,NumCell, | If LinkType =ADVERTISING | 552 | LinkOption, SlotframeID) | i.e. a broadcast cell Then Remove| 553 | | cell from EB's FrameAndCellIE | 554 +--------------------------------+----------------------------------+ 555 | Reallocate.softcell | 6tus_RemoveSoftCellReq() -- ACK | 556 |(NeigAddr,SlotframeID, | 6tus_ReserveSoftCellReq() -- ACK | 557 | SlotOffset,ChannelOffset) | ACK ---6tus_ReserveSoftCellResp()| 558 +--------------------------------+----------------------------------+ 560 2.4.2. Slotframe Commands 562 6tus provides the following commands to manage TSCH slotframes. 564 2.4.2.1. CREATE.slotframe 566 Creates a new slotframe. Returns the slotframe id that corresponds 567 to its priority (SlotFrameHandle). The command requires: 569 number of slots: the required number of slots. 571 Fails if the number of required slots is less than zero. 573 2.4.2.2. READ.slotframe 575 Returns the information of a slotframe given its slotframe id. The 576 command returns: 578 slotframe id: the id of the slotframe. (SlotFrameHandle) 580 number of slots: the number of slots. 582 Fails if the slotframe id does not exist. 584 2.4.2.3. UPDATE.slotframe 585 Change the number of slots in a slotframe. The command requires: 587 slotframe id: the id of the slotframe. 589 number of slots: the number of slots to be updated. 591 Fails if the number of required slots is less than zero. Fails if 592 the slotframe id does not exist. 594 2.4.2.4. DELETE.slotframe 596 Deletes a slotframe. The command requires: 598 slotframe id: the id of the slotframe. 600 Fails if the slotframe id does not exist. 602 2.4.2.5. Slotframe Command Behavior 604 The following table describes the behavior of 6tus upon reception of 605 the Slotframe management commands. 607 Slotframe Management Operations behavior 609 +--------------------------------+----------------------------------+ 610 | 6tus commands | 6tus behavior | 611 +--------------------------------+----------------------------------+ 612 | Create.slotframe(NumSlot) | MLME-SET-SLOTFRAME.request | 613 | |(operation=ADD) | 614 +--------------------------------+----------------------------------+ 615 | Read.slotframe(SlotframeID) | MLME-GET.request | 616 +--------------------------------+----------------------------------+ 617 | Delete.slotframe(SlotframeID) | MLME-SET-SLOTFRAME.request | 618 | |(operation=DELETE) | 619 +--------------------------------|----------------------------------+ 620 | Update.slotframe(SlotframeID | MLME-SET-SLOTFRAME.request | 621 | ,NumSlot) |(operation=MODIFY) | 622 +--------------------------------+----------------------------------+ 624 2.4.3. Monitoring Commands 626 Monitoring commands provide the means for upper layers to configure 627 whether 6tus must ensure the required bandwidth. This procedure is 628 achieved through over-provisioning according to cell status feedback. 629 Monitoring is also in charge of reallocating soft cells that are 630 under the required QoS. The mechanism is described in Section 2.8. 632 2.4.3.1. CONFIGURE.monitoring 634 Configures the level of QoS the Monitoring process must enforce. The 635 command requires: 637 slotframe id: the id of the slotframe. 639 target node: the destination node. 641 enforce policy: The policy used to enforce the QoS requirements. 642 Can be for example DISABLE, BEST_EFFORT, STRICT, OVER-PROVISION, 643 etc. 645 Fails if the slotframe id does not exist. 647 2.4.3.2. READ.monitoring.status 649 Reads the current Monitoring status. Requires the following 650 parameters. 652 slotframe id: the id of the slotframe. 654 target node: the destination node. 656 Returns the QoS levels for that Target node on that slotframe. 658 allocated_hard: Number of hard cells allocated. 660 allocated_soft: Number of soft cells allocated. 662 provisioned: the extra provisioned cells. 0 if CONFIGURE.qos 663 enforce is DISABLE. 665 QoS: the current QoS. Including overprovisioned cells, i.e what 666 bandwidth is being obtained including the overprovisioned cells. 668 RQoS: the real QoS without provisioned cells. What is the actual 669 bandwidth without taking into account the overprovisioned cells. 671 Fails if the slotframe id does not exist. 673 2.4.3.3. Monitoring Command Behavior 675 The following table describes the behavior of 6tus upon reception of 676 the Monitoring management commands. 678 Monitoring Management Operations behavior 679 +------------------------------------+------------------------------+ 680 | 6tus commands | 6tus behavior | 681 +------------------------------------+------------------------------+ 682 | Configure.monitoring(NeigAdd, | Create/Update Monitoring MIB | 683 | SlotframeID,Enforce) | Starts monitoring service | 684 +------------------------------------+------------------------------+ 685 | Read.monitoring.status(SlotframeID)| Reads 6tus Monitoring MIB | 686 +------------------------------------+------------------------------+ 688 Figure 2 690 2.4.4. Statistics Commands 692 6tus keeps track of TSCH statistics for upper layers to adapt 693 correctly to medium changes. The exact metrics for statistics are 694 out of the scope of this document but the present commands should be 695 used to configure and read monitored information regardless of the 696 specific metric. 698 2.4.4.1. CONFIGURE.statistics 700 Configures Statistics process. The command requires: 702 slotframe id: the id of the slotframe. If empty monitors all 703 slotframe ids 705 time slot: slot number to be monitored. If empty all slots are 706 monitored 708 channel offset: specific channel offset to be monitored. If empty 709 all channels are monitored. 711 target node: the destination node. If empty, all target nodes are 712 monitored. 714 metric: metric to be monitored. This may be PDR, ETX, queuing 715 statistics, energy-related metrics, etc.) 717 window: time window to be considered for the calculations. If 0 718 all historical data is considered. 720 enable: Enables statistics or disables them. 722 Fails if the slotframe id does not exist. The statistics service can 723 be configured to retrieve statistics at different levels. For 724 example to aggregate information by slotframe id, or to retrieve 725 statistics for a particular slot, etc. the CONFIGURE.statistics 726 enables flexible configuration by supporting empty parameters that 727 will force the monitoring of the statistics by all members of that 728 dimension. 730 2.4.4.2. READ.statistics 732 Reads a metric for the specified dimension. Information is 733 aggregated according to the parameters. The command requires: 735 slotframe id: the id of the slotframe. If empty aggregates 736 information of all slotframe ids 738 time slot: the slot number for which the information is required. 739 If empty all slots are aggregated 741 channel offset: the specific channel offset for which the 742 information is required. If empty all channels are aggregated. 744 target node: the destination node. If empty all target nodes are 745 aggregated. 747 metric: metric to be read. 749 Returns the value for the requested metric. 751 Fails if empty metric or metric does not exits. 753 2.4.4.3. RESET.statistics 755 Resets the gathered statistics. The command requires: 757 slotframe id: the id of the slotframe. If empty resets the 758 information of all slotframe ids 760 time slot: the slot number for which the information wants to be 761 reset. If empty statistics from all slots are reset 763 channel offset: the specific channel offset for which the 764 information wants to be reset. If empty all statistics for all 765 channels are reset. 767 target node: the destination node. If empty all statistics for 768 the target node are reset. 770 metric: metric to be reset. 772 Fails if empty metric or metric does not exits. 774 2.4.4.4. Statistics Command Behavior 776 The following table describes the behavior of 6tus upon reception of 777 the Statistics management commands. 779 Statistics Management Operations behavior 781 +--------------------------------+----------------------------------+ 782 | 6tus commands | 6tus behavior | 783 +--------------------------------+----------------------------------+ 784 | Configure.statistics | | 785 | (SlotFrameID,TSlot, ChannelOff,| Configures Statistics MIB. | 786 | NeigAdd,Metric,Window,En) | Enables statistics service | 787 +--------------------------------+----------------------------------+ 788 | Read.statistics(SlotFrameID) | Returns the statistic MIB for the| 789 | Ch.Off,NeigAdd,Metric) | requested parameters | 790 +--------------------------------+----------------------------------+ 791 | Reset.statistics(SlotFrameID) | Resets the required statistic MIB| 792 | Ch.Off,NeigAdd,Metric) | | 793 +--------------------------------+----------------------------------+ 795 2.4.5. Network Formation Commands 797 EBs need to be configured, including their transmission period, the 798 slot number and channel offset that they should be sent on, and the 799 priority announced. The parameters for that command are optional and 800 enable a very flexible configuration of EBs. If slotframe id is 801 specified, the EBs will be configured to use that specific slotframe; 802 if not they will use the first slotframe where the configured time 803 slot is allocated. Time slot enforces the EB to a specific time 804 slot. In case time slot parameter is not present, the EB is sent in 805 the first available transmit time slot. In case channel offset 806 parameter is not set, the EB is configured to use the first available 807 channel. 809 2.4.5.1. CONFIGURE.eb 811 Configures EBs. The command requires: 813 slotframe id: the id of the slotframe where the EBs MUST be sent. 814 Zero if any slotframe can be used. 816 time slot: the slot number where the EBs MUST be sent. Zero if 817 any timeslot can be used. 819 channel offset: the channel offset where the EBs MUST be sent. 820 Zero if any channel offset can be used. 822 period: the EBs period, in seconds. 824 expires: when the EBs periodicity will stop. If Zero the period 825 never stops. 827 priority: the joining priority model that will be used for 828 advertisement. Joining priority MAY be for example 829 SAME_AS_PARENT, RANDOM, BEST_PARENT+1. 831 Fails if the tuple slotframe id, timeslot, channel offset is already 832 scheduled. 834 2.4.5.2. READ.eb 836 Reads the EBs configuration. No parameters are required. 838 Returns the current EBs configuraton for that slotframe, which 839 contains: 841 slotframe id: the slotframe where the EB is being sent. 843 time slot: the slot number where the EBs is being sent. 845 channel offset: the channel offset the EBs is being sent on. 847 period: the EBs period. 849 expires: when the EBs periodicity stops. If 0 the period never 850 stops. 852 priority: the joining priority that this node advertises. 854 Fails if the slotframe id does not exist. 856 2.4.5.3. Network Formation Command Behavior 858 The following table describes the behavior of 6tus upon reception of 859 the Network Configuration management commands. 861 Network Configuration Management Operations behavior 862 +----------------------------------+--------------------------------+ 863 | 6tus commands | 6tus behavior | 864 +----------------------------------+--------------------------------+ 865 | Configure.EB(SlotFrameID,TSlot, | Configures the 6tus MIB | 866 | Ch.Off,Period,Expires,Prio,Con_p)| regarding EB configuration | 867 +----------------------------------+--------------------------------+ 868 | Read.EB() | Reads 6tus EB MIB | 869 | | | 870 +----------------------------------+--------------------------------+ 872 2.4.6. Time Source Neighbor Commands 874 Commands to select time source neighbors. 876 2.4.6.1. CONFIGURE.timesource 878 Configures the Time Source Neighbor selection process. More than one 879 time source neighbor can be selected. The command requires: 881 selection policy: The policy used to select the time parent. The 882 policy MAY be for example ALL_PARENTS, BEST_CONNECTED, 883 LOWEST_JOIN_PRIORITY, etc. 885 Fails if any of the time source neighbors do not exist or it is not 886 reachable. 888 2.4.6.2. READ.timesource 890 Retrieves information about the time parents of that node. The 891 command does not require any parameter. 893 Returns the following information for each of the time sources: 895 target node: address of the time parent. 897 statistics: includes for example minimum, maximum, average time 898 correction for that time parent 900 policy: the used policy 902 Fails if the slotframe id or no time source neighbors exist. 904 2.4.6.3. Time Source Neighbor Command Behavior 906 The following table describes the behavior of 6tus upon reception of 907 the Time Source Neighbor Configuration management commands. 909 Time Source Neighbors Configuration Management Operations behavior 911 +---------------------------------+---------------------------------+ 912 | 6tus commands | 6tus behavior | 913 +---------------------------------+---------------------------------+ 914 | Configure.timesource(Policy) | Configures the 6tus MIB | 915 | | regarding timesource parents | 916 +---------------------------------+---------------------------------+ 917 | Read.timesource() | Read 6tus timesource MIB | 918 | | | 919 +---------------------------------+---------------------------------+ 921 Figure 3 923 2.4.7. Neighbor Commands 925 Commands to manage neighbor table. The commands SHOULD be used by 926 the upper layer to query the neighbor related information and by the 927 lower layer to keep track of neighbors information. 929 2.4.7.1. CREATE.neighbor 931 Creates an entry for a neighbor in the neighbor table. 933 neighbor address: The address of the neighbor. 935 neighbor stats: for example, RSSI of the last received packet from 936 that neighbor, ASN when that neighbor has been added, etc. 938 Returns whether the neighbor is created or not. 940 2.4.7.2. READ.all.neighbor 942 Returns the list of neighbors of that node. Fails if empty. For 943 each neighbor in the list it returns: 945 neighbor address: The address of the neighbor. 947 neighbor stats: for example, RSSI of the last received packet from 948 that neighbor, ASN when that neighbor has been added, packets 949 received from that neighbor, packets sent to it, etc. . 951 2.4.7.3. READ.neighbor 953 Returns the information of a specific neighbors of that node 954 specified by its neighbor address. Fails if it does not exists. For 955 that neighbor it returns: 957 neighbor address: The address of the neighbor. 959 neighbor stats: for example, RSSI of the last received packet from 960 that neighbor, ASN when that neighbor has been added, packets 961 received from that neighbor, packets sent to it, etc. 963 2.4.7.4. UPDATE.neighbor 965 Updates an entry for a neighbor in the neighbor table. Fails if the 966 neighbor does not exist. Updates stats parameters. Requires: 968 neighbor address: The address of the neighbor. 970 neighbor stats: for example, RSSI of the last received packet from 971 that neighbor, ASN when that neighbor has been added, etc. . 973 Returns whether the neighbor is updated or not. 975 2.4.7.5. DELETE.neighbor 977 Deletes a neighbor given its address. Fails if the neighbor does not 978 exists. 980 2.4.7.6. Neighbors Command Behavior 982 The following table describes the behavior of 6tus upon reception of 983 the Neighbors Configuration management commands. 985 Neighbors Management Operations behavior 986 +---------------------------------+---------------------------------+ 987 | 6tus commands | 6tus behavior | 988 +---------------------------------+---------------------------------+ 989 | Create.neighbor(address,stats) | Adds a neighbor to the neighbor | 990 | | table in the 6tus MIB. | 991 +---------------------------------+---------------------------------+ 992 | Read.all.neighbor() | lists all neighbors from the | 993 | | neighbor table. | 994 +---------------------------------+---------------------------------+ 995 | Read.neighbor(address) | Reads neighbor information from | 996 | | neighbor table in the 6tus MIB | 997 +---------------------------------+---------------------------------+ 998 | Update.neighbor(address,stats) | Updates an entry for a neighbor | 999 | | in the 6tus MIB | 1000 +---------------------------------+---------------------------------+ 1001 | Delete.neighbor(address) | Removes the neighbor from the | 1002 | | 6tus MIB | 1003 +---------------------------------+---------------------------------+ 1005 2.4.8. Queueing Commands 1007 TSCH MAC layer queues need to be configured. This includes queue 1008 length, retransmission policy, discarding of packets, etc. 1010 2.4.8.1. CREATE.queue 1012 Creates and Configures TSCH Queues. The command SHOULD be applied 1013 for each required queue. The command requires: 1015 txqlength: the desired transmission queue length. 1017 rxqlength: the desired reception queue length. 1019 numrtx: number of allowed retransmissions. 1021 age: discard packet according to its age on the queue. 0 if no 1022 discards are allowed. 1024 rtxbackoff: retransmission back off in number of slotframes. 0 if 1025 next available slot wants to be used. 1027 statswindow: window of time used to compute stats. 1029 queue priority: the priority of this queue. 1031 Returns the queue id. 1033 2.4.8.2. READ.queue 1035 Reads the queue configuration. Requires the queue id. 1037 The command returns: 1039 txqlength: the transmission queue length. 1041 rxqlength: the reception queue length. 1043 numrtx: number of allowed retransmissions. 1045 age: maximum age of a packet befoer being discarded. 0 if no 1046 discards are allowed. 1048 rtxbackoff: retransmission backoff in number of slotframes. 0 if 1049 next available slot is used. 1051 2.4.8.3. READ.queue.stats 1053 Reads the queue stats. Requires queue id. 1055 The command returns: 1057 txqlengthstats: average, maximum, minimum length of the 1058 transmission queue. 1060 rxqlengthstats: average, maximum, minimum length of the reception 1061 queue. 1063 numrtxstats: average, maximum, minimum number of retransmissions. 1065 agestats: average, maximum, minimum age of a packet in the queue. 1067 rtxbackoffstats: average, maximum, minimum retransmission backoff. 1069 queue priority: the priority of this queue. 1071 2.4.8.4. UPDATE.queue 1073 Update a TSCH Queue. The command requires: 1075 queueid: the desired transmission queue length. 1077 txqlength: the desired transmission queue length. 1079 rxqlength: the desired reception queue length. 1081 numrtx: number of allowed retransmissions. 1083 age: discard packet according to its age on the queue. 0 if no 1084 discards are allowed. 1086 rtxbackoff: retransmission backoff in number of slotframes. 0 if 1087 next available slot wants to be used. 1089 statswindow: window of time used to compute stats. 1091 2.4.8.5. DELETE.queue 1093 Deletes a TSCH Queue. The command requires the queue id. All 1094 packets in the queue are discarded and the queue is deleted. 1096 2.4.8.6. Queueing Command Behavior 1098 The following table describes the behavior of 6tus upon reception of 1099 the Queue management commands. 1101 Queue Management Operations behavior 1103 +---------------------------------+---------------------------------+ 1104 | 6tus commands | 6tus behavior | 1105 +---------------------------------+---------------------------------+ 1106 | Create.queue(tqlen,trlen,numrtx,| Creates a queue with specified | 1107 | age,rtxbackoff,prio) | parameters. Updates 6tus MIB. | 1108 +---------------------------------+---------------------------------+ 1109 | Read.queue(id) | Reads the queue configuration | 1110 | | from 6tus MIB. | 1111 +---------------------------------+---------------------------------+ 1112 | Update.queue(id,tqlen,trlen, | Updates the queue configuration | 1113 | numrtx,age,rtxbackoff,prio) | from 6tus MIB. Readjustes actual| 1114 | | queue size if required. | 1115 +---------------------------------+---------------------------------+ 1116 | Delete.queue(id) | Deletes the queue from MIB. | 1117 | | | 1118 +---------------------------------+---------------------------------+ 1119 | Read.queue.stats() | Reads the queue | 1120 | | stats from 6tus MIB. | 1121 +---------------------------------+---------------------------------+ 1123 2.4.9. Security Commands 1125 The following commands are used to manage underlying layer security. 1126 In that case 6tus acts as delegating interface to IEEE802.15.4 1127 security configuration commands. 1129 2.4.9.1. CONFIGURE.security 1131 Enables/Disables Security and configures the MAC PIB. The command 1132 requires: 1134 enable: enables underlying layer security. 1136 macAutoRequestSecurityLevel: the security level used for automatic 1137 data requests as described by IEEE 802.15.4 table 61. 1139 macAutoRequestKeyIdMode: the key identifier mode used for 1140 automatic data requests as described by IEEE 802.15.4 table 61. 1142 macAutoRequestKeySource: the originator of the key for automatic 1143 data requests as described by IEEE 802.15.4 table 61. 1145 macAutoRequestKeyIndex: the index of the key used for automatic 1146 data requests as described by IEEE 802.15.4 table 61. 1148 macDefaultKeySource: the originator of the default key used for 1149 key identifier mode 0x01 as described by IEEE 802.15.4 table 61. 1151 macPANCordinatorExtendedAddress: Address of the PAN coordinator as 1152 described by IEEE 802.15.4 table 61. 1154 macPANCordinatorShortAddress: Short address of the PAN coordinator 1155 as described by IEEE 802.15.4 table 61. 1157 2.4.9.2. CONFIGURE.security.macKeyTable 1159 Configures Security Keys. The command requires: 1161 KeyIdLookupList: list of keyIdLookupDescriptor Entries as defined 1162 by IEEE 802.15.4 table 61. 1164 DeviceDescriptorHandleList: Implementation specific list of 1165 devices that are using this key. As defined by IEEE 802.15.4 1166 table 61. 1168 KeyUsageList: List of slotframe types on which this key is being 1169 used as specified by IEEE 802.15.4 section 7.4.1.2 1170 Key: 16 octets key. As specified by IEEE 802.15.4 table 61. 1172 2.4.9.3. CONFIGURE.security.macSecurityLevelTable 1174 Configures the set of security levels. The command requires: 1176 FrameType: Slotframe type as defined by IEEE802.15.4e std. 1178 Command Identifier: The command identifier as defined by 1179 IEEE802.15.4e std. 1181 Security Minimum: The minimum required security level as specified 1182 by IEEE 802.15.4e 1184 Device Override Security Minimum: whether the minimum security 1185 level can be overridden as specified by IEEE 802.15.4 Table 64 1187 Allowed Security Levels: the key identifier field that identifies 1188 the key that is being used as specified by IEEE 802.15.4 section 1189 7.4.3 1191 2.4.9.4. Security Command Behavior 1193 6tus offers the interface to upper layers so underlying MAC layer can 1194 be configured. In that sense, 6tus acts as a "none-layer" by only 1195 delegating the functionalities to the MAC security services. For 1196 more details Section 7 on IEEE802.15.4-2011 and its amendments on 1197 IEEE802.15.4e-2012 should be referred. 1199 2.4.10. Data Commands 1201 2.4.10.1. Send.data 1203 The command used by upper layers to queue a packet so underlying TSCH 1204 sends it. According to the specific priority the packet is pushed 1205 into a Queue with the equivalent priority or following a criteria out 1206 of the scope of this document. Once a packet is inserted into a 1207 queue it waits to be transmitted by TSCH according to the model 1208 defined in Section 2.3. 1210 The required parameters are: 1212 src address: L2 source address 1214 dest address: L2 unicast or broadcast destination address 1216 priority: packet priority, usually is consistent with queue 1217 priority 1218 message length: the length of the message. 1220 message: control message or data message 1222 securityLevel:As defined by IEEE802.15.4e std. 1224 2.4.10.2. Receive.data 1226 The command is invoked whenever a packet is received and inserted 1227 into a reception queue. The method acts as a callback function to 1228 notify to the upper layers the received message. Upper layers MUST 1229 provide an implementation for that method. 1231 The function has the following parameters: 1233 src address: L2 source address 1235 dest address: L2 unicast or broadcast destination address 1237 priority: packet priority, usually is consistent with queue 1238 priority 1240 message length: the length of the message. 1242 message: control message or data message 1244 2.4.10.3. Data Command Behavior 1246 The following table describes the behavior of 6tus upon reception of 1247 the Data Communication Configuration management commands. 1249 Data Communication Management Operations behavior 1251 +---------------------------------+---------------------------------+ 1252 | 6tus commands | 6tus behavior | 1253 +---------------------------------+---------------------------------+ 1254 | Send.data(src,dest,prio, | The message is inserted in the | 1255 | len,msg,seclevel) | the queue corresponding to the | 1256 | | required priority. Fails if the | 1257 | | queue is full. Fails if the | 1258 | | destination address is not a | 1259 | | L2 neighbor of the node. | 1260 +---------------------------------+---------------------------------+ 1261 | Receive.data(src,dest,prio,len, | The method is invoked whenever a| 1262 | msg) | message is inserted in the queue| 1263 | | after successful reception. | 1264 +---------------------------------+---------------------------------+ 1266 Figure 4 1268 2.5. Message Formats 1270 6tus has to negotiate the scheduling of soft cells with neighbor 1271 nodes. This negotiation happens through 6tus-specific TSCH 1272 Information Elements, the format of which is defined in this section. 1273 This section also details the formats of the IEs defined in 1274 [IEEE802154e] and reused without modification. 1276 6tus messages can contain one or more IEs. Section 2.5.1 defines the 1277 different IEs used by 6tus, both the ones used without modification 1278 from [IEEE802154e], and the new ones defined by 6tus. Section 2.5.2 1279 shows how those IEs are assembled to form the different packets used 1280 by 6tus. 1282 2.5.1. Information Elements 1284 IEEE802.15.4e defines Information elements (IEs) which are formatted 1285 data objects consisting of an ID, a length, and a data payload used 1286 to pass data between layers or devices. IEEE802.15.4e defines Header 1287 IEs and Payload IEs; 6tus only uses Payload IEs. A Payload IE 1288 includes one or more IEs, and ends with a termination IE (ID = 0xf, 1289 see [IEEE802154e]). 1291 6tus uses the following Information Elements, in which the first four 1292 IEs are defined in IEEE802.15.4e, and other three IEs are introduced 1293 in this document. 1295 Defined in [IEEE802154e] and used by 6tus without modification: 1297 TSCH Synchronization IE (Section 2.5.1.1) 1299 TSCH Slotframe and Cell IE (Section 2.5.1.2) 1301 TSCH Timeslot Template IE (Section 2.5.1.3) 1303 TSCH Channel Hopping IE (Section 2.5.1.4) 1305 Defined by 6tus: 1307 6tus Opcode IE (Section 2.5.1.5) 1309 6tus Bandwidth IE (Section 2.5.1.6) 1311 6tus Generic Schedule IE (Section 2.5.1.7) 1313 2.5.1.1. TSCH Synchronization IE 1315 A Synchronization IE (SyncIE) contains Information allowing a node to 1316 synchronize to a TSCH network, including the current ASN and a join 1317 priority. Synchronization IE must be included in all TSCH Enhanced 1318 Beacons. 1320 6tus re-uses this IE as defined in [IEEE802154e]. 1322 Format of a TSCH Synchronization IE (SyncIE). 1324 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 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Length | SubID |T| ASN | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | ASN | Join Priority | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 Figure 5 1333 Length=6 1335 SubID=0x1a 1337 T=0, i.e. short type 1339 ASN (5 octets) contains the Absolute Slot Number corresponding to the 1340 timeslot in which the TSCH Enhanced Beacon is sent. 1342 The Join Priority can be used by a joining device to select among 1343 beaconing devices when multiple beacons are heard. The PAN 1344 coordinator's join priority is zero. A lower value of join priority 1345 indicates that the device is the preferred one to connect to. The 1346 beaconing device's join priority is the lowest join priority heard 1347 when it joined the network plus one. 1349 2.5.1.2. TSCH Slotframe and Cell IE 1351 The Slotframe and Cell IE (FrameAndCellIE) contains one or more 1352 slotframes and their respective cells that a beaconing device 1353 advertises to allow other devices to join the network. 1355 6tus re-uses this IE as defined in [IEEE802154e]. 1357 Format of a TSCH Slotframe and Cell IE (FrameAndCellIE). 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Length | SubID |T| NumFrame | | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1363 | | 1364 // Slotframe and cell information // 1365 | | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 Figure 6 1370 Length=variable 1372 SubID=0x1b 1374 T=0, i.e. short type 1376 NumFrame is set to the total number of slotframe descriptors 1377 contained in the TSCH Enhanced Beacon. 1379 Format of a slotframe descriptor. 1381 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 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | FrameID | FrameLen | NumCell | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | | 1386 // Cell information for each cell (5x NumCell) // 1387 | | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 Figure 7 1392 FrameID field shall be set to the slotframeHandle that uniquely 1393 identifies the slotframe. 1395 FrameLen field shall be set to the size of the slotframe in number of 1396 timeslots. 1398 NumCell field shall be set to the number of cells that belong to the 1399 specific slotframe identified by the slotframeHandle. 1401 Format of a Cell information. 1403 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 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | SlotOffset | ChannelOffset | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | LinkOption | 1408 +-+-+-+-+-+-+-+-+ 1410 Figure 8 1412 SlotOffset shall be set to the timeslot of this cell. 1414 ChannelOffset shall be set to the logic channel of this cell. 1416 LinkOption indicates whether this cell is a TX cell, an RX cell, or a 1417 SHARED TX cell, whether the device to which it is being linked is to 1418 be used for clock synchronization, and whether this cell is hard 1419 cell. 1421 2.5.1.3. TSCH Timeslot Template IE 1423 Timeslot Template IE (SlotTemplateIE) defines Timeslot template being 1424 used by the TSCH device. 1426 6tus re-uses this IE as defined in [IEEE802154e]. 1428 Format of a TSCH Timeslot Template IE (SlotTemplateIE). 1430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Length | SubID |T| TemplateID | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 Figure 9 1437 Length=1 1439 SubID=0x1c 1441 T=0, i.e. short type 1443 TemplateID shall be set to a Timeslot template handle. The full 1444 time-slot template, which contains the macTimeslotTemplate of TSCH 1445 (total 25 octets), may be included.(see IEEE802.15.4e). 1447 2.5.1.4. TSCH Channel Hopping IE 1449 Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being 1450 used by the TSCH device. 1452 6tus re-uses this IE as defined in [IEEE802154e]. 1454 Format of a TSCH Channel Hopping IE (ChHoppingIE). 1456 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Length | SubID |T| HopSequenceID | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 Figure 10 1463 Length=1 1465 SubID=0x09 1467 T=1, i.e. long type 1469 HopSequenceID shall be set to a Hopping Sequence handle. The full 1470 Hopping Sequence information may be included. (see IEEE802.15.4e). 1472 2.5.1.5. 6tus Opcode IE 1474 6tus Opcode IE (OpcodeIE) defines operation codes of packets in 6tus 1475 layer. 1477 This IE is not present in [IEEE802154e] and is defined by 6tus. 1479 Format of a 6tus Opcode IE (OpcodeIE). 1481 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | Length | SubID |T| OpcodeID | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 Figure 11 1488 Length=1 1490 SubID=0x41 1492 T=0, i.e. short type 1494 OpcodeID field shall be set to one of the following codes. 1496 0x00: Reserve Soft Cell Request 1498 0x01: Reserve Soft Cell Response 1500 0x02: Remove Soft Cell Request 1502 0x03: Reserve Hard Cell Request 1504 0x04: Remove Hard Cell Request 1506 2.5.1.6. 6tus Bandwidth IE 1508 Bandwidth IE (BwIE) defines the number of cells to be reserved or 1509 actually be reserved. 1511 This IE is not present in [IEEE802154e] and is defined by 6tus. 1513 Format of a 6tus Bandwidth IE (BwIE). 1515 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 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Length | SubID |T| FrameID | NumCell | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 Figure 12 1522 Length=2 1524 SubID=0x42 1525 T=0, i.e. short type 1527 FrameID field may be set to the SlotFrameHandle to identify the 1528 slotframe from which cells are reserved. FrameID field may be set to 1529 NOP, which means no specific slotframe is associated. 1531 NumCell field shall be set to the number of cells. When BwIE is 1532 combined with the OpecodeID of Reserve Soft Cell Request, NumCell 1533 presents how many cells are required to reserve; and when BwIE is 1534 combined with the OpecodeID of Reserve Soft Cell Response, NumCell 1535 presents how many cells are reserved successfully. 1537 2.5.1.7. 6tus Generic Schedule IE 1539 Generic Schedule IE (ScheduleIE) describes cell sets. In different 1540 packet, ScheduleIE represents different information. See 1541 Section 2.5.2 for more detail. 1543 This IE is not present in [IEEE802154e] and is defined by 6tus. 1545 Format of a 6tus Generic Schedule IE (ScheduleIE). 1547 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 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | Length | SubID |T| | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1551 | | 1552 // Schedule Body // 1553 | | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 Figure 13 1558 Length=variable 1560 SubID=0x43 1562 T=0, i.e. short type 1564 Schedule Body carries one or more schedule object. An object may 1565 carry a TLV, which may itself comprise other TLVs. TLV format is as 1566 follows. Type: 1 byte, Length: 1 byte, Value: variable 1568 The following are some examples of schedule object TLV. 1570 Example 1. Cell Set TLV 1571 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 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | Type=1 | Length | FrameID | NumCell |F| 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | | 1576 // CellObjects // 1577 | | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 Figure 14 1582 FrameID shall be set to the slotframeHandle that uniquely identifies 1583 the slotframe. 1585 NumCell shall be set to the number of cells that belong to the 1586 specific slotframe identified by the slotframeHandle. 1588 F=1 means the specified cells equals to what are listed in 1589 CellObjects, and F=0 means the specified cells equals to what are not 1590 listed in CellObjects. 1592 CellObjects carries the information for one or more cells, including 1593 SlotOffset, ChannelOffset, LinkOption (Figure 8). 1595 Example 2. Schedule Matrix TLV 1597 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 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Type=2 | Length | FrameID |StartSlotOffset| 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 |StartSLotOffset| NumSlot | | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1603 | | 1604 // SlotBitMap (2x NumSlot) // 1605 | | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 Figure 15 1610 FrameID field shall be set to the slotframeHandle that uniquely 1611 identifies the slotframe. 1613 StartSlotOffset field (2 octets) shall be set to the slotoffset in 1614 the specific slotframe identified by the slotframeHandle. 1616 NumSlot field shall be set to the number of slots from 1617 StartSlotOffset in the specific slotframe identified by the 1618 slotframeHandle. 1620 SlotBitMap (per slot) indicates for the given slot which channels are 1621 specified. For the 16 channels in 2.4GHz band, 2-octets are used to 1622 indicate which channel is specified. For example, given a slot and a 1623 SlotBitmap with value (10001000,00010000); the bitmap represents that 1624 ChannelOffset-0, ChannelOffset-4, ChannelOffset-11 are specified. 1626 2.5.2. Packet Formats 1628 This section describes the packets used in 6tus to form a network, 1629 reserve/maintain bandwidth using soft cells, and reserve/remove hard 1630 cells in both Tx side and Rx side. Each of these packets use one or 1631 more IEs defined in Section 2.5.1. 1633 2.5.2.1. TSCH Enhanced Beacon 1635 The TSCH Enhanced Beacon is used to announce the presence of the 1636 network and allow new nodes to join. It is and IEEE802.15.4e 1637 Enhanced Beacon packet with the following Payload IEs: 1639 TSCH Synchronization IE (Section 2.5.1.1) 1641 TSCH Timeslot Template IE (Section 2.5.1.3) 1643 TSCH Channel Hopping IE (Section 2.5.1.4) 1645 TSCH Slotframe and Cell IE (Section 2.5.1.2) 1647 Payload IE of TSCH Enhanced Beacon Packet 1649 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 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Length |GroupID|T| SyncIE | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | SyncIE | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | SyncIE | SlotTemplateIE | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 |SlotTemplateIE | ChHoppingIE | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | | 1660 // FrameAndCellIE // 1661 | | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 Figure 16 1666 Length=variable 1667 GroupID=0x1, i.e. MLME IE 1669 T=1, i.e. payload IE 1671 See Section 2.5.1.1, Section 2.5.1.3, Section 2.5.1.4,Section 2.5.1.2 1672 for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndCellIE. 1674 2.5.2.2. Soft Cell Reservation Request 1676 Soft Cell Reservation Request packet is formatted in Data packet of 1677 IEEE802.15.4e with following payload IE. 1679 Payload IE of Soft Cell Reservation Request 1681 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 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Length |GroupID|T| OpcodeIE | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | OpcodeIE | BwIE | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | BwIE | | 1688 +-+-+-+-+-+-+-+-+ | 1689 // ScheduleIE // 1690 | | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 Figure 17 1695 Length=variable 1697 GroupID=0x1, i.e. MLME IE 1699 T=1, i.e. payload IE 1701 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x00, 1702 indicates Reserve Soft Cell Request operation. 1704 The NumCell field in 4-octet BwIE should be set to the number of 1705 cells needed to be reserved. 1707 The ScheduleIE specifies a candidate cell set, from which the cells 1708 should be reserved. ScheduleIE may be empty, means there is no 1709 constrain on which cells should not be reserved. 1711 2.5.2.3. Soft Cell Reservation Response 1713 Soft Cell Reservation Response is formatted in Data packet of 1714 IEEE802.15.4e with following payload IE. 1716 Payload IE of Soft Cell Reservation Response 1718 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 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Length |GroupID|T| OpcodeIE | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | OpcodeIE | BwIE | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | BwIE | | 1725 +-+-+-+-+-+-+-+-+ | 1726 // ScheduleIE // 1727 | | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 Figure 18 1732 Length=variable 1734 GroupID=0x1, i.e. MLME IE 1736 T=1, i.e. payload IE 1738 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x01, 1739 indicates Reserve Soft Cell Response operation. 1741 The NumCell field in 4-octet BwIE should be set to the number of 1742 cells which have been reserved successfully. 1744 The ScheduleIE should specify all of the cells which have been 1745 reserved successfully. 1747 2.5.2.4. Soft Cell Remove Request 1749 Soft Cell Remove Request is formatted in a Data packet of 1750 IEEE802.15.4e with the following payload IE. 1752 Payload IE of Soft Cell Remove Request 1754 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 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Length |GroupID|T| OpcodeIE | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | OpcodeIE | | 1759 +-+-+-+-+-+-+-+-+ | 1760 // ScheduleIE // 1761 | | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 Figure 19 1766 Length=variable 1768 GroupID=0x1, i.e. MLME IE 1770 T=1, i.e. payload IE 1772 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x02, 1773 indicates Remove Soft Cell Request operation. 1775 The ScheduleIE should specify all the cells that need to be removed. 1777 2.5.2.5. Hard Cell Reservation Request 1779 Hard Cell Reservation Request packet is formatted in Data packet of 1780 IEEE802.15.4e with following payload IE. 1782 Payload IE of Hard Cell Reservation Request 1784 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 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Length |GroupID|T| OpcodeIE | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | OpcodeIE | | 1789 +-+-+-+-+-+-+-+-+ | 1790 // ScheduleIE // 1791 | | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 Figure 20 1796 Length=variable 1798 GroupID=0x1, i.e. MLME IE 1799 T=1, i.e. payload IE 1801 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x03, 1802 indicates Reserve Hard Cell Request operation. 1804 The ScheduleIE should specify all the cell that need to be reserved. 1806 2.5.2.6. Hard Cell Remove Request 1808 Hard Cell Remove Request is formatted in a Data packet of 1809 IEEE802.15.4e with the following payload IE. 1811 Payload IE of Hard Cell Remove Request 1813 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 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Length |GroupID|T| OpcodeIE | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | OpcodeIE | | 1818 +-+-+-+-+-+-+-+-+ | 1819 // ScheduleIE // 1820 | | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 Figure 21 1825 Length=variable 1827 GroupID=0x1, i.e. MLME IE 1829 T=1, i.e. payload IE 1831 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x04, 1832 indicates Remove Hard Cell Request operation. 1834 The ScheduleIE should specify all the cells that need to be removed. 1836 2.6. Time Sequence 1838 6tus neighbors exchange 6tus-specific packets in the following cases, 1839 each detailed in a subsection. 1841 Network formation is detailed in Section 2.6.1. 1843 Creating soft cells is detailed in Section 2.6.2. 1845 Deleting soft cells is detailed in Section 2.6.3. 1847 Maintaining soft cells is detailed in Section 2.6.4. 1849 Creating hard cells is detailed in Section 2.6.5. 1851 Deleting hard cells is detailed in Section 2.6.6. 1853 2.6.1. Network Formation 1855 Network formation consists of two processes: joining and maintenance. 1857 2.6.1.1. Joining 1859 A node already in the network sends out TSCH Enhanced Beacons 1860 periodically. 1862 When a node is joining an existing network, it listens for TSCH 1863 Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs 1864 (the format of which is detailed in Section 2.5.2.1), the joining 1865 node must do the following. 1867 Initialize a neighbor table. Establish a neighbor table and 1868 record all of the information described in the TSCH Enhanced 1869 BEACONs as its initial schedule with those neighbors. 1871 Select a time source neighbor. According to the Joining Priority 1872 described by SyncIEs, the joining node chooses one or more of the 1873 advertisers as its time source neighbors. 6tus does not specify 1874 the criteria to choose time source neighbors from the Enhanced 1875 BEACONs. 1877 Select cells for Enhanced Beacons. The joining node selects one 1878 or more cells to broadcast its own Enhanced Beacons, which may be 1879 same as the cells used by its neighbors for Enhanced Beacon 1880 broadcast, and record those cell(s) into the TSCH schedule with 1881 LinkType=ADVERTISING. 1883 From its Enhanced Beacons, including the cell(s) for its Enhanced 1884 Beacon, which LinkOption should be set to "Receive" and 1885 "Timekeeping", telling its neighbors that the cell is used for 1886 broadcast. 1888 Start broadcasting Enhanced Beacon and communicate with neighbors. 1890 2.6.1.2. Maintenance 1892 Nodes may broadcast Enhance Beacons on the cells marked with 1893 LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors 1894 on the cells with LinkOption = "Receive" and "Timekeeping". If a 1895 cell with both LinkType=ADVERTISING has both the "Receive" and 1896 "Timekeeping" LinkOption, it is shared by neighbors and itself to 1897 broadcast, then broadcast Enhanced Beacon has higher priority. 1899 Whenever a node receives an Enhanced Beacon, it must update its 1900 schedule if there is a difference. 1902 2.6.2. Creating soft cells 1904 The upper layer instructs 6tus to schedule one or more soft cells by 1905 calling the Create soft cell command. This command can also be 1906 called by the monitoring process internal to 6tus. 1908 When receiving a Create soft cell command, Node A's 6tus layer forms 1909 a Soft Cell Reservation Request packet which includes BwIE and 1910 ScheduleIE. The BwIE includes the number of cells needed to be 1911 reserved (N1), and ScheduleIE includes a candidate cell set from 1912 which the new cells should be selected. If the ScheduleIE is empty, 1913 Node A indicates there is no constraint on cell selection. The Soft 1914 Cell Reservation Request is then sent to the neighbor (Node B) with 1915 whom new cells need to be added. After receiving the Soft Cell 1916 Reservation Request, Node B selects the cells from the candidate cell 1917 set defined by the ScheludeIE in the Soft Cell Reservation Request, 1918 and forms a Soft Cell Reservation Response packet, in which BwIE 1919 indicates the number of cells actually being reserved (N2), and 1920 ScheduleIE indicates those reserved cells. If N2 is smaller than N1, 1921 node B indicates to node A that there are not enough qualified cells 1922 to be reserved. Node B must record the reserved cells into its local 1923 schedule while sending out Soft Cell Reservation Response. After 1924 receiving the Soft Cell Reservation Response, Node A must record the 1925 reserved cells into its local schedule. 1927 The policy to build a candidate cell set and the policy to select 1928 cells from the candidate cell set to reserve is flexiable. For 1929 example, the candidate cell set can be all of the cells not used by 1930 Node A, and Node B can randomly choose N1 cells, which are not used 1931 by Node B, from the candidate cell set. 1933 The expression of Schedule Body is flexible. For example, Node A can 1934 use Cell Set TLV defined in Figure 14 with field 'F' set to '0', and 1935 the CellObjects includes all of the cells being used by Node A. In 1936 another word, the cell candidate set is all of the cells not being 1937 included in the list defined by CellObjects. 1939 The policy to deal with the failure or not fully satisfaction in a 1940 soft cell Reservation process is flexible. For example, Node A may 1941 initiate another soft cell reservation procedure, or simply report to 1942 upper layer. 1944 2.6.3. Deleting soft cells 1946 The upper layer instructs 6tus to delete one or more soft cells by 1947 calling the Delete soft cell command. This command can also be 1948 called by the monitoring process internal to 6tus. 1950 When receiving a Delete soft cell command, Node A's 6tus layer 1951 selects cells to be removed from its local schedule, and creates a 1952 Soft Cell Remove Request, including a ScheduleIE. The ScheduleIE 1953 indicates which specific cells to remove with a neighbor (Node B). 1954 The cells specified in the ScheduleIE should be removed from local 1955 schedule of Node A while the Soft Cell Remove Request is sent to Node 1956 B. When receiving the Soft Cell Remove Request, the cells specified 1957 in the ScheduleIE should be removed from the local schedule of Node 1958 B. 1960 The policy to select cells corresponding to a Delete soft cell 1961 command is out of scope. 1963 2.6.4. Maintaining soft cells 1965 The monitoring process internal to 6tus (Section 2.8) is responsible 1966 for monitoring and re-scheduling soft cells to meet some QoS 1967 requirements. The monitoring process may issue a soft cell 1968 Maintenance command, which indicate a set of cells to be moved in the 1969 TSCH schedule. 1971 When a receiving a soft cell Maintenance command, 6tus initializes a 1972 Soft Cell Remove Request (Section 2.6.3) with the neighbor in 1973 question, followed by a Soft Cell Reservation Request 1974 (Section 2.6.2). 1976 2.6.5. Creating hard cells 1978 The upper layer instructs 6tus to create one or more hard cells by 1979 calling the Create hard cell command. 1981 When receiving a Create hard cell command, Node A's 6tus layer 1982 creates a Hard Cell Reservation Request, including a ScheduleIE. The 1983 ScheduleIE indicates which specific cells with a neighbor (Node B) to 1984 be added. The cells specified in the ScheduleIE should be added in 1985 local schedule of Node A while the Hard Cell Reserve Request is sent 1986 to Node B. When receiving the Hard Cell Reserve Request, the cells 1987 specified in the ScheduleIE should be added in the local schedule of 1988 Node B. 1990 2.6.6. Deleting hard cells 1992 The upper layer instructs 6tus to delete one or more hard cells by 1993 calling the Delete hard cell command. 1995 When receiving a Delete hard cell command, Node A's 6tus layer 1996 creates a Hard Cell Remove Request, including a ScheduleIE. The 1997 ScheduleIE indicates which specific cells with a neighbor (Node B) to 1998 be removed. The cells specified in the ScheduleIE should be removed 1999 from local schedule of Node A while the Hard Cell Remove Request is 2000 sent to Node B. When receiving the Hard Cell Remove Request, the 2001 cells specified in the ScheduleIE should be removed from the local 2002 schedule of Node B. 2004 2.7. Statistics 2006 The 6tus Statistics Fuction (SF) is responsible for collecting 2007 statistics, which it can provide to an upper layer and the Monitoring 2008 Function (Section 2.8). 2010 2.7.1. Statistics Metrics 2012 6tus is in charge of keeping statistics from a set of metrics 2013 gathered from the behavior of the TSCH layer. 2015 The statistics data related to node states and cell metrics should be 2016 provided to upper layer for management, e.g. for RPL to calculate 2017 Rank or to GMPLS to determine whether the link in a multi-hop path is 2018 meeting the required bandwidth. The specific algorithm to generate 2019 the statistics is implementation dependent and hence out of the scope 2020 of this document. However, the statistics component should include 2021 the following metrics: 2023 1. LinkThroughput: associated with a link, Node A->Node B. For 2024 example, LinkThroughput can be calculated with: 2025 SUM(NumOfCell(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration) 2026 where NumOfCell(i) is the total number of cells from Node A to 2027 Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i. 2029 2. Latency: associated with a link, Node A->Node B. For example, 2030 latency can be expressed as Minimum and Maximum Latency. Minimum 2031 Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum 2032 Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where, 2033 MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum 2034 number of slots between two dedicated cells from Node A to Node B 2035 in Slotframe-i, respectively. 2037 3. LinkQuality. For example, average LQI, ETX; 2039 4. TafficLoad. For example, Queue Full Rate, Queue Empty Rate; 2041 5. NodeEnergy. For example, E_E=E_bat / [E_0 (T-t)/T]. 2043 2.7.2. Statistics Configuration 2045 Statistics Function should be configurable. The configuration 2046 parameters should include: 2048 LinkQualityStatisticsEn. 2050 TafficLoadStatisticsEn. 2052 DeviceStatisticsEn. 2054 6tus statistics function is enabled/disabled and configured by the 2055 commands defined in Section 2.4.4 2057 2.8. Monitoring 2059 Monitoring Fuction (MF) in 6tus is responsible for monitoring cell 2060 quality, traffic load, and issuing soft cell Maintenance command, or 2061 Create/Delete soft cell command. The data provided by Statistics 2062 Function may be used as a input of MF in making monitoring decision. 2064 2.8.1. Monitor Configuration 2066 Monitoring Function should be configurable. The configuration 2067 parameters should include: 2069 MaintainCellEn. 2071 CreateDeleteCellEn. 2073 QosLevel. QosLevel should associate with specific neighbor 2074 address. QosLevel may reflect the latency constraint, cell 2075 quality constraint, and so on. The value of QosLevel works as the 2076 bandwidth redundancy coefficient. 2078 6tus monitoring function is enabled/disabled and configured by the 2079 commands defined in Section 2.4.3 2081 2.8.2. Actuation 2083 The cell quality statistics may be used to generate soft cell 2084 Maintenance command, which leads to a soft cell Maintenance procedure 2085 (see Section 2.6.4). The traffic load statistics may be used to 2086 generate internal Create/Delete soft cell commands, which leads to a 2087 soft cell Reservation process or a soft cell Remove process, 2088 respectively. (see Section 2.6.2 and Section 2.6.3) 2090 The policy to generate the soft cell Maintenance command and the 2091 policy to generate Create/Delete soft cell commands is out of the 2092 scope. 2094 The policy to generate Create/Delete soft cell commands may take 2095 QosLevel into account. For example, there are two slotframes 2096 existing, Slotframe-1 consists of 32 slots, Slotframe-2 consists of 2097 96 slots; Slot duration is 10ms; QosLevel=1.5. If, from the traffic 2098 load statistics, MF figures out 2 packet/second should be added, then 2099 it leads to a Create soft cell command, where FrameID=2, NumCell=3. 2101 3. Using 6tus 2103 This part describes how 6tus gives support to specific upper layers. 2105 3.1. RPL on 6tus 2107 6tus provides a set of functionalities so higher layers can obtain 2108 information about the status of the network and take advantage of the 2109 slotted structure to improve metric calculation and objective 2110 function optimization. The following sections describe how RPL can 2111 make use of 6tus layer. 2113 In order to optimize the combination of RPL and TSCH, 6tus provides 2114 specific support to RPL in the following aspects: 2116 RPL Neighbor Discovery and Parent Selection 2118 RPL Rank Computation 2120 RPL Control Messages Broadcast 2122 QoS 2124 3.1.1. Support to Neighbor Discovery and Parent Selection 2125 The Section 2.4.7 defines a set of commands so the neighbor table can 2126 be managed and queried by RPL. An entry to the neighbor table is 2127 inserted whenever an EBs is received at L2. The EB causes the 6tus 2128 layer to create an entry to the neighbors table. A neighbor table 2129 entry contains a set of statistics with respect to that specific 2130 neighbor such as the ASN when the last packet has been received from 2131 that neighbor, a set of cell quality metrics (RSSI, LQI), number of 2132 packets sent to it or number of packets received from it amongst 2133 others. 6tus updates that table upon sending or reception of a 2134 packet from/to a neighbor. RPL can query at any time the neighbor 2135 table to retrieve information about a particular neighbor. This 2136 information can be used to compute the routing objective function as 2137 for example the inverse of the Probability Delivery Ratio (PDR). 2138 Parent selection can also be driven by the information contained on 2139 the neighbor table as well as complemented with the cells statistics 2140 defined in Section 2.4.4 and Section 2.7. 2142 6tus enables RPL to configure EB periodicity. By controlling the EBs 2143 periodicity, RPL can configure how network dynamism and support to 2144 mobility are addressed, as more frequent beacons the more prone to 2145 cope with mobility. Section 2.4.5 enables to configure how the 2146 network is formed and EBs periodicity. 2148 RPL may want to select the policy to determine the time source 2149 neighbor, this can be interesting when time source neighbors can be 2150 aligned to the routing topology, i.e, the selected time source 2151 neighbor can be the node's favorite parent in a specific DODAG. 2152 Section 2.4.6 describes the 6tus command to setup the desired policy. 2153 The policy is selected by RPL and enforced by 6tus layer. 2155 The rule for 6tus to select and maintain time sources is as follows. 2157 Time source of one node should be one member of the node's 2158 neighbor set. 2160 Time sources should be the neighbors which have relatively lower 2161 Join Priority in the neighbor set. Lower Join Priority means 2162 closer to TSCH Pan coordinator. 2164 The link from a node to its time sources should be in a good link 2165 quality. 2167 3.1.2. Support to Rank Computation 2169 RPL objective function is computed by a set of metrics. The specific 2170 metrics and how the objective function is calculated are out of the 2171 scope of the present document, however, 6tus builds a set of 2172 functionalities to provide more accurate statistics of the underlying 2173 layer so the objective function can be accommodated to the nature of 2174 a TSCH MAC layer. 2176 6tus provides Statistics for Rank computation as described in 2177 sections(Section 2.4.4 and Section 2.7). The function to compute the 2178 Rank based on those statistics is out of scope of 6tus, however the 2179 provided metrics are aligned to the behavior of the TSCH MAC layer. 2181 3.1.3. Support to Control Messages Broadcast 2183 In RPL, some control messages, e.g. DIO, and DAO in sorting mode, 2184 need to be broadcasted to the neighbors. The broadcast channel 2185 requirement has to be addressed by 6tus by configuring TSCH to 2186 provide such a channel. 2188 In order to decouple the upper (RPL) layer to TSCH, instead of 2189 carrying DIO message in the Enhance Beacon, 6tus introduces a 2190 mechanism to establish broadcast cells. 2192 In TSCH schedule, every cell has the LinkType attribute. If 2193 LinkType=ADVERTISING, indicates that the cell may be used to send an 2194 Enhanced Beacon. When a node forms its Enhanced Beacon, the cell, 2195 with LinkType=ADVERTISING, should be included in the FrameAndCellIE, 2196 and its LinkOption field should be set to the combination of 2197 "Receive" and "Timekeeping". The receiver of the Enhanced Beacon may 2198 listen to at the cell to get the Enhanced Beacon ([IEEE802154e]). 2199 6tus takes this way to establish broadcast channel, which not only 2200 allows TSCH broadcast Enhanced Beacon, but also allows an upper layer 2201 like RPL broadcast. 2203 To support DIO and DAO broadcast, 6tus uses the payload of a Data 2204 Packet to carry the DIO or DAO. The message is inserted into the 2205 queue associated with the cells which LinkType is set to ADVERTISING. 2206 Then, taking advantage of the broadcast cell feature established with 2207 FrameAndCellIE as described above, the data packet with DIO or DAO in 2208 payload can be received by neighbors, which leads to the maintenance 2209 of DODAG. 2211 The LinkOption of combining "Receive" and "Timekeeping" let the 2212 receivers of the Enhanced Beacon understand that the cell is used as 2213 broadcast cell. But the frequency of sending Enhance Beacon or other 2214 broadcast messages by upper layer is determined by the timers 2215 associated with the messages, e.g. Enhance Beacon is triggered by 2216 the timer in 6tus, and the DIO message is triggered by the trickle 2217 timer of RPL. Therefore, for energy efficiency, receivers can have 2218 some policy to wake up at the broadcast cell, but it is 2219 implementation dependent. 2221 3.1.4. Support to QoS 2223 TSCH MAC layer is decoupled from the upper layers and its interaction 2224 with them is asynchronous. This means that the MAC layer executes a 2225 schedule and checks at each slot according to the type of cell 2226 whether there is something to send or receive. If that is the case 2227 the packet is sent and the MAC layer continues its operation. When 2228 an upper layer sends a packet, this packet is pushed into a queue 2229 waiting to the MAC layer to read it and sent it in a particular slot 2230 according to is destination and priority (Section 2.3). 6tus 2231 provides a set of queue management operations which enable upper 2232 layers to create different queues and determine their priorities. In 2233 that sense different classes of traffic can be handled by the routing 2234 layer, i.e inserting a packet to a specific queue according to its 2235 priority. 2237 6tus provides at least a Broadcast Queue, a Transmit Queue, and a 2238 Receive Queue. RPL can configure the queues with Internal Queueing 2239 Command (Section 2.4.8.1). Broadcast Queue are associated with cells 2240 with LinkType=ADVERTISING in sender's schedule, and 2241 LinkOption="Receive" and "Timekeeping" in all neighbors' schedule. 2242 That indicates the cells can be used for broadcast from the sender to 2243 its neighbors. Transmit Queues are associated with the dedicated 2244 Transmit cells or Shared Cells. RPL can benefit from having 2245 different priority queues in order to improve latency or provide 2246 integrated services with different priorities, i.e different traffic 2247 classes. 2249 Data Communication Command (Section 2.4.10) can be used to send 2250 control messages and data messages. The operation is used to insert 2251 a message to an specific queue. 2253 For example a suitable configuration can include two Broadcast Queues 2254 with priority High and Low, respectively; three Transmit Queues, with 2255 priority High, Mid, and Low, respectively; and one Receive Queue. 2257 When DestAddr is a broadcast address, its related MAC layer packets 2258 will be pushed into the Broadcast Queue with the corresponding 2259 priority. 6tus is responsible for feeding these packets to TSCH at 2260 broadcast cells. 2262 When DestAddr is unicast address, its related MAC layer packets will 2263 be push into the Transmit Queue with corresponding priority. 6tus is 2264 responsible for feeding these packets to TSCH at Transmit cells or 2265 Shared Cells. 2267 6tus conducts a QoS policy, which is out of scope. Here is an 2268 example. Packets in higher priority queue MUST be sent out before 2269 the packets in lower priority queue. Then, when there is an 2270 available broadcast/unicast cell, 6tus checks the broadcast/unicast 2271 queue with higher priority first, if there is a packet, then feed it 2272 to TSCH at the cell, otherwise checks broadcast/unicast queue with 2273 lower priority further. Repeat the process, until find a broadcast/ 2274 unicast packet to feed to TSCH or find all of broadcast/unicast 2275 queues are empty. 2277 3.2. GMPLS on 6tus 2279 GMPLS is a 2.5 layer service that is used to forward packets based on 2280 the concept of generalized label. Labels are determined by a 2281 reservation protocol during the formation of a multi-hop path. As 2282 defined by [RFC3471],[RFC3473] and [RFC4606] a generalized label 2283 identifies a flow of data through a set of nodes that conform to a 2284 multi-hop path. Instead of being appended to each packet as is the 2285 case in MPLS [RFC3031], the generalized label it is kept at each node 2286 in the form of a table. The table can be used to map input cells to 2287 output cells so routing decisions can be taken at that layer. 2289 In order to optimize the combination of GMPLS and TSCH, 6tus provides 2290 specific support to GMPLS in the following aspects: 2292 Cell Reservation Support 2294 QoS 2296 3.2.1. Cell Reservation Support for GMPLS on 6tus 2298 The GMPLS control plane is used to send path reservation requests and 2299 reservation confirmations. When reservation confirmations are 2300 received, GMPLS needs to configure the underlying MAC layer to 2301 provide the required bandwidth. 6tus provides a set of commands to 2302 deal with bandwidth allocation, i.e. cell allocation. Section 2.4.1 2303 describes the operations that GMPLS layer may use for cell 2304 configuration. Note that 6tus supports different types of 2305 reservations: soft cell and hard cell. How the reservation 2306 requirements are expressed is out of scope of this document, but 6tus 2307 is able to handle a reservation done as a specific bandwidth 2308 requirement, done through specifying exact cells. 2310 GMPLS can also give different priorities to its control plane and 2311 data plane. It can for example be interesting to have a higher 2312 priority for control messages so the network adapts to new bandwidth 2313 requirements quickly. In contrast, data plane messages can be given 2314 a higher priority when they need to meet higher throughput or lower 2315 latency. 6tus provides commands (Section 2.4.8) to manage MAC layer 2316 queues and assign different priorities to them. 2318 3.2.2. Supporting QoS 2320 GMPLS can use 6tus statistics to determine whether some QoS 2321 requirement is met. Metrics defined in Section 2.7 and operations 2322 defined in Section 2.4.4.4 can be used by GMPLS to trigger new 2323 bandwidth allocation, or to map different input bundles to output 2324 bundles. 2326 4. References 2328 4.1. Normative References 2330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2331 Requirement Levels", BCP 14, RFC 2119, March 1997. 2333 4.2. Informative References 2335 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2336 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2337 Functional Specification", RFC 2205, September 1997. 2339 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2340 Networks", RFC 2464, December 1998. 2342 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2343 Label Switching Architecture", RFC 3031, January 2001. 2345 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2346 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2348 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 2349 (GMPLS) Signaling Functional Description", RFC 3471, 2350 January 2003. 2352 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2353 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2354 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2356 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2357 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2358 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2359 RFC 3819, July 2004. 2361 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 2362 Protocol Label Switching (GMPLS) Extensions for 2363 Synchronous Optical Network (SONET) and Synchronous 2364 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 2366 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2367 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2368 Overview, Assumptions, Problem Statement, and Goals", RFC 2369 4919, August 2007. 2371 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2372 "Transmission of IPv6 Packets over IEEE 802.15.4 2373 Networks", RFC 4944, September 2007. 2375 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 2376 "Routing Requirements for Urban Low-Power and Lossy 2377 Networks", RFC 5548, May 2009. 2379 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 2380 Routing Requirements in Low-Power and Lossy Networks", RFC 2381 5826, April 2010. 2383 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 2384 "Building Automation Routing Requirements in Low-Power and 2385 Lossy Networks", RFC 5867, June 2010. 2387 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 2388 "Industrial Routing Requirements in Low-Power and Lossy 2389 Networks", RFC 5673, October 2009. 2391 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 2392 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2393 September 2011. 2395 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 2396 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 2397 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 2398 Lossy Networks", RFC 6550, March 2012. 2400 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 2401 Application Spaces for IPv6 over Low-Power Wireless 2402 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 2404 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 2405 Statement and Requirements for IPv6 over Low-Power 2406 Wireless Personal Area Network (6LoWPAN) Routing", RFC 2407 6606, May 2012. 2409 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 2410 for OAuth", RFC 6755, October 2012. 2412 [I-D.thubert-roll-forwarding-frags] 2413 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 2414 Recovery", draft-thubert-roll-forwarding-frags-01 (work in 2415 progress), February 2013. 2417 [I-D.tsao-roll-security-framework] 2418 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 2419 Security Framework for Routing over Low Power and Lossy 2420 Networks", draft-tsao-roll-security-framework-02 (work in 2421 progress), March 2010. 2423 [I-D.thubert-roll-asymlink] 2424 Thubert, P., "RPL adaptation for asymmetrical links", 2425 draft-thubert-roll-asymlink-02 (work in progress), 2426 December 2011. 2428 [I-D.ietf-roll-terminology] 2429 Vasseur, J., "Terminology in Low power And Lossy 2430 Networks", draft-ietf-roll-terminology-12 (work in 2431 progress), March 2013. 2433 [I-D.ietf-roll-p2p-rpl] 2434 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 2435 Martocci, "Reactive Discovery of Point-to-Point Routes in 2436 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17 2437 (work in progress), March 2013. 2439 [I-D.ietf-roll-trickle-mcast] 2440 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 2441 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 2442 mcast-04 (work in progress), February 2013. 2444 [I-D.thubert-6lowpan-backbone-router] 2445 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 2446 6lowpan-backbone-router-03 (work in progress), February 2447 2013. 2449 [I-D.sarikaya-core-sbootstrapping] 2450 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 2451 Cragie, "Security Bootstrapping Solution for Resource- 2452 Constrained Devices", draft-sarikaya-core- 2453 sbootstrapping-04 (work in progress), April 2012. 2455 [I-D.gilger-smart-object-security-workshop] 2456 Gilger, J. and H. Tschofenig, "Report from the 'Smart 2457 Object Security Workshop', 23rd March 2012, Paris, 2458 France", draft-gilger-smart-object-security-workshop-00 2459 (work in progress), October 2012. 2461 [I-D.phinney-roll-rpl-industrial-applicability] 2462 Phinney, T., Thubert, P., and R. Assimiti, "RPL 2463 applicability in industrial networks", draft-phinney-roll- 2464 rpl-industrial-applicability-02 (work in progress), 2465 February 2013. 2467 [I-D.ietf-core-coap] 2468 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 2469 Application Protocol (CoAP)", draft-ietf-core-coap-16 2470 (work in progress), May 2013. 2472 [I-D.watteyne-6tsch-tsch-lln-context] 2473 Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: 2474 Overview, Problem Statement and Goals", draft-watteyne- 2475 6tsch-tsch-lln-context-01 (work in progress), February 2476 2013. 2478 [I-D.draft-palattella-6tsch-terminology] 2479 Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. 2480 Wang, "Terminology in IPv6 over Time Slotted Channel 2481 Hopping. draft-palattella-6tsch-terminology-00 (work in 2482 progress) ", March 2013. 2484 [I-D.draft-thubert-6tsch-architecture] 2485 Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An 2486 Architecture for IPv6 over Time Synchronized Channel 2487 Hopping. draft-thubert-6tsch-architecture-00 (work in 2488 progress) ", March 2013. 2490 4.3. External Informative References 2492 [IEEE802154e] 2493 IEEE standard for Information Technology, "IEEE std. 2494 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2495 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 2496 2012. 2498 [IEEE802154] 2499 IEEE standard for Information Technology, "IEEE std. 2500 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2501 and Physical Layer (PHY) Specifications for Low-Rate 2502 Wireless Personal Area Networks", June 2011. 2504 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , 2505 . 2507 Authors' Addresses 2508 Qin Wang (editor) 2509 Univ. of Sci. and Tech. Beijing 2510 30 Xueyuan Road 2511 Beijing, Hebei 100083 2512 China 2514 Phone: +86 (10) 6233 4781 2515 Email: wangqin@ies.ustb.edu.cn 2517 Xavier Vilajosana 2518 Universitat Oberta de Catalunya 2519 156 Rambla Poblenou 2520 Barcelona, Catalonia 08018 2521 Spain 2523 Phone: +34 (646) 633 681 2524 Email: xvilajosana@uoc.edu 2526 Thomas Watteyne 2527 Linear Technology 2528 30695 Huntwood Avenue 2529 Hayward, CA 94544 2530 USA 2532 Phone: +1 (510) 400-2978 2533 Email: twatteyne@linear.com