idnits 2.17.1 draft-wang-6tisch-6top-interface-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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([IEEE802154e]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the TrackID is set to (0,0), the cell can be used by the best-effort QoS configuration or as a Shared cell. If the TrackID is not set to (0,0), i.e., the cell belongs to a specific track, the cell MUST not be set as Shared cell. -- The document date (January 31, 2014) is 3737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 2516, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 2522, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 2528, but not defined == Unused Reference: 'RFC2119' is defined on line 2343, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 2348, but no explicit reference was found in the text == Unused Reference: 'RFC2464' is defined on line 2352, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 2358, but no explicit reference was found in the text == Unused Reference: 'RFC3819' is defined on line 2369, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 2379, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 2384, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 2388, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 2392, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 2396, but no explicit reference was found in the text == Unused Reference: 'RFC5673' is defined on line 2400, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 2404, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 2408, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 2413, but no explicit reference was found in the text == Unused Reference: 'RFC6606' is defined on line 2417, but no explicit reference was found in the text == Unused Reference: 'RFC6755' is defined on line 2422, but no explicit reference was found in the text == Unused Reference: 'I-D.palattella-6tisch-terminology' is defined on line 2437, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tsch-security' is defined on line 2448, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 2454, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 2459, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 2465, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 2470, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 2475, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 2481, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 2486, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 2491, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 2497, but no explicit reference was found in the text == Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is defined on line 2503, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap' is defined on line 2509, 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 (-12) exists of draft-ietf-roll-trickle-mcast-05 == Outdated reference: A later version (-05) exists of draft-sarikaya-core-sbootstrapping-04 == Outdated reference: A later version (-03) exists of draft-gilger-smart-object-security-workshop-00 Summary: 4 errors (**), 0 flaws (~~), 39 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: August 4, 2014 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 January 31, 2014 10 6TiSCH Operation Sublayer (6top) Interface 11 draft-wang-6tisch-6top-interface-00 13 Abstract 15 The recently published [IEEE802154e] standard formalizes the concept 16 of link-layer resources in LLNs. Nodes are synchronized and follow a 17 schedule. A cell in that schedule corresponds to an atomic link- 18 layer resource, and can be allocated to any pair of neighbors in the 19 network. This allows the schedule to be built to tightly match each 20 node's bandwidth, latency and energy constraints. The [IEEE802154e] 21 standard does not, however, present a mechanism to do so, as building 22 and managing the schedule is out of scope of the standard. This 23 document describes the 6TiSCH Operation Sublayer (6top) and the 24 commands it provides to upper network layers such as RPL or GMPLS. 25 The set of functionalities includes feedback metrics from cell states 26 so network layers can take routing decisions, TSCH configuration and 27 control procedures, and the support for decentralized and centralized 28 scheduling. In addition, 6top can be configured to enable packet 29 switching at layer 2.5, analogous to GMPLS. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 4, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. 6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . . 4 67 3. 6top Commands . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. hard cells . . . . . . . . . . . . . . . . . . . . . 7 70 3.1.2. soft cells . . . . . . . . . . . . . . . . . . . . . 7 71 3.2. Data Transfer Model . . . . . . . . . . . . . . . . . . . 7 72 3.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.3.1. Cell Commands . . . . . . . . . . . . . . . . . . . . 11 74 3.3.2. Slotframe Commands . . . . . . . . . . . . . . . . . 17 75 3.3.3. Monitoring Commands . . . . . . . . . . . . . . . . . 20 76 3.3.4. Statistics Commands . . . . . . . . . . . . . . . . . 21 77 3.3.5. Network Formation Commands . . . . . . . . . . . . . 22 78 3.3.6. Time Source Neighbor Commands . . . . . . . . . . . . 24 79 3.3.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 24 80 3.3.8. Queueing Commands . . . . . . . . . . . . . . . . . . 26 81 3.3.9. Data Commands . . . . . . . . . . . . . . . . . . . . 28 82 3.3.10. Label Switching Commands . . . . . . . . . . . . . . 29 83 3.3.11. Chunk Command . . . . . . . . . . . . . . . . . . . . 30 84 3.3.12. Chunk Cell Command . . . . . . . . . . . . . . . . . 30 85 4. Generic Data Model . . . . . . . . . . . . . . . . . . . . . 32 86 4.1. YANG model of 6top MIB . . . . . . . . . . . . . . . . . 32 87 4.2. YANG model of IEEE802.15.4 PIB . . . . . . . . . . . . . 47 88 4.3. YANG model of IEEE802.15.4e PIB . . . . . . . . . . . . . 47 89 5. Using 6top . . . . . . . . . . . . . . . . . . . . . . . . . 47 90 5.1. RPL on 6top . . . . . . . . . . . . . . . . . . . . . . . 47 91 5.1.1. Support to Neighbor Discovery and Parent Selection . 47 92 5.1.2. Support of Rank Computation . . . . . . . . . . . . . 48 93 5.1.3. Support of Control Messages Broadcast . . . . . . . . 49 94 5.1.4. Support for QoS . . . . . . . . . . . . . . . . . . . 50 95 5.2. GMPLS on 6top . . . . . . . . . . . . . . . . . . . . . . 51 96 5.2.1. Cell Reservation Support for GMPLS on 6top . . . . . 51 97 5.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 52 98 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 99 6.1. Normative References . . . . . . . . . . . . . . . . . . 52 100 6.2. Informative References . . . . . . . . . . . . . . . . . 52 101 6.3. External Informative References . . . . . . . . . . . . . 56 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 104 1. Introduction 106 As presented in [I-D.watteyne-6tsch-tsch-lln-context], the 107 [IEEE802154e] standard defines the mechanisms for a TSCH node to 108 communicate, given a schedule. It does not, however, define the 109 mechanism to build and maintain the TSCH schedule, match that 110 schedule to the multi-hop paths maintained by a network layer such as 111 RPL or a 2.5 layer such as GMPLS, adapt the resources allocated 112 between neighbor nodes to the data traffic flows, enforce a 113 differentiated treatment for data generated at the application layer 114 and signalling messages needed by 6LoWPAN and RPL to discover 115 neighbors, react to topology changes, self-configure IP addresses, or 116 manage keying material. 118 In a TSCH network, the MAC layer is not in charge of setting up the 119 schedule that controls the connectivity graph of the network and the 120 resources allocated to each cell in that topology. This 121 responsibility is left to an upper layer, defined in this document 122 and called "6top". 124 This document describes the 6TiSCH Operation Sublayer (6top) and the 125 main commands provided to upper network layers such as RPL or GMPLS. 126 The set of functionalities include feedback metrics from cell state 127 so the network layer can take routing decisions, TSCH configuration 128 and control procedures, and support for the different scheduling 129 mechanisms defined in [I-D.thubert-6tisch-architecture]. 6top 130 addresses the set of functionalities described in 131 [I-D.watteyne-6tsch-tsch-lln-context]. 133 For example, network formation in a TSCH network is handled by the 134 use of Enhanced Beacons (EB). EBs include information for joining 135 nodes to be able to synchronize and set up an initial network 136 topology. However, [IEEE802154e] does not specify how the period of 137 EBs is configured, nor the rules for a node to select a particular 138 node to join. 6top offers a set of commands so control mechanisms can 139 be introduced on top of TSCH to configure nodes to join a specific 140 node and obtain a unique 16-bit identifier from the network. Once a 141 network is formed, 6top maintains the network's health, allowing for 142 nodes to stay synchronized. It supplies mechanisms to manage each 143 node's time source neighbor and configure the EB interval. Network 144 layers running on top of 6top take advantage of the TSCH MAC layer 145 information so routing metrics, topological information, energy 146 consumption and latency requirements can be adjusted to TSCH, and 147 adapted to application requirements. 149 TSCH requires a mechanism to manage its schedule; 6top provides a set 150 of commands for upper layers to set up specific schedules, either 151 explicitly by detailing specific cell information, or by allowing 152 6top to establish a schedule given a bandwidth or latency 153 requirement. 6top is designed to enable decentralized, centralized or 154 hybrid scheduling solutions. 6top enables internal TSCH queuing 155 configuration, size of buffers, packet priorities, transmission 156 failure behavior, and defines mechanisms to encrypt and authenticate 157 MAC slotframes. 159 As described in [label-switching-154e], due to the slotted nature of 160 a TSCH network, it is possible to use a label switched architecture 161 on top of TSCH cells. As a cell belongs to a specific track, a label 162 header is not needed at each packet; the input cell (or bundle) and 163 the output cell (or bundle) uniquely identify the data flow. The 164 6top sublayer provides operations to manage the cell mappings. 166 2. 6TiSCH Operation Sublayer (6top) Overview 168 6top is a sublayer which is the next-higher layer for TSCH 169 (Figure 1), as detailed in [I-D.thubert-6tisch-architecture]. 6top 170 offers both management and data interfaces to an upper layer. It 171 includes monitoring and statistics collection, both of which are 172 configurable through the management interface. 174 Protocol Stack 176 +-----------------------------------+ 177 | PCEP | CoAP | | 6LoWPAN | | 178 | PCC | DTLS | PANA | ND |RPL | 179 +------------------------------------------+ 180 | TCP | UDP | ICMP | RSVP | 181 +------------------------------------------+ 182 | IPv6 | 183 +------------------------------------------+ 184 | 6LoWPAN HC | 185 +------------------------------------------+ 186 | 6top | 187 +------------------------------------------+ 188 | IEEE802.15.4e TSCH | 189 +------------------------------------------+ 190 | IEEE802.15.4 | 191 +------------------------------------------+ 193 Figure 1 195 6top distinguishes between hard cells and soft cells. It therefore 196 requires an extra flag to all cells in the TSCH schedule, as detailed 197 in Section 3.1. 199 When a higher layer gives 6top a 6LoWPAN packet for transmission, 200 6top maps it to the appropriate outgoing priority-based queue, as 201 detailed in Section 3.2. 203 All commands of the management and data interfaces are detailed in 204 Section 3.3. This set of commands is designed to support 205 decentralized, centralized and hybrid scheduling solutions. 207 YANG is used to express 6top data model, detailed in Section 4. 209 3. 6top Commands 211 3.1. Cell Model 213 [IEEE802154e] defines a set of options attached to each cell. A cell 214 can be a Transmit cell, a Receive cell, a Shared cell or a 215 Timekeeping cell. These options are not exclusive, as a cell can be 216 qualified with more than one of them. The MLME-SET-LINK.request 217 command defined in [IEEE802154e] uses a linkOptions bitmap to specify 218 the options of a cell. Acceptable values are: 220 b0 = Transmit 221 b1 = Receive 223 b2 = Shared 225 b3 = Timekeeping 227 b4-b7 = Reserved 229 Only Transmit cells can also be marked as Shared cells. When the 230 shared bit is set, a back-off procedure is applied to handle 231 collisions. Shared behavior does not apply to Receive cells. 233 6top allows an upper layer to schedule a cell at a specific 234 slotOffset and channelOffset, in a specific slotframe. 236 In addition, 6top allows an upper layer to schedule a certain amount 237 of bandwidth to a neighbor, without having to specify the exact 238 slotOffset(s) and channelOffset(s). Once bandwidth is reserved, 6top 239 is in charge of ensuring that this requirement is continuously 240 satisfied. 6top dynamically reallocates cells if needed, and over- 241 provisions if required. 243 6top allows an upper layer to associate a cell with a specific track 244 by using a TrackID. A TrackID is a tuple 245 (TrackOwnerAddr,InstanceID), where TrackOwnerAddr is the address of 246 the node which initializes the process of creating the track, i.e., 247 the owner of the track; and InstanceID is an instance identifier 248 given by the owner of the track. InstanceID comes from upper layer; 249 InstanceID could for example be the local instance ID defined in RPL. 251 If the TrackID is set to (0,0), the cell can be used by the best- 252 effort QoS configuration or as a Shared cell. If the TrackID is not 253 set to (0,0), i.e., the cell belongs to a specific track, the cell 254 MUST not be set as Shared cell. 256 6top allows an upper layer ask a node manage a a portion of a 257 slotframe, which is named as chunk. Chunks can be delegated 258 explicitly by the PCE to a node, or claimed automatically by any node 259 that participates to the distributed cell scheduling process. The 260 resource in a chunk can be appropriated by the node, i.e. the owner 261 of the chunk. 263 Given this mechanism, 6top defines hard cells (which have been 264 requested specifically) and soft cells (which can be reallocated 265 dynamically). The hard/soft flag is introduced by the 6top sublayer 266 named as CellType, 0: soft cell, 1: hard cell. This option is 267 mandatory; all cells are either hard or soft. 269 3.1.1. hard cells 271 A hard cell is a cell that cannot be dynamically reallocated by 6top. 272 A hard cell is uniquely identified by the following tuple: 274 slotframe ID: ID of the slotframe this cell is part of. 276 slotOffset: the slotOffset for the cell. 278 channelOffset: the channelOffset for the cell. 280 LinkOption bitmap: bitmap as defined in [IEEE802154]. 282 CellType: MUST be set to 1. 284 3.1.2. soft cells 286 A soft cell is a cell that can be reallocated by 6top dynamically. 287 The CellType MUST be set to 0. This cell is installed by 6top given 288 a specific bandwidth requirement. Soft cells are installed through 289 the soft cell negotiation procedure described in "draft-wang-6tisch- 290 6top-sublayer". 292 3.2. Data Transfer Model 294 Once a TSCH schedule is established, 6top is responsible for feeding 295 the data from the upper layer into TSCH. This section describes how 296 6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds 297 it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, the 298 properties associated with a packet/fragment from the upper layer 299 includes the next hop neighbor (DestAddr) and expected sending 300 priority of the packet (Priority), and/or TrackID(s). The output to 301 TSCH is the fragment corresponding to the next active cell in the 302 TSCH schedule. 304 6top Data Transfer Model 306 | 307 | (DestAddr, Priority, Fragment) 308 | 309 +---------------------------------------+ 310 | I-MUX | 311 +---------------------------------------+ 312 | | | | .... | 313 | | | | | 314 +---+ +---+ +---+ +---+ +---+ 315 | | | | | | | | | | 316 |Q1 | |Q2 | |Q3 | |Q4 | |Qn | 317 | | | | | | | | | | 318 +---+ +---+ +---+ +---+ +---+ 319 | | | | | 320 | | | | | 321 +---------------------------------------+ 322 | MUX | 323 +---------------------------------------+ 324 | 325 | 326 +---+ 327 |PDU| 328 +---+ 329 | 330 | TSCH MAC-payload 331 | 333 Figure 2 335 In Figure 2, Qi represents a queue, which is either broadcast or 336 unicast, and is assigned a priority. The number of queues is 337 configurable. The relationship between queues and tracks is 338 configurable. For example, for a given queue, only one specific 339 track can be used, all of the tracks can be used, or a subset of the 340 tracks can be used. 342 When 6top receives a packet to transmit through a Send.data command 343 (Section 3.3.9), the I-MUX module selects a queue in which to insert 344 it. If the packet's destination address is a unicast (resp. 345 broadcast) address, it will be inserted into a unicast (resp. 346 broadcast) queue. 348 The MUX module is invoked at each scheduled transmit cell by TSCH. 349 When invoked, the MUX module goes through the queues, looking for the 350 best matching frame to send. If it finds a frame, it hands it over 351 to TSCH for transmission. If the next active cell is a broadcast 352 cell, it selects a fragment only from broadcast queues. 354 How the MUX module selects the best frame is configurable. The 355 following rules are a typical example: 357 The frame's layer 2 destination address MUST match the neighbor 358 address associated with the transmit cell. 360 If the transmit cell is associated with a specific track, the 361 frames in the queue corresponding to the TrackID have the 362 highest priority. 364 If the transmit cell is not associated with a specific track, 365 i.e., TrackID=(0,0), frames from a queue with a higher priority 366 MUST be sent before frames from a queue with a lower priority. 368 Further rules can be configured to satisfy specific QoS requirements. 370 3.3. Commands 372 6top provides a set of commands as the interface with the higher 373 layer. Most of these commands are related to the management of 374 slotframes, cells and scheduling information. 6top also provides an 375 interface allowing an upper layer to retrieve status information and 376 statistics. This section describes the following commands provided 377 by 6top. 379 CREATE.hardcell: Section 3.3.1.1 381 CREATE.softcell: Section 3.3.1.2 383 READ.cell: Section 3.3.1.3 385 UPDATE.cell: Section 3.3.1.4 387 DELETE.hardcell: Section 3.3.1.5 389 DELETE.softcell: Section 3.3.1.6 391 REALLOCATE.softcell: Section 3.3.1.7 393 CREATE.slotframe: Section 3.3.2.1 395 READ.slotframe: Section 3.3.2.2 397 UPDATE.slotframe: Section 3.3.2.3 398 DELETE.slotframe: Section 3.3.2.4 400 CONFIGURE.monitoring: Section 3.3.3.1 402 READ.monitoring: Section 3.3.3.2 404 CONFIGURE.statistics: Section 3.3.4.1 406 READ.statistics: Section 3.3.4.2 408 RESET.statistics: Section 3.3.4.3 410 CONFIGURE.eb: Section 3.3.5.1 412 READ.eb: Section 3.3.5.2 414 CONFIGURE.timesource: Section 3.3.6.1 416 READ.timesource: Section 3.3.6.2 418 CREATE.neighbor: Section 3.3.7.1 420 READ.all.neighbor: Section 3.3.7.2 422 READ.neighbor: Section 3.3.7.3 424 UPDATE.neighbor: Section 3.3.7.4 426 DELETE.neighbor: Section 3.3.7.5 428 CREATE.queue: Section 3.3.8.1 430 READ.queue: Section 3.3.8.2 432 READ.queue.stats: Section 3.3.8.3 434 UPDATE.queue: Section 3.3.8.4 436 DELETE.queue: Section 3.3.8.5 438 Send.data: Section 3.3.9.1 440 Receive.data: Section 3.3.9.2 442 LabelSwitching.map: Section 3.3.10.1 444 LabelSwitching.unmap: Section 3.3.10.2 445 CREATE.chunk: Section 3.3.11.1 447 DELETE.chunk: Section 3.3.11.2 449 CREATE.hardcell.fromchunk: Section 3.3.12.1 451 DELETE.hardcell.fromchunk: Section 3.3.12.2 453 3.3.1. Cell Commands 455 6top provides the following commands to manage TSCH cells. 457 3.3.1.1. CREATE.hardcell 459 Creates one or more hard cells in the schedule. Fails if the cell 460 already exists. A cell is uniquely identified by the tuple 461 (slotframe ID, slotOffset, channelOffset). 463 To create a hard cell, the upper layer specifies: 465 slotframe ID: ID of the slotframe this timeslot will be 466 scheduled in. 468 slotOffset: the slotOffset for the cell. 470 channelOffset: channelOffset for the cell. 472 LinkOption bitmap: bitmap as defined in [IEEE802154e] 474 LinkType : as defined in section 6.2.19.3 of [IEEE802154e]. 476 CellType: as defined in Section 3.1 478 target node address: the address of that node to communicate 479 with over this cell. In case of broadcast cells this is the 480 broadcast address. 482 TrackID: ID of the track the cell will belong to. 484 6top schedules the cell and marks it as a hard cell, indicating that 485 it cannot reschedule this cell. The return value is CellID and the 486 created cell is also filled in CellList (Section 4.1). 488 The interaction between 6top and MAC layer caused by CREATE.hardcell 489 is as follows. 491 Firstly, 6top calls the premitive MLME-SET-LINK.request defind in 492 section 6.2.19.3 of [IEEE802154e]. The premitive parameters are set 493 as follows. 495 +---------------------------------+---------------------------------+ 496 | MLME-SET-LINK.request parameter | set by 6top | 497 +---------------------------------+---------------------------------+ 498 | operation | ADD-LINK | 499 +---------------------------------+---------------------------------+ 500 | LinkHandle | CellID | 501 +---------------------------------+---------------------------------+ 502 | slotframeHandle | slotframe ID | 503 +---------------------------------+---------------------------------+ 504 | timeslot | slotOffset | 505 +---------------------------------+---------------------------------+ 506 | channelOffset | channelOffset | 507 +---------------------------------+---------------------------------+ 508 | LinkOptions | LinkOption bitmap | 509 +---------------------------------+---------------------------------+ 510 | LinkType | LinkType | 511 +---------------------------------+---------------------------------+ 512 | nodeAddr | target node address | 513 +---------------------------------+---------------------------------+ 515 Secondly, if the status from MLME-SET-LINK.confirm defined in section 516 6.2.19.4 of [IEEE802154e] is SUCCESS, then add the LinkHandle to the 517 BundleList specified by TrackID, and confirm to upper layer with 518 status = SUCCESS; otherwise, confirm to upper layer with status = 519 FAIL. 521 3.3.1.2. CREATE.softcell 523 To create soft cell(s), the upper layer specifies: 525 slotframe ID: ID of the slotframe the cell(s) will be scheduled 526 in 528 number of cells: the required number of soft cells. 530 LinkOption bitmap: bitmap as defined in [IEEE802154e] 532 CellType: as defined in Section 3.1 534 target node address: the address of the node to communicate 535 with over the cell(s). In case of broadcast cells this is the 536 broadcast address. 538 TrackID: ID of the track the cell(s) will belong to. 540 QoS level: the cell redundancy policy. The policy can be for 541 example STRICT, BEST_EFFORT, etc. 543 6top is responsible for picking the exact slotOffset and 544 channelOffset in the schedule, and ensure that the target node choose 545 the same cell and TrackID. 6top marks these cells as soft cell, 546 indicating that it will continuously monitor their performance and 547 reschedule if needed. The return value is CellID, and the created 548 cell is also filled in CellList (Section 4.1). 550 6top deals with the allocation process by negotiation with the target 551 node. The command returns the list of created cells defined by 552 (slotframe ID, slotOffset, channelOffset). It fails if the required 553 number of cells is higher than the available number of cells in the 554 schedule. It fails if the negotiation with the target node fails. 555 It fails if the LinkOption bitmap indicates that the cell(s) MUST be 556 Hard. 558 The interaction between 6top and TSCH happens on both sides described 559 as follows. 561 For example, after neigotiation, node A and node B find a specifical 562 cell, slotOffset=10, channelOffset=12, as a Tx cell and Rx cell, 563 respectively, then the 6top in node A and node B will call the 564 premitive MLME-SET-LINK.request defind in section 6.2.19.3 of 565 [IEEE802154e], respectively. The premitive parameters are set in 566 node A and node B as follows. 568 +---------------------------------+---------------------------------+ 569 | MLME-SET-LINK.request parameter | set by A's 6top | set by B's top| 570 +---------------------------------+---------------------------------+ 571 | operation | ADD-LINK | ADD-LINK | 572 +---------------------------------+---------------------------------+ 573 | LinkHandle | CellID | CellID | 574 +---------------------------------+---------------------------------+ 575 | slotframeHandle | slotframe ID | slotframe ID | 576 +---------------------------------+---------------------------------+ 577 | timeslot | 10 | 10 | 578 +---------------------------------+---------------------------------+ 579 | channelOffset | 12 | 12 | 580 +---------------------------------+---------------------------------+ 581 | LinkOptions | Tx | Rx | 582 +---------------------------------+---------------------------------+ 583 | LinkType | NORMAL | NORMAL | 584 +---------------------------------+---------------------------------+ 585 | nodeAddr | Node A | Node B | 586 +---------------------------------+---------------------------------+ 587 If the Status from MLME-SET-LINK.confirm defined in section 6.2.19.4 588 of [IEEE802154e], 6top will notify upper layer failure. 590 3.3.1.3. READ.cell 592 Given a (slotframe ID, slotOffset, channelOffset), retrieves the cell 593 information. Fails if the cell does not exist. The returned 594 information contains: 596 slotframe ID: ID of the slotframe where this cell is installed. 598 slotOffset: the slotOffset for the cell. 600 channelOffset: the selected channelOffset for the cell. 602 LinkOption bitmap: bitmap as defined in [IEEE802154e] 604 CellType: as defined in Section 3.1 606 target node address: the target address of that cell. In case 607 of broadcast cells this is the broadcast address. 609 TrackID: ID of the track the cell will belong to. 611 NumOfStatistics: Number of elements in the following list of 612 tuple (StatisticsMetriceID and StatisticsValue) 614 list of (StatisticsMetriceID, StatisticsValue): 615 StatisticsMetriceID is the index to Statistics Metric defined 616 in Section 3.3.4, StatisticsValue is the value corresponding to 617 the metric indexd by StatisticsMetriceID 619 A read command can be issued for any cell, hard or soft. 6top gets 620 cell information from CellList (Section 4.1). 622 3.3.1.4. UPDATE.cell 624 Update a hard cell, i.e., re-allocate it to a different slotOffset 625 and/or channelOffset. Fails if the cell does not exist. Requires 626 both old (slotframe ID, slotOffset, channelOffset) and new (slotframe 627 ID, slotOffset, channelOffset) as parameters. And, the type of cell, 628 target node address and TrackID are the fields that cannot be 629 updated. Soft cells MUST NOT be updated by the UPDATE.cell command. 630 REALLOCATE.softcell (Section 3.3.1.7) MUST be used instead. 632 It causes a old cell being removed and a new cell being created. 634 3.3.1.5. DELETE.hardcell 636 To remove a hard cell, the upper layer specifies: 638 slotframe ID: the ID of the slotframe where this cell is 639 installed. 641 slotOffset: the slotOffset for the cell. 643 channelOffset: the selected channelOffset for the cell. 645 LinkOption bitmap: bitmap as defined in [IEEE802154e] 647 LinkType : as defined in in section 6.2.19.3 of [IEEE802154e]. 649 CellType: as defined in Section 3.1 651 target node address: the target address of that cell. In case 652 of broadcast cells this is the broadcast address. 654 TrackID: ID of the track the cell will belong to. 656 This removes the hard cell from the node's schedule, from CellList 657 (Section 4.1)as well. 659 The interaction between 6top and MAC layer caused by DELETE.hardcell 660 is as follows. 662 Firstly, 6top calls the premitive MLME-SET-LINK.request defind in 663 section 6.2.19.3 of [IEEE802154e]. The premitive parameters are set 664 as follows. 666 +---------------------------------+---------------------------------+ 667 | MLME-SET-LINK.request parameter | set by 6top | 668 +---------------------------------+---------------------------------+ 669 | operation | DELETE-LINK | 670 +---------------------------------+---------------------------------+ 671 | LinkHandle | CellID | 672 +---------------------------------+---------------------------------+ 673 | slotframeHandle | slotframe ID | 674 +---------------------------------+---------------------------------+ 675 | timeslot | slotOffset | 676 +---------------------------------+---------------------------------+ 677 | channelOffset | channelOffset | 678 +---------------------------------+---------------------------------+ 679 | LinkOptions | LinkOption bitmap | 680 +---------------------------------+---------------------------------+ 681 | LinkType | LinkType | 682 +---------------------------------+---------------------------------+ 683 | nodeAddr | target node address | 684 +---------------------------------+---------------------------------+ 686 Secondly, if the status from MLME-SET-LINK.confirm defined in section 687 6.2.19.4 of [IEEE802154e] is SUCCESS, then remove the LinkHandle from 688 its BundleList specified by TrackID, and confirm to upper layer with 689 status = SUCCESS; otherwise, confirm to upper layer with status = 690 FAIL. 692 3.3.1.6. DELETE.softcell 694 To remove a (number of) soft cell(s), the upper layer specifies: 696 slotframe ID: ID of the slotframe where this cell is installed. 698 number of cells: the number of cells to be removed 700 LinkOption bitmap: bitmap as defined in [IEEE802154e] 702 CellType: as defined in Section 3.1 704 target node address: the target address of that cell. In case 705 of broadcast cells this is the broadcast address. 707 TrackID: ID of the track the cell will belong to. 709 In the case a soft cell wants to be re-allocated from the allocated 710 cell so a hard cell can be installed instead, the REALLOCATE.softcell 711 (Section 3.3.1.7) MUST be used. 713 After the pair of nodes figure out the specific cell(s) to be 714 removed, the interaction between 6top and TSCH on both sides will be 715 similar to that caused by DELETE.hardcell, except LinkType should be 716 set to NORMAL. 718 3.3.1.7. REALLOCATE.softcell 720 To force a re-allocation of a soft cell, the upper layer specifies: 722 slotframe ID: ID of the slotframe where the cell is allocated. 724 slotOffset: the slotOffset for that cell. 726 channelOffset: the channelOffset for that cell. 728 The reallocated cell will be installed in a different slotOffset, 729 channelOffset but slotframe and TrackID remain the same. Hard cells 730 MUST NOT be reallocated. 732 The interaction between 6top and TSCH caused by this command includes 733 that described in Section 3.3.1.6 and Section 3.3.1.2. 735 3.3.2. Slotframe Commands 737 6top provides the following commands to manage TSCH slotframes. 739 3.3.2.1. CREATE.slotframe 741 Creates a new slotframe. The command requires: 743 slotframe ID: unique identifier of the slotframe, corresponding 744 to its priority. 746 number of timeslots: the required number of timeslots in the 747 slotframe. 749 Fails if the number of required timeslots is less than zero. 751 The interaction between 6top and MAC layer caused by CREATE.slotframe 752 is as follows. 754 Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind 755 in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are 756 set as follows. 758 +---------------------------------+---------------------------------+ 759 | MLME-SET-SLOTFRAME.request | | 760 | parameter | set by 6top | 761 +---------------------------------+---------------------------------+ 762 | slotframeHandle | slotframe ID | 763 +---------------------------------+---------------------------------+ 764 | operation | ADD | 765 +---------------------------------+---------------------------------+ 766 | size | number of timeslot | 767 +---------------------------------+---------------------------------+ 769 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 770 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 771 layer with status = SUCCESS; otherwise, confirm to upper layer with 772 status = FAIL. 774 3.3.2.2. READ.slotframe 776 Returns the information of a slotframe given its slotframe ID. The 777 command returns: 779 slotframe ID: ID of the slotframe. (SlotFrameHandle) 781 number of timeslots: the number of timeslots in the slotframe. 783 Fails if the slotframe ID does not exist. 785 TODO: access a specific slotframe with PIBAttribute of MLME- 786 GET.request 788 3.3.2.3. UPDATE.slotframe 790 Change the number of timeslots in a slotframe. The command requires: 792 slotframe ID: ID of the slotframe. 794 number of timeslots: the number of timeslots to be updated. 796 Fails if the number of required timeslots is less than zero. Fails 797 if the slotframe ID does not exist. 799 The interaction between 6top and MAC layer caused by UPDATE.slotframe 800 is as follows. 802 Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind 803 in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are 804 set as follows. 806 +---------------------------------+---------------------------------+ 807 | MLME-SET-SLOTFRAME.request | | 808 | parameter | set by 6top | 809 +---------------------------------+---------------------------------+ 810 | slotframeHandle | slotframe ID | 811 +---------------------------------+---------------------------------+ 812 | operation | MODIFY | 813 +---------------------------------+---------------------------------+ 814 | size | number of timeslot | 815 +---------------------------------+---------------------------------+ 817 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 818 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 819 layer with status = SUCCESS; otherwise, confirm to upper layer with 820 status = FAIL. 822 3.3.2.4. DELETE.slotframe 824 Deletes a slotframe. The command requires: 826 slotframe ID: ID of the slotframe. 828 number of timeslot: the number of timeslots in the slotframe. 830 Fails if the slotframe ID does not exist. 832 The interaction between 6top and MAC layer caused by DELETE.slotframe 833 is as follows. 835 Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind 836 in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are 837 set as follows. 839 +---------------------------------+---------------------------------+ 840 | MLME-SET-SLOTFRAME.request | | 841 | parameter | set by 6top | 842 +---------------------------------+---------------------------------+ 843 | slotframeHandle | slotframe ID | 844 +---------------------------------+---------------------------------+ 845 | operation | DELETE | 846 +---------------------------------+---------------------------------+ 847 | size | number of timeslot | 848 +---------------------------------+---------------------------------+ 850 Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in 851 section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper 852 layer with status = SUCCESS; otherwise, confirm to upper layer with 853 status = FAIL. 855 3.3.3. Monitoring Commands 857 Monitoring commands provide the means for upper layers to configure 858 whether 6top must ensure the required bandwidth. This procedure is 859 achieved through overprovisioning according to cell status feedback. 860 Monitoring is also in charge of reallocating soft cells that are 861 under the required QoS. 863 3.3.3.1. CONFIGURE.monitoring 865 Configures the level of QoS the Monitoring process MUST enforce. The 866 command requires: 868 slotframe ID: ID of the slotframe. 870 target node address: the target neighbor address. 872 enforce policy: The policy used to enforce the QoS 873 requirements. Can be for example DISABLE, BEST_EFFORT, STRICT, 874 OVER-PROVISION, etc. 876 Fails if the slotframe ID does not exist. 878 3.3.3.2. READ.monitoring.status 880 Reads the current Monitoring status. Requires the following 881 parameters. 883 slotframe ID: the ID of the slotframe. 885 target node address: the target neighbor address. 887 Returns the QoS levels for that Target node on that slotframe. 889 allocated_hard: Number of hard cells allocated. 891 allocated_soft: Number of soft cells allocated. 893 provisioned: the extra provisioned cells. 0 if CONFIGURE.qos 894 enforce is DISABLE. 896 QoS: the current QoS. Including overprovisioned cells, i.e 897 what bandwidth is being obtained including the overprovisioned 898 cells. 900 RQoS: the real QoS without provisioned cells. What is the 901 actual bandwidth without taking into account the 902 overprovisioned cells. 904 Fails if the slotframe ID does not exist. 906 3.3.4. Statistics Commands 908 6top keeps track of TSCH statistics for upper layers to adapt 909 correctly to medium changes. The exact metrics for statistics are 910 out of scope but the present commands SHOULD be used to configure and 911 read monitored information regardless of the specific metric. 913 3.3.4.1. CONFIGURE.statistics 915 Configures Statistics process. The command requires: 917 slotframe ID: ID of the slotframe. If empty monitors all 918 slotframe IDs 920 slotOffset: specific slotOffset to be monitored. If empty all 921 timeslots are monitored 923 channelOffset: specific channelOffset to be monitored. If 924 empty all channels are monitored. 926 target node address: the target neighbor address. If empty, 927 all neighbor nodes are monitored. 929 metric: metric to be monitored. This MAY be PDR, ETX, queuing 930 statistics, energy-related metrics, etc.) 932 window: time window to be considered for the calculations. If 933 0 all historical data is considered. 935 enable: Enables statistics or disables them. 937 Fails if the slotframe ID does not exist. The statistics service can 938 be configured to retrieve statistics at different levels. For 939 example to aggregate information by slotframe ID, or to retrieve 940 statistics for a particular timeslot, etc. The CONFIGURE.statistics 941 enables flexible configuration and supports empty parameters that 942 will force 6top to conduct statistics on all members of that 943 dimension. For example, if ChannelOffset is empty and metric is set 944 as PDR, then, 6top will conduct the statistics of PDR on all of 945 channels. 947 3.3.4.2. READ.statistics 949 Reads a metric for the specified dimension. Information is 950 aggregated according to the parameters. The command requires: 952 slotframe ID: ID of the slotframe. If empty aggregates 953 information of all slotframe IDs 955 slotOffset: the specific slotOffset for which the information 956 is required. If empty all timeslots are aggregated 958 channelOffset: the specific channelOffset for which the 959 information is required. If empty all channels are aggregated. 961 target node address: the target neighbor address. If empty all 962 neighbor addresses are aggregated. 964 metric: metric to be read. 966 Returns the value for the requested metric. 968 Fails if empty metric or metric does not exits. 970 3.3.4.3. RESET.statistics 972 Resets the gathered statistics. The command requires: 974 slotframe ID: ID of the slotframe. If empty resets the 975 information of all slotframe IDs 977 slotOffset: the specific slotOffset for which the information 978 wants to be reset. If empty statistics from all timeslots are 979 reset 981 channelOffset: the specific channelOffset for which the 982 information wants to be reset. If empty all statistics for all 983 channels are reset. 985 target node address: the target neighbor address. If empty all 986 neighbor addresses are aggregated. 988 metric: metric to be reset. 990 Fails if empty metric or metric does not exits. 992 3.3.5. Network Formation Commands 994 EBs need to be configured, including their transmission period, the 995 slotOffset and channelOffset that they SHOULD be sent on, and the 996 join priority they contain. The parameters for that command are 997 optional and enable flexible configuration of EBs. If slotframe ID 998 is specified, the EBs will be configured to use that specific 999 slotframe; if not, they will use the first slotframe where the 1000 configured slotOffset is allocated. The slotOffset enforces the EB 1001 to a specific timeslot. In case slotOffset parameter is not present, 1002 the EB is sent in the first available transmit timeslot. In case 1003 channelOffset parameter is not set, the EB is configured to use the 1004 first available channel. 1006 3.3.5.1. CONFIGURE.eb 1008 Configures EBs. The command requires: 1010 slotframe ID: ID of the slotframe where the EBs MUST be sent. 1011 Zero if any slotframe can be used. 1013 slotOffset: the slotOffset where the EBs MUST be sent. Zero if 1014 any timeslot can be used. 1016 channelOffset: the channelOffset where the EBs MUST be sent. 1017 Zero if any channelOffset can be used. 1019 period: the EBs period, in seconds. 1021 Expiration: when the EBs periodicity will stop. If Zero the 1022 period never stops. 1024 priority: the joining priority model that will be used for 1025 advertisement. Joining priority MAY be for example 1026 SAME_AS_PARENT, RANDOM, BEST_PARENT+1 or DAGRANK(rank) as 1027 decribed in in [I-D.vilajosana-6tisch-minimal]. 1029 Fails if the tuple (slotframe ID, slotOffset, channelOffset) is 1030 already scheduled. 1032 3.3.5.2. READ.eb 1034 Reads the EBs configuration. No parameters are required. 1036 Returns the current EBs configuration for that slotframe, which 1037 contains: 1039 slotframe ID: the slotframe where the EB is being sent. 1041 slotOffset: the slotOffset where the EBs is being sent. 1043 channelOffset: the channelOffset the EBs is being sent on. 1045 period: the EBs period. 1047 Expiration: when the EBs periodicity stops. If 0 the period 1048 never stops. 1050 priority: the joining priority that this node advertises. 1052 Fails if the slotframe ID does not exist. 1054 3.3.6. Time Source Neighbor Commands 1056 Commands to select time source neighbors. 1058 3.3.6.1. CONFIGURE.timesource 1060 Configures the Time Source Neighbor selection process. More than one 1061 time source neighbor can be selected. The command requires: 1063 selection policy: The policy used to select the time source 1064 neighbor. The policy MAY be for example ALL_PARENTS, 1065 BEST_CONNECTED, LOWEST_JOIN_PRIORITY, etc. 1067 Fails if any of the time source neighbors do not exist or it is not 1068 reachable. 1070 3.3.6.2. READ.timesource 1072 Retrieves information about the time source neighbors of that node. 1073 The command does not require any parameter. 1075 Returns the following information for each of the time sources: 1077 target node: address of the time source neighbor. 1079 statistics: includes for example minimum, maximum, average time 1080 correction for that time source neighbor 1082 policy: the used policy 1084 Fails if the slotframe ID or no time source neighbors exist. 1086 3.3.7. Neighbor Commands 1088 Commands to manage neighbor table. The commands SHOULD be used by 1089 the upper layer to query the neighbor related information and by the 1090 lower layer to keep track of neighbors information. 1092 3.3.7.1. CREATE.neighbor 1094 Creates an entry for a neighbor in the neighbor table. 1096 neighbor address: The address of the neighbor. 1098 neighbor stats: for example, RSSI of the last received packet 1099 from that neighbor, ASN when that neighbor has been added, etc. 1101 Returns whether the neighbor is created or not. 1103 3.3.7.2. READ.all.neighbor 1105 Returns the list of neighbors of that node. Fails if empty. For 1106 each neighbor in the list it returns: 1108 neighbor address: The address of the neighbor. 1110 neighbor stats: for example, RSSI of the last received packet 1111 from that neighbor, ASN when that neighbor has been added, 1112 packets received from that neighbor, packets sent to it, etc. 1114 3.3.7.3. READ.neighbor 1116 Returns the information of a specific neighbor of that node specified 1117 by its neighbor address. Fails if it does not exists. For that 1118 neighbor it returns: 1120 neighbor address: The address of the neighbor. 1122 neighbor stats: for example, RSSI of the last received packet 1123 from that neighbor, ASN when that neighbor has been added, 1124 packets received from that neighbor, packets sent to it, etc. 1126 3.3.7.4. UPDATE.neighbor 1128 Updates an entry for a neighbor in the neighbor table. Fails if the 1129 neighbor does not exist. Updates stats parameters. Requires: 1131 neighbor address: The address of the neighbor. 1133 neighbor stats: for example, RSSI of the last received packet 1134 from that neighbor, ASN when that neighbor has been added, etc. 1136 Returns whether the neighbor is updated or not. 1138 3.3.7.5. DELETE.neighbor 1140 Deletes a neighbor given its address. Fails if the neighbor does not 1141 exists. 1143 3.3.8. Queueing Commands 1145 Queues need to be configured. This includes queue length, 1146 retransmission policy, discarding of packets, etc. 1148 3.3.8.1. CREATE.queue 1150 Creates and Configures Queues. The command SHOULD be applied for 1151 each required queue. The command requires: 1153 txqlength: the desired transmission queue length. 1155 rxqlength: the desired reception queue length. 1157 numrtx: number of allowed retransmissions. 1159 age: discard packet according to its age on the queue. 0 if no 1160 discards are allowed. 1162 rtxbackoff: retransmission backoff in number of slotframes. 0 1163 if next available timeslot wants to be used. 1165 statswindow: window of time used to compute stats. 1167 queue priority: the priority of this queue. 1169 TrackIDs: a set of TrackIDs. While it is empty, no specific 1170 track is associated with the queue 1172 Returns the queue ID. 1174 3.3.8.2. READ.queue 1176 Reads the queue configuration. Requires the queue ID. 1178 The command returns: 1180 txqlength: the transmission queue length. 1182 rxqlength: the reception queue length. 1184 numrtx: number of allowed retransmissions. 1186 age: maximum age of a packet before being discarded. 0 if no 1187 discards are allowed. 1189 rtxbackoff: retransmission backoff in number of slotframes. 0 1190 if next available timeslot is used. 1192 3.3.8.3. READ.queue.stats 1194 Reads the queue stats. Requires queue ID. 1196 The command returns: 1198 txqlengthstats: average, maximum, minimum length of the 1199 transmission queue. 1201 rxqlengthstats: average, maximum, minimum length of the 1202 reception queue. 1204 numrtxstats: average, maximum, minimum number of 1205 retransmissions. 1207 agestats: average, maximum, minimum age of a packet in the 1208 queue. 1210 rtxbackoffstats: average, maximum, minimum retransmission 1211 backoff. 1213 queue priority: the priority of this queue. 1215 TrackIDs: a set of TrackIDs. 1217 3.3.8.4. UPDATE.queue 1219 Update a Queue. The command requires: 1221 queueid: the queue ID. 1223 txqlength: the desired transmission queue length. 1225 rxqlength: the desired reception queue length. 1227 numrtx: number of allowed retransmissions. 1229 age: discard packet according to its age on the queue. 0 if no 1230 discards are allowed. 1232 rtxbackoff: retransmission backoff in number of slotframes. 0 1233 if next available timeslot wants to be used. 1235 statswindow: window of time used to compute stats. 1237 queue priority: the desired priority of this queue. 1239 TrackIDs: the desired set of TrackIDs. 1241 3.3.8.5. DELETE.queue 1243 Deletes a Queue. The command requires the queue ID. All packets in 1244 the queue are discarded and the queue is deleted. 1246 3.3.9. Data Commands 1248 3.3.9.1. Send.data 1250 The command used by upper layers to queue a packet so underlying TSCH 1251 sends it. According to the specific priority, the packet is pushed 1252 into a Queue with the equivalent priority or following a criteria out 1253 of scope. Once a packet is inserted into a queue it waits to be 1254 transmitted by TSCH according to the model defined in Section 3.2. 1255 If the queue is full or destination address is not a L2 neighbor of 1256 the node, failure to enqueue will be indicated to the caller. 1258 The required parameters are: 1260 src address: L2 address 1262 dest address: L2 unicast or broadcast address 1264 priority: packet priority, usually is consistent with queue 1265 priority 1267 message length: the length of the message 1269 message: control message or data message 1271 securityLevel:As defined by [IEEE802154e]. 1273 3.3.9.2. Receive.data 1275 The command is invoked whenever a packet is received and inserted 1276 into a reception queue. The method acts as a callback function to 1277 notify to the upper layers the received message. Upper layers MUST 1278 terminate this indication. 1280 The function has the following parameters: 1282 src address: L2 source address 1283 dest address: L2 unicast or broadcast destination address 1285 priority: packet priority, usually is consistent with queue 1286 priority 1288 message length: the length of the message. 1290 message: control message or data message 1292 3.3.10. Label Switching Commands 1294 3.3.10.1. LabelSwitching.map 1296 The command used by an upper layer to map an input cell or a bundle 1297 of input cells to an output cell or a bundle of output cells. 6top 1298 stores this mapping and makes sure that the packets are forwarded at 1299 the specific output cell/bundle. Label Switching is enabled by the 1300 specified bundle as soon as the mapping is installed. 1302 The required parameters are: 1304 input cells: list of input cells (one or more cells in a 1305 bundle). Each input cells is described by an unique tuple 1306 (slotOffset, channelOffset, destination address). 1308 output cells: list of output cells (one or more cells in a 1309 bundle). Each output cells is described by an unique tuple 1310 (slotOffset, channelOffset, destination address). 1312 load balancing policy: A policy for load balance cell usage. 1313 The policy is out of scope, however an example can be use ROUND 1314 ROBIN policy within the cells of the same bundle. 1316 3.3.10.2. LabelSwitching.unmap 1318 The command used by upper layers to unmap one input cell or a bundle 1319 of input cells to an output cell or a bundle of output cells. The 1320 mapping is removed from the state kept by 6top. 1322 The required parameters are: 1324 input cells: list of input cells (one or more cells in a 1325 bundle). Each input cells is described by an unique tuple 1326 (slotOffset, channelOffset, destination address). 1328 output cells: list of output cells (one or more cells in a 1329 bundle). Each output cells is described by an unique tuple 1330 (slotOffset, channelOffset, destination address). 1332 3.3.11. Chunk Command 1334 3.3.11.1. Create.chunk 1336 Create a chunk which consists of one or more unappropriated cells. 1338 To create a chunk, upper layer specifies: 1340 slotframe ID: ID of the slotframe which this chunk belongs to. 1342 NumOfCells: number of the cells which the chunk includes. 1344 list of (slotOffset, channelOffset): 1346 slotOffset: the slotOffset for the cell. 1348 channelOffset: channelOffset for the cell. 1350 ChunkID is the return value of the command (Section 4.1). 1352 3.3.11.2. Delete.chunk 1354 To delete a chunk, upper layer specifies ChunkID. 1356 It removes the chunk from ChunkList (Section 4.1). It also causes 1357 all of the appropriated cells in the chunk are deleted from CellList 1358 (Section 4.1) and TSCH schedule as well. 1360 3.3.12. Chunk Cell Command 1362 3.3.12.1. CREATE.hardcell.fromchunk 1364 Creates one or more hard cells from a chunk. Fails if the cell 1365 already exists. A cell is uniquely identified by the tuple 1366 (slotframe ID, slotOffset, channelOffset). 1368 To create a hard cell from a chunk which is corresponding to a 1369 specific slotframe ID, the upper layer specifies: 1371 chunkID: ID of the chunk which this cell belongs to. 1373 slotOffset: the slotOffset for the cell. 1375 channelOffset: channelOffset for the cell. 1377 LinkOption bitmap: bitmap as defined in [IEEE802154e] 1379 LinkType : as defined in section 6.2.19.3 of [IEEE802154e]. 1381 CellType: as defined in Section 3.1 1383 target node address: the address of that node to communicate 1384 with over this cell. In case of broadcast cells this is the 1385 broadcast address. 1387 TrackID: ID of the track the cell will belong to. 1389 6top schedules the cell and marks it as a hard cell, indicating that 1390 it cannot reschedule this cell. In addition, 6top will change the 1391 attributes corresponding to the cell in the ChunkList, i.e. its 1392 CellID is changed to the same CellID in the CellList, and its Status 1393 is changed to APPROPRIATED (Section 4.1). 1395 The interaction between 6top and MAC layer caused by 1396 CREATE.hardcell.fromchunk is same as that caused by CREATE.hardcell 1397 (Section 3.3.1.1). 1399 3.3.12.2. DELETE.hardcell.fromchunk 1401 To remove a hard cell which comes from a chunk, the upper layer 1402 specifies: 1404 slotframe ID: the ID of the slotframe where this cell is 1405 installed. 1407 slotOffset: the slotOffset for the cell. 1409 channelOffset: the selected channelOffset for the cell. 1411 LinkOption bitmap: bitmap as defined in [IEEE802154e] 1413 LinkType : as defined in in section 6.2.19.3 of [IEEE802154e]. 1415 CellType: as defined in Section 3.1 1417 target node address: the target address of that cell. In case 1418 of broadcast cells this is the broadcast address. 1420 TrackID: ID of the track the cell will belong to. 1422 This removes the hard cell from the node's schedule and CellList 1423 (Section 4.1). In addition, it changes the attributes corresponding 1424 to the cell in the ChunkList, i.e. its CellID is changed back to 1425 FFFF, and its Status is changed to UNAPPROPRIATED (Section 4.1). 1427 The interaction between 6top and MAC layer caused by DELETE.hardcell 1428 is same as that caused by DELETE.hardcell (Section 3.3.1.5). 1430 4. Generic Data Model 1432 YANG model is used to express the generic data model as follows. The 1433 data model includes that corresponding to 6top MIB, part of 1434 [IEEE802154] PIB and part of [IEEE802154e] PIB. 1436 4.1. YANG model of 6top MIB 1438 list CellList { 1439 key "CellID"; 1441 description 1442 "List of of scheduled cells of a node with all of its neighbors, 1443 in all of its slotframes."; 1445 leaf CellID { 1446 type uint16; 1447 description 1448 "equal to Linkhandle in the linkTable of TSCH"; 1449 reference 1450 "IEEE802154e"; 1451 } 1452 leaf SlotframeID { 1453 type uint8; 1454 description 1455 "equal to SlotframeHandle defined in TSCH"; 1456 reference 1457 "IEEE802154e"; 1458 } 1459 leaf SlotOffset { 1460 type uint16; 1461 description 1462 "Defined in IEEE802154e."; 1463 reference 1464 "IEEE802154e"; 1465 } 1466 leaf ChannelOffset { 1467 type uint8; 1468 description 1469 "Defined in IEEE802154e. Value range is 0..15"; 1470 reference 1471 "IEEE802154e"; 1472 } 1473 leaf LinkOption { 1474 type bits { 1475 bit Transmit { 1476 position 0; 1477 } 1478 bit Receive { 1479 position 1; 1480 } 1481 bit Share { 1482 position 2; 1483 } 1484 bit Timekeeping { 1485 position 3; 1486 } 1487 bit Reserved1 { 1488 position 4; 1489 } 1490 bit Reserved2 { 1491 position 5; 1492 } 1493 bit Reserved3 { 1494 position 6; 1495 } 1496 bit Reserved4 { 1497 position 7; 1498 } 1499 } 1500 description 1501 "Defined in IEEE802154e."; 1502 reference 1503 "IEEE802154e"; 1504 } 1505 leaf LinkType { 1506 type enumeration { 1507 enum NORMAL; 1508 enum ADVERTISING; 1509 } 1510 description 1511 "defined in IEEE802154"; 1512 reference 1513 "IEEE802154"; 1514 } 1515 leaf CellType { 1516 type enumeration { 1517 enum SOFT; 1518 enum HARD; 1519 } 1520 description 1521 "defined in 6top"; 1522 } 1523 leaf TargetNodeAddress { 1524 type uint64; 1525 description 1526 "defined by 6top, but being constrained by TSCH macNodeAddress 1527 size, 2-octets. If using TSCH as MAC, higher 6-octets should 1528 be filled with "0", and lowest 2-octets is neighbor address"; 1529 } 1530 leaf TrackID { 1531 type uint16; 1532 description 1533 "A TrackID is a tuple (TrackOwnerAddr,InstanceID), where 1534 TrackOwnerAddr is the address of the node which initializes 1535 the process of creating the track, i.e., the owner of the 1536 track; and InstanceID is an instance identifier given by the 1537 owner of the track."; 1538 } 1539 container Statistic { 1540 leaf NumOfStatistic { 1541 type uint8; 1542 description 1543 "number of statistics conducted on the cell"; 1544 } 1545 list MeasureList { 1546 key "StatisticsMetricsID"; 1547 leaf StatisticsMetricsID{ 1548 type uint16; 1549 } 1550 leaf StatisticsValue{ 1551 type uint16; 1552 } 1553 } 1554 } 1555 } 1557 list SlotframeList { 1558 key "SlotframeID"; 1559 leaf SlotframeID { 1560 type uint8; 1561 } 1562 leaf NumOfSlots { 1563 type uint16; 1564 } 1565 } 1567 list MonitoringStatusList { 1568 key "MonitoringStatusID"; 1569 leaf MonitoringStatusID { 1570 type uint16; 1571 } 1572 leaf SlotframeID { 1573 type uint8; 1575 } 1576 leaf TargetNodeAddress { 1577 type uint64; 1578 } 1579 leaf EnforcePolicy { 1580 type enumeration { 1581 enum DISABLE; 1582 enum BESTEFFORT; 1583 enum STRICT; 1584 enum OVERPROVISION; 1585 } 1586 description 1587 "current enforced QoS policy"; 1588 } 1589 leaf AllocatedHard { 1590 type uint16; 1591 description 1592 "Number of hard cells allocated"; 1593 } 1594 leaf AllocatedSoft { 1595 type uint16; 1596 description 1597 "Number of soft cells allocated"; 1598 } 1599 leaf OverProvision { 1600 type uint16; 1601 description 1602 "Overprovisioned cells. 0 if CONFIGURE.qos enforce is DISABLE"; 1603 } 1604 leaf QoS { 1605 type uint16; 1606 description 1607 "Current QoS including overprovisioned cells, i.e. the 1608 bandwidth obtained including the overprovisioned cells."; 1609 } 1610 leaf NQoS { 1611 type uint16; 1612 description 1613 "real QoS without provisioned cells, i.e. the actual bandwidth 1614 without taking into account the overprovisioned cells."; 1615 } 1616 } 1618 list StatisticsMetricsList { 1619 key "StatisticsMetricsID"; 1620 leaf StatisticsMetricsID { 1621 type uint16; 1622 } 1623 leaf SlotframeID { 1624 type uint16; 1625 description 1626 "ID of the slotframe. If empty monitors all slotframe IDs"; 1627 reference 1628 "IEEE802154e"; 1629 } 1630 leaf SlotOffset { 1631 type uint16; 1632 description 1633 "Specific slotOffset to be monitored. If empty all timeslots are 1634 monitored"; 1635 reference 1636 "IEEE802154e"; 1637 } 1638 leaf ChannelOffset { 1639 type uint8; 1640 description 1641 "Specific channelOffset to be monitored. If empty all channels 1642 are monitored"; 1643 reference 1644 "IEEE802154e"; 1645 } 1646 leaf TargetNodeAddress { 1647 type uint64; 1648 description 1649 "If empty, all neighbor nodes are monitored."; 1650 } 1651 leaf Metrics { 1652 type enumeration { 1653 enum PDR; 1654 enum ETX; 1655 enum RSSI; 1656 enum LQI; 1657 } 1658 description 1659 "The metric to be monitored."; 1660 } 1661 leaf Window { 1662 type uint16; 1663 description 1664 "measurement period, in Number of the slotframe size"; 1665 } 1666 leaf Enable { 1667 type enumeration { 1668 enum DISABLE; 1669 enum ENABLE; 1670 } 1672 } 1673 } 1675 list EBList { 1676 key "EbID"; 1677 leaf EbID { 1678 type uint8; 1679 } 1680 leaf CellID { 1681 type uint16; 1682 description 1683 "equal to LinkHandle in IEEE802154e"; 1684 } 1685 leaf Peroid { 1686 type uint16; 1687 description 1688 "the EBs period, in seconds"; 1689 } 1690 leaf Expiration { 1691 type enumeration { 1692 enum NEVERSTOP; 1693 enum EXPIRATION; 1694 } 1695 description 1696 "with Period to indicate when the EBs periodicity will stop. 1697 If Zero the period never stops."; 1698 } 1699 leaf Priority { 1700 type uint8; 1701 description 1702 "the joining priority model that will be used for advertisement. 1703 Joining priority MAY be for example SAME_AS_PARENT, RANDOM, 1704 BEST_PARENT+1 or DAGRANK(rank)."; 1705 } 1706 } 1707 container TimeSource { 1708 leaf policy { 1709 type enumeration { 1710 enum ALLPARENT; 1711 enum BESTCONNECTED; 1712 enum LOWESTJOINPRIORITY; 1713 } 1714 } 1715 leaf TargetNodeAddress { 1716 type uint64; 1717 description 1718 "address of the time source neighbor"; 1719 } 1720 leaf MinTimeCorrection { 1721 type uint16; 1722 description 1723 "in microsecond"; 1724 } 1725 leaf MaxTimeCorrection { 1726 type uint16; 1727 description 1728 "in microsecond"; 1729 } 1730 leaf AveTimeCorrection { 1731 type uint16; 1732 description 1733 "in microsecond"; 1734 } 1735 } 1736 typedef asntype { 1737 description 1738 "the type to store ASN. String of 5 bytes"; 1739 type string { 1740 length "0..5"; 1741 } 1742 } 1744 list NeighborList { 1745 key "TargetNodeAddress"; 1747 leaf TargetNodeAddress { 1748 type uint64; 1749 description 1750 "address of the time source neighbor"; 1751 } 1753 leaf RSSI { 1754 type uint8; 1755 description 1756 "the received signal strength"; 1757 } 1759 leaf LinkQuality { 1760 type uint8; 1761 description 1762 "the LQI metric"; 1763 } 1765 leaf ASN { 1766 type asntype; 1767 description 1768 "the 5 ASN bytes"; 1769 } 1770 } 1772 list QueueList { 1773 key "QueueId"; 1775 leaf QueueId { 1776 type uint8; 1777 description 1778 "address of the time source neighbor"; 1779 } 1780 leaf TxqLength { 1781 type uint8; 1782 description 1783 "the tx queue length in number of packets"; 1785 } 1786 leaf RxqLength { 1787 type uint8; 1788 description 1789 "the rxqueue length in number of packets"; 1790 } 1791 leaf NumrTx { 1792 type uint8; 1793 description 1794 "number of allowed retransmissions."; 1795 } 1796 leaf Age { 1797 type uint16; 1798 description 1799 "In seconds. Discard packet according to its age 1800 on the queue. 0 if no discards are allowed."; 1801 } 1803 leaf RTXbackoff { 1804 type uint8; 1805 description 1806 "retransmission backoff in number of slotframes. 1807 0 if next available timeslot wants to be used."; 1808 } 1810 leaf StatsWindow { 1811 type uint16; 1812 description 1813 "In second, window of time used to compute stats."; 1814 } 1816 leaf QueuePriority { 1817 type uint8; 1818 description 1819 "the priority for this queue."; 1820 } 1822 list TrackIds { 1823 key "TrackID"; 1824 unique "TrackID"; 1826 leaf TrackID{ 1827 type uint16; 1828 description 1829 "the TrackID."; 1830 } 1831 } 1832 leaf MinLenTXQueue { 1833 type uint8; 1834 description 1835 "Statistics, lowest TX queue len registered in the window."; 1836 } 1838 leaf MaxLenTXQueue { 1839 type uint8; 1840 description 1841 "Statistics, largest TX queue len registered in the window."; 1842 } 1844 leaf AvgLenTXQueue { 1845 type uint8; 1846 description 1847 "Statistics, avg TX queue len registered in the window."; 1848 } 1850 leaf MinLenRXQueue { 1851 type uint8; 1852 description 1853 "Statistics, lowest RX queue len registered in the window."; 1854 } 1856 leaf MaxLenRXQueue { 1857 type uint8; 1858 description 1859 "Statistics, largest RX queue len registered in the window."; 1860 } 1862 leaf AvgLenRXQueue { 1863 type uint8; 1864 description 1865 "Statistics, avg RX queue len 1866 registered in the window."; 1867 } 1869 leaf MinRetransmissions { 1870 type uint8; 1871 description 1872 "Statistics, lowest number of 1873 retransmissions registered in the window."; 1874 } 1876 leaf MaxRetransmissions { 1877 type uint8; 1878 description 1879 "Statistics, largest number of retransmissions registered 1880 in the window."; 1881 } 1883 leaf AvgRetransmissions { 1884 type uint8; 1885 description 1886 "Statistics, average number of retransmissions registered 1887 in the window."; 1888 } 1890 leaf MinPacketAge { 1891 type uint16; 1892 description 1893 "Statistics, in seconds, minimum time a packet stayed in 1894 the queue during the observed window."; 1895 } 1897 leaf MaxPacketAge { 1898 type uint16; 1899 description 1900 "Statistics, in seconds, maximum time a packet stayed 1901 in the queue during the observed window."; 1902 } 1904 leaf AvgPacketAge { 1905 type uint16; 1906 description 1907 "Statistics, in seconds, average time a packet stayed in 1908 the queue during the observed window."; 1909 } 1911 leaf MinBackoff { 1912 type uint8; 1913 description 1914 "Statistics, in number of slotframes, minimum Backoff 1915 for a packet in the queue during the observed window."; 1916 } 1918 leaf MaxBackoff { 1919 type uint8; 1920 description 1921 "Statistics, in number of slotframes, maximum Backoff 1922 for a packet in the queue during the observed window."; 1923 } 1925 leaf AvgBackoff { 1926 type uint8; 1927 description 1928 "Statistics, in number of slotframes, average Backoff 1929 for a packet in the queue during the observed window."; 1930 } 1931 } 1933 list LabelSwitchList { 1934 key "LabelSwitchID"; 1936 leaf LabelSwitchID { 1937 type uint16; 1938 } 1940 list InputCellIds { 1941 key "CellID"; 1942 leaf CellID{ 1943 type uint16; 1944 description 1945 "the CellID."; 1946 } 1947 } 1949 list OutputCellIds { 1950 key "CellID"; 1951 leaf CellID{ 1952 type uint16; 1953 description 1954 "the CellID."; 1955 } 1956 } 1958 leaf LoadBalancingPolicy { 1959 type enumeration { 1960 enum ROUNDROBIN; 1961 enum OTHER; 1962 } 1963 description 1964 "The Load Balancing policy."; 1965 } 1966 } 1968 list BundleList { 1969 key "BundleID"; 1971 leaf BundleID { 1972 type uint8; 1973 } 1974 leaf TargetNodeAddress { 1975 type uint64; 1976 description 1977 "The destination address for this bundle."; 1978 } 1980 leaf TrackID{ 1981 type uint16; 1982 description 1983 "the track which the bundle is associted"; 1984 } 1986 list CellIds { 1987 key "CellID"; 1988 leaf CellID{ 1989 type uint16; 1990 description 1991 "the CellID."; 1992 } 1993 } 1995 leaf NumOfStatistics { 1996 type uint8; 1997 description 1998 "The number of statistics being monitored in the bundle."; 1999 } 2001 list Statistics { 2002 key "StatisticsMatriceId"; 2004 leaf StatisticsMatriceId{ 2005 type uint16; 2006 description 2007 "the Statistics List ID."; 2008 } 2010 leaf StatisticsValue{ 2011 type uint16; 2012 description 2013 "Their meaning depends on the value of Metrics 2014 indexed by StatisticsMatriceId."; 2015 } 2016 } 2017 } 2019 list TrackList { 2020 key "TrackId"; 2022 leaf TrackId { 2023 type uint16; 2024 } 2025 leaf TrackOwnerAddr { 2026 type uint64; 2027 description 2028 "the address of the node which initializes the process of creating 2029 the track, i.e., the owner of the track;"; 2030 } 2031 leaf InstanceID { 2032 type uint16; 2033 description 2034 "InstanceID is an instance identifier given by the owner of the 2035 track. InstanceID comes from upper layer; InstanceID could for 2036 example be the local instance ID defined in RPL."; 2037 } 2038 } 2039 } 2040 list ChunkList { 2041 key "ChunkId"; 2043 leaf ChunkId{ 2044 type uint16; 2045 description 2046 "the id of a Chunk"; 2047 } 2049 leaf SlotframeId{ 2050 type uint8; 2051 description 2052 "the id of the slotframe that is mapped to this chunk"; 2053 } 2055 list ChunkCells { 2056 key "SlotOffset ChannelOffset"; 2058 leaf SlotOffset{ 2059 type uint16; 2060 description 2061 "the slotoffset."; 2062 } 2064 leaf ChannelOffset{ 2065 type uint16; 2066 description 2067 "the channeloffset."; 2068 } 2070 leaf CellID{ 2071 type uint16; 2072 description 2073 "initial value of CellID is FFFF. When the cell is 2074 appropriated, the value of CellID is same as that in 2075 CellList"; 2076 } 2078 leaf ChunkCellStatus { 2079 type enumeration { 2080 enum UNAPPROPRIATED; 2081 enum APPROPRIATED; 2082 } 2083 } 2084 } 2085 } 2087 4.2. YANG model of IEEE802.15.4 PIB 2089 This section describes the YANG model of the part of [IEEE802154] PIB 2090 used in 6top, such as security related attributes. This part of data 2091 will be accessed by using primitives like MLME-GET and MLME-SET 2092 ([IEEE802154]). 2094 TODO 2096 4.3. YANG model of IEEE802.15.4e PIB 2098 This section describes the YANG model of the part of [IEEE802154e] 2099 PIB used in 6top, such as TSCH related attributes. This part of data 2100 will be accessed by using primitives like MLME-GET and MLME-SET 2101 ([IEEE802154]). 2103 TODO 2105 5. Using 6top 2107 This part describes how 6top gives support to specific upper layers. 2109 5.1. RPL on 6top 2111 6top provides a set of functionalities so higher layers can obtain 2112 information about the status of the network and take advantage of the 2113 slotted structure to improve metric calculation and objective 2114 function optimization. The following sections describe how RPL can 2115 make use of 6top sublayer. 2117 In order to optimize the combination of RPL and TSCH, 6top provides 2118 specific support to RPL in the following aspects: 2120 RPL Neighbor Discovery and Parent Selection 2122 RPL Rank Computation 2124 RPL Control Messages Broadcast 2126 QoS 2128 5.1.1. Support to Neighbor Discovery and Parent Selection 2130 The Section 3.3.7 defines a set of commands so the neighbor table can 2131 be managed and queried by RPL. An entry to the neighbor table is 2132 inserted whenever an EBs is received at L2. The EB causes the 6top 2133 sublayer to create an entry to the neighbors table. A neighbor table 2134 entry contains a set of statistics with respect to that specific 2135 neighbor such as the ASN when the last packet has been received from 2136 that neighbor, a set of cell quality metrics (RSSI, LQI), number of 2137 packets sent to it or number of packets received from it amongst 2138 others. 6top updates that table upon sending or reception of a packet 2139 from/to a neighbor. RPL can query at any time the neighbor table to 2140 retrieve information about a particular neighbor. This information 2141 can be used to compute the routing objective function as for example 2142 the Zero Objective function as described in 2143 [I-D.vilajosana-6tisch-minimal]. Parent selection can also be driven 2144 by the information contained on the neighbor table as well as 2145 complemented with the cells statistics defined in Section 3.3.4. 2147 6top enables RPL to configure EB periodicity. By controlling the EBs 2148 periodicity, RPL can configure how network dynamism and support to 2149 mobility are addressed, as more frequent beacons the more prone to 2150 cope with mobility. Section 3.3.5 enables to configure how the 2151 network is formed and EBs periodicity. 2153 RPL MAY want to select the policy to determine the time source 2154 neighbor, this can be interesting when time source neighbors can be 2155 aligned to the routing topology, i.e., the selected time source 2156 neighbor can be the node's favorite parent in a specific DODAG. 2157 Section 3.3.6 describes the 6top command to set up the desired 2158 policy. The policy is selected by RPL and enforced by the 6top 2159 sublayer. 2161 The rule for 6top to select and maintain time source neighbors is as 2162 follows: 2164 The time source neighbor of a node SHOULD be a member of the 2165 node's neighbor set. 2167 Time source neighbors SHOULD be the neighbors which have a 2168 relatively lower join priority in the neighbor set. A lower 2169 join priority indicates that the neighbor is closer to the TSCH 2170 PAN coordinator. 2172 The link between a node and one of its time source neighbors 2173 SHOULD be a good link quality. 2175 5.1.2. Support of Rank Computation 2177 The RPL objective function is computed using a set of metrics. The 2178 [I-D.vilajosana-6tisch-minimal] defines how Zero Objective Function 2179 is used to configure the rank and metrics used from 6top statistics. 2180 The specific metrics, and how the objective function is calculated 2181 are out of scope. However, 6top builds a set of functionalities to 2182 provide more accurate statistics of the underlying layer so the 2183 objective function can be accommodated to the nature of a TSCH MAC 2184 layer. 2186 6top provides statistics for rank computation as described in 2187 Section 3.3.4. The function used to compute the rank based on those 2188 statistics is out of scope. However, the provided metrics are 2189 aligned to the behavior of the TSCH MAC layer. 2191 5.1.3. Support of Control Messages Broadcast 2193 In RPL, some control messages, e.g., DIO in storing mode, need to be 2194 broadcast to all neighbor nodes. The broadcast channel requirement 2195 has to be addressed by 6top by configuring TSCH to provide such a 2196 channel. 2198 In order to decouple the upper (RPL) layer from TSCH, instead of 2199 carrying DIO messages in Enhance Beacons, 6top introduces a mechanism 2200 to establish broadcast cells. 2202 In TSCH schedule, every cell has the LinkType attribute. If 2203 LinkType=ADVERTISING, indicates that the cell MAY be used to send an 2204 Enhanced Beacon. When a node forms its Enhanced Beacon, the cell, 2205 with LinkType=ADVERTISING, SHOULD be included in the FrameAndLinkIE, 2206 and its LinkOption field SHOULD be set to the combination of 2207 "Receive" and "Timekeeping". The receiver of the Enhanced Beacon MAY 2208 be listening at the cell to get the Enhanced Beacon ([IEEE802154e]). 2209 6top takes this way to establish broadcast channel, which not only 2210 allows TSCH broadcast Enhanced Beacon, but also allows an upper layer 2211 like RPL broadcast. 2213 To support DIO and DAO broadcasts, 6top uses the payload of a Data 2214 Packet to carry the DIO or DAO. The message is inserted into the 2215 queue associated with the cells which LinkType is set to ADVERTISING. 2216 Then, taking advantage of the broadcast cell feature established with 2217 FrameAndLinkIE as described above, the data packet with DIO or DAO in 2218 the payload can be received by neighbors, which enforces to the 2219 maintenance of DODAG. 2221 A LinkOption combining "Receive" and "Timekeeping" bits indicates to 2222 the receivers of the Enhanced Beacon that the cell MUST be used as a 2223 broadcast cell. The frequency of sending Enhance Beacon or other 2224 broadcast messages by upper layer is determined by the timers 2225 associated with the messages. For example, the transmission of 2226 Enhance Beacons is triggered by a timer in 6top; transmission of a 2227 DIO message is triggered by the trickle timer of RPL. 2229 5.1.4. Support for QoS 2231 The TSCH MAC layer is decoupled from the upper layer, and the 2232 interaction between the upper layer ad TSCH is asynchronous. This 2233 means that the MAC layer executes a schedule and checks at each 2234 timeslot according to the type of cell whether there is something to 2235 send or receive. If that is the case the packet is transmitted and 2236 the MAC layer continues its operation. When an upper layer sends a 2237 packet, this packet is pushed into a queue waiting to the MAC layer 2238 to read it and send it in a particular timeslot according to is 2239 destination and priority (Section 3.2). 6top provides a set of queue 2240 management operations which enable upper layers to create different 2241 queues and determine their priorities. This allows different classes 2242 of traffic to be handled by the routing layer, i.e. inserting a 2243 packet to a specific queue according to its priority. 2245 A 6top implement MUST provide at least a Broadcast Queue, a Transmit 2246 Queue, and a Receive Queue. RPL can configure the queues with 2247 Internal Queueing Command (Section 3.3.8.1). The Broadcast Queue is 2248 associated with cells with LinkType=ADVERTISING in sender's schedule, 2249 and LinkOption="Receive" and "Timekeeping" in all neighbors' 2250 schedule. This indicates that the cells can be used as broadcast 2251 cells from the sender to its neighbors. A Transmit Queue is 2252 associated with the dedicated Transmit cells or Shared Cells. RPL 2253 can benefit from having different priority queues to improve latency 2254 or provide integrated services with different priorities, i.e. 2255 different traffic classes. 2257 Data Communication Commands (Section 3.3.9) can be used to send 2258 control messages and data messages. The operation is used to insert 2259 a message to an specific queue. 2261 For example a suitable configuration can include two Broadcast Queues 2262 with priority High and Low, respectively; three Transmit Queues, with 2263 priority High, Mid, and Low, respectively; and one Receive Queue. 2265 When DestAddr is a broadcast address, its related MAC layer packets 2266 will be pushed into the Broadcast Queue with the corresponding 2267 priority. 6top is responsible for feeding these packets to TSCH at 2268 broadcast cells. 2270 When DestAddr is unicast address, its related MAC layer packets will 2271 be push into the Transmit Queue with corresponding priority. 6top is 2272 responsible for feeding these packets to TSCH at Transmit cells or 2273 Shared Cells. 2275 6top conducts a QoS policy, which is out of scope. Here is an 2276 example. Packets in higher priority queue MUST be sent out before 2277 the packets in lower priority queue. Then, when there is an 2278 available broadcast/unicast cell, 6top checks the broadcast/unicast 2279 queue with higher priority first, if there is a packet, then feeds it 2280 to TSCH at the cell, otherwise it checks broadcast/unicast queue with 2281 lower priority further. 6top repeats the process, until it finds a 2282 broadcast/unicast packet to feed to TSCH or finds that all of 2283 broadcast/unicast queues are empty. 2285 5.2. GMPLS on 6top 2287 GMPLS is a 2.5 layer service that is used to forward packets based on 2288 the concept of generalized labels. Labels are determined by a 2289 reservation protocol during the formation of a multi-hop path. As 2290 defined by [RFC3471], [RFC3473] and [RFC4606] a generalized label 2291 identifies a flow of data through a set of nodes that conform to a 2292 multi-hop path. Instead of being written implicitly into a field in 2293 each packet, as is the case in MPLS [RFC3031], the generalized label 2294 is kept at each node in the form of a table. The table can be used 2295 to map input cells to output cells so routing decisions can be taken 2296 at that layer. 2298 In order to optimize the combination of GMPLS and TSCH, 6top provides 2299 specific support to GMPLS in the following aspects: 2301 Cell Reservation Support 2303 QoS 2305 5.2.1. Cell Reservation Support for GMPLS on 6top 2307 The GMPLS control plane is used to send path reservation requests and 2308 reservation confirmations. When reservation confirmations are 2309 received, GMPLS needs to configure the underlying MAC layer to 2310 provide the required bandwidth. 6top provides a set of commands to 2311 deal with bandwidth allocation, i.e., cell allocation. Section 3.3.1 2312 describes the operations that GMPLS layer MAY use for cell 2313 configuration. Note that 6top supports different types of 2314 reservations: soft cell and hard cell. How the reservation 2315 requirements are expressed is out of scope, but 6top is able to 2316 handle a reservation done as a specific bandwidth requirement, done 2317 through specifying exact cells. 2319 The [I-D.vilajosana-6tisch-minimal] defines a pre-configured schedule 2320 that can be used to bootstrap the network. Those cells can be seen 2321 as a GMPLS control plane where RPL routes can be formed and Track 2322 reservations issued. 2324 GMPLS can also give different priorities to its control plane and 2325 data plane. It can for example be interesting to have a higher 2326 priority for control messages so the network adapts to new bandwidth 2327 requirements quickly. In contrast, data plane messages can be given 2328 a higher priority when they need to meet higher throughput or lower 2329 latency. 6top provides commands (Section 3.3.8) to manage MAC layer 2330 queues and assign different priorities to them. 2332 5.2.2. Supporting QoS 2334 GMPLS can use 6top statistics to determine whether some QoS 2335 requirement is met. Operations defined in Section 3.3.4 can be used 2336 by GMPLS to trigger new bandwidth allocation, or to map different 2337 input bundles to output bundles. 2339 6. References 2341 6.1. Normative References 2343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2344 Requirement Levels", BCP 14, RFC 2119, March 1997. 2346 6.2. Informative References 2348 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2349 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2350 Functional Specification", RFC 2205, September 1997. 2352 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2353 Networks", RFC 2464, December 1998. 2355 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2356 Label Switching Architecture", RFC 3031, January 2001. 2358 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2359 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2361 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 2362 (GMPLS) Signaling Functional Description", RFC 3471, 2363 January 2003. 2365 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2366 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2367 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2369 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2370 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2371 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2372 RFC 3819, July 2004. 2374 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 2375 Protocol Label Switching (GMPLS) Extensions for 2376 Synchronous Optical Network (SONET) and Synchronous 2377 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 2379 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2380 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2381 Overview, Assumptions, Problem Statement, and Goals", RFC 2382 4919, August 2007. 2384 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2385 "Transmission of IPv6 Packets over IEEE 802.15.4 2386 Networks", RFC 4944, September 2007. 2388 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 2389 "Routing Requirements for Urban Low-Power and Lossy 2390 Networks", RFC 5548, May 2009. 2392 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 2393 Routing Requirements in Low-Power and Lossy Networks", RFC 2394 5826, April 2010. 2396 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 2397 "Building Automation Routing Requirements in Low-Power and 2398 Lossy Networks", RFC 5867, June 2010. 2400 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 2401 "Industrial Routing Requirements in Low-Power and Lossy 2402 Networks", RFC 5673, October 2009. 2404 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 2405 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2406 September 2011. 2408 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 2409 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 2410 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 2411 Lossy Networks", RFC 6550, March 2012. 2413 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 2414 Application Spaces for IPv6 over Low-Power Wireless 2415 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 2417 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 2418 Statement and Requirements for IPv6 over Low-Power 2419 Wireless Personal Area Network (6LoWPAN) Routing", RFC 2420 6606, May 2012. 2422 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 2423 for OAuth", RFC 6755, October 2012. 2425 [I-D.watteyne-6tsch-tsch-lln-context] 2426 Watteyne, T., Palattella, M., and L. Grieco, "Using 2427 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 2428 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 2429 context-02 (work in progress), May 2013. 2431 [I-D.thubert-6tisch-architecture] 2432 Thubert, P., Watteyne, T., and R. Assimiti, "An 2433 Architecture for IPv6 over the TSCH mode of IEEE 2434 802.15.4e", draft-thubert-6tisch-architecture-01 (work in 2435 progress), October 2013. 2437 [I-D.palattella-6tisch-terminology] 2438 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 2439 "Terminology in IPv6 over the TSCH mode of IEEE 2440 802.15.4e", draft-palattella-6tisch-terminology-00 (work 2441 in progress), October 2013. 2443 [I-D.vilajosana-6tisch-minimal] 2444 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 2445 Configuration", draft-vilajosana-6tisch-minimal-00 (work 2446 in progress), October 2013. 2448 [I-D.ohba-6tsch-security] 2449 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 2450 A. Yegin, "Security Framework and Key Management Protocol 2451 Requirements for 6TSCH", draft-ohba-6tsch-security-01 2452 (work in progress), July 2013. 2454 [I-D.thubert-roll-forwarding-frags] 2455 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 2456 Recovery", draft-thubert-roll-forwarding-frags-02 (work in 2457 progress), September 2013. 2459 [I-D.tsao-roll-security-framework] 2460 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 2461 Security Framework for Routing over Low Power and Lossy 2462 Networks", draft-tsao-roll-security-framework-02 (work in 2463 progress), March 2010. 2465 [I-D.thubert-roll-asymlink] 2466 Thubert, P., "RPL adaptation for asymmetrical links", 2467 draft-thubert-roll-asymlink-02 (work in progress), 2468 December 2011. 2470 [I-D.ietf-roll-terminology] 2471 Vasseur, J., "Terms used in Routing for Low power And 2472 Lossy Networks", draft-ietf-roll-terminology-13 (work in 2473 progress), October 2013. 2475 [I-D.ietf-roll-p2p-rpl] 2476 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 2477 Martocci, "Reactive Discovery of Point-to-Point Routes in 2478 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17 2479 (work in progress), March 2013. 2481 [I-D.ietf-roll-trickle-mcast] 2482 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 2483 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 2484 mcast-05 (work in progress), August 2013. 2486 [I-D.thubert-6lowpan-backbone-router] 2487 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 2488 6lowpan-backbone-router-03 (work in progress), February 2489 2013. 2491 [I-D.sarikaya-core-sbootstrapping] 2492 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 2493 Cragie, "Security Bootstrapping Solution for Resource- 2494 Constrained Devices", draft-sarikaya-core- 2495 sbootstrapping-04 (work in progress), April 2012. 2497 [I-D.gilger-smart-object-security-workshop] 2498 Gilger, J. and H. Tschofenig, "Report from the 'Smart 2499 Object Security Workshop', 23rd March 2012, Paris, 2500 France", draft-gilger-smart-object-security-workshop-00 2501 (work in progress), October 2012. 2503 [I-D.phinney-roll-rpl-industrial-applicability] 2504 Phinney, T., Thubert, P., and R. Assimiti, "RPL 2505 applicability in industrial networks", draft-phinney-roll- 2506 rpl-industrial-applicability-02 (work in progress), 2507 February 2013. 2509 [I-D.ietf-core-coap] 2510 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 2511 Application Protocol (CoAP)", draft-ietf-core-coap-18 2512 (work in progress), June 2013. 2514 6.3. External Informative References 2516 [IEEE802154e] 2517 IEEE standard for Information Technology, "IEEE std. 2518 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2519 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2520 2012. 2522 [IEEE802154] 2523 IEEE standard for Information Technology, "IEEE std. 2524 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2525 and Physical Layer (PHY) Specifications for Low-Rate 2526 Wireless Personal Area Networks", June 2011. 2528 [OpenWSN] "Berkeley's OpenWSN Project Homepage", 2529 . 2531 [label-switching-154e] 2532 Morell, A., Vilajosana, X., Lopez-Vicario, J., and T. 2533 Watteyne, "Label Switching over IEEE802.15.4e Networks. 2534 Transactions on Emerging Telecommunications Technologies", 2535 June 2013. 2537 Authors' Addresses 2539 Qin Wang (editor) 2540 Univ. of Sci. and Tech. Beijing 2541 30 Xueyuan Road 2542 Beijing, Hebei 100083 2543 China 2545 Phone: +86 (10) 6233 4781 2546 Email: wangqin@ies.ustb.edu.cn 2548 Xavier Vilajosana 2549 Universitat Oberta de Catalunya 2550 156 Rambla Poblenou 2551 Barcelona, Catalonia 08018 2552 Spain 2554 Phone: +34 (646) 633 681 2555 Email: xvilajosana@uoc.edu 2556 Thomas Watteyne 2557 Linear Technology 2558 30695 Huntwood Avenue 2559 Hayward, CA 94544 2560 USA 2562 Phone: +1 (510) 400-2978 2563 Email: twatteyne@linear.com