idnits 2.17.1
draft-thubert-6tisch-4detnet-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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 11, 2015) is 3236 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 900, but not
defined
== Missing Reference: 'IEEE802154' is mentioned on line 905, but not defined
== Missing Reference: 'IEEE802154e' is mentioned on line 911, but not
defined
== Missing Reference: 'PCE' is mentioned on line 930, but not defined
== Missing Reference: 'CCAMP' is mentioned on line 890, but not defined
== Missing Reference: 'ACE' is mentioned on line 886, but not defined
== Missing Reference: 'DICE' is mentioned on line 893, but not defined
== Missing Reference: 'HART' is mentioned on line 896, but not defined
== Missing Reference: 'ISA100' is mentioned on line 921, but not defined
== Missing Reference: 'TEAS' is mentioned on line 933, but not defined
== Missing Reference: 'WirelessHART' is mentioned on line 936, but not
defined
== Unused Reference: 'RFC2460' is defined on line 803, but no explicit
reference was found in the text
== Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on
line 829, but no explicit reference was found in the text
== Unused Reference: 'RFC2474' is defined on line 839, but no explicit
reference was found in the text
== Unused Reference: 'RFC3209' is defined on line 844, but no explicit
reference was found in the text
== Unused Reference: 'RFC4903' is defined on line 858, but no explicit
reference was found in the text
== Unused Reference: 'RFC4919' is defined on line 861, but no explicit
reference was found in the text
== Unused Reference: 'RFC6282' is defined on line 866, but no explicit
reference was found in the text
== Unused Reference: 'RFC6775' is defined on line 879, but no explicit
reference was found in the text
== Outdated reference: A later version (-04) exists of
draft-ietf-6tisch-6top-interface-03
== Outdated reference: A later version (-30) exists of
draft-ietf-6tisch-architecture-08
== Outdated reference: A later version (-10) exists of
draft-ietf-6tisch-terminology-04
** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200)
== Outdated reference: A later version (-08) exists of
draft-finn-detnet-architecture-01
== Outdated reference: A later version (-04) exists of
draft-svshah-tsvwg-deterministic-forwarding-03
== Outdated reference: A later version (-04) exists of
draft-wang-6tisch-6top-sublayer-01
Summary: 1 error (**), 0 flaws (~~), 26 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 6TiSCH P. Thubert, Ed.
3 Internet-Draft Cisco
4 Intended status: Informational June 11, 2015
5 Expires: December 13, 2015
7 6TiSCH requirements for DetNet
8 draft-thubert-6tisch-4detnet-01
10 Abstract
12 This document builds on the 6TiSCH architecture that defines, among
13 others, mechanisms to establish and maintain deterministic routing
14 and scheduling in a centralized fashion. The document details
15 dependencies on DetNet and PCE controller to express topologies and
16 capabilities, as well as abstract state that the controller must be
17 able to program into the network devices to enable deterministic
18 forwarding operations.
20 Requirements Language
22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
24 "OPTIONAL" in this document are to be interpreted as described in RFC
25 2119 [RFC2119].
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on December 13, 2015.
44 Copyright Notice
46 Copyright (c) 2015 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 3. 6TiSCH Overview . . . . . . . . . . . . . . . . . . . . . . . 4
64 3.1. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . 7
65 3.2. SlotFrames and Priorities . . . . . . . . . . . . . . . . 7
66 3.3. Schedule Management by a PCE . . . . . . . . . . . . . . 9
67 3.4. Track Forwarding . . . . . . . . . . . . . . . . . . . . 10
68 3.4.1. Transport Mode . . . . . . . . . . . . . . . . . . . 11
69 3.4.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . . . 12
70 3.4.3. Tunnel Metadata . . . . . . . . . . . . . . . . . . . 13
71 4. Operations of Interest for DetNet and PCE . . . . . . . . . . 14
72 4.1. Packet Marking and Handling . . . . . . . . . . . . . . . 15
73 4.1.1. Tagging Packets for Flow Identification . . . . . . . 15
74 4.1.2. Replication, Retries and Elimination . . . . . . . . 15
75 4.1.3. Differentiated Services Per-Hop-Behavior . . . . . . 16
76 4.2. Topology and capabilities . . . . . . . . . . . . . . . . 16
77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
81 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
82 8.2. Informative References . . . . . . . . . . . . . . . . . 18
83 8.3. Other Informative References . . . . . . . . . . . . . . 20
84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
86 1. Introduction
88 The emergence of wireless technology has enabled a variety of new
89 devices to get interconnected, at a very low marginal cost per
90 device, at any distance ranging from Near Field to interplanetary,
91 and in circumstances where wiring may not be practical, for instance
92 on fast-moving or rotating devices.
94 At the same time, a new breed of Time Sensitive Networks is being
95 developed to enable traffic that is highly sensitive to jitter, quite
96 sensitive to latency, and with a high degree of operational
97 criticality so that loss should be minimized at all times. Such
98 traffic is not limited to professional Audio/ Video networks, but is
99 also found in command and control operations such as industrial
100 automation and vehicular sensors and actuators.
102 At IEEE802.1, the Audio/Video Task Group [IEEE802.1TSNTG] Time
103 Sensitive Networking (TSN) to address Deterministic Ethernet. The
104 Medium access Control (MAC) of IEEE802.15.4 [IEEE802154] has evolved
105 with the new TimeSlotted Channel Hopping (TSCH)
106 [I-D.ietf-6tisch-tsch] mode for deterministic industrial-type
107 applications. TSCH was introduced with the IEEE802.15.4e
108 [IEEE802154e] amendment and will be wrapped up in the next revision
109 of the IEEE802.15.4 standard. For all practical purpose, this
110 document is expected to be insensitive to the future versions of the
111 IEEE802.15.4 standard, which is thus referenced undated.
113 Though at a different time scale, both TSN and TSCH standards provide
114 Deterministic capabilities to the point that a packet that pertains
115 to a certain flow crosses the network from node to node following a
116 very precise schedule, as a train that leaves intermediate stations
117 at precise times along its path. With TSCH, time is formatted into
118 timeSlots, and an individual cell is allocated to unicast or
119 broadcast communication at the MAC level. The time-slotted operation
120 reduces collisions, saves energy, and enables to more closely
121 engineer the network for deterministic properties. The channel
122 hopping aspect is a simple and efficient technique to combat multi-
123 path fading and co-channel interferences (for example by Wi-Fi
124 emitters).
126 The 6TiSCH Architecture [I-D.ietf-6tisch-architecture] defines a
127 remote monitoring and scheduling management of a TSCH network by a
128 Path Computation Element (PCE), which cooperates with an abstract
129 Network Management Entity (NME) to manage timeSlots and device
130 resources in a manner that minimizes the interaction with and the
131 load placed on the constrained devices.
133 This Architecture applies the concepts of Deterministic Networking on
134 a TSCH network to enable the switching of timeSlots in a G-MPLS
135 manner. This document details the dependencies that 6TiSCH has on
136 PCE [PCE] and DetNet [I-D.finn-detnet-architecture] to provide the
137 necessary capabilities that may be specific to such networks. In
138 turn, DetNet is expected to integrate and maintain consistency with
139 the work that has taken place and is continuing at IEEE802.1TSN and
140 AVnu.
142 2. Terminology
144 Readers are expected to be familiar with all the terms and concepts
145 that are discussed in "Multi-link Subnet Support in IPv6"
146 [I-D.ietf-ipv6-multilink-subnets].
148 The draft uses terminology defined or referenced in
149 [I-D.ietf-6tisch-terminology] and
150 [I-D.ietf-roll-rpl-industrial-applicability].
152 The draft also conforms to the terms and models described in
153 [RFC3444] and uses the vocabulary and the concepts defined in
154 [RFC4291] for the IPv6 Architecture.
156 3. 6TiSCH Overview
158 The scope of the present work is a subnet that, in its basic
159 configuration, is made of a TSCH [I-D.ietf-6tisch-tsch] MAC Low Power
160 Lossy Network (LLN).
162 ---+-------- ............ ------------
163 | External Network |
164 | +-----+
165 +-----+ | NME |
166 | | LLN Border | |
167 | | router +-----+
168 +-----+
169 o o o
170 o o o o
171 o o LLN o o o
172 o o o o
173 o
175 Figure 1: Basic Configuration of a 6TiSCH Network
177 In the extended configuration, a Backbone Router (6BBR) federates
178 multiple 6TiSCH in a single subnet over a backbone. 6TiSCH 6BBRs
179 synchronize with one another over the backbone, so as to ensure that
180 the multiple LLNs that form the IPv6 subnet stay tightly
181 synchronized.
183 ---+-------- ............ ------------
184 | External Network |
185 | +-----+
186 | +-----+ | NME |
187 +-----+ | +-----+ | |
188 | | Router | | PCE | +-----+
189 | | +--| |
190 +-----+ +-----+
191 | |
192 | Subnet Backbone |
193 +--------------------+------------------+
194 | | |
195 +-----+ +-----+ +-----+
196 | | Backbone | | Backbone | | Backbone
197 o | | router | | router | | router
198 +-----+ +-----+ +-----+
199 o o o o o
200 o o o o o o o o o o o
201 o o o LLN o o o o
202 o o o o o o o o o o o o
204 Figure 2: Extended Configuration of a 6TiSCH Network
206 If the Backbone is Deterministic, then the Backbone Router ensures
207 that the end-to-end deterministic behavior is maintained between the
208 LLN and the backbone. This SHOULD be done in conformance to the
209 DetNet Architecture [I-D.finn-detnet-architecture] which studies
210 Layer-3 aspects of Deterministic Networks, and covers networks that
211 span multiple Layer-2 domains. One particular requirement is that
212 the PCE MUST be able to compute a deterministic path and to end
213 across the TSCH network and an IEEE802.1 TSN Ethernet backbone, and
214 DetNet MUST enable end-to-end deterministic forwarding.
216 6TiSCH defines the concept of a Track, which is a complex form of a
217 uni-directional Circuit ([I-D.ietf-6tisch-terminology]). As opposed
218 to a simple circuit that is a sequence of nodes and links, a Track is
219 shaped as a directed acyclic graph towards a destination to support
220 multi-path forwarding and route around failures. A Track may also
221 branch off and rejoin, for the purpose of the so-called Packet
222 Replication and Elimination (PRE), over non congruent branches. PRE
223 may be used to complement layer-2 Automatic Repeat reQuest (ARQ) to
224 meet industrial expectations in Packet Delivery Ratio (PDR), in
225 particular when the Track extends beyond the 6TiSCH network.
227 +-----+
228 | IoT |
229 | G/W |
230 +-----+
231 ^ <---- Elimination
232 | |
233 Track branch | |
234 +-------+ +--------+ Subnet Backbone
235 | |
236 +--|--+ +--|--+
237 | | | Backbone | | | Backbone
238 o | | | router | | | router
239 +--/--+ +--|--+
240 o / o o---o----/ o
241 o o---o--/ o o o o o
242 o \ / o o LLN o
243 o v <---- Replication
244 o
246 Figure 3: End-to-End deterministic Track
248 In the example above, a Track is laid out from a field device in a
249 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN
250 backbone.
252 The Replication function in the field device sends a copy of each
253 packet over two different branches, and the PCE schedules each hop of
254 both branches so that the two copies arrive in due time at the
255 gateway. In case of a loss on one branch, hopefully the other copy
256 of the packet still makes it in due time. If two copies make it to
257 the IoT gateway, the Elimination function in the gateway ignores the
258 extra packet and presents only one copy to upper layers.
260 At each 6TiSCH hop along the Track, the PCE may schedule more than
261 one timeSlot for a packet, so as to support Layer-2 retries (ARQ).
262 It is also possible that the field device only uses the second branch
263 if sending over the first branch fails.
265 In current deployments, a TSCH Track does not necessarily support PRE
266 but is systematically multi-path. This means that a Track is
267 scheduled so as to ensure that each hop has at least two forwarding
268 solutions, and the forwarding decision is to try the preferred one
269 and use the other in case of Layer-2 transmission failure as detected
270 by ARQ.
272 3.1. TSCH and 6top
274 6top is a logical link control sitting between the IP layer and the
275 TSCH MAC layer, which provides the link abstraction that is required
276 for IP operations. The 6top operations are specified in
277 [I-D.wang-6tisch-6top-sublayer].
279 The 6top data model and management interfaces are further discussed
280 in [I-D.ietf-6tisch-6top-interface] and [I-D.ietf-6tisch-coap].
282 The architecture defines "soft" cells and "hard" cells. "Hard" cells
283 are owned and managed by an separate scheduling entity (e.g. a PCE)
284 that specifies the slotOffset/channelOffset of the cells to be
285 added/moved/deleted, in which case 6top can only act as instructed,
286 and may not move hard cells in the TSCH schedule on its own.
288 3.2. SlotFrames and Priorities
290 A slotFrame is the base object that the PCE needs to manipulate to
291 program a schedule into an LLN node. Elaboration on that concept can
292 be fond in section "SlotFrames and Priorities" of
293 [I-D.ietf-6tisch-architecture]
295 IEEE802.15.4 TSCH avoids contention on the medium by formatting time
296 and frequencies in cells of transmission of equal duration. In order
297 to describe that formatting of time and frequencies, the 6TiSCH
298 architecture defines a global concept that is called a Channel
299 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
300 cells with an height equal to the number of available channels
301 (indexed by ChannelOffsets) and a width (in timeSlots) that is the
302 period of the network scheduling operation (indexed by slotOffsets)
303 for that CDU matrix. The size of a cell is a timeSlot duration, and
304 values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to
305 accommodate for the transmission of a frame and an ack, including the
306 security validation on the receive side which may take up to a few
307 milliseconds on some device architecture.
309 The frequency used by a cell in the matrix rotates in a pseudo-random
310 fashion, from an initial position at an epoch time, as the matrix
311 iterates over and over.
313 A CDU matrix is computed by the PCE, but unallocated timeSlots may be
314 used opportunistically by the nodes for classical best effort IP
315 traffic. The PCE has precedence in the allocation in case of a
316 conflict.
318 In a given network, there might be multiple CDU matrices that operate
319 with different width, so they have different durations and represent
320 different periodic operations. It is recommended that all CDU
321 matrices in a 6TiSCH domain operate with the same cell duration and
322 are aligned, so as to reduce the chances of interferences from
323 slotted-aloha operations. The PCE MUST compute the CDU matrices and
324 shared that knowledge with all the nodes. The matrices are used in
325 particular to define slotFrames.
327 A slotFrame is a MAC-level abstraction that is common to all nodes
328 and contains a series of timeSlots of equal length and precedence.
329 It is characterized by a slotFrame_ID, and a slotFrame_size. A
330 slotFrame aligns to a CDU matrix for its parameters, such as number
331 and duration of timeSlots.
333 Multiple slotFrames can coexist in a node schedule, i.e., a node can
334 have multiple activities scheduled in different slotFrames, based on
335 the precedence of the 6TiSCH topologies. The slotFrames may be
336 aligned to different CDU matrices and thus have different width.
337 There is typically one slotFrame for scheduled traffic that has the
338 highest precedence and one or more slotFrame(s) for RPL traffic. The
339 timeSlots in the slotFrame are indexed by the SlotOffset; the first
340 cell is at SlotOffset 0.
342 The 6TiSCH architecture introduces the concept of chunks
343 ([I-D.ietf-6tisch-terminology]) to operate such spectrum distribution
344 for a whole group of cells at a time. The CDU matrix is formatted
345 into a set of chunks, each of them identified uniquely by a chunk-ID.
346 The PCE MUST compute the partitioning of CDU matrices into chunks and
347 shared that knowledge with all the nodes in a 6TiSCH network.
349 +-----+-----+-----+-----+-----+-----+-----+ +-----+
350 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
351 +-----+-----+-----+-----+-----+-----+-----+ +-----+
352 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
353 +-----+-----+-----+-----+-----+-----+-----+ +-----+
354 ...
355 +-----+-----+-----+-----+-----+-----+-----+ +-----+
356 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
357 +-----+-----+-----+-----+-----+-----+-----+ +-----+
358 0 1 2 3 4 5 6 M
360 Figure 4: CDU matrix Partitioning in Chunks
362 The appropriation of a chunk can be requested explicitly by the PCE
363 to any node. After a successful appropriation, the PCE owns the
364 cells in that chunk, and may use them as hard cells to set up Tracks.
366 3.3. Schedule Management by a PCE
368 6TiSCH supports a mixed model of centralized routes and distributed
369 routes. Centralized routes can for example be computed by a entity
370 such as a PCE. Distributed routes are computed by RPL.
372 Both methods may inject routes in the Routing Tables of the 6TiSCH
373 routers. In either case, each route is associated with a 6TiSCH
374 topology that can be a RPL Instance topology or a track. The 6TiSCH
375 topology is indexed by a Instance ID, in a format that reuses the
376 RPLInstanceID as defined in RPL [RFC6550].
378 Both RPL and PCE rely on shared sources such as policies to define
379 Global and Local RPLInstanceIDs that can be used by either method.
380 It is possible for centralized and distributed routing to share a
381 same topology. Generally they will operate in different slotFrames,
382 and centralized routes will be used for scheduled traffic and will
383 have precedence over distributed routes in case of conflict between
384 the slotFrames.
386 Section "Schedule Management Mechanisms" of the 6TiSCH architecture
387 describes 4 paradigms to manage the TSCH schedule of the LLN nodes:
388 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring
389 and scheduling management, and Hop-by-hop scheduling. The Track
390 operation for DetNet corresponds to a remote monitoring and
391 scheduling management by a PCE.
393 The 6top interface document [I-D.ietf-6tisch-6top-interface]
394 specifies the generic data model that can be used to monitor and
395 manage resources of the 6top sublayer. Abstract methods are
396 suggested for use by a management entity in the device. The data
397 model also enables remote control operations on the 6top sublayer.
399 [I-D.ietf-6tisch-coap] defines an mapping of the 6top set of
400 commands, which is described in [I-D.ietf-6tisch-6top-interface], to
401 CoAP resources. This allows an entity to interact with the 6top
402 layer of a node that is multiple hops away in a RESTful fashion.
404 [I-D.ietf-6tisch-coap] also defines a basic set CoAP resources and
405 associated RESTful access methods (GET/PUT/POST/DELETE). The payload
406 (body) of the CoAP messages is encoded using the CBOR format. The
407 PCE commands are expected to be issued directly as CoAP requests or
408 to be mapped back and forth into CoAP by a gateway function at the
409 edge of the 6TiSCH network. For instance, it is possible that a
410 mapping entity on the backbone transforms a non-CoAP protocol such as
411 PCEP into the RESTful interfaces that the 6TiSCH devices support.
412 This architecture will be refined to comply with DetNet
413 [I-D.finn-detnet-architecture] when the work is formalized.
415 3.4. Track Forwarding
417 By forwarding, this specification means the per-packet operation that
418 allows to deliver a packet to a next hop or an upper layer in this
419 node. Forwarding is based on pre-existing state that was installed
420 as a result of the routing computation of a Track by a PCE. The
421 6TiSCH architecture supports three different forwarding model, G-MPLS
422 Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6
423 Forwarding (6F) which is the classical IP operation. The DetNet case
424 relates to the Track Forwarding operation under the control of a PCE.
426 A Track is a unidirectional path between a source and a destination.
427 In a Track cell, the normal operation of IEEE802.15.4 Automatic
428 Repeat-reQuest (ARQ) usually happens, though the acknowledgment may
429 be omitted in some cases, for instance if there is no scheduled cell
430 for a retry.
432 Track Forwarding is the simplest and fastest. A bundle of cells set
433 to receive (RX-cells) is uniquely paired to a bundle of cells that
434 are set to transmit (TX-cells), representing a layer-2 forwarding
435 state that can be used regardless of the network layer protocol.
436 This model can effectively be seen as a Generalized Multi-protocol
437 Label Switching (G-MPLS) operation in that the information used to
438 switch a frame is not an explicit label, but rather related to other
439 properties of the way the packet was received, a particular cell in
440 the case of 6TiSCH. As a result, as long as the TSCH MAC (and
441 Layer-2 security) accepts a frame, that frame can be switched
442 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN
443 fragment, or a frame from an alternate protocol such as WirelessHART
444 or ISA100.11a.
446 A data frame that is forwarded along a Track normally has a
447 destination MAC address that is set to broadcast - or a multicast
448 address depending on MAC support. This way, the MAC layer in the
449 intermediate nodes accepts the incoming frame and 6top switches it
450 without incurring a change in the MAC header. In the case of
451 IEEE802.15.4, this means effectively broadcast, so that along the
452 Track the short address for the destination of the frame is set to
453 0xFFFF.
455 A Track is thus formed end-to-end as a succession of paired bundles,
456 a receive bundle from the previous hop and a transmit bundle to the
457 next hop along the Track, and a cell in such a bundle belongs to at
458 most one Track. For a given iteration of the device schedule, the
459 effective channel of the cell is obtained by adding a pseudo-random
460 number to the channelOffset of the cell, which results in a rotation
461 of the frequency that used for transmission. The bundles may be
462 computed so as to accommodate both variable rates and
463 retransmissions, so they might not be fully used at a given iteration
464 of the schedule. The 6TiSCH architecture provides additional means
465 to avoid waste of cells as well as overflows in the transmit bundle,
466 as follows:
468 In one hand, a TX-cell that is not needed for the current iteration
469 may be reused opportunistically on a per-hop basis for routed
470 packets. When all of the frame that were received for a given Track
471 are effectively transmitted, any available TX-cell for that Track can
472 be reused for upper layer traffic for which the next-hop router
473 matches the next hop along the Track. In that case, the cell that is
474 being used is effectively a TX-cell from the Track, but the short
475 address for the destination is that of the next-hop router. It
476 results that a frame that is received in a RX-cell of a Track with a
477 destination MAC address set to this node as opposed to broadcast must
478 be extracted from the Track and delivered to the upper layer (a frame
479 with an unrecognized MAC address is dropped at the lower MAC layer
480 and thus is not received at the 6top sublayer).
482 On the other hand, it might happen that there are not enough TX-cells
483 in the transmit bundle to accommodate the Track traffic, for instance
484 if more retransmissions are needed than provisioned. In that case,
485 the frame can be placed for transmission in the bundle that is used
486 for layer-3 traffic towards the next hop along the track as long as
487 it can be routed by the upper layer, that is, typically, if the frame
488 transports an IPv6 packet. The MAC address should be set to the
489 next-hop MAC address to avoid confusion. It results that a frame
490 that is received over a layer-3 bundle may be in fact associated to a
491 Track. In a classical IP link such as an Ethernet, off-track traffic
492 is typically in excess over reservation to be routed along the non-
493 reserved path based on its QoS setting. But with 6TiSCH, since the
494 use of the layer-3 bundle may be due to transmission failures, it
495 makes sense for the receiver to recognize a frame that should be re-
496 tracked, and to place it back on the appropriate bundle if possible.
497 A frame should be re-tracked if the Per-Hop-Behavior group indicated
498 in the Differentiated Services Field in the IPv6 header is set to
499 Deterministic Forwarding, as discussed in Section 4.1. A frame is
500 re-tracked by scheduling it for transmission over the transmit bundle
501 associated to the Track, with the destination MAC address set to
502 broadcast.
504 There are 2 modes for a Track, transport mode and tunnel mode.
506 3.4.1. Transport Mode
508 In transport mode, the Protocol Data Unit (PDU) is associated with
509 flow-dependant meta-data that refers uniquely to the Track, so the
510 6top sublayer can place the frame in the appropriate cell without
511 ambiguity. In the case of IPv6 traffic, this flow identification is
512 transported in the Flow Label of the IPv6 header. Associated with
513 the source IPv6 address, the Flow Label forms a globally unique
514 identifier for that particular Track that is validated at egress
515 before restoring the destination MAC address (DMAC) and punting to
516 the upper layer.
518 | ^
519 +--------------+ | |
520 | IPv6 | | |
521 +--------------+ | |
522 | 6LoWPAN HC | | |
523 +--------------+ ingress egress
524 | 6top | sets +----+ +----+ restores
525 +--------------+ dmac to | | | | dmac to
526 | TSCH MAC | brdcst | | | | self
527 +--------------+ | | | | | |
528 | LLN PHY | +-------+ +--...-----+ +-------+
529 +--------------+
531 Track Forwarding, Transport Mode
533 3.4.2. Tunnel Mode
535 In tunnel mode, the frames originate from an arbitrary protocol over
536 a compatible MAC that may or may not be synchronized with the 6TiSCH
537 network. An example of this would be a router with a dual radio that
538 is capable of receiving and sending WirelessHART or ISA100.11a frames
539 with the second radio, by presenting itself as an access Point or a
540 Backbone Router, respectively.
542 In that mode, some entity (e.g. PCE) can coordinate with a
543 WirelessHART Network Manager or an ISA100.11a System Manager to
544 specify the flows that are to be transported transparently over the
545 Track.
547 +--------------+
548 | IPv6 |
549 +--------------+
550 | 6LoWPAN HC |
551 +--------------+ set restore
552 | 6top | +dmac+ +dmac+
553 +--------------+ to|brdcst to|nexthop
554 | TSCH MAC | | | | |
555 +--------------+ | | | |
556 | LLN PHY | +-------+ +--...-----+ +-------+
557 +--------------+ | ingress egress |
558 | |
559 +--------------+ | |
560 | LLN PHY | | |
561 +--------------+ | |
562 | TSCH MAC | | |
563 +--------------+ | dmac = | dmac =
564 |ISA100/WiHART | | nexthop v nexthop
565 +--------------+
567 Figure 5: Track Forwarding, Tunnel Mode
569 In that case, the flow information that identifies the Track at the
570 ingress 6TiSCH router is derived from the RX-cell. The dmac is set
571 to this node but the flow information indicates that the frame must
572 be tunneled over a particular Track so the frame is not passed to the
573 upper layer. Instead, the dmac is forced to broadcast and the frame
574 is passed to the 6top sublayer for switching.
576 At the egress 6TiSCH router, the reverse operation occurs. Based on
577 metadata associated to the Track, the frame is passed to the
578 appropriate link layer with the destination MAC restored.
580 3.4.3. Tunnel Metadata
582 Metadata coming with the Track configuration is expected to provide
583 the destination MAC address of the egress endpoint as well as the
584 tunnel mode and specific data depending on the mode, for instance a
585 service access point for frame delivery at egress. If the tunnel
586 egress point does not have a MAC address that matches the
587 configuration, the Track installation fails.
589 In transport mode, if the final layer-3 destination is the tunnel
590 termination, then it is possible that the IPv6 address of the
591 destination is compressed at the 6LoWPAN sublayer based on the MAC
592 address. It is thus mandatory at the ingress point to validate that
593 the MAC address that was used at the 6LoWPAN sublayer for compression
594 matches that of the tunnel egress point. For that reason, the node
595 that injects a packet on a Track checks that the destination is
596 effectively that of the tunnel egress point before it overwrites it
597 to broadcast. The 6top sublayer at the tunnel egress point reverts
598 that operation to the MAC address obtained from the tunnel metadata.
600 4. Operations of Interest for DetNet and PCE
602 In a classical system, the 6TiSCH device does not place the request
603 for bandwidth between self and another device in the network.
604 Rather, an Operation Control System invoked through an Human/Machine
605 Interface (HMI) indicates the Traffic Specification, in particular in
606 terms of latency and reliability, and the end nodes. With this, the
607 PCE must compute a Track between the end nodes and provision the
608 network with per-flow state that describes the per-hop operation for
609 a given packet, the corresponding timeSlots, and the flow
610 identification that enables to recognize when a certain packet
611 belongs to a certain Track, sort out duplicates, etc...
613 For a static configuration that serves a certain purpose for a long
614 period of time, it is expected that a node will be provisioned in one
615 shot with a full schedule, which incorporates the aggregation of its
616 behavior for multiple Tracks. 6TiSCH expects that the programing of
617 the schedule will be done over COAP as discussed in 6TiSCH Resource
618 Management and Interaction using CoAP [I-D.ietf-6tisch-coap].
620 But an Hybrid mode may be required as well whereby a single Track is
621 added, modified, or removed, for instance if it appears that a Track
622 does not perform as expected for, say, PDR. For that case, the
623 expectation is that a protocol that flows along a Track (to be), in a
624 fashion similar to classical Traffic Engineering (TE) [CCAMP], may be
625 used to update the state in the devices. 6TiSCH provides means for a
626 device to negotiate a timeSlot with a neighbor, but in general that
627 flow was not designed and no protocol was selected and it is expected
628 that DetNet will determine the appropriate end-to-end protocols to be
629 used in that case.
631 Stream Management Entity
633 Operational System and HMI
635 -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
637 PCE PCE PCE PCE
639 -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
641 --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
642 6TiSCH / Device Device Device Device \
643 Device- - 6TiSCH
644 \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
645 ----Device------Device------Device------Device--
647 Figure 6
649 4.1. Packet Marking and Handling
651 Section "Packet Marking and Handling" of
652 [I-D.ietf-6tisch-architecture] describes the packet tagging and
653 marking that is expected in 6TiSCH networks.
655 4.1.1. Tagging Packets for Flow Identification
657 For packets that are routed by a PCE along a Track, the tuple formed
658 by the IPv6 source address and a local RPLInstanceID is tagged in the
659 packets to identify uniquely the Track and associated transmit bundle
660 of timeSlots.
662 It results that the tagging that is used for a DetNet flow outside
663 the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the
664 packet enters and then leaves the 6TiSCH network.
666 Note: The method and format used for encoding the RPLInstanceID at
667 6lo is generalized to all 6TiSCH topological Instances, which
668 includes Tracks.
670 4.1.2. Replication, Retries and Elimination
672 6TiSCH expects elimination and replication of packets along a complex
673 Track, but has no position about how the sequence numbers would be
674 tagged in the packet.
676 As it goes, 6TiSCH expects that timeSlots corresponding to copies of
677 a same packet along a Track are correlated by configuration, and does
678 not need to process the sequence numbers.
680 The semantics of the configuration MUST enable correlated timeSlots
681 to be grouped for transmit (and respectively receive) with a 'OR'
682 relations, and then a 'AND' relation MUST be configurable between
683 groups. The semantics is that if the transmit (and respectively
684 receive) operation succeeded in one timeSlot in a 'OR' group, then
685 all the other timeSLots in the group are ignored. Now, if there are
686 at least two groups, the 'AND' relation between the groups indicates
687 that one operation must succeed in each of the groups.
689 On the transmit side, timeSlots provisioned for retries along a same
690 branch of a Track are placed a same 'OR' group. The 'OR' relation
691 indicates that if a transmission is acknowledged, then further
692 transmissions SHOULD NOT be attempted for timeSlots in that group.
693 There are as many 'OR' groups as there are branches of the Track
694 departing from this node. Different 'OR' groups are programmed for
695 the purpose of replication, each group corresponding to one branch of
696 the Track. The 'AND' relation between the groups indicates that
697 transmission over any of branches MUST be attempted regardless of
698 whether a transmission succeeded in another branch. It is also
699 possible to place cells to different next-hop routers in a same 'OR'
700 group. This allows to route along multi-path tracks, trying one
701 next-hop and then another only if sending to the first fails.
703 On the receive side, all timeSlots are programmed in a same 'OR'
704 group. Retries of a same copy as well as converging branches for
705 elimination are converged, meaning that the first successful
706 reception is enough and that all the other timeSlots can be ignored.
708 4.1.3. Differentiated Services Per-Hop-Behavior
710 Additionally, an IP packet that is sent along a Track uses the
711 Differentiated Services Per-Hop-Behavior Group called Deterministic
712 Forwarding, as described in
713 [I-D.svshah-tsvwg-deterministic-forwarding].
715 4.2. Topology and capabilities
717 6TiSCH nodes are usually IoT devices, characterized by very limited
718 amount of memory, just enough buffers to store one or a few IPv6
719 packets, and limited bandwidth between peers. It results that a node
720 will maintain only a small number of peering information, and will
721 not be able to store many packets waiting to be forwarded. Peers can
722 be identified through MAC or IPv6 addresses, but a Cryptographically
723 Generated Address [RFC3972] (CGA) may also be used.
725 Neighbors can be discovered over the radio using mechanism such as
726 beacons, but, though the neighbor information is available in the
727 6TiSCH interface data model, 6TiSCH does not describe a protocol to
728 pro-actively push the neighborhood information to a PCE. This
729 protocol should be described and should operate over CoAP. The
730 protocol should be able to carry multiple metrics, in particular the
731 same metrics as used for RPL operations [RFC6551]
733 The energy that the device consumes in sleep, transmit and receive
734 modes can be evaluated and reported. So can the amount of energy
735 that is stored in the device and the power that it can be scavenged
736 from the environment. The PCE SHOULD be able to compute Tracks that
737 will implement policies on how the energy is consumed, for instance
738 balance between nodes, ensure that the spent energy does not exceeded
739 the scavenged energy over a period of time, etc...
741 5. IANA Considerations
743 This specification does not require IANA action.
745 6. Security Considerations
747 On top of the classical protection of control signaling that can be
748 expected to support DetNet, it must be noted that 6TiSCH networks
749 operate on limited resources that can be depleted rapidly if an
750 attacker manages to operate a DoS attack on the system, for instance
751 by placing a rogue device in the network, or by obtaining management
752 control and to setup extra paths.
754 7. Acknowledgments
756 This specification derives from the 6TiSCH architecture, which is the
757 result of multiple interactions, in particular during the 6TiSCH
758 (bi)Weekly Interim call, relayed through the 6TiSCH mailing list at
759 the IETF.
761 The authors wish to thank: Kris Pister, Thomas Watteyne, Xavier
762 Vilajosana, Qin Wang, Tom Phinney, Robert Assimiti, Michael
763 Richardson, Zhuo Chen, Malisa Vucinic, Alfredo Grieco, Martin Turon,
764 Dominique Barthel, Elvis Vogli, Guillaume Gaillard, Herman Storey,
765 Maria Rita Palattella, Nicola Accettura, Patrick Wetterwald, Pouria
766 Zand, Raghuram Sudhaakar, and Shitanshu Shah for their participation
767 and various contributions.
769 8. References
771 8.1. Normative References
773 [I-D.ietf-6tisch-6top-interface]
774 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
775 Operation Sublayer (6top) Interface", draft-ietf-6tisch-
776 6top-interface-03 (work in progress), March 2015.
778 [I-D.ietf-6tisch-architecture]
779 Thubert, P., "An Architecture for IPv6 over the TSCH mode
780 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work
781 in progress), May 2015.
783 [I-D.ietf-6tisch-coap]
784 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
785 Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
786 in progress), March 2015.
788 [I-D.ietf-6tisch-terminology]
789 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
790 "Terminology in IPv6 over the TSCH mode of IEEE
791 802.15.4e", draft-ietf-6tisch-terminology-04 (work in
792 progress), March 2015.
794 [I-D.ietf-6tisch-tsch]
795 Watteyne, T., Palattella, M., and L. Grieco, "Using
796 IEEE802.15.4e TSCH in an IoT context: Overview, Problem
797 Statement and Goals", draft-ietf-6tisch-tsch-06 (work in
798 progress), March 2015.
800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
801 Requirement Levels", BCP 14, RFC 2119, March 1997.
803 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
804 (IPv6) Specification", RFC 2460, December 1998.
806 8.2. Informative References
808 [I-D.finn-detnet-architecture]
809 Finn, N., Thubert, P., and M. Teener, "Deterministic
810 Networking Architecture", draft-finn-detnet-
811 architecture-01 (work in progress), March 2015.
813 [I-D.ietf-ipv6-multilink-subnets]
814 Thaler, D. and C. Huitema, "Multi-link Subnet Support in
815 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
816 progress), July 2002.
818 [I-D.ietf-roll-rpl-industrial-applicability]
819 Phinney, T., Thubert, P., and R. Assimiti, "RPL
820 applicability in industrial networks", draft-ietf-roll-
821 rpl-industrial-applicability-02 (work in progress),
822 October 2013.
824 [I-D.svshah-tsvwg-deterministic-forwarding]
825 Shah, S. and P. Thubert, "Deterministic Forwarding PHB",
826 draft-svshah-tsvwg-deterministic-forwarding-03 (work in
827 progress), March 2015.
829 [I-D.thubert-6lowpan-backbone-router]
830 Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
831 6lowpan-backbone-router-03 (work in progress), February
832 2013.
834 [I-D.wang-6tisch-6top-sublayer]
835 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
836 Operation Sublayer (6top)", draft-wang-6tisch-6top-
837 sublayer-01 (work in progress), July 2014.
839 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
840 "Definition of the Differentiated Services Field (DS
841 Field) in the IPv4 and IPv6 Headers", RFC 2474, December
842 1998.
844 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
845 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
846 Tunnels", RFC 3209, December 2001.
848 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
849 Information Models and Data Models", RFC 3444, January
850 2003.
852 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
853 RFC 3972, March 2005.
855 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
856 Architecture", RFC 4291, February 2006.
858 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June
859 2007.
861 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
862 over Low-Power Wireless Personal Area Networks (6LoWPANs):
863 Overview, Assumptions, Problem Statement, and Goals", RFC
864 4919, August 2007.
866 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
867 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
868 September 2011.
870 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
871 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
872 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
873 Lossy Networks", RFC 6550, March 2012.
875 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
876 Barthel, "Routing Metrics Used for Path Calculation in
877 Low-Power and Lossy Networks", RFC 6551, March 2012.
879 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
880 "Neighbor Discovery Optimization for IPv6 over Low-Power
881 Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
882 November 2012.
884 8.3. Other Informative References
886 [ACE] IETF, "Authentication and Authorization for Constrained
887 Environments", .
890 [CCAMP] IETF, "Common Control and Measurement Plane",
891 .
893 [DICE] IETF, "DTLS In Constrained Environments",
894 .
896 [HART] www.hartcomm.org, "Highway Addressable remote Transducer,
897 a group of specifications for industrial process and
898 control devices administered by the HART Foundation".
900 [IEEE802.1TSNTG]
901 IEEE Standards Association, "IEEE 802.1 Time-Sensitive
902 Networks Task Group", March 2013,
903 .
905 [IEEE802154]
906 IEEE standard for Information Technology, "IEEE std.
907 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
908 and Physical Layer (PHY) Specifications for Low-Rate
909 Wireless Personal Area Networks".
911 [IEEE802154e]
912 IEEE standard for Information Technology, "IEEE standard
913 for Information Technology, IEEE std. 802.15.4, Part.
914 15.4: Wireless Medium Access Control (MAC) and Physical
915 Layer (PHY) Specifications for Low-Rate Wireless Personal
916 Area Networks, June 2011 as amended by IEEE std.
917 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
918 Networks (LR-WPANs) Amendment 1: MAC sublayer", April
919 2012.
921 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation",
922 .
924 [ISA100.11a]
925 ISA/ANSI, "Wireless Systems for Industrial Automation:
926 Process Control and Related Applications - ISA100.11a-2011
927 - IEC 62734", 2011, .
930 [PCE] IETF, "Path Computation Element",
931 .
933 [TEAS] IETF, "Traffic Engineering Architecture and Signaling",
934 .
936 [WirelessHART]
937 www.hartcomm.org, "Industrial Communication Networks -
938 Wireless Communication Network and Communication Profiles
939 - WirelessHART - IEC 62591", 2010.
941 Author's Address
943 Pascal Thubert (editor)
944 Cisco Systems, Inc
945 Building D
946 45 Allee des Ormes - BP1200
947 MOUGINS - Sophia Antipolis 06254
948 FRANCE
950 Phone: +33 497 23 26 34
951 Email: pthubert@cisco.com