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