idnits 2.17.1 draft-watteyne-6tsch-tsch-lln-context-01.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 21, 2013) is 4082 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 547, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 553, but not defined == Missing Reference: 'WHART' is mentioned on line 559, but not defined == Missing Reference: 'ISA100' is mentioned on line 563, but not defined == Missing Reference: 'Emerson' is mentioned on line 567, but not defined == Missing Reference: 'CurrentCalculator' is mentioned on line 586, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 572, but not defined == Missing Reference: 'OpenWSNETT' is mentioned on line 575, but not defined == Missing Reference: 'IPSO' is mentioned on line 583, but not defined == Missing Reference: 'TSMP' is mentioned on line 599, but not defined == Missing Reference: 'TASA-PIMRC' is mentioned on line 629, but not defined == Missing Reference: 'TASA-SENSORS' is mentioned on line 636, but not defined == Missing Reference: 'TASA-WCNC' is mentioned on line 643, but not defined == Missing Reference: 'PANA' is mentioned on line 658, but not defined == Unused Reference: 'RFC2119' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 528, 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-11 == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-16 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-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 (~~), 34 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 21, 2013 5 Expires: August 25, 2013 7 Using IEEE802.15.4e TSCH in an LLN context: 8 Overview, Problem Statement and Goals 9 draft-watteyne-6tsch-tsch-lln-context-01 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 25, 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. Deterministic Behavior . . . . . . . . . . . . . . . . . . 9 62 3.8. Path Computation Engine . . . . . . . . . . . . . . . . . 9 63 3.9. Secure Communication . . . . . . . . . . . . . . . . . . . 10 64 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 6.3. External Informative References . . . . . . . . . . . . . 15 70 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 19 71 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 19 72 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . . 19 73 A.3. Mote Communication Schedule . . . . . . . . . . . . . . . 19 74 A.4. Links and Paths . . . . . . . . . . . . . . . . . . . . . 20 75 A.5. Dedicated vs. Shared Slots . . . . . . . . . . . . . . . . 20 76 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . . 21 77 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 21 78 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . . 22 79 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 23 80 A.10. Network Communication Schedule . . . . . . . . . . . . . . 23 81 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . . 23 82 A.12. Information Elements . . . . . . . . . . . . . . . . . . . 24 83 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 24 84 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 25 85 B.1. Collision Free Communication . . . . . . . . . . . . . . . 25 86 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 25 87 B.3. Cost of (continuous) Synchronization . . . . . . . . . . . 25 88 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . . 26 89 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . . 26 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 1. Introduction 94 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an 95 amendment to the Medium Access Control (MAC) protocol defined by the 96 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel 97 Hopping (TSCH) mode of IEEE802.15.4e is the object of this document. 99 TSCH was designed to "allow IEEE802.15.4 devices to support a wide 100 range of industrial applications" [IEEE802154e]. At its core is a 101 medium access technique which uses time synchronization to achieve 102 ultra low-power operation and channel hopping to enable high 103 reliability. This is very different from the "legacy" IEEE802.15.4 104 MAC protocol, and is therefore better described as a "redesign". 105 TSCH does not amend the physical layer; i.e., it can operate on any 106 IEEE802.15.4-compliant hardware. 108 IEEE802.15.4e can be seen as the latest generation of ultra-lower 109 power and reliable networking solutions for LLNs. Its core 110 technology is similar to the one used in industrial networking 111 technologies such as WirelessHART [WHART] or ISA100.11a [ISA100]. 112 These protocol solutions have been targeted essentially at the 113 industrial market. WirelessHART is for example the wireless 114 extension of HART, a long standing protocol suite for networking 115 industrial equipment. 117 [RFC5673] discusses industrial applications, and highlights the harsh 118 operating conditions as well as the stringent reliability, 119 availability, and security requirements for an LLN to operate in an 120 industrial environment. Industrial protocols such as WirelessHART 121 satisfy those requirements, and with tens of thousands of networks 122 deployed [Emerson], these types of networks have a large impact on 123 industrial applications. Commercial networking solutions are 124 available today in which motes consume 10's of micro-amps on average 125 [CurrentCalculator] with end-to-end packet delivery ratios over 126 99.999% [doherty07channel]. 128 IEEE802.15.4e builds on the same foundations as WirelessHART, and 129 therefore exhibits similar performance. Yet, unlike an industrial 130 protocol which is, by nature, application-specific, IEEE802.15.4e 131 TSCH focuses on the MAC layer only. This clean layering allows for 132 TSCH to fit under an IPv6 enabled protocol stack for LLNs, running 133 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP [I-D.ietf-core-coap]. 135 Bringing industrial-like performance into the LLN stack developed by 136 the 6LoWPAN, ROLL and CORE working groups opens up new application 137 domains for these networks. Sensors deployed in smart cities 138 [RFC5548] will be able to be installed for years without needing 139 battery replacement. "Umbrella" networks will interconnect smart 140 elements from different entities in smart buildings [RFC5867]. Peel- 141 and-stick switches will obsolete the need for costly conduits for 142 lighting solutions in smart homes [RFC5826]. 144 While [IEEE802154e] defines the mechanisms for a TSCH mote to 145 communicate, it does not define the policies to build and maintain 146 the communication schedule, match that schedule to the multi-hop 147 paths maintained by RPL, adapt the resources allocated between 148 neighbor nodes to the data traffic flows, enforce a differentiated 149 treatment for data generated at the application layer and signaling 150 messages needed by 6LoWPAN and RPL to discover neighbors, react to 151 topology changes, self-configure IP addresses, or manage keying 152 material. 154 In other words, IEEE802.15.4e TSCH is designed to allow optimizations 155 and strong customizations, simplifying the merging of TSCH with a 156 protocol stack based on IPv6, 6LoWPAN, and RPL. 158 2. TSCH in the LLN Context 160 In many cases, to map the services required by the IP layer to the 161 services provided by the link layer, an adaptation layer is used 162 [palattella12standardized]. The 6LoWPAN working group started 163 working in 2007 on specifications for transmitting IPv6 packets over 164 IEEE802.15.4 networks [RFC4919]. Typically, low-power WPANs are 165 characterized by small packet sizes, support for addresses with 166 different lengths, low bandwidth, star and mesh topologies, battery 167 powered devices, low cost, large number of devices, unknown node 168 positions, high unreliability, and periods during which communication 169 interfaces are turned off to save energy. Given these features, it 170 is clear that the adoption of IPv6 on top of a Low-Power WPAN is not 171 straightforward, but poses strong requirements for the optimization 172 of this adaptation layer. For instance, due to the IPv6 default 173 minimum MTU size (1280 bytes), an un-fragmented IPv6 packet is too 174 large to fit in an IEEE802.15.4 frame. Moreover, the overhead due to 175 the 40-byte long IPv6 header wastes the scarce bandwidth available at 176 the PHY layer [RFC4944]. For these reasons, the 6LoWPAN working 177 group has defined an effective adaptation layer [RFC6568]. Further 178 issues encompass the auto-configuration of IPv6 addresses 179 [RFC2464][RFC6755], the compliance with the recommendation on 180 supporting link-layer subnet broadcast in shared networks [RFC3819], 181 the reduction of routing and management overhead [RFC6606], the 182 adoption of lightweight application protocols (or novel data encoding 183 techniques), and the support for security mechanisms (confidentiality 184 and integrity protection, device bootstrapping, key establishment, 185 and management). 187 These features can run on top of TSCH. There are, however, important 188 issues to solve, as highlighted in Section 3. 190 Routing issues are challenging for 6LoWPAN, given the low-power and 191 lossy radio-links, the battery supplied nodes, the multi-hop mesh 192 topologies, and the frequent topology changes due to mobility. 193 Successful solutions take into account the specific application 194 requirements, along with IPv6 behavior and 6LoWPAN mechanisms 195 [palattella12standardized]. The ROLL working group has defined RPL 196 in [RFC6550]. RPL can support a wide variety of link layers, 197 including ones that are constrained, potentially lossy, or typically 198 utilized in conjunction with host or router devices with very limited 199 resources, as in building/home automation [RFC5867][RFC5826], 200 industrial environments [RFC5673], and urban applications [RFC5548]. 201 RPL is able to quickly build up network routes, distribute routing 202 knowledge among nodes, and adapt to a changing topology. In a 203 typical setting, motes are connected through multi-hop paths to a 204 small set of root devices, which are usually responsible for data 205 collection and coordination. For each of them, a Destination 206 Oriented Directed Acyclic Graph (DODAG) is created by accounting for 207 link costs, node attributes/status information, and an Objective 208 Function, which maps the optimization requirements of the target 209 scenario. The topology is set up based on a Rank metric, which 210 encodes the distance of each node with respect to its reference root, 211 as specified by the Objective Function. Regardless of the way it is 212 computed, the Rank monotonically decreases along the DODAG towards 213 the destination, building a gradient. RPL encompasses different 214 kinds of traffic and signaling information. Multipoint-to-Point 215 (MP2P) is the dominant traffic in LLN applications. Data is routed 216 towards nodes with some application relevance, such as the LLN 217 gateway to the larger Internet, or to the core of private IP 218 networks. In general, these destinations are the DODAG roots and act 219 as data collection points for distributed monitoring applications. 220 Point-to-Multipoint (P2MP) data streams are used for actuation 221 purposes, where messages are sent from DODAG roots to destination 222 nodes. Point-to-Point (P2P) traffic allows communication between two 223 devices belonging to the same LLN, such as a sensor and an actuator. 224 A packet flows from the source to the common ancestor of those two 225 communicating devices, then downward towards the destination. RPL 226 therefore has to discover both upward routes (i.e. from nodes to 227 DODAG roots) in order to enable MP2P and P2P flows, and downward 228 routes (i.e. from DODAG roots to nodes) to support P2MP and P2P 229 traffic. 231 Section 3 highlights the challenges that need to be addressed to use 232 RPL on top of TSCH. 234 Several open-source initiatives have emerged around TSCH. The 235 OpenWSN project [OpenWSN][OpenWSNETT] is an open-source 236 implementation of a fully standards-based protocol stack, which aims 237 at evaluating the applicability of TSCH to different applications. 238 This implementation was used as the foundation for an IP for Smart 239 Objects Alliance (IPSO) [IPSO] iteroperability event in 2011. In the 240 absence of a standardized scheduling mechanism for TSCH, a "slotted 241 Aloha" schedule was used. 243 3. Problems and Goals 245 As highlighted in Appendix A, TSCH is different for traditional low- 246 power MAC protocols because of its scheduled nature. TSCH defines 247 the mechanisms to execute a communication schedule, but it is the 248 entity that sets up that schedule which controls the topology of the 249 network, and the resources allocated to each link in that topology. 251 How this entity should operate is out of scope of TSCH. The 252 remainder of this section highlights the problems this entity needs 253 to address. For simplicity, we will refer to this entity by the 254 generic name "6TSCH", without loss of generality. In particular, we 255 do not assume the nature of 6TSCH, whether an adaptation layer, a 256 distributed reservation protocol, a centralized path computation 257 engine, or any combination thereof. 259 Some of the issues 6TSCH need to target might overlap with the scope 260 of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this case, it 261 is entailed that 6TSCH will profit from the services provided by 262 other protocols to pursue these objectives. 264 3.1. Network Formation 266 6TSCH needs to control the way the network is formed, including how 267 new motes join, and how already joined motes advertise the presence 268 of the network. 6TSCH needs to: 270 1. Define the Information Elements to include in the Enhanced 271 Beacons advertising the presence of the network. 273 2. For a new mote, define rules to process and filter received 274 Enhanced Beacons. This includes a mechanism to select the best 275 mote through which to join the network. 277 3. Define the joining procedure. This includes a mechanism to 278 assign a unique 16-bit address to a mote, and the management of 279 initial keying material. 281 4. Define a mechanism to secure the joining process and the 282 subsequent optional process of scheduling more communication 283 links. 285 3.2. Network Maintenance 287 Once a network is formed, 6TSCH needs to maintain the network's 288 health, allowing for motes to stay synchronized. 6TSCH needs to: 290 1. Manage each mote's time source neighbor(s). 292 2. Define a mechanism for a mote to update the join priority it 293 announces in its Enhanced Beacon. 295 3. Schedule transmissions of Enhanced Beacons to advertise the 296 presence of the network. 298 3.3. Multi-Hop Topology 300 RPL, given a weighted connectivity graph, determines multi-hop 301 routes. 6TSCH needs to: 303 1. Define a mechanism to gather topological information, which it 304 can then feed to RPL. 306 2. Ensure that the TSCH schedule contains links along the multi-hop 307 routes identified by RPL. 309 3. Where applicable, maintain independent sets of links to transport 310 independent flows of data. 312 3.4. Routing and Timing Parents 314 At all times, a TSCH mote needs to have at least one time source 315 neighbor it can synchronize to. 6TSCH therefore needs to assign time 316 source neighbors to allow for correct operation of the TSCH network. 317 These time source neighbors could, or not, be related to RPL time 318 parents. 320 3.5. Resource Management 322 A link in a TSCH schedule is a "unit" of resource. The number of 323 links to assign between neighbor motes needs to be appropriate for 324 the size of the traffic flow. 6TSCH needs to: 326 1. Define rules on when to create or delete a slotframe. 328 2. Define rules to determine the length of a slotframe, and the 329 trigger to modify the length of a slotframe. 331 3. Define rules on when to add or delete links in a particular 332 slotframe. 334 4. Define a mechanism for neighbor nodes to exchange information 335 about their schedule and, if applicable, negotiate the addition/ 336 deletion of links. 338 5. Allow for a (possibly centralized) entity to take full control 339 over the schedule. 341 6. Define a set of metrics to evaluate the tradeoff between latency, 342 bandwidth and energy consumption achieved by a particular 343 schedule. 345 3.6. Dataflow Control 347 TSCH defines mechanisms for a mote to signal it cannot accept an 348 incoming packet. It does not, however, define the policy which 349 determines when to stop accepting packets. 6TSCH need to: 351 1. Define a queueing policy for incoming and outgoing packets. 353 2. Manage the buffer space, and indicate to TSCH when to stop 354 accepting incoming packets. 356 3. Handle transmissions that have failed. A transmission is 357 declared failed when TSCH has retransmitted the packet multiple 358 times, without receiving an acknowledgment. This covers both 359 dedicated and shared links. 361 3.7. Deterministic Behavior 363 As highlighted in [RFC5673], in some applications, data is generated 364 periodically and has a well understood data bandwidth requirement, 365 which is deterministic and predictable. 6TSCH need to: 367 1. Ensure timely delivery of such data. 369 2. Provide a mechanism for such deterministic flows to coexist with 370 bursty or infrequent traffic flows of different priorities. 372 3.8. Path Computation Engine 374 As highlighted in [I-D.phinney-roll-rpl-industrial-applicability], 375 bandwidth allocation and multi-hop routes can be optimized by an 376 external Path Computation Engine (PCE). 6TSCH need to: 378 1. Provide a mechanism for an external PCE to be able to control the 379 entire schedule of the network, including the slotframes, links 380 and time source neighbor assignment. 382 2. Define a optional mechanism for the schedule managed by this PCE 383 to coexist with scheduling elements (slotframes, links) managed 384 up by a different mechanism such as a distribute scheduling 385 algorithm. 387 3.9. Secure Communication 389 Given some keying material, TSCH defines mechanisms to encrypt and 390 authenticate MAC frames. It does not define how this keying material 391 is generated. 6TSCH need to: 393 1. Define the keying material and authentication mechanism needed by 394 a new mote to join an existing network. 396 2. Define a mechanism to allow for the secure transfer of 397 application data between neighbor motes. 399 3. Define a mechanism to allow for the secure transfer of signaling 400 data between motes and 6TSCH. 402 4. Contributors 404 Maria Rita Palattella 405 SnT/University of Luxembourg 407 maria-rita.palattella@uni.lu 409 Luigi Alfredo Grieco 410 Politecnico di Bari 412 a.grieco@poliba.it 414 5. Acknowledgements 416 Special thanks to Jonathan Simon for his review and valuable 417 comments. 419 6. References 421 6.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 6.2. Informative References 428 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 429 Networks", RFC 2464, December 1998. 431 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 432 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 433 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 434 RFC 3819, July 2004. 436 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 437 over Low-Power Wireless Personal Area Networks (6LoWPANs): 438 Overview, Assumptions, Problem Statement, and Goals", 439 RFC 4919, August 2007. 441 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 442 "Transmission of IPv6 Packets over IEEE 802.15.4 443 Networks", RFC 4944, September 2007. 445 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 446 "Routing Requirements for Urban Low-Power and Lossy 447 Networks", RFC 5548, May 2009. 449 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 450 Routing Requirements in Low-Power and Lossy Networks", 451 RFC 5826, April 2010. 453 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 454 "Building Automation Routing Requirements in Low-Power and 455 Lossy Networks", RFC 5867, June 2010. 457 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 458 "Industrial Routing Requirements in Low-Power and Lossy 459 Networks", RFC 5673, October 2009. 461 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 462 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 463 September 2011. 465 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 466 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 468 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 469 Lossy Networks", RFC 6550, March 2012. 471 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 472 Application Spaces for IPv6 over Low-Power Wireless 473 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 475 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 476 Statement and Requirements for IPv6 over Low-Power 477 Wireless Personal Area Network (6LoWPAN) Routing", 478 RFC 6606, May 2012. 480 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 481 for OAuth", RFC 6755, October 2012. 483 [I-D.thubert-roll-forwarding-frags] 484 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 485 Recovery", draft-thubert-roll-forwarding-frags-00 (work in 486 progress), March 2012. 488 [I-D.tsao-roll-security-framework] 489 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 490 Security Framework for Routing over Low Power and Lossy 491 Networks", draft-tsao-roll-security-framework-02 (work in 492 progress), March 2010. 494 [I-D.thubert-roll-asymlink] 495 Thubert, P., "RPL adaptation for asymmetrical links", 496 draft-thubert-roll-asymlink-02 (work in progress), 497 December 2011. 499 [I-D.ietf-roll-terminology] 500 Vasseur, J., "Terminology in Low power And Lossy 501 Networks", draft-ietf-roll-terminology-11 (work in 502 progress), February 2013. 504 [I-D.ietf-roll-p2p-rpl] 505 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 506 Martocci, "Reactive Discovery of Point-to-Point Routes in 507 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16 508 (work in progress), February 2013. 510 [I-D.ietf-roll-trickle-mcast] 511 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 512 and Lossy Networks (MPL)", 513 draft-ietf-roll-trickle-mcast-03 (work in progress), 514 January 2013. 516 [I-D.thubert-6lowpan-backbone-router] 517 Thubert, P., "6LoWPAN Backbone Router", 518 draft-thubert-6lowpan-backbone-router-02 (work in 519 progress), June 2010. 521 [I-D.sarikaya-core-sbootstrapping] 522 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 523 Cragie, "Security Bootstrapping Solution for Resource- 524 Constrained Devices", 525 draft-sarikaya-core-sbootstrapping-04 (work in progress), 526 April 2012. 528 [I-D.gilger-smart-object-security-workshop] 529 Gilger, J. and H. Tschofenig, "Report from the 'Smart 530 Object Security Workshop', 23rd March 2012, Paris, 531 France", draft-gilger-smart-object-security-workshop-00 532 (work in progress), October 2012. 534 [I-D.phinney-roll-rpl-industrial-applicability] 535 Phinney, T., Thubert, P., and R. Assimiti, "RPL 536 applicability in industrial networks", 537 draft-phinney-roll-rpl-industrial-applicability-01 (work 538 in progress), October 2012. 540 [I-D.ietf-core-coap] 541 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 542 "Constrained Application Protocol (CoAP)", 543 draft-ietf-core-coap-13 (work in progress), December 2012. 545 6.3. External Informative References 547 [IEEE802154e] 548 IEEE standard for Information Technology, "IEEE std. 549 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 550 Networks (LR-WPANs) Amendament 1: MAC sublayer", 551 April 2012. 553 [IEEE802154] 554 IEEE standard for Information Technology, "IEEE std. 555 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 556 and Physical Layer (PHY) Specifications for Low-Rate 557 Wireless Personal Area Networks", June 2011. 559 [WHART] www.hartcomm.org, "Highway Addressable Remote Transducer, 560 a group of specifications for industrial process and 561 control devices administered by the HART Foundation". 563 [ISA100] ISA, "ISA100, Wireless Systems for Automation", May 2008, 564 < http://www.isa.org/Community/ 565 SP100WirelessSystemsforAutomation>. 567 [Emerson] Emerson Process Management, "Emerson Process Management 568 Smart Wireless Homepage", < http:// 569 www2.emersonprocess.com/en-US/plantweb/wireless/Pages/ 570 WirelessHomePage-Flash.aspx>. 572 [OpenWSN] "Berkeley's OpenWSN Project Homepage", 573 . 575 [OpenWSNETT] 576 Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 577 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 578 a standards-based low-power wireless development 579 environment", Transactions on Emerging Telecommunications 580 Technologies 2012, August 2012, . 583 [IPSO] "IP for Smart Objects Alliance Homepage", 584 . 586 [CurrentCalculator] 587 Linear Technology, "Application Note: Using the Current 588 Calculator to Estimate Mote Power", August 2012, . 593 [doherty07channel] 594 Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific 595 Wireless Sensor Network Path Data", IEEE International 596 Conference on Computer Communications and Networks 597 (ICCCN) 2008, 2007. 599 [TSMP] Pister, K. and L. Doherty, "TSMP: Time Synchronized Mesh 600 Prootocol", International Symposium on Distributed Sensor 601 Networks (DSN) 2008, Nov. 2008, < http:// 602 robotics.eecs.berkeley.edu/~pister/publications/2008/ 603 TSMP%20DSN08.pdf>. 605 [tinka10decentralized] 606 Tinka, A., Watteyne, T., and K. Pister, "A Decentralized 607 Scheduling Algorithm for Time Synchronized Channel 608 Hopping", Ad Hoc Networks 2010, 2010, < http:// 609 robotics.eecs.berkeley.edu/~pister/publications/2008/ 610 TSMP%20DSN08.pdf>. 612 [watteyne09reliability] 613 Watteyne, T., Mehta, A., and K. Pister, "Reliability 614 Through Frequency Diversity: Why Channel Hopping Makes 615 Sense", International Conference on Performance Evaluation 616 of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE- 617 WASUN) 2009, Oct. 2009, . 620 [kerkez09feasibility] 621 Kerkez, B., Watteyne, T., and M. Magliocco, "Feasibility 622 analysis of controller design for adaptive channel 623 hopping", International Workshop on Performance 624 Methodologies and Tools for Wireless Sensor Networks 625 (WSNPERF) 2009, Oct. 2009, . 629 [TASA-PIMRC] 630 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 631 and G. Boggia, "Traffic Aware Scheduling Algorithm for 632 Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, 633 Sept. 2012, < http://www.cttc.es/resources/doc/ 634 120531-submitted-tasa-25511.pdf>. 636 [TASA-SENSORS] 637 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., 638 and G. Boggia, "Traffic-Aware Time-Critical Scheduling In 639 Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT", 640 IEEE SENSORS 2012, Oct. 2012, < http://www.cttc.es/ 641 resources/doc/120821-sensors2012-4396981770946977737.pdf>. 643 [TASA-WCNC] 644 Accettura, N., Palattella, MR., Dohler, M., Grieco, LA., 645 and G. Boggia, "Standardized Power-Efficient and Internet- 646 Enabled Communication Stack for Capillary M2M Networks", 647 IEEE WCNC 2012, Apr. 2012, < http://www.cttc.es/resources/ 648 doc/120109-1569521283-submitted-58230.pdf>. 650 [palattella12standardized] 651 Palattella, MR., Accettura, N., Vilajosana, X., Watteyne, 652 T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized 653 Protocol Stack For The Internet Of (Important) Things", 654 IEEE Communications Surveys and Tutorials 2012, Dec. 2012, 655 < http://www.cttc.es/resources/doc/ 656 121025-completestackforiot-clean-4818610916636121981.pdf>. 658 [PANA] Kanda, M., Ohba, Y., Das, S., and S. Chasko, "PANA 659 applicability in constrained environments", Febr. 2012, . 663 Appendix A. TSCH Protocol Highlights 665 This appendix gives an overview of the key features of the 666 IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes 667 no attempt at repeating the standard, but rather focuses on the 668 following: 670 o Concepts which are sufficiently different from traditional 671 IEEE802.15.4 networking that they may need to be defined and 672 presented precisely. 674 o Techniques and ideas which are part of IEEE802.15.4e and which 675 might be useful for the work of 6TSCH. 677 A.1. Timeslots 679 All motes in a TSCH network are synchronized. Time is sliced up into 680 time slots. A time slot is long enough for a MAC frame of maximum 681 size to be sent from mote A to mote B, and for mote B to reply with 682 an acknowledgment (ACK) frame indicating successful reception. 684 The duration of a timeslot is not defined by the standard. With 685 IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band, 686 a maximum-length frame of 127 bytes takes about 4ms to transmit; a 687 shorter ACK takes about 1ms. With a 10ms slot (a typical duration), 688 this leaves 5ms to radio turnaround, packet processing and security 689 operations. 691 A.2. Slotframes 693 Timeslots are grouped into one of more slotframes. A slotframe 694 continuously repeats over time. TSCH does not impose a slotframe 695 size. Depending on the application needs, these can range from 10s 696 to 1000s of timeslots. The shorter the slotframe, the more often a 697 timeslot repeats, resulting in more available bandwidth, but also in 698 a higher power consumption. 700 A.3. Mote Communication Schedule 702 A communication schedule instructs each mote what to do in each slot: 703 transmit, receive or sleep. The schedule indicates, for each active 704 (transmit or receive) timeslot a channelOffset and the address of the 705 neighbor to communicate with. 707 Once a mote obtains its schedule, it executes it: 709 o For each transmit slot, the mote checks whether there is a packet 710 in the outgoing buffer which matches the neighbor written in the 711 schedule information for that slot. If there is none, the mote 712 keeps its radio off for the duration of the slot. If there is 713 one, the mote can ask for the neighbor to acknowledge it, in which 714 case it has to listen for the acknowledgment after transmitting. 716 o For each receive slot, the mote listens for possible incoming 717 packets. If none is received after some listening period, it 718 shuts down its radio. If a packet is received, addressed to the 719 mote, and passes security checks, the mote can send back an 720 aknowledgment. 722 How the schedule is built, updated and maintained, and by which 723 entity, is outside of the scope of the IEEE802.15.4e standard. 725 A.4. Links and Paths 727 Assuming the schedule is well built, if mote A is scheduled to 728 transmit to mote B at slotOffset 5 and channelOffset 11, mote B will 729 be scheduled to receive from mote A at the same slotOffset and 730 channelOffset. 732 A single slot of the schedule (i.e., a single cell of the grid), 733 characterized by a slotOffset and channelOffset, and reserved for 734 mote A to transmit to mote B (or for mote B to receive from mote A), 735 is called a "link". 737 If there is a lot of data flowing from mote A to mote B, the schedule 738 might contain multiple slots from A to B, at different times. 739 Multiple links scheduled to the same neighbor are typically 740 equivalent, i.e. the MAC layer sends the packet on whichever of these 741 links happens to show up first after the packet was put in the MAC 742 queue. The union of all links between two neighbors, A and B, is 743 called a "path". Since the slotframe repeats over time (and the 744 length of the slotframe is typically constant), each link gives a 745 "quantum" of bandwidth to a given neighbor. Modifying the number of 746 links in a path modifies the amount of resources allocated between 747 two neighbors. 749 A.5. Dedicated vs. Shared Slots 751 By default, each transmit timeslot within the TSCH schedule is 752 dedicated, i.e., reserved only for mote A to transmit to mote B. 753 IEEE802.15.4e allows also to mark a slot as shared. In a shared 754 slot, multiple motes can transmit at the same time, on the same 755 fequency. To avoid contention, TSCH defines a back-off algorithm for 756 shared slots. 758 A slot can be marked as both transmitting and receiving. In this 759 case, a mote transmits if it has an appropriate packet in its output 760 buffer, or listens otherwise. Marking a slot as 761 [transmit,shared,receive] results in slotted-Aloha behavior. 763 A.6. Absolute Slot Number 765 TSCH defines a timeslot counter called Absolute Slot Number (ASN). 766 When a new network is created, the ASN is initialized to 0; from then 767 on, it increments by 1 at each timeslot. In detail: 769 ASN = (k*S+t) 771 where k is the slotframe cycle (i.e., the number of slotframe 772 occurences over time), S the slotframe size and t the slotOffset. A 773 mote learns the current ASN when it joins the network. Since motes 774 are synchronized, they all know the current value of the ASN, and any 775 time. The ASN is encoded as a 5-byte number: this allows it to 776 increment for hundreds of years (the exact value depends on the 777 duration of a timeslot) without wrapping. The ASN is used (i) to 778 calculate the frequency to communicate on, jointly with the 779 channelOffset, (ii) to build unique security nonce counters used by 780 CCM*. 782 A.7. Channel Hopping 784 For each active slot, the schedule specifies a slotOffset and a 785 channelOffset. In a well-built schedule, when mote A has a transmit 786 slot to mote B on channelOffset 5, mote B has a receive slot from 787 mote A on the same channelOffset. The channelOffset is translated by 788 both nodes into a frequency using the following function: 790 frequency = F {(ASN + channelOffset) mod nFreq} 792 The function F consists of a look-up table containing the set of 793 available channels. The value nFreq (the number of available 794 frequencies) is the size of this look-up table. There are as many 795 channelOffset values as there are frequencies available (e.g. 16 when 796 using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are 797 used). Since both motes have the same channelOffset written in their 798 schedule for that timeslot, and the same ASN counter since they are 799 synchronized, they compute the same frequency. At the next iteration 800 (cycle) of the slotframe, however, the channelOffset will be the 801 same, but the ASN will have changed, resulting in the computation of 802 a different frequency. If the slotframe size, S (used for computing 803 ASN), and the number of channel offsets, nFreq, are relatively prime, 804 the translation function ensures that each link rotates through k 805 available channels over k slotframe cycles. This results in "channel 806 hopping": even with a static schedule, pairs of neighbors "hop" 807 between the different frequencies when communicating. 809 The look-up table F can be built to contain only a subset of all 810 available channels. This results in frequency "blacklisting". 812 Channel hopping is a technique known to efficiently combat multi-path 813 fading and external interference. This results in a TSCH network 814 having a more stable topology than if only a single channel were used 815 for the entire network. 817 A.8. Time Synchronization 819 Because of the slotted nature of communication in a TSCH network, 820 motes have to maintain tight synchronization. All motes are assumed 821 to be equipped with clocks to keep track of time (32kHz crystal 822 oscillators are typically used). Yet, because clocks in different 823 motes drift with respect to one another, neighbor motes need to 824 periodically re-synchronize. 826 In detail, each mote periodically synchronizes its network clock to 827 at least one other mote, and it also provides its network time to its 828 neighbors. It is up to the entity that manages the schedule to 829 assign adequate time source neighbor(s) to each mote, i.e., to 830 indicate in the schedule which of its neighbor(s) are its "time 831 source neighbors". While setting the time source neighbor, it is 832 important to avoid synchronization loops, which could result in the 833 formation of independent clusters of motes. 835 Typically, in a IEEE802.15.4e TSCH network, time propagates outwards 836 from the PAN coordinator (i.e., the root node). But the direction of 837 time propagation is independent of data flow in the network. A new 838 mote joining a TSCH network, because it does not have a schedule yet, 839 maintains time synchronization, using the information carried by the 840 Enhanced Beacons (EBs), sent by the advertising motes. 842 TSCH adds timing information in all packets that are exchanged (both 843 data and ACK frames). This means that neighbor motes can 844 resynchronize to one another whenever they exchange data. In detail, 845 in the IEEE 802.15.4e standard two methods are defined for allowing a 846 device to synchronize in a TSCH network: (I) Acknowledgment-Based and 847 (II) Frame-Based synchronization. In both cases, the receiver 848 calculates the difference in time between the expected time of frame 849 arrival and its actual arrival. In Acknowledgment-Based 850 synchronization, the receiver provides such information to the sender 851 mote in its acknowledgment. Thus, in this case, it is the sender 852 mote that synchronizes to the clock of the receiver. In Frame-Based 853 synchronization, the receiver uses the computed delta for adjusting 854 its own clock. Therefore, it is the receiver mote that synchronizes 855 to the clock of the sender. 857 Different synchronization policies are possible. Motes can keep 858 synchronization exclusively by exchanging EBs. Motes can also keep 859 synchronized by periodically sending valid frames to time source 860 neighbors to use the acknowledgement to resynchronize. Both method 861 (or a combination thereof) are valid synchronization policies; which 862 one to use depends on network requirements. 864 A.9. Power Consumption 866 There are only a handful of activities a mote can perform during a 867 timeslot: transmit, receive, or sleep. Each of these operations has 868 some energy cost associated to them, the exact value depending on the 869 the hardware used. Given the schedule of a mote, it is 870 straighforward to calculate the expected average power consumption of 871 that mote. 873 A.10. Network Communication Schedule 875 The schedule defines entirely the synchronization and communication 876 between motes. By adding/removing links between neighbors, one can 877 adapt a schedule to the needs of the application. Intuitive examples 878 are: 880 o Make the schedule "sparse" for applications where motes need to 881 consume as little energy as possible, at the price of reduced 882 bandwidth. 884 o Make the schedule "dense" for applications where motes generate a 885 lot of data, at the price of increased power consumption. 887 o Add more links along a multi-hop route over which many packets 888 flow. 890 A.11. Join Process 892 Motes already part of the network can periodically send Enhanced 893 Beacon (EB) frames to announce the presence the network. These 894 contain information about the size of the timeslot used in the 895 network, the current ASN, information about the slotframes and 896 timeslots the beaconing mote is listening on, and a 1-byte join 897 priority. This join priority corresponds to the number of hops 898 separating the mote sending the EB, and the PAN coordinator. Because 899 of the channel hopping nature of TSCH, these EB frames are sent on 900 all frequencies. 902 A mote wishing to join the network listens on some frequency for EBs. 904 It can wait to receive multiple, and can use the join priority in 905 those EBs to identify the best mote through which to join the 906 network. Using the ASN and the other timing information of the EB, 907 the new mote synchronizes to the network. Using the slotframe and 908 link information from the EB, it knows how to contact the mote it 909 just joined. 911 The TSCH standard does not define the steps beyond this "kickstart". 912 These steps can include a security handshake and the addition of more 913 communication links to the new mote's schedule. 915 A.12. Information Elements 917 TSCH introduces the concept of Information Elements (IES). An 918 information element is a list of Type-Length-Value containers placed 919 at the end of the MAC header. A small number of types are defined 920 for TSCH (e.g., the ASN in the EB is contained in an IE), and an 921 unmanaged range is available for extensions. 923 A data bit in the MAC header indicates whether the frame contains 924 IEs. IEs are grouped into Header IEs, consumed by the MAC layer and 925 therefore typically invisible to the next higher layer, and Payload 926 IEs, which are passed untouched to the next higher layer, possibly 927 followed by regular payload. Payload IEs can therefore be used for 928 the next higher layers of two neighbor motes to exchange information. 930 A.13. Extensibility 932 The TSCH standard is designed to be extensible. It introduces the 933 mechanisms as "building block" (e.g. links, slotframes, etc.), but 934 leaves entire freedom to the upper layer to assemble those. The MAC 935 protocol can be extended by defining new Header IEs. An intermediate 936 layer can be defined to manage the MAC layer by defining new Payload 937 IEs. 939 Appendix B. TSCH Gotchas 941 This section lists features of TSCH which we believe are important 942 and beneficial to the work of 6TSCH. 944 B.1. Collision Free Communication 946 TSCH allows one to easily design a schedule which yields collision- 947 free communication. This is done by building the schedule with 948 dedicated links in such a way that at most one link occupies each 949 slotOffset/channelOffset cell. Multiple pairs of neighbor motes can 950 exchange data at the same time, but on different frequencies. If a 951 deployment is done over a large area, slotOffset/channelOffset cells 952 can be reused by pairs of neigbors sufficiently far appart not to 953 interfere. 955 B.2. Multi-Channel vs. Channel Hopping 957 A TSCH schedule looks like a matrix of width "slotframe size", S, and 958 of height "number of frequencies", nFreq. For a scheduling 959 algorithm, these can be considered atomic "units" to schedule. In 960 particular, because of the channel hopping nature of TSCH, the 961 scheduling algorithm should not worry about the actual frequency 962 communication happens on, since it changes at each slotframe 963 iteration. 965 B.3. Cost of (continuous) Synchronization 967 When there is traffic in the network, motes which are communicating 968 implicitly re-synchronize using the data frames they exchange. In 969 the absence of data traffic, motes are required to synchronize to 970 their time source neighbor(s) periodically not to drift in time. If 971 they have not been communicating for some time (typically 30s), motes 972 can exchange an empty data frame, often referred to as a "Keep-alive" 973 message, to re-synchronize. The frequency at which such message need 974 to be transmitted depends on the stability of the clock source, and 975 on how "early" each mote starts listening for data (the "guard 976 time"). Theoretically, with a 10ppm clock and a 1ms guard time, this 977 period can be 100s. When acknowledgment-based synchronization is 978 used, re-synchronizing consists in sending any valid frame to the 979 time source neighbor and using the timing information in the ACK to 980 realign the clocks. Assuming this exchange causes the mote's radio 981 to be on for 5ms, this yields a radio duty cycle needed to keep 982 synchronized of 5ms/100s=0.005%. While TSCH does requires motes to 983 resynchronize periodically, the cost of doing so can be considered 984 almost negligible in many applications. 986 B.4. Topology Stability 988 The channel hopping nature of TSCH causes links to be very "stable". 989 Wireless phenomena such as multi-path fading and external 990 interference impact a wireless link between two motes differently on 991 each frequency. If a transmission from mote A to mote B fails, 992 retransmitting on a different frequency has a higher likelihood of 993 succeeding that retransmitting on the same frequency. As a result, 994 even when some frequencies are "behaving bad", channel hopping 995 "smoothens" the contribution of each frequency, resulting in more 996 stable links, and therefore a more stable topology. 998 B.5. Multiple Concurrent Slotframes 1000 The TSCH standard allows for multiple slotframes to coexist in a 1001 mote's schedule. It is possible that at some slot, a mote has 1002 multiple activities scheduled (e.g. transmit to mote B on slotFrame 1003 2, receive from mote C on slotFrame 1). To handle this situation, 1004 the TSCH standard defines the following precedence rules: 1006 1. Transmissions take precedence over receptions; 1008 2. Lower slotframe identifiers take precedence over higher slotframe 1009 identifiers. 1011 In the example above, the mote would transmit to mote B on slotFrame 1012 2. 1014 Author's Address 1016 Thomas Watteyne (editor) 1017 Linear Technology 1018 30695 Huntwood Avenue 1019 Hayward, CA 94544 1020 USA 1022 Phone: +1 (510) 400-2978 1023 Email: twatteyne@linear.com