idnits 2.17.1 draft-wang-6tsch-6tus-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([IEEE802154e]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 11, 2013) is 4063 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 2381, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 2387, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 2393, but not defined == Unused Reference: 'RFC2119' is defined on line 2219, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 2224, but no explicit reference was found in the text == Unused Reference: 'RFC2464' is defined on line 2228, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 2234, but no explicit reference was found in the text == Unused Reference: 'RFC3819' is defined on line 2245, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 2255, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 2260, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 2264, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 2268, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 2272, but no explicit reference was found in the text == Unused Reference: 'RFC5673' is defined on line 2276, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 2280, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 2284, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 2289, but no explicit reference was found in the text == Unused Reference: 'RFC6606' is defined on line 2293, but no explicit reference was found in the text == Unused Reference: 'RFC6755' is defined on line 2298, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 2301, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 2306, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 2312, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 2317, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 2322, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 2328, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 2333, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 2338, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 2344, but no explicit reference was found in the text == Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is defined on line 2350, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap' is defined on line 2356, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-palattella-6tsch-terminology' is defined on line 2367, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-02) exists of draft-thubert-roll-forwarding-frags-01 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-11 == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-16 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-04 == Outdated reference: A later version (-05) exists of draft-sarikaya-core-sbootstrapping-04 == Outdated reference: A later version (-03) exists of draft-gilger-smart-object-security-workshop-00 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-13 == Outdated reference: A later version (-02) exists of draft-watteyne-6tsch-tsch-lln-context-01 == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 == Outdated reference: A later version (-02) exists of draft-thubert-6tsch-architecture-00 Summary: 3 errors (**), 0 flaws (~~), 43 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: September 12, 2013 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 March 11, 2013 10 6tus Adaptation Layer Specification 11 draft-wang-6tsch-6tus-00 13 Abstract 15 The recently published [IEEE802154e] standard formalizes the concept 16 of link-layer resources in LLNs. Nodes are synchronized and follow a 17 schedule. A time slot in that schedule corresponds to an atomic 18 link-layer resource, and can be allocated to any pair of neighbors in 19 the network. This allows the schedule to be built to tightly match 20 each node's bandwidth, latency and energy constraints, while ensuring 21 collision-free communication. The [IEEE802154e] standard does not, 22 however, present a mechanism to do so, as building and managing the 23 schedule is out of the standard's scope. Routing layers such as the 24 IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to 25 route multipoint-to-point traffic (from devices inside the LLN 26 towards a central control point) and point-to-multipoint traffic 27 (from the central control point to the devices inside the LLN). 28 Network layer overlays cannot be optimized and adapted to take 29 advantage of the link-based topology created by the underlying TSCH 30 MAC layer as a missing set of functionalities need to be defined. 31 This document describes the 6tus adaptation layer and the main 32 commands it provides to upper network layers such as RPL or GMPLS. 33 The set of functionalities includes feedback metrics from link states 34 so network layers can take routing decisions, TSCH configuration and 35 control procedures, and the support for centralized and decentralized 36 scheduling policies. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 12, 2013. 55 Copyright Notice 57 Copyright (c) 2013 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. 6tus Adaptation Layer Specification . . . . . . . . . . . . . 4 74 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.2.1. Hard Links . . . . . . . . . . . . . . . . . . . . . 6 77 2.2.2. Soft Links . . . . . . . . . . . . . . . . . . . . . 6 78 2.3. Data Convey Model . . . . . . . . . . . . . . . . . . . . 7 79 2.4. Commands . . . . . . . . . . . . . . . . . . . . . . . . 8 80 2.4.1. Link Commands . . . . . . . . . . . . . . . . . . . . 8 81 2.4.2. Slotframe Commands . . . . . . . . . . . . . . . . . 13 82 2.4.3. Monitoring Commands . . . . . . . . . . . . . . . . . 14 83 2.4.4. Statistics Commands . . . . . . . . . . . . . . . . . 16 84 2.4.5. Network Formation Commands . . . . . . . . . . . . . 18 85 2.4.6. Time Source Neighbor Commands . . . . . . . . . . . . 20 86 2.4.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 21 87 2.4.8. Queueing Commands . . . . . . . . . . . . . . . . . . 23 88 2.4.9. Security Commands . . . . . . . . . . . . . . . . . . 26 89 2.4.10. Data Commands . . . . . . . . . . . . . . . . . . . . 27 90 2.5. Message Formats . . . . . . . . . . . . . . . . . . . . . 29 91 2.5.1. Information Elements . . . . . . . . . . . . . . . . 29 92 2.5.2. Packet Formats . . . . . . . . . . . . . . . . . . . 37 93 2.6. Time Sequence . . . . . . . . . . . . . . . . . . . . . . 40 94 2.6.1. Network Formation . . . . . . . . . . . . . . . . . . 40 95 2.6.2. Creating a Soft Link . . . . . . . . . . . . . . . . 41 96 2.6.3. Deleting a Soft Link . . . . . . . . . . . . . . . . 42 97 2.6.4. Maintaining Soft Links . . . . . . . . . . . . . . . 42 98 2.7. Statistics . . . . . . . . . . . . . . . . . . . . . . . 43 99 2.7.1. Statistics Metrics . . . . . . . . . . . . . . . . . 43 100 2.7.2. Statistics Configuration . . . . . . . . . . . . . . 44 101 2.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 44 102 2.8.1. Monitor Configuration . . . . . . . . . . . . . . . . 44 103 2.8.2. Actuation . . . . . . . . . . . . . . . . . . . . . . 44 104 3. Using 6tus . . . . . . . . . . . . . . . . . . . . . . . . . 45 105 3.1. RPL on 6tus . . . . . . . . . . . . . . . . . . . . . . . 45 106 3.1.1. Support to Neighbor Discovery and Parent Selection . 45 107 3.1.2. Support to Rank Computation . . . . . . . . . . . . . 46 108 3.1.3. Support to Control Messages Broadcast . . . . . . . . 46 109 3.1.4. Support to QoS . . . . . . . . . . . . . . . . . . . 47 110 3.2. GMPLS on 6tus . . . . . . . . . . . . . . . . . . . . . . 48 111 3.2.1. Link Reservation Support for GMPLS on 6tus . . . . . 49 112 3.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 49 113 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 114 4.1. Normative References . . . . . . . . . . . . . . . . . . 50 115 4.2. Informative References . . . . . . . . . . . . . . . . . 50 116 4.3. External Informative References . . . . . . . . . . . . . 53 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 119 1. Introduction 121 As presented in [I-D.watteyne-6tsch-tsch-lln-context], the 122 [IEEE802154e] standard defines the mechanisms for a TSCH node to 123 communicate given a schedule. It does not, however, define the 124 policies to build and maintain the TSCH schedule, match that schedule 125 to the multi-hop paths maintained by a network layer such as RPL or a 126 2.5 layer such as GMPLS, adapt the resources allocated between 127 neighbor nodes to the data traffic flows, enforce a differentiated 128 treatment for data generated at the application layer and signaling 129 messages needed by 6LoWPAN and RPL to discover neighbors, react to 130 topology changes, self-configure IP addresses, or manage keying 131 material. 133 In a TSCH network, the MAC layer is not in charge of setting up the 134 schedule that controls the connectivity graph of the network and the 135 resources allocated to each link in that topology. This 136 responsibility is left to an upper layer, defined in this document 137 and called "6tus" (pronounced "sixtus"). 139 This document describes the 6tus adaptation layer and the main 140 commands provided to upper network layers such as RPL or GMPLS. The 141 set of functionalities include feedback metrics from link state so 142 the network layer can take routing decisions, TSCH configuration and 143 control procedures and support centralized and decentralized 144 scheduling policies. The 6tus layer addresses the set of 145 functionalities described in [I-D.watteyne-6tsch-tsch-lln-context]. 147 For example, network formation in a TSCH network is handled by the 148 use of Enhanced Beacons (EB). EBs include information for joining 149 nodes to be able to synchronize and set up an initial network 150 topology, however [IEEE802154e] does not specify how the period of 151 EBs is configured, nor the rules for a node to select a particular 152 node to join. The 6tus layer offers a set of commands so control 153 mechanisms can be introduced on top of TSCH so nodes configure to 154 join a specific node and obtain an unique 16-bit identifier from the 155 network. Once a network is formed, 6tus maintains the network's 156 health, allowing for nodes to stay synchronized. It supplies 157 mechanisms to manage each node's time source neighbor and configure 158 the EB interval. Network layers running on top of 6tus take 159 advantage of the TSCH MAC layer information so routing metrics, 160 topological information, energy consumption and latency requirements 161 can be adjusted to TSCH and adapted to application requirements. 163 TSCH requires a mechanism to manage its schedule; 6tus provides a set 164 of commands for upper layers to set up specific schedules, either 165 explicitly by detailing specific link information, or by allowing 166 6tus to establish a schedule given a bandwidth or latency 167 requirement. 6tus is designed to enable centralized, decentralized 168 or hybrid scheduling entities. 6tus enables internal TSCH queuing 169 configuration, size of buffers, packet priorities, and transmission 170 failure behavior, and defines mechanisms to encrypt and authenticate 171 MAC slotframes. 173 2. 6tus Adaptation Layer Specification 175 2.1. Overview 177 6tus is an adaptation layer which is the next-higher layer for TSCH, 178 as detailed in [I-D.draft-thubert-6tsch-architecture]. 6tus offers 179 both management and data interfaces to an upper layer. It includes 180 monitoring and statistics collection, both of which are configurable 181 through the management interface. 183 6tus distinguishes between hard links and soft links. It therefore 184 requires an extra flag to all links in the TSCH schedule, as detailed 185 in Section 2.2. 187 When a higher layer gives 6tus a 6LoWPAN packet for transmission, 188 6tus maps it to the appropriate outgoing priority-based queue, as 189 detailed in Section 2.3. 191 All commands of the management and data interfaces are detailed in 192 Section 2.4. This set of commands is designed to support 193 centralized, decentralized and hybrid scheduling entities. 195 6tus defines TSCH Information Elements (IEs) for neighbors nodes to 196 negociate scheduling links in the TSCH schedule. The format of those 197 is given in Section 2.5. 199 Example data exchanges between neighbor nodes are illustrated in 200 Section 2.6. 202 Section 2.7 defines how 6tus gathers statistics (e.g. link quality, 203 energy level, queue usage), and what commands an upper layer can use 204 to configure and retrieve statistics. 206 6tus can be configured to monitor some links it has scheduled to 207 detect links with poor performance. It can then automatically move 208 those links inside the TSCH schedule. This behavior is described in 209 Section 2.8 211 2.2. Link Model 213 IEEE802.15.4e defines a set of options attached to each link. A link 214 can be a Transmit Link, a Receive Link, a Shared Link or a 215 Timekeeping Link. These options are not exclusive, as a link can be 216 qualified with more than one of them. The IEEE802.15.4e MLME-SET- 217 LINK.request command uses a linkOptions bitmap to specify the options 218 of a link. Acceptable values are: 220 b0 = Transmit 222 b1 = Receive 224 b2 = Shared 226 b3 = Timekeeping 228 b4-b7 = Reserved 230 Only Transmit links can also be marked as Shared links. When the 231 shared bit is set, and a back-off procedure is applied to handle 232 collisions. Shared behavior is not defined for Receive links. 234 6tus allows an upper layer to schedule a link at a specific timeslot 235 and channel offset in a specific slotframe. This translates directly 236 into the MLME-SET-LINK.request primitive described at 237 Section 6.2.19.3 of IEEE802.15.4e. In addition, 6tus allows an upper 238 layer to schedule a certain amount of bandwidth to a neighbor, 239 without having to specify the exact timeslot(s) and channel 240 offset(s). Instead, 6tus follows the reservation process described 241 in Section 2.6.2. Once bandwidth is reserved, 6tus is in charge of 242 ensuring that this requirement is continuously satisfied, as 243 described in Section 2.8. 6tus dynamically reallocates slots if 244 needed, and overprovisions if required. Given this mechanism, 6tus 245 defines hard links (which have been requested specifically) and soft 246 links (which that can be reallocated dynamically). The hard/soft 247 flag is introduced by the 6tus layer as an extension of the 248 IEEE802.15.4e Link Option flags. This option is mandatory; all links 249 are either hard or soft. 251 With the addition of the Hard/Soft flag, the resulting flags are: 253 b0 = Transmit 255 b1 = Receive 257 b2 = Shared 259 b3 = Timekeeping 261 b4 = Hard (1)/Soft (0) 263 b5-b7 = Reserved 265 2.2.1. Hard Links 267 A Hard Link is a link that cannot be dynamically reallocated by 6tus. 268 A Hard link is uniquely identified by the following tuple: 270 slotframe id: id of the slotframe this link is part of. 272 timeslot: the slot within the slotframe. 274 channel offset. 276 Link Option bitmap: bitmap as defined in Section 2.2, including 277 the hard/soft bit which must be set to 1. 279 2.2.2. Soft Links 281 A Soft Link is a link that can be reallocated by 6tus dynamically. 282 The hard/soft bit must be set to 0. This link is installed by 6tus 283 given a specific bandwidth requirement. Soft links are installed 284 through the soft link negotiation process described in Section 2.8. 286 2.3. Data Convey Model 288 Based on the established TSCH schedule, 6tus is responsible for 289 feeding the data flow from the upper layer into TSCH. This section 290 describes how 6tus shapes data from upper layer (e.g. RPL, 6LoWPAN), 291 and feeds it to TSCH. Since 6tus is a adaptation layer between TSCH 292 and 6LoWPAN, the properties assciated with a packet/fragment from the 293 upper layer includes the next hop neighbor (DestAddr) and expected 294 sending priority of the packet (Priority). The output to TSCH is the 295 fragment corresponding to the next active link in the TSCH schedule. 297 6tus Data Convey Model 299 | 300 | (DestAddr, Priority, Fragment) 301 | 302 +---------------------------------------+ 303 | I-MUX | 304 +---------------------------------------+ 305 | | | | .... | 306 | | | | | 307 +---+ +---+ +---+ +---+ +---+ 308 | | | | | | | | | | 309 |Q1 | |Q2 | |Q3 | |Q4 | |Qn | 310 | | | | | | | | | | 311 +---+ +---+ +---+ +---+ +---+ 312 | | | | | 313 | | | | | 314 +---------------------------------------+ 315 | MUX | 316 +---------------------------------------+ 317 | 318 | 319 +---+ 320 |PDU| 321 +---+ 322 | 323 | TSCH MAC-payload 324 | 326 Figure 1 328 In Figure 1, Qi represents a queue, which is either broadcast or 329 unicast, and is assigned a priority. The number of queues is 330 configurable. The relationship between queues and slotframes is 331 configurable. For example, for a given queue, only one specific 332 slotframe can be used, or all of the slotframes can be used, or a 333 subset of slotframes can be used. 335 When 6tus receives a packet to transmit through a Send.data command 336 (Section 2.4.10), the I-MUX module selects a queue in which to insert 337 it. If the packet's destination address is a unicast (resp. 338 broadcast) address, it will be inserted into a unicast (resp. 339 broadcast) queue. 341 The MUX module is invoked at each scheduled transmit link by TSCH. 342 When invoked, the MUX module goes through the queues, looking for the 343 best frame to send. If it finds a frame, it hands it over to TSCH 344 for transmission. If the next active link is a broadcast link, it 345 selects a fragment only from broadcast queues. 347 How the MUX module selects the best frame is configurable. 348 Typically, the following rules are used: 350 The frame's layer 2 destination address must match the neighbor 351 address associated with the transmit link. 353 Frames from a queue with a high priority must be sent before 354 frames from a queue with a low priority. 356 Further rules can be configured to satisfy specific QoS requirements. 358 2.4. Commands 360 6tus provides a set of commands a higher layer can call, including 361 management commands and data commands. Most of these commands are 362 related to the management of slotframes, time slots and scheduling 363 information. 6tus also provides an interface allowing an upper layer 364 to retrieve status information and statistics. This section lists 365 the commands offered by 6tus. 367 2.4.1. Link Commands 369 The following methods allow an upper layer to manage the network 370 schedule: 372 2.4.1.1. CREATE.hardlink 374 Creates one or more hard links in the schedule. Fails if the link 375 already exists. A link is uniquely identified by the tuple 376 (slotframe id, timeslot, channel offset). 378 To create a hard link, the upper layer specifies: 380 slotframe id: id of the slotframe this slot will be scheduled in. 382 time slot: the specific time slot number. 384 channel offset: the frequency offset. 386 Link Option bitmap: bitmap as defined in Section 2.2 388 target node address: the address of that node to communicate with 389 over this link. In case of broadcast links this is the broadcast 390 address. 392 6tus schedules the link and marks it as a hard link, indicating that 393 it cannot reschedule this link. 395 2.4.1.2. CREATE.softlink 397 To create a soft link, the upper layer specifies: 399 slotframe id: id of the slotframe this slot will be scheduled in 401 number of links: the required number of soft links. 403 Link Option bitmap: bitmap as defined in Section 2.2 405 target node address: the address of that node to communicate with 406 over this link. In case of broadcast links this is the broadcast 407 address. 409 QoS level: the link redundancy policy. The policy can be for 410 example STRICT, BEST_EFFORT, etc. 412 6tus is responsible for picking the exact timeslot and channel offset 413 in the schedule, and ensure that the target node chooses the same. 414 6tus marks these links as soft link, indicating that it will 415 continuously monitor their performance and reschedule if needed. 417 6tus deals with the allocation process by negotiation with the target 418 node. The negotiation process is described in Section 2.6.2. The 419 command returns the list of created links defined by (slotframe id, 420 time slot number, channel offset). It fails if the required number 421 of links is higher than the available number of links in the 422 schedule. It fails if the negotiation with the target node fails. 423 It fails if the Link Option bitmap indicates that the link MUST be 424 Hard. 426 2.4.1.3. READ.link 428 Given a (slotframe id, time slot number, channel offset), retrieves 429 the link information. Fails if the link does not exist. The 430 returned information contains: 432 slotframe id: the id of the slotframe where this link is 433 installed. 435 time slot: the time slot where the link is set. 437 channel offset: the selected channel offset for the link. 439 Link Option bitmap: bitmap as defined in Section 2.2 441 target node address: the target address of that link. In case of 442 broadcast links this is the broadcast address. 444 A read command can be issued for any link, hard or soft. 446 2.4.1.4. UPDATE.link 448 Update a hard link, i.e. move it to a different timeslot and/or 449 channel offset. Fails if the link does not exist. Requires a 450 (slotframe id, time slot, channel offset), type of link and target 451 node are the fields that can be updated. Soft links cannot be 452 updated by the UPDATE.link command. REALLOCATE.softlink 453 (Section 2.4.1.7) MUST be used instead. 455 2.4.1.5. DELETE.hardlink 457 To removes a hard link, the upper layer specifies: 459 slotframe id: the id of the slotframe where this link is 460 installed. 462 time slot: the time slot where the link is set. 464 channel offset: the selected channel offset for the link. 466 This removes the hard link from the node's schedule. 468 2.4.1.6. DELETE.softlink 470 To remove a (number of) soft link(s), the upper layer specifies: 472 slotframe id: the id of the slotframe where this link is 473 installed. 475 number of links: the number of links to be removed 477 Link Option bitmap: bitmap as defined in Section 2.2 478 target node address: the target address of that link. In case of 479 broadcast links this is the broadcast address. 481 In the case a soft link wants to be moved from the allocated slot so 482 a hard link can be installed instead, the REALLOCATE.softlink 483 (Section 2.4.1.7) MUST be used. 485 2.4.1.7. REALLOCATE.softlink 487 To force a move of a soft link, the upper layer specifies: 489 slotframe id: the id of the slotframe where the link is allocated. 491 time slot: the slot number where that link is installed. 493 channel offset: the channel offset for that link. 495 The reallocated link will be installed in a different slot, channel 496 offset but same slotframe. Hard links cannot be reallocated. 498 2.4.1.8. HardLink Command Behavior 500 The following table describe the behavior of 6tus upon reception of 501 the Hard Link management commands. 503 Hard Link Operations behavior 504 +---------------------------------+---------------------------------+ 505 | 6tus commands | 6tus behavior | 506 +---------------------------------+---------------------------------+ 507 | Create.hardlink | MLME-SET-LINK.request | 508 | (NeigAddr, SlotframeID, | (operation=ADD_LINK) | 509 | SlotOffset, | If NeigAddr ==Broadcast Address| 510 | ChannelOffset, LinkOption) | Then LinkType=ADVERTISING | 511 | | Add Link to EB's FrameAndLinkIE | 512 +---------------------------------+---------------------------------+ 513 | Read.Link | MLME-GET.request | 514 |(NeigAddr,SlotframeID,SlotOffset,| | 515 | ChannelOffset, LinkOption) | | 516 +---------------------------------+---------------------------------+ 517 | Delete.hardlink | MLME-SET-LINK.request | 518 | (NeigAddr ,SlotOffset, | (operation=DELETE_LINK) | 519 | ChannelOffset, LinkOption) | If LinkType=ADVERTISING, it is a| 520 | | broadcast link, Then Remove link| 521 | | from EB's FrameAndLinkIE of EB | 522 +---------------------------------+---------------------------------+ 523 | Update.Link | MLME-SET-LINK.request | 524 | (OldFrameID, OldSlotOffset, | (operation=DELETE_LINK) | 525 | OldChannelOffset, NewFrameID, | MLME-SET-LINK.request | 526 | NewSlotOffset,NewChannelOffset)| (operation=ADD_LINK, | 527 | | with same NeigAddr,LinkOption) | 528 | | If old Link is in EB | 529 | | Then modify EB | 530 +---------------------------------+---------------------------------+ 532 2.4.1.9. SoftLink Command Behavior 534 The following table describe the behavior of 6tus upon reception of 535 the SoftLink management commands. 537 Soft Link Operations behavior 538 +--------------------------------+----------------------------------+ 539 | 6tus commands | 6tus behavior | 540 +--------------------------------+----------------------------------+ 541 | Create.softlink | 6tus_ReserveLinkReq() ---- ACK | 542 |(NeigAddr, NumLink,LinkOption, | ACK --- 6tus_ReserveLinkResp()| 543 | SlotframeID, QoSLevel) | | 544 +--------------------------------+----------------------------------+ 545 | Read.Link | MLME-GET.request | 546 |(NeigAddr,SlotframeID, | | 547 | SlotOffset,ChannelOffset) | | 548 +--------------------------------+----------------------------------+ 549 | Delete.softlink | 6tus_RemoveLinkReq() --- ACK | 550 | (NeigAddr ,NumLink, | If LinkType =ADVERTISING | 551 | LinkOption, SlotframeID) | i.e. a broadcast link Then Remove| 552 | | link from EB's FrameAndLinkIE | 553 +--------------------------------+----------------------------------+ 554 | Reallocate.softLink | 6tus_RemoveLinkReq() --- ACK | 555 |(NeigAddr,SlotframeID, | 6tus_ReserveLinkReq() --- ACK | 556 | SlotOffset,ChannelOffset) | ACK --- 6tus_ReserveLinkResp() | 557 +--------------------------------+----------------------------------+ 559 2.4.2. Slotframe Commands 561 6tus provides the following commands to manage TSCH slotframes. 563 2.4.2.1. CREATE.slotframe 565 Creates a new slotframe. Returns the slotframe id that corresponds 566 to its priority (SlotFrameHandle). The command requires: 568 number of slots: the required number of slots. 570 Fails if the number of required slots is less than zero. 572 2.4.2.2. READ.slotframe 574 Returns the information of a slotframe given its slotframe id. The 575 command returns: 577 slotframe id: the id of the slotframe. (SlotFrameHandle) 579 number of slots: the number of slots. 581 Fails if the slotframe id does not exist. 583 2.4.2.3. UPDATE.slotframe 584 Change the number of slots in a slotframe. The command requires: 586 slotframe id: the id of the slotframe. 588 number of slots: the number of slots to be updated. 590 Fails if the number of required slots is less than zero. Fails if 591 the slotframe id does not exist. 593 2.4.2.4. DELETE.slotframe 595 Deletes a slotframe. The command requires: 597 slotframe id: the id of the slotframe. 599 Fails if the slotframe id does not exist. 601 2.4.2.5. Slotframe Command Behavior 603 The following table describes the behavior of 6tus upon reception of 604 the Slotframe management commands. 606 Slotframe Management Operations behavior 608 +--------------------------------+----------------------------------+ 609 | 6tus commands | 6tus behavior | 610 +--------------------------------+----------------------------------+ 611 | Create.slotframe(NumSlot) | MLME-SET-SLOTFRAME.request | 612 | |(operation=ADD) | 613 +--------------------------------+----------------------------------+ 614 | Read.slotframe(SlotframeID) | MLME-GET.request | 615 +--------------------------------+----------------------------------+ 616 | Delete.slotframe(SlotframeID) | MLME-SET-SLOTFRAME.request | 617 | |(operation=DELETE) | 618 +--------------------------------|----------------------------------+ 619 | Update.slotframe(SlotframeID | MLME-SET-SLOTFRAME.request | 620 | ,NumSlot) |(operation=MODIFY) | 621 +--------------------------------+----------------------------------+ 623 2.4.3. Monitoring Commands 625 Monitoring commands provide the means for upper layers to configure 626 whether 6tus must ensure the required bandwidth. This procedure is 627 achieved through over-provisioning according to link status feedback. 628 Monitoring is also in charge of reallocating soft links that are 629 under the required QoS. The mechanism is described in Section 2.8. 631 2.4.3.1. CONFIGURE.monitoring 633 Configures the level of QoS the Monitoring process must enforce. The 634 command requires: 636 slotframe id: the id of the slotframe. 638 target node: the destination node. 640 enforce policy: The policy used to enforce the QoS requirements. 641 Can be for example DISABLE, BEST_EFFORT, STRICT, OVER-PROVISION, 642 etc. 644 Fails if the slotframe id does not exist. 646 2.4.3.2. READ.monitoring.status 648 Reads the current Monitoring status. Requires the following 649 parameters. 651 slotframe id: the id of the slotframe. 653 target node: the destination node. 655 Returns the QoS levels for that Target node on that slotframe. 657 allocated_hard: Number of hard links allocated. 659 allocated_soft: Number of soft links allocated. 661 provisioned: the extra provisioned links. 0 if CONFIGURE.qos 662 enforce is DISABLE. 664 QoS: the current QoS. Including overprovisioned links, i.e what 665 bandwidth is being obtained including the overprovisioned links. 667 RQoS: the real QoS without provisioned links. What is the actual 668 bandwidth without taking into account the overprovisioned links. 670 Fails if the slotframe id does not exist. 672 2.4.3.3. Monitoring Command Behavior 674 The following table describes the behavior of 6tus upon reception of 675 the Monitoring management commands. 677 Monitoring Management Operations behavior 678 +------------------------------------+------------------------------+ 679 | 6tus commands | 6tus behavior | 680 +------------------------------------+------------------------------+ 681 | Configure.monitoring(NeigAdd, | Create/Update Monitoring MIB | 682 | SlotframeID,Enforce) | Starts monitoring service | 683 +------------------------------------+------------------------------+ 684 | Read.monitoring.status(SlotframeID)| Reads 6tus Monitoring MIB | 685 +------------------------------------+------------------------------+ 687 Figure 2 689 2.4.4. Statistics Commands 691 6tus keeps track of TSCH statistics for upper layers to adapt 692 correctly to medium changes. The exact metrics for statistics are 693 out of the scope of this document but the present commands should be 694 used to configure and read monitored information regardless of the 695 specific metric. 697 2.4.4.1. CONFIGURE.statistics 699 Configures Statistics process. The command requires: 701 slotframe id: the id of the slotframe. If empty monitors all 702 slotframe ids 704 time slot: slot number to be monitored. If empty all slots are 705 monitored 707 channel offset: specific channel offset to be monitored. If empty 708 all channels are monitored. 710 target node: the destination node. If empty, all target nodes are 711 monitored. 713 metric: metric to be monitored. This may be PDR, ETX, queuing 714 statistics, energy-related metrics, etc.) 716 window: time window to be considered for the calculations. If 0 717 all historical data is considered. 719 enable: Enables statistics or disables them. 721 Fails if the slotframe id does not exist. The statistics service can 722 be configured to retrieve statistics at different levels. For 723 example to aggregate information by slotframe id, or to retrieve 724 statistics for a particular slot, etc. the CONFIGURE.statistics 725 enables flexible configuration by supporting empty parameters that 726 will force the monitoring of the statistics by all members of that 727 dimension. 729 2.4.4.2. READ.statistics 731 Reads a metric for the specified dimension. Information is 732 aggregated according to the parameters. The command requires: 734 slotframe id: the id of the slotframe. If empty aggregates 735 information of all slotframe ids 737 time slot: the slot number for which the information is required. 738 If empty all slots are aggregated 740 channel offset: the specific channel offset for which the 741 information is required. If empty all channels are aggregated. 743 target node: the destination node. If empty all target nodes are 744 aggregated. 746 metric: metric to be read. 748 Returns the value for the requested metric. 750 Fails if empty metric or metric does not exits. 752 2.4.4.3. RESET.statistics 754 Resets the gathered statistics. The command requires: 756 slotframe id: the id of the slotframe. If empty resets the 757 information of all slotframe ids 759 time slot: the slot number for which the information wants to be 760 reset. If empty statistics from all slots are reset 762 channel offset: the specific channel offset for which the 763 information wants to be reset. If empty all statistics for all 764 channels are reset. 766 target node: the destination node. If empty all statistics for 767 the target node are reset. 769 metric: metric to be reset. 771 Fails if empty metric or metric does not exits. 773 2.4.4.4. Statistics Command Behavior 775 The following table describes the behavior of 6tus upon reception of 776 the Statistics management commands. 778 Statistics Management Operations behavior 780 +--------------------------------+----------------------------------+ 781 | 6tus commands | 6tus behavior | 782 +--------------------------------+----------------------------------+ 783 | Configure.statistics | | 784 | (SlotFrameID,TSlot, ChannelOff,| Configures Statistics MIB. | 785 | NeigAdd,Metric,Window,En) | Enables statistics service | 786 +--------------------------------+----------------------------------+ 787 | Read.statistics(SlotFrameID) | Returns the statistic MIB for the| 788 | Ch.Off,NeigAdd,Metric) | requested parameters | 789 +--------------------------------+----------------------------------+ 790 | Reset.statistics(SlotFrameID) | Resets the required statistic MIB| 791 | Ch.Off,NeigAdd,Metric) | | 792 +--------------------------------+----------------------------------+ 794 2.4.5. Network Formation Commands 796 EBs need to be configured, including their transmission period, the 797 slot number and channel offset that they should be sent on, and the 798 priority announced. The parameters for that command are optional and 799 enable a very flexible configuration of EBs. If slotframe id is 800 specified, the EBs will be configured to use that specific slotframe; 801 if not they will use the first slotframe where the configured time 802 slot is allocated. Time slot enforces the EB to a specific time 803 slot. In case time slot parameter is not present, the EB is sent in 804 the first available transmit time slot. In case channel offset 805 parameter is not set, the EB is configured to use the first available 806 channel. 808 2.4.5.1. CONFIGURE.eb 810 Configures EBs. The command requires: 812 slotframe id: the id of the slotframe where the EBs MUST be sent. 813 Zero if any slotframe can be used. 815 time slot: the slot number where the EBs MUST be sent. Zero if 816 any timeslot can be used. 818 channel offset: the channel offset where the EBs MUST be sent. 819 Zero if any channel offset can be used. 821 period: the EBs period, in seconds. 823 expires: when the EBs periodicity will stop. If Zero the period 824 never stops. 826 priority: the joining priority model that will be used for 827 advertisement. Joining priority MAY be for example 828 SAME_AS_PARENT, RANDOM, BEST_PARENT+1. 830 Fails if the tuple slotframe id, timeslot, channel offset is already 831 scheduled. 833 2.4.5.2. READ.eb 835 Reads the EBs configuration. No parameters are required. 837 Returns the current EBs configuraton for that slotframe, which 838 contains: 840 slotframe id: the slotframe where the EB is being sent. 842 time slot: the slot number where the EBs is being sent. 844 channel offset: the channel offset the EBs is being sent on. 846 period: the EBs period. 848 expires: when the EBs periodicity stops. If 0 the period never 849 stops. 851 priority: the joining priority that this node advertises. 853 Fails if the slotframe id does not exist. 855 2.4.5.3. Network Formation Command Behavior 857 The following table describes the behavior of 6tus upon reception of 858 the Network Configuration management commands. 860 Network Configuration Management Operations behavior 861 +----------------------------------+--------------------------------+ 862 | 6tus commands | 6tus behavior | 863 +----------------------------------+--------------------------------+ 864 | Configure.EB(SlotFrameID,TSlot, | Configures the 6tus MIB | 865 | Ch.Off,Period,Expires,Prio,Con_p)| regarding EB configuration | 866 +----------------------------------+--------------------------------+ 867 | Read.EB() | Reads 6tus EB MIB | 868 | | | 869 +----------------------------------+--------------------------------+ 871 2.4.6. Time Source Neighbor Commands 873 Commands to select time source neighbors. 875 2.4.6.1. CONFIGURE.timesource 877 Configures the Time Source Neighbor selection process. More than one 878 time source neighbor can be selected. The command requires: 880 selection policy: The policy used to select the time parent. The 881 policy MAY be for example ALL_PARENTS, BEST_CONNECTED, 882 LOWEST_JOIN_PRIORITY, etc. 884 Fails if any of the time source neighbors do not exist or it is not 885 reachable. 887 2.4.6.2. READ.timesource 889 Retrieves information about the time parents of that node. The 890 command does not require any parameter. 892 Returns the following information for each of the time sources: 894 target node: address of the time parent. 896 statistics: includes for example minimum, maximum, average time 897 correction for that time parent 899 policy: the used policy 901 Fails if the slotframe id or no time source neighbors exist. 903 2.4.6.3. Time Source Neighbor Command Behavior 905 The following table describes the behavior of 6tus upon reception of 906 the Time Source Neighbor Configuration management commands. 908 Time Source Neighbors Configuration Management Operations behavior 910 +---------------------------------+---------------------------------+ 911 | 6tus commands | 6tus behavior | 912 +---------------------------------+---------------------------------+ 913 | Configure.timesource(Policy) | Configures the 6tus MIB | 914 | | regarding timesource parents | 915 +---------------------------------+---------------------------------+ 916 | Read.timesource() | Read 6tus timesource MIB | 917 | | | 918 +---------------------------------+---------------------------------+ 920 Figure 3 922 2.4.7. Neighbor Commands 924 Commands to manage neighbor table. The commands SHOULD be used by 925 the upper layer to query the neighbor related information and by the 926 lower layer to keep track of neighbors information. 928 2.4.7.1. CREATE.neighbor 930 Creates an entry for a neighbor in the neighbor table. 932 neighbor address: The address of the neighbor. 934 neighbor stats: for example, RSSI of the last received packet from 935 that neighbor, ASN when that neighbor has been added, etc. 937 Returns whether the neighbor is created or not. 939 2.4.7.2. READ.all.neighbor 941 Returns the list of neighbors of that node. Fails if empty. For 942 each neighbor in the list it returns: 944 neighbor address: The address of the neighbor. 946 neighbor stats: for example, RSSI of the last received packet from 947 that neighbor, ASN when that neighbor has been added, packets 948 received from that neighbor, packets sent to it, etc. . 950 2.4.7.3. READ.neighbor 952 Returns the information of a specific neighbors of that node 953 specified by its neighbor address. Fails if it does not exists. For 954 that neighbor it returns: 956 neighbor address: The address of the neighbor. 958 neighbor stats: for example, RSSI of the last received packet from 959 that neighbor, ASN when that neighbor has been added, packets 960 received from that neighbor, packets sent to it, etc. 962 2.4.7.4. UPDATE.neighbor 964 Updates an entry for a neighbor in the neighbor table. Fails if the 965 neighbor does not exist. Updates stats parameters. Requires: 967 neighbor address: The address of the neighbor. 969 neighbor stats: for example, RSSI of the last received packet from 970 that neighbor, ASN when that neighbor has been added, etc. . 972 Returns whether the neighbor is updated or not. 974 2.4.7.5. DELETE.neighbor 976 Deletes a neighbor given its address. Fails if the neighbor does not 977 exists. 979 2.4.7.6. Neighbors Command Behavior 981 The following table describes the behavior of 6tus upon reception of 982 the Neighbors Configuration management commands. 984 Neighbors Management Operations behavior 985 +---------------------------------+---------------------------------+ 986 | 6tus commands | 6tus behavior | 987 +---------------------------------+---------------------------------+ 988 | Create.neighbor(address,stats) | Adds a neighbor to the neighbor | 989 | | table in the 6tus MIB. | 990 +---------------------------------+---------------------------------+ 991 | Read.all.neighbor() | lists all neighbors from the | 992 | | neighbor table. | 993 +---------------------------------+---------------------------------+ 994 | Read.neighbor(address) | Reads neighbor information from | 995 | | neighbor table in the 6tus MIB | 996 +---------------------------------+---------------------------------+ 997 | Update.neighbor(address,stats) | Updates an entry for a neighbor | 998 | | in the 6tus MIB | 999 +---------------------------------+---------------------------------+ 1000 | Delete.neighbor(address) | Removes the neighbor from the | 1001 | | 6tus MIB | 1002 +---------------------------------+---------------------------------+ 1004 2.4.8. Queueing Commands 1006 TSCH MAC layer queues need to be configured. This includes queue 1007 length, retransmission policy, discarding of packets, etc. 1009 2.4.8.1. CREATE.queue 1011 Creates and Configures TSCH Queues. The command SHOULD be applied 1012 for each required queue. The command requires: 1014 txqlength: the desired transmission queue length. 1016 rxqlength: the desired reception queue length. 1018 numrtx: number of allowed retransmissions. 1020 age: discard packet according to its age on the queue. 0 if no 1021 discards are allowed. 1023 rtxbackoff: retransmission back off in number of slotframes. 0 if 1024 next available slot wants to be used. 1026 statswindow: window of time used to compute stats. 1028 queue priority: the priority of this queue. 1030 Returns the queue id. 1032 2.4.8.2. READ.queue 1034 Reads the queue configuration. Requires the queue id. 1036 The command returns: 1038 txqlength: the transmission queue length. 1040 rxqlength: the reception queue length. 1042 numrtx: number of allowed retransmissions. 1044 age: maximum age of a packet befoer being discarded. 0 if no 1045 discards are allowed. 1047 rtxbackoff: retransmission backoff in number of slotframes. 0 if 1048 next available slot is used. 1050 2.4.8.3. READ.queue.stats 1052 Reads the queue stats. Requires queue id. 1054 The command returns: 1056 txqlengthstats: average, maximum, minimum length of the 1057 transmission queue. 1059 rxqlengthstats: average, maximum, minimum length of the reception 1060 queue. 1062 numrtxstats: average, maximum, minimum number of retransmissions. 1064 agestats: average, maximum, minimum age of a packet in the queue. 1066 rtxbackoffstats: average, maximum, minimum retransmission backoff. 1068 queue priority: the priority of this queue. 1070 2.4.8.4. UPDATE.queue 1072 Update a TSCH Queue. The command requires: 1074 queueid: the desired transmission queue length. 1076 txqlength: the desired transmission queue length. 1078 rxqlength: the desired reception queue length. 1080 numrtx: number of allowed retransmissions. 1082 age: discard packet according to its age on the queue. 0 if no 1083 discards are allowed. 1085 rtxbackoff: retransmission backoff in number of slotframes. 0 if 1086 next available slot wants to be used. 1088 statswindow: window of time used to compute stats. 1090 2.4.8.5. DELETE.queue 1092 Deletes a TSCH Queue. The command requires the queue id. All 1093 packets in the queue are discarded and the queue is deleted. 1095 2.4.8.6. Queueing Command Behavior 1097 The following table describes the behavior of 6tus upon reception of 1098 the Queue management commands. 1100 Queue Management Operations behavior 1102 +---------------------------------+---------------------------------+ 1103 | 6tus commands | 6tus behavior | 1104 +---------------------------------+---------------------------------+ 1105 | Create.queue(tqlen,trlen,numrtx,| Creates a queue with specified | 1106 | age,rtxbackoff,prio) | parameters. Updates 6tus MIB. | 1107 +---------------------------------+---------------------------------+ 1108 | Read.queue(id) | Reads the queue configuration | 1109 | | from 6tus MIB. | 1110 +---------------------------------+---------------------------------+ 1111 | Update.queue(id,tqlen,trlen, | Updates the queue configuration | 1112 | numrtx,age,rtxbackoff,prio) | from 6tus MIB. Readjustes actual| 1113 | | queue size if required. | 1114 +---------------------------------+---------------------------------+ 1115 | Delete.queue(id) | Deletes the queue from MIB. | 1116 | | | 1117 +---------------------------------+---------------------------------+ 1118 | Read.queue.stats() | Reads the queue | 1119 | | stats from 6tus MIB. | 1120 +---------------------------------+---------------------------------+ 1122 2.4.9. Security Commands 1124 The following commands are used to manage underlying layer security. 1125 In that case 6tus acts as delegating interface to IEEE802.15.4 1126 security configuration commands. 1128 2.4.9.1. CONFIGURE.security 1130 Enables/Disables Security and configures the MAC PIB. The command 1131 requires: 1133 enable: enables underlying layer security. 1135 macAutoRequestSecurityLevel: the security level used for automatic 1136 data requests as described by IEEE 802.15.4 table 61. 1138 macAutoRequestKeyIdMode: the key identifier mode used for 1139 automatic data requests as described by IEEE 802.15.4 table 61. 1141 macAutoRequestKeySource: the originator of the key for automatic 1142 data requests as described by IEEE 802.15.4 table 61. 1144 macAutoRequestKeyIndex: the index of the key used for automatic 1145 data requests as described by IEEE 802.15.4 table 61. 1147 macDefaultKeySource: the originator of the default key used for 1148 key identifier mode 0x01 as described by IEEE 802.15.4 table 61. 1150 macPANCordinatorExtendedAddress: Address of the PAN coordinator as 1151 described by IEEE 802.15.4 table 61. 1153 macPANCordinatorShortAddress: Short address of the PAN coordinator 1154 as described by IEEE 802.15.4 table 61. 1156 2.4.9.2. CONFIGURE.security.macKeyTable 1158 Configures Security Keys. The command requires: 1160 KeyIdLookupList: list of keyIdLookupDescriptor Entries as defined 1161 by IEEE 802.15.4 table 61. 1163 DeviceDescriptorHandleList: Implementation specific list of 1164 devices that are using this key. As defined by IEEE 802.15.4 1165 table 61. 1167 KeyUsageList: List of slotframe types on which this key is being 1168 used as specified by IEEE 802.15.4 section 7.4.1.2 1169 Key: 16 octets key. As specified by IEEE 802.15.4 table 61. 1171 2.4.9.3. CONFIGURE.security.macSecurityLevelTable 1173 Configures the set of security levels. The command requires: 1175 FrameType: Slotframe type as defined by IEEE802.15.4e std. 1177 Command Identifier: The command identifier as defined by 1178 IEEE802.15.4e std. 1180 Security Minimum: The minimum required security level as specified 1181 by IEEE 802.15.4e 1183 Device Override Security Minimum: whether the minimum security 1184 level can be overridden as specified by IEEE 802.15.4 Table 64 1186 Allowed Security Levels: the key identifier field that identifies 1187 the key that is being used as specified by IEEE 802.15.4 section 1188 7.4.3 1190 2.4.9.4. Security Command Behavior 1192 6tus offers the interface to upper layers so underlying MAC layer can 1193 be configured. In that sense, 6tus acts as a "none-layer" by only 1194 delegating the functionalities to the MAC security services. For 1195 more details Section 7 on IEEE802.15.4-2011 and its amendments on 1196 IEEE802.15.4e-2012 should be referred. 1198 2.4.10. Data Commands 1200 2.4.10.1. Send.data 1202 The command used by upper layers to queue a packet so underlying TSCH 1203 sends it. According to the specific priority the packet is pushed 1204 into a Queue with the equivalent priority or following a criteria out 1205 of the scope of this document. Once a packet is inserted into a 1206 queue it waits to be transmitted by TSCH according to the model 1207 defined in Section 2.3. 1209 The required parameters are: 1211 src address: L2 source address 1213 dest address: L2 unicast or broadcast destination address 1215 priority: packet priority, usually is consistent with queue 1216 priority 1217 message length: the length of the message. 1219 message: control message or data message 1221 securityLevel:As defined by IEEE802.15.4e std. 1223 2.4.10.2. Receive.data 1225 The command is invoked whenever a packet is received and inserted 1226 into a reception queue. The method acts as a callback function to 1227 notify to the upper layers the received message. Upper layers MUST 1228 provide an implementation for that method. 1230 The function has the following parameters: 1232 src address: L2 source address 1234 dest address: L2 unicast or broadcast destination address 1236 priority: packet priority, usually is consistent with queue 1237 priority 1239 message length: the length of the message. 1241 message: control message or data message 1243 2.4.10.3. Data Command Behavior 1245 The following table describes the behavior of 6tus upon reception of 1246 the Data Communication Configuration management commands. 1248 Data Communication Management Operations behavior 1250 +---------------------------------+---------------------------------+ 1251 | 6tus commands | 6tus behavior | 1252 +---------------------------------+---------------------------------+ 1253 | Send.data(src,dest,prio, | The message is inserted in the | 1254 | len,msg,seclevel) | the queue corresponding to the | 1255 | | required priority. Fails if the | 1256 | | queue is full. Fails if the | 1257 | | destination address is not a | 1258 | | L2 neighbor of the node. | 1259 +---------------------------------+---------------------------------+ 1260 | Receive.data(src,dest,prio,len, | The method is invoked whenever a| 1261 | msg) | message is inserted in the queue| 1262 | | after successful reception. | 1263 +---------------------------------+---------------------------------+ 1265 Figure 4 1267 2.5. Message Formats 1269 6tus has to negotiate the scheduling of soft links with neighbor 1270 nodes. This negotiation happens through 6tus-specific TSCH 1271 Information Elements, the format of which is defined in this section. 1272 This section also details the formats of the IEs defined in 1273 [IEEE802154e] and reused without modification. 1275 6tus messages can contain one or more IEs. Section 2.5.1 defines the 1276 different IEs used by 6tus, both the ones used without modification 1277 from [IEEE802154e], and the new ones defined by 6tus. Section 2.5.2 1278 shows how those IEs are assembled to form the different packets used 1279 by 6tus. 1281 2.5.1. Information Elements 1283 IEEE802.15.4e defines Information elements (IEs) which are formatted 1284 data objects consisting of an ID, a length, and a data payload used 1285 to pass data between layers or devices. IEEE802.15.4e defines Header 1286 IEs and Payload IEs; 6tus only uses Payload IEs. A Payload IE 1287 includes one or more IEs, and ends with a termination IE (ID = 0xf, 1288 see [IEEE802154e]). 1290 6tus uses the following Information Elements, in which the first four 1291 IEs are defined in IEEE802.15.4e, and other three IEs are introduced 1292 in this document. 1294 Defined in [IEEE802154e] and used by 6tus without modification: 1296 TSCH Synchronization IE (Section 2.5.1.1) 1298 TSCH Slotframe and Link IE (Section 2.5.1.2) 1300 TSCH Timeslot Template IE (Section 2.5.1.3) 1302 TSCH Channel Hopping IE (Section 2.5.1.4) 1304 Defined by 6tus: 1306 6tus Opcode IE (Section 2.5.1.5) 1308 6tus Bandwidth IE (Section 2.5.1.6) 1310 6tus Generic Schedule IE (Section 2.5.1.7) 1312 2.5.1.1. TSCH Synchronization IE 1314 A Synchronization IE (SyncIE) contains Information allowing a node to 1315 synchronize to a TSCH network, including the current ASN and a join 1316 priority. Synchronization IE must be included in all TSCH Enhanced 1317 Beacons. 1319 6tus re-uses this IE as defined in [IEEE802154e]. 1321 Format of a TSCH Synchronization IE (SyncIE). 1323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Length | SubID |T| ASN | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | ASN | Join Priority | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 Figure 5 1332 Length=6 1334 SubID=0x1a 1336 T=0, i.e. short type 1338 ASN (5 octets) contains the Absolute Slot Number corresponding to the 1339 timeslot in which the TSCH Enhanced Beacon is sent. 1341 The Join Priority can be used by a joining device to select among 1342 beaconing devices when multiple beacons are heard. The PAN 1343 coordinator's join priority is zero. A lower value of join priority 1344 indicates that the device is the preferred one to connect to. The 1345 beaconing device's join priority is the lowest join priority heard 1346 when it joined the network plus one. 1348 2.5.1.2. TSCH Slotframe and Link IE 1350 The Slotframe and Link IE (FrameAndLinkIE) contains one or more 1351 slotframes and their respective links that a beaconing device 1352 advertises to allow other devices to join the network. 1354 6tus re-uses this IE as defined in [IEEE802154e]. 1356 Format of a TSCH Slotframe and Link IE (FrameAndLinkIE). 1358 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Length | SubID |T| NumFrame | | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1362 | | 1363 // Slotframe and link information // 1364 | | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 Figure 6 1369 Length=variable 1371 SubID=0x1b 1373 T=0, i.e. short type 1375 NumFrame is set to the total number of slotframe descriptors 1376 contained in the TSCH Enhanced Beacon. 1378 Format of a slotframe descriptor. 1380 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | FrameID | FrameLen | NumLink | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | | 1385 // Link information for each link (5x NumLink) // 1386 | | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 Figure 7 1391 FrameID field shall be set to the slotframeHandle that uniquely 1392 identifies the slotframe. 1394 FrameLen field shall be set to the size of the slotframe in number of 1395 timeslots. 1397 NumLink field shall be set to the number of links that belong to the 1398 specific slotframe identified by the slotframeHandle. 1400 Format of a Link information. 1402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | SlotOffset | ChannelOffset | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | LinkOption | 1407 +-+-+-+-+-+-+-+-+ 1409 Figure 8 1411 SlotOffset shall be set to the timeslot of this link. 1413 ChannelOffset shall be set to the logic channel of this link. 1415 LinkOption indicates whether this link is a TX link, an RX link, or a 1416 SHARED TX link, whether the device to which it is being linked is to 1417 be used for clock synchronization, and whether this link is Hard 1418 link. 1420 2.5.1.3. TSCH Timeslot Template IE 1422 Timeslot Template IE (SlotTemplateIE) defines Timeslot template being 1423 used by the TSCH device. 1425 6tus re-uses this IE as defined in [IEEE802154e]. 1427 Format of a TSCH Timeslot Template IE (SlotTemplateIE). 1429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Length | SubID |T| TemplateID | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 Figure 9 1436 Length=1 1438 SubID=0x1c 1440 T=0, i.e. short type 1442 TemplateID shall be set to a Timeslot template handle. The full 1443 time-slot template, which contains the macTimeslotTemplate of TSCH 1444 (total 25 octets), may be included.(see IEEE802.15.4e). 1446 2.5.1.4. TSCH Channel Hopping IE 1448 Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being 1449 used by the TSCH device. 1451 6tus re-uses this IE as defined in [IEEE802154e]. 1453 Format of a TSCH Channel Hopping IE (ChHoppingIE). 1455 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Length | SubID |T| HopSequenceID | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 Figure 10 1462 Length=1 1464 SubID=0x09 1466 T=1, i.e. long type 1468 HopSequenceID shall be set to a Hopping Sequence handle. The full 1469 Hopping Sequence information may be included. (see IEEE802.15.4e). 1471 2.5.1.5. 6tus Opcode IE 1473 6tus Opcode IE (OpcodeIE) defines operation codes of packets in 6tus 1474 layer. 1476 This IE is not present in [IEEE802154e] and is defined by 6tus. 1478 Format of a 6tus Opcode IE (OpcodeIE). 1480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Length | SubID |T| OpcodeID | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 Figure 11 1487 Length=1 1489 SubID=0x41 1491 T=0, i.e. short type 1493 OpcodeID field shall be set to one of the following codes. 1495 0x00: Reserve Link Request 1497 0x01: Reserve Link Response 1499 0x02: Remove Link Request 1501 2.5.1.6. 6tus Bandwidth IE 1503 Bandwidth IE (BwIE) defines the number of links to be reserved. 1505 This IE is not present in [IEEE802154e] and is defined by 6tus. 1507 Format of a 6tus Bandwidth IE (BwIE). 1509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Length | SubID |T| FrameID | NumLink | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 Figure 12 1516 Length=2 1518 SubID=0x42 1520 T=0, i.e. short type 1521 FrameID field may be set to the SlotFrameHandle to identify the 1522 slotframe from which links are reserved. FrameID field may be set to 1523 NOP, which means no specific slotframe is associated. 1525 NumLink field shall be set to the number of links. When BwIE is 1526 combined with the OpecodeID of Reserve Link Request, NumLink presents 1527 how many links are required to reserve; and when BwIE is combined 1528 with the OpecodeID of Reserve Link Response, NumLink presents how 1529 many links are reserved successfully. 1531 2.5.1.7. 6tus Generic Schedule IE 1533 Generic Schedule IE (ScheduleIE) describes link sets. In different 1534 packet, ScheduleIE represents different information. See 1535 Section 2.5.2 for more detail. 1537 This IE is not present in [IEEE802154e] and is defined by 6tus. 1539 Format of a 6tus Generic Schedule IE (ScheduleIE). 1541 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Length | SubID |T| | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1545 | | 1546 // Schedule Body // 1547 | | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 Figure 13 1552 Length=variable 1554 SubID=0x43 1556 T=0, i.e. short type 1558 Schedule Body carries one or more schedule object. An object may 1559 carry a TLV, which may itself comprise other TLVs. TLV format is as 1560 follows. Type: 1 byte, Length: 1 byte, Value: variable 1562 The following are some examples of schedule object TLV. 1564 Example 1. Link Set TLV 1565 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Type=1 | Length | FrameID | NumLink |F| 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | | 1570 // LinkObjects // 1571 | | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 Figure 14 1576 FrameID shall be set to the slotframeHandle that uniquely identifies 1577 the slotframe. 1579 NumLink shall be set to the number of links that belong to the 1580 specific slotframe identified by the slotframeHandle. 1582 F=1 means the specified links equals to what are listed in 1583 LinkObjects, and F=0 means the specified links equals to what are not 1584 listed in LinkObjects. 1586 LinkObjects carries the information for one or more links, including 1587 SlotOffset, ChannelOffset, LinkOption (Figure 8). 1589 Example 2. Schedule Matrix TLV 1591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | Type=2 | Length | FrameID |StartSlotOffset| 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 |StartSLotOffset| NumSlot | | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1597 | | 1598 // SlotBitMap (2x NumSlot) // 1599 | | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 Figure 15 1604 FrameID field shall be set to the slotframeHandle that uniquely 1605 identifies the slotframe. 1607 StartSlotOffset field (2 octets) shall be set to the slotoffset in 1608 the specific slotframe identified by the slotframeHandle. 1610 NumSlot field shall be set to the number of slots from 1611 StartSlotOffset in the specific slotframe identified by the 1612 slotframeHandle. 1614 SlotBitMap (per slot) indicates for the given slot which channels are 1615 specified. For the 16 channels in 2.4GHz band, 2-octets are used to 1616 indicate which channel is specified. For example, given a slot and a 1617 SlotBitmap with value (10001000,00010000); the bitmap represents that 1618 ChannelOffset-0, ChannelOffset-4, ChannelOffset-11 are specified. 1620 2.5.2. Packet Formats 1622 This section describes the packets used in 6tus to form a network and 1623 reserve/maintain bandwidth using soft links. Each of these packets 1624 use one of more IEs defined in Section 2.5.1. 1626 2.5.2.1. TSCH Enhanced Beacon 1628 The TSCH Enhanced Beacon is used to announce the presence of the 1629 network and allow new nodes to join. It is and IEEE802.15.4e 1630 Enhanced Beacon packet with the following Payload IEs: 1632 TSCH Synchronization IE (Section 2.5.1.1) 1634 TSCH Timeslot Template IE (Section 2.5.1.3) 1636 TSCH Channel Hopping IE (Section 2.5.1.4) 1638 TSCH Slotframe and Link IE (Section 2.5.1.2) 1640 Payload IE of TSCH Enhanced Beacon Packet 1642 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Length |GroupID|T| SyncIE | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | SyncIE | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | SyncIE | SlotTemplateIE | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 |SlotTemplateIE | ChHoppingIE | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | | 1653 // FrameAndLinkIE // 1654 | | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 Figure 16 1659 Length=variable 1661 GroupID=0x1, i.e. MLME IE 1662 T=1, i.e. payload IE 1664 See Section 2.5.1.1, Section 2.5.1.3, Section 2.5.1.4,Section 2.5.1.2 1665 for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndLinkIE. 1667 2.5.2.2. Link Reservation Request 1669 Link Reservation Request packet is formatted in Data packet of 1670 IEEE802.15.4e with following payload IE. 1672 Payload IE of Link Reservation Request 1674 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | Length |GroupID|T| OpcodeIE | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | OpcodeIE | BwIE | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | BwIE | | 1681 +-+-+-+-+-+-+-+-+ | 1682 // ScheduleIE // 1683 | | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 Figure 17 1688 Length=variable 1690 GroupID=0x1, i.e. MLME IE 1692 T=1, i.e. payload IE 1694 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x00, 1695 indicates Reserve Link Request operation. 1697 The NumLink field in 4-octet BwIE should be set to the number of 1698 links needed to be reserved. 1700 The ScheduleIE specifies a candidate link set, from which the links 1701 should be reserved. ScheduleIE may be empty, means there is no 1702 constrain on which links should not be reserved. 1704 2.5.2.3. Link Reservation Response 1706 Link Reservation Response is formatted in Data packet of 1707 IEEE802.15.4e with following payload IE. 1709 Payload IE of Link Reservation Response 1711 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Length |GroupID|T| OpcodeIE | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | OpcodeIE | BwIE | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | BwIE | | 1718 +-+-+-+-+-+-+-+-+ | 1719 // ScheduleIE // 1720 | | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 Figure 18 1725 Length=variable 1727 GroupID=0x1, i.e. MLME IE 1729 T=1, i.e. payload IE 1731 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x01, 1732 indicates Reserve Link Response operation. 1734 The NumLink field in 4-octet BwIE should be set to the number of 1735 links which have been reserved successfully. 1737 The ScheduleIE should specify all of the links which have been 1738 reserved successfully. 1740 2.5.2.4. Link Remove Request 1742 Link Remove Request is formatted in a Data packet of IEEE802.15.4e 1743 with the following payload IE. 1745 Payload IE of Link Remove Request 1747 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Length |GroupID|T| OpcodeIE | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | OpcodeIE | | 1752 +-+-+-+-+-+-+-+-+ | 1753 // ScheduleIE // 1754 | | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 Figure 19 1759 Length=variable 1761 GroupID=0x1, i.e. MLME IE 1763 T=1, i.e. payload IE 1765 The OpcodeID field in the 3-octet OpcodeIE should be set to 0x02, 1766 indicates Remove Link Request operation. 1768 The ScheduleIE should specify all the links that need to be removed. 1770 2.6. Time Sequence 1772 6tus neighbors exchange 6tus-specific packets in the following cases, 1773 each detailed in a subsection. 1775 Network formation is detailed in Section 2.6.1. 1777 Creating a soft link is detailed in Section 2.6.2. 1779 Deleting a soft link is detailed in Section 2.6.3. 1781 Maintaining soft links is detailed in Section 2.6.4. 1783 2.6.1. Network Formation 1785 Network formation consists of two processes: joining and maintenance. 1787 2.6.1.1. Joining 1789 A node already in the network sends out TSCH Enhanced Beacons 1790 periodically. 1792 When a node is joining an existing network, it listens for TSCH 1793 Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs 1794 (the format of which is detailed in Section 2.5.2.1), the joining 1795 node must do the following. 1797 Initialize a neighbor table. Establish a neighbor table and 1798 record all of the information described in the TSCH Enhanced 1799 BEACONs as its initial schedule with those neighbors. 1801 Select a time source neighbor. According to the Joining Priority 1802 described by SyncIEs, the joining node chooses one or more of the 1803 advertisers as its time source neighbors. 6tus does not specify 1804 the criteria to choose time source neighbors from the Enhanced 1805 BEACONs. 1807 Select links for Enhanced Beacons. The joining node selects one 1808 or more links to broadcast its own Enhanced Beacons, which may be 1809 same as the links used by its neighbors for Enhanced Beacon 1810 broadcast, and record those link(s) into the TSCH schedule with 1811 LinkType=ADVERTISING. 1813 From its Enhanced Beacons, including the link(s) for its Enhanced 1814 Beacon, which LinkOption should be set to "Receive" and 1815 "Timekeeping", telling its neighbors that the link is used for 1816 broadcast. 1818 Start broadcasting Enhanced Beacon and communicate with neighbors. 1820 2.6.1.2. Maintenance 1822 Nodes may broadcast Enhance Beacons on the links marked with 1823 LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors 1824 on the links with LinkOption = "Receive" and "Timekeeping". If a 1825 link with both LinkType=ADVERTISING has both the "Receive" and 1826 "Timekeeping" LinkOption, it is shared by neighbors and itself to 1827 broadcast, then broadcast Enhanced Beacon has higher priority. 1829 Whenever a node receives an Enhanced Beacon, it must update its 1830 schedule if there is a difference. 1832 2.6.2. Creating a Soft Link 1834 The upper layer instructs 6tus to schedule one of more soft links by 1835 calling the Create Soft Link command. This command can also be 1836 called by the monitoring process internal to 6tus. 1838 When receiving a Create Soft Link command, Node A's 6tus layer forms 1839 a Link Reservation Request packet which includes BwIE and ScheduleIE. 1841 The BwIE includes the number of links needed to be reserved (N1), and 1842 ScheduleIE includes a candidate link set from which the new links 1843 should be selected. If the ScheduleIE is empty, Node A indicates 1844 there is no constraint on link selection. The Link Reservation 1845 Request is then sent to the neighbor (Node B) with whom new links 1846 need to be added. After receiving the Link Reservation Request, Node 1847 B selects the links from the candidate link set defined by the 1848 ScheludeIE in the Link Reservation Request, and forms a Link 1849 Reservation Response packet, in which BwIE indicates the number of 1850 links actually being reserved (N2), and ScheduleIE indicates those 1851 reserved links. If N2 is smaller than N1, node B indicates to node A 1852 that there are not enough qualified links to be reserved. Node B 1853 must record the reserved links into its local schedule while sending 1854 out Link Reservation Response. After receiving the Link Reservation 1855 Response, Node A must record the reserved links into its local 1856 schedule. 1858 The policy to build a candidate link set and the policy to select 1859 links from the candidate link set to reserve, and expression of 1860 Schedule Body are out of the scope. The policy to deal with the 1861 failure or not fully satisfaction in a Soft Link Reservation process 1862 is flexible. For example, Node A may initiate another soft link 1863 reservation procedure, or simply report to upper layer. 1865 2.6.3. Deleting a Soft Link 1867 The upper layer instructs 6tus to delete one of more soft links by 1868 calling the Delete Soft Link command. This command can also be 1869 called by the monitoring process internal to 6tus. 1871 When receiving a Delete Soft Link command, Node A's 6tus layer 1872 selects links to be removed from its local schedule, and creates a 1873 Link Remove Request, including a ScheduleIE. The ScheduleIE 1874 indicates which specific links to remove with a neighbor (Node B). 1875 The links specified in the ScheduleIE should be removed from local 1876 schedule of Node A while the Link Remove Request is sent to Node B. 1877 When receiving the Link Remove Request, the links specified in the 1878 ScheduleIE should be removed from the local schedule of Node B. 1880 The policy to select links corresponding to a Delete Soft Link 1881 command is out of scope. 1883 2.6.4. Maintaining Soft Links 1884 The monitoring process internal to 6tus (Section 2.8) is responsible 1885 for monitoring and re-scheduling soft links to meet some QoS 1886 requirements. The monitoring process may issue a Soft Link 1887 Maintenance command, which indicate a set of links to be moved in the 1888 TSCH schedule. 1890 When a receiving a Soft Link Maintenance command command, 6tus 1891 initializes a Link Reservation Request (Section 2.6.2) with the 1892 neighbor in question, followed by a Link Remove Request 1893 (Section 2.6.3). 1895 2.7. Statistics 1897 The 6tus Statistics Fuction (SF) is responsible for collecting 1898 statistics, which it can provide to an upper layer and the Monitoring 1899 Function (Section 2.8). 1901 2.7.1. Statistics Metrics 1903 6tus is in charge of keeping statistics from a set of metrics 1904 gathered from the behavior of the TSCH layer. 1906 The statistics data related to node states and link metrics should be 1907 provided to upper layer for management, e.g. for RPL to calculate 1908 Rank or to GMPLS to determine whether the path is meeting the 1909 required bandwidth. The specific algorithm to generate the 1910 statistics is implementation dependent and hence out of the scope of 1911 this document. However, the statistics component should include the 1912 following metrics: 1914 1. PathThroughput: associated with a path, Node A->Node B. For 1915 example, PathThroughput can be calculated with: 1916 SUM(NumOfLink(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration) 1917 where NumOfLink(i) is the total number of links from Node A to 1918 Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i. 1920 2. Latency: associated with a path, Node A->Node B. For example, 1921 latency can be expressed as Minimum and Maximum Latency. Minimum 1922 Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum 1923 Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where, 1924 MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum 1925 number of slots between two dedicated links from Node A to Node B 1926 in Slotframe-i, respectively. 1928 3. LinkQuality. For example, average LQI, ETX; 1930 4. TafficLoad. For example, Queue Full Rate, Queue Empty Rate; 1931 5. NodeEnergy. For example, E_E=E_bat / [E_0 (T-t)/T]. 1933 2.7.2. Statistics Configuration 1935 Statistics Function should be configurable. The configuration 1936 parameters should include: 1938 LinkQualityStatisticsEn. 1940 TafficLoadStatisticsEn. 1942 DeviceStatisticsEn. 1944 6tus statistics function is enabled/disabled and configured by the 1945 commands defined in Section 2.4.4 1947 2.8. Monitoring 1949 Monitoring Fuction (MF) in 6tus is responsible for monitoring link 1950 quality, traffic load, and issuing Soft Link Maintenance command, or 1951 Create/Delete Soft Link command. The data provided by Statistics 1952 Function may be used as a input of MF in making monitoring decision. 1954 2.8.1. Monitor Configuration 1956 Monitoring Function should be configurable. The configuration 1957 parameters should include: 1959 MaintainLinkEn. 1961 CreateDeleteLinkEn. 1963 QosLevel. QosLevel should associate with specific neighbor 1964 address. QosLevel may reflect the latency constraint, link 1965 quality constraint, and so on. The value of QosLevel works as the 1966 bandwidth redundancy coefficient. 1968 6tus monitoring function is enabled/disabled and configured by the 1969 commands defined in Section 2.4.3 1971 2.8.2. Actuation 1973 The link quality statistics may be used to generate Soft Link 1974 Maintenance command, which leads to a Soft Link Maintenance procedure 1975 (see Section 2.6.4). The traffic load statistics may be used to 1976 generate internal Create/Delete Soft Link commands, which leads to a 1977 Soft Link Reservation process or a Soft Link Remove process, 1978 respectively. (see Section 2.6.2 and Section 2.6.3) 1979 The policy to generate the Soft Link Maintenance command and the 1980 policy to generate Create/Delete Soft Link commands is out of the 1981 scope. 1983 The policy to generate Create/Delete Soft Link commands may take 1984 QosLevel into account. For example, there are two slotframes 1985 existing, Slotframe-1 consists of 32 slots, Slotframe-2 consists of 1986 96 slots; Slot duration is 10ms; QosLevel=1.5. If, from the traffic 1987 load statistics, MF figures out 2 packet/second should be added, then 1988 it leads to a Create Soft Link command, where FrameID=2, NumLink=3. 1990 3. Using 6tus 1992 This part describes how 6tus gives support to specific upper layers. 1994 3.1. RPL on 6tus 1996 6tus provides a set of functionalities so higher layers can obtain 1997 information about the status of the network and take advantage of the 1998 slotted structure to improve metric calculation and objective 1999 function optimization. The following sections describe how RPL can 2000 make use of 6tus adaptation layer. 2002 In order to optimize the combination of RPL and TSCH, 6tus provides 2003 specific support to RPL in the following aspects: 2005 RPL Neighbor Discovery and Parent Selection 2007 RPL Rank Computation 2009 RPL Control Messages Broadcast 2011 QoS 2013 3.1.1. Support to Neighbor Discovery and Parent Selection 2015 The Section 2.4.7 defines a set of commands so the neighbor table can 2016 be managed and queried by RPL. An entry to the neighbor table is 2017 inserted whenever an EBs is received at L2. The EB causes the 6tus 2018 layer to create an entry to the neighbors table. A neighbor table 2019 entry contains a set of statistics with respect to that specific 2020 neighbor such as the ASN when the last packet has been received from 2021 that neighbor, a set of link quality metrics (RSSI, LQI), number of 2022 packets sent to it or number of packets received from it amongst 2023 others. 6tus updates that table upon sending or reception of a 2024 packet from/to a neighbor. RPL can query at any time the neighbor 2025 table to retrieve information about a particular neighbor. This 2026 information can be used to compute the routing objective function as 2027 for example the inverse of the Probability Delivery Ratio (PDR). 2028 Parent selection can also be driven by the information contained on 2029 the neighbor table as well as complemented with the links statistics 2030 defined in Section 2.4.4 and Section 2.7. 2032 6tus enables RPL to configure EB periodicity. By controlling the EBs 2033 periodicity, RPL can configure how network dynamism and support to 2034 mobility are addressed, as more frequent beacons the more prone to 2035 cope with mobility. Section 2.4.5 enables to configure how the 2036 network is formed and EBs periodicity. 2038 RPL may want to select the policy to determine the time source 2039 neighbor, this can be interesting when time source neighbors can be 2040 aligned to the routing topology, i.e, the selected time source 2041 neighbor can be the node's favorite parent in a specific DODAG. 2042 Section 2.4.6 describes the 6tus command to setup the desired policy. 2043 The policy is selected by RPL and enforced by 6tus layer. 2045 The rule for 6tus to select and maintain time sources is as follows. 2047 Time source of one node should be one member of the node's 2048 neighbor set. 2050 Time sources should be the neighbors which have relatively lower 2051 Join Priority in the neighbor set. Lower Join Priority means 2052 closer to TSCH Pan coordinator. 2054 The path from a node to its time sources should be in a good link 2055 quality. 2057 3.1.2. Support to Rank Computation 2059 RPL objective function is computed by a set of metrics. The specific 2060 metrics and how the objective function is calculated are out of the 2061 scope of the present document, however, 6tus builds a set of 2062 functionalities to provide more accurate statistics of the underlying 2063 layer so the objective function can be accommodated to the nature of 2064 a TSCH MAC layer. 2066 6tus provides Statistics for Rank computation as described in 2067 sections(Section 2.4.4 and Section 2.7). The function to compute the 2068 Rank based on those statistics is out of scope of 6tus, however the 2069 provided metrics are aligned to the behavior of the TSCH MAC layer. 2071 3.1.3. Support to Control Messages Broadcast 2073 In RPL, some control messages, e.g. DIO, and DAO in sorting mode, 2074 need to be broadcasted to the neighbors. The broadcast channel 2075 requirement has to be addressed by 6tus by configuring TSCH to 2076 provide such a channel. 2078 In order to decouple the upper (RPL) layer to TSCH, instead of 2079 carrying DIO message in the Enhance Beacon, 6tus introduces a 2080 mechanism to establish broadcast links. 2082 In TSCH schedule, every link has the LinkType attribute. If 2083 LinkType=ADVERTISING, indicates that the link may be used to send an 2084 Enhanced Beacon. When a node forms its Enhanced Beacon, the link, 2085 with LinkType=ADVERTISING, should be included in the FrameAndLinkIE, 2086 and its LinkOption field should be set to the combination of 2087 "Receive" and "Timekeeping". The receiver of the Enhanced Beacon may 2088 listen to at the link to get the Enhanced Beacon ([IEEE802154e]). 2089 6tus takes this way to establish broadcast channel, which not only 2090 allows TSCH broadcast Enhanced Beacon, but also allows an upper layer 2091 like RPL broadcast. 2093 To support DIO and DAO broadcast, 6tus uses the payload of a Data 2094 Packet to carry the DIO or DAO. The message is inserted into the 2095 queue associated with the links which LinkType is set to ADVERTISING. 2096 Then, taking advantage of the broadcast link feature established with 2097 FrameAndLinkIE as described above, the data packet with DIO or DAO in 2098 payload can be received by neighbors, which leads to the maintenance 2099 of DODAG. 2101 The LinkOption of combining "Receive" and "Timekeeping" let the 2102 receivers of the Enhanced Beacon understand that the link is used as 2103 broadcast link. But the frequency of sending Enhance Beacon or other 2104 broadcast messages by upper layer is determined by the timers 2105 associated with the messages, e.g. Enhance Beacon is triggered by 2106 the timer in 6tus, and the DIO message is triggered by the trickle 2107 timer of RPL. Therefore, for energy efficiency, receivers can have 2108 some policy to wake up at the broadcast link, but it is 2109 implementation dependent. 2111 3.1.4. Support to QoS 2113 TSCH MAC layer is decoupled from the upper layers and its interaction 2114 with them is asynchronous. This means that the MAC layer executes a 2115 schedule and checks at each slot according to the type of link 2116 whether there is something to send or receive. If that is the case 2117 the packet is sent and the MAC layer continues its operation. When 2118 an upper layer sends a packet, this packet is pushed into a queue 2119 waiting to the MAC layer to read it and sent it in a particular slot 2120 according to is destination and priority (Section 2.3). 6tus 2121 provides a set of queue management operations which enable upper 2122 layers to create different queues and determine their priorities. In 2123 that sense different classes of traffic can be handled by the routing 2124 layer, i.e inserting a packet to a specific queue according to its 2125 priority. 2127 6tus provides at least a Broadcast Queue, a Transmit Queue, and a 2128 Receive Queue. RPL can configure the queues with Internal Queueing 2129 Command (Section 2.4.8.1). Broadcast Queue are associated with links 2130 with LinkType=ADVERTISING in sender's schedule, and 2131 LinkOption="Receive" and "Timekeeping" in all neighbors' schedule. 2132 That indicates the links can be used for broadcast from the sender to 2133 its neighbors. Transmit Queues are associated with the dedicated 2134 Transmit links or Shared Links. RPL can benefit from having 2135 different priority queues in order to improve latency or provide 2136 integrated services with different priorities, i.e different traffic 2137 classes. 2139 Data Communication Command (Section 2.4.10) can be used to send 2140 control messages and data messages. The operation is used to insert 2141 a message to an specific queue. 2143 For example a suitable configuration can include two Broadcast Queues 2144 with priority High and Low, respectively; three Transmit Queues, with 2145 priority High, Mid, and Low, respectively; and one Receive Queue. 2147 When DestAddr is a broadcast address, its related MAC layer packets 2148 will be pushed into the Broadcast Queue with the corresponding 2149 priority. 6tus is responsible for feeding these packets to TSCH at 2150 broadcast links. 2152 When DestAddr is unicast address, its related MAC layer packets will 2153 be push into the Transmit Queue with corresponding priority. 6tus is 2154 responsible for feeding these packets to TSCH at Transmit links or 2155 Shared Links. 2157 6tus conducts a QoS policy, which is out of scope. Here is an 2158 example. Packets in higher priority queue MUST be sent out before 2159 the packets in lower priority queue. Then, when there is an 2160 available broadcast/unicast link, 6tus checks the broadcast/unicast 2161 queue with higher priority first, if there is a packet, then feed it 2162 to TSCH at the link, otherwise checks broadcast/unicast queue with 2163 lower priority further. Repeat the process, until find a broadcast/ 2164 unicast packet to feed to TSCH or find all of broadcast/unicast 2165 queues are empty. 2167 3.2. GMPLS on 6tus 2169 GMPLS is a 2.5 layer service that is used to forward packets based on 2170 the concept of generalized label. Labels are determined by a 2171 reservation protocol during the formation of a path. As defined by 2172 [RFC3471],[RFC3473] and [RFC4606] a generalized label identifies a 2173 flow of data through a set of nodes that conform to a multi-hop path. 2174 Instead of being appended to each packet as is the case in MPLS 2175 [RFC3031], the generalized label it is kept at each node in the form 2176 of a table. The table can be used to map input links to output links 2177 so routing decisions can be taken at that layer. 2179 In order to optimize the combination of GMPLS and TSCH, 6tus provides 2180 specific support to GMPLS in the following aspects: 2182 Link Reservation Support 2184 QoS 2186 3.2.1. Link Reservation Support for GMPLS on 6tus 2188 The GMPLS control plane is used to transmit path reservation requests 2189 and reservation confirmations. When reservation confirmations are 2190 received, GMPLS needs to configure the underlying MAC layer to 2191 provide the required bandwidth. 6tus provides a set of commands to 2192 deal with bandwidth allocation, i.e. link allocation. Section 2.4.1 2193 describes the operations that GMPLS layer may use for link 2194 configuration. Note that 6tus supports different types of 2195 reservations: soft link and hard link. How the reservation 2196 requirements are expressed is out of scope of this document, but 6tus 2197 is able to handle a reservation done as a specific bandwidth 2198 requirement, done through specifying exact links. 2200 GMPLS can also give different priorities to its control plane and 2201 data plane. It can for example be interesting to have a higher 2202 priority for control messages so the network adapts to new bandwidth 2203 requirements quickly. In contrast, data plane messages can be given 2204 a higher priority when they need to meet higher throughput or lower 2205 latency. 6tus provides commands (Section 2.4.8) to manage MAC layer 2206 queues and assign different priorities to them. 2208 3.2.2. Supporting QoS 2210 GMPLS can use 6tus statistics to determine whether some QoS 2211 requirement is met. Metrics defined in Section 2.7 and operations 2212 defined in Section 2.4.4.4 can be used by GMPLS to trigger new 2213 bandwidth allocation, or to map different input bundles to output 2214 bundles. 2216 4. References 2217 4.1. Normative References 2219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2220 Requirement Levels", BCP 14, RFC 2119, March 1997. 2222 4.2. Informative References 2224 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2225 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2226 Functional Specification", RFC 2205, September 1997. 2228 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2229 Networks", RFC 2464, December 1998. 2231 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2232 Label Switching Architecture", RFC 3031, January 2001. 2234 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2235 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2237 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 2238 (GMPLS) Signaling Functional Description", RFC 3471, 2239 January 2003. 2241 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2242 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2243 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2245 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2246 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2247 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2248 RFC 3819, July 2004. 2250 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 2251 Protocol Label Switching (GMPLS) Extensions for 2252 Synchronous Optical Network (SONET) and Synchronous 2253 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 2255 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2256 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2257 Overview, Assumptions, Problem Statement, and Goals", RFC 2258 4919, August 2007. 2260 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2261 "Transmission of IPv6 Packets over IEEE 802.15.4 2262 Networks", RFC 4944, September 2007. 2264 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 2265 "Routing Requirements for Urban Low-Power and Lossy 2266 Networks", RFC 5548, May 2009. 2268 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 2269 Routing Requirements in Low-Power and Lossy Networks", RFC 2270 5826, April 2010. 2272 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 2273 "Building Automation Routing Requirements in Low-Power and 2274 Lossy Networks", RFC 5867, June 2010. 2276 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 2277 "Industrial Routing Requirements in Low-Power and Lossy 2278 Networks", RFC 5673, October 2009. 2280 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 2281 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2282 September 2011. 2284 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 2285 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 2286 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 2287 Lossy Networks", RFC 6550, March 2012. 2289 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 2290 Application Spaces for IPv6 over Low-Power Wireless 2291 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 2293 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 2294 Statement and Requirements for IPv6 over Low-Power 2295 Wireless Personal Area Network (6LoWPAN) Routing", RFC 2296 6606, May 2012. 2298 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 2299 for OAuth", RFC 6755, October 2012. 2301 [I-D.thubert-roll-forwarding-frags] 2302 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 2303 Recovery", draft-thubert-roll-forwarding-frags-01 (work in 2304 progress), February 2013. 2306 [I-D.tsao-roll-security-framework] 2307 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 2308 Security Framework for Routing over Low Power and Lossy 2309 Networks", draft-tsao-roll-security-framework-02 (work in 2310 progress), March 2010. 2312 [I-D.thubert-roll-asymlink] 2313 Thubert, P., "RPL adaptation for asymmetrical links", 2314 draft-thubert-roll-asymlink-02 (work in progress), 2315 December 2011. 2317 [I-D.ietf-roll-terminology] 2318 Vasseur, J., "Terminology in Low power And Lossy 2319 Networks", draft-ietf-roll-terminology-11 (work in 2320 progress), February 2013. 2322 [I-D.ietf-roll-p2p-rpl] 2323 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 2324 Martocci, "Reactive Discovery of Point-to-Point Routes in 2325 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16 2326 (work in progress), February 2013. 2328 [I-D.ietf-roll-trickle-mcast] 2329 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 2330 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 2331 mcast-04 (work in progress), February 2013. 2333 [I-D.thubert-6lowpan-backbone-router] 2334 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 2335 6lowpan-backbone-router-03 (work in progress), February 2336 2013. 2338 [I-D.sarikaya-core-sbootstrapping] 2339 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 2340 Cragie, "Security Bootstrapping Solution for Resource- 2341 Constrained Devices", draft-sarikaya-core- 2342 sbootstrapping-04 (work in progress), April 2012. 2344 [I-D.gilger-smart-object-security-workshop] 2345 Gilger, J. and H. Tschofenig, "Report from the 'Smart 2346 Object Security Workshop', 23rd March 2012, Paris, 2347 France", draft-gilger-smart-object-security-workshop-00 2348 (work in progress), October 2012. 2350 [I-D.phinney-roll-rpl-industrial-applicability] 2351 Phinney, T., Thubert, P., and R. Assimiti, "RPL 2352 applicability in industrial networks", draft-phinney-roll- 2353 rpl-industrial-applicability-02 (work in progress), 2354 February 2013. 2356 [I-D.ietf-core-coap] 2357 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 2358 "Constrained Application Protocol (CoAP)", draft-ietf- 2359 core-coap-13 (work in progress), December 2012. 2361 [I-D.watteyne-6tsch-tsch-lln-context] 2362 Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: 2363 Overview, Problem Statement and Goals", draft-watteyne- 2364 6tsch-tsch-lln-context-01 (work in progress), February 2365 2013. 2367 [I-D.draft-palattella-6tsch-terminology] 2368 Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. 2369 Wang, "Terminology in IPv6 over Time Slotted Channel 2370 Hopping. draft-palattella-6tsch-terminology-00 (work in 2371 progress) ", March 2013. 2373 [I-D.draft-thubert-6tsch-architecture] 2374 Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An 2375 Architecture for IPv6 over Time Synchronized Channel 2376 Hopping. draft-thubert-6tsch-architecture-00 (work in 2377 progress) ", March 2013. 2379 4.3. External Informative References 2381 [IEEE802154e] 2382 IEEE standard for Information Technology, "IEEE std. 2383 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2384 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 2385 2012. 2387 [IEEE802154] 2388 IEEE standard for Information Technology, "IEEE std. 2389 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2390 and Physical Layer (PHY) Specifications for Low-Rate 2391 Wireless Personal Area Networks", June 2011. 2393 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , 2394 . 2396 Authors' Addresses 2398 Qin Wang (editor) 2399 Univ. of Sci. and Tech. Beijing 2400 30 Xueyuan Road 2401 Beijing, Hebei 100083 2402 China 2404 Phone: +86 (10) 6233 4781 2405 Email: wangqin@ies.ustb.edu.cn 2406 Xavier Vilajosana 2407 Universitat Oberta de Catalunya 2408 156 Rambla Poblenou 2409 Barcelona, Catalonia 08018 2410 Spain 2412 Phone: +34 (646) 633 681 2413 Email: xvilajosana@uoc.edu 2415 Thomas Watteyne 2416 Linear Technology 2417 30695 Huntwood Avenue 2418 Hayward, CA 94544 2419 USA 2421 Phone: +1 (510) 400-2978 2422 Email: twatteyne@linear.com