idnits 2.17.1 draft-ietf-6tisch-tsch-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 21, 2013) is 3807 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 541, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 547, but not defined == Missing Reference: 'CurrentCalculator' is mentioned on line 567, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 553, but not defined == Missing Reference: 'OpenWSNETT' is mentioned on line 556, but not defined == Missing Reference: 'IPSO' is mentioned on line 564, but not defined == Missing Reference: 'TASA-PIMRC' is mentioned on line 603, but not defined == Missing Reference: 'TASA-SENSORS' is mentioned on line 610, but not defined == Missing Reference: 'TASA-WCNC' is mentioned on line 617, but not defined == Missing Reference: 'PANA' is mentioned on line 632, but not defined == Unused Reference: 'RFC2119' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 522, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-05 == Outdated reference: A later version (-05) exists of draft-sarikaya-core-sbootstrapping-04 == Outdated reference: A later version (-03) exists of draft-gilger-smart-object-security-workshop-00 Summary: 2 errors (**), 0 flaws (~~), 24 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH T. Watteyne, Ed. 3 Internet-Draft Linear Technology 4 Intended status: Informational MR. Palattella 5 Expires: May 25, 2014 University of Luxembourg 6 LA. Grieco 7 Politecnico di Bari 8 November 21, 2013 10 Using IEEE802.15.4e TSCH in an LLN context: 11 Overview, Problem Statement and Goals 12 draft-ietf-6tisch-tsch-00 14 Abstract 16 This document describes the environment, problem statement, and goals 17 for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. 18 The set of goals enumerated in this document form an initial set 19 only. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 25, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4 57 3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 6 60 3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7 61 3.4. Routing and Timing Parents . . . . . . . . . . . . . . . 7 62 3.5. Resource Management . . . . . . . . . . . . . . . . . . . 7 63 3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8 64 3.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8 65 3.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 8 66 3.9. Secure Communication . . . . . . . . . . . . . . . . . . 9 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 5.2. Informative References . . . . . . . . . . . . . . . . . 9 71 5.3. External Informative References . . . . . . . . . . . . . 12 72 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 14 73 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 14 74 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 15 75 A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 15 76 A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 15 77 A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 16 78 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 16 79 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 16 80 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 17 81 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 18 82 A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 18 83 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 18 84 A.12. Information Elements . . . . . . . . . . . . . . . . . . 19 85 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 19 86 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 19 87 B.1. Collision Free Communication . . . . . . . . . . . . . . 19 88 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 19 89 B.3. Cost of (continuous) Synchronization . . . . . . . . . . 20 90 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 20 91 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 95 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an 96 amendment to the Medium Access Control (MAC) protocol defined by the 97 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel 98 Hopping (TSCH) mode of IEEE802.15.4e is the object of this document. 100 This document describes the main issues arising from the adoption of 101 the IEEE802.15.4e TSCH in the LLN context, following the terminology 102 defined in [I-D.palattella-6tisch-terminology]. 104 TSCH was designed to "allow IEEE802.15.4 devices to support a wide 105 range of industrial applications" [IEEE802154e]. At its core is a 106 medium access technique which uses time synchronization to achieve 107 ultra low-power operation and channel hopping to enable high 108 reliability. This is very different from the "legacy" IEEE802.15.4 109 MAC protocol, and is therefore better described as a "redesign". 110 TSCH does not amend the physical layer; i.e., it can operate on any 111 IEEE802.15.4-compliant hardware. 113 IEEE802.15.4e can be seen as the latest generation of ultra-lower 114 power and reliable networking solutions for LLNs. [RFC5673] 115 discusses industrial applications, and highlights the harsh operating 116 conditions as well as the stringent reliability, availability, and 117 security requirements for an LLN to operate in an industrial 118 environment. Commercial networking solutions are available today in 119 which motes consume 10's of micro-amps on average [CurrentCalculator] 120 with end-to-end packet delivery ratios over 99.999% 121 [doherty07channel]. 123 IEEE802.15.4e TSCH focuses on the MAC layer only. This clean 124 layering allows for TSCH to fit under an IPv6 enabled protocol stack 125 for LLNs, running 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP 126 [I-D.ietf-core-coap]. 128 Bringing industrial-like performance into the LLN stack developed by 129 the 6LoWPAN, ROLL and CORE working groups opens up new application 130 domains for these networks. Sensors deployed in smart cities 131 [RFC5548] will be able to be installed for years without needing 132 battery replacement. "Umbrella" networks will interconnect smart 133 elements from different entities in smart buildings [RFC5867]. Peel- 134 and-stick switches will obsolete the need for costly conduits for 135 lighting solutions in smart homes [RFC5826]. 137 While [IEEE802154e] defines the mechanisms for a TSCH mote to 138 communicate, it does not define the policies to build and maintain 139 the communication schedule, match that schedule to the multi-hop 140 paths maintained by RPL, adapt the resources allocated between 141 neighbor nodes to the data traffic flows, enforce a differentiated 142 treatment for data generated at the application layer and signalling 143 messages needed by 6LoWPAN and RPL to discover neighbors, react to 144 topology changes, self-configure IP addresses, or manage keying 145 material. 147 In other words, IEEE802.15.4e TSCH is designed to allow optimizations 148 and strong customizations, simplifying the merging of TSCH with a 149 protocol stack based on IPv6, 6LoWPAN, and RPL. 151 2. TSCH in the LLN Context 153 In many cases, to map the services required by the IP layer to the 154 services provided by the link layer, an adaptation layer is used 155 [palattella12standardized]. The 6LoWPAN working group started 156 working in 2007 on specifications for transmitting IPv6 packets over 157 IEEE802.15.4 networks [RFC4919]. Typically, low-power WPANs are 158 characterized by small packet sizes, support for addresses with 159 different lengths, low bandwidth, star and mesh topologies, battery 160 powered devices, low cost, large number of devices, unknown node 161 positions, high unreliability, and periods during which communication 162 interfaces are turned off to save energy. Given these features, it 163 is clear that the adoption of IPv6 on top of a Low-Power WPAN is not 164 straightforward, but poses strong requirements for the optimization 165 of this adaptation layer. For instance, due to the IPv6 default 166 minimum MTU size (1280 bytes), an un-fragmented IPv6 packet is too 167 large to fit in an IEEE802.15.4 frame. Moreover, the overhead due to 168 the 40-byte long IPv6 header wastes the scarce bandwidth available at 169 the PHY layer [RFC4944]. For these reasons, the 6LoWPAN working 170 group has defined an effective adaptation layer [RFC6568]. Further 171 issues encompass the auto-configuration of IPv6 addresses 172 [RFC2464][RFC6755], the compliance with the recommendation on 173 supporting link-layer subnet broadcast in shared networks [RFC3819], 174 the reduction of routing and management overhead [RFC6606], the 175 adoption of lightweight application protocols (or novel data encoding 176 techniques), and the support for security mechanisms (confidentiality 177 and integrity protection, device bootstrapping, key establishment, 178 and management). 180 These features can run on top of TSCH. There are, however, important 181 issues to solve, as highlighted in Section 3. 183 Routing issues are challenging for 6LoWPAN, given the low-power and 184 lossy radio-links, the battery-powered nodes, the multi-hop mesh 185 topologies, and the frequent topology changes due to mobility. 186 Successful solutions take into account the specific application 187 requirements, along with IPv6 behavior and 6LoWPAN mechanisms 188 [palattella12standardized]. The ROLL working group has defined RPL 189 in [RFC6550]. RPL can support a wide variety of link layers, 190 including ones that are constrained, potentially lossy, or typically 191 utilized in conjunction with host or router devices with very limited 192 resources, as in building/home automation [RFC5867][RFC5826], 193 industrial environments [RFC5673], and urban applications [RFC5548]. 194 RPL is able to quickly build up network routes, distribute routing 195 knowledge among nodes, and adapt to a changing topology. In a 196 typical setting, motes are connected through multi-hop paths to a 197 small set of root devices, which are usually responsible for data 198 collection and coordination. For each of them, a Destination 199 Oriented Directed Acyclic Graph (DODAG) is created by accounting for 200 link costs, node attributes/status information, and an Objective 201 Function, which maps the optimization requirements of the target 202 scenario. The topology is set up based on a Rank metric, which 203 encodes the distance of each node with respect to its reference root, 204 as specified by the Objective Function. Regardless of the way it is 205 computed, the Rank monotonically decreases along the DODAG towards 206 the destination, building a gradient. RPL encompasses different 207 kinds of traffic and signalling information. Multipoint-to-Point 208 (MP2P) is the dominant traffic in LLN applications. Data is routed 209 towards nodes with some application relevance, such as the LLN 210 gateway to the larger Internet, or to the core of private IP 211 networks. In general, these destinations are the DODAG roots and act 212 as data collection points for distributed monitoring applications. 213 Point-to-Multipoint (P2MP) data streams are used for actuation 214 purposes, where messages are sent from DODAG roots to destination 215 nodes. Point-to-Point (P2P) traffic allows communication between two 216 devices belonging to the same LLN, such as a sensor and an actuator. 217 A packet flows from the source to the common ancestor of those two 218 communicating devices, then downward towards the destination. RPL 219 therefore has to discover both upward routes (i.e. from nodes to 220 DODAG roots) in order to enable MP2P and P2P flows, and downward 221 routes (i.e. from DODAG roots to nodes) to support P2MP and P2P 222 traffic. 224 Section 3 highlights the challenges that need to be addressed to use 225 RPL on top of TSCH. 227 Several open-source initiatives have emerged around TSCH. The 228 OpenWSN project [OpenWSN][OpenWSNETT] is an open-source 229 implementation of a standards-based protocol stack, which aims at 230 evaluating the applicability of TSCH to different applications. This 231 implementation was used as the foundation for an IP for Smart Objects 232 Alliance (IPSO) [IPSO] interoperability event in 2011. In the 233 absence of a standardized scheduling mechanism for TSCH, a "slotted 234 Aloha" schedule was used. 236 3. Problems and Goals 237 As highlighted in Appendix A, TSCH is different for traditional low- 238 power MAC protocols because of its scheduled nature. TSCH defines 239 the mechanisms to execute a communication schedule, yet it is the 240 entity that sets up that schedule which controls the topology of the 241 network. This scheduling entity also controls the resources 242 allocated to each link in that topology. 244 How this entity should operate is out of scope of TSCH. The 245 remainder of this section highlights the problems this entity needs 246 to address. For simplicity, we will refer to this entity by the 247 generic name "6TiSCH". Note that the 6top sublayer, currently being 248 defined in [I-D.wang-6tsch-6top], can be seen as an embodiment of 249 this generic "6TiSCH". 251 Some of the issues 6TiSCH needs to target might overlap with the 252 scope of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this 253 case, it is entailed that 6TiSCH will profit from the services 254 provided by other protocols to pursue these objectives. 256 3.1. Network Formation 258 6TiSCH needs to control the way the network is formed, including how 259 new motes join, and how already joined motes advertise the presence 260 of the network. 6TiSCH needs to: 262 1. Define the Information Elements to include in the Enhanced 263 Beacons advertising the presence of the network. 265 2. For a new mote, define rules to process and filter received 266 Enhanced Beacons. 268 3. Define the joining procedure. This includes a mechanism to 269 assign a unique 16-bit address to a mote, and the management of 270 initial keying material. 272 4. Define a mechanism to secure the joining process and the 273 subsequent optional process of scheduling more communication 274 links. 276 3.2. Network Maintenance 278 Once a network is formed, 6TiSCH needs to maintain the network's 279 health, allowing for motes to stay synchronized. 6TiSCH needs to: 281 1. Manage each mote's time source neighbor. 283 2. Define a mechanism for a mote to update the join priority it 284 announces in its Enhanced Beacon. 286 3. Schedule transmissions of Enhanced Beacons to advertise the 287 presence of the network. 289 3.3. Multi-Hop Topology 291 RPL, given a weighted connectivity graph, determines multi-hop 292 routes. 6TiSCH needs to: 294 1. Define a mechanism to gather topological information, which it 295 can then feed to RPL. 297 2. Ensure that the TSCH schedule contains links along the multi-hop 298 routes identified by RPL. 300 3. Where applicable, maintain independent sets of links to transport 301 independent flows of data. 303 3.4. Routing and Timing Parents 305 At all times, a TSCH mote needs to have a time source neighbor it can 306 synchronize to. 6TiSCH therefore needs to assign a time source 307 neighbor to allow for correct operation of the TSCH network. A time 308 source neighbors could, or not, be taken from the RPL routing parent 309 set. 311 3.5. Resource Management 313 A link in a TSCH schedule is a "unit" of resource. The number of 314 links to assign between neighbor motes needs to be appropriate for 315 the size of the traffic flow. 6TiSCH needs to: 317 1. Define rules on when to create or delete a slotframe. 319 2. Define rules to determine the length of a slotframe, and the 320 trigger to modify the length of a slotframe. 322 3. Define rules on when to add or delete links in a particular 323 slotframe. 325 4. Define a mechanism for neighbor nodes to exchange information 326 about their schedule and, if applicable, negotiate the addition/ 327 deletion of links. 329 5. Allow for an entity (e.g., a set of devices, a distributed 330 protocol, a PCE, etc.) to take control of the schedule. 332 6. Define a set of metrics to evaluate the trade-off between 333 latency, bandwidth and energy consumption achieved by a 334 particular schedule. 336 3.6. Dataflow Control 338 TSCH defines mechanisms for a mote to signal it cannot accept an 339 incoming packet. It does not, however, define the policy which 340 determines when to stop accepting packets. 6TiSCH needs to: 342 1. Define a queueing policy for incoming and outgoing packets. 344 2. Manage the buffer space, and indicate to TSCH when to stop 345 accepting incoming packets. 347 3. Handle transmissions that have failed. A transmission is 348 declared failed when TSCH has retransmitted the packet multiple 349 times, without receiving an acknowledgement. This covers both 350 dedicated and shared links. 352 3.7. Deterministic Behavior 354 As highlighted in [RFC5673], in some applications, data is generated 355 periodically and has a well understood data bandwidth requirement, 356 which is deterministic and predictable. 6TiSCH needs to: 358 1. Ensure timely delivery of such data. 360 2. Provide a mechanism for such deterministic flows to coexist with 361 bursty or infrequent traffic flows of different priorities. 363 3.8. Scheduling Mechanisms 365 Several scheduling mechanisms can be envisioned, and possibly coexist 366 in the same network. For example, 367 [I-D.phinney-roll-rpl-industrial-applicability] describe how the 368 allocation of bandwidth can be optimized by an external Path 369 Computation Element (PCE). Alternatively, two neighbor nodes can 370 adapt the number of cells autonomously by monitoring the amount of 371 traffic, and negotiating the allocation to extra cell when needed. 372 This mechanism can be used to establish multi-hop paths in a fashion 373 similar to RSVP. 6TiSCH needs to: 375 1. Provide a mechanism for two 6TiSCH devices to negotiate the 376 allocation and deallocation of cells between them. 378 2. Provide a mechanism for device to monitor and manage the 6TiSCH 379 capabilities of a node several hops away. 381 3. Define an mechanism for these different scheduling mechanisms to 382 coexist in the same network. 384 3.9. Secure Communication 386 Given some keying material, TSCH defines mechanisms to encrypt and 387 authenticate MAC frames. It does not define how this keying material 388 is generated. 6TiSCH needs to: 390 1. Define the keying material and authentication mechanism needed by 391 a new mote to join an existing network. 393 2. Define a mechanism to allow for the secure transfer of 394 application data between neighbor motes. 396 3. Define a mechanism to allow for the secure transfer of signalling 397 data between motes and 6TiSCH. 399 4. Acknowledgements 401 Special thanks to Jonathan Simon for his review and valuable 402 comments. Thanks to the IoT6 European Project (STREP) of the 7th 403 Framework Program (Grant 288445). 405 5. References 407 5.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 5.2. Informative References 414 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 415 Networks", RFC 2464, December 1998. 417 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 418 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 419 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 420 RFC 3819, July 2004. 422 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 423 over Low-Power Wireless Personal Area Networks (6LoWPANs): 424 Overview, Assumptions, Problem Statement, and Goals", RFC 425 4919, August 2007. 427 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 428 "Transmission of IPv6 Packets over IEEE 802.15.4 429 Networks", RFC 4944, September 2007. 431 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 432 "Routing Requirements for Urban Low-Power and Lossy 433 Networks", RFC 5548, May 2009. 435 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 436 Routing Requirements in Low-Power and Lossy Networks", RFC 437 5826, April 2010. 439 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 440 "Building Automation Routing Requirements in Low-Power and 441 Lossy Networks", RFC 5867, June 2010. 443 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 444 "Industrial Routing Requirements in Low-Power and Lossy 445 Networks", RFC 5673, October 2009. 447 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 448 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 449 September 2011. 451 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 452 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 453 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 454 Lossy Networks", RFC 6550, March 2012. 456 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 457 Application Spaces for IPv6 over Low-Power Wireless 458 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 460 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 461 Statement and Requirements for IPv6 over Low-Power 462 Wireless Personal Area Network (6LoWPAN) Routing", RFC 463 6606, May 2012. 465 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 466 for OAuth", RFC 6755, October 2012. 468 [I-D.wang-6tsch-6top] 469 Wang, Q., Vilajosana, X., and T. Watteyne, "6TSCH 470 Operation Sublayer (6top)", draft-wang-6tsch-6top-00 (work 471 in progress), July 2013. 473 [I-D.palattella-6tisch-terminology] 474 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 475 "Terminology in IPv6 over the TSCH mode of IEEE 476 802.15.4e", draft-palattella-6tisch-terminology-00 (work 477 in progress), October 2013. 479 [I-D.thubert-roll-forwarding-frags] 480 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 481 Recovery", draft-thubert-roll-forwarding-frags-02 (work in 482 progress), September 2013. 484 [I-D.tsao-roll-security-framework] 485 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 486 Security Framework for Routing over Low Power and Lossy 487 Networks", draft-tsao-roll-security-framework-02 (work in 488 progress), March 2010. 490 [I-D.thubert-roll-asymlink] 491 Thubert, P., "RPL adaptation for asymmetrical links", 492 draft-thubert-roll-asymlink-02 (work in progress), 493 December 2011. 495 [I-D.ietf-roll-terminology] 496 Vasseur, J., "Terms used in Routing for Low power And 497 Lossy Networks", draft-ietf-roll-terminology-13 (work in 498 progress), October 2013. 500 [I-D.ietf-roll-p2p-rpl] 501 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 502 Martocci, "Reactive Discovery of Point-to-Point Routes in 503 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17 504 (work in progress), March 2013. 506 [I-D.ietf-roll-trickle-mcast] 507 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 508 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 509 mcast-05 (work in progress), August 2013. 511 [I-D.thubert-6lowpan-backbone-router] 512 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 513 6lowpan-backbone-router-03 (work in progress), February 514 2013. 516 [I-D.sarikaya-core-sbootstrapping] 517 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 518 Cragie, "Security Bootstrapping Solution for Resource- 519 Constrained Devices", draft-sarikaya-core- 520 sbootstrapping-04 (work in progress), April 2012. 522 [I-D.gilger-smart-object-security-workshop] 523 Gilger, J. and H. Tschofenig, "Report from the 'Smart 524 Object Security Workshop', 23rd March 2012, Paris, 525 France", draft-gilger-smart-object-security-workshop-00 526 (work in progress), October 2012. 528 [I-D.phinney-roll-rpl-industrial-applicability] 529 Phinney, T., Thubert, P., and R. Assimiti, "RPL 530 applicability in industrial networks", draft-phinney-roll- 531 rpl-industrial-applicability-02 (work in progress), 532 February 2013. 534 [I-D.ietf-core-coap] 535 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 536 Application Protocol (CoAP)", draft-ietf-core-coap-18 537 (work in progress), June 2013. 539 5.3. External Informative References 541 [IEEE802154e] 542 IEEE standard for Information Technology, "IEEE std. 543 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 544 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 545 2012. 547 [IEEE802154] 548 IEEE standard for Information Technology, "IEEE std. 549 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 550 and Physical Layer (PHY) Specifications for Low-Rate 551 Wireless Personal Area Networks", June 2011. 553 [OpenWSN] , "Berkeley's OpenWSN Project Homepage", 554 . 556 [OpenWSNETT] 557 Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 558 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 559 a standards-based low-power wireless development 560 environment", Transactions on Emerging Telecommunications 561 Technologies 2012, August 2012, . 564 [IPSO] , "IP for Smart Objects Alliance Homepage", 565 . 567 [CurrentCalculator] 568 Linear Technology, "Application Note: Using the Current 569 Calculator to Estimate Mote Power", August 2012, . 573 [doherty07channel] 574 Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific 575 Wireless Sensor Network Path Data", IEEE International 576 Conference on Computer Communications and Networks (ICCCN) 577 2008, 2007. 579 [tinka10decentralized] 580 Tinka, A., Watteyne, T., and K. Pister, "A Decentralized 581 Scheduling Algorithm for Time Synchronized Channel 582 Hopping", Ad Hoc Networks 2010, 2010, < http:// 583 robotics.eecs.berkeley.edu/~pister/publications/2008/ 584 TSMP%20DSN08.pdf>. 586 [watteyne09reliability] 587 Watteyne, T., Mehta, A., and K. Pister, "Reliability 588 Through Frequency Diversity: Why Channel Hopping Makes 589 Sense", International Conference on Performance Evaluation 590 of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE- 591 WASUN) 2009, Oct. 2009, . 594 [kerkez09feasibility] 595 Kerkez, B., Watteyne, T., and M. Magliocco, "Feasibility 596 analysis of controller design for adaptive channel 597 hopping", International Workshop on Performance 598 Methodologies and Tools for Wireless Sensor Networks 599 (WSNPERF) 2009, Oct. 2009, . 603 [TASA-PIMRC] 604 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 605 and G. Boggia, "Traffic Aware Scheduling Algorithm for 606 Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept. 607 2012, < http://www.cttc.es/resources/doc/120531-submitted- 608 tasa-25511.pdf>. 610 [TASA-SENSORS] 611 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 612 and G. Boggia, "Traffic-Aware Time-Critical Scheduling In 613 Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT", 614 IEEE SENSORS 2012, Oct. 2012, < http://www.cttc.es/ 615 resources/doc/120821-sensors2012-4396981770946977737.pdf>. 617 [TASA-WCNC] 618 Accettura, N., Palattella, MR., Dohler, M., Grieco, LA., 619 and G. Boggia, "Standardized Power-Efficient and Internet- 620 Enabled Communication Stack for Capillary M2M Networks", 621 IEEE WCNC 2012, Apr. 2012, < http://www.cttc.es/resources/ 622 doc/120109-1569521283-submitted-58230.pdf>. 624 [palattella12standardized] 625 Palattella, MR., Accettura, N., Vilajosana, X., Watteyne, 626 T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized 627 Protocol Stack For The Internet Of (Important) Things", 628 IEEE Communications Surveys and Tutorials 2012, Dec. 2012, 629 < http://www.cttc.es/resources/doc/121025 630 -completestackforiot-clean-4818610916636121981.pdf>. 632 [PANA] Kanda, M., Ohba, Y., Das, S., and S. Chasko, "PANA 633 applicability in constrained environments", Febr. 2012, 634 . 637 Appendix A. TSCH Protocol Highlights 639 This appendix gives an overview of the key features of the 640 IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes 641 no attempt at repeating the standard, but rather focuses on the 642 following: 644 o Concepts which are sufficiently different from traditional 645 IEEE802.15.4 networking that they may need to be defined and 646 presented precisely. 648 o Techniques and ideas which are part of IEEE802.15.4e and which 649 might be useful for the work of the 6TiSCH WG. 651 A.1. Timeslots 653 All motes in a TSCH network are synchronized. Time is sliced up into 654 timeslots. A timeslot is long enough for a MAC frame of maximum size 655 to be sent from mote A to mote B, and for mote B to reply with an 656 acknowledgement (ACK) frame indicating successful reception. 658 The duration of a timeslot is not defined by the standard. With 659 IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band, 660 a maximum-length frame of 127 bytes takes about 4ms to transmit; a 661 shorter ACK takes about 1ms. With a 10ms slot (a typical duration), 662 this leaves 5ms to radio turnaround, packet processing and security 663 operations. 665 A.2. Slotframes 667 Timeslots are grouped into one of more slotframes. A slotframe 668 continuously repeats over time. TSCH does not impose a slotframe 669 size. Depending on the application needs, these can range from 10s 670 to 1000s of timeslots. The shorter the slotframe, the more often a 671 timeslot repeats, resulting in more available bandwidth, but also in 672 a higher power consumption. 674 A.3. Node TSCH Schedule 676 A TSCH schedule instructs each mote what to do in each timeslot: 677 transmit, receive or sleep. The schedule indicates, for each 678 scheduled (transmit or receive) cell a channelOffset and the address 679 of the neighbor to communicate with. 681 Once a mote obtains its schedule, it executes it: 683 o For each transmit cell, the mote checks whether there is a packet 684 in the outgoing buffer which matches the neighbor written in the 685 schedule information for that timeslot. If there is none, the 686 mote keeps its radio off for the duration of the timeslot. If 687 there is one, the mote can ask for the neighbor to acknowledge it, 688 in which case it has to listen for the acknowledgement after 689 transmitting. 691 o For each receive cell, the mote listens for possible incoming 692 packets. If none is received after some listening period, it 693 shuts down its radio. If a packet is received, addressed to the 694 mote, and passes security checks, the mote can send back an 695 acknowledgement. 697 How the schedule is built, updated and maintained, and by which 698 entity, is outside of the scope of the IEEE802.15.4e standard. 700 A.4. Cells and Bundles 702 Assuming the schedule is well built, if mote A is scheduled to 703 transmit to mote B at slotOffset 5 and channelOffset 11, mote B will 704 be scheduled to receive from mote A at the same slotOffset and 705 channelOffset. 707 A single element of the schedule characterized by a slotOffset and 708 channelOffset, and reserved for mote A to transmit to mote B (or for 709 mote B to receive from mote A) within a given slotframe, is called a 710 "scheduled cell". 712 If there is a lot of data flowing from mote A to mote B, the schedule 713 might contain multiple cells from A to B, at different times. 714 Multiple cells scheduled to the same neighbor can be equivalent, i.e. 715 the MAC layer sends the packet on whichever of these cells happens to 716 show up first after the packet was put in the MAC queue. The union 717 of all cells between two neighbors, A and B, is called a "bundle". 718 Since the slotframe repeats over time (and the length of the 719 slotframe is typically constant), each cell gives a "quantum" of 720 bandwidth to a given neighbor. Modifying the number of equivalent 721 cells in a bundle modifies the amount of resources allocated between 722 two neighbors. 724 A.5. Dedicated vs. Shared Cells 726 By default, each scheduled transmit cell within the TSCH schedule is 727 dedicated, i.e., reserved only for mote A to transmit to mote B. 728 IEEE802.15.4e allows also to mark a cell as shared. In a shared 729 cell, multiple motes can transmit at the same time, on the same 730 frequency. To avoid contention, TSCH defines a back-off algorithm 731 for shared cells. 733 A scheduled cell can be marked as both transmitting and receiving. 734 In this case, a mote transmits if it has an appropriate packet in its 735 output buffer, or listens otherwise. Marking a cell as 736 [transmit,shared,receive] results in slotted-Aloha behavior. 738 A.6. Absolute Slot Number 740 TSCH defines a timeslot counter called Absolute Slot Number (ASN). 741 When a new network is created, the ASN is initialized to 0; from then 742 on, it increments by 1 at each timeslot. In detail: 744 ASN = (k*S+t) 746 where k is the slotframe cycle (i.e., the number of slotframe 747 repetitions since the network was started), S the slotframe size and 748 t the slotOffset. A mote learns the current ASN when it joins the 749 network. Since motes are synchronized, they all know the current 750 value of the ASN, at any time. The ASN is encoded as a 5-byte 751 number: this allows it to increment for hundreds of years (the exact 752 value depends on the duration of a timeslot) without wrapping. The 753 ASN is used to calculate the frequency to communicate on, and can be 754 used for security-related operations. 756 A.7. Channel Hopping 758 For each scheduled cell, the schedule specifies a slotOffset and a 759 channelOffset. In a well-built schedule, when mote A has a transmit 760 cell to mote B on channelOffset 5, mote B has a receive cell from 761 mote A on the same channelOffset. The channelOffset is translated by 762 both nodes into a frequency using the following function: 764 frequency = F {(ASN + channelOffset) mod nFreq} 766 The function F consists of a look-up table containing the set of 767 available channels. The value nFreq (the number of available 768 frequencies) is the size of this look-up table. There are as many 769 channelOffset values as there are frequencies available (e.g. 16 when 770 using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are 771 used). Since both motes have the same channelOffset written in their 772 schedule for that scheduled cell, and the same ASN counter, they 773 compute the same frequency. At the next iteration (cycle) of the 774 slotframe, however, while the channelOffset is the same, the ASN has 775 changed, resulting in the computation of a different frequency. 777 This results in "channel hopping": even with a static schedule, pairs 778 of neighbors "hop" between the different frequencies when 779 communicating. Channel hopping is a technique known to efficiently 780 combat multi-path fading and external interference. 782 A.8. Time Synchronization 784 Because of the slotted nature of communication in a TSCH network, 785 motes have to maintain tight synchronization. All motes are assumed 786 to be equipped with clocks to keep track of time. Yet, because 787 clocks in different motes drift with respect to one another, neighbor 788 motes need to periodically re-synchronize. 790 Each mote needs to periodically synchronize its network clock to 791 another mote, and it also provides its network time to its neighbors. 792 It is up to the entity that manages the schedule to assign an 793 adequate time source neighbor to each mote, i.e., to indicate in the 794 schedule which of neighbor is its "time source neighbor". While 795 setting the time source neighbor, it is important to avoid 796 synchronization loops, which could result in the formation of 797 independent clusters of motes. 799 TSCH adds timing information in all packets that are exchanged (both 800 data and ACK frames). This means that neighbor motes can 801 resynchronize to one another whenever they exchange data. In detail, 802 in the IEEE 802.15.4e standard two methods are defined for allowing a 803 device to synchronize in a TSCH network: (i) Acknowledgement-Based 804 and (ii) Frame-Based synchronization. In both cases, the receiver 805 calculates the difference in time between the expected time of frame 806 arrival and its actual arrival. In Acknowledgement-Based 807 synchronization, the receiver provides such information to the sender 808 mote in its acknowledgement. Thus, in this case, it is the sender 809 mote that synchronizes to the clock of the receiver. In Frame-Based 810 synchronization, the receiver uses the computed delta for adjusting 811 its own clock. Therefore, it is the receiver mote that synchronizes 812 to the clock of the sender. 814 Different synchronization policies are possible. Motes can keep 815 synchronization exclusively by exchanging EBs. Motes can also keep 816 synchronized by periodically sending valid frames to a time source 817 neighbor and use the acknowledgement to resynchronize. Both method 818 (or a combination thereof) are valid synchronization policies; which 819 one to use depends on network requirements. 821 A.9. Power Consumption 823 There are only a handful of activities a mote can perform during a 824 timeslot: transmit, receive, or sleep. Each of these operations has 825 some energy cost associated to them, the exact value depending on the 826 the hardware used. Given the schedule of a mote, it is 827 straightforward to calculate the expected average power consumption 828 of that mote. 830 A.10. Network TSCH Schedule 832 The schedule defines entirely the synchronization and communication 833 between motes. By adding/removing cells between neighbors, one can 834 adapt a schedule to the needs of the application. Intuitive examples 835 are: 837 o Make the schedule "sparse" for applications where motes need to 838 consume as little energy as possible, at the price of reduced 839 bandwidth. 841 o Make the schedule "dense" for applications where motes generate a 842 lot of data, at the price of increased power consumption. 844 o Add more cells along a multi-hop route over which many packets 845 flow. 847 A.11. Join Process 849 Motes already part of the network can periodically send Enhanced 850 Beacon (EB) frames to announce the presence the network. These 851 contain information about the size of the timeslot used in the 852 network, the current ASN, information about the slotframes and 853 timeslots the beaconing mote is listening on, and a 1-byte join 854 priority. Because of the channel hopping nature of TSCH, these EB 855 frames are sent on all frequencies. 857 A mote wishing to join the network listens for EBs. Using the ASN 858 and the other timing information of the EB, the new mote synchronizes 859 to the network. Using the slotframe and link information from the 860 EB, it knows how to contact the network. 862 The IEEE802.15.4e TSCH standard does not define the steps beyond this 863 network "bootstrap". 865 A.12. Information Elements 867 TSCH introduces the concept of Information Elements (IEs). An 868 information element is a list of Type-Length-Value containers placed 869 at the end of the MAC header. A small number of types are defined 870 for TSCH (e.g., the ASN in the EB is contained in an IE), and an 871 unmanaged range is available for extensions. 873 A data bit in the MAC header indicates whether the frame contains 874 IEs. IEs are grouped into Header IEs, consumed by the MAC layer and 875 therefore typically invisible to the next higher layer, and Payload 876 IEs, which are passed untouched to the next higher layer, possibly 877 followed by regular payload. Payload IEs can therefore be used for 878 the next higher layers of two neighbor motes to exchange information. 880 A.13. Extensibility 882 The TSCH standard is designed to be extensible. It introduces the 883 mechanisms as "building block" (e.g., cells, bundles, slotframes, 884 etc.), but leaves entire freedom to the upper layer to assemble 885 those. The MAC protocol can be extended by defining new Header IEs. 886 An intermediate layer can be defined to manage the MAC layer by 887 defining new Payload IEs. 889 Appendix B. TSCH Gotchas 891 This section lists features of TSCH which we believe are important 892 and beneficial to the work of 6TiSCH. 894 B.1. Collision Free Communication 896 TSCH allows one to design a schedule which yields collision-free 897 communication. This is done by building the schedule with dedicated 898 cells in such a way that at most one node can communicate with a 899 specific neighbor in each slotOffset/channelOffset cell. Multiple 900 pairs of neighbor motes can exchange data at the same time, but on 901 different frequencies. 903 B.2. Multi-Channel vs. Channel Hopping 904 A TSCH schedule looks like a matrix of width "slotframe size", S, and 905 of height "number of frequencies", nFreq. For a scheduling 906 algorithm, these can be considered atomic "units" to schedule. In 907 particular, because of the channel hopping nature of TSCH, the 908 scheduling algorithm should not worry about the actual frequency 909 communication happens on, since it changes at each slotframe 910 iteration. 912 B.3. Cost of (continuous) Synchronization 914 When there is traffic in the network, motes which are communicating 915 implicitly re-synchronize using the data frames they exchange. In 916 the absence of data traffic, motes are required to synchronize to 917 their time source neighbor(s) periodically not to drift in time. If 918 they have not been communicating for some time (typically 30s), motes 919 can exchange an dummy data frame to re-synchronize. The frequency at 920 which such messages need to be transmitted depends on the stability 921 of the clock source, and on how "early" each mote starts listening 922 for data (the "guard time"). Theoretically, with a 10ppm clock and a 923 1ms guard time, this period can be 100s. Assuming this exchange 924 causes the mote's radio to be on for 5ms, this yields a radio duty 925 cycle needed to keep synchronized of 5ms/100s=0.005%. While TSCH does 926 requires motes to resynchronize periodically, the cost of doing so is 927 very low. 929 B.4. Topology Stability 931 The channel hopping nature of TSCH causes links to be very "stable". 932 Wireless phenomena such as multi-path fading and external 933 interference impact a wireless link between two motes differently on 934 each frequency. If a transmission from mote A to mote B fails, 935 retransmitting on a different frequency has a higher likelihood of 936 succeeding that retransmitting on the same frequency. As a result, 937 even when some frequencies are "behaving bad", channel hopping 938 "smoothens" the contribution of each frequency, resulting in more 939 stable links, and therefore a more stable topology. 941 B.5. Multiple Concurrent Slotframes 943 The TSCH standard allows for multiple slotframes to coexist in a 944 mote's schedule. It is possible that at some timeslot, a mote has 945 multiple activities scheduled (e.g. transmit to mote B on slotframe 946 2, receive from mote C on slotframe 1). To handle this situation, 947 the TSCH standard defines the following precedence rules: 949 1. Transmissions take precedence over receptions; 950 2. Lower slotframe identifiers take precedence over higher slotframe 951 identifiers. 953 In the example above, the mote would transmit to mote B on slotframe 954 2. 956 Authors' Addresses 958 Thomas Watteyne (editor) 959 Linear Technology 960 30695 Huntwood Avenue 961 Hayward, CA 94544 962 USA 964 Phone: +1 (510) 400-2978 965 Email: twatteyne@linear.com 967 Maria Rita Palattella 968 University of Luxembourg 969 Interdisciplinary Centre for Security, Reliability and Trust 970 4, rue Alphonse Weicker 971 Luxembourg L-2721 972 LUXEMBOURG 974 Phone: +352 46 66 44 5841 975 Email: maria-rita.palattella@uni.lu 977 Luigi Alfredo Grieco 978 Politecnico di Bari 979 Department of Electrical and Information Engineering 980 Via Orabona 4 981 Bari 70125 982 Italy 984 Phone: +39 08 05 96 3911 985 Email: a.grieco@poliba.it