idnits 2.17.1 draft-ietf-6tisch-architecture-23.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 == Line 2406 has weird spacing: '...ssimiti for h...' == Line 2409 has weird spacing: '... Pister for c...' == Line 2412 has weird spacing: '...attella for m...' == Line 2415 has weird spacing: '...hardson for h...' == Line 2418 has weird spacing: '... Struik for t...' == (6 more instances...) -- The document date (June 28, 2019) is 1761 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-12 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-11 == Outdated reference: A later version (-21) exists of draft-ietf-6lo-fragment-recovery-04 == Outdated reference: A later version (-15) exists of draft-ietf-6lo-minimal-fragment-02 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-dtsecurity-zerotouch-join-03 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-11 == Outdated reference: A later version (-18) exists of draft-ietf-6tisch-msf-03 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-22 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-00 == Outdated reference: A later version (-02) exists of draft-ietf-lwig-6lowpan-virtual-reassembly-01 == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-07 == Outdated reference: A later version (-34) exists of draft-ietf-roll-dao-projection-06 == Outdated reference: A later version (-30) exists of draft-ietf-roll-unaware-leaves-00 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-30 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-13 == Outdated reference: A later version (-02) exists of draft-thubert-6lo-unicast-lookup-00 == Outdated reference: A later version (-05) exists of draft-thubert-raw-technologies-02 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 24 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational June 28, 2019 5 Expires: December 30, 2019 7 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 8 draft-ietf-6tisch-architecture-23 10 Abstract 12 This document describes a network architecture that provides low- 13 latency, low-jitter and high-reliability packet delivery. It 14 combines a high-speed powered backbone and subnetworks using IEEE 15 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements 16 of LowPower wireless deterministic applications. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 30, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10 56 2.3. Related Documents . . . . . . . . . . . . . . . . . . . . 11 57 3. High Level Architecture . . . . . . . . . . . . . . . . . . . 12 58 3.1. A Non-Broadcast Multi-Access Radio Mesh Network . . . . . 12 59 3.2. A Multi-Link Subnet Model . . . . . . . . . . . . . . . . 14 60 3.3. TSCH: A Deterministic MAC Layer . . . . . . . . . . . . . 15 61 3.4. Scheduling TSCH . . . . . . . . . . . . . . . . . . . . . 16 62 3.5. Distributed vs. Centralized Routing . . . . . . . . . . . 17 63 3.6. Forwarding Over TSCH . . . . . . . . . . . . . . . . . . 18 64 3.7. 6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . 19 65 3.8. Communication Paradigms and Interaction Models . . . . . 21 66 4. Architecture Components . . . . . . . . . . . . . . . . . . . 22 67 4.1. 6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . . 22 68 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND . . . . . . . . . . 22 69 4.1.2. RPL Root And 6LBR . . . . . . . . . . . . . . . . . . 23 70 4.2. Network Access and Addressing . . . . . . . . . . . . . . 23 71 4.2.1. Join Process . . . . . . . . . . . . . . . . . . . . 23 72 4.2.2. Registration . . . . . . . . . . . . . . . . . . . . 25 73 4.3. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . 27 74 4.3.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . 27 75 4.3.2. Scheduling Functions and the 6top protocol . . . . . 28 76 4.3.3. 6top and RPL Objective Function operations . . . . . 30 77 4.3.4. Network Synchronization . . . . . . . . . . . . . . . 30 78 4.3.5. Slotframes and CDU matrix . . . . . . . . . . . . . . 32 79 4.3.6. Distributing the reservation of cells . . . . . . . . 33 80 4.4. Schedule Management Mechanisms . . . . . . . . . . . . . 34 81 4.4.1. Static Scheduling . . . . . . . . . . . . . . . . . . 34 82 4.4.2. Neighbor-to-neighbor Scheduling . . . . . . . . . . . 34 83 4.4.3. Remote Monitoring and Schedule Management . . . . . . 35 84 4.4.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . 38 85 4.5. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 38 86 4.5.1. General Behavior of Tracks . . . . . . . . . . . . . 39 87 4.5.2. Serial Track . . . . . . . . . . . . . . . . . . . . 39 88 4.5.3. Complex Track with Replication and Elimination . . . 40 89 4.5.4. DetNet End-to-end Path . . . . . . . . . . . . . . . 40 90 4.5.5. Cell Reuse . . . . . . . . . . . . . . . . . . . . . 41 91 4.6. Forwarding Models . . . . . . . . . . . . . . . . . . . . 42 92 4.6.1. Track Forwarding . . . . . . . . . . . . . . . . . . 42 93 4.6.2. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . 45 94 4.6.3. Fragment Forwarding . . . . . . . . . . . . . . . . . 45 95 4.7. Advanced 6TiSCH Routing . . . . . . . . . . . . . . . . . 47 96 4.7.1. Packet Marking and Handling . . . . . . . . . . . . . 47 97 4.7.2. Replication, Retries and Elimination . . . . . . . . 48 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 50 101 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 102 7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 52 103 7.2. Special Thanks . . . . . . . . . . . . . . . . . . . . . 53 104 7.3. And Do not Forget . . . . . . . . . . . . . . . . . . . . 54 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 106 8.1. Normative References . . . . . . . . . . . . . . . . . . 54 107 8.2. Informative References . . . . . . . . . . . . . . . . . 56 108 Appendix A. Related Work In Progress . . . . . . . . . . . . . . 63 109 A.1. Chartered IETF work items . . . . . . . . . . . . . . . . 63 110 A.2. Unchartered IETF work items . . . . . . . . . . . . . . . 63 111 A.2.1. 6TiSCH Zerotouch security . . . . . . . . . . . . . . 63 112 A.2.2. 6TiSCH Track Setup . . . . . . . . . . . . . . . . . 63 113 A.2.3. Using BIER in a 6TiSCH Network . . . . . . . . . . . 64 114 A.3. External (non-IETF) work items . . . . . . . . . . . . . 65 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 65 117 1. Introduction 119 Wireless Networks enable a wide variety of devices of any size to get 120 interconnected, often at a very low marginal cost per device, at any 121 range, and in circumstances where wiring may be impractical, for 122 instance on fast-moving or rotating devices. 124 On the other hand, Deterministic Networking maximizes the packet 125 delivery ratio within a bounded latency so as to enable mission- 126 critical machine-to-machine (M2M) operations. Applications that need 127 such networks are presented in [I-D.ietf-detnet-use-cases]. They 128 include Professional Media and Operation Technology (OT) Industrial 129 Automation Control Systems (IACS). 131 The Timeslotted Channel Hopping (TSCH) [RFC7554] mode of the IEEE 132 Std. 802.15.4 [IEEE802154] Medium Access Control (MAC) was introduced 133 with the IEEE Std. 802.15.4e [IEEE802154e] amendment and is now 134 retrofitted in the main standard. For all practical purposes, this 135 document is expected to be insensitive to the revisions of that 136 standard, which is thus referenced undated. TSCH is both a Time- 137 Division Multiplexing and a Frequency-Division Multiplexing technique 138 whereby a different channel can be used for each transmission, and 139 that allows to schedule transmissions for deterministic operations. 141 Proven Deterministic Networking standards for use in Process Control, 142 including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART], 143 have demonstrated the capabilities of the IEEE Std. 802.15.4 TSCH MAC 144 for high reliability against interference, low-power consumption on 145 well-known flows, and its applicability for Traffic Engineering (TE) 146 from a central controller. 148 To enable the convergence of Information Technology (IT) and 149 Operational Technology (OT) in Low-Power Lossy Networks (LLNs), the 150 6TiSCH Architecture supports an IETF suite of protocols over the IEEE 151 Std. 802.15.4TSCH MAC to provide IP connectivity for energy and 152 otherwise constrained wireless devices. 154 6TiSCH provides large scaling capabilities, which, in a number of 155 scenarios, require the addition of a high-speed and reliable backbone 156 and the use of IP version 6 (IPv6) [RFC8200]. The 6TiSCH 157 Architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to the 158 constrained media and RPL [RFC6550] for the distributed routing 159 operations. 161 The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model 162 that is composed of a federating backbone, e.g., an Ethernet bridged 163 network, and a number of IEEE Std. 802.15.4 TSCH low-power wireless 164 networks federated and synchronized by Backbone Routers. 166 Centralized routing refers to a model where routes are computed and 167 resources are allocated from a central controller. This is 168 particularly helpful to schedule deterministic multihop 169 transmissions. In contrast, Distributed Routing refers to a model 170 that relies on concurrent peer to peer protocol exchanges for TSCH 171 resource allocation and routing operations. 173 The architecture defines mechanisms to establish and maintain routing 174 and scheduling in a centralized, distributed, or mixed fashion, for 175 use in multiple OT environments. It is applicable in particular to 176 highly scalable solutions such as used in Advanced Metering 177 Infrastructure [AMI] solutions that leverage distributed routing to 178 enable multipath forwarding over large LLN meshes. 180 Other use cases includes industrial control systems, building 181 automation, in-vehicle command and control, commercial automation and 182 asset tracking with mobile scenarios, and home automation 183 applications. The determinism provides for a more reliable 184 experience which can be used to monitor and manage resources, e.g., 185 energy and water, in a more efficient fashion. 187 2. Terminology 189 2.1. New Terms 191 The draft does not reuse terms from the IEEE Std. 802.15.4 192 [IEEE802154] standard such as "path" or "link" which bear a meaning 193 that is quite different from classical IETF parlance. 195 This document adds the following terms: 197 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e): 6TiSCH defines 198 an adaptation sublayer for IPv6 over TSCH called 6top, a 199 set of protocols for setting up a TSCH schedule in 200 distributed approach, and a security solution. 6TiSCH may 201 be extended in the future for other MAC/PHY pairs 202 providing a service similar to TSCH. 204 6top (6TiSCH Operation Sublayer): The next higher layer of the IEEE 205 Std. 802.15.4 TSCH MAC layer. 6top provides the 206 abstraction of an IP link over a TSCH MAC, schedules 207 packets over TSCH cells, and exposes a management 208 interface to schedule TSCH cells. 210 6P (6top Protocol): The protocol defined in [RFC8480]. 6P enables 211 Layer-2 peers to allocate, move or deallocate cells in 212 their respective schedules to communicate. 6P operates 213 at the 6top layer. 215 6P Transaction: A 2-way or 3-way sequence of 6P messages used by 216 Layer-2 peers to modify their communication schedule. 218 ASN (Absolute Slot Number): The total number of timeslots that have 219 elapsed since the PAN coordinator has started the TSCH 220 network. Incremented by one at each timeslot. It is 221 wide enough to not roll over in practice. 223 bundle: A group of equivalent scheduled cells, i.e. cells 224 identified by different [slotOffset, channelOffset], 225 which are scheduled for a same purpose, with the same 226 neighbor, with the same flags, and the same slotframe. 227 The size of the bundle refers to the number of cells it 228 contains. For a given slotframe length, the size of the 229 bundle translates directly into bandwidth. A bundle is a 230 local abstraction that represents a half-duplex link for 231 either sending or receiving, with bandwidth that amounts 232 to the sum of the cells in the bundle. 234 Layer-2 vs. Layer-3 bundle: Bundles are associated for either 235 Layer-2 (switching) or Layer-3 (routing) forwarding 236 operations. A pair of Layer-3 bundles (one for each 237 direction) maps to an IP Link with a neighbor, whereas a 238 set of Layer-2 bundles (a number per neighbor, either 239 from or to the neighbor) corresponds to the relation of 240 one or more incoming bundle(s) from the previous-hop 241 neighbor(s) with one or more outgoing bundle(s) to the 242 next-hop neighbor(s) along a Track. 244 CCA (Clear Channel Assessment): A mechanism defined in [IEEE802154] 245 whereby nodes listen to the channel before sending to 246 detect ongoing transmissions from other parties. Because 247 the network is synchronized, CCA cannot be used to detect 248 colliding transmissions within the same network, but it 249 can be used to detect other radio networks in vicinity. 251 cell: A unit of transmission resource in the CDU matrix, a cell 252 is identified by a slotOffset and a channelOffset. A 253 cell can be scheduled or unscheduled. 255 Channel Distribution/Usage (CDU) matrix: : A matrix of cells (i,j) 256 representing the spectrum (channel) distribution among 257 the different nodes in the 6TiSCH network. The CDU 258 matrix has width in timeslots, equal to the period of the 259 network scheduling operation, and height equal to the 260 number of available channels. Every cell (i,j) in the 261 CDU, identified by (slotOffset, channelOffset), belongs 262 to a specific chunk. 264 channelOffset: Identifies a row in the TSCH schedule. The number of 265 channelOffset values is bounded by the number of 266 available frequencies. The channelOffset translates into 267 a frequency with a function that depends on the absolute 268 time when the communication takes place, resulting in a 269 channel hopping operation. 271 chunk: A well-known list of cells, distributed in time and 272 frequency, within a CDU matrix. A chunk represents a 273 portion of a CDU matrix. The partition of the CDU matrix 274 in chunks is globally known by all the nodes in the 275 network to support the appropriation process, which is a 276 negotiation between nodes within an interference domain. 277 A node that manages to appropriate a chunk gets to decide 278 which transmissions will occur over the cells in the 279 chunk within its interference domain (i.e., a parent node 280 will decide when the cells within the appropriated chunk 281 are used and by which node, among its children. 283 CoJP (Constrained Join Protocol): The Constrained Join Protocol 284 (CoJP) enables a pledge to securely join a 6TiSCH network 285 and obtain network parameters over a secure channel. 286 Minimal Security Framework for 6TiSCH 287 [I-D.ietf-6tisch-minimal-security] defines the minimal 288 CoJP setup with pre-shared keys defined. In that mode, 289 CoJP can operate with a single round trip exchange. 291 dedicated cell: A cell that is reserved for a given node to transmit 292 to a specific neighbor. 294 deterministic network: The generic concept of deterministic network 295 is defined in [I-D.ietf-detnet-architecture]. When 296 applied to 6TiSCH, it refers to the reservation of Tracks 297 which guarantee an end-to-end latency and optimize the 298 PDR for well-characterized flows. 300 distributed cell reservation: A reservation of a cell done by one or 301 more in-network entities. 303 distributed Track reservation: A reservation of a Track done by one 304 or more in-network entities. 306 EB (Enhanced Beacon): A special frame defined in [IEEE802154] used 307 by a node, including the JP, to announce the presence of 308 the network. It contains enough information for a pledge 309 to synchronize to the network. 311 hard cell: A scheduled cell which the 6top sublayer may not 312 relocate. 314 hopping sequence: Ordered sequence of frequencies, identified by a 315 Hopping_Sequence_ID, used for channel hopping when 316 translating the channelOffset value into a frequency. 318 IE (Information Element): Type-Length-Value containers placed at the 319 end of the MAC header, used to pass data between layers 320 or devices. Some IE identifiers are managed by the IEEE 321 [IEEE802154]. Some IE identifiers are managed by the 322 IETF [RFC8137]. 324 join process: The overall process that includes the discovery of the 325 network by pledge(s) and the execution of the join 326 protocol. 328 join protocol: The protocol that allows the pledge to join the 329 network. The join protocol encompasses authentication, 330 authorization and parameter distribution. The join 331 protocol is executed between the pledge and the JRC. 333 joined node: The new device, after having completed the join 334 process, often just called a node. 336 JP (Join Proxy): Node already part of the 6TiSCH network that serves 337 as a relay to provide connectivity between the pledge and 338 the JRC. The JP announces the presence of the network by 339 regularly sending EB frames. 341 JRC (Join Registrar/Coordinator): Central entity responsible for the 342 authentication, authorization and configuration of the 343 pledge. 345 link: A communication facility or medium over which nodes can 346 communicate at the Link-Layer, the layer immediately 347 below IP. In 6TiSCH, the concept is implemented as a 348 collection of Layer-3 bundles. Note: the IETF parlance 349 for the term "Link" is adopted, as opposed to the IEEE 350 Std. 802.15.4 terminology. 352 Operational Technology: OT refers to technology used in automation, 353 for instance in industrial control networks. The 354 convergence of IT and OT is the main object of the 355 Industrial Internet of Things (IIOT). 357 pledge: A new device that attempts to join a 6TiSCH network. 359 (to) relocate a cell: The action operated by the 6top sublayer of 360 changing the slotOffset and/or channelOffset of a soft 361 cell. 363 (to) schedule a cell: The action of turning an unscheduled cell into 364 a scheduled cell. 366 scheduled cell: A cell which is assigned a neighbor MAC address 367 (broadcast address is also possible), and one or more of 368 the following flags: TX, RX, shared, timeskeeping. A 369 scheduled cell can be used by the IEEE Std. 802.15.4 TSCH 370 implementation to communicate. A scheduled cell can 371 either be a hard or a soft cell. 373 SF (6top Scheduling Function): The cell management entity that adds 374 or deletes cells dynamically based on application 375 networking requirements. The cell negotiation with a 376 neighbor is done using 6P. 378 SFID (6top Scheduling Function Identifier): A 4-bit field 379 identifying an SF. 381 shared cell: A cell marked with both the "TX" and "shared" flags. 382 This cell can be used by more than one transmitter node. 383 A back-off algorithm is used to resolve contention. 385 slotframe: A collection of timeslots repeating in time, analogous to 386 a superframe in that it defines periods of communication 387 opportunities. It is characterized by a slotframe_ID, 388 and a slotframe_size. Multiple slotframes can coexist in 389 a node's schedule, i.e., a node can have multiple 390 activities scheduled in different slotframes, based on 391 the priority of its packets/traffic flows. The timeslots 392 in the Slotframe are indexed by the SlotOffset; the first 393 timeslot is at SlotOffset 0. 395 slotOffset: A column in the TSCH schedule, i.e. the number of 396 timeslots since the beginning of the current iteration of 397 the slotframe. 399 soft cell: A scheduled cell which the 6top sublayer can relocate. 401 time source neighbor: A neighbor that a node uses as its time 402 reference, and to which it needs to keep its clock 403 synchronized. 405 timeslot: A basic communication unit in TSCH which allows a 406 transmitter node to send a frame to a receiver neighbor, 407 and that receiver neighbor to optionally send back an 408 acknowledgment. 410 Track: A Track is a Directed Acyclic Graph (DAG) that is used as 411 a complex multi-hop path to the destination(s) of the 412 path. In the case of unicast traffic, the Track is a 413 Destination Oriented DAG (DODAG) where the root of the 414 DODAG is the destination of the unicast traffic. A Track 415 enables replication, elimination and reordering functions 416 on the way (more on those functions in the Deterministic 417 Networking Architecture [I-D.ietf-detnet-architecture]). 418 A Track reservation locks physical resources such as 419 cells and buffers in every node along the DODAG. A Track 420 is associated with a owner that can be for instance the 421 destination of the Track. 423 TrackID: A TrackID is either globally unique, or locally unique to 424 the Track owner, in which case the identification of the 425 owner must be provided together with the TrackID to 426 provide a full reference to the Track. If the Track 427 owner is the destination of the Track then the 428 destination IP address of packets along the Track can be 429 used as identification of the owner and a local 430 InstanceID [RFC6550] can be used as TrackID. In that 431 case, a RPL Packet Information [RFC6550] in an IPv6 432 packet can unambiguously identify the Track and can be 433 expressed in a compressed form using [RFC8138]. 435 TSCH: A medium access mode of the IEEE Std. 802.15.4 436 [IEEE802154] standard which uses time synchronization to 437 achieve ultra-low-power operation, and channel hopping to 438 enable high reliability. 440 TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset 441 and a channelOffset. The TSCH schedule contains all the 442 scheduled cells from all slotframes and is sufficient to 443 qualify the communication in the TSCH network. The 444 number of channelOffset values (the "height" of the 445 matrix) is equal to the number of available frequencies. 447 Unscheduled Cell: A cell which is not used by the IEEE Std. 802.15.4 448 TSCH implementation. 450 2.2. Abbreviations 452 This document uses the following abbreviations: 454 6BBR: 6LoWPAN Backbone Router (router with a proxy ND function) 456 6LBR: 6LoWPAN Border Router (authoritative on DAD) 458 6LN: 6LoWPAN Node 460 6LR: 6LoWPAN Router (relay to the registration process) 462 6CIO: Capability Indication Option 464 (E)ARO: (Extended) Address Registration Option 466 (E)DAR: (Extended) Duplicate Address Request 468 (E)DAC: (Extended) Duplicate Address Confirmation 470 DAD: Duplicate Address Detection 472 DODAG: Destination-Oriented Directed Acyclic Graph 474 LLN: Low-Power and Lossy Network (a typical IoT network) 476 NA: Neighbor Advertisement 478 NCE: Neighbor Cache Entry 479 ND: Neighbor Discovery 481 NDP: Neighbor Discovery Protocol 483 PCE: Path Computation Element 485 NME: Network Management Entity 487 ROVR: Registration Ownership Verifier (pronounced rover) 489 RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) 491 RA: Router Advertisement 493 RS: Router Solicitation 495 TSCH: timeslotted Channel Hopping 497 TID: Transaction ID (a sequence counter in the EARO) 499 2.3. Related Documents 501 The draft also conforms to the terms and models described in 502 [RFC3444] and [RFC5889] and uses the vocabulary and the concepts 503 defined in [RFC4291] for the IPv6 Architecture and refers [RFC4080] 504 for reservation 506 The draft uses domain-specific terminology defined or referenced in: 508 6LoWPAN ND "Neighbor Discovery Optimization for Low-power and 509 Lossy Networks" [RFC6775] and "Registration Extensions for 6LoWPAN 510 Neighbor Discovery" [RFC8505], 512 "Terms Used in Routing for Low-Power and Lossy Networks (LLNs)" 513 [RFC7102], 515 and RPL "Objective Function Zero for the Routing Protocol for Low- 516 Power and Lossy Networks (RPL)" [RFC6552], and "RPL: IPv6 Routing 517 Protocol for Low-Power and Lossy Networks" [RFC6550]. 519 Other terms in use in LLNs are found in "Terminology for Constrained- 520 Node Networks" [RFC7228]. 522 Readers are expected to be familiar with all the terms and concepts 523 that are discussed in 525 o "Neighbor Discovery for IP version 6" [RFC4861], and "IPv6 526 Stateless Address Autoconfiguration" [RFC4862]. 528 In addition, readers would benefit from reading: 530 o "Problem Statement and Requirements for IPv6 over Low-Power 531 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], 533 o "Multi-Link Subnet Issues" [RFC4903], and 535 o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 536 Overview, Assumptions, Problem Statement, and Goals" [RFC4919] 538 prior to this specification for a clear understanding of the art in 539 ND-proxying and binding. 541 3. High Level Architecture 543 3.1. A Non-Broadcast Multi-Access Radio Mesh Network 545 A 6TiSCH network is an IPv6 [RFC8200] subnet which, in its basic 546 configuration illustrated in Figure 1, is a single Low-Power Lossy 547 Network (LLN) operating over a synchronized TSCH-based mesh. 549 ---+-------- ............ ------------ 550 | External Network | 551 | +-----+ 552 +-----+ | NME | 553 | | LLN Border | PCE | 554 | | router (6LBR) +-----+ 555 +-----+ 556 o o o 557 o o o o o 558 o o 6LoWPAN + RPL o o 559 o o o o 561 Figure 1: Basic Configuration of a 6TiSCH Network 563 Inside a 6TiSCH LLN, nodes rely on 6LoWPAN Header Compression 564 (6LoWPAN HC) [RFC6282] to encode IPv6 packets. From the perspective 565 of the network layer, a single LLN interface (typically an IEEE Std. 566 802.15.4-compliant radio) may be seen as a collection of Links with 567 different capabilities for unicast or multicast services. 569 6TiSCH nodes join a mesh network by attaching to nodes that are 570 already members of the mesh (see Section 4.2.1). The security 571 aspects of the join process are further detailed in Section 6. In a 572 mesh network, 6TiSCH nodes are not necessarily reachable from one 573 another at Layer-2 and an LLN may span over multiple links. 575 This forms an homogeneous non-broadcast multi-access (NBMA) subnet, 576 which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) 577 [RFC4861][RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND) 578 [RFC6775][RFC8505] specifies extensions to IPv6 ND that enable ND 579 operations in this type of subnet. 581 Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses 582 and register them using 6LoWPAN ND. This guarantees that the 583 addresses are unique and protects the address ownership over the 584 subnet, more in Section 4.2.2. 586 Within the NBMA subnet, RPL [RFC6550] enables routing in the so- 587 called Route Over fashion, either in storing (stateful) or non- 588 storing (stateless, with routing headers) mode. From there, some 589 nodes can act as routers for 6LoWPAN ND and RPL operations, as 590 detailed in Section 4.1. 592 With TSCH, devices are time-synchronized at the MAC level. The use 593 of a particular RPL Instance for time synchronization is discussed in 594 Section 4.3.4. With this mechanism, the time synchronization starts 595 at the RPL root and follows the RPL loopless routing topology. 597 RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) 598 within Instances of the protocol, each Instance being associated with 599 an Objective Function (OF) to form a routing topology. A particular 600 6TiSCH node, the LLN Border Router (6LBR), acts as RPL root, 6LoWPAN 601 HC terminator, and Border Router for the LLN to the outside. The 602 6LBR is usually powered. More on RPL Instances can be found in 603 section 3.1 of RPL [RFC6550], in particular "3.1.2. RPL Identifiers" 604 and "3.1.3. Instances, DODAGs, and DODAG Versions". RPL adds 605 artifacts in the data packets that are compressed with a 6LoWPAN 606 addition 6LoRH [RFC8138]. 608 Additional routing and scheduling protocols may be deployed to 609 establish on-demand Peer-to-Peer routes with particular 610 characteristics inside the 6TiSCH network. This may be achieved in a 611 centralized fashion by a Path Computation Element (PCE) [PCE] that 612 programs both the routes and the schedules inside the 6TiSCH nodes, 613 or by in a distributed fashion using a reactive routing protocol and 614 a Hop-by-Hop scheduling protocol. 616 This architecture expects that a 6LoWPAN node can connect as a leaf 617 to a RPL network, where the leaf support is the minimal functionality 618 to connect as a host to a RPL network without the need to participate 619 to the full routing protocol. The architecture also expects that a 620 6LoWPAN node that is not aware at all of the RPL protocol may also 621 connect as described in [I-D.ietf-roll-unaware-leaves]. 623 3.2. A Multi-Link Subnet Model 625 An extended configuration of the subnet comprises multiple LLNs as 626 illustrated in Figure 2. In the extended configuration, a Routing 627 Registrar [RFC8505] may be connected to the node that acts as RPL 628 root and / or 6LoWPAN 6LBR and provides connectivity to the larger 629 campus / factory plant network over a high-speed backbone or a back- 630 haul link. The Routing registrar may perform IPv6 ND proxy 631 operations, or redistribute the registration in a routing protocol 632 such as OSPF [RFC5340] or BGP [RFC2545], or inject a route in a 633 mobility protocol such as MIPv6 [RFC6275], NEMO [RFC3963], or LISP 634 [RFC6830]. 636 Multiple LLNs can be interconnected and possibly synchronized over a 637 backbone, which can be wired or wireless. The backbone can operate 638 with IPv6 ND [RFC4861][RFC4862] procedures or an hybrid of IPv6 ND 639 and 6LoWPAN ND [RFC6775] [RFC8505]. 641 | 642 +-----+ +-----+ +-----+ 643 (default) | | (Optional) | | | | IPv6 644 Router | | 6LBR | | | | Node 645 +-----+ +-----+ +-----+ 646 | Backbone side | | 647 --------+---+--------------------+-+---------------+------+--- 648 | | | 649 +-----------+ +-----------+ +-----------+ 650 | Routing | | Routing | | Routing | 651 | Registrar | | Registrar | | Registrar | 652 +-----------+ +-----------+ +-----------+ 653 o Wireless side o o o o 654 o o o o o o o o o o o o o o 655 o 6TiSCH o 6TiSCH o o o o 6TiSCH o 656 o o LLN o o o o LLN o o LLN o 657 o o o o o o o o o o o o o o 659 Figure 2: Extended Configuration of a 6TiSCH Network 661 A Routing Registrar that performs proxy IPv6 ND operations over the 662 backbone on behalf of the 6TiSCH nodes is called a Backbone Router 663 (6BBR) [I-D.ietf-6lo-backbone-router]. The 6BBRs are placed along 664 the wireless edge of a Backbone, and federate multiple wireless links 665 to form a single MultiLink Subnet. The 6BBRs synchronize with one 666 another over the backbone, so as to ensure that the multiple LLNs 667 that form the IPv6 subnet stay tightly synchronized. 669 The use of multicast can also be reduced on the backbone with a 670 registrar that would contribute to Duplicate Address Detection as 671 well as Address Lookup using only unicast request/response exchanges. 672 [I-D.thubert-6lo-unicast-lookup] is a proposed method that presents 673 an example of how to this could be achieved with an extension of 674 [RFC8505], using a 6LBR as a SubNet-level registrar. 676 As detailed in Section 4.1 the 6LBR that serves the LLN and the root 677 of the RPL network need to share information about the devices that 678 are learned through either protocol but not both. The preferred way 679 of achieving this is to collocate/combine them. The combined RPL 680 root and 6LBR may be collocated with the 6BBR, or directly attached 681 to the 6BBR. In the latter case, it leverages the extended 682 registration process defined in [RFC8505] to proxy the 6LoWPAN ND 683 registration to the 6BBR on behalf of the LLN nodes, so that the 6BBR 684 may in turn perform proxy classical ND operations over the backbone. 686 The DetNet Architecture [I-D.ietf-detnet-architecture] studies 687 Layer-3 aspects of Deterministic Networks, and covers networks that 688 span multiple Layer-2 domains. If the Backbone is Deterministic 689 (such as defined by the Time Sensitive Networking WG at IEEE), then 690 the Backbone Router ensures that the end-to-end deterministic 691 behavior is maintained between the LLN and the backbone. 693 3.3. TSCH: A Deterministic MAC Layer 695 Though at a different time scale (several orders of magnitude), both 696 IEEE Std. 802.1TSN and IEEE Std. 802.15.4 TSCH standards provide 697 Deterministic capabilities to the point that a packet that pertains 698 to a certain flow may traverse a network from node to node following 699 a precise schedule, as a train that enters and then leaves 700 intermediate stations at precise times along its path. 702 With TSCH, time is formatted into timeslots, and individual 703 communication cells are allocated to unicast or broadcast 704 communication at the MAC level. The time-slotted operation reduces 705 collisions, saves energy, and enables to more closely engineer the 706 network for deterministic properties. The channel hopping aspect is 707 a simple and efficient technique to combat multipath fading and co- 708 channel interference. 710 6TiSCH builds on the IEEE Std. 802.15.4 TSCH MAC and inherits its 711 advanced capabilities to enable them in multiple environments where 712 they can be leveraged to improve automated operations. The 6TiSCH 713 Architecture also inherits the capability to perform a centralized 714 route computation to achieve deterministic properties, though it 715 relies on the IETF DetNet Architecture 717 [I-D.ietf-detnet-architecture], and IETF components such as the PCE 718 [PCE], for the protocol aspects. 720 On top of this inheritance, 6TiSCH adds capabilities for distributed 721 routing and scheduling operations based on the RPL routing protocol 722 and capabilities to negotiate schedule adjustments between peers. 723 These distributed routing and scheduling operations simplify the 724 deployment of TSCH networks and enable wireless solutions in a larger 725 variety of use cases from operational technology in general. 726 Examples of such use-cases in industrial environments include plant 727 setup and decommissioning, as well as monitoring of lots of lesser 728 importance measurements such as corrosion and events and mobile 729 workers accessing local devices. 731 3.4. Scheduling TSCH 733 A scheduling operation attributes cells in a Time-Division- 734 Multiplexing (TDM) / Frequency-Division Multiplexing (FDM) matrix 735 called the Channel distribution/usage (CDU) to either individual 736 transmissions or as multi-access shared resources. The CDU matrix 737 can be formatted in chunks that can be allocated exclusively to 738 particular nodes to enable distributed scheduling without collision. 739 More in Section 4.3.5. 741 From the standpoint of a 6TiSCH node (at the MAC layer), its schedule 742 is the collection of the timeslots at which it must wake up for 743 transmission, and the channels to which it should either send or 744 listen at those times. The schedule is expressed as one or more 745 slotframes that repeat over and over. Slotframes may collide and 746 require a device to wake up at a same time, in which case the 747 slotframe with the highest priority is actionable. 749 The 6top sublayer (see Section 4.3 for more) hides the complexity of 750 the schedule from the upper layers. The Link abstraction that IP 751 traffic utilizes is composed of a pair of Layer-3 cell bundles, one 752 to receive and one to transmit. Some of the cells may be shared, in 753 which case the 6top sublayer must perform some arbitration. 755 Scheduling enables multiple communications at a same time in a same 756 interference domain using different channels; but a node equipped 757 with a single radio can only either transmit or receive on one 758 channel at any point of time. Scheduled cells that play an equal 759 role, e.g., receive IP packets from a peer, are grouped in bundles. 761 The 6TiSCH architecture identifies four ways a schedule can be 762 managed and CDU cells can be allocated: Static Scheduling, Neighbor- 763 to-Neighbor Scheduling, Remote Monitoring and Schedule Management, 764 and Hop-by-hop Scheduling. 766 Static Scheduling: This refers to the minimal 6TiSCH operation 767 whereby a static schedule is configured for the whole network for 768 use in a slotted-Aloha fashion. The static schedule is 769 distributed through the native methods in the TSCH MAC layer and 770 does not preclude other scheduling operations to co-exist on a 771 same 6TiSCH network. A static schedule is necessary for basic 772 operations such as the join process and for interoperability 773 during the network formation, which is specified as part of the 774 Minimal 6TiSCH Configuration [RFC8180]. 776 Neighbor-to-Neighbor Scheduling: This refers to the dynamic 777 adaptation of the bandwidth of the Links that are used for IPv6 778 traffic between adjacent routers. Scheduling Functions such as 779 the "6TiSCH Minimal Scheduling Function (MSF)" 780 [I-D.ietf-6tisch-msf] influence the operation of the MAC layer to 781 add, update and remove cells in its own, and its peer's schedules 782 using 6P [RFC8480], for the negotiation of the MAC resources. 784 Centralized (or Remote) Monitoring and Schedule Management: This 785 refers to the central computation of a schedule and the capability 786 to forward a frame based on the cell of arrival. In that case, 787 the related portion of the device schedule as well as other device 788 resources are managed by an abstract Network Management Entity 789 (NME), which may cooperate with the PCE to minimize the 790 interaction with and the load on the constrained device. This 791 model is the TSCH adaption of the "DetNet Architecture" 792 [I-D.ietf-detnet-architecture], and it enables Traffic Engineering 793 with deterministic properties. 795 Hop-by-hop Scheduling: This refers to the possibility to reserves 796 cells along a path for a particular flow using a distributed 797 mechanism. 799 It is not expected that all use cases will require all those 800 mechanisms. Static Scheduling with minimal configuration one is the 801 only one that is expected in all implementations, since it provides a 802 simple and solid basis for convergecast routing and time 803 distribution. 805 A deeper dive in those mechanisms can be found in Section 4.4. 807 3.5. Distributed vs. Centralized Routing 809 6TiSCH enables a mixed model of centralized routes and distributed 810 routes. Centralized routes can for example be computed by an entity 811 such as a PCE. 6TiSCH leverages the RPL [RFC6550] routing protocol 812 for interoperable distributed routing operations. 814 Both methods may inject routes in the Routing Tables of the 6TiSCH 815 routers. In either case, each route is associated with a 6TiSCH 816 topology that can be a RPL Instance topology or a Track. The 6TiSCH 817 topology is indexed by a Instance ID, in a format that reuses the 818 RPLInstanceID as defined in RPL. 820 RPL [RFC6550]is applicable to Static Scheduling and Neighbor-to- 821 Neighbor Scheduling. The architecture also supports a centralized 822 routing model for Remote Monitoring and Schedule Management. It is 823 expected that a routing protocol that is more optimized for point-to- 824 point routing than RPL [RFC6550], such as the "Asymmetric AODV-P2P- 825 RPL in Low-Power and Lossy Networks" [I-D.ietf-roll-aodv-rpl] (AODV- 826 RPL), which derives from the Ad Hoc On-demand Distance Vector Routing 827 (AODV) [I-D.ietf-manet-aodvv2] will be selected for Hop-by-hop 828 Scheduling. 830 Both RPL and PCE rely on shared sources such as policies to define 831 Global and Local RPLInstanceIDs that can be used by either method. 832 It is possible for centralized and distributed routing to share a 833 same topology. Generally they will operate in different slotframes, 834 and centralized routes will be used for scheduled traffic and will 835 have precedence over distributed routes in case of conflict between 836 the slotframes. 838 3.6. Forwarding Over TSCH 840 The 6TiSCH architecture supports three different forwarding models. 841 One is the classical IPv6 Forwarding, where the node selects a 842 feasible successor at Layer-3 on a per packet basis and based on its 843 routing table. The second derives from Generic MPLS (G-MPLS) for so- 844 called Track Forwarding, whereby a frame received at a particular 845 timeslot can be switched into another timeslot at Layer-2 without 846 regard to the upper layer protocol. The third model is the 6LoWPAN 847 Fragment Forwarding, which allows to forward individual 6loWPAN 848 fragments along a route that is setup by the first fragment. 850 In more details: 852 IPv6 Forwarding: This is the classical IP forwarding model, with a 853 Routing Information Based (RIB) that is installed by the RPL 854 routing protocol and used to select a feasible successor per 855 packet. The packet is placed on an outgoing Link, that the 6top 856 layer maps into a (Layer-3) bundle of cells, and scheduled for 857 transmission based on QoS parameters. Besides RPL, this model 858 also applies to any routing protocol which may be operated in the 859 6TiSCH network, and corresponds to all the distributed scheduling 860 models, Static, Neighbor-to-Neighbor and Hop-by-Hop Scheduling. 862 G-MPLS Track Forwarding: This model corresponds to the Remote 863 Monitoring and Schedule Management. In this model, A central 864 controller (hosting a PCE) computes and installs the schedules in 865 the devices per flow. The incoming (Layer-2) bundle of cells from 866 the previous node along the path determines the outgoing (Layer-2) 867 bundle towards the next hop for that flow as determined by the 868 PCE. The programmed sequence for bundles is called a Track and 869 can assume DAG shapes that are more complex than a simple direct 870 sequence of nodes. 872 6LoWPAN Fragment Forwarding: This is an hybrid model that derives 873 from IPv6 forwarding for the case where packets must be fragmented 874 at the 6LoWPAN sublayer. The first fragment is forwarded like any 875 IPv6 packet and leaves a state in the intermediate hops to enable 876 forwarding of the next fragments that do not have a IP header 877 without the need to recompose the packet at every hop. 879 A deeper dive on these operations can be found in Section 4.6. 881 The following table summarizes how the forwarding models apply to the 882 various routing and scheduling possibilities: 884 +-------------------+------------+----------------------------------+ 885 | Forwarding Model | Routing | Scheduling | 886 +===================+============+==================================+ 887 | | | Static (Minimal Configuration) | 888 + classical IPv6 + RPL +----------------------------------+ 889 | / | | Neighbor-to-Neighbor (SF+6P) | 890 + 6LoWPAN Fragment +------------+----------------------------------+ 891 | |Reactive P2P| Hop-by-Hop (TBD) | 892 +-------------------+------------+----------------------------------+ 893 |G-MPLS Track Fwding| PCE |Remote Monitoring and Schedule Mgt| 894 +-------------------+------------+----------------------------------+ 896 3.7. 6TiSCH Stack 898 The IETF proposes multiple techniques for implementing functions 899 related to routing, transport or security. 901 The 6TiSCH architecture limits the possible variations of the stack 902 and recommends a number of base elements for LLN applications to 903 control the complexity of possible deployments and device 904 interactions, and to limit the size of the resulting object code. In 905 particular, UDP [RFC0768], IPv6 [RFC8200] and the Constrained 906 Application Protocol [RFC7252] (CoAP) are used as the transport / 907 binding of choice for applications and management as opposed to TCP 908 and HTTP. 910 The resulting protocol stack is represented in Figure 4: 912 +--------+--------+ 913 | Applis | CoJP | 914 +--------+--------+--------------+-----+ 915 | CoAP / OSCORE | 6LoWPAN ND | RPL | 916 +-----------------+--------------+-----+ 917 | UDP | ICMPv6 | 918 +-----------------+--------------------+ 919 | IPv6 | 920 +--------------------------------------+----------------------+ 921 | 6LoWPAN HC / 6LoRH HC | Scheduling Functions | 922 +--------------------------------------+----------------------+ 923 | 6top (to be IEEE Std. 802.15.12) inc. 6top protocol | 924 +-------------------------------------------------------------+ 925 | IEEE Std. 802.15.4 TSCH | 926 +-------------------------------------------------------------+ 928 Figure 4: 6TiSCH Protocol Stack 930 RPL is the routing protocol of choice for LLNs. So far, there was no 931 identified need to define a 6TiSCH specific Objective Function. The 932 Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL 933 over a static schedule used in a slotted aloha fashion, whereby all 934 active slots may be used for emission or reception of both unicast 935 and multicast frames. 937 The 6LoWPAN Header Compression [RFC6282] is used to compress the IPv6 938 and UDP headers, whereas the 6LoWPAN Routing Header (6LoRH) [RFC8138] 939 is used to compress the RPL artifacts in the IPv6 data packets, 940 including the RPL Packet Information (RPI), the IP-in-IP 941 encapsulation to/from the RPL root, and the Source Route Header (SRH) 942 in non-storing mode. "When to use RFC 6553, 6554 and IPv6-in-IPv6" 943 [I-D.ietf-roll-useofrplinfo] provides the details on when headers or 944 encapsulation are needed. 946 The Object Security for Constrained RESTful Environments (OSCORE) 947 [I-D.ietf-core-object-security], is leveraged by the Constrained Join 948 Protocol (CoJP) and is expected to be the primary protocol for the 949 protection of the application payload as well. The application 950 payload may also be protected by the Datagram Transport Layer 951 Security (DTLS) [RFC6347] sitting either under CoAP or over CoAP so 952 it can traverse proxies. 954 The 6TiSCH Operation sublayer (6top) is a sublayer of a Logical Link 955 Control (LLC) that provides the abstraction of an IP link over a TSCH 956 MAC and schedules packets over TSCH cells, as further discussed in 957 the next sections, providing in particular dynamic cell allocation 958 with the 6top Protocol (6P) [RFC8480]. 960 The reference stack that the 6TiSCH architecture presents was 961 implemented and interop tested by a conjunction of opensource, IETF 962 and ETSI efforts. One goal is to help other bodies to adopt the 963 stack as a whole, making the effort to move to an IPv6-based IoT 964 stack easier. 966 For a particular environment, some of the choices that are made in 967 this architecture may not be relevant. For instance, RPL is not 968 required for star topologies and mesh-under Layer-2 routed networks, 969 and the 6LoWPAN compression may not be sufficient for ultra- 970 constrained cases such as some Low-Power Wide Area (LPWA) networks. 971 In such cases, it is perfectly doable to adopt a subset of the 972 selection that is presented hereafter and then select alternate 973 components to complete the solution wherever needed. 975 3.8. Communication Paradigms and Interaction Models 977 Section 2.1 provides the terms of Communication Paradigms and 978 Interaction Models, which can be placed in parallel to the 979 Information Models and Data Models that are defined in [RFC3444]. 981 A Communication Paradigms would be an abstract view of a protocol 982 exchange, and would come with an Information Model for the 983 information that is being exchanged. In contrast, an Interaction 984 Models would be more refined and could point on standard operation 985 such as a Representational state transfer (REST) "GET" operation and 986 would match a Data Model for the data that is provided over the 987 protocol exchange. 989 Section 2.1.3 of [I-D.ietf-roll-rpl-industrial-applicability] and 990 next sections discuss application-layer paradigms, such as Source- 991 sink (SS) that is a Multipeer to Multipeer (MP2MP) model primarily 992 used for alarms and alerts, Publish-subscribe (PS, or pub/sub) that 993 is typically used for sensor data, as well as Peer-to-peer (P2P) and 994 Peer-to-multipeer (P2MP) communications. Additional considerations 995 on Duocast and its N-cast generalization are also provided. Those 996 paradigms are frequently used in industrial automation, which is a 997 major use case for IEEE Std. 802.15.4 TSCH wireless networks with 998 [ISA100.11a] and [WirelessHART], that provides a wireless access to 999 [HART] applications and devices. 1001 This specification focuses on Communication Paradigms and Interaction 1002 Models for packet forwarding and TSCH resources (cells) management. 1003 Management mechanisms for the TSCH schedule at Link-Layer (one-hop), 1004 Network-layer (multithop along a Track), and Application-layer 1005 (remote control) are discussed in Section 4.4. Link-Layer frame 1006 forwarding interactions are discussed in Section 4.6, and Network- 1007 layer Packet routing is addressed in Section 4.7. 1009 4. Architecture Components 1011 4.1. 6LoWPAN (and RPL) 1013 A RPL DODAG is formed of a root, a collection of routers, and leaves 1014 that are hosts. Hosts are nodes which do not forward packets that 1015 they did not generate. RPL-aware leaves will participate to RPL to 1016 advertise their own addresses, whereas RPL-unaware leaves depend on a 1017 connected RPL router to do so. RPL interacts with 6LoWPAN ND at 1018 multiple levels, in particular at the root and in the RPL-unaware 1019 leaves. 1021 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND 1023 RPL needs a set of information to advertise a leaf node through a DAO 1024 message and establish reachability. 1026 "Routing for RPL Leaves" [I-D.ietf-roll-unaware-leaves] details the 1027 basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN that 1028 supports [RFC8505] to obtain return connectivity via the RPL network 1029 as an RPL-unaware leaf. The leaf indicates that it requires 1030 reachability services for the Registered Address from a Routing 1031 Registrar by settig a 'R' flag in the Extended Address Registration 1032 Option [RFC8505], and it provides a TID that maps to a sequence 1033 number in section 7 of RPL [RFC6550]. 1035 The RPL InstanceID that the leaf wants to participate to may be 1036 signaled in the Opaque field of the EARO. On the backbone, the 1037 InstanceID is expected to be mapped to an overlay that matches the 1038 RPL Instance, e.g., a Virtual LAN (VLAN) or a virtual routing and 1039 forwarding (VRF) instance. 1041 Though at the time of this writing the above specification enables a 1042 model where the separation is possible, this architecture recommends 1043 to collocate the functions of 6LBR and RPL root. 1045 4.1.2. RPL Root And 6LBR 1047 With the 6LowPAN ND [RFC6775], information on the 6LBR is 1048 disseminated via an Authoritative Border Router Option (ABRO) in RA 1049 messages. [RFC8505] extends [RFC6775] to enable a registration for 1050 routing and proxy ND. The capability to support [RFC8505] is 1051 indicated in the 6LoWPAN Capability Indication Option (6CIO). The 1052 discovery and liveliness of the RPL root are obtained through RPL 1053 [RFC6550] itself. 1055 When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL root 1056 functionalities are co-located in order that the address of the 6LBR 1057 be indicated by RPL DIO messages and to associate the unique ID from 1058 the EDAR/EDAC [RFC8505] exchange with the state that is maintained by 1059 RPL. 1061 Section 5 of [I-D.ietf-roll-unaware-leaves] details how the DAO 1062 messages are used to reconfirm the registration, thus eliminating a 1063 duplication of functionality between DAO and EDAR/EDAC messages. 1065 Even though the root of the RPL network is integrated with the 6LBR, 1066 it is logically separated from the Backbone Router (6BBR) that is 1067 used to connect the 6TiSCH LLN to the backbone. This way, the root 1068 has all information from 6LoWPAN ND and RPL about the LLN devices 1069 attached to it. 1071 This architecture also expects that the root of the RPL network 1072 (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, for 1073 whatever operation the 6BBR performs on the backbone, such as ND 1074 proxy, or redistribution in a routing protocol. This relies on an 1075 extension of the 6LoWPAN ND registration described in 1076 [I-D.ietf-6lo-backbone-router]. 1078 This model supports the movement of a 6TiSCH device across the Multi- 1079 Link Subnet, and allows the proxy registration of 6TiSCH nodes deep 1080 into the 6TiSCH LLN by the 6LBR / RPL root. This is why in [RFC8505] 1081 the Registered Address is signaled in the Target Address field of the 1082 NS message as opposed to the IPv6 Source Address, which, in the case 1083 of a proxy registration, is that of the 6LBR / RPL root itself. 1085 4.2. Network Access and Addressing 1087 4.2.1. Join Process 1089 A new device, called the pledge, undergoes the join protocol to 1090 become a node in a 6TiSCH network. This usually occurs only once 1091 when the device is first powered on. The pledge communicates with 1092 the Join Registrar/Coordinator (JRC) of the network through a Join 1093 Proxy (JP): a radio neighbor of the pledge. 1095 The join protocol provides the following functionality: 1097 o Mutual authentication 1099 o Authorization 1101 o Parameter distribution to the pledge over a secure channel 1103 Minimal Security Framework for 6TiSCH 1104 [I-D.ietf-6tisch-minimal-security] defines the minimal mechanisms 1105 required for this join process to occur in a secure manner. The 1106 specification defines the Constrained Join Protocol (CoJP) that is 1107 used to distribute the parameters to the pledge over a secure session 1108 established through OSCORE [I-D.ietf-core-object-security], and a 1109 secure configuration of the network stack. In the minimal setting 1110 with pre-shared keys (PSKs), CoJP allows the pledge to join after a 1111 single round-trip exchange with the JRC. The provisioning of the PSK 1112 to the pledge and the JRC needs to be done out of band, through a 1113 'one-touch' bootstrapping process, which effectively enrolls the 1114 pledge into the domain managed by the JRC. 1116 In certain use cases, the 'one touch' bootstrapping is not feasible 1117 due to the operational constraints and the enrollment of the pledge 1118 into the domain needs to occur in-band. This is handled through a 1119 'zero-touch' extension of the Minimal Security Framework for 6TiSCH. 1120 Zero touch [I-D.ietf-6tisch-dtsecurity-zerotouch-join] extension 1121 leverages the 'Bootstrapping Remote Secure Key Infrastructures 1122 (BRSKI)' [[I-D.ietf-anima-bootstrapping-keyinfra] work to establish a 1123 shared secret between a pledge and the JRC without necessarily having 1124 them belong to a common (security) domain at join time. This happens 1125 through inter-domain communication occurring between the JRC of the 1126 network and the domain of the pledge, represented by a fourth entity, 1127 Manufacturer Authorized Signing Authority (MASA). Once the zero- 1128 touch exchange completes, the CoJP exchange defined in 1129 [I-D.ietf-6tisch-minimal-security] is carried over the secure session 1130 established between the pledge and the JRC. 1132 Figure 5 depicts the join process. 1134 6LoWPAN Node 6LR 6LBR Join Registrar MASA 1135 (pledge) (Join Proxy) (root) /Coordinator (JRC) 1136 | | | | | 1137 | 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network | 1138 | LLN link |Route-Over mesh|(the Internet)|(the Internet)| 1139 | | | | | 1140 | Layer-2 | | | | 1141 |enhanced beacon| | | | 1142 |<--------------| | | | 1143 | | | | | 1144 | NS (EARO) | | | | 1145 | (for the LL @)| | | | 1146 |-------------->| | | | 1147 | NA (EARO) | | | | 1148 |<--------------| | | | 1149 | | | | | 1150 | (Zero-touch | | | | 1151 | handshake) | (Zero-touch handshake) | (Zero-touch | 1152 | Link Local @ | Global Unicast @ | handshake) | 1153 |<------------->|<---------------------------->|<------------>| 1154 | | | | | 1155 | CoJP Join Req | | | | \ 1156 | Link Local @ | | | | | 1157 |-------------->| | | | | 1158 | | CoJP Join Request | | | 1159 | | Global Unicast @ | | | 1160 | |----------------------------->| | | C 1161 | | | | | | o 1162 | | CoJP Join Response | | | J 1163 | | Global Unicast @ | | | P 1164 | |<-----------------------------| | | 1165 |CoJP Join Resp | | | | | 1166 | Link Local @ | | | | | 1167 |<--------------| | | | / 1168 | | | | | 1170 Figure 5: Join process in a Multi-Link Subnet. Parentheses () denote 1171 optional exchanges. 1173 4.2.2. Registration 1175 Once the pledge successfully completes the CoJP protocol and becomes 1176 a network node, it obtains the network prefix from neighboring 1177 routers and registers its IPv6 addresses. As detailed in 1178 Section 4.1, the combined 6LoWPAN ND 6LBR and root of the RPL network 1179 learn information such as the device Unique ID (from 6LoWPAN ND) and 1180 the updated Sequence Number (from RPL), and perform 6LoWPAN ND proxy 1181 registration to the 6BBR of behalf of the LLN nodes. 1183 Figure 6 illustrates the initial IPv6 signaling that enables a 6LN to 1184 form a global address and register it to a 6LBR using 6LoWPAN ND 1185 [RFC8505], is then carried over RPL to the RPL root, and then to the 1186 6BBR. 1188 6LoWPAN Node 6LR 6LBR 6BBR 1189 (RPL leaf) (router) (root) 1190 | | | | 1191 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 1192 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 1193 | | | | 1194 | IPv6 ND RS | | | 1195 |-------------->| | | 1196 |-----------> | | | 1197 |------------------> | | 1198 | IPv6 ND RA | | | 1199 |<--------------| | | 1200 | | | | 1201 | NS(EARO) | | | 1202 |-------------->| | | 1203 | 6LoWPAN ND | Extended DAR | | 1204 | |-------------->| | 1205 | | | NS(EARO) | 1206 | | |-------------->| 1207 | | | | NS-DAD 1208 | | | |------> 1209 | | | | (EARO) 1210 | | | | 1211 | | | NA(EARO) | 1212 | | |<--------------| 1213 | | Extended DAC | | 1214 | |<--------------| | 1215 | NA(EARO) | | | 1216 |<--------------| | | 1217 | | | | 1219 Figure 6: Initial Registration Flow over Multi-Link Subnet 1221 Figure 7 illustrates the repeating IPv6 signaling that enables a 6LN 1222 to keep a global address alive and registered to its 6LBR using 1223 6LoWPAN ND [RFC8505], using 6LoWPAN ND ot the 6LR, RPL to the RPL 1224 root, and then 6LoWPAN ND again to the 6BBR. 1226 6LoWPAN Node 6LR 6LBR 6BBR 1227 (RPL leaf) (router) (root) 1228 | | | | 1229 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 1230 | LLN link |Route-Over mesh| ant IPv6 link | Backbone 1231 | | | | 1232 | | | | 1233 | | | | 1234 | NS(EARO) | | | 1235 |-------------->| | | 1236 | NA(EARO) | | | 1237 |<--------------| | | 1238 | | DAO | | 1239 | |-------------->| | 1240 | | DAO-ACK | | 1241 | |<--------------| | 1242 | | | NS(EARO) | 1243 | | |-------------->| 1244 | | | NA(EARO) | 1245 | | |<--------------| 1246 | | | | 1247 | | | | 1249 Figure 7: Next Registration Flow over Multi-Link Subnet 1251 As the network builds up, a node should start as a leaf to join the 1252 RPL network, and may later turn into both a RPL-capable router and a 1253 6LR, so as to accept leaf nodes to recursively join the network. 1255 4.3. TSCH and 6top 1257 4.3.1. 6top 1259 6TiSCH expects a high degree of scalability together with a 1260 distributed routing functionality based on RPL. To achieve this 1261 goal, the spectrum must be allocated in a way that allows for spatial 1262 reuse between zones that will not interfere with one another. In a 1263 large and spatially distributed network, a 6TiSCH node is often in a 1264 good position to determine usage of the spectrum in its vicinity. 1266 With 6TiSCH, the abstraction of an IPv6 link is implemented as a pair 1267 of bundles of cells, one in each direction. IP Links are only 1268 enabled between RPL parents and children. The 6TiSCH operation is 1269 optimal when the size of a bundle is such that both the energy wasted 1270 in idle listening and the packet drops due to congestion loss are 1271 minimized, while packets are forwarded within an acceptable latency. 1273 Use cases for distributed routing are often associated with a 1274 statistical distribution of best-effort traffic with variable needs 1275 for bandwidth on each individual link. The 6TiSCH operation can 1276 remain optimal if RPL parents can adjust dynamically, and with enough 1277 reactivity to match the variations of best-effort traffic, the amount 1278 of bandwidth that is used to communicate between themselves and their 1279 children, in both directions. In turn, the agility to fulfill the 1280 needs for additional cells improves when the number of interactions 1281 with other devices and the protocol latencies are minimized. 1283 6top is a logical link control sitting between the IP layer and the 1284 TSCH MAC layer, which provides the link abstraction that is required 1285 for IP operations. The 6top protocol, 6P, which is specified in 1286 [RFC8480], is one of the services provided by 6top. In particular, 1287 the 6top services are available over a management API that enables an 1288 external management entity to schedule cells and slotframes, and 1289 allows the addition of complementary functionality, for instance a 1290 Scheduling Function that manages a dynamic schedule management based 1291 on observed resource usage as discussed in Section 4.4.2. For this 1292 purpose, the 6TiSCH architecture differentiates "soft" cells and 1293 "hard" cells. 1295 4.3.1.1. Hard Cells 1297 "Hard" cells are cells that are are owned and managed by a separate 1298 scheduling entity (e.g. a PCE) that specifies the slotOffset/ 1299 channelOffset of the cells to be added/moved/deleted, in which case 1300 6top can only act as instructed, added/moved/deleted, in which case 1301 6top can only act as instructed, and may not move hard cells in the 1302 TSCH schedule on its own. 1304 4.3.1.2. Soft Cells 1306 In contrast, "soft" cells are cells that 6top can manage locally. 1307 6top contains a monitoring process which monitors the performance of 1308 cells, and can add, remove soft cells in the TSCH schedule to adapt 1309 to the traffic needs, or move one when it performs poorly. To 1310 reserve a soft cell, the higher layer does not indicate the exact 1311 slotOffset/channelOffset of the cell to add, but rather the resulting 1312 bandwidth and QoS requirements. When the monitoring process triggers 1313 a cell reallocation, the two neighbor devices communicating over this 1314 cell negotiate its new position in the TSCH schedule. 1316 4.3.2. Scheduling Functions and the 6top protocol 1318 In the case of soft cells, the cell management entity that controls 1319 the dynamic attribution of cells to adapt to the dynamics of variable 1320 rate flows is called a Scheduling Function (SF). 1322 There may be multiple SFs with more or less aggressive reaction to 1323 the dynamics of the network. 1325 An SF may be seen as divided between an upper bandwidth adaptation 1326 logic that is not aware of the particular technology that is used to 1327 obtain and release bandwidth, and an underlying service that maps 1328 those needs in the actual technology, which means mapping the 1329 bandwidth onto cells in the case of TSCH using the 6top protocol as 1330 illustrated in Figure 8. 1332 +------------------------+ +------------------------+ 1333 | Scheduling Function | | Scheduling Function | 1334 | Bandwidth adaptation | | Bandwidth adaptation | 1335 +------------------------+ +------------------------+ 1336 | Scheduling Function | | Scheduling Function | 1337 | TSCH mapping to cells | | TSCH mapping to cells | 1338 +------------------------+ +------------------------+ 1339 | 6top cells negotiation | <- 6P -> | 6top cells negotiation | 1340 +------------------------+ +------------------------+ 1341 Device A Device B 1343 Figure 8: SF/6P stack in 6top 1345 The SF relies on 6top services that implement the 6top Protocol (6P) 1346 [RFC8480] to negotiate the precise cells that will be allocated or 1347 freed based on the schedule of the peer. It may be for instance that 1348 a peer wants to use a particular time slot that is free in its 1349 schedule, but that timeslot is already in use by the other peer for a 1350 communication with a third party on a different cell. 6P enables the 1351 peers to find an agreement in a transactional manner that ensures the 1352 final consistency of the nodes state. 1354 MSF [I-D.ietf-6tisch-msf] is one of the possible scheduling 1355 functions. MSF uses the rendez-vous slot from [RFC8180] for network 1356 discovery, neighbor discovery, and any other broadcast. 1358 For basic unicast communication with any neighbor, each node uses a 1359 receive cell at a well-known slotOffset/channelOffset, derived from a 1360 hash of their own MAC address. Nodes can reach any neighbor by 1361 installing a transmit (shared) cell with slotOffset/channelOffset 1362 derived from the neighbor's MAC address. 1364 For child-parent links, MSF continuously monitors the load to/from 1365 parents and children. It then uses 6P to install/remove unicast 1366 cells whenever the current schedule appears to be under-/over- 1367 provisioned. 1369 4.3.3. 6top and RPL Objective Function operations 1371 An implementation of a RPL [RFC6550] Objective Function (OF), such as 1372 the RPL Objective Function Zero (OF0) [RFC6552] that is used in the 1373 Minimal 6TiSCH Configuration [RFC8180] to support RPL over a static 1374 schedule, may leverage, for its internal computation, the information 1375 maintained by 6top. 1377 An OF may require metrics about reachability, such as the ETX. 6top 1378 creates and maintains an abstract neighbor table, and this state may 1379 be leveraged to feed an OF and/or store OF information as well. A 1380 neighbor table entry may contain a set of statistics with respect to 1381 that specific neighbor. 1383 The neighbor information may include the time when the last packet 1384 has been received from that neighbor, a set of cell quality metrics 1385 (e.g. RSSI or LQI), the number of packets sent to the neighbor or 1386 the number of packets received from it. This information can be made 1387 available through 6top management APIs and used for instance to 1388 compute a Rank Increment that will determine the selection of the 1389 preferred parent. 1391 6top provides statistics about the underlying layer so the OF can be 1392 tuned to the nature of the TSCH MAC layer. 6top also enables the RPL 1393 OF to influence the MAC behaviour, for instance by configuring the 1394 periodicity of IEEE Std. 802.15.4 Extended Beacons (EBs). By 1395 augmenting the EB periodicity, it is possible to change the network 1396 dynamics so as to improve the support of devices that may change 1397 their point of attachment in the 6TiSCH network. 1399 Some RPL control messages, such as the DODAG Information Object (DIO) 1400 are ICMPv6 messages that are broadcast to all neighbor nodes. With 1401 6TiSCH, the broadcast channel requirement is addressed by 6top by 1402 configuring TSCH to provide a broadcast channel, as opposed to, for 1403 instance, piggybacking the DIO messages in Layer-2 Enhanced Beacons 1404 (EBs), which would produce undue timer coupling among layers, packet 1405 size issues and could conflict with the policy of production networks 1406 where EBs are mostly eliminated to conserve energy. 1408 4.3.4. Network Synchronization 1410 Nodes in a TSCH network must be time synchronized. A node keeps 1411 synchronized to its time source neighbor through a combination of 1412 frame-based and acknowledgment-based synchronization. To maximize 1413 battery life and network throughput, it is advisable that RPL ICMP 1414 discovery and maintenance traffic (governed by the trickle timer) be 1415 somehow coordinated with the transmission of time synchronization 1416 packets (especially with enhanced beacons). 1418 This could be achieved through an interaction of the 6top sublayer 1419 and the RPL objective Function, or could be controlled by a 1420 management entity. 1422 Time distribution requires a loop-free structure. Nodes taken in a 1423 synchronization loop will rapidly desynchronize from the network and 1424 become isolated. It is expected that a RPL DAG with a dedicated 1425 global Instance is deployed for the purpose of time synchronization. 1426 That Instance is referred to as the Time Synchronization Global 1427 Instance (TSGI). The TSGI can be operated in either of the 3 modes 1428 that are detailed in section 3.1.3 of RPL [RFC6550], "Instances, 1429 DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with 1430 independent roots may be used if all the roots share a common time 1431 source such as the Global Positioning System (GPS). 1433 In the absence of a common time source, the TSGI should form a single 1434 DODAG with a virtual root. A backbone network is then used to 1435 synchronize and coordinate RPL operations between the backbone 1436 routers that act as sinks for the LLN. Optionally, RPL's periodic 1437 operations may be used to transport the network synchronization. 1438 This may mean that 6top would need to trigger (override) the trickle 1439 timer if no other traffic has occurred for such a time that nodes may 1440 get out of synchronization. 1442 A node that has not joined the TSGI advertises a MAC level Join 1443 Priority of 0xFF to notify its neighbors that is not capable of 1444 serving as time parent. A node that has joined the TSGI advertises a 1445 MAC level Join Priority set to its DAGRank() in that Instance, where 1446 DAGRank() is the operation specified in section 3.5.1 of [RFC6550], 1447 "Rank Comparison". 1449 A root is configured or obtains by some external means the knowledge 1450 of the RPLInstanceID for the TSGI. The root advertises its DagRank 1451 in the TSGI, that must be less than 0xFF, as its Join Priority in its 1452 IEEE Std. 802.15.4 Extended Beacons (EB). We'll note that the Join 1453 Priority is now specified between 0 and 0x3F leaving 2 bits in the 1454 octet unused in the IEEE Std. 802.15.4e specification. After 1455 consultation with IEEE authors, it was asserted that 6TiSCH can make 1456 a full use of the octet to carry an integer value up to 0xFF. 1458 A node that reads a Join Priority of less than 0xFF should join the 1459 neighbor with the lesser Join Priority and use it as time parent. If 1460 the node is configured to serve as time parent, then the node should 1461 join the TSGI, obtain a Rank in that Instance and start advertising 1462 its own DagRank in the TSGI as its Join Priority in its EBs. 1464 4.3.5. Slotframes and CDU matrix 1466 6TiSCH enables IPv6 best effort (stochastic) transmissions over a MAC 1467 layer that is also capable of scheduled (deterministic) 1468 transmissions. A window of time is defined around the scheduled 1469 transmission where the medium must, as much as practically feasible, 1470 be free of contending energy to ensure that the medium is free of 1471 contending packets when time comes for a scheduled transmission. One 1472 simple way to obtain such a window is to format time and frequencies 1473 in cells of transmission of equal duration. This is the method that 1474 is adopted in IEEE Std. 802.15.4 TSCH as well as the Long Term 1475 Evolution (LTE) of cellular networks. 1477 The 6TiSCH architecture defines a global concept that is called a 1478 Channel Distribution and Usage (CDU) matrix to describe that 1479 formatting of time and frequencies, 1481 A CDU matrix is defined centrally as part of the network definition. 1482 It is a matrix of cells with an height equal to the number of 1483 available channels (indexed by ChannelOffsets) and a width (in 1484 timeslots) that is the period of the network scheduling operation 1485 (indexed by slotOffsets) for that CDU matrix. There are different 1486 models for scheduling the usage of the cells, which place the 1487 responsibility of avoiding collisions either on a central controller 1488 or on the devices themselves, at an extra cost in terms of energy to 1489 scan for free cells (more in Section 4.4). 1491 The size of a cell is a timeslot duration, and values of 10 to 15 1492 milliseconds are typical in 802.15.4 TSCH to accommodate for the 1493 transmission of a frame and an ack, including the security validation 1494 on the receive side which may take up to a few milliseconds on some 1495 device architecture. 1497 A CDU matrix iterates over and over with a well-known channel 1498 rotation called the hopping sequence. In a given network, there 1499 might be multiple CDU matrices that operate with different width, so 1500 they have different durations and represent different periodic 1501 operations. It is recommended that all CDU matrices in a 6TiSCH 1502 domain operate with the same cell duration and are aligned, so as to 1503 reduce the chances of interferences from slotted-aloha operations. 1504 The knowledge of the CDU matrices is shared between all the nodes and 1505 used in particular to define slotframes. 1507 A slotframe is a MAC-level abstraction that is common to all nodes 1508 and contains a series of timeslots of equal length and precedence. 1509 It is characterized by a slotframe_ID, and a slotframe_size. A 1510 slotframe aligns to a CDU matrix for its parameters, such as number 1511 and duration of timeslots. 1513 Multiple slotframes can coexist in a node schedule, i.e., a node can 1514 have multiple activities scheduled in different slotframes. A 1515 slotframe is associated with a priority that may be related to the 1516 precedence of different 6TiSCH topologies. The slotframes may be 1517 aligned to different CDU matrices and thus have different width. 1518 There is typically one slotframe for scheduled traffic that has the 1519 highest precedence and one or more slotframe(s) for RPL traffic. The 1520 timeslots in the slotframe are indexed by the SlotOffset; the first 1521 cell is at SlotOffset 0. 1523 When a packet is received from a higher layer for transmission, 6top 1524 inserts that packet in the outgoing queue which matches the packet 1525 best (Differentiated Services [RFC2474] can therefore be used). At 1526 each scheduled transmit slot, 6top looks for the frame in all the 1527 outgoing queues that best matches the cells. If a frame is found, it 1528 is given to the TSCH MAC for transmission. 1530 4.3.6. Distributing the reservation of cells 1532 The 6TiSCH architecture introduces the concept of chunks 1533 (Section 2.1) to distribute the allocation of the spectrum for a 1534 whole group of cells at a time. The CDU matrix is formatted into a 1535 set of chunks, possibly as illustrated in Figure 9, each of the 1536 chunks identified uniquely by a chunk-ID. The knowledge of this 1537 formatting is shared between all the nodes in a 6TiSCH network. 1539 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1540 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 1541 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1542 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 1543 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1544 ... 1545 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1546 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 1547 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1548 0 1 2 3 4 5 6 M 1550 Figure 9: CDU matrix Partitioning in Chunks 1552 The 6TiSCH Architecture expects that a future protocol will enable a 1553 chunk ownership appropriation whereby a RPL parent discovers a chunk 1554 that is not used in its interference domain, claims the chunk, and 1555 then defends it in case another RPL parent would attempt to 1556 appropriate it while it is in use. The chunk is the basic unit of 1557 ownership that is used in that process. 1559 As a result of the process of chunk ownership appropriation, the RPL 1560 parent has exclusive authority to decide which cell in the 1561 appropriated chunk can be used by which node in its interference 1562 domain. In other words, it is implicitly delegated the right to 1563 manage the portion of the CDU matrix that is represented by the 1564 chunk. 1566 Initially, those cells are added to the heap of free cells, then 1567 dynamically placed into existing bundles, in new bundles, or 1568 allocated opportunistically for one transmission. 1570 Note that a PCE is expected to have precedence in the allocation, so 1571 that a RPL parent would only be able to obtain portions that are not 1572 in-use by the PCE. 1574 4.4. Schedule Management Mechanisms 1576 6TiSCH uses 4 paradigms to manage the TSCH schedule of the LLN nodes: 1577 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 1578 and scheduling management, and Hop-by-hop scheduling. Multiple 1579 mechanisms are defined that implement the associated Interaction 1580 Models, and can be combined and used in the same LLN. Which 1581 mechanism(s) to use depends on application requirements. 1583 4.4.1. Static Scheduling 1585 In the simplest instantiation of a 6TiSCH network, a common fixed 1586 schedule may be shared by all nodes in the network. Cells are 1587 shared, and nodes contend for slot access in a slotted aloha manner. 1589 A static TSCH schedule can be used to bootstrap a network, as an 1590 initial phase during implementation, or as a fall-back mechanism in 1591 case of network malfunction. This schedule is pre-established, for 1592 instance decided by a network administrator based on operational 1593 needs. It can be pre-configured into the nodes, or, more commonly, 1594 learned by a node when joining the network using standard IEEE Std. 1595 802.15.4 Information Elements (IE). Regardless, the schedule remains 1596 unchanged after the node has joined a network. RPL is used on the 1597 resulting network. This "minimal" scheduling mechanism that 1598 implements this paradigm is detailed in [RFC8180]. 1600 4.4.2. Neighbor-to-neighbor Scheduling 1602 In the simplest instantiation of a 6TiSCH network described in 1603 Section 4.4.1, nodes may expect a packet at any cell in the schedule 1604 and will waste energy idle listening. In a more complex 1605 instantiation of a 6TiSCH network, a matching portion of the schedule 1606 is established between peers to reflect the observed amount of 1607 transmissions between those nodes. The aggregation of the cells 1608 between a node and a peer forms a bundle that the 6top layer uses to 1609 implement the abstraction of a link for IP. The bandwidth on that 1610 link is proportional to the number of cells in the bundle. 1612 If the size of a bundle is configured to fit an average amount of 1613 bandwidth, peak traffic is dropped. If the size is configured to 1614 allow for peak emissions, energy is be wasted idle listening. 1616 As discussed in more details in Section 4.3, the 6top Protocol 1617 [RFC8480] specifies the exchanges between neighbor nodes to reserve 1618 soft cells to transmit to one another, possibly under the control of 1619 a Scheduling Function (SF). Because this reservation is done without 1620 global knowledge of the schedule of other nodes in the LLN, 1621 scheduling collisions are possible. 1623 And as discussed in Section 4.3.2, an optional Scheduling Function 1624 (SF) is used to monitor bandwidth usage and perform requests for 1625 dynamic allocation by the 6top sublayer. The SF component is not 1626 part of the 6top sublayer. It may be collocated on the same device 1627 or may be partially or fully offloaded to an external system. The 1628 "6TiSCH Minimal Scheduling Function (MSF)" [I-D.ietf-6tisch-msf] 1629 provides a simple scheduling function that can be used by default by 1630 devices that support dynamic scheduling of soft cells. 1632 Monitoring and relocation is done in the 6top layer. For the upper 1633 layer, the connection between two neighbor nodes appears as a number 1634 of cells. Depending on traffic requirements, the upper layer can 1635 request 6top to add or delete a number of cells scheduled to a 1636 particular neighbor, without being responsible for choosing the exact 1637 slotOffset/channelOffset of those cells. 1639 4.4.3. Remote Monitoring and Schedule Management 1641 Remote monitoring and Schedule Management refers to a DetNet/SDN 1642 model whereby an NME and a scheduling entity, associated with a PCE, 1643 reside in a central controller and interact with the 6top layer to 1644 control IPv6 Links and Tracks (Section 4.5) in a 6TiSCH network. The 1645 composite centralized controller can assign physical resources (e.g., 1646 buffers and hard cells) to a particular Track to optimize the 1647 reliability within a bounded latency for a well-specified flow. 1649 The work at the 6TiSCH WG focused on non-deterministic traffic and 1650 did not provide the generic data model that is necessary for the 1651 controller to monitor and manage resources of the 6top sublayer. 1652 This is deferred to future work, see Appendix A.2.2. 1654 With respect to Centralized routing and scheduling, it is envisioned 1655 that the related component of the 6TiSCH Architecture would be an 1656 extension of the Deterministic Networking Architecture 1657 [I-D.ietf-detnet-architecture], which studies Layer-3 aspects of 1658 Deterministic Networks, and covers networks that span multiple 1659 Layer-2 domains. 1661 The DetNet architecture is a form of Software Defined Networking 1662 (SDN) Architecture and is composed of three planes, a (User) 1663 Application Plane, a Controller Plane (where the PCE operates), and a 1664 Network Plane which can represent a 6TiSCH LLN. 1666 Software-Defined Networking (SDN): Layers and Architecture 1667 Terminology [RFC7426] proposes a generic representation of the SDN 1668 architecture that is reproduced in Figure 10. 1670 o--------------------------------o 1671 | | 1672 | +-------------+ +----------+ | 1673 | | Application | | Service | | 1674 | +-------------+ +----------+ | 1675 | Application Plane | 1676 o---------------Y----------------o 1677 | 1678 *-----------------------------Y---------------------------------* 1679 | Network Services Abstraction Layer (NSAL) | 1680 *------Y------------------------------------------------Y-------* 1681 | | 1682 | Service Interface | 1683 | | 1684 o------Y------------------o o---------------------Y------o 1685 | | Control Plane | | Management Plane | | 1686 | +----Y----+ +-----+ | | +-----+ +----Y----+ | 1687 | | Service | | App | | | | App | | Service | | 1688 | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | 1689 | | | | | | | | 1690 | *----Y-----------Y----* | | *---Y---------------Y----* | 1691 | | Control Abstraction | | | | Management Abstraction | | 1692 | | Layer (CAL) | | | | Layer (MAL) | | 1693 | *----------Y----------* | | *----------Y-------------* | 1694 | | | | | | 1695 o------------|------------o o------------|---------------o 1696 | | 1697 | CP | MP 1698 | Southbound | Southbound 1699 | Interface | Interface 1700 | | 1701 *------------Y---------------------------------Y----------------* 1702 | Device and resource Abstraction Layer (DAL) | 1703 *------------Y---------------------------------Y----------------* 1704 | | | | 1705 | o-------Y----------o +-----+ o--------Y----------o | 1706 | | Forwarding Plane | | App | | Operational Plane | | 1707 | o------------------o +-----+ o-------------------o | 1708 | Network Device | 1709 +---------------------------------------------------------------+ 1711 Figure 10: SDN Layers and Architecture Terminology per RFC 7426 1713 The PCE establishes end-to-end Tracks of hard cells, which are 1714 described in more details in Section 4.6.1. 1716 The DetNet work is expected to enable end to end Deterministic Path 1717 across heterogeneous network. This can be for instance a 6TiSCH LLN 1718 and an Ethernet Backbone. 1720 This model fits the 6TiSCH extended configuration, whereby a 6BBR 1721 federates multiple 6TiSCH LLN in a single subnet over a backbone that 1722 can be, for instance, Ethernet or Wi-Fi. In that model, 6TiSCH 6BBRs 1723 synchronize with one another over the backbone, so as to ensure that 1724 the multiple LLNs that form the IPv6 subnet stay tightly 1725 synchronized. 1727 If the Backbone is Deterministic, then the Backbone Router ensures 1728 that the end-to-end deterministic behavior is maintained between the 1729 LLN and the backbone. It is the responsibility of the PCE to compute 1730 a deterministic path and to end across the TSCH network and an IEEE 1731 Std. 802.1 TSN Ethernet backbone, and that of DetNet to enable end- 1732 to-end deterministic forwarding. 1734 4.4.4. Hop-by-hop Scheduling 1736 A node can reserve a Track (Section 4.5) to one or more 1737 destination(s) that are multiple hops away by installing soft cells 1738 at each intermediate node. This forms a Track of soft cells. A 1739 Track Scheduling Function above the 6top sublayer of each node on the 1740 Track is needed to monitor these soft cells and trigger relocation 1741 when needed. 1743 This hop-by-hop reservation mechanism is expected to be similar in 1744 essence to [RFC3209] and/or [RFC4080]/[RFC5974]. The protocol for a 1745 node to trigger hop-by-hop scheduling is not yet defined. 1747 4.5. On Tracks 1749 The architecture introduces the concept of a Track, which is a 1750 directed path from a source 6TiSCH node to one or more destination(s) 1751 6TiSCH node(s) across a 6TiSCH LLN. 1753 A Track is the 6TiSCH instantiation of the concept of a Deterministic 1754 Path as described in [I-D.ietf-detnet-architecture]. Constrained 1755 resources such as memory buffers are reserved for that Track in 1756 intermediate 6TiSCH nodes to avoid loss related to limited capacity. 1757 A 6TiSCH node along a Track not only knows which bundles of cells it 1758 should use to receive packets from a previous hop, but also knows 1759 which bundle(s) it should use to send packets to its next hop along 1760 the Track. 1762 4.5.1. General Behavior of Tracks 1764 A Track is associated with Layer-2 bundles of cells with related 1765 schedules and logical relationships and that ensure that a packet 1766 that is injected in a Track will progress in due time all the way to 1767 destination. 1769 Multiple cells may be scheduled in a Track for the transmission of a 1770 single packet, in which case the normal operation of IEEE Std. 1771 802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the 1772 acknowledgment may be omitted in some cases, for instance if there is 1773 no scheduled cell for a possible retry. 1775 There are several benefits for using a Track to forward a packet from 1776 a source node to the destination node. 1778 1. Track forwarding, as further described in Section 4.6.1, is a 1779 Layer-2 forwarding scheme, which introduces less process delay 1780 and overhead than Layer-3 forwarding scheme. Therefore, LLN 1781 Devices can save more energy and resource, which is critical for 1782 resource constrained devices. 1784 2. Since channel resources, i.e. bundles of cells, have been 1785 reserved for communications between 6TiSCH nodes of each hop on 1786 the Track, the throughput and the maximum latency of the traffic 1787 along a Track are guaranteed and the jitter is maintained small. 1789 3. By knowing the scheduled time slots of incoming bundle(s) and 1790 outgoing bundle(s), 6TiSCH nodes on a Track could save more 1791 energy by staying in sleep state during in-active slots. 1793 4. Tracks are protected from interfering with one another if a cell 1794 belongs to at most one Track, and congestion loss is avoided if 1795 at most one packet can be presented to the MAC to use that cell. 1796 Tracks enhance the reliability of transmissions and thus further 1797 improve the energy consumption in LLN Devices by reducing the 1798 chances of retransmission. 1800 4.5.2. Serial Track 1802 A Serial (or simple) Track is the 6TiSCH version of a circuit; a 1803 bundle of cells that are programmed to receive (RX-cells) is uniquely 1804 paired to a bundle of cells that are set to transmit (TX-cells), 1805 representing a Layer-2 forwarding state which can be used regardless 1806 of the network layer protocol. A Serial Track is thus formed end-to- 1807 end as a succession of paired bundles, a receive bundle from the 1808 previous hop and a transmit bundle to the next hop along the Track. 1810 For a given iteration of the device schedule, the effective channel 1811 of the cell is obtained by adding a pseudo-random number to the 1812 channelOffset of the cell, which results in a rotation of the 1813 frequency that used for transmission. The bundles may be computed so 1814 as to accommodate both variable rates and retransmissions, so they 1815 might not be fully used in the iteration of the schedule. 1817 4.5.3. Complex Track with Replication and Elimination 1819 The art of Deterministic Networks already include PRE techniques. 1820 Example standards include the Parallel Redundancy Protocol (PRP) and 1821 the High-availability Seamless Redundancy (HSR) [IEC62439]. 1822 Similarly, and as opposed to a Serial Track that is a sequence of 1823 nodes and links, a Complex Track is shaped as a directed acyclic 1824 graph towards one or more destination(s) to support multi-path 1825 forwarding and route around failures. 1827 A Complex Track may branch off over non congruent branches for the 1828 purpose of multicasting, and/or redundancy, in which case it 1829 reconverges later down the path. This enables the DetNet Packet 1830 Replication, Elimination and Ordering Functions (PREOF). PRE may be 1831 used to complement Layer-2 ARQ to meet industrial expectations in 1832 Packet Delivery Ratio (PDR), in particular when the Track extends 1833 beyond the 6TiSCH network in a larger DetNet network. 1835 In the art of TSCH, a path does not necessarily support PRE but it is 1836 almost systematically multi-path. This means that a Track is 1837 scheduled so as to ensure that each hop has at least two forwarding 1838 solutions, and the forwarding decision is to try the preferred one 1839 and use the other in case of Layer-2 transmission failure as detected 1840 by ARQ. Similarly, at each 6TiSCH hop along the Track, the PCE may 1841 schedule more than one timeslot for a packet, so as to support 1842 Layer-2 retries (ARQ). It is also possible that the field device 1843 only uses the second branch if sending over the first branch fails. 1845 4.5.4. DetNet End-to-end Path 1847 Ultimately, DetNet [I-D.ietf-detnet-architecture] should enable to 1848 extend a Track beyond the 6TiSCH LLN as illustrated in Figure 11. In 1849 that example, a Track that is laid out from a field device in a 1850 6TiSCH network to an IoT gateway that is located on an 802.1 Time- 1851 Sensitive Networking (TSN) backbone. A 6TiSCH-Aware DetNet Service 1852 Layer handles the Packet Replication, Elimination, and Ordering 1853 Functions over the DODAG that forms a Track. 1855 The Replication function in the 6TiSCH Node sends a copy of each 1856 packet over two different branches, and the PCE schedules each hop of 1857 both branches so that the two copies arrive in due time at the 1858 gateway. In case of a loss on one branch, hopefully the other copy 1859 of the packet still makes it in due time. If two copies make it to 1860 the IoT gateway, the Elimination function in the gateway ignores the 1861 extra packet and presents only one copy to upper layers. 1863 +-=-=-+ 1864 | IoT | 1865 | G/W | 1866 +-=-=-+ 1867 ^ <=== Elimination 1868 Track branch | | 1869 +-=-=-=-+ +-=-=-=-=+ Subnet Backbone 1870 | | 1871 +-=|-=+ +-=|-=+ 1872 | | | Backbone | | | Backbone 1873 o | | | router | | | router 1874 +-=/-=+ +-=|-=+ 1875 o / o o-=-o-=-=/ o 1876 o o-=-o-=/ o o o o o 1877 o \ / o o LLN o 1878 o v <=== Replication 1879 o 1881 Figure 11: Example End-to-End DetNet Track 1883 4.5.5. Cell Reuse 1885 The 6TiSCH architecture provides means to avoid waste of cells as 1886 well as overflows in the transmit bundle of a Track, as follows: 1888 A TX-cell that is not needed for the current iteration may be reused 1889 opportunistically on a per-hop basis for routed packets. When all of 1890 the frame that were received for a given Track are effectively 1891 transmitted, any available TX-cell for that Track can be reused for 1892 upper layer traffic for which the next-hop router matches the next 1893 hop along the Track. In that case, the cell that is being used is 1894 effectively a TX-cell from the Track, but the short address for the 1895 destination is that of the next-hop router. 1897 It results in a frame that is received in a RX-cell of a Track with a 1898 destination MAC address set to this node as opposed to broadcast must 1899 be extracted from the Track and delivered to the upper layer (a frame 1900 with an unrecognized destination MAC address is dropped at the lower 1901 MAC layer and thus is not received at the 6top sublayer). 1903 On the other hand, it might happen that there are not enough TX-cells 1904 in the transmit bundle to accommodate the Track traffic, for instance 1905 if more retransmissions are needed than provisioned. In that case, 1906 and if the frame transports an IPv6 packet, then it can be placed for 1907 transmission in the bundle that is used for Layer-3 traffic towards 1908 the next hop along the Track. The MAC address should be set to the 1909 next-hop MAC address to avoid confusion. 1911 It results in a frame that is received over a Layer-3 bundle may be 1912 in fact associated to a Track. In a classical IP link such as an 1913 Ethernet, off-Track traffic is typically in excess over reservation 1914 to be routed along the non-reserved path based on its QoS setting. 1915 But with 6TiSCH, since the use of the Layer-3 bundle may be due to 1916 transmission failures, it makes sense for the receiver to recognize a 1917 frame that should be re-Tracked, and to place it back on the 1918 appropriate bundle if possible. A frame should be re-Tracked if the 1919 Per-Hop-Behavior group indicated in the Differentiated Services Field 1920 of the IPv6 header is set to Deterministic Forwarding, as discussed 1921 in Section 4.7.1. A frame is re-Tracked by scheduling it for 1922 transmission over the transmit bundle associated to the Track, with 1923 the destination MAC address set to broadcast. 1925 4.6. Forwarding Models 1927 By forwarding, this specification means the per-packet operation that 1928 allows to deliver a packet to a next hop or an upper layer in this 1929 node. Forwarding is based on pre-existing state that was installed 1930 as a result of a routing computation Section 4.7. 6TiSCH supports 1931 three different forwarding model, G-MPLS Track Forwarding, 6LoWPAN 1932 Fragment Forwarding and classical IPv6 Forwarding. 1934 4.6.1. Track Forwarding 1936 Forwarding along a Track can be seen as a Generalized Multi-protocol 1937 Label Switching (G-MPLS) operation in that the information used to 1938 switch a frame is not an explicit label, but rather related to other 1939 properties of the way the packet was received, a particular cell in 1940 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 1941 Layer-2 security) accepts a frame, that frame can be switched 1942 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 1943 fragment, or a frame from an alternate protocol such as WirelessHART 1944 or ISA100.11a. 1946 A data frame that is forwarded along a Track normally has a 1947 destination MAC address that is set to broadcast - or a multicast 1948 address depending on MAC support. This way, the MAC layer in the 1949 intermediate nodes accepts the incoming frame and 6top switches it 1950 without incurring a change in the MAC header. In the case of IEEE 1951 Std. 802.15.4, this means effectively broadcast, so that along the 1952 Track the short address for the destination of the frame is set to 1953 0xFFFF. 1955 There are 2 modes for a Track, native mode and tunnel mode. 1957 4.6.1.1. Native Mode 1959 In native mode, the Protocol Data Unit (PDU) is associated with flow- 1960 dependent meta-data that refers uniquely to the Track, so the 6top 1961 sublayer can place the frame in the appropriate cell without 1962 ambiguity. In the case of IPv6 traffic, this flow identification may 1963 be done using a 6-tuple as discussed in [I-D.ietf-detnet-ip]. In 1964 particular, implementations of this document should support 1965 identification of DetNet flows based on the IPv6 Flow Label field. 1966 The flow identification may also be done using a dedicated RPL 1967 Instance (see section 3.1.3 of [RFC6550]), signaled in a RPL Packet 1968 Information (more in section 11.2.2.1 of [RFC6550]). The flow 1969 identification is validated at egress before restoring the 1970 destination MAC address (DMAC) and punting to the upper layer. 1972 Figure 12 illustrates the Track Forwarding operation which happens at 1973 the 6top sublayer, below IP. 1975 | Packet flowing across the network ^ 1976 +--------------+ | | 1977 | IPv6 | | | 1978 +--------------+ | | 1979 | 6LoWPAN HC | | | 1980 +--------------+ ingress egress 1981 | 6top | sets +----+ +----+ restores 1982 +--------------+ DMAC to | | | | DMAC to 1983 | TSCH MAC | brdcst | | | | dest 1984 +--------------+ | | | | | | 1985 | LLN PHY | +-------+ +--...-----+ +-------+ 1986 +--------------+ 1987 Ingress Relay Relay Egress 1988 Stack Layer Node Node Node Node 1990 Figure 12: Track Forwarding, Native Mode 1992 4.6.1.2. Tunnel Mode 1994 In tunnel mode, the frames originate from an arbitrary protocol over 1995 a compatible MAC that may or may not be synchronized with the 6TiSCH 1996 network. An example of this would be a router with a dual radio that 1997 is capable of receiving and sending WirelessHART or ISA100.11a frames 1998 with the second radio, by presenting itself as an access Point or a 1999 Backbone Router, respectively. In that mode, some entity (e.g. PCE) 2000 can coordinate with a WirelessHART Network Manager or an ISA100.11a 2001 System Manager to specify the flows that are transported. 2003 +--------------+ 2004 | IPv6 | 2005 +--------------+ 2006 | 6LoWPAN HC | 2007 +--------------+ set restore 2008 | 6top | +DMAC+ +DMAC+ 2009 +--------------+ to|brdcst to|nexthop 2010 | TSCH MAC | | | | | 2011 +--------------+ | | | | 2012 | LLN PHY | +-------+ +--...-----+ +-------+ 2013 +--------------+ | ingress egress | 2014 | | 2015 +--------------+ | | 2016 | LLN PHY | | | 2017 +--------------+ | Packet flowing across the network | 2018 | TSCH MAC | | | 2019 +--------------+ | DMAC = | DMAC = 2020 |ISA100/WiHART | | nexthop v nexthop 2021 +--------------+ 2022 Source Ingress Egress Destination 2023 Stack Layer Node Node Node Node 2025 Figure 13: Track Forwarding, Tunnel Mode 2027 In that case, the flow information that identifies the Track at the 2028 ingress 6TiSCH router is derived from the RX-cell. The DMAC is set 2029 to this node but the flow information indicates that the frame must 2030 be tunneled over a particular Track so the frame is not passed to the 2031 upper layer. Instead, the DMAC is forced to broadcast and the frame 2032 is passed to the 6top sublayer for switching. 2034 At the egress 6TiSCH router, the reverse operation occurs. Based on 2035 tunneling information of the Track, which may for instance indicate 2036 that the tunneled datagram is an IP packet, the datagram is passed to 2037 the appropriate Link-Layer with the destination MAC restored. 2039 4.6.1.3. Tunneling Information 2041 Tunneling information coming with the Track configuration provides 2042 the destination MAC address of the egress endpoint as well as the 2043 tunnel mode and specific data depending on the mode, for instance a 2044 service access point for frame delivery at egress. 2046 If the tunnel egress point does not have a MAC address that matches 2047 the configuration, the Track installation fails. 2049 If the final Layer-3 destination address is the same address as the 2050 tunnel termination, then it is possible that the IPv6 address of the 2051 destination is compressed at the 6LoWPAN sublayer based on the MAC 2052 address. It is thus mandatory at the ingress point to validate that 2053 the MAC address that was used at the 6LoWPAN sublayer for compression 2054 matches that of the tunnel egress point. For that reason, the node 2055 that injects a packet on a Track checks that the destination is 2056 effectively that of the tunnel egress point before it overwrites it 2057 to broadcast. The 6top sublayer at the tunnel egress point reverts 2058 that operation to the MAC address obtained from the tunnel 2059 information. 2061 4.6.2. IPv6 Forwarding 2063 As the packets are routed at Layer-3, traditional QoS and Active 2064 Queue Management (AQM) operations are expected to prioritize flows. 2066 | Packet flowing across the network ^ 2067 +--------------+ | | 2068 | IPv6 | | +-QoS+ +-QoS+ | 2069 +--------------+ | | | | | | 2070 | 6LoWPAN HC | | | | | | | 2071 +--------------+ | | | | | | 2072 | 6top | | | | | | | 2073 +--------------+ | | | | | | 2074 | TSCH MAC | | | | | | | 2075 +--------------+ | | | | | | 2076 | LLN PHY | +-------+ +--...-----+ +-------+ 2077 +--------------+ 2078 Source Ingress Egress Destination 2079 Stack Layer Node Router Router Node 2081 Figure 14: IP Forwarding 2083 4.6.3. Fragment Forwarding 2085 Considering that per section 4 of [RFC4944] 6LoWPAN packets can be as 2086 large as 1280 bytes (the IPv6 minimum MTU), and that the non-storing 2087 mode of RPL implies Source Routing that requires space for routing 2088 headers, and that a IEEE Std. 802.15.4 frame with security may carry 2089 in the order of 80 bytes of effective payload, an IPv6 packet might 2090 be fragmented into more than 16 fragments at the 6LoWPAN sublayer. 2092 This level of fragmentation is much higher than that traditionally 2093 experienced over the Internet with IPv4 fragments, where 2094 fragmentation is already known as harmful. 2096 In the case to a multihop route within a 6TiSCH network, Hop-by-Hop 2097 recomposition occurs at each hop to reform the packet and route it. 2098 This creates additional latency and forces intermediate nodes to 2099 store a portion of a packet for an undetermined time, thus impacting 2100 critical resources such as memory and battery. 2102 [I-D.ietf-6lo-minimal-fragment] describes a framework for forwarding 2103 fragments end-to-end across a 6TiSCH route-over mesh. Within that 2104 framework, [I-D.ietf-lwig-6lowpan-virtual-reassembly] details a 2105 virtual reassembly buffer mechanism whereby the datagram tag in the 2106 6LoWPAN Fragment is used as a label for switching at the 6LoWPAN 2107 sublayer. 2109 Building on this technique, [I-D.ietf-6lo-fragment-recovery] 2110 introduces a new format for 6LoWPAN fragments that enables the 2111 selective recovery of individual fragments, and allows for a degree 2112 of flow control based on an Explicit Congestion Notification. 2114 | Packet flowing across the network ^ 2115 +--------------+ | | 2116 | IPv6 | | +----+ +----+ | 2117 +--------------+ | | | | | | 2118 | 6LoWPAN HC | | learn learn | 2119 +--------------+ | | | | | | 2120 | 6top | | | | | | | 2121 +--------------+ | | | | | | 2122 | TSCH MAC | | | | | | | 2123 +--------------+ | | | | | | 2124 | LLN PHY | +-------+ +--...-----+ +-------+ 2125 +--------------+ 2126 Source Ingress Egress Destination 2127 Stack Layer Node Router Router Node 2129 Figure 15: Forwarding First Fragment 2131 In that model, the first fragment is routed based on the IPv6 header 2132 that is present in that fragment. The 6LoWPAN sublayer learns the 2133 next hop selection, generates a new datagram tag for transmission to 2134 the next hop, and stores that information indexed by the incoming MAC 2135 address and datagram tag. The next fragments are then switched based 2136 on that stored state. 2138 | Packet flowing across the network ^ 2139 +--------------+ | | 2140 | IPv6 | | | 2141 +--------------+ | | 2142 | 6LoWPAN HC | | replay replay | 2143 +--------------+ | | | | | | 2144 | 6top | | | | | | | 2145 +--------------+ | | | | | | 2146 | TSCH MAC | | | | | | | 2147 +--------------+ | | | | | | 2148 | LLN PHY | +-------+ +--...-----+ +-------+ 2149 +--------------+ 2150 Source Ingress Egress Destination 2151 Stack Layer Node Router Router Node 2153 Figure 16: Forwarding Next Fragment 2155 A bitmap and an ECN echo in the end-to-end acknowledgment enable the 2156 source to resend the missing fragments selectively. The first 2157 fragment may be resent to carve a new path in case of a path failure. 2158 The ECN echo set indicates that the number of outstanding fragments 2159 should be reduced. 2161 4.7. Advanced 6TiSCH Routing 2163 4.7.1. Packet Marking and Handling 2165 All packets inside a 6TiSCH domain must carry the Instance ID that 2166 identifies the 6TiSCH topology that is to be used for routing and 2167 forwarding that packet. The location of that information must be the 2168 same for all packets forwarded inside the domain. 2170 For packets that are routed by a PCE along a Track, the tuple formed 2171 by the IPv6 source address and a local RPLInstanceID in the packet 2172 identify uniquely the Track and associated transmit bundle. 2174 For packets that are routed by RPL, that information is the 2175 RPLInstanceID which is carried in the RPL Packet Information (RPI), 2176 as discussed in section 11.2 of [RFC6550], "Loop Avoidance and 2177 Detection". The RPI is transported by a RPL option in the IPv6 Hop- 2178 By-Hop Header [RFC6553]. 2180 A compression mechanism for the RPL packet artifacts that integrates 2181 the compression of IP-in-IP encapsulation and the Routing Header type 2182 3 [RFC6554] with that of the RPI in a 6LoWPAN dispatch/header type is 2183 specified in [RFC8025] and [RFC8138]. 2185 Either way, the method and format used for encoding the RPLInstanceID 2186 is generalized to all 6TiSCH topological Instances, which include 2187 both RPL Instances and Tracks. 2189 4.7.2. Replication, Retries and Elimination 2191 6TiSCH supports the PREOF operations of elimination and reordering of 2192 packets along a complex Track, but has no requirement about whether a 2193 sequence number would be tagged in the packet for that purpose. With 2194 6TiSCH, the schedule can tell when multiple receive timeslots 2195 correspond to copies of a same packet, in which case the receiver may 2196 avoid listening to the extra copies once it had received one instance 2197 of the packet. 2199 The semantics of the configuration will enable correlated timeslots 2200 to be grouped for transmit (and respectively receive) with a 'OR' 2201 relations, and then a 'AND' relation would be configurable between 2202 groups. The semantics is that if the transmit (and respectively 2203 receive) operation succeeded in one timeslot in a 'OR' group, then 2204 all the other timeslots in the group are ignored. Now, if there are 2205 at least two groups, the 'AND' relation between the groups indicates 2206 that one operation must succeed in each of the groups. 2208 On the transmit side, timeslots provisioned for retries along a same 2209 branch of a Track are placed a same 'OR' group. The 'OR' relation 2210 indicates that if a transmission is acknowledged, then 2211 retransmissions of that packet should not be attempted for remaining 2212 timeslots in that group. There are as many 'OR' groups as there are 2213 branches of the Track departing from this node. Different 'OR' 2214 groups are programmed for the purpose of replication, each group 2215 corresponding to one branch of the Track. The 'AND' relation between 2216 the groups indicates that transmission over any of branches must be 2217 attempted regardless of whether a transmission succeeded in another 2218 branch. It is also possible to place cells to different next-hop 2219 routers in a same 'OR' group. This allows to route along multi-path 2220 Tracks, trying one next-hop and then another only if sending to the 2221 first fails. 2223 On the receive side, all timeslots are programmed in a same 'OR' 2224 group. Retries of a same copy as well as converging branches for 2225 elimination are converged, meaning that the first successful 2226 reception is enough and that all the other timeslots can be ignored. 2227 A 'AND' group denotes different packets that must all be received and 2228 transmitted over the associated transmit groups within their 2229 respected 'AND' or 'OR' rules. 2231 As an example say that we have a simple network as represented in 2232 Figure 17, and we want to enable PREOF between an ingress node I and 2233 an egress node E. 2235 +-+ +-+ 2236 -- |A| ------ |C| -- 2237 / +-+ +-+ \ 2238 / \ 2239 +-+ +-+ 2240 |I| |E| 2241 +-+ +-+ 2242 \ / 2243 \ +-+ +-+ / 2244 -- |B| ------- |D| -- 2245 +-+ +-+ 2247 Figure 17: Scheduling PREOF on a Simple Network 2249 The assumption for this particular problem is that a 6TiSCH node has 2250 a single radio, so it cannot perform 2 receive and/or transmit 2251 operations at the same time, even on 2 different channels. 2253 Say we have 6 possible channels, and at least 10 timeslots per 2254 slotframe. Figure 18 shows a possible schedule whereby each 2255 transmission is retried 2 or 3 times, and redundant copies are 2256 forwarded in parallel via A and C on the one hand, and B and D on the 2257 other, providing time diversity, spatial diversity though different 2258 physical paths, and frequency diversity. 2260 slotOffset 0 1 2 3 4 5 6 7 9 2261 +----+----+----+----+----+----+----+----+----+ 2262 channelOffset 0 | | | | | | |B->D| | | ... 2263 +----+----+----+----+----+----+----+----+----+ 2264 channelOffset 1 | |I->A| |A->C|B->D| | | | | ... 2265 +----+----+----+----+----+----+----+----+----+ 2266 channelOffset 2 |I->A| | |I->B| |C->E| |D->E| | ... 2267 +----+----+----+----+----+----+----+----+----+ 2268 channelOffset 3 | | | | |A->C| | | | | ... 2269 +----+----+----+----+----+----+----+----+----+ 2270 channelOffset 4 | | |I->B| | |B->D| | |D->E| ... 2271 +----+----+----+----+----+----+----+----+----+ 2272 channelOffset 5 | | |A->C| | | |C->E| | | ... 2273 +----+----+----+----+----+----+----+----+----+ 2275 Figure 18: Example Global Schedule 2277 This translates in a different slotframe for every node that provides 2278 the waking and sleeping times, and the channelOffset to be used when 2279 awake. Figure 19 shows the corresponding slotframe for node A. 2281 slotOffset 0 1 2 3 4 5 6 7 9 2282 +----+----+----+----+----+----+----+----+----+ 2283 operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ... 2284 +----+----+----+----+----+----+----+----+----+ 2285 channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ... 2286 +----+----+----+----+----+----+----+----+----+ 2288 Figure 19: Example Slotframe for Node A 2290 The logical relationship between the timeslots is given by the 2291 following table: 2293 +------+---------------------+------------------------+ 2294 | Node | rcv slotOffset | xmit slotOffset | 2295 +------+---------------------+------------------------+ 2296 | I | N/A | (0 OR 1) AND (2 OR 3) | 2297 | A | (0 OR 1) | (2 OR 3 OR 4) | 2298 | B | (2 OR 3) | (4 OR 5 OR 6) | 2299 | C | (2 OR 3 OR 4) | (5 OR 6) | 2300 | D | (4 OR 5 OR 6) | (7 OR 8) | 2301 | E | (5 OR 6 OR 7 OR 8) | N/A | 2302 +------+---------------------+------------------------+ 2304 5. IANA Considerations 2306 This specification does not require IANA action. 2308 6. Security Considerations 2310 The operation of 6TiSCH Tracks inherits its high level operation from 2311 DetNet and is subject to the observations in section 5 of 2312 [I-D.ietf-detnet-architecture]. As discussed there, measures must be 2313 taken to protect the time synchronization, and for 6TiSCH this 2314 includes ensuring that the Absolute Slot Number (ASN), which is used 2315 as ever incrementing counter for the computation of the Link-Layer 2316 security nonce, is not compromised, more below on this. Also, the 2317 installation and the maintenance of the 6TiSCH Tracks depends on the 2318 availability of a controller with a PCE to compute and push them in 2319 the network. When that connectivity is lost, existing Tracks may 2320 continue to operate until the end of their lifetime, but cannot be 2321 removed or updated, and new Tracks cannot be installed. As with 2322 DetNet in general, the communication with the PCE must be secured and 2323 should be protected against DoS attacks, and the discussion on the 2324 security considerations defined for Abstraction and Control of 2325 Traffic Engineered Networks (ACTN) in Section 9 of [RFC8453], applies 2326 equally to 6TiSCH. 2328 This architecture operates on IEEE Std. 802.15.4 and expects the 2329 Link-Layer security to be enabled at all times between connected 2330 devices, except for the very first step of the device join process, 2331 where a joining device may need some initial, unsecured exchanges so 2332 as to obtain its initial key material. 2334 IEEE Std. 802.15.4 [IEEE802154] specifies that in a TSCH network, the 2335 nonce that is used for the computation of the Message Integrity Code 2336 (MIC) to secure Link-Layer frames is composed of the address of the 2337 source of the frame and of the ASN. The standard assumes that the 2338 ASN is distributed securely by other means. The ASN is not passed 2339 explicitly in the data frames and does not constitute a complete 2340 anti-replay protection. It results that upper layer protocols must 2341 provide a way to detect duplicates and cope with them. 2343 If the receiver and the sender have a different sense of ASN, the MIC 2344 will not validate and the frame will be dropped. In that sense, TSCH 2345 induces an event horizon whereby only nodes that have a common sense 2346 of ASN can talk to one another in an authenticated manner. With 2347 6TiSCH, the pledge discovers a tentative ASN in beacons from nodes 2348 that have already joined the network. But even if the beacon can be 2349 authenticated, the ASN cannot be trusted as it could be a replay by 2350 an attacker and thus could announce an ASN that represents a time in 2351 the past. If the pledge uses an ASN that is learned from a replayed 2352 beacon for an encrypted transmission, a nonce-reuse attack becomes 2353 possible and the network keys may be compromised. 2355 Time Synchronization in TSCH induces another event horizon whereby a 2356 node will only communicate with another node if they are synchronized 2357 within a guard time. The pledge discovers the synchronization of the 2358 network based on the time of reception of the beacon. If an attacker 2359 synchronizes a pledge outside of the guard time of the legitimate 2360 nodes then the pledge will never see a legitimate beacon and may not 2361 discover the attack. 2363 After obtaining the tentative ASN, a pledge that wishes to join the 2364 6TiSCH network must use a join protocol to obtain its security keys. 2365 The join protocol used in 6TiSCH is the Constrained Join Protocol 2366 (CoJP). In the minimal setting defined in 2367 [I-D.ietf-6tisch-minimal-security], the authentication requires a 2368 pre-shared key, based on which a secure session is derived. The CoJP 2369 exchange may also be preceded with a zero-touch handshake 2370 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in order to enable pledge 2371 joining based on certificates and/or inter-domain communication. 2373 As detailed in Section 4.2.1, a Join Proxy (JP) helps the pledge for 2374 the join procedure by relaying the link-scope Join Request over the 2375 IP network to a Join Registrar/Coordinator (JRC) that can 2376 authenticate the pledge and validate that it is attached to the 2377 appropriate network. As a result of the CoJP exchange, the pledge is 2378 in possession of a Link-Layer material including keys and a short 2379 address, and if the ASN is known to be correct, all traffic can now 2380 be secured using CCM* at the Link-Layer. 2382 The authentication steps must be such that they cannot be replayed by 2383 an attacker, and they must not depend on the tentative ASN being 2384 valid. During the authentication, the keying material that the 2385 pledge obtains from the JRC does not provide protection against 2386 spoofed ASN. Once the pledge has obtained the keys to use in the 2387 network, it may still need to verify the ASN. If the nonce used in 2388 the Layer-2 security derives from the extended (MAC-64) address, then 2389 replaying the ASN alone cannot enable a nonce-reuse attack unless the 2390 same node is lost its state with a previous ASN. But if the nonce 2391 derives from the short address (e.g., assigned by the JRC) then the 2392 JRC must ensure that it never assigns short addresses that were 2393 already given to this or other nodes with the same keys. In other 2394 words, the network must be rekeyed before the JRC runs out of short 2395 addresses. 2397 Those issues are discussed in more details in 2398 [I-D.ietf-6tisch-minimal-security]. 2400 7. Acknowledgments 2402 7.1. Contributors 2404 The co-authors of this document are listed below: 2406 Robert Assimiti for his breakthrough work on RPL over TSCH and 2407 initial text and guidance; 2409 Kris Pister for creating it all and his continuing guidance through 2410 the elaboration of this design; 2412 Maria Rita Palattella for managing the Terminology document merged 2413 into this through the work of 6TiSCH; 2415 Michael Richardson for his leadership role in the Security Design 2416 Team and his contribution throughout this document; 2418 Rene Struik for the security section and his contribution to the 2419 Security Design Team; 2421 Malisa Vucinic for the work on the one-touch join process and his 2422 contribution to the Security Design Team; 2424 Xavier Vilajosana who lead the design of the minimal support with 2425 RPL and contributed deeply to the 6top design and the G-MPLS 2426 operation of Track switching; 2428 Qin Wang who lead the design of the 6top sublayer and contributed 2429 related text that was moved and/or adapted in this document; 2431 Thomas Watteyne for his contribution to the whole design, in 2432 particular on TSCH and security, and to the open source 2433 community with openWSN that he created. 2435 Simon Duquennoy for his contribution to the open source community 2436 with the 6TiSCH implementaton of contiki, and for his 2437 contribution to MSF and autonomous unicast cells. 2439 Tero Kivinen for his contribution to the security work in general 2440 and the security section in particular. 2442 7.2. Special Thanks 2444 Special thanks to Tero Kivinen, Jonathan Simon, Giuseppe Piro, Subir 2445 Das and Yoshihiro Ohba for their deep contribution to the initial 2446 security work, to Yasuyuki Tanaka for his work on implementation and 2447 simulation that tremendously helped build a robust system, to Diego 2448 Dujovne for starting and leading the SF0 effort and to Tengfei Chang 2449 for evolving it in the MSF. 2451 Special thanks also to Pat Kinney for his support in maintaining the 2452 connection active and the design in line with work happening at IEEE 2453 Std. 802.15.4. 2455 Special thanks to Ted Lemon who was the INT Area A-D while this 2456 specification was initiated for his great support and help 2457 throughout, and to Suresh Krishnan who took over with that kind 2458 efficiency of his till publication. 2460 Also special thanks to Ralph Droms who performed the first INT Area 2461 Directorate review, that was very deep and through and radically 2462 changed the orientations of this document, and then to Eliot Lear and 2463 Carlos Pignataro who help finalize this document in preparation to 2464 the IESG reviews, and to Gorry Fairhurst, David Mandelberg, Qin Wu, 2465 and Andrew Malis who contributed to the final shaping of this 2466 document through the IESG review procedure. 2468 7.3. And Do not Forget 2470 This specification is the result of multiple interactions, in 2471 particular during the 6TiSCH (bi)Weekly Interim call, relayed through 2472 the 6TiSCH mailing list at the IETF, over the course of more than 5 2473 years. 2475 The authors wish to thank in arbitrary order: Alaeddine Weslati, 2476 Chonggang Wang, Georgios Exarchakos, Zhuo Chen, Georgios 2477 Papadopoulos, Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Deji 2478 Chen, Martin Turon, Dominique Barthel, Elvis Vogli, Geraldine Texier, 2479 Malisa Vucinic, Guillaume Gaillard, Herman Storey, Kazushi Muraoka, 2480 Ken Bannister, Kuor Hsin Chang, Laurent Toutain, Maik Seewald, Maria 2481 Rita Palattella, Michael Behringer, Nancy Cam Winget, Nicola 2482 Accettura, Nicolas Montavont, Oleg Hahm, Patrick Wetterwald, Paul 2483 Duffy, Peter van der Stock, Rahul Sen, Pieter de Mil, Pouria Zand, 2484 Rouhollah Nabati, Rafa Marin-Lopez, Raghuram Sudhaakar, Sedat Gormus, 2485 Shitanshu Shah, Steve Simlo, Tengfei Chang, Tina Tsou, Tom Phinney, 2486 Xavier Lagrange, Ines Robles and Samita Chakrabarti for their 2487 participation and various contributions. 2489 8. References 2491 8.1. Normative References 2493 [I-D.ietf-detnet-architecture] 2494 Finn, N., Thubert, P., Varga, B., and J. Farkas, 2495 "Deterministic Networking Architecture", draft-ietf- 2496 detnet-architecture-13 (work in progress), May 2019. 2498 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2499 DOI 10.17487/RFC0768, August 1980, 2500 . 2502 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2503 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2504 DOI 10.17487/RFC4861, September 2007, 2505 . 2507 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2508 Address Autoconfiguration", RFC 4862, 2509 DOI 10.17487/RFC4862, September 2007, 2510 . 2512 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2513 "Transmission of IPv6 Packets over IEEE 802.15.4 2514 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2515 . 2517 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2518 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2519 DOI 10.17487/RFC6282, September 2011, 2520 . 2522 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2523 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2524 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2525 Low-Power and Lossy Networks", RFC 6550, 2526 DOI 10.17487/RFC6550, March 2012, 2527 . 2529 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 2530 Protocol for Low-Power and Lossy Networks (RPL)", 2531 RFC 6552, DOI 10.17487/RFC6552, March 2012, 2532 . 2534 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2535 Power and Lossy Networks (RPL) Option for Carrying RPL 2536 Information in Data-Plane Datagrams", RFC 6553, 2537 DOI 10.17487/RFC6553, March 2012, 2538 . 2540 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2541 Routing Header for Source Routes with the Routing Protocol 2542 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2543 DOI 10.17487/RFC6554, March 2012, 2544 . 2546 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2547 Bormann, "Neighbor Discovery Optimization for IPv6 over 2548 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2549 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2550 . 2552 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2553 Application Protocol (CoAP)", RFC 7252, 2554 DOI 10.17487/RFC7252, June 2014, 2555 . 2557 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2558 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2559 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2560 . 2562 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2563 "IPv6 over Low-Power Wireless Personal Area Network 2564 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2565 April 2017, . 2567 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2568 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2569 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2570 May 2017, . 2572 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2573 (IPv6) Specification", STD 86, RFC 8200, 2574 DOI 10.17487/RFC8200, July 2017, 2575 . 2577 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2578 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2579 DOI 10.17487/RFC8453, August 2018, 2580 . 2582 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2583 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2584 DOI 10.17487/RFC8480, November 2018, 2585 . 2587 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2588 Perkins, "Registration Extensions for IPv6 over Low-Power 2589 Wireless Personal Area Network (6LoWPAN) Neighbor 2590 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2591 . 2593 8.2. Informative References 2595 [AMI] US Department of Energy, "Advanced Metering Infrastructure 2596 and Customer Systems", 2006, 2597 . 2600 [ANIMA] IETF, "Autonomic Networking Integrated Model and 2601 Approach", 2602 . 2604 [CCAMP] IETF, "Common Control and Measurement Plane", 2605 . 2607 [HART] www.hartcomm.org, "Highway Addressable remote Transducer, 2608 a group of specifications for industrial process and 2609 control devices administered by the HART Foundation". 2611 [I-D.ietf-6lo-ap-nd] 2612 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2613 "Address Protected Neighbor Discovery for Low-power and 2614 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 2615 progress), April 2019. 2617 [I-D.ietf-6lo-backbone-router] 2618 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2619 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 2620 in progress), February 2019. 2622 [I-D.ietf-6lo-fragment-recovery] 2623 Thubert, P., "6LoWPAN Selective Fragment Recovery", draft- 2624 ietf-6lo-fragment-recovery-04 (work in progress), June 2625 2019. 2627 [I-D.ietf-6lo-minimal-fragment] 2628 Watteyne, T., Bormann, C., and P. Thubert, "LLN Minimal 2629 Fragment Forwarding", draft-ietf-6lo-minimal-fragment-02 2630 (work in progress), June 2019. 2632 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 2633 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 2634 draft-ietf-6tisch-dtsecurity-zerotouch-join-03 (work in 2635 progress), October 2018. 2637 [I-D.ietf-6tisch-minimal-security] 2638 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 2639 "Minimal Security Framework for 6TiSCH", draft-ietf- 2640 6tisch-minimal-security-11 (work in progress), June 2019. 2642 [I-D.ietf-6tisch-msf] 2643 Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and 2644 D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", 2645 draft-ietf-6tisch-msf-03 (work in progress), April 2019. 2647 [I-D.ietf-anima-bootstrapping-keyinfra] 2648 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2649 S., and K. Watsen, "Bootstrapping Remote Secure Key 2650 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2651 keyinfra-22 (work in progress), June 2019. 2653 [I-D.ietf-core-object-security] 2654 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2655 "Object Security for Constrained RESTful Environments 2656 (OSCORE)", draft-ietf-core-object-security-16 (work in 2657 progress), March 2019. 2659 [I-D.ietf-detnet-ip] 2660 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 2661 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 2662 draft-ietf-detnet-ip-00 (work in progress), May 2019. 2664 [I-D.ietf-detnet-use-cases] 2665 Grossman, E., "Deterministic Networking Use Cases", draft- 2666 ietf-detnet-use-cases-20 (work in progress), December 2667 2018. 2669 [I-D.ietf-lwig-6lowpan-virtual-reassembly] 2670 Bormann, C. and T. Watteyne, "Virtual reassembly buffers 2671 in 6LoWPAN", draft-ietf-lwig-6lowpan-virtual-reassembly-01 2672 (work in progress), March 2019. 2674 [I-D.ietf-manet-aodvv2] 2675 Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 2676 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 2677 (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in 2678 progress), May 2016. 2680 [I-D.ietf-roll-aodv-rpl] 2681 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 2682 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 2683 Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in 2684 progress), April 2019. 2686 [I-D.ietf-roll-dao-projection] 2687 Thubert, P., Jadhav, R., Gillmore, M., and J. Pylakutty, 2688 "Root initiated routing state in RPL", draft-ietf-roll- 2689 dao-projection-06 (work in progress), May 2019. 2691 [I-D.ietf-roll-rpl-industrial-applicability] 2692 Phinney, T., Thubert, P., and R. Assimiti, "RPL 2693 applicability in industrial networks", draft-ietf-roll- 2694 rpl-industrial-applicability-02 (work in progress), 2695 October 2013. 2697 [I-D.ietf-roll-unaware-leaves] 2698 Thubert, P., "Routing for RPL Leaves", draft-ietf-roll- 2699 unaware-leaves-00 (work in progress), May 2019. 2701 [I-D.ietf-roll-useofrplinfo] 2702 Robles, I., Richardson, M., and P. Thubert, "Using RPL 2703 Option Type, Routing Header for Source Routes and IPv6-in- 2704 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 2705 roll-useofrplinfo-30 (work in progress), June 2019. 2707 [I-D.rahul-roll-mop-ext] 2708 Jadhav, R. and P. Thubert, "RPL Mode of Operation 2709 extension", draft-rahul-roll-mop-ext-01 (work in 2710 progress), June 2019. 2712 [I-D.selander-ace-cose-ecdhe] 2713 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 2714 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 2715 cose-ecdhe-13 (work in progress), March 2019. 2717 [I-D.thubert-6lo-bier-dispatch] 2718 Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A 2719 6loRH for BitStrings", draft-thubert-6lo-bier-dispatch-06 2720 (work in progress), January 2019. 2722 [I-D.thubert-6lo-unicast-lookup] 2723 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 2724 Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work 2725 in progress), January 2019. 2727 [I-D.thubert-bier-replication-elimination] 2728 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 2729 TE extensions for Packet Replication and Elimination 2730 Function (PREF) and OAM", draft-thubert-bier-replication- 2731 elimination-03 (work in progress), March 2018. 2733 [I-D.thubert-raw-technologies] 2734 Thubert, P., Cavalcanti, D., and X. Vilajosana, "Reliable 2735 and Available Wireless Technologies", draft-thubert-raw- 2736 technologies-02 (work in progress), June 2019. 2738 [I-D.thubert-roll-bier] 2739 Thubert, P., "RPL-BIER", draft-thubert-roll-bier-02 (work 2740 in progress), July 2018. 2742 [IEC62439] 2743 IEC, "Industrial communication networks - High 2744 availability automation networks - Part 3: Parallel 2745 Redundancy Protocol (PRP) and High-availability Seamless 2746 Redundancy (HSR) - IEC62439-3", 2012, 2747 . 2749 [IEEE802154] 2750 IEEE standard for Information Technology, "IEEE Std. 2751 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2752 and Physical Layer (PHY) Specifications for Low-Rate 2753 Wireless Personal Area Networks". 2755 [IEEE802154e] 2756 IEEE standard for Information Technology, "IEEE standard 2757 for Information Technology, IEEE Std. 802.15.4, Part. 2758 15.4: Wireless Medium Access Control (MAC) and Physical 2759 Layer (PHY) Specifications for Low-Rate Wireless Personal 2760 Area Networks, June 2011 as amended by IEEE Std. 2761 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2762 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2763 2012. 2765 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 2766 . 2768 [ISA100.11a] 2769 ISA/ANSI, "Wireless Systems for Industrial Automation: 2770 Process Control and Related Applications - ISA100.11a-2011 2771 - IEC 62734", 2011, . 2774 [PCE] IETF, "Path Computation Element", 2775 . 2777 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2778 "Definition of the Differentiated Services Field (DS 2779 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2780 DOI 10.17487/RFC2474, December 1998, 2781 . 2783 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 2784 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 2785 DOI 10.17487/RFC2545, March 1999, 2786 . 2788 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2789 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2790 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2791 . 2793 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2794 Information Models and Data Models", RFC 3444, 2795 DOI 10.17487/RFC3444, January 2003, 2796 . 2798 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 2799 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 2800 RFC 3963, DOI 10.17487/RFC3963, January 2005, 2801 . 2803 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 2804 Bosch, "Next Steps in Signaling (NSIS): Framework", 2805 RFC 4080, DOI 10.17487/RFC4080, June 2005, 2806 . 2808 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2809 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2810 2006, . 2812 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 2813 DOI 10.17487/RFC4903, June 2007, 2814 . 2816 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2817 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2818 Overview, Assumptions, Problem Statement, and Goals", 2819 RFC 4919, DOI 10.17487/RFC4919, August 2007, 2820 . 2822 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2823 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2824 . 2826 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 2827 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 2828 September 2010, . 2830 [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS 2831 Signaling Layer Protocol (NSLP) for Quality-of-Service 2832 Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010, 2833 . 2835 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 2836 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2837 2011, . 2839 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2840 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2841 January 2012, . 2843 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 2844 Statement and Requirements for IPv6 over Low-Power 2845 Wireless Personal Area Network (6LoWPAN) Routing", 2846 RFC 6606, DOI 10.17487/RFC6606, May 2012, 2847 . 2849 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2850 Locator/ID Separation Protocol (LISP)", RFC 6830, 2851 DOI 10.17487/RFC6830, January 2013, 2852 . 2854 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2855 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2856 2014, . 2858 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2859 Constrained-Node Networks", RFC 7228, 2860 DOI 10.17487/RFC7228, May 2014, 2861 . 2863 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 2864 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 2865 Defined Networking (SDN): Layers and Architecture 2866 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2867 2015, . 2869 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 2870 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 2871 Internet of Things (IoT): Problem Statement", RFC 7554, 2872 DOI 10.17487/RFC7554, May 2015, 2873 . 2875 [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information 2876 Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 2877 2017, . 2879 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 2880 . 2882 [WirelessHART] 2883 www.hartcomm.org, "Industrial Communication Networks - 2884 Wireless Communication Network and Communication Profiles 2885 - WirelessHART - IEC 62591", 2010. 2887 Appendix A. Related Work In Progress 2889 . This document has been incremented as the work progressed 2890 following the evolution of the WG charter and the availability of 2891 dependent work. The intent was to publish when the WG concludes on 2892 the covered items. At the time of publishing the following 2893 specification are still in progress and may affect the evolution of 2894 the stack in a 6TiSCH-aware node. 2896 A.1. Chartered IETF work items 2898 The operation of the Backbone Router [I-D.ietf-6lo-backbone-router] 2899 is stable but the RFC is not published yet. The protection of 2900 registered addresses against impersonation and take over will be 2901 guaranteed by Address Protected Neighbor Discovery for Low-power and 2902 Lossy Networks [I-D.ietf-6lo-ap-nd], which is not yet published 2903 either. 2905 New procedures have been defined at ROLL that extend RPL and may be 2906 of interest for a 6TiSCH stack. In particular 2907 [I-D.ietf-roll-unaware-leaves] enables a 6LN that implements only 2908 [RFC8505] and avoid the support of RPL. 2910 A.2. Unchartered IETF work items 2912 A.2.1. 6TiSCH Zerotouch security 2914 The security model and in particular the zerotouch join process 2915 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] depends on the ANIMA 2916 [ANIMA] Bootstrapping Remote Secure Key Infrastructures (BRSKI) 2917 [I-D.ietf-anima-bootstrapping-keyinfra] to enable zero-touch security 2918 provisionning; for highly constrained nodes, a minimal model based on 2919 pre-shared keys (PSK) is also available. As written to this day, it 2920 also depends on a nmuber of documents in progress as CORE, and on 2921 "Ephemeral Diffie-Hellman Over COSE (EDHOC)" 2922 [I-D.selander-ace-cose-ecdhe], which is facing significant opposition 2923 at ACE. 2925 A.2.2. 6TiSCH Track Setup 2927 ROLL is now standardizing a reactive routing protocol based on RPL 2928 [I-D.ietf-roll-aodv-rpl] The need of a reactive routing protocol to 2929 establish on-demand constraint-optimized routes and a reservation 2930 protocol to establish Layer-3 Tracks is being discussed at 6TiSCH but 2931 not chartered for. 2933 At the time of this writing, the formation of a new working group 2934 called RAW for Reliable and Available Wireless networking is being 2935 considered. During the PAW BoF that took place on that matter, one 2936 of the considered work items was to develop a generic specification 2937 for Tracks that would cover 6TiSCH requirements as expressed in this 2938 architecture. 2940 ROLL is also standardizing an extension to RPL to setup centrally- 2941 computed routes [I-D.ietf-roll-dao-projection] The work on 2942 centralized Track computation is deferred to a subsequent work, not 2943 necessarily at 6TiSCH. A Predicatable and Available Wireless (PAW) 2944 bar-BoF took place; the formation of a new working group called RAW 2945 for Reliable and Available Wireless networking is being considered. 2946 RAW may form as a WG and develop a generic specification for Tracks 2947 that would cover 6TiSCH requirements as expressed in this 2948 architecture, more in [I-D.thubert-raw-technologies] 2950 The 6TiSCH Architecture should thus inherit from the DetNet 2951 [I-D.ietf-detnet-architecture] architecture and thus depends on it. 2952 The Path Computation Element (PCE) should be a core component of that 2953 architecture. An extension to RPL or to TEAS [TEAS] will be required 2954 to expose the 6TiSCH node capabilities and the network peers to the 2955 PCE, possibly in combination with [I-D.rahul-roll-mop-ext]. A 2956 protocol such as a lightweight PCEP or an adaptation of CCAMP [CCAMP] 2957 G-MPLS formats and procedures could be used in combination to 2958 [I-D.ietf-roll-dao-projection] to install the Tracks, as computed by 2959 the PCE, to the 6TiSCH nodes. 2961 A.2.3. Using BIER in a 6TiSCH Network 2963 ROLL is actively working on Bit Index Explicit Replication (BIER) as 2964 a method to compress both the dataplane packets and the routing 2965 tables in storing mode [I-D.thubert-roll-bier]. 2967 BIER could also be used in the context of the DetNet service layer. 2968 BIER-TE-based OAM, Replication and Elimination 2969 [I-D.thubert-bier-replication-elimination] leverages BIER Traffic 2970 Engineering (TE) to control in the data plane the DetNet Replication 2971 and Elimination activities, and to provide traceability on links 2972 where replication and loss happen, in a manner that is abstract to 2973 the forwarding information. 2975 a 6loRH for BitStrings [I-D.thubert-6lo-bier-dispatch] proposes a 2976 6LoWPAN compression for the BIER Bitstring based on 6LoWPAN Routing 2977 Header [RFC8138]. 2979 A.3. External (non-IETF) work items 2981 The current charter positions 6TiSCH on IEEE Std. 802.15.4 only. 2982 Though most of the design should be portable on other link types, 2983 6TiSCH has a strong dependency on IEEE Std. 802.15.4 and its 2984 evolution. The impact of changes to TSCH on this Architecture should 2985 be minimal to non-existent, but deeper work such as 6top and security 2986 may be impacted. A 6TiSCH Interest Group at the IEEE maintains the 2987 synchronization and helps foster work at the IEEE should 6TiSCH 2988 demand it. 2990 Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would 2991 logically include the 6top sublayer. The interaction with the 6top 2992 sublayer and the Scheduling Functions described in this document are 2993 yet to be defined. 2995 ISA100 [ISA100] Common Network Management (CNM) is another external 2996 work of interest for 6TiSCH. The group, referred to as ISA100.20, 2997 defines a Common Network Management framework that should enable the 2998 management of resources that are controlled by heterogeneous 2999 protocols such as ISA100.11a [ISA100.11a], WirelessHART 3000 [WirelessHART], and 6TiSCH. Interestingly, the establishment of 3001 6TiSCH Deterministic paths, called Tracks, are also in scope, and 3002 ISA100.20 is working on requirements for DetNet. 3004 Author's Address 3006 Pascal Thubert (editor) 3007 Cisco Systems, Inc 3008 Building D 3009 45 Allee des Ormes - BP1200 3010 MOUGINS - Sophia Antipolis 06254 3011 FRANCE 3013 Phone: +33 497 23 26 34 3014 Email: pthubert@cisco.com