idnits 2.17.1 draft-wang-6tisch-6top-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([IEEE802154e]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the TrackID is set to (0,0), the cell can be used by the best-effort QoS configuration or as a Shared cell. If the TrackID is not set to (0,0), i.e., the cell belongs to a specific track, the cell MUST not be set as Shared cell. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The ScheduleIE specifies a candidate cell set, from which the cells SHOULD be reserved. ScheduleIE MAY be empty, means there is no constrain on which cells SHOULD not be reserved. -- The document date (October 20, 2013) is 3834 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 2525, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 2531, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 2537, but not defined == Unused Reference: 'RFC2119' is defined on line 2352, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 2357, but no explicit reference was found in the text == Unused Reference: 'RFC2464' is defined on line 2361, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 2367, but no explicit reference was found in the text == Unused Reference: 'RFC3819' is defined on line 2378, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 2388, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 2393, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 2397, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 2401, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 2405, but no explicit reference was found in the text == Unused Reference: 'RFC5673' is defined on line 2409, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 2413, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 2417, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 2422, but no explicit reference was found in the text == Unused Reference: 'RFC6606' is defined on line 2426, but no explicit reference was found in the text == Unused Reference: 'RFC6755' is defined on line 2431, but no explicit reference was found in the text == Unused Reference: 'I-D.palattella-6tisch-terminology' is defined on line 2446, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tsch-security' is defined on line 2457, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 2463, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 2468, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 2474, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 2479, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 2484, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 2490, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 2495, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 2500, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 2506, but no explicit reference was found in the text == Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is defined on line 2512, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap' is defined on line 2518, 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 (-01) exists of draft-thubert-6tisch-architecture-00 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-05 == 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 Summary: 3 errors (**), 0 flaws (~~), 40 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: April 23, 2014 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 October 20, 2013 10 6TiSCH Operation Sublayer (6top) 11 draft-wang-6tisch-6top-00 13 Abstract 15 The recently published [IEEE802154e] standard formalizes the concept 16 of link-layer resources in LLNs. Nodes are synchronized and follow a 17 schedule. A cell in that schedule corresponds to an atomic link- 18 layer resource, and can be allocated to any pair of neighbors in the 19 network. This allows the schedule to be built to tightly match each 20 node's bandwidth, latency and energy constraints. The [IEEE802154e] 21 standard does not, however, present a mechanism to do so, as building 22 and managing the schedule is out of scope of the standard. This 23 document describes the 6TiSCH Operation Sublayer (6top) and the 24 commands it provides to upper network layers such as RPL or GMPLS. 25 The set of functionalities includes feedback metrics from cell states 26 so network layers can take routing decisions, TSCH configuration and 27 control procedures, and the support for decentralized and centralized 28 scheduling. In addition, 6top can be configured to enable packet 29 switching at layer 2.5, analogous to GMPLS. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 23, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. 6TiSCH Operation Sublayer (6top) . . . . . . . . . . . . . . 4 67 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2.1. hard cells . . . . . . . . . . . . . . . . . . . . . 7 70 2.2.2. soft cells . . . . . . . . . . . . . . . . . . . . . 7 71 2.3. Data Convey Model . . . . . . . . . . . . . . . . . . . . 7 72 2.4. Commands . . . . . . . . . . . . . . . . . . . . . . . . 9 73 2.4.1. Cell Commands . . . . . . . . . . . . . . . . . . . . 11 74 2.4.2. Slotframe Commands . . . . . . . . . . . . . . . . . 14 75 2.4.3. Monitoring Commands . . . . . . . . . . . . . . . . . 15 76 2.4.4. Statistics Commands . . . . . . . . . . . . . . . . . 16 77 2.4.5. Network Formation Commands . . . . . . . . . . . . . 17 78 2.4.6. Time Source Neighbor Commands . . . . . . . . . . . . 19 79 2.4.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 20 80 2.4.8. Queueing Commands . . . . . . . . . . . . . . . . . . 21 81 2.4.9. Security Commands . . . . . . . . . . . . . . . . . . 23 82 2.4.10. Data Commands . . . . . . . . . . . . . . . . . . . . 25 83 2.4.11. Label Switching Commands . . . . . . . . . . . . . . 26 84 2.5. Message Formats . . . . . . . . . . . . . . . . . . . . . 27 85 2.5.1. Information Elements . . . . . . . . . . . . . . . . 27 86 2.5.2. Packet Formats . . . . . . . . . . . . . . . . . . . 35 87 2.6. Time Sequence . . . . . . . . . . . . . . . . . . . . . . 40 88 2.6.1. Network Formation . . . . . . . . . . . . . . . . . . 40 89 2.6.2. Creating soft cells . . . . . . . . . . . . . . . . . 41 90 2.6.3. Deleting soft cells . . . . . . . . . . . . . . . . . 42 91 2.6.4. Maintaining soft cells . . . . . . . . . . . . . . . 42 92 2.6.5. Creating hard cells . . . . . . . . . . . . . . . . . 43 93 2.6.6. Deleting hard cells . . . . . . . . . . . . . . . . . 43 94 2.7. Statistics . . . . . . . . . . . . . . . . . . . . . . . 43 95 2.7.1. Statistics Metrics . . . . . . . . . . . . . . . . . 43 96 2.7.2. Statistics Configuration . . . . . . . . . . . . . . 44 97 2.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 44 98 2.8.1. Monitor Configuration . . . . . . . . . . . . . . . . 44 99 2.8.2. Actuation . . . . . . . . . . . . . . . . . . . . . . 45 100 2.9. Label Switching . . . . . . . . . . . . . . . . . . . . . 45 101 3. Using 6top . . . . . . . . . . . . . . . . . . . . . . . . . 46 102 3.1. RPL on 6top . . . . . . . . . . . . . . . . . . . . . . . 46 103 3.1.1. Support to Neighbor Discovery and Parent Selection . 46 104 3.1.2. Support of Rank Computation . . . . . . . . . . . . . 47 105 3.1.3. Support of Control Messages Broadcast . . . . . . . . 47 106 3.1.4. Support for QoS . . . . . . . . . . . . . . . . . . . 48 107 3.2. GMPLS on 6top . . . . . . . . . . . . . . . . . . . . . . 49 108 3.2.1. Cell Reservation Support for GMPLS on 6top . . . . . 50 109 3.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 50 110 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 111 4.1. Normative References . . . . . . . . . . . . . . . . . . 50 112 4.2. Informative References . . . . . . . . . . . . . . . . . 51 113 4.3. External Informative References . . . . . . . . . . . . . 54 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 116 1. Introduction 118 As presented in [I-D.watteyne-6tsch-tsch-lln-context], the 119 [IEEE802154e] standard defines the mechanisms for a TSCH node to 120 communicate, given a schedule. It does not, however, define the 121 mechanism to build and maintain the TSCH schedule, match that 122 schedule to the multi-hop paths maintained by a network layer such as 123 RPL or a 2.5 layer such as GMPLS, adapt the resources allocated 124 between neighbor nodes to the data traffic flows, enforce a 125 differentiated treatment for data generated at the application layer 126 and signalling messages needed by 6LoWPAN and RPL to discover 127 neighbors, react to topology changes, self-configure IP addresses, or 128 manage keying material. 130 In a TSCH network, the MAC layer is not in charge of setting up the 131 schedule that controls the connectivity graph of the network and the 132 resources allocated to each cell in that topology. This 133 responsibility is left to an upper layer, defined in this document 134 and called "6top". 136 This document describes the 6TiSCH Operation Sublayer (6top) and the 137 main commands provided to upper network layers such as RPL or GMPLS. 138 The set of functionalities include feedback metrics from cell state 139 so the network layer can take routing decisions, TSCH configuration 140 and control procedures, and support for the different scheduling 141 mechanisms defined in [I-D.thubert-6tisch-architecture]. 6top 142 addresses the set of functionalities described in 143 [I-D.watteyne-6tsch-tsch-lln-context]. 145 For example, network formation in a TSCH network is handled by the 146 use of Enhanced Beacons (EB). EBs include information for joining 147 nodes to be able to synchronize and set up an initial network 148 topology. However, [IEEE802154e] does not specify how the period of 149 EBs is configured, nor the rules for a node to select a particular 150 node to join. 6top offers a set of commands so control mechanisms can 151 be introduced on top of TSCH to configure nodes to join a specific 152 node and obtain a unique 16-bit identifier from the network. Once a 153 network is formed, 6top maintains the network's health, allowing for 154 nodes to stay synchronized. It supplies mechanisms to manage each 155 node's time source neighbor and configure the EB interval. Network 156 layers running on top of 6top take advantage of the TSCH MAC layer 157 information so routing metrics, topological information, energy 158 consumption and latency requirements can be adjusted to TSCH, and 159 adapted to application requirements. 161 TSCH requires a mechanism to manage its schedule; 6top provides a set 162 of commands for upper layers to set up specific schedules, either 163 explicitly by detailing specific cell information, or by allowing 164 6top to establish a schedule given a bandwidth or latency 165 requirement. 6top is designed to enable decentralized, centralized or 166 hybrid scheduling solutions. 6top enables internal TSCH queuing 167 configuration, size of buffers, packet priorities, transmission 168 failure behavior, and defines mechanisms to encrypt and authenticate 169 MAC slotframes. 171 As described in [label-switching-154e], due to the slotted nature of 172 a TSCH network, it is possible to use a label switched architecture 173 on top of TSCH cells. As a cell belongs to a specific track, a label 174 header is not needed at each packet; the input cell (or bundle) and 175 the output cell (or bundle) uniquely identify the data flow. The 176 6top sublayer provides operations to manage the cell mappings. 178 2. 6TiSCH Operation Sublayer (6top) 180 2.1. Overview 182 6top is a sublayer which is the next-higher layer for TSCH (Figure 183 1), as detailed in [I-D.thubert-6tisch-architecture]. 6top offers 184 both management and data interfaces to an upper layer. It includes 185 monitoring and statistics collection, both of which are configurable 186 through the management interface. 188 Protocol Stack 189 +-----------------------------------+ 190 | PCEP | CoAP | | 6LoWPAN | | 191 | PCC | DTLS | PANA | ND |RPL | 192 +------------------------------------------+ 193 | TCP | UDP | ICMP | RSVP | 194 +------------------------------------------+ 195 | IPv6 | 196 +------------------------------------------+ 197 | 6LoWPAN HC | 198 +------------------------------------------+ 199 | 6top | 200 +------------------------------------------+ 201 | IEEE802.15.4e TSCH | 202 +------------------------------------------+ 203 | IEEE802.15.4 | 204 +------------------------------------------+ 206 Figure 1 208 6top distinguishes between hard cells and soft cells. It therefore 209 requires an extra flag to all cells in the TSCH schedule, as detailed 210 in Section 2.2. 212 When a higher layer gives 6top a 6LoWPAN packet for transmission, 213 6top maps it to the appropriate outgoing priority-based queue, as 214 detailed in Section 2.3. 216 All commands of the management and data interfaces are detailed in 217 Section 2.4. This set of commands is designed to support 218 decentralized, centralized and hybrid scheduling solutions. 220 6top defines TSCH Information Elements (IEs) for neighbors nodes to 221 negotiate scheduling cells in the TSCH schedule. The format of those 222 is given in Section 2.5. Example data exchanges between neighbor 223 nodes are illustrated in Section 2.6. 225 Section 2.7 defines how 6top gathers statistics (e.g., link quality, 226 energy level, queue usage), and what commands an upper layer can use 227 to configure and retrieve statistics. 229 6top can be configured to monitor the cells it has scheduled in order 230 to detect cells with poor performance. It can automatically re- 231 allocate those cells inside the TSCH schedule. This behavior is 232 described in Section 2.8 234 2.2. Cell Model 236 [IEEE802154e] defines a set of options attached to each cell. A cell 237 can be a Transmit cell, a Receive cell, a Shared cell or a 238 Timekeeping cell. These options are not exclusive, as a cell can be 239 qualified with more than one of them. The MLME-SET-LINK.request 240 command defined in [IEEE802154e] uses a linkOptions bitmap to specify 241 the options of a cell. Acceptable values are: 243 b0 = Transmit 245 b1 = Receive 247 b2 = Shared 249 b3 = Timekeeping 251 b4-b7 = Reserved 253 Only Transmit cells can also be marked as Shared cells. When the 254 shared bit is set, a back-off procedure is applied to handle 255 collisions. Shared behavior does not apply to Receive cells. 257 6top allows an upper layer to schedule a cell at a specific 258 slotOffset and channelOffset, in a specific slotframe. 6top follows 259 the hard cell reservation process described in Section 2.6.5. 261 In addition, 6top allows an upper layer to schedule a certain amount 262 of bandwidth to a neighbor, without having to specify the exact 263 slotOffset(s) and channelOffset(s). 6top follows the soft cell 264 reservation process described in Section 2.6.2. Once bandwidth is 265 reserved, 6top is in charge of ensuring that this requirement is 266 continuously satisfied, as described in Section 2.8. 6top dynamically 267 reallocates cells if needed, and over-provisions if required. 269 6top allows an upper layer to associate a hard/soft cell with a 270 specific track by using a TrackID. A TrackID is a tuple 271 (TrackOwnerAddr,InstanceID), where TrackOwnerAddr is the address of 272 the node which initializes the process of creating the track, i.e., 273 the owner of the track; and InstanceID is an instance identifier 274 given by the owner of the track. InstanceID comes from upper layer; 275 InstanceID could for example be the local instance ID defined in RPL. 277 If the TrackID is set to (0,0), the cell can be used by the best- 278 effort QoS configuration or as a Shared cell. If the TrackID is not 279 set to (0,0), i.e., the cell belongs to a specific track, the cell 280 MUST not be set as Shared cell. 282 Given this mechanism, 6top defines hard cells (which have been 283 requested specifically) and soft cells (which can be reallocated 284 dynamically). The hard/soft flag is introduced by the 6top sublayer 285 as an extension of LinkOption flags defined in [IEEE802154e]. This 286 option is mandatory; all cells are either hard or soft. 288 With the addition of the Hard/Soft flag, the resulting flags are: 290 b0 = Transmit 292 b1 = Receive 294 b2 = Shared 296 b3 = Timekeeping 298 b4 = Hard (1)/Soft (0) 300 b5-b7 = Reserved 302 2.2.1. hard cells 304 A hard cell is a cell that cannot be dynamically reallocated by 6top. 305 A hard cell is uniquely identified by the following tuple: 307 slotframe ID: ID of the slotframe this cell is part of. 309 slotOffset: the slotOffset for the cell. 311 channelOffset: the channelOffset for the cell. 313 LinkOption bitmap: bitmap as defined in Section 2.2, including 314 the hard/soft bit which MUST be set to 1. 316 2.2.2. soft cells 318 A soft cell is a cell that can be reallocated by 6top dynamically. 319 The hard/soft bit MUST be set to 0. This cell is installed by 6top 320 given a specific bandwidth requirement. Soft cells are installed 321 through the soft cell negotiation procedure described in Section 2.6. 323 2.3. Data Convey Model 325 Once a TSCH schedule is established, 6top is responsible for feeding 326 the data from the upper layer into TSCH. This section describes how 327 6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds 328 it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, the 329 properties associated with a packet/fragment from the upper layer 330 includes the next hop neighbor (DestAddr) and expected sending 331 priority of the packet (Priority), and/or TrackID(s). The output to 332 TSCH is the fragment corresponding to the next active cell in the 333 TSCH schedule. 335 6top Data Convey Model 337 | 338 | (DestAddr, Priority, Fragment) 339 | 340 +---------------------------------------+ 341 | I-MUX | 342 +---------------------------------------+ 343 | | | | .... | 344 | | | | | 345 +---+ +---+ +---+ +---+ +---+ 346 | | | | | | | | | | 347 |Q1 | |Q2 | |Q3 | |Q4 | |Qn | 348 | | | | | | | | | | 349 +---+ +---+ +---+ +---+ +---+ 350 | | | | | 351 | | | | | 352 +---------------------------------------+ 353 | MUX | 354 +---------------------------------------+ 355 | 356 | 357 +---+ 358 |PDU| 359 +---+ 360 | 361 | TSCH MAC-payload 362 | 364 Figure 2 366 In Figure 2, Qi represents a queue, which is either broadcast or 367 unicast, and is assigned a priority. The number of queues is 368 configurable. The relationship between queues and tracks is 369 configurable. For example, for a given queue, only one specific 370 track can be used, all of the tracks can be used, or a subset of the 371 tracks can be used. 373 When 6top receives a packet to transmit through a Send.data command 374 (Section 2.4.10), the I-MUX module selects a queue in which to insert 375 it. If the packet's destination address is a unicast (resp. 376 broadcast) address, it will be inserted into a unicast (resp. 377 broadcast) queue. 379 The MUX module is invoked at each scheduled transmit cell by TSCH. 380 When invoked, the MUX module goes through the queues, looking for the 381 best matching frame to send. If it finds a frame, it hands it over 382 to TSCH for transmission. If the next active cell is a broadcast 383 cell, it selects a fragment only from broadcast queues. 385 How the MUX module selects the best frame is configurable. The 386 following rules are a typical example: 388 The frame's layer 2 destination address MUST match the neighbor 389 address associated with the transmit cell. 391 If the transmit cell is associated with a specific track, the 392 frames in the queue corresponding to the TrackID have the 393 highest priority. 395 If the transmit cell is not associated with a specific track, 396 i.e., TrackID=(0,0), frames from a queue with a higher priority 397 MUST be sent before frames from a queue with a lower priority. 399 Further rules can be configured to satisfy specific QoS requirements. 401 2.4. Commands 403 6top provides a set of commands as the interface with the higher 404 layer. Most of these commands are related to the management of 405 slotframes, cells and scheduling information. 6top also provides an 406 interface allowing an upper layer to retrieve status information and 407 statistics. This section describes the following commands provided 408 by 6top. 410 CREATE.hardcell: Section 2.4.1.1 412 CREATE.softcell: Section 2.4.1.2 414 READ.cell: Section 2.4.1.3 416 UPDATE.cell: Section 2.4.1.4 418 DELETE.hardcell: Section 2.4.1.5 420 DELETE.softcell: Section 2.4.1.6 422 REALLOCATE.softcell: Section 2.4.1.7 424 CREATE.slotframe: Section 2.4.2.1 426 READ.slotframe: Section 2.4.2.2 427 UPDATE.slotframe: Section 2.4.2.3 429 DELETE.slotframe: Section 2.4.2.4 431 CONFIGURE.monitoring: Section 2.4.3.1 433 READ.monitoring: Section 2.4.3.2 435 CONFIGURE.statistics: Section 2.4.4.1 437 READ.statistics: Section 2.4.4.2 439 RESET.statistics: Section 2.4.4.3 441 CONFIGURE.eb: Section 2.4.5.1 443 READ.eb: Section 2.4.5.2 445 CONFIGURE.timesource: Section 2.4.6.1 447 READ.timesource: Section 2.4.6.2 449 CREATE.neighbor: Section 2.4.7.1 451 READ.all.neighbor: Section 2.4.7.2 453 READ.neighbor: Section 2.4.7.3 455 UPDATE.neighbor: Section 2.4.7.4 457 DELETE.neighbor: Section 2.4.7.5 459 CREATE.queue: Section 2.4.8.1 461 READ.queue: Section 2.4.8.2 463 READ.queue.stats: Section 2.4.8.3 465 UPDATE.queue: Section 2.4.8.4 467 DELETE.queue: Section 2.4.8.5 469 CONFIGURE.security: Section 2.4.9.1 471 CONFIGURE.security.macKeyTable: Section 2.4.9.2 473 CONFIGURE.security.macSecurityLevelTable:Section 2.4.9.3 474 Send.data: Section 2.4.10.1 476 Receive.data: Section 2.4.10.2 478 LabelSwitching.map: Section 2.4.11.1 480 LabelSwitching.unmap: Section 2.4.11.2 482 2.4.1. Cell Commands 484 6top provides the following commands to manage TSCH cells. 486 2.4.1.1. CREATE.hardcell 488 Creates one or more hard cells in the schedule. Fails if the cell 489 already exists. A cell is uniquely identified by the tuple 490 (slotframe ID, slotOffset, channelOffset). 492 To create a hard cell, the upper layer specifies: 494 slotframe ID: ID of the slotframe this timeslot will be 495 scheduled in. 497 slotOffset: the slotOffset for the cell. 499 channelOffset: channelOffset for the cell. 501 LinkOption bitmap: bitmap as defined in Section 2.2 503 target node address: the address of that node to communicate 504 with over this cell. In case of broadcast cells this is the 505 broadcast address. 507 TrackID: ID of the track the cell will belong to. 509 6top schedules the cell and marks it as a hard cell, indicating that 510 it cannot reschedule this cell. 512 2.4.1.2. CREATE.softcell 514 To create soft cell(s), the upper layer specifies: 516 slotframe ID: ID of the slotframe the cell(s) will be scheduled 517 in 519 number of cells: the required number of soft cells. 521 LinkOption bitmap: bitmap as defined in Section 2.2 522 target node address: the address of the node to communicate 523 with over the cell(s). In case of broadcast cells this is the 524 broadcast address. 526 TrackID: ID of the track the cell(s) will belong to. 528 QoS level: the cell redundancy policy. The policy can be for 529 example STRICT, BEST_EFFORT, etc. 531 6top is responsible for picking the exact slotOffset and 532 channelOffset in the schedule, and ensure that the target node choose 533 the same cell and TrackID. 6top marks these cells as soft cell, 534 indicating that it will continuously monitor their performance and 535 reschedule if needed. 537 6top deals with the allocation process by negotiation with the target 538 node. The negotiation process is described in Section 2.6.2. The 539 command returns the list of created cells defined by (slotframe ID, 540 slotOffset, channelOffset). It fails if the required number of cells 541 is higher than the available number of cells in the schedule. It 542 fails if the negotiation with the target node fails. It fails if the 543 LinkOption bitmap indicates that the cell(s) MUST be Hard. 545 2.4.1.3. READ.cell 547 Given a (slotframe ID, slotOffset, channelOffset), retrieves the cell 548 information. Fails if the cell does not exist. The returned 549 information contains: 551 slotframe ID: ID of the slotframe where this cell is installed. 553 slotOffset: the slotOffset for the cell. 555 channelOffset: the selected channelOffset for the cell. 557 LinkOption bitmap: bitmap as defined in Section 2.2 559 target node address: the target address of that cell. In case 560 of broadcast cells this is the broadcast address. 562 TrackID: ID of the track the cell will belong to. 564 A read command can be issued for any cell, hard or soft. 566 2.4.1.4. UPDATE.cell 568 Update a hard cell, i.e., re-allocate it to a different slotOffset 569 and/or channelOffset. Fails if the cell does not exist. Requires 570 both old (slotframe ID, slotOffset, channelOffset) and new (slotframe 571 ID, slotOffset, channelOffset) as parameters. And, the type of cell, 572 target node address and TrackID are the fields that cannot be 573 updated. Soft cells MUST NOT be updated by the UPDATE.cell command. 574 REALLOCATE.softcell (Section 2.4.1.7) MUST be used instead. 576 2.4.1.5. DELETE.hardcell 578 To remove a hard cell, the upper layer specifies: 580 slotframe ID: the ID of the slotframe where this cell is 581 installed. 583 slotOffset: the slotOffset for the cell. 585 channelOffset: the selected channelOffset for the cell. 587 This removes the hard cell from the node's schedule. 589 2.4.1.6. DELETE.softcell 591 To remove a (number of) soft cell(s), the upper layer specifies: 593 slotframe ID: ID of the slotframe where this cell is installed. 595 number of cells: the number of cells to be removed 597 LinkOption bitmap: bitmap as defined in Section 2.2 599 target node address: the target address of that cell. In case 600 of broadcast cells this is the broadcast address. 602 TrackID: ID of the track the cell will belong to. 604 In the case a soft cell wants to be re-allocated from the allocated 605 cell so a hard cell can be installed instead, the REALLOCATE.softcell 606 (Section 2.4.1.7) MUST be used. 608 2.4.1.7. REALLOCATE.softcell 610 To force a re-allocation of a soft cell, the upper layer specifies: 612 slotframe ID: ID of the slotframe where the cell is allocated. 614 slotOffset: the slotOffset for that cell. 616 channelOffset: the channelOffset for that cell. 618 The reallocated cell will be installed in a different slotOffset, 619 channelOffset but slotframe and TrackID remain the same. Hard cells 620 MUST NOT be reallocated. 622 2.4.2. Slotframe Commands 624 6top provides the following commands to manage TSCH slotframes. 626 2.4.2.1. CREATE.slotframe 628 Creates a new slotframe. Returns the slotframe ID that corresponds 629 to its priority (SlotFrameHandle). The command requires: 631 number of timeslots: the required number of timeslots in the 632 slotframe. 634 Fails if the number of required timeslots is less than zero. 636 2.4.2.2. READ.slotframe 638 Returns the information of a slotframe given its slotframe ID. The 639 command returns: 641 slotframe ID: ID of the slotframe. (SlotFrameHandle) 643 number of timeslots: the number of timeslots in the slotframe. 645 Fails if the slotframe ID does not exist. 647 2.4.2.3. UPDATE.slotframe 649 Change the number of timeslots in a slotframe. The command requires: 651 slotframe ID: ID of the slotframe. 653 number of timeslots: the number of timeslots to be updated. 655 Fails if the number of required timeslots is less than zero. Fails 656 if the slotframe ID does not exist. 658 2.4.2.4. DELETE.slotframe 660 Deletes a slotframe. The command requires: 662 slotframe ID: ID of the slotframe. 664 Fails if the slotframe ID does not exist. 666 2.4.3. Monitoring Commands 668 Monitoring commands provide the means for upper layers to configure 669 whether 6top must ensure the required bandwidth. This procedure is 670 achieved through overprovisioning according to cell status feedback. 671 Monitoring is also in charge of reallocating soft cells that are 672 under the required QoS. The mechanism is described in Section 2.8. 674 2.4.3.1. CONFIGURE.monitoring 676 Configures the level of QoS the Monitoring process MUST enforce. The 677 command requires: 679 slotframe ID: ID of the slotframe. 681 target node address: the target neighbor address. 683 enforce policy: The policy used to enforce the QoS 684 requirements. Can be for example DISABLE, BEST_EFFORT, STRICT, 685 OVER-PROVISION, etc. 687 Fails if the slotframe ID does not exist. 689 2.4.3.2. READ.monitoring.status 691 Reads the current Monitoring status. Requires the following 692 parameters. 694 slotframe ID: the ID of the slotframe. 696 target node address: the target neighbor address. 698 Returns the QoS levels for that Target node on that slotframe. 700 allocated_hard: Number of hard cells allocated. 702 allocated_soft: Number of soft cells allocated. 704 provisioned: the extra provisioned cells. 0 if CONFIGURE.qos 705 enforce is DISABLE. 707 QoS: the current QoS. Including overprovisioned cells, i.e 708 what bandwidth is being obtained including the overprovisioned 709 cells. 711 RQoS: the real QoS without provisioned cells. What is the 712 actual bandwidth without taking into account the 713 overprovisioned cells. 715 Fails if the slotframe ID does not exist. 717 2.4.4. Statistics Commands 719 6top keeps track of TSCH statistics for upper layers to adapt 720 correctly to medium changes. The exact metrics for statistics are 721 out of scope but the present commands SHOULD be used to configure and 722 read monitored information regardless of the specific metric. 724 2.4.4.1. CONFIGURE.statistics 726 Configures Statistics process. The command requires: 728 slotframe ID: ID of the slotframe. If empty monitors all 729 slotframe IDs 731 slotOffset: specific slotOffset to be monitored. If empty all 732 timeslots are monitored 734 channelOffset: specific channelOffset to be monitored. If 735 empty all channels are monitored. 737 target node address: the target neighbor address. If empty, 738 all neighbor nodes are monitored. 740 metric: metric to be monitored. This MAY be PDR, ETX, queuing 741 statistics, energy-related metrics, etc.) 743 window: time window to be considered for the calculations. If 744 0 all historical data is considered. 746 enable: Enables statistics or disables them. 748 Fails if the slotframe ID does not exist. The statistics service can 749 be configured to retrieve statistics at different levels. For 750 example to aggregate information by slotframe ID, or to retrieve 751 statistics for a particular timeslot, etc. The CONFIGURE.statistics 752 enables flexible configuration and supports empty parameters that 753 will force 6top to conduct statistics on all members of that 754 dimension. For example, if ChannelOffset is empty and metric is set 755 as PDR, then, 6top will conduct the statistics of PDR on all of 756 channels. 758 2.4.4.2. READ.statistics 760 Reads a metric for the specified dimension. Information is 761 aggregated according to the parameters. The command requires: 763 slotframe ID: ID of the slotframe. If empty aggregates 764 information of all slotframe IDs 766 slotOffset: the specific slotOffset for which the information 767 is required. If empty all timeslots are aggregated 769 channelOffset: the specific channelOffset for which the 770 information is required. If empty all channels are aggregated. 772 target node address: the target neighbor address. If empty all 773 neighbor addresses are aggregated. 775 metric: metric to be read. 777 Returns the value for the requested metric. 779 Fails if empty metric or metric does not exits. 781 2.4.4.3. RESET.statistics 783 Resets the gathered statistics. The command requires: 785 slotframe ID: ID of the slotframe. If empty resets the 786 information of all slotframe IDs 788 slotOffset: the specific slotOffset for which the information 789 wants to be reset. If empty statistics from all timeslots are 790 reset 792 channelOffset: the specific channelOffset for which the 793 information wants to be reset. If empty all statistics for all 794 channels are reset. 796 target node address: the target neighbor address. If empty all 797 neighbor addresses are aggregated. 799 metric: metric to be reset. 801 Fails if empty metric or metric does not exits. 803 2.4.5. Network Formation Commands 804 EBs need to be configured, including their transmission period, the 805 slotOffset and channelOffset that they SHOULD be sent on, and the 806 join priority they contain. The parameters for that command are 807 optional and enable flexible configuration of EBs. If slotframe ID 808 is specified, the EBs will be configured to use that specific 809 slotframe; if not, they will use the first slotframe where the 810 configured slotOffset is allocated. The slotOffset enforces the EB 811 to a specific timeslot. In case slotOffset parameter is not present, 812 the EB is sent in the first available transmit timeslot. In case 813 channelOffset parameter is not set, the EB is configured to use the 814 first available channel. 816 2.4.5.1. CONFIGURE.eb 818 Configures EBs. The command requires: 820 slotframe ID: ID of the slotframe where the EBs MUST be sent. 821 Zero if any slotframe can be used. 823 slotOffset: the slotOffset where the EBs MUST be sent. Zero if 824 any timeslot can be used. 826 channelOffset: the channelOffset where the EBs MUST be sent. 827 Zero if any channelOffset can be used. 829 period: the EBs period, in seconds. 831 Expiration: when the EBs periodicity will stop. If Zero the 832 period never stops. 834 priority: the joining priority model that will be used for 835 advertisement. Joining priority MAY be for example 836 SAME_AS_PARENT, RANDOM, BEST_PARENT+1 or DAGRANK(rank) as 837 decribed in in [I-D.vilajosana-6tisch-minimal]. 839 Fails if the tuple (slotframe ID, slotOffset, channelOffset) is 840 already scheduled. 842 2.4.5.2. READ.eb 844 Reads the EBs configuration. No parameters are required. 846 Returns the current EBs configuration for that slotframe, which 847 contains: 849 slotframe ID: the slotframe where the EB is being sent. 851 slotOffset: the slotOffset where the EBs is being sent. 853 channelOffset: the channelOffset the EBs is being sent on. 855 period: the EBs period. 857 Expiration: when the EBs periodicity stops. If 0 the period 858 never stops. 860 priority: the joining priority that this node advertises. 862 Fails if the slotframe ID does not exist. 864 2.4.6. Time Source Neighbor Commands 866 Commands to select time source neighbors. 868 2.4.6.1. CONFIGURE.timesource 870 Configures the Time Source Neighbor selection process. More than one 871 time source neighbor can be selected. The command requires: 873 selection policy: The policy used to select the time source 874 neighbor. The policy MAY be for example ALL_PARENTS, 875 BEST_CONNECTED, LOWEST_JOIN_PRIORITY, etc. 877 Fails if any of the time source neighbors do not exist or it is not 878 reachable. 880 2.4.6.2. READ.timesource 882 Retrieves information about the time source neighbors of that node. 883 The command does not require any parameter. 885 Returns the following information for each of the time sources: 887 target node: address of the time source neighbor. 889 statistics: includes for example minimum, maximum, average time 890 correction for that time source neighbor 892 policy: the used policy 894 Fails if the slotframe ID or no time source neighbors exist. 896 2.4.7. Neighbor Commands 898 Commands to manage neighbor table. The commands SHOULD be used by 899 the upper layer to query the neighbor related information and by the 900 lower layer to keep track of neighbors information. 902 2.4.7.1. CREATE.neighbor 904 Creates an entry for a neighbor in the neighbor table. 906 neighbor address: The address of the neighbor. 908 neighbor stats: for example, RSSI of the last received packet 909 from that neighbor, ASN when that neighbor has been added, etc. 911 Returns whether the neighbor is created or not. 913 2.4.7.2. READ.all.neighbor 915 Returns the list of neighbors of that node. Fails if empty. For 916 each neighbor in the list it returns: 918 neighbor address: The address of the neighbor. 920 neighbor stats: for example, RSSI of the last received packet 921 from that neighbor, ASN when that neighbor has been added, 922 packets received from that neighbor, packets sent to it, etc. 924 2.4.7.3. READ.neighbor 926 Returns the information of a specific neighbor of that node specified 927 by its neighbor address. Fails if it does not exists. For that 928 neighbor it returns: 930 neighbor address: The address of the neighbor. 932 neighbor stats: for example, RSSI of the last received packet 933 from that neighbor, ASN when that neighbor has been added, 934 packets received from that neighbor, packets sent to it, etc. 936 2.4.7.4. UPDATE.neighbor 938 Updates an entry for a neighbor in the neighbor table. Fails if the 939 neighbor does not exist. Updates stats parameters. Requires: 941 neighbor address: The address of the neighbor. 943 neighbor stats: for example, RSSI of the last received packet 944 from that neighbor, ASN when that neighbor has been added, etc. 946 Returns whether the neighbor is updated or not. 948 2.4.7.5. DELETE.neighbor 950 Deletes a neighbor given its address. Fails if the neighbor does not 951 exists. 953 2.4.8. Queueing Commands 955 Queues need to be configured. This includes queue length, 956 retransmission policy, discarding of packets, etc. 958 2.4.8.1. CREATE.queue 960 Creates and Configures Queues. The command SHOULD be applied for 961 each required queue. The command requires: 963 txqlength: the desired transmission queue length. 965 rxqlength: the desired reception queue length. 967 numrtx: number of allowed retransmissions. 969 age: discard packet according to its age on the queue. 0 if no 970 discards are allowed. 972 rtxbackoff: retransmission backoff in number of slotframes. 0 973 if next available timeslot wants to be used. 975 statswindow: window of time used to compute stats. 977 queue priority: the priority of this queue. 979 TrackIDs: a set of TrackIDs. While it is empty, no specific 980 track is associated with the queue 982 Returns the queue ID. 984 2.4.8.2. READ.queue 986 Reads the queue configuration. Requires the queue ID. 988 The command returns: 990 txqlength: the transmission queue length. 992 rxqlength: the reception queue length. 994 numrtx: number of allowed retransmissions. 996 age: maximum age of a packet before being discarded. 0 if no 997 discards are allowed. 999 rtxbackoff: retransmission backoff in number of slotframes. 0 1000 if next available timeslot is used. 1002 2.4.8.3. READ.queue.stats 1004 Reads the queue stats. Requires queue ID. 1006 The command returns: 1008 txqlengthstats: average, maximum, minimum length of the 1009 transmission queue. 1011 rxqlengthstats: average, maximum, minimum length of the 1012 reception queue. 1014 numrtxstats: average, maximum, minimum number of 1015 retransmissions. 1017 agestats: average, maximum, minimum age of a packet in the 1018 queue. 1020 rtxbackoffstats: average, maximum, minimum retransmission 1021 backoff. 1023 queue priority: the priority of this queue. 1025 TrackIDs: a set of TrackIDs. 1027 2.4.8.4. UPDATE.queue 1029 Update a Queue. The command requires: 1031 queueid: the queue ID. 1033 txqlength: the desired transmission queue length. 1035 rxqlength: the desired reception queue length. 1037 numrtx: number of allowed retransmissions. 1039 age: discard packet according to its age on the queue. 0 if no 1040 discards are allowed. 1042 rtxbackoff: retransmission backoff in number of slotframes. 0 1043 if next available timeslot wants to be used. 1045 statswindow: window of time used to compute stats. 1047 queue priority: the desired priority of this queue. 1049 TrackIDs: the desired set of TrackIDs. 1051 2.4.8.5. DELETE.queue 1053 Deletes a Queue. The command requires the queue ID. All packets in 1054 the queue are discarded and the queue is deleted. 1056 2.4.9. Security Commands 1058 The following commands are used to manage underlying layer security. 1059 In that case 6top acts as delegating interface to the security 1060 attributes defined in the MAC PIB ([IEEE802154]). 1062 2.4.9.1. CONFIGURE.security 1064 Enables/Disables Security and configures the MAC PIB. The command 1065 requires: 1067 enable: enables underlying layer security. 1069 macAutoRequestSecurityLevel: the security level used for 1070 automatic data requests as described by table 60 in 1071 [IEEE802154]. 1073 macAutoRequestKeyIdMode: the key identifier mode used for 1074 automatic data requests as described by table 60 in 1075 [IEEE802154]. 1077 macAutoRequestKeySource: the originator of the key for 1078 automatic data requests as described by table 60 in 1079 [IEEE802154]. 1081 macAutoRequestKeyIndex: the index of the key used for automatic 1082 data requests as described by table 60 in [IEEE802154]. 1084 macDefaultKeySource: the originator of the default key used for 1085 key identifier mode 0x01 as described by table 60 in 1086 [IEEE802154]. 1088 macPANCordinatorExtendedAddress: Address of the PAN coordinator 1089 as described by table 60 in [IEEE802154]. 1091 macPANCordinatorShortAddress: Short address of the PAN 1092 coordinator as described by table 60 in [IEEE802154]. 1094 2.4.9.2. CONFIGURE.security.macKeyTable 1096 Configures Security Keys. The command requires: 1098 KeyIdLookupList: list of keyIdLookupDescriptor Entries as 1099 defined by table 61 in [IEEE802154]. 1101 DeviceDescriptorHandleList: Implementation specific list of 1102 devices that are using this key. As defined by table 61 in 1103 [IEEE802154]. 1105 KeyUsageList: List of slotframe types on which this key is 1106 being used as specified by table 61 in [IEEE802154]. 1108 Key: 16 octets key. As specified by table 61 in [IEEE802154]. 1110 2.4.9.3. CONFIGURE.security.macSecurityLevelTable 1112 Configures the set of security levels. The command requires: 1114 FrameType: Slotframe type as defined by table 63 in 1115 [IEEE802154]. 1117 Command Identifier: The command identifier as defined by table 1118 63 in [IEEE802154]. 1120 Security Minimum: The minimum required security level as 1121 specified by table 63 in [IEEE802154]. 1123 Device Override Security Minimum: whether the minimum security 1124 level can be overridden as specified by table 63 in 1125 [IEEE802154]. 1127 Allowed Security Levels: the key identifier field that 1128 identifies the key that is being used as specified by table 63 1129 in [IEEE802154]. 1131 2.4.9.4. Security Command Behavior 1133 6top offers the interface to upper layers so underlying MAC layer can 1134 be configured. In that sense, 6top only delegates the 1135 functionalities to the MAC security services. For more details 1136 Section 7 on [IEEE802154] and its amendments on [IEEE802154e] SHOULD 1137 be referred. 1139 2.4.10. Data Commands 1141 2.4.10.1. Send.data 1143 The command used by upper layers to queue a packet so underlying TSCH 1144 sends it. According to the specific priority, the packet is pushed 1145 into a Queue with the equivalent priority or following a criteria out 1146 of scope. Once a packet is inserted into a queue it waits to be 1147 transmitted by TSCH according to the model defined in Section 2.3. 1148 If the queue is full or destination address is not a L2 neighbor of 1149 the node, failure to enqueue will be indicated to the caller. 1151 The required parameters are: 1153 src address: L2 address 1155 dest address: L2 unicast or broadcast address 1157 priority: packet priority, usually is consistent with queue 1158 priority 1160 message length: the length of the message 1162 message: control message or data message 1164 securityLevel:As defined by [IEEE802154e]. 1166 2.4.10.2. Receive.data 1168 The command is invoked whenever a packet is received and inserted 1169 into a reception queue. The method acts as a callback function to 1170 notify to the upper layers the received message. Upper layers MUST 1171 terminate this indication. 1173 The function has the following parameters: 1175 src address: L2 source address 1177 dest address: L2 unicast or broadcast destination address 1178 priority: packet priority, usually is consistent with queue 1179 priority 1181 message length: the length of the message. 1183 message: control message or data message 1185 2.4.11. Label Switching Commands 1187 2.4.11.1. LabelSwitching.map 1189 The command used by an upper layer to map an input cell or a bundle 1190 of input cells to an output cell or a bundle of output cells. 6top 1191 stores this mapping and makes sure that the packets are forwarded at 1192 the specific output cell/bundle. Label Switching is enabled by the 1193 specified bundle as soon as the mapping is installed. 1195 The required parameters are: 1197 input cells: list of input cells (one or more cells in a 1198 bundle). Each input cells is described by an unique tuple 1199 (slotOffset, channelOffset, destination address). 1201 output cells: list of output cells (one or more cells in a 1202 bundle). Each output cells is described by an unique tuple 1203 (slotOffset, channelOffset, destination address). 1205 load balancing policy: A policy for load balance cell usage. 1206 The policy is out of scope, however an example can be use ROUND 1207 ROBIN policy within the cells of the same bundle. 1209 2.4.11.2. LabelSwitching.unmap 1211 The command used by upper layers to unmap one input cell or a bundle 1212 of input cells to an output cell or a bundle of output cells. The 1213 mapping is removed from the state kept by 6top. 1215 The required parameters are: 1217 input cells: list of input cells (one or more cells in a 1218 bundle). Each input cells is described by an unique tuple 1219 (slotOffset, channelOffset, destination address). 1221 output cells: list of output cells (one or more cells in a 1222 bundle). Each output cells is described by an unique tuple 1223 (slotOffset, channelOffset, destination address). 1225 2.5. Message Formats 1227 6top has to negotiate the scheduling of soft cells with neighbor 1228 nodes. This negotiation happens through 6top-specific TSCH 1229 Information Elements, the format of which is defined in this section. 1230 For completeness, this section also details the formats of the IEs 1231 already defined in [IEEE802154e] and presented here without 1232 modification. 1234 6top messages can contain one or more IEs. Section 2.5.1 defines the 1235 different IEs used by 6top, both the ones used without modification 1236 from [IEEE802154e], and the new ones defined by this document. 1237 Section 2.5.2 shows how several IEs are assembled to form the 1238 different frames used by 6top. 1240 2.5.1. Information Elements 1242 [IEEE802154e] defines Information elements (IEs). IEs are formatted 1243 data objects consisting of an ID, a length, and a data payload used 1244 to pass data between layers or devices. [IEEE802154e] defines Header 1245 IEs and Payload IEs; 6top only uses Payload IEs. A Payload IE 1246 includes one or more IEs, and ends with a termination IE (ID = 0xf, 1247 see [IEEE802154e]). 1249 6top uses the following Information Elements, some defined in 1250 [IEEE802154e], others introduced in this document. 1252 Defined in [IEEE802154e] and used by 6top without modification: 1254 TSCH Synchronization IE (Section 2.5.1.1) 1256 TSCH Slotframe and Link IE (Section 2.5.1.2) 1258 TSCH Timeslot Template IE (Section 2.5.1.3) 1260 TSCH Channel Hopping IE (Section 2.5.1.4) 1262 Defined by 6top: 1264 6top Opcode IE (Section 2.5.1.5) 1266 6top Bandwidth IE (Section 2.5.1.6) 1268 6top TrackID IE (Section 2.5.1.7) 1269 6top Generic Schedule IE (Section 2.5.1.8) 1271 2.5.1.1. TSCH Synchronization IE 1273 A Synchronization IE (SyncIE) contains Information allowing a node to 1274 synchronize to a TSCH network, including the current ASN and a join 1275 priority. Synchronization IE MUST be included in all TSCH Enhanced 1276 Beacons. 1278 6top re-uses this IE as defined in [IEEE802154e]. 1280 Format of a TSCH Synchronization IE (SyncIE). 1282 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 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | Length | SubID |T| ASN | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | ASN | Join Priority | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 Figure 3 1291 Length=6 1293 SubID=0x1a 1295 T=0, i.e., short type 1297 ASN (5 octets) contains the Absolute Slot Number corresponding to the 1298 timeslot in which the TSCH Enhanced Beacon is sent. 1300 The Join Priority can be used by a joining device to select among 1301 beaconing devices when multiple beacons are heard. The PAN 1302 coordinator's join priority is zero. A lower value of join priority 1303 indicates that the device is the preferred one to connect to. As 1304 suggested by [I-D.vilajosana-6tisch-minimal], the beaconing device's 1305 join priority is its DAGRank(rank). 1307 2.5.1.2. TSCH Slotframe and Link IE 1309 The Slotframe and Link IE (FrameAndLinkIE) contains one or more 1310 slotframes and their respective cells that a beaconing device 1311 advertises to allow other devices to join the network. 1313 6top re-uses this IE as defined in [IEEE802154e]. 1315 Format of a TSCH Slotframe and Link IE (FrameAndLinkIE). 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Length | SubID |T| NumFrame | | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1321 | | 1322 // Slotframe and cell information // 1323 | | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 Figure 4 1328 Length=variable 1330 SubID=0x1b 1332 T=0, i.e., short type 1334 NumFrame is set to the total number of slotframe descriptors 1335 contained in the TSCH Enhanced Beacon. 1337 Format of a slotframe descriptor. 1339 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 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | FrameID | FrameLen | NumCell | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | | 1344 // Cell information for each cell (5x NumCell) // 1345 | | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 Figure 5 1350 The FrameID field shall be set to the slotframeHandle that uniquely 1351 identifies the slotframe. 1353 The FrameLen field shall be set to the size of the slotframe in 1354 number of timeslots. 1356 The NumCell field shall be set to the number of cells that belong to 1357 the specific slotframe identified by the slotframeHandle. 1359 Format of a Cell information. 1361 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 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | SlotOffset | ChannelOffset | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | LinkOption | 1366 +-+-+-+-+-+-+-+-+ 1368 Figure 6 1370 SlotOffset shall be set to the slotOffset of this cell. 1372 ChannelOffset shall be set to the channelOffset of this cell. 1374 LinkOption indicates whether this cell is a TX cell, an RX cell, or a 1375 SHARED TX cell, whether the device to which it is being linked is to 1376 be used for clock synchronization, and whether this cell is hard 1377 cell. 1379 2.5.1.3. TSCH Timeslot Template IE 1381 Timeslot Template IE (SlotTemplateIE) defines Timeslot template being 1382 used by the TSCH device. 1384 6top re-uses this IE as defined in [IEEE802154e]. 1386 Format of a TSCH Timeslot Template IE (SlotTemplateIE). 1388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Length | SubID |T| TemplateID | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 Figure 7 1395 Length=1 1397 SubID=0x1c 1399 T=0, i.e., short type 1401 TemplateID shall be set to a Timeslot template handle. The full 1402 timeslot template, which contains the macTimeslotTemplate of TSCH 1403 (total 25 octets), MAY be included.(see [IEEE802154e]). 1405 2.5.1.4. TSCH Channel Hopping IE 1407 Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being 1408 used by the TSCH device. 1410 6top re-uses this IE as defined in [IEEE802154e]. 1412 Format of a TSCH Channel Hopping IE (ChHoppingIE). 1414 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Length | SubID |T| HopSequenceID | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 Figure 8 1421 Length=1 1423 SubID=0x09 1425 T=1, i.e., long type 1427 HopSequenceID shall be set to a Hopping Sequence handle. The full 1428 Hopping Sequence information MAY be included. (see [IEEE802154e]). 1430 2.5.1.5. 6top Opcode IE 1432 6top Opcode IE (OpcodeIE) defines operation codes of packets in 6top 1433 sublayer. 1435 This IE is not present in [IEEE802154e] and is defined by 6top. 1437 Format of a 6top Opcode IE (OpcodeIE). 1439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | Length | SubID |T| OpcodeID | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 Figure 9 1446 Length=1 1448 SubID=0x41 1450 T=0, i.e., short type 1452 OpcodeID field shall be set to one of the following codes. 1454 0x00: Reserve Soft Cell Request 1456 0x01: Reserve Soft Cell Response 1457 0x02: Remove Soft Cell Request 1459 0x03: Reserve Hard Cell Request 1461 0x04: Remove Hard Cell Request 1463 2.5.1.6. 6top Bandwidth IE 1465 Bandwidth IE (BwIE) defines the number of cells to be reserved or 1466 actually be reserved. 1468 This IE is not present in [IEEE802154e] and is defined by 6top. 1470 Format of a 6top Bandwidth IE (BwIE). 1472 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 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Length | SubID |T| FrameID | NumCell | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 Figure 10 1479 Length=2 1481 SubID=0x42 1483 T=0, i.e., short type 1485 FrameID MAY be set to the SlotFrameHandle to identify the slotframe 1486 from which cells are reserved. FrameID field MAY be set to NOP, 1487 which means no specific slotframe is associated. 1489 NumCell shall be set to the number of cells. When BwIE is combined 1490 with the OpecodeID of Reserve Soft Cell Request, NumCell presents how 1491 many cells are required to reserve; and when BwIE is combined with 1492 the OpecodeID of Reserve Soft Cell Response, NumCell presents how 1493 many cells are reserved successfully. 1495 2.5.1.7. 6top TrackID IE 1497 TrackID IE (TrackIdIE) describes the track which the reserved/removed 1498 cell(s) are associated with. 1500 This IE is not present in [IEEE802154e] and is defined by 6top. 1502 Format of a 6top TrackID IE (TrackIdIE). 1504 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 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Length | SubID |T|OwnerInstID|rev| | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1508 // // 1509 | TrackOwnerAddr | 1510 | | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 Figure 11 1515 Length=3 or 7. When length=3, TrackOwnerAddr is 2 bytes short 1516 address, and when length=7, TrackOwnerAddr is 6 bytes long address. 1518 SubID=0x43 1520 T=0, i.e., short type 1522 The combination of TrackOwnerAddr and OwnerInstId represents a 1523 specific TrackID. 1525 2.5.1.8. 6top Generic Schedule IE 1527 Generic Schedule IE (ScheduleIE) describes cell sets. In different 1528 packets, ScheduleIE represents different information. See 1529 Section 2.5.2 for more detail. 1531 This IE is not present in [IEEE802154e] and is defined by 6top. 1533 Format of a 6top Generic Schedule IE (ScheduleIE). 1535 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 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Length | SubID |T| | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1539 | | 1540 // Schedule Body // 1541 | | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 Figure 12 1546 Length=variable 1548 SubID=0x44 1550 T=0, i.e., short type 1551 Schedule Body carries one or more schedule object. An object MAY 1552 carry a TLV (Type-Length-Value), which MAY itself comprise other 1553 TLVs. TLV format is as follows. Type: 1 byte, Length: 1 byte, 1554 Value: variable 1556 The following are some examples of schedule object TLV. 1558 Example 1. Cell Set TLV 1560 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 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Type=1 | Length | FrameID | NumCell |F| 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | | 1565 // CellObjects // 1566 | | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 Figure 13 1571 FrameID shall be set to the slotframeHandle that uniquely identifies 1572 the slotframe. 1574 NumCell shall be set to the number of cells that belong to the 1575 specific slotframe identified by the slotframeHandle. 1577 F=1 means the specified cells equals to what are listed in 1578 CellObjects, and F=0 means the specified cells equals to what are not 1579 listed in CellObjects. 1581 CellObjects carries the information for one or more cells, including 1582 SlotOffset, ChannelOffset, LinkOption (Figure 6). 1584 Example 2. Schedule Matrix TLV 1586 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 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Type=2 | Length | FrameID |StartSlotOffset| 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 |StartSLotOffset| NumSlot | | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1592 | | 1593 // SlotBitMap (2x NumSlot) // 1594 | | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 Figure 14 1599 FrameID field MUST be set to the slotframeHandle that uniquely 1600 identifies the slotframe. 1602 StartSlotOffset field (2 octets) MUST be set to the slotOffset in the 1603 specific slotframe identified by the slotframeHandle. 1605 NumSlot field MUST be set to the number of timeslots from 1606 StartSlotOffset in the specific slotframe identified by the 1607 slotframeHandle. 1609 SlotBitMap (per timeslot) indicates for the given timeslot which 1610 channels are specified. For the 16 channels in 2.4GHz band, 2-octets 1611 are used to indicate which channel is specified. For example, given 1612 a timeslot and a SlotBitmap with value (10001000,00010000); the 1613 bitmap represents that ChannelOffset-0, ChannelOffset-4, 1614 ChannelOffset-11 are specified. 1616 2.5.2. Packet Formats 1618 This section describes the packets used in 6top to form a network, 1619 reserve/maintain bandwidth using soft cells, and reserve/remove hard 1620 cells in both the transmitter side and receiver sides. Each of these 1621 packets uses one or more IEs defined in Section 2.5.1. 1623 2.5.2.1. TSCH Enhanced Beacon 1625 The TSCH Enhanced Beacon is used to announce the presence of the 1626 network and allows new nodes to join. It is an Enhanced Beacon 1627 packet defined in [IEEE802154e] with the following Payload IEs: 1629 TSCH Synchronization IE (Section 2.5.1.1) 1631 TSCH Timeslot Template IE (Section 2.5.1.3) 1633 TSCH Channel Hopping IE (Section 2.5.1.4) 1635 TSCH Slotframe and Link IE (Section 2.5.1.2) 1637 Payload IE of TSCH Enhanced Beacon Packet 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Length |GroupID|T| SyncIE | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | SyncIE | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | SyncIE | SlotTemplateIE | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 |SlotTemplateIE | ChHoppingIE | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | | 1649 // FrameAndLinkIE // 1650 | | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 Figure 15 1655 Length=variable 1657 GroupID=0x1, i.e., MLME IE 1659 T=1, i.e., payload IE 1661 See Section 2.5.1.1, Section 2.5.1.3, Section 2.5.1.4,Section 2.5.1.2 1662 for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndLinkIE. 1664 2.5.2.2. Soft Cell Reservation Request 1666 A Soft Cell Reservation Request packet is a DATA packet defined in 1667 [IEEE802154e] with the following payload IE. 1669 Payload IE of Soft Cell Reservation Request 1671 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | Length |GroupID|T| OpcodeIE | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | OpcodeIE | BwIE | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | BwIE | | 1678 +-+-+-+-+-+-+-+-+ | 1679 // ScheduleIE // 1680 | | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 Figure 16 1685 Length=variable 1686 GroupID=0x1, i.e., MLME IE 1688 T=1, i.e., payload IE 1690 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x00, 1691 indicates Reserve Soft Cell Request operation. 1693 The NumCell field in 4-octet BwIE SHOULD be set to the number of 1694 cells needed to be reserved. 1696 The ScheduleIE specifies a candidate cell set, from which the cells 1697 SHOULD be reserved. ScheduleIE MAY be empty, means there is no 1698 constrain on which cells SHOULD not be reserved. 1700 In addition, TrackIdIE can be added in the packet to associate the 1701 reserved soft cells to a specific TrackID. 1703 2.5.2.3. Soft Cell Reservation Response 1705 Soft Cell Reservation Response is a DATA packet defined in 1706 [IEEE802154e] with the following payload IE. 1708 Payload IE of Soft Cell Reservation Response 1710 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 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Length |GroupID|T| OpcodeIE | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | OpcodeIE | BwIE | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | BwIE | | 1717 +-+-+-+-+-+-+-+-+ | 1718 // ScheduleIE // 1719 | | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 Figure 17 1724 Length=variable 1726 GroupID=0x1, i.e., MLME IE 1728 T=1, i.e., payload IE 1730 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x01, 1731 indicates Reserve Soft Cell Response operation. 1733 The NumCell field in 4-octet BwIE SHOULD be set to the number of 1734 cells which have been reserved successfully. 1736 The ScheduleIE SHOULD specify all of the cells which have been 1737 reserved successfully. 1739 In addition, TrackIdIE can be added in the packet to associate the 1740 reserved soft cells to a specific TrackID. 1742 2.5.2.4. Soft Cell Remove Request 1744 Soft Cell Remove Request is a DATA packet defined in [IEEE802154e] 1745 with the following payload IE. 1747 Payload IE of Soft Cell Remove Request 1749 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 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Length |GroupID|T| OpcodeIE | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | OpcodeIE | | 1754 +-+-+-+-+-+-+-+-+ | 1755 // ScheduleIE // 1756 | | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 Figure 18 1761 Length=variable 1763 GroupID=0x1, i.e., MLME IE 1765 T=1, i.e., payload IE 1767 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x02, 1768 indicates Remove Soft Cell Request operation. 1770 The ScheduleIE SHOULD specify all the cells that need to be removed. 1772 2.5.2.5. Hard Cell Reservation Request 1774 Hard Cell Reservation Request packet is a DATA packet defined in 1775 [IEEE802154e] with the following payload IE. 1777 Payload IE of Hard Cell Reservation Request 1778 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 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Length |GroupID|T| OpcodeIE | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | OpcodeIE | | 1783 +-+-+-+-+-+-+-+-+ | 1784 // ScheduleIE // 1785 | | 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 Figure 19 1790 Length=variable 1792 GroupID=0x1, i.e., MLME IE 1794 T=1, i.e., payload IE 1796 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x03, 1797 indicates Reserve Hard Cell Request operation. 1799 The ScheduleIE SHOULD specify all the cell that need to be reserved. 1801 In addition, TrackIdIE can be added in the packet to associate the 1802 reserved hard cells to a specific TrackID. 1804 2.5.2.6. Hard Cell Remove Request 1806 Hard Cell Remove Request is a DATA packet defined in [IEEE802154e] 1807 with the following payload IE. 1809 Payload IE of Hard Cell Remove Request 1811 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 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | Length |GroupID|T| OpcodeIE | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | OpcodeIE | | 1816 +-+-+-+-+-+-+-+-+ | 1817 // ScheduleIE // 1818 | | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 Figure 20 1823 Length=variable 1825 GroupID=0x1, i.e., MLME IE 1826 T=1, i.e., payload IE 1828 The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x04, 1829 indicates Remove Hard Cell Request operation. 1831 The ScheduleIE SHOULD specify all the cells that need to be removed. 1833 2.6. Time Sequence 1835 6top neighbors exchange 6top-specific packets in the following cases, 1836 each detailed in a subsection. 1838 Network formation (Section 2.6.1) 1840 Creating soft cells (Section 2.6.2) 1842 Deleting soft cells (Section 2.6.3) 1844 Maintaining soft cells (Section 2.6.4) 1846 Creating hard cells (Section 2.6.5) 1848 Deleting hard cells (Section 2.6.6) 1850 2.6.1. Network Formation 1852 Network formation consists of two processes: joining and maintenance. 1854 2.6.1.1. Joining 1856 A node already in the network sends out TSCH Enhanced Beacons 1857 periodically. 1859 When a node is joining an existing network, it listens for TSCH 1860 Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs 1861 (the format of which is detailed in Section 2.5.2.1), the joining 1862 node MUST do the following. 1864 Initialize a neighbor table. Establish a neighbor table and 1865 record all of the information described in the TSCH Enhanced 1866 BEACONs as its initial schedule with those neighbors. 1868 Select a time source neighbor. According to the Joining 1869 Priority described by SyncIEs, the joining node chooses time 1870 source neighbors. 6top does not specify the criteria to choose 1871 time source neighbors from the Enhanced BEACONs. 1873 Select cells for Enhanced Beacons. The joining node selects 1874 one or more cells to indicate in its own Enhanced Beacons, 1875 which MAY be the same as the cells used by its neighbors for 1876 Enhanced Beacon broadcast, and record those cell(s) into the 1877 TSCH schedule with LinkType=ADVERTISING. 1879 Its Enhanced Beacons SHOULD include the cell(s) selected for EB 1880 purposes. The EB cells MUST be configured with LinkOption to 1881 "Receive" and "Timekeeping", telling its neighbors that the 1882 cell is used for broadcast. 1884 Start broadcasting Enhanced Beacon and communicate with 1885 neighbors. 1887 2.6.1.2. Maintenance 1889 Nodes MAY broadcast Enhance Beacons on the cells marked with 1890 LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors 1891 on the cells with LinkOption = "Receive" and "Timekeeping". If a 1892 cell with LinkType=ADVERTISING has both the "Receive" and 1893 "Timekeeping" LinkOptions set, which means that the cell is shared by 1894 neighbors and itself for broadcasting, then broadcasting Enhanced 1895 Beacon has higher priority. 1897 Whenever a node receives an Enhanced Beacon, it SHOULD update its 1898 schedule if there is a difference regarding to the cells used for 1899 synchronizing with the advertiser of the Enhanced Beacon. 1901 2.6.2. Creating soft cells 1903 The upper layer instructs 6top to schedule one or more soft cells by 1904 calling the Create soft cell command. This command can also be 1905 called by the monitoring process internal to 6top. 1907 When receiving a Create soft cell command, Node A's 6top sublayer 1908 forms a Soft Cell Reservation Request packet which includes the BwIE 1909 and ScheduleIE Information Elements. The BwIE indicates the number 1910 of cells to be reserved (N1); the ScheduleIE indicates set of a 1911 candidate cells from which the new cells SHOULD be selected. If the 1912 ScheduleIE is empty, Node A indicates there is no constraint on cell 1913 selection. 1915 The Soft Cell Reservation Request is sent to the neighbor (Node B) 1916 with whom new cells need to be scheduled. After receiving the Soft 1917 Cell Reservation Request, Node B selects the cells from the candidate 1918 cell set defined by the ScheduleIE in the Soft Cell Reservation 1919 Request, and forms a Soft Cell Reservation Response packet. In the 1920 Cell Reservation Response packet, the BwIE indicates the number of 1921 cells actually being reserved (N2); the ScheduleIE indicates those 1922 reserved cells. If N2 is smaller than N1, node B indicates to node A 1923 that there are not enough qualified cells to be reserved. Node B 1924 MUST record the reserved cells into its local schedule when sending 1925 the Soft Cell Reservation Response. After receiving the Soft Cell 1926 Reservation Response, Node A MUST record the reserved cells into its 1927 local schedule. 1929 The policy to build a candidate cell set and the policy to select 1930 cells from the candidate cell set to reserve are out of scope. 1932 The format of Schedule Body is flexible. For example, Node A can use 1933 Cell Set TLV defined in Figure 13 with field 'F' set to '0', and the 1934 CellObjects includes all of the cells being used by Node A. In 1935 another word, the cell candidate set is all of the cells not being 1936 included in the list defined by CellObjects. 1938 The behavior of the nodes when the soft cells negotiation fails is 1939 out of scope. 1941 2.6.3. Deleting soft cells 1943 The upper layer instructs 6top to delete one or more soft cells by 1944 calling the Delete soft cell command (Section 2.4.1.6). This command 1945 can also be called by the monitoring process internal to 6top 1946 (Section 2.8). 1948 When receiving a Delete soft cell command, Node A's 6top sublayer 1949 selects cells to be removed from its local schedule, and creates a 1950 Soft Cell Remove Request, which includes a ScheduleIE Information 1951 Element. The ScheduleIE indicates which specific cells to remove 1952 with a neighbor (Node B). The cells specified in the ScheduleIE 1953 SHOULD be removed from local schedule of Node A when the Soft Cell 1954 Remove Request is sent to Node B. When receiving the Soft Cell Remove 1955 Request, the cells specified in the ScheduleIE SHOULD be removed from 1956 the local schedule of Node B. 1958 The policy to select cells corresponding to a Delete soft cell 1959 command is out of scope. 1961 2.6.4. Maintaining soft cells 1963 The monitoring process internal to 6top (Section 2.8) is responsible 1964 for monitoring and re-scheduling soft cells to meet some QoS 1965 requirements. The monitoring process MAY issue a soft cell 1966 Maintenance command, which indicate a set of cells to be re-allocated 1967 in the TSCH schedule. 1969 When receiving a soft cell Maintenance command, 6top initializes a 1970 Soft Cell Remove Request (Section 2.6.3) with the neighbor in 1971 question, followed by a Soft Cell Reservation Request 1972 (Section 2.6.2). 1974 2.6.5. Creating hard cells 1976 The upper layer instructs 6top to create one or more hard cells by 1977 calling the Create hard cell command. 1979 When receiving a Create hard cell command, Node A's 6top sublayer 1980 creates a Hard Cell Reservation Request, including a ScheduleIE. The 1981 ScheduleIE indicates which specific cells with a neighbor (Node B) to 1982 be added. The cells specified in the ScheduleIE SHOULD be added in 1983 local schedule of Node A while the Hard Cell Reserve Request is sent 1984 to Node B. When receiving the Hard Cell Reserve Request, the cells 1985 specified in the ScheduleIE SHOULD be added in the local schedule of 1986 Node B. 1988 2.6.6. Deleting hard cells 1990 The upper layer instructs 6top to delete one or more hard cells by 1991 calling the Delete hard cell command. 1993 When receiving a Delete hard cell command, Node A's 6top sublayer 1994 creates a Hard Cell Remove Request, including a ScheduleIE. The 1995 ScheduleIE indicates which specific cells with a neighbor (Node B) to 1996 be removed. The cells specified in the ScheduleIE SHOULD be removed 1997 from local schedule of Node A while the Hard Cell Remove Request is 1998 sent to Node B. When receiving the Hard Cell Remove Request, the 1999 cells specified in the ScheduleIE SHOULD be removed from the local 2000 schedule of Node B. 2002 2.7. Statistics 2004 The 6top Statistics Function (SF) is responsible for collecting 2005 statistics, which it can provide to an upper layer and the Monitoring 2006 Function (Section 2.8). 2008 2.7.1. Statistics Metrics 2010 6top is in charge of keeping statistics from a set of metrics 2011 gathered from the behavior of the TSCH layer. 2013 The statistics data related to node states and cell metrics SHOULD be 2014 provided to upper layer for management, e.g., for RPL to calculate 2015 the node's Rank or for GMPLS to the required bandwidth is met. The 2016 specific algorithm to generate the statistics is out of scope. 2018 However, the statistics component SHOULD include the following 2019 metrics: 2021 1. LinkThroughput: associated with a link, Node A->Node B. For 2022 example, LinkThroughput can be calculated with: 2023 SUM(NumOfCell(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration) 2024 where NumOfCell(i) is the total number of cells from Node A to 2025 Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i. 2026 The unit is Byte/second. 2028 2. Latency: associated with a link, Node A->Node B. For example, 2029 latency can be expressed as Minimum and Maximum Latency. Minimum 2030 Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum 2031 Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where, 2032 MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum 2033 number of timeslots between two dedicated cells from Node A to 2034 Node B in Slotframe-i, respectively. 2036 3. LinkQuality. For example, average LQI, ETX; 2038 4. TafficLoad. For example, Queue Full Rate, Queue Empty Rate; 2040 5. NodeEnergy. For example, E_E=E_bat / [E_0 (T-t)/T]. 2042 2.7.2. Statistics Configuration 2044 The Statistics Function SHOULD be configurable. The configuration 2045 parameters SHOULD include: 2047 LinkQualityStatisticsEn 2049 TafficLoadStatisticsEn 2051 DeviceStatisticsEn 2053 6top statistics function is enabled/disabled and configured by the 2054 commands defined in Section 2.4.4 2056 2.8. Monitoring 2058 The 6top Monitoring Function (MF) is responsible for monitoring cell 2059 quality, traffic load, and issuing soft cell Maintenance commands, or 2060 Create/Delete soft cell commands. The data provided by the 2061 Statistics Function MAY be used as an input of MF in taking a 2062 monitoring decision. 2064 2.8.1. Monitor Configuration 2065 Monitoring Function SHOULD be configurable. The configuration 2066 parameters SHOULD include: 2068 MaintainCellEn. 2070 CreateDeleteCellEn. 2072 QosLevel. QosLevel SHOULD associate with specific neighbor 2073 address. QosLevel MAY reflect the latency constraint, cell 2074 quality constraint, and so on. The value of QosLevel works as 2075 the bandwidth redundancy coefficient. 2077 The 6top monitoring function is enabled/disabled and configured by 2078 the commands defined in Section 2.4.3 2080 2.8.2. Actuation 2082 The cell quality statistics MAY be used to generate soft a cell 2083 Maintenance command, which triggers a soft cell Maintenance procedure 2084 (see Section 2.6.4). The traffic load statistics MAY be used to 2085 generate internal Create (resp. Delete) soft cell commands, which 2086 trggiers a soft cell Reservation (resp. Remove) process (see 2087 Section 2.6.2 and Section 2.6.3). 2089 The policy to generate the soft cell Maintenance command and the 2090 policy to generate Create/Delete soft cell commands is out of scope. 2092 The policy to generate Create/Delete soft cell commands MAY take 2093 QosLevel into account. For example, there are two slotframes 2094 existing, Slotframe-1 consists of 32 timeslots, Slotframe-2 consists 2095 of 96 timeslots; timeslot duration is 10ms; QosLevel=1.5. If, from 2096 the traffic load statistics, MF determines that 2 packet/second 2097 SHOULD be added, then the MF generates a Create soft cell command, 2098 where FrameID=2, NumCell=3. 2100 2.9. Label Switching 2102 Label Switching Fuction (LS) in 6top is responsible for maintaining 2103 the mapping of input cells and output cells in the same track in a 2104 particular node. By keeping that mapping, layer 3 routing can be 2105 avoided as packets are forwarded by the 6top sublayer according to 2106 the input cells they were received on. The selected output cell is 2107 one of the cells that forward the packet to the subsequent hop in the 2108 track. As cells can be grouped in bundles, 6top can maintain 2109 mappings from input bundles to output bundles and provide a policy to 2110 select the output cell according to the input cell. 2112 3. Using 6top 2114 This part describes how 6top gives support to specific upper layers. 2116 3.1. RPL on 6top 2118 6top provides a set of functionalities so higher layers can obtain 2119 information about the status of the network and take advantage of the 2120 slotted structure to improve metric calculation and objective 2121 function optimization. The following sections describe how RPL can 2122 make use of 6top sublayer. 2124 In order to optimize the combination of RPL and TSCH, 6top provides 2125 specific support to RPL in the following aspects: 2127 RPL Neighbor Discovery and Parent Selection 2129 RPL Rank Computation 2131 RPL Control Messages Broadcast 2133 QoS 2135 3.1.1. Support to Neighbor Discovery and Parent Selection 2137 The Section 2.4.7 defines a set of commands so the neighbor table can 2138 be managed and queried by RPL. An entry to the neighbor table is 2139 inserted whenever an EBs is received at L2. The EB causes the 6top 2140 sublayer to create an entry to the neighbors table. A neighbor table 2141 entry contains a set of statistics with respect to that specific 2142 neighbor such as the ASN when the last packet has been received from 2143 that neighbor, a set of cell quality metrics (RSSI, LQI), number of 2144 packets sent to it or number of packets received from it amongst 2145 others. 6top updates that table upon sending or reception of a packet 2146 from/to a neighbor. RPL can query at any time the neighbor table to 2147 retrieve information about a particular neighbor. This information 2148 can be used to compute the routing objective function as for example 2149 the Zero Objective function as described in 2150 [I-D.vilajosana-6tisch-minimal]. Parent selection can also be driven 2151 by the information contained on the neighbor table as well as 2152 complemented with the cells statistics defined in Section 2.4.4 and 2153 Section 2.7. 2155 6top enables RPL to configure EB periodicity. By controlling the EBs 2156 periodicity, RPL can configure how network dynamism and support to 2157 mobility are addressed, as more frequent beacons the more prone to 2158 cope with mobility. Section 2.4.5 enables to configure how the 2159 network is formed and EBs periodicity. 2161 RPL MAY want to select the policy to determine the time source 2162 neighbor, this can be interesting when time source neighbors can be 2163 aligned to the routing topology, i.e., the selected time source 2164 neighbor can be the node's favorite parent in a specific DODAG. 2165 Section 2.4.6 describes the 6top command to set up the desired 2166 policy. The policy is selected by RPL and enforced by the 6top 2167 sublayer. 2169 The rule for 6top to select and maintain time source neighbors is as 2170 follows: 2172 The time source neighbor of a node SHOULD be a member of the 2173 node's neighbor set. 2175 Time source neighbors SHOULD be the neighbors which have a 2176 relatively lower join priority in the neighbor set. A lower 2177 join priority indicates that the neighbor is closer to the TSCH 2178 PAN coordinator. 2180 The link between a node and one of its time source neighbors 2181 SHOULD be a good link quality. 2183 3.1.2. Support of Rank Computation 2185 The RPL objective function is computed using a set of metrics. The 2186 [I-D.vilajosana-6tisch-minimal] defines how Zero Objective Function 2187 is used to configure the rank and metrics used from 6top statistics. 2188 The specific metrics, and how the objective function is calculated 2189 are out of scope. However, 6top builds a set of functionalities to 2190 provide more accurate statistics of the underlying layer so the 2191 objective function can be accommodated to the nature of a TSCH MAC 2192 layer. 2194 6top provides statistics for rank computation as described in 2195 Section 2.4.4 and Section 2.7. The function used to compute the rank 2196 based on those statistics is out of scope. However, the provided 2197 metrics are aligned to the behavior of the TSCH MAC layer. 2199 3.1.3. Support of Control Messages Broadcast 2201 In RPL, some control messages, e.g., DIO in storing mode, need to be 2202 broadcast to all neighbor nodes. The broadcast channel requirement 2203 has to be addressed by 6top by configuring TSCH to provide such a 2204 channel. 2206 In order to decouple the upper (RPL) layer from TSCH, instead of 2207 carrying DIO messages in Enhance Beacons, 6top introduces a mechanism 2208 to establish broadcast cells. 2210 In TSCH schedule, every cell has the LinkType attribute. If 2211 LinkType=ADVERTISING, indicates that the cell MAY be used to send an 2212 Enhanced Beacon. When a node forms its Enhanced Beacon, the cell, 2213 with LinkType=ADVERTISING, SHOULD be included in the FrameAndLinkIE, 2214 and its LinkOption field SHOULD be set to the combination of 2215 "Receive" and "Timekeeping". The receiver of the Enhanced Beacon MAY 2216 be listening at the cell to get the Enhanced Beacon ([IEEE802154e]). 2217 6top takes this way to establish broadcast channel, which not only 2218 allows TSCH broadcast Enhanced Beacon, but also allows an upper layer 2219 like RPL broadcast. 2221 To support DIO and DAO broadcasts, 6top uses the payload of a Data 2222 Packet to carry the DIO or DAO. The message is inserted into the 2223 queue associated with the cells which LinkType is set to ADVERTISING. 2224 Then, taking advantage of the broadcast cell feature established with 2225 FrameAndLinkIE as described above, the data packet with DIO or DAO in 2226 the payload can be received by neighbors, which enforces to the 2227 maintenance of DODAG. 2229 A LinkOption combining "Receive" and "Timekeeping" bits indicates to 2230 the receivers of the Enhanced Beacon that the cell MUST be used as a 2231 broadcast cell. The frequency of sending Enhance Beacon or other 2232 broadcast messages by upper layer is determined by the timers 2233 associated with the messages. For example, the transmission of 2234 Enhance Beacons is triggered by a timer in 6top; transmission of a 2235 DIO message is triggered by the trickle timer of RPL. 2237 3.1.4. Support for QoS 2239 The TSCH MAC layer is decoupled from the upper layer, and the 2240 interaction between the upper layer ad TSCH is asynchronous. This 2241 means that the MAC layer executes a schedule and checks at each 2242 timeslot according to the type of cell whether there is something to 2243 send or receive. If that is the case the packet is transmitted and 2244 the MAC layer continues its operation. When an upper layer sends a 2245 packet, this packet is pushed into a queue waiting to the MAC layer 2246 to read it and send it in a particular timeslot according to is 2247 destination and priority (Section 2.3). 6top provides a set of queue 2248 management operations which enable upper layers to create different 2249 queues and determine their priorities. This allows different classes 2250 of traffic to be handled by the routing layer, i.e. inserting a 2251 packet to a specific queue according to its priority. 2253 A 6top implement MUST provide at least a Broadcast Queue, a Transmit 2254 Queue, and a Receive Queue. RPL can configure the queues with 2255 Internal Queueing Command (Section 2.4.8.1). The Broadcast Queue is 2256 associated with cells with LinkType=ADVERTISING in sender's schedule, 2257 and LinkOption="Receive" and "Timekeeping" in all neighbors' 2258 schedule. This indicates that the cells can be used as broadcast 2259 cells from the sender to its neighbors. A Transmit Queue is 2260 associated with the dedicated Transmit cells or Shared Cells. RPL 2261 can benefit from having different priority queues to improve latency 2262 or provide integrated services with different priorities, i.e. 2263 different traffic classes. 2265 Data Communication Commands (Section 2.4.10) can be used to send 2266 control messages and data messages. The operation is used to insert 2267 a message to an specific queue. 2269 For example a suitable configuration can include two Broadcast Queues 2270 with priority High and Low, respectively; three Transmit Queues, with 2271 priority High, Mid, and Low, respectively; and one Receive Queue. 2273 When DestAddr is a broadcast address, its related MAC layer packets 2274 will be pushed into the Broadcast Queue with the corresponding 2275 priority. 6top is responsible for feeding these packets to TSCH at 2276 broadcast cells. 2278 When DestAddr is unicast address, its related MAC layer packets will 2279 be push into the Transmit Queue with corresponding priority. 6top is 2280 responsible for feeding these packets to TSCH at Transmit cells or 2281 Shared Cells. 2283 6top conducts a QoS policy, which is out of scope. Here is an 2284 example. Packets in higher priority queue MUST be sent out before 2285 the packets in lower priority queue. Then, when there is an 2286 available broadcast/unicast cell, 6top checks the broadcast/unicast 2287 queue with higher priority first, if there is a packet, then feeds it 2288 to TSCH at the cell, otherwise it checks broadcast/unicast queue with 2289 lower priority further. 6top repeats the process, until it finds a 2290 broadcast/unicast packet to feed to TSCH or finds that all of 2291 broadcast/unicast queues are empty. 2293 3.2. GMPLS on 6top 2295 GMPLS is a 2.5 layer service that is used to forward packets based on 2296 the concept of generalized labels. Labels are determined by a 2297 reservation protocol during the formation of a multi-hop path. As 2298 defined by [RFC3471], [RFC3473] and [RFC4606] a generalized label 2299 identifies a flow of data through a set of nodes that conform to a 2300 multi-hop path. Instead of being written implicitly into a field in 2301 each packet, as is the case in MPLS [RFC3031], the generalized label 2302 is kept at each node in the form of a table. The table can be used 2303 to map input cells to output cells so routing decisions can be taken 2304 at that layer. 2306 In order to optimize the combination of GMPLS and TSCH, 6top provides 2307 specific support to GMPLS in the following aspects: 2309 Cell Reservation Support 2311 QoS 2313 3.2.1. Cell Reservation Support for GMPLS on 6top 2315 The GMPLS control plane is used to send path reservation requests and 2316 reservation confirmations. When reservation confirmations are 2317 received, GMPLS needs to configure the underlying MAC layer to 2318 provide the required bandwidth. 6top provides a set of commands to 2319 deal with bandwidth allocation, i.e., cell allocation. Section 2.4.1 2320 describes the operations that GMPLS layer MAY use for cell 2321 configuration. Note that 6top supports different types of 2322 reservations: soft cell and hard cell. How the reservation 2323 requirements are expressed is out of scope, but 6top is able to 2324 handle a reservation done as a specific bandwidth requirement, done 2325 through specifying exact cells. 2327 The [I-D.vilajosana-6tisch-minimal] defines a pre-configured schedule 2328 that can be used to bootstrap the network. Those cells can be seen 2329 as a GMPLS control plane where RPL routes can be formed and Track 2330 reservations issued. 2332 GMPLS can also give different priorities to its control plane and 2333 data plane. It can for example be interesting to have a higher 2334 priority for control messages so the network adapts to new bandwidth 2335 requirements quickly. In contrast, data plane messages can be given 2336 a higher priority when they need to meet higher throughput or lower 2337 latency. 6top provides commands (Section 2.4.8) to manage MAC layer 2338 queues and assign different priorities to them. 2340 3.2.2. Supporting QoS 2342 GMPLS can use 6top statistics to determine whether some QoS 2343 requirement is met. Metrics defined in Section 2.7 and operations 2344 defined in Section 2.4.4 can be used by GMPLS to trigger new 2345 bandwidth allocation, or to map different input bundles to output 2346 bundles. 2348 4. References 2350 4.1. Normative References 2352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2353 Requirement Levels", BCP 14, RFC 2119, March 1997. 2355 4.2. Informative References 2357 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2358 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2359 Functional Specification", RFC 2205, September 1997. 2361 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2362 Networks", RFC 2464, December 1998. 2364 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2365 Label Switching Architecture", RFC 3031, January 2001. 2367 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2368 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2370 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 2371 (GMPLS) Signaling Functional Description", RFC 3471, 2372 January 2003. 2374 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2375 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2376 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2378 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2379 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2380 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2381 RFC 3819, July 2004. 2383 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 2384 Protocol Label Switching (GMPLS) Extensions for 2385 Synchronous Optical Network (SONET) and Synchronous 2386 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 2388 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2389 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2390 Overview, Assumptions, Problem Statement, and Goals", RFC 2391 4919, August 2007. 2393 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2394 "Transmission of IPv6 Packets over IEEE 802.15.4 2395 Networks", RFC 4944, September 2007. 2397 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 2398 "Routing Requirements for Urban Low-Power and Lossy 2399 Networks", RFC 5548, May 2009. 2401 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 2402 Routing Requirements in Low-Power and Lossy Networks", RFC 2403 5826, April 2010. 2405 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 2406 "Building Automation Routing Requirements in Low-Power and 2407 Lossy Networks", RFC 5867, June 2010. 2409 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 2410 "Industrial Routing Requirements in Low-Power and Lossy 2411 Networks", RFC 5673, October 2009. 2413 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 2414 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2415 September 2011. 2417 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 2418 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 2419 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 2420 Lossy Networks", RFC 6550, March 2012. 2422 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 2423 Application Spaces for IPv6 over Low-Power Wireless 2424 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 2426 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 2427 Statement and Requirements for IPv6 over Low-Power 2428 Wireless Personal Area Network (6LoWPAN) Routing", RFC 2429 6606, May 2012. 2431 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 2432 for OAuth", RFC 6755, October 2012. 2434 [I-D.watteyne-6tsch-tsch-lln-context] 2435 Watteyne, T., Palattella, M., and L. Grieco, "Using 2436 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 2437 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 2438 context-02 (work in progress), May 2013. 2440 [I-D.thubert-6tisch-architecture] 2441 Thubert, P., Assimiti, R., and T. Watteyne, "An 2442 Architecture for IPv6 over the TSCH mode of IEEE 2443 IEEE802.15.4e", draft-thubert-6tisch-architecture-00 (work 2444 in progress), October 2013. 2446 [I-D.palattella-6tisch-terminology] 2447 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 2448 "Terminology in IPv6 over the TSCH mode of IEEE 2449 802.15.4e", draft-palattella-6tisch-terminology-00 (work 2450 in progress), October 2013. 2452 [I-D.vilajosana-6tisch-minimal] 2453 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 2454 Configuration", draft-vilajosana-6tisch-minimal-00 (work 2455 in progress), October 2013. 2457 [I-D.ohba-6tsch-security] 2458 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 2459 A. Yegin, "Security Framework and Key Management Protocol 2460 Requirements for 6TSCH", draft-ohba-6tsch-security-01 2461 (work in progress), July 2013. 2463 [I-D.thubert-roll-forwarding-frags] 2464 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 2465 Recovery", draft-thubert-roll-forwarding-frags-02 (work in 2466 progress), September 2013. 2468 [I-D.tsao-roll-security-framework] 2469 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 2470 Security Framework for Routing over Low Power and Lossy 2471 Networks", draft-tsao-roll-security-framework-02 (work in 2472 progress), March 2010. 2474 [I-D.thubert-roll-asymlink] 2475 Thubert, P., "RPL adaptation for asymmetrical links", 2476 draft-thubert-roll-asymlink-02 (work in progress), 2477 December 2011. 2479 [I-D.ietf-roll-terminology] 2480 Vasseur, J., "Terms used in Ruting for Low power And Lossy 2481 Networks", draft-ietf-roll-terminology-13 (work in 2482 progress), October 2013. 2484 [I-D.ietf-roll-p2p-rpl] 2485 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 2486 Martocci, "Reactive Discovery of Point-to-Point Routes in 2487 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17 2488 (work in progress), March 2013. 2490 [I-D.ietf-roll-trickle-mcast] 2491 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 2492 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 2493 mcast-05 (work in progress), August 2013. 2495 [I-D.thubert-6lowpan-backbone-router] 2496 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 2497 6lowpan-backbone-router-03 (work in progress), February 2498 2013. 2500 [I-D.sarikaya-core-sbootstrapping] 2501 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 2502 Cragie, "Security Bootstrapping Solution for Resource- 2503 Constrained Devices", draft-sarikaya-core- 2504 sbootstrapping-04 (work in progress), April 2012. 2506 [I-D.gilger-smart-object-security-workshop] 2507 Gilger, J. and H. Tschofenig, "Report from the 'Smart 2508 Object Security Workshop', 23rd March 2012, Paris, 2509 France", draft-gilger-smart-object-security-workshop-00 2510 (work in progress), October 2012. 2512 [I-D.phinney-roll-rpl-industrial-applicability] 2513 Phinney, T., Thubert, P., and R. Assimiti, "RPL 2514 applicability in industrial networks", draft-phinney-roll- 2515 rpl-industrial-applicability-02 (work in progress), 2516 February 2013. 2518 [I-D.ietf-core-coap] 2519 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 2520 Application Protocol (CoAP)", draft-ietf-core-coap-18 2521 (work in progress), June 2013. 2523 4.3. External Informative References 2525 [IEEE802154e] 2526 IEEE standard for Information Technology, "IEEE std. 2527 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2528 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2529 2012. 2531 [IEEE802154] 2532 IEEE standard for Information Technology, "IEEE std. 2533 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2534 and Physical Layer (PHY) Specifications for Low-Rate 2535 Wireless Personal Area Networks", June 2011. 2537 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , 2538 . 2540 [label-switching-154e] 2541 Morell, A., Vilajosana, X., Lopez-Vicario, J., and T. 2542 Watteyne, "Label Switching over IEEE802.15.4e Networks. 2543 Transactions on Emerging Telecommunications Technologies", 2544 June 2013. 2546 Authors' Addresses 2548 Qin Wang (editor) 2549 Univ. of Sci. and Tech. Beijing 2550 30 Xueyuan Road 2551 Beijing, Hebei 100083 2552 China 2554 Phone: +86 (10) 6233 4781 2555 Email: wangqin@ies.ustb.edu.cn 2557 Xavier Vilajosana 2558 Universitat Oberta de Catalunya 2559 156 Rambla Poblenou 2560 Barcelona, Catalonia 08018 2561 Spain 2563 Phone: +34 (646) 633 681 2564 Email: xvilajosana@uoc.edu 2566 Thomas Watteyne 2567 Linear Technology 2568 30695 Huntwood Avenue 2569 Hayward, CA 94544 2570 USA 2572 Phone: +1 (510) 400-2978 2573 Email: twatteyne@linear.com