idnits 2.17.1 draft-watteyne-6tsch-tsch-lln-context-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 (February 8, 2013) is 4093 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 504, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 510, but not defined == Missing Reference: 'WHART' is mentioned on line 516, but not defined == Missing Reference: 'ISA100' is mentioned on line 520, but not defined == Missing Reference: 'Emerson' is mentioned on line 524, but not defined == Missing Reference: 'CurrentCalculator' is mentioned on line 543, but not defined == Missing Reference: 'Doherty' is mentioned on line 125, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 529, but not defined == Missing Reference: 'OpenWSNETT' is mentioned on line 532, but not defined == Missing Reference: 'IPSO' is mentioned on line 540, but not defined == Missing Reference: 'TSMP' is mentioned on line 556, but not defined == Missing Reference: 'TASA-PIMRC' is mentioned on line 586, but not defined == Missing Reference: 'TASA-SENSORS' is mentioned on line 593, but not defined == Missing Reference: 'TASA-WCNC' is mentioned on line 600, but not defined == Missing Reference: 'PANA' is mentioned on line 615, but not defined == Unused Reference: 'RFC2119' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is defined on line 491, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-thubert-roll-forwarding-frags-00 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-10 == 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-03 == Outdated reference: A later version (-03) exists of draft-thubert-6lowpan-backbone-router-02 == 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 (-02) exists of draft-phinney-roll-rpl-industrial-applicability-01 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-13 Summary: 2 errors (**), 0 flaws (~~), 36 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH T. Watteyne, Ed. 3 Internet-Draft Linear Technology 4 Intended status: Informational February 8, 2013 5 Expires: August 12, 2013 7 Using IEEE802.15.4e TSCH in an LLN context: 8 Overview, Problem Statement and Goals 9 draft-watteyne-6tsch-tsch-lln-context-00 11 Abstract 13 This document describes the environment, problem statement, and goals 14 for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. 15 The set of goals enumerated in this document form an initial set 16 only. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 12, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 5 54 3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7 56 3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7 57 3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . . 8 58 3.4. Routing and Timing Parents . . . . . . . . . . . . . . . . 8 59 3.5. Resource Management . . . . . . . . . . . . . . . . . . . 8 60 3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . . 9 61 3.7. Secure Communication . . . . . . . . . . . . . . . . . . . 9 62 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 67 6.3. External Informative References . . . . . . . . . . . . . 14 68 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 18 69 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 18 70 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . . 18 71 A.3. Mote Communication Schedule . . . . . . . . . . . . . . . 18 72 A.4. Links and Paths . . . . . . . . . . . . . . . . . . . . . 19 73 A.5. Dedicated vs. Shared Slots . . . . . . . . . . . . . . . . 19 74 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . . 20 75 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 20 76 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . . 21 77 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 21 78 A.10. Network Communication Schedule . . . . . . . . . . . . . . 21 79 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . . 22 80 A.12. Information Elements . . . . . . . . . . . . . . . . . . . 22 81 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 23 82 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 24 83 B.1. Collision Free Communication . . . . . . . . . . . . . . . 24 84 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 24 85 B.3. Cost of (continuous) Synchronization . . . . . . . . . . . 24 86 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . . 24 87 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . . 25 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 1. Introduction 92 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an 93 amendment to the Medium Access Control (MAC) protocol of the 94 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel 95 Hopping (TSCH) mode of the IEEE802.15.4e standard is the object of 96 this document. 98 TSCH was designed to "allow IEEE802.15.4 devices to support a wide 99 range of industrial applications" [IEEE802154e]. At its core is a 100 medium access technique which uses time synchronization to achieve 101 ultra low-power operation and channel hopping to enable high 102 reliability. This is very different from the "legacy" IEEE802.15.4 103 MAC protocol, and is therefore better described as a "redesign". 104 TSCH does not amend the physical layer; i.e. it can operate on any 105 IEEE802.15.4-compliant hardware. 107 IEEE802.15.4e can be seen as the latest generation of ultra-lower 108 power and reliable networking solutions for LLNs. Its core 109 technology is similar to the one used in industrial networking 110 technologies such as WirelessHART [WHART] or ISA100.11a [ISA100]. 111 These protocol solutions have been targeted essentially at the 112 industrial market. WirelessHART is for example the wireless 113 extension of HART, a long standing protocol suite for networking 114 industrial equipment. 116 [RFC5673] discusses industrial applications, and highlights the harsh 117 operating conditions as well as the stringent reliability, 118 availability and security requirements for an LLN to operate in an 119 industrial environment. Industrial protocols such as WirelessHART 120 satisfy those requirements, and with tens of thousands of networks 121 deployed [Emerson], these types of networks have a large impact on 122 industrial applications. Commercial networking solutions are 123 available today in which motes consume 10's of micro-amps on average 124 [CurrentCalculator] with end-to-end packet delivery ratios over 125 99.999% [Doherty]. 127 IEEE802.15.4e builds on the same foundations as WirelessHART, and 128 therefore exhibits similar performance. Yet, unlike an industrial 129 protocol which is, by nature, application-specific, IEEE802.15.4e 130 TSCH focuses on the MAC layer only. This clean layering allows for 131 TSCH to fit under an IPv6 enabled protocol stack for LLNs, running 132 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP [I-D.ietf-core-coap]. 134 Bringing industrial-like performance into the LLN stack developed by 135 the 6LoWPAN, ROLL and CORE working groups will open up new 136 application domains for these networks. Sensors deployed in smart 137 cities [RFC5548] will be able to be installed for years without 138 needing battery replacement. "Umbrella" networks will interconnect 139 smart elements from different entities in smart buildings [RFC5867]. 140 Peel-and-stick switches will obsolete the need for costly conduits 141 for lighting solutions in smart homes [RFC5826]. 143 While [IEEE802154e] defines the mechanisms for a TSCH mote to 144 communicate, it does not define the policies to build and maintain 145 the communication schedule, match that schedule to the multi-hop 146 paths maintained by RPL, adapt the resources allocated between 147 neighbor nodes to the data traffic flows, enforce a differentiated 148 treatment for data generated at the application layer and signaling 149 messages needed by 6LoWPAN and RPL to discover neighbors, react to 150 topology changes, self-configuring IP addresses, or manage keying 151 material. 153 2. TSCH in the LLN Context 155 In many cases, to map the services required by the IP layer to the 156 services provided by the link layer, an adaptation layer is used 157 [palattella12standardized]. The 6LoWPAN working group has started in 158 2007 to work on specifications for transmitting IPv6 over 159 IEEE802.15.4 networks [RFC4919]. Typically, low-power WPANs are 160 characterized by small packet sizes, support for addresses with 161 different lengths, low bandwidth, star and mesh topologies, battery 162 powered devices, low cost, large number of devices, unknown node 163 positions, high unreliability, and periods during which communication 164 interfaces are turned off to save energy. Given these features, it 165 is clear that the adoption of IPv6 on top of a Low-Power WPAN is not 166 straightforward, but poses strong requirements for the optimization 167 of this adaptation layer. For instance, due to the IPv6 default 168 minimum MTU size (1280 bytes), an un-fragmented IPv6 packet would be 169 too large to fit in an IEEE802.15.4 frame. Moreover, the overhead 170 due to the 40-byte long IPv6 header would waste the scarce bandwidth 171 available at the PHY layer [RFC4944]. For these reasons, the 6LoWPAN 172 working group has defined an effective adaptation layer [RFC6568]. 173 Further issues encompass the auto-configuration of IPv6 addresses 174 [RFC2464][RFC6755], the compliance with the recommendation on 175 supporting link-layer subnet broadcast in shared networks [RFC3819], 176 the reduction of routing and management overhead [RFC6606], the 177 adoption of lightweight application protocols (or novel data encoding 178 techniques), and the support for security mechanisms (confidentiality 179 and integrity protection, device bootstrapping, key establishment, 180 and management). 182 These features can run on top of TSCH. There are, however, important 183 issues to solve, as highlighted in Section 3. 185 Routing issues are challenging for 6LoWPAN, given the low-power and 186 lossy radio-links, the battery supplied nodes, the multi-hop mesh 187 topologies, and the frequent topology changes due to mobility. 188 Successful solutions take into account the specific application 189 requirements, along with IPv6 behavior and 6LoWPAN mechanisms 190 [palattella12standardized]. The ROLL working group has defined RPL 191 in [RFC6550]. RPL can support a wide variety of link layers, 192 including ones that are constrained, potentially lossy, or typically 193 utilized in conjunction with host or router devices with very limited 194 resources, as in building/home automation [RFC5867][RFC5826], 195 industrial environments [RFC5673], and urban applications [RFC5548]. 196 It is able to quickly build up network routes, to distribute routing 197 knowledge among nodes, and to adapt the topology. In a typical 198 setting, motes are connected through multi-hop paths to a small set 199 of root devices, which are usually responsible for data collection 200 and coordination duties. For each of them, a Destination Oriented 201 Directed Acyclic Graph (DODAG) is created by accounting for link 202 costs, node attributes/status information, and an Objective Function, 203 which maps the optimization requirements of the target scenario. The 204 topology is set-up based on a Rank metric, which encodes the distance 205 of each node with respect to its reference root, as specified by the 206 Objective Function. Regardless of the way it is computed, the Rank 207 monotonically decreases along the DODAG towards the destination, 208 following a gradient-based approach. RPL encompasses different kinds 209 of traffic and signaling information. Multipoint-to-Point (MP2P) is 210 the dominant traffic in LLN applications. Data is routed towards 211 nodes with some application relevance, such as the LLN gateway to the 212 larger Internet, or to the core of private IP networks. In general, 213 these destinations are the DODAG roots and they act as data 214 collection points for distributed monitoring applications. Point-to- 215 Multipoint (P2MP) data streams are used for actuation purposes, where 216 messages are sent from DODAG roots to destination nodes. Point-to- 217 Point (P2P) traffic allows communication between two devices 218 belonging to the same LLN, e.g. a sensor and an actuator. A packet 219 will flow from the source towards the common ancestor of those two 220 communicating devices, then downward towards the destination. As an 221 consequence, RPL has to discover both upward routes (i.e., from nodes 222 to DODAG roots) in order to enable MP2P and P2P flows, and downward 223 routes (i.e., from DODAG roots to nodes) to support P2MP and P2P 224 traffic. 226 Section 3 highlights the challenges that need to be addressed to use 227 RPL on top of TSCH. 229 Several open-source initiatives have emerged around TSCH. The 230 OpenWSN project [OpenWSN][OpenWSNETT] is an open-source 231 implementation of a fully standards-based protocol stack, which aims 232 at evaluating the applicability of TSCH to different applications. 233 This implementation was used as the foundation for an IP for Smart 234 Objects Alliance (IPSO) [IPSO] iteroperability demo in 2011. In the 235 absence of a standardized scheduling mechanism for TSCH, a "slotted 236 Aloha" schedule was used. 238 3. Problems and Goals 240 As highlighted in Appendix A, TSCH is different for traditional low- 241 power MAC protocols because of its scheduled nature. TSCH defines 242 the mechanisms to execute a communication schedule, but it is the 243 entity that sets up that schedule which controls the topology of the 244 network, and the resources allocated to each link in that topology. 246 How this entity should operate is out of scope of TSCH. The 247 remainder of this section highlights the problems this entity needs 248 to address. For simplicity, we will refer to this entity by the 249 generic name "6TSCH", without loss of generality. In particular, we 250 do not assume the nature of 6TSCH, whether an adaptation layer, a 251 distributed reservation protocol, a centralized path computation 252 engine, or any combination thereof. 254 3.1. Network Formation 256 6TSCH needs to control the way the network is formed, including how 257 new motes join, and how already joined motes advertise the presence 258 of the network. 6TSCH needs to: 260 1. Define the Information Elements to include in Enhanced Beacons 261 advertising the presence of the network. 263 2. For a new mote, define rules to process and filter received 264 Enhanced Beacons. This includes a mechanism to select the best 265 mote to join the network through. 267 3. Define the joining procedure. This includes a mechanism to 268 assign a unique 16-bit address to a mote, and the management of 269 initial keying material. 271 3.2. Network Maintenance 273 Once a network is formed, 6TSCH needs to maintain the network's 274 health, allowing for motes to stay synchronized. 6TSCH needs to: 276 1. Manage each mote's time source neighbor(s). 278 2. Define a mechanism for a mote to update the join priority it 279 announces in its Enhanced Beacon. 281 3. Schedule transmissions of an Enhanced Beacon to advertise the 282 presence of the network. 284 3.3. Multi-Hop Topology 286 RPL, given a weighted connectivity graph, determines multi-hop 287 routes. 6TSCH needs to: 289 1. Define a mechanism whereby it gathers topological information, 290 which it can then feed to RPL. 292 2. Ensure that the TSCH schedule contains links along the multi-hop 293 routes identified by RPL. 295 3. Where applicable, maintain independent sets of links to transport 296 independent flows of data. 298 3.4. Routing and Timing Parents 300 At all times, a TSCH mote needs to have at least one time source 301 neighbor it can synchronize to. 6TSCH therefore needs to assign time 302 source neighbors to allow for correct operation of the TSCH network. 303 These time source neighbors could, or not, be related to RPL time 304 parents. 306 3.5. Resource Management 308 A link in a TSCH schedule is a "unit" of resource. The number of 309 links to assign between neighbor motes needs to be appropriate for 310 the size of the traffic flow. 6TSCH needs to: 312 1. Define rules on when to create or delete a slotframes. 314 2. Define rules to determine the length of a slotframe, and the 315 trigger to modify the length of a slotframe. 317 3. Define rules on when to add or delete links in a particular 318 slotframe. 320 4. Define a mechanism for neighbor nodes to exchange information 321 about their schedule and, if applicable, negotiate the addition/ 322 deletion of links. 324 5. Allow for a (possibly centralized) entity to take full control 325 over the schedule. 327 6. Define a set of metrics to evaluate the tradeoff between latency, 328 bandwidth and energy consumption achieved by a particular 329 schedule. 331 3.6. Dataflow Control 333 TSCH defines mechanisms for a mote to signal it cannot accept an 334 incoming packet. It does not, however, define the policy which 335 determines when not to accept. 6TSCH need to: 337 1. Define a queueing policy for incoming and outgoing packets. 339 2. Manage the buffer space and indicate to TSCH when to stop 340 accepting incoming packet. 342 3. Handle transmissions that have failed. 344 3.7. Secure Communication 346 Given some keying material, TSCH defines mechanisms to encrypt and 347 authenticate MAC frames. It does not define how this keying material 348 is generated. 6TSCH need to: 350 1. Define the keying material and authentication mechanism needed by 351 a new mote to join an existing network. 353 2. Define a mechanism to allow for the secure transfer of 354 application data between neighbor motes. 356 3. Define a mechanism to allow for the secure transfer of signaling 357 data between motes and 6TSCH. 359 4. Contributors 361 Maria Rita Palattella 362 SnT/University of Luxembourg 364 maria-rita.palattella@uni.lu 366 Luigi Alfredo Grieco 367 Politecnico di Bari 369 a.grieco@poliba.it 371 5. Acknowledgements 373 Special thanks to Jonathan Simon for his review and valuable 374 comments. 376 6. References 378 6.1. Normative References 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 6.2. Informative References 385 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 386 Networks", RFC 2464, December 1998. 388 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 389 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 390 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 391 RFC 3819, July 2004. 393 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 394 over Low-Power Wireless Personal Area Networks (6LoWPANs): 395 Overview, Assumptions, Problem Statement, and Goals", 396 RFC 4919, August 2007. 398 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 399 "Transmission of IPv6 Packets over IEEE 802.15.4 400 Networks", RFC 4944, September 2007. 402 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 403 "Routing Requirements for Urban Low-Power and Lossy 404 Networks", RFC 5548, May 2009. 406 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 407 Routing Requirements in Low-Power and Lossy Networks", 408 RFC 5826, April 2010. 410 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 411 "Building Automation Routing Requirements in Low-Power and 412 Lossy Networks", RFC 5867, June 2010. 414 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 415 "Industrial Routing Requirements in Low-Power and Lossy 416 Networks", RFC 5673, October 2009. 418 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 419 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 420 September 2011. 422 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 423 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 425 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 426 Lossy Networks", RFC 6550, March 2012. 428 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 429 Application Spaces for IPv6 over Low-Power Wireless 430 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 432 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 433 Statement and Requirements for IPv6 over Low-Power 434 Wireless Personal Area Network (6LoWPAN) Routing", 435 RFC 6606, May 2012. 437 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 438 for OAuth", RFC 6755, October 2012. 440 [I-D.thubert-roll-forwarding-frags] 441 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 442 Recovery", draft-thubert-roll-forwarding-frags-00 (work in 443 progress), March 2012. 445 [I-D.tsao-roll-security-framework] 446 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 447 Security Framework for Routing over Low Power and Lossy 448 Networks", draft-tsao-roll-security-framework-02 (work in 449 progress), March 2010. 451 [I-D.thubert-roll-asymlink] 452 Thubert, P., "RPL adaptation for asymmetrical links", 453 draft-thubert-roll-asymlink-02 (work in progress), 454 December 2011. 456 [I-D.ietf-roll-terminology] 457 Vasseur, J., "Terminology in Low power And Lossy 458 Networks", draft-ietf-roll-terminology-10 (work in 459 progress), January 2013. 461 [I-D.ietf-roll-p2p-rpl] 462 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 463 Martocci, "Reactive Discovery of Point-to-Point Routes in 464 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16 465 (work in progress), February 2013. 467 [I-D.ietf-roll-trickle-mcast] 468 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 469 and Lossy Networks (MPL)", 470 draft-ietf-roll-trickle-mcast-03 (work in progress), 471 January 2013. 473 [I-D.thubert-6lowpan-backbone-router] 474 Thubert, P., "6LoWPAN Backbone Router", 475 draft-thubert-6lowpan-backbone-router-02 (work in 476 progress), June 2010. 478 [I-D.sarikaya-core-sbootstrapping] 479 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 480 Cragie, "Security Bootstrapping Solution for Resource- 481 Constrained Devices", 482 draft-sarikaya-core-sbootstrapping-04 (work in progress), 483 April 2012. 485 [I-D.gilger-smart-object-security-workshop] 486 Gilger, J. and H. Tschofenig, "Report from the 'Smart 487 Object Security Workshop', 23rd March 2012, Paris, 488 France", draft-gilger-smart-object-security-workshop-00 489 (work in progress), October 2012. 491 [I-D.phinney-roll-rpl-industrial-applicability] 492 Phinney, T., Thubert, P., and R. Assimiti, "RPL 493 applicability in industrial networks", 494 draft-phinney-roll-rpl-industrial-applicability-01 (work 495 in progress), October 2012. 497 [I-D.ietf-core-coap] 498 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 499 "Constrained Application Protocol (CoAP)", 500 draft-ietf-core-coap-13 (work in progress), December 2012. 502 6.3. External Informative References 504 [IEEE802154e] 505 IEEE standard for Information Technology, "IEEE std. 506 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 507 Networks (LR-WPANs) Amendament 1: MAC sublayer", 508 April 2012. 510 [IEEE802154] 511 IEEE standard for Information Technology, "IEEE std. 512 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 513 and Physical Layer (PHY) Specifications for Low-Rate 514 Wireless Personal Area Networks", June 2011. 516 [WHART] www.hartcomm.org, "Highway Addressable Remote Transducer, 517 a group of specifications for industrial process and 518 control devices administered by the HART Foundation". 520 [ISA100] ISA, "ISA100, Wireless Systems for Automation", May 2008, 521 < http://www.isa.org/Community/ 522 SP100WirelessSystemsforAutomation>. 524 [Emerson] Emerson Process Management, "Emerson Process Management 525 Smart Wireless Homepage", < http:// 526 www2.emersonprocess.com/en-US/plantweb/wireless/Pages/ 527 WirelessHomePage-Flash.aspx>. 529 [OpenWSN] "Berkeley's OpenWSN Project Homepage", 530 . 532 [OpenWSNETT] 533 Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 534 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 535 a standards-based low-power wireless development 536 environment", Transactions on Emerging Telecommunications 537 Technologies 2012, August 2012, . 540 [IPSO] "IP for Smart Objects Alliance Homepage", 541 . 543 [CurrentCalculator] 544 Linear Technology, "Application Note: Using the Current 545 Calculator to Estimate Mote Power", August 2012, . 550 [doherty07channel] 551 Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific 552 Wireless Sensor Network Path Data", IEEE International 553 Conference on Computer Communications and Networks 554 (ICCCN) 2008, 2007. 556 [TSMP] Pister, K. and L. Doherty, "TSMP: Time Synchronized Mesh 557 Prootocol", International Symposium on Distributed Sensor 558 Networks (DSN) 2008, Nov. 2008, < http:// 559 robotics.eecs.berkeley.edu/~pister/publications/2008/ 560 TSMP%20DSN08.pdf>. 562 [tinka10decentralized] 563 Tinka, A., Watteyne, T., and K. Pister, "A Decentralized 564 Scheduling Algorithm for Time Synchronized Channel 565 Hopping", Ad Hoc Networks 2010, 2010, < http:// 566 robotics.eecs.berkeley.edu/~pister/publications/2008/ 567 TSMP%20DSN08.pdf>. 569 [watteyne09reliability] 570 Watteyne, T., Mehta, A., and K. Pister, "Reliability 571 Through Frequency Diversity: Why Channel Hopping Makes 572 Sense", International Conference on Performance Evaluation 573 of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE- 574 WASUN) 2009, Oct. 2009, . 577 [kerkez09feasibility] 578 Kerkez, B., Watteyne, T., and M. Magliocco, "Feasibility 579 analysis of controller design for adaptive channel 580 hopping", International Workshop on Performance 581 Methodologies and Tools for Wireless Sensor Networks 582 (WSNPERF) 2009, Oct. 2009, . 586 [TASA-PIMRC] 587 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 588 and G. Boggia, "Traffic Aware Scheduling Algorithm for 589 Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, 590 Sept. 2012, < http://www.cttc.es/resources/doc/ 591 120531-submitted-tasa-25511.pdf>. 593 [TASA-SENSORS] 594 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 595 and G. Boggia, "Traffic-Aware Time-Critical Scheduling In 596 Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT", 597 IEEE SENSORS 2012, Oct. 2012, < http://www.cttc.es/ 598 resources/doc/120821-sensors2012-4396981770946977737.pdf>. 600 [TASA-WCNC] 601 Accettura, N., Palattella, MR., Dohler, M., Grieco, LA., 602 and G. Boggia, "Standardized Power-Efficient and Internet- 603 Enabled Communication Stack for Capillary M2M Networks", 604 IEEE WCNC 2012, Apr. 2012, < http://www.cttc.es/resources/ 605 doc/120109-1569521283-submitted-58230.pdf>. 607 [palattella12standardized] 608 Palattella, MR., Accettura, N., Vilajosana, X., Watteyne, 609 T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized 610 Protocol Stack For The Internet Of (Important) Things", 611 IEEE Communications Surveys and Tutorials 2012, Dec. 2012, 612 < http://www.cttc.es/resources/doc/ 613 121025-completestackforiot-clean-4818610916636121981.pdf>. 615 [PANA] Kanda, M., Ohba, Y., Das, S., and S. Chasko, "PANA 616 applicability in constrained environments", Febr. 2012, . 620 Appendix A. TSCH Protocol Highlights 622 This appendix gives an overview of the key features of the 623 IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes 624 no attempt at repeating the standard, but rather focuses on the 625 following: 627 o Concepts which are sufficiently different from traditional 628 IEEE802.15.4 networking that they may need to be defined and 629 presented precisely. 631 o Techniques and ideas which are part of IEEE802.15.4e and which 632 might be useful for the work of 6TSCH. 634 A.1. Timeslots 636 All motes in a TSCH network are synchronized. Time is sliced up into 637 time slots. A time slot is long enough for a MAC frame of maximum 638 size to be sent from mote A to mote B, and for mote B to reply with 639 an acknowledgment (ACK) frame indicating successful reception. 641 The duration of a timeslot is not defined by the standard. With 642 IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band, 643 a maximum-length frame of 127 bytes takes about 4ms to transmit; a 644 shorter ACK takes about 1ms. With a 10ms slot (a typical duration), 645 this leaves 5ms to radio turnaround, packet processing and security 646 operations. 648 A.2. Slotframes 650 Timeslots are grouped into one of more slotframes. A slotframe 651 continuously repeats over time. TSCH does not impose any slotframe 652 size. Depending on the application needs, these can range from 10s 653 to 1000s of timeslots. The shorter the slotframe, the more often a 654 timeslot repeats, resulting in more available bandwidth, but also in 655 a higher power consumption. 657 A.3. Mote Communication Schedule 659 A communication schedule instructs each mote what to do in each slot: 660 transmit, receive or sleep. The schedule indicates, for each active 661 (transmit or receive) timeslot a channelOffset and the address of the 662 neighbor to communicate with. 664 Once a mote obtains its schedule, it executes it: 666 o For each transmit slot, the mote checks whether there is a packet 667 in the outgoing buffer which matches the neighbor written in the 668 schedule information for that slot. If there is none, the mote 669 keeps its radio off for the duration of the slot. If there is 670 one, the mote can ask for the neighbor to acknowledge it, in which 671 case it has to listen for the acknowledgment after the 672 transmission. 674 o For each receive slot, the mote listens for possible incoming 675 packets. If none is received after some listening period, it 676 shuts down its radio. If a packet is received, addressed to the 677 mote, and passes security checks, the mote typically sends back 678 and aknowledgment. 680 How the schedule is built, updated and maintained, and by which 681 entity, is outside of the scope of the IEEE802.15.4e standard. 683 A.4. Links and Paths 685 Assuming the schedule is well built, if mote A is scheduled to 686 transmit to mote B at slotOffset 5 and channelOffset 11, mote B will 687 be scheduled to receive from mote A at the same slotOffset and 688 channelOffset. 690 A single slot of the schedule (i.e., a single cell of the grid), 691 characterized by a slotOffset and channelOffset, and reserved for 692 mote A to transmit to mote B (or for mote B to receive from mote A), 693 is called a "link". 695 If there is a lot of data flowing from mote A to mote B, the schedule 696 might contain multiple slots from A to B, at different times. 697 Multiple links scheduled to the same neighbor are typically 698 equivalent, i.e. the MAC layer sends the packet on whichever of these 699 links happens to show up after the packet was put in the MAC queue. 700 The union of all links between two neighbors, A and B, is called a 701 "path". Since the slotframe repeats over time (and the length of the 702 slotframe is typically constant), each link gives a "quantum" of 703 bandwidth to a given neighbor. Modifying the number of links in a 704 path modify the amount of resources allocated between two neighbors. 706 A.5. Dedicated vs. Shared Slots 708 By default, each transmit timeslot within the TSCH schedule is 709 dedicated, i.e., reserved only for mote A to transmit to mote B. 710 IEEE802.15.4e allows also to mark a slot as shared. In a shared 711 slot, multiple motes can transmit at the same time, on the same 712 fequency. To avoid contention, TSCH defines a back-off algorithm for 713 shared slots. 715 A slot can be marked as both transmitting and receiving. In this 716 case, a mote transmits if it has an appropriate packet in its output 717 buffer, or listens otherwise. Marking a slot as 718 [transmit,shared,receive] results in slotted-Aloha behavior. 720 A.6. Absolute Slot Number 722 TSCH defines a timeslot counter called Absolute Slot Number (ASN). 723 When a new network is created, the ASN is initialized to 0; from then 724 on it increments by 1 at each timeslot. In detail: 726 ASN = (k*S+t) 728 where S is the slotframe size and k the slotframe cycle (i.e., the 729 number of slotframe occurences over time). A mote learns the current 730 ASN when it joins the network. Since motes are synchronized, they 731 all know the current value of the ASN, and any time. The ASN is 732 encoded as a 5-byte number: this allows it to increment for hundreds 733 of years (the exact value depends on the duration of a timeslot) 734 without wrapping. The ASN is used (i) to calculate the frequency to 735 communicate on, jointly with the channelOffset, (ii) to build unique 736 security nonce counters, when the CCM* mode is activated. 738 A.7. Channel Hopping 740 For each active slot, the schedule specifies a timeOffset and a 741 channelOffset. In a well-built schedule, when mote A has a transmit 742 slot to mote B on channelOffset 5, mote B has a receive slot from 743 mote A on the same channelOffset. The channelOffset, is translated 744 by both nodes into a frequency using the following function: 746 frequency = F {(ASN + channelOffset) mod nCh} 748 The function F consists of a look-up table containing the set of 749 available channels. The value nCh (the number of available 750 frequencies) is the size of this look-up table. There are as many 751 channelOffset values as there are frequencies available (e.g. 16 when 752 using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are 753 used). Since both motes have the same channelOffset written in their 754 schedule for that timeslot, and the same ASN counter since they are 755 synchronized, they compute the same frequency. At the next iteration 756 (cycle) of the slotframe, however, the channelOffset will be the 757 same, but the ASN will have changed, resulting in the computation of 758 a different frequency. If the slotframe size, S (used for computing 759 ASN), and the number of channel offsets, nCh, are relatively prime, 760 the translation function ensures that each link rotates through k 761 available channels over k slotframe cycles. This results in "channel 762 hopping": even with a static schedule, pairs of neighbors "hop" 763 between the different frequencies when communicating. 765 The look-up table F can be built to contain only a subset of all 766 available channels. This results in "blacklisting". 768 Channel hopping is a technique known to efficiently combat multi-path 769 fading and external interference. This results in a TSCH network 770 having a more stable topology than if only a single channel were used 771 for the entire network. 773 A.8. Time Synchronization 775 Because of the slotted nature of communication in a TSCH network, 776 motes have to maintain tight synchronization. All motes are assumed 777 to be equipped with clocks to keep track of time (32kHz crystal 778 oscillators are typically used). Yet, because clocks in different 779 motes drift with respect to one another, neighbor motes need to 780 periodically re-synchronize. 782 TSCH adds timing information in all packets that are exchanged (both 783 data and ACK frames). This means that neighbor motes can 784 resynchronize to one another whenever they exchange data. The 785 schedule of a mote indicates which of its neighbor(s) are its "time 786 source neighbors". When a mote communicates with one of its time 787 source neighbors, it uses the timing information in the exchanged 788 frames to realign its clock to its neighbor's. 790 It is up to the entity that manages the schedule to assign adequate 791 time source neighbor(s) to each mote. It is important to avoid 792 synchronization loops, which could result in the formation of 793 independent clusters of motes. 795 A.9. Power Consumption 797 There are only a handful of activities a mote can perform during a 798 timeslot: transmit, receive, or sleep. Depending on the the hardware 799 used, each of these operations has some energy cost associated to 800 them. Given the schedule of a mote, it is straighforward to 801 calculate the expected average power consumption of that mote. 803 A.10. Network Communication Schedule 805 The schedule defines entirely the synchronization and communication 806 between motes. By adding/removing link between neighbors, one can 807 adapt a schedule to the needs of the application. Intuitive examples 808 are: 810 o Make the schedule "sparse" for applications where motes need to 811 consume as little as possible, at the price of reduced bandwidth. 813 o Make the schedule "dense" for applications where motes generate a 814 lot of data, at the price of increased power consumption. 816 o Add more links along a multi-hop route over which many packets 817 flow. 819 A.11. Join Process 821 Motes already part of the network can periodically send Enhanced 822 Beacon (EB) frames to announce the presence the network. These 823 contain information about the size of the timeslot used in the 824 network, the current ASN, information about the slotframes and 825 timeslots the beaconing mote is listening on, and a 1-byte join 826 priority. This join priority corresponds to the number of hops 827 separating the mote sending the EB, and the PAN coordinator. Because 828 of the channel hopping nature of TSCH, these EB frames are sent on 829 all frequencies. 831 A mote wishing to join the network listens on some frequency for EBs. 832 It can wait to receive multiple, and can use the join priority in 833 those EBs to identify the best mote to join the network through. 834 Using the ASN and the other timing information of the EB, the new 835 mote synchronizes to the network. Using the slotframe and link 836 information from te EB, it knows how to contact the mote it just 837 joined. 839 The TSCH standard does not define the steps beyond this "kickstart". 840 These steps can include a security handshake and the addition of more 841 communication links to the new mote's schedule. 843 A.12. Information Elements 845 TSCH introduces the concept of Information Elements (IES). An 846 information element is a list of Type-Length-Value containers placed 847 at the end of the MAC header. A small number of types are defined 848 for TSCH (e.g., the ASN in the EB is contained in an IE), but an 849 unmanaged range is available for extensions. 851 A bit in the MAC header indicates whether the frame contains IEs. 852 IEs are grouped into Header IEs, consumed by the MAC layer and 853 therefore typically invisible to the next higher layer, and Payload 854 IEs, which are passed untouched to the next higher layer, possibly 855 followed by regular payload. Payload IEs can therefore be used for 856 the next higher layers of two neighbor motes to exchange information. 858 A.13. Extensibility 860 The TSCH standard is designed to be extensible. It introduces the 861 mechanisms as "building block" (e.g. links, frame, etc.), but leaves 862 entire freedom to the upper layer to assemble those. The MAC 863 protocol can be extended by defining new Header IEs. An intermediate 864 layer can be defined to manage the MAC layer by defining Payload IEs. 866 Appendix B. TSCH Gotchas 868 This section lists features of TSCH which we believe are important 869 and beneficial to the work of 6TSCH. 871 B.1. Collision Free Communication 873 TSCH allows you to easily design a schedule which yields collision- 874 free communication. This is done by building the schedule in such a 875 way that at most one link occupies each slotOffset/channelOffset 876 cell. Multiple pairs of neighbor motes can exchange data at the same 877 time, but on different frequencies. If a deployment is done over a 878 large area, slotOffset/channelOffset cells can be reused by pairs of 879 neigbors sufficiently far appart not to interfere. 881 B.2. Multi-Channel vs. Channel Hopping 883 A TSCH schedule looks like a matrix of width "slotFrame length" and 884 height "number of channels". For a scheduling algorithm, these can 885 be considered atomic "units" to schedule. In particular, because of 886 the channel hopping nature of TSCH, the scheduling algorithm should 887 not worry about the actual frequency communication happens on, since 888 it changes at each slotFrame iteration. 890 B.3. Cost of (continuous) Synchronization 892 In the absence of data traffic, a mote is required to synchronize to 893 its time source neighbor(s) periodically not to drift in time. The 894 period at which this needs to happen depends on the stability of the 895 clock source, and on how "early" each mote starts listening for data 896 (the "guard time"). Theoretically, with a 10ppm clock and a 1ms 897 guard time, this period can be 100s. Resynchronizing consists in 898 sending any valid frame to the time source neighbor and using the 899 timing information in the ACK to realign the clocks. If this 900 exchange causes the mote's radio to be on for 5ms, this yields a 901 radio duty cycle needed to keep synchronized of 5ms/100s=0.005%. 902 While TSCH does requires motes to resynchronize periodically, the 903 cost of doing so in almost negligible. 905 B.4. Topology Stability 907 The channel hopping nature of TSCH causes links to be very "stable". 908 Wireless phenomena such as multi-path fading and external 909 interference impact a wireless link between two motes differently on 910 each frequency. It a transmission from mote A to mote B fails, 911 retransmitting on a different frequency has a higher likelihood of 912 succeeding that retransmitting on the same frequency. As a result, 913 even when some frequencies are "behaving bad", channel hopping 914 "smoothens" the contribution of each frequency, resulting in more 915 stable links, and therefore a more stable topology. 917 B.5. Multiple Concurrent Slotframes 919 The TSCH standard allows for multiple slotframes to coexist in a 920 mote's schedule. It is possible that at some slot, a mote has 921 multiple activities scheduled (e.g. transmit to mote 0xfeed on 922 slotFrame 2, receive from mote 0xbeef on slotFrame 1). To handle 923 this situation, the TSCH standard defines the following precedence 924 rules: 926 1. Transmissions take precedence over receptions; 928 2. Lower slotframe identifiers take precedence over higher slotframe 929 identifiers. 931 In the example above, the mote would transmit to mote 0xfeed on 932 slotFrame 2. 934 Author's Address 936 Thomas Watteyne (editor) 937 Linear Technology 938 30695 Huntwood Avenue 939 Hayward, CA 94544 940 USA 942 Phone: +1 (510) 400-2978 943 Email: twatteyne@linear.com