idnits 2.17.1 draft-thubert-paw-for-tisch-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 (January 28, 2019) is 1912 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'HART' is defined on line 805, but no explicit reference was found in the text == Unused Reference: 'ISA100' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'TEAS' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'WirelessHART' is defined on line 929, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-19 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-10 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-10 == Outdated reference: A later version (-06) exists of draft-thubert-6lo-bier-dispatch-05 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAW P. Thubert, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational January 28, 2019 5 Expires: August 1, 2019 7 PAW for TSCH 8 draft-thubert-paw-for-tisch-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 https://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 August 1, 2019. 44 Copyright Notice 46 Copyright (c) 2019 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 (https://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. 6TiSCH Overview . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. SlotFrames and Priorities . . . . . . . . . . . . . . . . 7 65 3.2. Schedule Management by a PCE . . . . . . . . . . . . . . 8 66 3.3. Track Scheduling Protocol . . . . . . . . . . . . . . . . 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 3.4.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4. Operations of Interest for DetNet and PCE . . . . . . . . . . 14 73 4.1. Packet Marking and Handling . . . . . . . . . . . . . . . 15 74 4.1.1. Tagging Packets for Flow Identification . . . . . . . 15 75 4.1.2. Replication, Retries and Elimination . . . . . . . . 16 76 4.1.3. Differentiated Services Per-Hop-Behavior . . . . . . 16 77 4.2. Topology and capabilities . . . . . . . . . . . . . . . . 17 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 83 8.2. Informative References . . . . . . . . . . . . . . . . . 18 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) [RFC7554] mode for 106 deterministic industrial-type applications. TSCH was introduced with 107 the IEEE802.15.4e [IEEE802154e] amendment and will be wrapped up in 108 the next revision of the IEEE802.15.4 standard. For all practical 109 purpose, this document is expected to be insensitive to the future 110 versions of the IEEE802.15.4 standard, which is thus referenced 111 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 the 6TiSCH 136 Architecture has on PAW, PCE [PCE] and DetNet 137 [I-D.ietf-detnet-architecture] to provide the necessary capabilities 138 that may be specific to such networks. 140 2. Terminology 142 The draft uses terminology defined or referenced in 143 [I-D.ietf-6tisch-architecture] and 144 [I-D.ietf-roll-rpl-industrial-applicability]. 146 The draft also conforms to the terms and models described in 147 [RFC3444] and uses the vocabulary and the concepts defined in 148 [RFC4291] for the IPv6 Architecture. 150 3. 6TiSCH Overview 152 The scope of the present work is a subnet that, in its basic 153 configuration, is made of a TSCH [RFC7554] MAC Low Power Lossy 154 Network (LLN). 156 ---+-------- ............ ------------ 157 | External Network | 158 | +-----+ 159 +-----+ | NME | 160 | | LLN Border | | 161 | | router +-----+ 162 +-----+ 163 o o o 164 o o o o 165 o o LLN o o o 166 o o o o 167 o 169 Figure 1: Basic Configuration of a 6TiSCH Network 171 In the extended configuration, a Backbone Router (6BBR) 172 [I-D.ietf-6lo-backbone-router] federates multiple 6TiSCH in a single 173 subnet over a backbone. PAW needs to ensure that 6BBRs synchronize 174 with one another over the backbone, so that the multiple LLNs that 175 form the IPv6 subnet stay tightly synchronized. 177 ---+-------- ............ ------------ 178 | External Network | 179 | +-----+ 180 | +-----+ | NME | 181 +-----+ | +-----+ | | 182 | | Router | | PCE | +-----+ 183 | | +--| | 184 +-----+ +-----+ 185 | | 186 | Subnet Backbone | 187 +--------------------+------------------+ 188 | | | 189 +-----+ +-----+ +-----+ 190 | | Backbone | | Backbone | | Backbone 191 o | | router | | router | | router 192 +-----+ +-----+ +-----+ 193 o o o o o 194 o o o o o o o o o o o 195 o o o LLN o o o o 196 o o o o o o o o o o o o 198 Figure 2: Extended Configuration of a 6TiSCH Network 200 If the Backbone is Deterministic, then PAW must enable the 6BBRS to 201 ensure that the end-to-end deterministic behavior is maintained 202 between the LLN and the backbone. This SHOULD be done in conformance 203 to the DetNet Architecture [I-D.ietf-detnet-architecture] which 204 studies Layer-3 aspects of Deterministic Networks, and covers 205 networks that span multiple Layer-2 domains. One particular 206 requirement is that the PCE MUST be able to compute a deterministic 207 path and to end across the TSCH network and an IEEE802.1 TSN Ethernet 208 backbone, and DetNet MUST enable end-to-end deterministic forwarding. 210 6TiSCH defines the concept of a Track, which is a complex form of a 211 uni-directional Circuit ([I-D.ietf-6tisch-architecture]) but did not 212 propose the methods to implement them: this would be a task for PAW. 213 As opposed to a simple circuit that is a sequence of nodes and links, 214 a Track is shaped as a directed acyclic graph towards a destination 215 to support multi-path forwarding and route around failures. A Track 216 may also branch off and rejoin, for the purpose of the so-called 217 Packet Replication and Elimination (PRE), over non congruent 218 branches. PRE may be used to complement layer-2 Automatic Repeat 219 reQuest (ARQ) to meet industrial expectations in Packet Delivery 220 Ratio (PDR), in particular when the Track extends beyond the 6TiSCH 221 network. 223 +-----+ 224 | IoT | 225 | G/W | 226 +-----+ 227 ^ <---- Elimination 228 | | 229 Track branch | | 230 +-------+ +--------+ Subnet Backbone 231 | | 232 +--|--+ +--|--+ 233 | | | Backbone | | | Backbone 234 o | | | router | | | router 235 +--/--+ +--|--+ 236 o / o o---o----/ o 237 o o---o--/ o o o o o 238 o \ / o o LLN o 239 o v <---- Replication 240 o 242 Figure 3: End-to-End deterministic Track 244 In the example above, a Track is laid out from a field device in a 245 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN 246 backbone. 248 The Replication function in the field device sends a copy of each 249 packet over two different branches, and the PCE schedules each hop of 250 both branches so that the two copies arrive in due time at the 251 gateway. In case of a loss on one branch, hopefully the other copy 252 of the packet still makes it in due time. If two copies make it to 253 the IoT gateway, the Elimination function in the gateway ignores the 254 extra packet and presents only one copy to upper layers. 256 At each 6TiSCH hop along the Track, the PCE may schedule more than 257 one timeSlot for a packet, so as to support Layer-2 retries (ARQ). 258 It is also possible that the field device only uses the second branch 259 if sending over the first branch fails. 261 In current deployments, a TSCH Track does not necessarily support PRE 262 but is systematically multi-path. This means that a Track is 263 scheduled so as to ensure that each hop has at least two forwarding 264 solutions, and the forwarding decision is to try the preferred one 265 and use the other in case of Layer-2 transmission failure as detected 266 by ARQ. 268 3.1. SlotFrames and Priorities 270 A slotFrame is the base object that the PCE needs to manipulate to 271 program a schedule into an LLN node. Elaboration on that concept can 272 be fond in section "SlotFrames and Priorities" of 273 [I-D.ietf-6tisch-architecture] 275 IEEE802.15.4 TSCH avoids contention on the medium by formatting time 276 and frequencies in cells of transmission of equal duration. In order 277 to describe that formatting of time and frequencies, the 6TiSCH 278 architecture defines a global concept that is called a Channel 279 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 280 cells with an height equal to the number of available channels 281 (indexed by ChannelOffsets) and a width (in timeSlots) that is the 282 period of the network scheduling operation (indexed by slotOffsets) 283 for that CDU matrix. The size of a cell is a timeSlot duration, and 284 values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to 285 accommodate for the transmission of a frame and an ack, including the 286 security validation on the receive side which may take up to a few 287 milliseconds on some device architecture. 289 The frequency used by a cell in the matrix rotates in a pseudo-random 290 fashion, from an initial position at an epoch time, as the matrix 291 iterates over and over. 293 A CDU matrix is computed by the PCE, but unallocated timeSlots may be 294 used opportunistically by the nodes for classical best effort IP 295 traffic. The PCE has precedence in the allocation in case of a 296 conflict. 298 In a given network, there might be multiple CDU matrices that operate 299 with different width, so they have different durations and represent 300 different periodic operations. It is recommended that all CDU 301 matrices in a 6TiSCH domain operate with the same cell duration and 302 are aligned, so as to reduce the chances of interferences from 303 slotted-aloha operations. The PCE MUST compute the CDU matrices and 304 shared that knowledge with all the nodes. The matrices are used in 305 particular to define slotFrames. 307 A slotFrame is a MAC-level abstraction that is common to all nodes 308 and contains a series of timeSlots of equal length and precedence. 309 It is characterized by a slotFrame_ID, and a slotFrame_size. A 310 slotFrame aligns to a CDU matrix for its parameters, such as number 311 and duration of timeSlots. 313 Multiple slotFrames can coexist in a node schedule, i.e., a node can 314 have multiple activities scheduled in different slotFrames, based on 315 the precedence of the 6TiSCH topologies. The slotFrames may be 316 aligned to different CDU matrices and thus have different width. 317 There is typically one slotFrame for scheduled traffic that has the 318 highest precedence and one or more slotFrame(s) for RPL traffic. The 319 timeSlots in the slotFrame are indexed by the SlotOffset; the first 320 cell is at SlotOffset 0. 322 The 6TiSCH architecture introduces the concept of chunks 323 ([I-D.ietf-6tisch-architecture]) to operate such spectrum 324 distribution for a whole group of cells at a time. The CDU matrix is 325 formatted into a set of chunks, each of them identified uniquely by a 326 chunk-ID. The PCE MUST compute the partitioning of CDU matrices into 327 chunks and shared that knowledge with all the nodes in a 6TiSCH 328 network. 330 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 331 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 332 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 333 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 334 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 335 ... 336 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 337 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 338 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 339 0 1 2 3 4 5 6 M 341 Figure 4: CDU matrix Partitioning in Chunks 343 The appropriation of a chunk can be requested explicitly by the PCE 344 to any node. After a successful appropriation, the PCE owns the 345 cells in that chunk, and may use them as hard cells to set up Tracks. 346 Then again, 6TiSCH did not propose a method for chunk definition and 347 a protocol for appropriation. This is to be done at PAW. 349 3.2. Schedule Management by a PCE 351 6TiSCH supports a mixed model of centralized routes and distributed 352 routes. Centralized routes can for example be computed by a entity 353 such as a PCE. Distributed routes are computed by RPL. 355 Both methods may inject routes in the Routing Tables of the 6TiSCH 356 routers. In either case, each route is associated with a 6TiSCH 357 topology that can be a RPL Instance topology or a track. The 6TiSCH 358 topology is indexed by a Instance ID, in a format that reuses the 359 RPLInstanceID as defined in RPL [RFC6550]. 361 Both RPL and PCE rely on shared sources such as policies to define 362 Global and Local RPLInstanceIDs that can be used by either method. 363 It is possible for centralized and distributed routing to share a 364 same topology. Generally they will operate in different slotFrames, 365 and centralized routes will be used for scheduled traffic and will 366 have precedence over distributed routes in case of conflict between 367 the slotFrames. 369 3.3. Track Scheduling Protocol 371 Section "Schedule Management Mechanisms" of the 6TiSCH architecture 372 describes 4 paradigms to manage the TSCH schedule of the LLN nodes: 373 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 374 and scheduling management, and Hop-by-hop scheduling. The Track 375 operation for DetNet corresponds to a remote monitoring and 376 scheduling management by a PCE. 378 Early work at 6TiSCH on a data model and a protocol to program the 379 schedule in the 6TiSCH device was never concluded as the group 380 focussed on best effort traffic. This work would be revived by PAW: 382 The 6top interface document [I-D.ietf-6tisch-6top-interface] (to 383 be reopened at PAW) was intended to specify the generic data model 384 that can be used to monitor and manage resources of the 6top 385 sublayer. Abstract methods were suggested for use by a management 386 entity in the device. The data model also enables remote control 387 operations on the 6top sublayer. 389 [I-D.ietf-6tisch-coap] (to be reopened at PAW) was intended to 390 define a mapping of the 6top set of commands, which is described 391 in [I-D.ietf-6tisch-6top-interface], to CoAP resources. This 392 allows an entity to interact with the 6top layer of a node that is 393 multiple hops away in a RESTful fashion. 395 [I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and 396 associated RESTful access methods (GET/PUT/POST/DELETE). The 397 payload (body) of the CoAP messages is encoded using the CBOR 398 format. The PCE commands are expected to be issued directly as 399 CoAP requests or to be mapped back and forth into CoAP by a 400 gateway function at the edge of the 6TiSCH network. For instance, 401 it is possible that a mapping entity on the backbone transforms a 402 non-CoAP protocol such as PCEP into the RESTful interfaces that 403 the 6TiSCH devices support. 405 3.4. Track Forwarding 407 By forwarding, this specification means the per-packet operation that 408 allows to deliver a packet to a next hop or an upper layer in this 409 node. Forwarding is based on pre-existing state that was installed 410 as a result of the routing computation of a Track by a PCE. The 411 6TiSCH architecture supports three different forwarding model, G-MPLS 412 Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 413 Forwarding (6F) which is the classical IP operation. The DetNet case 414 relates to the Track Forwarding operation under the control of a PCE. 416 A Track is a unidirectional path between a source and a destination. 417 In a Track cell, the normal operation of IEEE802.15.4 Automatic 418 Repeat-reQuest (ARQ) usually happens, though the acknowledgment may 419 be omitted in some cases, for instance if there is no scheduled cell 420 for a retry. 422 Track Forwarding is the simplest and fastest. A bundle of cells set 423 to receive (RX-cells) is uniquely paired to a bundle of cells that 424 are set to transmit (TX-cells), representing a layer-2 forwarding 425 state that can be used regardless of the network layer protocol. 426 This model can effectively be seen as a Generalized Multi-protocol 427 Label Switching (G-MPLS) operation in that the information used to 428 switch a frame is not an explicit label, but rather related to other 429 properties of the way the packet was received, a particular cell in 430 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 431 Layer-2 security) accepts a frame, that frame can be switched 432 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 433 fragment, or a frame from an alternate protocol such as WirelessHART 434 or ISA100.11a. 436 A data frame that is forwarded along a Track normally has a 437 destination MAC address that is set to broadcast - or a multicast 438 address depending on MAC support. This way, the MAC layer in the 439 intermediate nodes accepts the incoming frame and 6top switches it 440 without incurring a change in the MAC header. In the case of 441 IEEE802.15.4, this means effectively broadcast, so that along the 442 Track the short address for the destination of the frame is set to 443 0xFFFF. 445 A Track is thus formed end-to-end as a succession of paired bundles, 446 a receive bundle from the previous hop and a transmit bundle to the 447 next hop along the Track, and a cell in such a bundle belongs to at 448 most one Track. For a given iteration of the device schedule, the 449 effective channel of the cell is obtained by adding a pseudo-random 450 number to the channelOffset of the cell, which results in a rotation 451 of the frequency that used for transmission. The bundles may be 452 computed so as to accommodate both variable rates and 453 retransmissions, so they might not be fully used at a given iteration 454 of the schedule. The 6TiSCH architecture provides additional means 455 to avoid waste of cells as well as overflows in the transmit bundle, 456 as follows: 458 In one hand, a TX-cell that is not needed for the current iteration 459 may be reused opportunistically on a per-hop basis for routed 460 packets. When all of the frame that were received for a given Track 461 are effectively transmitted, any available TX-cell for that Track can 462 be reused for upper layer traffic for which the next-hop router 463 matches the next hop along the Track. In that case, the cell that is 464 being used is effectively a TX-cell from the Track, but the short 465 address for the destination is that of the next-hop router. It 466 results that a frame that is received in a RX-cell of a Track with a 467 destination MAC address set to this node as opposed to broadcast must 468 be extracted from the Track and delivered to the upper layer (a frame 469 with an unrecognized MAC address is dropped at the lower MAC layer 470 and thus is not received at the 6top sublayer). 472 On the other hand, it might happen that there are not enough TX-cells 473 in the transmit bundle to accommodate the Track traffic, for instance 474 if more retransmissions are needed than provisioned. In that case, 475 the frame can be placed for transmission in the bundle that is used 476 for layer-3 traffic towards the next hop along the track as long as 477 it can be routed by the upper layer, that is, typically, if the frame 478 transports an IPv6 packet. The MAC address should be set to the 479 next-hop MAC address to avoid confusion. It results that a frame 480 that is received over a layer-3 bundle may be in fact associated to a 481 Track. In a classical IP link such as an Ethernet, off-track traffic 482 is typically in excess over reservation to be routed along the non- 483 reserved path based on its QoS setting. But with 6TiSCH, since the 484 use of the layer-3 bundle may be due to transmission failures, it 485 makes sense for the receiver to recognize a frame that should be re- 486 tracked, and to place it back on the appropriate bundle if possible. 487 A frame should be re-tracked if the Per-Hop-Behavior group indicated 488 in the Differentiated Services Field in the IPv6 header is set to 489 Deterministic Forwarding, as discussed in Section 4.1. A frame is 490 re-tracked by scheduling it for transmission over the transmit bundle 491 associated to the Track, with the destination MAC address set to 492 broadcast. 494 There are 2 modes for a Track, transport mode and tunnel mode. 496 3.4.1. Transport Mode 498 In transport mode, the Protocol Data Unit (PDU) is associated with 499 flow-dependant meta-data that refers uniquely to the Track, so the 500 6top sublayer can place the frame in the appropriate cell without 501 ambiguity. In the case of IPv6 traffic, this flow identification is 502 transported in the Flow Label of the IPv6 header. Associated with 503 the source IPv6 address, the Flow Label forms a globally unique 504 identifier for that particular Track that is validated at egress 505 before restoring the destination MAC address (DMAC) and punting to 506 the upper layer. 508 | ^ 509 +--------------+ | | 510 | IPv6 | | | 511 +--------------+ | | 512 | 6LoWPAN HC | | | 513 +--------------+ ingress egress 514 | 6top | sets +----+ +----+ restores 515 +--------------+ dmac to | | | | dmac to 516 | TSCH MAC | brdcst | | | | self 517 +--------------+ | | | | | | 518 | LLN PHY | +-------+ +--...-----+ +-------+ 519 +--------------+ 521 Track Forwarding, Transport Mode 523 3.4.2. Tunnel Mode 525 In tunnel mode, the frames originate from an arbitrary protocol over 526 a compatible MAC that may or may not be synchronized with the 6TiSCH 527 network. An example of this would be a router with a dual radio that 528 is capable of receiving and sending WirelessHART or ISA100.11a frames 529 with the second radio, by presenting itself as an Access Point or a 530 Backbone Router, respectively. 532 In that mode, some entity (e.g. PCE) can coordinate with a 533 WirelessHART Network Manager or an ISA100.11a System Manager to 534 specify the flows that are to be transported transparently over the 535 Track. 537 +--------------+ 538 | IPv6 | 539 +--------------+ 540 | 6LoWPAN HC | 541 +--------------+ set restore 542 | 6top | +dmac+ +dmac+ 543 +--------------+ to|brdcst to|nexthop 544 | TSCH MAC | | | | | 545 +--------------+ | | | | 546 | LLN PHY | +-------+ +--...-----+ +-------+ 547 +--------------+ | ingress egress | 548 | | 549 +--------------+ | | 550 | LLN PHY | | | 551 +--------------+ | | 552 | TSCH MAC | | | 553 +--------------+ | dmac = | dmac = 554 |ISA100/WiHART | | nexthop v nexthop 555 +--------------+ 557 Figure 5: Track Forwarding, Tunnel Mode 559 In that case, the flow information that identifies the Track at the 560 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 561 to this node but the flow information indicates that the frame must 562 be tunneled over a particular Track so the frame is not passed to the 563 upper layer. Instead, the dmac is forced to broadcast and the frame 564 is passed to the 6top sublayer for switching. 566 At the egress 6TiSCH router, the reverse operation occurs. Based on 567 metadata associated to the Track, the frame is passed to the 568 appropriate link layer with the destination MAC restored. 570 3.4.3. Tunnel Metadata 572 Metadata coming with the Track configuration is expected to provide 573 the destination MAC address of the egress endpoint as well as the 574 tunnel mode and specific data depending on the mode, for instance a 575 service access point for frame delivery at egress. If the tunnel 576 egress point does not have a MAC address that matches the 577 configuration, the Track installation fails. 579 In transport mode, if the final layer-3 destination is the tunnel 580 termination, then it is possible that the IPv6 address of the 581 destination is compressed at the 6LoWPAN sublayer based on the MAC 582 address. It is thus mandatory at the ingress point to validate that 583 the MAC address that was used at the 6LoWPAN sublayer for compression 584 matches that of the tunnel egress point. For that reason, the node 585 that injects a packet on a Track checks that the destination is 586 effectively that of the tunnel egress point before it overwrites it 587 to broadcast. The 6top sublayer at the tunnel egress point reverts 588 that operation to the MAC address obtained from the tunnel metadata. 590 3.4.4. OAM 592 An Overview of Operations, Administration, and Maintenance (OAM) 593 Tools [RFC7276] provides an overwiew of the existing tooling for OAM 594 [RFC6291]. Tracks are complex paths and new tooling is necessary to 595 manage them, with respect to load control, timing, and the Packet 596 Replication and Elimination Functions (PREF). 598 An example of such tooling can be found in the context of BIER 599 [RFC8279] and more specifically BIER Traffic Engineering 600 [I-D.ietf-bier-te-arch] (BIER-TE): 601 [I-D.thubert-bier-replication-elimination] leverages BIER-TE to 602 control the process of PREF, and to provide traceability of these 603 operations, in the deterministic dataplane, along a complex Track. 604 For the 6TiSCH type of constrained environment, 605 [I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the 606 BIER bitmap within the 6LoRH framework. 608 4. Operations of Interest for DetNet and PCE 610 In a classical system, the 6TiSCH device does not place the request 611 for bandwidth between self and another device in the network. 612 Rather, an Operation Control System invoked through an Human/Machine 613 Interface (HMI) indicates the Traffic Specification, in particular in 614 terms of latency and reliability, and the end nodes. With this, the 615 PCE must compute a Track between the end nodes and provision the 616 network with per-flow state that describes the per-hop operation for 617 a given packet, the corresponding timeSlots, and the flow 618 identification that enables to recognize when a certain packet 619 belongs to a certain Track, sort out duplicates, etc... 621 For a static configuration that serves a certain purpose for a long 622 period of time, it is expected that a node will be provisioned in one 623 shot with a full schedule, which incorporates the aggregation of its 624 behavior for multiple Tracks. 6TiSCH expects that the programing of 625 the schedule will be done over COAP as discussed in 6TiSCH Resource 626 Management and Interaction using CoAP [I-D.ietf-6tisch-coap]. 628 But an Hybrid mode may be required as well whereby a single Track is 629 added, modified, or removed, for instance if it appears that a Track 630 does not perform as expected for, say, PDR. For that case, the 631 expectation is that a protocol that flows along a Track (to be), in a 632 fashion similar to classical Traffic Engineering (TE) [CCAMP], may be 633 used to update the state in the devices. 6TiSCH provides means for a 634 device to negotiate a timeSlot with a neighbor, but in general that 635 flow was not designed and no protocol was selected and it is expected 636 that DetNet will determine the appropriate end-to-end protocols to be 637 used in that case. 639 Stream Management Entity 641 Operational System and HMI 643 -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 645 PCE PCE PCE PCE 647 -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 649 --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- 650 6TiSCH / Device Device Device Device \ 651 Device- - 6TiSCH 652 \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device 653 ----Device------Device------Device------Device-- 655 Figure 6 657 4.1. Packet Marking and Handling 659 Section "Packet Marking and Handling" of 660 [I-D.ietf-6tisch-architecture] describes the packet tagging and 661 marking that is expected in 6TiSCH networks. 663 4.1.1. Tagging Packets for Flow Identification 665 For packets that are routed by a PCE along a Track, the tuple formed 666 by the IPv6 source address and a local RPLInstanceID is tagged in the 667 packets to identify uniquely the Track and associated transmit bundle 668 of timeSlots. 670 It results that the tagging that is used for a DetNet flow outside 671 the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the 672 packet enters and then leaves the 6TiSCH network. 674 Note: The method and format used for encoding the RPLInstanceID at 675 6lo is generalized to all 6TiSCH topological Instances, which 676 includes Tracks. 678 4.1.2. Replication, Retries and Elimination 680 6TiSCH expects elimination and replication of packets along a complex 681 Track, but has no position about how the sequence numbers would be 682 tagged in the packet. 684 As it goes, 6TiSCH expects that timeSlots corresponding to copies of 685 a same packet along a Track are correlated by configuration, and does 686 not need to process the sequence numbers. 688 The semantics of the configuration MUST enable correlated timeSlots 689 to be grouped for transmit (and respectively receive) with a 'OR' 690 relations, and then a 'AND' relation MUST be configurable between 691 groups. The semantics is that if the transmit (and respectively 692 receive) operation succeeded in one timeSlot in a 'OR' group, then 693 all the other timeSLots in the group are ignored. Now, if there are 694 at least two groups, the 'AND' relation between the groups indicates 695 that one operation must succeed in each of the groups. 697 On the transmit side, timeSlots provisioned for retries along a same 698 branch of a Track are placed a same 'OR' group. The 'OR' relation 699 indicates that if a transmission is acknowledged, then further 700 transmissions SHOULD NOT be attempted for timeSlots in that group. 701 There are as many 'OR' groups as there are branches of the Track 702 departing from this node. Different 'OR' groups are programmed for 703 the purpose of replication, each group corresponding to one branch of 704 the Track. The 'AND' relation between the groups indicates that 705 transmission over any of branches MUST be attempted regardless of 706 whether a transmission succeeded in another branch. It is also 707 possible to place cells to different next-hop routers in a same 'OR' 708 group. This allows to route along multi-path tracks, trying one 709 next-hop and then another only if sending to the first fails. 711 On the receive side, all timeSlots are programmed in a same 'OR' 712 group. Retries of a same copy as well as converging branches for 713 elimination are converged, meaning that the first successful 714 reception is enough and that all the other timeSlots can be ignored. 716 4.1.3. Differentiated Services Per-Hop-Behavior 718 Additionally, an IP packet that is sent along a Track uses the 719 Differentiated Services Per-Hop-Behavior Group called Deterministic 720 Forwarding, as described in 721 [I-D.svshah-tsvwg-deterministic-forwarding]. 723 4.2. Topology and capabilities 725 6TiSCH nodes are usually IoT devices, characterized by very limited 726 amount of memory, just enough buffers to store one or a few IPv6 727 packets, and limited bandwidth between peers. It results that a node 728 will maintain only a small number of peering information, and will 729 not be able to store many packets waiting to be forwarded. Peers can 730 be identified through MAC or IPv6 addresses. 732 Neighbors can be discovered over the radio using mechanism such as 733 beacons, but, though the neighbor information is available in the 734 6TiSCH interface data model, 6TiSCH does not describe a protocol to 735 pro-actively push the neighborhood information to a PCE. This 736 protocol should be described and should operate over CoAP. The 737 protocol should be able to carry multiple metrics, in particular the 738 same metrics as used for RPL operations [RFC6551] 740 The energy that the device consumes in sleep, transmit and receive 741 modes can be evaluated and reported. So can the amount of energy 742 that is stored in the device and the power that it can be scavenged 743 from the environment. The PCE SHOULD be able to compute Tracks that 744 will implement policies on how the energy is consumed, for instance 745 balance between nodes, ensure that the spent energy does not exceeded 746 the scavenged energy over a period of time, etc... 748 5. IANA Considerations 750 This specification does not require IANA action. 752 6. Security Considerations 754 On top of the classical protection of control signaling that can be 755 expected to support DetNet, it must be noted that 6TiSCH networks 756 operate on limited resources that can be depleted rapidly if an 757 attacker manages to operate a DoS attack on the system, for instance 758 by placing a rogue device in the network, or by obtaining management 759 control and to setup extra paths. 761 7. Acknowledgments 763 This specification derives from the 6TiSCH architecture, which is the 764 result of multiple interactions, in particular during the 6TiSCH 765 (bi)Weekly Interim call, relayed through the 6TiSCH mailing list at 766 the IETF. 768 The authors wish to thank: Kris Pister, Thomas Watteyne, Xavier 769 Vilajosana, Qin Wang, Tom Phinney, Robert Assimiti, Michael 770 Richardson, Zhuo Chen, Malisa Vucinic, Alfredo Grieco, Martin Turon, 771 Dominique Barthel, Elvis Vogli, Guillaume Gaillard, Herman Storey, 772 Maria Rita Palattella, Nicola Accettura, Patrick Wetterwald, Pouria 773 Zand, Raghuram Sudhaakar, and Shitanshu Shah for their participation 774 and various contributions. 776 8. References 778 8.1. Normative References 780 [I-D.ietf-6tisch-6top-interface] 781 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 782 (6top) Interface", draft-ietf-6tisch-6top-interface-04 783 (work in progress), July 2015. 785 [I-D.ietf-6tisch-architecture] 786 Thubert, P., "An Architecture for IPv6 over the TSCH mode 787 of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work 788 in progress), December 2018. 790 [I-D.ietf-6tisch-coap] 791 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 792 Interaction using CoAP", draft-ietf-6tisch-coap-03 (work 793 in progress), March 2015. 795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 796 Requirement Levels", BCP 14, RFC 2119, 797 DOI 10.17487/RFC2119, March 1997, 798 . 800 8.2. Informative References 802 [CCAMP] IETF, "Common Control and Measurement Plane", 803 . 805 [HART] www.hartcomm.org, "Highway Addressable remote Transducer, 806 a group of specifications for industrial process and 807 control devices administered by the HART Foundation". 809 [I-D.ietf-6lo-backbone-router] 810 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 811 Backbone Router", draft-ietf-6lo-backbone-router-10 (work 812 in progress), January 2019. 814 [I-D.ietf-bier-te-arch] 815 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 816 Engineering for Bit Index Explicit Replication (BIER-TE)", 817 draft-ietf-bier-te-arch-01 (work in progress), October 818 2018. 820 [I-D.ietf-detnet-architecture] 821 Finn, N., Thubert, P., Varga, B., and J. Farkas, 822 "Deterministic Networking Architecture", draft-ietf- 823 detnet-architecture-10 (work in progress), December 2018. 825 [I-D.ietf-roll-rpl-industrial-applicability] 826 Phinney, T., Thubert, P., and R. Assimiti, "RPL 827 applicability in industrial networks", draft-ietf-roll- 828 rpl-industrial-applicability-02 (work in progress), 829 October 2013. 831 [I-D.svshah-tsvwg-deterministic-forwarding] 832 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 833 draft-svshah-tsvwg-deterministic-forwarding-04 (work in 834 progress), August 2015. 836 [I-D.thubert-6lo-bier-dispatch] 837 Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A 838 6loRH for BitStrings", draft-thubert-6lo-bier-dispatch-05 839 (work in progress), July 2018. 841 [I-D.thubert-bier-replication-elimination] 842 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 843 TE extensions for Packet Replication and Elimination 844 Function (PREF) and OAM", draft-thubert-bier-replication- 845 elimination-03 (work in progress), March 2018. 847 [IEEE802.1TSNTG] 848 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 849 Networks Task Group", March 2013, 850 . 852 [IEEE802154] 853 IEEE standard for Information Technology, "IEEE std. 854 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 855 and Physical Layer (PHY) Specifications for Low-Rate 856 Wireless Personal Area Networks". 858 [IEEE802154e] 859 IEEE standard for Information Technology, "IEEE standard 860 for Information Technology, IEEE std. 802.15.4, Part. 861 15.4: Wireless Medium Access Control (MAC) and Physical 862 Layer (PHY) Specifications for Low-Rate Wireless Personal 863 Area Networks, June 2011 as amended by IEEE std. 864 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 865 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 866 2012. 868 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 869 . 871 [ISA100.11a] 872 ISA/ANSI, "Wireless Systems for Industrial Automation: 873 Process Control and Related Applications - ISA100.11a-2011 874 - IEC 62734", 2011, . 877 [PCE] IETF, "Path Computation Element", 878 . 880 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 881 Information Models and Data Models", RFC 3444, 882 DOI 10.17487/RFC3444, January 2003, 883 . 885 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 886 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 887 2006, . 889 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 890 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 891 Acronym in the IETF", BCP 161, RFC 6291, 892 DOI 10.17487/RFC6291, June 2011, 893 . 895 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 896 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 897 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 898 Low-Power and Lossy Networks", RFC 6550, 899 DOI 10.17487/RFC6550, March 2012, 900 . 902 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 903 and D. Barthel, "Routing Metrics Used for Path Calculation 904 in Low-Power and Lossy Networks", RFC 6551, 905 DOI 10.17487/RFC6551, March 2012, 906 . 908 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 909 Weingarten, "An Overview of Operations, Administration, 910 and Maintenance (OAM) Tools", RFC 7276, 911 DOI 10.17487/RFC7276, June 2014, 912 . 914 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 915 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 916 Internet of Things (IoT): Problem Statement", RFC 7554, 917 DOI 10.17487/RFC7554, May 2015, 918 . 920 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 921 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 922 Explicit Replication (BIER)", RFC 8279, 923 DOI 10.17487/RFC8279, November 2017, 924 . 926 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 927 . 929 [WirelessHART] 930 www.hartcomm.org, "Industrial Communication Networks - 931 Wireless Communication Network and Communication Profiles 932 - WirelessHART - IEC 62591", 2010. 934 Author's Address 936 Pascal Thubert (editor) 937 Cisco Systems, Inc 938 Building D 939 45 Allee des Ormes - BP1200 940 MOUGINS - Sophia Antipolis 06254 941 FRANCE 943 Phone: +33 497 23 26 34 944 Email: pthubert@cisco.com