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