idnits 2.17.00 (12 Aug 2021) /tmp/idnits4629/draft-thubert-6tisch-4detnet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 4, 2015) is 2543 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 816, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 821, but not defined == Missing Reference: 'IEEE802154e' is mentioned on line 827, but not defined == Missing Reference: 'PCE' is mentioned on line 846, but not defined == Missing Reference: 'ACE' is mentioned on line 802, but not defined == Missing Reference: 'CCAMP' is mentioned on line 806, but not defined == Missing Reference: 'DICE' is mentioned on line 809, but not defined == Missing Reference: 'HART' is mentioned on line 812, but not defined == Missing Reference: 'ISA100' is mentioned on line 837, but not defined == Missing Reference: 'TEAS' is mentioned on line 849, but not defined == Missing Reference: 'WirelessHART' is mentioned on line 852, but not defined == Unused Reference: 'RFC2460' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC4903' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 795, 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: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-04 == Outdated reference: draft-ietf-6tisch-tsch has been published as RFC 7554 ** 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 (~~), 27 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 4, 2015 5 Expires: December 6, 2015 7 6TiSCH requirements for DetNet 8 draft-thubert-6tisch-4detnet-00 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 6, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. SlotFrames and Priorities . . . . . . . . . . . . . . . . . . 7 66 6. Schedule Management by a PCE . . . . . . . . . . . . . . . . 9 67 7. Track Forwarding . . . . . . . . . . . . . . . . . . . . . . 10 68 7.1. Transport Mode . . . . . . . . . . . . . . . . . . . . . 11 69 7.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.3. Tunnel Metadata . . . . . . . . . . . . . . . . . . . . . 13 71 8. Packet Marking and Handling . . . . . . . . . . . . . . . . . 14 72 8.1. Tagging Packets for Flow Identification . . . . . . . . . 14 73 8.2. Replication, Retries and Elimination . . . . . . . . . . 14 74 8.3. Differentiated Services Per-Hop-Behavior . . . . . . . . 15 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 12.2. Informative References . . . . . . . . . . . . . . . . . 16 81 12.3. Other Informative References . . . . . . . . . . . . . . 18 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 The emergence of wireless technology has enabled a variety of new 87 devices to get interconnected, at a very low marginal cost per 88 device, at any distance ranging from Near Field to interplanetary, 89 and in circumstances where wiring may not be practical, for instance 90 on fast-moving or rotating devices. 92 At the same time, a new breed of Time Sensitive Networks is being 93 developed to enable traffic that is highly sensitive to jitter, quite 94 sensitive to latency, and with a high degree of operational 95 criticality so that loss should be minimized at all times. Such 96 traffic is not limited to professional Audio/ Video networks, but is 97 also found in command and control operations such as industrial 98 automation and vehicular sensors and actuators. 100 At IEEE802.1, the Audio/Video Task Group [IEEE802.1TSNTG] Time 101 Sensitive Networking (TSN) to address Deterministic Ethernet. The 102 Medium access Control (MAC) of IEEE802.15.4 [IEEE802154] has evolved 103 with the new TimeSlotted Channel Hopping (TSCH) 104 [I-D.ietf-6tisch-tsch] mode for deterministic industrial-type 105 applications. TSCH was introduced with the IEEE802.15.4e 106 [IEEE802154e] amendment and will be wrapped up in the next revision 107 of the IEEE802.15.4 standard. For all practical purpose, this 108 document is expected to be insensitive to the future versions of the 109 IEEE802.15.4 standard, which is thus referenced undated. 111 Though at a different time scale, both TSN and TSCH standards provide 112 Deterministic capabilities to the point that a packet that pertains 113 to a certain flow crosses the network from node to node following a 114 very precise schedule, as a train that leaves intermediate stations 115 at precise times along its path. With TSCH, time is formatted into 116 timeSlots, and an individual cell is allocated to unicast or 117 broadcast communication at the MAC level. The time-slotted operation 118 reduces collisions, saves energy, and enables to more closely 119 engineer the network for deterministic properties. The channel 120 hopping aspect is a simple and efficient technique to combat multi- 121 path fading and co-channel interferences (for example by Wi-Fi 122 emitters). 124 The 6TiSCH Architecture [I-D.ietf-6tisch-architecture] defines a 125 remote monitoring and scheduling management of a TSCH network by a 126 Path Computation Element (PCE), which cooperates with an abstract 127 Network Management Entity (NME) to manage timeSlots and device 128 resources in a manner that minimizes the interaction with and the 129 load placed on the constrained devices. 131 This Architecture applies the concepts of Deterministic Networking on 132 a TSCH network to enable the switching of timeSlots in a G-MPLS 133 manner. This document details the dependencies that 6TiSCH has on 134 PCE [PCE] and DetNet [I-D.finn-detnet-architecture] to provide the 135 necessary capabilities that may be specific to such networks. In 136 turn, DetNet is expected to integrate and maintain consistency with 137 the work that has taken place and is continuing at IEEE802.1TSN and 138 AVnu. 140 2. Terminology 142 Readers are expected to be familiar with all the terms and concepts 143 that are discussed in "Multi-link Subnet Support in IPv6" 144 [I-D.ietf-ipv6-multilink-subnets]. 146 The draft uses terminology defined or referenced in 147 [I-D.ietf-6tisch-terminology] and 148 [I-D.ietf-roll-rpl-industrial-applicability]. 150 The draft also conforms to the terms and models described in 151 [RFC3444] and uses the vocabulary and the concepts defined in 152 [RFC4291] for the IPv6 Architecture. 154 3. Overview 156 The scope of the present work is a subnet that, in its basic 157 configuration, is made of a TSCH [I-D.ietf-6tisch-tsch] MAC Low Power 158 Lossy Network (LLN). 160 ---+-------- ............ ------------ 161 | External Network | 162 | +-----+ 163 +-----+ | NME | 164 | | LLN Border | | 165 | | router +-----+ 166 +-----+ 167 o o o 168 o o o o 169 o o LLN o o o 170 o o o o 171 o 173 Figure 1: Basic Configuration of a 6TiSCH Network 175 In the extended configuration, a Backbone Router (6BBR) federates 176 multiple 6TiSCH in a single subnet over a backbone. 6TiSCH 6BBRs 177 synchronize with one another over the backbone, so as to ensure that 178 the multiple LLNs that form the IPv6 subnet stay tightly 179 synchronized. 181 ---+-------- ............ ------------ 182 | External Network | 183 | +-----+ 184 | +-----+ | NME | 185 +-----+ | +-----+ | | 186 | | Router | | PCE | +-----+ 187 | | +--| | 188 +-----+ +-----+ 189 | | 190 | Subnet Backbone | 191 +--------------------+------------------+ 192 | | | 193 +-----+ +-----+ +-----+ 194 | | Backbone | | Backbone | | Backbone 195 o | | router | | router | | router 196 +-----+ +-----+ +-----+ 197 o o o o o 198 o o o o o o o o o o o 199 o o o LLN o o o o 200 o o o o o o o o o o o o 202 Figure 2: Extended Configuration of a 6TiSCH Network 204 If the Backbone is Deterministic, then the Backbone Router ensures 205 that the end-to-end deterministic behavior is maintained between the 206 LLN and the backbone. This SHOULD be done in conformance to the 207 DetNet Architecture [I-D.finn-detnet-architecture] which studies 208 Layer-3 aspects of Deterministic Networks, and covers networks that 209 span multiple Layer-2 domains. One particular requirement is that 210 the PCE MUST be able to compute a deterministic path and to end 211 across the TSCH network and an IEEE802.1 TSN Ethernet backbone, and 212 DetNet MUST enable end-to-end deterministic forwarding. 214 6TiSCH defines the concept of a Track, which is a complex form of a 215 uni-directional Circuit ([I-D.ietf-6tisch-terminology]). As opposed 216 to a simple circuit that is a sequence of nodes and links, a Track is 217 shaped as a directed acyclic graph towards a destination to support 218 multi-path forwarding and route around failures. A Track may also 219 branch off and rejoin, for the purpose of the so-called Packet 220 Replication and Elimination (PRE), over non congruent branches. PRE 221 may be used to complement layer-2 Automatic Repeat reQuest (ARQ) to 222 meet industrial expectations in Packet Delivery Ratio (PDR), in 223 particular when the Track extends beyond the 6TiSCH network. 225 +-----+ 226 | IoT | 227 | G/W | 228 +-----+ 229 ^ <---- Elimination 230 | | 231 Track branch | | 232 +-------+ +--------+ Subnet Backbone 233 | | 234 +--|--+ +--|--+ 235 | | | Backbone | | | Backbone 236 o | | | router | | | router 237 +--/--+ +--|--+ 238 o / o o---o----/ o 239 o o---o--/ o o o o o 240 o \ / o o LLN o 241 o v <---- Replication 242 o 244 Figure 3: End-to-End deterministic Track 246 In the example above, a Track is laid out from a field device in a 247 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN 248 backbone. 250 The Replication function in the field device sends a copy of each 251 packet over two different branches, and the PCE schedules each hop of 252 both branches so that the two copies arrive in due time at the 253 gateway. In case of a loss on one branch, hopefully the other copy 254 of the packet still makes it in due time. If two copies make it to 255 the IoT gateway, the Elimination function in the gateway ignores the 256 extra packet and presents only one copy to upper layers. 258 At each 6TiSCH hop along the Track, the PCE may schedule more than 259 one timeSlot for a packet, so as to support Layer-2 retries (ARQ). 260 It is also possible that the field device only uses the second branch 261 if sending over the first branch fails. 263 In current deployments, a TSCH Track does not necessarily support PRE 264 but is systematically multi-path. This means that a Track is 265 scheduled so as to ensure that each hop has at least two forwarding 266 solutions, and the forwarding decision is to try the preferred one 267 and use the other in case of Layer-2 transmission failure as detected 268 by ARQ. 270 4. TSCH and 6top 272 6top is a logical link control sitting between the IP layer and the 273 TSCH MAC layer, which provides the link abstraction that is required 274 for IP operations. The 6top operations are specified in 275 [I-D.wang-6tisch-6top-sublayer]. 277 The 6top data model and management interfaces are further discussed 278 in [I-D.ietf-6tisch-6top-interface] and [I-D.ietf-6tisch-coap]. 280 The architecture defines "soft" cells and "hard" cells. "Hard" cells 281 are owned and managed by an separate scheduling entity (e.g. a PCE) 282 that specifies the slotOffset/channelOffset of the cells to be 283 added/moved/deleted, in which case 6top can only act as instructed, 284 and may not move hard cells in the TSCH schedule on its own. 286 5. SlotFrames and Priorities 288 A slotFrame is the base object that the PCE needs to manipulate to 289 program a schedule into an LLN node. Elaboration on that concept can 290 be fond in section "SlotFrames and Priorities" of 291 [I-D.ietf-6tisch-architecture] 293 IEEE802.15.4 TSCH avoids contention on the medium by formatting time 294 and frequencies in cells of transmission of equal duration. In order 295 to describe that formatting of time and frequencies, the 6TiSCH 296 architecture defines a global concept that is called a Channel 297 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 298 cells with an height equal to the number of available channels 299 (indexed by ChannelOffsets) and a width (in timeSlots) that is the 300 period of the network scheduling operation (indexed by slotOffsets) 301 for that CDU matrix. The size of a cell is a timeSlot duration, and 302 values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to 303 accommodate for the transmission of a frame and an ack, including the 304 security validation on the receive side which may take up to a few 305 milliseconds on some device architecture. 307 The frequency used by a cell in the matrix rotates in a pseudo-random 308 fashion, from an initial position at an epoch time, as the matrix 309 iterates over and over. 311 A CDU matrix is computed by the PCE, but unallocated timeSlots may be 312 used opportunistically by the nodes for classical best effort IP 313 traffic. The PCE has precedence in the allocation in case of a 314 conflict. 316 In a given network, there might be multiple CDU matrices that operate 317 with different width, so they have different durations and represent 318 different periodic operations. It is recommended that all CDU 319 matrices in a 6TiSCH domain operate with the same cell duration and 320 are aligned, so as to reduce the chances of interferences from 321 slotted-aloha operations. The PCE MUST compute the CDU matrices and 322 shared that knowledge with all the nodes. The matrices are used in 323 particular to define slotFrames. 325 A slotFrame is a MAC-level abstraction that is common to all nodes 326 and contains a series of timeSlots of equal length and precedence. 327 It is characterized by a slotFrame_ID, and a slotFrame_size. A 328 slotFrame aligns to a CDU matrix for its parameters, such as number 329 and duration of timeSlots. 331 Multiple slotFrames can coexist in a node schedule, i.e., a node can 332 have multiple activities scheduled in different slotFrames, based on 333 the precedence of the 6TiSCH topologies. The slotFrames may be 334 aligned to different CDU matrices and thus have different width. 335 There is typically one slotFrame for scheduled traffic that has the 336 highest precedence and one or more slotFrame(s) for RPL traffic. The 337 timeSlots in the slotFrame are indexed by the SlotOffset; the first 338 cell is at SlotOffset 0. 340 The 6TiSCH architecture introduces the concept of chunks 341 ([I-D.ietf-6tisch-terminology]) to operate such spectrum distribution 342 for a whole group of cells at a time. The CDU matrix is formatted 343 into a set of chunks, each of them identified uniquely by a chunk-ID. 344 The PCE MUST compute the partitioning of CDU matrices into chunks and 345 shared that knowledge with all the nodes in a 6TiSCH network. 347 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 348 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 349 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 350 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 351 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 352 ... 353 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 354 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 355 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 356 0 1 2 3 4 5 6 M 358 Figure 4: CDU matrix Partitioning in Chunks 360 The appropriation of a chunk can be requested explicitly by the PCE 361 to any node. After a successful appropriation, the PCE owns the 362 cells in that chunk, and may use them as hard cells to set up Tracks. 364 6. Schedule Management by a PCE 366 6TiSCH supports a mixed model of centralized routes and distributed 367 routes. Centralized routes can for example be computed by a entity 368 such as a PCE. Distributed routes are computed by RPL. 370 Both methods may inject routes in the Routing Tables of the 6TiSCH 371 routers. In either case, each route is associated with a 6TiSCH 372 topology that can be a RPL Instance topology or a track. The 6TiSCH 373 topology is indexed by a Instance ID, in a format that reuses the 374 RPLInstanceID as defined in RPL [RFC6550]. 376 Both RPL and PCE rely on shared sources such as policies to define 377 Global and Local RPLInstanceIDs that can be used by either method. 378 It is possible for centralized and distributed routing to share a 379 same topology. Generally they will operate in different slotFrames, 380 and centralized routes will be used for scheduled traffic and will 381 have precedence over distributed routes in case of conflict between 382 the slotFrames. 384 Section "Schedule Management Mechanisms" of the 6TiSCH architecture 385 describes 4 paradigms to manage the TSCH schedule of the LLN nodes: 386 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 387 and scheduling management, and Hop-by-hop scheduling. The Track 388 operation for DetNet corresponds to a remote monitoring and 389 scheduling management by a PCE. 391 The 6top interface document [I-D.ietf-6tisch-6top-interface] 392 specifies the generic data model that can be used to monitor and 393 manage resources of the 6top sublayer. Abstract methods are 394 suggested for use by a management entity in the device. The data 395 model also enables remote control operations on the 6top sublayer. 397 [I-D.ietf-6tisch-coap] defines an mapping of the 6top set of 398 commands, which is described in [I-D.ietf-6tisch-6top-interface], to 399 CoAP resources. This allows an entity to interact with the 6top 400 layer of a node that is multiple hops away in a RESTful fashion. 402 [I-D.ietf-6tisch-coap] also defines a basic set CoAP resources and 403 associated RESTful access methods (GET/PUT/POST/DELETE). The payload 404 (body) of the CoAP messages is encoded using the CBOR format. The 405 PCE commands are expected to be issued directly as CoAP requests or 406 to be mapped back and forth into CoAP by a gateway function at the 407 edge of the 6TiSCH network. For instance, it is possible that a 408 mapping entity on the backbone transforms a non-CoAP protocol such as 409 PCEP into the RESTful interfaces that the 6TiSCH devices support. 410 This architecture will be refined to comply with DetNet 411 [I-D.finn-detnet-architecture] when the work is formalized. 413 7. Track Forwarding 415 By forwarding, this specification means the per-packet operation that 416 allows to deliver a packet to a next hop or an upper layer in this 417 node. Forwarding is based on pre-existing state that was installed 418 as a result of the routing computation of a Track by a PCE. The 419 6TiSCH architecture supports three different forwarding model, G-MPLS 420 Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 421 Forwarding (6F) which is the classical IP operation. The DetNet case 422 relates to the Track Forwarding operation under the control of a PCE. 424 A Track is a unidirectional path between a source and a destination. 425 In a Track cell, the normal operation of IEEE802.15.4 Automatic 426 Repeat-reQuest (ARQ) usually happens, though the acknowledgment may 427 be omitted in some cases, for instance if there is no scheduled cell 428 for a retry. 430 Track Forwarding is the simplest and fastest. A bundle of cells set 431 to receive (RX-cells) is uniquely paired to a bundle of cells that 432 are set to transmit (TX-cells), representing a layer-2 forwarding 433 state that can be used regardless of the network layer protocol. 434 This model can effectively be seen as a Generalized Multi-protocol 435 Label Switching (G-MPLS) operation in that the information used to 436 switch a frame is not an explicit label, but rather related to other 437 properties of the way the packet was received, a particular cell in 438 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 439 Layer-2 security) accepts a frame, that frame can be switched 440 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 441 fragment, or a frame from an alternate protocol such as WirelessHART 442 or ISA100.11a. 444 A data frame that is forwarded along a Track normally has a 445 destination MAC address that is set to broadcast - or a multicast 446 address depending on MAC support. This way, the MAC layer in the 447 intermediate nodes accepts the incoming frame and 6top switches it 448 without incurring a change in the MAC header. In the case of 449 IEEE802.15.4, this means effectively broadcast, so that along the 450 Track the short address for the destination of the frame is set to 451 0xFFFF. 453 A Track is thus formed end-to-end as a succession of paired bundles, 454 a receive bundle from the previous hop and a transmit bundle to the 455 next hop along the Track, and a cell in such a bundle belongs to at 456 most one Track. For a given iteration of the device schedule, the 457 effective channel of the cell is obtained by adding a pseudo-random 458 number to the channelOffset of the cell, which results in a rotation 459 of the frequency that used for transmission. The bundles may be 460 computed so as to accommodate both variable rates and 461 retransmissions, so they might not be fully used at a given iteration 462 of the schedule. The 6TiSCH architecture provides additional means 463 to avoid waste of cells as well as overflows in the transmit bundle, 464 as follows: 466 In one hand, a TX-cell that is not needed for the current iteration 467 may be reused opportunistically on a per-hop basis for routed 468 packets. When all of the frame that were received for a given Track 469 are effectively transmitted, any available TX-cell for that Track can 470 be reused for upper layer traffic for which the next-hop router 471 matches the next hop along the Track. In that case, the cell that is 472 being used is effectively a TX-cell from the Track, but the short 473 address for the destination is that of the next-hop router. It 474 results that a frame that is received in a RX-cell of a Track with a 475 destination MAC address set to this node as opposed to broadcast must 476 be extracted from the Track and delivered to the upper layer (a frame 477 with an unrecognized MAC address is dropped at the lower MAC layer 478 and thus is not received at the 6top sublayer). 480 On the other hand, it might happen that there are not enough TX-cells 481 in the transmit bundle to accommodate the Track traffic, for instance 482 if more retransmissions are needed than provisioned. In that case, 483 the frame can be placed for transmission in the bundle that is used 484 for layer-3 traffic towards the next hop along the track as long as 485 it can be routed by the upper layer, that is, typically, if the frame 486 transports an IPv6 packet. The MAC address should be set to the 487 next-hop MAC address to avoid confusion. It results that a frame 488 that is received over a layer-3 bundle may be in fact associated to a 489 Track. In a classical IP link such as an Ethernet, off-track traffic 490 is typically in excess over reservation to be routed along the non- 491 reserved path based on its QoS setting. But with 6TiSCH, since the 492 use of the layer-3 bundle may be due to transmission failures, it 493 makes sense for the receiver to recognize a frame that should be re- 494 tracked, and to place it back on the appropriate bundle if possible. 495 A frame should be re-tracked if the Per-Hop-Behavior group indicated 496 in the Differentiated Services Field in the IPv6 header is set to 497 Deterministic Forwarding, as discussed in Section 8. A frame is re- 498 tracked by scheduling it for transmission over the transmit bundle 499 associated to the Track, with the destination MAC address set to 500 broadcast. 502 There are 2 modes for a Track, transport mode and tunnel mode. 504 7.1. Transport Mode 506 In transport mode, the Protocol Data Unit (PDU) is associated with 507 flow-dependant meta-data that refers uniquely to the Track, so the 508 6top sublayer can place the frame in the appropriate cell without 509 ambiguity. In the case of IPv6 traffic, this flow identification is 510 transported in the Flow Label of the IPv6 header. Associated with 511 the source IPv6 address, the Flow Label forms a globally unique 512 identifier for that particular Track that is validated at egress 513 before restoring the destination MAC address (DMAC) and punting to 514 the upper layer. 516 | ^ 517 +--------------+ | | 518 | IPv6 | | | 519 +--------------+ | | 520 | 6LoWPAN HC | | | 521 +--------------+ ingress egress 522 | 6top | sets +----+ +----+ restores 523 +--------------+ dmac to | | | | dmac to 524 | TSCH MAC | brdcst | | | | self 525 +--------------+ | | | | | | 526 | LLN PHY | +-------+ +--...-----+ +-------+ 527 +--------------+ 529 Track Forwarding, Transport Mode 531 7.2. Tunnel Mode 533 In tunnel mode, the frames originate from an arbitrary protocol over 534 a compatible MAC that may or may not be synchronized with the 6TiSCH 535 network. An example of this would be a router with a dual radio that 536 is capable of receiving and sending WirelessHART or ISA100.11a frames 537 with the second radio, by presenting itself as an access Point or a 538 Backbone Router, respectively. 540 In that mode, some entity (e.g. PCE) can coordinate with a 541 WirelessHART Network Manager or an ISA100.11a System Manager to 542 specify the flows that are to be transported transparently over the 543 Track. 545 +--------------+ 546 | IPv6 | 547 +--------------+ 548 | 6LoWPAN HC | 549 +--------------+ set restore 550 | 6top | +dmac+ +dmac+ 551 +--------------+ to|brdcst to|nexthop 552 | TSCH MAC | | | | | 553 +--------------+ | | | | 554 | LLN PHY | +-------+ +--...-----+ +-------+ 555 +--------------+ | ingress egress | 556 | | 557 +--------------+ | | 558 | LLN PHY | | | 559 +--------------+ | | 560 | TSCH MAC | | | 561 +--------------+ | dmac = | dmac = 562 |ISA100/WiHART | | nexthop v nexthop 563 +--------------+ 565 Figure 5: Track Forwarding, Tunnel Mode 567 In that case, the flow information that identifies the Track at the 568 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 569 to this node but the flow information indicates that the frame must 570 be tunneled over a particular Track so the frame is not passed to the 571 upper layer. Instead, the dmac is forced to broadcast and the frame 572 is passed to the 6top sublayer for switching. 574 At the egress 6TiSCH router, the reverse operation occurs. Based on 575 metadata associated to the Track, the frame is passed to the 576 appropriate link layer with the destination MAC restored. 578 7.3. Tunnel Metadata 580 Metadata coming with the Track configuration is expected to provide 581 the destination MAC address of the egress endpoint as well as the 582 tunnel mode and specific data depending on the mode, for instance a 583 service access point for frame delivery at egress. If the tunnel 584 egress point does not have a MAC address that matches the 585 configuration, the Track installation fails. 587 In transport mode, if the final layer-3 destination is the tunnel 588 termination, then it is possible that the IPv6 address of the 589 destination is compressed at the 6LoWPAN sublayer based on the MAC 590 address. It is thus mandatory at the ingress point to validate that 591 the MAC address that was used at the 6LoWPAN sublayer for compression 592 matches that of the tunnel egress point. For that reason, the node 593 that injects a packet on a Track checks that the destination is 594 effectively that of the tunnel egress point before it overwrites it 595 to broadcast. The 6top sublayer at the tunnel egress point reverts 596 that operation to the MAC address obtained from the tunnel metadata. 598 8. Packet Marking and Handling 600 Section "Packet Marking and Handling" of 601 [I-D.ietf-6tisch-architecture] describes the packet tagging and 602 marking that is expected in 6TiSCH networks. 604 8.1. Tagging Packets for Flow Identification 606 For packets that are routed by a PCE along a Track, the tuple formed 607 by the IPv6 source address and a local RPLInstanceID is tagged in the 608 packets to identify uniquely the Track and associated transmit bundle 609 of timeSlots. 611 It results that the tagging that is used for a DetNet flow outside 612 the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the 613 packet enters and then leaves the 6TiSCH network. 615 Note: The method and format used for encoding the RPLInstanceID at 616 6lo is generalized to all 6TiSCH topological Instances, which 617 includes Tracks. 619 8.2. Replication, Retries and Elimination 621 6TiSCH expects elimination and replication of packets along a complex 622 Track, but has no position about how the sequence numbers would be 623 tagged in the packet. 625 As it goes, 6TiSCH expects that timeSlots corresponding to copies of 626 a same packet along a Track are correlated by configuration, and does 627 not need to process the sequence numbers. 629 The semantics of the configuration MUST enable correlated timeSlots 630 to be grouped for transmit (and respectively receive) with a 'OR' 631 relations, and then a 'AND' relation MUST be configurable between 632 groups. The semantics is that if the transmit (and respectively 633 receive) operation succeeded in one timeSlot in a 'OR' group, then 634 all the other timeSLots in the group are ignored. Now, if there are 635 at least two groups, the 'AND' relation between the groups indicates 636 that one operation must succeed in each of the groups. 638 On the transmit side, timeSlots provisioned for retries along a same 639 branch of a Track are placed a same 'OR' group. The 'OR' relation 640 indicates that if a transmission is acknowledged, then further 641 transmissions SHOULD NOT be attempted for timeSlots in that group. 642 There are as many 'OR' groups as there are branches of the Track 643 departing from this node. Different 'OR' groups are programmed for 644 the purpose of replication, each group corresponding to one branch of 645 the Track. The 'AND' relation between the groups indicates that 646 transmission over any of branches MUST be attempted regardless of 647 whether a transmission succeeded in another branch. It is also 648 possible to place cells to different next-hop routers in a same 'OR' 649 group. This allows to route along multi-path tracks, trying one 650 next-hop and then another only if sending to the first fails. 652 On the receive side, all timeSlots are programmed in a same 'OR' 653 group. Retries of a same copy as well as converging branches for 654 elimination are converged, meaning that the first successful 655 reception is enough and that all the other timeSlots can be ignored. 657 8.3. Differentiated Services Per-Hop-Behavior 659 Additionally, an IP packet that is sent along a Track uses the 660 Differentiated Services Per-Hop-Behavior Group called Deterministic 661 Forwarding, as described in 662 [I-D.svshah-tsvwg-deterministic-forwarding]. 664 9. IANA Considerations 666 This specification does not require IANA action. 668 10. Security Considerations 670 On top of the classical protection of control signaling that can be 671 expected to support DetNet, it must be noted that 6TiSCH networks 672 operate on limited resources that can be depleted rapidly if an 673 attacker manages to operate a DoS attack on the system, for instance 674 by placing a rogue device in the network, or by obtaining management 675 control and to setup extra paths. 677 11. Acknowledgments 679 This specification derives from the 6TiSCH architecture, which is the 680 result of multiple interactions, in particular during the 6TiSCH 681 (bi)Weekly Interim call, relayed through the 6TiSCH mailing list at 682 the IETF. 684 The authors wish to thank: Kris Pister, Thomas Watteyne, Xavier 685 Vilajosana, Qin Wang, Tom Phinney, Robert Assimiti, Michael 686 Richardson, Zhuo Chen, Malisa Vucinic, Alfredo Grieco, Martin Turon, 687 Dominique Barthel, Elvis Vogli, Guillaume Gaillard, Herman Storey, 688 Maria Rita Palattella, Nicola Accettura, Patrick Wetterwald, Pouria 689 Zand, Raghuram Sudhaakar, and Shitanshu Shah for their participation 690 and various contributions. 692 12. References 694 12.1. Normative References 696 [I-D.ietf-6tisch-6top-interface] 697 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 698 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 699 6top-interface-03 (work in progress), March 2015. 701 [I-D.ietf-6tisch-architecture] 702 Thubert, P., "An Architecture for IPv6 over the TSCH mode 703 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 704 in progress), May 2015. 706 [I-D.ietf-6tisch-coap] 707 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 708 Interaction using CoAP", draft-ietf-6tisch-coap-03 (work 709 in progress), March 2015. 711 [I-D.ietf-6tisch-terminology] 712 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 713 "Terminology in IPv6 over the TSCH mode of IEEE 714 802.15.4e", draft-ietf-6tisch-terminology-04 (work in 715 progress), March 2015. 717 [I-D.ietf-6tisch-tsch] 718 Watteyne, T., Palattella, M., and L. Grieco, "Using 719 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 720 Statement and Goals", draft-ietf-6tisch-tsch-06 (work in 721 progress), March 2015. 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 727 (IPv6) Specification", RFC 2460, December 1998. 729 12.2. Informative References 731 [I-D.finn-detnet-architecture] 732 Finn, N., Thubert, P., and M. Teener, "Deterministic 733 Networking Architecture", draft-finn-detnet- 734 architecture-01 (work in progress), March 2015. 736 [I-D.ietf-ipv6-multilink-subnets] 737 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 738 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in 739 progress), July 2002. 741 [I-D.ietf-roll-rpl-industrial-applicability] 742 Phinney, T., Thubert, P., and R. Assimiti, "RPL 743 applicability in industrial networks", draft-ietf-roll- 744 rpl-industrial-applicability-02 (work in progress), 745 October 2013. 747 [I-D.svshah-tsvwg-deterministic-forwarding] 748 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 749 draft-svshah-tsvwg-deterministic-forwarding-03 (work in 750 progress), March 2015. 752 [I-D.thubert-6lowpan-backbone-router] 753 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 754 6lowpan-backbone-router-03 (work in progress), February 755 2013. 757 [I-D.wang-6tisch-6top-sublayer] 758 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 759 Operation Sublayer (6top)", draft-wang-6tisch-6top- 760 sublayer-01 (work in progress), July 2014. 762 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 763 "Definition of the Differentiated Services Field (DS 764 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 765 1998. 767 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 768 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 769 Tunnels", RFC 3209, December 2001. 771 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 772 Information Models and Data Models", RFC 3444, January 773 2003. 775 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 776 Architecture", RFC 4291, February 2006. 778 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 779 2007. 781 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 782 over Low-Power Wireless Personal Area Networks (6LoWPANs): 783 Overview, Assumptions, Problem Statement, and Goals", RFC 784 4919, August 2007. 786 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 787 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 788 September 2011. 790 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 791 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 792 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 793 Lossy Networks", RFC 6550, March 2012. 795 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 796 "Neighbor Discovery Optimization for IPv6 over Low-Power 797 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 798 November 2012. 800 12.3. Other Informative References 802 [ACE] IETF, "Authentication and Authorization for Constrained 803 Environments", . 806 [CCAMP] IETF, "Common Control and Measurement Plane", 807 . 809 [DICE] IETF, "DTLS In Constrained Environments", 810 . 812 [HART] www.hartcomm.org, "Highway Addressable remote Transducer, 813 a group of specifications for industrial process and 814 control devices administered by the HART Foundation". 816 [IEEE802.1TSNTG] 817 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 818 Networks Task Group", March 2013, 819 . 821 [IEEE802154] 822 IEEE standard for Information Technology, "IEEE std. 823 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 824 and Physical Layer (PHY) Specifications for Low-Rate 825 Wireless Personal Area Networks". 827 [IEEE802154e] 828 IEEE standard for Information Technology, "IEEE standard 829 for Information Technology, IEEE std. 802.15.4, Part. 830 15.4: Wireless Medium Access Control (MAC) and Physical 831 Layer (PHY) Specifications for Low-Rate Wireless Personal 832 Area Networks, June 2011 as amended by IEEE std. 833 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 834 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 835 2012. 837 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 838 . 840 [ISA100.11a] 841 ISA/ANSI, "Wireless Systems for Industrial Automation: 842 Process Control and Related Applications - ISA100.11a-2011 843 - IEC 62734", 2011, . 846 [PCE] IETF, "Path Computation Element", 847 . 849 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 850 . 852 [WirelessHART] 853 www.hartcomm.org, "Industrial Communication Networks - 854 Wireless Communication Network and Communication Profiles 855 - WirelessHART - IEC 62591", 2010. 857 Author's Address 859 Pascal Thubert (editor) 860 Cisco Systems, Inc 861 Building D 862 45 Allee des Ormes - BP1200 863 MOUGINS - Sophia Antipolis 06254 864 FRANCE 866 Phone: +33 497 23 26 34 867 Email: pthubert@cisco.com