idnits 2.17.1 draft-wang-6tsch-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). -- The document date (July 13, 2013) is 3911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 2677, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 2683, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 2689, but not defined == Unused Reference: 'RFC2119' is defined on line 2505, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 2510, but no explicit reference was found in the text == Unused Reference: 'RFC2464' is defined on line 2514, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 2520, but no explicit reference was found in the text == Unused Reference: 'RFC3819' is defined on line 2531, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 2541, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 2546, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 2550, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 2554, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 2558, but no explicit reference was found in the text == Unused Reference: 'RFC5673' is defined on line 2562, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 2566, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 2570, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 2575, but no explicit reference was found in the text == Unused Reference: 'RFC6606' is defined on line 2579, but no explicit reference was found in the text == Unused Reference: 'RFC6755' is defined on line 2584, but no explicit reference was found in the text == Unused Reference: 'I-D.palattella-6tsch-terminology' is defined on line 2599, but no explicit reference was found in the text == Unused Reference: 'I-D.vilajosana-6tsch-basic' is defined on line 2605, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tsch-security' is defined on line 2609, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 2615, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 2620, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 2626, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 2631, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 2636, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 2642, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 2647, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 2652, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 2658, but no explicit reference was found in the text == Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is defined on line 2664, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap' is defined on line 2670, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-02) exists of draft-thubert-6tsch-architecture-01 == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 == Outdated reference: A later version (-01) exists of draft-vilajosana-6tsch-basic-00 == Outdated reference: A later version (-02) exists of draft-thubert-roll-forwarding-frags-01 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-12 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-04 == Outdated reference: A later version (-05) exists of draft-sarikaya-core-sbootstrapping-04 == Outdated reference: A later version (-03) exists of draft-gilger-smart-object-security-workshop-00 Summary: 3 errors (**), 0 flaws (~~), 43 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: January 14, 2014 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 July 13, 2013 10 6TSCH Operation Sublayer (6top) 11 draft-wang-6tsch-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 time slot in that schedule corresponds to an atomic 18 link-layer resource, and can be allocated to any pair of neighbors in 19 the network. This allows the schedule to be built to tightly match 20 each node's bandwidth, latency and energy constraints, while ensuring 21 collision-free communication. The [IEEE802154e] standard does not, 22 however, present a mechanism to do so, as building and managing the 23 schedule is out of the standard's scope. Routing layers such as the 24 IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to 25 route multipoint-to-point traffic (from devices inside the LLN 26 towards a central control point) and point-to-multipoint traffic 27 (from the central control point to the devices inside the LLN). 28 Network layer overlays cannot be optimized and adapted to take 29 advantage of the cell-based topology created by the underlying TSCH 30 MAC layer as a missing set of functionalities need to be defined. 31 This document describes the 6TSCH Operation Sublayer (6top) and the 32 main commands it provides to upper network layers such as RPL or 33 GMPLS. The set of functionalities includes feedback metrics from 34 cell states so network layers can take routing decisions, TSCH 35 configuration and control procedures, and the support for centralized 36 and decentralized scheduling policies. In addition, 6top can be 37 configured to enable packet switching at layer 2.5, analogous to 38 GMPLS. Once a multi-hop track is defined, input cells can be mapped 39 to output cells and packets can be relayed without the need of higher 40 layer routing. 6top defines the operations so input cells and output 41 cells can be mapped and the configuration maintained. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on January 14, 2014. 60 Copyright Notice 62 Copyright (c) 2013 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. 6TSCH Operation Sublayer (6top) . . . . . . . . . . . . . . . 4 79 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2.2. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 5 81 2.2.1. hard cells . . . . . . . . . . . . . . . . . . . . . 7 82 2.2.2. soft cells . . . . . . . . . . . . . . . . . . . . . 7 83 2.3. Data Convey Model . . . . . . . . . . . . . . . . . . . . 7 84 2.4. Commands . . . . . . . . . . . . . . . . . . . . . . . . 9 85 2.4.1. Cell Commands . . . . . . . . . . . . . . . . . . . . 9 86 2.4.2. Slotframe Commands . . . . . . . . . . . . . . . . . 14 87 2.4.3. Monitoring Commands . . . . . . . . . . . . . . . . . 15 88 2.4.4. Statistics Commands . . . . . . . . . . . . . . . . . 17 89 2.4.5. Network Formation Commands . . . . . . . . . . . . . 19 90 2.4.6. Time Source Neighbor Commands . . . . . . . . . . . . 21 91 2.4.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 22 92 2.4.8. Queueing Commands . . . . . . . . . . . . . . . . . . 24 93 2.4.9. Security Commands . . . . . . . . . . . . . . . . . . 27 94 2.4.10. Data Commands . . . . . . . . . . . . . . . . . . . . 29 95 2.4.11. Label Switching Commands . . . . . . . . . . . . . . 30 97 2.5. Message Formats . . . . . . . . . . . . . . . . . . . . . 31 98 2.5.1. Information Elements . . . . . . . . . . . . . . . . 32 99 2.5.2. Packet Formats . . . . . . . . . . . . . . . . . . . 40 100 2.6. Time Sequence . . . . . . . . . . . . . . . . . . . . . . 45 101 2.6.1. Network Formation . . . . . . . . . . . . . . . . . . 45 102 2.6.2. Creating soft cells . . . . . . . . . . . . . . . . . 46 103 2.6.3. Deleting soft cells . . . . . . . . . . . . . . . . . 47 104 2.6.4. Maintaining soft cells . . . . . . . . . . . . . . . 48 105 2.6.5. Creating hard cells . . . . . . . . . . . . . . . . . 48 106 2.6.6. Deleting hard cells . . . . . . . . . . . . . . . . . 48 107 2.7. Statistics . . . . . . . . . . . . . . . . . . . . . . . 49 108 2.7.1. Statistics Metrics . . . . . . . . . . . . . . . . . 49 109 2.7.2. Statistics Configuration . . . . . . . . . . . . . . 49 110 2.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 50 111 2.8.1. Monitor Configuration . . . . . . . . . . . . . . . . 50 112 2.8.2. Actuation . . . . . . . . . . . . . . . . . . . . . . 50 113 2.9. Label Switching . . . . . . . . . . . . . . . . . . . . . 51 114 3. Using 6top . . . . . . . . . . . . . . . . . . . . . . . . . 51 115 3.1. RPL on 6top . . . . . . . . . . . . . . . . . . . . . . . 51 116 3.1.1. Support to Neighbor Discovery and Parent Selection . 51 117 3.1.2. Support of Rank Computation . . . . . . . . . . . . . 52 118 3.1.3. Support of Control Messages Broadcast . . . . . . . . 53 119 3.1.4. Support to QoS . . . . . . . . . . . . . . . . . . . 53 120 3.2. GMPLS on 6top . . . . . . . . . . . . . . . . . . . . . . 55 121 3.2.1. Cell Reservation Support for GMPLS on 6top . . . . . 55 122 3.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 55 123 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 124 4.1. Normative References . . . . . . . . . . . . . . . . . . 56 125 4.2. Informative References . . . . . . . . . . . . . . . . . 56 126 4.3. External Informative References . . . . . . . . . . . . . 59 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 129 1. Introduction 131 As presented in [I-D.watteyne-6tsch-tsch-lln-context], the 132 [IEEE802154e] standard defines the mechanisms for a TSCH node to 133 communicate, given a schedule. It does not, however, define the 134 policies to build and maintain the TSCH schedule, match that schedule 135 to the multi-hop paths maintained by a network layer such as RPL or a 136 2.5 layer such as GMPLS, adapt the resources allocated between 137 neighbor nodes to the data traffic flows, enforce a differentiated 138 treatment for data generated at the application layer and signaling 139 messages needed by 6LoWPAN and RPL to discover neighbors, react to 140 topology changes, self-configure IP addresses, or manage keying 141 material. 143 In a TSCH network, the MAC layer is not in charge of setting up the 144 schedule that controls the connectivity graph of the network and the 145 resources allocated to each cell in that topology. This 146 responsibility is left to an upper layer, defined in this document 147 and called "6top". 149 This document describes the 6TSCH Operation Sublayer (6top) and the 150 main commands provided to upper network layers such as RPL or GMPLS. 151 The set of functionalities include feedback metrics from cell state 152 so the network layer can take routing decisions, TSCH configuration 153 and control procedures, and support for centralized and decentralized 154 scheduling policies. 6top addresses the set of functionalities 155 described in [I-D.watteyne-6tsch-tsch-lln-context]. 157 For example, network formation in a TSCH network is handled by the 158 use of Enhanced Beacons (EB). EBs include information for joining 159 nodes to be able to synchronize and set up an initial network 160 topology. However, [IEEE802154e] does not specify how the period of 161 EBs is configured, nor the rules for a node to select a particular 162 node to join. 6top offers a set of commands so control mechanisms can 163 be introduced on top of TSCH to configure nodes to join a specific 164 node and obtain a unique 16-bit identifier from the network. Once a 165 network is formed, 6top maintains the network's health, allowing for 166 nodes to stay synchronized. It supplies mechanisms to manage each 167 node's time source neighbor and configure the EB interval. Network 168 layers running on top of 6top take advantage of the TSCH MAC layer 169 information so routing metrics, topological information, energy 170 consumption and latency requirements can be adjusted to TSCH, and 171 adapted to application requirements. 173 TSCH requires a mechanism to manage its schedule; 6top provides a set 174 of commands for upper layers to set up specific schedules, either 175 explicitly by detailing specific cell information, or by allowing 176 6top to establish a schedule given a bandwidth or latency 177 requirement. 6top is designed to enable centralized, decentralized or 178 hybrid scheduling entities. 6top enables internal TSCH queuing 179 configuration, size of buffers, packet priorities, transmission 180 failure behavior, and defines mechanisms to encrypt and authenticate 181 MAC slotframes. 183 As described in [label-switching-154e], due to the slotted nature of 184 TSCH networks, it is possible to use a label switched architecture on 185 top of TSCH cells. As a cell belongs to a specific track, a label 186 header is not needed at each packet; the input cell (or bundle) and 187 the output cell (or bundle) uniquely identify the data flow. The 188 6top sublayer provides operations to manage the cell mappings. 190 2. 6TSCH Operation Sublayer (6top) 191 2.1. Overview 193 6top is a sublayer which is the next-higher layer for TSCH, as 194 detailed in [I-D.thubert-6tsch-architecture]. 6top offers both 195 management and data interfaces to an upper layer. It includes 196 monitoring and statistics collection, both of which are configurable 197 through the management interface. 199 6top distinguishes between hard cells and soft cells. It therefore 200 requires an extra flag to all cells in the TSCH schedule, as detailed 201 in Section 2.2. 203 When a higher layer gives 6top a 6LoWPAN packet for transmission, 204 6top maps it to the appropriate outgoing priority-based queue, as 205 detailed in Section 2.3. 207 All commands of the management and data interfaces are detailed in 208 Section 2.4. This set of commands is designed to support 209 centralized, decentralized and hybrid scheduling entities. 211 6top defines TSCH Information Elements (IEs) for neighbors nodes to 212 negociate scheduling cells in the TSCH schedule. The format of those 213 is given in Section 2.5. 215 Example data exchanges between neighbor nodes are illustrated in 216 Section 2.6. 218 Section 2.7 defines how 6top gathers statistics (e.g. link quality, 219 energy level, queue usage), and what commands an upper layer can use 220 to configure and retrieve statistics. 222 6top can be configured to monitor some cells it has scheduled in 223 order to detect cells with poor performance. It can then 224 automatically move those cells inside the TSCH schedule. This 225 behavior is described in Section 2.8 227 2.2. Cell Model 229 IEEE802.15.4e defines a set of options attached to each cell. A cell 230 can be a Transmit cell, a Receive cell, a Shared cell or a 231 Timekeeping cell. These options are not exclusive, as a cell can be 232 qualified with more than one of them. The IEEE802.15.4e MLME-SET- 233 LINK.request command uses a linkOptions bitmap to specify the options 234 of a cell. Acceptable values are: 236 b0 = Transmit 238 b1 = Receive 239 b2 = Shared 241 b3 = Timekeeping 243 b4-b7 = Reserved 245 Only Transmit cells can also be marked as Shared cells. When the 246 shared bit is set, a back-off procedure is applied to handle 247 collisions. Shared behavior does not apply to Receive cells. 249 6top allows an upper layer to schedule a cell at a specific timeslot 250 and channel offset, in a specific slotframe. 6top follows the hard 251 cell reservation process described in Section 2.6.5. 253 In addition, 6top allows an upper layer to schedule a certain amount 254 of bandwidth to a neighbor, without having to specify the exact 255 timeslot(s) and channel offset(s). 6top follows the soft cell 256 reservation process described in Section 2.6.2. Once bandwidth is 257 reserved, 6top is in charge of ensuring that this requirement is 258 continuously satisfied, as described in Section 2.8. 6top dynamically 259 reallocates slots if needed, and overprovisions if required. 261 6top allows an upper layer to associate a hard/soft cell with a 262 specific track by using a TrackID. A TrackID is a tuple 263 (TrackOwnerAddr,InstanceID), where TrackOwnerAddr is the address of 264 the node which initalizes the process of creating the track, i.e. the 265 owner of the track; and InstanceID is an instance identifier given by 266 the owner of the track. InstanceID comes from upper layer; 267 InstanceID could for example be the local instance ID defined in RPL. 269 If the TrackID is set to (0,0), the cell can be used by the best- 270 effort QoS configuration or as a Shared cell. If the TrackID is not 271 set to (0,0), i.e. the cell belongs to a specific track, the cell 272 must not be set as Shared cell. 274 Given this mechanism, 6top defines hard cells (which have been 275 requested specifically) and soft cells (which that can be reallocated 276 dynamically). The hard/soft flag is introduced by the 6top sublayer 277 as an extension of the IEEE802.15.4e LinkOption flags. This option 278 is mandatory; all cells are either hard or soft. 280 With the addition of the Hard/Soft flag, the resulting flags are: 282 b0 = Transmit 284 b1 = Receive 286 b2 = Shared 287 b3 = Timekeeping 289 b4 = Hard (1)/Soft (0) 291 b5-b7 = Reserved 293 2.2.1. hard cells 295 A hard cell is a cell that cannot be dynamically reallocated by 6top. 296 A hard cell is uniquely identified by the following tuple: 298 slotframe id: id of the slotframe this cell is part of. 300 timeslot: the slot within the slotframe. 302 channel offset. 304 LinkOption bitmap: bitmap as defined in Section 2.2, including the 305 hard/soft bit which must be set to 1. 307 2.2.2. soft cells 309 A soft cell is a cell that can be reallocated by 6top dynamically. 310 The hard/soft bit must be set to 0. This cell is installed by 6top 311 given a specific bandwidth requirement. soft cells are installed 312 through the soft cell negotiation procedure described in Section 2.6. 314 2.3. Data Convey Model 316 Once a TSCH schedule is established, 6top is responsible for feeding 317 the data flow from the upper layer into TSCH. This section describes 318 how 6top shapes data from the upper layer (e.g. RPL, 6LoWPAN), and 319 feeds it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, 320 the properties associated with a packet/fragment from the upper layer 321 includes the next hop neighbor (DestAddr) and expected sending 322 priority of the packet (Priority), and/or TrackID(s). The output to 323 TSCH is the fragment corresponding to the next active cell in the 324 TSCH schedule. 326 6top Data Convey Model 327 | 328 | (DestAddr, Priority, Fragment) 329 | 330 +---------------------------------------+ 331 | I-MUX | 332 +---------------------------------------+ 333 | | | | .... | 334 | | | | | 335 +---+ +---+ +---+ +---+ +---+ 336 | | | | | | | | | | 337 |Q1 | |Q2 | |Q3 | |Q4 | |Qn | 338 | | | | | | | | | | 339 +---+ +---+ +---+ +---+ +---+ 340 | | | | | 341 | | | | | 342 +---------------------------------------+ 343 | MUX | 344 +---------------------------------------+ 345 | 346 | 347 +---+ 348 |PDU| 349 +---+ 350 | 351 | TSCH MAC-payload 352 | 354 Figure 1 356 In Figure 1, Qi represents a queue, which is either broadcast or 357 unicast, and is assigned a priority. The number of queues is 358 configurable. The relationship between queues and tracks is 359 configurable. For example, for a given queue, only one specific 360 track can be used, or all of the tracks can be used, or a subset of 361 tracks can be used. 363 When 6top receives a packet to transmit through a Send.data command 364 (Section 2.4.10), the I-MUX module selects a queue in which to insert 365 it. If the packet's destination address is a unicast (resp. 366 broadcast) address, it will be inserted into a unicast (resp. 367 broadcast) queue. 369 The MUX module is invoked at each scheduled transmit cell by TSCH. 370 When invoked, the MUX module goes through the queues, looking for the 371 best frame to send. If it finds a frame, it hands it over to TSCH 372 for transmission. If the next active cell is a broadcast cell, it 373 selects a fragment only from broadcast queues. 375 How the MUX module selects the best frame is configurable. 376 Typically, the following rules are used: 378 The frame's layer 2 destination address must match the neighbor 379 address associated with the transmit cell. 381 If the transmit cell is associated with a specific track, the 382 frames in the queue corresponding to the TrackID have the highest 383 priority. 385 If the transmit cell is not associated with a specific track, i.e. 386 TrackID=(0,0), frames from a queue with a higher priority must be 387 sent before frames from a queue with a lower priority. 389 Further rules can be configured to satisfy specific QoS requirements. 391 2.4. Commands 393 6top provides a set of commands a higher layer can call, including 394 management commands and data commands. Most of these commands are 395 related to the management of slotframes, time slots and scheduling 396 information. 6top also provides an interface allowing an upper layer 397 to retrieve status information and statistics. This section lists 398 the commands offered by 6top. 400 2.4.1. Cell Commands 402 The following methods allow an upper layer to manage the network 403 schedule: 405 2.4.1.1. CREATE.hardcell 407 Creates one or more hard cells in the schedule. Fails if the cell 408 already exists. A cell is uniquely identified by the tuple 409 (slotframe id, timeslot, channel offset). 411 To create a hard cell, the upper layer specifies: 413 slotframe id: id of the slotframe this slot will be scheduled in. 415 time slot: the specific time slot number. 417 channel offset: the frequency offset. 419 LinkOption bitmap: bitmap as defined in Section 2.2 420 target node address: the address of that node to communicate with 421 over this cell. In case of broadcast cells this is the broadcast 422 address. 424 TrackID: id of the track the cell will belong to. 426 6top schedules the cell and marks it as a hard cell, indicating that 427 it cannot reschedule this cell. 429 2.4.1.2. CREATE.softcell 431 To create a soft cell, the upper layer specifies: 433 slotframe id: id of the slotframe this slot will be scheduled in 435 number of cells: the required number of soft cells. 437 LinkOption bitmap: bitmap as defined in Section 2.2 439 target node address: the address of that node to communicate with 440 over this cell. In case of broadcast cells this is the broadcast 441 address. 443 TrackID: id of the track the cell will belong to. 445 QoS level: the cell redundancy policy. The policy can be for 446 example STRICT, BEST_EFFORT, etc. 448 6top is responsible for picking the exact timeslot and channel offset 449 in the schedule, and ensure that the target node choose the same cell 450 and TrackID. 6top marks these cells as soft cell, indicating that it 451 will continuously monitor their performance and reschedule if needed. 453 6top deals with the allocation process by negotiation with the target 454 node. The negotiation process is described in Section 2.6.2. The 455 command returns the list of created cells defined by (slotframe id, 456 time slot number, channel offset). It fails if the required number 457 of cells is higher than the available number of cells in the 458 schedule. It fails if the negotiation with the target node fails. 459 It fails if the cell Option bitmap indicates that the cell MUST be 460 Hard. 462 2.4.1.3. READ.cell 464 Given a (slotframe id, time slot number, channel offset), retrieves 465 the cell information. Fails if the cell does not exist. The 466 returned information contains: 468 slotframe id: the id of the slotframe where this cell is 469 installed. 471 time slot: the time slot where the cell is set. 473 channel offset: the selected channel offset for the cell. 475 LinkOption bitmap: bitmap as defined in Section 2.2 477 target node address: the target address of that cell. In case of 478 broadcast cells this is the broadcast address. 480 TrackID: id of the track the cell will belong to. 482 A read command can be issued for any cell, hard or soft. 484 2.4.1.4. UPDATE.cell 486 Update a hard cell, i.e. move it to a different timeslot and/or 487 channel offset. Fails if the cell does not exist. Requires a 488 (slotframe id, time slot, channel offset), type of cell, target node 489 and TrackID are the fields that can be updated. soft cells cannot be 490 updated by the UPDATE.cell command. REALLOCATE.softcell 491 (Section 2.4.1.7) MUST be used instead. 493 2.4.1.5. DELETE.hardcell 495 To removes a hard cell, the upper layer specifies: 497 slotframe id: the id of the slotframe where this cell is 498 installed. 500 time slot: the time slot where the cell is set. 502 channel offset: the selected channel offset for the cell. 504 This removes the hard cell from the node's schedule. 506 2.4.1.6. DELETE.softcell 508 To remove a (number of) soft cell(s), the upper layer specifies: 510 slotframe id: the id of the slotframe where this cell is 511 installed. 513 number of cells: the number of cells to be removed 515 LinkOption bitmap: bitmap as defined in Section 2.2 516 target node address: the target address of that cell. In case of 517 broadcast cells this is the broadcast address. 519 TrackID: id of the track the cell will belong to. 521 In the case a soft cell wants to be moved from the allocated slot so 522 a hard cell can be installed instead, the REALLOCATE.softcell 523 (Section 2.4.1.7) MUST be used. 525 2.4.1.7. REALLOCATE.softcell 527 To force a move of a soft cell, the upper layer specifies: 529 slotframe id: the id of the slotframe where the cell is allocated. 531 time slot: the slot number where that cell is installed. 533 channel offset: the channel offset for that cell. 535 The reallocated cell will be installed in a different slot, channel 536 offset but slotframe and TrackID remain the same. Hard cells cannot 537 be reallocated. 539 2.4.1.8. Hardcell Command Behavior 541 The following table describe the behavior of 6top upon reception of 542 the hard cell management commands. 544 hard cell Operations behavior 545 +---------------------------------+---------------------------------+ 546 | 6top commands | 6top behavior | 547 +---------------------------------+---------------------------------+ 548 | Create.hardcell | 6top_ReserveHardCellReq() -ACK | 549 | (NeigAddr, TrackID, SlotframeID,| | 550 | SlotOffset, | If NeigAddr ==Broadcast Address| 551 | ChannelOffset, LinkOption) | Then LinkType=ADVERTISING | 552 | | Add cell to EB's FrameAndCellIE | 553 +---------------------------------+---------------------------------+ 554 | Read.cell | MLME-GET.request | 555 |(NeigAddr, TrackID | | 556 | SlotframeID,SlotOffset, | | 557 | ChannelOffset, LinkOption) | | 558 +---------------------------------+---------------------------------+ 559 | Delete.hardcell | 6top_RemoveHardCellReq() --ACK | 560 | (NeigAddr, TrackID, | | 561 | SlotOffset, | | 562 | ChannelOffset, LinkOption) | If LinkType=ADVERTISING, it is a| 563 | | broadcast cell, Then Remove cell| 564 | | from EB's FrameAndCellIE | 565 +---------------------------------+---------------------------------+ 566 | Update.cell | 6top_RemoveHardCellReq() --ACK | 567 | (OldFrameID, OldSlotOffset, | 6top_ReserveHardCellReq() --ACK | 568 | OldChannelOffset, NewFrameID, | (with same NeigAddr, TrackID, | 569 | NewSlotOffset,NewChannelOffset)| LinkOption) | 570 | | If old cell is in EB | 571 | | Then modify EB | 572 +---------------------------------+---------------------------------+ 574 2.4.1.9. Softcell Command Behavior 576 The following table describe the behavior of 6top upon reception of 577 the Softcell management commands. 579 soft cell Operations behavior 580 +--------------------------------+----------------------------------+ 581 | 6top commands | 6top behavior | 582 +--------------------------------+----------------------------------+ 583 | Create.softcell | 6top_ReserveSoftCellReq() -ACK | 584 |(NeigAddr, TrackID, | | 585 | NumCell,LinkOption, | ACK ---6top_ReserveSoftCellResp()| 586 | SlotframeID, QoSLevel) | | 587 +--------------------------------+----------------------------------+ 588 | Read.cell | MLME-GET.request | 589 |(NeigAddr, TrackID, | | 590 | SlotframeID, | | 591 | SlotOffset,ChannelOffset) | | 592 +--------------------------------+----------------------------------+ 593 | Delete.softcell | 6top_RemoveSoftCellReq() -- ACK | 594 | (NeigAddr, TrackID ,NumCell, | If LinkType =ADVERTISING | 595 | LinkOption, SlotframeID) | i.e. a broadcast cell Then Remove| 596 | | cell from EB's FrameAndCellIE | 597 +--------------------------------+----------------------------------+ 598 | Reallocate.softcell | 6top_RemoveSoftCellReq() -- ACK | 599 |(NeigAddr, TrackID | 6top_ReserveSoftCellReq() -- ACK | 600 | SlotframeID, | ACK ---6top_ReserveSoftCellResp()| 601 | SlotOffset,ChannelOffset) | | 602 +--------------------------------+----------------------------------+ 604 2.4.2. Slotframe Commands 606 6top provides the following commands to manage TSCH slotframes. 608 2.4.2.1. CREATE.slotframe 610 Creates a new slotframe. Returns the slotframe id that corresponds 611 to its priority (SlotFrameHandle). The command requires: 613 number of slots: the required number of slots. 615 Fails if the number of required slots is less than zero. 617 2.4.2.2. READ.slotframe 619 Returns the information of a slotframe given its slotframe id. The 620 command returns: 622 slotframe id: the id of the slotframe. (SlotFrameHandle) 624 number of slots: the number of slots. 626 Fails if the slotframe id does not exist. 628 2.4.2.3. UPDATE.slotframe 630 Change the number of slots in a slotframe. The command requires: 632 slotframe id: the id of the slotframe. 634 number of slots: the number of slots to be updated. 636 Fails if the number of required slots is less than zero. Fails if 637 the slotframe id does not exist. 639 2.4.2.4. DELETE.slotframe 641 Deletes a slotframe. The command requires: 643 slotframe id: the id of the slotframe. 645 Fails if the slotframe id does not exist. 647 2.4.2.5. Slotframe Command Behavior 649 The following table describes the behavior of 6top upon reception of 650 the Slotframe management commands. 652 Slotframe Management Operations behavior 654 +--------------------------------+----------------------------------+ 655 | 6top commands | 6top behavior | 656 +--------------------------------+----------------------------------+ 657 | Create.slotframe(NumSlot) | MLME-SET-SLOTFRAME.request | 658 | |(operation=ADD) | 659 +--------------------------------+----------------------------------+ 660 | Read.slotframe(SlotframeID) | MLME-GET.request | 661 +--------------------------------+----------------------------------+ 662 | Delete.slotframe(SlotframeID) | MLME-SET-SLOTFRAME.request | 663 | |(operation=DELETE) | 664 +--------------------------------|----------------------------------+ 665 | Update.slotframe(SlotframeID | MLME-SET-SLOTFRAME.request | 666 | ,NumSlot) |(operation=MODIFY) | 667 +--------------------------------+----------------------------------+ 669 2.4.3. Monitoring Commands 670 Monitoring commands provide the means for upper layers to configure 671 whether 6top must ensure the required bandwidth. This procedure is 672 achieved through over-provisioning according to cell status feedback. 673 Monitoring is also in charge of reallocating soft cells that are 674 under the required QoS. The mechanism is described in Section 2.8. 676 2.4.3.1. CONFIGURE.monitoring 678 Configures the level of QoS the Monitoring process must enforce. The 679 command requires: 681 slotframe id: the id of the slotframe. 683 target node: the destination node. 685 enforce policy: The policy used to enforce the QoS requirements. 686 Can be for example DISABLE, BEST_EFFORT, STRICT, OVER-PROVISION, 687 etc. 689 Fails if the slotframe id does not exist. 691 2.4.3.2. READ.monitoring.status 693 Reads the current Monitoring status. Requires the following 694 parameters. 696 slotframe id: the id of the slotframe. 698 target node: the destination node. 700 Returns the QoS levels for that Target node on that slotframe. 702 allocated_hard: Number of hard cells allocated. 704 allocated_soft: Number of soft cells allocated. 706 provisioned: the extra provisioned cells. 0 if CONFIGURE.qos 707 enforce is DISABLE. 709 QoS: the current QoS. Including overprovisioned cells, i.e what 710 bandwidth is being obtained including the overprovisioned cells. 712 RQoS: the real QoS without provisioned cells. What is the actual 713 bandwidth without taking into account the overprovisioned cells. 715 Fails if the slotframe id does not exist. 717 2.4.3.3. Monitoring Command Behavior 719 The following table describes the behavior of 6top upon reception of 720 the Monitoring management commands. 722 Monitoring Management Operations behavior 724 +------------------------------------+------------------------------+ 725 | 6top commands | 6top behavior | 726 +------------------------------------+------------------------------+ 727 | Configure.monitoring(NeigAdd, | Create/Update Monitoring MIB | 728 | SlotframeID,Enforce) | Starts monitoring service | 729 +------------------------------------+------------------------------+ 730 | Read.monitoring.status(SlotframeID)| Reads 6top Monitoring MIB | 731 +------------------------------------+------------------------------+ 733 Figure 2 735 2.4.4. Statistics Commands 737 6top keeps track of TSCH statistics for upper layers to adapt 738 correctly to medium changes. The exact metrics for statistics are 739 out of the scope of this document but the present commands should be 740 used to configure and read monitored information regardless of the 741 specific metric. 743 2.4.4.1. CONFIGURE.statistics 745 Configures Statistics process. The command requires: 747 slotframe id: the id of the slotframe. If empty monitors all 748 slotframe ids 750 time slot: slot number to be monitored. If empty all slots are 751 monitored 753 channel offset: specific channel offset to be monitored. If empty 754 all channels are monitored. 756 target node: the destination node. If empty, all target nodes are 757 monitored. 759 metric: metric to be monitored. This may be PDR, ETX, queuing 760 statistics, energy-related metrics, etc.) 762 window: time window to be considered for the calculations. If 0 763 all historical data is considered. 765 enable: Enables statistics or disables them. 767 Fails if the slotframe id does not exist. The statistics service can 768 be configured to retrieve statistics at different levels. For 769 example to aggregate information by slotframe id, or to retrieve 770 statistics for a particular slot, etc. the CONFIGURE.statistics 771 enables flexible configuration by supporting empty parameters that 772 will force the monitoring of the statistics by all members of that 773 dimension. 775 2.4.4.2. READ.statistics 777 Reads a metric for the specified dimension. Information is 778 aggregated according to the parameters. The command requires: 780 slotframe id: the id of the slotframe. If empty aggregates 781 information of all slotframe ids 783 time slot: the slot number for which the information is required. 784 If empty all slots are aggregated 786 channel offset: the specific channel offset for which the 787 information is required. If empty all channels are aggregated. 789 target node: the destination node. If empty all target nodes are 790 aggregated. 792 metric: metric to be read. 794 Returns the value for the requested metric. 796 Fails if empty metric or metric does not exits. 798 2.4.4.3. RESET.statistics 800 Resets the gathered statistics. The command requires: 802 slotframe id: the id of the slotframe. If empty resets the 803 information of all slotframe ids 805 time slot: the slot number for which the information wants to be 806 reset. If empty statistics from all slots are reset 808 channel offset: the specific channel offset for which the 809 information wants to be reset. If empty all statistics for all 810 channels are reset. 812 target node: the destination node. If empty all statistics for 813 the target node are reset. 815 metric: metric to be reset. 817 Fails if empty metric or metric does not exits. 819 2.4.4.4. Statistics Command Behavior 821 The following table describes the behavior of 6top upon reception of 822 the Statistics management commands. 824 Statistics Management Operations behavior 826 +--------------------------------+----------------------------------+ 827 | 6top commands | 6top behavior | 828 +--------------------------------+----------------------------------+ 829 | Configure.statistics | | 830 | (SlotFrameID,TSlot, ChannelOff,| Configures Statistics MIB. | 831 | NeigAdd,Metric,Window,En) | Enables statistics service | 832 +--------------------------------+----------------------------------+ 833 | Read.statistics(SlotFrameID) | Returns the statistic MIB for the| 834 | Ch.Off,NeigAdd,Metric) | requested parameters | 835 +--------------------------------+----------------------------------+ 836 | Reset.statistics(SlotFrameID) | Resets the required statistic MIB| 837 | Ch.Off,NeigAdd,Metric) | | 838 +--------------------------------+----------------------------------+ 840 2.4.5. Network Formation Commands 842 EBs need to be configured, including their transmission period, the 843 slot number and channel offset that they should be sent on, and the 844 priority announced. The parameters for that command are optional and 845 enable a very flexible configuration of EBs. If slotframe id is 846 specified, the EBs will be configured to use that specific slotframe; 847 if not they will use the first slotframe where the configured time 848 slot is allocated. Time slot enforces the EB to a specific time 849 slot. In case time slot parameter is not present, the EB is sent in 850 the first available transmit time slot. In case channel offset 851 parameter is not set, the EB is configured to use the first available 852 channel. 854 2.4.5.1. CONFIGURE.eb 856 Configures EBs. The command requires: 858 slotframe id: the id of the slotframe where the EBs MUST be sent. 859 Zero if any slotframe can be used. 861 time slot: the slot number where the EBs MUST be sent. Zero if 862 any timeslot can be used. 864 channel offset: the channel offset where the EBs MUST be sent. 865 Zero if any channel offset can be used. 867 period: the EBs period, in seconds. 869 expires: when the EBs periodicity will stop. If Zero the period 870 never stops. 872 priority: the joining priority model that will be used for 873 advertisement. Joining priority MAY be for example 874 SAME_AS_PARENT, RANDOM, BEST_PARENT+1. 876 Fails if the tuple (slotframe id, timeslot, channel offset) is 877 already scheduled. 879 2.4.5.2. READ.eb 881 Reads the EBs configuration. No parameters are required. 883 Returns the current EBs configuraton for that slotframe, which 884 contains: 886 slotframe id: the slotframe where the EB is being sent. 888 time slot: the slot number where the EBs is being sent. 890 channel offset: the channel offset the EBs is being sent on. 892 period: the EBs period. 894 expires: when the EBs periodicity stops. If 0 the period never 895 stops. 897 priority: the joining priority that this node advertises. 899 Fails if the slotframe id does not exist. 901 2.4.5.3. Network Formation Command Behavior 903 The following table describes the behavior of 6top upon reception of 904 the Network Configuration management commands. 906 Network Configuration Management Operations behavior 908 +----------------------------------+--------------------------------+ 909 | 6top commands | 6top behavior | 910 +----------------------------------+--------------------------------+ 911 | Configure.EB(SlotFrameID,TSlot, | Configures the 6top MIB | 912 | Ch.Off,Period,Expires,Prio,Con_p)| regarding EB configuration | 913 +----------------------------------+--------------------------------+ 914 | Read.EB() | Reads 6top EB MIB | 915 | | | 916 +----------------------------------+--------------------------------+ 918 2.4.6. Time Source Neighbor Commands 920 Commands to select time source neighbors. 922 2.4.6.1. CONFIGURE.timesource 924 Configures the Time Source Neighbor selection process. More than one 925 time source neighbor can be selected. The command requires: 927 selection policy: The policy used to select the time parent. The 928 policy MAY be for example ALL_PARENTS, BEST_CONNECTED, 929 LOWEST_JOIN_PRIORITY, etc. 931 Fails if any of the time source neighbors do not exist or it is not 932 reachable. 934 2.4.6.2. READ.timesource 936 Retrieves information about the time parents of that node. The 937 command does not require any parameter. 939 Returns the following information for each of the time sources: 941 target node: address of the time parent. 943 statistics: includes for example minimum, maximum, average time 944 correction for that time parent 946 policy: the used policy 948 Fails if the slotframe id or no time source neighbors exist. 950 2.4.6.3. Time Source Neighbor Command Behavior 952 The following table describes the behavior of 6top upon reception of 953 the Time Source Neighbor Configuration management commands. 955 Time Source Neighbors Configuration Management Operations behavior 957 +---------------------------------+---------------------------------+ 958 | 6top commands | 6top behavior | 959 +---------------------------------+---------------------------------+ 960 | Configure.timesource(Policy) | Configures the 6top MIB | 961 | | regarding timesource parents | 962 +---------------------------------+---------------------------------+ 963 | Read.timesource() | Read 6top timesource MIB | 964 | | | 965 +---------------------------------+---------------------------------+ 967 Figure 3 969 2.4.7. Neighbor Commands 971 Commands to manage neighbor table. The commands SHOULD be used by 972 the upper layer to query the neighbor related information and by the 973 lower layer to keep track of neighbors information. 975 2.4.7.1. CREATE.neighbor 977 Creates an entry for a neighbor in the neighbor table. 979 neighbor address: The address of the neighbor. 981 neighbor stats: for example, RSSI of the last received packet from 982 that neighbor, ASN when that neighbor has been added, etc. 984 Returns whether the neighbor is created or not. 986 2.4.7.2. READ.all.neighbor 988 Returns the list of neighbors of that node. Fails if empty. For 989 each neighbor in the list it returns: 991 neighbor address: The address of the neighbor. 993 neighbor stats: for example, RSSI of the last received packet from 994 that neighbor, ASN when that neighbor has been added, packets 995 received from that neighbor, packets sent to it, etc. . 997 2.4.7.3. READ.neighbor 999 Returns the information of a specific neighbors of that node 1000 specified by its neighbor address. Fails if it does not exists. For 1001 that neighbor it returns: 1003 neighbor address: The address of the neighbor. 1005 neighbor stats: for example, RSSI of the last received packet from 1006 that neighbor, ASN when that neighbor has been added, packets 1007 received from that neighbor, packets sent to it, etc. 1009 2.4.7.4. UPDATE.neighbor 1011 Updates an entry for a neighbor in the neighbor table. Fails if the 1012 neighbor does not exist. Updates stats parameters. Requires: 1014 neighbor address: The address of the neighbor. 1016 neighbor stats: for example, RSSI of the last received packet from 1017 that neighbor, ASN when that neighbor has been added, etc. . 1019 Returns whether the neighbor is updated or not. 1021 2.4.7.5. DELETE.neighbor 1023 Deletes a neighbor given its address. Fails if the neighbor does not 1024 exists. 1026 2.4.7.6. Neighbors Command Behavior 1028 The following table describes the behavior of 6top upon reception of 1029 the Neighbors Configuration management commands. 1031 Neighbors Management Operations behavior 1032 +---------------------------------+---------------------------------+ 1033 | 6top commands | 6top behavior | 1034 +---------------------------------+---------------------------------+ 1035 | Create.neighbor(address,stats) | Adds a neighbor to the neighbor | 1036 | | table in the 6top MIB. | 1037 +---------------------------------+---------------------------------+ 1038 | Read.all.neighbor() | lists all neighbors from the | 1039 | | neighbor table. | 1040 +---------------------------------+---------------------------------+ 1041 | Read.neighbor(address) | Reads neighbor information from | 1042 | | neighbor table in the 6top MIB | 1043 +---------------------------------+---------------------------------+ 1044 | Update.neighbor(address,stats) | Updates an entry for a neighbor | 1045 | | in the 6top MIB | 1046 +---------------------------------+---------------------------------+ 1047 | Delete.neighbor(address) | Removes the neighbor from the | 1048 | | 6top MIB | 1049 +---------------------------------+---------------------------------+ 1051 2.4.8. Queueing Commands 1053 TSCH MAC layer queues need to be configured. This includes queue 1054 length, retransmission policy, discarding of packets, etc. 1056 2.4.8.1. CREATE.queue 1058 Creates and Configures TSCH Queues. The command SHOULD be applied 1059 for each required queue. The command requires: 1061 txqlength: the desired transmission queue length. 1063 rxqlength: the desired reception queue length. 1065 numrtx: number of allowed retransmissions. 1067 age: discard packet according to its age on the queue. 0 if no 1068 discards are allowed. 1070 rtxbackoff: retransmission back off in number of slotframes. 0 if 1071 next available slot wants to be used. 1073 statswindow: window of time used to compute stats. 1075 queue priority: the priority of this queue. 1077 TrackIDs: a set of TrackIDs. While it is empty, no specific track 1078 is associated with the queue 1080 Returns the queue id. 1082 2.4.8.2. READ.queue 1084 Reads the queue configuration. Requires the queue id. 1086 The command returns: 1088 txqlength: the transmission queue length. 1090 rxqlength: the reception queue length. 1092 numrtx: number of allowed retransmissions. 1094 age: maximum age of a packet befoer being discarded. 0 if no 1095 discards are allowed. 1097 rtxbackoff: retransmission backoff in number of slotframes. 0 if 1098 next available slot is used. 1100 2.4.8.3. READ.queue.stats 1102 Reads the queue stats. Requires queue id. 1104 The command returns: 1106 txqlengthstats: average, maximum, minimum length of the 1107 transmission queue. 1109 rxqlengthstats: average, maximum, minimum length of the reception 1110 queue. 1112 numrtxstats: average, maximum, minimum number of retransmissions. 1114 agestats: average, maximum, minimum age of a packet in the queue. 1116 rtxbackoffstats: average, maximum, minimum retransmission backoff. 1118 queue priority: the priority of this queue. 1120 TrackIDs: a set of TrackIDs. 1122 2.4.8.4. UPDATE.queue 1124 Update a TSCH Queue. The command requires: 1126 queueid: the queue id. 1128 txqlength: the desired transmission queue length. 1130 rxqlength: the desired reception queue length. 1132 numrtx: number of allowed retransmissions. 1134 age: discard packet according to its age on the queue. 0 if no 1135 discards are allowed. 1137 rtxbackoff: retransmission backoff in number of slotframes. 0 if 1138 next available slot wants to be used. 1140 statswindow: window of time used to compute stats. 1142 queue priority: the desired priority of this queue. 1144 TrackIDs: the desired set of TrackIDs. 1146 2.4.8.5. DELETE.queue 1148 Deletes a TSCH Queue. The command requires the queue id. All 1149 packets in the queue are discarded and the queue is deleted. 1151 2.4.8.6. Queueing Command Behavior 1153 The following table describes the behavior of 6top upon reception of 1154 the Queue management commands. 1156 Queue Management Operations behavior 1157 +---------------------------------+---------------------------------+ 1158 | 6top commands | 6top behavior | 1159 +---------------------------------+---------------------------------+ 1160 | Create.queue(tqlen,trlen,numrtx,| Creates a queue with specified | 1161 | age,rtxbackoff,prio,TrackIDs) | parameters. Updates 6top MIB. | 1162 +---------------------------------+---------------------------------+ 1163 | Read.queue(id) | Reads the queue configuration | 1164 | | from 6top MIB. | 1165 +---------------------------------+---------------------------------+ 1166 | Update.queue(id,tqlen,trlen, | Updates the queue configuration | 1167 | numrtx,age,rtxbackoff, | from 6top MIB. Readjustes actual| 1168 | prio, TrackIDs) | queue size if required. | 1169 +---------------------------------+---------------------------------+ 1170 | Delete.queue(id) | Deletes the queue from MIB. | 1171 | | | 1172 +---------------------------------+---------------------------------+ 1173 | Read.queue.stats() | Reads the queue | 1174 | | stats from 6top MIB. | 1175 +---------------------------------+---------------------------------+ 1177 2.4.9. Security Commands 1179 The following commands are used to manage underlying layer security. 1180 In that case 6top acts as delegating interface to IEEE802.15.4 1181 security configuration commands. 1183 2.4.9.1. CONFIGURE.security 1185 Enables/Disables Security and configures the MAC PIB. The command 1186 requires: 1188 enable: enables underlying layer security. 1190 macAutoRequestSecurityLevel: the security level used for automatic 1191 data requests as described by IEEE 802.15.4 table 61. 1193 macAutoRequestKeyIdMode: the key identifier mode used for 1194 automatic data requests as described by IEEE 802.15.4 table 61. 1196 macAutoRequestKeySource: the originator of the key for automatic 1197 data requests as described by IEEE 802.15.4 table 61. 1199 macAutoRequestKeyIndex: the index of the key used for automatic 1200 data requests as described by IEEE 802.15.4 table 61. 1202 macDefaultKeySource: the originator of the default key used for 1203 key identifier mode 0x01 as described by IEEE 802.15.4 table 61. 1205 macPANCordinatorExtendedAddress: Address of the PAN coordinator as 1206 described by IEEE 802.15.4 table 61. 1208 macPANCordinatorShortAddress: Short address of the PAN coordinator 1209 as described by IEEE 802.15.4 table 61. 1211 2.4.9.2. CONFIGURE.security.macKeyTable 1213 Configures Security Keys. The command requires: 1215 KeyIdLookupList: list of keyIdLookupDescriptor Entries as defined 1216 by IEEE 802.15.4 table 61. 1218 DeviceDescriptorHandleList: Implementation specific list of 1219 devices that are using this key. As defined by IEEE 802.15.4 1220 table 61. 1222 KeyUsageList: List of slotframe types on which this key is being 1223 used as specified by IEEE 802.15.4 section 7.4.1.2 1225 Key: 16 octets key. As specified by IEEE 802.15.4 table 61. 1227 2.4.9.3. CONFIGURE.security.macSecurityLevelTable 1229 Configures the set of security levels. The command requires: 1231 FrameType: Slotframe type as defined by IEEE802.15.4e std. 1233 Command Identifier: The command identifier as defined by 1234 IEEE802.15.4e std. 1236 Security Minimum: The minimum required security level as specified 1237 by IEEE 802.15.4e 1239 Device Override Security Minimum: whether the minimum security 1240 level can be overridden as specified by IEEE 802.15.4 Table 64 1242 Allowed Security Levels: the key identifier field that identifies 1243 the key that is being used as specified by IEEE 802.15.4 section 1244 7.4.3 1246 2.4.9.4. Security Command Behavior 1248 6top offers the interface to upper layers so underlying MAC layer can 1249 be configured. In that sense, 6top acts as a "none-layer" by only 1250 delegating the functionalities to the MAC security services. For 1251 more details Section 7 on IEEE802.15.4-2011 and its amendments on 1252 IEEE802.15.4e-2012 should be referred. 1254 2.4.10. Data Commands 1256 2.4.10.1. Send.data 1258 The command used by upper layers to queue a packet so underlying TSCH 1259 sends it. According to the specific priority, the packet is pushed 1260 into a Queue with the equivalent priority or following a criteria out 1261 of the scope of this document. Once a packet is inserted into a 1262 queue it waits to be transmitted by TSCH according to the model 1263 defined in Section 2.3. 1265 The required parameters are: 1267 src address: L2 source address 1269 dest address: L2 unicast or broadcast destination address 1271 priority: packet priority, usually is consistent with queue 1272 priority 1274 message length: the length of the message. 1276 message: control message or data message 1278 securityLevel:As defined by IEEE802.15.4e std. 1280 2.4.10.2. Receive.data 1282 The command is invoked whenever a packet is received and inserted 1283 into a reception queue. The method acts as a callback function to 1284 notify to the upper layers the received message. Upper layers MUST 1285 provide an implementation for that method. 1287 The function has the following parameters: 1289 src address: L2 source address 1291 dest address: L2 unicast or broadcast destination address 1293 priority: packet priority, usually is consistent with queue 1294 priority 1296 message length: the length of the message. 1298 message: control message or data message 1300 2.4.10.3. Data Command Behavior 1301 The following table describes the behavior of 6top upon reception of 1302 the Data Communication Configuration management commands. 1304 Data Communication Management Operations behavior 1306 +---------------------------------+---------------------------------+ 1307 | 6top commands | 6top behavior | 1308 +---------------------------------+---------------------------------+ 1309 | Send.data(src,dest,prio, | The message is inserted in the | 1310 | len,msg,seclevel) | the queue corresponding to the | 1311 | | required priority. Fails if the | 1312 | | queue is full. Fails if the | 1313 | | destination address is not a | 1314 | | L2 neighbor of the node. | 1315 +---------------------------------+---------------------------------+ 1316 | Receive.data(src,dest,prio,len, | The method is invoked whenever a| 1317 | msg) | message is inserted in the queue| 1318 | | after successful reception. | 1319 +---------------------------------+---------------------------------+ 1321 Figure 4 1323 2.4.11. Label Switching Commands 1325 2.4.11.1. LabelSwitching.map 1327 The command used by upper layers to map one input cell or a bundle of 1328 input cells to an output cell or a bundle of output cells. 6top 1329 stores this mapping and makes sure that the packets are forwarded at 1330 the specific output cell/bundle. Label Switching is enabled by the 1331 specified bundle as soon as the mapping is installed. 1333 The required parameters are: 1335 input cells: list of input cells (one or more cells in a bundle). 1336 Each input cells is described by an unique tuple (time slot, 1337 frequency offset, destination address). 1339 output cells: list of output cells (one or more cells in a 1340 bundle). Each output cells is described by an unique tuple (time 1341 slot, frequency offset, destination address). 1343 load balancing policy: A policy for load balance cell usage. The 1344 policy is out of the scope of this document, however an example 1345 can be use ROUND ROBIN policy within the cells of the same bundle. 1347 2.4.11.2. LabelSwitching.unmap 1348 The command used by upper layers to unmap one input cell or a bundle 1349 of input cells to an output cell or a bundle of output cells. The 1350 mapping is removed from the state kept by 6top. 1352 The required parameters are: 1354 input cells: list of input cells (one or more cells in a bundle). 1355 Each input cells is described by an unique tuple (time slot, 1356 frequency offset, destination address). 1358 output cells: list of output cells (one or more cells in a 1359 bundle). Each output cells is described by an unique tuple (time 1360 slot, frequency offset, destination address). 1362 2.4.11.3. Label Switching Command Behavior 1364 The following table describes the behavior of 6top sublayer upon 1365 reception of the Label Switching Commands. 1367 Data Communication Management Operations behavior 1369 +---------------------------------+---------------------------------+ 1370 | 6top commands | 6top behavior | 1371 +---------------------------------+---------------------------------+ 1372 | LabelSwitching.map(src,dest, | The 6top sublayer label mapping | 1373 | policy) | table is configured with the | 1374 | | input and output cells bindings.| 1375 | | According to the policy a | 1376 | | monitoring mechanism is started | 1377 | | so load balancing can be | 1378 | | enforced. | 1379 +---------------------------------+---------------------------------+ 1380 | LabelSwitching.unmap(src,dest) | The src and dst cells are | 1381 | | removed from the mapping table | 1382 | | and any load balancing policy | 1383 | | is disabled. | 1384 +---------------------------------+---------------------------------+ 1386 Figure 5 1388 2.5. Message Formats 1390 6top has to negotiate the scheduling of soft cells with neighbor 1391 nodes. This negotiation happens through 6top-specific TSCH 1392 Information Elements, the format of which is defined in this section. 1393 This section also details the formats of the IEs defined in 1394 [IEEE802154e] and reused without modification. 1396 6top messages can contain one or more IEs. Section 2.5.1 defines the 1397 different IEs used by 6top, both the ones used without modification 1398 from [IEEE802154e], and the new ones defined by 6top. Section 2.5.2 1399 shows how those IEs are assembled to form the different packets used 1400 by 6top. 1402 2.5.1. Information Elements 1404 IEEE802.15.4e defines Information elements (IEs) which are formatted 1405 data objects consisting of an ID, a length, and a data payload used 1406 to pass data between layers or devices. IEEE802.15.4e defines Header 1407 IEs and Payload IEs; 6top only uses Payload IEs. A Payload IE 1408 includes one or more IEs, and ends with a termination IE (ID = 0xf, 1409 see [IEEE802154e]). 1411 6top uses the following Information Elements, some defined in 1412 IEEE802.15.4e, others introduced in this document. 1414 Defined in [IEEE802154e] and used by 6top without modification: 1416 TSCH Synchronization IE (Section 2.5.1.1) 1418 TSCH Slotframe and Cell IE (Section 2.5.1.2) 1420 TSCH Timeslot Template IE (Section 2.5.1.3) 1422 TSCH Channel Hopping IE (Section 2.5.1.4) 1424 Defined by 6top: 1426 6top Opcode IE (Section 2.5.1.5) 1428 6top Bandwidth IE (Section 2.5.1.6) 1430 6top TrackID IE (Section 2.5.1.7) 1432 6top Generic Schedule IE (Section 2.5.1.8) 1434 2.5.1.1. TSCH Synchronization IE 1436 A Synchronization IE (SyncIE) contains Information allowing a node to 1437 synchronize to a TSCH network, including the current ASN and a join 1438 priority. Synchronization IE must be included in all TSCH Enhanced 1439 Beacons. 1441 6top re-uses this IE as defined in [IEEE802154e]. 1443 Format of a TSCH Synchronization IE (SyncIE). 1445 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 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Length | SubID |T| ASN | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | ASN | Join Priority | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 Figure 6 1454 Length=6 1456 SubID=0x1a 1458 T=0, i.e. short type 1460 ASN (5 octets) contains the Absolute Slot Number corresponding to the 1461 timeslot in which the TSCH Enhanced Beacon is sent. 1463 The Join Priority can be used by a joining device to select among 1464 beaconing devices when multiple beacons are heard. The PAN 1465 coordinator's join priority is zero. A lower value of join priority 1466 indicates that the device is the preferred one to connect to. The 1467 beaconing device's join priority is the lowest join priority heard 1468 when it joined the network plus one. 1470 2.5.1.2. TSCH Slotframe and Cell IE 1472 The Slotframe and Cell IE (FrameAndCellIE) contains one or more 1473 slotframes and their respective cells that a beaconing device 1474 advertises to allow other devices to join the network. 1476 6top re-uses this IE as defined in [IEEE802154e]. 1478 Format of a TSCH Slotframe and Cell IE (FrameAndCellIE). 1480 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 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Length | SubID |T| NumFrame | | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1484 | | 1485 // Slotframe and cell information // 1486 | | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 Figure 7 1491 Length=variable 1493 SubID=0x1b 1495 T=0, i.e. short type 1497 NumFrame is set to the total number of slotframe descriptors 1498 contained in the TSCH Enhanced Beacon. 1500 Format of a slotframe descriptor. 1502 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 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | FrameID | FrameLen | NumCell | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | | 1507 // Cell information for each cell (5x NumCell) // 1508 | | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 Figure 8 1513 The FrameID field shall be set to the slotframeHandle that uniquely 1514 identifies the slotframe. 1516 The FrameLen field shall be set to the size of the slotframe in 1517 number of timeslots. 1519 The NumCell field shall be set to the number of cells that belong to 1520 the specific slotframe identified by the slotframeHandle. 1522 Format of a Cell information. 1524 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 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | SlotOffset | ChannelOffset | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | LinkOption | 1529 +-+-+-+-+-+-+-+-+ 1531 Figure 9 1533 SlotOffset shall be set to the timeslot of this cell. 1535 ChannelOffset shall be set to the logic channel of this cell. 1537 LinkOption indicates whether this cell is a TX cell, an RX cell, or a 1538 SHARED TX cell, whether the device to which it is being linked is to 1539 be used for clock synchronization, and whether this cell is hard 1540 cell. 1542 2.5.1.3. TSCH Timeslot Template IE 1544 Timeslot Template IE (SlotTemplateIE) defines Timeslot template being 1545 used by the TSCH device. 1547 6top re-uses this IE as defined in [IEEE802154e]. 1549 Format of a TSCH Timeslot Template IE (SlotTemplateIE). 1551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Length | SubID |T| TemplateID | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 Figure 10 1558 Length=1 1560 SubID=0x1c 1562 T=0, i.e. short type 1564 TemplateID shall be set to a Timeslot template handle. The full 1565 time-slot template, which contains the macTimeslotTemplate of TSCH 1566 (total 25 octets), may be included.(see IEEE802.15.4e). 1568 2.5.1.4. TSCH Channel Hopping IE 1570 Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being 1571 used by the TSCH device. 1573 6top re-uses this IE as defined in [IEEE802154e]. 1575 Format of a TSCH Channel Hopping IE (ChHoppingIE). 1577 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | Length | SubID |T| HopSequenceID | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 Figure 11 1584 Length=1 1586 SubID=0x09 1588 T=1, i.e. long type 1590 HopSequenceID shall be set to a Hopping Sequence handle. The full 1591 Hopping Sequence information may be included. (see IEEE802.15.4e). 1593 2.5.1.5. 6top Opcode IE 1595 6top Opcode IE (OpcodeIE) defines operation codes of packets in 6top 1596 sublayer. 1598 This IE is not present in [IEEE802154e] and is defined by 6top. 1600 Format of a 6top Opcode IE (OpcodeIE). 1602 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Length | SubID |T| OpcodeID | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 Figure 12 1609 Length=1 1611 SubID=0x41 1613 T=0, i.e. short type 1615 OpcodeID field shall be set to one of the following codes. 1617 0x00: Reserve Soft Cell Request 1619 0x01: Reserve Soft Cell Response 1620 0x02: Remove Soft Cell Request 1622 0x03: Reserve Hard Cell Request 1624 0x04: Remove Hard Cell Request 1626 2.5.1.6. 6top Bandwidth IE 1628 Bandwidth IE (BwIE) defines the number of cells to be reserved or 1629 actually be reserved. 1631 This IE is not present in [IEEE802154e] and is defined by 6top. 1633 Format of a 6top Bandwidth IE (BwIE). 1635 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 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Length | SubID |T| FrameID | NumCell | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 Figure 13 1642 Length=2 1644 SubID=0x42 1646 T=0, i.e. short type 1648 FrameID may be set to the SlotFrameHandle to identify the slotframe 1649 from which cells are reserved. FrameID field may be set to NOP, 1650 which means no specific slotframe is associated. 1652 NumCell shall be set to the number of cells. When BwIE is combined 1653 with the OpecodeID of Reserve Soft Cell Request, NumCell presents how 1654 many cells are required to reserve; and when BwIE is combined with 1655 the OpecodeID of Reserve Soft Cell Response, NumCell presents how 1656 many cells are reserved successfully. 1658 2.5.1.7. 6top TrackID IE 1660 TrackID IE (TrackIdIE) describes the track which the reserved/removed 1661 cell(s) are associated with. 1663 This IE is not present in [IEEE802154e] and is defined by 6top. 1665 Format of a 6top TrackID IE (TrackIdIE). 1667 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 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | Length | SubID |T|OwnerInstID|rev| | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1671 // // 1672 | TrackOwnerAddr | 1673 | | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 Figure 14 1678 Length=3 or 7. When length=3, TrackOwnerAddr is 2 bytes short 1679 address, and when length=7, TrackOwnerAddr is 6 bytes long address. 1681 SubID=0x43 1683 T=0, i.e. short type 1685 The combination of TrackOwnerAddr and OwnerInstId represents a 1686 specific TrackID. 1688 2.5.1.8. 6top Generic Schedule IE 1690 Generic Schedule IE (ScheduleIE) describes cell sets. In different 1691 packets, ScheduleIE represents different information. See 1692 Section 2.5.2 for more detail. 1694 This IE is not present in [IEEE802154e] and is defined by 6top. 1696 Format of a 6top Generic Schedule IE (ScheduleIE). 1698 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Length | SubID |T| | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1702 | | 1703 // Schedule Body // 1704 | | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 Figure 15 1709 Length=variable 1711 SubID=0x44 1713 T=0, i.e. short type 1714 Schedule Body carries one or more schedule object. An object may 1715 carry a TLV, which may itself comprise other TLVs. TLV format is as 1716 follows. Type: 1 byte, Length: 1 byte, Value: variable 1718 The following are some examples of schedule object TLV. 1720 Example 1. Cell Set TLV 1722 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 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Type=1 | Length | FrameID | NumCell |F| 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | | 1727 // CellObjects // 1728 | | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 Figure 16 1733 FrameID shall be set to the slotframeHandle that uniquely identifies 1734 the slotframe. 1736 NumCell shall be set to the number of cells that belong to the 1737 specific slotframe identified by the slotframeHandle. 1739 F=1 means the specified cells equals to what are listed in 1740 CellObjects, and F=0 means the specified cells equals to what are not 1741 listed in CellObjects. 1743 CellObjects carries the information for one or more cells, including 1744 SlotOffset, ChannelOffset, LinkOption (Figure 9). 1746 Example 2. Schedule Matrix TLV 1748 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 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Type=2 | Length | FrameID |StartSlotOffset| 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 |StartSLotOffset| NumSlot | | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1754 | | 1755 // SlotBitMap (2x NumSlot) // 1756 | | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 Figure 17 1761 FrameID field shall be set to the slotframeHandle that uniquely 1762 identifies the slotframe. 1764 StartSlotOffset field (2 octets) shall be set to the slotoffset in 1765 the specific slotframe identified by the slotframeHandle. 1767 NumSlot field shall be set to the number of slots from 1768 StartSlotOffset in the specific slotframe identified by the 1769 slotframeHandle. 1771 SlotBitMap (per slot) indicates for the given slot which channels are 1772 specified. For the 16 channels in 2.4GHz band, 2-octets are used to 1773 indicate which channel is specified. For example, given a slot and a 1774 SlotBitmap with value (10001000,00010000); the bitmap represents that 1775 ChannelOffset-0, ChannelOffset-4, ChannelOffset-11 are specified. 1777 2.5.2. Packet Formats 1779 This section describes the packets used in 6top to form a network, 1780 reserve/maintain bandwidth using soft cells, and reserve/remove hard 1781 cells in both Tx side and Rx side. Each of these packets use one or 1782 more IEs defined in Section 2.5.1. 1784 2.5.2.1. TSCH Enhanced Beacon 1786 The TSCH Enhanced Beacon is used to announce the presence of the 1787 network and allows new nodes to join. It is an IEEE802.15.4e 1788 Enhanced Beacon packet with the following Payload IEs: 1790 TSCH Synchronization IE (Section 2.5.1.1) 1792 TSCH Timeslot Template IE (Section 2.5.1.3) 1794 TSCH Channel Hopping IE (Section 2.5.1.4) 1796 TSCH Slotframe and Cell IE (Section 2.5.1.2) 1798 Payload IE of TSCH Enhanced Beacon Packet 1799 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 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | Length |GroupID|T| SyncIE | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | SyncIE | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | SyncIE | SlotTemplateIE | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 |SlotTemplateIE | ChHoppingIE | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | | 1810 // FrameAndCellIE // 1811 | | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 Figure 18 1816 Length=variable 1818 GroupID=0x1, i.e. MLME IE 1820 T=1, i.e. payload IE 1822 See Section 2.5.1.1, Section 2.5.1.3, Section 2.5.1.4,Section 2.5.1.2 1823 for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndCellIE. 1825 2.5.2.2. Soft Cell Reservation Request 1827 A Soft Cell Reservation Request packet is an IEEE802.15.4e data 1828 packet with the following payload IE. 1830 Payload IE of Soft Cell Reservation Request 1832 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 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | Length |GroupID|T| OpcodeIE | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | OpcodeIE | BwIE | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | BwIE | | 1839 +-+-+-+-+-+-+-+-+ | 1840 // ScheduleIE // 1841 | | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 Figure 19 1846 Length=variable 1847 GroupID=0x1, i.e. MLME IE 1849 T=1, i.e. payload IE 1851 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x00, 1852 indicates Reserve Soft Cell Request operation. 1854 The NumCell field in 4-octet BwIE should be set to the number of 1855 cells needed to be reserved. 1857 The ScheduleIE specifies a candidate cell set, from which the cells 1858 should be reserved. ScheduleIE may be empty, means there is no 1859 constrain on which cells should not be reserved. 1861 In addition, TrackIdIE can be added in the packet to associate the 1862 reserved soft cells to a specific TrackID. 1864 2.5.2.3. Soft Cell Reservation Response 1866 Soft Cell Reservation Response is an IEEE802.15.4e data packet with 1867 the following payload IE. 1869 Payload IE of Soft Cell Reservation Response 1871 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 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | Length |GroupID|T| OpcodeIE | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | OpcodeIE | BwIE | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | BwIE | | 1878 +-+-+-+-+-+-+-+-+ | 1879 // ScheduleIE // 1880 | | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 Figure 20 1885 Length=variable 1887 GroupID=0x1, i.e. MLME IE 1889 T=1, i.e. payload IE 1891 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x01, 1892 indicates Reserve Soft Cell Response operation. 1894 The NumCell field in 4-octet BwIE should be set to the number of 1895 cells which have been reserved successfully. 1897 The ScheduleIE should specify all of the cells which have been 1898 reserved successfully. 1900 In addition, TrackIdIE can be added in the packet to associate the 1901 reserved soft cells to a specific TrackID. 1903 2.5.2.4. Soft Cell Remove Request 1905 Soft Cell Remove Request is an IEEE802.15.4e data packet with the 1906 following payload IE. 1908 Payload IE of Soft Cell Remove Request 1910 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 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Length |GroupID|T| OpcodeIE | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 | OpcodeIE | | 1915 +-+-+-+-+-+-+-+-+ | 1916 // ScheduleIE // 1917 | | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 Figure 21 1922 Length=variable 1924 GroupID=0x1, i.e. MLME IE 1926 T=1, i.e. payload IE 1928 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x02, 1929 indicates Remove Soft Cell Request operation. 1931 The ScheduleIE should specify all the cells that need to be removed. 1933 2.5.2.5. Hard Cell Reservation Request 1935 Hard Cell Reservation Request packet is an IEEE802.15.4e data packet 1936 with the following payload IE. 1938 Payload IE of Hard Cell Reservation Request 1939 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 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | Length |GroupID|T| OpcodeIE | 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 | OpcodeIE | | 1944 +-+-+-+-+-+-+-+-+ | 1945 // ScheduleIE // 1946 | | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 Figure 22 1951 Length=variable 1953 GroupID=0x1, i.e. MLME IE 1955 T=1, i.e. payload IE 1957 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x03, 1958 indicates Reserve Hard Cell Request operation. 1960 The ScheduleIE should specify all the cell that need to be reserved. 1962 In addition, TrackIdIE can be added in the packet to associate the 1963 reserved hard cells to a specific TrackID. 1965 2.5.2.6. Hard Cell Remove Request 1967 Hard Cell Remove Request is an IEEE802.15.4e data packet with the 1968 following payload IE. 1970 Payload IE of Hard Cell Remove Request 1972 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 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | Length |GroupID|T| OpcodeIE | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | OpcodeIE | | 1977 +-+-+-+-+-+-+-+-+ | 1978 // ScheduleIE // 1979 | | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 Figure 23 1984 Length=variable 1986 GroupID=0x1, i.e. MLME IE 1987 T=1, i.e. payload IE 1989 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x04, 1990 indicates Remove Hard Cell Request operation. 1992 The ScheduleIE should specify all the cells that need to be removed. 1994 2.6. Time Sequence 1996 6top neighbors exchange 6top-specific packets in the following cases, 1997 each detailed in a subsection. 1999 Network formation is detailed in Section 2.6.1. 2001 Creating soft cells is detailed in Section 2.6.2. 2003 Deleting soft cells is detailed in Section 2.6.3. 2005 Maintaining soft cells is detailed in Section 2.6.4. 2007 Creating hard cells is detailed in Section 2.6.5. 2009 Deleting hard cells is detailed in Section 2.6.6. 2011 2.6.1. Network Formation 2013 Network formation consists of two processes: joining and maintenance. 2015 2.6.1.1. Joining 2017 A node already in the network sends out TSCH Enhanced Beacons 2018 periodically. 2020 When a node is joining an existing network, it listens for TSCH 2021 Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs 2022 (the format of which is detailed in Section 2.5.2.1), the joining 2023 node must do the following. 2025 Initialize a neighbor table. Establish a neighbor table and 2026 record all of the information described in the TSCH Enhanced 2027 BEACONs as its initial schedule with those neighbors. 2029 Select a time source neighbor. According to the Joining Priority 2030 described by SyncIEs, the joining node chooses one or more of the 2031 advertisers as its time source neighbors. 6top does not specify 2032 the criteria to choose time source neighbors from the Enhanced 2033 BEACONs. 2035 Select cells for Enhanced Beacons. The joining node selects one 2036 or more cells to broadcast its own Enhanced Beacons, which may be 2037 same as the cells used by its neighbors for Enhanced Beacon 2038 broadcast, and record those cell(s) into the TSCH schedule with 2039 LinkType=ADVERTISING. 2041 From its Enhanced Beacons, including the cell(s) for its Enhanced 2042 Beacon, which LinkOption should be set to "Receive" and 2043 "Timekeeping", telling its neighbors that the cell is used for 2044 broadcast. 2046 Start broadcasting Enhanced Beacon and communicate with neighbors. 2048 2.6.1.2. Maintenance 2050 Nodes may broadcast Enhance Beacons on the cells marked with 2051 LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors 2052 on the cells with LinkOption = "Receive" and "Timekeeping". If a 2053 cell with both LinkType=ADVERTISING has both the "Receive" and 2054 "Timekeeping" LinkOption, it is shared by neighbors and itself to 2055 broadcast, then broadcast Enhanced Beacon has higher priority. 2057 Whenever a node receives an Enhanced Beacon, it must update its 2058 schedule if there is a difference. 2060 2.6.2. Creating soft cells 2062 The upper layer instructs 6top to schedule one or more soft cells by 2063 calling the Create soft cell command. This command can also be 2064 called by the monitoring process internal to 6top. 2066 When receiving a Create soft cell command, Node A's 6top sublayer 2067 forms a Soft Cell Reservation Request packet which includes BwIE and 2068 ScheduleIE. The BwIE includes the number of cells needed to be 2069 reserved (N1), and ScheduleIE includes a candidate cell set from 2070 which the new cells should be selected. If the ScheduleIE is empty, 2071 Node A indicates there is no constraint on cell selection. The Soft 2072 Cell Reservation Request is then sent to the neighbor (Node B) with 2073 whom new cells need to be added. After receiving the Soft Cell 2074 Reservation Request, Node B selects the cells from the candidate cell 2075 set defined by the ScheludeIE in the Soft Cell Reservation Request, 2076 and forms a Soft Cell Reservation Response packet, in which BwIE 2077 indicates the number of cells actually being reserved (N2), and 2078 ScheduleIE indicates those reserved cells. If N2 is smaller than N1, 2079 node B indicates to node A that there are not enough qualified cells 2080 to be reserved. Node B must record the reserved cells into its local 2081 schedule while sending out Soft Cell Reservation Response. After 2082 receiving the Soft Cell Reservation Response, Node A must record the 2083 reserved cells into its local schedule. 2085 The policy to build a candidate cell set and the policy to select 2086 cells from the candidate cell set to reserve is flexiable. For 2087 example, the candidate cell set can be all of the cells not used by 2088 Node A, and Node B can randomly choose N1 cells, which are not used 2089 by Node B, from the candidate cell set. 2091 The expression of Schedule Body is flexible. For example, Node A can 2092 use Cell Set TLV defined in Figure 16 with field 'F' set to '0', and 2093 the CellObjects includes all of the cells being used by Node A. In 2094 another word, the cell candidate set is all of the cells not being 2095 included in the list defined by CellObjects. 2097 The policy to deal with the failure or not fully satisfaction in a 2098 soft cell Reservation process is flexible. For example, Node A may 2099 initiate another soft cell reservation procedure, or simply report to 2100 upper layer. 2102 2.6.3. Deleting soft cells 2104 The upper layer instructs 6top to delete one or more soft cells by 2105 calling the Delete soft cell command. This command can also be 2106 called by the monitoring process internal to 6top. 2108 When receiving a Delete soft cell command, Node A's 6top sublayer 2109 selects cells to be removed from its local schedule, and creates a 2110 Soft Cell Remove Request, including a ScheduleIE. The ScheduleIE 2111 indicates which specific cells to remove with a neighbor (Node B). 2112 The cells specified in the ScheduleIE should be removed from local 2113 schedule of Node A while the Soft Cell Remove Request is sent to Node 2114 B. When receiving the Soft Cell Remove Request, the cells specified 2115 in the ScheduleIE should be removed from the local schedule of Node 2116 B. 2118 The policy to select cells corresponding to a Delete soft cell 2119 command is out of scope. 2121 2.6.4. Maintaining soft cells 2123 The monitoring process internal to 6top (Section 2.8) is responsible 2124 for monitoring and re-scheduling soft cells to meet some QoS 2125 requirements. The monitoring process may issue a soft cell 2126 Maintenance command, which indicate a set of cells to be moved in the 2127 TSCH schedule. 2129 When a receiving a soft cell Maintenance command, 6top initializes a 2130 Soft Cell Remove Request (Section 2.6.3) with the neighbor in 2131 question, followed by a Soft Cell Reservation Request 2132 (Section 2.6.2). 2134 2.6.5. Creating hard cells 2136 The upper layer instructs 6top to create one or more hard cells by 2137 calling the Create hard cell command. 2139 When receiving a Create hard cell command, Node A's 6top sublayer 2140 creates a Hard Cell Reservation Request, including a ScheduleIE. The 2141 ScheduleIE indicates which specific cells with a neighbor (Node B) to 2142 be added. The cells specified in the ScheduleIE should be added in 2143 local schedule of Node A while the Hard Cell Reserve Request is sent 2144 to Node B. When receiving the Hard Cell Reserve Request, the cells 2145 specified in the ScheduleIE should be added in the local schedule of 2146 Node B. 2148 2.6.6. Deleting hard cells 2150 The upper layer instructs 6top to delete one or more hard cells by 2151 calling the Delete hard cell command. 2153 When receiving a Delete hard cell command, Node A's 6top sublayer 2154 creates a Hard Cell Remove Request, including a ScheduleIE. The 2155 ScheduleIE indicates which specific cells with a neighbor (Node B) to 2156 be removed. The cells specified in the ScheduleIE should be removed 2157 from local schedule of Node A while the Hard Cell Remove Request is 2158 sent to Node B. When receiving the Hard Cell Remove Request, the 2159 cells specified in the ScheduleIE should be removed from the local 2160 schedule of Node B. 2162 2.7. Statistics 2164 The 6top Statistics Fuction (SF) is responsible for collecting 2165 statistics, which it can provide to an upper layer and the Monitoring 2166 Function (Section 2.8). 2168 2.7.1. Statistics Metrics 2170 6top is in charge of keeping statistics from a set of metrics 2171 gathered from the behavior of the TSCH layer. 2173 The statistics data related to node states and cell metrics should be 2174 provided to upper layer for management, e.g. for RPL to calculate 2175 Rank or to GMPLS to determine whether the link in a multi-hop path is 2176 meeting the required bandwidth. The specific algorithm to generate 2177 the statistics is implementation dependent and hence out of the scope 2178 of this document. However, the statistics component should include 2179 the following metrics: 2181 1. LinkThroughput: associated with a link, Node A->Node B. For 2182 example, LinkThroughput can be calculated with: 2183 SUM(NumOfCell(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration) 2184 where NumOfCell(i) is the total number of cells from Node A to 2185 Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i. 2187 2. Latency: associated with a link, Node A->Node B. For example, 2188 latency can be expressed as Minimum and Maximum Latency. Minimum 2189 Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum 2190 Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where, 2191 MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum 2192 number of slots between two dedicated cells from Node A to Node B 2193 in Slotframe-i, respectively. 2195 3. LinkQuality. For example, average LQI, ETX; 2197 4. TafficLoad. For example, Queue Full Rate, Queue Empty Rate; 2199 5. NodeEnergy. For example, E_E=E_bat / [E_0 (T-t)/T]. 2201 2.7.2. Statistics Configuration 2203 Statistics Function should be configurable. The configuration 2204 parameters should include: 2206 LinkQualityStatisticsEn. 2208 TafficLoadStatisticsEn. 2210 DeviceStatisticsEn. 2212 6top statistics function is enabled/disabled and configured by the 2213 commands defined in Section 2.4.4 2215 2.8. Monitoring 2217 The 6top Monitoring Fuction (MF) is responsible for monitoring cell 2218 quality, traffic load, and issuing soft cell Maintenance command, or 2219 Create/Delete soft cell command. The data provided by Statistics 2220 Function may be used as a input of MF in making monitoring decision. 2222 2.8.1. Monitor Configuration 2224 Monitoring Function should be configurable. The configuration 2225 parameters should include: 2227 MaintainCellEn. 2229 CreateDeleteCellEn. 2231 QosLevel. QosLevel should associate with specific neighbor 2232 address. QosLevel may reflect the latency constraint, cell 2233 quality constraint, and so on. The value of QosLevel works as the 2234 bandwidth redundancy coefficient. 2236 6top monitoring function is enabled/disabled and configured by the 2237 commands defined in Section 2.4.3 2239 2.8.2. Actuation 2241 The cell quality statistics may be used to generate soft cell 2242 Maintenance command, which leads to a soft cell Maintenance procedure 2243 (see Section 2.6.4). The traffic load statistics may be used to 2244 generate internal Create/Delete soft cell commands, which leads to a 2245 soft cell Reservation process or a soft cell Remove process, 2246 respectively. (see Section 2.6.2 and Section 2.6.3) 2248 The policy to generate the soft cell Maintenance command and the 2249 policy to generate Create/Delete soft cell commands is out of the 2250 scope. 2252 The policy to generate Create/Delete soft cell commands may take 2253 QosLevel into account. For example, there are two slotframes 2254 existing, Slotframe-1 consists of 32 slots, Slotframe-2 consists of 2255 96 slots; Slot duration is 10ms; QosLevel=1.5. If, from the traffic 2256 load statistics, MF figures out 2 packet/second should be added, then 2257 it leads to a Create soft cell command, where FrameID=2, NumCell=3. 2259 2.9. Label Switching 2261 Label Switching Fuction (LS) in 6top is responsible for maintaining 2262 the mapping of input cells and output cells in the same track in a 2263 particular node. By keeping that mapping, layer 3 routing can be 2264 avoided as packets are forwarded by the 6top sublayer according to 2265 the input cells they were received on. The selected output cell is 2266 one of the cells that forward the packet to the subsequent hop in the 2267 track. As cells can be grouped in bundles, 6top can maintain 2268 mappings from input bundles to output bundles and provide a policy to 2269 select the output cell according to the input cell. 2271 3. Using 6top 2273 This part describes how 6top gives support to specific upper layers. 2275 3.1. RPL on 6top 2277 6top provides a set of functionalities so higher layers can obtain 2278 information about the status of the network and take advantage of the 2279 slotted structure to improve metric calculation and objective 2280 function optimization. The following sections describe how RPL can 2281 make use of 6top sublayer. 2283 In order to optimize the combination of RPL and TSCH, 6top provides 2284 specific support to RPL in the following aspects: 2286 RPL Neighbor Discovery and Parent Selection 2288 RPL Rank Computation 2290 RPL Control Messages Broadcast 2292 QoS 2294 3.1.1. Support to Neighbor Discovery and Parent Selection 2296 The Section 2.4.7 defines a set of commands so the neighbor table can 2297 be managed and queried by RPL. An entry to the neighbor table is 2298 inserted whenever an EBs is received at L2. The EB causes the 6top 2299 sublayer to create an entry to the neighbors table. A neighbor table 2300 entry contains a set of statistics with respect to that specific 2301 neighbor such as the ASN when the last packet has been received from 2302 that neighbor, a set of cell quality metrics (RSSI, LQI), number of 2303 packets sent to it or number of packets received from it amongst 2304 others. 6top updates that table upon sending or reception of a packet 2305 from/to a neighbor. RPL can query at any time the neighbor table to 2306 retrieve information about a particular neighbor. This information 2307 can be used to compute the routing objective function as for example 2308 the inverse of the Probability Delivery Ratio (PDR). Parent 2309 selection can also be driven by the information contained on the 2310 neighbor table as well as complemented with the cells statistics 2311 defined in Section 2.4.4 and Section 2.7. 2313 6top enables RPL to configure EB periodicity. By controlling the EBs 2314 periodicity, RPL can configure how network dynamism and support to 2315 mobility are addressed, as more frequent beacons the more prone to 2316 cope with mobility. Section 2.4.5 enables to configure how the 2317 network is formed and EBs periodicity. 2319 RPL may want to select the policy to determine the time source 2320 neighbor, this can be interesting when time source neighbors can be 2321 aligned to the routing topology, i.e., the selected time source 2322 neighbor can be the node's favorite parent in a specific DODAG. 2323 Section 2.4.6 describes the 6top command to set up the desired 2324 policy. The policy is selected by RPL and enforced by the 6top 2325 sublayer. 2327 The rule for 6top to select and maintain time source neighbors is as 2328 follows: 2330 The time source neighbor of a node should be a member of the 2331 node's neighbor set. 2333 Time source neighbors should be the neighbors which have a 2334 relatively lower join priority in the neighbor set. A lower join 2335 priority indicates that the neighbor is closer to the TSCH PAN 2336 coordinator. 2338 The link between a node and one of its time source neighbors 2339 should be a good link quality. 2341 3.1.2. Support of Rank Computation 2343 The RPL objective function is computed using a set of metrics. The 2344 specific metrics and how the objective function is calculated are out 2345 of the scope of the present document, however, 6top builds a set of 2346 functionalities to provide more accurate statistics of the underlying 2347 layer so the objective function can be accommodated to the nature of 2348 a TSCH MAC layer. 2350 6top provides statistics for rank computation as described in 2351 sections Section 2.4.4 and Section 2.7. The function used to compute 2352 the rank based on those statistics is out of scope of 6top, however 2353 the provided metrics are aligned to the behavior of the TSCH MAC 2354 layer. 2356 3.1.3. Support of Control Messages Broadcast 2358 In RPL, some control messages, e.g. DIO and DAO in storing mode, need 2359 to be broadcast to all neighbor nodes. The broadcast channel 2360 requirement has to be addressed by 6top by configuring TSCH to 2361 provide such a channel. 2363 In order to decouple the upper (RPL) layer from TSCH, instead of 2364 carrying DIO messages in Enhance Beacons, 6top introduces a mechanism 2365 to establish broadcast cells. 2367 In TSCH schedule, every cell has the LinkType attribute. If 2368 LinkType=ADVERTISING, indicates that the cell may be used to send an 2369 Enhanced Beacon. When a node forms its Enhanced Beacon, the cell, 2370 with LinkType=ADVERTISING, should be included in the FrameAndCellIE, 2371 and its LinkOption field should be set to the combination of 2372 "Receive" and "Timekeeping". The receiver of the Enhanced Beacon may 2373 listen to at the cell to get the Enhanced Beacon ([IEEE802154e]). 2374 6top takes this way to establish broadcast channel, which not only 2375 allows TSCH broadcast Enhanced Beacon, but also allows an upper layer 2376 like RPL broadcast. 2378 To support DIO and DAO broadcast, 6top uses the payload of a Data 2379 Packet to carry the DIO or DAO. The message is inserted into the 2380 queue associated with the cells which LinkType is set to ADVERTISING. 2381 Then, taking advantage of the broadcast cell feature established with 2382 FrameAndCellIE as described above, the data packet with DIO or DAO in 2383 payload can be received by neighbors, which leads to the maintenance 2384 of DODAG. 2386 The LinkOption of combining "Receive" and "Timekeeping" let the 2387 receivers of the Enhanced Beacon understand that the cell is used as 2388 broadcast cell. But the frequency of sending Enhance Beacon or other 2389 broadcast messages by upper layer is determined by the timers 2390 associated with the messages, e.g. Enhance Beacon is triggered by the 2391 timer in 6top, and the DIO message is triggered by the trickle timer 2392 of RPL. Therefore, for energy efficiency, receivers can have some 2393 policy to wake up at the broadcast cell, but it is implementation 2394 dependent. 2396 3.1.4. Support to QoS 2398 TSCH MAC layer is decoupled from the upper layers and its interaction 2399 with them is asynchronous. This means that the MAC layer executes a 2400 schedule and checks at each slot according to the type of cell 2401 whether there is something to send or receive. If that is the case 2402 the packet is sent and the MAC layer continues its operation. When 2403 an upper layer sends a packet, this packet is pushed into a queue 2404 waiting to the MAC layer to read it and sent it in a particular slot 2405 according to is destination and priority (Section 2.3). 6top provides 2406 a set of queue management operations which enable upper layers to 2407 create different queues and determine their priorities. In that 2408 sense different classes of traffic can be handled by the routing 2409 layer, i.e inserting a packet to a specific queue according to its 2410 priority. 2412 6top provides at least a Broadcast Queue, a Transmit Queue, and a 2413 Receive Queue. RPL can configure the queues with Internal Queueing 2414 Command (Section 2.4.8.1). Broadcast Queue are associated with cells 2415 with LinkType=ADVERTISING in sender's schedule, and 2416 LinkOption="Receive" and "Timekeeping" in all neighbors' schedule. 2417 That indicates the cells can be used for broadcast from the sender to 2418 its neighbors. Transmit Queues are associated with the dedicated 2419 Transmit cells or Shared Cells. RPL can benefit from having 2420 different priority queues in order to improve latency or provide 2421 integrated services with different priorities, i.e different traffic 2422 classes. 2424 Data Communication Command (Section 2.4.10) can be used to send 2425 control messages and data messages. The operation is used to insert 2426 a message to an specific queue. 2428 For example a suitable configuration can include two Broadcast Queues 2429 with priority High and Low, respectively; three Transmit Queues, with 2430 priority High, Mid, and Low, respectively; and one Receive Queue. 2432 When DestAddr is a broadcast address, its related MAC layer packets 2433 will be pushed into the Broadcast Queue with the corresponding 2434 priority. 6top is responsible for feeding these packets to TSCH at 2435 broadcast cells. 2437 When DestAddr is unicast address, its related MAC layer packets will 2438 be push into the Transmit Queue with corresponding priority. 6top is 2439 responsible for feeding these packets to TSCH at Transmit cells or 2440 Shared Cells. 2442 6top conducts a QoS policy, which is out of scope. Here is an 2443 example. Packets in higher priority queue MUST be sent out before 2444 the packets in lower priority queue. Then, when there is an 2445 available broadcast/unicast cell, 6top checks the broadcast/unicast 2446 queue with higher priority first, if there is a packet, then feed it 2447 to TSCH at the cell, otherwise checks broadcast/unicast queue with 2448 lower priority further. Repeat the process, until find a broadcast/ 2449 unicast packet to feed to TSCH or find all of broadcast/unicast 2450 queues are empty. 2452 3.2. GMPLS on 6top 2454 GMPLS is a 2.5 layer service that is used to forward packets based on 2455 the concept of generalized label. Labels are determined by a 2456 reservation protocol during the formation of a multi-hop path. As 2457 defined by [RFC3471],[RFC3473] and [RFC4606] a generalized label 2458 identifies a flow of data through a set of nodes that conform to a 2459 multi-hop path. Instead of being appended to each packet as is the 2460 case in MPLS [RFC3031], the generalized label it is kept at each node 2461 in the form of a table. The table can be used to map input cells to 2462 output cells so routing decisions can be taken at that layer. 2464 In order to optimize the combination of GMPLS and TSCH, 6top provides 2465 specific support to GMPLS in the following aspects: 2467 Cell Reservation Support 2469 QoS 2471 3.2.1. Cell Reservation Support for GMPLS on 6top 2473 The GMPLS control plane is used to send path reservation requests and 2474 reservation confirmations. When reservation confirmations are 2475 received, GMPLS needs to configure the underlying MAC layer to 2476 provide the required bandwidth. 6top provides a set of commands to 2477 deal with bandwidth allocation, i.e. cell allocation. Section 2.4.1 2478 describes the operations that GMPLS layer may use for cell 2479 configuration. Note that 6top supports different types of 2480 reservations: soft cell and hard cell. How the reservation 2481 requirements are expressed is out of scope of this document, but 6top 2482 is able to handle a reservation done as a specific bandwidth 2483 requirement, done through specifying exact cells. 2485 GMPLS can also give different priorities to its control plane and 2486 data plane. It can for example be interesting to have a higher 2487 priority for control messages so the network adapts to new bandwidth 2488 requirements quickly. In contrast, data plane messages can be given 2489 a higher priority when they need to meet higher throughput or lower 2490 latency. 6top provides commands (Section 2.4.8) to manage MAC layer 2491 queues and assign different priorities to them. 2493 3.2.2. Supporting QoS 2495 GMPLS can use 6top statistics to determine whether some QoS 2496 requirement is met. Metrics defined in Section 2.7 and operations 2497 defined in Section 2.4.4.4 can be used by GMPLS to trigger new 2498 bandwidth allocation, or to map different input bundles to output 2499 bundles. 2501 4. References 2503 4.1. Normative References 2505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2506 Requirement Levels", BCP 14, RFC 2119, March 1997. 2508 4.2. Informative References 2510 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2511 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2512 Functional Specification", RFC 2205, September 1997. 2514 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2515 Networks", RFC 2464, December 1998. 2517 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2518 Label Switching Architecture", RFC 3031, January 2001. 2520 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2521 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2523 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 2524 (GMPLS) Signaling Functional Description", RFC 3471, 2525 January 2003. 2527 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2528 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2529 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2531 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2532 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2533 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2534 RFC 3819, July 2004. 2536 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 2537 Protocol Label Switching (GMPLS) Extensions for 2538 Synchronous Optical Network (SONET) and Synchronous 2539 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 2541 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2542 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2543 Overview, Assumptions, Problem Statement, and Goals", RFC 2544 4919, August 2007. 2546 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2547 "Transmission of IPv6 Packets over IEEE 802.15.4 2548 Networks", RFC 4944, September 2007. 2550 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 2551 "Routing Requirements for Urban Low-Power and Lossy 2552 Networks", RFC 5548, May 2009. 2554 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 2555 Routing Requirements in Low-Power and Lossy Networks", RFC 2556 5826, April 2010. 2558 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 2559 "Building Automation Routing Requirements in Low-Power and 2560 Lossy Networks", RFC 5867, June 2010. 2562 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 2563 "Industrial Routing Requirements in Low-Power and Lossy 2564 Networks", RFC 5673, October 2009. 2566 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 2567 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2568 September 2011. 2570 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 2571 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 2572 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 2573 Lossy Networks", RFC 6550, March 2012. 2575 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 2576 Application Spaces for IPv6 over Low-Power Wireless 2577 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 2579 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 2580 Statement and Requirements for IPv6 over Low-Power 2581 Wireless Personal Area Network (6LoWPAN) Routing", RFC 2582 6606, May 2012. 2584 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 2585 for OAuth", RFC 6755, October 2012. 2587 [I-D.watteyne-6tsch-tsch-lln-context] 2588 Watteyne, T., Palattella, M., and L. Grieco, "Using 2589 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 2590 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 2591 context-02 (work in progress), May 2013. 2593 [I-D.thubert-6tsch-architecture] 2594 Thubert, P., Assimiti, R., and T. Watteyne, "An 2595 Architecture for IPv6 over Time Slotted Channel Hopping", 2596 draft-thubert-6tsch-architecture-01 (work in progress), 2597 April 2013. 2599 [I-D.palattella-6tsch-terminology] 2600 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 2601 "Terminology in IPv6 over Time Slotted Channel Hopping", 2602 draft-palattella-6tsch-terminology-00 (work in progress), 2603 March 2013. 2605 [I-D.vilajosana-6tsch-basic] 2606 Vilajosana, X., "Minimal 6TSCH Configuration", draft- 2607 vilajosana-6tsch-basic-00 (work in progress), June 2013. 2609 [I-D.ohba-6tsch-security] 2610 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 2611 A. Yegin, "Security Framework and Key Management Protocol 2612 Requirements for 6TSCH", draft-ohba-6tsch-security-01 2613 (work in progress), July 2013. 2615 [I-D.thubert-roll-forwarding-frags] 2616 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 2617 Recovery", draft-thubert-roll-forwarding-frags-01 (work in 2618 progress), February 2013. 2620 [I-D.tsao-roll-security-framework] 2621 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 2622 Security Framework for Routing over Low Power and Lossy 2623 Networks", draft-tsao-roll-security-framework-02 (work in 2624 progress), March 2010. 2626 [I-D.thubert-roll-asymlink] 2627 Thubert, P., "RPL adaptation for asymmetrical links", 2628 draft-thubert-roll-asymlink-02 (work in progress), 2629 December 2011. 2631 [I-D.ietf-roll-terminology] 2632 Vasseur, J., "Terminology in Low power And Lossy 2633 Networks", draft-ietf-roll-terminology-12 (work in 2634 progress), March 2013. 2636 [I-D.ietf-roll-p2p-rpl] 2637 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 2638 Martocci, "Reactive Discovery of Point-to-Point Routes in 2639 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17 2640 (work in progress), March 2013. 2642 [I-D.ietf-roll-trickle-mcast] 2643 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 2644 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 2645 mcast-04 (work in progress), February 2013. 2647 [I-D.thubert-6lowpan-backbone-router] 2648 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 2649 6lowpan-backbone-router-03 (work in progress), February 2650 2013. 2652 [I-D.sarikaya-core-sbootstrapping] 2653 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 2654 Cragie, "Security Bootstrapping Solution for Resource- 2655 Constrained Devices", draft-sarikaya-core- 2656 sbootstrapping-04 (work in progress), April 2012. 2658 [I-D.gilger-smart-object-security-workshop] 2659 Gilger, J. and H. Tschofenig, "Report from the 'Smart 2660 Object Security Workshop', 23rd March 2012, Paris, 2661 France", draft-gilger-smart-object-security-workshop-00 2662 (work in progress), October 2012. 2664 [I-D.phinney-roll-rpl-industrial-applicability] 2665 Phinney, T., Thubert, P., and R. Assimiti, "RPL 2666 applicability in industrial networks", draft-phinney-roll- 2667 rpl-industrial-applicability-02 (work in progress), 2668 February 2013. 2670 [I-D.ietf-core-coap] 2671 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 2672 Application Protocol (CoAP)", draft-ietf-core-coap-18 2673 (work in progress), June 2013. 2675 4.3. External Informative References 2677 [IEEE802154e] 2678 IEEE standard for Information Technology, "IEEE std. 2679 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2680 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 2681 2012. 2683 [IEEE802154] 2684 IEEE standard for Information Technology, "IEEE std. 2685 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2686 and Physical Layer (PHY) Specifications for Low-Rate 2687 Wireless Personal Area Networks", June 2011. 2689 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , 2690 . 2692 [label-switching-154e] 2693 Morell, A., Vilajosana, X., Lopez-Vicario, J., and T. 2694 Watteyne, "Label Switching over IEEE802.15.4e Networks. 2696 Transactions on Emerging Telecommunications Technologies", 2697 June 2013. 2699 Authors' Addresses 2701 Qin Wang (editor) 2702 Univ. of Sci. and Tech. Beijing 2703 30 Xueyuan Road 2704 Beijing, Hebei 100083 2705 China 2707 Phone: +86 (10) 6233 4781 2708 Email: wangqin@ies.ustb.edu.cn 2710 Xavier Vilajosana 2711 Universitat Oberta de Catalunya 2712 156 Rambla Poblenou 2713 Barcelona, Catalonia 08018 2714 Spain 2716 Phone: +34 (646) 633 681 2717 Email: xvilajosana@uoc.edu 2719 Thomas Watteyne 2720 Linear Technology 2721 30695 Huntwood Avenue 2722 Hayward, CA 94544 2723 USA 2725 Phone: +1 (510) 400-2978 2726 Email: twatteyne@linear.com